Systems Engineering Management Plan (SEMP) - NASA’s Systems Engineering Handbook has concise definitions for the IMP and SEMP that are summarized here. The IMP, described above, defines how the project will be managed to achieve its goals and objectives within defined programmatic constraints. The Systems Engineering Management Plan (SEMP) is the subordinate document that defines to all project participants how the project will be technically managed within the constraints established by the IMP. The SEMP communicates to all participants how they must respond to pre-established management practices.
Note that the SEMP relates the planned systems engineering work to pre-established practices. This means, that like the IMP, the SEMP does not have to define from scratch how the project will be technically managed; it just has to define what standard practices will be used and any deviations from standard practices. Therefore, again like the IMP, the SEMP should not be a monster sized document that no one will ever read. There is a good discussion of SEMPs in NASA’s Systems Engineering Handbook. A concern with the NASA discussion is that it may lead teams to develop SEMPs that are much too detailed and therefore much too time consuming and expensive to prepare. The same concern exists with the discussion of the SEMP in IEEE Std. 1220. An outline for a SEMP that addresses these concerns was developed by Eric Honour of Honourcode, Inc. of Pensacola, FL in 2003.
A copy of Eric Honour’s outline is presented here with his permission. The only significant change made to is to strongly recommend that we recognize that today project documentation is almost always maintained in electronic format accessible via an enterprise’s intranet. Therefore one key to high quality documentation is achieving the “best” balance between copying material from one document to another and hyper linking between documents. An excess of hyper linking makes reading more tedious but excessive duplication also makes reading tedious for those that have already read other documents. A prescription for the “best” balance is not recommended here since it depends on the documentation particular to a specific organization. Authors of project planning documents should use their best judgment for achieving a good balance.
The following is Eric Honour’s outline in italics with the author’s comments in normal type:
The topics and outline provide comprehensive coverage. Each topic should be considered in the planning for a program, and then reviewed at the beginning of each subsequent phase. Some topics may only receive cursory consideration in early phases, with later expansion. (E.g. Producibility Analysis, System Implementation Transition)
The SEMP should contain only those processes and plans that are unique to the program.
Initial creation of a SEMP should require between 2-5 working days. Expansion of the SEMP to full planning later may take 2-4 weeks. Revision effort during later phases varies from 2 days to 3 weeks.
A complete SEMP may be as few as 5 pages, or as many as 50.
Annotated Outline
1.0 INTRODUCTION (Note that this section and section 1.1 should be identical to that in the IMP and copied from the IMP.
1.1 Overview
Identify the system and this document in one sentence. Use a sentence or two to summarize the purpose of this plan.
1.2 System Description
Describe the system, using text and/or figures as appropriate. This identical system description can be used in all plans created for this program. (E. g. define the design architecture using hardware and software trees.)
2.0 REFERENCED DOCUMENTS (Here is an example where the IMP should link to this List.)
List all documents that are specifically referenced within this document. Provide document number (including revision letter) and name in the format: ANSI/EIA-632 Processes for Engineering a System
3.0 TECHNICAL PROGRAM PLANNING AND CONTROL
3.1 Task Descriptions
3.1.1 Definition of Work
Define the technical work that must be performed under the contract. Show the contract work breakdown structure (CWBS), and describe the scope of each technical work package. Indicate the flow down of CDRL items to work packages (can be shown on the CWBS).
3.1.2 Subcontractor Work Effort
Define the work efforts to be performed by subcontractors or teammates under the contract. Identify the CWBS work packages containing this effort.
3.1.3 Schedule
Show the program schedule. Identify development phases and major milestones. Show a task network of task dependencies, with critical path. (I would copy the one page Master schedule from the IMP and link to the detail schedule or IMS)
3.2 Organization
3.2.1 Technical Organization
Show a diagram of the technical project organization. Also include diagrams of the related program organization and functional organizations. In creating this diagram, consider the principles of concurrent engineering. (Here is another opportunity for the IMP to link to more detailed information in the SEMP.)
3.2.2 Technical Functions
Provide a textual description of the responsibilities of each person in the technical project organization. Cross-reference responsibilities to the CWBS. Include subcontractor personnel, and include subcontractor monitoring responsibilities. (Section 4.3 of NASA’s System Engineering Handbook has an excellent and concise discussion of tying the lowest level of the CWBS to the responsible engineer or manager.)
3.2.3 Program Interfaces
Define the formal and informal technical interfaces to others. Consider customer and internal technical interface meetings, interface control working groups, and standards committees. Define how to control the interfaces - authority and responsibility.
3.3 Technical Control (Don’t forget the instruction in the beginning to include only things that are unique to the project. Don’t describe standard processes. Just note any tailoring specific to the project.)
3.3.1 Requirements Management
Describe the plans to manage technical issues on the program. Identify technical project meetings, issues tracking lists, issue resolution methods, and resolution authority.
3.3.2 Technical Issues Management
Describe the plans to manage technical issues on the program. Identify technical project meetings, issues tracking lists, issue resolution methods, and resolution authority.
3.3.3 Risk Management
Describe the plans to manage and mitigate technical risks on the program. Identify risk levels, threshold criteria and decision authority. Identify methods to identify risk, analyze risk and track risks. (Make the detailed Risk Management Plan a separate document and provide an overview here with links to the detailed plan. The reason is that the Risk Management Plan is a very active document that needs to be updated much more often than a SEMP as risks are mitigated and new risks are identified.)
3.3.4 Interface Control
Describe the plans to control interfaces within the system and between the system and other systems. Identify the interfaces to be controlled.
3.3.5 Configuration Control
Describe the plans to control baseline configuration of the system design. If a separate Configuration Management Plan exists, refer to it.
3.3.6 Document Control
Describe the plans to control the documents on the program. Consider master documents, copies, and distribution. Include documents created by the program team and those received from external sources. (The plans should include an “Information Architecture” diagram. Include the diagram in this section along with the descriptions recommended.)
3.4 Performance Control
3.4.1 TPM Process
Define the process to gather and calculate Technical Performance Measures (TPM). Define the frequency of measurement. Define the methods to disseminate the results, including management visibility.
3.4.2 Technical Performance Measures
Define the TPMs to be calculated. Define the raw data required and sources. Define the calculation methods for each TPM.
3.5 Program and Design Reviews
3.5.1 Review Process
Define the process to be followed for program and design reviews.
3.5.2 Review Schedule
Show a schedule for the specific program and design reviews to be used. Describe the purpose and content of each review. (The reviews should be on the Master schedule. Only describe them here if the project is deviating from the organization’s standard processes for reviews. If the reviews are tailored project leaders should distribute copies of the tailored checklists ahead of preparation for each review; otherwise workers are likely to refer to standard documentation for reviews rather than to dig instructions out of the SEMP.)
4.0 SYSTEM ENGINEERING PROCESS
4.1 Process Description
In the subsections that follow, describe the program-unique processes in each phase. Use standards as a reference, and do not restate the processes therein. Consider each activity in each phase. Specifically address the automated tools that will be used and their interconnection.
4.1.1 Operational Definition
4.1.2 Requirements Definition
4.1.3 System Architecting
4.1.4 Preliminary Component Design
4.1.5 Detailed Component Design
4.1.6 Prototype Manufacture
4.1.7 System Integration
4.1.8 System Verification
4.1.9 System Validation
4.1.10 Operation and Maintenance
4.2 Related Processes
4.2.1 Electronics
Define the specific electronic engineering development processes to be used. Define the types of system engineering support required.
4.2.2 Software
Define the specific software development processes to be used. Define the types of system engineering support required.
4.2.3 Mechanical
Define the specific mechanical engineering development processes to be used. Define the types of system engineering support required.
4.2.4 Process Development
Describe the methods by which program processes will be monitored and improved. Consider the impact on systems engineering and other processes.
4.3 Trade Studies
4.3.1 Trade Study Process
Describe the process to be used in performing trade studies. Consider trade matrix formats, depth of analysis, and types of information. Describe how to handle multi-dimensional interdependencies.
4.3.2 Trade Study Tasks
Identify the major system trade studies to be performed. Indicate the issues and constraints, including interdependencies. (I highly recommend an N-Squared diagram be included here or linked to. See previous posts on N-Squared diagrams.)
4.4 Requirements Allocation
Describe the unique processes to be used to allocate requirements to system components. Use standards as a reference, and do not restate the processes therein.
4.5 Design Optimization/Effectiveness
4.5.1 Analysis Methods and Tools
Describe the mathematical, simulation, and/or prototyping methods to be used to optimize the design and measure its effectiveness. Define how these methods will be used to impact the design, in which phases. Identify the specific tools to be used. Describe how to handle multi-dimensional interdependencies.
4.5.2 Design Analyses
Identify the specific analyses, simulations, and/or prototypes that will be developed. Identify when each analysis will be performed, and by which personnel. Identify the issues and constraints on each, including interdependencies. Identify the results anticipated from each. Include technical and cost analyses. Consider the following possible types of analysis:
Performance Analysis (Throughput, Latency, Dynamic Range, Bandwidth, Memory, etc.)
Logistic Support Analysis
Life Cycle Cost
Design to Cost
Design for Manufacturability
Design for Test
Producibility
4.6 Documentation (Additional recommendations for defining documentation are given below in the section titled Information Architecture.)
4.6.1 Specification Tree
Show a hierarchical diagram of the specifications that will be created for the system and its elements. Identify the type of each specification. Indicate which specifications are internal and which must be delivered. (Replace the specification tree with a document tree for a more complete description.)
4.6.2 Other Documents
List other documents that will be created. Indicate which documents are internal and which must be delivered.
4.6.3 Document Generation Methods
Describe the methods to be used to generate documents. Identify the specific tools, and their required interconnections. Describe the review and sign-off process.
5.0 ENGINEERING SPECIALTY INTEGRATION
5.1 Control of Engineering Specialties
Describe the integration and coordination of the various engineering specialties in each system engineering phase. Indicate how system engineering controls achieve the best mix of technical/performance values. Where the specialty programs overlap, define the responsibilities and authorities of each.
5.2 Integrated Logistics Support Plan
Summarize the approach to Integrated Logistic Support (ILS). Refer to a separate ILS Plan, if available. Consider the aspects of Logistic Support Analysis, Provisioning, and Training. Indicate the information needed by ILS and its source and time of need. Indicate the expected results and when.
5.3 Reliability/Maintainability/Availability Plan
Summarize the approach to Reliability/Maintainability/ Availability (RMA) analysis and control. Refer to a separate RMA Plan or plans, if available. Indicate the information needed by RMA and its source and time of need. Indicate the expected results and when.
5.4 Safety Plan
Summarize the approach to safety analysis and control. Refer to a separate Safety Plan, if available. Indicate the information needed by safety engineers and its source and time of need. Indicate the expected results and when.
5.5 Human Factors Engineering Plan
Summarize the approach to human factors analysis and control. Refer to a separate HFE Plan, if available. Indicate the information needed by human factors engineers and its source and time of need. Indicate the expected results and when.
5.6 Security Plan
Summarize the approach to security analysis and control. Refer to a separate Security Plan, if available. Indicate the information needed by security engineers and its source and time of need. Indicate the expected results and when.
5.7 Electromagnetic Effects Plan
Summarize the approach to electromagnetic effects analysis and control. Consider EMI, EMC, and TEMPEST as appropriate. Refer to a separate plan, if available. Indicate the information needed by electromagnetic effects engineers and its source and time of need. Indicate the expected results and when.
5.8 Value Engineering Plan
Summarize the approach to value engineering analysis and control. Refer to a separate plan, if available. Indicate the information needed by value engineers and its source and time of need. Indicate the expected results and when.
5. X (Other Plans)
(Describe other applicable specialty plans and programs such as: Test & Evaluation Master Plan; Quality Assurance; Nuclear Survivability; and Parts Control)
No comments:
Post a Comment