Major Capability Acquisition (MCA)
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 Systems Engineer supports the production of a preliminary system design that achieves a suitable level of system maturity for low-risk entry into EMD. Usually the Systems Engineer implements a strategy of prototyping on a system element or subsystem level, balancing capability needs and design considerations to synthesize system requirements for a preliminary end-item design for the system.
Technical Outputs from the TMRR Phase include:
- Preliminary system design
- Updated functional and allocated baselines
- Associated technical products including associated design and management decisions
- Trade-off analysis results
- Updated results could include knees-in-the-curves sensitivity analyses, product selections, etc.
- Updated results of automation trades: Informed advice for automation levels as related to system architecture or software and personnel cost trades
- Informed advice for CDD validation; showing how cost varies as a function of system requirements (including Key Performance Parameters), major design parameters and schedule; identify major affordability drivers
Reference Source: DAG CH 3–4.3 Design Considerations
The Program Manager (PM) and Systems Engineer should consider and document all statutory and regulatory requirements, as well as other design considerations, in order to:
- Translate the end-user desired capabilities into a structured system of interrelated design specifications that support delivery of required operational capability.
- Enable trade-offs among the design considerations in support of achieving desired mission effectiveness within cost and schedule constraints.
- Incorporate design considerations into the set of system requirements, as some are mandated by laws, regulations or treaties, while others are mandated by the domain or DoD Component or Agency; these mandates should be incorporated during the Requirements Analysis process to achieve balance across all system requirements.
Some design considerations are concepts that assist trade-offs and should be accommodated or applied to each system or program. Others are constraints, boundaries or limitations, with values that can sometimes be tailored or negotiated, but which generally represent immovable parts of the trade space. The PM and Systems Engineer should show evidence of critical thinking in addressing the design considerations, as documented in the program SEP. According to the SEP Outline, the SEP should include a table of design considerations that are critical to the program and are an integral part of the design process, including trade-off analyses.
With the understanding that each design consideration is a discrete item to investigate during the design process, the PM, Systems Engineer, and other stakeholders should also view design considerations as an integrated set of variables that can influence one another. The PM and Systems Engineer should consider them in conjunction with one another, as early as the Analysis of Alternatives, to achieve better mission performance and to preclude a stovepipe view during design.
The design considerations listed in Table 42 should be assessed for applicability to the system, as they may not all be appropriate. Table 42 lists the statutory requirements for the design considerations covered in this chapter, as well as applicable policy and guidance related to those design considerations. See the DAG Chapter 3 Design Considerations Standards supplemental guidance for a partial list of government and Department of Defense (DoD) adopted non-government standards relevant to the design considerations listed in Table 42.
Program Managers and Systems Engineers can incorporate the standards into acquisition contracts to support delivery of required operational capability. It is important to note the supplemental guidance contains several mandatory standards.
Table 42 is not all inclusive; it does not include any additional design considerations levied by the Service, the Center, the platform, or the domain. Not all design considerations are equally important or critical to a given program, but all should be examined for relevancy.
Policy & Guidance
|Accessibility (Section 508 Compliance)||
|Affordability – SE Trade-Off Analysis||
|Corrosion Prevention and Control (CPC)||
|Critical Safety Item (CSI)||
|Demilitarization and Disposal||
|Diminishing Manufacturing Sources and Material Shortages (DMSMS)||
|Environment, Safety and Occupational Health (ESOH)||
|Human Systems Integration (HSI)||
|Intelligence (Life-cycle Mission Data Plan (LMDP))||
|Interoperability and Dependency (I&D)||
|Item Unique Identification (IUID)||
|Packaging, Handling, Storage and Transportation (PHS&T)||
|Producibility, Quality & Manufacturing (PQM)||
|Reliability & Maintainability (R&M) Engineering||
|Survivability (including CBRN) & Susceptibility||
|System Security Engineering (SSE)||
Reference Source: DAG CH 3-3.2.3 TMRR Phase
Inputs for TMRR Phase
DoD Component combat developer (e.g., Requirements Manager) provides:
|Analysis of Alternatives (AoA) Report and AoA Sufficiency Report (See CH 2–2.3.)|
Preferred materiel solution
|Acquisition Decision Memorandum (ADM) (may contain additional direction)|
|SEP (See CH 3–2.2. Systems Engineering Plan)|
Reliability, Availability, Maintainability and Cost Rationale (RAM-C) Report (See CH 3–4.3.19.)
Reliability Growth Curves (RGC) (See CH 3–4.3.19.)
|Program Protection Plan (PPP) (See CH 9–22.214.171.124.)|
Trade-off analysis results
Assumptions and constraints
|Environment, safety and occupational health (ESOH) planning (See CH 3–4.3.9.)|
Risk assessment (See CH 3–4.1.5.)
|Consideration of technology issues|
Initial identification of critical technologies
|Interdependencies/interfaces/memoranda of agreements (MOAs)|
|Life-Cycle Mission Data Plan for Intelligence Mission Data (IMD)-dependent programs (See CH 3–4.3.12. Intelligence (Life-Cycle Mission Data Plan) and CH 7–4.1.3.)|
|Draft system performance specification|
Other technical information generated during the MSA phase
|Validated On-Line Life-cycle Threat (VOLT) Report (See CH 7–4.1.2.)|
Affordability Assessment (See CH 1–4.2.15. and CH 3–4.3.2.)
|AS (See CH 1–4.1.)|
|Life-Cycle Sustainment Plan (LCSP) (See CH 4–3.1.)|
|Test and Evaluation Master Plan (TEMP) (See CH 8–4.1.)|
Informed advice to the developmental test and evaluation (DT&E) assessments (See CH 8–4.1.)
|Draft and final Request for Proposal (RFP)|
|Security Classification Guide (SCG)|
|Spectrum Supportability Risk Assessment (See DoDI 4650.01 and CH 3–4.3.20.)|
Develop Functional and Allocated Baselines
Reference Source: DAG CH 3-4.1.6 Configuration Management Process
Functional Baseline: Describes the system’s performance (functional, interoperability and interface characteristics) and the verification required to demonstrate the achievement of those specified characteristics. It is directly traceable to the operational requirements contained in the Initial Capabilities Document (ICD). The Program Manager (PM) establishes Government control of the functional baseline at the System Functional Review (SFR) and verifies it through Functional Configuration Audits (FCA) leading up to the system-level FCA or the System Verification Review (SVR). Attributes of the functional baseline include:
- Assessed to be achievable within cost and schedule constraints
- Documentation of established interfaces between functional segments
- Documented performance requirements traced to (draft) Capability Development Document (CDD) requirements
- Reflects design considerations and clear linkage in the systems of systems (SoS) context
- Documented verification requirements
Allocated Baseline: Describes the functional and interface characteristics for all system elements (allocated and derived from the higher-level product structure hierarchy) and the verification required to demonstrate achievement of those specified characteristics. The allocated baseline for each lower-level system element (hardware and software) is usually established and put under configuration control at the system element Preliminary Design Review (PDR). This process is repeated for each system element and culminates in the complete allocated baseline at the system-level PDR. The PM then verifies the allocated baseline at the FCA and/or SVR. Attributes of the allocated baseline include:
- All system-level functional performance requirements decomposed (or directly allocated) to lower-level specifications (configuration items (CI) for system elements)
- Uniquely identified CIs for all system elements at the lowest level of the specification tree
- All interfaces, both internal (between element CIs) and external (between the system under development and other systems), documented in interface control documents
- Verification requirements to demonstrate achievement of all specified functional performance characteristics (element CI to element CI level and at the system level) documented
- Design constraints documented and incorporated into the design
Reference Source: DAG CH 3–4.2.3 Architecture Design Process
The Architecture Design process is a trade and synthesis method to allow the Program Manager (PM) and Systems Engineer to translate the outputs of the Stakeholder Requirements Definition and Requirements Analysis processes into alternative design solutions and establishes the architectural design of candidate solutions that may be found in a system model. The alternative design solutions may include hardware, software and human elements; their enabling system elements; and related internal and external interfaces. The Architecture Design process, combined with Stakeholder Requirements Definition and Requirements Analysis, provides key insights into technical risks early in the acquisition life cycle, allowing for early development of mitigation strategies. Architecture Design is integral to ensuring that multiple well-supported solutions are considered. The Architecture Design process supports analysis of design considerations and enables reasoning about key system aspects and attributes such as reliability, maintainability, survivability, sustainability, performance and total ownership cost.
Architecture design synthesizes multiple potential solutions from system performance requirements, evaluates those solutions and eventually describes the system down to the individual system element for implementation. The Architecture Design process is iterative and strives to seek a balance among cost, schedule, performance, and risk that still meets stakeholder needs. The development of the system architecture should adhere to sound systems engineering (SE) and conform to industry standards as applicable. The functional architecture should be part of the functional baseline, and the physical architecture should be part of the allocated and product baselines. The system architecture should be placed under configuration control and maintained in a robust repository that maintains the architecture descriptions and its relationships to each of the baselines. This control provides the Systems Engineer with a means of ensuring consistency of the system architecture definition throughout the acquisition life cycle.
The functional architecture provides the foundation for defining the system architecture through the allocation of functions and sub-functions to hardware/software, databases, facilities and human operations to achieve its mission. The physical architecture consists of one or more product structures, or views, of the physical solution. The product structure may consist of conceptual design drawings, schematics and/or block diagrams that define the system’s form and the arrangement of the system elements and associated interfaces. The DoD Architecture Framework (DoDAF) provides guidance on how to generate operational and system views that describe interface relationships in a manner common across the DoD user community (see the DoD CIO DoDAF page for additional information).
The development of the physical architecture is an iterative and recursive process and evolves together with the functional requirements and functional architecture. Development of the physical architecture is complete when the system has been decomposed to the lowest system element (usually the lowest replaceable unit of the support strategy). It is critical that this process identify the design drivers and driving requirements as early as possible.
The PM may oversee Architecture Design efforts to gain and maintain insights into program schedule and cost drivers for use in the evaluation of alternative architectures, excursions, mitigation approaches, etc.
Key activities in the Architecture Design process include:
- Analyzing and synthesizing the physical architecture and appropriate allocation.
- Analyzing constraint requirements.
- Identifying and defining physical interfaces and system elements.
- Identifying and defining critical attributes of the physical system elements, including design budgets (e.g., weight, reliability) and open system principles.
During this process, derived requirements come from solution decisions. It is essential to identify derived requirements and ensure that they are traceable and part of the allocated requirements. For each given solution alternative, the Decision Analysis process trades off requirements against given solution alternatives. For each solution alternative, based on programmatic decisions, certain performance requirements may be emphasized over others. The essence of this activity is to achieve a balanced and feasible design with acceptable risk; that falls within the program design constraints. An integral part of defining and refining the functional and physical architecture is to provide technical support to the market research, especially early in the acquisition life cycle. Systems engineers should analyze whether existing products (commercial or non-developmental items) can meet user performance requirements or whether technologies can realistically be matured within the required time frame. When possible, mature technologies should be used to satisfy end-user needs.
The output of this process is the allocated baseline, which includes the documentation that describes the physical architecture of the system and the specifications that describe the functional and performance requirements for each configuration item, along with the interfaces that compose the system. In addition, Work Breakdown Structures (WBS) and other technical planning documentation are updated. The system architecture and the resulting design documentation should be sufficiently detailed to:
- Confirm the upward and downward traceability of requirements.
- Confirm the interoperability and open system performance requirements.
- Sufficiently define products and processes to support implementation, verification and validation of the system.
- Establish achievable alternatives to allow key stakeholders to make informed decisions.
Confirmation of requirements traceability and the soundness of the selected physical architecture can be accomplished using a cost-effective combination of design modeling and analysis, as applicable.
The result of the Architecture Design process is an architectural design that meets the end-user capability needs shown in the Requirements Management process to have all stated and derived requirements allocated to lower-level system elements and to have the possibility of meeting cost, schedule and performance objectives. The architectural design should be able to be communicated to the customers and to the design engineers. The level of detail of the architectural design depends on the complexity of the system and the support strategy. It should be detailed enough to bound the cost and schedule of the delivered system, define the interfaces, assure customers that the requirements can be met and control the design process down to the lowest removable unit to support operations and sustainment. This architecture design may be documented and found in a program’s system model. Once identified, the system architecture is placed under configuration management.
Modular Open Systems Approach (MOSA)
Reference Source: 10 USC 2446a
Requirement for modular open system approach in major defense acquisition programs
Modular Open System Approach Requirement.— A major defense acquisition program that receives Milestone A or Milestone B approval after January 1, 2019, shall be designed and developed, to the maximum extent practicable, with a modular open system approach to enable incremental development and enhance competition, innovation, and interoperability. Definitions.—In this chapter:
The term “modular open system approach” means, with respect to a major defense acquisition program, an integrated business and technical strategy that—employs a modular design that uses major system interfaces between a major system platform and a major system component, between major system components, or between major system platforms; is subjected to verification to ensure major system interfaces comply with, if available and suitable, widely supported and consensus-based standards; uses a system architecture that allows severable major system components at the appropriate level to be incrementally added, removed, or replaced throughout the life cycle of a major system platform to afford opportunities for enhanced competition and innovation while yielding—(i) significant cost savings or avoidance; (ii) schedule reduction; (iii) opportunities for technical upgrades; (iv) increased interoperability, including system of systems interoperability and mission integration; or (v) other benefits during the sustainment phase of a major weapon system; and complies with the technical data rights set forth in section 2320 of this title.
The term “major system platform” means the highest level structure of a major weapon system that is not physically mounted or installed onto a higher level structure and on which a major system component can be physically mounted or installed.
The term “major system component”—means a high level subsystem or assembly, including hardware, software, or an integrated assembly of both, that can be mounted or installed on a major system platform through well-defined major system interfaces; and includes a subsystem or assembly that is likely to have additional capability requirements, is likely to change because of evolving technology or threat, is needed for interoperability, facilitates incremental deployment of capabilities, or is expected to be replaced by another major system component.
The term “major system interface”—means a shared boundary between a major system platform and a major system component, between major system components, or between major system platforms, defined by various physical, logical, and functional characteristics, such as electrical, mechanical, fluidic, optical, radio frequency, data, networking, or software elements; and is characterized clearly in terms of form, function, and the content that flows across the interface in order to enable technological innovation, incremental improvements, integration, and interoperability.
The term “program capability document” means, with respect to a major defense acquisition program, a document that specifies capability requirements for the program, such as a capability development document or a capability production document. The terms “program cost targets” and “fielding target” have the meanings provided in section 2448a(a) of this title. he term “major defense acquisition program” has the meaning provided in section 2430 of this title. The term “major weapon system” has the meaning provided in section 2379(f) of this title.
Reference Source: DODI 5000.88 Section 3.7
The LSE, under the direction of the PM, will use a modular, open systems approach in product designs to the maximum extent practicable in accordance with Sections 2446a, 2446b, and 2446c of Title 10, U.S.C. The modular and open systems approach will be documented in the digital authoritative source of truth. The PM will acquire the appropriate rights to the interface technical data to allow system evolution and interoperability in accordance with the program’s IP strategy.
The PM will use an appropriate open business model and system architecture that allows major system components to be severable at the appropriate level for incremental addition, removal, or replacement over the system’s life-cycle. The selection of severable components will take into consideration:
- Enhanced competition and innovation.
- Cost savings or avoidance.
- Incremental and evolutionary technical upgrades.
- Schedule reduction.
- Increased system-on-system interoperability, mission integration, and reuse across the joint force.
- Availability of IP and government rights thereto.
In accordance with Sections 2446a, 2446b, and 2446c of Title 10, U.S.C., the LSE, working for the PM, will clearly define major system interfaces between the major system platform and major system components, between major system components, and between major system platforms. Specifically consider the expected evolution of the platform, subsystem, and major component as well as interdependent systems dependencies.
The LSE, working for the PM, will use consensus-based standards for interfaces, unless unavailable or unsuitable, and provide open sharing of definitions to interdependent programs. The PM will provide justification to the MDA if consensus-based standards are not used.
In support of Milestone B (or equivalent), the PM will provide to the MDA the program’s modular open system approach. The MDA will review the approach to ensure standardized interfaces and appropriate arrangements for obtaining necessary IP rights have been addressed and implemented. The PM will provide justification to the MDA if MOSA is not used. The MDA will review and determine whether or not the justification to not use MOSA is appropriate.
The PM will ensure that the RFPs for development or production contracts include compliance with MOSA enabling interfaces, the modular open system approach, appropriate data rights requests, and identification of the minimum set of major system components to which the design and data sharing requirements apply.
Reference Source: DAG CH 3-2.4.1 Modular Open Systems Approach
A modular open systems approach (MOSA) is defined as an acquisition and design strategy consisting of a technical architecture that adopts open standards and supports a modular, loosely coupled and highly cohesive system structure. This modular open architecture includes publishing of key interfaces within the system and relevant design disclosure. The key enabler for MOSA is the adoption of an open business model that requires doing business in a transparent way that leverages the collaborative innovation of numerous participants across the enterprise, permitting shared risk, maximized reuse of assets and reduced total ownership costs. The combination of open systems architecture and an open business model permits the acquisition of systems that are modular and interoperable, allowing for system elements to be added, modified, replaced, removed and/or supported by different vendors throughout the life cycle in order to afford opportunities for enhanced competition and innovation. MOSA is not an end result sought by the warfighter or end-item user; it is an approach to system design that can enable additional characteristics in the end item.
DoD identifies the primary benefits of MOSA as:
- Increased interoperability
- Enhanced competition
- Facilitation of technology refresh
- Increased innovation
- Potential cost savings or cost avoidance
MOSA benefits Program Managers (PMs) by using a general set of principles to help manage system complexity by breaking up complex systems into discrete pieces, which can then communicate with one another through well-defined interfaces. In this way, MOSA is broadly defined and inclusive of a variety of tools and practices.
Acquisition programs adopting MOSA may benefit from:
- Reduced life-cycle costs without sacrificing capability
- Reduced reliance on single-source vendors (“Vendor Lock”)
- Shortened program acquisition timeline
- Enhanced rapid and agile development
- Accelerated transition from science and technology into acquisition due to modular insertion
- Increased ability and flexibility to retrofit/upgrade system elements for new/evolving capability
- Enhanced incremental approach to capabilities
- Increased competition and innovation
- Enhanced ability to create security structures within a design to reduce security risk
MOSA may also benefit warfighters by:
- Reducing operator learning curves by using systems that have similar functions and are operated in similar ways, thereby reducing costs
- Increasing interchangeability
- Reducing support and sustainment costs
Although a PM may employ MOSA to achieve some or all of these benefits, the methods the PM’s staff uses, and the associated business implications, can vary widely and may drive different techniques and additional responsibilities into programs. The implementation strategy chosen should consider both impacts to the program and to the system’s performance (e.g., its effectiveness and feasibility). These factors underpin the Department’s policy for MOSA in acquisition.
PMs are to evaluate and implement MOSA where feasible and cost-effective. The USD(AT&L) memorandum, “Better Buying Power 2.0: Continuing the Pursuit for Greater Efficiency and Productivity in Defense Spending,” November 13, 2012, raises the relevance of MOSA along with the acquisition of data rights for appropriate system elements. The overarching business case for DoD is increasing the level of competition by enabling small and large businesses to participate in competition for new or upgraded capabilities. Programs should develop a business model, documenting the strategy for use of MOSA and associated data rights.
The DoD Open Systems Architecture Contract Guidebook for Program Managers contains guidance regarding contract language programs should use to acquire data rights in support of a program’s MOSA strategy.
The PM should:
- Establish supportive requirements; business practices; and technology development, acquisition, test and evaluation and product support strategies for effective development of open systems
- Ensure data deliverables support the Intellectual Property (IP) Strategy (see Acquisition Strategy template) and secure the necessary data rights to support and sustain the system.
- Map modular open systems strategy and functional architecture to Statement of Work (SOW) requirements, Data Item Descriptions (DID) and Contract Data Requirements List (CDRL) items consistently across the enterprise.
- Ensure compliance.
- Consider including MOSA as one of the evaluation criteria for contract proposals.
- Determine the appropriateness of MOSA by considering software constraints, security requirements and procedures, availability and cost of data rights, life-cycle affordability and reliability of open standards, as well as other relevant factors such as environmental constraints (e.g., temperature, humidity) and environment, safety and occupational health (ESOH) considerations
The Systems Engineer should:
- Employ an overall plan for MOSA that supports the system functional architecture and uses prescribed USD(AT&L) business case analyses
- Ensure the system functional architecture is structured to accommodate Open Systems Architecture (OSA) where feasible, due to the high potential for reduced risk and cost
- Assess performance
- Balance current implementation of MOSA with performance and evolving technology at the physical level; MOSA establishes a technical baseline that may support modular architecture, but formally constrains the interfaces between modules, where interfaces close to current performance limits may quickly become obsolete
- Evaluate the technical appropriateness of MOSA by considering software constraints, security requirements and procedures, availability and cost of data rights, life-cycle affordability and reliability of open standards, as well as other relevant factors, such as environmental constraints (e.g., temperature, humidity) and ESOH considerations
Open systems benefits may not be realized without deliberate planning and guidance at the Program Executive Office (PEO) level. Re-use may be challenging if open systems and software on other systems (even other open systems) are not developed and modularized in a common fashion. As an example, an aviation platform may develop an Automatic Dependent Surveillance-Broadcast (ADS-B) software application that is MOSA conformant, but that application may never be re-used by a sister platform that may have its ADS-B and Tactical air navigation software combined in a single module.
Modular open system designs, developed from the system architecture, should be analyzed at each design review because there is a link between MOSA and the level and type of technical data, computer software and data rights the Government needs for life-cycle support. In many cases weapon systems using MOSA system elements can have increased opportunities for competitive sourcing during the life-cycle sustainment, and a correspondingly lesser need for detailed design data and associated data rights. This benefit enables an incremental approach to capability adaptation in MOSA-enabled systems and is a benefit of the modularity originally specified in the functional architecture.
The engineering trade analyses conducted prior to Milestone B help determine which system elements can be adapted to MOSA in order to reduce program cost and development time lines. Correct application of MOSA principles and practices results in modular system elements having well-defined functions and open standards-based interfaces. Threat analyses, functional criticality analyses, technology opportunities and evolved capability assessments are examples of assessments against the functional architecture to determine which system elements should be MOSA-enabled. When these system elements require an upgrade, replacement should be competitive, faster and cheaper because the MOSA-enabled system elements are modular. Because system functional architecture maps from the higher-level enterprise architecture, engineering trade analyses and assessments supporting MOSA should be completed and MOSA-enabled system elements specified, before contracts are let for technology development of those system elements. Successful implementation of MOSA approaches requires the synchronized acquisition of data rights for modular open systems and interfacing architecture elements. These data rights are initially structured to support acquisition of modular open system designs but also should address life-cycle support.
Figure 4 depicts an example architectural approach for mapping and assessing which system element interfaces can be open, how associated risk is ascertained and how to visualize the impact to interfaces with other system elements. The figure presents a top-level system view of the MOSA characteristics of system elements. Not all interfaces need to be open at any one level of the design, only those that are required to meet anticipated incremental capability updates, changes in threat or technology insertion. A system view such as this includes a record of the data rights that are required to enable the planned MOSA design. The levels of data rights that need to be required for each MOSA-enabled system element are determined in order to assert the requisite contract requirements to obtain them. The data rights strategy ensures that enterprise-level data rights flow to system elements and that they support the system architecture. Levels of data rights are described in Chapter (CH) 1 and in Appendix 9 of the OSA Contract Guidebook.
Successfully implementing a MOSA strategy results in the identification of required technical data and software deliverables necessary to field and maintain weapon systems and their logistics support. The Acquisition Strategy should be updated throughout the system’s life cycle to reflect changes in the MOSA approach resulting from technology and software evolutionary developments. The Systems Engineering Plan (SEP) is also updated to reflect the MOSA-related updates and modifications employed throughout the system and its system elements.
Specific MOSA-related data deliverables that should be considered include:
- Software Development Plans (DI-IPSC-81427)
- Software Development Status Reports (DI-MCCR-80459)
- Software Development Summary Reports (DI-MCCR-80902)
- Software Design Descriptions (DI-IPSC-81435)
- Hardware development plans and Hardware Design Descriptions
In addition, the PM should maintain an open systems management plan. The plan describes the offeror’s approach for:
- OSA, modularity and open design
- Inter-system element dependencies
- Design information documentation
- Technology insertion
- Life-cycle sustainability
- Interface design and management
- Treatment of proprietary or vendor-unique elements
- Reuse of preexisting items, including all commercial-off-the-shelf/non-developmental item (COTS/NDI) system elements, their functionality and proposed function in the system
- Copies of license agreements related to the use of COTS/NDI system elements for Government approval
The open system management plan should also include a statement explaining why each COTS/NDI system element was selected for use.
Program products typically used in making decisions regarding MOSA include:
- System Requirements
- Acquisition Strategy (AS)
- Program Protection Plan (PPP)
- Analysis of Alternatives (AoA)
- Enterprise Architecture
Modular open systems approaches and requirements should be addressed at design reviews, e.g., System Requirements Review (SRR), Preliminary Design Review (PDR and Critical Design Review (CDR).
See DoD Acquisition Streamlining and Standardization Information System (ASSIST) homepage for more data item deliverables that may be appropriate for each specific program and DoD 5010.12-M for data deliverables.
Mature Technology and Perform Systems Trade Analysis
Reference Source: DAG CH 3-3.2.3 TMRR Phase
Perform Technology Maturation. The AS identifies technologies requiring further maturation before they can be implemented within a solution. Technology maturation involves design, development, integration and testing. There could be one or more risk areas related to hardware, software or information technology, and there may be multiple industry contracts/Government efforts for maturing the technology. The TEMP should stipulate the test and evaluation approach for assessing the results of the technology maturation activities (see CH 8–4.2.). The Systems Engineer participates in the technology readiness assessment (TRA). The TRA focuses only on technology maturity as opposed to engineering and integration risk. OSD TRA Guidance provides policy and guidance for TRAs.
Perform System Trade Analysis. The Systems Engineer assesses alternatives with respect to performance, cost, schedule and risk, and makes a recommendation to the PM. The SE assessment should consider the full range of relevant factors, for example, affordability goals and caps, technology maturity, development and deployment constraints, modular open system approaches and user-identified needs and shortfalls. System trades should be used to inform and shape the CDD and cost and schedule objectives to be documented in the Acquisition Program Baseline (APB).
Modeling and Simulation
Reference Source: DAG CH 3-2.4.2 Modeling and Simulation
Models and simulations are SE tools used by multiple functional area disciplines during all system life-cycle phases. Models, simulations, data and artifacts should be developed in a well-defined and controlled engineering environment to support the program’s reuse of the information across the acquisition life cycle or for reuse and repurposing in support of other acquisition efforts. All models, simulations, data and artifacts are to be integrated, managed and controlled to ensure that the products maintain consistency with the system and external program dependencies, provide a comprehensive view of the program and increase efficiency and confidence throughout the program’s life cycle. Models are essential to aid in understanding complex systems and system interdependencies, and to communicate among team members and stakeholders. Simulation provides a means to explore concepts, system characteristics and alternatives; open up the trade space; facilitate informed decisions and assess overall system performance.
Models and simulations provide:
- Understanding of capabilities and the requirements set
- Data to inform program and technical decisions
- Efficient communication and shared understanding among stakeholders about relationships between system requirements and the system being developed, through precise engineering artifacts and traceability of designs to requirements
- Exploration of system alternatives to support the early identification of viable system solutions and any necessary doctrine change requests
- An alternative solution for building prototypes and enabling cost savings
- Better analysis and understanding of system designs, including system elements and enabling system elements
- Improved capability to address defects and failures at all levels through a greater understanding of the system.
- Support to engineering and design trade-off analysis studies
- Support for early interface and interoperability testing
- Greater efficiencies in design and manufacturing by reducing the time and cost of iterative build/test/fix cycles
- Timely understanding of program impacts of proposed changes
- Insight into program cost, schedule, performance and supportability risk
The Systems Engineering Digital Engineering Fundamentals recommends that all programs identify and maintain a system model, representing all necessary viewpoints on the design and capturing all relevant system interactions. The system model should include, but not be limited to, parametric descriptions, structure, definitions of behaviors, design assumptions, internal and external interfaces, cost inputs and traces from operational capabilities to requirements and design constructs.
The system model should be captured digitally to create an integrated set of authoritative technical data, information and knowledge, generated and used by all stakeholders throughout the system life cycle. Use of a digital system model can help drive consistency and integration among SE and analytical tools, and provide the program with a capability to assess potential design changes, as well as system upgrades, throughout the life cycle. The Program Manager (PM) and Systems Engineer should consider establishing and using a digital system model when planning for the development, incorporation and application of models, simulations and analyses on their program. Figure 5 shows some benefits of using models and simulation throughout the acquisition life cycle. This figure is adapted from a 2010 National Defense Industrial Association (NDIA) Systems Engineering Division “Model-Based Engineering (MBE)” study and is used with permission.
Models and simulations should take advantage of opportunities for reuse (see DoD Modeling and Simulation Catalog [requires Common Access Card (CAC) to access website]). Models and simulations developed in early acquisition phases may be repurposed for other activities during later phases (e.g., engineering models can be used in training simulations). SE should use models and simulations from many disciplines and across a hierarchy of perspectives that range from an engineering/technical level up to the campaign/strategic level in order to effectively analyze requirements, design, cost, schedule, performance and risk. These models and simulations often exist, but sometimes need to be newly developed, which can be costly. An option for new development is to consider federating existing models and simulations, using any of various interoperability standards in order to create needed capability. PMs and Systems Engineers should consider how to leverage models, simulations, and their interoperability as they plan for their use throughout a program’s life cycle. Modeling and simulation is also used to support developmental test and evaluation (DT&E) and operational test and evaluation (OT&E).
Roles, Responsibilities, and Activities
To make effective and appropriate use of models and simulations, the PM and Systems Engineer should ensure that planned modeling and simulation activities are:
- Complete, comprehensive and trusted, including all efforts anticipated throughout the life cycle, to include planning, development and acceptance as well as verification, validation, and accreditation (VV&A) (see CH 8–3.7.7.)
- Integrated into the program’s technical planning (Work Breakdown Structure (WBS), schedules, budgets, Systems Engineering Plan (SEP) and other program documentation; see CH 3–4.1.1.Technical Planning Process)
- Appropriately resourced, including a properly skilled workforce
The PM and Systems Engineer should establish, manage, control, and maintain integrated sources of all relevant models, simulations, data and other artifacts that describe what the system is and does. These data sources also should contain descriptive system information that could be used to feed other models, simulations and acquisition efforts.
Figure 6 provides examples of models, simulations and analyses throughout the life cycle.
The PM and Systems Engineer should ensure that the program’s modeling and simulation activities are coordinated, managed and controlled such that products are consistent with the system and architecture design at all levels. Plans to use models and simulations should be integrated with the overall program plan. The program may choose to integrate the modeling and simulation planning details into the program plan or create a separate modeling and simulation planning document. If the documents are separate, the program ensures the modeling and simulation planning is kept up to date as the program plan adjusts. PMs should follow their organization’s standards for planning, managing and controlling such activities.
Models and simulations should be:
- Developed and matured through the life of the program
- Developed and documented, to include metadata and open standards, to maximize opportunity for reuse and repurposing (both within the program and in support of other acquisition efforts)
- Properly managed and controlled as part of the program’s technical baseline.
- Included as part of the technical data package to be transitioned into the next phase of the life cycle or into other efforts
Models, data and artifacts should be evident in the contents of the required program technical reviews and in the baselined technical data needed to support major program reviews and program decisions.
Reference Source: DAG CH 4-3.3.2 Design Interface
During the EMD phase, the PM continues to assess and refine technological and programmatic risks to achieving performance requirements, including sustainment and affordability, and works with design engineers to demonstrate the R&M requirements during Developmental Test.
Reference Source: DODI 5000.88 Section 3.6
The impact of specialty engineering activities on total system cost, schedule, and performance will determine the extent of their application during the system design process. Execution of activities in specialty engineering will, to the largest extent practicable, use information from, and contribute to, the digital authoritative source of truth.
Reference Source: DODI 5000.88 Section 3.6.a
The development and sustainment of software can be a major portion of the total system cost and should be considered throughout the acquisition life-cycle.
The PM will select the appropriate software development approach based on scope, requirements, schedule, and risk, and should consider an iterative software development process using modern agile development and operations methods. The PM should:
- Assign a lead software engineer to manage the software acquisition team, software engineering processes, and delivery of code.
- Consider establishing a software factory with multiple pipelines to deliver capability in a series of manageable, minimum viable products, to gain user acceptance and feedback for the next viable product. The software factory includes the trained personnel, culture, architecture, processes, and tools that automate the activities in software development, build, test, and delivery cycles.
The PM and lead software engineer will implement a software development approach. The approach will address:
- Software architecture design considerations.
- Software re-use and commercial off-the-shelf (COTS) integration.
- Software obsolescence.
- Inclusion of software configuration items in technical reviews.
- Software system safety and software security considerations.
- Metrics identification, tracking, and reporting to address software technical performance, development process, and quality.
- Software development resources.
- Software unique program risks.
The program may automate collection of metrics as much as possible.
For those metrics that cannot be automated initially, the program may develop a plan for moving toward automation. Programs may consider providing an automated read only self-service metrics portal for the Program Office, PEO, CAE, Defense Acquisition Executive (DAE), OUSD(A&S), OUSD(R&E), and other approved stakeholders as deemed appropriate. PMs will be cognizant of and comply with DoDI 4630.09 in their software engineering development approach. The PM and lead software engineer will document the software development approach and minimum metrics in the SEP. The PM and lead software engineer will estimate the overall size and cost of the software development project using multiple software estimation methods. Initial software sizing estimates should be provided for each computer software configuration item and for each major build.
Software sizing estimates should include:
- Newly developed code.
- Reuse of pre-existing code.
- Modified existing code.
- Auto-generated software.
The integration, test, and certification of COTS software should be estimated separately in the program work break down structure. COTS software should not be included as part of the initial size estimate. Systematic estimation methods should be used to scope the software development effort and to compute software size (e.g., source lines of code, story points, function points, sprints) and must be normalized to be used for program benchmarking, comparisons for future builds and analogous programs.
Reliability and Maintainability (R&M)
Reference Source: DODI 5000.88 Section 3.6.b
For all defense acquisition programs, the LSE, working for the PM, will integrate R&M engineering as an integral part of the overall engineering process and the digital representation of the system being developed.
The LSE will plan and execute a comprehensive R&M program using an appropriate strategy consisting of engineering activities, products, and digital artifacts, including:
- R&M allocations, block diagrams, and predictions.
- Failure definitions and scoring criteria.
- Failure mode, effects, and criticality analysis,
- Maintainability and built-in test demonstrations.
- Reliability testing at the system and subsystem level.
- A failure reporting, analysis, and corrective action system maintained through design, development, test, production, and sustainment.
For ACAT I (MDAPs) and II (Major Systems) weapon systems designs, the PM will include in the contract and in the process for source selection, clearly defined and measureable R&M requirements and engineering activities as required by Section 2443 of Title 10, U.S.C. The PMs of MDAPs and Major Systems must provide justification in the acquisition strategy for not including R&M requirements and engineering activities in TMRR, EMD, or production solicitations or contracts.
For MDAPs, the PM will conduct a preliminary reliability, availability, maintainability, and cost rationale analysis in support of the Milestone A decision or program initiation decision in accordance with the Reliability, Availability, Maintainability, and Cost Rationale Report Outline Guidance.
- The analysis provides a quantitative basis for R&M performance attributes during the development of capability requirements, including product support and operating and support cost rationale and its specific correlation with the system’s R&M attributes, ensuring the requirements are valid (e.g., support warfighter needs) and technically feasible.
- The analysis will be attached to the SEP at Milestone A, or program initiation decision, and updated at subsequent milestones.
Assessments of development test data provide measures of effectiveness for the R&M engineering program and are used to track progress on reliability growth planning curves.
- The LSE, working for the PM, will develop planning curves for each reliability threshold and include them in the SEP and, beginning at Milestone B, in the Test and Evaluation Master Plan.
- Planning curves will be stated in a series of intermediate goals and tracked through fully integrated system-level test and evaluation events. If a curve is not adequate to describe overall system reliability, curves for critical subsystems should also be developed. Reliability growth will be monitored and reported in quarterly DAE Summary reviews, throughout developmental testing until the reliability threshold(s) are achieved.
The PMs of MDAPs and major systems will ensure incentive fees and penalties (as appropriate) that incentivize achievement of design specification requirements for R&M in all EMD and production solicitations and contracts is encouraged, pursuant to Section 2443 of Title 10, U.S.C.
- Data collection methods to measure R&M requirements and to base determinations of contractor performance during EMD and production will be described in the contract. The collected R&M data will be shared with appropriate contractor and U.S. Government organizations to the maximum extent practicable.
- MDAs will notify the congressional defense committees upon entering into an EMD or production contract that includes incentive fees or penalties to the contractor based on achievement of R&M design specifications. The MDA will provide a copy of the notification letters to OUSD(A&S) and OUSD(R&E).
Quality and Manufacturing
Reference Source: DODI 5000.88 Section 3.6.c
The production, quality, and manufacturing (PQM) lead, working for the PM, will ensure manufacturing, producibility, and quality risks are identified and managed throughout the program’s lifecycle.
Beginning in the materiel solution analysis phase, manufacturing readiness and risk will be assessed and documented in the SEP. By the end of the TMRR Phase, manufacturing and quality processes will be assessed and demonstrated to the extent needed to verify that risk has been reduced to an acceptable level. During the EMD Phase, the PQM lead will advise the PM on the maturity of critical manufacturing and quality processes to ensure they are affordable and executable.
Before a production decision, the PQM lead, working for the PM, will ensure that:
- Manufacturing, producibility, and quality risks are acceptable.
- Supplier qualifications are completed.
- Any applicable manufacturing processes are or will be under statistical process control.
Human Systems Integration
Reference Source: DODI 5000.88 Section 3.6.d
The LSE will:
- Working for the PM, use a human-centered design approach for system definition, design, development, test, and evaluation to optimize human-system performance.
- Conduct frequent and iterative end user validation of features and usability for identifying, communicating, and visualizing user needs under defined operational conditions and expected mission threads.
- Working for the PM, ensure human systems integration risks are identified and managed throughout the program’s life-cycle.
Reference Source: DODI 5000.88 Section 3.6.e
The system safety standard practice identifies the DoD Systems Engineering approach to eliminating hazards, where possible, and minimizing risks where those hazards cannot be eliminated.
System Safety Engineering.
The LSE, working for the PM, will:
- Integrate system safety engineering into the overall systems engineering process. The LSE will use the methodology in Military Standard (MIL-STD)-882E to address environment, safety, and occupational health (ESOH) risks associated with system-related hazards. In addition to MIL-STD-822E, the LSE will use the guidance identified in the DoD Joint Software Systems Safety Engineering Handbook to achieve an acceptable level of software system safety risk.
- Identify, document, and analyze identified hazards and assess the ESOH risks where hazards cannot be eliminated.
- The user representative, as defined in MIL-STD-882E, must be part of this process throughout the life-cycle and will provide formal concurrence before serious and high risk acceptance decisions. Before exposing people, equipment, or the environment to known system-related hazards, the LSE will document that the associated risks have been accepted by these acceptance authorities: the CAE (or DAE) for high risks, program executive officer-level for serious risks, and the PM for medium and low risks.
- For joint programs, risk acceptance authorities reside within the lead DoD Component. The PM will report the status of ESOH risks and acceptance decisions at technical reviews. Acquisition program reviews and fielding decisions will address the status of all serious and high ESOH risks. The PM will manage risks associated with ESOH statutory requirements using the program overall risk, issue, and opportunity management processes.
Programmatic ESOH Evaluation (PESHE).
- The PM of a major capability acquisition program, regardless of ACAT level, will maintain a PESHE that documents the status, results, and conclusions of the ESOH analyses and statutory compliance activities conducted in support of program execution.
- For all other acquisition pathway programs, the PESHE may be tailored based on program schedule and performance requirements.
- For all systems containing energetics, the LSE, working with the PM, will comply with insensitive munitions requirements in accordance with the DoD and component policy requirements as required by Section 2389 of Title 10, U.S.C.
- The PESHE will summarize, at a minimum:
- Identified ESOH risks and their current status.
- Required external safety reviews, approvals, and certifications.
- Section 4321 of Title 42, U.S.C., also known and referred to in this issuance as the “National Environmental Policy Act of 1969 (NEPA),” and Executive Order (E.O.) 12114 compliance schedule.
- Identified hazardous materials, wastes, and pollutants (e.g., discharges, emissions, and noise) associated with the system and its support as well as the plans for minimization and/or safe disposal.
- Additional system and ESOH information needed by users, training and test locations, and receiving activities to prepare arrival and sustainment support of the system.
NEPA and E.O. 12114.
The PM will maintain a NEPA and E.O. 12114 compliance schedule that covers all known or projected system-related activities through FOC that may trigger compliance requirements including testing, fielding, and support of the system.
- The compliance schedule will provide timelines and locations for system-related activities to enable consideration of potential impacts to the environment and completion of appropriate documentation in accordance with DoD Component implementing procedures.
- The PM will conduct and document the NEPA and E.O. 12114 analyses for which the PM is the action proponent. The PM will provide system-specific analyses and data to support other organizations’ NEPA and E.O. 12114 analyses when the PM is not the action proponent.
- The CAE or designee is the approval authority for system-related NEPA and E.O. 12114 documentation for which the PM is the action proponent. For joint programs, the CAE is the lead DoD Component.
Mishap Investigation Support.
The LSE, working for the PM, will support system-related Class A and B mishap investigations by providing analyses of hazards that contributed to the mishap and recommendations for materiel risk mitigation measures, especially those that minimize human errors.
System Safety in SEP.
The SEP will be used to document a strategy for the system safety engineering program in accordance with MIL-STD-882E. In addition, the PM will document the ESOH risk and compliance requirements management planning in the SEP by attaching the PESHE and NEPA and E.O. 12114 compliance schedule, in accordance with Section 4321 of Title 42, U.S.C.
Reference Source: DODI 5000.88 Section 3.6.f
The PM will ensure that a parts management process is used for the selection of parts during design to consider the life cycle application stresses, standardization, technology (e.g., new and ageing), reliability, maintainability, supportability, life cycle cost, and diminishing manufacturing sources and material shortages. As applicable, parts management requirements should be specified in the RFP’s statement of work for the TMRR, EMD, and production acquisition phases.