Transcription
CH 3–1. PurposeThe Defense Acquisition Guidebook (DAG), Chapter 3 provides overarching guidance on the systemsengineering discipline, its activities and processes and its practice in defense acquisition programs. TheProgram Manager (PM) and the Systems Engineer should use this chapter to effectively plan andexecute program activities across the system life cycle.CH 3–2. BackgroundSystems engineering (SE) establishes the technical framework for delivering materiel capabilities to thewarfighter. SE provides the foundation upon which everything else is built and supports program success.SE ensures the effective development and delivery of capability through the implementation of a balancedapproach with respect to cost, schedule, performance and risk, using integrated, disciplined andconsistent SE activities and processes regardless of when a program enters the acquisition life cycle. SEalso enables the development of resilient systems that are trusted, assured and easily modified. Thevalue of systems engineering is supported by the GAO Report 17-77, which indicates that, "Systemsengineering is the primary means for determining whether and how the challenge posed by a program’srequirements can be met with available resources. It is a disciplined learning process that translatescapability requirements into specific design features and thus identifies key risks to be resolved. Our priorbest practices work has indicated that if detailed systems engineering is done before the start of productdevelopment, the program can resolve these risks through trade-offs and additional investments,ensuring that risks have been sufficiently retired or that they are clearly understood and adequatelyresourced if they are being carried forward.”SE planning, as documented in the Systems Engineering Plan (SEP), identifies the most effective andefficient path to deliver a capability, from identifying user needs and concepts through delivery andsustainment. SE event-driven technical reviews and audits assess program maturity and determine thestatus of the technical risks associated with cost, schedule and performance goals."Positive acquisition outcomes require the use of a knowledge-based approach to product developmentthat demonstrates high levels of knowledge before significant commitments are made. In essence,knowledge supplants risk over time." (Source: GAO Report 12-400SP)Additional SE benefits are that it: Supports development of realistic and achievable program performance, schedule and cost goalsas documented in the Joint Capabilities Integration and Development System (JCIDS)documents, Acquisition Program Baseline (APB) and Acquisition Strategy (AS).Provides the end-to-end, integrated perspective of the technical activities and processes acrossthe system life cycle, including how the system fits into a larger system of systems (SoS)construct.Emphasizes the use of integrated, consistent and repeatable processes to reduce risk whilematuring and managing the technical baseline. The final product baseline forms the basis forproduction, sustainment, future changes and upgrades.Provides insight into system life-cycle resource requirements and impacts on human health andthe environment.This chapter uses the following terms: The "Systems Engineer" refers to the Program Lead Systems Engineer, the Chief Engineer orLead Engineer with SE responsibility and the SE staff responsible for SE processes and whoplan, conduct and/or manage SE activities in the program.The "end user” includes the warfighter and other operational users, including support personnel,maintainers and trainers who use or support the systemThe "developer" refers to the system prime contractor (including associated subcontractors) orthe Government agency responsible for designing and building the system.Definition of Systems Engineering
Systems engineering (SE) is a methodical and disciplined approach for the specification, design,development, realization, technical management, operations and retirement of a system. As illustrated inFigure 1, a system is an aggregation of system elements and enabling system elements to achieve agiven purpose or provide a needed capability. The enabling system elements provide the means fordelivering a capability into service, keeping it in service or ending its service, and may include thoseprocesses or products necessary for developing, producing, testing, deploying and sustaining the system.Figure 1: The SystemSE applies critical thinking to the acquisition of a capability. It is a holistic, integrative discipline, wherebythe contributions across engineering disciplines, such as structural engineers, electrical engineers,mechanical designers, software engineers, human factors engineers and reliability engineers, areevaluated and balanced to produce a coherent capability -- the system.The Systems Engineer balances the conflicting design constraints of cost, schedule, and performancewhile maintaining an acceptable level of risk. SE solves systems acquisition problems using a multidisciplined approach. The Systems Engineer should possess the skills, instincts and critical thinkingability to identify and focus efforts on the activities needed to enhance the overall system effectiveness,suitability, survivability and sustainability.SE activities begin before a program is officially established and are applied throughout the acquisition lifecycle. Any effective SE approach should support and be integrated with sound program management.Prior to program initiation, the Program Manager (PM), or Service lead if no PM has been assigned,should perform development planning to lay the technical foundation for successful acquisition.Development planning encompasses the engineering analyses and technical planning activities thatprovide the foundation for informed investment decisions on which path a materiel development decisiontakes. Development planning effectively addresses the capability gap(s), desired operational attributesand associated dependencies of the desired capability. In addition, development planning ensures thatthere exists a range of technically feasible solutions generated from across the entire solution space andthat consideration has been given to near-term opportunities to provide a more rapid interim response tothe capability need. Development planning is initiated prior to the Materiel Development Decision review,
continues throughout the Materiel Solution Analysis phase, and transitions the knowledge (documents,tools and related data) to the designated program.AffordabilityThe Systems Engineer contributes to defining, establishing and achieving affordability goals and capsthroughout the life cycle of the system. Affordability goals are set early in the program to inform capabilityrequirements and major design trade-offs to define the product being acquired. Likewise, affordabilitycaps are fixed cost requirements set prior to Milestone B that are equivalent to Key PerformanceParameters (KPP). Affordability goals and caps are based on future estimates of what the Departmentcan afford to spend for the capability, including program procurement and sustainment costs. Affordabilitygoals and caps are used as design constraints in the development, procurement and sustainment of anaffordable system. See CH 3–4.3.2. Affordability - Systems Engineering Trade-Off Analyses, for moreinformation on how affordability drives design decisions.The PM controls requirements growth and should use affordability goals early to guide design trades andprogram decisions. The Systems Engineer assists in managing affordability by working closely with theprogram cost estimator/analyst team when developing common cost and technical models and aligningbaselines. See CH 1–4.2.1.1. for more information on affordability.Throughout the acquisition life cycle, the PM and Systems Engineer should monitor the systemaffordability, seek out cost saving opportunities and identify any associated cost, schedule andperformance risks. The PM’s emphasis prior to Milestone B should be on defining and achievingaffordability goals and caps and desired capabilities. During the Technology Maturation and RiskReduction (TMRR) phase, the PM and Systems Engineer work to reduce technical risk and develop asufficient understanding of the materiel solution development to validate design approaches and costestimates, to refine requirements, and to ensure affordability is designed in to the desired capability. AfterMilestone B, the affordability emphasis shifts to defining and achieving should-cost estimates.Should-cost management is a deliberate strategy to drive cost efficiencies and productivity growth intoprograms. The will-cost estimate is the likely life-cycle cost of the system based on historical data andrepresents the program’s independent cost estimate, e.g., as generated by the Cost Assessment andProgram Evaluation (CAPE) office or Service equivalent. As the program identifies inefficiencies, theshould-cost estimate is developed based on specific actions and opportunities to mitigate, eliminate orreduce those inefficiencies that allow the program to come in below the expected will-cost estimates. ThePM, with support from the Systems Engineer, develops program office cost estimates reflecting shouldcost opportunities and plans. The PM and Systems Engineer use the should-cost estimate as a tool to: Influence design trades and choices when analyzing and setting contract/production executiontargetsManage all costs throughout the product’s life cycleManage the product’s final unit and sustainment costProvide incentives for both of the parties (Government and industry) to execute efficiently:Government managers, who seek more value for the warfighter and taxpayer; and industrymanagers, who develop, build and sustain the systems and provide needed servicesShould-cost management focuses on controlling the cost of both current and planned work. To have animpact, these activities should inform contract negotiations leading up to Engineering and ManufacturingDevelopment (EMD) and Production and Deployment (P&D) phases. Should-cost management does notmean trading away the long-term value of sound design practices and disciplined SE activities for shortterm gain; it does mean eliminating low-value-added activities and reports that are not required and thatare deemed unessential. The Under Secretary of Defense for Acquisition, Technology, and Logistics(USD(AT&L)) Memorandum, “Should Cost Management in Defense Acquisition” describes that shouldcost management is a core initiative of Better Buying Power and is an important tool to control costs inthe short term and throughout the product life cycle. For guidance on implementing should-costmanagement, see the Better Buying Power website.
PMs address affordability requirements and begin to apply should-cost management early in theacquisition life cycle. This includes applying SE to define an affordable system design while also workingto eliminate inefficiencies and duplication where applicable and to drive productivity improvements intotheir programs. Throughout the life cycle, PMs and Systems Engineers should consider ValueEngineering as a key tool for meeting or beating affordability constraints and should-cost targets (See CH3–2.4.4. Value Engineering).Systems Engineering ProcessesThe practice of SE is composed of 16 processes: eight technical processes and eight technicalmanagement processes as listed in Figure 2 and described in CH 3–4. Additional PlanningConsiderations. These 16 processes provide a structured approach to increasing the technical maturity ofa system and increasing the likelihood that the capability being developed balances mission performancewith cost, schedule, risk, and design constraints.The eight technical management processes are implemented across the acquisition life cycle and provideinsight and control to assist the PM and Systems Engineer to meet performance, schedule and costgoals. The eight technical processes closely align with the acquisition life-cycle phases and include thetop-down design processes and bottom-up realization processes that support transformation ofoperational needs into operational capabilities.The purpose of the SE processes is to provide a framework that allows the program to structure andconduct its technical efforts to efficiently and effectively deliver a capability to satisfy a validatedoperational need. To fulfill that purpose, a program implements the SE technical processes in anintegrated and overlapping manner to support the iterative maturation of the system solution.Implementation of the SE processes begins with the identification of a validated operational need asshown in the top left corner of the V-diagram (see Figure 2). The technical processes enable the SE teamto ensure that the delivered capability accurately reflects the operational needs of the stakeholders. Thekey activities accomplished by the execution of the technical processes are described below: During the Stakeholder Requirements Definition process, the operational requirements and inputsfrom relevant stakeholders are translated into a set of top-level technical requirements. Theserequirements are decomposed and elaborated during the Requirements Analysis process toproduce a complete set of system functional and performance requirements.During the Architecture Design process, the Systems Engineer, often through system modeling,trade-offs, and decision analyses, captures the functional requirements and interdependencies inthe system architecture. Trade-offs and analyses are also used to mature and realize the designof the system and system elements during the Implementation process, generating the productbaseline.During the Integration process, the program assembles the system elements together to providethe system for testing in the Verification process (developmental tests verifying the functionalrequirements)
Should-cost management is a deliberate strategy to drive cost efficiencies and productivity growth into programs. The will-cost estimate is the likely life-cycle cost of the system based on historical data and represents the program’s independent cost estimate, e.g., as generated by the Cost Assessment and
