《AIAA-G-043-1992.pdf》由会员分享，可在线阅读，更多相关《AIAA-G-043-1992.pdf（38页珍藏版）》请在三一文库上搜索。
1、IW Ob95534 O002082 Ob8 Special Copyright Notice I992 by the American Institute of Aeronautics and Astronautics. All rights reserved. Copyright American Institute of Aeronautics and Astronautics Provided by IHS under license with AIAA Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resal
2、e, 04/18/2007 09:18:26 MDTNo reproduction or networking permitted without license from IHS -,-,- A I A A G-043 92 m Ob95534 0000527 9T5 = ANSVAIAA G-043-1992 Guide for the Preparation of Operational Concept Documents Copyright American Institute of Aeronautics and Astronautics Provided by IHS under
3、license with AIAA Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/18/2007 09:18:26 MDTNo reproduction or networking permitted without license from IHS -,-,- A I A A G-OY3 92 W Ob95534 0000528 831 = ANSVAIAA G-043-1992 American National Standard Guide for the Preparation of Op
4、erational Concept Documents Sponsor American Institute of Aeronautics and Astronautics Approved January 22,1993 American National Standards Institute Abstract Military and NASA standards require that information that relates t o system o p e r a t i o n a l concepts be prepared in support of the spe
5、cification and development of systems. There are Data Item Descriptions IDS) which describe the format and content of the information. This AIAA Guide describes which types of information are most relevant, their purpose, and who should participate in the effort. It also provides advice regarding ef
6、fective procedures for generation of the information, and how to document it. Finally, this AIAA Guide provides an example of how the described process was applied to support the development of a major system within NASA. Copyright American Institute of Aeronautics and Astronautics Provided by IHS u
7、nder license with AIAA Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/18/2007 09:18:26 MDTNo reproduction or networking permitted without license from IHS -,-,- A I A A G-O43 92 Ob95534 O000529 778 ANSVAMA G#3-1992 Approval of an American National Standard requires verificat
8、ion by ANSI that the require.mens for due process, camsus, andocheraiteriahavebeen met by the standards Consensus is established when, in the judgement ofthe ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected interess. Substantial agreement mea
9、ns much more than a simple majority, but not necesserily Unanimity. Consensus requires that all views and objections be considered, and that a coeffoItbemadetowaKltheresolutian. American National Standard developer. The use of American Naional Standards is completely v01untary;theU existenOe doesna
10、in any respect preclude anyone, whether he has appved the standards or n o t , from manufacturing, marketing, purchasing, or using products, processes, or procedures not conforming to the standards. The American National Standards Institute does not develop standards and will i n no circumstances gi
11、ve an inteqretation of any American National Sandard. Moreover, no person shaii have the right or authority to issue an intg-tatiOn of an American N a t i o n a l Standard in the name of the American National Siandards Institute. Requests for interpretations should be addressed t o the secretariat o
12、 r sponsor whose name appears on the titie page of this standard. CAUTION NOTICE This Amencan National Standard may be revised o r Withdrawn a t any time. The procedures of the American National Standards Institute quire that action be talren t o affirm, revise, or withdraw this standard no i a t e
13、r than five years fhm the data of approval FWchasers of American National Standards may receive current information on all standards by calling or writing the American National Standards Institute. Guide for the preparation * ofopeiationalconcepts/sponsar, p. cm. American institute of Amnautics and
14、Astronautics ; approved, AmericanNatiodStandardsInstitute. At head of title: American National Stanard. inclrades bibliogqhid references. EiecmNc data pmxssing documenWon-Standards. “ANSI/AIAA, G-043-1992.“ ISBN 1-56347450-0 I. American Institute of Aenmautics and Astronautics. Ii.American National
15、Standards Institute. QA76.9-85 1993 004.2lm i.e., a subsystem of a large system may itself possess all of the attributes of a system. For this reason, this technique should be applied at these levels as well, resulting potentially in several OCDs of different levels of detail within a given system.
16、2.2.2 Perspectives of OCD Application 2.2 . 2.1 An CD communicates to system developers and users, in the users language, the desired characteristics of a system t o be developed. To do so, two different categories of informaion must be provided. These are: perational system charactens tics, System
17、constraints and limitations, Relevant customer / developer policies and organizations, External interfaces, Extemal requirements (Le., changes t o ex- isting internal elements that are necessary for the proposed system to correctly interface and function), and User organization (e.g., functions, re-
18、 sponsibilities, capabilities, and interfaces). 2.2.2.1.1 The System Context, which consists oft Mission objectives including rationale, Overall operational philosophies, 2.2.2.1.2 A useis opemional view which contains b o t h static and dynamic views of the proposed system with the delivered opera-
19、 tional characteristics and constraints. It p n vides the rationale behind the proposed sys- tem and should consist of at least: Copyright American Institute of Aeronautics and Astronautics Provided by IHS under license with AIAA Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 0
20、4/18/2007 09:18:26 MDTNo reproduction or networking permitted without license from IHS -,-,- A I A A G-043 92 m OS95534 O000536 908 m Mission description, perational environment, Support environment, Envelope of system capabilities and con- straints (in users terminology), and A set of operational s
21、cenarios (a dynamic view of the system in operation, again with emphasis on the users point of view). 2.2.2.2 The OCD provides a mechanism to trigger questions and raise issues regarding user-related requirements / design trades. The OCD can serve in a number of ways. Three major ways are: Act as a
22、catalyst to stimulate the develop- ment of complete, consistent, testable re- quirements and designs with emphasis upon those attributes that shape the user- related elements of the system; Provide guidance for the development of the subsequent system definition docu- mentation (e.g., functional sys
23、tem specifications, and interface control draw- ings); and Form the basis for long range operational planning activities (i.e., staffing, facilities, training, security, safety, and logistics). The OCD does not contain specific imple- mentation or design-dependent constraints. 2.3 Intended Audience
24、The information in an OCD is intended for communication and understanding between several key players. These players and the specific uses that each w i l l make of an OCD: 2.3.1 Users / Operators / Maintainers use the OCD for: Planning, organizational, operational, and logistical support aspects, i
25、ncluding available resources; Technical attributes concerned with hu- man-machine interfaces and interactions, inter- and intra-system hardware and software interfaces, components, locations, sequences, functions, and requirements; Philosophies and policies regarding local and depot maintenance leve
26、ls, operational constraints related to maintenance, accessi- bility of the system, and maximum acceptable downtimes; and Early definition of user constraints, capa- bilities, operating procedures, resources, responsibilities, and user / system integration for use by the development community. 2.3.2
27、System Engineers and Architects use the OCD as a framework to: Facilitate development team understanding of the mission needs and as a basis for comparing alternative system designs; Establish the system context, as defined above, to include a description of inter- facing system structure; Enable un
28、derstanding of mission objec- tives and priorities with the rationale be- hind them; and Determine relationships of relevant evel- opment and user Organizational strucaiies. 2.3.3 System Implementors use the 0 to provide: A brief overview of the system context with emphasis on the objectives and con
29、- straints along with operational issues such as logistics, facilities, standards, timelines, and end-to-end information flows; Understanding of the rationale for system objectives; and Insight into the role of the proposed system with respect to interfacing systems and its place in the overall envi
30、ronment. 2.3.4 Customers and Buyers use the OCD to: 3 Copyright American Institute of Aeronautics and Astronautics Provided by IHS under license with AIAA Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/18/2007 09:18:26 MDTNo reproduction or networking permitted without licen
31、se from IHS -,-,- A I A A G-043 92 Ob95534 O000537 844 Facilitate undersiandhg of mission objec- tives, system gods, constraints, and exter- nalin-agnements: Form a basis for system acceptance cri- teria; Understand optional philosophies to fa- cilitate appropriate test focus (e.g., effdve use of op
32、tional sequences and d a t a ) ; and Understand the operational attributes of external interfaces to ensure thorough testing o f the associated system elements. 2.3.6 Customer and Developer Organization Management use the OCD 00: Focus on the system context with em- phasis on mission objectives and
33、system goals, policies and philosophies, and constraints; and Facilita MIL-STD-483A, Configuration Management Practices for Systems, Equip- ment, Munitions, and Computer Programs; MIGSTD-49oA, Specification Practices; and MIL-STD-l521B, Technical Reviews and Audits for Systems, Equipments, and Com-
34、puter Programs. Within the associate set of DIDs far DoD-STD-2167 was a DID entitled, Operational Concept Document, the purpose of which was to describe the mission of the system, its operational and support environ- ments, and the functions and characteristics of the computer system within the over
35、all system. During a revision of DoD-STD- 2167 (DoD-STD-2167A, February 1988), the Operational Concept Document was dropped in favor of some operational concept information appearing in a System / Segment Design Document. Also in this time frame, a Concept Data Item Aeronautics and Space Administrat
36、ion prod- uct Specification Document Standards. Within the Federal Aviation Agency (FAA), 026. The 00, however, was not dropped. It is still required by the FAA and is typically developed at more than one level within a system (e.g., system and sub-system levels). The Operational Concept Document is
37、 con- DoD-STD-2167A was adopted as FAA-STD- 2 EEE computer Society pres tori ri ai, “system and Software Engineering“ by R. H . Thayer and M. Dorfman. sidered by the American Institute of Aeronau- tics and Astronatics (AIAA) Software Sysm Committee on Standards to be a very impor- tant document. Dev
38、elopment of a set of 0 0 s and related scenarios at each appropri- ate level in the system hierarchy should be- come a planned a c t i v i t y of any development life cycle, with OCDs and scenarios define as specific life cycle products. 4.0 CONTENTS OF A PRACTICAL OCD 4.1 Overview Based on the prev
39、iously-defied users, the OCD must be somewhat all things to all peo- ple because the intended audience has a w i d e range of technical and managerial back- grounds. At the same time it must remain readable and understandable. The most prac- tical way to achieve this goal is t o write the OCD in a n
40、arrative farm describing, in non- specification-type prose, the way in which the system is envisioned to fit and function within the proposed o r expected operational environment. Graphics, functional f l o w dia- grams and timelines should be used to the maximum extent feasible because these vi- su
41、al, pictorial representations significantly enhance the communication of information, particularly to such a wide and varied audi- ence. 4.2 Content i n view of the preceding, a good CD should tell a story; that is, it should be a namative, pictorial description of the systems intended use. The need
42、 to enhance the value of the OCD to different populations through clear, concise information is shown conceptually in Figure 2. This can be accomplished by describing the What, Where, When, Who, Why, and How of the system operations. These are sum - asfollows: Whats: These are the known components o
43、 r elements and top level capabilities required of the system, at its highest level of abstraction, to perform the necessary functions. The components are described from an opera- tional point of view. Necessary mission 5 Copyright American Institute of Aeronautics and Astronautics Provided by IHS u
44、nder license with AIAA Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/18/2007 09:18:26 MDTNo reproduction or networking permitted without license from IHS -,-,- A I A A 6-043 92 m Ob95534 0000539 bL7 m ANSIjAIAA G-043-1992 g- E 4 - . I .I c 5! e . V Li i e . O i e . ce O Y C
45、 . I 2 VI Li V - 5 o Y E e cr Copyright American Institute of Aeronautics and Astronautics Provided by IHS under license with AIAA Licensee=IHS Employees/1111111001, User=Wing, Bernie Not for Resale, 04/18/2007 09:18:26 MDTNo reproduction or networking permitted without license from IHS -,-,- A I A
46、A G-043 92 Ob95534 O000540 339 phases o r modes may also be described here. Wheres: These are the environments, such as geographical and physical locations of customers facilities and interfacing systems, within which the capabilities are required tobe pedormed and supported. W hens: These describe
47、activities, tasks, flows, precedence, concurrencies, and other time / sequence-related elements necessary to achieve the mission objectives in each of the various mission modes and conditions. W hos: These describe the interactions among the various human elements within the system including their i
48、nterfaces with people external to the system. The CD and related scenarios should also identify decision points to include who (title) has authority to make those decisions. Whys: These provide the rationale, when not obvious or when it would benefit reader understanding, behind any established parti- tioning of the mission tasks between the sys- tem components and the operators, and the reasoning for specific sequences of activities or tasks. For example, an important function of an OQ) is to provide the rationale behind the definition of the l