open doc documentAEROSPACE REPORT NOTOR2005(8583)3

1、aerospace report no. tor-2005(8583)-3 systems engineering 15 april 2005 edited by l. w. pennell sparta, inc. f. l. knight corporate chief architect/engineer systems planning and engineering prepared for space and missile systems center air force space command 2430 e. el segundo boulevard los angeles

2、 air force base, ca 90245 contract no. fa8802-04-c-0001 systems planning and engineering group approved for public release; distribution is unlimited. aerospace report no. tor-2005(8583)-3 systems engineering prepared by l. w. pennell sparta, inc. f. l. knight corporate chief architect/engineer syst

3、ems planning and engineering 15 april 2005 systems planning and engineering group the aerospace corporation el segundo, ca 90245-4691 prepared for space and missile systems center air force space command 2430 e. el segundo boulevard los angeles air force base, ca 90245 contract no. fa8802-04-c-0001

4、approved for public release; distribution is unlimited. note this tor contains a new draft version of military standard 499, systems engineer- ing. it incorporates suggested revisions to the mil-std-499 and the “b” revision to that document, which was never officially released. it was prepared by an

5、d smc team that included aerospace, government, setas, and independent consultants. this draft has had only limited review by smc spos and industry. this draft is being published at this time to support near-term smc acquisitions with the intent of using it as a compliance standard. the goal is to r

6、eissue this draft standard as an smc standard. prior to that, further review by smc organizations, discussions with industry, and coordination with other agencies such as the nro and nasa are planned. acknowledgments the mil-std-499c is the result of contributions received from many individuals from

7、 a wide spectrum of technical disciplines. the names and organizations of the principal contributors, or those acting as the focal point of contact for their organiza- tions, are listed below. aerospace: michael fabrizibusiness and operations analysis subdivision gerard fishernational systems engine

8、ering/architecture al hohebthe aerospace institute thanh hoangspace architecture department joe meltzeroffice of chief engineer/architect susan ruthground systems development and operations department external: bill crabtreeindependent consultant david davis u.s. air force - smc/ax jerry lakesystems

9、 management international barry portnerinnovative systems engineering services, inc. not measurement sensitive mil-std-499c revised 24 march 2005 superseding mil-std-499b 6 may 1974 military standard systems engineering amsc area misc distribution statement a. approved for public release; distributi

10、on is unlimited. mil-std-499b 2.70 draft foreword this standard is approved for use by all departments and agencies of the department of defense (dod) and may be used by other government and commercial organizations. send comments and pertinent data for improving this standard to hq smc/axem, 2420 v

11、ela way, los angeles, ca 90245 or email to dave davis at . this standard captures the key aspects of dod policy to be included in the next revision of the dod 5000 series as well as the national security space acquisition policy (nssap) 03-01 guidance to apply a robust sy

12、stems engineering approach that balances total system performance and total owner- ship costs within the family-of-systems, systems-of-systems context. this standard defines the gov- ernment requirements for an executable contractor systems engineering process and required systems engineering effort

13、s to assist in defining, performing, managing, and evaluating systems engineering efforts in defense system acquisitions and technology developments. the scope of systems engineering is defined in terms of what should be done, not how to do it. the requirements in this standard, includ- ing those fo

14、r systems engineering management, are defined in terms of the required systems engi- neering products and the required attributes of the products. this standard provides a reference to the government for analyzing competing contractor proposals and for evaluating the contractors systems engineering

15、program once on contract. the government will perform initial tailoring of this standard to address appropriate program scope, appropriate pro- gram size, and progress within the acquisition life cycle. the standard and tailoring, if any, will be part of the draft and final requests for proposal (rf

16、p) along with instructions for contractors to per- form further tailoring as part of their proposal submittals. this standard provides the technical foundation for integrating product and process development. this requires the simultaneous development of system products and life-cycle processes to s

17、atisfy user needs; multidisciplinary teamwork; and a systems engineering process (sep). the integrated master plan (imp), the systems engineering management plan (semp), and/or other plans or policies, to the extent required by the rfp and contract, describe the implementation of these by each contr

18、actor organiza- tion with technical responsibilities. the imp/semp/sep and/or other systems engineering plans and policies required by the rfp and contract are intended to coordinate, integrate, and execute all technical aspects of the program in accordance with the requirements of this standard. th

19、is standard governs the conduct of a complete, integrated technical effort (systems engineering), not the organizational entity or method of implementation. the organization of resources employed to implement this standard is expected to vary from one program implementation to another. this standard

20、 integrates the entire technical effort. this includes requirements from other standardi- zation documents selected for contractual implementation, but does not replace them. each program implementation will employ other standards to satisfy program requirements and to comply with dod policy. it is

21、the program managers responsibility to select and tailor those standards, which are nec- essary to execute the program successfully. this standard must be conscientiously tailored to ensure that only necessary and appropriate require- ments are cited in defense solicitations and contracts. tailoring

22、 guidance can be found in mil-hdbk- 248, acquisition streamlining, and in paragraph 6.3 of this document. table of contents 1. scope.7 1.1document purpose.7 1.2responsibility for success.8 1.3systems engineeringconcept.8 2. reference documents.11 2.1order of precedence.12 3. acronyms and definitions

23、.13 4. general requirements.15 4.1system engineering process application.16 4.2systems engineering requirements.16 4.2.1requirements analysis and validation.16 4.2.2functional analysis, allocations, and validation, or logical solution representation definition and assignment and validation.20 4.2.3s

24、ystem product technical requirements analysis and validation.22 4.2.4design or physical solution representation .23 4.2.5assessments of system effectiveness, cost, schedule, and risk.25 4.2.6design or physical solution verification and validation .28 4.2.7tradeoff analyses .33 4.2.8management of the

25、 systems engineering process.33 4.2.9application across the life cycle.41 4.3systems engineering output.45 4.3.1decision database.45 4.3.2specifications and baselines .46 4.3.3requirements traceability matrix.47 5. detailed requirements.49 5.1functional tasks (specialty functions) .49 5.1.1integrate

26、d logistics support (ils).49 5.1.2manufacturing/producibility .50 5.1.3parts, materials, and processes (pmp) control.50 5.1.4quality assurance .51 5.1.5reliability and maintainability.52 5.1.6survivability.52 5.1.7 environmental, safety and health (es it is equally applicable to civil and commercial

27、 developments. it is thus a compliance document to be applied to performing activities in system acquisitions. performing activities are generally private contractors or subcontractors engaged by the government to design and produce, but sometimes also to operate, maintain, and dispose of weapon sys

28、tems, information systems, software systems, command and control and c4i systems, intelligence systems, and other materiel systems. this standard is primarily intended to define requirements for performing activities; tasking activities will also use it as a guide to assist in systems engineering pl

29、anning and management. tasking activities will generally be agencies responsible for acquiring, operating, and maintaining systems and families of systems. this standards objectives are defining the minimum essential work products, produced in the sys- tems engineering process, needed to: (1) adequa

30、tely define a system over its life cycle such that the integrated system, when deployed, provides at least the threshold or minimum needed capabilities and is affordable, but otherwise balances capability, cost, schedule, risk, and the potential for evolutionary growth. the system is defined by oper

31、ations concepts, operational capabilities/ requirements, system architectures, specifications, drawings, technical orders, training documents, maintenance facilities and equipment documents, test plans and procedures, and other documents that are essential to build-to, buy-to, code-to, verify-to, de

32、ploy-to train-to, operate-to, support/sustain-to, and dispose-to over the system life-cycle. the system definition products satisfying this objective are referred to as the system configu- ration baseline. (2) define clear-cut intermediate development stages to be used by the tasking and perform- in

33、g activities to plan, monitor, and control the progress over each phase and contract of the system acquisition program such that the first objective is achieved effectively and efficiently. the intermediate development stages are defined in terms of the increasing accuracy and completeness of three

34、preliminary results called the requirements, allocated, and design release baselines. the development stages are then defined in terms of the maturity of each of these baselines at key technical reviews and audits. 1.2responsibility for success the government is responsible for the system acquisitio

35、ns success. this responsibility cannot be assigned or delegated to the contractor or to any other organization. the contractor is responsible for executing to terms and conditions, performance requirements, and service-level agreements as specified in the contract or memorandum of understanding by w

36、hich the contractors services were acquired. 1.3systems engineeringconcept systems engineering (se) is an interdisciplinary approach encompassing the entire set of scientific, technical, and managerial efforts needed to provide a set of life-cycle balanced system solutions that satisfy customer need

37、s. throughout this standard, “balanced” refers to system requirements and/or the corresponding design for which the capabilities to be provided, cost, schedule, risk, and potential for evolutionary growth have been assessed and found to be acceptable in the context of the program that is to satisfy

38、the requirements. the se process is an iterative, disciplined method that includes requirements analysis, requirements allocation, design synthesis, and technical management proc- esses. this process takes place over the entire life cycle, from needs definition to system disposal and applies to all

39、levels of acquisition from systems of systems (sos) to individual platforms, systems, subsystems and components.1 system success is dependent on the extent to which these systems sat- isfy their stakeholders needs, are affordable, are acquired on time, work with other systems in a coherent family of

40、 systems, and can be changed over time to meet changing requirements. stakeholders consist of (1) all individuals and organizations whose mission success is enabled by the capabilities embodied in the systems, and (2) all individuals and organizations responsible for system operations and maintenanc

41、e. both the tasking organization and the performing organizations perform the systems engineering process and activities. together they must manage requirements, including managing change, so that stakeholders needs are always reflected in the most recent requirements baseline. the focus of this doc

42、ument is on the requirements for the contractor but information is provided to assist the government. systems engineering is thus a disciplined acquisition approach that requires identifying stakeholder requirements to a level of detail sufficient to design and build the system, to make trades betwe

43、en alternative means of satisfying these requirements, to select the tradeoff alternatives that balance performance, cost, schedule, risk, and potential for evolutionary growth, and to identify the interfaces (both internal to the system and external to it) necessary so that the system or family of

44、systems can achieve success. it is vitally important that systems engineering be approached as the discipline guiding all acquisition activities, and not as a compliance afterthought. systems engineering defines a trade space, the set of possible solutions to stakeholder needs. the government should

45、 ensure that (1) a wide enough trade space is defined so that real tradeoff deci- sions can be made; and (2) the specific design, which includes the hardware and software needed to achieve a solution, is left to the contractor. there are two systems engineering perspectives. both are needed to help

46、ensure successful systems acquisitions. the first is that of a series of discrete steps occurring sequentially over time. here, 1 air force instruction 63-xxx (draft), 05 january, 2005, disciplined systems engineering process work products are successively refined through various control gates, such

47、 as technical reviews or acquisition phases. the second perspective is that a set of technical activities that occur throughout the entire life cycle. this set includes requirements analysis, verification and validation, test, and synthesis. further, these activities must address the system function

48、s needed for the systems development, operation, mainte- nance, and, eventually, disposal. the technical activities set thus pertains to the process of designing and implementing a system. the system functions, which must be addressed by the technical activi- ties, pertain to the product itself. whi

49、le this technical activities set is performed over the life cycle, the relative importance of each of the activities will vary, as will the produced work products. early on in the life cycle, for example, requirements analysis will be emphasized more heavily than test, and the work products produced

50、 will consist of high-level operational architectures. on the other hand, later in the life cycle, during detailed design, the importance of test relative to other activities will increase. the output work products produced will likely be detailed specifications at the subsystem level. through succe

51、ssive iterations of the systems engineering process, the system will be decomposed into subsystems. some of these, in turn, will be further decomposed into lower-level subsystems. for each system or subsystem so defined, the technical activities set will be performed to (1) translate the input requi

52、rements and architectures into a build-to specification (the allocated baseline), or (2) define the inputs to yet another, lower-level set of subsystems. systems engineering thus provides an effec- tive means to deal with the modern systems complexity. an intractably complex problem is trans- formed

53、 into a succession of smaller problems. these are, in turn, transformed into still smaller prob- lems. this process continues until a hardware and software solution can be implemented. throughout this iterative process, the technical activities outputs, the work products for the systems and subsyste

54、ms, must be integrated and reviewed at the control gates occurring at discrete points in time. these reviews ensure that time and budget are being well spent, and that progress is sufficient to ensure that the required capabilities will be delivered in a timely and cost-effective manner. thus, a dis

55、ciplined acquisition approach is achieved. the work products are matured over control gates, as those provided by acquisition phases. the systems engineering technical activities (requirements analysis, functional analysis/allocation, synthesis, and systems analysis and control) span all control gat

56、es. and, these technical activities must address all functions needed across the systems life cycle. tailoring the systems engineering process is achieved by deciding (1) what control gates and (2) how far to decompose the system and, thus, how many iterations of technical activities are needed for

57、suc- cessful system acquisition. for example, a relatively simple system (e.g., a single black box to be installed on a weapon system) will likely require fewer decomposition levels and technical activity iterations than would the whole weapon system. likewise, a purely software system would likely

58、have different control gates than would a hardware and software system. systems engineering supports the dod acquisition process, as codified in dodd 5000.1, the dodi 5000.2, the cjcsi 3170, the nssa 03-01, directive 7 and related documents. these documents: shift from a requirements to a capabiliti

59、es basis for designing system; (2) insist that systems function together, as well as separately; and (3) explicitly recognize that systems must be changed over time to meet changing needs. 2. reference documents the following documents are referenced in this standard (the reference numbers do not im

60、ply order of precedence): (1) national security space acquisition policy 03-01, 27 december, 2004 (2) department of defense directive 5000.1, may 12, 2003, /darc/darc.html. (3) operation of the defense acquisition system, dodi 5000.2, may 12, 2003 (4) joint capabilities integration