Sign In
  • Question

    Does the adapter have to undergo testing before it can be delivered as AAI? If it does what regulation (paragraph if possible) addresses this non-standard activity? I must provide guidance to the Project Office on or before 30 Jan 2020.


    Answer

    Each service will have a different view regarding the scope of testing required to verify/validate the modification you mention with the installation of the new “adapter”  to the fielded system.  There is no “by the book” solution in this this case.  Your program’s stakeholders are going to have to work out the required scope of testing on their own.  The key questions to consider are:

     

    1.            What new/additional functionality/capability does installation of the adapter to the fielded system provide?  From an operational perspective, how significant is this new/additional capability?  If the capability developer/user/warfighter determines the significance is “high” then the testing required will be much more extensive than if it were “low.”  If the significance is “high” then the program would probably need to conduct a full gamut of developmental testing (DT) and at least some level of operational testing (OT).  If the significance is “low” then I would think the program should execute just enough DT to ensure the adapter performs as required, from both a performance and reliability perspectives without causing problems to the fielded system platform.  The DT should at least focus on the following three areas:

    2.            Once installed, does the adapter perform its function to the degree required?

    3.            Once installed, has the adapter’s reliability been reduced?

    4.            Once installed, has the adapter induced any performance or reliability problems to the fielded system platform?

     

    Each service will have their own culture and test methodology, but it appears that AR 73-1, paragraph 3-5 provides good generic guidance.

     

    AR 73–1 • 8 June 2018 21

    3–5. Test and evaluation in support of system changes a. System changes to deployed systems can be accomplished via recapitalization, technology refreshment, or other improvements (such as modernization or modification) that are not part of an increment acquisition strategy and/or DBS Problem Statement. An Army recapitalization strategy can follow two paths: a rebuild or a selected-upgrade-program. Continuous technology refreshment is the intentional, incremental insertion of newer technology into existing systems to improve reliability, maintainability, or reduce cost—typically in conjunction with normal maintenance (see AR 70–1).

    b. System changes (such as modifications and upgrades) to a legacy system must be adequately tested and evaluated. A modification is a change to a system that is still in production consisting of an alteration, conversion, or modernization of an end item or component of investment equipment that changes or improves the original purpose or operational capacity in relation to effectiveness, efficiency, reliability, or safety of that item. An upgrade is a change to a system that is out of production. Such changes can be improvements to system capabilities or fixes to correct deficiencies.

    c. The integrated T&E strategy developed for a given system change will depend on the operational impact of the change. When the system change is a new or revised requirement, preplanned product improvement, or when the CAPDEV determines the system change to have (or have significant potential for) operational impact, then the level of the integrated T&E will be determined by the T&E WIPT (see chap 8).

    d. If a system change does not have operational impact, the PM (or procuring command when a PM office does not exist) will determine the actions necessary to support the decision to apply the system change. In all cases, the level of the evaluation that is required to address the impact of the change will determine the necessary testing. In particular, for computer resources (software, hardware, or firmware), the proportion of system change and the criticality of affected computer software units must be considered.

    e. If a system change compromises the baseline or causes an operational impact to the system, to include the user's operation or maintenance of the system, the previously approved system TEMP will be updated (see para 10–2c(1)).

    Open full Question Details
Chat with DAU Assistant
Bot Image