《GEIA-EIA-731.1-2002.pdf》由会员分享，可在线阅读，更多相关《GEIA-EIA-731.1-2002.pdf（140页珍藏版）》请在三一文库上搜索。
1、EIA STANDARD Systems Engineering Capability Model EIA-73 1.1 (Formerly EMS-731.1) AUGUST 2002 ELECTRONIC INDUSTRIES ALLIANCE GOVERNMENT ELECTRONICS AND INFORMATION TECHNOLOGY ASSOCIATION Copyright Government Electronics (b) acquirers of systems; (c) university professors, organizational trainers, an
2、d consultants; and (d) developers of other maturity or capability models. Use is not limited to specific disciplines, industry sectors, or technology domains. This Standard may be tailored for a specific domain, organization, or program. This Standard is intended to neither specifj nor encourage the
3、 use of any particular implementation method or tool. The using organization is responsible for selecting those methods or tools necessary to support the objectives of the organization and program, and to define and implement engineering policies and procedures. Annexes A and B are normative. Normat
4、ive annexes are integral parts of the standard that, for reasons of convenience, are placed after all other normative elements. The fact that an annex is normative is made clear by the way in which it is referred to in the text, by a statement to the effect in the foreword, and by an indication at t
5、he head of the annex itself. Annexes Cy Dy and E are informative. Informative annexes, formerly called appendices, give additional information and are placed after the normative elements of a standard. They do not contain requirements. The fact that an annex is informative is made clear by the way i
6、n which it is refered to in the text, by a statement in the foreword, and by an indication at the beginning of the annex itself . 111 Copyright Government Electronics the current release of the SECAM Assessment Method is Version 1.50, dated July 1997. In January 1994, the EPIC (then called Industria
7、l Collaboration) began generating the Capability Maturity Model (CMM) for Systems Engineering (SE-CMM) and completed it as an initial release, Version 1.0, in December 1994. Version 1.0 of the SE-CMM Appraisal Method was released in June 1995. Following the initial release, one update was made to bo
8、th the EPIC SE-CMM and the SE-CMM Appraisal Method. The current release of the EPIC SE-CMM is Version 1.1 , dated November 1995; the current release of the SE- CMM Appraisal Method is Version 1.1 , dated 1996. In March 1996, an effort was initiated under the auspices of the EIA G-47 (Systems Enginee
9、ring) Committee to merge the current versions of the INCOSE SECAM and its Assessment Method with the current versions of the EPIC SE-CMM and its Appraisal Method. The resulting EIA Systems Engineering Capability Model (SECM) and SECM Appraisal Method will be proposed as a US national standard for th
10、e measurement and improvement of systems engineering capability. 1.2 Benefits Associated with the Use of this Standard Proper implementation of this Standard is intended to improve the capability to perform systems engineering. Improved capability enables an organization to: Reduce cycle time from c
11、oncept to deployed system products; Improve the match of deployed system product capability with stakeholder requirements; Reduce total ownership cost of system products; Reduce the number of engineering changes; Improve system quality; Improve communications among personnel involved in the engineer
12、ing of a system; Improve ability to sustain and upgrade system products after deployment; and Reduce development risks. By proper implementation, it is meant that: a) b) c) Processes, activities, and tasks of this Standard are appropriately tailored (see Annex A and EIA-73 1-2, EIA SECM Appraisal Me
13、thod); Skilled personnel are used to accomplish the purpose of this Standard as tailored; Users of this Standard have training and familiarity with the usage of this Standard. Copyright Government Electronics simple or complex; software intensive or not; precedented or unprecedented. It applies to s
14、ystems that may contain hardware, software, personnel, facilities, data, materials, services, or techniques. This Standard is applicable to the engineering of a new system or the reengineering of a legacy system, or portions thereof. This Standard is intended solely to be used for self-development,
15、self-improvement, and self-appraisal. Organizations should not apply this Standard to suppliers as a means of source selection or as a means of qualification to be a supplier. 2.4 Limitations This Standard is not intended to specifj the details of “how to” implement process activities. It does not s
16、pecifj the methods or tools a developer would use to accomplish required activities. The developer will select methods, techniques, and tools that are consistent with program or organization needs, directives, and procedures. Adherence to this Standard shall be entirely voluntary and within the disc
17、retion of individual organizations. This Standard does not prescribe the name, format, content, or structure of documentation. Throughout this Standard, the terms “document” or “documentation” are used to mean a collection of data regardless of its medium. This Standard is, to a large extent, a proc
18、ess-based systems engineering capability model. Process maturity indicators were developed first because they were deemed easiest to develop and had received the most attention in other efforts, e.g., IS0 initiatives, and other disciplines, e.g., software. This Standard also includes non-process ind
19、icators of systems engineering capability. These non-process indicators represent high leverage characteristics of systems engineering capability. Copyright Government Electronics a sixth, and lowest, level of capability is a default level that contains no questions. The numbering of each FA indicat
20、es the Category to which it belongs, as follows: TC 1.0 Systems Engineering Technical Category FA 1.1 Define Stakeholder and System Level Requirements FA 1.2 Define Technical Problem FA 1.3 Define Solution FA 1.4 Assess and Select FA 1.5 Integrate System FA 1.6 Verify System FA 1.7 Validate System T
21、C 2.0 Systems Engineering Management Category FA 2.1 FA 2.2 FA 2.3 FA 2.4 FA 2.5 FA 2.6 FA 2.7 FA 2.8 Plan and Organize Monitor and Control Integrate Disciplines Coordinate with Suppliers Manage Risk Manage Data Manage Configurations Ensure Quality TC 3.0 Systems Engineering Environment Category FA
22、3.1 Define and Improve the Systems Engineering Process FA 3.2 Manage Competency FA 3.3 Manage Technology FA 3.4 Manage Systems Engineering Support Environment Copyright Government Electronics use of formal and informal reviews and audits; as well as the system and test equipment being developed. Inc
23、remental verification requires that the developer be capable of managing multiple configurations of systems, products, and documentation. Typical Work Products: 0 0 0 Results of system verification 0 Demonstrations Results of work product verifications Results of subsystem and component verification
24、s Specific Practices: SP 1.6-3-la SP 1.6-3-lb SP 1.6-3-2a SP 1.6-3-2b SP 1.6-3-2c SP 1.6-3-2d Perform re-verification of corrected deficiencies and changed requirements and designs. Inspect implemented, purchased, and reused components to verify they meet requirements. Test new and unproven designs
25、(Le., highest risk) at the lowest assembly level to verify their compliance with established requirements early in the development life cycle. Review the incremental verification results vis-vis requirements with key stakeholders on an on-going basis. Verify system, subsystem, and work products agai
26、nst requirements established in an earlier phase. Perform incremental verification on systems, subsystems, and work products. 1.6-4 Analysis and Actions Description: Verification activities are executed, and the resulting data are collected and analyzed against the defined verification criteria. Rep
27、orts state verification results in terms of the system requirements, indicating whether or not requirements were met and, in case of deficiencies, assessing the degree of success or failure, categorizing causes of failure, and indicating what actions were taken as a result. Copyright Government Elec
28、tronics identification, integration and scheduling of all engineering functions and tasks; work breakdown structure (WBS) development; organizational structure definition (as related to the program); and descriptions of, or references to, key policies and procedures. Planning is documented in a tech
29、nical management plan which sometimes references other planning documents. The technical management plan relates the technical requirements to program requirements, providing the structure to guide and control the integration of engineering activities needed to achieve the systems engineering object
30、ives consistent with a top level management plan for the program. The technical management plan addresses planning for three basic areas: 0 0 Systems engineering process, 0 Engineering specialty integration. Technical program planning the tailored process then is incorporated into the program planni
31、ng. Copyright Government Electronics if risks are not identified then analysis and appropriate corrective action cannot be taken. Risk analysis is the process of quantiQing each specific risk; determining the probability of its occurrence and the impact on the program associated with its occurrence;
32、 and developing and analyzing alternative options, backed up by specific recommendations for action. Risk mitigation is the process of avoiding, reducing and controlling, or deliberately accepting risk on the program. In order to be effective, risk management activities need to be communicated to al
33、l affected groups and individuals. Risk management is both a program and technical management process for a program conducted in an uncertain environment. Risk management provides a means of addressing issues which have the potential for causing a specified performance, schedule, or cost requirement
34、 on the program to not be satisfied. Risk management should not be viewed as a separate program office function, but rather as an integral part of sound systems engineering management of the technical effort. In essence, risk management is “a method of managing that concentrates on identiqing and co
35、ntrolling the areas or events that have a potential of causing unwanted change and it is no more and no less than informed management” 2. Risk management is considered a critical systems engineering activity; yet effective risk management is one of the most difficult and elusive tasks 3. The effecti
36、veness of the program risk management effort will be based upon the breadth of experience, depth of system expertise, interface and integration experience, and creativity of the assigned risk manager, program team, and the participants from the line organizations. This will be further influenced by
37、the scope of the charter provided by the program manager, whose support cannot be underestimated for this process to be beneficial and timely. Identification, analysis, and mitigation of risks early in the product life cycle is important because typically 70 percent of life cycle costs are committed
38、, or “locked in”, by decisions made during the expenditure of the first 5 percent of the life cycle cost 4. In each product life cycle phase, early detection of risk is important because it is easier and cheaper to make changes and correct errors than in the middle or the end of that phase 51. Risk
39、management applies to all program sizes with additional considerations taken into account when implementing the process. For instance, the formality depends on the program size, program phase, funds available, program complexity, and maturity of the technology being considered. Small programs may no
40、t need a very formal approach, but regardless of the program size, the approach requires discipline and should include all program suppliers. The risk management approach selected for the Manage Risk Focus Area is oriented about the approach taken to address risks developed by the Defense Systems Ma
41、nagement College (DSMC), which has become widely used within industry. A somewhat useful, but earlier source, on risk management from DSMC is given in 6. Copyright Government Electronics page 3-3; Defense Systems Management College (Fort Belvoir); March 1989. Caver, T. V.; “Risk Management as a Mean
42、s of Direction and Control”; FAPt Sheet Program Managers Notebook; Defense Systems Management College (Fort Belvoir), No. 6.1; April 1985. Systems Engineering Management Guide; page 12-9; Defense Systems Management College (Fort Belvoir); May 1996 (Draft. Systems Engineering Management Guide; pages
43、17- 1 through 17-3; Defense Systems Management College (Fort Belvoir); January 1990. Hudak, G. J., et al., Design to Reduce Technical Risk, page 9, McGraw-Hill, 1993. Risk Assessment Techniques; Defense Systems Management College (Fort Belvoir); July 1983. Themes of Manage Risk: 2.5-1 Risk Managemen
44、t Plan 2.5-2 2.5-3 Risk Quantification 2.5-4 Risk Analysis 2.5-5 2.5-6 2.5-7 2.5-8 Identification of Performance, Cost, and Schedule Risks Development of a Risk Mitigation Strategy Implementation of the Risk Mitigation Strategy Monitoring of Risk Mitigation Action Communication and Coordination of R
45、isk Status and Risk Mitigation Efforts Across Affected Groups Theme Descriptions, Typical Work Products, and Practices: 2.5-1 Risk Management Plan Description: Most programs are guided by an overall, encompassing technical management plan that includes, sometimes by reference, a series of sub-plans.
46、 A risk management plan is an essential part of this suite of sub-plans. The risk management plan should be developed at the beginning of the program and updated as needed throughout the life of the effort. The purpose of a risk management plan is to force an organized approach to the subject of eli
47、minating, minimizing, or containing the effects of undesirable occurrences. The risk management plan should contain the essentials of any plan (see Plan under Glossary), but in addition, address those essential items of the risk effort. Some of these essential items that characterize the risk manage
48、ment effort are the approach to: identiQing, quantiQing, and analyzing risks; developing, implementing, and monitoring the risk mitigation activities; and communicating and coordinating the risk management activities across affected groups. Copyright Government Electronics determining the degree of
49、success of existing risk mitigation actions; developing new options and fall back positions for risk mitigation actions that have not achieved the required effect; and identimng new risks, quantifying and analyzing these risks, and developing and implementing appropriate mitigation strategy(s). Typical Work Products: 0 0 0 Updates to risk ratings 0 0 Updates to risk management plan Updates to list of program risks Updates to risk watch list Updates to cumulative risk probability distribution Specific Practices: SP 2.5-7-3a SP 2.5-7-3b SP 2.5-7-3c SP 2.5-7-4 Monitor and re-evaluate r