Docstoc

Engineering and Manufacturing Development Phase Procedure

Document Sample
Engineering and Manufacturing Development Phase Procedure Powered By Docstoc
					SDPR002         Engineering and Manufacturing Development Phase             30 October 2012
                                  Procedure

Engineering and Manufacturing Development Phase Procedure
Phases: Framework Dependent:
   5000.02 Framework:
       Phase: Engineering and Manufacturing Development
   Non-5000.02 Framework:
       Phase: None

Description:
The intent of this procedure is to guide the Program Manager and the team through the
second phase of the Systems Engineering Process (SEP). The basis for the SEP is the
Integrated Defense Acquisition, Technology, and Logistics Life Cycle Management
Framework and includes the Systems Engineering disciplines necessary for Information
Technology acquisition and development. Not every step in this procedure is required for
every program or project. The associated Tailoring Worksheet for Engineering and
Manufacturing Development Phase, Production & Deployment Phase, and Operations &
Support Phase and the SEP Tailoring Guide allow the program or project team to tailor
products and activities to support the unique needs of the program or project.
Program or project team members should review this entire procedure for process
understanding before beginning any of the steps listed below.
Continuous Activities: There are activities that must be kept up-to-date throughout the
life cycle of the project. Rather than being redundant throughout the procedure, these
activities are addressed here and will not be referred to again. It is the responsibility of
the Project Manager to ensure these are done at the appropriate times.
     Peer Reviews. Team members must review and produce minutes for every product
      delivered to the customer. Refer to Peer Review Procedure, Peer Review Minutes,
      and Peer Review Self-Administered Test Checklist.
     Risk Management. Risk Management addresses issues that could endanger
      achievement of critical project objectives. Risk Management identifies potential
      problems before they occur thus enabling the planning for and invoking of risk-
      handling activities throughout the life of the project. Document identified risks in
      an approved risk management tool. Refer to Risk Management Procedure.
     Configuration Management. Configuration Management establishes and
      maintains the integrity of work products using configuration identification,
      configuration control, configuration status accounting, and configuration audits. It
      applies direction and surveillance to:
           o Identify and document functional and physical characteristics
           o Record and report change processing and implementation status
           o Verify compliance with requirements
      Refer to the Configuration Management Systems Engineering Discipline for a
      complete list of CM procedures.
     Requirements Management. The intent of Requirements Management is to
      manage the requirements of the project’s products and product components and to



                                        Page 1 of 18
SDPR002          Engineering and Manufacturing Development Phase          30 October 2012
                                   Procedure
       identify inconsistencies between those requirements and the project’s plans and
       work products. Requirements Management includes documenting changes and
       their rationale as well as maintaining traceability between high-level requirements
       and low-level requirements and between requirements and related products. Refer
       to Requirements Management Procedure and Requirements Management
       Checklist.
      Project Monitoring and Control. The purpose of Project Monitoring and Control
       is to provide an understanding of the project's progress so that appropriate
       corrective actions can be taken when the project's performance deviates
       significantly from the plan. Refer to the Project Monitoring and Control process
       area of the Systems Engineering Disciplines for a list of procedures addressing the
       activities listed here. Part of this activity includes such things as:
             o Continuously maintaining information in the Enterprise Information
                 Technology Data Repository (EITDR)
            o Continuously maintaining information in the System Metrics and
              Reporting Tool (SMART) database
            o Continuously maintaining information in the ENWeb database
            o Monitoring action items
            o Conducting effective and various reviews
            o Managing unresolved issues, etc.
Entry Criteria:
Complete the following before beginning this procedure:
      Acquisition Decision Memorandum signed by the Milestone Decision
       Authority granting approval to proceed to the Engineering and
       Manufacturing Development phase
      If the Milestone Decision Authority authorizes entry into the life cycle during
       this phase, all required activities and work products from the Technology
       Development phase that will have impact in the Engineering and
       Manufacturing Development phase must be addressed.
INTEGRATED SYSTEM DESIGN MAJOR EFFORT:
The goal of Integrated System Design is to define system and system-of-systems
functionality and interfaces, complete detailed design, and reduce system-level risk. The
program shall enter Integrated System Design when the PM has a technical solution for
the system, but has not yet integrated the subsystems into a complete system. This major
effort shall typically include the demonstration of prototype articles or engineering
development models (EDMs).
Procedure Steps: (These steps are not necessarily sequential.)
1. MAJOR EFFORT INITIATION AND PROJECT MANAGEMENT
 ACTIVITIES.
      1.1. Finalize SEP Tailoring Worksheet for Engineering and Manufacturing
      Development.


                                       Page 2 of 18
SDPR002       Engineering and Manufacturing Development Phase            30 October 2012
                                Procedure
  Finalize the SEP TWS for Engineering and Manufacturing Development Phase
  (EMD) drafted during Technology Development Phase. Develop the TWS on the
  assumption that there is an established project. If there is not an established project,
  refer to Establish a Program Procedure. Products and activities may be tailored to fit
  the requirements of the specific project. However, some products and activities are
  not tailorable. The following link will bring up the tailoring worksheet for this phase:
  Tailoring Worksheet for Engineering and Manufacturing Development, Production &
  Deployment Phase, and Operations & Support Phase. For help, refer to the SEP
  Tailoring Guide.
  1.2. Confirm Job Order Number.
  Contact the Financial Management and Comptroller Function to confirm
  establishment of an appropriate Job Order Number (JON). Refer to Project Tracking
  and Oversight Guide.
  1.3. Confirm Project Code.
  Confirm that a Project Code has been established after a JON has been assigned.
  Refer to Project Tracking and Oversight Guide.
  1.4. Load Engineering and Manufacturing Development Phase Schedule.
  Notify the Metrics and Scheduling Function with the approved project code. Choose
  the products to accomplish during the EMD Phase and load the schedule. Refer to
  Project Tracking and Oversight Guide and Release Schedule Template for
  Engineering and Manufacturing Development Phase.
  1.5. Refine Stakeholder Identification.
     1.5.1. Update Stakeholder Identification and Assessment.
     Update the stakeholder identification and assessment as the project progresses to
     account for new required skills or new stakeholders. Refer to the Stakeholder
     Identification and Assessment Template.
     1.5.2. Conduct Engineering and Manufacturing Development Stakeholder
     Kick-off Meeting.
     Conduct a stakeholder kick-off meeting for the EMD Phase if stakeholders have
     been added since the Technology Development Phase, or if deemed appropriate.
     Refer to Effective Meeting Procedure, Action Item Procedure, and Action Item
     Form.
     1.5.3. Update stakeholder list in EITDR.
     Update stakeholder lists in EITDR as the project progresses and personnel
     transfer to other duties, or the focus of the project changes. Refer to EITDR
     Guide.
     1.5.4. Complete or update the Intergroup Coordination Checklist for
     Engineering and Manufacturing Development.




                                     Page 3 of 18
SDPR002       Engineering and Manufacturing Development Phase            30 October 2012
                                Procedure
     Complete an Intergroup Coordination Checklist or update the existing one.
     Contact each function for support and ensure the checklist correctly addresses the
     support needed for that function. Refer to the Intergroup Coordination Checklist.
     1.5.5. Assign or update SEP roles to Project Team Members.
     Assign or update roles to project team members, ensuring the necessary skills are
     available to complete the project. The Program Manager is responsible for
     assigning project team members, including the Project Manager. Assign and
     revise project members as a project progresses and skill requirements change.
     Refer to SEP Roles and Project Organization Guide.
     1.5.6. Establish and update Individual Development Plans.
     The Program Manager or the Project Manager shall establish and update an
     Individual Development Plan (IDP) for each team member. The IDPs should be
     recorded in a project-specific training plan or an equivalent project training
     organizational repository. Refer to Project-Specific Training Procedure.
     1.5.7. Prepare or update Project-Specific Training Plan.
     Prepare or update a Project-Specific Training Plan, since projects may have
     unique training requirements that are most appropriately satisfied at the individual
     project level. Document the project training plans and execution in a project-
     specific document or an equivalent project training organizational repository. If
     the project has access to a project training organizational repository, the project
     must use the organizational repository. Refer to Project-Specific Training
     Procedure, Project-Specific Training Template, and Generic Peer Review
     Checklist.
  1.6. Complete Global Combat Support System – Air Force (GCSS-AF)
  Integration Framework Registration.
  Register with the GCSS-AF Integration Framework if registration is required and has
  not been established earlier in the life cycle. This web site has instructions for
  registering with the GCSS-AF Integration Framework.
  1.7. Finalize Configuration Management Plan.
  Finalize the Configuration Management Plan (CMP) that should have been started
  earlier in the life cycle. Refer to the Configuration Management Planning Procedure,
  Configuration Management Plan Template, and Configuration Management Plan Peer
  Review Checklist.
  1.8. Review Lessons Learned Database.
  Review the pertinent sections of the Lessons Learned Database. The database is
  available for help in avoiding proven pitfalls and also for helping with ideas that have
  worked well for others. It can be found on the SEP website.
  1.9. Conduct Integrated Baseline Review.
  Conduct an Integrated Baseline Review (IBR) to review the contractor’s
  performance. Prepare minutes for the review. The Program Manager, with assistance



                                     Page 4 of 18
SDPR002       Engineering and Manufacturing Development Phase         30 October 2012
                                Procedure
   from technical staffs or Integrated Product Teams (IPTs), reviews the Contractor’s
   Performance Measurement (CPM) baseline. For those contracts requiring compliance
   with DoD Earned Value Management System (EVMS) criteria or Cost/Schedule
   Status Report (CSS/R) requirements, the IBR must take place within six months after
   contract award. The IBR is part of the Formal Review activities. Refer to the
   Integrated Baseline Review Procedure, Action Item Procedure, and Action Item
   Form.
NOTE: Steps 2 and 4 thru 9 apply only when the Preliminary Design Review (PDR)
occurs after Milestone B. Refer to the SEP Tailoring Guide for details regarding
when the PDR occurs in relation to Milestone B.
2. REQUIREMENTS DOCUMENTATION ACTIVITIES.
   2.1. Draft the General Requirements Specification.
   Draft the General Requirements Specification (GRS) if the choice is to use the GRS
   template rather that the Concept of Operations (ConOps), Software Requirements
   Specification (SRS), and System/Subsystem Specification (SSS). Refer to General
   Requirements Specification Template Guide, General Requirements Specification
   Template, and the Generic Peer Review Checklist.
   2.2. Prepare draft Concept of Operations.
   Prepare draft Concept of Operations (ConOps) only if not using the GRS. Refer to
   Concept of Operations Template and ConOps Peer Review Checklist.
   2.3. Prepare draft Software Requirements Specification.
   Prepare draft Software Requirements Specification (SRS) only if not using the GRS.
   Refer to Software Requirements Specification Template and Software Requirements
   Specification Peer Review Checklist.
   2.4. Prepare draft System Subsystem Specification.
   Prepare draft System Subsystem Specification (SSS) only if not using the GRS.
   Refer to System Subsystem Specification Template and System Subsystem
   Specification Peer Review Checklist.
3. REQUIREMENTS REVIEWS.
   3.1. Conduct System Requirements Review.
   Conduct the System Requirements Review (SRR) to ascertain progress in defining
   system technical requirements. Prepare Minutes for the SRR. Refer to System
   Requirements Review Procedure and System Requirements Review Checklist. Refer
   also to Action Item Procedure and Action Item Form.
   3.2. Conduct System Functional Review.
   Conduct the System Functional Review (SFR) to ensure that the system under review
   can proceed into preliminary design and that all system requirements and functional
   performance requirements are defined and are consistent with cost (program budget),
   schedule (program schedule), risk, and other system constraints. Refer to System



                                     Page 5 of 18
SDPR002        Engineering and Manufacturing Development Phase          30 October 2012
                                 Procedure
   Functional Review Procedure, System Functional Review Checklist, Effective
   Meeting Procedure, Action Item Procedure, and Action Item Form.
4. BASELINING ACTIVITIES.
   4.1. Refine Functional Baseline.
   Refine the Functional Baseline (FBL) to include the GRS, ConOps, SRS, and SSS.
   Refer to Baseline Establishment Procedure and Baseline Management Procedure.
5. PRELIMINARY DESIGN ACTIVITIES.
   5.1. Produce Preliminary System Design.
   Produce a high-level system design by completing activities such as planning for
   Preliminary Design activities, developing appropriate simulations and prototypes,
   developing high-level database design and high-level application design. Refer to
   Preliminary Design and Release Schedule Procedure.
   5.2. Prepare Preliminary Design Document.
   Prepare a Design Document (DD) to document the allocation of requirements, system
   and software designs, and internal and external interfaces. Refer to Design Document
   Template, Design Document Checklist, and Design Document Peer Review
   Checklist.
   5.3. Prepare Preliminary Database Specification.
   Prepare a preliminary Database Specification (DS) to describe the database
   organization, storage allocation, detailed data model of the logical and physical
   design, as well as other necessary information. Refer to Database Development
   Procedure, Database Specification Template, Database Specification Checklist, and
   Database Specification Peer Review Checklist.
6. SYSTEM ENGINEERING ACTIVITIES.
   6.1. Update Systems Engineering Plan.
   Update the Systems Engineering Plan to reflect the results of activities performed
   since the previous update. Refer to Systems Engineering Plan Guide and Generic
   Peer Review Checklist.
   6.2. Prepare Software Development Plan.
   Prepare a Software Development Plan (SDP) for every project that develops or
   configures software. The SDP must address software development activities and be
   tailored for the specific type of system being procured. It outlines the project's
   development process and it must map directly to the approved tailored worksheet.
   Refer to Software Development File Guide, Software Development Plan Template,
   and Software Development Plan Peer Review Checklist.
   6.3. Update Architecture Viewpoints.
   Update architecture viewpoints as appropriate. Consult with the Engineering
   Architectural Function for guidance. Refer to Department of Defense Architecture
   Framework (DoDAF), v2.x.


                                      Page 6 of 18
 SDPR002       Engineering and Manufacturing Development Phase            30 October 2012
                                 Procedure
   6.4. Update Information Support Plan.
   Update the Information Support Plan (ISP) to reflect the results of activities
   performed since the previous update. Refer to the ISP Guide and Generic Peer
   Review Checklist.
7. TEST PLANNING ACTIVITIES.
   7.1. Continue Initial Integrated Test Design (IITD).
   Update the Integrated Test Team (ITT) Charter, Test and Evaluation Master Plan
   (TEMP), and Integrated Test Plan (ITP); and draft the test scenarios, test cases, test
   scripts, and Integrated Test Description (ITD). Refer to the IITD Procedure.
8. FORMAL REVIEW.
   8.1. Conduct Preliminary Design Review.
   Conduct the Preliminary Design Review (PDR) after resolving all major design
   issues. The PDR should address and resolve critical, system-wide issues. The review
   ensures that the system can proceed into detailed design and can meet the stated
   performance requirements within cost, schedule, risk, and other system constraints.
   Refer to Preliminary Design Review Procedure, Review Meeting Guide, Preliminary
   Design Review Checklist, Effective Meetings Procedure, Action Item Procedure, and
   Action Item Form.
   8.2. Conduct Post-Preliminary Design Review Assessment (Post-PDR A).
   Conduct the Post-PDR A to determine whether remedial action is necessary to
   achieve Acquisition Program Baseline (APB) objectives. Refer to Post-Preliminary
   Design Review Assessment (Post-PDR A) Procedure.
9. BASELINING ACTIVITIES.
   9.1. Establish Allocated Baseline.
   Establish the Allocated Baseline (ABL) following a successful Preliminary Design
   Review. Refer to Baseline Establishment Procedure and Baseline Management
   Procedure.
   9.2. Update Expectation Management Agreement.
   Update the Expectation Management Agreement (EMA) if the preliminary design
   dictates an update to the project cost and schedule estimates. Ensure the EMA
   reflects any changes.
10. ESTIMATION ACTIVITIES.
   10.1. Refine cost estimates for project.
   Refine the cost estimate that was defined earlier in the project. Update any potential
   risks and their effect on estimates. Refer to Develop Estimates Procedure.
   10.2. Refine and re-baseline project schedule.




                                       Page 7 of 18
 SDPR002       Engineering and Manufacturing Development Phase           30 October 2012
                                 Procedure
   Refine and re-baseline the project schedule for the EMD phase that was drafted
   during Technology Development Phase. Refer to Project Tracking and Oversight
   Guide and Release Schedule Template for EMD.
11. SISSU AND DIACAP ACTIVITIES.
   11.1. Start the responses to the SISSU questions in EITDR designated as Design
   questions. Refer to EITDR Guide.
   11.2. Initiate DIACAP Phase 2 Activities.
   Initiate DIACAP Phase 2 by contacting the Security Function. The DIACAP is the
   standard DoD process for identifying information security requirements, providing
   security solutions, and managing information system security activities.
   11.3. Draft System Security Authorization Agreement.
   Draft the System Security Authorization Agreement (SSAA). If needed, contact the
   Security Function for assistance.
12. DETAILED DESIGN ACTIVITIES.
   12.1. Produce detailed system design.
   Produce a detailed system design. Consistently perform a well-defined engineering
   process that translates requirements into design activities that produce correct and
   consistent products effectively and efficiently. Design is the process of defining the
   architecture, components, interfaces, and other characteristics of a software system or
   component. Refer to Critical Design and Database Specification Procedure.
   12.2. Prepare Software Development File(s).
   Prepare a Software Development File (SDF), which is a repository for material
   pertinent to the development of a particular body of software. Contents typically
   include (either directly or by reference) considerations, rationale, and constraints
   related to requirement analysis, design, and implementation; developer internal test
   information; and schedule and status information. Refer to Software Development
   File Guide.
   12.3. Prepare final Design Document.
   Prepare the final Design Document (DD) that documents the allocation of
   requirements, system or software designs, and internal or external interfaces. Refer to
   Design Document Template, Design Document Checklist, and Design Document
   Peer Review Checklist.
   12.4. Prepare final Database Specification.
   Prepare the final Database Specification (DS) that describes the database organization
   and storage allocation and provides the detailed data model of the logical and
   physical design, as well as other necessary information. Refer to Database
   Specification Template, Database Specification Checklist, Database Specification
   Peer Review Checklist, Critical Design and Database Specification Procedure, and
   Database Development Procedure.
13. SYSTEM ENGINEERING ACTIVITIES.

                                      Page 8 of 18
 SDPR002        Engineering and Manufacturing Development Phase              30 October 2012
                                  Procedure
   13.1. Prepare draft Implementation Plan.
   Prepare a draft Implementation Plan (IP) to document the implementation and
   transition of the system (to include, but not limited to, delivery, installation, site
   preparation, training, schedule, resources, etc.). Refer to Implementation Plan
   Template and Implementation Plan Peer Review Checklist.
   13.2. Prepare Release Request Letter.
   Prepare a Release Request Letter for each release. Refer to Request Release Letter
   and Instruction Form.
   13.3. Update Life Cycle Sustainment Plan.
   Update the Life Cycle Sustainment Plan (LCSP) that was developed as part of the
   Acquisition Strategy. Refer to Acquisition Strategy Procedure; USD(AT&L)
   Memorandum, Document Streamlining - Life-Cycle Sustainment Plan (LCSP), dated
   14 Sep 11; Peer Review Procedure; and Generic Peer Review Checklist.
   13.4. Prepare and update architecture viewpoints.
   Prepare new or update existing architecture viewpoints as appropriate. Consult with
   the Engineering Architectural Function for guidance. Refer to Department of
   Defense Architecture Framework (DoDAF), v2.x.
   13.5. Update Information Support Plan.
   Update the Information Support Plan (ISP) by referring to Information Support Plan
   Guide.
14. SISSU AND DIACAP ACTIVITIES.
   14.1. Complete the responses to the SISSU questions in EITDR designated as
   Design questions. Refer to EITDR Guide.
   14.2. Review and Validate SISSU Data.
   SISSU reviewers and validators, identified when other stakeholders were identified,
   shall analyze and validate responses to the SISSU questions designated for the Design
   Phase. There are reviewers and validators for each of the SISSU areas (security,
   interoperability, support and sustainment, and usability). Discrepancies identified
   during review and validation must be corrected. Refer to EITDR Guide.
   14.3. Update System Security Authorization Agreement.
   Update the System Security Authorization Agreement (SSAA). If needed, contact the
   Security Function for assistance.
15. REQUIREMENTS DOCUMENTATION.
   15.1. Finalize Interface Requirements Agreement.
   Finalize the IRAs. Refer to Interface Requirements Agreement Template and
   Interface Requirements Agreement Peer Review Checklist.
   15.2. Finalize General Requirements Specification.



                                        Page 9 of 18
 SDPR002       Engineering and Manufacturing Development Phase           30 October 2012
                                 Procedure
   Finalize the GRS unless using the ConOps, SSS, and SRS. Refer to General
   Requirements Specification Template, General Requirements Specification Template
   Guide, and Generic Peer Review Checklist.
   15.3. Finalize Concept of Operations.
   If not using the GRS, finalize the ConOps. Do not rewrite. Refer to Concept of
   Operations Template and ConOps Peer Review Checklist.
   15.4. Finalize System Subsystem Specification.
   If not using the GRS, finalize the SSS. Do not rewrite. Refer to System Subsystem
   Specification Template and System Subsystem Specification Peer Review Checklist.
   15.5. Finalize Software Requirements Specification.
   If not using the GRS, finalize the SRS. Do not rewrite. Refer to Software
   Requirements Specification Template and Software Requirements Specification Peer
   Review Checklist.
   15.6. Finalize Requirements Traceability Matrix.
   Finalize the RTM. Do not rewrite. Refer to Requirements Traceability Matrix
   Template, Requirements Traceability Matrix Guide, and Generic Peer Review
   Checklist.
16. TEST PLANNING ACTIVITIES.
   16.1. Continue IITD.
   Update the ITT Charter, TEMP, ITP, test scenarios, test cases, test scripts, and ITD.
   Refer to the IITD Procedure.
17. ESTIMATION ACTIVITIES.
   17.1. Refine cost estimates for project.
   Refine the cost estimate made earlier in the process. Update any potential risks and
   their effect on estimates. Refer to Develop Estimates Procedure.
   17.2. Refine project schedule.
   Refine the project schedule (built and loaded during the Define Need Phase). Refer
   to Project Tracking and Oversight Guide Schedule Re-baseline or Refinement
   Procedure, and Release Schedule Template for EMD.
18. FORMAL REVIEWS.
   18.1. Conduct Critical Design Review.
   Conduct the Critical Design Review (CDR) to ensure that the system meets the stated
   performance requirements within cost, schedule, risk, and other system constraints.
   Prepare the minutes of the CDR. Refer to Critical Design Review Procedure, Critical
   Design Review Checklist, Review Meetings Guide, Action Item Procedure, and
   Action Item Form.
   18.2. Obtain Engineering Go/No-Go Recommendation.



                                     Page 10 of 18
 SDPR002         Engineering and Manufacturing Development Phase          30 October 2012
                                   Procedure
    Obtain an Engineering Go/NoGo Recommendation (involves evaluating the entry
    criteria for each management review to ensure all work products represent the
    system). The Lead Engineer assigned to the program represents the engineering
    community and reviews the system artifacts. Refer to Engineering Go/NoGo
    Recommendation Procedure, Review Meetings Guide, Action Item Procedure, and
    Action Item Form.
    18.3. Conduct Post-Critical Design Review Assessment (Post-CDR A).
    Conduct the Post-CDR A to determine whether additional action is necessary to
    satisfy Engineering and Manufacturing Development Phase exit criteria and to
    achieve the program outcomes specified in the APB. Refer to Post-Critical Design
    Review Assessment (Post-CDR A) Procedure.
 SYSTEM CAPABILITY AND MANUFACTURING PROCESS
 DEMONSTRATION MAJOR EFFORT:
 This major effort demonstrates the ability of the system to operate in a useful way
 consistent with the approved Key Performance Parameters. The program shall enter
 System Capability and Manufacturing Process Demonstration upon completion of the
 Post-CDR A. This major effort ends when:
          The system is demonstrated in its intended environment using the selected
            production-representative article;
          The system meets approved requirements;
          Industrial capabilities are reasonably available
          The system meets or exceeds exit criteria and Milestone C entrance
            requirements.
 The following are critical:
          Successful development test and evaluation to assess technical progress
            against critical technical parameters,
          Early operational assessments,
          The use of modeling and simulation (where proven capabilities exist) to
            demonstrate system integration
 The completion of this phase depends on the MDA’s decision to commit to the program
 at Milestone C or to end this major effort.
19. INITIATION AND IMPLEMENTATION PLANNING ACTIVITIES.
 Beginning with this section of activities the project moves into the System Capability and
 Manufacturing Process Demonstration portion of the Engineering and Manufacturing
 Development Phase.
    19.1. Review stakeholders.
    As a project progresses, new stakeholders may be needed as personnel transfer to
    other duties and the focus of the project changes. Update the stakeholder list as
    stakeholders are added or deleted. Refer to Stakeholder Identification and
    Assessment Template.
    19.2. Update stakeholder list in EITDR.




                                       Page 11 of 18
 SDPR002        Engineering and Manufacturing Development Phase           30 October 2012
                                  Procedure
    After completing the Stakeholder Identification and Assessment Template and the
    Kick-Off Meeting, update the EITDR database to reflect the project stakeholders.
    Refer to the EITDR Guide. Identification of Security, Interoperability,
    Supportability, Sustainability, and Usability (SISSU) reviewers and validators is
    critical.
    19.3. Finalize Implementation Plan.
    Finalize the draft Implementation Plan (IP) that was prepared during the Design
    Phase. Refer to Implementation Plan Template and Implementation Plan Peer
    Review Checklist.
    19.4. Perform site survey.
    A site survey is not required for sites receiving a release for an existing AIS.
    However, the survey is required for a new site. During the site survey, the site survey
    team will coordinate with the customer to define existing infrastructure, identify
    remaining requirements, and document the findings for further action necessary from
    the customer and the Program Management Office (PMO). Document any revisions
    to the Implementation Plan. Refer to Site Survey Procedure and Site Survey Form.
    19.5. Develop User Manual or On-Line Help.
    Develop the User Manual (UM) to provide information on installing and operating
    the system. This manual is for user-run software that has a user interface requiring
    on-line user input or interpretation of displayed output. A separate UM may be
    necessary for embedded software. Refer to User Manual Template and User Manual
    Peer Review Checklist.
    19.6. Develop Operator Manual.
    Develop the Operator Manual (OM) to provide information on installing and
    operating the system. This manual is for users accessing the system via terminals or
    personal computers or submitting and receiving inputs and outputs in batch or
    interactive mode. It provides computer control personnel and computer operators in
    an information processing center with a detailed operational description of the system
    and its associated environment. Refer to Operator Manual Template and Operator
    Manual Peer Review Checklist.
20. SISSU ACTIVTIES.
 SISSU supplements the Certification and Accreditation Process. It shifts the focus from a
 document-centric certification process, to an information-based process. The SISSU
 questions in EITDR indicate the information needed when developing or sustaining a
 system.
    20.1. Start the responses to the SISSU questions in EITDR designated as Build
    and Test questions. Refer to EITDR Guide.
21. PROJECT ESTIMATION ACTIVITIES.
    21.1. Update Analysis of Alternatives.




                                      Page 12 of 18
SDPR002        Engineering and Manufacturing Development Phase              30 October 2012
                                 Procedure
  Update Analysis of Alternatives (AoA) that was conducted during Materiel Solution
  Analysis. An AoA is required for all information technology (IT) systems at major
  milestone decision points. It is an analytical comparison of the operational
  effectiveness, suitability, and life-cycle cost of alternatives that satisfies established
  capability needs.
  21.2. Update economic analysis.
  If an economic analysis was completed earlier, update it. An economic analysis is
  necessary for MAIS programs only. Economic analysis is required in support of the
  Milestone A, Milestone B, and Full Deployment Decision Reviews. Its purpose is to
  determine the best AIS program acquisition alternative.
  21.3. Prepare Cost Analysis Requirements Documents.
  Prepare a Cost Analysis Requirements Document (CARD) for Acquisition Category I
  and IA programs and any other designated programs. The CARD defines and
  describes the AIS program for purposes of preparing both the Economic Analysis and
  the DoD Component Cost Analysis. For an AIS program, the CARD typically
  addresses the following elements of the program: description, operational concept,
  data management requirements, quantity requirements, manpower requirements,
  fielding strategy, milestone schedule, and acquisition plan or strategy. Refer to the
  Defense Acquisition Guide and Generic Peer Review Checklist.
  21.4. Prepare CARD-like document.
  Prepare a CARD-like document for all acquisition programs that do not require a
  CARD. Refer to Generic Peer Review Checklist.
  21.5. Prepare Program Office Estimate.
  Prepare a Program Office Estimate (POE), a detailed estimate of acquisition and
  ownership costs normally required for high-level decisions. The estimate is
  performed early in the program and serves as the basis for all subsequent tracking and
  auditing purposes. Refer to Generic Peer Review Checklist.
  21.6. Prepare Component Cost Assessment.
  Prepare a Component Cost Assessment (CCA), a cost estimate prepared by an office
  or other entity of a Military Department that is outside the chain of command of that
  Military Department's authority responsible for developing or acquiring the program.
  Refer to Generic Peer Review Checklist.
  21.7. Obtain Independent Cost Estimate.
  Obtain an Independent Cost Estimate (ICE), a Life-Cycle Cost Estimate (LCCE) for
  Acquisition Category (ACAT) I programs, from an office or other entity not under
  the control of:
             The Military Department
             Defense Agency
             Other component of the DoD directly responsible for the development or
              acquisition of the program


                                      Page 13 of 18
 SDPR002       Engineering and Manufacturing Development Phase           30 October 2012
                                 Procedure
   Refer to Generic Peer Review Checklist.
22. COMPLIANCE ACTIVITIES.
   22.1. Complete Title 40/Clinger-Cohen Act (CCA) compliance and Component
   Chief Information Officer (CIO) confirmation.
   Title 40/CCA compliance is required of all information technology (IT) systems.
   Title 40/CCA improves the way the Federal Government acquires and manages IT.
   Title 40/CCA requires DoD to use performance-based management principles for
   acquiring IT, including National Security Systems (NSS). The Component CIO
   confirms Title 40/CCA compliance of all IT systems. Refer to Title 40/Clinger-
   Cohen Act Guide and Title 40/Clinger-Cohen Act Compliance and Confirmation
   Template.
   22.2. Complete Title 40/CCA DoD CIO confirmation.
   For Major Defense Acquisition Programs (MDAPs) and Major Automated
   Information System (MAIS) programs, the DoD CIO (in addition to the Component
   CIO) confirms Title 40/CCA compliance. Refer to Title 40/Clinger-Cohen Act Guide
   and Title 40/Clinger-Cohen Act Compliance and Confirmation Template.
   22.3. Update defense business system certification and approval (if required).
   Defense business system certification and approval assures compliance with the
   Business Enterprise Architecture (BEA). Any information technology (IT) system
   that is designated as a defense business system with a total modernization or
   development funding exceeding $1 million must be certified by the designated
   Investment Review Board (IRB) and approved by the Defense Business Systems
   Management Committee (DBSMC) prior to obligating funds. Per Section 332 of the
   Ronald W. Reagan National Defense Authorization Act for FY05 (FY05 NDAA,
   P.L.108-375), failure to obtain DBSMC approval may result in an Anti-Deficiency
   Act violation. Details of the Air Force’s certification process are found in the AF IT
   Investment Review Guide.
23. COMPONENT BUILD AND CONFIGURATION ACTIVITIES.
   23.1. Build database.
   Build the database by implementing the Database Specification (DS) established
   during the Design Phase. Otherwise, implement the DS. If the system has a database
   or supports persistent data storage, a database structure is required. Refer to the
   Database Development Procedure.
   23.2. Build and configure components.
   Build and configure components by implementing the Design Document (DD)
   established during the Design Phase. Configure, assemble, and code to the detailed
   design and product specifications (prime mission product with database). Build the
   components. When possible, incorporate reusable code assets. Build hardware,
   systems software, and communications infrastructure and verify they meet specified
   requirements. Refer to the Code and Individual Component Validation (ICV)
   Procedure.


                                     Page 14 of 18
 SDPR002       Engineering and Manufacturing Development Phase            30 October 2012
                                 Procedure
   23.3. Conduct code reviews.
   Conduct reviews of only organically developed code. Refer to Peer Review
   Procedure and Code Peer Review Checklist.
   23.4. Update Requirements Traceability Matrix.
   Update, do not rewrite, the Requirements Traceability Matrix (RTM). Refer to
   Requirements Traceability Matrix Template, Requirements Traceability Matrix
   Guide, Peer Review Procedure, and Generic Peer Review Checklist.
24. SYSTEM ENGINEERING ACTIVITIES.
   24.1. Finalize architectural viewpoints.
   Finalize the architecture viewpoints. Consult with the Engineering Architectural
   Function for guidance. Refer to Department of Defense Architecture Framework
   (DoDAF), v2.x.
   24.2. Finalize Information Support Plan.
   Finalize the Information Support Plan (ISP) that was prepared earlier in the life cycle.
   Refer to Information Support Plan Guide, Peer Review Procedure, and Generic Peer
   Review Checklist.
   24.3. Update Program Protection Plan (PPP).
   Update if required the Program Protection Plan (PPP) as appropriate. Refer to
   Principal Deputy Under Secretary of Defense for Acquisition, Technology, and
   Logistics (PDUSD(AT&L)) Memorandum, Document Streamlining - PPP.
25. SISSU AND DIACAP ACTIVITIES.
   25.1. Complete the responses to the SISSU questions in EITDR designated as
   Build and Test Questions. Refer to EITDR Guide.
   25.2. Review and validate SISSU data.
   Review and validate the SISSU data recorded in EITDR for the Engineering and
   Manufacturing Development Phase. The SISSU reviewers and validators (identified
   at the same time as other stakeholders) will review, analyze, and validate the
   responses to the SISSU questions in EITDR. There are reviewers and validators for
   each of these areas: security, interoperability, support and sustainment, and usability.
   The reviewers and validators provide recommendations pertaining to the applicable
   set of SISSU responses for the Engineering and Manufacturing Development Phase.
   Discrepancies identified during review and validation must be corrected.
   25.3. Initiate DIACAP Phase 3 activities.
   Initiate DIACAP Phase 3 by contacting the Security Function. DIACAP is necessary
   for developing the Security System Authorization Agreement (SSAA). The DIACAP
   is the standard DoD process for identifying information security requirements,
   providing security solutions, and managing information system security activities.
   Refer to http://iase.disa.mil/ditscap/interim-ca-guidance.pdf and
   http://www.afei.org/documents/DIACAPandtheGIGCCRTS_371.pdf.



                                      Page 15 of 18
 SDPR002       Engineering and Manufacturing Development Phase            30 October 2012
                                 Procedure
   25.4. Update System Security Authorization Agreement.
   Update the System Security Authorization Agreement (SSAA). If needed, contact the
   Security Function for assistance.
26. TEST PLANNING ACTIVITIES.
   26.1. Continue IITD.
   Finalize the ITT Charter, TEMP, ITP, test scenarios, test cases, test scripts, and ITD.
   Refer to the IITD Procedure.
27. COMPONENT VALIDATION AND INTEGRATION (CV&I) ACTIVITIES.
   27.1. Conduct CV&I.
   Conduct CV&I. Refer to the Component Validation and Integration (CV&I)
   Procedure.
28. BASELINING ACTIVITIES.
   28.1. Establish Product Baseline.
   Establish the Product Baseline (PBL) if the TRR I decision is to continue with testing.
   Refer to Baseline Establishment Procedure and Baseline Management Procedure.
   28.2. Prepare and submit final release package.
   Prepare and submit final release package by assembling items that have been
   prepared throughout the life cycle. Refer to Product Distribution Procedure, Turn In
   and Release Guide, Version Description Document Guide, Version Description
   Document Form, and Release Turn-In Certification Form.
29. FORMAL REVIEW.
   29.1. Conduct Test Readiness Review I (TRR I).
   Conduct TRR I after completion of CV&I. The co-chairpersons determine the
   appropriate type of meeting (i.e., physical or virtual). During the TRR I, if agreement
   is reached to proceed, continue with the testing activities. If the agreement is to
   recycle, recycle the system to the appropriate phase for resolution. If an agreement
   cannot be reached, elevate the situation up the management chain until resolved.
   Refer to Test Readiness Review I (TRR I) Procedure, Test Readiness Review I
   Checklist, and Review Meeting Guide.
30. QUALIFICATION TEST AND EVALUATION (QT&E) ACTIVITIES.
   30.1. Conduct QT&E.
   Conduct QT&E. Refer to the Qualification Test and Evaluation (QT&E) Procedure.
31. SYSTEM ENGINEERING AND PROGRAM MANAGEMENT ACTIVITIES.
   31.1. Perform Functional Configuration Audit.
   Perform a Functional Configuration Audit (FCA) by auditing the Configuration Item
   (CI) performance against its approved configuration documentation to verify the
   customer's functional requirements. Note: Functional Configuration Audit is


                                      Page 16 of 18
 SDPR002       Engineering and Manufacturing Development Phase            30 October 2012
                                 Procedure
   synonymous with System Verification Review (SVR). Refer to Functional
   Configuration Audit Procedure.
   31.2. Prepare Acquisition Program Baseline.
   Prepare the Acquisition Program Baseline (APB) that prescribes the key cost,
   schedule, and performance constraints in the phase succeeding the milestone for
   which they were developed. The Capability Development Document (CDD) and the
   Capability Production Document (CPD) Key Performance Parameters are included
   verbatim in the APB. Refer to Baseline Establishment Procedure and Baseline
   Management Procedure.
32. FORMAL REVIEW.
   32.1. Obtain Engineering Go/NoGo Recommendation.
   The Lead Engineer assigned to the program represents the engineering community
   and will make the recommendation. The recommendation involves evaluating the
   entry criteria for each management review to ensure all work products represent the
   system. Refer to Engineering Go/NoGo Recommendation Procedure, Review
   Meeting Guide, Action Item Procedure, and Action Item Form.
   32.2. Conduct Operational Test Readiness Review (OTRR).
   Conduct the OTRR to determine if the system is ready to proceed. Return the system
   to the appropriate phase for resolution if it is determined that it is not ready. Proceed
   to Operational Test and Evaluation (OT&E) if the system is determined to be ready.
   The chairperson of the OTRR determines the type of meeting (i.e., physical or virtual)
   that is appropriate. The AF Network DAA (AF NETOPS/CC) or delegated
   representative attends the OTRR to approve the system for release on the operational
   network for OT&E. Refer to Operational Test Readiness Review (OTRR) Procedure,
   Review Meeting Guide, Action Item Procedure, and Action Item Form.
   32.3. Obtain Interim Authority to Operate.
   Obtain a temporary approval (Interim Authority to Operate (IATO)) granted by the
   Designated Accrediting Authority (DAA) for a system to operate based on
   preliminary results of a security evaluation. At a minimum, an IATO is required
   before putting the system on the live network for operational testing. The IATO may
   be issued at the OTRR. Refer to Review Meeting Guide, Action Item Procedure, and
   Action Item Form.
   32.4. Conduct Milestone C Review.
   Conduct the Milestone C Review, during which a decision is made as to whether to
   proceed to the Production and Deployment Phase. Refer to the Milestone Review
   Procedure, Review Meeting Guide, Action Item Procedure, and Action Item Form.
   32.5. Prepare Acquisition Decision Memorandum.
   Prepare an Acquisition Decision Memorandum (ADM) to document the Milestone C
   Review and the decisions made. The Milestone Decision Authority signs the ADM.
   Refer to Acquisition Decision Memorandum Template.



                                      Page 17 of 18
 SDPR002          Engineering and Manufacturing Development Phase       30 October 2012
                                    Procedure
33. SUBMIT LESSONS LEARNED.
       33.1. Submit Lessons Learned.
       Electronically submit the Lessons Learned to the SEPG from the SEP website. Refer
       to Lessons Learned Procedure.
 Exit Criteria:
 Prior to exiting the Engineering and Manufacturing Development Phase, and beginning
 the Production and Deployment Phase, the following exit criteria must be met:
             All system work products required during the Engineering and Manufacturing
              Development Phase have been completed with formal peer reviews conducted
             All formal reviews for the Engineering and Manufacturing Development
              Phase have been completed and properly documented:
                     o System Functional Review (SFR)
                     o Preliminary Design Review (PDR)
                     o Critical Design Review (CDR)
                     o Post-Critical Design Review Assessment (Post-CDR A)
                     o Test Readiness Review I (TRR I)
                     o Engineering Go/NoGo Recommendation
                     o Operational Test Readiness Review(OTRR)
                     o Milestone C Review
        The Acquisition Decision Memorandum from the Milestone C Review grants
         authorization to move into the Production and Deployment Phase




                                       Page 18 of 18

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:4/12/2013
language:English
pages:18