GEIA EIA-632-1999 Processes for Engineering a System《工程系统化的过程》.pdf

《GEIA EIA-632-1999 Processes for Engineering a System《工程系统化的过程》.pdf》由会员分享，可在线阅读，更多相关《GEIA EIA-632-1999 Processes for Engineering a System《工程系统化的过程》.pdf（138页珍藏版）》请在麦多课文档分享上搜索。

1、APPROVED: JANUARY 1999 REAFFIRMED: SEPTEMBER 2003 GEIA STANDARD Processes for Engineering a System EIA-632 (Upgrade and Revision of EIADS-632) JANUARY 1999 GOVERNMENT ELECTRONICS AND INFORMATION TECHNOLOGY ASSOCIATION A Sector of the Electronzc Industrzes Allzanc Copyright Government Electronics dis

2、tribution is unlimited. Copyright Government Electronics preparing enterprise standards, policies, and procedures for engineering a system; developing lower-tier industry- or domain-specific process standards; developing process capability and assessment models; establishing terminology and concepts

3、 for better communications; developing training and education curricula; preparing plans for actual development of a product. Use is not limited to specific disciplines, industry sectors, or technology domains. To provide each enterprise with the greatest degree of flexibility for adapting to changi

4、ng environments while maintaining the integrity of adopted processes, this Standard a) limits the set of required processes to those directly related to the technical aspects of engineering systems; b) defines representative tasks associated with each process; c) includes the relevant information fl

5、ows and interactions with enterprise and project entities. This Standard is intended to define “what to do” with respect to the processes for engineering a system. ANSUEIA-73 1, Systems Engineering CapabiliS, provides a capability model and assessment method as a basis and means for determining “how

6、 well” the processes in ANSUEIA-632 are defined and implemented. This Standard is consistent with IS0 9000 in that it provides processes that can be adopted by enterprises for engineering systems. Annex A is normative. Annexes B through G are informative. vii Copyright Government Electronics b) Prod

7、ucts are an integrated composite of hierarchical elements so integrated as to meet the defined stakeholder requirements; c) The engineering of a system and its related products is accomplished by applying a set of processes to each element of the system hierarchy by a multidisciplinary team of peopl

8、e who have the requisite knowledge and skills. The systematic approach of this Standard is applicable for: (1) completing corrective actions, (2) making refinements, (3) developing derivatives, (4) producing modifications, and (5) updating existing products, (6) creating and realizing new systems, a

9、nd (7) allowing for the safe and cost-effective disposal (retirement) of a system. This approach is incrementally applied in an engineering life cycle framework that can be implemented during any one or more phases of an enterprise-based life cycle (for example, during production, operations, suppor

10、t, or disposal). Voluntary Compliance Adoption of this Standard is intended to be entirely voluntary, within the discretion of individual enterprises or other individual organizations. ix Copyright Government Electronics satis% requirements within cost, schedule, and risk constraints; provide a syst

11、em, or any portion of a system, that satisfies stakeholders over the life of the products that make up the system. NOTE-The termproduct is used in this standard to mean: aphysical item, such as a satellite (end product), or any of its component parts (endproducts); a software item such as a stand-al

12、one application to run within an existing system (endproduct); or a document such as a plan, or a service such as test, training, or maintenance support, or equipment such as a simulator (enabling products). d) provide for the safe and/or cost-effective disposal or retirement of a system. 1.2 Covera

13、ge This Standard defmes processes for engineering a system, as shown in Figure 1.2. These have been organized into five groups. (Subclause 4.1) (Subclause 4.2) Acquisition and Supply + Supply Process / + Acquisition Process Technical Management + Planning Process + Assessment Process System Design (

14、Subclause 4.3) Processes for + Control Process + Requirements Definition Process + Solution Definition Process Product Realization (Subclause 4.4) + Implementation Process + Transition to Use Process Tech n cal Eva1 uation (Subclause 4.5) + Systems Analysis Process + Requirements Validation Process

15、+ System Verification Process + End Products Validation Process Figure 1.2-Fundamental processes for engineering a system Copyright Government Electronics any system, small or large, simple or complex, software-intensive or not, precedented or unprecedented; systems containing products made up of ha

16、rdware, software, firmware, personnel, facilities, data, materials, services, techniques, or processes (or combinations thereof); a new system or a legacy system, or portions thereof. NOTE-The specific tasks and implementation methods for applying the processes required by this Standard can vary, fo

17、r example, between commercial and government projects, or between customer- involved and internally developed projects. The fundamental processes, however, are the same in all cases. The requirements of this Standard, or a designated subset, are intended to be applied by establishing enterprise poli

18、cies and procedures that define the requirements for project implementation of the adopted processes of this Standard. The application of this Standard with respect to enterprises and projects is shown in Figure 1.3. Enterprise Project establishes implements Industry Figure 1.3-Application of this S

19、tandard 1.4 Limitations This Standard does not speciSl the details of “how to” implement process requirements for engineering a system. Nor does it spec the methods or tools a developer would use to implement the process requirements. It is intended that the developer select or define methods and to

20、ols that are applicable to the development, and that are consistent with enterprise policies and procedures. This Standard does not prescribe the name, format, content, structure, or medium of documentation. 2 Copyright Government Electronics (2) decide which requirements from this Standard apply fo

21、r the processes selected; (3) establish appropriate policies and procedures that govern project implementation; (4) define appropriate tasks for each of the selected requirements; and (5) establish the methods and tools to support task implementation. Representative tasks, along with their expected

22、outcomes, are provided in Annex C for each requirement of this Standard. NOTES 1 2 3 supplying an end product to another organization, while acquiring subsystems from a third organization. The developer can be an enterprise, a group of enterprises, an organization, or a project. A developer can be e

23、ither an acquirer or a supplier of systems, subsystems, or end products. A developer can act in both roles (acquirer and supplier) simultaneously on the same project, e.g., 5 Copyright Government Electronics and (2) ANSUEIA-649 for configuration management. 4.1 Acquisition and Supply The Acquisition

24、 and Supply Processes are used by a developer to arrive at an agreement with another party to accomplish specific work and to deliver required products, or with another party or parties to have work done and to obtain desired products. The parties can either be inside the developers own enterprise (

25、another project, functional organization, or project team), or can be in a different enterprise. The Acquisition and Supply Processes can be initiated as a result of a project go-ahead or approval decision, or by the receipt of an acquisition request, offer or directive. A project go-ahead can be gi

26、ven within an enterprise as a result of a market-needs analysis, technology breakthrough, a perceived market opportunity, a customer requirement, an internal project directive, or a similar stimulus. NOTE-Although a project or development effort can be initiated by casual means, an agreement is neve

27、rtheless useful to ensure that all parties involved understand the purpose, goals, and expectations of the work. An agreement can be between enterprises and between organizational elements within an enterprise, to include between projects, between projects and functional units, and between units wit

28、hin a project. The agreement within an enterprise can take the form of a work directive, work package, work authorization, or project memorandum of agreement. Agreements between enterprises can take the form of a formal contract for the delivery of a product, or a memorandum of agreement that establ

29、ishes the working relationship between two or more enterprises on a common project. Regardless of the form or purpose of the agreement, certain information should be included, for example: Work to be performed; Cost and schedule constraints; Concept of operations; Requirements to be satisfied, inclu

30、ding known functional, performance, and interface requirements, attributes, and characteristics; Product and data to be delivered; Information pertaining to cost, schedule, planning, delivery information, product structure, packaging and handling instructions, or installation instructions; Appropria

31、te technical plans; Applicable financial structure, management and authority provisions; Exit criteria for relevant enterprise-based life cycle phases; Identification of applicable engineering life cycle phases; Required technical reviews. NOTE-A developer can be developing a product without any con

32、tractual relationship to the user or customer (e.g., commercial product development). However, much of the information above must be available to the developing organization in order to proceed. 6 Copyright Government Electronics (2) determine whether to proceed with an internal enterprise project f

33、or a new product or a product improvement; (3) guide the work efforts that will meet the requirements of an established agreement; or (4) replan applicable processes for engineering a system. Replanning is normally initiated (1) when required by an agreement; (2) when significant variations or anoma

34、lies are identified from other Technical Management process outcomes, or (3) before implementation of the next enterprise- based life cycle phase. The five requirements associated with the Planning Process are shown in Figure 4.2.1. Requirement 4 - Process Implementation Strategy Requirement 5 - Tec

35、hnical Effort Definition Requirement 6 - Schedule and Organization Requirement 7 - Technical Plans Requirement 8 - Work Directives Figure 4.2.1-Planning Process requirements Requirement 4-Process Implementation Strategy The developer shall define a strategy for implementing the adopted processes of

36、this Standard as a basis for project technical planning and that is in accordance with the agreement. 10 Copyright Government Electronics (2) are to be implementable by each product team or product manager; (3) are used in preparing and negotiating an agreement; and (4) influence the developers abil

37、ity to fulfill the other requirements of the Planning Process. The process implementation strategy includes requirements for the processes to be undertaken, applicable constraints, completion criteria, and feasibility of each process, considering resources (personnel, materials, technology) and proj

38、ect execution environment. This strategy can be a part of the project plan or a stand-alone document. Requirement 5-Technical Effort Definition The developer shall define a technical effoi-t that is in accordance with the process implementation strategy. The developer should plan and do the appropri

39、ate tasks to complete this requirement. Tasks to consider include the following: Identi% project requirements to include: agreement requirements; other stakeholder requirements; and enterprise, project, and associated process constraints. Establish an information database that will allow capture of

40、project data and be able to securely retain and make information available, as required. Determine the risk management strategy to identi% technical risks to the appropriate level and properly avert those risks that could adversely affect the project. 11 Copyright Government Electronics b) Risk Mana

41、gement Plan; c) Technical Review Plan; d) Verification Plans; e) Validation Plans; f) Other applicable plans as called for in the agreement or by enterprise policies and procedures. The expected outcomes for the tasks related to developing these plans are provided in Annex C. The outcomes associated

42、 with completing this requirement provide guidance for preparing work directives and completing other applicable project processes for engineering a system. Any plan created should include the scope, tasks, methods, tools, metrics, risks, and resources as applicable to fulfill the purpose of the pla

43、n. NOTE-Annex D of this Standard contains a listing of typical planning documents. Some projects require either more or significantly less documentation. These planning documents can be tailored as to the level and formality of planning to suit project complexity and uncertainty. Requirement 8-Work

44、Directi.es The developer shall create work directives that implement the planned technical effoi-t. The developer should plan and do appropriate tasks to complete this requirement. Tasks to consider include the following: a) Develop individual project team or organization work packages that describe

45、 the work to be done, resource sources, schedules, budget, and reporting requirements. 13 Copyright Government Electronics (2) review progress during technical reviews; and (3) support control of the engineering of a system. The product and process metrics selected for assessing progress should prov

46、ide information for risk aversion, meaningful financial and non-financial performance, and support of proj ect management. NOTE-When variations are sufficiently significant or cannot be corrected by re-accomplishment of the process tasks that generated the outcome data, the Planning Process is re-in

47、itiated in order to implement appropriate corrective actions. The three requirements associated with the Assessment Process are shown in Figure 4.2.2. Requirement 9 - Progress Against Plans and Schedules Requirement 1 O - Progress Against Requirements Requirement 11 - Technical Reviews Assessment Pr

48、ocess Figure 4.2.2-Assessment Process requirements Inputs to the Assessment Process are in the form of technical plans, stakeholder requirements, and engineering outcomes from other processes. The developer should plan and do appropriate tasks to complete this requirement. Tasks to consider include

49、the following: a) Identi% events, tasks, and process metrics for monitoring progress against plans and schedules. b) Collect and analyze identified process metrics data and results from completion of planned and scheduled tasks and events. c) Compare process metrics data against plans and schedule to determine technical areas requiring management or team attention. d) Determine and implement required changes to correct variances, make changes to plan and schedule, and redirect work. 14 Copyright Government Electronics & Information Technology Association Reproduced by IHS under license wi