Software Reuse, Facts and Myths - K. Wentzel

7/28/2019 Software Reuse, Facts and Myths - K. Wentzel

1/9

Software Reuse - Facts and Myths

Kevin D. Wentzel

Hewlett-Packard Laboratories1501 Page Mill Road, Palo Alto, CA, 94303, USA

[email protected]

Abstract

The concept of systematic software reuse is simple: the idea of building and using "softwarepreferred parts."By building systems out of carefully designed, pre-tested components, one will

save the cost of designing, writing and testing new code. Thepractice of reuse has not proven tobe 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 likecomputers. 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 thatreuse 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 majorimprovements 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 aredesigned 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 indiscussions 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'veexplained a few ofmy own below.

2.1 Libraries

One very common myth about reuse is, "The larger your software library, the more reuse you

will achieve."


2/9

While code library use is common and helpful, most libraries handle only low-level, genericparts, 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 enoughemphasis 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 codeor 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 reuseprograms we have found, there are a very small number of reusable components however thesecomponents 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 tobe 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. Thesystematic 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 consumereusable software workproducts. Effective software reuse needs a clear division amongthe roles ofproducers of reusable workproducts and consumers who use them to build

applications. Changes in management and support structures are needed to support thenew 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 andtechnologies to take advantage of reuse. Applications will no longer be designed

independently, one at a time. Instead, conscious effort will be made (DomainEngineering) to design reusable assets for a range of expected applications and newapplications 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 onwhen 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 termpayback 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. Benefitsof 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 producingproject 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


3/9

HP Laboratories started a multi-disciplinary software reuse research program in 1992 tocomplement 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 andflexible software factories. Thedomain-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 workconcentrates 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 seriesof 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 SoftwareFactory. 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 InstituteforAdvanced 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 ormyths 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 includeproduct 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 experiencesuch 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 someexperiences, 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 impliessome 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.


4/9

When trying to reuse any form of experience, some form of modification is typically required toadjust 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 considerthis 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 ofthe 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 haveminimized our opportunities for reuse.

Fact 3: Software development processes do not explicitly support reuse, i.e., in fact theyimplicitly inhibit reuse

If reuse of an artifact requires modification, Who does it, who pays for it, and when does it getdone? 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 theshortest 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 experiencesfor 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, duringproject development, must be supported by the appropriate processes and sufficient resources.

The reuse of experience has not been fully incorporated into the development or maintenanceprocess models.

Software Reuse Experience at Hewlett-Packard

Martin L. Griss

Hewlett-Packard Laboratories

1501 Page Mill Road Palo Alto. CA [email protected]

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 CorporateReuse 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 poorlyunderstood, 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 toavoid 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 amulti-disciplinary research program to investigate and develop better methods for domain-

specific, reuse-based software engineering.

We have learned that for large-scale reuse to work, the problems to overcome are mostly non-technical. 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 paradigmchange, leading to the creation, management and use of persistent software assets. This links

previously independent project lifecycles into a laboratory- or organization-wide process.


5/9

Management support is critical - reuse is not a "grassroots" effort. While many engineers feelthat 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 canonly 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 essentialto 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 rarelysucceeds. Careful consideration must be given to the way reusable workproducts must be

designed, packaged and managed. We advocate a distinct component producing organization, orat 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 theconfidence 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 ensurethat the right goals are addressed. For example, overall development productivity (cost savings),

appears less significant than the cost savings attributed to improved quality and decreasedmaintenance.

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 TraczLoral Federal Systems Company Owego. NY

[email protected]

It has been six years since the author published the paper Software Reuse Myths in ACMSoftware 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 sixyears. 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, isattempting to come up with standards for reusable components and their interchange through

common library access methods. Furthermore, recent efforts within the DoD to changegovernment acquisition policies will further stimulate the industry. Finally, with copyright law


6/9

now being re-interpreted by the courts to allow for more flexibility in developing plugcompatible 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-The-Shelf) 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 reuseenvironments. 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. Whilethey 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 artifactsassociated 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 insolving 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 hasbeen 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 ofreusing 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% for additional generalization

15% for additional documentation

10% 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% ondocumentation 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 makingcertain 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 commonground 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 itsknowledge acquisition and representation experience, has a lot to offer to support this kind of

reuse. In fact, machine learning and knowledge acquisition closely resemble applicationgenerators and domain analysis -- both fundamental to software reuse.


7/9

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 investedin 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 theyhaven'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 lendsitself 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 someparameterization 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 component-based 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' thatmakes 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 object-oriented 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 thescience, 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 togetherwith, 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 beplanned 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). Iam 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.


8/9

Reuse Facts and Myths

Michael WasmundIBM 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 ashaving 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 andpolymorphism, 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 typeof 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 anenabling platform for high degrees of reuse ifexplicitly planned forand appropriate actions

taken. Ignoring this experience leads to generation of software which is object-oriented but notreusable 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 reusablesoftware, 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 theestablishment of quantitative targets for reuse. At IBM's system software development site in

Boeblingen, Germany, we did test both approaches: Mandating reuse targets significantly raisedthe 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. Itmust 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 whichbenefits 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 developmentinto 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. Toobtain this flexibility, significant investment must be made at an early stage, spanning all phases


9/9

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

Software Reuse, Facts and Myths - K. Wentzel

Documents

Transcript of Software Reuse, Facts and Myths - K. Wentzel