1、m Ob95534 0003284 BO5 = Special Copy right Notice O 1994 by the American Institute of Aeronautics and Astronautics. All rights reserved. AIAA G-O30 93 m Ob95534 0003532 15T m AIAA G-010-1993 Reusable Software: Assessment Criteria for Aerospace Applications AIAA G-010 93 m Ob95534 0003533 096 m AIAA
2、G-O 1 O- 1993 Guide for Reusable Software: Assessment Criteria for Aerospace Applications Sponsor American Institute of Aeronautics and Astronautics Abstract This AIAA Guide provides a basis for assessing. potentially reusable software. It introduces the concept of domain analysis and describes the
3、principal products of this method. Criteria for assessing the reusability of software down to the component level, along with specific examples are included. A methodology for storing the analyses and criteria and establishing a reuse library are given. AIAA G-O30 93 Ob95534 0003534 T22 AIAA G-010-1
4、993 Guide for reusable software : assessment criteria for aerospace applications ; sponsor, American Institute of Aeronautics and Astronautics. p. cm. Includes bibliographical references. 1. Computer software-Reusability. 2. Aeronautics-Computer ISBN 1-56347-049-7 programs. 3. Astronautics-Computer
5、programs. I. American Institute of Aeronautics and Astronautics. QA76.76.R47G85 1993 005.1-dc20 Published by American Institute of Aeronautics and Astronautics 370 LEnfant Promenade, SW, Washington, DC 20024 Copyright O 1993 American Institute of Aeronautics and Astronautics All rights reserved No p
6、art of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America 11 93-28289 CIP AIAA G-O10 73 0895534 0001535 767 = AIAA G-O 1 O- 1993 CONTENTS Foreword i 1.0 1.1 1.2 1.3
7、 1.4 1.5 1.6 2.0 2.1 2.2 3.0 4.0 4.1 4.2 5.0 6 .O 7.0 Appendix A Appendix B Appendix C v Introduction . 1 Purpose . 1 Intended Audience 1 Background 1 Assumptions . 2 scope . 1 The Component Assessment Process . 2 Domain Analysis 2 Domain Analysis Criteria . 6 Domain Analysis Approaches . 3 Componen
8、t Assessment . 6 Reuse Library 7 Emerging Issues . Software Reuse Library Support for a Reuse Process . 7 Emerging Issues . Library Interoperability . 8 Conclusion 9 Glossary 9 References . 10 Domain Analysis Criteria . 13 Component Assessment Criteria . 15 Reuse Library Criteria . 21 . 111 AIAA G-0
9、10 93 Ob95534 000153b 8T5 W AIAA G-O 10- 1993 iv Foreword This Guide for Reusable Software: Assess- ment Criteria for Aerospace Applications has been sponsored by the American Institute of Aeronautics and Astronautics as part of its Standards Program. Software reuse and the development of cri- teria
10、 to aid in assessing potentially reusable software is an emerging discipljne. This AIAA Guide provides the reader with in- formation on performing domain analysis as the basis for developing criteria for assessing potentially reusable software and establishing on performing the following: i 3 a soft
11、ware reuse library. It includes guidance o Domain analysis o Component assessment o Reuse library assessment. ! This Guide was developed to meet the vary- ing needs of software personnel such as: o Managers o Software engineers o Quality engineers o Software reuse librarians o Reuse analysts o Reuse
12、 researchers. l The AIAA Standards Procedures provide that all approved Standards, Recommended Prac- tices, and Guides are advisory only. Their use by anyone engaged in industry or trade is entirely voluntary. There is no prior agree- ment to adhere to any AIAA standards publi- cation and no commitm
13、ent to conform to or be guided by any standards report. In formulating, revising, and approving stan- dards publications, the Committees on Stan- dards will not consider patents which may apply to the subject matter. Prospective users of the publications are responsible for protecting themselves aga
14、inst liability for in- fringement of patents or copyrights, or both. AIAA G-010-1993 This project was an undertaking of the AIAA Committee on Standards for Software Systems (SoftICoS) and its Software Reuse Working Group (SoftReWG). The SoftReWG developed this document and in- corporated comments of
15、 reviewers from academia, government, and industry. After broader use of the Guide, it is planned to submit it for approval as an American Na- tional Standard. AIAA Software Systems Committee on Standards At the time of preparation, the following individuals were members of the AIAA Software Systems
16、 Committee on Standards: Beverly Kitaoka, Chairman (Science Appli- cations International Corporation) John W. Brackett (Boston University) Ed Comer (Software Productivity Solutions) Anne B. Elson (Jet Propulsion Laboratory) Steven Glaseman ( Aerospace Corporation) Frank Lamonica (Rome Laboratory) Br
17、ian Larman (Jet Propulsion Laboratory) Constance Palmer (McDonnell Douglas Missile Systems Company) Richard J. Pariseau (Naval Air Warfare Cen- ter, Aircraft Division) Randall Scott (Software Productivity Con- sortium) Alice A. Wong (Federal Aviation Adminis- tration) The following individuals const
18、ituted the Software Reuse Working Group: Beverly Kitaoka Frank Lamonica Brian Larman The document was approved by the Software Systems Committee on Standards in March 1993. The AIAA Standards Technical Council (Ali H. Ghovanlou, Chairman) approved the document in May 1993. V AIAA G-O30 93 Ob95534 00
19、03538 b78 M AIAA G-01 O- 1993 vi 1 .O INTRODUCTION 1.1 Purpose This Guide provides the reader with informa- tion on performing domain analysis as the basis for developing criteria for assessing potentially reusable software and establishing a software reuse library. It focuses on the applicability o
20、f this approach within aerospace applications domains. This ap- proach is relevant both to organizations with established reuse programs and to those de- siring to establish a software reuse program. 1.2 Scope This Guide commences with a discussion of domain analysis, followed by component as- sessm
21、ent and concludes with the role of a reuse library. Section 2.0 defines domain analysis, and describes the principal products of such an analysis. Discussion of various approaches and techniques documented in the literature is then provided. Examples of cur- rent aerospace applications domain analys
22、is are the Common Ada Missile Parts (CAMP) and the Naval Training Systems Center Reuse Initiative projects. Criteria to be con- sidered for domain analysis are then presented. Section 3 .O explains component assessment for reuse and provides criteria that could be used for such an assessment. To ach
23、ieve significant productivity gains with reuse, the code must be expanded to include compo- nents of many types such as specifications, requirements, designs, data sets, and test sets. The component assessment criteria of section 3.0 are divided into three categories: domain assessment, reuse assess
24、ment, and software assessment criteria. i traditional concept of components as source Finally, as presented in section 4.0, the as- sessment criteria specified during the domain analysis process must be captured and stored in a reuse library where they are readily ac- cessible to both the component
25、developers and the component assessors. The reuse li- brary stores information about the domain and provides tools to facilitate its use. The role of the library with respect to component AIAA G-010-1993 assessment is described to provide a complete picture of the reuse process from the assess- ment
26、 perspective. 1.3 Intended Audience This guide is intended for use by both practi- tioners (e.g., software developers, manager., quality engineers, and reuse librarians) aILd researchers. Its purpose is to provide a common baseline for discussion and to define a procedure for assessing the reusabili
27、ty of software, performing domain analysis, and setting up a reuse library. 1.4 Background As the cost of software development rises, techniques for controlling the upward trend must be pursued and implemented. One of the most promising techniques being em- ployed involves reusing software that has
28、been developed and paid for in prior projects. The use of the Ada language also assists in controlling the life cycle costs of software development. In addition to being a Depart- ment of Defense (DoD) requirement since 1987, there are many compelling reasons for using Ada in todays aerospace applic
29、ations. Coupled with effective software design methods, such as object oriented design, Ada directly supports the development of highly reliable and maintainable aerospace systems. It provides for an efficient development envi- ronment, particularly when coupled with the concept of reusability, thus
30、 offering the po- tential for significant productivity improve- ments. Ada also supports software portabil- ity and reuse while standardizing on a single development environment for component development. With few exceptions, the reuse of software has not been overly successful to date. In the past,
31、 software has typically been developed to fit a particular function with no thought to enhancing the component for use on another project. Software has not been designed with reuse as a primary objective. Software must be designed and developed with reuse as a primary goal in order for components to
32、 be reused effectively in other projects or applications. 1 AIAA G-O10 93 m Ob95534 0001540 22b m AIAA G-010-1993 1.5 The Component Assessment Process The main objectives of the assessment pro- cess are to provide guidance to software component developers in producing good reusable components and to
33、 assist the asses- sor in evaluating these potential reusable components. To aid in the automation of the assessment process, several commercial off- the-shelf (COTS) tools are currently avail- able. To aid in the assessment of domain specific applications, corresponding domain specific assessment t
34、ools are also being developed. Reuse will have a major impact on the classi- cal software life cycle if reuse is an integral part of each life cycle phase and if special consideration and concerns are addressed. To achieve the productivity gains envisioned, tasks such as searching for existing produ
35、cts which meet the system requirements either di- rectly or through simple modification should be included in the project proposal stage. In each of the subsequent phases of the software life cycle there are corresponding places for inclusion of reuse (e.g., rapid prototyping, requirements analysis,
36、 and testing) in addition to actual software development. If the suppliers of reusable software compo- nents have performed the domain analysis (see section 2.0) correctly, without a bias to- wards a specific architecture or proprietary product, then these components should be appropriate for most u
37、sers. This underscores the critical need to have a skilled component assessor perform assessments so that many appropriate components are placed in the li- brary. 1.6 Assumptions In developing the assessment criteria, the following assumptions were made. Domain analysis personnel and component devel
38、op- ers, if not the same, must work together to develop reusable components. In addition, component developers and the assessor must have access to the assessment criteria during the development of the reusable components. Without some guidance, the developed com- ponents will not meet these criteri
39、a. In addi- tion, assessment tools based on the assess- ment criteria must be available to assist the component developers and component asses- sors in the assessment task so that it does not become overwhelming. The concept of developing reusable compo- nents is new to many component developers, as
40、 are the assessment criteria. There are many lessons to be learned which will result in refining these criteria. As a reuse library becomes populated with components, users will identify good reusable components by the number of accesses, extractions, and user comments. This data and other metrics s
41、hould be used to refine the assessment crite- ria. 2.0 DOMAIN ANALYSIS Domain analysis is an approach to the analy- sis and structuring of software requirements aimed at facilitating reuse of software re- quirements, design, code, and test informa- tion across a domain. Performing a domain analysis
42、entails factoring out commonality and factoring in generality. A domain is a set of problems with similar requirements for which a general solution can be developed. Examples of aerospace applications domains are identified below: Control systems - Systems typically char- acterized by stringent timi
43、ng requirements, processor and memory resource limitations, and safety / fault tolerance requirements. Ap- plications include systems for the control of aircraft, missiles, satellites, and industrial processes. Signal processing systems - Systems that analyze and respond to complex signals, typicall
44、y characterized by complex processing algorithms on high performance hardware. Applications include electronic warfare, intel- ligence signal processing, and satellite image processing. Command and control systems - Sys- tems that are typically characterized by signif- icant man-in-the-loop involvem
45、ent, complex user interfaces and data bases, and coordina- tion of distributed functions. Applications 2 AIAA G-O10 93 m 069553it 0001541 162 m AIAA G-010-1993 include military C3I systems, communica- tions network control systems, and ground control systems for satellites. The scope of a domain is
46、typically set through consideration of economic and tech- nical factors associated with system imple- mentation and the business objectives of the organization. As such, the principal determi- nation of a domain is whether software arti- facts developed for one instance of the do- main may be cost-e
47、ffectively reused for another instance. The principal products of a domain analysis, relevant to the assessment process, are: Domain Definition - a working definition of the domain that provides sufficient infor- mation to determine whether a specific sys- tem is a candidate for inclusion in the do-
48、 main. The domain definition characterizes the functional boundaries of the domain and helps determine whether it will pay to reuse existing domain components in a new sys- tem. This boundary may change throughout the domain analysis process (and beyond) as key economic and technical issues associat
49、ed with domain software reuse become more clearly understood. The key determinant of this boundary is the potential for cost-effec- tive reuse of software components. After a software reuse program has been imple- mented, the domain definition can be further refined based upon various usage metrics which can be collected from suppliers and users. Conceptual Taxonomy - a definition of domain terminology that provides an initial basis for relating domain instances. The tax- onomy includes any necessary thesaurus in- formation to begin the process of correlating different instances of the
