1. Background and Introduction.- 1.1 The Problem.- 1.2 Concepts and Definitions.- 1.3 Research Activities.- 1.4 Status of Reuse Practice.- 1.5 Scope and Organization of this Book.- 1.6 References.- 2. Managerial Guidelines.- 2.1 Managerial Issues and Approaches.- 2.1.1 Organizational Management and Structure.- 2.1.2 Organizational Behavior.- 2.1.3 Contractual and Legal Considerations.- 2.1.4 Financial Considerations.- 2.1.5 Case Study: Reuse Program at Hartford Insurance Group.- 2.2 Software Development and Maintenance Incorporating Reuse.- 2.2.1 The Software Process.- 2.2.2 Life-Cycle Models.- 2.2.3 A Generic Reuse/Reusability Model.- 2.2.4 Establishing a Process.- 2.2.5 Case Study: JIAWG Reuse-Based Process Plan.- 2.3 References.- 3. Technical Guidelines.- 3.1 Domain Analysis.- 3.1.1 Overview.- 3.1.2 Case Study: The Domain Analysis Project at Software Engineering Institute (SEI).- 3.2 Creating Reusable Components.- 3.2.1 Spanning the Life Cycle.- 3.2.2 Requirements and Designs.- 3.2.2.1 Overview.- 3.2.2.2 Object-Oriented Approaches.- 3.2.3 Code Components.- 3.2.3.1 Code Component Structures.- 3.2.3.2 Programming Style.- 3.2.4 Component Quality.- 3.2.5 Classifying and Storing Components.- 3.2.6 Case Study: A Design Study of Telephony Software at Ericsson Telecom.- 3.3 Reusing Components.- 3.3.1 Cognitive Aspects.- 3.3.2 Searching and Retrieving.- 3.3.3 Understanding and Assessing Components.- 3.3.4 Adapting Components.- 3.3.5 Composition of Code Components.- 3.3.6 Case Study: A Quantitative Study of Spacecraft Control Software Reuse at GSFC.- 3.3.7 Case Study: The Reusable Software Library (RSL) at Intermetrics, Inc..- 3.4 Tools and Environments.- 3.5 References.- 4. Getting Started.- 4.1 Discussion.- 4.2 A Phased Approach.- 4.3 References.- Appendix A: Collected Guidelines.- Appendix B: Guidelines for Reusable Ada Code.

Observers in the present usually have an advantage when it comes to interpreting events of the past. In the case of software reuse, how ever, it is unclear why an idea that has gained such universal accep tance was the source of swirling controversy when it began to be taken seriously by the software engineering community in the mid-1980's. From a purely conceptual point of view, the reuse of software de signs and components promises nearly risk-free benefits to the devel oper. Virtually every model of software cost and development effort predicts first-order dependencies on either products size or the num ber of steps carried out in development. Reduce the amount of new product to be developed and the cost of producing the product de creases. Remove development steps, and total effort is reduced. By reusing previously developed engineering products the amount of new product and the number of development steps can be reduced. In this way, reuse clearly has a major influence on reducing total development cost and effort. This, of course, raises the issue of from whence the reused products arise. There has to be a prior investment in creating "libraries of reuse products before reuse can be successfuL . . " How can organizations with a "bottom line" orientation be enticed into contributing to a reuse venture? Fortunately, the economics of reuse l resembles many other financial investment situations ."