NAVSEAINST NAVAIRINST JUL JAN 2010

Transcription

1 MARCORSYSCOM Order NAVSUPINST DEPARTMENT OF THE NAVY NAVAL AIR SYSTEMS COMMAND, PATUXENT RIVER, MD SPAWARINST NAVFACINST NAVAL SEA SYSTEMS COMMAND, WASHINGTON NAVY YARD, DC NAVAL SUPPLY SYSTEMS COMMAND, MECHANICSBURG, PA NAVAL FACILITIES ENGINEERING COMMEAND, WASHINGTON NAVY YARD, DC SPACE AND NAVAL WARFARE SYSTEMS COMMAND, SAN DIEGO, CA NAVSEAINST NAVAIRINST MARINE CORPS SYSTEMS COMMAND, QUANTICO, VA MARCORSYSCOM Order SPAWARINST NAVFACINST MCSC 06 SPW 05A FAC CI 11 MAY FEB APR 2009 SUP 31 Ser TAB/12 AIR JAN 2009 From: Commander, Naval Air Systems Command Commander, Naval Sea Systems Command Commander, Naval Supply Systems Command Commander, Naval Facilities Engineering Command Commander, Space and Naval Warfare Systems Command Commander, Marine Corps Systems Command Subj: NAVAL SYSCOM SYSTEMS ENGINEERING POLICY Ref: (a) ASN RD&A Memo, Systems Engineering Technical Review Process for Naval Acquisition Programs of 13 June 08 (b) SECNAVINST C, Department of the Navy (DON) Research and Development, Acquisition, Associated Life Cycle Management, and Logistics Responsibilities and Accountability of 13 Sep 07 (c) VS-JI-22A, Virtual SYSCOM Engineering and Technical Authority Policy of 31 Jan 07 (d) MARCORSYSCOM Order , Technical Authority of 13 Aug 08 (e) DoDD , The Defense Acquisition System of 12 May 03 (f) DoDI , Operation of the Defense Acquisition System of 2 Dec 08 (g) Interim Defense Acquisition Guidebook of 15 Jun 09 (h) SECNAVINST D, Implementation and Operation of the Defense Acquisition System and the Joint Capabilities Integration and Development System of 16 Oct 08 (i) DON Joint letter, Implementation of System Design Specification (SDS) Guidebook and associated system specific appendices of 18 Jul 08 (j) DON System Design Specification (SDS) Guidebook of 17 Jul 08

2 (k) CJCSI G, Joint Capabilities Integration and Development System of 1 Mar 09 (l) CJCSI , Joint Requirements Oversight Council (JROC) Programmatic Process for Joint Experimentation and Joint Resource Change Recommendations of 31 Oct 02 (m) DoD Systems Engineering Plan (SEP) Preparation Guide, Version 2.01 of Apr 08 (n) ASN RDA Memo, Amplification of Policy for DON Systems Engineering Plan Review and Approval of 16 Nov 2007 (o) Naval SYSCOM Risk Management Policy Instruction of 21 Jul 08 (p) OPNAVINST G, Facilities Project Instruction of 14 Oct 05 (q) Navy Marine Corps Acquisition Regulation Supplement, Subpart , DON authorities and responsibilities of Apr 08 (r) Naval Systems Engineering Guide of October 2004 (s) Naval Systems Engineering Stakeholders Group Charter Encl: (1) Naval SYSCOM Systems Engineering Policy Figures (2) Naval Systems Engineering Technical Review Handbook, Version Purpose a. To establish systems engineering policy for all Naval Systems Commands (SYSCOMs) and affiliated Program Executive Officers (PEOs) and Direct Reporting Program Managers (DRPMs), consistent with references (a) through (o), Department of Defense (DOD), Department of Navy (DON) and Naval SYSCOM policy. b. To establish a common Systems Engineering Technical Review (SETR) process within the DON, as directed by reference (a) and promulgated as the enclosure (2) handbook. 2. Scope and Applicability. This instruction applies to systems engineering performed by all Naval SYSCOMs, affiliated Program PEOs and DRPMs, consistent with the scope of references (b), (c) and (d). This instruction does not apply to the exclusions listed in reference (c), or to construction and facilities engineering 2

3 programs which are addressed under reference (p) as authorized by reference (q). Application of this instruction shall be consistent with reference (e), Defense Acquisition System Policies, including Flexibility, Responsiveness, Innovation, Discipline, and Streamlined and Effective Management. This instruction does not change the responsibilities of SYSCOMs, PEOs, DRPMs, Program Managers (PMs), Participating Managers or other Program Support Managers as delineated in the applicable policy and guidance in references (e), (f) and (h). 3. Background a. Roles and Responsibilities. In accordance with reference (b), PMs are vested with the authority, accountability, and resources necessary to manage all aspects of assigned programs from concept through disposal. The SYSCOMs are responsible for overseeing the core processes required to support the acquisition, in-service support, sustainment, modernization and disposal of weapon and Information Technology (IT) systems, including acquisition and in-service systems engineering. The SYSCOMs serve as the technical authority, and operational safety and assurance certification authorities. The SYSCOM Technical Authorities include the SYSCOM Commanders and Chief Engineers (CHENGs), Deputy Warrant Officers (DWOs), Technical Warrant Holders (TWHs), and others as defined in references (c) and (d). References (c) and (d) describe how programmatic and technical authorities collaborate to produce certified products that meet user needs. b. Systems Engineering Definition. References (e), (f) and (g) provide policy and guidance on systems engineering within the DoD. Reference (h) amplifies DoD systems engineering policy for DON. In summary: (1) Systems engineering focuses on defining user needs and required functionality early in the development cycle, documenting requirements, and proceeding with design synthesis and system validation to achieve the total capability. Solutions include hardware, software, human operators, maintainers, support personnel, facilities, infrastructures and procedures. (2) The exercise of systems engineering includes standards, processes, tools, methods, and data for requirements 3

4 management, technical specifications, platform and systems design, architectures, standardization, system safety, human systems integration, information protection, reliability, availability, maintainability, interoperability, integration, risk management, and test and evaluation. (3) System of Systems (SoS) and Family of Systems (FoS) are described in references (g) and (h) which provide that all programs responding to a capabilities or requirements document, regardless of acquisition category, shall apply a robust systems engineering approach that balances total system performance and total ownership costs within a SoS, FoS context. In other words, SoS and FoS should be treated and managed as systems in their own right, and are therefore subject to the same systems engineering processes and best practices as applied to individual systems. Reference (h) elaborates on the technical authority of Assistant Secretary of the Navy for Research Development and Acquisition (ASN RD&A) Chief Systems Engineer (CHSENG) related to SoS and FoS integration and interoperability. c. Total Life Cycle Cost. References (e) through (h) require PMs to apply a robust systems engineering approach that balances total systems performance and total ownership costs, both within and across program lines. Systems engineering is employed to balance the program objectives of optimal total system performance that meets user requirements and minimizes total ownership cost. d. Acquisition Life Cycle. As described in references (e) through (h), the acquisition life cycle has five major phases: Materiel Solution Analysis (MSA); Technology Development; Engineering & Manufacturing Development; Production and Deployment; and Operations and Support; with milestone decisions between some of the phases. A well-developed Acquisition Strategy minimizes the time and cost required to satisfy approved capability needs, and maximizes affordability throughout the program life cycle. In reference (h), the Secretary of the Navy (SECNAV) tailored the acquisition timeline by establishing a twopass/six-gate review process. References (i) and (j) expand on implementation of the System Design Specification (SDS) linked to the two-pass/six-gate review process. The purpose is to improve the governance of the entire requirements and acquisition process for major programs and systems, from requirements definition 4

5 through system acquisition and into system sustainment. This will ensure that PMs and systems engineers better understand the impact of proposed requirements on total life cycle costs, and provides opportunity to assess those impacts before locking in decisions. Enclosure (1), figures (1a) and (1b), depict the DON acquisition life cycle. e. Joint Capabilities Integration and Development System. The first step in the acquisition life cycle is setting the user requirements for the system using the Joint Capabilities Integration and Development System (JCIDS) process, and defined in references (k) and (l) and referred to in the reference (h) twopass/six-gate process. The JCIDS process sets the foundation for systems engineering by identifying capability gaps, operational risks, and potential materiel and non-materiel solutions. These potential solutions must be explored further by using a robust analytical process that objectively considers a range of operating, maintenance, sustainment, and acquisition approaches. There are three primary parts to the JCIDS process: (1) The JCIDS process addresses the establishment of requirements in the Initial Capabilities Document (ICD), and potential solutions in the Analysis of Alternatives. The ICD validates that there is a need to address capabilities gaps, and that there are potentially affordable and technically feasible solutions to the gaps. The ICD is the basis to analyze and identify the most appropriate system to provide the desired capability. (2) A Capabilities Development Document (CDD) is then developed to describe that approach. The primary objective of the CDD is to specify the system technical performance criteria of the system that will deliver the needed capability identified in the ICD. Approval of the CDD is a key factor in the final decision by the Milestone Decision Authority (MDA) to initiate a development program. (3) Upon completion of the system development, the process evolves to a Capability Production Document (CPD). The primary objective of the CPD is to describe the actual performance of the system that will go into production. The primary difference 5

6 between a CPD and a CDD is that the CPD incorporates lessons learned during the development process. f. Systems Engineering Plans (SEPs). Once the initial requirements for the system are established through the JCIDS process, the next step is defining the SEP that will be used by the PM and systems engineers throughout the life of the program. In references (f), (g) and (m), the DoD requires that PMs and systems engineers document their systems engineering process in a SEP. The SEP shall guide all technical aspects of an acquisition program and describe the overall technical approach, systems engineering processes, resources, key technical tasks, activities and events along with their metrics and success criteria. The initial SEP is developed during the MSA Phase and is updated at each milestone for approval by the MDA. It is intended to be a living document, tailored to the program, and a roadmap that supports program management by defining a comprehensive set of systems engineering activities. It addresses how systems engineering will support the translation of systems capability needs into an effective, suitable product that is sustainable at an affordable cost. In reference (n), the ASN RD&A elaborates on the DoD policy, stressing the collaboration of programmatic authorities and systems engineering technical authorities. g. System Design Specification (SDS). References (i) and (j) require development of the SDS. The SDS determines the family of system specifications including tailorable and non- design standards, and derives system requirements to a tailorable specifications, interface requirements, and detailed preliminary design level of detail as defined in tailored, system specific appendices. The purpose is threefold. First, the SDS allocates the system or platform-specific Mission Performance requirements and attributes from higher level capability documents, describes the results of top-level system trades, and provides input into the acquisition program baseline. Second, the SDS identifies Navy and Industry Design Criteria and Standards that are used during system development. Third, the SDS details the expected producibility, operability and maintainability of the system. The SDS provides decision makers greater insight into design maturity, capabilities, schedule, cost impact of alternatives and risks early in the acquisition process. This reduces execution risk associated with the technology development and acquisition of the system by 6

7 defining what we will actually acquire, and providing a solid basis for a revised cost estimate. h. Systems Engineering Technical Review (SETR). Consistent with references (a) through (o), SETRs are required throughout the acquisition life cycle. The SETRs implement a technical assessment process that evaluates the maturing design over the life of the program. The SETRs provide a framework for structured systems engineering management, including assessment of predicted system performance. The SETRs also provide the PM with a better understanding of program technical health. The SETRs are tailored according to the SEP approved by the MDA or the reference (f) or (r) delegated authority. The SETRs are event-driven, have specific entry and closure criteria, and are used to evaluate technical baselines. The SETRs are chaired by technical authorities independent of the program, with participation by the PM and support from the associated Integrated Product Team (IPT) (government/contractor). Involvement of stakeholders, peers, technical authorities, subject matter experts, and senior leaders in SETRs is defined in the SEP. Stakeholders include users; testers; Environmental, Safety and Occupational Health (ESOH) representatives; certifiers; and design and sustainment engineers. Reference (a) tasked the Naval SYSCOMs to work with their affiliated PEOs and the ASN RD&A CHSENG to develop a common SETR process for use across all DON SYSCOMs and acquisition programs. 4. Policy a. Systems Engineering Roles. Consistent with references (a) through (o), programmatic authorities are responsible for establishing, using, maintaining, and funding an integrated systems engineering process. Technical, programmatic and certification authority for systems engineering shall be in accordance with reference (c) or (d). As required by reference (b), technical and certification authorities are independent of programmatic authorities to ensure appropriate checks and balances. Technical, certification and programmatic authorities shall collaborate in executing the systems engineering process throughout the life cycle to ensure products certified to meet requirements are delivered to the Navy and Marine Corps users in an affordable manner. Risk management shall be applied throughout the systems engineering process in accordance with reference (o), so that the acquisition community and end users fully understand 7

8 and accept the risks associated with delivered products. All risk categories shall be considered, including programmatic (e.g., projected sustainment cost risks, schedule impacts from repairs, and performance expectations over the life cycle, system safety, and ESOH) risks. b. Systems Engineering in the JCIDS Process. The SYSCOM technical authorities shall work with the PM and the user to establish and refine operational needs, attributes, performance parameters, capability gaps, operational risks, and constraints that flow from JCIDS-described capabilities, and ensure that all relevant requirements are addressed, consistent with references (e) through (j). c. Systems Engineering Plans. The SEPs shall be developed in accordance with references (f), (m) and (r) to ensure a complete description of how the PM and SYSCOMs will perform systems engineering throughout the life cycle. Deviations from the policy contained in Joint SYSCOM instructions that the PM needs to properly tailor and execute the program shall be clearly identified for approval by the MDA in the SEP at each milestone. The SEP updates between milestones should be approved by the SYSCOM CHENG and the PEO, as allowed by reference (m) guidance. (1) Integrated Product Teams. SEPs shall describe the organization of the Program IPT, including all appropriate technical, certification and programmatic authority functions. The SYSCOM CHENG shall designate, in writing, a technical authority (e.g., a TWH) to assist the PM in leading all technical aspects of the Program IPT. The SYSCOM CHENG may delegate the authority to designate this individual to one or more direct reports in the technical authority chain of command (e.g., DWOs), but no further. The designated technical authority shall work with the PM and the IPT to develop and submit the SEP. In the case of sea and air platforms, the designated technical authority will normally be the assigned Platform Design Manager, as described in reference (c). (2) SETR Schedule. The SEP shall detail the specific SETR hierarchy and sequencing for the program. This is especially important for evolutionary acquisition strategies, 8

9 using incremental development processes, or multi-component programs. (3) SEP Approval. The SEP approval at each milestone shall be in accordance with enclosure (1), figures (2a), (2b) and (2c). Additional signatures may be added to the signature page based on agreement of the SYSCOM CHENG and the PEO. For example, a Program Technical Director submittal block could be added above the PM s, or a DWO s concurrence block could be added above the SYSCOM CHENG s. Note that DoD and ASN RD&A have delegated their MDA and component approval authority for SEPs in references (f) and (n), as depicted in enclosure (1), figures (2a), (2b), (2c) and (3). d. System Design Specification. A key building block of a comprehensive and useful SDS is traceability of the technical requirements developed from the operational capabilities outlined in the Capability Development Document and Concept of Operations, in accordance with reference (j). Requirements allocation and traceability result from a disciplined systems engineering process that not only decomposes the operational capabilities, but ensures that operational capabilities and risks are accounted for with a corresponding set of technical requirements. The use of Dynamic Object Oriented Requirements System, or other suitable tool, allows the PM to demonstrate the completeness and traceability of the flow down of requirements. The SDS shall be developed in accordance with reference (j) and approved in accordance with enclosure (1), figure (3). e. Systems Engineering Technical Reviews. All programs shall conduct SETRs in accordance with references (a) through (o) and the enclosure (2) interim handbook. SETRs should be tailored, dependent upon the scope and complexity of the program. Enclosure (1), figures (4a) and (4b) depict a typical SETR timeline for more complex programs, related to the acquisition timeline. For Navy-led Joint and National Major Defense Acquisition Programs, this instruction and enclosure (2) apply. For Joint Acquisition Programs led by other services, their equivalent process should be used; Naval SYSCOM and PEO systems engineers shall ensure they are active participants in that process. 9

10 (1) Technical Review Board Chair. The SETR events are jointly conducted by the Program and the Technical Review Board (TRB). The SYSCOM CHENG assigns, in writing, a Government employee to chair the TRB for each SETR event defined in the program SEP. The TRB Chair shall be independent from the program and is normally a senior individual from the Naval SYSCOM technical authority chain with technical expertise relevant to the program. When approved by the SYSCOM CHENG, a principal member of the TRB from the program or the Fleet may be assigned. The final authority for closing the technical review is the TRB Chair. (2) Agenda. The TRB Chair determines the membership of the TRB, ensuring appropriate representation of stakeholders, peers, technical authorities, subject matter experts and senior leadership, as described in the SEP, and then issues the agenda. The agenda shall include the TRB membership, SETR participants, Program IPT support required, event-driven schedules, and entry and closure criteria, consistent with the SEP. (3) Planning. The SETRs shall be event-driven and conducted when the system design satisfies the entry criteria. Each SETR event must have defined entry criteria, areas of interest, and closure criteria tied to the required level of design maturity and applied across all requirements and technical disciplines. Note that the SETR timeline is contained in the approved SEP. (4) Conduct. As a system or platform develops, it passes through a series of SETRs to assess the increasing maturity of the design. The SETRs are structured to provide oversight of the technical baseline, and confidence that it is maturing adequately. These reviews confirm that acceptable results are evolving from a continuous systems engineering process. New issues should not arise at SETRs; if significant unanticipated issues do emerge, the review is being held prematurely, with an inherent increase in risk. (5) Document Review. The SETR process depends on objective documentation, analyses, process plans, and the specific SETR entry and closure criteria. These documents are part of the engineering process and are prepared to document the 10

11 progress of a configuration-managed design and document design decisions. Each SETR event is a process unto itself and begins with delivery or presentation of documentation and analyses for the TRB to review. The correctness and completeness of this information should be measured against clearly stated objective standards. The PM shall ensure the Statement of Work, System Specification, and Contract Data Requirements Lists contain the required plans, specifications, and analyses to support the SETR proce ss. The method and timing of delivery should provide for sufficient Government review and adjudication of comments. (6) Results. The TRB Chair shall capture the action items and monitor closure of the SETR event. Any action item that is satisfied prior to the conclusion of the review shall be dispositioned as closed, with the appropriate supporting information. SETR closeout is defined as a SETR report signed by the TRB Chair to the PM, PEO, SYSCOM CHENG, SYSCOM Commander, and, for all cases where the MDA is not within the SYSCOM or PEO, to the RD&A CHSENG. The report shall address the following, described in more detail in enclosure (2): (a) How the closure criteria have been met; (b) Approval of the Requests for Action (RFAs) generated during the SETR; (c) Approval of the technical baseline evaluation; (d) Confidence that the technical baseline is mature enough for the next stage of development; and (e) The assessment of risk in progressing toward an opera tionally effective and suitable system, with input from the operational test activities involved, as appropriate. (7) SETR Alignment to Gate Reviews. Gate Reviews have been established by reference (h) to review acquisition program maturity at specified times during the acquisition life cycle. Gate Reviews serve a distinct purpose in relation to acquisition program maturity and do not replace the requirement to conduct SETRs. The results of SETRs will provide evidence as input to the conduct of reviews at each Gate. As the Gate Review process 11

12 matures and the necessary alignment with the SETR events is determined, this policy will be updated to reflect the new guidance. f. Conflict Resolution. Whenever programmatic and/or technical authorities disagree on a technical issue, the conflict resolution policy of reference (c) or (d) applies. 5. Action. Naval SYSCOMs and affiliated Programmatic Authorities shall: a. Implement the policies and guidance contained in this Instruction, as well as the interim guidance contained in enclosure (2): b. Update enclosure (2) within ten months of the date of this Instruction to provide more detailed appendices for ships; aircraft (including targets and UAS); weapons systems; land systems; space, enterprise information system; and Command Control, Communications, Computers and Intelligence systems, and to ensure alignment with the latest references, such as references (f) and (h). c. Update the reference (r), Naval Systems Engineering Guide (NSEG), to be consistent with current policy and guidance by 30 June 2010, and to incorporate reference (j), attachment (1), and other relevant topics, such as the human systems integration and systems safety areas of interest. Approval authority for reference (r) shall be the Naval SYSCOM CHENGs. Prior to signature, the Naval Systems Engineering Stakeholders Group (SESG), chartered by reference (s), shall coordinate the NSEG with the RD&A CHSENG and the SYSCOM Technical Authority Boards as defined in references (c) and (d), which include the DWOs, PEOs, Warfare Center Commanders, and user representatives. d. Ensure all DOD, DON and SYSCOM Systems Engineering policy and guidance documents are accessible to all Naval programs and systems engineers on the Naval Systems Engineering Resource Center (NSERC) web site, 12

13 6. Review. The Naval SESG shall review this instruction annually, coordinating and implementing updates and changes as appropriate. BGEN, USMC RADM, USN RADM, CEC, USN Commander, Commander, Space Commander, Marine Corps and Naval Warfare Naval Facilities Systems Command Systems Command Engineering Command Commander, Naval Air Systems Command Distribution: SNDL FKP COMNAVSEASYSCOM Shore Activities C84 COMNAVSEASYSCOM Shore Based Detachments NAVSEA Special List Y1 A1J1F PEO SHIP 13

14 A1J1L PEO IWS A1JIM PEO LMW AIJIN PEO SUB AIJ1Q PEO CARRIERS 21A1 CFFC 21A2 COMPACFLT 24A Air Force Commanders 24D Surface Force Commanders 24G Submarine Force Commanders 26U Regional Maintenance Centers FT88 EDOSCOL DRPM ERP FKA1C COMNAVFACENGCOM ASN (I&E) CNIC CMC (I&L) AIR 1.0, 4.0, 5.0 and 6.0 PEO (T) PEO (A) PEO (W) NAWC AD, WD FKQ SPAWAR Activities SPAWAR 00, 01, 02, 04, 05, WLA NETWARCOM SPAWAR ITC (00) PEO C4I AND SPACE PEO IT PEO SPACE SYSTEMS DRPM NMCI NAVSUP MARCORSYSCOM CoS, SIAT & AC PROG MCCDC NAVSAFCEN, Naval Safety Center RD&A CHSENG SP 10, 201 NAVAIR Directives web site: or NAVSUP (Electronic only via the Naval Logistics Library (NLL) web site: 14

15 NAVAL SYSCOM SYSTEMS ENGINEERING POLICY FIGURES Figure 1a. DoD acquisition life cycle, with SECNAV 2-pass/6-gate Review, for Milestone A programs 1 Enclosure (1)

16 Figure 1b. DoD acquisition life cycle with SECNAV 2-pass/6- gate review for Milestone B programs. 2

17 PROGRAM NAME - ACAT LEVEL SYSTEMS ENGINEERING PLAN VERSION SUPPORTING MILESTONE MONTH DAY, YEAR *************************************************************************** SUBMITTED BY Designated Technical Authority Program Manager CONCURRENCE SYSCOM Chief Engineer Program Executive Officer or Equivalent COMPONENT APPROVAL MDA APPROVAL ASN (RD&A) Chief Systems Engineer Deputy Under Secretary of Defense (A&T) *************************************************************************** Figure 2a. Systems Engineering Plan (SEP) Signature Page for ACAT 1D and 1AM Programs 3

18 SYSTEMS ENGINEERING PLAN VERSION SUPPORTING MILESTONE MONTH DAY, YEAR *************************************************************************** SUBMITTED BY Designated Technical Authority Program Manager CONCURRENCE SYSCOM Chief Engineer Program Executive Officer or Equivalent APPROVAL ASN (RD&A) Chief Systems Engineer *************************************************************************** Figure 2b. Systems Engineering Plan (SEP) Signature Page for ACAT 1C, 1AC, II & Special Interest Programs 4

19 PROGRAM NAME - ACAT LEVEL SYSTEMS ENGINEERING PLAN VERSION SUPPORTING MILESTONE MONTH DAY, YEAR *************************************************************************** SUBMITTED BY Designated Technical Authority Program Manager CONCURRENCE SYSCOM Chief Engineer APPROVAL MDA *************************************************************************** Figure 2c. Systems Engineering Plan (SEP) Signature Page for ACAT III and IV Programs 5

20 PROGRAM NAME ACAT LEVEL SYSTEMS DESIGN SPECIFICATION (SDS) VERSION SUPPORTING GATE NUMBER MONTH DAY, YEAR *************************************************************** SUBMITTED BY DATE DATE DATE Designated Program Manager OPNAV N6x / N8x or Technical Authority SYSCOM Code PROGRAM NAME Equivalent CONCURRENCE DATE DATE DATE SYSCOM Chief Engineer PEO or Equivalent OPNAV N6 / N8 or Equivalent *************************************************************** Figure 3. System Design Specification (SDS) Signature Page 6

21 Figure 4a. DoD acquisition life cycle, with SECNAV 2-pass/6- gate review, and an example of System Engineering Technical Review milestones for a major program for Milestone A programs. 7

22 Figure 4b. DoD acquisition life cycle, with SECNAV 2-pass/6- gate review, and an example of System Engineering Technical Review milestones for a major program for Milestone B programs. 8