Seminar: Systems Engineering

1. Seminar: Systems Engineering Program Management Office Course PMT 352B Version 1.3, 12-11-09

2. Technical ManagementProcesses Decision Analysis Technical Planning Technical Assessment Requirements Management Risk Management Configuration Management Technical Data Management Interface Management Technical Processes Stakeholder Requirements Definition Requirements Analysis Architecture Design Implementation Integration Verification Validation Transition Standardized Terminology Defense Acquisition Guidebook (DAG) para 4.2.3 “The many systems and software engineering process models and standards 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.”

3. 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.” DAG, paragraph 4.2.3.1

4. Decision Analysis • Ensures proper technical decision making for balancing • Cost effectiveness • Performance • Schedule • Supportability • Robustness • Comprises • Trade studies • Supportability analysis • Cost analysis • Defines and prioritizes decision criteria with respect to programmatic, technical, and total life cycle concerns

5. Technical Planning • Ensures proper application of the SE process throughout the system’s life cycle • Addresses • Technical effort required • Technical maturation of the system throughout the program • Each of the technical processes are subject to technical planning • May influence the (derived) technical requirements • The Systems Engineering Plan is a mandated tool for this activity

6. Technical Assessment • Measures technical progress and maturation • Technical Performance Measurement - Forecasts values of essential performance parameters - Measures values achieved by current design - Determines impact of difference (forecast vs. current) on system effectiveness • Plans and conducts technical reviews • Demonstrates and confirms technical maturity and relevant exit criteria

7. Technical Review: Preliminary Design Review (PDR) • Now required by the DoDI 5000.02 process • System–level Preliminary Design Review (PDR) - For Non-Major programs (ACATs II-IV): can be done during TD phase (if part of the Technology Development Strategy (TDS), or post MS B, early in EMD phase, (if part of the Acquisition Strategy) - For Major Defense Acquisition Programs (MDAPs - ACAT I programs): PDR, PDR Report, and Post-PDR Assessment required to be done prior to Milestone B • Assesses the preliminary design as captured in performance specs for each configuration item (CI); determines whether the system is ready to proceed to detailed design; confirms the “allocated” baseline • Formal PDR Report required from PM – assessed as part of Milestone B review, or after MS B at Post PDR Assessment, as appropriate

8. Technical Review: Critical Design Review (CDR) • Now required by the DoDI 5000.02 process • System–level Critical Design Review (CDR) - accomplished during Engineering and Manufacturing Development (EMD) phase • Assesses system final design as captured in performance specs for each CI; determines whether the system is ready to proceed to fabrication; confirms the “product” baseline • Formal CDR Report required from PM – assessed at post CDR-Assessment – success allows entry into System Capability and Manufacturing Process Demonstration effort of EMD phase

9. Requirements Management • Provides adequate practices and repository to capture, present, and manage requirements, their attributions and relationships • Maintain bi-directional traceability from capability needs identified by JCIDS down to lowest level derived technical requirements • Also establish traceability to verification and validation • Document changes to requirements • Capture rationale for changes

10. Risk Management • Addresses potential risks for deviation from the program objectives over the whole life cycle • Integrates performance risk with life cycle and programmatic risk • Risk is addressed from day one and throughout the program • Risk identification • Risk analysis • Risk mitigation planning • Risk mitigation plan implementation • Risk tracking • Some risk aspects • Technology and design • Manufacturing capabilities • Industry sources and contracts • Technical support process • Information sensitivity and security issues

11. Configuration Management (CM) Requirements • Establish and maintain consistency between • Requirements • Actual “As built” attributes • Configuration information • Includes • CM Planning and management • Configuration identification • Configuration change control • Configuration status accounting • Configuration verification and audit Actual system “as-built” attributes System configuration information

12. Data Management • Efficient data management is an essential enabler for good SE • Provides technical and programmatic insight and supports management activities as well as decision making • Attributes of data management • Proper acquisition and structuring of data from various sources • Enable sharing and integration of data between government and industry • Access and efficient retrieval of the “right” data • Elements of data management • Data acquisition and retrieval (access vs. acquisition of all data) • Data protection (security as well as contingency) • Data storage and retrieval (digitization of continued need information vs. long term archiving)

13. Interface Management • Establishes practices and procedures to ensure proper interface definitions, documentation and compliance throughout the system life cycle • Develops interface control requirements governing the development effort • Enables integration of system and subsystems • Facilitates contractor/supplier bidding • Supports maintenance and future enhancements/upgrades Interfaces are among the most common sources of failure in complex systems

14. Technical Processes “The Program Manager uses technical processes to design the system, subsystems, and components, including the supporting or enabling systems required to produce, support, operate, or dispose of a system.” DAG, paragraph 4.2.3.2

15. Stakeholder Requirements Definition • Elicit stakeholder inputs −JCIDS documents identify capability gaps and express Concept of Operations (CONOPS) • Engage with user community to understand and refine the operational needs, attributes, performance parameters and constraints that flow from JCIDS • Translate input into technical program and system requirements addressing: • Performance parameters, objectives and thresholds • Affordability constraints • Scheduling constraints • Technical Constraints • An iterative application of rigorous systems engineering is key since the majority of requirements will be defined through system decomposition at later stages in the program • Stakeholder Requirements Definition complements Requirements Analysis and Architectural Design technical processes

16. Requirements Analysis • Encompasses the definition and refinement of system, subsystem, and lower level functional and performance requirements and interfaces to facilitate the Architecture Design process • Functional Architecture – Essential aspect of the Requirements Analysis process; provides definition of the system functional baseline – Expresses the detailed functional, interface, and temporal aspects of the system to unambiguously communicate system behavior in its intended environment −Outcome of a functional architecture is the development of lower tier functional and performance requirements that need to be allocated to the system physical architecture

17. Architecture Design • Trade and synthesis process that translates the outputs of the Stakeholder Requirements Definition and Requirements Analysis processes into alternative design solutions and selects a final design solution • Physical architecture – model of the physical (design) solution; physical architecture is complete when the system has been decomposed to lowest system element or configuration item level • Output of System Architecture Design : Physical design resulting from a trade off between alternatives • Framework for design definition documentation (specifications and allocated and product baselines) • Confirmation of interoperability and open system performance requirements • Up and downward traceability of requirements across functional, allocated, and product baselines

18. Implementation • Prepares the lowest level elements in the physical system hierarchy for integration, verification and validation for • Manufacturing/coding, or • Procurement, or • Reuse • Above decisions are integral in a Modular Open Systems Approach (MOSA), especially for IT systems, and may impose • Constraints on the design solution process • Development of a manufacturing/supply chain system • Implementation may also involve • Development of supporting documentation (e.g. manuals) • Packaging, handling, and storage

19. Integration • Process of incorporating lower level system elements into higher level system elements in the physical architecture • Also the final incorporation of the system into its operational environment • The integration strategy and planning may impose constraints on the design solution as well as implementation processes • The integration process may require the development of enabling systems such as test-beds, fixtures, simulation environments

20. Verification • Generates evidence of compliance with “build to” specifications • “Did you build the system right?” • Done accordingly at all levels of implementation and integration, to include interfaces • Verification methods • Analysis • Examination • Demonstration • Testing

21. Validation • Validates the system in its operational environment • Was the operational capability gap correctly identified? • Does the system fill the gap in a life cycle context • Start validation in the early stages of system life cycle to reduce risk • Prototypes • Mock-ups • Modeling/simulation of system characteristics • Modeling/simulation of operational environment “Did you build the right thing?” Get the requirements right!

22. Transition • Moves a system element from one level in the physical hierarchy to the next • Might include • Proper configuration • Supporting documentation • Technical reviews or peer reviews