Reuse and Management Issues

ESE Module 5-4

Reuse and Management Issues

learned the benefits of reuse. The wheel was probably

the first reusable design. Column and arch designs

that withstood the challenge of nature were reused

repeatedly by the engineers of antiquity. Machine

designs created in the 17th and 18th centuries are still

in use today. The list of reusable components in classi-cal engineering disciplines is almost endless. And what about software? After many false starts, the software industry is finally beginning to move toward component reuse.

Readings

The following reading is an edited and adapted ver-

sion of a series of articles written by Edward Berard in

the mid-1980s and posted on the Internet newsgroup comp.software.eng. This material is used with his permission.

Berard addresses many of the problems associat-

ed in achieving a reuse culture, discusses the techni-

cal aspects of reuse, and offers a few suggestions for

overcoming at least some reuse problems. It is interest-

ing to note that although Berard wrote this material in

the 1980s, the problems he defines and the solutions

he proposes are equally valid today.

A quick study of the possible benefits of reusing software

reveals that there is much more to be gained than a simple

cost savings during the development of a software product.

For example, the reuse of a software component which is

known to be reliable introduces less risk than redesigning

and recoding the same component for each new applica-

tion. Efficiency issues can also be more effectively address-

ed if one can focus attention on optimizing a set of reusable

components rather than having to continually reoptimize

newly recoded versions of previously existing modules.

However, it seems that [many companies] are greatly

confused about just what an increased emphasis on soft-

ware reusability might mean. While they might acknowl-

edge that some existing software development practices

will have to change, they seem unaware of which specific

items will be different. There are a number of very large

roadblocks to software reusability, and it should be useful

to mention a few of them.

1. Few companies and organizations have anything that

even slightly resembles a comprehensive software reusabil-

ity plan. Yes, many of these companies and organizations

have someone somewhere who is "researching" the idea.

However, few have any intention of implementing such a

plan any time in the near future. Let's face it: software

We're all guilty of it to some extent. Technologists wor-

ship technology. Even though experience indicates

otherwise, we believe that all problems could be

solved if only a better more robust, more adaptable,

more powerful technology were introduced.

Software people have fallen prey to technology

worship with every new technological advance: struc-

tured programming, new programming languages,

rapid prototyping, fourth generation techniques,

CASE, ... every new technology has been hyped as

the solution to the software bottleneck. And yet, prob-

lems persist.

With the widespread use of object technologies,

technology worship has escalated to new levels. And

that's a danger signal. It is true that object-oriented software engineering offers significant benefits. But it's also true that it must be coupled with a mature software process, good project management, solid SQA and SCM, thorough testing and a meaningful reuse strategy, if it is to achieve the benefits that have been advertised.

In this ESE module, we'll explore the infrastructure

that must be established to support object-oriented

methods:

·  reuse strategies

·  management for OO projects

·  object-oriented testing

Reuse offers significant potential and may lead to real

breakthroughs in software quality and development

productivity. But a number of technical and manage-

ment problems remain to be solved. We'll explore

these and examine potential solutions in this ESE mod-

ule.

An object-oriented project requires a somewhat

different management approach than a software

project that uses conventional methods. The primary

reason for this is the evolutionary nature of the object-

oriented paradigm and the need to encourage

reuse.

Finally, the testing of OO systems requires subtle

changes in testing strategy and tactics to accommo-

date the unique nature of the OO system. We'll con-

sider some of these changes.

Reuse and Reusability Strategies

Reuse is an engineering concept that dates back mil-

lennia, not decades. As art evolved into craft, and

craft matured into engineering, ancient cultures

5-4.2 ·· Essential Software Engineering

reuse is hardly a "top priority item" for many software

firms.

2. Examine the commercial marketplace. How many vendors do you see who are selling software reuse related

products? I am not referring just to reusable software mod-

ules. What about entire software reusability systems, or

tools specifically designed to aid and foster the reuse of

software. (Some vendors have taken old products and

placed the words "reuse" and "reusable" in their marketing

literature. While some of their claims may be true, the

reuse of software is not quite business as usual.)

3. Look at the software engineering training available.

How many courses whose main focus is software reuse can

you name? Compare that to the number of [object-oriented

programming / development courses] that are currently

offered. For that matter, how much emphasis is placed on

the reuse of software in the existing courses? Remember, it

is not only the technical staff who must be trained in soft-

ware reuse. Management must also be trained in software

reuse.

4. Examine the attitudes of the software personnel (pro-

grammers and managers) themselves. For some time now,

I have been participating in software reusability forums,

and I have become aware of many horror stories relating to

software reuse. For example, it is not uncommon to hear

technical personnel recite long lists of the "disadvantages

of reusing software." Managers seem equally committed to

maintaining the status quo. Even when managers purchase

the tools and training necessary for rudimentary software

reuse, staff resistance to the concept can still be high.

5. Many companies continue to encourage software

development methodologies which do not facilitate reuse

(e.g., functional decomposition), while discouraging others

that seem to encourage reuse (e.g., object oriented

approaches).

6. Few companies provide incentives to produce

reusable program components. In fact, there are disincen-

tives. The customer for the current project will be hesitant

to fund the extra expense required to develop reusable

components. As a result, project managers push to get the

job done with program components that are as specific as

is possible.

Finally, in addition to the technical problems which must

be addressed, we have to consider many other connected

issues. Political, managerial, legal, cultural, financial, mar-

keting, and productization issues must also be considered.

A Brief Technical Analogy

In the computer hardware industry, reuse is the norm. For

example, there are standard CPU chips, standard RAM,

mathematical coprocessor, and ROM chips. These, and

other, chips are used in a wide variety of applications. A

long time ago, electronics engineers discovered that one of

the most important axioms of reusability was generality.

Unlike their software counterparts, electronics engi-

neers do not have to verify, for example, that every "op-

code" supported by a particular CPU is executed in a spe-

cific application. Nor do they have to demonstrate that

every last byte of RAM is utilized. While the reasons for

this should be obvious, it would be helpful to point out a

few of them:

1) Once a CPU chip is created and verified, a known (and

typically very high) level of reliability can be established

for the chip. When this chip is reused in another applica-

tion, its known reliability can be factored into a determina-

tion of the overall reliability of the new system.

2) If a change is introduced into the software which is

running on a particular CPU chip, specifically a change

which now requires that a previously unused "op-code"

come into use, there is little need to replace (or alter) the

CPU chip. (Think of an Ada package as a chip, and the

operations in its interface as "op-codes." A similar argu-

ment could be made for the amount of random access

memory incorporated in a computer system.

3) As new engineers are assigned to a project, it is likely

that they may have experience with standard, reusable

chips. Even if they do not have experience with the specific

chips being used, there are certain fundamental concepts

which are common to particular classes of chips, and the

new engineers are likely to be aware of these concepts.

4) With the demand for computer hardware (everything

from embedded systems to stand-alone computers) at an

ever increasing high level, the cost and time required to

custom-design chips so that they are optimized for a specif-

ic application is prohibitive. {Notice that since few organi-

zations track real software costs, that it is often difficult to

make a similar justification for not overly-customizing soft-

ware.}

How does one apply the above analogy to reusable

software? Consider the design of a reusable software com-

ponent. To be truly reusable, a software component must

be usable in some place other than its current specific

application (or part of an application). To increase the

chances of this happening, the software engineer must

make the component more general. In fact, there are well-

known ways of increasing the generality of a software

component to a very high level.

Of course, there are trade-offs. Increasing the generali-

ty may decrease the efficiency, or even increase the com-

plexity. These, and other considerations, must be balanced

against such factors as the potential increased reliability

resulting from using a known verified component, and the

cost and times savings resulting from software reuse.

Some of the items which we now know about software

reusability are:

Reuse and Management Issues ·· 5-4.3

2..Require that software reusability be an integral part of

any technical and managerial training. This should be espe-

cially true for Ada and object-oriented training.

3. In accordance with your in-house software reusability

plan, acquire the tools and libraries you feel will most posi-

tively contribute to the reuse of software within your orga-

nization.

4. Encourage the use of methodologies and tools which

have been demonstrated to enhance the reuse of software.

5. Track and measure both the reuse of software and the

impact of software reuse. Policy decisions should be made

on "hard data," not on guesswork.

6. Management must let it be known that it actively

encourages the reuse of software.

7. Recognize that more than just "modules" can be

reused. Tools, test data, designs, plans, environments, and

other software items can be reused.

8. Above all, recognize that software reuse is not 'busi-

ness as usual." A commitment to software reuse will

require some changes. These changes should be introduced

in an effective manner. Remember that the concept of soft-

ware reuse is alien to most technical and managerial per-

sonnel.

The above suggestions are not the only ones that need to be

considered. I view them as a "starting point" for future dis-

cussions.

Edward V. Berard

Berard Software Engineering, Inc.

902 Wind River Land, Suite 203

Gaithersburg, MD 20878

Phone:(301)417-9884

FAX: (301)417-0021

Email:

Berard's company specializes in "Object-Oriented Training,

Consulting, Mentoring, and CASE Tools"

Exercise 5-7

Defining Reusable Components

Consider the application domain for the computer

software developed by your organization.

1. Write a one or two page description of the appli-

cation domain. What are the characteristics of the

problems you solve and the software products that

you build? What information is processed and what

form does the output take?

2. Apply a grammatical parse to your description

and isolate a set of potential objects (see ESE Module

5-2 for additional information on this approach).

·  Much more than source code can be reused. In fact,

designs, plans, test data, and documentation (among oth-

ers) can be reused. The smallest gains in productivity, relia-

bility, etc., are obtained by only reusing source code.

Reusing the documentation associated with "reusable

source code" greatly enhances any gains associated with

merely reusing the source code.

·  Reusability is not a concept that is limited to the cod-

ing phase of the software life-cycle. It must be a highly visi-

ble item from requirements analysis to the retirement of the

product.

·  Research seems to indicate, and practice seems to

show, that the majority of many software products can be

assembled from reusable components.

·  There are any number of metrics associated with soft-

ware reuse. They include metrics which measure the sheer

bulk of source code and documentation reused in an appli-

cation, to metrics which measure the affects of software

reusability, e.g., software productivity metrics.

Do we know what software reuse is. There are two

answers to this question. The vast majority of today's soft-

ware practitioners either do not know what it is, or assume

that it is "yet another buzzword." There is a small minority

of individuals and organizations who are researching and

implementing various aspects of software reuse.

Software reusability technology is indeed a collection

of things. These things include reusable components, tax-

onomies, reusability systems, composition concepts,

methodologies, and others. This technology is more cou-

pled with the size of the software product than it is with

"the scale at which the reuse is to take place."

Software design methodologies do play an important

part in software reuse. Some methodologies enhance soft-

ware reuse, others discourage it. We have known for some

time that software designs should be constructed so that

they can easily be modified. We are only now beginning to

understand that by bringing software reusability issues to

the first phases of the software life-cycle, we can greatly

enhance the impact of software reusability. Finally, by

studying the designs of many systems within a particular

application domain we are finding designs are very much

reusable, e.g., consider the basis for many fourth-genera-

tion languages.

Some Suggestions