Software Reuse - Facts and Myths Kevin D.

Wentzel Hewlett-Packard Laboratories 1501 Page Mill Road, Palo Alto, CA, 94303, USA wentzel@hpl.hp.com Abstract The concept of systematic software reuse is simple: the idea of building and using "software preferred parts." By building systems out of carefully designed, pre-tested components, one will save the cost of designing, writing and testing new code. The practice of reuse has not proven to be this simple however, and there are many misconceptions about how to implement and gain benefit from software reuse. This panel brings together several researchers and practitioners of software reuse to discuss what they see as some of the most important facts and myths about software reuse. 1 Introduction Software is constantly increasing in its importance in product development. Currently at Hewlett-Packard Company, approximately 70% of our engineers do some software development. In many products, it is now software that provides the competitive advantage. This is true both in computers and in products like laser printers and oscilloscopes which don't look much like computers. Systematic software reuse is a key business strategy that software managers can employ to improve their software development processes, to decrease time-to-market and costs, and to improve product quality. The concept of systematic software reuse is simple: the idea of building and using "software preferred parts." By building systems out of carefully designed, pre-tested components, one will save the cost of designing, writing and testing new code. In practice, there are many technical, process, economic and organizational issues to overcome. However, several companies find that reuse does work, and can payoff handsomely with high levels of reuse. There are significant corporate reuse programs at AT&T, HP, IBM, GTE, NEC, Toshiba, and others. They see major improvements in time-to-market, quality and costs[l]. To be successful, a reuse program requires much more than just reusable code modules and library technology. Careful consideration must be given to the way reusable workproducts are designed and packaged, to the architecture and framework in which reusable workproducts are combined, and to organizational and economic structures. 2 Facts and Myths about Reuse Because reuse is such a simple concept, we have found many misconceptions about it in discussions with software developers and software engineering researchers. The panelists are expected to explain what they view as the most important facts and myths about reuse. I've explained a few of my own below. 2.1 Libraries One very common myth about reuse is, "The larger your software library, the more reuse you will achieve."

While code library use is common and helpful, most libraries handle only low-level, generic parts, leading to low levels of reuse. In many cases, libraries are built by collecting pieces of potentially reusable code from existing applications and from new developments without enough emphasis on standards for quality, documentation, architecture, and testing. Current library research is focused on classification, library tools and library interoperability. To get high levels of reuse and consequent high levels of benefits, one needs more than just code or object libraries. One needs to deal with the careful design of reusable architectures and components that fit together for particular domains and with the systematic introduction and institutionalization of reuse in the development organization. In several of the successful reuse programs we have found, there are a very small number of reusable components however these components are architected to work together to make up a sizable percentage of a delivered system. In these systems the architecture is carefully designed to allow additional functionality to be added for features not covered by the reusable modules. A library management system is unnecessary in these reuse programs. 2.2 The software development process Effective reuse is not a simple addition to existing software development processes. The systematic application of software reuse will dramatically change the software process [3]. Two of the most important changes are: Changes in the way software entities will organize themselves to produce and consume reusable software workproducts. Effective software reuse needs a clear division among the roles of producers of reusable workproducts and consumers who use them to build applications. Changes in management and support structures are needed to support the new roles. Changes in the way developers are evaluated and rewarded may be required to reinforce the new roles. Changes will be made in software development models, methods, processes and technologies to take advantage of reuse. Applications will no longer be designed independently, one at a time. Instead, conscious effort will be made (Domain Engineering) to design reusable assets for a range of expected applications and new applications will be designed to take maximum advantage of the available software preferred parts.

2.3 Reuse payback When a reuse program is started, the organization needs to have appropriate expectations on when a return on the investment will be realized. Reuse has proven to be a long term investment showing benefits over a series of projects often spanning several years [4]. When a short term payback is expected, disappointing early results can cause a program to be canceled before it has a chance to pay off. Benefits of a reuse program are more than cost savings on projects. Benefits of earlier time to market and of decreased long term maintenance costs must also be taken into account when evaluating a reuse program. Since reuse changes roles and organizations and may require new organizational structures, funding the production, use, and maintenance of components can be a thorny issue in today's business environment. The reuse producers may not be attached to a particular profit producing project and can be viewed as a cost center. This leaves them vulnerable to cuts when budget adjustments must be made. 3 Reuse research at Hewlett-Packard

HP Laboratories started a multi-disciplinary software reuse research program in 1992 to complement HP's Corporate Reuse Program [1,2]. An integrated approach to technology, method, process and organization issues is key to our research program. The research has two major theme: domain-specific kits and flexible software factories. The domain-specific kit research focuses on the technologies and methods for the production use and support of kits for application development, while the flexible software factory work concentrates on the processes, organization design, economic issues, and software engineering and communication infrastructures for kit-based software development. We are testing the ideas of domain-specific kits and flexible software factories through a series of prototypes and pilot projects in Hewlett-Packard product divisions. References [1] Martin L. Griss, John Favaro, and Paul Walton. Managerial and Organizational Issues Starting and Running a Software Reuse Program, chapter 3, pages 51-78. Ellis Horwood, Chichester, GB, 1993. [2] Martin L. Griss. Software reuse: from library to factory. IBM Systems Journal, 32(4):1-23, November 1993. [3] Martin L. Griss and Kevin D. Wentzel. Hybrid Domain-Specific Kits for a Flexible Software Factory. In proceedings: SAC'94, Phoenix, Arizona, March 1994. [4] J. E. Gaffney and R.D. Cruickshank. A General Economics Model of Software Reuse. In proceedings: 14th ICSE, Melbourne Australia, May 1992.

Facts and Myths affecting Software Reuse Victor R. Basili Institute for Advanced Computer Studies and Department of Computer Science University of Maryland College Park, Maryland 20742 For this panel, we were asked to discuss what we thought were the three most important facts or myths affecting reuse. I believe there is a great deal of misunderstanding about reuse in the software domain and it is difficult to pick out only three, but I will try. Fact 1: There has been too much emphasis on the reuse of code. There are an enormous variety of 'experiences' that can be reused, other than code. These include product artifacts, such as design, architecture, requirements, user's manuals and test plans; processes such as life cycle models, methods, and techniques, and other forms of experience such as cost models, baselines of defect classes, etc. Sometimes, reuse of some objects, e.g., product architectures, directly enable the reuse of others, e.g., code. Sometimes the reuse of some experiences, make it difficult to use others. For example, it is difficult to reuse a code module in an object oriented design that was developed using functional design. The ability to reuse implies some form of domain analysis has been done to identify the appropriate contexts for reuse of the particular object under consideration. Fact 2: Software reuse implies some form of modification of the artifact being reused.

When trying to reuse any form of experience, some form of modification is typically required to adjust the object to the context in which it will be used. The simplest case is where the modification is the substitution of a parameter, e.g., the square root(x) and we typically consider this verbatim reuse. But most cases are more complex; the basic framework can be reused but the parts need to be changed, e.g., the format of a requirements document can be reused but most of the requirements are new. The goal is to maximize the amount of information reused. However, if we view the reuse decision as a binary switch, verbatim reuse or not at all, then we have minimized our opportunities for reuse. Fact 3: Software development processes do not explicitly support reuse, i.e., in fact they implicitly inhibit reuse If reuse of an artifact requires modification, Who does it, who pays for it, and when does it get done? There is an implication that someone must package artifacts to make them reusable. This is hard to do during project development, where the goal is to get the product out the door in the shortest time possible. Thus, other resources (time, people, money) must be expended to package artifacts to maximize their potential for reuse. These activities include the analysis, generalization, tailoring, and formalization of existing experiences and must not be on the critical path of the project. One such option is to create an organization whose role is to analyze and synthesize experiences for reuse. On the other hand, the development processes themselves need to be defined to take advantage of these reusable artifacts. i.e., searching and modifying experiences on-line, during project development, must be supported by the appropriate processes and sufficient resources. The reuse of experience has not been fully incorporated into the development or maintenance process models. Software Reuse Experience at Hewlett-Packard Martin L. Griss Hewlett-Packard Laboratories 1501 Page Mill Road Palo Alto. CA 94301-1126 griss@hpl.hp.com At Hewlett-Packard, we have had visible divisional software reuse efforts since the mid-1980s. Most of these efforts were started with the goal of reducing time to market, improving software productivity, or improving product consistency. In 1990 we initiated a multi-faceted Corporate Reuse Program to gather information about reuse from within HP and from other companies. As we studied the existing reuse programs, we discovered that certain issues were poorly understood, and as a consequence, mistakes were made in starting and running certain programs at HP and elsewhere. Our corporate reuse program focused on packaging best-practice information and guidelines to avoid common pitfalls. We also developed technology transfer and educational processes to spread this information and enhance reuse practice within the company. In 1992 we launched a multi-disciplinary research program to investigate and develop better methods for domainspecific, reuse-based software engineering. We have learned that for large-scale reuse to work, the problems to overcome are mostly nontechnical. Reuse efforts that focus only on building a library, and worse, on f1fSt building a library system, will not achieve their goals. Achieving high-orders of reuse requires a paradigm change, leading to the creation, management and use of persistent software assets. This links previously independent project lifecycles into a laboratory- or organization-wide process.

Management support is critical - reuse is not a "grassroots" effort. While many engineers feel that reuse is just a technical problem, and so can be handled informally, the process and organization change required to assure that high-quality software components is produced can only be funded by a concerted, dedicated management effort. Furthermore, it will take several years to build up the experience and asset base, and high-level management support is essential to sustain the commitment. Management, with the support of a process improvement team and reuse, must integrate people, process and technology issues.

Software entities must think about how they are organized, and how work is partitioned. Often, managers will say "produce that product, and on the way, produce components too." This rarely succeeds. Careful consideration must be given to the way reusable workproducts must be designed, packaged and managed. We advocate a distinct component producing organization, or at the least, a component support organization, that can take candidate (potentially reusable) software and carefully package, document, and certify them. Only then will users feel the confidence to build their products using these components. The kind of kit methods and technology and the kind of organization and processes needed should be based on the specific business situation, such the stability of the application domain, what business issues (such as time to market, conformance to standards, interoperability) drive the factory. Economics models and metrics must be developed, adapted and deployed to ensure that the right goals are addressed. For example, overall development productivity (cost savings), appears less significant than the cost savings attributed to improved quality and decreased maintenance. This seems like a lot of work, just to achieve reuse. Fortunately, one does not need to go all the way in one giant step. We believe that one can choose an investment level, based on experience, to get an increasing number of benefits. An incremental adoption strategy will include several steps. such as: Leverage or Cloning; Black-box Code Reuse; Broad Workproduct Reuse; Architected Reuse; and. Systematic Software Reuse. As one moves from step to step, we get increased benefits. Each step should be tested with a pilot project before widespread deployment. Our research and pilot work includes the development and study of formal adoption processes, domain-specific kits, business modeling, organization design, and technology infrastructure for a flexible software factory. Software Reuse Myths Revisited Will Tracz Loral Federal Systems Company Owego. NY tracz@Ynet.ibm.com It has been six years since the author published the paper Software Reuse Myths in ACM Software Engineering Notices [tracz87h]. This short paper comments on these "myths" in light of recent technology advances. Myth #1: Software Reuse is a Technical Problem Three major non-technical impediments to reuse have diminished somewhat over the last six years. There has been some consensus building efforts focused on coming up with standard definitions for reuse and reusability. The RIG (Reuse Interoperability Group), for example, is attempting to come up with standards for reusable components and their interchange through common library access methods. Furthermore, recent efforts within the DoD to change government acquisition policies will further stimulate the industry. Finally, with copyright law

now being re-interpreted by the courts to allow for more flexibility in developing plug compatible solutions (that may have some common design structure but no common code), the software marketplace is poised to better be served by competitive COTS (Commercial Off-TheShelf) offerings for reuse. On the technical side, research in process programming, persistent object bases, and knowledge representation and manipulation show potential for facilitating the creation of fertile reuse environments. The success of ARPA's Domain-Specific Software Architecture program also provides valuable credibility to reuse in general. Myth #2: Special Tools are Needed for Software Reuse Integrated CASE tools, when they get here, have the potential to enhance software reuse. While they are not necessary for reuse, they do go a long ways toward making reuse fun. They will facilitate the traceability of requirements to design and code, along with the other artifacts associated with software development. Reusable software can be thought of as a CASE tool in itself in that reusable software components are just another tool that should be leveraged in solving problems. Myth #3: Reusing Code Results in Huge Increases in Productivity There has been a lack of good empirical data related to reuse success stories. There really should be more data out in the literature, but there isn't. While it is true that in some instances, reuse has been shown to result in a 20 to 1 reduction in effort for "certain" stages in the development life cycle, this should be placed in perspective with the "cost" of reuse. There are three costs associated with reuse: the cost of making something reusable, the cost of reusing it, and the cost of defining and implementing a reuse process. Focusing on the cost of making software reusable, a conservative breakdown is a follows: 25% 15% 10% for additional generalization for additional documentation for additional testing

5% for library support and maintenance ______________________________________ 60% additional cost of making something reusable The subtle/sad thing is, reusability is quite subjective. Who can say that spending x% on documentation will make it y% more reusable, or an additional z% spent generalizing will make it q% more reusable1 Obviously, you don't just "spend the money", you focus it on making certain attributes of the software "better". Myth #4: Artificial Intelligence Will Solve the Reuse Problem I have always been skeptical of "imitation intelligence." Recently, through my involvement in the ARPA DSSA community, I have become convinced that software reuse is the common ground where AI and software engineering will meet. It is becoming more and more apparent that one needs to reuse more than just code to gain increased benefits from reuse. AI, with its knowledge acquisition and representation experience, has a lot to offer to support this kind of reuse. In fact, machine learning and knowledge acquisition closely resemble application generators and domain analysis -- both fundamental to software reuse.

Myth #5: The Japanese Have Solved the Reuse Problem The Japanese continue to do good things by taking an evolutionary rather than revolutionary approach. They have recognized the non-technical inhibitors to software reuse and have invested in creating the assets and processes to support reuse. As I have previously stated "Before you can reuse software, you need software to reuse." They have addressed this issue head on, though they haven't declared victory yet. Myth #6: Ada has Solved the Reuse Problem Ada has not, nor will not go away. Ada9X has made claims to have increased support for reusability in the form of an anemic inheritance mechanism and object types (but it still lends itself for improvement as well as abuse). As far as a language that promotes reuse goes, C++, as baroque as it is, has almost become the defacto standard, but again, it is missing some parameterization capabilities that would enhance its applicability. Myth #7: Designing Software from Reusable Parts is like Designing Hardware using Integrated Circuits I have wavered on the position I took on this point five years ago, as the analogy of componentbased software design and component-based hardware design is conveniently seductive. (Yes Brad Cox, I hate to admit you may be right with your software-IC analogy.) The big "if' that makes me want to agree with the analogy is "if software interfaces were defined as crisply as hardware interfaces" then I would believe the myth is true, especially in light of all the objectoriented religious fervor that has been so popular of late. But of course, there are no catalogs of components, outside of user interface widgets. The reason may still lay in the immaturity of the science, or in that we do not understand the complexity of integration. Said another way, we don't understand the types of glue/solder that are needed to connect the components together with, nor do we have standard bus protocols to let us hook up larger components. Myth #8: Reused Software is the Same as Reusable software This point needs no discussion. With several reuse standards for "designing software for reuse" available, it is testimony that reusability, like quality, is an attribute of software that must be planned for. It is refreshing to see that the government is finally recognizing the difference between "unplanned/opportunistic" reuse, which it (and others in industry call "salvaging") and "planned" reuse. Myth #9: Software Reuse Will Just Happen In five years time, reuse has been given a lot of press, but it really has not blossomed. I am encouraged by the DoD initiatives (e.g., STARS, ARPA's DSSA, and tile DISA CIM effort). I am also pleased by the progress HP and IBM have made at institutionalizing software reuse as part of tile Corporate programming strategy. The bottom line is that software reuse is maturing. It has learned to crawl and in the next 5 years, may even walk upright without dragging its knuckles. References [Tracz87h] W.J. Tracz, Software Reuse Myths. ACM Software Engineering Notes, volume 13, Number l, January, 1988, Pages 17-21.

Reuse Facts and Myths Michael Wasmund IBM Geffi1any, Schoenaicher Str. 220, D-71032 Boeblingen The following is the view of a practitioner rather than of a scientist. Myth #1: OO eats up Reuse Fact #1: OO does not automate Reuse, both can complement each other. Non-technical, i.e., management circles are increasingly frustrated by the slow progress of reuse in terms of realized .Return of Investment. Object-oriented technologies are often viewed as having reuse 'built-in', thereby enabling the introduction of two technologies at once with reduced effort. This view is supported by attributes of OO technology, namely inheritance and polymorphism, which provide adaptability of available objects to diverse environments. Reuse is a software engineering discipline rather than a technology. It can be applied to any type of software assets; be it class libraries or 3rd generation software. OOT is in no way a replacement for reuse, OOT does not automatically yield high reuse rates, but OOT is an enabling platform for high degrees of reuse if explicitly planned for and appropriate actions taken. Ignoring this experience leads to generation of software which is object-oriented but not reusable beyond a very limited scope. Myth #2: Incentives are key to Reuse Success. Fact #2: Incentives create awareness, are cheap but don't change much. Major companies established incentive programs to stimulate reuse and consider this helpful particular in the beginning stage. However, massive progress caused by incentives is seldom reported. To my opinion, the reasons are: First, traditionally organized development teams are 'booked' to an extent, which doesn't provide any extra space for efforts to build reusable software, even if encouraged. Second, when accepting an award, individuals, who displayed the desired behavior even before establishment of the incentive program, mostly win. Third, incentives are an external motivation, which can yield temporary compliance to desired behavior, whereas intrinsic permanent motivation is not generated. An alternative way is the establishment of quantitative targets for reuse. At IBM's system software development site in Boeblingen, Germany, we did test both approaches: Mandating reuse targets significantly raised the level of practiced reuse in general, whereas incentives helped to create awareness, didn't cost much, and didn't change much. Myth #3: Reuse is for free. Fact #3: Reuse is a mid-tern investment impacting the entire software development process. It must be based on a product strategy which spans several releases or a family of products. A frequently practiced initial approach to reuse is the traditional common code concept which benefits the single project. I consider this concept helpful, but do not expect significant improvements by this for the future. A more advanced approach is the transformation of traditional incremental product development into a growing collection of interoperable software assets, forming a product building kit. The kit provides the enterprise with essential flexibility when responding to future market demands. To obtain this flexibility, significant investment must be made at an early stage, spanning all phases

of the development cycle, from domain analysis to maintenance. Short-sighted investments in reuse are cheaper but return nothing.