Major Capability Acquisition (MCA)

AAF  >  MCA  >  Develop System

Develop System

How to use this site

Each page in this pathway presents a wealth of curated knowledge from acquisition policies, guides, templates, training, reports, websites, case studies, and other resources. It also provides a framework for functional experts and practitioners across DoD to contribute to the collective knowledge base. This site aggregates official DoD policies, guides, references, and more.

DoD and Service policy is indicated by a BLUE vertical line.

Directly quoted material is preceeded with a link to the Reference Source.

Reference Source: Guidance from OUSD(A&S)

The previous activity (Complete System Design) culminates in a Critical Design Review (CDR), which aims to establish an initial product baseline and confirm that the system’s functions and capabilities satisfy the program’s requirements. That baseline design serves as the primary guidance for developing the initial system.

The contractor now uses the CDR-approved design to produce initial test articles to be used in Developmental Testing. These articles should be representative samples and/or prototypes which accurately represent the planned design. However, developmental test articles should also be inexpensive and flexible enough to be modified in response to initial test results. Developmental tests are likely to uncover opportunities to modify and improve the design, so artifacts produced during this activity should be built with thrift and adaptability in mind.

 

Reference Source: DODI 5000.85 Section 3C.3.e

Configuration Steering Board (CSB)

The CAE for each DoD Component will form and chair a CSB with broad executive membership, as identified in Section 814 of P.L. 110-417, as amended. The CSB will meet at least annually to review all requirements changes, critical intelligence parameter changes, and any significant technical configuration changes for ACAT I programs in development, production, and sustainment that have the potential to result in cost and schedule impacts to the program.  De-scoping options will also be considered.  CSBs will review potential requirements changes and propose to the requirements authority for validation those changes that may be necessary to achieve affordability or program goal constraints or that will result in a more cost effective product.  Changes that increase cost will not normally be approved unless funds are identified and schedule impacts are addressed. If the service acquisition executive (SAE) determines in writing that there have been no changes to program requirements or adversary advancements against critical intelligence parameters in the preceding year, the CSB is not required to meet.

Realization

Reference Source: DAG CH 3-4.2.4 Implementation Process

Realization is the process of building the system elements using specified materials and fabrication and production tools/procedures identified during design. Early fabrication and production planning is critical for the successful realization and delivery of the needed capability. System elements are built to the product baseline and should meet quality standards. Realization activities may include:

  • Obtaining or acquiring access to materials and tools required to build system elements.
  • Obtaining external system elements as applicable.
  • Building system elements in accordance with implementation procedures, tolerances and applicable ESOH, security, and privacy.
  • Determining system elements functionality against specified product quality characteristics.
  • Document fabrication and production issues and associated corrective actions.
  • Delivering implemented system elements for integration and verification.

The output of the Implementation process is the physical system elements as identified in the product baseline, including fabrication and production methods.