“Waste not, want not” has never been the motto of software developers. On the contrary, waste has been encouraged as a normal part of the one-of-a-kind system development philosophy advocated in most software projects. The software tradition is that the best way to serve the user/customer is by building each new system from scratch, without any notice or regard to the amount of “reinventing of the software wheel” that occurs.
What has not been realized is the extent of unnecessary reinventing and the enormous waste of resources that occurs in most software projects. Countless software projects have wasted resources developing software components that bear a great similarity to those that already exist. Software waste is a very common occurrence because software systems tend to be more alike than different from one another. Comparative analysis of software systems has shown that, in general, sixty to seventy percent of a system's functionality is common to more than one system.
Unless specific measures are taken, software waste will continue to occur regardless of the type of technology used or the type of application system built. Newer technologies such as software automation, object orientation and client-server do not change this fact. However, they do make it easier to take advantage of software similarities. Some software similarities can be predefined and built into software tools (such as reusable code patterns in generators); others can be created as reusable components which are stored in software reuse libraries and made available to develop new systems.
Because software systems typically are composed of similar parts, the majority of each new software system can and should be assembled from predefined reusable components. Although often overlooked, software reuse is the best answer to the decades-old software crisis.
A reusable component may be program source code, but the bigger benefits from reuse often come from a broader and higher-level view of what can be reused. Software specifications, designs, test scripts, project plans, documentation, object frameworks, and subroutines are all examples of viable types of reusable components. In general, any software project deliverable could be produced from reusable components. High on the list of reusable component types should be reusable skeletons that can aid the production of every kind of project documentation, report, and plan. Since these skeletons can be provided as word processing template forms, they are fast and easy to create and make available in the reuse catalog. The benefit is not only saving time, but also ensuring that corporate standards are followed and consistency is enforced across software development processes and systems. This leads to better quality systems that are easier to understand, maintain and reuse. Finally, this type of reusable component is unlikely to offend the creative needs of system developers because documentation is not something they enjoy doing. Many of these skeletons are probably already in existence in some parts of the organization and should be made available to all software development groups.
The two other kinds of software components that should be high on the list of valuable reusable components are design components and test components.
Design components are important because the best place to maximize leverage from reuse is at design time. Design components are at a higher level of abstraction than code, making them less implementation-specific and, therefore, more portable and more reusable. Also, since design is a more expensive development task than coding, reusing designs can potentially provide greater savings than reusing code. In addition, reuse at the design level can lead to reuse at the code level if there is some traceability between the design and the code that implements it. Traceability can be handled automatically by CASE tools. Focusing on design components can solve some of the concern over differences and incompatibilities between components written in different programming languages.
Test components, such as test data, test scripts, test cases, and test plans, are also very important to consider. In some cases, although the code may not be reusable due to language or tool differences, the test components may be reusable. Reusing test components can ensure that a system is more thoroughly tested and this, of course, can result in a more reliable, easier-to-maintain system. Since testing, like design, is a very expensive task, reusing test components can save a great deal of project time and resources.
Exploiting reuse opportunities enables significant software productivity, quality and cost improvements. The major benefits that reuse can deliver are to:
Increase software productivity
Shorten software development time
Develop software with fewer people
Move personnel, tools and methods more easily from project to project
Reduce software costs
Produce better quality software
Improve software system interoperability
Provide a competitive advantage
Although the idea of reuse is simple, its implementation is not. Today, the vast majority of United States corporations do not have formal reuse programs. Although reuse is as old as programming itself, it is a software technology that has remained on the shelf of good ideas endorsed as the right thing to do, but, like most good intentions, never really put into practice.
The position of most software developers and their management on reuse is that if they knew how to do it in a cost-effective, low-risk, and timely fashion they would practice reuse. The problem is that most of the software methodologies they use do not include reuse. The methodologies do not explicitly define the where, when, and how of practicing reuse as part of the development process. Furthermore, neither the reuse roles and responsibilities of the project team, the user, and management, nor the tools needed to support reuse are understood.
Purpose of This Book
This book is about reuse. However, it not a general discussion of the definition of software reuse or the merits of the concept. Rather, it is a detailed explanation of how to make reuse work in practice. The purpose of this book is to fill in the missing details about how to practice software reuse. It is a step-by-step guide that empowers the reader to infuse reuse into the software development process (both object-oriented and traditional structured/non-object-oriented processes) and to attain the maximum benefits it can offer. This book is intended for anyone who has a background in software development and wants to learn how to practice reuse-driven software development.
System developers and maintainers can use this book to learn how reuse changes and simplifies the job of building and maintaining software systems and how to perform techniques that are unique to reuse.
Software methodologists, who are responsible for selecting and defining their corporate software life cycle methodologies and software standards, can use this book to understand what characteristics are required by a software life cycle methodology to support reuse. With this understanding they will be able to choose the methodologies that provide the best support for reuse and be able to extend their existing corporate methods to support reuse.
Database/repository management groups can use this book as a guide in building a reuse library/reuse catalog with a classification scheme and certification process for reusable components.
Software project managers can use this book to learn how to factor reuse into project scheduling, resource requirements, software productivity and quality measurements, and personnel management.
Software trainers and educators can use this book to define the contents of software reuse courses for software managers and technical personnel.
Finally, a corporation that is contemplating the establishment of a corporate reuse initiative can use this book to define and implement a formal, yet practical reuse program that spans across software groups, business units and, perhaps eventually, the entire enterprise.
Structure of This Book
This book is divided into three basic parts:
1. Introduction to Reuse
2. Reuse Techniques
The introduction consists of three chapters. The first chapter is an overview that presents the case for reuse with the reuse success stories from several corporations. Not only do the stories explain how the companies practice reuse, but they also provide the reader with valuable reuse lessons and gems of practical reuse advice from the field. The purpose of the first chapter is to whet the reader's appetite for learning more about how to apply reuse in their work and to encourage corporations to seriously consider adopting the reuse software development paradigm.
The second chapter begins the reader's immersion into the details of reuse. In this chapter, the general question of how reuse changes the software process is explored. The reader is shown where reuse thinking and reuse tasks impact the software process. For example, strategic reuse planning is added to strategic systems planning tasks and reuse checking is added to system design reviews and inspections. The reader is shown that following a reuse paradigm means that the software life cycle process must start with reuse, end with reuse, and include reuse in all the stages in between. The three characteristics that a software process must have to enable it to support reuse are described. They are
1. Reuse Themes that govern software development decision making.
2. Reuse Requirements for broadening the development perspective from one system at a time to a family of related systems over time.
3. Reuse Views that slice the software development process into the Consumer and Producer sides of reuse.
Chapter 3 continues the explanation of how reuse changes the software life cycle process, but moves the reader down to the details level. Techniques, which are unique to reuse, fill in the missing details of how to practice reuse. Since reuse is a different software paradigm, a practitioner of reuse must master these reuse techniques. In all, sixteen reuse techniques are defined in the book.
The book divides reuse techniques into three categories:
1. Management Techniques that aid in the management of practicing reuse at the corporate reuse program level and the system development project level.
2. Consumer Techniques that aid developers in how to use reusable components to build software systems and their associated deliverables.
3. Producer Techniques that aid in the identification, creation, and packaging of software components for reuse.
Reuse techniques are of little value unless the reader understands where to apply them in the context of the software process. In Chapter 3, the reader is given a brief explanation of each reuse technique and is shown where each technique fits into the software life cycle process.
The second part of the book contains the substance of the book and the substance of how to practice reuse. It consists of sixteen chapters, each of which is devoted to a detailed, step-by-step procedural description of one reuse technique. A glossary of terms to clarify how the terms are defined in the “reuse world” is included at the end of the book. For example, the term “domain” has a different meaning in reuse terminology than in database terminology.
Each technique represents a synthesis of the ideas and experiences of industry reuse experts. Extensive references have been included at the end of each chapter to point the reader to material published by these experts. Many of the techniques presented in the book are industry-tested in the sense that they have been applied in practice by real corporations. Whenever possible, an example of how the technique has been used is included with the technique description.
The book closes with an Epilogue to remind the reader that implementing reuse correctly takes work, but because of the benefits reuse can deliver, it is well worth the effort.