Embed Size (px)
Citation preview
SYSTEMS ENGINEERING MANAGEMENT PLAN (SEMP) Type and Working Draft
Updated Oct, 2000 from Oct, 1992 draft and Oct, 1994 “final” 1.0 SCOPE 1.1 Purpose. This System Engineering Management Plan describes an internally developed
approach to a fully integrated engineering effort. It addresses how the typical contract will be managed and conducted to ensure that program cost, schedules and technical performance address the requirements for a SEMP in accordance with MIL-STD-499A. (Note that –499B was never officially issued. Some concepts are from Defense System Management College).
1.2 Application. This SEMP applies to the wide range of engineering efforts currently being
being pursued, especially those that involve the integration of systems. It is applicable to programs that transcend the entire life cycle (Concept Exploration, Demonstration and Validation, Full-Scale Development, Production and Operational Phases) or programs that encompass a single phase. Additionally, the SEMP is applicable to those contract that involve System Engineering and Technical Assistance (SETA) efforts in support of a prime or Government Program Management Office.
1.3 Implementation. The SEMP approach adheres to the management approach directed by
the Office of the Secretary of Defense (OSD) and implemented through Directive 5000.1 and DoD Instruction (DoD) 5000.2 (both dated 23 February 1991, subsequent instructions and updates). DoDI 5000.2 requires an effective systems engineering program be implemented for each acquisition program in accordance with MIL-STD-499. This SEMP addresses Systems Engineering in three parts as defined on paragraph 5.1 and amplified in sections 4, 6 and 10 of MIL-STD-499A. Technical Planning and Control will be addressed in Paragraph 5.1 following as an integrated topic with the Systems Engineering Management Section. System Engineering Process and Specialty Engineering will be discussed as integrated efforts in paragraphs 5.2 and 5.3 respectfully.
This SEMP address the three management functions typical with a matrix-managed
organization. These include the Program Management Function (Overall program authority, responsibility and control) and the two main support functions (1) Engineering and Technical Control (2) Administrative including financial planning. Cost collection and Cost Reporting functions are included in the Administrative responsibilities.
a) Program Management. The designated Program Manager (PM) and his
immediate staff is the central management author for all contractual efforts. Technical Planning Control functions shall reside with the Program Manager and his staff.
b) Engineering Staff. The Director of Engineering shall perform under the direction
of the Program Manager. The Director of Engineering shall establish and maintain a Core Engineering Staff that is dedicated for each program. In addition, the Director of Engineering shall maintain a cadre engineering staff to assist the Core Engineering Staff on an as required basis. Typical the cadre staff would include design engineers, specialty engineers and operational specialists.
1
c) Chief Engineer. The Chief Engineer and his staff will be responsible to the Program Manager for technical program oversight. The Chief Engineer will be responsible for tailoring all engineering processes to accommodate the needs of the program and submit same to each designated PM for approval and implementation. The Chief Engineer is responsible to the PM for defining and conducting the technical review and audit process as defined in the Technical Review and Audit Manual and for implementing and monitoring the Technical Performance Measurement (TPM) program.
2.0 APPLICABLE SUPPORTIVE DOCUMENT AND PROCESS
• Task Authorization Process
• Contract Work Breakdown Structure Guidelines
• Financial Management Planning, Reporting and Monitoring Process Manual
• Technical Performance Measurement (TPM) Process
• Technical Review and Audit Manual
• Total Quality Management (TQM) or Continuous Process Improvement (CPI) Manual
• Risk Management Manual
• Configuration Management Manual
• Data Management Manual
• Software Environment Program (SEP) Process
• Quality Assurance Process Manual
• Software Development Process
• Software Test and Evaluation Process
3.0 DEFINITIONS 3.1 Engineering Management. This office will conduct engineering management paralleling
the requirements invoked by DoDD 5000.1, DoDI 5000.2 and DoD 5000.2M for DoD acquisition. The approach is based on the existence a flowdown of all these requirements from acquisition managers either directly for contract execution or within the scope of a SETA support requirement support to the acquisition manager.
3.2 Technical Program Planning and Control. The management of those design,
development, test and evaluation tasks required to progress from an operational need to
2
deployment and operation of an integrated system (to include contractual efforts specifically directed to a portion of that defined task within that phase or in support the operational phase of such a program). The technical program planning and control process is based on a risk management strategy and include a comprehensive TPM approach.
3.3 System Engineering Process. The structured sequence of activities and decisions that
transform an operational need into a description of system performance parameters and a preferred system configuration. The process included rapid prototyping as a means of demonstration systems capabilities. Rapid Prototyping focuses on correcting system requirements misconceptions and reducing ambiguities is performance parameters early in the engineering design phase as a cost risk mitigation effort.
3.4 Engineering Specialty Integration. The timely and appropriate interactive process that
ensures that engineering efforts and disciplines such as reliability, maintainability, human factors, safety, quality assurance, TQM/CPI, etc., will effectively influence the system design throughout the design process.
3.5 Other. The definitions included in the applicable documents and processes listed in
Section 2 shall apply. 4.0 GENERAL CRITERIA
Our engineering management process shall conform to item (a) through (k) specified in paragraph 4 of MIL-STD-499A. The MIL-STD-499A requirements are stated here for convenience:
a) Technical Objectives. Technical objectives shall be established for each program
so that meaningful relationships among need, urgency, risks and worth can be established.
b) Baselines. Functional, allocated, and product baselines shall be developed
progressively. Appropriate specifications shall be prepared in accordance with MIL-STD-490.
c) Technology. Specification requirements shall be delineated in light of acceptable
technological risks defined by risk assessment.
d) Realistic System Values. Realistic Reliability, Maintainability, and other such system values shall be established prior to full-scale development phase.
e) Design Simplicity. The concept of design simplicity and standardization shall be
evident.
f) Design Completeness. The design shall be complete from a total system element viewpoint (hardware, facilities, personnel, computer programs, procedural data).
g) Documentation. The concept of minimum documentation shall be evident.
Where possible stipulated plans, reports, and other data items shall be used to record the engineering outputs. The repository of this accumulated data will be
3
defined. Engineering data shall be the sole source of performance requirements used in the design and production of the system.
h) Engineering Decision Studies. Engineering decisions regarding design
alternatives and the technical program shall reflect consideration of system cost effectiveness analysis based on the specified figure(s) of merit, performance parameters, program schedule, resource constraints, producibility, and life cycle cost factors.
i) Cost Estimates. Cost estimates shall include acquisition and ownership costs.
This shall include any established “design to” cost goals and a current estimate of these costs.
j) Technical Task and Work Breakdown Structure Compatibility. Elements of the
Contract Work Breakdown Elements of the Contract Work Breakdown Structure and associated technical tasks shall be identified and controlled in accordance with this standard and MIL-STD-881.
k) Consistency and Correlation of Requirements. System technical program
requirements shall be consistent, correctable, and traceable throughout the Contract Work Breakdown Structure so that impact of technical problems can be promptly determine and accurately appraised.
l) Technical Performance Measurement. Progress in achieving technical
requirements shall be continually assessed. Problems and risk areas shall be identified.
m) Interface Design Compatibility. Intra-system and inter system design
compatibility of engineering interfaces shall be delineated as interface requirements in appropriate specifications. Interface control requirements and drawings related to (1) the major system elements of a prime contractual responsibility, (2) other equipment, computer programs, facilities, and procedural data furnished by the Government, and (3) other program participants, shall be coordinated established and maintained (MIL-STD- 483 (USAF)). Clear lines of communication and timely dissemination of changes to these documents shall be maintained.
n) Engineering Specialty Integration. Engineering efforts such as Integrated
Logistics Support (ILS), test engineering, production engineering, transportability, reliability and maintainability engineering, value engineering, safety engineering, electromagnetic compatibility, standardization, etc., shall be integrated into the mainstream design effort.
o) Engineering Decision Traceability. Significant engineering decisions shall be
traceable to the system engineering process activities on which they were based.
p) Historical Data. Historical engineering/operational data available to system designers shall be identified.
q) Responsiveness to Change. Changes to system and program requirements in
response to directed changes by the procuring activity, of problem solutions
4
identified shall be evaluated, for total program impact with respect to performance, cost and schedules.
r) Compatibility with Related Activities. Engineering Management activities shall
be compatible with related program management activities such as cost schedule control system criteria, contract administration, production management, etc.
5.0 SYSTEM ENGINEERING MANAGEMENT
Under the charter to establish and maintain leadership in the development of systems and in support of system acquisition managers, our management approach necessarily parallels and supports the DoD acquisition policies set forth in DoDD 5000.1, DoDI 5000.2 and DoD 5000.2M. The fundamental philosophy is to allow engineering directorates maximum flexibility and to eliminate over managing and its negative attributes. The management philosophy is based on Risk Management strategies followed by monitoring of cost, schedule and performance parameters. Comparison of actual versus predicted, observing and evaluating trends, and using the latest management analysis tools and techniques is the foundation of the management philosophy.
5.1 Technical Program Planning and Control. This System Engineering Management Plan (SEMP) identifies organizational responsibilities and authority for systems engineering as chartered by our corporation. This is illustrated in Figure 5-1 (put your org chart here). Flexibility is provided by allowing administrative responsibilities at one level and technical control at another, i.e., Director of Plans and Program can by under the direction of Sr. VP MX operations for high risk programs of programs requiring high corporate management visibility while still under SB administrative control.
5.1.1 Project Management. The program manager for each contractual effort is identified by
an officer of the company. He/she is be responsible to the Director of Plans and Programs to perform business and program management efforts to accomplish overall project objectives. These efforts include preparation, review, and revision/updating of management documentation selecting and implementing the appropriate software management tools for information management and performance analysis (including requirement for upper management and customer review requirements) of overall business, administration and engineering activities. Our organization will establish a process for planning and controlling project, systems engineering and technical support to acquisition mangers within this SEMP. Tailoring is the responsibility of the individual PM. It is accomplished with concurrence by the acquisition manger.
Figure 5-2 delineates the responsibilities for the typical development
documentation that will govern system development. Under a prime contracting approach, the Program Manager is typically is a contractor function. In the case of a SETA and where the role of the prime is retained within the government, the SETA contractor will support the government PM in the development of the top-level documentation and review of the contractor produced documentation.
5.1.2 Contracts Management. The support contractor PM is required to perform judicious
monitoring of activities to keep their aspect of management in focus. If required, the PM prepares Statements of Work (SOWs) for submittal to the Acquisition Manager for contract execution. PM, upon contract approval, prepares task authorization tasking for
5
the Technical Director or Engineering Manager responsible for executing the engineering efforts. This is accomplished in accordance with the Task Authorization process; Program Manager is individually accountable for the effort serves as a single point of contract of technical monitoring and development progress within our company and is the single point of contract for reporting status to the customer.
6
Note: reduction by one layer is desirable.
CEO
SR VP XX
OPERATIONS
VP xx
Systems Engineering
DIRECTOR of
Engineering
DIRECTOR of
Plans of Program
TYPE ORGAN
Responsible for overall efforts and strategies and for corporate performance
Responsible for Individual Program performance, Conducts corporate management in-process reviews; Responsible for Corporate Resource Allocation (Manpower and Financial)
Prime Responsibility for Program Execution
Responsible for technical program execution including technical planning and control
Responsible for Program Management including sub-contracting
Figure 5-1
IZATIONAL STRUCTURE
7
8
C
D
B
A SIIs – SYSTEM IN ON INTERFACE SPECIFICATION HWCI – HARDW IGURATION ITEM SEAR – SYSTEM RING ANALYSIS REPORT
ACQUISITION MANAGER RESPONSIBLE
PM RESPONSIBLE/ACQUISITION MANAGER APPROVAL
PM RESPONSIBILITY
PM RESPONSIBIITY/ACQUISITION MANAGER REVIEW
D
SOFTWARE C5
SPEC
C
LISTINGS
CONCEPT DEMONSTRATION AND DEFINITION VALIDATION PHASE FULL SCALE ENGINEERING PHASE PHASE
D
D
DRAFT HWCI
C1 SPEC
D
SOFTWARE TOP LEVEL
DESIGN DOCUMENT
SE
NT
CE
NT
D
NT
REVISIONS AND UPDATES AS REQUIRED
C
SEAR
UPDATE
B
D
SOFTWARE B5
SPEC
INTERFACE REQ’T SPEC
B
SYSTEM “A”
SPEC
C
B
B
B
SYSTEM PROGRAM
PLANS
TAILORED
SEMP
SUBSYSTEM DESIGN AND
SUPPORT PLANS
B
D
HWCI B1
SPECS
SEGMENT SYSTEM
“A” SPEC
SEAR
A
A
TOP LEVEL PROGRAM
PLAN
A
SUBSITTED WITH PROPOSAL
A
SEMP
PROGRAM DESIGN AND
SUPPORT PLANS
SIIs
PROGRAM REQUIREMENT SPECIFICATION
Figure 5-2 TYPICAL PROGRAM DEVELOPMENT PRODUCT AND R IBILITIE
TEGRATI
ARE CONF
ENGINEE
HWCIC1
SPEC
D
D
D
DATABADESIGN
DOCUME
INTERFADESIGN
DOCUME
S/W DETAILE
DESIGNDOCUME
ESPONS
9
5.1.2 Sub-Contractor Management. PM has the same responsibilities for sub-contractor tasking, monitoring and oversight as he/she has for this firm’s internal engineering efforts. The process will follow Vitro corporate processes and policies.
5.1.3 System Test Planning. Figure 5-3 depicts the typical program test requirements.
Acquisition Managers and Prime Contractor Program managers have the same responsibilities if the Government retains prime contract role and contracts for System Engineering and Technical Assistance (SETA) efforts.
The system test planning necessarily includes risk mitigation efforts with
experiments to demonstrate risk reduction. The system planning also includes provisions for performance measures development and reporting. These include intermediate performance criteria and key engineering milestones and schedules to complement engineering management with risk management strategies. Technical Performance Measurement (TPM) techniques is developed, implemented and maintained as integral to the system test planning process.
5.1.4 Risk Analysis. The PM is responsible for structuring technically sound programs that
assess risk at all levels and identify areas of high risk. High-risk areas are subject to corrective actions or risk mitigation activities. Risk analysis techniques and the characteristics of software tools necessary to support program risk analysis are identified in the Risk Management Manual. PM, with acquisition manager’s concurrence, is responsible for tailoring the manual to achieve adherence to overall technical, financial and schedule program goals.
The risk manual is used in conjunction with DoD 4245-7M, which serves as a
guideline for identifying areas of risk and determination of risk drivers for establishing the uncertainties inherent to risk analysis efforts. The risk manual includes using outlines contained in DoD 4245.7M for reducing risk and implementing risk abatement programs. Risk Analysis is a major function at each System Design Review (Ref. internal Technical Review and Audit Process Manual).
5.1.5 Contract Work Breakdown Structure (CWBS). The program CWBS developed in
accordance with CWBS development guidelines. The guidelines are in accordance MIL-STD-181 and Defense Systems Management (DMSC) Systems Engineering Management Guide. The Program CWBS is identifying tasking development, tasking, authorization and status monitoring activities. Each task in the CWBS tree is assigned a code that preserves and communicates the CWBS subdivisional/summation requirements. Standardization of CWBS nomenclature is inherent in the process to maintain traceability for historical costs to fulfill compliance with DFARS 215.811.
5.1.6 Technical Performance Measurement (TPM). The program manager implements TPM in
accordance with the Technical Performance Measurement Manual. TPM implementation follows MIL-STD-499A requirements and is tailored by the program manager (with acquisition manger concurrence) to specific programs needs. The program complements the System Management Philosophy being implemented.
5.1.6.1 Performance Parameters. The selection of the TPM performance parameters is
predicated on (1) ability to provide visibility of actual versus planned performance to support decision making process, (2) ability to provide early detection or prediction of
10
Figure 5-3 TYPICAL PROGRAM TEST REQUIRE
A
B
C
D
CI – CONFIGURATION ITEM HWCI – HARDWARE CONFIGURATION ITEM LBEF – LAND BASED EVALUATION FACILITY TEMP – TEST AND EVALUATION MASTER PLAN
ACQUISITION MANAGER/PM RESPONSIBILITY
PM/TECHNICAL DIRECTOR RESPONSIBLE/ACQUISITION MANAGER/PM APPROVAL
PM/TECHNICAL DIRECTOR RESPONSIBILITY
PM/TECHNICAL DIRECTOR RESPONSIBIITY/ACQUISITION MANAGER/PM OBSERVER
CONCEPT DEMONSTRATION AND EXPLORATION VALIDATION PHASE FULL SCALE ENGINEERING PHASE PHASE
PREPARE
TEST REPORTS
PREPARE
TEST REPORTS
PREPARE
TEST REPORTS
SYSTEM
COMPONENT/ SUBSYSTEM
PREPARE SYSTEM
INTEGRATION TEST
PROCEDURES PREPARE
TEST REPORTS
PREPARE SYSTEM
INEGRATION TEST PLAN
PERFORM LBEF
TESTING
PERFORM OPERATION
TESTING
D D DDDD
PREPARE MASTER
TEST PLAN
PREPARE PROGARM
TEMP
A
PREPARE SYSTEM
TEST PLAN
PREPARE TEST
PROCEDURES
PERFORM
EXPERIMENTS
PERFORM ADM/EPM TESTING
PREPARE SOFTWARE
TEST DECRIPTION
PREPARE HARDWARE
CI TEST PLAN
PREPARE HARDWARE
INSTALLATION TESTS
PREPARE SOFTWARE
CI TEST PLAN
PREPARE HWCI TEST
PROCEDURES
PERFORM SOFTWARE
TESTS
PREPARE SOFTWARE
TEST PROCEDURES
C C C CC
B
COMPONENT/ SUBSYSTEM
C C C C C C BC
MENTS
problems or trends which require management attention, and (3) ability to evaluate change alternatives. The TPM risk assessment and related technical control processes are a continuum of interrelated, interactive, and interdependent systems. TPM provides the data for technical risk planning and assessment. TPM selection process receives input from the risk management processes, wherein, parameter criticality is identified by the critical path templates provided in DoD 4245.7M
5.1.6.2 TPM Assessment Methods. There is a wide range of methods available for technical performance. Test methods supported by comparative analysis between actual and predicted results are preferred but these do not necessarily meet the criteria for early prediction of problems. Forecasting methods such as math models and simulations which have application in the concept definition and feasibility demonstration phase and which phase appear to be best suited for our development or technical assistance efforts. Vitro recognizes the need for early detection of problems to support management decisions before irrevocable cost or schedule impact occurs. We are constantly developing or evaluating Computer Aided System Engineering (CASE) tool sets with emphasis of Systems Requirements definition. We have significant internal resources applied to development of Rapid Prototyping Techniques (System Requirements and Man-Machine Interface evaluation aids) to supplement our extensive systems simulation and computer modeling development programs.
5.1.6.3 Report Frequency and Timing. The tailoring of reporting requirements is left to the discretion of the individual PMs (or Acquisition Managers). TPM tracking results will be reported at each Systems Design or System Progress Review. Formal TPM assessments are be planned to coincide with planned completion of significant design and testing tasks and will be significant inputs program decision milestone activities.
5.1.7 Interface Compatibility.
5.1.7.1 Interoperability. Interoperability is defined as the ability of systems, units, or forces to provide services to and accept services from other systems, units or forces and to use the services, which are exchanged so as to enable them to act together. The typical system interoperability requirements exist at three levels: between primary system under development and an external hierarchical entity; between primary component systems; and wotjom component systems.
5.1.7.2 System Integration Interfaces. The typical system achieves interoperability by controlling and documenting the interfaces at the three levels of interoperability. These interfaces are called System Integrating Interfaces (SIIs) and are defined as any interface, internal or external, to the primary Systems that is identified, defined, and controlled by the PM to ensure required system interoperability and commonality.
5.1.7.3 Interoperability Process. The interoperability process is a formal structure wherein system compatibility requirements are defined. It is typically accomplished by an analytical group within the engineering sector. The group will use functional analysis techniques to develop the functional and interface requirements. As the total system is broken down into functional areas, interfaces between the functional areas will be identified as potential SIIs. Mission and design constraints are factored into the effort further developing the SIIs. The primary method of definition is through an Interface Working Group (IWG). An IWG is formed with specialists in each functional area participating. The IWG is responsible for documenting the design and control
11
requirement in the Interface Control Documents (ICDs) or SIIs. These must be approved by all parties to ensure agreement on the interface design details. Detail design engineers must satisfy the requirement of these interface documents as they realize the design of their piece of the system. In this way, the system is integrated so all the pieces work together in an orchestrated whole. In this manner systems engineering will be concerned with total systems architecture allowing design engineers the flexibility with their detail design. Systems integration assembles the pieces and tests to ensure compliance with systems requirements. The Chief Engineer, through the Technical Review and Audit process, is responsible for auditing the design documentation and results of the tests to ensure system interface complies with the requirement documentation.
In complex systems a Test Interface Working Group (TIWG) will be chartered with its own unique responsibilities. The IWG concept with adequately prepared documentation will be complemented by the TIWG function to define the test, test analysis functions and the test sequence that will influence the form and format of the ICDs and SIIs. Interactive Staffing of both the IWG and TIWG functions promotes total interoperability and compatibility.
5.1.8 Data Management. The PM will perform necessary activities in order to prepare, review,
and revise/update management data, as defined below, to reflect system design, development, and installation requirements and status. As applicable, management data will be inclusive of networks, cost estimates and models, cost performance reports, and contractor funds status reports.
As a minimum the PM: a) establishes and maintain a CWBS, which will be organized in accordance
with guidance provided herein, and utilize the CWBS to establish the program database
b) develops and maintains a Project Master Schedule (PMS), which will include
design documentation deliveries, program and design reviews, equipment acquisition, and installation planning milestones
c) conducts project reviews at least quarterly in order to provide status and
replanning data to acquisition manager throughout the development period with respect to a summarization of accomplished work, problem area, cost expenditures, and anticipated activities for the following period
d) prepares and maintain the status of work accomplished, with expenditures
identified to the appropriate CWBS element
e) provides financial analysis and cost breakdown reports that cover each task and subtask order in terms of both planned and actual expenditures
f) conducts semiannual program status reviews for the purpose of financial
planning for anticipated tasking during forthcoming periods. 5.1.9 Configuration Management. The PM will establish a Configuration Management
Program guided by the requirements of MIL-STD-483 and the internal Configuration Management Manual and assure a complete and accurate technical description of the
12
13
system. The program will provide toe establishing and maintaining systems configuration identifications, and auditing SII Technical Data Packages (TDPs), controlling changes to baselines of Configuration Items/Computer Software Configuration Items (CIs/CSCIs), and control and status accounting for identification of approval baselines and proposed or approved changes.
5.1.10 Technical Reviews and Audit. Program reviews and audits are outlined in the internal
Technical Review and Audit Manual. Technical reviews will be conducted in general compliance with MIL-STD-1521 and DoD STD 2167A. Figure 5-4 summarizes review requirements and responsibilities.
5.1.11 Formal Program Reviews. The PM conducts quarterly formal program reviews to
present complete contract status including performance cost and schedule. The technical management program status, problems, and issues shall be presented from each Project Leader.
5.1.12 Informal Reviews. PMs are encouraged to hold informal reviews, as necessary or as
requested by the Acquisition Manager to discuss and answer questions or action items, resolve issues and problems, review and discuss hardware, software, and documentation, and to present results of test or analysis.
5.1.13 Financial Management. PM maintains and management control system that includes
policies, procedures and methods that are designed to ensure that they are in concurrence with the requirements of DoDI 5000.2, Part II, Section B, Attachment 1. Specific processors and software management tool characteristics applicable to various efforts are delineated in the internal Financial Management Planning, Reporting and Monitoring Process Manual.
5.2 System Engineering Process and Planning. This section describes the system engineering
process to ensure a successful, cost-effective development program. It also provides the guidelines for effective use of Computer Aided System Engineering (CASE) tools, models, and simulation to aid the process.
5.2.1 System Engineering Process. The system engineering process recommended is depicted
in Figure 5-5. It is a flexible approach that is adaptable to typical system development programs and to each component subsystem of these programs.
5.2.2 General Approach. The system engineering process utilities tried and proven techniques.
It is a top down design methodology characterized by an evolutionary iterative and interactive process. Use of automated systems engineering tools is encouraged. The emphasis is on commercially available tool sets with new development of models and simulations only when necessary. New development is accomplished in a manner that allows easy aggregation into an existing inventory to provide systems solutions. The approach emphasizes rapid prototyping to allow earlier and more comprehensive design reviews. The reviews will uncover specification errors and ambiguities in the development phase where corrections are the least expensive. Finally, the process is documented. PM requires the maintenance of a System Engineering Analysis Report (SEAR). The SEAR has the same utility as the engineering notebook has for the researcher. It provides the necessary engineering traceability. It provides the background for follow-on investigations and Preplanned Product Improvement (P3I) programs. It can
CONCEPT DEMONSTRATION AND EXPLORATION VALIDATION PHASE FULL SCALE ENGINEERING PHASE PHASE
SOFTWARE
PCA
FORMAL
QUALIFICATION REVIEW
SYSTEM
PCA
FORMAL
QUALIFICATION REVIEW
HWCI PCA
CSCI NO 2
CSC1
NO ‘IV’
CSC1 NO 2
SYSTEM REQUIREMENTS
REVIEW
SYSTEM REQ’TS RAPID
PROTOTYPE REVIEW
MMI RAPID
PROTOTYPE REVIEW
A A A
FUNCTIONAL ANALYSIS &
SYSTEM DEFINITION COMPLETE
A B
B
B
B
B
PRODUCTION READINESS
REVIEW
B
B
A A
A
A
A
*
*
FUNCTIONAL BASELINE
ESTABLISHED
ALLOCATED BASELINE
ESTABLISHED
SYSTEM DESIGN REVIEW
DRAFT SEGMENT SYSTEM
A SPEC REVIEW
DRAFT SOFTWARE
SPEC REVIEW
DRAFT HWCI
B1 SPEC REVIEW
PDR CSCI NO 1
PDR
HWCI
CDR CSCI NO 1
CDR
HWCI
HWCI FCA
SOFTWARE
FCA
SYSTEM
FCA
A
C B
B
• PROGRAM MANAGER’S QUARTERLY PROGRAM REVIEW
A MAN-MACHINE INTERFACE
– HARDWARE CONFIGURATION ITEM
PRELIMINARY DESIGN REVIEW
CRITICAL DESIGN REVIEW
FUNCTIONAL CONFIGURATION AUDIT
PHYSICAL CONFIGURATION AUDIT
– COMPUTER SOFTWARE CONFIGURATION ITEM
CHIEF ENGINEERING RESPONSIBLE FOR INTERNAL REVIEW/PM FOR EXTERNAL REVIEW
PM RESPONSIBILITY
PM RESPONSIBILITY/ACQUISITION MANAGER REVIEW
* RECOMMENDED ACTIVITIES
B
C
Figure 5-4 14
CSCI NO ‘IV’
MMI –
HWCI
PDR –
CDR –
FCA –
PCA –
CSCI
CSCI-2
CSCI-1
SUBSYSTEM-M
CSCI-2
CSCI-1
SUBSYSTEM-A
OPS REQUIREMENTS
ENVIRONMENT
ARIOS
STEP 1
MISSION ANALYSIS REVIEW
EXISTING MISSION
ANALYSIS
MISSION
STEP 2 REQUIREMENTS/
OPS CONCEPT EFINITION
STEP 4 PARAMETRIC
REQUIREMENTS ANALYSIS
STEP 3
SCEN
FUNCTIONAL ALLOCATION
EFFECTIVENESS MODELS & SIMULATIONS
FUNCTIONAL
FUNCTIONAL IDENTIFICATION
PERFORMANCE REQUIREMENTS
ANALYSIS SUBSYSTEM
PERFORMANCE
STEP 3 TRADE
STUDIES
SOFTWARE ARCHITECTUREHARDWARE
ARCHITECTURE
STEP 10 PROGRAM
DEFINITION/ SPECIFICATION DEVELOPMENT
STEP 9 REQ’TS &
MMI RAPID PROTOTYPING
MAIN PROCESS FLOW
ITERATIVE PROCESS
SECONDARY FLOW
STEP 8
EVALUATION SUBSYSTEM CANDIDATES
STEP 8
EVALUATE SYSTEM
ALTERNATIVE
SCHEDULE RISK
PERFORMANCE
EFFECTIVENESS
PHYSICAL CONTRAINTS
COST TECHNICAL RISK
STEP 7 DEFINE SYSTEM ALTERNATIVES
LIFE CYCLE COST
ANALYSIS
RISK ANALYSIS
LOGISTICS ANALYSIS
RM&A ANALYSIS
MANPOWER & SKILL LEVEL
ANALYSIS
EFFECTIVENESS
RISKCOST
SUPPORTABILITY
MANPOWER GROWTH POTENTIAL
Figure 5-5. SYSTEM ANALYTICAL ENGINEERING PROCESS
15
D
be extremely useful and cost effective for program managers and system engineers performing similar design initiative.
5.2.2.1 Step 1 – Mission Analysis Review. Review of Mission Analysis, as depicted in Figure 5-5-5 is defined for a complete System front-end design application. Mission analysis can be equally applicable to analyzing the requirements for component subsystems, feasibility of modifying existing systems to meet operational requirements, or modifications (reliability or performance enhancements) to exiting system. Tasks associated with these subsets require similar reviews and continue along the same process, differing only in scope and depth of the numerous supporting analyses. Results of Step 1 will be documented in the SEAR and summaries will be available for PM review.
5.2.2.2 Step 2 – Operations Concepts/Requirements Definition. The beginning of the detailed systems engineering design process commences with the definition of the many operational concepts to fulfill a proposed mission requirement or profile. The totality of missions and operational factors are integrated to further define flight profiles, operating environment, communications, control hierarchy, and recovery responsibilities that definitive the operational concepts. Further analysis results in the initial system concept and leads to the development of the top-level requirements. The results of Step 2 shall be documented in the SEAR and the top-level requirements submitted to PM and/or Acquisition Manager for review.
5.2.2.3 Step 3 – Function Analysis and Allocation. Function analysis, as indicated, is composed of two distinct process segments: (1) functional identification and, (2) functional performance requirement analysis. The basic system engineering tool for functional identification is the Functional Flow Diagram (FFD) that shows the logical sequences and relationships between operational and supports functions at the system levels. Commercially available tools, based on FFD techniques, aid and enhance the process. Tool selection criteria should include ability to support the functional performance requirement analysis. The output is then utilized for functional allocation processes.
Step 3 is indicative of the system engineering process at work. It should use intermediate outputs for multiple purposes.
a) Initially, it should record performance against each function
b) During System Synthesis it records the allocation of functional requirements
to individual subsystem elements or combination of elements
c) Later, it will be used for formulating specification details.
Step 3 is an iterative process. Alternate allocations are made to create subsystem options. Each option may produce a different operational concept and system architecture. The output of Step 3, a top level description of the alternative system architecture. The output of Step 3, a top level description of the alternative system architecture and the alternative allocations of function to subsystems, shall be documented in the SEAR.
5.2.2.4 Step 4 – Parametric Analysis. Parametric analysis that includes defining the
interrelationship between key subsystem performance requirements must be conducted
16
for all the system architectures defined in Step 3. This step evaluates the combinations of subsystem performance capabilities that can achieve the total system performance. This step identifies and quantifies all the major performance relationships of the key subsystems. Data, data sets, and summary graphs for each alternative and concept shall be documented in the SEAR.
5.2.2.5 Step 5 – Trade-Off Studies. Trade-Off Studies commence during the conduct of
parametric analysis. Subsystem trade-off results are developed for performance versus design parameters, cost, weight, and other technical performance measures. Parametric requirements are used to bound the performance range being explored. The emphasis may be either or subsystem trade-offs, on key subsystem combinations that lead to modification of older systems, or on new systems. Its goal is to achieve a synergistic balance between architectures (software and hardware) and subsystem performance allocations.
Steps 3, 4, and 5 are necessarily highly iterative and highly interactive. The
system engineer must assess the impact on system complexity, cost, physical constraints, and overall mission effectiveness of the requirement. An awareness of the penalty for not achieving a particular requirement must be continually present during the process. Sufficient number of alternative approaches should be visible and documented in the SEAR to ensure subsystem optimization.
5.2.2.6 Step 6 – Evaluation of Subsystem Candidates. Evaluation of subsystem candidates
begins with defining a preliminary design approach. To the extent possible, the designs are parametric because subsystem performance requirements should not be set until (1) a total military system is defined and the combination of subsystem and/or payloads working together in the different alternatives are known, and (2) the physical constraints and the technological limitations are computed for a given configuration.
A preliminary evaluation considers performance (as related to parametric
requirements analysis), analysis of system capability (peak and sustaining rates), mission effectiveness, physical constraints, and costs (development, unit production, and total life cycle) will be interactive to reducing technical and schedule risks. Measures of Systems Effectiveness will be developed to serve as evaluation criteria for the multiple interaction of this step.
5.2.2.7 Step 7 – Define System Alternatives. The system alternatives are the logical combination
of subsystem candidates from a consideration of the evaluation criteria and other relevant factors, e.g., potential for evolutionary growth.
5.2.2.8 Step 8 – Evaluate System Alternatives. The different alternatives are examined. The
evaluation criteria include but are not limited to mission effectiveness, risk (technical, costs, and schedule), life cycle cost, supportability (including RMA), manpower requirements, and growth potential. The evaluation is supported by a series of documented analyses in the SEAR that include mission effectiveness, risk, life cycle cost, RM&A, logistics, and manpower (to include skills requirements). The results of steps 6, 7, and 8 are a study report that is documented separately or as an addendum to the SEAR.
5.2.2.9 Step 9 – Requirements and Man-Machine Interface (MMI) Rapid Prototyping. Rapid
Prototyping is a relatively ne but essential element in the system engineering process. Commercially-available tools are available to use as kernels of an evaluation system that
17
achieves static and dynamic representations of the requirements. This allows customer and the design staff to observe and interact with the systems concepts as modeled by the analytical engineers. Moreover, the output of most models generates the detailed requirements that become part of the specification. This eliminates the errors and ambiguities that plague the translation of human ideas into specification language and conveyance of those ideas to the design engineers.
Interactive with and iterative to the requirements modeling, rapid prototyping
(using commercially available tools) is key to the MMI in a virtual environment. This will allow human factors and operational specialists to execute the display and control functions and to influence the specification requirement in the infancy of the design phase.
Results of the requirements and MMI rapid prototyping demonstration become
major agenda items for Preliminary Design Review (PDR) activities.
5.2.2.10 Step 10 – Program Definition and System Specification Development. The final step is to select the preferred alternative(s) and to define the required development. Programs that could be effectively evolved into the final system. The product of the process is a system specification or a set of modifications to the existing system specification.
5.2.3 Decision and Control (D&C) Processing. The typical Project Decision and Control
process is depicted in Figure 5-6. The key characteristic of the process is the orderly flow down of requirements and the flexibility of options in the implementation. It is generally the acquisition responsibility to flow down requirements from newly defined or changing mission and operational requirements to the system requirements. The PM is responsible to the Acquisition Manager for ensuring that alternatives are identified and appropriately evaluated during that process. The Acquisition Manager will involve the appropriate working groups for assistance in the Centers of Excellence, and operations groups for assistance in the identification and evaluation process. Once decided, the requirements will be flowed down to the contractor for implementation.
5.2.4 Interoperability Process. Interoperability, is assured through control of the mission
critical interfaces in each system. Precise definition of the System Integration Interfaces (SIIs) early in the Program is essential to this process. The interoperability process will be managed by the PM or SETA, who will coordinate with the Project Mangers or the Acquisition Mangers Program Steering Group to define the SIIs. In addition, SIIs are fabricated and validated in accordance with the SII documentation. The PM/SETA is accountable for the proper performance of each SII.
5.2.5 Systems Modeling and Simulations. The PM shall develop and maintain a system
modeling and simulation capability that can be used to determine mission and system performance effectiveness.
The individual component system Project Managers develops or acquires and
maintains modeling and simulations capability to perform the following analytical tasks: • Rapid Prototyping of Systems Requirements and Architectures • Rapid Prototyping of the Control System(s) Man-Machine Interfaces • Parametric Requirements Analysis
18
INTEROPERABILITY SUBPROCESS
CRITICAL PERFORMANCE REQ’TS
OPERATIONAL REQ’TS
FUNCTIONAL REQ’TS
OPERATIONAL EXPERIMENTS
MISSION REQ’TS
TOP LEVEL SPEC
ICWG/CM PROCESS
PROGRAM STEERING GROUP
SIIs
SYSTEM CHARACTERISTIC WBS
NEW APPLICATION
DECISION
MODIFICATION DECISION
NEW DEVELOPMENT
DECISION
APPLICATION EVALUATION
DEVELOPMENT PROGRAM
TOP LEVEL SPEC CHANGE
PRODUCTION PLANNING
TEST PROGRAM
SII CHANGE
PRODUCTION DECISION
TAILORED PROGRAM
DEVELOPMENT PROGRAM
INDUSTRY/GOVERNMENT LABS TECHNOLOGY INFUSION
TEST PROGRAM
PRODUCTION DECISION
Figure 5-6 TYPICAL PROJECT D&C
19
• Engineering Trade Studies • System Control Algorithm Development • System Flight Analysis • System Test Analysis • L-C-C Estimating • Reliability and Maintainability Analyses • Spares Computational Analysis. The PM shall make the models and simulations available (if requested) to the
Acquisition Manager or his designate agent to allow aggregation for total system analysis.
5.2.6 Specification Development. Specifications shall be prepared in accordance with MIL-
STD-490A, DoDD 4120.3, and DoD 4120.3M. Specification Tailoring is encouraged. The PMs shall be responsible for ensuring that only the requirements that are truly necessary will be imposed by the individual contracts.
5.3 Specialty Engineering Integration. This paragraph defines how the specialties
engineering of logistics, quality assurance, reliability, maintainability, human engineering, system safety, and other areas are integrated into the mainstream design effort. Figures 5-7 and 5-8 depict the processes for ensuring early influence of specialty engineering on design process.
5.3.1 Logistics Engineering. Integrated Logistic Support (ILS) is the composite of all the
support considerations necessary to ensure the effective and economical support of a system, subsystem or component over its life cycle. This includes the principle logistic personnel, support and test equipment, facilities, transportation sand handling, and technical data. This also includes the logistics management activities required to implement the logistics engineering concepts, funding, policies, and procedures formulated through logistics engineering efforts during the system design development phase. Typical Table 5-1 summarizes the major ILS activities and delineates the division of responsibilities between Acquisition Manager and the Program Manager. The program manager’s responsibilities are subject to authorization (or delineating of responsibility) by the acquisition manager.
5.3.2 Quality Assurance.
5.3.2.1 Program Quality Assurance Requirements. The PM plans establish, implements and
maintains a Quality Assurance Program Plan. The Quality Assurance Program Plan reflects the guidance of MIL-S-52779, MIL-Q-9858, and MIL-STD-2167. The plan provides guidelines for PM Quality Assurance program and defines quality responsibilities for participation in scheduled management and technical reviews, and in support of the preparation of System test plans, test procedures, and specifications. Details are provided in the SB Quality Assurance Process Manual.
5.3.2.2 System PM Quality Assurance Requirements. The System PM establishes and maintains
a comprehensive Quality Assurance Plan and documented Policy Papers. MIL-Q-9858 is used for supplemental guidance. The PM implements Total Quality Management (TQM) principles throughout the life of his cognizant program. Special care is taken to ensure the use of TQM principles by contractors as described in the TQM principles by
20
PARAMETRIC REQUIREMENTS
ANALYSIS
MISSION ANALYSIS REVIEWS
FUNCTIONAL ANALYSIS
AND ALLOCATION
SUBSYSTEM PERFORMANCE
SYSTEM TRADE
STUDIES
A
RISK ANALYSTSSYSTEMS ANALYSYSTEMS ANALYINSTALLATION SCOST ANALYSTSSYSTEMS ANALY
RMA ENGR/LSYSTEM ANAMANUFACTUCOST ANALYLOGISTICS ASYSTEM ANASYSTEMS AN
EVALUATE DESIGN DETAILS
NS
SUPPORTABILITY
COST PRODUCIBILITY
A
EVALUATION EQUIPMENT
DESIGN APPROACHES
EFFECTIVENESS
PHYSICAL CONTRAINTS
TECHNICAL RISK
SUBSYSTEM DESIGN
EFFECTIVENESS & SIMULATIONS
MISSION MODELS
SYSTEM DESIGN
EDM TEST & EVALUATIONTRANSITIONAL DESIGN REVIEW (ENGR TO PRODUCTION) LOGISTICS/MANFACTURING/PRODUCTION PRODUCIBILITY ENGR/ACQ MGMT
EDM BUILDING
NDI DEMOS
FUNCTIONAL COMPONENT DESIGN PROCESSSEGMENT DESIGN REVIEWS TEAM MGRS/LOGISTICS/RMA RISK ANALYSTS/SYSTEM ANALYSTS
SYSTE LOGISQA/CMLOGISRMA E
BRASSBOARDS
REQUIREMENTS
PR
Figure 5-7. Process for Early Specialty Engineering Influence into System Design (Hardware Specific)
RAPID OTOTYPING
21
SPECIALTY ENGINEEERING INPUT
MS ANALYSTS/OPERATIONAL SPECIALISTSTICS ENGR/RISK ANALYSTS /DM/TEST ENGR
TICS, CM/DM, TEST ENGR NGR, ACQ MGMT, OPS SPECIALISTS
SPECIALTY ENGINEERING INPUT
/PRODUCIBILITY ANALYSTS/ACQUISITION MGMT STS/OPERATIONAL SPECIALISTS/RM&A ANALYSTS STS/OPERATIONAL SPECIALISTS/RM&A ANALYSTS PEC/MARINE ENGRS/EMC ENGRS/SAFETY ENGRS STS/RISK ANALYSTS/RMA ENGRS/LOGISTIC ENGR
SPECIALTY ENGINEERING INPUT
OGISTIC ENGR/SYSTEM ANALYSTS LYSTS/RESEARCH ENGR/LOGISTICIANS RING ENGR/LOGISTICIANS/SYSTEM ANALYSTS STS/ACQUISITION MGMT NALYSTS/TRAINING SPEC/OPS SPEC LYSTS/OPS SPECIALISTS ALYST/LOGISTICIANS/ACQ MGMT
PSI PLA
EFFECTIVENESTECHNOLOGY RISK
RM&
SCHEDULE RISK
PERFORMANCE
COST
SPECIALTY ENGEERING INPUT • ENGINEERING • RISK ANALYSIS • RM&A ANALYSIS • L-C-C ANALYSIS • LOGISTICS ANALYSIS
SOFTWARE RCHITECTURE
HARDWARE ARCHITECTURE
PARAMETRIC REQUIREMENTS
ANALYSIS
MISSION ANALYSIS REVIEWS
FUNCTIONAL ANALYSIS
AND ALLOCATION
SUBSYSTEM PERFORMANCE
SYSTEM TRADE
STUDIES
A EE
SUBSYSTEM DESIGN
EVALUATION SUBSYSTEM CANDIDATES
EFFECTIVENESS
PHYSICAL CONTRAINTS
TECHNICAL RISK
EVALUATE SYSTEM
ALTERNATIVE
RISK ANASYSTEMSSYSTEMSINSTALLCOST ANSYSTEMS
EFFECTIVENESS & SIMULATIONS
TY
EFFECTIVENESS
MISSION MODELS
SYSTEM DESIGN
MAN-MACHINE INTERFACE
REQUIREMENTS
PR
D
AP
PROGRAM DEFINITION/IRSs/ DEVELOPMENT SPECIFICATION(S)
APPROVAL
22
SPECIALTY ENGEERING INPUTS • ENGINEERING • RISK ANALYSIS • RM&A ANALYSIS • L-C-C ANALYSIS • LOGISTICS ANALYSIS
SOFTWARE RCHITECTUR
HARDWARE ARCHITECTUR
LYSTS
SCHEDULE RISK ANAL ANAL PERFORMANCEATIONALYST ANAL
COST
SPECIALTY ENGINEERING INPUTS
/PRODUCIBILITY ANALYSTS/ACQUISITION MGMT YSTS/OPERATIONAL SPECIALISTS/RM&A ANALYSTSYSTS/OPERATIONAL SPECIALISTS/RM&A ANALYSTS SPEC/MARINE ENGRS/EMC ENGRS/SAFETY ENGRS S YSTS/RISK ANALYSTS/RMA ENGRS/LOGISTIC ENGR
SPECIALTY ENGINEERING INPUTS MANPOWER/SKILLS/TRAINING ANALYSTS RISK ANALYSTS/ACQUISITION MGMT
MANPOWER
COST ANALYSTS/RISK ANALYSTS
RISK LOGISTICS/RMA/SAFETY ENGRS COS SYSTEM ANALYSTS/OPERATIONS SPECIALIST SUPPORTABILITGROWTH POTENTIAL
SYSTEMLOGISTIQA/CM/DHUMANTRAININ
TRANSITIONAL REVIEW(S) (DESIGN TO SOFTWARE DEVELOPMENT)
NDI EMOS/
DESIGN PROVAL
RAPID OTOTYPING
SYSTEMQA/CM/DACQUISI
SPECIALTY ENGINEEERING INPUT
S ANALYSTS/OPERATIONAL SPECIALISTS CS ENGR/RISK ANALYSTS M/TEST ENGR
ENGINEERINGS/OPERATIONAL SPECIALISTS G SPECIALISTS/MAINTAINABILITY ENGRS
DESIGN/SOFTWARE DESIGN M/RISK MGMT TION MGMT/TEST ENGRS
FULL SCALE ENGINEERING DEVELOPMENT
Figure 5-8. Design Phase (Software Intensive System Specific)
Table 5-1. Integrated Logistic Support
REQUIREMENT ACQUISITION MANAGER RESPONSIBILITY
PM RESPONSIBILITY
LS Planning
Ensure establish ILS Directorate Responsibilities Develop an Integrated Support Plan (ISP) to provide ILS Planning guidelines over the entire life cycle; establish the ILS/System Engineering Iterative, Interactions Maintain centralized logistic support cost data file for the program; reporting format to be defined in the ISP Encourage CALS technology usage as delineated in DoDI 5000.2, Part 6, Section H
Designate ILS manager; ensure each contractor has appointed ILS Manager with sign-off authority equal to engineering and production managers Develop and ILS Plan (ILSP) for implementing Project Manager and subcontractor responsibilities Develop a logistics requirements in accordance with WBS as part of ILSP and forward reports monthly to Acquisition Manager Establish a management process to encourage use of CALS technology
Logistic Support Analysis (LSA)
Coordinate task ILS Directorate to Requirements LSA guidance; establish the LSA/System Engineering Linkages Establish and maintain a validated LSA Record (LSAR) automated data processing system
Organizational and intermediate level LSA tasks MIL-STD-1388-1A define tasks: LSA Plan; reviews; mission hardware; S/W and support system standardization; LOR program; task analysis, early fielding assessment; supportability assessment Require use of a validate LSAR automatic data processing system compatible with the Acquisition Manager’s System
Maintenance Planning Program
Develop depot level maintenance requirements from the LSA process
Organizational and intermediate level tasks using LSA/LORA process
• Identify miniature/microminiature repair capability requirements
• Demonstrate (by analysis) fault detection, fault isolation, and fault localization capabilities
• Identify Maintenance Assist Modules (MAMs)
23
Table 5-1. Integrated Logistic Support (Continued)
REQUIREMENT ACQUISITION MANAGER RESPONSIBILITY
PM RESPONSIBILITY
Maintenance Planning Program (Cont’d)
• Identify use of Standard
Electronic Modules (SEMs)
Manpower and Personnel
Provide guidelines
Demonstrate that LSA documented manpower and personnel levels are commensurate with operational and maintenance requirements Perform HARDMAN analysis
Training and Training Support
Provide Training Plan guidelines Provide the Training/Systems Engineering Linkages
Develop training plan using HARDMAN analysis and LSA Develop training course in accordance with MIL-STD-1379 Provide factory training as authorized
Supply Support
Provide guidelines Provide the System Engineering-Support System Linkages
Prime responsibility for procuring and maintaining supply support before transitioning the service supply support activity
Technical Manuals
Establish requirements
Develop and validate technical manuals
contractors as described in the TQM (often considered CPI) and Subcontractor Control Templates of DoD Manual 4245.7M.
5.3.3 System Safety. The PM develops and implements with Acquisition Manager approval
Safety Program Plan in general compliance with MIL-STD-882.
• PM maintains system safety data files available to and compatible with Acquisition Manager’s requirements,
• Maintains a system safety report database available to and compatible with Acquisition Manager’s requirement, Subsystem or Component Hazard Safety Analysis responsibilities are included,
• System Hazard Analysis of Test Configuration is generally the responsibility of the PM (Task 204) with Acquisition Managers assistance, if required,
24
• Operating and Support Hazard Analysis (O&SHA) is generally the responsibility of System PM,
• Software Requirements Hazard Analysis, responsibility of the PM, to include Hazard Analysis of (1) Top Level Design, (2) Detailed Design, (3) Code Level, (4) Software Testing, (5) Software User Interface, and (6) Software Safety changes,
• A Fault Tree Analysis, to be conducted to identify all failure modes contributing to an undesired event, is generally the responsibility of System PM
• Acquisition Manager generally establishes a System Safety Working Group as detailed in MIL-STD-882 (task 104).
5.3.4 Human Engineering (HE). PM develops a Human Engineering Program Plan in
accordance with DoDI 5000.2, Part 6, Section H Human Factors which provides general HE requirements and is readily tailored to meet specific system requirements. PMs develop appendices to address the specifics unique to their programs.
5.3.5 Reliability, Maintainability, and Availability (RMA). The PM establishes effective
RM&A Engineering “By Design” efforts in accordance with Acquisition Policy Papers. The program includes the additional guidance provided by MIL-STD-470, MIL-STD-785, DoD-STD-2167, and DoD Manual 4245.7M. Testability efforts in accordance with MIL-STD-2165 are considered within the RMA requirement scope.
5.3.5.1 Failure Reporting, Analysis, Corrective – Action System (FRACAS) and Test Analysis
and Fix (TAAF) Program. PM establishes FRACAS and TAAF Programs. Failure collection and recording commences with either first functional hardware test or first formal software and continues through production. Data collection, analysis, and correction requirements for Maintainability and Testability efforts are integrated with FRACAS and reported at all Failure Review Board Meetings. All software and hardware failures are used to determine the maturity of System Reliability and all test activities are monitored and failures subjected to analysis to determine the effectiveness and adequacy of BIT/BITE and to identify corrective actions in both design and production.
5.3.5.2 Models and Prediction. PM develops and maintains reliability (MIL-STD-756 Tasks 102
and 104 provide guidance) and maintainability (derived from the Reliability Model to address Organizational Level maintenance) models. A method for allocating reliability and maintainability to lower levels shall be evident in the processes. Reliability predictions are accomplished in accordance with MIL-STD-756 and Maintainability in accordance with MIL-HDBK-472. Predictions are continuously updated and integrated into the LSA process.
25
