The many systems and software engineering process standards and capability models use different terms to describe the processes, activities, and tasks within the systems engineering and other life-cycle processes. This chapter uses the terminology in Table 4.2.3.T1 to represent generic systems engineering processes. They are grouped in two categories: Technical Management Processes and Technical Processes:

Table 4.2.3.T1. Chapter Terminology

Technical Management Processes	Technical Processes
Decision Analysis	Stakeholders Requirements Definition
Technical Planning	Requirements Analysis
Technical Assessment	Architectural Design
Requirements Management	Implementation
Risk Management	Integration
Configuration Management	Verification
Technical Data Management	Validation
Interface Management	Transition

These generic processes are described briefly below and applied throughout the life-cycle phases. More detail with regard to systems engineering processes can be found in any of the above-mentioned standards or capability models. Because systems engineering cannot be conducted without good organization and project processes, as well as sufficient infrastructure, these standards and capability models also may include processes and activities, such as organizational training, that are beyond the technical ones that may be considered specific to systems engineering. Throughout this chapter, the term "system element" is used to indicate a subsystem, a component, or a configuration item, depending on the systems engineering context and phase of acquisition under discussion. Also, throughout this document, the term "configuration item" generally refers to both software and hardware items.

4.2.3.1. Technical Management Processes

The program manager uses technical management processes to manage the technical development of the system increments, including the supporting or enabling systems. This section of the Guidebook discusses the eight technical management processes that are used throughout the life cycle. Section 4.2.3.2 describes the eight technical processes. Section 4.5 describes in detail the key techniques and tools for technical management, oversight and analysis.

4.2.3.1.1. Decision Analysis

Decision Analysis is a discipline that employs many procedures, methods, and tools for identifying, representing, and formally assessing the important aspects of alternative decisions (options) to select an optimum (i.e., the best possible) decision. Decision Analysis activities provide the basis for evaluating alternatives and selecting the optimum decision. It involves selecting the criteria for the decision and the methods to be used in conducting the analysis. For example, during system design, analysis is conducted to help chose among alternatives to achieve a balanced, supportable, safe, robust, and cost-effective system design. These analyses include, but are not limited to, trade studies, system analysis, system safety analyses, trade off analysis, supportability analysis, level of repair analysis, post fielding support analysis, repair versus discard analysis, and cost analysis. These studies/analyses should be augmented with models and simulation, or virtual and/or physical prototypes, where applicable, before making decisions on the best alternative. The criteria to determine the best alternative may include, for example, interoperability constraints, size, transportability requirements, maintenance concept, producibility, affordability, reliability, availability and maintainability goals, and schedule.

The Decision Analysis process for system of systems includes the development of integrated approaches that rely on data sharing, collaboration, and interoperability to execute assessment and decision making effectively. The system of systems analysis plan should consider the constituent systems analysis plans and integrate such plans across multiple organizations.

4.2.3.1.2. Technical Planning

Technical Planning activities provide the critical quantitative input to program planning and ensure that the systems engineering processes are applied properly throughout a system's life cycle. Technical Planning defines the scope of the technical effort required to develop, field, and sustain the system. The scope of the technical effort includes the following:

Work Breakdown Structure for the technical activities and tasks,
Integrated Master Plan for all technical activities and tasks,
Time phased sequence of the technical effort in an event driven Integrated Master Schedule, and
Resources (skilled workforce, support equipment/tools and facilities) required to develop, field, and sustain the system.

The scope of the technical effort is critical to provide the basis for a program cost estimate (Independent Cost Estimate and/or Cost Analysis Requirements Document), Risk Identification and Risk Analysis, and to provide the quantitative measures supporting the Technical Assessment Process. Also, the resulting program estimates and risk assessments are essential elements to support Milestone Review decisions, establish the Performance Measurement Baseline and enable mandatory program certifications (e.g., section 2366a or section 2366b).

A mandated tool for Technical Planning, required for every program milestone, is the Systems Engineering Plan. Each of the 16 technical and technical management processes requires planning. The application of these technical processes can identify constraints, dependencies, and interfaces that will result in derived technical requirements.

4.2.3.1.3. Technical Assessment

Technical Assessment activities measure technical progress and assess both program plans and requirements. Activities within Technical Assessment include those associated with Technical Performance Measurement, the conduct of Technical Reviews (including Preliminary Design Review/Critical Design Review Reports, when required), Program Management Review (PMR), Technical Interchange Meeting (TIM), Interface Control Working Group (ICWG), Program Support Reviews (PSR), Assessment of Operational Test Readiness (AOTR), Risk Identification, the support of Certification, and Earned Value Management (EVM) (whenever it is required in accordance with DoD Instruction 5000.02, Table 5, EVM Implementation Policy). A structured technical review process should demonstrate and confirm completion of required accomplishments and exit criteria as defined in program and system planning. The Preliminary Design Review is an example of a technical review that is mandatory for all MDAPs and will be scheduled before MS B. Technical reviews are discussed in detail in Section 4.3 and summarized in Section 4.5.9. Technical Assessment activities discover problems (deficiencies or anomalies) and warnings of potential program problems that often lead to corrective action. This information is provided to the Program Manager and contributes to the Quarterly Defense Acquisition Executive Summary (DAES) Report.

A TIM is often held to address technical issues and will result in detailed discussion of technical alternatives, risks, recommendations, and action items. The government and industry team members attend the technical meeting as required to address the agenda and meeting purpose. Typically, the Statement of Work (SOW) tasks the contractor to participate in the TIM, capture minutes, and forward any TIM findings or any recommendations to the responsible Integrated Product Team(s) (IPT) or lead systems engineer.

A PMR is regularly conducted at defined intervals (monthly or quarterly) by the Program Manager for the purpose of determining the status of an assigned system. PMRs are designed as tools to report program status, identify issues and problems, discuss risks, and to develop appropriate follow-up actions as required. Typically, the SOW tasks the contractor to participate in the PMR and to capture minutes.

The ICWG is the traditional forum to establish official communications links between those responsible for the design of interfacing systems or components. Within the IPT framework, ICWGs can be integrated teams that establish linkages between interfacing design IPTs, or could be integrated into a system-level engineering working group. Membership of ICWGs or comparable integrated teams should include representatives from each contractor, significant vendors, and participating government agencies the procuring program office (external and selected top-level interfaces) or prime contractor (internal interfaces) generally designates the chair.

The Deputy Assistant Secretary of Defense (Systems Engineering) (DASD(SE)) shall have access to any DoD component records or data relating to systems engineering and development planning (including classified, unclassified, competition sensitive, and proprietary information) necessary to carry out assigned duties (see Directive-Type Memorandum (DTM) 09-027 – Implementation of the Weapon Systems Acquisition Reform Act of 2009).

4.2.3.1.4. Requirements Management

Requirements Management provides traceability back to user-defined capabilities as documented through either the Joint Capabilities Integration and Development System or other user-defined source, and to other sources of requirements. Requirements traceability is one function of requirements management. As the systems engineering process proceeds, requirements are developed to increasing lower levels of the design. Requirements traceability is conducted throughout the system life cycle and confirmed at each technical review. Traceability between requirements documents and other related technical planning documents, such as the Test and Evaluation Master Plan, should be maintained through a relational data base, numbering standards, or other methods that show relationships. A good requirements management system should allow for traceability from the lowest level component all the way back to the user capability document or other source document from which it was derived. The program manager should institute Requirements Management to do the following:

Maintain the traceability of all requirements from capabilities needs through design and test,
Document all changes to those requirements, and
Record the rationale for those changes.

Emerging technologies and threats can influence the requirements in the current as well as future increments of the system. In evolutionary acquisition and systems of systems, the management of requirements definition and changes to requirements take on an added dimension of complexity.

4.2.3.1.5. Risk Management

Risk management is the overarching process that encompasses identification, analysis, mitigation planning, mitigation plan implementation, and tracking. Risk management should begin at the earliest stages of program planning and continue throughout the total life cycle of the program. Additionally, risk management is effective only if it is fully integrated with the program's systems engineering and program management processes. This is accomplished through the identification of risk drivers, dependencies, root causes, and consequence management. A common misconception, and program office practice, concerning risk management is to identify and track issues (vice risks) and then manage the consequences (vice the root causes). Risks should not be confused with issues (realized risks). If a root cause is described in the past tense, the root cause has already occurred, and is therefore an issue that needs to be resolved but not a risk.

Risk management is critical to acquisition program success. Addressing risk on programs helps ensure that program cost, schedule, and performance objectives are achieved at every stage in the life cycle and communicates to stakeholders the process for uncovering, determining the scope of, and managing program uncertainties. Because risk can be associated with all aspects of a program, it is important to recognize that risk identification is part of everyone's job, not just that of the systems engineer or program manager.

Risk

Risk is a measure of future uncertainties in achieving program performance goals and objectives within defined cost, schedule, and performance constraints. Risk can be associated with all aspects of a program (e.g., threat environment, hardware, software, human interface, technology maturity, supplier capability, design maturation, performance against plan,) as these aspects relate across the work breakdown structure and Integrated Master Schedule.
The impact of software development and integration efforts should be addressed as part of the program's risk management activities. Risk addresses the potential variation in the planned approach and its expected outcome.

Risk has three components:

A future root cause (yet to happen), which, if eliminated or corrected, would prevent a potential consequence from occurring,
A probability (or likelihood) assessed at present of that future root cause occurring, and
The consequence (or effect) of that future occurrence.

A future root cause is the most basic reason for the presence of a risk. Accordingly, risks should be linked to future root causes and their effects.

The risk management process includes the following key activities, performed on a continuous basis (See Figure 4.2.3.1.5.F1 Risk Management Process – Key Activities):

Risk Identification
Risk Analysis,
Risk Mitigation Planning,
Risk Mitigation Plan Implementation, and
Risk Tracking.

Figure 4.2.3.1.5.F1. Risk Management Process – Key Activities

Risk Identification

Risk identification is the activity that examines each element of the program to identify associated root causes, begin their documentation, and set the stage for their successful management. Risk identification begins as early as possible in successful programs and continues throughout the program with regular reviews and analyses of Technical Performance Measurements/Critical Technical Parameters, schedule, resource data, life-cycle cost information, Earned Value Management data/trends, progress against critical path, technical baseline maturity, safety, operational readiness, and other program information available to program Integrated Product Team members.

The intent of risk identification is to answer the question "What can go wrong?" by:

Looking at current and proposed staffing, schedules, process, design, supplier, operational employment, resources, dependencies, etc.,
Monitoring test results especially test failures (readiness results and readiness problems for the sustainment phase),
Reviewing potential shortfalls against expectations,
Analyzing negative trends, and
Conducting system safety and environmental analyses.

Risk Analysis

The intent of risk analysis is to answer the question "How big is the risk?" by:

Considering the likelihood of the root cause occurrence;
Identifying the possible consequences in terms of performance, schedule, and cost; and
Identifying the risk level using the Risk Reporting Matrix.

Each undesirable event that might affect the success of the program (performance, schedule, and cost) should be identified and assessed as to the likelihood and consequence of occurrence. A standard format for evaluation and reporting of program risk assessment findings facilitates common understanding of program risks at all levels of management. The Risk Reporting Matrix below is typically used to determine the level of risks identified within a program. The level of risk for each root cause is reported as low (green), moderate (yellow), or high (red).

Risk Mitigation Planning

The intent of risk mitigation planning is to answer the question "What is the program approach for addressing this potential unfavorable consequence?" One or more of these mitigation options may apply:

Avoiding risk by eliminating the root cause and/or the consequence,
Controlling the cause or consequence,
Transferring the risk, and/or
Assuming the level of risk and continuing on the current program plan.

Risk mitigation planning is the activity that identifies, evaluates, and selects options to set risk at acceptable levels given program constraints and objectives. Risk mitigation planning is intended to enable program success. It includes the specifics of what should be done, when it should be accomplished, who is responsible, and the funding and schedule tasks required to implement the risk mitigation plan. The most appropriate program approach is selected from the mitigation options listed above and documented in a risk mitigation plan. The level of detail depends on the program life-cycle phase and the nature of the need to be addressed. However, there must be enough detail to allow a general estimate of the effort required and technological capabilities needed based on system complexity.

Risk Mitigation Plan Implementation

The intent of risk mitigation (plan) execution is to ensure successful risk mitigation occurs. It answers the question "How can the planned risk mitigation be implemented?"

The risk mitigation plan:

Determines what planning, budget, schedule tasks, requirements and contractual changes are needed,
Provides a coordination vehicle with management and other stakeholders,
Directs the teams to execute the defined and approved risk mitigation plans,
Outlines the risk reporting requirements for on-going monitoring, and
Documents the change history.

Implementing risk mitigation should also be accomplished by risk category, and it is important for this process to be worked through the IPT structure, requiring the IPTs at each WBS level to scrub and endorse the risk mitigations of lower levels. It is important to mitigate risk where possible before passing it up to the next WBS level. In addition, each IPT must communicate potential cost or schedule growth to all levels of management. It is imperative that the Systems Engineer and Program Manager understand and approve the mitigation plan and examine the plan in terms of secondary, unforeseen impacts to other elements of the program outside of the risk owning IPT. As part of this effort, the IPTs should ensure effective mitigation plans are implemented and ongoing results of the risk management process are formally documented and briefed, as appropriate, during program and technical reviews.

Risk Tracking

The intent of risk tracking is to ensure successful risk mitigation. It answers the question "How are things going?" by:

Communicating risks to all affected stakeholders,
Monitoring risk mitigation plans,
Reviewing regular status updates,
Displaying risk management dynamics by tracking risk status within the Risk Reporting Matrix (see Figure 4.2.3.1.5. F2), and,
Alerting management as to when risk mitigation plans should be implemented or adjusted.

Figure 4.2.3.1.5.F2 Risk Reporting Matrix

Risk tracking activities are integral to good program management. At a top level, periodic program management reviews and technical reviews provide much of the information used to identify any performance, schedule, readiness, and cost barriers to meeting program objectives and milestones. Risk tracking documents may include: program metrics, technical reports, earned value reports, watch lists, schedule performance reports, technical review minutes/reports, and critical risk processes reports.

Typical risk sources include:

Threat. The sensitivity of the program to uncertainty in the threat description, the degree to which the system design would have to change if the threat's parameters change, or the vulnerability of the program to foreign intelligence collection efforts (sensitivity to threat countermeasure).
Requirements. The sensitivity of the program to uncertainty in the system description and requirements, excluding those caused by threat uncertainty. Requirements include operational needs, attributes, performance and readiness parameters (including KPPs), constraints, technology, design processes, and WBS elements.
Technical Baseline. The ability of the system configuration to achieve the program's engineering objectives based on the available technology, design tools, design maturity, etc. Program uncertainties and the processes associated with the "ilities" (reliability, supportability, maintainability, etc.) must be considered. The system configuration is an agreed-to description (an approved and released document or a set of documents) of the attributes of a product, at a point in time, which serves as a basis for defining change.
Test and Evaluation. The adequacy and capability of the test and evaluation program to assess attainment of significant performance specifications and determine whether the system is operationally effective, operationally suitable, and interoperable.
Modeling and Simulation (M&S). The adequacy and capability of M&S to support all life-cycle phases of a program using verified, validated, and accredited models and simulations.
Technology. The degree to which the technology proposed for the program has demonstrated sufficient maturity to be realistically capable of meeting all of the program's objectives.
Logistics. The ability of the system configuration and associated documentation to achieve the program's logistics objectives based on the system design, maintenance concept, support system design, and availability of support data and resources.
Production/Facilities. The ability of the system configuration to achieve the program's production objectives based on the system design, manufacturing processes chosen, and availability of manufacturing resources (repair resources in the sustainment phase).
Concurrency. The sensitivity of the program to uncertainty resulting from the combining or overlapping of life-cycle phases or activities.
Industrial Capabilities. The abilities, experience, resources, and knowledge of the contractors to design, develop, manufacture, and support the system.
Cost. The ability of the system to achieve the program's life-cycle support objectives. This includes the effects of budget and affordability decisions and the effects of inherent errors in the cost estimating technique(s) used (given that the technical requirements were properly defined and taking into account known and unknown program information).
Management. The degree to which program plans and strategies exist and are realistic and consistent. The government's acquisition and support team should be qualified and sufficiently staffed to manage the program.
Schedule. The sufficiency of the time allocated for performing the defined acquisition tasks. This factor includes the effects of programmatic schedule decisions, the inherent errors in schedule estimating, and external physical constraints.
External Factors. The availability of government resources external to the program office that are required to support the program such as facilities, resources, personnel, government furnished equipment, etc.
Budget. The sensitivity of the program to budget variations and reductions and the resultant program turbulence.
Earned Value Management System. The adequacy of the contractor's EVM process and the realism of the integrated baseline for managing the program.

Risk Management Tools:

There are many types of software solutions available to help you with risk management tasks. Each tool provides some specific capability as part of an overall Risk Management process. The Tools can largely be broken down into the following categories:

Risk Management Systems - web-based, highly scalable systems (running on databases such as MS SQL Server or Oracle) that integrate into planning or requirements applications (such as Telelogic DOORS, MS Project or Primavera) and assist with the identification, assessment, management, analysis, reporting and communication of risk information (cost, schedule, technical, etc.) on projects and operations.
Standalone Tools - may be web-based or client tools that are limited in scalability (normally running on databases such as Excel or Access) that assist with some or all of the following on smaller projects: identification, assessment, analysis, and communication of risk information.
Analysis Tools - assist in the quantification of risk information (normally one or more of the following: cost, schedule and/or technical) from either a risk register or a planning applications (such as Microsoft Project or Primavera).

Additional information on this subject is in the Risk Management Guide for DoD Acquisition and the MIL-STD-882E, "DoD Standard Practice for System Safety" for environment, safety, and occupational health risk management (see section 4.4.7.5).

4.2.3.1.6. Configuration Management

DoD Instruction 5000.02, Enclosure 12, paragraph 5, directs the use of configuration management across the total system life cycle per the following extract:

The PM shall use a configuration management approach to establish and control product attributes and the technical baseline across the total system life cycle. This approach shall identify, document, audit, and control the functional and physical characteristics of the system design; track any changes; provide an audit trail of program design decisions and design modifications; and be integrated with the SEP and technical planning. At completion of the system level Critical Design Review, the PM shall assume control of the initial product baseline for all Class 1 configuration changes.

Configuration management is the application of sound program practices to establish and maintain consistency of a product's or system's attributes with its requirements and evolving technical baseline over its life. It involves interaction among government and contractor program functions such as systems engineering, hardware/software engineering, specialty engineering, logistics, contracting, and production in an Integrated Product Team environment. The program manager should use configuration management to establish and mature the technical baseline throughout the acquisition life cycle.

4.2.3.1.6.1. Configuration Management of the Technical Baseline

The technical baseline includes user requirements, program and product information and related documentation for all configuration items (i.e., those system elements under configuration management). Configuration items can consist of the integrated master schedule, system requirements, specifications, hardware, software, and documentation (data). A configuration management process guides the system products, processes, and related documentation, and facilitates the development of open systems. Configuration management efforts result in a complete audit trail of plans, decisions and design modifications. Configuration management functions include the following:

Planning and Management—Provides total life-cycle configuration management planning for the program/project and manages the implementation of that planning,
Identification—Establishes configuration information and documentation of functional and physical characteristics of each configuration items. Documents agreed-to configuration baselines and changes to those configurations that occur over time,
Change Management—Ensures that changes to a configuration baseline are properly identified, recorded, evaluated, approved or disapproved, and incorporated and verified, as appropriate. A common change method is the Engineering Change Proposal. See MIL-HDBK-61A.
Status Accounting—Manages the capture and maintenance of product configuration information necessary to account for the configuration of a product throughout the product life cycle, and
Verification and Audit—Establishes that the performance and functional requirements defined in the technical baseline are achieved by the design and that the design is accurately documented in the technical baseline.

The technical baseline consists of many configuration documents, technical review artifacts, and information objects. Typically these include: specifications, drawings, interface control documents, requirements, parts lists or bill of materials, software documentation, standards, processes, models and simulations, architecture descriptions, and other associated items. A technical data package is the subset of this information associated with a related acquisition, production, engineering, or sustainment activity.

4.2.3.1.6.2. Establishment of Configuration Baselines

The concept of baselines is central but not unique to configuration management. The Acquisition Program Baseline (APB) provides key cost, schedule, and performance objectives and thresholds for each major program milestone. Similarly, configuration baselines are established for specific events and contribute to the performance portion of a program's APB. Typically, a configuration baseline would be established for each of the technical reviews discussed throughout Section 4.3 and summarized in Section 4.5.9.

At a minimum, to mature the technical baseline, the following configuration baselines should be established:

Functional Baseline—Definition of the required system functionality describing functional and interface characteristics of the overall system, and the verification required to demonstrate the achievement of those specified functional characteristics. This baseline is derived from the Capability Development Document (CDD) and normally includes a detailed functional performance specification for the overall system and the tests necessary to verify and validate overall system performance. The functional baseline is normally established and put under configuration control at the System Functional Review. It is usually verified with a System Verification Review and/or a Functional Configuration Audit (FCA).
Allocated Baseline—Definition of the configuration items making up a system, and then how system function and performance requirements are allocated across lower level configuration items (hence the term allocated baseline). It includes all functional and interface characteristics that are allocated from the top level system or higher-level configuration items, derived requirements, interface requirements with other configuration items, design constraints, and the verification required to demonstrate the traceability and achievement of specified functional, performance, and interface characteristics. The performance of each configuration item in the allocated baseline is described in its preliminary design specification as are the tests necessary to verify and validate configuration item performance. The allocated baseline is usually established and put under configuration control at each configuration item's (hardware and software) Preliminary Design Review (PDR), culminating in a system allocated baseline established at the system-level PDR.
Product Baseline—Documentation describing all of the necessary functional and physical characteristics of a configuration item; the selected functional and physical characteristics designated for production acceptance testing; and tests necessary for deployment/installation, operation, support, training, and disposal of the configuration item. The initial product baseline includes "build-to" specifications for hardware (product, process, material specifications, engineering drawings, and other related data) and software (software module design— "code-to" specifications). The Initial product baseline is usually established and put under configuration control at each configuration item's Critical Design Review (CDR), culminating in an initial system product baseline established at the system-level CDR. By DoD policy, the PM shall assume control over this initial product baseline after the system-level CDR and control all Class 1 changes. Until completion of the System Verification Review (SVR) and/or FCA, Class 1 changes shall be those changes that affect the government performance specification. Following the SVR/FCA, the government will further define contractually what constitutes a Class 1 change. The system product baseline is finalized and validated at the Physical Configuration Audit.

Figure 4.2.3.1.6.2.F1 shows the relationship of the various configuration baselines and a specification tree for a sample program.

Once established, these configuration baselines (functional, allocated, product) may be managed by either the program office or the contractor, depending upon the nature of the contractual relationship between the parties. Additional information on configuration management processes is provided in the following standards and best practices:

Figure 4.2.3.1.6.2.F1. Depiction of a sample set of configuration baselines

ANSI/EIA 649A, "Configuration Management," available for sale on the Information Technology Association of America website
ISO 10007, "Quality management systems - Guidelines for configuration management," available for sale on the American National Standards Institute website
ISO/TS 10303-403:2010, "Industrial automation systems and integration - Product data representation and exchange - Part 403: Application module: AP203 configuration controlled 3D design of mechanical parts and assemblies," available for sale on the American National Standards Institute website
EIA-836-A, "Configuration Management Data Exchange and Interoperability," available for sale on the Information Technology Association of America website
MIL-HDBK-61A, "Configuration Management Guidance"
MIL-STD-1916, "DOD Preferred Methods for Acceptance of Product"

4.2.3.1.7. Data Management

Data are defined as recorded information regardless of the form or method of recording. Data management applies policies, procedures and information technology to plan for, acquire, access, manage, protect, and use data of a technical nature to support the total life cycle of the system. Data is used to gain insight and provide guidance to systems development programs through sustainment.

Data management in this chapter will focus on technical data, which is any data other than computer software that is of a scientific or technical nature. This includes data associated with system development, configuration management, test and evaluation, installation, parts, spares, repairs and product sustainment. Data specifically not included would be data relating to tactical operations information; sensor or communications information; financial transactions; personnel data; and other data of a purely business nature. Technical data can exist in many forms: paper or electronic documents, specifications, drawings, lists, records, repositories, standards, models, correspondence, and other descriptions of a system. Additional guidance relative to data is contained in section 5.1.6.

Data management plays an important role in facilitating other systems engineering processes. Data management:

Enables collaboration and life cycle use of acquisition system product data,
Captures and organizes all systems engineering artifacts input to, processed by, or output from systems engineering processes,
Documents traceability among requirements, designs, solutions, decisions, and rationale,
Records engineering decisions, procedures, methods, results, and analyses,
Facilitates technology insertion for affordability improvements during reprocurement and post-production support,
Supports configuration management, risk management, interface management, requirements management, trade-off analyses, technical assessment, and technical review activities, and
Enables advanced concepts, such as Knowledge-Based Acquisition and model based systems engineering (also see section 11.8).

Data management also enables sharing of system data that is required to support collaboration and oversight with other government and industry organizations and authorities. Systems Engineering Managers should work with the Contractor (through the SOW) to establish a common, electronic data management capability in order to facilitate and document all systems engineering documents, drawings, decisions, meeting notes and decisions. This process is critical to the success of the Government / Contractor IPT interface.

Under the life cycle management approach, the program manager is responsible for data management for each phase of the system life cycle. The program manager should determine the data needs of the program (including external obligations) and develop a long-term strategy that integrates data requirements across all functional disciplines. Corresponding plans for data management should be included in the Systems Engineering Plan. This responsibility includes proper indexing and management of product data, to include indexing that data within the Military Engineering and Data Asset Locator System (MEDALS), to formally store that data for the life cycle of the program, and beyond. The following resources provide additional information related to data management:

Data Management Community of Practice (CoP), located on the Acquisition Community Connection on the Defense Acquisition University (DAU) website,
DoD 5010.12-M, Procedures for the Acquisition and Management of Technical Data, May 1993 (http://www.dtic.mil/whs/directives/corres/html/501012m.htm),
GEIA-859, Consensus Standard for Data Management, located on the GEIA website (http://www.geia.org/) (click on STANDARDS), and
"Intellectual Property: Navigating Through Commercial Waters", October 15, 2001.

4.2.3.1.7.1. Data Acquisition

Data acquisition encompasses all activities that create, obtain, or access data from internal or external sources to satisfy data requirements driven by the data strategy. When at all possible, data should be acquired in a structured format that is independent of the method of access or delivery and defined by or based on open standards. Open data exchange formats promote interoperability of systems engineering tools and repositories, improve the meaning and understanding of data and its reuse, foster collaboration and competition, and help to ensure access to data consistently throughout the system life cycle and across systems of systems. Consider the following standards for defining the structure of digital data:

Object Management Group (OMG) Systems Modeling Language (SysML) (http://www.omgsysml.org/), and
S1000D International Specification for Technical Publications Utilizing a Common Source Database (http://www.s1000d.org/)

The decision to purchase data should be carefully examined, as there may be situations where access to required data is not sufficient to support life cycle needs. In accordance with the Weapons Systems Acquisition Reform Act, the PM and Chief SE should work closely with the program's Logistic Lead to establish life cycle data requirements and include these data as requirements of the EMD contract. This agreed to approach must be documented in the Life Cycle Sustainment Plan and the EMD contract requirements. DoD 5010.12-M provides information specific to acquiring data from contractors, such as the role and use of Contract Data Requirements Lists and Data Item Descriptions. PMs should always consult with contracting and legal subject matter experts when crafting technical data acquisition strategies.

4.2.3.1.7.2. Data Protection

The program manager is responsible for protecting system data, whether the data is stored and managed by the government or by contractors. The DoD policy with regard to data protection, marking, and release can be found in DoD Instruction 5230.24, DoD Directive 5230.25, DoD 5400.7-R, and DoD 5200.1-M. Data containing information subject to restrictions are required to be protected in accordance with the appropriate guidance, contract, or agreement. Guidance on distribution statements, restrictive markings, and restrictions on use, release, or disclosure, of data can be found in the DFARS Part 252.227-7013 &7014, and DoD Directive 5230.24. When digital data is used, the data should display applicable restriction markings, legends, and distribution statements clearly visible when the data is first opened or accessed. These safeguards not only assure government compliance with use of data but also guarantee and safeguard contractor data that are delivered to the government, and extend responsibilities of data handling and use to parties who subsequently use the data.

Section 208 of Public Law 107-347 and DoD Privacy Impact Assessment (PIA) guidance requires that PIA be conducted prior to developing or purchasing any DoD information system that will collect, maintain, use, or disseminate personally identifiable information about members of the public, federal personnel, DoD contractors and, in some cases, foreign nationals. Available PIA Guidance provides procedures for completing and approving PIAs in the Department of Defense. For further details, see section 7.5.6.4.

All data deliverables should include distribution statements. Processes should be established to protect all data that contain critical technology information, as well as ensure that limited distribution data, intellectual property data, or proprietary data is properly handled throughout the life cycle, whether the data are in hard-copy or digital format.

4.2.3.1.7.3. Data Storage

The program manager also has responsibility for addressing long-term storage and retrieval of data and associated program information. This includes long-term planning and incremental digitization, as required, to ensure that applicable data are available, preserved, and migrated to successive formats for future planning and use.

4.2.3.1.7.4. Definition and Scope of Data

The topic of data is very broad and relevant to all stakeholders in an enterprise or project that produce, consume and manage data. The DFARS provides specific definitions for data, and it is important to understand the context and associated definitions when engaging in data related discussions. The figure below depicts a hierarchy of the types of data that are relevant to an enterprise or project. Each data element, tagged 1, 2 and 3, are followed with definitions.

Figure 4.2.3.1.7.4.F1. Data Depiction and Scope

4.2.3.1.7.4.1. Data Definition (1)

The term Data is the broadest definition of data and applies to the entire project or enterprise. Data is defined as follows:

"Recorded information regardless of the form or method of recording. The term includes technical data, computer software documentation, financial information, management information, representation of facts, numbers, or datum of any nature that can be communicated, stored, and processes to form information and other information required by a contract to be delivered to, or accessed by, the Government." DFARS

4.2.3.1.7.4.2. Technical Data Definition (2)

For the purposes of DoD acquisition programs and the acquisition and management of data; technical data is the scope of interest. The term technical data is defined as:

"Recorded information (regardless of the form or method of the recording) of a scientific or technical nature (including computer software documentation) relating to supplies procured by an agency. Such term does not include computer software or financial, administrative, cost or pricing, or management data or other information incidental to contract administration." See 10 U.S.C. 2302(4)."

For ACAT I and II programs, a Technical Data Rights Strategy is required prior to each milestone review as part of the Acquisition Strategy. The acquisition, management, and rights are defined in the Strategy. For additional guidance, refer to Guidebook section 2.8.7.6.

4.2.3.1.7.4.3. Technical-Product Data Definition (3)

The term Technical Product data defines the data that systems engineering have primary concern. Systems engineering is a key stakeholder in the development of the DMS and should advocate the technical product data that needs to be included in the DMS. The definition of Technical Product Data is:

"Information that describes the product's performance, functional, and physical attributes, including requirements information (e.g. specifications and requirements documents) and design information (e.g. drawings, part models, software listings and design descriptions). Product information provides the technical basis for actions taken during all product life-cycle phases for product validation and for product operational information."

Technical-Product Data is "All data created as a consequence of defining (requirements), designing, testing, producing, packaging, storing, distributing, operating, maintaining, modifying and disposing of a product."

Technical - Product definition information - information that defines the product's requirements, documents the product's attributes and is the authoritative source for configuration definition and control.

Technical - Product operational information - information used to operate, maintain and dispose the product.

Technical - Associated information - information generated as part of the product development and life-cycle management process, but isn't clearly definable as either of the other two categories.

The following sub paragraphs further delineate Technical-Product Data.

Technical Product - Definition Data
Examples of Technical-Product Definition Data include:
- Design Information
  Design Technical-product data Package (TDP) consisting of:
  - Drawings
  - 3-D CAD Drawings
  - Specifications
  - Lists
  - SW documentation
  - Interface Control Documents
  - Engineering Product Structure
- Other Design Information
  Other design information is related to the product and product decisions but not directly associated to the specification or design of the product. Examples consist of:
  - Trade Study Reports
  - Design Selection Worksheets
  - Engineering Analysis
  - Models and Test Cases
- Requirements Information
  Requirements information consists of originating requirements that the program uses as source documentation. The following are examples that a given program will need to maintain:
  - Requirements Document Information
  - Joint Capabilities Development System (JCIDS) Documents
  - Integrated Architecture Model Information and Views ( AVs, OVs, SVs and TVs)
  - External Interface Control Documents
  - GFE/CFE Documentation
  - Other Requirements

Other requirements are those requirements not specific to the product or implementation of the product. The following are examples:

Contract Statement of Work (SOW)
Process Standards (e.g. CMMI )

Technical-Product Operational Information
Technical-Product Operation Information is defined from the product definition information. Product operational information consists of procedures and technical information needed by operators and support personnel to operate, maintain and dispose of the product. Product operational information also includes field data that can be fed back into the product design improvement and the status accounting processes.
Examples of Technical-Product Operational Information include:
- Logistics Management Information (LMI)
  - Maintenance Planning Information
  - Technical Manuals
  - Interactive Electronic Manuals (IETMs)
  - Technical Publications
  - Support & Test Equipment Information
  - Supply Support Information
  - Manpower, Personnel & Training Information
  - Packaging, Handling, Storage & Transportation Information
  - Environment Safety & Occupational Health Information
  - Material IN-Service Information
  - Field Feedback Information
  - Demand Data from Field requisitions
  - Item Prognostics & Diagnostics Information
  - Field Quality Deficiency Reports
  - Product Unit Configuration Information
Technical-Product Associated Information
Technical-Product Associated Information is generated as part of product development and life-cycle management process, but isn't clearly definable as either product definition information or product operational information. This category of product data relates to the processes used in product definition, validation and operation, but doesn't necessarily directly describe the final product configuration.
Examples of Technical-Product Associated Information are:
- Test and Quality Assurance Information
- Test Reports
- System Evaluation Report
- Configuration Control Information
- Requirements for Changes
- Requirements for Variance
- CCB Decisions
- Product Configuration Management Status
- Other Associated Information
- GIDEP Notices of Obsolete Parts
- Supplier Notices of Obsolete Parts
- Disposal Information
- Related Contract ID Information

4.2.3.1.8. Interface Management

The interface management process ensures interface definition and compliance among the elements that compose the system, as well as with other systems with which the system or system elements will interoperate (i.e., system-of-systems (SoS)). Interface management control measures ensure that all internal and external interface requirement changes are properly documented in accordance with the configuration management plan and communicated to all affected configuration items.

Interface management deals with:

Defining and establishing interface specifications,
Assessing compliance of interfaces among configuration items comprising systems or system of systems,
Monitoring the viability and integrity of interfaces within a system, and
Establishing an interface management plan to assess existing and emerging interface standards and profiles, update interfaces, and abandon obsolete architectures.
An interface management plan is a part of a configuration management plan that:
Documents a system's internal and external interfaces and their requirement specifications,
Identifies preferred and discretionary interface standards and their profiles,
Provides justification for selection and procedure for upgrading interface standards, and
Describes the certifications and tests applicable to each interface or standard.

The Interface Control Working Group (ICWG) is a specialized technical working group composed of appropriate technical representatives from the interfacing activities and other interested participating organizations. The ICWG serves as a forum to develop and provide interface requirements, as well as to focus on interface detail definition and timely resolution of issues The ICWG requires collaboration with external program offices and contractors in a system or system of systems environment.

Many of the external interfaces are identified through the Joint Capabilities Integration and Development System process and its accompanying documents and architectures. As system interface control requirements are developed, they are documented and made available to the appropriate stakeholders. Documented interface control requirements serve critical functions at all levels of the system. These interface control requirements are documented in an Interface Control Document and placed under configuration control. Some of these functions include:

Facilitating competitive bids,
Enabling integration of systems and sub-systems,
Developing functional and physical architectures,
Supporting system maintenance, future enhancement, and upgrades, and
Providing input data for continuous risk management efforts.

Refinement of the interfaces is achieved through iteration. As more is learned about the system during the design phases, lower-level, verifiable requirements and interfaces are defined and refined. Impacts of the original defined capabilities and interfaces, performance parameter thresholds and objectives, and the system are evaluated when defining and modifying interfaces.

Interface management is a critical technical management process in a SoS. For individual systems, flexibility and stability of interfaces are mostly under individual program control. The dynamic nature and multi-constituent system construct of SoS makes successful interface management challenging and crucial. In a SoS, control of interface management will most likely be at the SoS level, while execution will likely be at the constituent system level.

Top of page

Previous and Next Page arrows