Software Reuse: Methods, Models, Costs, Second Edition

To the Reader

This book was originally published in 1997 by McGraw-Hill publishing company in New York.  It has been out of print for several years.  However, except for a few, easily spotted out-of-date references (such as one that describes floppy disks!) to specific software packages, and a few of the tools being superseded by newer versions and software packages, the basic ideas continue to be completely relevant to the needs of those who produce large software systems.  In fact, the newest trend in software engineering in the defense arena is the development of what are called systems of systems, which cries out for systematic software reuse.

In this troubled time period for the publishing industry, it makes little sense for an author to attempt to even consider publishing a book with a relatively small potential audience under the auspices of a major publisher.  Instead of doing all the work for a second edition, with the strong probability that this effort will be for naught, it made more sense to simply reissue the book electronically.  I hope this book is useful to you.

Preface

The primary intended audience for this book is software engineers and managers faced with practical problems in developing software, especially schedule, cost, and quality pressures.  The book can be used as a secondary reference for additional reading in an upper-division or graduate-level software engineering or software engineering economics course.  It can also be used as the primary text in an advanced software engineering course based primarily on software reuse.  Both professionals and students can read the book profitably.

The typical reader of this book will have had previous exposure to the development and maintenance of software systems that are too complex to be designed and implemented by a single person.

Software reuse continues to be one of the hottest topics in software engineering.  For the past few years, nearly every conference with a heavy focus on software engineering has included at least one paper session, panel discussion, or invited talk on some aspect of software reuse.  Many larger conferences have tutorial sessions on software reuse.

Software reuse is the software engineer's attempt to model the process by which an electrical engineer designs circuits by using standard components with well-defined, well-documented interfaces.  Reusable components can be found at any place in the software life cycle: requirements, design, code, test, integration, documentation, and maintenance.  Reuse often allows the software engineer to be much more productive since total life cycle costs frequently can be greatly reduced.

While this book will provide a complete description of software reuse, it will focus on methods for reuse that are feasible without major investments in new software methodology, on cost estimation issues, and on certification of reusable software components.  It will be based on experiences dealing with systems that are changing rapidly.  This viewpoint is different from the perspective of many writers in this area who only consider systems that are stable over time.  However, it is consistent with software development using the rapid prototyping or spiral models of the development process.

This book emphasizes both theoretical and practical techniques for the reuse of software artifacts.  Software artifacts include source code modules, requirements, designs, documentation, user manuals, test plans, test cases, test case results, and installation guides.  The book is organized as follows:

Chapter 1 is an introductory chapter.  In it, we present a rationale for software reuse and briefly describe some of the early results and current trends.  Disincentives to software reuse, including legal and security issues are also presented.

Chapter 2 presents more detailed discussions of several essential techniques.  The primary theoretical technique discussed is domain analysis.  Domain analysis is the application of systems engineering principles to the determination of common components in an organization's collection of software artifacts. The practical techniques discussed will include the development of standard interfaces, object-oriented approaches, designing for reuse, setting requirements to meet reuse standards, and some appropriate metrics.

We introduce the issue of reuse library management in Chapter 3.  This chapter also includes a discussion of some of the more readily-available reuse libraries, with some description of software artifacts that are at a higher level than source code.  These higher-level artifacts include some designs, complete subsystems, and software written in fourth generation languages.

Chapter 4 is devoted to the certification of reusable software components.  The term certification refers to a quality evaluation taken after the software artifact has passed through normal software testing and has been placed into service.  An additional certification step is necessary, because software components may be used in contexts other than the one in which they were originally developed.  There will also be recommendations for appropriate standards and practices to encourage the systematic employment of software reuse.

We present a large set of cost estimation models in Chapter 5.  There will be heavy emphasis on the collection and interpretation of software metrics for both evaluation of process and prediction of cost savings.  Cost estimation models for reuse will include both the classical waterfall life cycle and iterative software development paradigms such as the spiral and rapid prototyping processes.  We will emphasize the effect of life cycle leverage on the potential savings due to reuse.  We will also describe the optimum size of reusable components (the economic reuse quantity).

Reengineering of software is discussed in Chapter 6.  Reengineering involves change in a system's design in order to improve maintainability.  Software reuse and reengineering are related because a major concern of software managers is that the cost involved with reengineering a system is affected by the amount that is reused.

Four case studies are presented in Chapter 7.  These include some programs at particular installations of NASA, Battelle National Laboratories, AT&T, and Hewlett-Packard.

Chapter 8 is devoted to a discussion of some tools for software reuse.  The tools discussed range from commercial to public domain to some that are restricted to a particular organization.

There are four appendices: metrics, a glossary of terms, sources for reuse libraries, and a set of suggestions for a course on software reuse.

Some of the material, particularly the certification issues, some of the cost models including the economic reuse quantity, the heavy use of metrics in software reuse, and the reengineering model have not appeared in print previously.

Many people deserve thanks for their part in this effort.  Special thanks are due to Judith Bruner, Jack Koslosky, Ron Mahmot, and Henry Murray of the Space Center Systems Branch of NASA/Goddard Space Flight Center in Greenbelt, Maryland for providing access to the rich history of the TPOCC project, which focused heavily on reuse.  Many thanks also to Kellyann Jeletic for several interesting discussions about software process and metrics, for making us aware of the details of some of the analyses performed by the Software Engineering Laboratory at Goddard, and for reading and commenting on an earlier version of the manuscript.  Clayton Sigman and Ron Mahmot of Goddard also made many insightful comments on an earlier version of the manuscript.

Linda Rosenberg of Unisys also provided important resources for metrics analysis of some of the NASA/Goddard systems.  Toni Zepp of Computer Science Corporation provided access to her electronic database of discrepancy reports for metrics analysis and comparison.

Many people provided insights into the impact of reuse on cost estimation models.  Among them are Brian Bolger, Jay Carlin, Victor Church, and Gary Meyers of Computer Sciences Corporation; Dan Mandl and Larry Zeigenfuss of Goddard, and Evan Eller and Toby Perkins of Allied Signal Corporation.  Many of the inputs to the cost estimation models in Chapter 5 have their roots in informal conversations with these colleagues.  Ronald Cherry and Isaac Jackson of DISA, Kawanna Rice of the Maryland Procurement Office, and Annette Johnson also provided critiques of this manuscript.

Michael Feldman of SIGAda and The George Washington University and Richard Conn and Hal Haft of SIGAda are owed special thanks for their many years of effort on behalf of the Ada community, especially in the area of information dissemination.  These efforts have strongly influenced reuse efforts on a national level.

Special thanks are due to Christa Clark of AT&T and Terrence Fuller of Bell Northern Research for some preliminary work on software reuse and for providing brief overviews of the reuse activities at AT&T and Battelle Northern Laboratory, respectively.  Patricia Collins of Hewlett-Packard provided insight into reuse programs at HP.

Dr. William Frakes of Virginia Polytechnic and State University is owed special thanks for interesting discussions and for a very stimulating seminar he gave at Howard University.  Shari Lawrence Pfleeger was also very helpful with her important insights.

My editors at McGraw-Hill, Marjorie Spencer and John Wyzalek, the reviewers, and the McGraw-Hill book team provided invaluable assistance in the production of this manuscript.  Many thanks are due to all.

Preface to the Second Edition

There have been many improvements in the software development process in the aerospace and defense industries during the last fifteen years: CMM, CMMI, the Internet, new programming languages and paradigms, increased attention to reuse and reengineering, and some important publications.  In this paper we present an interview with a senior project manager fifteen years ago and assess what has changed since then in one particular area – software reuse.  The assessment presented here should provide some insight into rapidly evolving situations when both development and technology processes, and the complexity of systems being designed, increase greatly over a long period.

How much has changed since then?

One of my most professionally rewarding efforts was examining the reuse program at NASA Goddard Space Flight Center in Greenbelt, Maryland.  As part of my efforts, I interviewed a senior project manager at a large government contractor that had responsibility for large scale development, testing, deployment, and maintenance.  The context for the interview was: a civilian contractor to the government, adherence to a large manual for the systems engineering and development processes, a detailed work breakdown structure that incorporated reuse percentages was used for cost modeling, there was little use of the Internet, and most external documentation required multiple loose-leaf notebooks.

The SEI Capability Maturity Model (CMM) [SEI91] had just been introduced and most government contracting organizations were at CMM Level 1 and below.  The Software Reengineering Assessment Handbook [SEI97] and the U.S. Department of Defense Architectural Framework (DoDAF) [DODAF2004], which hold considerable promise for treating complex systems of systems, did not exist at that time.

The information provided in this preface is taken directly from my handwritten notes on statements made by the manager interviewed, with abbreviations removed and the answers put into complete sentences.  It has been sanitized to eliminate any mention of the organizations involved.  Other than these editorial changes, the material presented here describes the interview accurately.  The interview and the assessment are presented below.

Question 1: How many design projects has the manager worked for the government in this application domain?

1992 Answer:  Many.

Current practice in the same domain:  Same.

Prediction:  Software engineers continue to have experience on multiple projects.

Question 2: How many design projects has the manager headed for the government in this application domain?

1992 Answer:  Three, with successive projects having greater size and complexity.

Current practice in the same domain:  Project managers progress toward having responsibility for successive projects having greater size and complexity.

Prediction:  Software managers continue to progress toward successive projects having greater size and complexity. The changing demographics of the software professionals may have some influence.

Question 3: How important does the manager feel reuse is?

1992 Answer:  Reuse is critical because of limited contractor staff – they are not a project and have to be accountable for all projects. 

Current practice in the same domain:  Same, in most areas. 

Prediction:  The sharp decline in enrollments in computer science undergraduate programs will make the shortage of staff even more critical in the future for areas critical to the national need.  The accounting issues in providing cost analyses of software reuse programs continue to be a problem.

Question 4: Is reuse required and/or supported by the monitoring organization?

1992 Answer: There is strong support in the monitoring organization. Some code from missions has been folded into larger systems (systems of systems) and reuse.  Reuse is not a problem – the contractor is kept lean and mean.

Current practice in the same domain:  It is still important.

Prediction: Reuse will continue to be important, strongly supported by the government, and difficult to achieve at the highest levels.

Question 5:  How is reuse incorporated into design?

1992 Answer:  There is no generic design document.  There are links to see original design document.  There is no generic design document – some with a short-term project.  (There is a summer project to place generic requirements into a Requirements Generation System.  All linking, even if at high level, is limited to link to document and is done manually.  Structured programming has been used for requirement specifications and data flow.  They are far along with software development, probably too far to revise practices).

Current practice in the same domain:  The requirements generation system was deployed and resulted in a reasonable amount of cost savings.  Linking is now done via hypertext (HTML, XML) on a closed, private network is used to provide information access.  Structured programming has been substantially superseded by more object-oriented methods.  Many contracting organizations have to revise practices to include high SEI CMM and CMMI levels in order to be allowed to bid on government contracts.

Prediction:  This area needs improvement, because of potential cost savings.

Question: How is reuse incorporated into code?

1992 Answer: The sccs tool is used for configuration management.

Current practice in the same domain: Contents of a version’s release are flagged with comments in the sccs file.

Prediction:  This will continue, with some increased use of CASE tools.

Question 7: What special testing requirements re required for reusable components?

Answer given in 1992:  Perhaps not applicable – everything they do is likely to be reused. It depends on who the code came from.

Current practice in the same domain:  There is often additional testing done.

Prediction: This will become more important due to liability and licensing issues.   

Question 8:  How do programmers react to reuse?

1992 Answer:  There has not been any downsizing in this area yet!  (Editorial note – there may have been no resistance because jobs were not lost at the time!)

Current practice in the same domain:  Downsizing and outsourcing will be important in some industries, less so in aerospace and defense. 

Prediction:  Downsizing and outsourcing will be less important, except for simpler applications, and will be even less so in aerospace and defense. 

Question 9: How do programmers react to training for reuse? 

1992 Answer: There is no formal training.  Most folks have worked on several projects. There are some problems with those unfamiliar with missions.  The central reusable software core grew out a prototype proof of concept.  There is formal training in structured programming, then informal dissemination of knowledge.  Examples are the gnu compiler for the front end and the (older) Kernighan and Ritchie C, the purify software tool as a debugger.  There was some use of C++.

Current practice in the same domain: There is still little training in reuse.  Use of some case tools and object-oriented languages (C++, Java, and Ada) has increased. 

Prediction:  There is still little formal training in reuse.  Lechner [10] recently suggested that managers determine the 10% of code that should be reengineered each year to maintain a reasonable return on investment for software.  This code selection for reengineering may be very difficult without advanced training.     

Question 10: How do they code for reuse?

1992 Answer: There is informal dissemination of knowledge. 

Current practice in the same domain: Same

Prediction:  There is still little formal training in reuse.

Question 11: How do you certify components, designs, etc., for reusability?

1992 Answer: If something is special purpose and not reusable, then they don’t do it and just send it to the mission application folks.

Current practice in the same domain: There has been some use of reuse libraries and some library analysis tools such as Inquisix.  The important work of Jeffrey Voas and others on certification of COTS products and other, relatively large components provides some insight into state-of-the-art, but does not seem to have had as large an effect on the state-of-the-practice.

Prediction:  There is almost no training of managers for this.  The problem may get worse as senior managers retire.

Question 12: How do you control access to the reuse library?  (Of code, of designs, of requirements, of test plans, ...)

1992 Answer: Trees for code development, integration, and release are used for systems – source code only.  Display widget man pages on-line, no on-line display of man pages for library routines.  No way to link publications (requirements, design, documentation, etc.) to releases, possibly FrameMaker to link text, graphics.

Current practice in the same domain: There is much better linking of artifacts and different ranges of publications (requirements, design, documentation, etc.) to the software version’s release via either embedded HTML or an overall web site design.

Prediction:  The use of HTML will be augmented by XML, especially with increased use of the semantic web. 

Question 13: How do you handle configuration management for reuse?

1992 Answer:  The sccs source configuration management tool was used, along with special directories.  The technical publications department was used for the rest.

Current practice in the same domain: Configuration management is typical, with other version control programs such as rcs and cvs  replacing sccs. 

Prediction:  Most version control systems are still based on the file where the error occurred, and do not allow propagation of errors throughout systems to be considered as a transaction flow.  Thus, it may be difficult to determine a chain of files and systems affected by a maintenance change that causes other changes.

Question 14: General comments, any available documentation?

1992 Answer:  Forms, memos, etc.

Current practice in the same domain:  This was typical.

Prediction:  Most documentation will be on-line in private, secure intranets.     

Question 15:  About documentation – do you use hypertext to reuse entire components of user’s guides?

1992 Answer: Not answered at interview.  An action item was to see tech pubs to check on reuse of user’s guide – little evidence of hypertext was found.

Current practice in the same domain:  Largely on-line.

Prediction:  Most documentation will be on-line in private, secure intranets

Question 16: Were metrics collected? 

1992 Answer: Yes

Current practice in the same domain:  Same.

Prediction for the future:  Metrics collection is universal, due to CMM and CMMI.

Question 17: When were metrics collected?

1992 Answer: At least monthly; the metrics were reported monthly.

Current practice in the same domain:  Same.

Prediction:  The CMM and CMMI practices will continue to strongly influence metrics collection intervals.  Monthly collection and analysis will be most common.     

Question 18:  How were metrics collected?

1992 Answer: Metrics data collection was automatically done on release trees, not by the programmer.  The policy was to not use metrics for evaluation of programmers.

Current practice in the same domain:  The policy on metrics data collection was the same.  Many organizations used metrics to assess productivity of individual programmers.

Prediction: Metrics data collection will be similar.  The use of many metrics, such as the number of lines of code produced per day for programmer evaluation, has been somewhat discredited, and appears to be disappearing from common use.

Question 19: What kinds of metrics were collected?

1992 Answer: Lines of code, Halstead, and McCabe metrics were typically collected.  Maintenance reports were entered into a database.  At times, some special metrics were collected for research purposes

Current practice in the same domain: Essentially the same

Prediction:  Metrics databases will be examined more carefully in the future for insight into failures.

Question 20: How were metrics used by managers?

1992 Answer: To assess team productivity.

Current practice in the same domain:  Same

Prediction:  This will remain true, and will increase in importance in the awarding of small subcontracts.  There will be little effect on larger contracts.

The obvious conclusion is that relatively little has changed in the treatment of reuse over the last fifteen years, other than the improvements enabled by technology (the web and hypertext for document linking) and some processes (CMMI is a more sophisticated version of CMM).

The cost pressures will continue, making it difficult to allocate resources to up-front costs of systematic reuse programs.

Please do not disseminate the book illegally, since I still retain copyright rights.

Enjoy!  And reuse this book wisely.

CHAPTER 1 WHAT IS SOFTWARE REUSE?

In general, the term software reuse refers to a situation in which some software is used in more than one project.  Here software is defined loosely as one or more items that are considered part of an organization's standard software engineering process that produces some product.  Thus software could refer either to source code or to other products of the software life cycle, such as requirements, designs, test plans, test suites, or documentation.  The term software artifact is frequently used in this context.

Software reuse has several different meanings in the software engineering community.  Different individuals have viewpoints that depend upon their responsibilities.

For example, a high-level software manager might view software reuse as a technique for improving the overall productivity and quality of his or her organization.  As such, the focus would be on costs and benefits of organizational reuse plans and on schemes for implementing company-wide schemes.

Developers who use reusable code written by others probably view software reuse as the efficient use of a collection of available assets.  For these consumers of existing software, software reuse is considered a positive goal since it can improve productivity.  A project manager for such development would probably view reuse as useful if the appropriate reused software was easy to obtain and was of high quality.  The manager would have a different view if he or she was forced to use poorly-tested code that caused many problems in system integration and maintenance because of its lack of modularity or adherence to standards.

On the other hand, developers who are producers of reusable code for use for their own projects and for reuse by others might view reuse as a drain on their limited resources.  This is especially true if they are required to provide additional quality in their products or to collect and analyze additional metrics.

A reuse librarian, who is responsible for operating and maintaining a library of reusable components, would have a different view.  Each new reuse library component would have to be subjected to configuration management.  Some degree of cataloging would be necessary for future access.  Software reuse makes the job of a reuse librarian necessary.

In layman's terms, reuse can be defined as using what already exists to achieve what is desired.  Reuse can be achieved with no special language, paradigm, library, operating system, or techniques.  It has been practiced for many years in many different contexts.

Reusing code is often more appealing than automatic code generation.  In the vast majority of projects, much of the necessary software has been already been developed, even if not in-house.  Frequently, it's just a matter of knowing what to reuse, how to reuse it, and what the tradeoffs are.

Reusability is widely believed to be a key to improving software development productivity and quality.  By reusing high quality software components, software developers can simplify the product and make it more reliable.  Frequently, fewer total subsystems are used and less time is spent on organizing the subsystems.

There are many examples of successful software reuse.  Several success stories were cited by Charles Lillie at the Second Annual Reuse Education and Training Workshop [LILL93].  These include:

·  Three hundred and twelve projects in the aerospace industry, with averages of 20% increase in productivity, 20% reduction in customer complaints, 25% reduced time to repair, and 25% reduction in time to produce the system.

·  An Japanese industry study that noted 15-50% increases in productivity, 20-35% reduction in customer complaints, 20% reduction in training costs, and 10-50% reduction in time to produce the system.

·  A simulator system developed for the US Navy with a increase of nearly 200% in the number of source lines of code produced per hour.

·  Tactical protocol software with a return on investment of 400%.

·  A NASA report lists reductions of 75% in overall development effort and cost [McGA93].

These are impressive success stories.  They clearly indicate that software reuse is a technique that can have a positive impact on software engineering practice in many environments.

The phrase reusable software engineering encompasses the reuse of all information generated during the software development process.  The questions what? and how? to reuse software, and in which? method does it prove to be the most successful, are commonly asked.

Despite the positive outlook for reuse, some questions remain:

·  How should potentially reusable code be developed?

·  How do we locate appropriate software components?

·  What tools are available?  Do they work?

·  Why is the expected quality of projects sometimes hard to achieve?

·  Why is the projected cost savings of software reuse sometimes hard to determine?

·  Why do some reused-based development projects appear to have higher life cycle costs than similar ones developed without reuse?

·  What changes have to be made to our organization's software development practices?

·  What changes do we have to make to our cost models?

Some people even ask, Why is reusability a strategy of great promise that has been largely unfulfilled?  All these questions will be addressed by the systematic approach to software reuse that is emphasized in this book.

This chapter will provide a brief introduction to some of the issues associated with software reuse.  We will describe some of the earliest successful efforts in software reuse and indicate the role of reuse in different software development methodologies, including those based on the classic waterfall, rapid prototyping, and spiral models.  We will discuss the relationship between software reengineering and software reuse.

The fundamental technique of domain analysis and its relevance to reuse library management will be introduced next.  After a diversion to briefly describe some of the disadvantages of reuse and some legal issues, the chapter will close with a description of the basic understanding, the state of the art, and the state of the practice of software reuse.

You might have noticed that there is no explicit mention of object-oriented approaches to software reuse in this chapter.  As we will see several times in this book, object-oriented techniques present many opportunities for reuse of source code components.  We will describe these techniques in several places in this chapter and elsewhere in this book.

1.1 Origins of Software Reuse

As the large increase in software costs and the problems in developing quality products on schedule became more evident, several organizations viewed software reuse as a goal that could be achieved in limited ways at that time and as a goal that could later be achieved in broader ways through advanced development and research.  Reusing software can be traced back at least as far as the early attempts of Lanergan and Poynton at Raytheon and of Matsumoto at Toshiba [MATS89].  The initial work emphasized cost savings.

One of the first papers to present the concept of formal software reuse was McIlroy's presentation [McIL68] at a NATO conference.  The survey article by T. Capers Jones [JONE84] provides a good overview of some of the early work in the area of software reuse.

The U.S. Department of Defense saw reuse as a prime candidate in attempts to improve software productivity and it was a major factor in the design of the Ada programming language.  Many repositories of code have been developed and maintained as part of this continuing effort.

Since the adoption of the ANSI-MIL standard for Ada in [ADA83], there have been long range research efforts to improve the understanding and ability to reuse information in the development of software.  Software reuse was attracting much interest and was noted in 1992 as the year's most sought after objective or Holy Grail of application development.  Unfortunately, developers and analysts reported successful application of reuse to software projects as being hindered by a web of issues such as: training, costs, technical difficulties, and psychological resistance [RAY92].  Public perception of the importance of software reuse for cost reduction and quality improvement was illustrated by Scientific American magazine publishing an article on the topic [CORC93].

It was not too long ago that hardware designers built hardware in the same manner in which software is built today.  They assembled custom circuits from individual electrical components in the same manner as functions were developed from low-level components of programming languages (for example, assignment statements, conditional statements, function calls, etc.).  Until a packaging technology evolved that could make the hardware environment of a chip relatively independent of the detailed workings of that chip, massive reusability techniques of hardware designs was not possible.

Three steps were necessary to improve this situation:

Reuse of basic components, with standard interfaces and precisely-defined functionality.

Low price of computer components, due to a repeatable manufacturing process.

Development of tools such as VHDL for representing architectures at higher levels of abstraction.

One important concept that stands out in hardware systems is that many of the components perform unique services.  These services are provided upon request, and the result is the only concern, not the internal methods of data used.

The software concept that is equivalent to this process is referred to as encapsulation, which defines a data structure along with a group of procedures for accessing it.  The data structure can only be accessed by the users through careful documentation [BECK92], [LEBD85].

Some of these steps are mirrored in the evolution of compilers, database management systems, and operating systems.  Most compiler designers use tools that take high-level lexical and semantic descriptions of the language being compiled and use tools to obtain initial compilers by using lexical analyzers such as lex, flex, and Alex, or compiler-compilers such as yacc, bison, and Ayacc.  These readily-available tools support higher-level representations of the languages and have standard interfaces.

You have probably noted the similarity of the language of the last few paragraphs to the fundamental concepts of object-oriented design and programming.  This is clearly not an accident.  The concepts of object-oriented design and programming were developed in order to support the higher levels of abstraction and information hiding necessary for software development using reusable software components.

You should note, however, that most existing systems are not object-oriented, and that many systems developed using the object-oriented paradigm are so new that their total life cycle costs (including the costs of analysis, requirements, design, coding, testing, integration, maintenance, and documentation) have not yet become apparent.  Thus, for many organizations, the total life cycle savings due to software reuse for object-oriented systems cannot be completely determined yet.  The increase in abstraction of some object-oriented systems over equivalent, procedurally-oriented ones, will have some effect on reuse-programs, but the complete effect of the object-orientation appears hard to quantify at this point.

Since there are many billions of lines of code in existing applications, most of which were developed using procedural and not object-related paradigms, any reuse method that only that is only capable of addressing object-oriented systems is not likely to have immediate positive effects for the majority of existing software systems.  The long-term benefit of application of such a method to procedurally-developed systems remains to be seen.

However, since many of the ideas underlying the object-oriented approach frequently are consistent with the goals of software reuse, we will encounter object-oriented approaches many times in this book.

1.2 Reuse and the Software Life Cycle

Software artifacts may be reused at many phases of the software engineering life cycle, including analysis, requirements, designs, implementations, test plans, test cases, test results, error data, and documentation.  This is true regardless of the software development life cycle model that is used in the organization.  We will describe the classical waterfall, rapid prototyping, and spiral models in more detail in Chapter 5, when we present cost models for software reuse programs.  In general, you should expect that earlier reuse in the life cycle is better than later reuse, because of the potential for eliminating software development steps.

It is important to classify the places where software reuse can occur.  In the next few pages, we will describe three common categorizations for reuse activities and provide an additional one to reflect some more recent trends in software development.

Capers Jones [JONE84] lists five important subtopics under the general heading of reusability: reusable data, reusable architecture, reusable designs, reusable programs and common systems, and reusable modules.

·  Reusable data.  The concept of reusable functions implies that there is a standard data interchange format.  Reusable programming requires reusable data.

·  Reusable architecture.  Since for the first 30 years of programming, designers and programmers have tended to consider each application as a unique artifact, there is no widespread architectural scheme for reusable programming. [JONE84]

·  Reusable design.  Software should be designed so that sections of code can be reused.  Doing so is pretty hard, despite its appearance of being fairly easy [CORC93].

·  Reusable programs and common systems.  Programs used by more than one customer are considered reusable.  Reusable programs tend to concentrate in just a few application areas.  A second aspect of reusable programs is that of common systems that are developed and shared among enterprises with multiple locations. 

·  Reusable modules.  Reusable modules and standard subroutines are more common now that reusable modules are beginning to be supported in the industry by library management systems.

Note that COTS (Commercial Off-the Shelf) software is in the category of reusable programs and common systems.  This is the most extreme case of software reuse.  The percentage of a software artifact that is reused should be considered as a continuum ranging from an entirely new system with zero reuse, to a COTS system, with 100% reuse.

Gold [GOLD90] has a more object-oriented focus.  He suggests that most reuse falls into one of five categories:

·  Algorithm reuse.  Algorithm reuse involves using the same algorithm across data structures.  Using the data abstraction supported by object-oriented technology, algorithms that use the object-oriented data abstraction technique can be implemented at a high level of a class hierarchy and automatically become available to subclasses.

·  Reuse of classes and instances.  Reuse at the object level occurs in either the form of refining a class via inheritance to obtain a new class, or using instances of a class in the composition of a new class.  With inheritance, both the protocols for the interface and implementation of the class are both reused.  However, with composition, only the interface protocol specified in the class of the instance is reused.

·