1.2.2 Describe the need to convert functional and behavioral expectations to technical requirements Technical Requirements 1.2.2.1 Evaluate technical requirements for affordability, achievability and traceability to stakeholder’s requirements, expectations, and perceived constraints. 1.2.2.2 Validate and base line the technical requirements. 1.2.2.3 Define the technical problem scope and the related design and product constraints. Undertand and reference the Concept of Operations (CONOPS). Ensure connectios are made to user requirements (e.g. JCIDS) and mission operation summary/mission profile. 1.2.3 Ensure the design incorporates reliability, availability and maintainability requirements across a system's life cycle Reliabiltity Growth Curves RAM-C Report 1.2.3.1 Develop and document reliability growth expecations. 1.2.3.2 Assess reliabiltiy growth progress versus the RAM-C expectations. that program planning (and resourcing) is reflective of RAM approach. RAM across the program to support cost and supportability projections for lifetime support. References: DoDI 5000.02, Enclosure 3 DoD RAM-C Report Manual June 2009 1.2.4 Ensure the open systems architecture design is compatible with user performance, interoperability, and product support requirements and desired capabilities. Open Systems Architecture Certification SEP LSCP 1.2.4.1 Define system design to achieve interoperability with existing and planned DoD/Service/Agency systems. 1.2.4.2 Incorporate a in order to optimize the design for effective and efficient product support. 1. Survey existing and planned modular and open systems and lessons learned. 2. Determine from systems candidates for the system. 3. Consider the life-cycle support costs and benefits of incorporating the existing systems. 4. Coordinate design decisions with stakeholders. 5. Document decisions in the LCSP in coordination with the SEP.
References: DoDI 5000.02, Enclosure 3 "DoD Open System Architecture Contract Guidebook for Program Managers," December 15, 2011 1.2.5 Ensure the information technology design requirement considers Interoperability as well as trusted systems and networks IT Interoperability Plan 1.2.5.1 Evaluate (and document) the degree to which information technology (IT) design requirements consider both Interoperability and trusted systems/networks. working group of key IT and NSS stakeholders. interoperability requirements. requirements for trusted systems and networks. (with stakeholders) development of the IT interoperability plan. References: DoDI 5000.02, Enclosure 11 DoDD 4630.05, "Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS)," May 5, 2004 DoD Instruction 4630.8, ''Procedures for Interoperability and Supportability of Information Technology (IT) and National Security Systems (NSS)," June 30,2004 DoD Instruction 8320.02, "Sharing Data, Information, and Information Technology (IT) Services in the Department of Defense," August 5, 2013 DoD Instruction 8410.03, "Network Management (NM)," August 29,2012
COI, KSA) into system development terms is typically accomplished via TPMs 1.3.5 Ensure technical measures are continually assessed (tracked, trended and forecasted) to support program decisions Technical performance measures (TPMs) and technical measures 1.3.5.1 Identify and implement hardware and software metrics appropriate for each level of a program 1.3.5.2 Identify and implement technical support measures to be incorporated as part of the QASP 1.3.5.3 Identify and track technical measures associated with the handling of risks and opportunities Steps: Establish technical performance measures (TPM) and/or functionality points/indicators as appropriate to ensure insight into KPP, KSA or other desired performance. Align TPMs and/or functionality with associated design/functional requirements and WBS elementsEstablish key indicators of technical process maturity/execution. Integrate TPM and technical process indicators into risk handling plans. TPM, risk handling tasks/options and technical process indicators into IMS tasks and associated closure criteria. Guidance: “Level of a program” refers to how the system is decomposed or manged at the component up to the system level. “TPMs” refer to technical measures directly linked to attaining the program KPPs and KSAs, e.g. system weight, speed, S/W reliability, etc. Technical measures are linked to the technical tracking of the program, e.g., status of process performance, status of requirementss, status of interfaces, status of technical documentation, etc.
requirements and product configuration information Deviation, and/or Request for Waiver 1.5.2.2 Support or a Configuration Control board (CCB). 2. Assess the cost and schedule implications and ensure incorporation into performance measurement and forecasting. 3. Ensure relevant DIDs and CDRL items are reviewed, tailored as appropriate and incorporated into the contract. References: MIL-HDBK-61A, APPENDIX D, ECP Management Guide 1.6 Technical Data Management 1.6.1 the principles, procedures, and tools of data management and associated data rights Data Management Strategy (as integrated in the Acquisition Strategy) 1.6.1.1 Develop and implement a data management strategy for the long-term needs for product data necessary to develop, acquire, manufacture, operate, support, maintain and dispose of their acquisition program. Steps: Assess and determine the data required to design, manufacture, and sustain the system. Assess and determine the data required to support re-competition for production, sustainment or upgrade. References: DoD 5010.12M, Procedures for the Acquisition and Management of Technical Data 1.6.2 Oversee and appraise a Program’s Technical Data Management Plan Technical Data Management Plan 1.6.2.1 Determine the appropriate data rights required (quality and quality) to ensure the Government can use the data across the program life cycle to the appropriate legal extent. 1.6.2.2 Envoke and document a disciplined process to plan, acquire, access, manage, protect, and use data of a technical nature to support the life cycle of the system Steps: Assess the risks to the program of not acquiring the desired product data and/or data rights due to cost or other considerations. Determine the contractual actions needed to acquire the data and data rights from contractors. Determine, plan and budget for the Information Technology (IT) repositories/environment, access controls,
Preliminary Design Review (PDR), Critical Design Review (CDR), Physical Configuration (PCA, and Post Implementation Review (PIR) Identify appropriate artifacts associated with each design review Assess, based on unique program conditions, the desired content and maturity of each document at each review. IIntegrate desired artifact characteristics with and exit review criteria for each review. Using the IMS, adjust or ensure timing of artifact deliveries allows adequate time for Government review and contracgtor response IIntegrate desired characteristics and timing of artifacts directly into SOW and CDRL requirements. References: DAG chapter 4 DoDI 5000.02, enclosure 11, para 4 Documented CCB decisions Current and complete interface control documents (ICDs)and specifications 1.7.1.4 Conduct, or substantively participate in an Interface Control Working (ICWG) to execute the Interface Management Control Process Flow. Steps: 1. Establish systems and subsystem interface requirements. 2. stakeholders with each interface or set of interfaces. 3. Establish ICWG membership based on identified stakeholders. 4. Evolve/Modify ICWG membership as program matures/changes and additional interfaces are revealed or refined. References: Configuration Management-Reference MIL-HDBK-61A
DATA ITEM DESCRIPTION (DID) Title: Systems Engineering Management Plan (SEMP) Number: DI-SESS-81785 OSD’s SEP Preparation Open Systems Architecture Guidebook for Program Managers, DAG section 4.3.5. Requirements Management Process TM 2 Defense Business Systems: Ability to evaluate the complexity of a software effort; synthesize the development, integration, and test management activities; and apply appropriate measurement techniques to support embedded system software, computer systems, or IT related programs 2.1 DBS Certification 2.1.1 Interpret and comply with Defense Business Systems certification/ accreditation guidance DBSMC certification approval 2.1.1.1 Develop and implement plans within appropriate technical planning documents to ensure DBSMC certification approval. Steps: DBSMC certification approval is received prior to any obligation of funds for acquisition. programs are re-certified at least annually. Guidance: Defense Business Systems Management Committee (DBSMC), chaired by the Deputy Secretary of Defense, is the approval authority for all statutorily required DBS certifications and will document such decisions. The Milestone Decision Authority (MDA) [when at the OSD or Military Department level] will serve as a member of the DBSMC. References: DoD I 5000.02, November 25, 2013 Enclosure 12 Office of the DoD Deputy Chief Management Officer, "Defense Business
3.1.7. Recognize the role of data alignment in supporting specific test objectives required to successfully conduct an overall evaluation Test Report 3.1.7.1 Assess the degree to a test & evaluation program ensures alignment of test data with test objectives. 3.1.7.2 Evaluate the use and application of collected test data in light of impact to operational requirements. Steps: 1. Identify the test and evaluation framework required to shape desired data collection. 2. Determine the cost, schedule and performance ramifications relative to accomplishments, gaps and/or new testing relative to the existing framework. 3.2 Test Execution 3.2.1 (DT): Oversee a comprehensive T&E program to validate system specifications and requirements including use of Modeling & Simulation. TEMP Test and evaluation reports 3.2.1.1 Apply outputs of the T&E program (including M&S) to assess whether evolving design meets system design-to or build-to specifications and user requriements. 3.2.1.2 actual schedule and test resources being used to execute the T&E program to enable early identification of any projected shortfalls or schedule impacts. Elevate to program government body as potential need for management reserve. 3.2.1.3 Maintain insight into contractor T&E activities to track progress in accomplishing test objectives and meeting subsystem or system performance requirements. 3.2.1.4 Evaluate the T&E efforts of other participating government activities to ensure efficient and timely execution as well as seamless integration with other test efforts. 3.2.1.5 Ensure test infrastructure and to be used in operational tests undergo verification, validation, and accreditation (VV&A) by the intended user or appropriate agency. Steps: the execution of T&E to elevate any key performance issues early for consideration of design trade-offs. the ITT consists of empowered representatives of test data producers and consumers (to include all applicable stakeholders) to execute and/or the test strategy to efficiently throughout the acquisition life cycle. all test infrastructure and/or tools (e.g., models, simulations, automated tools, synthetic environments) to support acquisition decisions are verified, validated, and accredited (VV&A) by the intended user or appropriate agency. workaround options from TPWG to mitigate cost/schedule impacts of any VV&A issues. appropriate integration of operational test considerations in development tests.
3.2.2 (OT): Manage Department/Agency process to ensure the system does not IOT&E before it is sufficiently mature to successfully pass suitability and effectiveness measures. System maturity metrics for IOT&E entrance criteria 3.2.2.1 Ensure the Operational Test Readiness Review system maturity metrics support the decision to proceed into IOT&E. 3.2.2.2 Assess system requirements against latest threat information. 3.2.2.3 Ensure user involvement in early system assessments/tests. Steps: Establish critical technical parameters and track progress throughout DT&E. Coordinate with the operational test director to articulate the of planned operational testing, the critical operational issues, and the measures of effectiveness and suitability. TM 4 Manufacturing Management: Ability to manage and apply the principles of manufacturing management in order to influence the design process, transition to production, and execution of the manufacturing plan. Able to analyze program office and contractor status/plans for transition to production. 4.1 Manufacturing Planning and Transition 4.1.1 Oversee management actions leading to an adequate and efficient manufacturing capability and production (if applicable) of the minimum quantity necessary to provide production or production-representative articles for IOT&E. System Engineering Plan (SEP), Statement of Work (SOW) and associated CDRLs CDR conduct and Post-CDR Assessment 4.1.1.1 Formulate SEP and contract requirements that drive manufacturing considerations into the system design and engineering process. 4.1.1.2 Ensure PQM considerations are addressed in technical and design reviews. 4.1.1.3 Evaluate whether results of producability assessments warrant changes to system level requirements to drive more efficient manufacturing capability and production. 4.1.1.4 Ensure the manufacturing strategy/plan aligns to the authorized budget, resources and schedule for the program. 4.1.1.5 With customer and industry partner(s), evaluate trade space between design choices, producability, and cost/schedule. Steps: 1. Ensure the SEP addresses how manufacturing trades should be factored into the design process. 2. Ensure SOW addresses Manufacturing Readiness Levels and process proofing as part of considerations for entrance/exit criteria for PDR, CDR, and Production Readiness Review(s). 3. Assess manufacturing readiness early in the program lifecycle, as early as the AoA and Milestone A. Reference: Defense Manufacturing Management Guide (available on the DAU ACC.
4.1.2 Establish an initial production base (along with initial spares production) for the system expandable to an effective full rate production Low-rate initial production decision Production Readiness Review Report Milestone C Briefing 4.1.2.1 Discern LRIP readiness based on demonstrated manufacturing capability and program maturity. 4.1.2.2 Incorporate production requirements into the contract (statement of work, CDRL, and associated request for proposals, etc). 4.1.2.3 Ensure the overall production support/facilities resources will be available and capable to execute the manufactuing program. Steps: Establish conditions that will determine “stability” of the design. Once the design is determined to be stabile, update program cost estimate on, at a minimum, revised production process yields and labor costs. 4.1.3 Establish and optimize a full rate production base for the system, based on LRIP and successful operational testing PCA PRR report full-rate production decision 4.1.3.1 Discern FRP readiness based on demonstrated manufacturing capability and program maturity. Steps: Update program cost estimate. Consider post production shut down (and re-start) issues. 4.1.4 Understand material management functions, manufacturing facilities design and associated issues/implications of new product and process technologies Manufacturing program review assessment/ report 4.1.4.1 Conduct, or substantially participate in, periodic/ongoing reviews of manufacturing performance. 4.1.4.2 Apply, in coordination with DCMA quality control, quality assurance, and validation and verification techniques associated with PQM environment in order to ensure quality products. 4.1.4.3 Evaluate supply chain management roles and responsibilities (including DMSMS) in the design and execution of a production line. Steps: Perform the manufacturing readiness assessment at all milestones. Resource planning and scheduling for the manufacturing readiness assessment as required. Tooling and special test equipment are planned for and resourced. References: SD20-22 DMSMS Guidebook and the Defense Manufacturing Management Guide (available on the DAU ACC)
storage of associated manufacturing items and artifacts. In conjunction with the PCO, develop an approach to relevant contracts. 4.2.2 Execute a system production line shutdown and transition to post production supply chain support. System Verification Review approval Production shutdown decision 4.2.2.1 Analyze and plan for post-production support activities and address during the System Verification Review. 4.2.2.2 Ensure special tooling and production facilities are properly placed in long term storage or disposed. 4.2.2.3 Ensure all production line documentation is properly archieved. 4.2.2.4 Ensure post product supply processes are established to address failure defect investigation support. 1. Assess the extent of post-production support required based on individual program and item. 2. Allocate failure / defect investigation support as required from design agent production engineering resources. 3. Plan and budget for the personnel resources in the event resources are needed for both of these items. Reference: DoD SVR checklist available on the DAU ACC site TM 5 Product Support Management: Ability to manage and apply the principles of DoD life cycle logistics management in order to influence the design process and the development and execution of the product support plan. This includes an understanding and implementation of appropriate actions on supply chain management, environmental matters 5.1 Product Support Planning 5.1.1 Oversee management actions leading to an adequate and efficient hardware and software product support capability. Requirements Analysis Integrated Logistics Assessment Supportability analysis Product support strategy LCSP 5.1.1.1 Ensure all user requirements documents are reviewed and program planning documents are appropriately aligned to provide an affordable life cycle solution. 5.1.1.2 Analyze overall life cyle risks and opportunities related to cost, schedule and product support impacts. 5.1.1.3 Evaluate legacy system support requirements and corresponding documentation. Steps: 1. Assess KPPs and KSAs for life-cycle support implications. 2. Identify program and system design to comply with functional, quality, and constraint requirements. 3. Identify life-cycle support features from the legacy system which we want to sustain in the new system (minimize redundancies). 4. Identify life-cycle support features in the legacy system that we do not want to continue in the new system. 5. Review legacy system life-cycle support lessons learned documentation.