Reengineering

Software
How to R euse
Programming
to Build New,
State-of-the-Art
Software
Second Edition

Roy Rada
First published 1999 by Glen lake Publishing Company, Ltd.

Published 2021 by Routledge

2 Park Square, Milton Park, Abingdon, Oxon OX 14 4RN
605 Third Avenue, New York, NY 10017

Routledge is an imprint of the Taylor & Francis Group, an informa

business

Copyright © 1999 by Taylor & Francis

All rights reserved. No part of this book may be reprinted or

reproduced or utilised in any form or by any electronic, mechanical,
or other means, now known or hereafter invented, including
photocopying and recording, or in any information storage or
retrieval system, without permission in writing from the publishers.

Notice:
Product or corporate names may be trademarks or registered
trademarks, and are used only for identification and explanation
without intent to infringe.

Library Edition: Fitzroy Dearborn Publishers, Chicago and London

ISBN: 1-57958-183-8

ISBN 13: 978-1-57958-183-l (hbk)

C ontents

P re fa c e ................................................................................................. vii

Chapter 1—Introduction........................................................................ 1
The N e e d ................................................................................................. 1
What is Reuse? .......................................................................................3
Types of Reuse .......................................................................................5
Domain A nalysis.....................................................................................6
Hypertext................................................................................................. 7
Epilogue..................................................................................................11

Section 1— Background

Chapter 2—The Software Life Cycle ................................................. 15

Requirements......................................................................................... 17
D esign................................................................................................... 20
Implementation .................................................................................... 22
Testing and Documentation ..................................................................24
Maintenance...........................................................................................27
Standards............................................................................................... 28
Epilogue ............................................................................................... 34

Chapter 3—Management ........................... 35

Software Team Organization ................................................................35
Process M odelling................................................................................ 39
Software Project M odelling..................................................................42

iii
iv Contents

Scheduling.............................................................................................44
Epilogue ............................................................................................... 46

Section 2—Enterprise & Standards

Chapter 4—Reuse Framework ........................................................... 49

Process Idioms and Sources..................................................................50
Reuse Management .............................................................................. 52
Asset C reation.......................................................................................55
Asset Management................................................................................ 57
Asset Utilization .................................................................................. 61
Costs versus B enefits............................................................................ 63
Legal Issues...........................................................................................66
Im p a c t................................................................................................... 68
Epilogue ............................................................................................... 69

Chapter 5—Standards.......................................................................... 71
Expectations...........................................................................................72
Existing Related Standards....................................................................74
Recommendations ................................................................................ 80
Conclusion............................................................................................. 86

Section 3— Organize to Reorganize

Chapter 6—Organizing........................................................................ 91
Indexing................................................................................................. 91
Document Outlines .............................................................................. 94
Domain M odels.....................................................................................97
Code Organization...............................................................................101
Frameworks......................................................................................... 104
Epilogue............................................................................................... 106

Chapter 7—Retrieving ...................................................................... 107

Retrieval Specification........................................................................ 107
Document R etrieval............................................................................ I ll
Program Retrieval ...............................................................................112
Retrieval Systems.................................................................................116
Contents v

Monitoring Retrieval .......................................................................... 122

Epilogue................................................................................................124

Chapter 8—Reorganizing.................................................................. 127

Retrieved Component Suitability........................................................128
Document Reorganizing...................................................................... 130
Program Reorganizing........................................................................ 132
Code Generators...................................................................................139
Testing and Reuse ...............................................................................142
Epilogue................................................................................................144

Section 4— Practical Examples

Chapter 9—Software Reuse Tools ................................................... 149

CASE....................................................................................................149
Practitioner........................................................................................... 154
M U CH ..................................................................................................168
SoftClass ............................................................................................. 170
A User Interface Generator ................................................................176
Epilogue................................................................................................180

Chapter 10—Case Studies ................................................................181

Successful Commercial Cases ............................................................181
Practitioner and the ABB Steel Works ............................................... 183
IBM R euse........................................................................................... 185
The IBM Boblingen Experience..........................................................186
An IBM Reusable Parts Centre............................................................192
HP R euse............................................................................................. 193
Motorola Reuse ...................................................................................196
CIM-EXP............................................................................................. 198
Epilogue................................................................................................198

Chapter 11—Courseware R e u s e ....................................................... 201

Courseware Standards ........................................................................ 202
Small C om pany.................................................................................. 205
Coordination .......................................................................................211
Educational Object Economies........................................................... 217
Epilogue............................................................................................... 220
VI Contents

Chapter 12—Conclusion.................................................................... 221

Representations ...................................................................................221
Industry V iew .......................................................................................222
Government View .............................................................................. 224
Costs and B enefits.............................................................................. 226
Analogy to Traditional Libraries......................................................... 227
Epilogue............................................................................................... 228

Appendix I—Selected Glossary......................................................... 231

Appendix II—References..................................................................237

Index................................................................................................... 249
Preface

At first glance, software reuse appears a natural way to develop software,

but in practice this does not happen. The challenges are numerous and
require a fresh approach to the entire range of activities involved in the
engineering of software. Every time new software is needed developers
tend to write from scratch rather than harness components developed
through previous projects. Why this is so and how it can be changed will
be explored in this book.
This book addresses the state of the art, principles, approaches, sup-
port systems, underlying methodologies and real cases in software reuse.
Document-oriented versus object-oriented approaches to reuse are dis-
cussed and compared and some software reuse support systems, incorpo-
rating both approaches, are described. Standards are emphasized, as is the
influence of the World Wide Web in the spread of reuse practice. The
theme throughout is that reuse is fundamental to software engineering but
under-appreciated and under-practiced.

First Edition
The first drafts of this book began in 1988 when Section 1, ‘Background,’
was written for a course on software engineering. Section 2, ‘Reuse
Processes’ and Section 3, ‘Practical Examples,’ began with the joining of
Roy Rada s research group in the European ESPRIT Practitioner Project
on software reuse. Three researchers at the University of Liverpool,
Weigang Wang, Karl Strickland, and Cornelia Boldyreff, were particular-
ly active in the Practitioner work. Hafedh Mili of the University of
Quebec at Montreal is the leader of the SoftClass project that is described

VII
viii Preface

in this book and was a regular contributor to the Practitioner project.

Many of Mili s ideas and descriptions are included in this book. Important
other participants in the Practitioner project who indirectly contributors to
this book include Lene Olsen, Jan Witt, Peter Elzer, and Jurgen Heger. In
1992 Stuart MacGlashan and Michelle Usher began work on background
material for the book and in 1993 Renata Malinowski and Claude Ghaoui
became active contributors. All of the above listed people deserve a very
major thanks for their contributions. Stuart MacGlashan particularly
invested a large amount of time in developing textual and graphical con-
tent and took the book as his special project. He deserves the largest
acknowledgement.
The first edition of this book was published in 1995. The author
believes in reuse and the book was intended to show how a systematic
approach to document reuse can lead to good results. In the end, the con-
certed efforts of Stuart and then Roy were required to bring cohesiveness
to the book. A team of people involved in reuse must communicate exten-
sively to produce one seamless product and this was more easily achieved
by one person working for a long time than many people working for a
short time. The outline of the original book was based on a published
paper that had a balanced outline which is based on organizing, finding,
and reorganizing documents and objects (Rada et al, 1992). Based on ear-
lier work (Rada and You, 1992), this balanced outline was expected to
guide the collaborative production of a cohesive book. In the end, rela-
tively little of the book, only parts of Section 2 actually reflected this bal-
anced outline. Again the expectations for reuse are not always reflected
in practice. The jury is still debating about the best ways to achieve reuse.
The question is not whether reuse is good but rather how to identify the
circumstances in which reuse can be effective. Reuse depends not only on
the character of the available information but also on the management of
the authoring team. The contributors to this book are committed not only
to further exploration of the principles of reuse, but also to the practice of
reuse in everyday affairs.

S e c o n d Edition
One of the greatest impacts on reuse is the widespread accessibility of
document and software archives through the World Wide Web. Tht!
spread of the web has also stimulated further development of software
and information systems whose components can be reused. In other
words, the needs and opportunities for reuse have significantly grown.
Preface IX

Since this book appeared in 1995, several other reuse books have
appeared on the market—a good sign of the topic s increasing impor-
tance. The other new books fall into a few, general categories: selected
conference papers, managing software reuse, special tools or libraries for
reuse, and general reuse overviews. For example, new books in the cate-
gory of selected conference papers include a conference on correctness
and reusability (Wieringa and Feenstra, 1995). Such a book is more
focused and less cohesive than this book. In the topic of managing reuse
were new books by Lim (1995) and Tracz (1995) that were specifically
about managing or institutionalizing software reuse. The book in your
hand does emphasize the importance of managerial and institutional
approaches to software reuse, but covers, in some depth, the more asset
specific topics. In the category of special tools are many books, such as a
book on reusable Unix software (Krishnamurthy, 1995) and one on reuse
metrics (Poulin, 1997). The book in your hand addresses reuse of Unix
software components and metrics of reuse but only as part of the book
rather than the theme of the book.
Finally comes the category of general-purpose book into which this
book falls. Here there seem to be fewer books than in the other three cat-
egories but still the reader has options. For instance, the book by Bassett
(1997) suits the strong, contemporary interest in frameworks. This par-
ticular book is less scholarly in its intentions than the book in your hand.
Comparisons could continue in this fashion but suffice it to say that this
book attempts to cover the field broadly and concisely. Furthermore, this
second edition has been updated to reflect developments of the past two
years.

The book is divided into four major sections entitled:

1. Background
2. Enterprise and Standards
3. Organize, Retrieve, and Reorganize
4. Practical Examples

The Background Section looks at the software life cycle and software
management. The Enterprise and Standards Section presents first a con-
ceptual framework for reuse that emphasizes enterprise issues and second
the important standards are germane to reuse. The Organize, Retrieve,
and Reorganize Section examines reuse from the perspective of organiz-
ing a library, retrieving items from the library, and reorganizing or tailor-
ing the assets thus retrieved to make a new product. The Practical
X Preface

Examples Section considers tools, case studies of organizations, and

takes a special look at the domain of courseware reuse.
The chapter on software reuse standards is new to the second edition.
It is based on the work of the Software Engineering Standards Committee
Reuse Group and columns co-authored with James Moore. The software
engineering community has decided that object-oriented engineering is
not the panacea that it was once claimed to be and is now talking about
patterns and frameworks. Patterns and frameworks extend the object-ori-
ented paradigm to deal at a larger level of granularity. This trend towards
patterns and frameworks is reflected in various sections of the book.
The courseware chapter has been augmented with new results in the
form of web-based libraries of reusable components and standards for
courseware reuse. Courseware serves as an example of the kind of devel-
opments that one would find across many domains in which increased
web access and demand for software has lead to new libraries and high-
level tool sets. Furthermore, courseware about reuse could be important
in supporting education about reuse itself. A key barrier to improved
reuse practice is the lack of adequate education about reuse itself.
The author and publisher of this book want to build on the value of
the information superhighway to the reader. Accordingly, the book is
available for free in electronic form on the World Wide Web—this dis-
tinguishes the book further from the other books on reuse. Also the book
is integrated into a virtual classroom and is available in that way on the
web. The book and the course can be found by visiting the author s home
page on the web. The author is also helping create a Virtual Information
Technology College under the sponsorship of the Globewide Network
Academy. Part of the intention of the new college is that teachers, stu-
dents, and others can participate in the College by studying a course and
also by contributing to the evolution of the software infrastructure of the
Virtual College. This will provide an opportunity for students to both
study and practice reuse at the same time.
C hapter 1
In t r o d u c t i o n

During the last decade, the gap between the demand for new complex
software systems and the supply has widened. This gap and the difficul-
ties faced by software engineers in bridging it have been described as the
Software Crisis, whereby systems have become so large and complex that
creating software for them is increasingly more difficult to complete on
time and within the constraints of the project budget. Software reuse is of
growing importance as a major factor in alleviating some of the problems
resulting from the Software Crisis.

The Need
Engineering is about using knowledge of natural principles from science
and technology to design and build artifacts. In the early 20th century, an
engineer was one who designed and supervised the execution of physical
systems. In the late 20th century, the notion of engineering has been
extended. For instance, Webster’s Dictionary defines engineering as ‘the
application of science and mathematics by which the properties of matter
and the sources of energy in nature are made useful to man in structures,
machines, products, systems, and processes’. A process is not necessari-
ly physical.
In the first 35 years of computer history the emphasis was on hard-
ware developments, but now the emphasis has shifted more toward
human concerns. As late as the mid-1950’s, 90 percent of application
costs were devoted to hardware, but now 90 percent of the costs are soft-
ware. This reversal reflects not only the decline in hardware costs and the

1
2 Chapter 1

increase in programmer salaries, but also the recognition that systems

must be carefully designed and developed to accommodate human users.
Through history there have been various applications of program-
ming technologies that could be said to have caused revolutions. For
instance, the Industrial Revolution was marked by such progress as the
invention of the automatic loom which had instructions to form patterns
in cloth. But the complex interaction between sequences of instructions
and machines that marks the modem digital computer is unparalleled in
the technological history of humankind.
Software is essentially a symbolic product and differs from the vast
range of other products produced by conventional engineering tech-
niques. Software, once designed, has no manufacturing phase and does
not deteriorate, although changing environments will usually require soft-
ware modifications.
Software may be systems software or applications software. Systems
software serves applications software and includes compilers, editors, file
management utilities, operating system facilities, and telecommunication
processors. Systems software interacts with computer hardware and usu-
ally requires scheduling, sharing of resources, and effective process man-
agement. Applications software performs specific, real-world tasks that
the user requires. For instance, software to handle payrolls, accounts
receivable, and inventories are part of the applications software prevalent
in business information processing. These individual application products
may be integrated into a larger product, such as a management informa-
tion system.
Studies have shown that reusability can significantly improve soft-
ware development productivity and quality. Productivity increases as
parts developed for previous projects can be used in current ones, saving
on development time. Quality can be increased as frequently used parts
have been tested and debugged in a variety of circumstances. Despite the
benefits of reuse, several factors exist which seem to discourage software
developers from embracing the concept of reuse. The most often cited
reasons why software is not reused are (Tracz, 1988):

• a lack of tools to support a developer in trying to reuse compo-

nents,
• a lack of training for developers to create reusable components and
to use
• reusable components wherever possible, and
Introduction 3

• a lack of an educational methodology and motivation (both finan-

cial and psychological) to open the eyes of developers and their
management to the practical long term benefits of reuse.

That software reuse has not been widely accepted questions the suit-
ability of existing management practices, organisational structures and
technologies involved in the development of software. In short a rethink
of software development is needed.

What is R e u se ?
The distinction between use and reuse is sometimes a subtle one. We
would argue that success in society is intimately linked, in the first
instance, to the ability to create products and/or services that are used.
The grander success occurs when what one produces becomes a critical
building block in what others create— this is reuse.
The popular reuse icon (three green arrows in a cycle) is typically
about decomposing natural products and incorporating them in new nat-
ural products in a cyclic way. Software can, however, be arbitrarily often
copied, and software reuse should lead to new products in a spiraling way
(see Figure 1.1 Reuse Spiral)

Figure 1.1 -R eu se Spiral: The figure on the left show s the cycle of physical reuse
w hereas the software reuse spiral can lead to progressively more software from
the sam e original software.
4 Chapter 1

More rigorously, reuse is the practice of using an asset in more than

one software system. An asset is any product of the software life cycle.
Reuse requires the existence of a library of assets. A reuse library is a
controlled collection of assets, together with the procedures and support
functions required to provide the assets for reuse. Reuse typically occurs
within a domain of activity or knowledge in which applications share a
set of common capabilities and data.
While the terminology of assets, reuse libraries, and domains is ger-
mane to understanding the technological side of software reuse. Software
reuse is also about processes that involve people. It is about learning how
to do software reuse, about planning an organizations strategy for reuse,
and about maintaining a process of reuse that people have been taught to
follow. Reuse is also about economics.
Many people confuse reuse with use. Each has distinct, important
roles in software engineering. When one eats, one obviously uses the
dishes. Are the dishes being reused? They were used previously.
However, these successive uses are not what is meant by reuse except in
the trivial sense. A computer program invoked from a menu is being used
again. However, here again this is only the trivial sense of reuse. Use is a
run-time concept, while reuse is a construction-time concept (Bassett,
1997).
Run-time is the time during which a computer executes software
modules. Construction time is the time during which a programmer or a
computer constructs the executable or interpretable module. Construction
time precedes run time.
Activities such as invoking programs means using them as is. The
important properties of usability are functionality, efficiency, and ease of
use. Binding is the process of assigning values to appropriate variables in
a module. When done at run time, this provides the ability to vary the
module’s behavior. This relates to functionality and ease of use. Such run
time binding, however, tends to decrease performance. Binding at con-
struction time provides a mode of flexibility unavailable at run time.
If a person wants to take parts of a dish and make a new dish, that is
a kind of reuse. In the physical world, such reuse may be very difficult.
In the software world, reuse should be natural. At run time a programs
data structures and basic logic can only change slightly, otherwise the
program is not predictable. At construction time the data structures and
logic can change in ways that would be unacceptable at run time. A
reusable component has three key properties: generality, adaptability, and
usability. Generality refers to how many contexts a part can be reused.
Adaptability refers to how much work must be done to adapt a compo-
Introduction 5

nent for use in each context. In summary, reuse is the process of adapting
a generalized component to various contexts of use.

Types of R e u s e
While current management practices are not suitable for reuse-oriented
development methodologies, the unsuitability is often overstated. Part of
the problem is due to a blurring of the distinction between information
life-cycles and development methodologies, and one often gets blamed
for the shortcomings of the other (Agresti, 1986). Roughly speaking an
information life-cycle is a model for organising, planning, and controlling
the activities associated with software development and maintenance. For
the most part, a life-cycle prescribes a division of labor, and identifies and
standardises intermediary work products. A development methodology on
the other hand specifies a notation with which to describe those work
products and a process by which to arrive at those products.
Activities associated with the life-cycle involve financial and human
resources. Diverting resources, both human and financial, into building a
base of reusable information has a number of organisational implications,
including team structures and cost imputations. In addition to the typical
project team structure of information organisations, a reuse library team
is needed. Minimally, the library team would be responsible for packag-
ing and controlling the quality of what gets added to the reuse library
(Prieto-Diaz and Freeman, 1987). The librarians may work closely with
the project teams that develop information as those project teams both use
material from the library and contribute new material to the library.
Development methodologies broadly use either generative or build-
ing blocks approaches. The generative approach shortens the typical
information life-cycle by removing design, implementation, and testing.
Developers specify the desired product in some high-level specification
language. The generated information is usually correct by construction,
and no testing is needed (Simos, 1988).
The building blocks approach typically incorporates:

1. statement o f the problem

2. computer-based search and retrieval of building blocks
3. assessing reuse worth of retrieved blocks
4. adapting the retrieved blocks to the present need or solving the
problem afresh.
6 Chapter 1

Traditionally software reuse has meant the reuse of code, gathered

together in subroutine libraries. The reuse of software in the form of com-
ponent libraries has existed widely since the 1950s in such languages as
FORTRAN. However, experience has shown that only small improve-
ments can be achieved by simply reusing code in this way. From the doc-
uments of the software life cycle more than the code itself can and should
be reused. The hope is now to widen the scope of the reuse to cover all
products of the software development process, to include the compo-
nents, together with their abstractions, and their associated
documentation.

Domain A n a ly s i s
Recently there has been a growing interest in domain analysis and
domain model ‘reuse,’ extending the scope of reusable information to
earlier in the development life-cycle than the code stage (Mili et al,
1994). At this stage the software developer is able to look at the structure
of a component, expressed perhaps in some formal specification method
without the important concepts of the component being masked by
implementation details. This method does not offer the huge productivity
gains made possible by reusing a piece of code directly but has advan-
tages. Storing components in this manner allows for the range of require-
ments satisfied by any component to be extended, since the items are in
a simple generic form and can thus be more widely applied, allowing
changes to the design to be made directly. Storing components in this
manner it should be possible to reach a stage such that if a component at
the program code level is a close but not exact match for a developer’s
desired component the developer would be able to trace back through that
component’s development history and find a level of abstraction at which
the component is general enough to be reused.
The main problem with reuse is how to render the software items
readily reusable. Domain analysis can be a fundamental step in creating
real reusable components. Organisations who have conducted domain
analysis prior to creating reusable components have met with greater suc-
cess in software reuse.
Domain Analysis is a method for analysing a software domain by
studying existing software systems, emerging technology, and the devel-
opments in terminology of the software field (Lung and Urban, 1993). In
domain analysis common characteristics from similar systems are gener-
alised, objects and operations common to all systems within the same
Introduction 7

domain are identified, and a domain model is defined to describe the rela-
tionships between the objects
Domain modelling in software reuse aims to provide a framework for
the identification of objects, operations, and other structures that can be
captured as reusable software concepts. Both domain expertise and exper-
tise in design-with-reuse are used for efficient domain modelling.
Whether the domain analyst is an expert in the domain or not, she will
require access to, and experience in the use of, tools that can aid in pro-
viding an overview of the domain. Such tools and techniques have been
developed in areas such as systems analysis and knowledge engineering,
where the problem of domain comprehension is also a central issue.
The concepts of ‘domain analysis’ and ‘domain modelling’ are fun-
damental to all object-oriented approaches to software modelling. One
commonly cited and well understood example of a domain is that of
Mathematical Applications. The topics in this area can be modelled into
classes, such as ‘equations’, ‘set theory’, ‘calculus’ and so on. The equa-
tions class, for example, can be subdivided into further classes, called
subclasses, such as ‘simultaneous equations’, ‘differential equations’ and
so on, as can the other classes. Often these subclasses too can be split fur-
ther into subclasses, and so on (see Figure 1.2 Domain Analysis).
A long document that is to be read by people usually has a table of
contents or an outline. This table of contents corresponds to a hierarchy
of headings in the document and gives readers an overview of the con-
tents, enabling them to find thematically-organised sections. Due to the
nature of this division a well-organised outline is a ready made form of
domain model. This is an example of reuse of information already con-
tained in documents helping the reuse process.

Hypertext
Hypertext is a richly-linked, document-like information structure. It
allows the reader of a document to access the information stored in it
from many perceived points of view, in any order and to follow many dif-
ferent paths through the information. In a hypertext system, information
is stored in ‘chunks’ which can be of any size, depending upon imple-
mentation. These chunks are called nodes, and they can be linked togeth-
er to make up a document (see Figure 1.3 Hypertext Document).
8 Chapter 1

Figure 1.2-Domain Analysis: The ‘Domain Analyst’ divides up the domain into
its various classifications

Hypertext systems are a benefit in a reuse environment because to

understand a software concept that is to be reused, typically large
amounts of information, which will exist for any well-documented soft-
ware project, have to be examined by the developer. To access this mate-
rial for relevant information by hand is tedious and time consuming.
Good hypertext systems make this task easier and more accurate.
Introduction 9

Figure 1.3-H ypertext D ocum ent: The text of the document is held in nodes, the
order in which information is presented to the user will depend on the path fol-
lowed through the nodes.

A common example of software documentation access that could be

improved using hypertext is the UNIX documentation system, called
‘m an’ (for manual). The Unix man system offers on-line documentation
explaining the function and usage of programs that are available to users
of the system. An example is the ‘man page’ for the command Is. Its ‘man
page’ describes how to get listings of different directories and what the
access rights each file is listed with mean and so on. To help the user
understand what these concepts are and which commands are necessary
to influence these attributes the ‘man page’ contains a reference to relat-
ed commands.
10 Chapter 1

In a hypertext system if a reference to one of these commands was

present, simply clicking on the reference would retrieve the ‘man page’
for that command. Then clicking on another button will bring back the
‘man page’ from which it was summoned. This can be used recursively,
if a called-up page references another page, then further references can be
followed and back-tracked at will by the user.
Hypertext techniques are also useful with program code (see Figure
1.4 Ccodel). When trying to understand what a segment of code means,
the developer needs to know how each of the variables in that segment
are defined. The only method to find this out is usually to methodically
read through the listing noting where variables are defined and modified
and searching through documentation to find a description of the variable.
This is tedious and with opaque code, a very difficult task. A hypertext
system could automatically analyse the program to find definitions and
references to variables and to search documentation for definitions. Thus,
if the piece of code was being viewed using one of these systems the vari-
ables would be highlighted in some way, bold font for example, and click-
ing upon one of them would bring up that variable’s definition and a list
of references to it in the program.

Figure 1.4-Ccode1: A sam ple C program. The variables q1, q2, nam e, and buf
m ust be understood.

s t r c p y (name, ( i n t ) ql +2) ;
g e t b l o ck. () ;
q2 = ( c h a r * ) strchr (buf, T " T) ;
if ( i q 2)
{
/ * No l uck t h i s t i m e */
s t r c a t ( n a m e , buf);
get bl ock () ;
}

Hypertext may also support collaboration. Hypertext systems can be

set to log access to each piece of information. Such a system can then
Introduction 11

keep track of who has accessed what and when. It can then be an aid to
understanding which are the most important parts of the documents, who
in the team understands which parts of the system, and so forth.

Epilogue
There is increasingly a need for more reliable and complex computer pro-
grams which will be delivered on time and will be cost effective to main-
tain. Traditional software engineering techniques do not fulfill these
needs. Software reuse techniques may help.
Inhibitors to the widespread acceptance of reuse are both managerial
and technological. This book emphasises a technological approach to
reuse based on domain analysis and software libraries. The management
problems and solutions are also described
Section 1
B ack g round

This section provides background in the form of two chapters. The first
chapter describes the software life-cycle and the second chapter intro-
duces issues in the management of software engineers. Inhibitors to effec-
tive software reuse are largely managerial in character. Software engi-
neers must be persuaded that creating material which fits well into a
library is of long-term value. These two chapters relate to management in
software engineering and to the life cycle of software components. One
can not properly understand the management of the people and their tools
without also understanding the processes through which the software
objects themselves go. Software reuse involves many, many aspects that
are both concerned with people and with software.
C hapter 2
T h e S o f t w a r e Life C y c l e

The classic software life-cycle was not conceived with reuse in mind.
This life-cycle has been criticized for being inherently top-down, where-
as good software reuse techniques require a combination of top-down and
bottom-up approaches. Nevertheless, an understanding of the traditional
approach is important as a foundation for understanding reuse, and this
chapter provides that foundation.
The traditional software life-cycle emphasizes the need for each step to
meet the specifications of the previous step (see Figure 2.1 Software life-
cycle). The five basic steps are:

1. Requirements describe what the client wants from the software.

2. The design represents the requirements in a language closer to that
of the computer.
3. In the implementation step the design is converted into actual code
that can be executed by a computer. If the design is very formal-
ized, this may be an automatic step.
4. Testing is the proving of the implementation by the rigorous appli-
cation of data to the system.
5. Maintenance is the longest part of the cycle, it is the modification
of the finished program as and when the need arises.

This stage is made easier if the previous stages have been well executed.

15
16 Chapter 2

Figure 2.1-S oftw are life-cycle: The software life-cycle seen in a typical
production engineering flow chart.

Use can also be made of other common process concepts, such as

incremental delivery (Simons, 1987). In incremental delivery the soft-
ware life-cycle is divided into parallel parts (see Figure 2.2 Incremental
Delivery). For instance, the design can be divided into parts each of
which is done separately and simultaneously but is later integrated. With
rapid prototyping a simple version of the desired system is quickly con-
structed for the sake of insights about the important problems throughout
the cycle.
The Software Life Cycle 17

Figure 2 .2-lncrem ental Delivery: Incremental delivery view of software

life-cycle.

R eq u irem en ts
Requirements should:

• be helpful and understandable to end users,

• serve as a basis for design and testing,
• be suitable to the application, and
• encourage thinking in terms of external and not internal system
behavior.
18 Chapter 2

A software requirements document establishes the first official

boundaries on the solution space of the problem of developing a useful
software system (Yeh and Zave, 1980). Depending on the complexity of
the problem, the size of the requirements document will vary. For
instance, a requirements document for a ballistic missile defense system
contained over 8,000 requirements and filled 2,500 pages (Bell et al,
1977).
The most popular language for requirements is natural language
because it is the most expressive and because it is understood by both
users and system developers. A software requirements document contains
a complete description of what the software will do without describing
how it will do it. It serves as the basis for all design activities, and all sys-
tem test planning. The IEEE Standards document for software quality
says that requirements should (IEEE, 1981).

“clearly and precisely describe the essential functions, performances,

design constraints, attributes, and external interfaces. Each require-
ment shall be defined such that its achievement is capable of being
objectively verified by a prescribed method, for example, inspection,
demonstration, analysis, or test.”

While natural language requirements may perpetuate ambiguity,

they are critically important. For example the requirements for the Ada
programming environment (Defense, 1980) include:

“The database shall support the generation and control of configura-

tion objects, that is the objects which are themselves groupings of
other objects in the database.”

More rigorous specifications will be needed, but they should be com-

plemented by the natural language version, in any case. Surprisingly the
expression of requirements in natural language may lead to less misun-
derstanding by software developers than more formal requirements.
Two major components of the requirements document are the con-
ceptual requirements and the functional requirements. The conceptual
requirements is a high-level description of the relationships among the
services of the system. The functional requirements describe how the sys-
tem will function (Yadav et al, 1988).
The outline of a requirements document may be divided into parts
that include operational and non-operational requirements (see Figure 2.3
Operational or Testable Outline of Requirements Document). Operational
The Software Life Cycle 19

or testable requirements outline the system’s performance characteristics,

interface constraints, quality assurance standards and human factors
(Hayashi and Sekijima, 1993). The operational requirements can be
traced through the design and implementation of the system. Non-opera-
tional requirements outline the organizational resources available to sup-
port system development, the package of resources available, fore-
thoughts about the system’s development cycle, assumptions about the
system operation in its target environment, and expected changes in the
system operational requirements over the life of the system.

Figure 2.3-Operational or Testable Outline of Requirements Document:

Functional requirements detail computational functions the system is to perform.
The architectural requirements describes the interconnection among abstract
modules.
1. Overview
2. Problem
2.1 Technology in use
2.2 System diagram
2.3 Theory of system operation
2.4 Intended applications
2.5 User skills
3. Operational requirements
3.1 Performance characteristics
3.2 Standard interfaces
3.3 Software quality assurance
3.4 Software portability
3.5 User orientation
4. Non-operational requirements
4.1 Resources available for development
4.2 Package of resources built into system
4.3 Forethoughts about system life cycle
4.4 Assumptions about system operation
4.5 Expected changes in requirements
5. Functional requirements
6. Architectural requirements
20 Chapter 2

Design
Two different designers using the same design method and same require-
ments document would not necessarily generate the same design (though
some methodologies such as Jackson Structured Design state that they
should). The designer must still rely on his or her own insight and cre-
ativity in decomposing the system into its constituent structures and
ensuring that the design adequately captures the system specifications.
Design methods in common use have been criticized because they are
largely informal. Nevertheless they have been applied successfully in
many large projects and have resulted in significant cost reductions.
There is no single design tool which is best for all types of software
design. In fact, there are hundreds of different design tools and design
notations, each of which may be useful for describing different levels of
design within particular application areas. Some of the more common,
generic design tools include data flow diagrams, structure charts and
trees. An experiment was run in which a group of students were asked to
use various methods and a group of experts assess the results (Yadav et
al, 1988). The conclusion of the study was that the Data Flow Diagram
method was easier to use and learn.
Data-flow diagrams may be part of top-down design methodology.
Top-down design involves decomposing the system into its functional
sub-components and then creating a design for each sub-component. The
designs for the collection of sub-components are joined to create a design
for the overall system. For top-down design there are 4 phases:

• 1 study and understand a component of the system requirements,

• 2 identify major features of one possible design for this compo-
nent,
• 3 construct a data flow diagram, showing gross data transforma-
tions in the system, and
• 4 from the data flow diagram construct a structure chart showing
the program units, and describe these program units in pseudo-
code.

A data flow diagram shows how data is transformed as it is moved

from one system component to another. Structure charts are hierarchical
trees with the roots at the top and are useful tools for system design. A
software system is broken down into separate programs and each pro-
gram is decomposed into modules. Each of the modules is broken further
The Software Life Cycle 21

into smaller modules. Decomposition continues until the amount of infor-

mation in the module is small enough to be easily managed.
By example, an Office Information Retrieval System (OIRS) can file
documents under some name in one or more indices, retrieve documents,
display and maintain document indices, archive documents and destroy
documents. Commands might include get proposal, file as on-loan, and
edit proposal. A first data flow diagram of this OIRS system reveals mod-
ules which handle each of the inputs and outputs. A further decomposi-
tion of the data flow diagram shows the user command leading into the
database query. The output comes from the database and is translated into
an output message and output data (see Figure 2.4 Data Flow Diagram).
The structure chart takes the data flow diagram and imposes a hierarchi-
cal structure. Then it is easier to decide which effort can be independent-
ly invested in which part of the OIRS system (see Figure 2.5 Structure
Chart).

Figure 2.4-Data Flow Diagram: Data flow diagram for Office Information
Retrieval System. DBMS m eans D ataBase M anagem ent System.
22 Chapter 2

Figure 2.5-Structure Chart: Example of a structure chart for preceding Data

Flow Diagram.

Implementation
After design comes implementation of code or software. Correspondence
from design to code should be correct and traceable. It should preserve all
decisions made earlier. With a well-defined design notation, it may be
possible to specify explicit guidelines for mapping design constructs to
code.
If a project has the opportunity to select the programming language
to be used, it is desirable to consider support for high-quality, component
construction provided by a candidate language. Some of the considera-
tions include:
The Software Life Cycle 23

• Its support for extended parameterization through a facility such as

Ada’s generic procedures,
• Its ability to guarantee error-free, robust software through such
mechanisms as type checking, and
• Its support for the creation of readable, modifiable, and maintain-
able programs.

Also, the anticipated language requirements of future systems should

be considered.
If the programming language provides exceptions (a means of signal-
ing an exceptional condition by transferring execution control to a routine
specifically provided to handle that condition), this can be a way of han-
dling boundary conditions flexibly. The component might also provide
auxiliary routines for getting additional information about what caused
the exception. A 6safe’ component will likely include a number of checks
to insure that the component does not accidentally crash. For example,
there may be checks on expressions for division by zero, for checking that
a queue is empty or full, or for hardware read errors when reading from a
disk.
The principle of information hiding refers to the concept of making
certain information visible while hiding other information. This supports
the view of a ‘software chip’—a black box whose function and interfaces
are well-defined while no knowledge of its implementation is required.
The interface specification provides the ‘directions’ for component
installation.
In an object-oriented methodology, an object representing a data item
is defined in terms of the values it holds and the operations that may take
place on those values (Booch, 1994). Objects belong to classes, which are
groups of objects which share common features, inherited from their
class. The state or values held by an object are changed by sending a mes-
sage to the object invoking one of the functions defined in it. This is a
form of information hiding since the object sending the message only
understands the message sent and the effect it should have, not exactly
how the change will be implemented. This is useful since it means func-
tionally equivalent objects can be swapped and when an object is reused
what expectations the new program can make are clearly defined in the
messages an object can receive.
24 Chapter 2

Testing and D o c u m e n ta tio n

There are two main categories into which program testing strategies fall
(Hartmann and Robson, 1990).

• Functional Testing techniques are based around checking a com-

ponent using data that the component is likely to receive in use and
ensuring responses are apt.
• In Structural Testing techniques, test data is designed using a
knowledge of the structure of the component to be tested. For
example, if it is known that values in the ranges 10-20, 30-40 and
80-200, will cause different branches through the program to be
executed, then values in all three of these ranges would be used to
test the program.

These two methods can also be combined (Woodfleld et al, 1983).

Quality assurance or testing should not wait until code is finished. At
each phase of the life-cycle, testing should ensure that the appropriate
requirements for that phase are being followed. Testing should be includ-
ed in each design review, with an established audit procedure for each
product and activity. If the guidance is ignored in these early phases, lit-
tle benefit will be gained from following it in the coding phase.
Testing usually focuses on products - specifications and code. These
are usually amenable to objective quality measures. It is important to also
audit the work activities that influence the quality of the product. For
example, such evaluations might address:

• whether software engineering tools are being used as expected,

and whether they are serving the intended purpose and
• whether changes to components are strictly controlled by configu-
ration management procedures.

Evaluations should be objective and should be assisted by a checklist

to ensure that all key points are covered. Such a checklist also provides a
mechanism for documenting audit results and preparing discrepancy
reports.
Documentation of the software development cycle is essential, both
to manage and distribute information within the project whilst it is in
progress and to be able to maintain the system once in use. In fact it can
be said that the products of the software life-cycle are mainly documents.
A further demonstration of this is that in 1979 within the IBM
The Software Life Cycle 25

Corporation, the title ‘technical writer’ was changed to 'information

developer’ to reflect the widening scope of the writer’s responsibilities.
IBM has said that information development can be thought of as one of
three equal parts of a total IBM product, where the other two parts are
hardware development and software development.
The authoring of documentation is called information development to
differentiate it from normal writing activities, such as writing this book.
In large organizations information development may be best accom-
plished within the confines of a single administrative unit. In this situa-
tion information development work can be moved within the existing
organization rather than moving the information development people to
different administrative units in the company. On the other hand, inte-
grating the information developers into the overall organization increases
the opportunities for synergism among the project’s hardware and soft-
ware groups. Differences between ‘information development’ and tradi-
tional technical writing include that the information developer:

• tends to get information from people rather than books,

• works as part of a team,
• tests the information for its usability, and
• may put the final written product into a variety of forms.

The information development process can be decomposed into the fol-

lowing sequence:

• become familiar with the hardware and software plan,

• set objectives for the information to be provided,
• develop drafts,
• verify the draft with inspection, editing, and testing, and
• maintain the information based on feedback.

The model for good information development suggests some

approaches to proper education for information developers. For one, col-
laboration must be part of the process. For another, the hardware and soft-
ware professionals must be approached as peers in the development
process so that feedback can be bi-directional.
The theory of documentation stems from philosophical as well as sci-
entific considerations and should address the broad problem of user sup-
port technology of which manuals are a part (Weiss, 1988). This theory
26 Chapter 2

should help define the relationship between internal support, such as for
screen design and external support, such as manuals. It should clarify the
relative costs and benefits of information services, such as teaching and
consulting versus information products, such as manuals and tutorial
disks. One principle of a theory of documentation is that:

“nearly every aspect of user support (including manuals) derives

from the nature of the user interface.”

Consequently, the nature of the user interface must be considered as part

of the initial product conception, and the user interface specification
made as important as the hardware or the software specification. Another
principle states that:

“Manuals are a component in a fully-designed 'user support enve-

lope’, which may include any information product or service made
desirable or necessary by the user interface.”

Manuals are not the lone creations of individual writers or artists. Each
publication should be written to an engineered specification, not created
in private by an artisan. Each part of the document should go into a data
base where it will be maintained and reused by other writers. Manuals
will be developed through models and prototypes and tested before they
are drafted, by applying the principles to models.
Case studies reveal interesting patterns in investment in documenta-
tion. Firms which make a large investment in a product of which only a
few copies are sold tend to rely heavily on personal contacts with the buy-
ers to help the buyers use the product. Firms which sell large quantities
of a modestly priced product find it cost effective to have excellent doc-
umentation because the firm could not afford the number of service calls
which would be required for helping the users in person. More specifi-
cally, two variables dominate management’s decision on the relative size
of its investment in documentation. High projected sales volume seems to
predict a relatively large investment, because high volume precludes per-
sonal contact with customers before and after sales. High unit cost, on the
other hand, predicts a lower relative investment in documentation,
because personal contact is more effective in influencing the purchase
decision and competes with documentation as a means of delivering
maintenance support.
In the case of low-investment documentation the vast majority of
time spent on documentation goes towards writing. Relatively little time
The Software Life Cycle 27

goes into management, editing, or artwork. For a high-investment docu-

mentation effort the man-months spent on each part of the documentation
are relatively equally distributed among management, writing, editing,
and artwork.

M ainten ance
The primary business of the software industry has historically been new
development; now it is maintenance and evolution. Today more software
professionals are employed to maintain and evolve existing applications
than to develop new systems from scratch. Software engineers need a
variety of analytical skills, tools, and methodologies to cope with the
challenges of maintaining large, aging software systems. The software
industry critically depends on enhancing the maintenance processes of
legacy or heritage systems which potentially constitute immense corpo-
rate advantages if managed effectively.
Every time an alteration is made to any aspect of the software, be it
designs or code, it is necessary to make the corresponding change in the
documentation to indicate the change. Otherwise, it may be very difficult
for another programmer to understand the software sufficiently to main-
tain it. Software maintenance is the term given to the process of modify-
ing the program after it has been delivered and is in use. These modifica-
tions may involve simple changes to correct coding errors, more exten-
sive changes to correct design errors, or drastic rewrites to accommodate
new requirements.
Programmers may hope that what is important about their programs
is immediately visible. Realistically the problems are many, and cost lies
under the surface. Generally the cost of software maintenance has steadi-
ly increased during the past 20 years. A typical software development
organization spends about 40% - 60% of its money on software mainte-
nance. The common error made by the maintainers is that, when an error
is encountered, the coding is investigated and corrected, but the docu-
mentation is not correspondingly updated. Whenever a change to the soft-
ware, whatever the format or type of change may be, is made, the docu-
mentation must also be updated. Otherwise a subsequent user or main-
tainer would find it difficult to realize the change that has been made to
the original version of the software.
28 Chapter 2

Standards
The importance of standards in software engineering can not be overstat-
ed. Reuse hinges on standards. A person can not reuse an object when the
description is not in a language (and this means not only the natural lan-
guage but also the software design language) that the person understands.
The interfaces of the object to other objects have to speak the same lan-
guage. If the components of the life cycle are to communicate with one
another, the first standard that is required is directed to the commonality
in the language that is used to describe the software life cycle. This chap-
ter has summarized some of the key views on and components of the soft-
ware life cycle. Next standards for the software life cycle are considered
after an introductory look at standards organizations and processes.
The standard making process involves many different groups whose
mode of operation is a complex combination of commerce and govern-
ment. Consensus must be obtained and often this involves significant
expenditure of resources in time and money. An advanced country tends
to have at least one major standards institute. The United States has the
American National Standards Institute, the United Kingdom has the
British Standards Institute, and so on. An alliance of European nations
has created a standards organization called the Committee of European
Normalization which receives input from 18 European countries. The
International Organization for Standards receives input from virtually all
countries. In addition to the national and supranational organizations,
many commercial and volunteer groups play important roles in develop-
ing standards (Rada et al, 1994). For instance, the Institute of Electrical
and Electronic Engineers (IEEE) sponsors the development of numerous
standards.
The International Organization of Standards (ISO) is an independent
organization for fostering international agreement on standards with a
view to expanding international trade. ISO consists of national represen-
tatives only. The work of ISO is undertaken by Technical Committees. A
draft standard is advanced by a Technical Committee to the membership
of ISO, and if 75% of the membership of ISO approve, then the draft
becomes an International Standard.
American Standards
Traditionally, each sector interested in regulating the development and
maintenance of software has written its own specification to summarize
the requirements of interest. Over twenty years ago the U.S. government
over twenty years ago organized a software life cycle around ten docu-
The Software Life Cycle 29

ments (NBS, 1976). At roughly the same time, the U.S. Navy commis-
sioned a standard for the software life cycle (USN, 1976). The Federal
Aviation Authority and other regulatory bodies also standardized the soft-
ware life cycle they expected contractors to follow in developing quality
software.
The commercial sector also helped to proliferate life cycle standards.
The Institute of Electrical and Electronic Engineers (IEEE) created a
standard for the definition of life cycle processes, IEEE Std 1074. Unlike
the aforementioned standards which placed requirements on the external
characteristics of a life cycle, 1074 focused on the life cycle model. It
specified a number of process fragments along with their inputs and out-
puts. The process architect could assemble a life cycle model from the
pieces specified by the standard. Even private companies, like IBM, had
their own life cycle definitions, treated as proprietary material because
they were presumed to confer a competitive advantage.
If the 1970s and 80s were a period of differentiation in life cycle stan-
dards, the 1990s were a period of consolidation. The DoD undertook an
effort to unify various software life cycle standards it had sponsored. The
IEEE and the Electronics Industry Association then produced a joint stan-
dard that the American National Standards Institute (ANSI) issued as
ANSI Joint Standard 016.
ISO 12207
While each country was developing its own software life cycle standards,
the international standards community was also active. ISO/IEC
JTC1/SC7 (the software engineering subcommittee of Joint Technical
Committee 1 of the International Organization for Standardization and
the International Electrotechnical Commission) developed a standard
known as ISO/IEC 12207. Whereas ANSI 016 placed requirements on
only the development process, 12207 specified four additional primary
processes (acquisition, supply, maintenance, and operation), as well as
eight supporting processes and four organizational processes. Although
12207 is useful in organizational or individual contexts, its conformance
requirement specifically applies to the relationship between an acquirer
and a supplier in the development, maintenance, or operation of software.
The standard is intended to be tailored by the deletion of inapplicable
tasks (specific parts of processes) when it is applied to any particular con-
tract. (Of course, additional requirements may be placed in a contract.)
On the other hand, organizations that adopt the standard as a “condition
of trade” are expected to publish the minimum set of acceptable tasks.
30 Chapter 2

ISO 12207 impacts international commerce in software because it

provides a common framework of terminology and process structure for
acquirers and suppliers in different countries. Many of the major coun-
tries are moving toward the adoption of 12207 as a national standard.
Nevertheless, there are some obstacles to use, particularly by U.S. users.
The standard does not provide a set of data descriptions for the recording
of information essential to software development. The standard provides
no way for an organization to assert that its own internally institutional-
ized software development methods conform to 12207. The standard does
not provide a clear transition path for the large number of U.S. stake-
holders in the ANSI-016 and related standards.
The various national U.S. bodies have created a “U.S. Industrial
Implementation” of 12207. Recall that organizations can tailor ISO
12207 and augment it with material from ANSI 016 and other sources.
IEEE has adopted 12207 “as is”. IEEE has mapped some of its many
standards to the ISO 12207 framework (see Figure 2.6 IEEE and ISO).
U.S. efforts have developed an “organizational” mode that permits an
organization to assert that its internally adopted processes for software
development, maintenance, or operation meet all of the requirements of
the U.S. 12207—a 12207 badge.

Figure 2.6-IEEE and ISO: Existing IEEE Standards support the ISO 12207
Process Framework. The leftmost column is the high-level process addressed by
I S 0 12207, while the second column is the next-level process in I S 0 12207. The
third column is an IEEE standard that relates directly to the corresponding ISO
process.
ISO 12207 Process Corresponding IEEE
SESC Standard

Primary Acquisition 1062 Software Acquisition

Development 830 Software Requirements
Specifications, 1016 Software
Design Descriptions, 1008
Software Unit Testing
Maintenance 1219 Software Maintenance
Supporting Configuration 828 Software Configuration
Management Management Plans
Quality Assurance 730 Software Quality Assurance
Plans
Verification 1012 Software Verification and
Validation
The Software Life Cycle 31

Figure 2.6—
IEEE and ISO, c o n 't
ISO 12207 Process Corresponding IEEE
SESC Standard
Joint Review 1028 Software Reviews and
Audits
Problem Resolution 1044 Classification of Software
Anomalies
Organizational Management 1058 Software Project
Management Plans
Infrastructure 1209 Evaluation and Selection of
CASE Tools
Tailoring 1074 Developing Software Life
Cycle Processes

A 12207 badge suits the needs of the U.S. defense industry, one of the pri-
mary customers of software engineering standards. When the Department
of Defense stopped writing and imposing its own process standards, it
endorsed the concept that contractors should develop their own organiza-
tional processes conforming to generally accepted standards. Defense
contractors are among the first to display the 12207 badge. ISO is exploit-
ing the success of 12207 in several ways. A guidebook providing advice
on 12207 usage is available. ISO is reshaping its other software engi-
neering standards projects so they will “plug into” the 12207 life cycle
processes.
P ro ces s A s s e s s m e n t Methods
A badge already familiar to some U.S. software developers is the
Capability Maturity Model developed by the Software Engineering
Institute at Camegie-Mellon University. The CMM began as a self-
assessment mechanism intended to guide the improvement of organiza-
tional software development processes. It grew to an evaluation mecha-
nism, applied by some agencies of the U.S. Department of Defense to
judge the capabilities of potential suppliers.
U.S. software developers may not be as familiar with assessment
models and methods, such as Trillium (Bell, 1994), Bootstrap and per-
haps a half-dozen others, developed by organizations in other countries.
The proliferation of assessment mechanisms presents a barrier to organi-
zations desiring to act as suppliers in the international software market-
place.
32 Chapter 2

To address these concerns, ISO/IEC JTC1 created in 1993, a project

called SPICE (Software Process Improvement and Capability
dEtermination) assigning it to SC7, the same subcommittee that devel-
oped the 12207 standard. The objective of the SPICE project is to har-
monize existing process assessment approaches by identifying a common
framework. Work to date suggests a two-dimensional framework: one
dimension structured by the processes of 12207; the other dimension
structured similarly to maturity levels. The framework would be applica-
ble to assessing process capability within an organization as well as deter-
mining the capability of potential suppliers. It is intended that the stan-
dard would be culturally independent and applicable to a variety of appli-
cation domains and organizations.
The intent is to allow users of existing models to continue their use
while providing a common framework against which results of the vari-
ous models and methods can be reported and tracked. Whether organiza-
tions wear a badge saying “SPICE” or a badge bearing a more familiar
name, it seems likely that process assessment will be applied on an inter-
national scale.
IEEE’s Customer-Oriented Program
The IEEE Software Engineering Standards Committee (SESC) is the
world’s most prolific creator of software engineering practice standards.
Its collection numbers over 35 and grows at the rate of five or so per year.
Organizations that apply the SESC standards do so without compulsion.
One reason to adopt the SESC standards is that the collection repre-
sents a comprehensive corpus of practices for good software engineering.
Furthermore, some organizations find themselves in the unenviable posi-
tion of defending their development practices in regulatory or legal situ-
ations. Their defense might be to say that they have applied a recognized
body of software engineering practice, the SESC collection. For example,
a major consumer credit reporting company, sued for alleged reckless
conduct in the development of its databases and software, has adopted the
entire collection to defend itself against future court challenges. A utility
company applies the standards to the development of nuclear plant oper-
ating software and performs causal analysis all the way to the standards
themselves whenever a fault is discovered.
Despite such successes, the SESC collection does have its problems.
Accreted in a piece-wise fashion over twenty years, the collection has
legitimately been criticized as ad hoc. Beginning in 1993, the SESC
began a re-organization of its standards to address these concerns and to
ensure that their collection of standards was responsive to the needs of
The Software Life Cycle 33

their customers—software engineers. The strategic plan is captured in

several key documents:

• The SESC Survey identified 220 existing and in-progress norma-

tive documents developed by 46 organizations on the subject of
software engineering (Magee and Tripp, 1994).
• The SESC Master Plan identified 18 classes of customers for soft-
ware engineering standards and enumerated a set of expectations,
a total of 370 of them, for each class of customers. It specified 165
objectives for software engineering standards, allocated to 26 sub-
ject areas. It listed 58 general requirements and constraints on
those standards and postulates 222 topics for potential standards.
• Their SESC 1995 Strategy Statement placed software engineering
within the context of the related disciplines of quality management
and systems engineering, including cross-cutting disciplines such
as safety and dependability.

The SESC Strategy Plan adopted a unified organizational idiom for

all of the SESC standards: any standard is applied by a project; a project
interacts with a customer, uses resources, and executes processes to pro-
duce products (IEEE, 1995). These four items of customer, resources,
processes, and products form the program elements for a reorganized col-
lection of software engineering standards. Each program element will be
packaged as a unified collection, including top-level policies and princi-
ples, key element standards, and accompanying guides all drawing on a
shared toolbox of technique standards. The entire collection will be uni-
fied with a single terminology standard and an overall road map that will
also position the SESC collection with respect to the relevant interna-
tional standards.
SESC’s work is coordinated with that of ISO/IEC JTC1/SC7 through
the ANSI Technical Advisory Group to SC7. This coordination suggests
that one possible result is a revision of the SESC collection so that a core
group of standards can be directly applied to add detail to the process
framework of 12207 (see again Figure 2.6 “IEEE and SESC” for the close
fit that already exists). Under legal and regulatory pressure, some organi-
zations already wear the badge of conformance to the SESC collection of
standards. Earning that badge will become more attractive to a wider vari-
ety of organizations as the various coordinated standards become avail-
able. SESC will thus help connect ISO 12207 and SPICE. Organizations
may eventually be expected to wear the 12207 badge (to signify adoption
of the international life cycle process framework), to wear the SESC
34 Chapter 2

badge (to signify adoption of standards detailing the 12207 processes),

and to wear the SPICE badge (to signify maturity in applying those
processes).

Epilogue
Reuse may take place at any level of the life-cycle model, and thus the
model needs to be addressed at each level to reflect reuse practices.
Perhaps one of the most fundamental criticisms of the traditional software
life cycle is its separation of design and implementation. In a reuse envi-
ronment, design and implementation are linked. To implement with a pre-
designed (reusable) component may mean going back and changing the
design. Analysts may need to look ahead in the process to determine what
components are available to them in the components library and tailor
their design accordingly. It would therefore be better, if these two stages
were linked.
Reuse of components is greatly facilitated if the components are in
machine-readable form. This is essential for effective computer organiza-
tion and retrieval of the material (which is discussed later in this book)
and also means that the components can be loaded into software engi-
neering support tools, since this will usually facilitate the easiest manip-
ulation of this material. This portability of representations is unlikely to
be generally possible until there are more widespread standards for these
representations and tools.
The plethora of existing software life cycle models and languages is
one barrier to reuse. At least, within a given domain such as manufactur-
ing software or health care software, software engineering organizations
in that discipline need to agree on some standards. This agreement on
standards is a salient mark of a profession. This conformance to the stan-
dards will be associated with badges. Software product and service
providers will earn and wear these badges to signify their compliance
with professional standards.
Chapter 3
M anagement

Developing large software systems must be treated, at least in part, as a

learning, communicating and negotiating process. At the early phases of
a project much of the effort must go into becoming familiar with the
application. A small subset of the design team with superior application
knowledge often exerts a large impact on the design. Organizational
boundaries to communication among groups inhibit the integration of
existing knowledge. Any software development environment must
become a medium of communication. This chapter describes the role of
communication in team organization and in project modeling and
scheduling.

Softw are Team Organization

The popular image of programmers is that they work alone, an image held
both by the programmers themselves and others. In fact, a great deal of
programming is cooperative. In one major study 50% of a typical pro-
grammer’s time was spent interacting with other team members, 30%
working alone, and 20% in not directly productive activities (McCue,
1978). The interaction of personalities within a group and the role of the
leader are critical to group success.
Experience suggests that programming teams should be relatively
small— fewer than 9 members (Sommerville, 1996). A small team mini-
mizes communication problems, supports consensus management, and
allows each member to know what each other member is doing. If one
person leaves, that person’s work can be easily continued. High-level sys-
tem design is done by senior team members but low-level design is the
35
36 Chapter 3

responsibility of the person given the task. A serious problem arises when
no team members have substantial experience, for then the authority of
the experienced members is missing and coordination suffers.

Figure 3.1-Hierarchical Management: Sketch of part of hierarchy in information

technology m anagem ent.

The traditional management structure is strictly hierarchical (see

Figure 3.1 Hierarchical Management). In a large organization there
should be a director of software or information technology. This person
may well have vice-president status in the organization. Reporting to this
director are several program managers and a quality manager. The quali-
ty manager also has several teams of quality assurance people whose job
is to help evaluate the success of the software development which is being
Management 37

directed by the other program managers. The quality manager has a direct
line to the director so as to avoid distortion of the quality assessment
results. The program managers have project managers who report to
them, and team leaders report to the project managers.
The chief programmer team approach utilizes an experienced chief
programmer and provides him with substantial support (Baker, 1972). All
communication goes through the team chief. The other members of the
team might include :

• Backup programmer who provides general support as well as

developing test cases,
• Librarian who does all clerical work associated with the project
and is assisted by a computerized document management system,
• Toolsmith who produces software tools,
• Documentation editor who prepares the documentation of the chief
programmer for publication,
• Project administrator who does administrative tasks for the chief
programmer, and
• Language and system expert who is familiar with the idiosyn-
crasies of the language and system and helps the chief programmer
take advantage of those idiosyncrasies.

A diagram of the ‘chief programmer’ concept shows the relative

decentralization that the concept allows relative to the traditional
approach where a programmer is at the bottom of a large hierarchy of
administrators (see Figure 3.2 Chief Programmer).
The technical and the administrative leader of a software group are
not necessarily the same person. Expertise with the technology and han-
dling the problem at hand is so important in programming work that the
person with this expertise at any given point is likely to command respect.
The autocratic style of leadership which may suit the military does not
necessarily suit programming groups. Group loyalty can be important in
that it strengthens the interpersonal ties and makes it easier for people to
help one another. On the other hand, the group leader must prevent a
group from adopting narrow-minded attitudes as a consequence of the
conservative impacts of loyalty.
38 Chapter 3

Figure 3.2-Chief Programmer: The Chief Program mer paradigm allows the
expert program m er to take advantage of the resources of a team of assistants.

Individuals in a work situation can be classified into three types. An

individual type and what motivates that type are paired as follows:

• the task-oriented type is interested primarily in the work,

• the interaction-oriented type of person most appreciates the pres-
ence of co-workers, and
• the individual wants mainly personal success.

When a group was composed entirely of members of one type, only

the group composed of interaction-oriented individuals succeeded. The
most successful groups have individuals from each class with the leader
being task-oriented. In practice, two group members often play comple-
mentary roles. A task specialist sets, allocates, and coordinates the work
of the group. An interaction specialist helps maintain the social equilibri-
um of the group (Weinberg, 1971). Since the majority of those involved
Management 39

in computer programming work are task-oriented, attention must be paid

to the selection of members of a group to assure a mixture of personality
types. Egoless programming requires the members of a group to con-
tribute to the group without necessarily identifying the productivity of
individuals. In this way, an individual is less likely to feel attacked when
criticisms arise about work which that individual produced.
While communication is critical for group productivity, communica-
tion is often not directly productive. Accordingly, a group should be orga-
nized so that the amount of communication necessary for effectiveness is
minimized. One way to do this is to have a small group. The layout of the
office space should allow privacy on the one hand and group face-to-face
meetings of both a formal and informal nature. In other words, the indi-
vidual should have a private space with his or her own workstation, but a
lounge should be available for informal meetings, and a seminar room
should be available for group meetings.

P r o c e s s Modeling
Reuse can occur on more than code, it can occur on process models of an
organization. These models were discussed loosely in the preceding sec-
tion. Here, one particular method and language for developing such
process models is presented. Activity standards are prescribed in places,
such as ISO 12207 (see the preceding chapter), but process model for a
particular organization must include and thus transcend just the activity
models.
Software reuse has gone further and further from the emphasis on
simply reusing code to the emphasis on appreciating and reusing infor-
mation throughout the software life cycle. This has corresponded with an
appreciation of the importance of describing the entire organizational
operation and reusing that information as well (Cockbum, 1996). This
higher level analysis of activities in an organization may go under the
heading of patterns work and an issue of the Communications of the
ACM was devoted to such patterns in 1996 (Schmidt, et al, 1996).
A simple taxonomy of business process models distinguishes formal
methods from empirical ones. The object-oriented paradigm used here is
empirical. The modeling language is called Gertrude (Succi et al, 1997)
and uses four entities: people, roles, processes, and infrastructures.
People fill roles. Roles execute processes through activity profiles of the
roles and processes. Infrastructure provides materials for processes.
40 Chapter 3

Activities are atomic processes. People are the employees of the firm;
they play roles to perform the activities. Infrastructures are passive phys-
ical objects, such as equipment and facilities. A process may be farther
categorized as interfacing to roles and infrastructure outside the firm or
inside to controlling other processes, or to neither interfacing nor con-
trolling.
As employees in the firm must benefit from the model, they need to
understand the modeling language to some extent. The modeler has to
know the details of the language. Other people may be given external
views that hide complexities or details of the model and its language so
that those people can derive from the model just what they need to know.
To do quantitative evaluations, such as productivity and profitability,
activity-based costing is incorporated in the Gertrude approach. When a
process is executed, data is collected about resource consumption. If a
process is reused with changes, it is necessary to evaluate the effects of
the changes on the profitability of the process.
The modeling process is approached in an iterative fashion both off-
line and on-line. Off-line means by benefiting from accumulated infor-
mation. On-line means the firm provides data on a day-to-day basis that
is directly incorporated in the model building.
An example of the modeling is presented. Employees describe the
operations in the firm. Some general patterns appear. For instance, a ver-
bal description like this might appear:

The client asks for a design. Sue handles the order and requirements.
Sue informs John about the resource requirements. John uses a
resource-allocation strategy to choose which designers will handle
the project. The designers work on the project. The design is passed
to Ann who meets with the client to discuss the designs suitability.
Ann then reports to John on the success of the design, and John deter-
mines the next step in resource allocation.

In this process, four activities have been identified:

• interaction with client,

• resource allocation,
• design, and
• validation.
Management 41

Roles have also been identified within a hierarchy to include at the

bottom manager, designer, and analyst (see Figure 3.3 Roles Hierarchy).
In this approach, people have no intrinsic hierarchical relation among
themselves, but only to the extent they assume roles in the hierarchy are
they associated with reporting relations. A process hierarchy is also
developed in which design and validation are both grouped under devel-
opment processes because of their cost and value similarity.

Figure 3.3-Roles Hierarchy: The boxes describe roles. The lines indicate
taxonomy hierarchical relations.

Activity-based costing forms are distributed to employees who keep

track of their investments of time and other resources on each activity to
which their role(s) commit. As a result of these recordings, John, the
resource manager, notes that one of the designers is taking much longer
than expected. Accordingly, a new activity is added to the firm’s list of
things to do, namely to evaluate the possible value of computer-aided
design tools for the designer in question. The Gertrude model of the firm
is then updated to incorporate this request for computer-aided design tool
assessment.
42 Chapter 3

Softw are Project Modeling

Many models for costing software projects have been developed. In one
experiment several of these models were applied to the same input data,
but cost estimates were produced which varied from $300,000 to
$3,000,000 (Mohanty, 1981 ). This vast discrepancy points to the impor-
tance of choosing a model which fits the character of the organization and
project at hand. One of the better documented software costing models is
the COCOMO one (Boehm, 1981). The COCOMO (Constructive COst
MOdel) method is based on the premise that one can estimate the number
of thousand (or Kilo) Delivered Source Instructions (KDSI) that will be
needed to complete a project. This quantity is then used to compute an
estimate for the effort required for completing that project. Estimating
KDSI may be as difficult as estimating the effort directly. However, by
breaking the system into small enough modules, one can estimate the
KDSI for each module. Then assuming that interactions among modules
will not lead to significant additional needed instructions, the total KDSI
is the sum of the KDSI over the modules.
Versions of the estimation formula exist for both organic mode projects
and embedded mode projects. An organic mode project requires only a
small team working in a familiar environment. Communications over-
head is low. An embedded mode project involves a maze of hardware,
software, and regulations. Project team members are new to this problem
type, this is a more complex problem and the completion time will be cor-
respondingly longer. Even though the output of the COCOMO model is
very rough, it can be useful for management decision making.
Graphically, the relationship of person-months to KDSI is like a straight
line for the organic form and a parabola for the embedded form (see
Figure 3.4 COCOMO Curves).
The simple assumption about effort is that the amount expended on a
project is proportional to the product of the number of people working on
a project and the amount of time they spend on the project. Thus, if each
of 10 people works 5 days on a project, then the project has had 50 per-
son-days invested into it. Assessing projects as to the number of person-
days required to complete them implies that assigning more people to a
task would shorten the number of days required to complete the project.
For instance, 50 people working one day might be able to solve the 50
person-day problem. In reality, however, this assumption about produc-
tivity is misleading. The difficulty is akin to the difficulty with multiple
processors in a parallel-processing computer. Namely, as more processors
are assigned to a task, the inter-processor communication costs rise and
may overwhelm the advantage of additional processing power.
Management 43

Figure 3.4-COCOMO Curves: Curves showing the growth in person-m onths

needed to generate a certain num ber of lines of code.

Each new person brought into a project needs instructions about what
he or she is to do, which takes time from those who give the instructions.
The new person can do work but also needs guidance which costs the
work time of others. In the worst case, the communication needs are such
that a new person must communicate with every person already on the
project. If there are p-people and each must spend time in contact with the
other p-1 people, then the amount of contact is p(p-l) or roughly p2. The
effort which can be expended by p people over t time when there is no
overhead cost is p times t. Given that e effort satisfies e = p times t, the
time to complete a given task is t = e over p. As p grows, t declines. If the
communication costs are considered, then these costs are proportional to
the square of the number of people. In this case, the curve of t versus p
no longer declines monotonically with p; rather there is an inflection
point from which t rises with rising p (see Figure 3.5 Time Rising).
44 Chapter 3

Figure 3.5-Time Rising: Curve showing the initial decline but the subsequent
rise in time as people are added to the job.

Scheduling
Without some estimate of programmer productivity, project scheduling is
impossible. Also, some of the advantages to the use of new programming
and management methodologies are difficult to assess without quantita-
tive measures of programmer productivity. The most commonly used
measure of programmer productivity is lines of source code per pro-
grammer-month. This is computed by dividing the number of lines of
source code delivered by the programmer-months in the project. The pro-
grammer-months include analysis and design, coding, testing, and docu-
mentation time. One of the difficulties in applying this measure of pro-
ductivity is defining ‘a line of code’ (Jones, 1978) Another difficulty is
that this measure does not take into account the quality of the code pro-
duced, only the quantity.
Management 45

Figure 3 .6-B ar Chart: Person A does tasks T1, T2, and T4, while Person B does
tasks T3 and T5.

There are a number of different tools available to help schedule pro-

jects. While bar charts provide a useful visualization of part of project
planning, they fail to show dependencies among tasks. For instance, if T3
has to be done before T4, then a delay in the completion of T3 must be
reflected in a change in the timing of T4 (see Figure 3.6 Bar Chart).
Activity networks overcome this deficiency, as they portray dependen-
cies. Each node of an activity graph represents the culmination of one or
more activities. A labeled arc from one node to another could represent
the name of the activity along with the time required to complete the
activity.
46 Chapter 3

To develop a schedule, a project is first broken down into tasks. Next

one asks: ‘What other tasks must be completed before this task finishes
?’ ‘How long will it take to perform this particular task ?’ Given a project
begin time, one can compute the ‘Earliest Begin’ and the ‘Earliest Finish’
times for each task, and the total project duration.

E p ilo g ue
Producing large systems is a difficult task of managing both people and
information. This is true in a reuse environment where extra personnel,
such as those that manage and retrieve elements from the reuse library,
are needed. The Chief programmer approach to software team organiza-
tion includes reuse-oriented roles, such as the librarian role.
Of the many models which have been developed to model the devel-
opment of software systems, the COCOMO model is perhaps the best
known. It estimates the number of lines of code that a project will need to
produce and shows interesting relations among project type and effort
required. Reuse parameters can be folded into the COCOMO model.
The mythical man-month notion (Brooks, 1975) shows that adding
more people to a project does not necessarily reduce the time needed to
finish the project. Adding a person to the project may bring more com-
munication costs than productivity benefits. Initiating a reuse effort may
initially require additional staff and their concomitant costs.
To schedule a software project, tasks and their dependencies must be
appreciated. Software reuse introduces new tasks and dependencies. The
challenge then is to manage these dependencies so that overall benefit
exceeds overall cost.
Section 2
Enterprise and
Standards

This section contains two chapters. The first details a conceptual frame-
work for reuse. A reuse life cycle for software assets is described that
centers around the library of assets. The human issues in the reuse
framework are also emphasized in a cycle of activity that goes from plan-
ning to enactment to learning. The enterprise chapter also addresses eco-
nomics and legal issues. Software reuse involves many, many aspects that
are both concerned with people and with software. For instance, to estab-
lish a software reuse library one should first estimate the costs of devel-
oping software with or without the library. Legal matters, such as copy-
right, may play an important role in determining what is or is not reused.
The second chapter of this section looks at standards relevant to
reuse. Reuse in some fundamental ways requires standardization. People
have to agree on the language of discourse, assets have to be able to com-
municate with other assets through standard interfaces, and organizations
must communicate in clear, systematic ways to their employees about
processes for reuse. Certainly, standards within an organization exist but
these are being supported increasingly by formal, global standards, and
those are the subjects of the second chapter in this Section.
Chapter 4
R eu se Framework

The vision for reuse is to move from the current6re-invent the software’
cycle to a library-based way of constructing software (DoD, 1992). A
conceptual framework for reuse should provide the technological and
management basis to influence and enable this paradigm shift. In this new
paradigm the standard approach to software development is to derive sys-
tems principally from existing assets rather than to create the systems
anew. Reusable assets are thus a central concept of the reuse vision, and
they imply a need for processes to create such assets, manage them and
utilize them to produce new systems.
Experience suggests that this library-based approach must be
domain-specific. Being domain-specific means that the reusable assets,
the development processes, and the supporting technology are appropri-
ate to the application domain for which the software is being developed.
Application domains are generally considered to be broad in scope, for
example communication systems. The effectiveness of domain-specific
assets depends on a number of factors, including the maturity of the appli-
cation domain and the investment applied to create the assets. As a
domain matures, it generally becomes more stable and better understood,
thus increasing the likelihood that assets will be reusable. However, even
in mature domains, asset reusability and quality will be maximized only
if suitable investment has been applied to identify and exploit key reuse
opportunities. Domain analysis and its resultant models are critical to the
success of a domain-specific reuse program.

49
50 Chapter 4

P r o c e s s Idioms and S o u r c e s
Software engineering should be done in accordance with well defined,
repeatable processes. One framework for reuse consists of dual, intercon-
nected ‘process idiom s’ called Reuse M anagem ent and Reuse
Engineering (see Figure 4.1 Reuse Management and Reuse Engineering).
Outputs from the Framework are software systems and new reusable
assets.

Figure 4 .1 -R eu se M anagem ent and R euse E ngineering: Plan, Enact, and

Learn are in the M anagem ent idiom. Create, M anage and Utilize are in the
Engineering idiom.

The Reuse Management idiom describes a cyclic pattern of activity

addressing the establishment and continual improvement of reuse-orient-
ed activities within an organization by emphasizing learning as an
Reuse Framework 51

institutional mechanism for change. Learning in this context means

actively evaluating and reflecting on behavior to effect positive change.
The Reuse Engineering idiom also explicitly recognizes the role of the
broker as a mediator between asset producers and consumers. The Reuse
Management and Reuse Engineering idioms represent reuse-specific
adaptations of more general forms of organizational activity. The
Framework specializes these more general idioms to facilitate adaptation
of a wide body of management and organizational theory to the software
reuse problem.
The Framework is generic with respect to domains, organizations,
and technologies. Framework concepts should generally be applicable to
reuse in any information-intensive context, such as technical documenta-
tion or scientific information management. The scope is limited to iden-
tifying the processes involved in reuse and describing at a high level how
those processes operate and interact.
The Framework which is described in this chapter is largely based on
a document entitled “STARS Conceptual Framework for Reuse
Processes” (Boeing, 1993). That document reflects an effort to modern-
ize software productivity by the Software Technology for Adaptable,
Reliable Systems (STARS) program of the U.S. Department of Defense.
The Framework reflects the experiences of software reuse efforts both
within and outside of STARS. The Framework provides a conceptual
foundation for reuse processes needed to accomplish the STARS reuse
mission. However, for an organization undertaking a reuse program, the
Framework must be augmented and numerous documents provide infor-
mation for such an augmentation (STARS, 1993; 1993b; Virginia, 1992;
Frakes and Gandel, 1990)
Naturally, other organizations also have reuse frameworks. For
instance, the North Atlantic Treaty Organization has published a 3-vol-
ume standard for software reuse (GTE, 1992a, 1992b, 1992c). The vol-
umes are entitled:

• Development of Reusable Software Components,

• Management of a Reusable Software Component Library, and
• Software Reuse Procedures.

The content of these 3 volumes is in principle harmonious with the con-

tent of the ‘Conceptual Framework for Reuse’ of STARS.
52 Chapter 4

Figure 4.2-Reuse Management: Planning, Enacting, and Learning include the

processes.
REUSE MANAGEMENT
• Planning
Assessment
Direction Setting
Scoping
Infrastructure Planning
Project Planning
• Enacting
Project Management
Infrastructure Implementation
• Learning
Project Observation
Project Evaluation
Innovation Exploration
Enhancement Recommendation

R e u s e M a nagem ent
Reuse involves both people and information. The Reuse Management
process idiom focuses on people. It describes a cyclical pattern of plan-
ning, enacting, and learning (see Figure 4.2 Reuse Management). Reuse
Management incorporates emerging general theories of organizational
learning (Senge, 1990) that have been adapted to the reuse-based soft-
ware engineering context. The following subsections deal with managing
people, but later this chapter will emphasize the information- side o f reuse
under the headings of Asset Creation, Asset Management, and Asset
Utilization.
Reuse Planning
The Reuse Planning process encompasses both strategic planning and
tactical, project-oriented planning within a reuse program. One key
strategic reuse planning function, which augments traditional product line
planning within an organization, is to select the key domains of focus for
the reuse program and determine how the domain assets will support the
organization’s product engineering efforts. One key focus of Reuse
Planning is the reuse infrastructure that is required to sustain a reuse-
Reuse Framework 53

based software engineering approach. The outputs from the reuse

Planning family include:

• Plans for the reuse program, and

• Committed resources to support the projects, in terms of staff and
equipment.

The five processes in planning are Assessment, Direction Setting,

Scoping, Infrastructure Planning, and Project Planning.

1. Assessment processes characterize the current state of reuse prac-

tice within an organization, the readiness of the organization as a
whole for practicing reuse-based software engineering, and the
reuse technology and expertise available.
2. Direction Setting processes define specific objectives for the reuse
program, strategies for achieving those objectives, and criteria for
evaluating how successfully the objectives have been met.
3. Scoping processes define the overall scope of the reuse program by
delineating the program’s technical and organizational boundaries.
The technical scope is defined in terms of the domains and prod-
uct lines to be encompassed by the reuse program, while the orga-
nizational scope is defined in terms of the program’s organization-
al context and management influence.

A first step in domain selection is to identify and characterize promis-

ing candidate domains, based on the organization’s business interests, key
areas of expertise, and existing legacy systems. Criteria for identifying
promising domains include (Holibaugh, et al, 1989):

• The domain is well-understood, and

• The domain is based on predictable technology that will not make
the reusable assets obsolete before the investment in their devel-
opment can be recovered.

4. Infrastructure Planning processes identify needs for various types

of support that are common among planned reuse projects, and
develop plans for establishing a shared reuse infrastructure to sat-
isfy those needs.
5. Project Planning processes plan the reuse program’s Reuse
Engineering projects in detail. Project Planning is responsible for
54 Chapter 4

establishing specific objectives for each identified project, and for

defining the metrics to be used to evaluate the effectiveness of the
projects relative to those objectives. A variety of metrics can be
defined relating specifically to assets and reuse, such as:

• The percentage of each application product that was directly

derived from domain assets,
• The number of times each asset has been reused, and
• The number of regular users of an asset library.

The final stage of Project Planning is to plan the reuse project’s

resource needs, budgets, and schedules in detail and then obtain the nec-
essary commitment to implement the plans. Commitment should be
obtained from both higher level management and the technical staff mem-
bers whose buy-in will ultimately determine whether or not reuse practice
is really improved by the program.
Reuse Enactment and Reuse Learning
Reuse Enactment addresses initiation, performance, and retirement of the
various reuse-related plans. Reuse Enactment includes Project
Management processes and Infrastructure Implementation processes.
Project Management processes establish a temporal context for reuse
project activities and include the following specific functional areas:

• Project initiation activities include allocation and tailoring of tech-

nical reuse infrastructure capabilities to specific projects.
• Project performance is where the processes being enacted are actu-
ally performed by individual staff members.
• Project control activities intervene with project performance to
optimize overall project performance relative to project objectives.
• Project monitoring activities capture information from the projects
as they are performed.
• Project retirement activities include terminating the project and
archiving the key results.

Infrastructure Implementation processes ensure that reuse infrastruc-

ture capabilities are established and evolved in accordance with project
needs.
Reuse Framework 55

The goal of Reuse Learning processes is to enhance the performance

of a reuse program. The results of Reuse Learning are fed back to Reuse
Planning processes in the form of recommendations for the next reuse
program cycle. Reuse Learning includes Project Observation and
Innovation Exploration processes.
Project Observation processes gather information about enacted
reuse projects. A primary goal of Reuse Learning processes is to support
the evolution of an organization’s reuse-based software engineering capa-
bilities. Innovation Exploration processes address this goal in a different
way than Project Evaluation, by gathering, generating, analyzing, and
testing new ideas, discoveries, and innovations to generate recommenda-
tions for major improvements.

A s s e t Creation
Reuse Engineering addresses the creation, management, and utilization of
reusable assets. Asset Management serves a brokerage role between
Asset Creation and Asset Utilization and reflects common marketplace
interactions (see Figure 4.3 Decomposition of Reuse Engineering). In an
organization that has a mature reuse program underway, there will likely
be multiple Asset Creation, Asset Management, and Asset Utilization
projects in operation simultaneously.
The goals of Asset Creation are to capture, organize, and represent
knowledge about a domain, and use that knowledge to develop reusable
assets. Asset Creation can be viewed as consisting of:

• 1 Domain Modeling processes that characterize application prod-

ucts in terms of what the products have in common and how they
vary, and
• 2 Asset Implementation processes that produce reusable assets.

Domain models and asset bases are logically at different levels of

abstraction and serve different purposes. The primary role of domain
models within Asset Creation is to assist in determining which asset
should be produced and the range of characteristics they should support.
For that reason, domain models focus on describing the commonality and
variability among systems, rather than op describing the systems them-
selves. The assets that are developed using the domain models are at a
lower level of abstraction, they implement products.
56 Chapter 4

Although there are many domain analysis methods (e.g.„ STARS,

1993b; DISA, 1993), there remains little consensus on specific tech-
niques. However, many existing domain analysis processes have in com-
mon the following general activities:

• Reverse engineering,
• Knowledge acquisition,
• Technology forecasting,
• Domain modeling, and
• Asset specification.

To extract expertise already encoded in legacy systems, they are often

analyzed using reverse engineering techniques. Processes to support
knowledge acquisition in domain analysis can be adapted from knowl-
edge acquisition techniques used for in-depth interviewing in any disci-
pline.
In order for reuse to remain viable over a period of years so that a
return on the investment in asset creation will be fully realized, forecast-
ing of future trends is essential. Then an organization can accommodate
changes in a manner that will allow smooth evolution and modernization
of assets over time. If knowledge acquisition is a craft, technology fore-
casting is an art. Short term forecasts of a few months can often be devel-
oped with reasonable confidence. Long term forecasts of several years are
difficult to develop with confidence.
After the gathering of domain information by reverse engineering,
knowledge acquisition, and forecasting, the information is integrated into
domain models that can be used to support asset specification and devel-
opment. This is usually done in an ad hoc manner because general meth-
ods do not adequately support comprehensive model synthesis of this
nature. Domain models need to be validated in some way to establish
confidence in their correctness and utility. Processes supporting model
validation include walkthroughs, expert reviews, and trial application of
assets derived from the models.
The goal of Asset Implementation is to produce the assets in the asset
base. This could be done by creating the assets from scratch with guid-
ance from the domain models as to what kinds of components should be
developed. Alternately, a company may require that its software develop-
ers provide whatever code they develop to the software reuse librarians
so that it can be considered for incorporation into the library. This latter
Reuse Framework 57

case in which libraries acquire existing components is discussed in the

next sections.

Figure 4.3-Decomposition of Reuse Engineering: The three main processes

of engineering reusable assets, namely, creation, m anagem ent, and utilization,
are shown here with their many subprocesses.

• Asset Creation
Domain Analysis and Modeling
Domain Architecture Development
Asset Implementation
• Asset Management
Library Operation
Library Data Modeling
Library Usage Support
Asset Brokering
Asset Acquisition
Asset Acceptance
Asset Cataloging
Asset Certification
• Asset Utilization
Asset Criteria Determination
Asset Identification
Asset Selection
Asset Tailoring
Asset Integration

A s s e t M a nagem ent
The Asset Management processes fall into two general classes: processes
that focus on acquiring, installing, and evaluating individual assets in a
library, and processes that focus on developing and operating libraries
that house collections of assets, provide access to those assets, and sup-
port their utilization (see Figure 4.4 Managing Engineering). Asset
Management overlaps in some ways with Reuse Management.
Organizational assets, such as plans, are generally treated as part of the
reuse infrastructure, while library support technology is generally
58 Chapter 4

considered the province o f Asset Management. Asset Management

addresses the selection and support of technology that is inherently
asset-, library-, or domain-specific, or tailored to be so

Figure 4.4-M anaging E ngineering: The reuse cycle is shown with detail pro-
vided for the M anagem ent phase in which Library and A sset processes occur.

Li br a r y Processes

Asset Processes

Library P r o c e s s e s
A library houses managed asset collections. A library need not be auto-
mated to effectively manage a collection of assets and serve a useful
mediator role between Asset Creation and Asset Utilization processes.
The goal of Library Operation processes is to ensure the availability
and accessibility of the library and its associated assets for Asset
Utilization. This can involve a variety of activities, such as:
Reuse Framework 59

• Administration and operation of the physical library facility,

• Library access control and security,
• Periodic archiving and backup of library contents, and
• Support for interoperation with other libraries.

These activities are strictly operational in nature, and organizations

may consider them to be aspects of general infrastructure. However, there
are aspects of these activities that relate specifically to asset libraries and
merit attention from an Asset Management perspective. Some typical
library user roles, corresponding to some of the Asset Management and
Asset Utilization processes, include library data modeler, asset cataloger,
asset certifier, library operator, asset utilizer, and asset broker.
The goal of Library Data Modeling processes is to develop a data
model for describing assets within a library. This library data model syn-
thesizes the domain models, asset models, and assets. The specific
approach is thus dependent on the characteristics of the Asset Creation
products and on the objectives of the library in supporting Asset
Utilization. If the library’s objectives are to provide a basic search and
retrieval capability for individual assets, it should suffice for the library
data model to include mainly taxonomic information derived from one or
more domain models. If the objectives are more ambitious, then the
library data model must integrate additional elements of the domain
models.
In addition to incorporating information produced by Asset Creation
processes, the library data model also codifies information that specifi-
cally addresses Asset Management needs. For example, a model could
include data elements to record asset certification information and user
feedback data. In addition to simply operating a library and making assets
available within it, Asset Management should provide a set of library ser-
vices that anticipate and address specific asset utilizer needs. Examples of
these kinds of services include:

• the collection and generation of asset data in a number of different

formats, including a variety of media (e.g.„ paper and on-line files)
and data representations (e.g.„ text and executables), and
• the operation of electronic hot lines to accept and resolve user
complaints.

Specific tools can support activities such as viewing assets, executing

assets for evaluation, extracting sets of closely related assets, and so on.
60 Chapter 4

An often critical form of Library Usage Support is direct, personal

assistance to users. These consultation services can be likened to the role
of the traditional librarian in conventional book libraries. Such services
can be automated to some degree, but may be most effective when ren-
dered in person. This person-to-person approach can effectively lower the
technological barriers to reuse that typical library software presents to
many users.
A related form of library user support services is asset subscription,
which allows users that ‘subscribe’ to a particular asset to be informed of
all changes to that asset as it evolves. The kinds of asset changes about
which a user can be notified include identification or resolution of errors,
changes in classification, development of new variations, and addition of
new usage history data.
Asse t P r o c e s s e s
Related to activities considered library processes are asset processes.
These include asset brokering, asset acquisition, asset acceptance, asset
cataloging, and asset certification (Boeing, 1993). Localized efforts may
monitor asset flows, interactions, and feedback among Asset Creation,
Management, and Utilization processes, and apply that knowledge to
work proactively with all concerned parties to improve effectiveness in
particular areas. Such activities can be viewed as Asset Brokering
processes.
The principal goal of Asset Acquisition is to obtain assets from exter-
nal sources to support Asset Utilization activities. Asset Acquisition
obtains assets that appear to be good candidates for inclusion in an asset
library. The goal of Asset Acceptance is to ensure that an asset that is a
candidate for inclusion in a library satisfies relevant policy, legal, and
domain-specific constraints. The purpose of library policy constraints is
typically to ensure that assets in a library satisfy at least minimal criteria
for quality and suitability for use in Asset Utilization activities. Asset
Cataloging incorporates accepted assets into a library classifying,
describing, and installing them. Asset certification goes beyond asset
acceptance and puts the ‘official seal of approval’ on an asset after rigor-
ous testing.
Other perspectives on asset processes exist. One view emphasizes
actual software rather than software-related documents and tends to call
assets by the name ‘components’. In this view, the library receives from
its customers and others, recommendations for components to add to the
library. A file may be maintained for every proposed component (GTE,
1992a). This file would note for the component its description, availabil-
Reuse Framework 61

ity, and rationale for its request. The librarians evaluate each proposal for
a component to ensure that the proposer has, at least, one application in
mind, to assess the cost-effectiveness of the component, and to identify
other beneficial characteristics, such as wide applicability and low
complexity.
The library acquires reusable components from numerous sources.
There is no absolute need for the library to contain a physical copy of
each component. A component would be incorporated by reference only,
if it is:

• maintained and distributed by an outside organization or

• executable code.

When a component is incorporated by reference, the library should

provide on-line instructions for obtaining the component and documenta-
tion for the component.
The fundamental criterion for acceptance of a component into the
library is cost-effectiveness. The cost of obtaining and reusing the com-
ponent must be less than the cost of developing the desired capability
directly. One aspect of a component is the method by which it was pro-
duced. A component developed with sound methods by a recognized
team of software developers has a greater likelihood of being easy to
reuse than a component developed in some other way. No product, how-
ever, can be considered reusable if it lacks an understandable description
of its capabilities and clear instructions on its use. If a reusable compo-
nent is incorporated by reference, quality assessment information is still
required. The folder for a component ready for accession contains con-
siderable information. This information should include a user’s manual,
testing data, and quality assessment. Once the necessary supporting mate-
rial, including the classification of the component is available, the librar-
ians assimilate the component into the library and distribute information
about its availability to the library users.

A s s e t Utilization
The goal of Asset Utilization is to construct new application products
using previously developed assets. The outputs from Asset Utilization
include:
62 Chapter 4

• Software Systems and other application products that are con-

structed from assets,
• New assets for incorporation into the asset base, and
• Feedback concerning the library and its assets.

Asset Utilization generally involves determining a set of criteria to

use in selecting assets for reuse, identifying suitable candidate assets in
the context of those criteria, selecting and tailoring assets to meet the cri-
teria, and integrating the tailored assets with the target application.
The reuser must tailor assets that have been selected for reuse so that they
satisfy target system requirements. This tailoring generally comes in two
forms, either or both of which may be applied to any given asset:

• Anticipated Target system needs lie within the range of variability

anticipated for an asset during Asset Creation; the asset encapsu-
lates the variability through some set of tailoring interfaces (such
as parameters); these interfaces can be used to resolve the vari-
ability to meet target system needs.
• Unanticipated Target system needs lie outside the range of vari-
ability anticipated for an asset during Asset Creation (e.g.„ there is
a need for new features where no variability was anticipated); the
asset thus provides no relevant tailoring interfaces that can be
applied and must be modified to address the unanticipated target
system needs.

To perform anticipated tailoring, an engineer must understand the

range of variability an asset may accommodate and how the asset’s tai-
loring interfaces are used to select among the variations. This information
should be included in the library in the form of ‘reuse instructions’ for the
asset, which may be augmented by examples. In addition to parameteri-
zation, another technique that can be used for anticipated tailoring is hand
modification of the asset in accordance with precise instructions. An asset
that can be tailored in this manner is typically called a template.
Unanticipated tailoring is more of an ad hoc process in which the
engineer assesses the asset’s shortcomings relative to system needs and
then employs whichever strategies are appropriate to tailor the asset to
those needs. This often involves hand modification of the asset to add
desired features or remove undesired features. Modifications may also be
needed to address issues such as performance, environment compatibili-
ty, and safety, reliability, or other quality factors.
Reuse Framework 63

Figure 4.5-Reuse Costs: Initially the cost of the reuse program is very high, as
the library of reusable items is built. Returns cannot start until the library is usable,
and then will tend to be low, a s the library needs to becom e suited to the devel-
opers who use it and gaps in the libraries content are filled. The final level of
return is uncertain, it should becom e high and remain high, but this will depend
on the quality of the reuse library, it’s retrieval system and the willingness of
developers to reuse.

M on ey

C o sts v e rs u s B enefits

Software reuse is difficult for companies to initiate because it has the least
desirable cost structure, initially very high, recouping over time. Start-up
costs include setting up the software component library that will be
64 Chapter 4

needed, training staff to set up the library, populating the library and train-
ing the software development teams to use the library software and reuse
the actual components. Gradual returns over the life of the library should
pay for initial costs over a period of time, and return profits, but may not.
There are other possible benefits in the quality of the software produced
and minimization of developer time and resources, but these benefits may
be difficult to measure (see Figure 4.5 Reuse Costs).
To be willing to provide an investment in reuse, companies will need
proof of the benefits of reuse. Some of the benefits of reuse are tangible,
for example the time to build a project should be reduced. But the way to
prove that project development time had been reduced would be to build
a project using conventional means and then to ‘go back in time’ to before
it was written and to create it again using exactly the same people, with-
out the knowledge they gained by building the system in the first case,
with reusable components. This is of course impossible, and would in any
case be inconclusive since the benefits of reuse will vary from project to
project. Most of the benefits of reuse, increased quality of programs and
documentation, less testing required, fewer skills needed within the
development team, and the production of components available for future
projects, are difficult to measure.
Reuse is only cost effective if it actually takes place. If on a project
reuse options are investigated, i.e., requests for reusable components are
formulated and submitted to the library system, and some components
retrieved and investigated for suitability and none of them prove suitable
or none are found, then a perhaps significant amount of time has been
wasted by the developers. Also the library has failed to live up to its
expectations on this project and thus no money used to set up and run the
reuse library has been recouped. For a new library and reuse methodolo-
gy unless very significant amounts of money have been spent creating the
library, then low returns on reuse should be expected on quite a regular
basis. The components created (since reusable ones could not be found)
should be used to add to the library, but this will be more expensive than
custom-creating the components for just this project.
The method used to estimate reuse costs and benefits should be com-
patible with the methods used by the rest of the company. The two quan-
tities of primary importance are:

• the net saving to the individual user for each instance of reuse of a
component and
• the net saving to the company from all reuses of the component.
Reuse Framework 65

The quantities in the analysis can be expressed either in some mone-

tary unit or in labor hours. Benefits may be categorized as (GTE, 1992a):

• The savings due to reuse, S R, is the sum of costs avoided each

time the component is reused.
• The service life, L, is the useful lifetime of the component in years.
• Demand, is the number N, of times the component is likely to be
used during its service life. If the costs and benefits may vary from
year to year, then the demand should be apportioned per year as N
y where y = 1,2, ..., L.

The costs associated with a component may be formalized as:

• The cost to reuse, C R, is the cost incurred each time the compo-
nent is reused, including retrieval and tailoring costs.
• The accession time, T A, is the amount of time between the deci-
sion to acquire the component and its availability in the library.
• The accession cost, C A, is the cost to add the component to the
library.
• The maintenance cost, C M, is the cost to maintain the component
in the library. Again if yearly costs vary, the maintenance cost dis-
tribution C My where y=l, 2,..., L is the cost to maintain the com-
ponent for each year of its service life.

Risks which might be incurred need to be estimated. These may be

due to a dependency on a particular environment or configuration, obso-
lescence of the design or code, and legal obstacles. These risks can be
accommodated in the preceding variables as appropriate.
The net saving NSR to the individual for each instance of reuse is the
difference between the saving due to avoided cost and the cost to reuse,
or in symbols, NSR = SR - CR. The total savings from all instances of
reuse is NSR multiplied by the number of reuses. Thus the net savings
from all reuses NSP is the total saving minus the accession and mainte-
nance costs, or in symbols, NSP = (NSR x N) - (CA + CM).
The NSP may be calculated on an annual basis. For each year, NSPy
= (NSR x Ny) - CMy. This calculation assumes that the accession cost is
incurred prior to the beginning of the first year of service and is recorded
separately. The cost estimation method may include an adjustment for the
fact that future cash flows decrease in value with time at a rate that can
66 Chapter 4

be given the discount rate i. Thus the annual discounted NSP can be given
as DNSPy = ( ( NSR x Ny) - CMy) / (1 + i)y.
To compare two potential reusable components to determine which to
acquire for the library and which not, the cumulative discounted cash
flow CDCF for each would be determined and the component would be
preferred with the higher CDCF. CDCF = DNSP! + DNSP2 + ... +
DNSPl - CA. With the appropriate data and these formulas, a company
can better plan its reuse investments.
Depending on the management strategy adopted by the software
development company, the costs of reuse may be absorbed by the devel-
oper in the hope of creating similar projects later, and thus recouping the
investment that way. Or alternatively the developer may form a partner-
ship with the client, where initial startup costs and any later benefits are
both shared.

Legal I s s u e s
If the client of a software house is willing to allow the software house to
reuse components developed for them for other clients who need similar
systems, then the software house has more reasons to practice software
reuse. However who it is that is the owner of a component developed for
a project could be a thorny issue. Does permission need to be sought to
include a component developed for a project in a library, if that compo-
nent is generic? Should commission be paid to the instigating client?
These issues may be soluble by written agreements listing terms and con-
ditions between the client and the developers.
Legal issues affect a reuse effort as they effect any other endeavor
that involves the utilization of the work of others in the creation of new
work. There must be clear legal boundaries defining what is reuse and
what would constitute plagiarism. Copyright exists in most western coun-
tries to some extent, and motion pictures and books have well defined
protection in law (Lahore and Dworkin, 1984). In nearly all countries
legal protection of software is more hazy as the law attempts to get to
grips with and catch up with the technologies to hand.
Within the European Union moves are under way to standardize leg-
islation between the various member states. Computer software is gener-
ally regarded as intellectual property and as such may be protected under
patent and copyright law. The copyright protects the expression of the
software, the routines and the order in which they are called. Whereas
patent protects the industrial realization of the concept. That the rationale
Reuse Framework 67

behind the software is protected by patent extends the protection beyond

simply the code to cover flow charts or pseudo code and thus protects the
author against language translation, reverse engineering and adaptation of
the code. Although under the United Kingdom Patents Act 1977 comput-
er programs as such are described as expressly non-patentable inventions,
patents may be granted for new and improved products incorporating
inventive concepts embodied in a computer program (Edwards, et al,
1990).
The granting of a patent to an individual or organization grants to the
holder monopoly rights over the subject of the patent for a period of nor-
mally twenty years. The criteria upon which a patent application will be
granted are that it is of a technical nature, is new and makes a technical
contribution to the known art. Taking out a patent offers greater protec-
tion to the author than is available under copyright as there is no onus to
prove copying has taken place. The major drawback is the time taken to
process patent applications and that making the application for a patent
reveals to the public the nature of the invention.
Copyright of software is a property right and means literally the right
to copy the literary or artistic work produced by the author. Literary con-
tent may refer to the program code or documentation. Artistic work may
refer to the user interface generated by the software. Copyright more
importantly restrains others from reproducing or adapting the contents of
an original work. Copyright protection is offered automatically - by order
of law - on the recording in writing (or storage in an electronic format) of
a copyright message stating ‘Copyright 1994 Our Company’. This applies
copyright to an original work and protects against copying and adaptation
of the work. The existence of a copyright, however, does not prevent
another organization arriving at a similar solution providing it does so by
independent means. In this respect a copyright, unlike a patent, does not
offer monopoly rights over a product. The copyright is applicable for a
period of fifty years from the date of publication.
For software reuse libraries bought from a vendor, the vendor’s
licensing agreement will generally include clauses amounting to non-
exclusive licensing of the software. As they are sold as reusable compo-
nents, they may be incorporated into a product which may be either for
distribution within the company or to be sold as a commercial product.
68 Chapter 4

Impact
To successfully set up a reuse program involves transferring research
approaches to reuse into standard industrial practices. Four main stages
are identifiable in the transfer process:

• the Audit,
• the Planning Stage,
• the Implementation, and
• the Evaluation.

The audit involves examining the current system and investigating

options for retaining parts of the existing process. This stage is especial-
ly important because for reuse to succeed, it is, of course, important to
build on any existing reuse practices, and in any case, it is common sense
to determine the current state of affairs before attempting to change it. In
any case, a baseline is required to determine whether or not the change
has been successfully accomplished. Moreover, at the start, it is essential
to determine the most fruitful areas in an organization where people are
likely to champion reuse, or where the most benefits from reuse practices
are likely to accrue.
Once an audit has been completed, the reuse planning team should be
in a position to plan a course of action with the aim of creating a situation
where reuse is standard practice. In formulating the reuse program plan in
the areas where existing reuse has been identified the aim should be to
improve on existing practice if possible, for example with better support.
In planning for implementation, some general consideration of the
channels of communication within an organization may be helpful.
During the actual implementation stage, it is helpful to build on any suc-
cesses in acceptance of reuse. Strategies to achieve this include encour-
agement of reuse champions and communication of best practice. As with
any new practice, it is better to implement a small but successful program
gaining the confidence of staff and then build it up, rather than attempt-
ing to establish a more grandiose scheme and lose the goodwill of staff.
In all accounts of successful reuse, the importance of ensuring that there
is management support for the reuse program has been stressed.
In considering the factors that influence effective reuse, attention
must be given to the process of reuse, supporting technology, potential
objects of reuse, standards, and other technical aspects. While technical
issues do require attention, it has been increasingly recognized that con-
sideration must be primarily given to non-technical factors such as man-
Reuse Framework 69

agement, scope of reuse program, economics and, perhaps most impor-

tant, the social implications. In this context, the use of quality circles has
been reported as offering an opportunity to introduce the concept of reuse
within a company as part of a broader concern to improve overall quali-
ty of the enterprise.
One of the main obstacles to software reuse in the large is the under-
standable tendency of software producers to protect their intellectual
property against competitors to maintain a commercial advantage. The
collaboration of these commercial entities to extend the benefits of soft-
ware reuse across company boundaries requires the existence of a benev-
olent organization to co-ordinate and fund the reuse activities. In the
United States this role is played by federal bodies, such as the National
Aeronautics and Space Administration and the Department of Energy,
who actively encourage software reuse by making available to contracted
organizations reusable components produced on behalf of the federal
body to all contractors in an attempt to reduce development time for soft-
ware as a whole. The initial cost for the federal body in creating the
reusable components is thus offset by the benefits incurred as the com-
ponents are reused in later projects.

E p ilo g ue
The themes about reuse as expressed in the Conceptual Framework for
Reuse Processes are:

• Software reuse has both management and engineering dimensions,

• Reuse should be applied as a ‘first principle’. That is, reusable
product should always be considered as the basis for work before
creating new products.
• Learning and managed change, based on measurement history, and
innovation, are essential to reuse.
• Technical, organizational, and educational infrastructure is essen-
tial to reuse, and must be designed and managed to support it.
• The asset producer, broker, and consumer roles are important, sep-
arable aspects of reuse that form distinctive patterns of activity
within the Reuse Engineering idiom.

The Framework is generic with respect to domains and technologies.

It can be applied in an organization of any size, at any organizational
70 Chapter 4

level. It provides a basis for the analysis of reuse processes and the defi-
nition of reusable assets.
The individual reuse processes gain synergistic value when viewed as
modular building blocks that can be used to construct a wide variety of
reuse-specific process configurations reflecting different planning levels,
organizational structures, and interaction patterns. To support the con-
struction of process configurations, the Framework should include a set
of composition techniques to connect the processes together in a variety
of ways. These techniques provide a flexible and scalable composition
approach enabling the Framework to capture aspects of reuse-based engi-
neering practice not easily described with traditional software life cycle
models.
Modifying the software life-cycle for reuse involves everyone
involved in the creation of software. Formulas exist for determining the
costs and benefits but obtaining realistic values for the variables in the
formula is challenging. Everyone from developers to those who manage
budgets and plan projects and even the final customers for the programs
produced will play some role in the ultimate value of the reuse effort. If
reuse is successful at a company, then everyone involved will benefit.
Developers will not have to waste time developing software repetitively
and costs will be reduced in the long term. These savings can be passed
to the customer in reduced costs, faster delivery, and increased reliability.
Chapter 5
Standards

The key to reuse is that people agree on constructs and methods.

Standards reflect this. Very few standards specific to software reuse have
been widely accepted by the international community. However, numer-
ous organization-specific reuse standards have been developed and they
are reviewed in this chapter.
The Reuse Planning Group was created by the IEEE Software
Engineering Standards Committee in April 1995 with the following
assignment:

The Reuse Planning Group will define for SESC a statement of direc-
tion for IEEE standards related to the analysis, design, implementa-
tion, validation, verification, documentation, and maintenance of
reusable software assets as well as their supporting infrastructure in
the creation of new applications.

The group began with an analysis of the needs of various users of

standards. Then a list of available, normative documents on the subject of
software reuse was compiled. These documents were evaluated for the
role that they might play in the standardization process. Finally, the doc-
ument articulated a model relationship between principles and practice
that new reuse standards should satisfy (Baldo et al, 1997). Using these
frameworks, it made recommendations.
The Master Plan for Software Engineering Standards (SESC, 1993)
provides a list of user expectations for standards. In overview, users
expect that the standards will ensure that software will provide a correct,
standard solution for well-known problems. The software will perform as
specified and expected, and is user friendly. The software can be
71
72 Chapter 5

modified within pre-defined limits which will meet specific requirements

without difficulty. The software satisfies operational, functional, and per-
formance requirements. The software is verifiable. The software quality
and cost can benefit from the reuse of artifacts (requirements, design, test
cases, and code). The software has sufficient associated data available to
make an intelligent acquisition choice. Use of standards should promote
reusable and portable software process artifacts and should permit reuse
of development environments. It should be possible to accurately esti-
mate the time and budget for software maintenance work. Standards
should include criteria for certification of software as fit for use and
reuse.

Expectations
User expectations have been annotated to categorize the kind of standard
that might address such an expectation. The lists of expectations here are
based on those contained in the IEEE SESC Master Plan for Software
Engineering Standards. At the beginning is a list of postulated roles that
reuse standards might fill. Each expectation is annotated with one or more
roles indicating that standards fulfilling the annotated role should address
the expectation.
The postulated roles are:

« d o m » Standards describing domain analysis methods or other

methods for identifying reuse opportunities could address these
expectations.
« p r o d » Standards describing the production of reusable software
assets could address these expectations.
«doc» Standards regarding the documentation of reusable soft-
ware assets could address these expectations.
« lib » Standards for libraries of reusable assets could address
these expectations.
« c e r t » Standards for certification of reusable assets could
address these expectations.
« in t» Standards regarding the mechanisms or frameworks for
integrating reusable assets could address these expectations.
Standards 73

« s w l c » Standards addressing how software reuse is integrated

into the overall software life cycle and/or life cycle processes
could address these expectations.
« a d o p t » Standards regarding the adoption of reuse practices
(including economics) could address these expectations.
«N A » These expectations are regarded as not applicable, usual-
ly because software reuse seems to introduce no issues beyond
those faced in other forms of software development.

The software user expects standards to ensure that:

• Software is categorized in a useful manner. « l i b »

• Software will provide a correct, standard solution for well-known
problems. < < d o m » « c e r t» « p r o d »
• Software will be measurable, measured, and sufficient for the
intended application. « N A »
• Software is supported, maintained, and has a planned enhancement
cycle. « s w l c »
• Software purchasers expect standards that ensure that:
• Processes, including selection criteria, for evaluating and selecting
purchased software. « s w l c » « c e r t »
• Information on the software package describes form, fit and func-
tion of the software. < < d o m » « l i b » « c e r t »
• The required environment for software is specified so that incre-
mental capability that is needed is easily identifiable.
« d o m » « lib »
• For each software release, there is a clear, concise articulation of
differences, features, new functions, limitations, and constraints.
« d o c » « lib »

Software asset managers expect the standards to provide require-

ments or guidelines that ensure:

• Criteria for determining the value of software as an asset will be

available. « a d o p t »
• Cost models for modifying versus replacing software are reliable.
< < a d o p t» « d o m » « s w lc »
74 Chapter 5

• Identification of reuse benefits of existing software assets.

« a d o p t» « s w lc »
• Common methods for identification and labeling components and
media to facilitate software library organization. « l i b »

The lists of expectations can be regrouped by role. For instance, the soft-
ware asset manager expects the standards to provide requirements or
guidelines that ensure that the theory for software depreciation schedules
has a practical business foundation and that cost models for modifying
versus replacing software are reliable.

Existing Related S ta n d a r d s
Which existing documents might be of use in a standardization program?
Documents are considered that are normative, (i.e., standard-like, in
nature). Each document is described in terms of its purpose, scope, and
audience. An evaluation is performed to assign each document a candi-
date usage.
Evaluation Criteria
The purpose of evaluating existing documents is to determine how they
might appropriately contribute to standardization efforts regarding soft-
ware reuse. Evaluation criteria are formulated to support the making of
such recommendations. The result of each evaluation will be an assign-
ment of a candidate usage for the document. There are four categories of
usage called base document, normative advice, helpful information, and
not useful with the following descriptions:

• Suitable for use as a base document in a standardization effort.

• Good, normative advice that could contribute to a standardization
effort.
• Helpful information that could be used whenever appropriate.
• Not useful for standardization efforts.

In determining the candidate usage, the following characteristics are

considered: Relevance, Impact, Normative Nature, Currency, and
Quality.
Standards 75

Relevance is determined on the basis of:

• significance to software reuse of the issues treated by the docu-

ment and
• the extent of the document’s potential for dealing with user expec-
tations.

The Impact criterion evaluates the extent to which the document has
already achieved acceptance in the reuse and software engineering com-
munity. Impact is determined on the basis of the following characteristics:

• How broad was the community of consensus involved in writing

the document?
• How broad is the current community that is applying the docu-
ment?
• How effective has the document been in improving software reuse
practice?

The Normative Nature criterion evaluates the extent to which the

document provides normative direction rather than information. Three
ratings are provided:

1. Conformance: To achieve this rating the document must have a

statement of conformance. Furthermore, it must be possible to
evaluate conformance in a manner that is reasonably objective,
(e.g., by measurement or by an administrative law judge).
2. Guidance: The document provides advice and recommendations.
3. Information: The document provides only information.

The Currency criterion evaluates the extent to which the document is

suitable for application today and in the foreseeable future. Three ratings
are provided: Far Seeing, Current, and Obsolescent, with the obvious
interpretations of each. Finally, the quality criterion depends on the clar-
ity and accuracy of the document.
Evaluation of Existing Documents
Next, existing documents are briefly described in terms of their audience,
purpose, and scope. The descriptions of the document are grouped by the
organizations that issued or maintain them.
76 Chapter 5

Software Engineering Standards Committee (SESC)

One of the major contributors of software standards is the IEEE Software
Engineering Standards Committee (SESC). Most of the products of the
SESC that are related to reuse are submitted to it by the Reuse Library
Interoperability Group (RIG). The RIG is an independent group of reuse
library users, operators, and vendors that are developing specifications
for the interoperation of reuse libraries. The RIG is comprised of more
than 150 individual members and about 20 organizational members par-
ticipating at various levels of activity. The RIG’s work is progressed to
the status of standards via its Memorandum of Understanding with the
IEEE SESC.
The RIG has produced a Data Model for Reuse Library
Interoperability - Basic Interoperability Data Model (BIDM) to describe
the minimal information that reuse libraries should be prepared to
exchange in describing their assets. This document is already an IEEE
Standard. The RIG has also developed extensions to the BIDM that may
be used for explaining the manner in which assets were certified for qual-
ity or other attributes and guidance for performing certification. This doc-
ument is being processed as an IEEE Standard. The RIG is in a very early
draft phase of a standard for the binding of the BIDM (IEEE Std 1420.1)
to HTML and to SGML.
ARPA
The United States Advanced Research Projects Agency (ARPA) has sev-
eral programs of worth to RIG. Its Conceptual Framework for Reuse
Processes (Boeing et al, 1993) was described in the previous chapter. The
primary audience is project planners, process engineers, and reuse advo-
cates. The principal purpose is to define a conceptual framework that
describes reuse in terms of the processes involved. The framework is
intended to be generic with respect to domains, organizations, economic
sectors, methodologies, and technologies. The scope of the CFRP is lim-
ited to identifying the processes involved in reuse and describing at a high
level how those processes operate and interact. In so doing, it indicates
how some reuse processes can be integrated with other processes. It does
not prescribe how reuse can be implemented. Legal, business, and acqui-
sition aspects of reuse are outside the scope. The CFRP is considered a
highly relevant document with high impact (see Figure 5.1 ARPA
Evaluation).
Standards 77

Figure 5.1-ARPA Evaluation: The docum ent titles are in the first column. The
document attributes are given in the first row. The other entries are the values on
each attribute for each document.
Document Relevance Impact Nature Currency Quality Usage
CFRP High High Guidance Far Seeing Good to Base
High Document
Strategy High Some Conform Far Seeing Good Normative
Advice
Direction- Relevant Some Guidance Current Good Normative
Level Advice

The Reuse Strategy Model (Boeing, 1993) has an intended audience of

business and project planners whose organizations are making the transi-
tion to domain-specific, reuse-based development practices. The docu-
ment is intended as a planning aid for reuse-based projects. It provides a
set of dimensions for characterizing current reuse practice and a suggest-
ed process performing the characterization. Based on the results, a vari-
ety of reasonable goals are provided. The model presumes that the project
has been characterized with respect to the STARS CFRP, and that the
organization wishes to move toward domain-specific, reuse-based devel-
opment practices.
The Direction-Level Handbook for Reusable Defense Software
(Paramax, 1992) is directed toward Department of Defense acquisition
executives to facilitate their institutionalization of software reuse. The
document provides a framework to assist acquisition executives in estab-
lishing plans to manage reuse across the systems under their purview. It
is intended to assist in initial planning for new acquisitions as well as
other critical points within the life cycle.
United States Department of Defense
The United States Department of Defense Software Reuse Initiative has
produced several documents of interest to the standards community. The
Software Reuse Executive Primer (DoD, 1995) targets defense acquisi-
tion managers. It provides a simple and understandable overview of soft-
ware reuse. The primer appears to be applicable within the defense acqui-
sition community and specific to their particular problems and proce-
dures. This Department of Defense document has had little impact (see
Figure 5.2 DoD Document Evaluations).
78 Chapter 5

Figure 5.2-DoD Document Evaluations: Two DoD docum ents are listed in the
leftmost column and their attributes are nam ed in the top row.
Document Relevance Im pact Norm ative C urrency Quality C andidate
N ature Usage
P rim er R e le v an t Som e to In fo rm atio n C u rren t G ood H elp fu l
L ittle In fo rm atio n

Business H ig h Som e G u id an ce F a r Seeing G ood N o rm a tiv e

Model A d v ice

The Software Reuse Business Model (DoD, 1995) targets manage-

ment involved with incorporating reuse into the acquisition process and
individuals responsible for making reuse happen. The document is far-
seeing and should be of normative value in fixture reuse standardization.
This document presents a business model detailing the incorporation of
reuse principles into the acquisition cycle of software systems within the
Department of Defense. The focus is the steps involved in performing
systematic software reuse including activities, information, processes,
and tools.
United States Armed Forces
The United States Armed Forces have produced various software reuse
standards. In the Guidelines for Successful Acquisition and Management
o f Software Intensive Systems (USAF, 1995) software reuse is a central
theme. The audience is anyone responsible for the acquisition, manage-
ment, or support of major software development efforts. The document is
rather focused on Department of Defense systems and, thus, not of nor-
mative value for international standardization.

Figure 5.3-Armed Forces Standards: The two Armed Forces docum ents are
listed in the leftmost column and their attribute values in the interior cells of the
array.
Document Relevance Im pact Norm ative C urrency Quality C andidate
Nature Usage
Acquisition R e le v an t Som e In fo rm atio n C u rren t G ood H e lp fu l
In fo rm a tio n

Guidelines R e le v an t Som e G u id an ce O bso le te G ood H elp fu l

In fo rm atio n
Standards 79

The document Software Reuse Guidelines (USAF, 1990) provides

guidelines for U.S. Army development groups undertaking software
reuse. Management and technical issues are discussed. Management
issues include: impediments to reuse; the creation of incentives for reuse;
and incorporating reuse into a software development and maintenance
process. Technical issues include: domain analysis; preparing reusable
assets; assuring asset quality; and classifying, storing, and retrieving
assets. Some sections place emphasis on Ada. This and the other Armed
Forces document are of moderate value to further reuse standardization
(see Figure 5.3 Armed Forces Standards).
Software Productivity Consortium
The Software Productivity Consortium has produced several documents.
The Reuse Adoption Guidebook (Virginia, 1992) targets business organi-
zations that want to begin adopting software reuse practices to better meet
their goals or to become more competitive. It is more specifically orient-
ed to those that need to further examine the applicability of reuse tech-
nology and need support in identifying and implementing required
changes. The Guidebook describes a reuse adoption process controlled by
the organization’s objectives, opportunities, and current capability. An
important component is a reuse capability model that assists in under-
standing current capabilities and establishing goals.
The Reuse Adoption Guidebook model is strongly tied to the Software
Productivity Consortium Synthesis framework. Synthesis provides a
domain engineering process to create a product family and an application
engineering process to create specific instances of the family in response
to customer needs. Nevertheless, the document is highly relevant and pro-
vides normative standards material.
The Domain Engineering Guidebook (Software Productivity
Consortium, 1992) is intended for use by business-area managers, project
managers, and engineers. The guidebook defines two instances of the
Synthesis approach for the development of families of software products.
Again this document is considered highly relevant.
Others
The American Institute of Aeronautics and Astronautics has a Guide for
Reusable Software: Assessment Criteria for Aerospace Applications. The
Guide is intended for use by software personnel, including managers,
engineers, librarians, analysts, and researchers. The Guide is intended to
focus on the domain of aerospace applications, but much of the advice is
80 Chapter

generally applicable. The section on domain analysis surveys various

approaches and then develops criteria for domain analysis and the princi-
pal products of the analysis. The next section describes asset assessment
criteria in three categories: domain (suitability to application); reuse
(potential value of assets to other projects); and software (development of
reusable components). The final section discusses how assessment infor-
mation can be captured in a library and suggests some criteria for evalu-
ating reuse libraries. The document is a candidate for normative advice.
The National Institute of Standards and Technology has prepared a
managerial overview of software reuse (Wong, 1986). The report pro-
vides an overview of the various aspects, problems, and benefits of soft-
ware reuse, including both management and technical issues. The Reuse
Planning Group assessed that the report was of little impact and obsolete
currency. A similar document from the same institute (Wong, 1988)
received a similar negative assessment. A glossary of software reuse
terms from the National Institutes of Standards and Technology (Katz,
1994) was judged as of little use because the audience is intended to be
only the Department of Defense software reuse community.
Bell Canada has produced software process models that are relevant
to reuse. One process capability model called Trillium targets customers
who acquire software-intensive systems (Bell, 1994). Trillium is a
process maturity assessment method, comparable to the Software
Engineering Institute’s Capability Maturity Model. One of 28 road maps
focuses on software reuse. The evaluation shows the document to have
high impact, high relevance, to be far-seeing, and to be a candidate as a
base document for a reuse standard.

R ecom m endations
The Master Plan of the IEEE SESC describes an evolutionary approach
to reorganizing the collection of SESC standards. Future SESC standards
related to reuse can be positioned within this master plan. The master plan
provides a four-layer model structured as follows (see Figure 5.4
Organization of SESC):

1. Terminology
2. Master Road Map
3. Program Elements
4. Technique Standards
Standards 81

Figure 5.4-Organization of SESC: The four major com ponents are shown in
their order

The top layer, Terminology, is provided principally by IEEE Glossary

of Software Engineering Terminology. Terms specific to software reuse
will be adopted via the mechanism of including them in the glossary.
The second layer, Master Road Map, is intended to be an overview
document describing the relationships among key SESC standard as well
as with those of other organizations. In general terms, software reuse will
find a place in that description. The bottom layer, Technique Standards,
consists of standards describing techniques which are at a detailed level
or which might be applied in a number of different contexts.
The third layer, Program Elements, is the key one for positioning
reuse standards within the SESC collection. SESC has four program ele-
ments:

3.A Customer - relationships with the customer of a project.

3.B Resource - resources that can be used by a project.
3.C Process - processes that can be followed by a project.
3.D Product - products that can be produced by a project.

Each program element can be viewed as a stack of three components:

3.x. 1 Policy or Principle Standards

3.x.2 Element Standards
3.X.3 Application Guides
82 Chapter 5

The Policy Standards provide objectives for the various standards

collected within the program element. The Element Standards are high-
level standards providing normative guidance on important software
engineering activities. The Application Guides provide advice on how to
apply the Element Standards within particular situations.
Reuse standards might occupy the following position in the Master
Plan:

• 3.B.2 Resource Element Standards, e.g., reuse libraries and their

interoperation. The existing Reuse Interoperability Group stan-
dards fit here.
• 3.C.2 Process Element Standards, e.g., reuse process adoption,
reuse capability assessment, domain analysis processes and adap-
tation of software life cycle processes to reuse
• 4. Technique Standards, e.g., coding guidelines for reusable com-
ponents, documentation of reusable components

In the remainder of this section, candidate standards will be labeled

with their anticipated positioning within SESC’s Master Plan. Finally, a
few alternatives that were considered, but rejected, will be described
briefly.
Potential New Standards
There is sparse evidence regarding the effectiveness of specific reuse
techniques. The principal drivers and obstacles to successful reuse are
non-technical in nature. Even though the requirement for reuse is con-
temporary, much of the technology is still emerging. These observations
argue for a conservative approach, standardizing only what is necessary
to permit the continued evolution of the field. Those necessary items
might include a framework for the discussion of reuse processes and prac-
tices, terminology, acquirer/supplier provisions, and library interfaces.
The SESC collection should articulate principles for software reuse.
These principles should be traceable to a set of fundamental principles of
software engineering and based upon successful patterns o f usage (see
Figure 5.5 Principles and Patterns). This would ensure that the standards
are both principled and based on actual practice.
Patterns of usage are important as reflected in these four recom-
mended further types of standards for reuse:
Standards 83

• a set of reuse processes (or reuse-motivated modifications to nor-

mal life cycle processes) that are traceable to the principles.
• a set of practices that implement the processes.
• an assessment mechanism for the processes and practices.
• implemented processes, practices and assessment mechanisms
together regarded as patterns of usage.

Figure 5.5-Principles and Standards: Software principles lead to reuse princi-

ples which lead to patterns of use.

A standard for principles o f reuse would provide a vocabulary and a

framework of principles to organize and rationalize other standards relat-
ed to software reuse. It would include a glossary of terms for software
reuse and principles for software reuse
A list of candidate principles for this document follows:

• Build a software domain architecture as a framework for reuse

activities.
• Use a software development process that promotes and controls
reuse.
84 Chapter 5

• Reuse more than just code.

• Practice domain engineering.
• Integrate reuse into project management, quality management and
software engineering activity.
• Organize the enterprise to facilitate partnering to achieve reuse
across product boundaries.

Even though technology for performing domain analysis is immature,

there is great demand for it. Some successful analyses have been per-
formed and there is a body of work explaining how such analysis should
be performed. The purpose of a domain analysis standard would be to
describe the minimum required processes and products of domain analy-
sis.
Most software reuse processes are not distinct from the normal life
cycle but instead must be integrated into other life cycle processes. Some
acquirers are demanding software reuse even though the effectiveness is
not quantitatively proven. Fortunately, some successful reuse efforts have
occurred and there is a body of work describing these efforts. These con-
siderations argue for a process standard that explains how software reuse
processes may be incorporated into the life cycle. This might be a sup-
plement to ISO and US 12207 explaining how reuse processes are incor-
porated into the life cycle processes of 12207. Relevant base documents
would be:

• ISO 12207 and

• STARS CFRP

Other Normative Advice would come from:

• ANSI J-016
• CARDS Direction Level Handbook
• DoD Software Reuse Institute Reuse Business Model
• Software Productivity Consortium Reuse Adoption Guidebook

No reuse practice or assessment specifications are recommended for

standardization. None of the specific practices have proved sufficiently
repeatable to merit standardization. Those wishing to apply software
reuse techniques should select practices consistent with the principles and
processes described in higher level standards.
Standards 85

Even though technology for software reuse is immature, some acquir-

ers are demanding that it be performed and desire to understand the capa-
bility of potential suppliers for adopting reuse practices. This sort of
capability assessment should not be performed in isolation but in the con-
text of the more general capabilities of the supplier. A supplement to
SPICE is recommended that explain how reuse processes may be
assessed within the context of the life cycle processes of 12207.
Rejected Alternatives
The topic of assessing reusable components might be regarded as among
the most desirable of standards, but it cannot be pursued as a standard at
this time because of a lack of available art in this area. Groups of vendors
might be able to agree on conventions for their products that restrict them
in such a way as to permit assessment. Work by consortia in this area
might be useful. The state of the art in this area should be reevaluated
periodically.
Configuration management (CM) is a particularly interesting issue
because the CM desired for a reuse library is fundamentally different than
the CM used in a software development program. During software devel-
opment, the raison d’etre of CM is to make sure that the latest, best and
most bug-free version of a component is the one that gets integrated into
the final product. On the other hand, the reason for CM in a reuse library
is to make sure that the appropriate version of the component is made
available to a user. (For example, a user might choose to reject an
“improved” version of flight control software if the improvement was
done for purpose of prototyping and was never flight-rated.) So, CM in
software development has the goal of controlling the user’s choice of
components while CM in a reuse library has the goal of informing the
user of the detailed relationships between components that are similar but
slightly different. Frankly, this new role is poorly understood. It presents
some technological challenges to extend CM out of controlled environ-
ments while still maintaining control. For example, components must be
given names that last “forever,” that remain unchanged when the compo-
nent is moved to a new library, and that permit the users to satisfy them-
selves that the component has not been altered—even by the original
author. It is one of the items in the area of “library organization and oper-
ation” that is technological immature and lacks proven effectiveness.
The Reuse Planning Group also evaluated and rejected several other
topics as not suitable for standardization at this stage. Reuse adoption
guidance has little evidence of repeatable effectiveness and little evidence
of de facto consensus. Reuse development practices are too specific to
86 Chapter 5

particular tools and technologies and too low-level and voluminous.

Library organization and operation have no measures of effectiveness.

Conclusion
In 1992 the North Atlantic Treaty Organization (NATO) issued three doc-
uments about software reuse as standards for NATO. When one reads the
NATO documents, one appreciates that they are NATO-specific. In other
words, they are plans for how NATO itself will conduct software reuse
activities.
The observation about the NATO-specific standards is merely one
example of a more general phenomenon in reuse standardization—the
most tangible reuse standards are specific to a single organization. That’s
because successful reuse practices touch many parts of an organization’s
methods and culture for doing business.
To better appreciate the organization-specific character of the most
tangible reuse guidelines consider an example. Assume a standard says
that any reusable subroutine must be documented with its “intended func-
tion.” In an organization indoctrinated in Harlan Mills’s structured pro-
gramming techniques, this has a precise mathematical definition that is
well understood because of the corporate culture of pursuing Mills’s tech-
niques (Mills et al, 1986). If one generalizes this standard to other orga-
nizations and expects them to use the Mills’s techniques, one would be
faced with the complaint that “this organization documents its software
differently.” So in an effort to be general one would relax the standard to
a requirement that software be documented—a very non-specific require-
ment that can be satisfied in a variety of superficial ways. In broadening
the applicability of the standard, one robs the standard of its ability to dis-
criminate. This phenomenon appears over and over again in software
reuse standards.
Standards can be developed by many different kinds of organizations
(Rada and Berg, 1995). IBM and Motorola have developed corporate
standards for reuse among their employees. Government agencies have
developed standards for how government contractors must follow soft-
ware reuse processes. Relatively little has been done explicitly about soft-
ware reuse by official standards development organizations.
The major international standards organization relative to informa-
tion technology is ISO-IEC JTC1. The standards from the US Military
and NATO, are not JTC1 standards. JTC1 has one project underway that
Standards 87

is particularly germane to software reuse. This is the “Software Process

Improvement Capability dEtermination” (SPICE) project.
SPICE provides road maps for important software practices. Reuse is
one of the practices covered by SPICE. SPICE is designed to provide
software organizations with an internationally recognized mechanism to
support their continuous process improvement programs, and to help
managers ensure that the process is aligned with the business needs of the
organization. SPICE will also help purchasers determine the capability of
software suppliers and identify risks.
The IEEE SESC chartered a Reuse Planning Group to develop a plan.
That plan recommends four new efforts:

• a standard describing principles of software reuse—principles that

individual organizations could satisfy in a variety of ways;
• a standard describing the characteristics of domain analysis—
domain analysis though little understood is now frequently prac-
ticed;
• a supplement to the ISO 12207 life cycle process standard (Moore
and Rada, 1996) to describe how reuse practices relate to the
12207 processes; and
• a method for performing capability assessment for suppliers of
reusable components, probably within the context of SPICE.

The recommendations are notable also for the efforts that were con-
sidered but rejected. For example, the group rejected efforts for standards
related to “reuse development practices” because they were regarded as
being too specific to tools and technologies and being too low-level and
voluminous. Standards for library organization and operation were reject-
ed because reliable measures of effectiveness do not yet exist. Guides for
reuse adoption were rejected because there is little evidence of repeatable
effectiveness and because there is little evidence of de facto consensus.
Perhaps most notably, an effort to write a standard for the assessment of
reusable components was rejected because of the concerns regarding the
ability to “scale” reuse practices beyond the scope of a single organiza-
tion.
The US Department of Defense is already writing software develop-
ment contracts that require reuse. Yet, no internationally recognized stan-
dard for how software reuse should occur exists. Such standards are
needed.
88 Chapter 5

Two kinds o f standards are being developed. One kind is technical

and focuses on the software assets that are to be reused. Another kind is
social and guides the human side of software reuse. The artifacts are
much less complex than the people. Developing a suite of standards that
apply seamlessly to the people and their artifacts will not be easy.
Section 3
O rganize, Retrieve, and
Reorganize

In this Section three phases of reuse engineering are examined. These

phases are the initial organization of a library of reusable components or
concepts for later reuse, the retrieval of relevant components from the
library, and the reorganizing of these components to form a useful system.
In other words, this life cycle includes:

1. Representation of software items that can be reused, i.e., semantic

and syntactic means or conventions for describing them -
Organization,
2. Later retrieval of these items by another developer - Retrieval, and
3. Development of software using reusable components -
Reorganization.

Document and object oriented approaches to all three phases are dis-
cussed and compared, as are applications of both techniques to program
code, and higher levels of abstraction such as software requirements. The
discussion of program document retrieval is augmented by practical
examples.
A major problem to be overcome in the deployment of software reuse
techniques is to identify appropriate methods for the classification and
retrieval of software items. If retrieval is not made easy for developers,
they will prefer to re-write the component from scratch. At the same time
classification must be simple and cost effective to justify the cost of set-
ting up and maintaining the library of items against the cost of develop-
ing the items each time from scratch. These twin aims of simple classifi-
cation and powerful retrieval are contradictory in themselves, as will be
explained.
Chapter 6
O r g a n izi n g

In constructing, or maintaining a reuse system, an early step is to build a

repository of reusable concepts and components for developers to use as
a resource. These components can come from many sources (see Figure
6.1 Component Sources). These components need to be processed to
ensure that consistency and quality are maintained throughout the library.
Organizing refers to collecting, analyzing, indexing and storing infor-
mation so that it can be easily accessed later. Before software documents
(here documents being any information produced during the software
life-cycle, such as a piece of code or a requirements document) can be
successfully reused, they must be somehow organized (Rada, 1991).
Documents that are to be reused should be organized into a carefully
designed system that reflects their topic. There are several methods for
organizing items. At one extreme each document is stored in a file and an
index associates strings with the files that contain them, while at the other
extreme a knowledge base replaces the documents entirely, representing
them in its structure.

Indexing
After material has been collected and analyzed (as described earlier), it
should be indexed. The two most important basic approaches to docu-
ment indexing are the interpretive and structural approaches. With inter-
pretive indexing the document is read and understood before index terms
are assigned (Kaplan and Maarek, 1990). In contrast, the structural
approach uses the frequency of word usage in natural text as an indicator
of relevance of the contents to a topic without semantic interpretation
91
92 Chapter 6

being assigned to any word. In the interpretive approach ‘indexing con-

cepts’ are chosen to represent a document expressed in a natural language
such as English (see Figure 6.2 Keyword Approach). The indexers may
have complete freedom of choice over what they can use as an indexing
term to represent a concept, or they may have guidelines to follow over
how certain concepts should be represented. This approach without
guidelines is quick to implement, but can lead to inconsistent indexing
terms for documents in the library, especially if the library is large, and
has many people indexing components for it.

Figure 6.1-Component Sources: Com ponents may arrive for the library from a
software house, or from public domain sources, or from projects on-going which
have developed new com ponents suitable for reuse.

L ib r a r ia n
Organizing 93

Structural indexing is based on the observation that writers usually

repeat certain words as they advance or vary their arguments, or elaborate
on an aspect of a subject. This approach has motivated a number of auto-
matic indexing algorithms for information retrieval systems (Yu and
Salton, 1997) An important automatic indexing approach is frequency
based. A typical word frequency indexing algorithm is to:

1. Identify all the unique words in the document set.

2. Remove all common function words included in a stop list (such as
‘a,’ The,’ ‘or,’ ‘and,’ ‘is,’ ..., etc.)
3. Remove some suffixes and combine identical forms of the same
word (stems). This reduces a variety of different forms such as
‘constructs,’ ‘constructing,’ ‘constructor,’ and ‘constructed,’ to a
common word stem ‘construct.’
4. Calculate the frequency of occurrence of the resulting word stems.
5. Assign a mid-range of frequencies for terms to be considered for
indexing.
6. All terms that are within the mid-range are then selected as index-
ing terms.

Frequency-based indexing generates a flat description, i.e., a fre-

quency ordered set of unrelated index terms for each document. A more
sophisticated indexing mechanism can identify the relationships between
the co-occurring index terms.

Figure 6.2-Keyword Approach: A list of concepts to index this paragraph.

“Computer Aided Instmction (CAI) systems have improved greatly over the
years. Their knowledge content is still however low, and the system decisions,
though usually correct cannot be analyzed for the reasoning behind them.
Knowledge can be stored in the domain of a learner model in a variety of ways,
and thus a student may have to acquire knowledge using several different
methods.”

Possible indexing concepts:

Computer Aided Instruction,
knowledge content,
learner model.
94 Chapter 6

D o c u m e n t O utlin es
Successful interpretive indexing requires understanding a document’s
content. A document’s outline may provide a valuable guide to this
understanding. Most well prepared documents have an outline. The out-
line manifests itself in the layout of the document as highlighted and
numbered headings in the document body, as well as in a separate listing
at the beginning of the document in the ‘table of contents.’ This physical
layout helps people understand the logical structures of the document and
find thematically-organized sections in the document. This means that
there is an existing organization of themes (or sort of domain model) in
the document that can be easily observed and perhaps utilized in orga-
nizing the document for reuse systems. Analysis of the outline provides a
quick and simple insight into the content of the document. Tools can auto-
matically extract an outline from a document and thus split documents
into themed sections, showing the relations between these sections (see
Figure 6.3 Outline Analysis).
Obviously the size, balance and depth of this structure varies from
document to document. There are no strict rules for the construction of
headings or outlines, though some patterns in headings do exist. In many
cases, headings are noun phrases, such as ‘Introduction to Database
System Concepts,’ ‘Physical Data Organization’ and ‘Protecting the
Database Against Misuse.’ But headings may even be complete sen-
tences, such as ‘What Makes Interlisp Unique?.’ The heading of a section
should briefly describe the contents of that section, and headings can be
seen as ‘content index’ terms for a document. It follows therefore that one
may extract index terms from the headings to represent more generically
the sections under those headings. For example, both ‘The Network
Model’ and ‘The Relational Model’ may be indexed by the key word
‘Model.’
In many documents, some subheadings inherit attributes from their
parent heading. For example, the heading ‘Hardware’ under ‘Site
Requirement’ means ‘the site requirement on hardware.’ This depen-
dence may continue on several levels. In some scientific documents,
headings repeat. Documents of a given type, such as requirements docu-
ments, may all have the same outline. Some company policies require
such conformity of outlines. Furthermore, the documents of a given soft-
ware life-cycle fall themselves within a kind of high-level outline whose
headings may show some relationship across documents (see Figure 6.4
Relations among Outlines). When one studies the nature of the relation-
ship between headings in an outline one observes three kinds of relations,
structural, hierarchical and attributive (Mili et al, 1996).
Organizing 95

• The structure relation refers to parts of a document outline which

are not fundamental to the major topic of the document but serve
rhetorical or record-keeping functions. For example the title of the
document connects to the ‘Introduction’ heading via a structure
relation, and the ‘Date o f Creation’ heading has the same link from
the title.
• The hierarchical relation includes the traditional partitive (a part
of) and inheritance (kind of) relations. For instance, the link from
‘Function’ to ‘Subfunctionl’ would be of the hierarchical type.
• The attributive relation is a non-hierarchical relation. For instance,
if the section headed ‘Function’ includes subheadings ‘Inputs’ and
‘Outputs,’ then the relation from ‘Function’ to these subheadings
would be attributive.

Figure 6.3-O utline A nalysis: By analyzing the hierarchy of the outline of a book
it may be possible to automatically break the book into domains.

S o f tw a re E n g in e e r m g
B ook e tc ,

C h 1 : E. a s ic C o n c e p ts
W h a t is so f tw are ?
W h a t is s o f t w a r e E n g i n e e ri n g

C h 2 : S o f t w a r e S p e c i f ic a t io n
R e q u i re rn e n ts D o c u m e n ts
M o d e l l i n g R e q u i r e rn e n t s

C h 3 : 3 o f t w a re D e s i g n
T o p D o w n D e sig n
B o t to rn TJ p D e s l g n

C h 4 : 3 o ftw are i r n p i e rn e n t a t i o n
D esig n
T e s t in g

C h 5 : M e t h o d o 1o g y

e tc .
96 Chapter 6

Such a characterization of outline relations can greatly facilitate the

manipulation of outlines. These outlines are not, however, as frequently
used in supporting reuse as they might. Some outlines are not sufficient-
ly well organized or descriptive to guide reuse, so additional effort is
needed to abstract the contents of these documents and to represent that
information in easily maniputable ways.

Figure 6.4-Relations among Outlines: Each box represents a docum ent of the
software life-cycle w hose title is indicated in its upper left corner. The arrows show
how a heading of a docum ent in one phase of the software life-cycle can be relat-
ed to a heading in another docum ent of the sam e software life-cycle.

Hardware
Organizing 97

Domain Models
A high-level organization of an information space may be reflected in a
model of that space. Given that the information space addresses a partic-
ular topic or domain, the model could be called a topic model or a domain
model. A domain model should identify the objects and operations on
those objects that are common to an application domain. Also important
are relationships and constraints between the objects and their corre-
sponding properties or attributes, that are likely to be used by developers
in the process of searching for reusable components - these must be made
explicit. One part of a domain model may be a classification. A classifi-
cation groups together like things. An enumerated classification scheme
(Ranganathan, 1937) assumes a universe of knowledge divided into suc-
cessively narrower classes that include all possible classes (see Figure 6.5
Enumerated Example). These are then arranged to display their hierar-
chical relationships. An example of this scheme is the Dewey Decimal
system.
Thesauri
The enumerated classification has little flexibility, as it is usually repre-
sented as simply a strict hierarchy of terms with no further attributes and
no term occurs in more than one place in the hierarchy. A thesaurus
extends the enumerated classification by allowing a few other attributes
for each terms, in addition to the attribute of hierarchical location. A the-
saurus may be presented in a hierarchical, ‘Table of Contents’ form or as
an alphabetical sorting. It includes preferred terms (descriptors) for
indexing, and non-preferred terms as lead-in terms (or synonyms) to cor-
responding preferred terms. The preferred term essentially labels a con-
cept. Two basic relationships between concepts are hierarchical (broader
than, narrower than) and associative relations. Several other attributes for
a thesaurus term can be defined, including dates of entry (see Figure 6.6
Thesaurus Terms Table).
A thesaurus supports organizing and finding documents in both
object- and document-oriented systems (though in itself it is object-ori-
ented). With a thesaurus one document can be indexed under several
terms. A user can broaden or restrict the results of his or her search by
asking the system to refer to the thesaurus. Thus the thesaurus provides
the retrieval system with some natural language ‘ability.’
98 Chapter 6

Figure 6.5-Enumerated Example: In this greatly simplified classification

schem e of the sciences, an enum erated classification schem e has been
imposed. For many cases this is perfectly adequate. However, if the topic
‘Biological Paradigm s for Computer Vision’ had to be classified the system fails,
since this topic is equally relevant at A and B in the above classification.

Science

Thesauri are normally part of a larger system and are best built with
regard to their function in that system. It is possible to build a thesaurus
first and then use it to index the documents to be added to the library. This
is described as a top-down approach. To do this requires an amount of
prior knowledge of what the library is likely to contain. Alternatively, in
the bottom-up approach the documents may be indexed using free terms
and then the thesaurus is constructed after accumulating a number of
these free terms. Consistency must be maintained in the terms used and
their structure as preferred and non-preferred terms. When the function
required of the thesaurus is retrieval, as it largely is in the software reuse
Organizing 99

world, the best method for building the thesaurus is a mixture of these.
The drawback of using thesauri is the effort needed to build and maintain
them.

Figure 6.6-Thesaurus Terms Table: This show s the term s associated with the
preferred term ‘Snakes.’ Top term s represent main classes in a classification sys-
tem, in this case the main class being ‘Animals.’ It is also possible to define a rela-
tionship between prior designations for a concept and its current naming, in this
case ‘Serpents’ a s an older naming for the concept of ‘S nakes.’ In software doc-
um ents this is useful for version following.

A ttr ib u te V a lu e

P re fe rre d T erm S n a k es
D efin itio n
D a te o f E ntry June 3 1992
T o p T erm A n im als
B road er T erm R ep tiles
N arrow er T erm R a ttle sn a k e s
A ssociated Terms W orm s
Synonym V ip ers
Pr ior T erm S er p e n ts

Faceted Classification
A thesaurus basically provides a hierarchy of concepts with little other
information about each concept than its hierarchical position. To extend
the thesaurus, one may expand the representation of each concept in it. A
faceted classification is a kind of extended thesaurus. Faceted schemes
are easier to expand than enumerative schemes. They are more flexible,
more precise, and better suited for large, continuously expanding collec-
tions. A software component may be described by a set of {facet, facet
term} pairs:
100 Chapter 6

• A facet is a fixed set of concepts from which to view components.

• A facet term comes from the library’s list of representative terms
for the particular facet.
• Any number of pairs may be applied to a given software
component.

Typically a domain will have about ten facets.

A typical set of software facets might include:

• object: a software engineering abstraction operated upon by the

software component,
• function: an action performed by the component, such as sort or
delete,
• algorithm: any special method associated with a function or
method, such as “algorithm, bubble” associated with “function,
sort” ,
• component type: the particular kind of software life-cycle product,
such as code or design,
• language: the language used to construct the component, such as
Ada, C, or English, and
• environment: any hardware or software for which the component
is specialized, such as Unix.

A component is described by assigning appropriate facet terms for all

applicable facets.
A description for a sort routine might use the facet ‘object’ twice but
the facet ‘environment’ not at all (see Figure 6.7 Descriptions of Sort
Routines). In a more flexible sort routine, the facet ‘object’ has disap-
peared, since the object to be sorted is a generic parameter of any type.
This example also illustrates that more than one facet term may be given
for a single facet. Thus the user who has an application-oriented view
might be served equally well as the user who has a software-oriented
view, if the librarian has put both an application-oriented facet term into
the facet and a software-oriented facet term into the same facet.
Organizing 101

Figure 6.7-Descriptions of Sort Routines: The facets for two different software
com ponents, called Rigid Component and Flexible Component, are given. Note
that the ‘Flexible Com ponent’ does not use the facet ‘object.’

Facet Facet Term

N am e Rigid Component Flexible Component

object address
object mail code
function sort sort
algorithm binary sort binary sort
com ponent type code code
language Ada Ada

C o d e Organization
Reuse of code, usually in very informal ways, is almost as old as pro-
gramming itself. All high-level programming languages are in them-
selves a kind of code reuse system. They provide a method of manipulat-
ing the hardware at quite a high-level which reuses large amounts of very
low-level code in each instruction. Some aspects of operating systems
offer a similar function. Libraries of functions in high-level languages
continue this abstraction a level higher. Systems like the UNIX pipe func-
tion (which is described later in this book) extend this abstraction to
include reuse of whole programs typically themselves written in a high-
level language using sub-routines. Newer languages, such as object-ori-
ented languages like C++, and generic functions and packages in ADA,
provide powerful facilities for the programmer to make abstractions.
102 Chapter 6

Figure 6.8-Component Code: A sam ple piece of code to show how keywords
can be considered to exist in ordinary code.

PACKAGE i n t _qu eu e ( p a r a m e te r s . . . )

---- D e s c r i p t i o n -----
AUTHOR: D. C h a p lin
DATE: 2 8 th May 1 9 9 2
NAME: i n t _ q u e u e
COMPANY: N O J o f t w a r e
VERSION: 4 .2
FUNCTION: A v a r i a b l e s i z e queue for
i n t e g e r s . queue is a f i r s t —i n -
f i r s t —o u t (or FIFO)
d a ta s t r u c t u r e .

---- C l a s s i f i c a t i o n - —
CA T E G O R I E S : D ata S t o r a g e ,
Ab s t r a c t Da t a Ty pe .

KE Y ¥ O R D S : que u e ,
f i r s t —i n —f i r s t —o u t ,
d a ta s t o r a g e .

——S t o r a g e R e q u i r e m e n t s ——
M E MO R Y A L L O C A T I O N : as n e e d e d .

— -D e p e n d e n c i e s ----
LIB RARIES : n e e d s m ath, l i b .

----- tt * D e f i n i t i o n s * ■* ■*

end i n t q u e u e ;

Code that is to be reused can vary in size from a small block of code,
of say a dozen lines, that performs some minor function, to a procedure
of thousands of lines that performs a complex operation. There are prob-
lems and advantages to reusing both sizes of object. Smaller components
are less productive since their functionality is not as great due to their
size, but are easier to combine and modify to achieve a different goal
from that originally intended, since they encapsulate a single function.
Organizing 103

Functions can, however, be expected to receive and return their parame-

ters differently, both in number, format and type. Using small functions
means that these ‘structure clashes’ will occur more frequently, since
there will be a greater number of individual routines.
Keyword-based approaches to indexing programs are similar to those
used for documents, namely that an indexer uses a natural language, such
as English to describe the content of a component. Indexing terms could
be added to the start of an actual program code component (see Figure 6.8
Component Code).
A form of outline-extraction may be possible for a well-commented
program. The comments might include headings in a way analogous to
the headings in a conventional document. However for many programs,
their existing comments are not written to this standard. It should be pos-
sible to add comments to the code to achieve this, although this would be
time consuming and therefore remove many of the advantages of using
this method.
Object-oriented software is widely seen as a possible major con-
tributing factor in the wider acceptance of software for reuse (and was
briefly discussed in the chapter on the software life cycle). This is due to
features of object-oriented languages such as data encapsulation and
information hiding, which reduce or eliminate much of the effort
involved in making components suitable for reuse. In recent years sever-
al object-oriented languages have appeared, for example Smalltalk 80,
together with object-oriented extensions to some existing functional lan-
guages, such as Object Pascal, Objective C and C++.
Object-oriented programs are made up of interacting components
called objects. These objects may correspond to real world entities i.e.,
bank accounts, or to computer hardware and software components.
Others may correspond to data structures such as lists, stacks, and queues.
Software construction using object oriented languages is the assembly of
objects to form a system. Each object is by its nature well defined since
it implements a real world ‘object’ and its scope is fixed and defined by
a real world entity. Object-oriented programming encourages program-
mers to assemble complex programs from simpler components.
With object-oriented document classification schemes, domain mod-
eling is important, this is also true in object-oriented program component
schemes. Program components are described in a subject-oriented hierar-
chy depending on the functions offered in the program component. The
domain model can be refined to several levels of granularity, at the finest
104 Chapter 6

level this should lead to subclasses that contain program segments which
are different versions of the same program segment or functionally equiv-
alent program segments.

Framework s
One extension to the object-oriented methodology is sometimes
described as frames or frameworks. Of course, the term framework has
many meanings in the world at large and may be used in generic ways in
software engineering also. However, for the purposes of software reuse,
a framework is defined as a reusable, semi-complete application that can
be specialized to produce custom applications (Fayad and Schmidt,
1997). In contrast to earlier object-oriented reuse techniques based on
class libraries, frameworks are targeted for particular business units or
application domains.
A framework enhances extensibility by providing explicit hood
methods that allow applications to extend its stable interfaces. Hook
methods systematically decouple the stable interfaces and behaviors of an
application domain from the variations required by instantiation of an
application in a particular context. The run-time architecture of a frame-
work is characterized by an inversion of control. This architecture enables
canonical application processing steps to be customized by event handler
objects that are invoked via the framework’s reactive dispatching mecha-
nism. The framework’s dispatcher reacts by invoking hook methods on
pre-registered handler objects, which perform application-specific pro-
cessing on the events. The framework determines which set of applica-
tion-specific methods to invoke—this is the inversion of control.
Developers in certain domains have been using frameworks for many
years. The Microsoft Foundation Classes is a contemporary graphical-
user interface framework that has become the de facto industry standard
for creating graphical applications on personal computer platforms. For
numerous complex domains, off-the-shelf frameworks do not exist, but
the developers in those domains have each developed their own frame-
works. Java is spreading new frameworks like AWT and Beans.
Frameworks are a component in the sense that vendors sell them as
products. But frameworks are more customizable than most components,
and have more complex interfaces. Classes in the object-oriented sense
have not realized much success in general as reuse devices. Frameworks
are harder to learn than individual components or classes. However, a
good framework lends itself more to reuse.
Organizing 105

Frameworks provide a reusable context for components. A frame-

work provides a standard way for components to handle errors, to
exchange data, and to invoke operations on each other. The so called com-
ponent systems such as OLE, OpenDoc, and Java Beans, are really frame-
works that solve standard problems that arise in building compound doc-
uments and other composite objects. Frameworks provide the standard
interfaces that enable existing components to be reused (Johnson, 1997).
Frequently, the two views of framework reuse, referred to as white-
box and black-box approaches to reuse, are simultaneously present in one
framework. Features likely to be common to most applications can be
offered and therefore reused as black boxes with minor changes. On the
other hand, the class library accompanying the framework usually pro-
vides base classes or white boxes that can be specialized by adding sub-
classes as needed and that are easily integrated with the rest of the frame-
work (Brugali et al, 1997).
Patterns and frameworks are similar. Both are efforts to extend the
object-oriented approach so that it incorporates domain analysis and
addresses particular problem areas with partial solutions of a larger gran-
ularity than would be otherwise addressed by traditional objects or class-
es. While each pattern describes a decision point in the development of
an application, groups of related patterns can be organized as a tree or
graph in which each pattern leads to a series of other patterns. Such a
structure is called a pattern language and represents the sequence of deci-
sions leading to a complete design, so a pattern language becomes a
method that guides the development process. This complements general
development methods by adding domain-specific, concrete advice to
their general guidelines. A pattern language supports the development of
the framework that in turn supports the use of the patterns.
Books are now available that present patters or frameworks for par-
ticular domains. For instance one book focuses on business patterns
(Fowler, 1997). Two broad types of patterns are described within the
book: analysis and support patterns. The analysis patterns are groups of
concepts that represent a common construction in business modeling.
They may be relevant to one or more domains. Support patterns are pat-
terns in themselves. Their role within this book is to show how the analy-
sis patterns may be applied. The patterns within this book include
accountability, observations and measurement, referring to objects,
inventory and accounting, and planning and trading. The support patterns
include layer architecture for information systems.
106 Chapter 6

Epilogue
The way in which software information is organized in a library is cru-
cial. It constrains how the developer may use the library. Techniques for
the organization of components may be document-oriented or object-
oriented.
The document-oriented approach relies on the extant structure of doc-
uments and on free-word indexing. A document-oriented system is easy
to set up and offers many methods for organizing documents fully or, at
least partially, automatically. But document-oriented methods are weak in
many retrieval situations, since the information they provide about the
structure of documents and the structure into which documents are orga-
nized is quite simple. Only basic retrieval methods, such as searching for
topics explicitly mentioned in a document, is possible. Automatically
extracted information is usually a subset of the information stored in the
document, and thus offers less information about the documents than the
documents themselves and only weak associations between them. This
can be improved by human indexers reading the documents and assign-
ing keywords to describe the contents of the document, but it is hard for
this indexing to be kept consistent over large databases of thousands of
documents, or with several indexers working simultaneously. This caus-
es many problems at the retrieval stage, which are described in the fol-
lowing chapter.
Object-oriented systems basically depend on some form of high-level
abstraction or model, commonly called a domain model. Object-oriented
techniques are labor-intensive for the set-up stage. However a rich struc-
ture is produced that can be interrogated in many ways and provides
many advantages to a searcher. A thesaurus provides a system with some
basic knowledge of a domain, thus allowing ‘intelligent’ searches which
find documents using terms related to desired terms rather than simply
failing. The emphasis can be on making retrieval easier, at a cost of mak-
ing organization more complex, time-consuming and expensive. Or the
opposite, where it is retrieval that requires expertise and may prove
unproductive, but organization is simple.
Chapter 7
R etrievi ng

Before a developer can write a program using reusable components, the

components to be reused must be obtained. A reuse library will not be
used effectively, if it is not relatively easy for its users to retrieve the
desired information from it. Users must be allowed to be flexible in how
they search for information. If the library is searched with a specification
or partial specification of the required component, then the system should
be able to determine how much of that specification can be met by copy-
ing and combining existing items from the library, in an ideal case at
least. In a situation where the library does not contain the desired infor-
mation on a particular topic, the user should be able to browse for and
examine any possibly related components in the library (see Figure 7.1
Flexible Searching).

Retrieval S p e c i f ic a t io n
As described earlier, the software life-cycle can be viewed as a refine-
ment process, which starts with the developer having only very informal
and abstract specifications of what the final product should look like.
Unfortunately it may be important to know in the early stages of this
process which reusable components are applicable, since existing
reusable items can only be integrated, if the system is designed to accom-
modate the reusable items. However, at these early stages, the user of the
library might have difficulty expressing what precisely is required.
Despite the vagueness of the retrieval specification, the resulting search
of the library should lead to helpful information. The developer should be

107
108 Chapter 7

able to progressively modify the query as retrieved items add to their

mental model of the library contents. This can be called iterative search-
ing or browsing (see Figure 7.2 Iterative Searching).

Figure 7.1— Flexible Searching: In this system 3 avenues of exploration are

available to the developer, he or she can pose a query a s a ‘Full Specification’ of
the component, part of that specification a ‘Partial Specification,’ or by ‘Browsing’
through the com ponents that exist in the library.
Retrieving 109

Figure 7.2—Iterative Searching: This is a description of a technique in which the

user poses an initial query to the library retrieval system and uses the results
returned by this query to formulate a new and more detailed query. This is then
used to query the system , and this process can then be repeated.

With a thesaurus-indexed collection, if the user asks for document

components about for example ‘depth-first traversal,’ and if the system
has no document components indexed with that term, then the system
might find the term closest to ‘depth-first traversal’ in the thesaurus and
perform retrieval on that term. For instance, if in the thesaurus ‘graph
algorithms’ is a broader concept than ‘depth-first traversal,’ and if the
retrieval system has document components indexed under ‘graph algo-
rithm s,’ then the system should return those document components to the
user (see Figure 7.3 Guaranteed Return). Thesaurus-aided searching may
110 Chapter 7

need to be complex (Mili, 1991). A developer may need, for example, a

multiplication routine. Multiplication can be performed (as it often is in
very low level languages) as a series of shifts and additions. Normally
shifting and multiplication would not be synonymous, and thus a compo-
nent on shifting would not usually be offered to someone who searched
for multiplication. This is a simple example and in this case many devel-
opers could make the link themselves and submit searches for shifting
and addition components themselves. However in the general case it
would be hoped that retrieval systems would be able to decompose a
search in that way. From even these simple examples it can be seen that
the demands upon the retrieval mechanism to be used for software reuse
are many and varied.

Figure 7 .3 -G u aran teed R eturn: The user has requested text on ‘depth-first,’
and the thesaurus has been followed to find related text.

Request No
Depth First Depth First Match
Traversal Traversal
>
Thesaurus
e turned
II "E'epth First Traversal"
item

Broader G raph
Term Algorithms

Graph
Algorithms

IR System
Retrieving 111

D o c u m e n t Retrieval
Document-oriented retrieval approaches include searching for key terms
expressed in a natural language, such as English. When a large library
containing many thousands of items is indexed by more than one person
the terms adopted can become inconsistent. This inconsistency o f terms
chosen to represent components can lead to different keywords being
used to represent the same concept in two components. Problems may
also exist in searching the library for very common phrases like ‘system’
that may have been used as an indexing term for very many unrelated
items. Efforts can be made to help this situation if careful controls over
the indexing terms are exercised.
The keyword form of Information Retrieval is widely used in
Japanese software houses, where reuse of software components is an inte-
grated activity in software development. The stored components are
indexed manually using keywords covering the technical or application-
oriented aspects of the component. The tools applied for retrieval are very
simple (Matsumoto, 1987). Much of the success enjoyed using this infor-
mal method is due in part to many specific Japanese social and working
conditions, rather than their implementation of this method. The
Japanese use training procedures encouraging software reuse and stan-
dardized methods for software description and development, in addition
most Japanese software houses enjoy only very small staff turnover with
the result that informal contacts with fellow employees allows useful
components to be found without relying solely on the retrieval system.
Free-text retrieval requires that the user knows, or is able to deter-
mine what free-text term would represent the document for which he or
she looking. This approach will fail to find documents which are relevant
but use a different term, such as ‘sorting’ and ‘ranking’ (unless good the-
saurus support is given, which due to the effort required to maintain the-
sauri, in some ways defeats the advantages given by using this method).
If the system is using the concept model described in the previous
Chapter, then techniques for finding documents can use the attribute val-
ues stored for each of the components. These attributes and their values
carry more information about a document than a simple list of keywords.
They give not only an indication of what subjects a document is dis-
cussing, but how those subjects are relevant to a topic (see Figure 7.4
Concept Model Links). This kind of linking among concept models is
especially important in situations where hundreds of documents are avail-
able and many thousands of links are possible.
112 Chapter 7

A retrieval system should not produce a bewildering selection of top-

ics from which to choose at any point in the process of traversing a the-
saurus or hierarchy of classes. The number of sub-classes from which the
user is to choose at any point should be limited to an acceptably small
number, ideally about twelve. The thesaurus can be further exploited to
aid the user in searching. Starting at the root node of the thesaurus, the
library system may ask the user a question, defined by the indexer, about
their desired document. From this the system can determine which branch
to follow from that node. By repeating this process the system can tra-
verse the thesaurus and find the desired concept under user guidance
(Saurel, 1985). To apply this method requires a well structured and under-
stood domain, like mathematical applications, for which a comprehensive
set of questions can be defined to guide the system, and for a human
indexer to take the time to create all the questions, and to ensure that if
the addition of new concepts requires a restructuring of the thesaurus that
the questions are still valid in relation to the new structure.

Program Retrieval
Several methods for the retrieval of software documents have been dis-
cussed above. Next methods that can be used to retrieve existing code are
outlined. Some of these approaches are similar to those for retrieving
ordinary documents, but there are specific constraints to take into account
when retrieving program code.
The simplest technique for specifying a search is by using a small
piece of code that the developer would expect to find in the target routine,
such as an Ada statement or a list of commands that are expected to be in
the program. This is in many ways analogous to full-text searching for
code. The string may need to be exactly specified or in a more sophisti-
cated system wildcards may be allowed, for example printf(*%f!) may
find all programs that contain the command printf with a floating point
number regardless of the other parameters used in each case. This search-
ing method makes it difficult for the library to find related components
without some automatic way of generalizing from such a precise defini-
tion. It is more useful, particularly in the early stages of the software
development life-cycle, to use a less specific representation, one which
can describe a component in terms of what it needs to be able to do rather
than how it could be able to do it.
Retrieving 113

Figure 7.4-Concept Model Links: This diagram show s three concept models. A
plain text system would link all three with equal weighting. The links can be seen
to be accurate as there is a logical ‘chain’ of topics from ‘Archivers’ to ‘Dynamic
Interfaces.’Although com pression is significant to the ‘MPEG II’ Model, it is a sub-
issue of dealing with motion video. In the ‘Archivers’ Model it is central. Similarly
the ‘MPEG II’ docum ent though relevant, is not as relevant to ‘Dynamic
Interfaces’ a s a docum ent about 'Novel Interaction’ would be. This difference in
em phasis is important.
114 Chapter 7

Formal methods for specifying the semantics of a software item

include the Z-Schema or the Vienna Development Method. Unfortunately
there are many varying methods, none of which is especially prevalent or
standardized, therefore a library could not be designed to support all of
them, or any particular one without restricting developers. Also specify-
ing a component in terms of its semantics can be a time consuming and
tedious task, and still requires a very good idea of the function of the com-
ponent. But, a specification of this form is in a language independent
form, and thus can be used to search a library which contains components
in more than one programming language using a single retrieval system,
even though of course a user of the library will only very rarely be in a
position to be able to use a component regardless of its language.
With programs, domain analysis should ultimately lead to sub-class-
es that contain programs which are different versions of functionally
equivalent programs. Even with well defined sub-classes which would
often be hard to achieve in practice there can be problems comparing the
programs in a sub-class. Two dummy package headers for an abstract
data type will be used for an example (see Figure 7.5 Package Headers).
These two packages in an Ada-type pseudo language define some
abstract storage mechanism called a ‘box’ and allow some operations to
be performed on that ‘box’ to move ‘item’s from box to box. The two
packages are similar but not the same. One package does not offer a
‘MOVE’ command, to move an ‘item’ from one ‘box’ to another.
However the two packages are functionally equivalent since the user may
simulate a ‘MOVE’ by performing a ‘COPY’ on the ‘item’ to be moved
and then ‘DELETE’ on the original ‘item.’ A search by a library user for
an abstract data type of this kind should retrieve both of these items. In
larger and more complex programs the commonality between two rou-
tines or packages may be considerably more subtle.
There is a minimal model of the data types that can be defined for
both routines (see Figure 7.6 Second ADT). This model outlines a speci-
fication for all items in this sub-class of components. The user of the
library then searches with a minimal model specification and the library
retrieval system matches it with the stored model for that sub-class. This
is sometimes called the ‘Family Interface’ method (Pamas, 1979) since
the minimal model provides a common interface to all the programs in a
component subclass or ‘family.’ However the user of the library has to be
able to define a minimum model of the desired component.
Retrieving 115

Figure 7.5-Package Headers: Two basically functionally equivalent, but differ-

ently specified com ponents.
p a. c k a g e an AD T i 3
-

------A Va i 1 a b 1 e t yp e S a e e
ty Pe b o X Xs p e i v a t e
hyp e i t em is p r xv a t e ;

-----A v a ± 1 a b 1 e £ u n c t Xo n s a r e .
p e o c e d 'Ll e e ITOVE ( x t e ill b ox, box ) ;
------M o v e a n ite m f Eo m o n e b oX t o a n ot b e r
p r o c e dn r e COPY ( x t e ill , b ox, box ) ;
-----C opy a n ite m £ e om on e b oX t o a n ot b e e
p e a c e d i.i e e DE L E TE ( x t e ill , b oX ) ;
------D e 1 e t e an x t e ILL £ e om a b OX .
p e o c e din e e C L E A R ( Xt e m , box
-----C 1 e a r an item xn a box .
end an_ADT;

(2)
p a c k a g e an o t b e e AD T is
-

------A v a x 1 a b 1 e t yp e s a e e .
ty p e b o X Xs p Ei Va t e
ty p e x t e ill is p e i V a t e ;

-----A Va x 1 a b 1 e f mn c t i o n s a e e .
p r oc e dm e e COPY <i t e m , b ox, b o x ) ;
-----C o py a n ite m £ Eo m o n e b ox to an ot h e e .
P E OC e dm e e DELE TE ( i t e m , b oX ) ;
-----D e 1 e t e an i t e m £ Eo m a b OX .
p E OC e dm e e CLEAR( i t e m, box )
------c 1 e a E an item i n a box ■

end. a n o t b e E _A DT

Figure 7.6-Second ADT: This specifies the minimum or family interface for the
two com ponents.

P ac k ag e ge EL e e i c t y p e AD T i s
t YP e b ox i s P e i V a t e r
t YP e i t e III i s P E i v a t e
P E 0 c e d U E e COP Y ( i t e ILL , b ox , b
P E 0 c e d U E e DEL ETE ( i t em , b ox )
P E 0 c e d U E e CLE AR ( i t e m, b o X) ;
e nd aEL 0 t he E ADT
116 Chapter 7

Retrieval systems may utilize ‘grammatical’ slots for software (Oh et

al, 1994). One example of these ‘grammatical’ slots for software includes
(Batory et al, 1993):

• Actions (what the component does) for example Sorting;

• Nominals (what the component does it to) for example Linked
Lists;
• Modifier (any particular way in which it does what it does) for
example Bubble or Exchange (sorting).

An indexed software component is found by describing its character-

istics according to these slots. For example a string searching routine
might be found by the user entering the modifier term ‘find,’ the nominal
‘string’ and action ‘search.’ A database of this kind can be supported by
a thesaurus of all the possible terms that can be used in a slot. A grammar
specifies how the terms may be used in combination, to avoid nonsensi-
cal searches. These systems are useful in that they are structured but do
not require that the user specify queries in a complex formal language.

Retrieval S y s t e m s
Many software document retrieval systems exist in the form of on-line
help systems. These systems typically lack a faceted classification or
domain model but do illustrate powerful features of document-oriented
systems. The UNIX and Andrew help systems are next described in terms
of their retrieval support.
UNIX man Command
Every major command on a UNIX system has an associated man page
which describes its function (Kemighan and Pike, 1984). These entries
vary in size between one and several pages and are all stored in a stan-
dard format to make retrieval of specific information from a document
easy (see Figure 7.7 Sample Man Page). Users may retrieve these ‘man’
pages in many ways depending on how man is invoked at the command
line:

• Print or display the one-line description accompanying a set of

manual entries specified by a keyword. For example, man -k
Retrieving 117

initialization lists all one-line manual entries relevant to ‘initial-

ization.’
• Print or display the one-line description accompanying a specific
command specified by name. For example, man -f lp gives all the
one-line manual entries relevant to the ‘lp’ command.
• Print or display the whole manual page specified by name. For
example, man cat gives the manual page or pages for ‘cat.’

Figure 7.7-Sample Man Page: This shows a generic description of a typical

UNIX man page.

name_of_prog(l) name_of_prog(l) NAME

nam eofjprog - one line description of how the program works.
SYNOPSIS name of prog [ option 1 -option2] DESCRIPTION
More detailed textual description of the program and its options and how
these options affect the use of the program.
OPTIONS
-option 1 describes the effect of this option -option2 describes the effect of
this option etc.
EXTERNAL INFLUENCES
How other programs, and global environment variables affect the operation
of this program.
EXAMPLES
(of use of the program) To do such a thing use :
name_of_prog -option2
WARNINGS
List of known problems or bugs with the software.
FILES
What ancillary files are needed to mn the software, or are used or expected
by the software.
SEE ALSO
Related programs which also have man pages, these are typically the pro-
grams which affect the ‘External Influences’
118 Chapter 7

Any term mentioned in the main title of a help file of a utility can be
used as a search term. There is also an option to search for a keyword in
a specific section of the man page, for example to search for printer set-
tings in the ‘External Influences’ section.
This is a very useful system for experienced users, but not for begin-
ners or people who are looking for a new command, since it demands that
the user knows quite specifically what they are looking for before they
can find it. If the on-line help does not contain an entry on a particular
topic, then the user is simply informed there is no manual entry corre-
sponding to that topic, and no help is given to enable the user to find a
related or equivalent program held in the system.
The Andrew Help System
The Andrew help system is part of the Andrew Toolkit (Zanger, 1996).
The Andrew Toolkit provides a total environment for the integration of
diagrams, animations, raster images and other multimedia elements, the
sending and receipt of multimedia mail, and the easy creation of new
Andrew packages, seamlessly in one user environment built under X
Windows on UNIX. The Help System is designed to support the user
more comprehensively than the basic man command. The system is set up
to provide help on any of the programs that make up the Andrew Toolkit
or the underlying UNIX system. To get help on any topic in the system
the user first types the command “help which” displays a window (see
Figure 7.8 Andrew Help Screen) listing the main programs on which help
is available in the right side of the window. This list can be expanded to
list all the programs for which help can be found by selecting an option
from the menus.
Help can be found by using a specific word which describes some-
thing the user wants, such as ‘Bitmap,’ or a specific program, such as
‘ez.’ The system can also maintain a history of the help requests made by
the user (see Figure 7.9 Andrew Help Screen 2). This allows the user to
backtrack through the help screens they have accessed and thus follow-
up keywords or return to previously viewed information.
This system better supports the user than the standard command,
since the users are choosing a subject they require from a list of mean-
ingful options rather trying to guess at what might be the correct term.
There are overview documents that can give the user an overview of what
each available topic is, rather than the user having to wade through a
Retrieving 119

series of entries to find out whether it is like the one line description. The
system also incorporates manual pages defined to a strict format which is
designed to allow the user to find specific sections quickly without
having to read the whole entry and contains a section on related topics in
the system. To view any of these related topics, or if at any time a term in
the text is not understood, it can be highlighted with the mouse and the
system will attempt to find an entry explaining that term.
A similar program, called ‘xm an,’ has been developed for the stan-
dard UNIX system. It too lists all the available commands, but this com-
mand is in addition to and optional to the standard ‘m an’ system and not
the de facto system as ‘help’ is for Andrew, as well as providing fewer
features.

Figure 7.8-A ndrew Help S creen: This screen shows the large left-hand window
which displays the help page for the users chosen topic, here the start-up con-
tents of ‘help.’ On the right are two smaller windows showing document titles on
general aspects of the system in ‘Overviews’ and a list of the programs available
under Andrew in ‘Program .’

hall* Search Prim Other Panels Window

A Guided Tuur ufAndrew

To see more of this text: Move toe ir.ws e curs or Into the verdcal b ar z\ tie
left edge of the Hdp vrir.daw. This verted boor is the sereBter . To move
dawn in the text click toe kfimausm mutton, I'omavcup, r±c.< toe right mouse
5
li-.itton when thf. ri:rsorw Htor. srroFiar. The. wlvnlr scrriFliar np.p-* ft-Ths toe
Iwd. die •.■•’iii.ebciik toe tc:‘dlbtr Jit pa:-. oCihs: toxllha.i*
on fhe screen.

To n « tl» niwinw: Mos" win dews rantan sets op tst&m? . Hloosiig ontinrs
horn Ihiie menus dlows vculo chantey aurworkji .0 e vaxij us leaLire so J
a program. On a r.^a-buiton mouse, vress ar.dhald dovm both meuse bur.or.s
to ccuse the menus :o eppear. (Or. a three b oon mausa, press and hold
davmthc midele mouse button.) To cnoose a main aphon. keep -_hc butior.tsj
p-rssrdwlvlr. novrng tor. euno- to thr* nr.m: i-m yo j wa nt. W im "hr. irenii
iLeic: beco:nifc* darkened, lei «o uf IhebuLuiic* VU: choose it

•8 ;j: H w 10 see m ore help document!

120 Chapter 7

Figure 7.9-A ndrew Help S creen 2: This show s the history window in the bottom
right hand corner, showing the programs on which the user has sought help.

X I ik I |i /iiK r/liii:rfl/rtriiir K v /h n iji/z i[i .I ik I j i E3j

j Sttaj-uli PrLril Otfuji Parw*L Wuulkiw Mt;m; I

!S Zip: A D ra w in g V iew er an d E ditor Overtfffvrc

d '£;i
A rd w ror
;jvjr.i W hat Zip Is 1 7£/. r/umreJia •
v.^ • h/al j:
i!&
7 p s a p r o la n fir r.rr/thg and virsvino drawings. You f.a"i nsr 7jp as ?
ilajiL-aioitprogramwvcucankcluJeZpiriseUinItxLdacuntJiU j i labitv
|
|
P'ocrarrinhq \
Far r.ors Infarrr.jdcn. an crssdng and eitb fi 21a as an insets see -Jie J v4i:
helpdocuner.t, |
ill if i;I 1
K 71Js Htlp Locujntnt comisls :I Jit CaLowuig par.* | Mi
1 Starting Zip
Lrcpeoring. to dravt
Program* ;

jf§ nl*r. p ?ni r. ar d thr palrttf.s adev/

?he Zp .ppts bush
jp Entering CompaseMcds champ

|
Drawing {gaterd insyjctiicns) corsole
■wih fading and depth i® cut
Boudwl Hg.iie* S ' cq
Free-fomi figures m cz
czonnt
j
i !pj,:I
Drawing. each Aprs :vpe (specific insttvcions)
::exiting, maving. duplirsiting ccad deleting aLt jure types
M
i RMhapirgaid r.ditirg, r/r.i ngurr. typr.
i# Htrlji TTikIi ■'y
i j**)':
i
Previewing scad Pmtiiq s g iiju i# o

|
Using the Grit end 7 aordhate system
j
langir g aiir view oJth r. der^in « B
;! ij ui
fqjres
I

U Oe b ac.Lii o w.d and p aging It aLit * |

H
Foa-Up er.u Meanings I j
Preferences [ ?

i
; |
ixccntUhengcs 1

i....
Rrlatrd nr.o s H
•3
| Ifjjw: j

Web
The World Wide Web provides an interface to libraries like the world has
never seen previously. The web provides a massive collection of retrieval
tools that expedite finding information anywhere on the web. Features of
tools that were originally developed independently of the web and oper-
ated independently of it have become incorporated rapidly into features
of web systems. For instance, Gopher had much wider usage than the web
for some years. That’s no longer true and whatever can be done with
Gopher is now done through a web interface and typically more easily.
Retrieving 121

The WAIS information servers at one point competed with the web for
information access provision, but the word frequency tools used by WAIS
are now part of web retrieval tools.
Aside from these generic interfaces to web information, one can go
via the web to specific sites for retrieving software-related assets. For
instance, the United States Army maintains an active web site for the
“Army Reuse Center.” There one can not only learn much about the
Arm y’s views on reuse, but can also gain access to depositories of soft-
ware assets (see Figure 7.10 Army Center).

Figure 7.10-A rm y C enter: This screen image shows the w eb-based tutorial to
the Army R euse Center reusable software library (Army, 1997).
722 Chapter 7

Asset Source for Software Engineering Technology (ASSET) was

originally constituted by the Defense Advanced Research Projects
Agency as a sub-task under the Software Technology for Adaptable
Reliable Systems program to provide an on-line repository for reusable
software. Its first four years were devoted to developing, operating, and
maintaining the systems needed to operate the repository. In 1995,
Science Applications International Corporation (SAIC) began transition-
ing ASSET to a commercial site on the World Wide Web. SAIC/ASSET’s
core capabilities and experience, therefore, are centered around software
reuse and web technology: digital libraries, database management,
object-oriented systems development, software configuration manage-
ment, distributed information systems and Intemet/Web-based telecom-
munications.
SAIC/ASSET offers products and services over the web on the topic
of software reuse. One of its divisions is called Worldwide Software
Resource Discovery. That division contains over 1,000 assets available to
the public via the World Wide Web. From the web site users can search,
browse and download assets cataloged in 38 domains. Another division
of SAIC/ASSET is called Reusable Software Asset Brokerage Services.
This service provides access to commercial high-technology software and
tools via an electronic commerce service. Users may search, browse, and
order directly from the Web site (see Figure 7.11 SAIS/ASSETS).
Vendors with tools for sale can directly add their products to the
SAIC/ASSET catalog.

Monitoring Retrieval
If items retrieved from the library are separated into ‘relevant’ and ‘non-
relevant’ sets (see Figure 7.12 Retrieved Sets), then Recall and Precision
may be defined:

• Recall measures the ability of a system to retrieve relevant docu-

ments,
• While conversely, precision measures the ability to reject non-rel-
evant materials.

Alternatively, recall can be viewed as sensitivity and precision as

accuracy.
Retrieving 123

Figure 7.11-SAIS/ASSET: This screen from the company SAIS/ASSET shows

som e assets retrievable through its web site. The library is organized in various
ways. The path to this site went from domains to artificial intelligence.

y Assets in Domain: AR TI FI ClAL INTELLIGENCE - Microsoft Internet Explorer BBS

Fie Edit View Go Favorites Help

VOL 2 - NEURAL NETWORK DEVELOPMENT H

• ASSET B 1057 INTELLIGENT SOFTWARE DIRECTORY:
VOL 1 EXPERT SYSTEM APPLICATIONS
ASSET A 915 C-R Search Class Library (Alsearch) - DOS
ASSET A 914 C++ Search Class Library (Alseardii UNIX - - s-j.

ASSET A 903 CNCL (Comnumication Networks Class Library)

ASSET A 769 C++ Search Class Libran' (AISEARCH)
ASSET R 604 CLIPS/ADA - C Language Integrated : j
Production System, Ada Version (Reference)
• ASSET A 231 Pattern Recognition Packages

f What’s New] [Home I TSearch 1 f WSRD Catalog 1 f Suggestions 1 [

Add a Product 1 zl
'A

A good system is one which exhibits both high recall and high preci-
sion. A mathematical model of recall versus precision has been described
and can be used to quantify the trade-off in recall and precision (Gordon
and Kochen, 1989). In general most systems with high recall have low
precision, and most high precision systems have relatively low recall.
The size o f a library? relates to its value. The larger the stock of a
library the more likely the library is to contain the desired component.
The retrieval effort pays off more often and thus is more likely to be used
by developers to find components. The larger the library is the more it
will cost to build, but use o f the library will be more cost effective due to
cost savings resulting from reusing components. There must be a trade-
off between these requirements. Policies can be defined for adding com-
ponents to the library. The library retrieval system could be set up to
124 Chapter 7

monitor requests for components and produce statistics for the rate of
retrieval for each of the components in the library. This will show which
types of components are the most useful in the library and thus should be
updated or expanded. If the library system also produces statistics based
on components that are requested but do not exist in the library, the
library organizers could monitor which components should be added. If a
well organized method is used to search the library, the failed searches
could provide detailed specifications of needed components.

Figure 7.12-R etrieved S ets: Definitions of m easures for retrieval performance.

T o t a l E. e tri e v e d It ern s

N on -
R e 1e v a n t R elev a n t
Item s Item s

E. e c a l l = IT u rn b e r o £ 1 1e rn s r e tr 1 e v e d an d r e 1e v a n t

T o t al r el e v an t

Pi' e c i s i o n = ITu rn b e r o £ i t ern s r e t r i e v e d a n d re 1 e v an t

T o t a l r e tri e v e d

Ep ilogue
The concept of retrieving documents from a library is intrinsically linked
with that of storing the data in the library. Software documents commu-
nicate some model of the world, and for reuse of these concepts a devel-
oper needs to be able to access this model.
Retrieving 125

The user of a software reuse library is assisted in searching for useful

software components by an information retrieval system (see Figure 7.13
Principle of Information Retrieval from User Perspective). Using docu-
ment-oriented techniques a searcher enters keywords to specify a soft-
ware document. These retrieval methods, though simple, can work well.
But semantically they are very weak, and there can be little structure
implied in a search. In the object-oriented perspective, domain analysis is
used and software components are seen as objects with attributes, includ-
ing ‘input,’ ‘output’ and ‘function.’ The user then searches for useful
components by specifying desirable attribute values. This method is more
flexible for retrieval than document-oriented techniques, but results in the
organization of the library being more difficult and time-consuming to set
up and maintain. The user has a need for a component or components, this
need is expressed by them to the Information Retrieval System, which
can obtain the components.
Document-oriented retrieval requires that the user has a firm idea of
both what his or her desired component looks like, and how it is likely to
have been described or indexed at the organizational stage by either a
human or automatic indexer. This contradicts one of the basic require-
ments of a software component system, that the user of the library must
be able to retrieve a software component even when their ideas of how it
might work precisely are not yet fully formed or defined. This makes
retrieval particularly difficult for a developer in the early stages of the
software development life-cycle, when he or she may most need to know
which reusable components are available to fulfill his or her needs, and
thus this is another factor discouraging to potential users. This method
may also be a problem for the novice user, who may not easily be able to
express his or her needs clearly due to inexperience of the domain or of
the retrieval system.
The object-oriented retrieval methods are more formal and require
more effort from the people building the library. Domain modeling must
take place each time a component is to be added to the library, as the
model must be carefully maintained to ensure its integrity. Thesauri are
very useful tools to support retrieval but they too require much human
effort to create and maintain.
Traditionally there is a tension. A system is either large, complex, and
difficult to maintain but supports complex and powerful searching tech-
niques for users, with facilities such as a thesaurus. However if the the-
saurus is not well presented by the retrieval system, then this is an extra
factor to bewilder and discourage novice users. Or a system is essential-
ly very simple and it is up to the user to work out how to find the
126 C h a p ter 7

components they need. This tension has been a contributing factor to the
lack of acceptance of software reuse as a standard practice in software
development in the software industry.
The wide-spread use of the World Wide Web has changed many
things. The web does not resolve the problem of building thesauri. If any-
thing the plethora of infonnation on the web makes the importance and
challenge of good organization and thesauri all the more severe.
However, the popularity of the web interface creates a certain uniformity
of expectation and use that supports the use o f web libraries. Even simple
domain models and free text searching can be good enough when the
assets are good and people are comfortable with the interface.

Figure 7.13-Principle of Inform ation Retrieval from U ser P erspective: The

user has a need for a com ponents, this need is expressed to the information
retrieval system which can obtain the components.
Chapter 8
R e o r g a n i z i ng

The goal of software reuse is not simply to find program and document
components which might subsequently be reused, it is also to allow the
developer to modify and combine components and concepts to create new
software. In general, the components and concepts retrieved by the soft-
ware developer from the library cannot be directly reused without being
modified. They must be revised to fit with the target problem. This stage
may be called asset utilization or reorganization. How much work is
needed to reorganize an item depends upon many factors.
If the library contains program code for reuse, then unless the com-
ponents were designed from the outset to be reused in other projects and
in other domains, then reorganizing the component may not be a simple
case of instantiating the existing general component for the current prob-
lem in hand. Fundamental changes to a component may be necessary. For
example, to change the data-type or language, a redesign may be
required. Alternatively, the library may contain the top-level design doc-
uments abstracted from the brief of the prior project. These are general
documents and changing aspects of them is easier than with more specif-
ic documents, but the number of abstractional stages that are reused is
reduced.
The application in which the component was originally developed
will affect it in many ways, some perhaps extremely subtle. In a particu-
lar application it may be important for a component to be efficient in its
memory allocation, or to be fast and efficient in execution. This is just
one of many compromise decisions that may be encoded in a software
document, be it a code segment or a design document. There may be
many compromises made in the design of the software, dealing with every
aspect of the described component: usability versus functionality,
127
128 Chapter 8

readability versus optimization, and so on. These must be transformed to

match the developers current application. This can be extremely difficult
to do, and is made more difficult by the fact that the original developers
themselves may not have been aware of some decisions of this type.

R etriev ed C o m p o n e n t Suitability
Even if a search for an item does not simply fail, the retrieved item may
not fit the expectations of the developer. To what this may be attributable
will depend on the skills and methodologies of both the indexer and the
developer. Systems for retrieval might allow searches to account for qual-
ity of desired components. Items may be inefficient or poorly tested.
A code segment or design, although well written may have require-
ments for control over data structures or system resources that are unrea-
sonable in the context of the new target system. As a simplified example,
a retrieved item may be a fast sorting algorithm. However to operate this
algorithm requires two copies of the data. This may be undesirable, or
infeasible given storage restrictions on the target machine.
The library may only store components expressed in one design
methodology or programming language (or both). However if mixed
methodologies are used, it might be the case that a retrieved component
is expressed in a specification or programming language with which the
developer is unfamiliar. If this is the case it may be that the developer can-
not rely on understanding the component to the required degree. Only in
extreme circumstances would it be considered worthwhile for the devel-
oper to learn a new software engineering technique, or programming lan-
guage in order to comprehend the component. A similar problem would
exist if the library contained specifications which were a mixture of data-
flow oriented and control-flow oriented designs, as these are fundamen-
tal methodologies and cannot easily be reconciled together.
It may be very clear to a developer that a component exactly fits the
specification, or is totally unsuitable. However in most cases the useful-
ness of the retrieved component or components is somewhere between
these two extremes. It would be ideal if some automatic system could be
designed to quantify how close a match exists between the retrieved com-
ponent or components and the desired one. This is a non-trivial exercise
and could only be achieved (if at all) by complex and formal specifica-
tion of both the retrieved components and the target component, which
would in many cases be undesirable.
Reorganizing 129

The common method for modifying code is to thoroughly read the

code and from that design and implement the modifications. Problems are
found and usefulness assessed by the time-consuming process of modifi-
cation itself. Also in many cases it will not be simply a case of closely
examining a single component. If the library system is large and well
stocked then it may return, superficially useful components. All or some
of them may be suitable for the target component, some may even be opti-
mal, but to analyze them to the level required to illicit this information is
difficult and time-consuming.
It has been a common theme in this book that in the creation of any
software component, design decisions have been made by the original
designer that affect the component and it’s reusability. These design deci-
sions fall into roughly three categories :

1. Those that describe the problem domain and model the solution,
2. Constraints imposed by the solution space, such as power and type
of target machine and programming language used, and
3. Stand alone decisions that have little or no effect on the rest of the
program.

Decisions of Type 1 are the most important ones in the reuse process,
these are affected by Type 2 decisions. Type 3 are in general irrelevant.
Some design decisions are explicitly documented, though usually these
will only be the fundamental decisions that affected large areas of the
components structure. Most decisions made and in many cases, all deci-
sions, go undocumented and thus the reason that the decision was made
and to a large extent the specific result of that decision are lost. The only
representation of the decisions is the parts of the program that were influ-
enced by the decision made. These parts may be hidden in several parts
of the program and influenced by other factors and decisions.
So it is important to be able to find these hidden global and local deci-
sions. These are most detectable at different levels of abstraction. The
major decisions are best viewed at a higher level of abstraction than a rep-
resentation suitable for finding the localized decisions. Reverse engineer-
ing is helpful in this process, it is the process of extracting a higher level
description of a component from a lower level one, such as pseudo-code
from a C code program (Hausler et al, 1990). Performing this task reveals
decisions that are obscured by the perhaps pages of code that is required
to implement them (Ruigaber et al, 1990).
130 C h apter 8

D o c u m e n t R e organ izing
Reorganization of non-code documents forms an important part of utiliz-
ing reusable components since much of the information generated by the
software development cycle produces critical documents as well as the
next abstraction of the algorithm. Some of this documentation will be cre-
ated anew, but for the reused components attempts should be made to
generate the new documents from their existing documentation (see
Figure 8.1 Document Reorganization)

Figure 8.1-D ocum ent R eorganization: Original docum ents are processed
using their outlines and thesauri to form new outlines and thus new documents.

Docum ent Reorgani zat i on

Existing
Docum ents
R eo rg a n izin g 131

Figure 8.2-D ocum ent R eorganization U sing a T h esau ru s: The docum ents
are indexed using common terms, shown in the large box above. Those docu-
m ents that share indexing terms can be considered to cover som e common
ground and thus are candidates for integration.

A single document can be reorganized by moving around its sections.

To be able to do this in a meaningful and constructive way requires that
the outline and document be designed in a carefully balanced and modu-
lar manner (Rada, 1990). There are problems however with simply
changing the ordering o f a document. Good documents present an argu-
ment and then gradually develop that argument as they progress. Simply
re-sorting a group o f paragraphs will destroy this cohesiveness.
Components from several documents can be reorganized together
forming a new document. This can be performed by searching for blocks
of text containing certain key words, whereupon the outlines they are part
of are combined and reduced to allow the user to form a new document.
Thesauri are useful in aiding the reorganization o f documents. If two
132 Chapter 8

documents have been indexed using some or all of the same terms, then
it is not unreasonable to assume that those two sections cover related top-
ics and thus could be usefully compared or combined (see Figure 8.2
“Document Reorganization Using a Thesaurus”). If not enough links are
generated by the raw indexing material, this method of concatenation can
be extended by using a thesaurus to broaden the range of the linked terms.

P rogram R eorganizing
Retrieved software components may be modified in various ways (Mili
et al, 1994):

• specializing: a generic component is in some way made specific to

the current problem,
• composing: reusable components are reassembled to satisfy new
requirements.
• tailoring: adaptation of software components for new require-
ments.

Tailoring is the rewriting of an existing component to meet a desired

specification and was discussed earlier in this book under the heading of
‘Asset Utilization.’ Tailoring is labor intensive and discourages the reuser
in that many of the required tasks, such as in-depth analysis of existing
code, are unpleasant and tedious.
Specialization
Specialization is the act of binding generic components to the desired
solution space. For this to be effective the programming language used
for the components must support generalized constructs. Ada provides
structured techniques for generic components, called generic packages
(see Figure 8.3 Generic Variables). The package is instantiated in the
main code segment of a program that uses this package. A package may
even be instantiated for more than one data type within the same program.
This is made possible by Ada’s ability to handle overloaded operators.
For example, there can be several versions of the function add_item, all
called additem. When a call to additem is made the version of additem
instantiated to use the correct variable type for the calling parameters is
automatically selected.
Reorganizing 133

In other languages, depending upon the complexity of the data struc-

ture to be inserted or modified, search and replace techniques or condi-
tional compilation methods support specialization. Conditional compila-
tion is a method in which a makefile, a file that controls the compilation
of perhaps several separate source files to produce an object program,
contains conditional statements. By setting variables, the makefile will
compile different versions of a program. For example, on some systems
several separate code routines exist to drive different visual display units
(different number of colors, size of screen, and such). Any program
which is to drive the display on any specific machine will have a variable
set to indicate which display it has and the makefile will detect this, based
on environmental variables, and automatically compile the correct
display device driver.
Another kind of generic instantiation is template based. Here a pro-
gram code routine is written containing blank spaces, where for example
the declarations should go. To instantiate the routine all the user needs to
do is fill in the blanks (see Figure 8.4 Template). This offers advantages
over simple code modification in that the area that needs to be modified
is highlighted for the developers, and thus they do not have to spend a
long time trying to analyze the function to find these areas themselves.
The disadvantage of this method is that the templates must be specially
created, either from scratch or derived from existing components.
Composition
Composition is the combination of separately designed and written com-
ponents to create a cohesive whole, as in the UNIX pipe mechanism.
When composing components it is important that they can be made to fit
together correctly, i.e., that the parameters the first component passes to
the second match the parameters that the second component expects from
the first. In the UNIX pipe system, which is described in detail below,
each program has just one input and one output; however, in most cases
this is insufficiently powerful.
In the UNIX command line shell environment, standard system prim-
itive commands are implemented as simple programs, such as ‘lp’ which
prints a file, and ‘cat’ which opens a file and prints the contents to the
screen. Each of these programs is small and provides only a limited func-
tionality. However, when combined together using pipes, they can
produce complex results.
134 Chapter 8

Figure 8.3-Generic Variables: This code skeleton defines a package to imple-

ment an abstract data type for a queue. The items in the queue are defined as
generic, and limited private (which is a code hiding technique to prevent users
from attempting to ‘hack’ the internal structure of the package and m isuse the pro-
vided functions). The queue itself is then defined to use those generic param e-
ters. Nowhere in this code segm ent is a specific data type mentioned.
gene r ic
t ype it em is p r i v a t e ;
package queue_adt i s
t ype queue i s l i m i t e d p r i v a t e ;

— Oper at or s
pr o c e d u r e add_i t er n(t o _ q u e u e : queu e ; n e w_ i t e r n : i t er n ) ;

—‘ Con d i t i o n s
f u n c t i o n q u e u e _ e m p t y ( t e s t _ q u e u e : q u e u e ) r e t u r n boo l e a n ;

pr i vat e
■
— Code to implement the p r oc e d u r e s and f u n c t i o n s ,

end queue_adt ;

Every component has the same input and output mechanism, and the
output of one can be joined to the input of another very simply using a
simple command called a ‘pipe.’ To join two commands together is sim-
ply a case of placing the pipe command ‘|’ between the two commands
(see Figure 8.5 UNIX Pipe). This means that if a program is required to,
for example, open a file, process it (for example to add certain compo-
nents), and print the result, instead of a new program being written, or
even a sequence of code modules being joined together and compiled, the
three programs are simply linked together at the command line (see
Figure 8.6 Inter-Program Communication Using Pipe). This forms what
is called a ‘pipeline.’
R eo rg a n izin g 135

Figure 8.4-T em plate: An example of a code template, showing the param eters
in bold that should or could be changed by the reusing developer.
Fu n c t i o n B ub b l e S o r t ( ;a n a ys J
+ Template written by An d y Gr a y .

+ Declare Parameters :

+ Define f i r s t element of array

first input :=

+ Define site of input array

len g th in p u t :=

Be g i n
for counter var = first input to length i n p u t ~1
+ Check for c o u n te r ja r element greater than n ex t
i f
t hen
+ Swa p the items
endi f
en d

Figure 8.5-UNIX Pipe: The process on the left takes its input, from Std-ln and
produces its output on Std-Out. The ‘pipe’ connects the Std-Out from Process
One and the Std-ln from Process Two. Thus the output from Process One
becom es the input to Process Two.
136 Chapter 8

The developer is only required to write the ‘n e w p ro c e ss’ part, the

printer routine and file opening are supplied as part of the operating sys-
tem. This means that the developer need only concern him self or herself
with the new code, to actually calculate the totals. Input and output to the
new routine are dealt with using simple input and output code, which is
similar to the code that would be used outside the pipe environment. This
allows for massive increases in reliability, since ‘cat’ and clp’ will already
have been in use with many other programs and have therefore already
have been implemented for the current system and exhaustively tested.

Figure 8.6-Inter-Program C om m unication Using Pipe: cat’ opens the file and
its output is fed (via a pipe) into ‘new _process’ input and then ‘new process’ out-
put is fed (again via a pipe) into ‘Ip’s input.

cat so urcejle | new_process | Ipr-laserjet

sti-0 lit mu stijut stajn

There is no problem with version numbers since the programs are not
actually compiled together and all versions used will automatically be the
latest one. UNIX provides several of these basic programs for opening
files, printing them, sorting them, searching them, word counting, and so
Reorganizing 137

forth. Since the code used to implement these routines is very basic C
code, and all UNIX systems use C, they should be very portable from sys-
tem to system.
A very useful application of this pipe technique is to use programs as
what are called filters. These are extensively used in many systems. For
example, say that the totals program ‘new_process’ above, will only work
with floating point numbers, due to the way in which it was written. It
would be possible to modify the source code to create another program to
add up integers, but this may be bad practice. For example, if the way in
which the totals are calculated is changed, then the two programs, floats
and integers, must be modified, not one. In UNIX one solution is to write
a filter, another program which goes into the pipeline, that takes integers
and converts them to floats. Thus only the pipeline is changed and
‘new_process’ is unmodified.
This filter technique can be and is used to solve common problems,
such as that of picture display and conversion. Many different file formats
exist for storing raster picture information. Many micro-computer plat-
forms have their own most prevalent image formats, such as TIFF and
PCX. Other formats are more common on workstations, such as
Postscript encapsulated rasters and X Bitmaps. More recently standard
cross-platform formats like GIF and JPEG have become widely used.
These formats are all incompatible with one another. A program for dis-
playing GIFs cannot display a PCX file and a X Bitmap viewer cannot
display a GIF.
A user may have a display program for every format he or she uses,
for example a X Bitmap display program, a TIFF display program and so
forth. Each program must handle different screen displays and is usually
quite complex. An alternative approach is to have a set of conversion pro-
grams. But converting files one at a time is tedious. It would be better to
have a single display program that could handle all formats. However
building such a large system is a huge task. With the UNIX pipe another
alternative is available. The user has one complex display program, that
can display for example Portable PixMap (PPM) files, and has a conver-
sion program to convert JPEG to PPM, X bitmap to PPM, and so forth.
Pipes filter the input file to create a generic image format and send that to
the display program (see Figure 8.7 Image Conversion).
The UNIX pipe mechanism is easy to use due to it’s simplicity, but
this is also a problem. It is often important to pass many different para-
meters in different forms, such as complex, abstract data structures, like
arrays, stacks or queues, for which the above is not an appropriate model.
It is only suited to simple flows of information. The handling of complex
138 Chapter 8

parameters is greatly simplified in object-oriented languages, such as

C++. Here the objects to be composed are distinct and communication
between components is minimized to those values that make sense for a
particular object.

Figure 8.7-Im age C onversion: The original image format is filtered by a rele-
vant program to produce a PPM or Portable PixMap. This is a very simple ‘low-
est common denom inator’ file format, which is easy to handle. Then this file is
displayed via a pipe by another program which can only display PPM’s, which
performs all the complex display handling. A large number of programs are avail-
able to perform functions on PPMs, such as to double the size.
Reorganizing 139

Work has been done on Module Interconnection Languages

(DeRemer and Kron, 1976; Kaiser and Garlan, 1987) in which rules auto-
mate code level integration. Developers describe their software as a set of
modules and a specification of each of their input and output characteris-
tics. The system then tests the connections to see whether they are com-
patible. This approach to building reusable components makes relevant
compromises between the granularity of the components and specificity
of their function.

C od e G en erators
An alternative method of creating code efficiently is to generate it auto-
matically from formal requirements or design. This code generation tech-
nique is not strictly speaking software reuse. On the other hand, it is
another use of the specification and bypasses the organization and
retrieval stages of the reuse cycle. The code generation approach may
shorten the waterfall life-cycle by removing design, implementation, and
testing from the software production process. Developers specify the
desired program in some high-level language, with a possible mix of
declarative and procedural constructs. The generated programs are usu-
ally correct in construction, thus alleviating the need for testing.
In some views of software engineering, software development is seen
as simply a series of transformations (Balzer, 1981; Rich and Waters,
1988; Green and Westfold, 1982; Smith et al, 1985) from formal specifi-
cations to the finished program (see Figure 8.8 Program Transformation).
Code generating systems are designed such that given a program specifi-
cation written using some formal method, like Z-Sehema or VDM, that
specification is transformed, via a series of intermediate representations,
to either an executable form or a form that can be readily made exe-
cutable. Code generation systems have four main advantages:

1. They relieve developers from labor-intensive, routine derivation of

the lower level abstractions of code.
2. Since the lower abstractions are machine generated, transcription
mistakes are impossible,
3. The system automatically maintains a record of development
choices, their rationale, or both, for maintenance purposes. Since
this too is automatically generated it too is error free, and
140 Chapter 8

4. Ensures the ‘correctness’ of the resulting programs by construc-

tion.

The transformation is performed by syntactic rules which work upon

the original definition and replace it with lower-level abstractions, until
the executable stage is reached (see Figure 8.9 Program Transformation).
In a reuse scenario a transformation may also be required to modify an
existing retrieved component specification that does not quite match the
developer’s specification into a specification to fulfill those requirements
(Boyle et al, 1984).

Figure 8 .8-P rogram T ransform ation: The formal specification is transformed

via several intermediate representations to produce a target program, and a log
of the changes m ade by each transformation is maintained.

Form al
S p ecifica tio n Transform Transform Transform Program
O ne Tw o Three C ode

Change Log
R eo rg a n izin g 141

Figure 8.9-P ro g ram T ransform ation Exam ple: Here can be seen part of a for-
mal specification (in a textual form, for simplicity). This specifies that at that par-
ticular point the user may wish to load an exam ple file. This can be transformed
or expanded to show the tasks involved in the two intermediate representations
(I.R. 1 and I.R. 2) choosing a file and opening the file. This in turn can be expand-
ed to list the steps involved in each of these stages. This produces an executable
specification, which could be compiled or perhaps transformed (via T’form 1 and
T’form 2) into an executable language like C or Pascal.

The difficulty in creating software using the transformation method is

that the developer must specify exactly and with total accuracy his or her
desired component using a complex, formal method. Furthermore, this
method has not been successfully implemented on other than toy
142 Chapter 8

examples and the amount of knowledge necessary to implement a system

for anything larger could be prohibitive (Partsch and Steinbruggen,
1983).

Testing after R e u s e
In the vast majority of cases software will not be reused in the same state
in which it was retrieved from the library, instead it will be modified or
re-written. These changes mean that any validation or testing techniques
used to check the original program are no longer guaranteed to be applic-
able. This case is also true of programs that are modified as part of the
normal software maintenance process, and it has been because of this that
the selective revalidation of software has been most extensively
researched in the past. This technique involves designing testing strate-
gies that instead of testing a program exhaustively, which has already
been fully tested prior to being modified, simply tests the modified sec-
tions. This is quite complex as the interactions between perhaps hundreds
of components are extremely complex.
However in a reuse situation this revalidation is more complex due to
the more subtle ways in which the original testing procedures can be
invalidated. For example the original testing can be made invalid by the
component being reused in a situation where the data the routine is
required to act upon is different in emphasis and range of values.
Reuse provides special challenges to a developer who reaches the
testing stage. Testing is easier to do if the developer of a piece of software
is at hand, since that individual will know that piece of software inti-
mately and will have a good idea of what they think are difficult parts of
the solution that the program provides. In many ways of course it could
be argued that equally important is to use an impartial tester who does not
have a large set of preconceived ideas about how the routine is written
and what special cases and so forth are handled in the code. However, in
a reuse scenario the choice of using either or both will not exist in many
cases, since the original developer of a reused component might have no
connection at all with the current team. The program may come with test
data, but if the program has been changed, then this test data may be inap-
propriate. The programmer or analyst who has modified the component
will obviously have gained an understanding of the component, but this
will not usually be as in depth as that held by its original author.
Whilst talking about software testing it is appropriate to talk about the
quality of software. All through this book it has been put forward that the
R eo rg a n izin g 143

quality of a component is extremely important for the reusability of that

component. But what is quality? Due to its subjective nature, quality is
best enforced using guidelines for developers so that when a component
is written it can be expected to have certain features that are considered
to give quality to a component, such as all modules having approximate-
ly a standardized size and all having been tested using specific techniques
and documented to a specified quality level (Halstead, 1977). This creat-
ed software is then reviewed by someone other than the author to ensure
that the standards have been followed (see Figure 8.10 Quality Review).
This task is also performed when the software is modified in some way.
Determining quality is a challenging and continuous task, as was also
indicated in the ‘Reuse Framework’ Chapter.

Figure 8.10-Q uality Review: From the original specification the developer cre-
ates a software package following the guidelines. The com ponent is checked for
quality by the reviewer comparing it with the guidelines and a review of how well
it m eets the criterion is written.
S pecification G uidelines

R e v ie w er
144 Chapter 8

Epilogue
Precise methods for tailoring or adapting software or other assets are not
generally useful. Instead the reorganization of assets remains largely an
art. The analogy to reproduction with change in biology is partially valid.
The organisms do not know exactly how to modify their genes, but use
some broad heuristics like the cross-over operator and hope for the best.
Software reuse is a little like this. The problems relate to the complexity
of the assets to be reused and the complexity of the target, new products.
One recent experience highlights these difficulties. A team attempted
to reuse three standard pieces (Garlan et al, 1995):

• an object-oriented database,
• a toolkit for constructing graphical user interfaces, and
• an event-based tool-integration mechanism.

Selection of assets to reuse was made on the basis of promise for

working together and requiring the same compiler that the team used on
its other major project. After five person years a prototype was devel-
oped, but the system was huge, sluggish, and difficult to maintain. The
main difficulties resulting from the integration included:

• excessive code,
• poor performance,
• the need to modify external packages, and
• the need to reinvent existing functions.

In retrospect, the problems were largely associated with conflicting

assumptions among the parts that were being reused. Each asset is based
on certain assumptions, pre-eminently about the data model, the control
model, the protocols, the topology of system communication, the pres-
ence o f other components, and an order o f operation. These assumptions
are not typically made clear enough in an asset description. The reuse
team discovers these assumptions the hard way as it tailors the assets to
the new situation. Thus, successful tailoring must begin with careful
selection of assets from a well-understood library of components that is
harmonious in many ways with the environment of the new development
team.
It is something of a paradox that the Reorganizing Stage is the most
important of the entire reuse cycle, but is the least well covered in
Reorganizing 145

research and tools. There are several reasons for this. The first and fore-
most reason is that reorganization can not occur until there has been orga-
nization and retrieval and those two steps remain themselves the subject
of much debate and research.
The organization and retrieval stages are based on much long term
work in the field of library science. The reorganization stage enjoys no
such parallel field. Reorganization is the most complex and difficult to
perform. It will be no easier to automate this stage of the reuse process
than to write programs which can themselves write programs, adapting to
problems along the way.
The reorganizing stage raises many questions:

• If code is retrieved, is it in the right language? How well has this

code been tested? Is the test data available?
• If design documents are retrieved, are they in the appropriate
design language?
• If two components are retrieved that do the same job using differ-
ent algorithms (for example merge and shell sorts), which is the
most applicable here?
• Can documentation be reused too?

Many of these questions have no simple answer but the reorganiza-

tion phase depends on answers to these questions.
Once reorganization is completed, it is then and only then that it is
first possible for the development team to look back over the project and
attempt to assess if reuse techniques have paid off in this project. There
are many possible pay-offs that reuse may have, including shorter devel-
opment time, less expertise demanded of team members, and greater reli-
ability and number of components created for future reuse. Successful
reorganization depends on good organization and retrieval. Additionally,
no organization or retrieval can be good unless the ultimate reorganiza-
tion is successful.
Section 4
Practical E x a m p le s

This section contains three chapters. The first describes reuse tools, while
the second presents case studies in the management of reuse at compa-
nies. The third chapter is about systems for multimedia courseware reuse.
Chapter 9
S oftw are R e u s e Tools

Within this Chapter several prototype systems are examined which sup-
port document and object-oriented software reuse. First software engi-
neering tools are reviewed and then two prototype reuse systems, called
Practitioner and SoftClass. Finally a user interface generator is described.

CASE
Computer Aided Software Engineering (CASE) may increase productivi-
ty in software development. The productivity gained by using CASE
comes from the following areas:

1. CASE tools help enforce consistent technique usage throughout an

organization.
2. Interactive graphics support allows software engineers to develop
and manage diagrams that help communicate design concepts.
3. CASE tools ease the complex book-keeping chores associated with
software implementation through a system of reminders.

In order to maintain consistency throughout the software develop-

ment cycle, many CASE tools have centrally a database that stores all the
components of a project. This database must at the very least allow engi-
neers to logically associate documentation and source code, annotate
freely any part of the design, and manage different versions of the soft-
ware in production. But, by it’s very nature, a CASE environment will
make further demands on a database. For example, it must allow simul-
149
150 Chapter 9

taneous access by team members, allowing them to work independently

and then merge their work back into the main project. Hypertext, with it’s
arbitrary information structuring and entity relationships, provides an
appropriate model on which such a system may be built.
CASE Architectures
There are a great many CASE tools available which aid the software
development process in a variety of ways. An Integrated Project Support
Environment (IPSE) is intended to support all of the activities in the soft-
ware process from initial feasibility studies to software maintenance and
evolution. At present there are few IPSEs in use, but there are many under
construction in North America, Europe and Japan. Several available soft-
ware tools are interfaced to a database management system so that output
of any one tool could potentially be an input into any other tool. It is nor-
mally the case that tool interaction is predictable, but there are many
cases of serendipitous tool combinations and the IPSE database allows
these combinations to occur when required. Another advantage is that the
project management have direct access to project information and man-
agement tools and are able to use actual data collected during the course
of the project (see Figure 9.1 Case Tools).
All of the documents produced in the course of a project from feasi-
bility studies to fault reports can, if necessary, be put under configuration
control and managed by the configuration management tools which are
an integral part of the environment. Furthermore the database facilities
are rich enough to allow relationships between documents to be recorded
so that designs, for example, could be linked to their associated code, and
changes to each automatically tracked. If an environment is properly inte-
grated, all support tools will present the user with a consistent interface,
so that the task of learning new tools would be made significantly easier.
A typical structure for IPSEs is to be built around a layered system,
analogous to an onion, where there are a number of layers of functional-
ity provided by the different levels in the system. The model includes the
following layers.

1. Operating System,
2. Database System,
3. Object Management,
4. Public Tools Interface, and
5. User Interface.
Software Reuse Tools 151

Figure 9 .1 -C ase Tools: The database supports the wider functions taking place
in the development of software.

It can be argued that IPSEs should be built in conjunction with a spe-

cial purpose operating system tailored to support the environment, but the
need for portability has meant that the innermost kernel (layer 1) in the
IPSE is a standard operating system. The majority of IPSEs have been
chosen to be built on top o f the UNIX operating system. The reasons for
this are partly to make use of the software tools supported by UNIX.
The third layer in the IPSE is the layer which distinguishes an IPSE
from a software toolkit or CASE workbench. This is the object manage-
ment layer which is responsible for controlling and managing all of the
entities produced during software development. Broadly, the object man-
agement layer allows objects to be named, to exist in a number of differ-
ent versions, and it provides facilities for relationships to be recorded
between objects.
152 Chapter 9

Hypertext CASE
Many interconnections exist among the components of the software life-
cycle but these interconnections are difficult and time-consuming to
maintain in paper forms. Hypertext makes it practical to connect all these
pieces together automatically and dynamically (Biggerstaff, 1989).
Furthermore, hypertext supports information reuse. For example, when a
paragraph about a component’s design is used as a comment in the pro-
gram documentation and as a paragraph in both the user and design doc-
umentation, in a conventional system this means creating and maintain-
ing multiple copies of the same information. In hypertext, this configura-
tion can be implemented with appropriate links from all the occurrences
to a master copy of the information node. This gives many advantages,
not the least being that any modifications made to the section are auto-
matically reflected in all its occurrences. Also the relationship between
such documents as requirements and code can be traced.
The Hypertext Abstract Machine (HAM) from Tektronix is a gener-
al-purpose hypertext storage system which can be used as a base engine
for other hypertext systems and in CASE systems (Campbell and
Goodman, 1988). HAM stores its database in a centralized file server.
The storage model is based on five objects: graphs, contexts, nodes, links,
and attributes. A graph is the highest-level object which, in turn, contains
contexts. Each context has one parent context and zero or more child con-
texts. Contexts contain nodes and links, while attributes can be attached
to contexts, nodes, or links. HAM is designed to work in a networked
environment.
Tektronix has developed a CASE system called Neptune which uses
HAM and is extensible (Delisle and Schwartz, 1986). Neptune holds all
the project components : requirements, design, source code, test data and
results, and documentation. In Neptune a link or node can have any num-
ber of attribute/value pairs. The attribute ‘projectComponent’ can have
any value from the set of project components: requirements, design, source
code, tests or documentation. The attribute ‘relatesTo’ is applied to links and
can have any value from the set ‘leadsTo,’ ‘comments,’ ‘refersTo,’
‘callsProcedure,’ ‘followsFrom,’ ‘implements,’ or ‘isDefinedBy.’ By example,
a node with ‘projectComponent’ value of ‘requirements’ would have a
‘relatesTo’ value of TeadsTo’ with the node whose ‘projectComponent’ was
‘design’ (see Figure 9.2 Neptune).
A node may contain any amount or type of information. A link is not
restricted to pointing to an entire node but can point to any point within a
node. Contexts are defined by grouping nodes and links with certain val-
ues. For instance, nodes with the ‘projectComponent’ value of ‘code’ are
Software Reuse Tools 153

implicitly grouped into a context and each node gets an attribute called
‘System.’ The values of ‘System’ can be UNIX or VMS a query is made for
the node predicate of ‘System=VMS,’ then only those nodes whose source
code is applicable to Digital Equipment Corporations VAX/VMS operat-
ing system are returned.

Figure 9.2-N eptune: Showing two nodes related by one attribute, as described
in the text.

With Neptune one can copy a subset o f nodes and links from one con-
text into another context. Contexts can be used to define a workspace and
partition a project into local and global workspaces. A local workspace
lets a developer abstract a subset of nodes and links from the global work-
space and place them in a workspace where he or she can make local
modifications, test these modifications against the rest of the project, and
when satisfied merge the changes back into the global workspace.
154 Chapter 9

Ideally, the partitioning of workspaces between engineers should be

disjoint, but in practice it may transpire that two or more are working on
the same nodes concurrently. In order to allow this, Neptune must resolve
concurrent update conflicts and not allow the work of one engineer to be
overwritten by that of another when local workspaces are merged into the
project workspace. To aid the developer in accessing all the information
stored many browsers are available, these include a node browser, an
attribute browser, a version browser and a node differences browser.

Practitioner
Practitioner was a five year project funded by the European Commission
and comprising teams in Germany, the United Kingdom and Denmark.
The ultimate goal was the development of a support system for develop-
ers involved in the pragmatic reuse of software concepts. This system was
realized as a set of prototypes, called PRESS {Practitioner Reuse Support
System). Practitioner was concerned with the reuse of software concepts
from the ‘ideas’ embodied in requirements documents through to code.
PRESS was designed not to be bound to a specific programming lan-
guage but to emphasize the description of software concepts. Thus it tried
to bridge the gap between:

• knowledge representation techniques; and

• the more general, information storage and retrieval techniques,
which are usually based around component retrieval from a library.

The PRESS system was designed with a ‘domain specific application

area’ in mind, that of a Steel Mill, which the project used as its example,
but embodied techniques that would be relevant in any area. To quote the
project documentation:

‘In a sense, the PRESS prototypes can be seen as an information plat-

form for the trained professional in the technical world. They may be
used not only to store and administrate information related to soft-
ware concepts, but also more general domain-related information,
about the application area the software was written for, in a structured
form, which may be more or less rigorously formalized. ’
Software Reuse Tools 155

Figure 9.3-L evel O ne P ress: Here the three main com ponents of the system
can be seen, in conjunction with their interactions with the user-interface.

UN IX ORACLE
F ile-S v stem D at a b a s e

PRESS included three partially complementary prototypes: a small,

low overhead variant called PRESSTO, a bigger and more powerful ver-
sion called PRESSTIGE, and a collaborative hypertext system called
MUCH. PRESSTO ran without any form of database system, being sole-
ly supported by the UNIX file system, whereas PRESSTIGE made sub-
stantial use of an SQL relational database management system.
156 Chapter 9

Figure 9.4-ToPD Bubble: Tool on Plain Documents (ToPD) functionality.

I n p u t f or T o P D

User input
f or e d i t i n g
and browsing

ID F ie

U N IX U N IX
F il e - S y ste m F ile -S y ste m
O u t p u t f r om T o P D

The PRESS toolkit included three processes exchanging information

(see Figure 9.3 Level One Press). The 'Tool on Plain Documents’ was for
retrieving plain text files based on words in them. The 'Thesaurus Tool’
and 'Tool on Structured Documents’ were for the manipulation of more
structured information.
Software Reuse Tools 157

PRESSTO
PRESSTO is the simplest o f the Practitioner tools, it is designed to specif-
ically deal with plain text, with some thesaurus support. PRESSTO sup-
ports searching across document collections using words taken from a
word index by the user. PRESSTO is very much based on features in the
UNIX operating system and does not use a database system. PRESSTO
instead simply accesses files containing reusable components or concepts
as they are stored in directories on the host computer (see Figure 9.4
ToPD Bubble).

Figure 9.5-PR ESSTO Indexer: Showing a docum ent that has been loaded to be
indexed and the functions that are available to act on it.

0ES lir a s * i

F ile E d it Help [

| s e l e c t dccunart l i s t |

_________________________________________ 1
I i d set- d zeu n srt

2
B o x n e n ta on 1 y p e t e x e
| s e l e c t te r n l i s t

| e e l act stopuDrd l i s t !

Ted N elacn D e f in it io n s c f H 2 S B S L
□ ir c .u d e rubbers o n / s f f
' H u p e r te x t i s ! a c o n b ir a tic n of n a c jr a l language t e x t J i t h tk e c u n
iirtjri: y fin* iril.K”ri:l.i .fl- lrvrn:hir y i f ilyn-n ii: l is p l r y ". , , 1 if n i t
cr ea te M l ter n l i s t tcK t U * +. i n ic h aennot be p r in te d on a czjrvcn tion n i p c q : / i
[Mahon.. T.H t C1367> G ettin g ] t Dct o f Our S ys:= n . l r S c n e c h ta r, G, 1
in fe r n a tio n :Jetr L?.,.a.i f C*i t : c a l R c d e u , k aih * ILD*. F ic n p ia - Ilo:k:
| 11 xjlrty i i:i:u"iny |j -r m |
'H jr e r -a v t. :r n o n -e e q .ia n :ie ] v r l t m;) u : :n f r e e u ta r nouenent a l © x
i i e i h f l e ard o d i o u s : d s c . I t i i m creld t h e e . e i t r o n i f i c a t i o n af
h t e r a r j c o n n e c t ld t s aa ue a ir e a c y knew t n e n . ' [ N e ls o n , T A C1987)
| d is p la y r e n a ir in g t e r ns | 2
| <91------------------------- i b
| ren ^ -e stop u ard s

| npil-il m I w i i 1 ixl.

| upd ate T i le l i l t

[q u it index: i l

1 n k id n e j f : l a l i s t |
158 Chapter 9

The key concept around which PRESSTO is built is the notion of the
occurrence of a token (a term important to the developer) in a file. The
main question that is being asked by a developer of the software is ‘ Which
files contain which tokens?.’ To set up PRESSTO a file has to be created,
called a Ts-file’ which lists all the relevant files containing reusable infor-
mation and a ‘talc-file’ that lists all the relevant indexing words in a nat-
ural language (such as English or German). PRESSTO can then be used
to extract all user defined symbols from programs written in a program-
ming language such as C or to extract only those terms that appear in the
talc and a document. The activation of the indexing function is controlled
from a menu-based interface (see Figure 9.5 PRESSTO Indexer).
The retrieval function of the PRESSTO tool involves (see Figure 9.6
PRESSTO Retrieval) two modes, 'File Mode’ and 'Index Term Mode.’ In
Index Term Mode clicking on an index term, for example Giraffe,’ caus-
es all files that contain giraffe as an indexing term to be highlighted in the
file list. Clicking on the file name then causes it to be displayed in the text
window at the bottom of the screen. The File Mode is similar in principle
but is functionally opposite. Hence clicking on a filename would cause all
keywords contained in that file to be highlighted in the terms list.
PRESSTIGE
PRESSTIGE provides methods and tools for building a concept model
called a ‘questionnaire,’ and provided techniques for retrieving informa-
tion relating to software concepts. One method used to provide a struc-
tured form for entering information about software is to create a concept
model. One of the main purposes of the concept model is to guide the
analysis of documents being added and the extraction of the information
that will be needed to reuse the component later in a structured way. A
concept model should ideally contain all the information that may be use-
ful to a potential reuser (Albrechtsen, 1990). It may be possible to derive
some aspects of the concept model automatically using facilities offered
by software engineering tools. The concept model should store informa-
tion about itself in addition to the information it stores about the compo-
nent it describes. It should say who created the concept model, if it is tied
to a specific project, and so on. PRESSTIGE offered a set of supporting
functions for three tasks :
Software Reuse Tools 159

Figure 9.6-PR ESSTO Retrieval: The PRESSTO search tool interface. More
power can be given by using the buttons in the middle of the screen. If two term s
are selected, then clicking on ‘OR’ will list all files that contain either keyword,
clicking on ‘AND’ would display all files that contain both. The ‘NOT’ button is
designed to allow the developer to search for files that do not contain a particular
term /set of terms.
160 Chapter 9

Figure 9.7—H ierarchical C oncept Model: The answ ers to the questions on the
Top Level’ questionnaire are in turn ‘Component 6,' ‘String Lib,’ ‘Math Lib’ and for
‘Component 6,’ ‘A.D.T. 6.’ This provides a hierarchically structured sem antic net-
like structure of descriptions of a software item.
Software Reuse Tools 161

Figure 9.8-HLQS DFD: Data-Flow diagram of the software module. HLQS has
the three com ponents Translate, Query, and Report.

HLQS BD

Users
Input

User's
Report
E x p l o d e d Vi ew
of HLQS
162 Chapter 9

Figure 9.9-HLQS Concept Model: Excerpts from questionnaire describing

HLQS.

High Level Interface to a R elation DBMS ( HLQS )

Authorising Person: Joe Blow
Created by Person: John Smith

De f i nit ion:
Func t i o n : HLQS provides a high level i n t e r f a c e . ..
In t e r f ace s
Inte r faces Prov ided
Us e r 1s rep o r t
In t e r f a c e s Required
User's Input
R elational DB
Cone ept Decomposition
Sub c o n c e p t b e i n g Insta n ila t e d
T ran s 1 at e
Interface Bindings
External concept in terface bindings
IN: U s e r 1s Input
Interna 1 s ubconcept in terface bindings
0UT: SQL query
0 UT: Format tempi a te
Sub c o n c e p t being In stan tiated
Qu e r y
Interface Bindings
External concept in terface bindings
IN: R elational DB
Internal sub c o n c e p t in terface bindings
IN: SQL Q u e r y
OUT: T a b l e
Sub c o n c e p t b e i n g In stan tiated
Report
I n t e r f a c e Bin ding s
External concept interface bindings
OUT: User's Report
Internal sub c o n e e p t in terface bindings
IN: Table
IN: Format template
Software Reuse Tools 163

• Construction and maintenance of a thesaurus and its related index-

ing terms,
• Description and indexing of software concepts (using question-
naires), and
• Browsing and retrieval of software concepts.

These tasks constitute a reuse scenario, where the domain model pro-
vides a standard vocabulary that can be applied for subject representation
(indexing) as well as for subject retrieval of software concepts. The the-
saurus links together questionnaires and aids the developer in browsing
groups of related documents by creating networks of documents based on
linking terms in separate texts via the thesaurus.
The key components in the PRESSTIGE questionnaire are derived
by the developer answering various questions about the component to be
stored. What these questions are in a particular company would depend
on the domain in which the PRESSTIGE system was to be used. Typical
ones include :

• administrative to the questionnaire itself; such as ‘authorizing per-

son,’ ‘created by person’ and ‘date of creation,’ or
• interfaces that the concept makes with other concepts, such as
‘interfaces provided (output),’ ‘interfaces required (input),’ and
‘interface bindings.’

One of the main purposes of the questionnaire is to guide the analy-

sis of the source material and the knowledge analysis process that finally
leads to the formulation of reusable concepts. Questionnaires include
Application-Oriented Descriptions, Implementation-Oriented
Descriptions, and Historic Development (for version control) informa-
tion. A questionnaire may reference another questionnaire. Allowing
hierarchies of questionnaires allows a top-down decomposition of soft-
ware concepts of any size, anything up to entire software systems (see
Figure 9.7 Hierarchical Concept Model).
Questionnaires may be formed from scratch based on information in
the software engineer’s mind, or may be derived from existing software
documents, such as programs or design documents. Filling in a question-
naire requires comprehension of the domain framework, especially when
dealing with high-level conceptual designs. In many cases the question-
naire attribute values are uncontrolled, free text, but they can be the
names of other questionnaires, providing a structured document tree. This
164 C h apter 9

is a mixed approach to library organization, i.e., a combination o f both

object (the questionnaires) and document (the answers on the question-
naires) methods.

Figure 9.10-T he B ase W indow of the S earch Tool: This window show s the
Press search tool. An example of the result of a search for all the concept mod-
els indexed on 'heating’ is shown. The nam es in the window are the titles of con-
cept models found using that term.

rm PRFSSiSparrh Trml

^ E x scu ts ccl ) ( sho-ff lo g . . . j ( sho-j H * :p .. . )

CCL E d i t o r ' FIXr) ( O P ) (A M D j j' NOT

f ih d h satiric
$

^ 1abbi -g TTni - Co - =nd fl - ?i 1 ]

O v era ll Haregener.c In form ation an t P ro cu ctio n C cn ed u lirg -1
f in i s h i n g and Warehousing U nit c o n tr o l and dupery i s io n - 1
c c o v e n U nit c o n tr o l and E u p erv isio n -1
B1ay L FLil i i a . ■= Uni . Co il I ' o I r.Jid S ..p^x v 1 = Lon~ 1.1
Dv<=-n Ff- i t. Cnntro 1 and rup^rtri s ion -1 .1
F in is h in g and W arehousing U nit C ontrol and S u p e r v is io n -1.1
u v e r a il flanigorient in fo rm a tio n and P rod u ction tfc n o d u -in g -l.
= iab bing U nit C ontro_ end fc>uporvic i o n - i .1

3 Q u e s tio n n a ir e ts i selE cted Pl ant it i o n e r: Ke i I man n

An example questionnaire will be provided for a software module

that provides a high-level interface called HLQS to a relational database
management system. HLQS takes as input a high-level query in some
format, and accesses a database of records (see Figure 9.8 HLQS DFD).
In the corresponding questionnaire (see Figure 9.9 HLQS Concept
Model) the subcomponents are referred to only by name because it is
expected that they be described in separate questionnaires. Interface
Software Reuse Tools 165

Bindings describe both the interface of the subcomponents to outside

components (through the interface of the component itself) and the bind-
ings to data flows that are internal to HLQS.
The PRESSTIGE search tool makes use of the Common Command
Language (CCL) search language. The user is allowed the use of AND,
OR, NOT and wild cards except that under PRESSTIGE they are used for
the retrieval of questionnaires, not files (see Figure 9.10 The Base
Window of the Search Tool). The form of a CCL statement is:

find [<property>=] <search term [+<thes. relations>]

[AND | OR | NOT [<property>=] <search term> [+<thes.
relations>]] [AND | OR | NOT ...

Where entries between brackets are optional search terms may contain
wild cards. For example, the search term

ind?

will find questionnaires that have been indexed with a term starting with
‘ind’ such as indexing, indexed, or indices. The qualifier can constrain the
matches found by a search by specifying a questionnaire property (for
example the 'Function’ of component) for which the match must occur.
The qualifier <thes. relations> is used to extend search terms. For
example, the query:

find ‘Function’ = ‘open-loop control’ +BT

returns questionnaires whose Function have been indexed by 'open-loop

control’ or any of its broader terms (BT).
The browse tool enables the user to see all the keywords from all the
questionnaires, all authors of the concept models, all dates of creation of
concept models, and so on. It allows the user to see the terminology used
in all the questionnaires and thus get a flavor for the whole system. The
form of a questionnaire for a domain can be described in any way the user
chooses. Once a questionnaire has been set up, the questionnaires to be
entered into the same system must be consistent with it. Once the
Questionnaire Tool has retrieved a questionnaire the developer may edit
it, copy it, delete it, or move it. The thesaurus tool is used for general
management of the thesaurus (see Figure 9.11 PRESSTIGE Thesaurus
Tool). A term, for example 'open loop control,’ can be entered and the
thesaurus item for this term is retrieved and displayed in the ten windows
166 C h apter 9

that form the thesaurus tool display. The user can then see the BT (broad-
er term), the date of creation, and so forth. Any o f the terms generated by
the search, for example the Narrower Term, can now be used as a search
term to retrieve further related items. Usually only the domain analyst has
control over adding and deleting terms to or from the thesaurus. Control
over terms is important, if consistency is to be maintained throughout the
thesaurus.

Figure 9.11-PRESSTIG E T h esau ru s Tool: This is a tool to show a thesaurus

term, in this case ‘open-loop control,’ and its associated terms.
S o ftw a re R e u s e Tools 167

Figure 9 .1 2 -P ractitio n er R euse Mill: This diagram shows how the different pro-
gram s that were developed for the Practitioner project fit together and exchange
information.

WRITE WITH REU SE

textual concept representation

& retrieval & thesaurus new
document

graphical retrieval &

con cept rep re s entati on thesaurus
168 Chapter 9

MUCH
The MUCH (Many Using and Creating Hypermedia) system supports
collaborative hypertext authoring (Rada et al, 1989). MUCH enhances a
number of functionalities of PRESS and helps integrate PRESSTO and
PRESSTIGE into a single multi-faceted system (see Figure 9.12
Practitioner Reuse Mill). PRESSTO testing demonstrated that 'under-
standing’ tasks were not well-supported when searching separate, but
inter-connected documents, the user having to go to the next one via word
search. The MUCH system can alleviate the problems in this situation.
The MUCH system is programmed in C running on networked UNIX
workstations, having its own database system, and X-Windows interface.
MUCH puts stress on the outline in a document, since it forms the
existing structure in documents and is possible to extract automatically.
Outlines can provide an overview of a domain and can aid a user in
domain exploration. In MUCH, a fisheye view of a document is imple-
mented, by the user 'folding/unfolding’ the outline. Different links can be
distinguished by labels. Annotation and discussion are also supported by
a Typed link,’ called ‘Comment’ as a communication mechanism among
co-authors. Users can add links between hypertext nodes at will (see
Figure 9.13 Create Link). The MUCH system is particularly useful for
writing with reuse. To this end two particularly strong features have been
incorporated into the MUCH system :

• the capability to import documents prepared in an SGML-like for-

mat into the MUCH representation, and
• the ability to generate traditional documents from the MUCH sys-
tem

MUCH supports tools for importing textual documents in standard

markup languages and builds hypertext where the outline is used as a
hierarchical semantic net, and the text under an outline heading is indexed
using its heading. The document generation capability is based on a tra-
versal algorithm which performs a extended depth-first traversal of the
hypertext document (see Figure 9.14 Traversal System).
S o ftw a re R e u s e Tools 169

Figure 9.13-C reate Link: The outline is on the left. Paragraphs that are attached
to the nodes appear on the right when the user selects an item from the windows
on the left. The user has elected to create another link and is about to enter rel-
evant information in the small, ‘pop-up’ window in the center of the screen. (Note
that links have types).

m ucha Edit- D ocum en t

If-nuch Into I Update [HcafogL-oyh'Icid
J VUC IA User G jb e
” VUC 1A Sj/stem A c m m tm c n
Dugs T cuid
S uegsstior D>;
G ooal M essages
"Val Iok Welcome To The MUCH System
J DEMONSTRATION
A M id el Qtjl .C^L ialratativ.e ...tur.ft.'jr.ft.li.a.A-OlBaut
‘F/liCHflji ^
IISF-GHI
* Or Hahn a
m *Thesai.iu
* O rgirivfi
Create Link
" Omr.fi M
” V I10-1/At Nndp : mi :>i
> Rynl And
*RiydMn Targcl Node: iversityj
iiiii '' hV IVjc P l a « A fter:
lfeX
MRm
' E .tu ciliu r L in k T y p e : D _ D o a jX i< x t
' Div.amlji
' S.r-vyx = D ead End:
' P yns
Exjnf.lbv
CRE A T E LINK

m m

The MUCH system allows a user to take existing documents and cre-
ate new documents based on these. The user selects a start heading and a
level to which a depth-first traversal should proceed. New links can be
created and certain links may be defined as dead ends so that the traver-
sals can generate documents with significantly different outlines from
any currently in the library. The reorganization efforts in MUCH aim at
providing different views of the same library according to users’ specifi-
cation. Thus the result in some sense can be seen as a draft of a new doc-
ument, and users can readily modify the structure and the contents of the
draft with the MUCH authoring facilities.
170 Chapter 9

Figure 9.14-T raversal System : Here the MUCH outline system can be seen,
and options available to the user for manipulating the outline, are shown. T hese
allow the user to control which of the types of links between nodes that exist in
the text should be followed.

ttiueh.i Edit D ocum ent ..,

imjch I Jpriatf* M UCHAUscr_Ci*te

T MUCHA U ser G lide
= MUCIK AulhDr’s Guide ISM!
D jgs Fourd
S jg g eslicn Dox 1nnidvi ■M
rw*'•
: uhiKbcoc
G lota r/eu sa g es
Traversal Options
= Mail Do*
: DCMONi_ "ATIOf' t] |
A \ 1rd=!l FnrCrllai ^ N n H e : um±
MHTkayvera j .. ....
TftswiOJ’i !....
C n g rif v » A .ip rft-ir|L*e Im i :
: Oanr.=> MnrJpl
5 fir ml A nd
5 R l'jri MnrJpl I Aatliur:
: MIVcc
j Date YYfaM/DD f - 1i T./UM./DDl: _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ i
' Si v;j >. Pa{.v
■j Key Wuuls:
* G&H p ifjd r = e f r Tufnnuatinn: SfU^hoc I_ _ _ _ _ _ _ _ _ _ _ Credit/ j
' Plar v
E.xitnplvv DistribirtiDn:
* p a. i..1isia. d
' MUCH=M
* MUCH Brcciure GENERATE OUTLINE CANCEL
■"C O -G roup

U i

SoftC lass
The SoftClass project was funded jointly by Canadian research granting
agencies and Tandem Corporation (Mili, 1994). The project aimed to
enhance software reuse for distributed management software and priori-
ties hinged upon two alternative goals:

• reuse existing software, and

• to develop object-oriented software.
Software Reuse Tools 171

In SoftClass, the term ‘software component’ refers to software prod-

ucts at all stages of development, including requirements and design.
Repackaging
One focus of the SoftClass project was the repackaging of documenta-
tion. This repackaging relies on:

• a tool called SoftText that uses a theoretical model of technical

writing to extract a skeleton software architecture and
• a simple automatic indexer—called Softlndex—that matches parts
of the document to specific vocabularies to support later retrieval.

The representation of software components in SoftClass is similar to

Practitioner’s questionnaires. Indexing terms belong to predefined (or
computable) semantic hierarchies (i.e., taxonomies), and support various
retrieval algorithms.
In SoftClass, all software component descriptions are instances of
description templates or categories (somewhat like the PRESS
Questionnaires). In general, for a given development methodology, there
is one category for each type of component (e.g., process versus data) and
for each level of development. Categories are themselves arranged in a
class hierarchy to take advantage of similarities between categories. Each
category is characterized by:

• a set of relevant attributes and their semantics,

• a set of permissible component categories, and
• a set of permissible generic internal relations.

When defining instances of the category, developers are automatical-

ly prompted for mandatory attributes but have to explicitly bring up
optional attributes. If an attribute is shared between a component and its
sub-components, its values are automatically filled for the subcompo-
nents. If an attribute remains invariant across development stages, its
value is automatically filled for subsequent level descriptions. The
SoftClass project particularly considered the step from a pre-design or
analysis stage to the design stage. For example, the 'purpose’ of a soft-
ware module remains the same at the analysis or the design level. It suf-
fices to specify it for the analysis level.
172 Chapter 9

Alternatives were explored in order that SoftClass’s database could

be ‘populated’ with descriptions of existing software components from
various sources. The two alternative source were:

textual documentation and

CASE tools export files.

The information contained in these sources is complementary.

Textual documentation is destined for human consumption and contains
prosaic descriptions that are not found in export files. Export files from
CASE tools contain structural information that is missing or hard to
extract from textual documentation.
Extracting SoftClass-like descriptions of software components from
other CASE tools’ export files is fairly simple, and can also be an aid in
extracting relevant sections from textual documentation and assigning
them the right attributes. However, because of the relatively recent foray
of CASE tools into software engineering practice, and because most of the
early CASE tools offer little beyond drawing capabilities, the project
team had to expend considerable effort trying to extract structured
descriptions of software components from textual documentation alone.
To aid in this they developed the tool SoftText, that extracts a skeleton of
software architecture from textual documentation into SQL.
SoftText
Software document outlines reflect:

• the structure of software being documented (decomposition/aggre-

gation and component-attribute relationships),
• the structure of development tasks, and
• various taxonomies (e.g., a taxonomy of attributes and a taxonomy
of component categories).

The extraction algorithm relies on a categorization of outline headings

and a categorization of the relationship between outline headings. With
this information, SoftText can reconstruct a skeleton of the software
being documented and extract the relevant pieces of text in the core of the
document (see Figure 9.15 SoftText Extraction).
Software Reuse Tools 173

Figure 9.15-SoftText Extraction: Analyzing this docum ent and having identified
‘Function’ as an attribute name, and ‘HLQS’ a s a software com ponent name,
SoftText knows that ‘Function’ is an attribute of ‘HLQS,’ and that the text immedi-
ately following section 1.1 is the textual description of the value ‘Function’ for
HLQS.
1. HLQS System
1.1 Function
HLQS provides a high-level interface

When documentation standards are closely followed—modulo lexi-

cal variations which the tool is able to handle—all section headings and
component names can be unambiguously categorized. Additional heuris-
tic rules are used to ascertain the categorization of section headings as
component names. Once two hierarchically adjacent section headings
have been characterized, there is often only one possible interpretation for
the relation between the two.
SoftText takes as input MS-Worddocuments in text format, and pro-
duces a file of batch commands (in Smalltalk) to SoftClass to create the
extracted components and assign them textual attribute values. SoftText
is able to recognize that a component is a subcomponents another of com-
ponent. However, it does not elicit the exact relationships between them.
Such relationships are extracted from export files produced by
PowerTools(PowerTools is a CASE tool from Iconix Software Inc.),
when they are available, including their graphical layout for the purposes
of the graphical interface. In Softclass a simple automatic indexer is
implemented that matches textual descriptions to a list of keywords.
SoftText complements the extracted information with CASE tools export
files, when such files are available.
Transformations
Support for transforming reusable components is also embodied in
SoftClass. In addition to issues of component classification and retrieval,
attempts were made to answer three questions :

1. Given that no component was found that closely matches the

requirements, which combination of components (and in what
combination) might satisfy them, if any?
174 Chapter 9

2. Given the (partial) description of a desired software component

(presented as a query to the software components library) and the
closely matching description of a retrieved component, which
transformations should be applied to the retrieved component so
that it satisfies the desired requirements?
3. Given that a transformation has been applied to a retrieved com-
ponent at a given development stage (e.g., analysis), which trans-
formation^) should be applied to its subsequent level descriptions
(e.g., design)?

Focus on these problems was motivated by empirical data suggesting

that developers are quick to fall back on developing from scratch when a
reusable component requires non-trivial modifications (Woodfield et al,
1987). The first problem can be seen as a retrieval problem, and provides
the basis for bottom-up development. An exact solution to this problem
is impractical, if not theoretically impossible, although heuristic methods
can be developed that provide potential solutions. The second problem is
very difficult to deal with but can be dealt with to some extent. Methods
to do this aid in dealing with the third problem.
SoftClass supports data definition facilities that promote the reuse of
data objects. At the representation level, data objects are treated in the
same way as process objects: they have attributes, components, and an
internal structure. However, they have one special attribute, ‘Operations,’
whose value is a list of protocols, each containing a list of related process-
like software components that operate on the data object. In SoftClass,
the inputs/outputs of process-like objects are represented by attributes.
The keyword value of such attributes is the ‘type’ of the input/output. A
process-like component that appears in the ‘Operations’ of a data object
must have that object as a type for one of its inputs/outputs. In addition,
data objects support sub-classing whereby a data object inherits both the
components and the attributes of its ‘super-object.’
At the analysis level, the category Data-Object is used to describe
application-dependent data objects, such as ‘Customer File,’ or ‘Product
Inventory.’ Attributes include things such as ‘Update Frequency’ and
‘Access Authorization.’
At the design level, two categories were defined, one for generic,
application-independent data structures, called GenericDataStructure,
and one for application-dependent data structures called simply
DataStructure. Instances of GenericDataStructure include things such as
‘List,’ ‘OrderedList,’ or ‘HashTable.’ These have generic names for com-
ponents and operations (e.g., ‘GetFirstElement’). A DataStructure is
Software Reuse Tools 175

created by mapping a DataObject to a GenericDataStructure. For exam-

ple, ‘Customer File’ would be represented at the design level by mapping
its analysis level representation to the GenericDataStructure ‘HashTable.’
The mapping involves:

• mapping the application-meaningful attributes and components of

the analysis-level DataObject to the names of attributes and com-
ponents of the GenericDataObject, and
• mapping analysis-level operations to the operations of the
GenericDataStructure.

Part of the latter is done automatically based on the mapping between

names of components and attributes. The dual inheritance structure for
data objects distinguishes between application semantics and
design/implementation semantics, which are traditionally mixed in
object-orientation, with adverse effects on the clarity of designs and the
reusability of classes. This structure is also referenced by a program
design language compiler to validate manipulations on data objects.
SoftClass is a transformational software development tool. Software
is developed by starting with more or less formal specifications, leading
to some form of program code which is executable, or can be executed.
The process of transformation is not completely automatic and the user
may be prompted to choose the most applicable transformation at a cer-
tain point in the transformation process, if the knowledge SoftClass has
is incomplete. SoftClass uses mappings to record development transfor-
mations. For those development transformations that can be automated,
the mappings are given in a functional format, and when triggered, auto-
matically produce the target descriptions. For those development trans-
formations that require developer intervention, the mapping is recorded
after the fact. In either case, a developer is able to predict the effect of
local changes at one level of the development process on successive lev-
els. SoftClass implements a trace of the evolution of software through
various development phases. The trace is made from a sequence of map-
pings that echo the transformational process.
Related System
DRACO is another reuse system, like SoftClass,which interacts with and
supports the developer during the transformational process (Neighbors,
1989). DRACO is designed to capture and reuse analysis information,
rather than lower-level information, such as code modules. A processor
accepts high-level descriptions of the desired program and generates the
176 Chapter 9

code. Designs for a particular domain are expressed in a formal way, lead-
ing to an understanding of the inputs/outputs and processes. DRACO is
based upon domains and involves three new human roles in the software
development process :

• application domain analyst - a domain expert who can identify

common constituents in the requirements of several systems in a
domain, or problem area. His or her job is to define the objects and
operations important in that domain.
• domain designer - specifies different implementations for these
objects and operations in terms of the other domains.
• modelling domain analyst - similar to the application domain ana-
lyst but is more concerned with which of these domain require-
ments have proven themselves general to several areas of interest.

Once the DRACO domain is large enough, new systems can be built
from the existing component information. This is software concept level
reuse but this can then be transformed into code. The system has many
domains, organized hierarchically and some of which contain executable
information to allow the transformation of code to take place.

A User Interface Generator

Approaches to reuse may be classified as compositional or generative.
Compositional approaches support the bottom-up development of sys-
tems from a library of available lower-level components. Much work has
been devoted to classification and retrieval technology and to the devel-
opment of automated systems to support this. Generative approaches are
application domain specific; they adopt a standard domain architecture
model and standard interfaces for the components. Their goal is to be able
to automatically generate a new system from an appropriate specification
of its parameters. The Fourth Generation Languages used in the commer-
cial world can be considered an example of generative reuse. Such
approaches can be highly effective in very well understood domains, but
significant effort is required to develop the initial model.
Application generators accept specifications of desired application
characteristics and generate application products. By example, a genera-
tor supporting interactive construction of graphical user interfaces might
allow the direct specification of user interface abstractions, such as menus
and buttons. An application generator typically manipulates rather high-
So ftw a re R e u s e Tools 177

level constructs and allows the user, in a sense, to readily reorganize the
components into a new product. In this sense the application generator is
a reuse tool. On the other hand, some would argue that an application
generator is basically another piece of software and not a reuse tool. The
remainder of this section describes a graphical user interface generator
and treats it as an example of a reuse tool.
The main overall requirement of a user interface is ease of use. In
several ways this can be seen as a subjective thing, though there are sev-
eral sets o f guidelines to help developers. One o f the main needs when
designing an interface is for consistency (Nielson, 1989). Consistency
should exist at many levels, from window to window in a program, from
program to program on a platform and so on. If all the gadgets (a func-
tional part of the interface, like a button or scroll bar) work in the same
way, then the user should be able not only to transfer skills from gadget
to gadget, when used for the same thing, (e.g., all scrolling windows have
the same sort of scroll bars, whether they scroll text or graphics) but also
when faced with a new interface item, will be able to predict what it does
by the gadgets it uses. This also reduces potentially costly mistakes which
users make. Furthermore, consistency relates to code reuse, as the same
code can be used to ensure that all functions of a particular type behave
identically.

Figure 9.16—G raphical U ser Interface Exam ple: This show s the standard Motif
file selector.
PUKH ID s e le c t io n popup

F i It-cr-
^ c © /F c r n b -k ,hy=fcook-,‘emac:=±:ook-,T:tfPE33ErtC.-iV’s*

J ir e 'j ’ zr i a© Fi la ©
d :r
/■c,3 / fo r n ^ /h H = b .o o < /c n o = jb o o -:y F n P = i-± !n U 'c/ _ ► c n o io b o o <
o r « 3t / , h y = b o o s / * e n o ^ 5 b o o v r f l P i r :B f l C ■ V b o z ^ i h y p i r T o ..s i
l^/iiy-lllHK/HlIrl =".| ll ll I _f--

m m
na s:
j5lcc3.icn
/oa/Kcrrib^hM^ook^crtoc3took-,T-flPt-ifcflU<^JS ]
C an cel
I °K I I m m
178 Chapter 9

A ‘widgef is a construct used in the building of user interfaces and

contains several gadgets. The Motif file selector (see Figure 9.16
Graphical User Interface Example) a compound widget, it is built up from
several other widgets, two text widgets (‘Filter’ & ‘Selection’), two
scrolled text window widgets (‘Directories’ & ‘Files’) and four buttons
(‘OK,’ ‘Filter,’ ‘Cancel’ & ‘Help’). The code for the text widgets, windows
and buttons has been reused to create this widget. If users wish to manu-
ally edit the ‘Filter’ field, they know that they must click on it with the
mouse button to type, from their experience with other text widgets. This
means documentation for these widgets can also be reused, since the
information explaining, for example the action of the scrolled window,
can be the same anywhere that a scrolled window is used. The user does
still have to learn how the actions of the buttons and clicking on text in
the scrolled windows allows them to select a file, but once that knowl-
edge is acquired it is applicable whenever a file is to be loaded or saved
with this file selector, in this program or any other Motif complaint
program.
The benefits to reusing widgets include less tangible gains. The pre-
dictability of the interface gives users a feeling of confidence. If the orig-
inal interface specification used to design the widgets is well designed
and 'pretty,’ then all consistent interfaces are also likely to be so. Some
aspects of consistency are cosmetic, such as fonts and colors, but most are
to do with functionality.
Developers are eager to reuse interface widgets not just because of
the direct benefits of consistency, but also for other reasons. Developing
good user interfaces is a complex and time consuming task. The code for
even some of the fundamental objects such as a scrolled window may
involve many, many lines of complex code. The benefits of reuse are
more obvious, and the ability to reuse is more tangible. Not reusing in a
user-interface is often noticeable to users. If windows look different or do
not function in the same way as other windows, then users will quickly
notice.
Reuse in interface development is made more automatic because of
interface development toolkits on the marketplace, for example
Microsoft’s Visual BASICfor Microsoft Windows, and Hewlett Packard’s
Interface Architectfor X Window. These are different in many ways but
the basic principle is the same in both. The developer creates an interface
visually using high level constructs. All code is automatically generated
by the package using the specification drawn by the user on the screen
and selected from menus. The user writes only code that is domain
Software Reuse Tools 179

specific, the rest is generated from reusable templates and code segments
by the system.
Interface Architect is a software package by Hewlett Packard for the
creation of X Window applications. It allows the user to create interfaces
which use the international standard widget set of Motif, with very little,
if any actual code having to be written by hand. Interfaces are created by
selecting items from menus and drawing on the screen, the interface
being drawn as it will look on the screen when completed. Then the user
can attach text areas, buttons and so forth to that window by selecting the
desired items from menus and dragging out their area. Each of these items
can be edited to move them, change fonts, indicate how it behaves when
activated, and so on. The developers can add their own code to the vari-
ous buttons so that when a button is clicked a program is executed. This
is in stark contrast to usual methods of creating these interfaces, which
involve writing many hundreds of lines of code.
Interface creation is typically complex but unless something special-
ized or complex is needed a developer can use Architect to create an
interface without having to learn anything about the actual physical code
needed to perform any task such as opening a window, thus allowing
them to concentrate on the actual application-specific segments. Once the
interface has been designed, it can be automatically generated. Architect
generates stand-alone C code. Developers never need to directly manipu-
late the generated source code. Instead the constructs can be loaded into
Architect and manipulated graphically.
Generic components can be created. It is possible to define parts of
the interface, such as the title of a window, using variables. The actual
value used at run time (and thus the text that is displayed) is the value of
the variables when the call is made to create the window. This feature is
described in Hewlett Packard’s Architect documentation as a reusable
parametric component. It means that if similar dialogs are needed for a
group of tasks only one need be defined uniquely, the others can be
acquired by modifying the values.
As well as creating programs, users can create partial interfaces, thus
a developer could create a set of reusable higher level components, which
would be of widgets similar in level of functionality to the file selector
(which is already predefined) and load them into Architect whenever they
are needed. Also Architect provides for reuse by allowing graphical user
interfaces to be added to existing command line driven UNIX programs
quite simply.
180 Chapter 9

E p ilo g ue
CASE tools support systematic software engineering and facilitate reuse
processes. This chapter has emphasized two such tools, namely
Practitioner and SoftClass. A user interface generator has also been pre-
sented as an example of another kind of reuse tool.
The Practitioner and SoftClass systems emphasize domain analysis.
Each helps the user analyze software-related information and encode that
analysis into a computerized-representation. Some of the analysis may be
automatically done. Retrieval in the Practitioner system is based on word
searches, thesaurus searches, or hypertext browsing. SoftClass supports
retrieval of software descriptions from queries that are partial descrip-
tions. The authoring of new software or software-related documents is
supported by collaborative, hypertext authoring tools in Practitioner and
transformational processes in SoftClass.
An application generator is a very different type of reuse tool.
Hewlett Packard’s Interface Architect is a user interface generator. It has
been described in some detail to illustrate the domain model and the
assets which application generators need and benefits of consistency and
efficiency they allow.
Chapter 1O
C ase Studies

The major barrier to reuse is often claimed to be managerial or organiza-

tional, in the sense of organizing people not organizing information.
Accordingly, a study of technological tools for organizing, retrieving, and
reorganizing information can only directly address the smaller part of the
reuse problem. Managerial models have been introduced in Section 1 of
this book but a proper appreciation of those models depends on real world
examples or case studies. This chapter presents those case studies. The
key issue in this chapter is how companies manage their people in order
to achieve software reuse. As part of the Practitioner Project (described in
the previous Chapter) work was done at a commercial partner and is also
described in this chapter.

S u c c e s s f u l Com m ercial C a s e s
The following brief sketches illustrate the potential benefits of reuse
(GTE, 1992a). The companies tend to be large and several are dealing
with military applications. Later in this chapter detailed managerial
mechanisms of the corporate giants IBM, HP, and Motorola are
presented.
The Toshiba Fuchu Software Factory produces software using a stan-
dardized life-cycle model. This factory produces process control software
products. At Fuchu, the use of metrics has been recognized from the start
and reuse has been measured since 1977. A fourteen percent gain in pro-
ductivity has been achieved annually. 'Promote Reuse’ is a company
motto, and reuse is fully supported by the management. A large library of
reusable software items has been developed, and it is standard practice for
181
182 Chapter 10

every project to review possible candidates for reuse at the start and
throughout a development project.
The GTE Asset Management Programme has been based on a proto-
type system developed at the University of California at Irvine. This pro-
totype was redeveloped by GTE and resulted in a successful transfer of
technology. At GTE, the aim was to support reuse of any asset with the
emphasis on software. The production system developed by GTE held
over 200 COBOL components. GTE found that in 1987, they achieved a
reuse factor of 14% and saved $1.5 million.
Raytheon Missile Systems recognized the redundancy in its business
application systems and instituted a reuse program. In an analysis of over
5000 production COBOL programs, three major classes were identified.
Templates with standard architectures were designed for each class, and
a library of parts developed by modifying existing modules to fit the
architectures. Raytheon reports an average of 60% reuse and 50% net
productivity increase in new developments.
NEC Software Engineering Laboratory analyzed its business appli-
cations and identified 32 logic templates and 130 common algorithms. A
reuse library was established to catalogue these templates and compo-
nents. The library was automated and integrated into NEC’s software
development environment, which enforces reuse in all stages of develop-
ment. NEC reports a 7:1 productivity improvement and 3:1 quality
improvement.
Bofors Electronics had a requirement to develop command, control,
and communications systems for five ship classes. As each ship class was
specific to a different country, there were significantly different require-
ments for each. To benefit from reuse, Bofors developed a single generic
architecture and a set of large-scale reusable parts to fit that architecture.
Because of a well-structured design, internal reuse, and a transition to
modern CASE tools, Bofors experienced a sizeable productivity
improvement in the number of lines of code generated per hour.
Universal Defense Systems in Australia develops Ada command and
control applications. The company began its work in this business with a
reuse focus, and has developed a company-owned library of 400 Ada
modules comprising 500 thousands lines of code. With this base, the
company developed the Australian Maritime Intelligent Support Terminal
with approximately 60% reuse, delivering a 700 thousand line system in
18 months.
Case Studies 183

Practitioner and the ABB S te el Works

The Practitioner case study is concerned with reuse within a Steel Mill
control system. Field studies in this domain were done with Peine-
Salzgitter Steel Works and Asea Brown Boveri (ABB). ABB implements
control systems for steel mills and wanted to establish a work process to
improve the quality of software, minimize the risk involved in the pro-
duction of new software, provide more flexibility when requirements
change, and allow the reuse of software components from earlier projects.
The American Association of Iron and Steel Engineers (AISE) has
studied the role of software systems in steel mills. For steel makers the
problems are in general the same as for other software projects, the need
to cut costs and maintain quality. The AISE set up a study and identified
that reusing software was very desirable in steel mills. Their original aim
was for portable programs (ones developed for one system could easily
be used on another), but doing this without changing the software was not
always possible (Cartwright, 1985). AISE identified the problems with
reuse as being :

• no single methodology to support reusability among disparate

application areas
• lack of techniques to provide reliable means of storing and retriev-
ing reusable software
• lack of adequate documentation for reusable software, and of
means to identify its function
• lack of structuring principles applied in the design of software
holding back reuse of functional designs
and with regard to the steel industry
• lack of management commitment for financial and technical sup-
port required to develop reusable software
• need for software library development and management
• need for educating software engineers in the steel industry about
reuse methods and benefits
• need to impose and enforce reusability guidelines on outside soft-
ware developers that supply the steel industry.

A big problem when upgrading software in a steel mill control sys-

tem is that the original system that is to be upgraded was probably writ-
ten 20 or so years ago and nobody truly knows the old programs in any
184 Chapter 10

detail. Also expectations of software now are much greater than they
would have been 20 years ago. An example of the life-span of these sys-
tems is that at ABB one of the steel mill lines was first made operational
in 1963, enhanced in 1975 and again in 1985, this line has always been
computer controlled. The Practitioner Project aimed to find a way of
reusing at least some of the concepts that this software addressed.
Several studies of steel mills and steel mill processes were analyzed
and combined to form a set of concept models or questionnaires to
describe processes in the ‘Hot Mill Rolling Area’ of the steel mill. This
formed the domain analysis necessary to form a useful model of the steel
mill, the processes involved and the materials transformed by these
processes. The Practitioner Project built on the results of AISE.
Questionnaires were produced to 'provide a high level conceptual view’
of the control systems in various areas of the plant, for example 'Hot
Rolling Line Roll Management Systems’. These questionnaires both
complemented and augmented existing documentation about the system
and planned systems.
Experiments were carried out in-house by the Practitioner Developers
and at ABB with the Practitioner tools. Two sets of experiments tested the
functionality of PRESSTIGE. In one experiment, a C software package
amounting to 2,800 lines of code was redocumented using questionnaires.
The entire functionality of the package was documented in question-
naires. Filling the questionnaires took most of the 240 hours spent on the
task. Users complained that some aspects of the concept model were
either irrelevant or unimportant.
After an introduction into the concepts underlying Practitioner and
the tools, two engineers performed tasks related to three major areas:

• thesaurus use and maintenance, using the thesaurus tool,

• locating questionnaires, using the CCL tool and the browse tool,
and
• the use of questionnaires for offer preparation in response to an
actual call for tenders.

The preparation of a tender for a project was chosen for the purpose
of demonstrating the reuse process, as it provides a short illustration of
reuse, while at the same time bearing enough resemblance to the design
process to make realistic use of the Practitioner methods and tools. The
engineers were impressed with the functionality of PRESSTIGE, and
especially the browse tool which they felt was a powerful instrument to
list relations between objects in the database. However, they felt that
Case Studies 185

PRESSTIGE lacked tools to navigate directly through questionnaires

without going through the thesaurus, suggesting hypertext technology as
a natural extension. All participants raised concerns about the tools
response time - an implementation detail - but more fundamentally, about
the cost of building questionnaires for a given application domain.
While ABB was not dissatisfied with the Practitioner tools, ABB has
not continued to use the tools. The cost of building a domain model via
the Practitioner questionnaires was greater than the benefits which ABB
realized. ABB remains committed to encouraging reuse in its world-wide
operations but will rely less on new tools and more on managerial inno-
vations.

IBM R e u s e
Most major companies have quality management programs. IBM’s qual-
ity management approach has as a major element the increased reuse of
valuable assets such as software, designs, and experiences to prevent
redundant development and maintenance efforts. In the late 1980s, IBM
launched a worldwide campaign to implement reuse formally into the
processes of its internal operations.
Significant accomplishments have been made within IBM since the
early 1980s in reuse technology. Sites such as Boblingen, Germany,
Houston, Texas, and Poughkeepsie, New York have participated in this
work. Part of the effort to formalize the management of reuse in IBM can
be traced to the work in Boblingen on building blocks. Subsequently the
IBM Corporate Reuse Council was established. The Council established
broad communication channels. These took many forms, including
newsletters, a ‘starter kit’, and electronic bulletin boards (Tiro and
Gregorius, 1993).
A focal group called the Reuse Technology Support Center was
formed in January 1991. Its responsibility was to coordinate the reuse
effort within IBM, provide consulting to technical organizations, and pro-
vide funds for tools and assets. In addition, reusable parts technology cen-
ters were established. As writing reusable software costs more initially
than other software, management support is needed to make that invest-
ment possible.
The application of reuse at IBM was recognized to occur at different
levels. The implementation of reuse in a business area entails exploiting
opportunities for software reuse across multiple contracts or products. For
project-level reuse the key activity is the establishment of a project reuse
186 Chapter 10

team leader. The leader participates in all of the project reviews and must
be aware of external sources for reusable components.
Implementing reuse for a site requires additional coordination. A site
champion is given broad coordination responsibilities. A common library
of reusable parts is established. The primary focus of the IBM reuse pro-
gram is to establish reuse across an entire site. Different sites within IBM
have taken different approaches to populating their reuse libraries. Some
examine their current development efforts and identify and build reuse
candidates, while other sites solicit donations.
When the IBM Reuse Technology Center was formed, it targeted five
sites for support during the first year. By 1993, 30 sites world-wide were
involved with the Center. The best programs showed savings in the mil-
lions of dollars and reuse accounted for 25 percent of the components in
a software product. There have been cases where the finely-tuned data
abstractions provided by the building blocks exhibited better performance
characteristics than custom-built data structures. These projects have ben-
efited from the reduced maintenance costs as well as the improved per-
formance gains.
Few major breakthroughs are necessary to exploit reuse. Certain
attributes of software make software easier to reuse, but these are not nec-
essary for reuse. IBM experience shows that reuse can be accomplished
successfully in existing products with existing techniques and knowledge.

The IBM B o b lin g e n E x p er ie n c e

At the IBM system software development site in Boblingen, Germany,
the first reusable parts center was established in 1987. The objective of
the parts center is the production of highly generic reusable software
components for worldwide use within IBM (Wasmund, 1993).
Steps
The Bobligen approach followed 5 steps: 1) define the goal, 2) determine
critical success factors, 3) define required activities, 4) validate plan, and
5) execute activities. The goal was to establish a well-defined reuse pro-
gram within two years that would shorten development time, increase
reliability of products, and increase the extent of reuse. Brainstorming
contributed to the determination of critical success factors. The goal was
seen to have aspects of trading. In other words, for assets to have multi-
ple applications, it is necessary to establish a trading infrastructure to link
Case Studies 187

customers and suppliers. The elements of a marketplace are derived from

the fact that suppliers offer parts and customers require parts.
To store and advertise the parts to be traded, a repository for holding
the parts as well as their description is needed. Traders must also trust the
quality of the parts. As quality is often loosely interpreted, IBM preferred
to use the concept of certification level. This means a guaranteed com-
pleteness and defect rate of a part. Additionally, the purchaser of a part
wants some maintenance assurances. Some kind of accounting is required
to record exchanges and associated costs and savings.
Overall, the determination of critical success factors identified the
following factors: motivation, education, requirements for parts, offering
of parts, part library, quality criteria, maintenance, progress control, and
accounting. To increase motivation, incentives were introduced as an
activity. A part library could initially be a simple list, but communication
channels are needed to make known and accessible this library. As the
library grows, structured methods and tools to support the library are
needed. For certification levels, the lowest was 'as-is’ for software that
was not designed to be reusable but might be of use to someone. The
medium level certification indicated a part that can be reused without
additional explanation. Maintenance changes to software must be accom-
modated by the library. Education is important at IBM. An appropriate
curriculum addressing all aspects of reuse was created.
Validating the Plan
Validating the IBM plan for reuse involves itself several derived activities
including:

1. modify development processes,

2. run incentive program,
3. establish communication paths,
4. apply standards,
5. find sources for parts,
6. establish curriculum, and
7. have supporting tools.

In modifying the development process, the first modified phase is the

requirements phase. As a result of the reuse analysis, the estimated
amount of code for a system is divided in the requirements phase into
product-unique code and reused code. This separation eventually leads to
188 Chapter 10

a list of requirements for parts. This kind of requirement allows for prop-
er subsequent monitoring of progress in reuse. The state of reuse is col-
lected in every development step.
Maintenance effectiveness for reused parts is gained by redefining
the appropriate process step such that error reports of customers can be
quickly routed to the owner of an erroneous component. More and more
products should be composed of building blocks owned by different orga-
nizations rather than created new each time. To exploit the economic
attributes of reuse, new accounting methods are needed. Experiences at
IBM shows that there is a lack of progress in determining the value of a
reusable part and of availability of flexible charging mechanisms between
organizations.
The IBM experience with modifying processes indicates that imma-
ture processes are not appropriate to modify. With maturity measured on
a scale from least mature to most mature, a good starting point for modi-
fication of processes so as to better suit reuse was deemed to be a process
in the middle of the least to most mature scale. Even at this one can not
expect the staff to initially change their day-to-day operations.
The implementation of the process modifications is time-consuming
and ideally one would have many years to slowly adapt an organization
to a new emphasis. However, the IBM reuse goal was to reach significant
results within two years. Accordingly an accelerator was needed. IBM
adopted incentive programs for reuse. The provider of a reusable part gets
credit depending on the size and usage of the part, and the user gets cred-
it for integrating available parts. The award program at IBM Boblingen
also is consistent with existing award schemes in its schedule and empha-
sis on quality, and rewards for usage of unmodified code only.
Considering the benefits of reuse, the incentives are a relatively low-cost
investment.
The third activity in validating the plan concerns the communication
paths. Several communication channels were deemed important at IBM,
including personal communication, electronic bulletin boards, and data-
bases. Personal communication always proves to be the most important
channel when working with representatives of product areas. This person
should be recognized as a competent professional and be able to support
exchange of information germane to reuse objectives. Bulletin boards are
also heavily used for reuse communications.
In the initial phase of reuse, when the repository of parts is small, a
simple list of these parts is circulated around the site. Later as the repos-
itory grows in size, a database is used. IBM developed a sophisticated
database for corporate-wide storage and retrieval of reusable parts for
Case Studies 189

internal use. It is similar to a literature database, which is anyhow a reuse

database of documented experiences. Searching simple lists for reusable
parts works very well for fewer than 500 parts. String search can be eas-
ily used to find items in the list. While sophisticated databases are valu-
able when more than 500 parts are available, the IBM experience shows
that even for a large-scale repository that users benefit from the avail-
ability of simple lists of available parts.
The fourth reuse activity concerns standards and measurements.
Experience shows that covering multiple sites by the same standards
requires coordination from a central body. IBM established the Reuse
Technology Support Center for this purpose. The most important guide-
line from this Center says how to measure the number of reused lines of
code. Financial and productivity calculations can be derived from this
measure of number of reused lines of code.
Counting the number of reused lines of code is not always a straight-
forward process. At IBM, source instructions from a reused part count
one, independently of how many times one calls or expands the part
(Caruso and Hancock, 1993). The choice of using a subroutine versus a
macro should not be made to artificially increase the perceived number of
lines of reused code. In one actual example, a project reported 11 thou-
sand lines of reused code. Closer inspection revealed that 5120 line of the
11 thousand came from one macro. The original code contained the 10-
line macro and a ‘Do’ loop: Do i := 1 to 512
MACRO (i).
However to optimize the loop it was unrolled to yield: MACRO (1);
MACRO (2);

MACRO (512).
The reuse report therefore contained 512 source instructions and
5120 reused instructions, but does not fairly represent the degree of reuse.
In finding sources for reuse, IBM Boblingen had the advantage of
multiple existing sources. As previously noted, electronic bulletin boards
are a popular medium of exchange about reusable parts. While these bul-
letin boards have the disadvantages of'as-is’ usage without certification
of parts, they are attractive to staff. A reusable parts center was also con-
structed. Finally, as new software is developed it is reviewed by a reuse
board for spin-offs that can be contributed to the reusable parts center.
A curriculum for helping people understand and employ reuse was
designed. The concept of reuse was best introduced in the course of tran-
sition from third-generation language to object-oriented technologies
because object-oriented technologies have many reuse characteristics.
190 Chapter 10

Support tools should be available for reuse. IBM identified three par-
ticularly important tool types:

• a repository for reusable parts,

• a source code configuration management tool to support integra-
tion of reusable parts into products, and
• a code counting tool to count reused source instructions.

These tools should be integrated. However, presently these tools are

not fully integrated, and this lack of integration inhibits the diffusion of
reuse.

Figure 10.1-Fingertip Reuse: The figure show s two fingers walking across a
book.

Execution
Two extreme modes of inserting new technologies are the grass-roots and
the edict approaches. IBM used both. Edicts quickly generate some
results. However, experience showed that acceptance by staff of the
Case Studies 191

methodology is not necessarily obtained by the edict approach. Grass-

roots projects requires patience on behalf of the funding bodies. While
incentives are inexpensive, IBM experience showed that only people who
already have some affinity to a method will be further motivated by
incentives.
The constraints of development organizations to deliver products to
market in the shortest possible time does not allow room for additional
efforts to produce generalised software. The production of building
blocks is therefore the responsibility of parts centers. The scope of the
parts center may be of various types. At IBM Boblingen the library is of
the horizontal type and provides general-purpose building blocks usable
in almost any application, such as queues. A vertical type of library was
developed and maintained at IBM in Rockville, Maryland. The vertical
approach requires that parts be available which are of higher abstraction
than needed for the next product release.
At IBM Boblingen the first step in technology transfer was to teach
and distribute information about reuse methodology and parts. This step
did not actually lead to the application of the new methods. A second step
of advice and consultation was added. The decision to get reusable parts
for product development happens during the design phase. Therefore con-
sultation was offered to projects in the design phase. This offer was wel-
comed but not really used. In many projects, design happens very infor-
mally and interactively and consultation does not readily fit into this
mode of work. Thus IBM introduced a third step, called fingertip reuse
into the technology transfer process (see Figure 10.1 Fingertip Reuse).
Fingertip reuse includes the availability of a tool with which a designer
can look for reusable parts within seconds, just when it comes to mind.
Otherwise, the threshold of asking for consultation proved too high.
The metaphor of 'let your fingertips do the walking’ which has been
popularized through advertising for Yellow Pages is appropriate to soft-
ware reuse. The Yellow Pages are accessible within moments at most
offices and homes and users know how to instantly find something which
would otherwise be time-consuming to find. As a result of its efforts in
reuse, IBM Boblingen was able to triple its reuse rate within 12 months.
However, increasing financial and administrative independence of com-
pany divisions may lessen opportunities for reuse. The application of the
Critical Success Factors method helped the planning and implementing of
a reuse strategy, but the execution of the activities required iterative
readjustment.
192 Chapter 10

An IBM R e u s a b l e Parts Center

Prior to the 1980s, reuse of code across project borders at IBM seldom
took place. No organizational structures supported cross-project commu-
nication, and the lack of a common design language farther impeded
communication. The code that was written had too many references to
global variables.
The IBM Boblingen parts center was started in 1981. In the begin-
ning the goal was to have an integrated software development center that
supported the reuse of parts. Investigations into reusable design showed
that common structures exist in the areas of data structures and modules.
Developers were subsequently encouraged to write software that would
allow components to be added to the reuse library. Existing products were
scanned to identify replicated functions. A problem of too many global
dependencies became apparent. Data abstraction became attractive.
In 1983 a project was started to explore data abstraction for a network
communication program. Seven abstract data types, called building
blocks, were written that represented a third of the total lines of code. Due
to the good experiences with abstract data types, a reuse model was con-
structed for it. The model showed the importance of information hiding,
modularity, standardization, parameterization, and validation. The pro-
gramming language PL/S primarily used at IBM at that time was not
strong in these features. Therefore a language extension was developed
on a second pilot project. The building block language extension BB/LX
follows the model of generic packages of Ada.
Building blocks in BB/LX are readily tested. IBM experience has
proven the quality gains to be significant. In one project, the quality of the
building-block code was about 9 times better than the rest of the code. In
another completed, building-block project, no errors were found during
the entire test cycle o f the product (Bauer, 1993).
As more building blocks were produced, tools for the library became
more important. Tools for creating, compiling, and testing building
blocks were provided. An online library with a catalog aided in selecting
the required building blocks.
The expectation that with BB/LX the developers would write their
own building blocks was not realized. Instead there was increased
demand for building blocks from the parts center. A project in 1984 led
to a library for which all building blocks have:
Case Studies 193

• consistent and complete interfaces,

• common terminology, and
• hierarchical implementation.

A comprehensive catalog of reusable abstract data types was provided.

Subsequently, building blocks in C++ were investigated. As C++ was
naturally much better suited for reuse than PL/S, the development of the
building block library in C++ did not require as much time as for PL/S.
In August 1991, the first release of the library for C++ became available
within IBM. By the end of 1991, 57 projects with 340 programmers were
already using the C++ building blocks. Users seem more comfortable
with the C++ than the PL/S building blocks. For both languages, few
developers use abstract data types as if they were a usual part of the pro-
gramming language. This makes support in selecting and applying build-
ing blocks necessary.

HP R e u s e
Hewlett-Packard (HP) has been engaged in software reuse since the early
1980s (Griss, 1993). Early work included the development of libraries of
software components written in the BASIC language and more recently
the development of libraries in object-oriented programs. Some of these
libraries have been widely distributed within HP and some provided to
the outside. At the end of the 1980s HP established a corporate-wide
reuse strategy. This lead in the early 1990s to the successful application
of reuse on a larger scale and the development of further software
libraries.
The HP corporate reuse strategy involves a core team of software
reuse experts with additional people working on assignments with sever-
al HP pilot projects. HP is divided into several large divisions, such as the
printer division, and unlike some corporations, HP is not building a sin-
gle corporate-wide reuse library. Rather each division creates reuse pro-
grams and products customized to their needs. The core team works with
the different divisions to help them exploit reuse. The core team develops
economic models, coding guidelines, educational handbooks, and gener-
ally consults with the divisions. The core team focuses on domain-spe-
cific approaches to software reuse and has developed a domain analysis
methodology for HP.
A study of reuse practice at HP has made it strikingly clear that the
impediments to improving software reuse are predominantly nontechni-
194 Chapter 10

cal and socioeconomic. When confronted with their first reuse failure, a
division should pursue an incremental improvement process. For a reuse
program to be effective, the specific inhibitors likely to affect it must be
identified. To better visualize these inhibitors, HP divides these factors
into the following categories:

• people factors include culture, motivation, management, training,

and skills,
• process factors include domain, economics, and standards, and
• technology factors include tools and languages.

Once the inhibitors are identified, solutions can be tried.

The most effective reuse programs concentrate on the identification
and development of a small, high-quality set of needed, useful compo-
nents, and make sure that the users of those components know about
them. This small library of less than 100 components can be handled
largely on paper in terms of the catalog and the distribution of informa-
tion about it. Large libraries of poor-quality components with complex
library system interfaces are not wanted. In this way, significant levels of
reuse can be achieved in any language with very little tool support. From
this base, the reuse effort can grow.
For many kinds of software development, reducing time-to-market
can be more important than direct cost reduction. Missing a market win-
dow can result in a loss of market share. A six-month slip in market intro-
duction in a five-year lifetime product can lose one-third of the potential
profit. Under these circumstances, investing in reuse may be the best way
to allow subsequent reduction in product development times. For exam-
ple, one of HP’s instrument divisions was able to successfully produce the
application software for a new product in less than six months. The divi-
sion general manager asserted that without their prior investments in
reuse which allowed them to achieve 80 percent reuse in their software
product, that they would have not been able to meet their time schedule.
For embedded firmware products, recovery from defects shipped in
the product can be devastating. Increased cost for field service or product
exchange can destroy product profits. An estimate based on data gathered
at one HP medical division shows that a rework cost due to a firmware
error can easily exceed $1 million. HP’s peripheral and medical divisions
consider reuse as an approach to significantly improve quality and thus a
sound investment in reducing long-term costs.
Typical manufacturing organizations expend a significant amount of
money to select and qualify vendors and parts. Engineers are then
Case Studies 195

required to design new products using these preferred parts. In one HP

software project this manufacturing approach to parts acquisition was
applied to the design of a real-time database system. The approach result-
ed in a 25 percent saving in total project cost.
In 1992 HP Laboraties (the research division of HP) initiated a com-
prehensive, multidisciplinary software reuse program. While the library
metaphor has guided much work in software reuse, HP Laboratories is
exploring an alternative metaphor to the library. Typically, in the library-
centered reuse approach, software code libraries are intended to attract
users who have a system design and want a tailorable part. The HP
Laboraty metaphor is called domain-specific kits and corresponds to the
commercial children’s toys from LEGO Systems, Inc., called LEGO
building blocks. The LEGO metaphor suggests parts that fit together and
exhibit ease of use. Over the years, the LEGO Systems building blocks
have evolved from a small variety of simple generic parts to a rich fami-
ly of kits. Kits for spacecraft, for farms, and other domains exist. Each
system comes carefully packaged with instructions for how to use it and
may sometimes contain frameworks, such as a space platform. The HP
Laboraties approach to software reuse exchanges the library metaphor
with the domain-specific kit metaphor. The domain-specific kit includes
components, frameworks, glue languages, generic applications, tools,
environments, and processes (see Figure 10.2 Kit).

Figure 10.2-Kit: In the domain-specific kit, com ponents are placed within a
framework and connected with glue.
Components Framework

Application
196 Chapter 10

HP’s HP-VEE system supports the construction of instrument sys-

tems and allows engineers to connect virtual instruments together.
Components are selected from a palette and assembled using tools and a
visual glue language to make complete programs that can then be imme-
diately run. HP Laboraties is exploring numerous domain-specific reuse
kits, such as a software bus kit. The Laboraties then work with particular
divisions to pilot test the utility of these kits.
One way to design a software factory based on the kit approach is to
consider inputs of user needs and purchased software parts into the fac-
tory (see Figure 10.3 Kit Factory). Kit developers than take these two
inputs and develop reuse kits from them. Kit users than work with the kits
to develop a rich range of software applications.

Figure 10.3-Kit Factory: The two inputs on the left go through kit production and
kit use inside the factory before applications result.

Software Factory

Motorola R e u s e
Until the 1990s Motorola was primarily a hardware producer. From the
beginning of the 1990s the company committed itself to becoming a
premier producer of software also. The role of reuse in this multi-year,
Case Studies 197

transitional project can be described as a first-phase, grass roots effort and

a second-phase, top-down effort.
Grass Roots Phase
Technical advisors to Motorola recommended that software reuse become
a fundamental practice at Motorola. As is often the case in a company
considering a new strategy, a reuse taskforce was created. The task force
set various guidelines particularly ones on education, motivation, and
metrics. Finally the task force was transformed into a reuse working
group (Joos, 1994).
Corporate culture at Motorola dictates that major changes be driven
from the bottom up rather than the top down. Thus Motorola did not man-
date software reuse but wanted the software engineers in the various divi-
sions of the company to drive the software reuse effort. The corporate
reuse working group consisted of fifteen engineers who represented the
entire Motorola software community. The group concerned itself primar-
ily with education. Five person years were invested in offering reuse
workshops to the Motorola community.
While the reuse workshops were enthusiastically attended and gener-
ated much favorable comment, the net impact of this grass roots approach
was negligible. Motorola’s middle mangers were reluctant to adopt soft-
ware reuse because of the up-front costs and slow return on investment.
Top Down P hase
The Chief Executive Officer of Motorola responded to the difficulties of
the grass roots approach of the software reuse working group by assign-
ing two senior managers to an indoctrination or top-down effort that
includes funded pilot studies. One of the pilot studies was run by top
management at Motorola’s Israel facility and was based on a cash incen-
tive scheme. In one example the reuse of a program saved $15,000 in
engineering costs and a bonus of about $1,000 was divided among the
engineers involved.
To encourage software engineers to share their software components,
the program awards $100 for each approved component that is added to
the database of reusable parts. Each time a software component is
retrieved from the database for reuse, an additional award is given. This
award is, at least, 5% of the estimated savings that use of the component
brings. The developer receives 40% of the award and the reuser 60%. The
Israel group of 150 software engineers has through its cash incentive
scheme become the premier example of software reuse at Motorola.
198 Chapter 10

CIM-EXP
CIM-EXP Limited is a typical small enterprise consisting of 10 pro-
grammer-engineers working on different research and development pro-
jects (Kovacs, 1997). Some of the projects are one-of-a-kind to serve spe-
cific industrial needs. In these one-of-a-kind projects, any kind of stan-
dardization is very hard and complicated.
Other projects employ standards and reuse, but the projects are a
challenge to manage due to the specificity of the tool set. Most program-
ming is done in C and C++ and various computer-aided software engi-
neering tools are used along with the programming language. The CIM-
EXP projects tend to address communication and networking problems,
and the design of real-time control systems for flexible manufacturing
systems.
One of the approaches to reuse is based on faceted classification of
reusable components. Reuse is valuable when components can be found
that fit into new system needs. The basic approach is to classify part of
the design for reuse by strictly using the facets of the classification lan-
guage to describe all documents and components of the software life
cycle. The advantage to this was that the employees developed a certain
familiarity with the classification and could use it fairly easily. The prob-
lem has been that not all facets apply to all assets. The range of assets that
CIM-EXP uses is so wide that the classification system is neither too
broad to be useful or so specific that it only partially applies to many
assets.

Ep ilogue
The construction of domain models and libraries that support software
reuse has occurred in numerous organizations. The costs of developing
and maintaining the libraries are high and only systematic, reuse-orient-
ed management of the software staff leads to long-term benefits exceed-
ing cost. This chapter has documented several experiences of software
reuse.
At ABB the sophisticated Practitioner tool set and its domain model
methodology was not attractive enough for ABB divisions to be willing
to further invest in the tool set. The challenge is to fit into the work flow
of software engineers. For new reuse efforts this fit may require simple
tools.
At IBM, fingertip reuse has proved critical to user acceptance. If soft-
ware engineers must consult with the corporate or division reuse
Case Studies 199

librarians in formalized ways, the engineers will not bother to follow the
reuse plan. With fingertip reuse, a designer can look for reusable parts
within seconds, just when it comes to mind.
The HP experience is consistent with that of ABB and IBM. HP
found that the most effective reuse programs concentrate on a small,
high-quality set of useful components, and make sure that the engineers
know about this small library. At Motorola a cash incentive scheme has
proven most helpful to reuse. Again and again the conclusion is that care-
ful focused management of incremental change is the key to reuse.
C h a p t e r 11
Courseware R euse

Courseware is computer-based learning material and a kind of software.

Typically the courseware exploits full features of hypermedia. One syn-
onym for hypermedia is interactive multimedia (Rada, 1995). Multimedia
contains more than one media. Hypertext is a particular instance of hyper-
media which is devoted to textual material, although it may contain pho-
tographs, tables, and such.
To what extent can existing courseware be reused to expedite the pro-
duction of new courseware? For many years courseware authors have
tried to determine the factors which influence the efficiency of course-
ware development. Reusable, instructional templates within authoring
tools were identified as contributing to efficient courseware authoring
over 15 years ago (Avner, 1979). As the availability of multimedia
courseware components has increased, the attractiveness of building and
exploiting libraries of this material has grown. Several large internation-
al projects have recently focused on developing tools for such libraries
(Chen and Rada, 1994) and on populating such libraries (Margiotta and
Picco, 1993).
Despite the reduction in cost of hardware and improved functionality
of authoring software, the development effort required to produce hyper-
media courseware is still substantial. In the aerospace training sector, one
company spends about 400 hours in developing each hour of training
material. The inclusion of high quality sound, animation, or video can
mean that developing a course from which students gain 1 hour of train-
ing time will require 800 hours from the authors of the courseware.
Developing courseware is very expensive.
The main methods for estimating hypermedia courseware develop-
ment include educated guesses, industry averages, and formulas
201
202 Chapter 11

(Marshall et al, 1994). Educated guesses have proven particularly unreli-

able. Industry averages vary widely from circumstance to circumstance.
The Cost Estimating Algorithm for Courseware (CEAC) uses a compos-
ite model to estimate both courseware development time and cost
(Barnes, 1992). The model uses both course-independent and course-
dependent parameters. For instance, course-independent parameters
include ‘overhead rates’ and Tabor rates.’ Course-dependent parameters
include ‘instructional sophistication’ and ‘availability of existing lecture
material.’
Libraries o f media are being made available for reuse in various pro-
jects. For instance, the University of Bristol has produced a videodisc
with 36,000 biomedical images. Copyright of the images remains with
the donors of the images. The images can, however, be freely reused for
teaching and learning purposes within educational establishments for
non-profit making purposes. A catalogue of the material is available and
can be searched electronically (Williams and Hammond, 1994).
In a film, the production cost of a single frame often costs over $300.
Amazingly this ultraexpensive footage is only used once. Experience has
suggested that the probability of finding and buying the right image(s) to
fit into a movie is so low that producers would rather make their own
footage from scratch. Several efforts have been made to build video
libraries which could be reused. The MIT Media Laboratory experiment-
ed with repurposing footage from the soap opera Dallas for interactive
replay. The experiment failed because this apparently multithreaded soap
opera was too tightly structured to be repurposed. The Laboratory is now
exploring new tools to support video reuse (Goldman-Segall, 1993).
This chapter will first describe standards for courseware that are
intended to support reuse. Then two systems that support courseware
reuse are presented. One was developed for a small company, the other,
for a large company. The features are widely different, as one might
expect. Finally, large libraries of educational software modules are intro-
duced.

C o u rs ew a re S t a n d a r d s
Courseware components can be reused when appropriately classified and
embedded within environments that have standard interfaces. Standards
have been developed by the aviation industry that standardize what these
components should be like so that such reuse can be facilitated.
Course Reuse 203

The aviation standards for courseware recommend guidelines for the

interchange of the elements that occur in courseware. These elements
include:

• Text,
• Graphics,
• Video,
• Audio, and
• Logic.

The standard recommends the use of authoring systems able to export

and import courseware elements in standard formats. Specifically, the
authoring system must be able to:

• Export and import all basic elements to individual files in standard

industry formats.
• Export and import lesson logic to a text representation.

The recommended formats for courseware elements emphasize the

common ones. Logic elements can be stored in one or more plain text
files per lesson. The text files may contain programming language code,
a scripting language, or standard generalized markup language-tagged
text. The content, in whatever format, must be comprehensive and clear
enough to enable a person with a good understanding (of the scripting or
markup language) to reproduce (without any other information) the
exported courseware completely.
Files can be used to describe a course’s content and structure. The
level of complexity determines the number of files required and the
amount of information required in each file. The following list briefly
describes the contents or purpose of several of the files:

• Course Description File: Information about the course as a whole

including a textual description of the course, and general makeup
of the course—the number and type of elements.
• Course Structure File: The basic data on the structure of the
course, including how the elements are organized.
• Objectives Relationships File: Objectives have complex and vari-
able relationships to other elements of a course. This file defines
all of these relationships.
204 Chapter 11

Files are the most common data structure in computer science and by
asking that the courseware structure be represented in files, the standards
developers have reached to the lowest common denominator among the
target audience, as standards developers are expected to do.
In the past, authoring systems made the courseware author and stu-
dent user a captive of the authoring system vendor. If the customer want-
ed to manage a set of students in a class, he had two choices:

• Design his own management system with his authoring system

tools, or
• Purchase a management system from the same vendor who sup-
plied the authoring system.

In either case, the management system works only for course content
from a single vendor. This is fine, until the customer acquires course
material prepared with a different authoring system. Standards should
promote interoperatibilty (AICC, 1997). Interoperability means the abili-
ty of a given management system to handle lessons from different origins.
It also means the ability for a given lesson to exchange data with differ-
ent management systems.
There are two ways to enable interoperability of management with
lesson delivery:

1. Lesson launch: The management should have a standard approach

to lesson initiation.
2. Communication-. The management should have a standard
approach to providing information to the lessons and receiving
information from the lessons.

Interoperability works as follows:

• The management system creates a file containing the data neces-

sary to start-up a lesson.
• Once the lesson is initiated, it reads the data file created by the
management system.
• The lesson system must create a file containing data to be passed
back to the management system so that the management system
can update its student performance data and make the next assign-
ment.
Course Reuse 205

• When the student leaves the lesson, the lesson system updates and
completes the file of information for the management system.
• The management system reads the lesson-to-management file,
updates applicable student data, and determines the next student
assignment or routing activity.

Management system and lesson system communication is two-way.

The management system sends information to the lesson when it begins.
The lesson sends information to the management system when the lesson
ends.
A standard for the virtual classroom concerns the management of the
students in the classroom. The standard describes how a student’s perfor-
mance should be tracked. This tracking information must be possible to
extract from the virtual classroom system that collects it. The models of
intelligent tutoring include a student model, a pedagogy model, and a
domain model. The student performance information could be seen as
part of the student model, but now collected by the teacher to manage a
classroom of students.
Rather sophisticated courseware systems have been developed that
purport to support reusability of courseware components. These would
include, for instance, the LeamingWorks systems. LeamingWorks
(Goldberg et al, 1997) allows students and teachers to visualize complex
relationships among concepts and software components and to directly
author new modules by building on existing modules. The system is
based on SmallTalk and evidently works well for developing courses
about SmallTalk and for students learning Smalltalk. How well it would
generalize to handling general-purpose educational needs is less clear.

Small C o m p a ny
Integrated Radiological Services Limited (IRS Ltd) is a small company
with seventeen employees that specializes in diagnostic radiology and
authors courseware about radiological safety. IRS Ltd has a large number
of potential reusable components around the office, the majority of which
are not currently being used by courseware developers at IRS Ltd. IRS
Ltd develops its courseware with an authoring package called Toolbook
from Asymmetrix Corporation and decided to develop facilities in
Toolbook to support courseware reuse.
206 Chapter 11

Figure 11.1-E ntry: This screen from the IRS Ltd system shows the Table of
C ontents’ and ‘Media Index' options which the user first faces.

System Architecture
The IRS Ltd system supports librarians in entering material into the
library and authors in accessing material from the library. The authors at
IRS Ltd identified eight types o f material that they wanted the library to
contain:

• Text
• Diagrams
• Photographs
• Graphs
• Tables
• References
• Questions/Answers
• Programs

and considered each type o f material to be a distinct media type. The

material is organized in the library according to media type and to domain
type (see Figure 11.1 Entry). Each reusable component within the data-
base is o f one of the eight media types previously listed. Furthermore,
each component has a textual description associated with it. This course-
Course Reuse 207

ware library also possesses a table of contents which incorporates the

main topics within the field of diagnostic radiology from the table of con-
tents of a book of diagnostic radiology. Each heading in the table of con-
tents may correspond to many reusable components of different media
types.
In developing and maintaining the library several different roles must
be fulfilled, including that of Collector, Populator, and Indexer. The
Collector takes a list of items from the author, finds the actual items, and
gives them to the Populator. The Populator converts the material into a
format which is compatible with the courseware library and then enters
the reusable components into the courseware library. The Indexer is
required to place a text caption with each component that describes the
key concepts conveyed by the component. The Indexer also maintains the
Table of Contents and the list of Media Types. The scenario for retrieval
from the courseware library begins when the author selects the type of
access to the library, i.e., table of contents or media index. On selecting
the media index, the author next selects the type of medium he wishes to
examine. Then he enters keyword(s) which describe the topic on which
he wishes to retrieve components. The computer next searches the com-
ponents of that media type within the library. If the author selects ‘photo-
graph’ from the media index and then enters the keyword ‘bum,’ a pho-
tograph of a bum may be retrieved (see Figure 11.2 Typical Screen of the
Reusable Courseware Library). Authors are also able to retrieve relevant
material from the library by selecting a heading from the table of
contents.
Multiple instances of Toolbook windows can be on the screen simul-
taneously. The author uses one instance of a Toolbook window in retriev-
ing components from the library and another instance of a Toolbook win-
dow in directly creating the new course. Material to be reused is trans-
ferred from the reusable courseware library to the courseware being
developed by the author.
Development versus Exploitation
An exercise was performed to ascertain whether the addition of materials
to the library followed by the development of courseware using the mate-
rial within the library helps to reduce authoring costs. Material which is
not in a format compatible with the courseware library is first converted
into an appropriate format. Text presents itself in a wide variety of for-
mats. Text which is to be reused from documents only available in paper
form may be processed by scanning the text into the computer and using
optical character recognition software. Toolbook possesses an ‘import’
208 C h a p ter 11

facility which allows plain text to be automatically imported. Figures

which are paper-based are also first scanned. For the purposes of this
courseware library, all figures were converted to a bitmap format and then
imported into the library. The populators found the scaling of the images
more time consuming than other tasks, as this often involved trial and
error.

Figure 11.2-Typical S creen of the R eusable C oursew are Library: Image

showing the facilities available during retrieval of a media type to visit other com-
ponents of the sam e type. The photograph presented in the right half of the com-
puter screen shows fingers with radiation burns.

After the library is ready, the author uses the material within the
library to author courseware. The time taken for the author to do this task
is noted. Hence, the time taken for the author to develop courseware with
the aid of the tool can be calculated and this can be compared with the
time taken for the author to develop a similar piece of courseware with-
out the aid of the tool. The values obtained are substituted into the fol-
lowing relationship:

TA with LibraryMA + Tc Mc + Tp Mp + Tj Mj ? TA aloneMAwhere

* with Library t^ie ^ me taken by the author to develop course-

ware with the aid of the course library in hours;
Course Reuse 209

• is the wage paid to the author per hours;

• T q is the time for the Collecting of material for the Library (P for
Populator and I for Indexer).
• Mq is the hourly wage paid to the Collector; and
• T a Alone ^me taken by the author to develop the course-
ware without the aid of the tool.

At IRS Ltd, the librarian-skilled staff are paid $7 per hour, while the
authors, who are also domain experts, are paid $15 per hour. For the sin-
gle course developed in this exercise, the cost of the author’s time is about
$80 and the librarian costs are about $500. Developing the course by the
author alone costs $240. How many courses of similar size to the one
already developed and such that all components come from the reuse
library would have to be developed before the cost of the library was less
than the benefit o f the library ? The inequality given earlier of

T A with Library ^ A + ^C ^ C + ^P ^ P + ^1 Mj ? T ^ alone ^ A

would be ‘greater than’ for 1 or 2 courses but ‘less than’ for 3 or courses.
The cost of developing the library should include the cost of devel-
oping or acquiring the software for the library. The library software was
developed by one software engineer working with one radiologist at an
approximate labor cost of $5000, which is much greater than the cost of
collecting, populating, and indexing the small amount of material which
this library holds. If this cost of software is added to the previous equa-
tion, the new equation is

^A with Library^A +Software + T^M^ + Tp Mp + Tj Mj ? T ^ alone

For this inequality about 40 courses must be written from the library
before the library proves cost effective.
Media Index versus Table of Contents
The Table of Contents was a useful guide for text retrieval (Rada, 1996).
Unexpected problems occurred when the author tried to use the table o f
contents within the reusable courseware library to retrieve material other
than text, for example, diagrams or photographs. If there was a section
within the book called Introduction, then this would suggest that the text
in this section of the book was introductory. If however, a diagram, graph,
photograph or table was included in this introductory section of the book,
210 Chapter 11

the author could not anticipate the content of the media. The author was
unable to develop courseware using the table of contents alone because
he was only able to effectively retrieve text from the library, and the
courseware which the author wished to develop was multimedia.
The author found the media index easier to use than the table of con-
tents in some ways. The author was able to first decide the medium he
wished to examine and then enter a keyword describing the topic on
which he wished to retrieve material. However, the author was not prac-
tically able to develop courseware using the media index alone, because
he could not get an adequate overview simply by accessing the media
index of what was available within the courseware library.
Results show that neither the media index nor the table of contents
alone are enough to support good recall or precision but together the
media index and table of contents do support effective retrieval (Acquah,
1994). The author found the table of contents index useful as he was able
to see, from the headings in the contents window, what was present with-
in the library. This enabled the author to access easily the text he required
and also helped him to decide on relevant keywords to enter when using
the media index to retrieve text. The author spent the majority of his time
retrieving material using the media index, but used the table of contents
index when he wished to orientate himself. To improve the speed with
which items could be retrieved from the library and thus increase author-
ing speed, both the table of contents and the media index should be
present.
Collecting material which might go into a courseware reuse library is
a major task. At some juncture, this material must be assessed for its true
value to the library and such assessments are themselves difficult. Getting
the material into the proper format for the library is a job for multimedia
which is more complicated than for text. Digitising video, for instance,
requires powerful hardware. Indexing the material for the library is anoth-
er major activity. While some indexing can be done automatically, much
experience suggests that human indexing, while laborious, is important.
With these various costs to acquiring and evaluating material for the
library the challenge of building a large enough library to be useful is
clearly daunting. Furthermore, the contents of the library must be contin-
ually updated and this must be done in close communication with the
needs of the users of the library. In the fast evolving world of hyperme-
dia, new formats themselves are regularly introduced and old ones made
extinct. Maintaining the format converters for this multimedia library is
a technical problem and in a sense easier to handle than the complex
Course Reuse 211

problems of content and user satisfaction, but is nevertheless a significant

problem.
The Toolbook authoring package used for the development of the IRS
Ltd tool was not designed to facilitate the building of courseware libraries
or to act as a database. When building libraries for reusable courseware
components, a standard database should be used to store the artifacts so
that searches can be done quickly and easily. This technical problem was
addressed with the next system to be discussed. More importantly, the
next system explicitly supports collaborative work.

Coordination
The experiences with IRS Ltd system have indicated various important
features of courseware reuse libraries. The conceptual model for the
library and the mechanisms for supporting coordination can be extended.
One project for the training division of a large, Italian, aerospace manu-
facturing company, called Augusta SpA, has produced a particularly
sophisticated prototype courseware reuse system. The overall system is
called Open System for Collaborative Authoring and Reuse of course-
ware (OSCAR).
Reuse Architecture
The OSCAR architecture represents the way in which the OSCAR ser-
vices are organized, what functional level they realize, and what relation-
ship exists between them. To better represent the organization of services
provided by OSCAR and the relationship between them, OSCAR services
have been grouped in layers (see Figure 11.3 The OSCAR Layers).
OSCAR provides the following layers:

• Hardware Platforms: contains all hardware components supported

by OSCAR;
• Operating Systems: contains the operating systems supported by
OSCAR on the various hardware platforms;
• Communication Space: provides services supporting the distribu-
tion of the system and the network management;
• Common Information Space: supplies information management
services relevant to the library;
• Coordination and Reuse Space: this layer provides high level ser-
vices to support coordination and reuse for a courseware library.
212 Chapter 11

Figure 11.3-The OSCAR Layers: Four layers are depicted here. OODBMS
m eans object-oriented database m anagem ent system.

O p eratin g System

H ardw are P latform s

Client workstations represent the user entry point into the OSCAR
system. The OSCAR client workstations are mainly multimedia personal
computers on which library applications run. They also allow access to
shared services such as email, file transfer, and information management.
They can be remotely connected to allow a distant author to get access to
the OSCAR services. The OSCAR server provides multi-user services in
the distributed environment. Operating system services provide the man-
agement of all physical resources of a computer system and establish the
basic execution environment for applications. UNIX serves as the multi-
user operating system. MS-WINDOWS is the reference operating system
for the client workstation.
The OSCAR Common Information Space (CIS) allows different soft-
ware components and different users of the system to share information,
update them consistently, and base their work on the work of others. The
Course Reuse 213

CIS includes instructional objects each of which has an ‘instructional

component’ and a ‘presentational component.’ The objects of the
Instructional Component (see Figure 11.4 Two Components of CIS)
include domain objects which are produced by a Domain Analysis and
Student Modeling objects. On the other hand, the Presentational
Component includes the physical representation of the actual learning
material. The MultiMedia Unit (MMU) is a composition in space and
time of several Monomedia Units (MUs). Examples of MMUs are pic-
tures with captions, but also couples or triples of pictures, pictures with
voice, and so on. A single picture, a text, or a sound sequence are exam-
ples of MUs (see Figure Screen onto Media Units). Of course, there is a
need for an object that specifies how several MUs can be combined in
space and time to make a MMU. Such an object should also be able to
handle small interactions among MUs and diversified exits from a MMU.
This object is called ‘layout,’ and it has been defined as a separate object
to allow an author to present the same MMU in different ways, and vari-
ous MMUs in the same way.
The CIS includes a pedagogical classification schema. This peda-
gogical classification schema functions as a kind of domain-specific fil-
ter between users and the CIS (Persico et al, 1992). A MMU may be char-
acterized by the pedagogical classification schema in terms of attributes,
such as student background, teaching technique, and domain. A flexible
and powerful description and classification schema is necessary for the
purpose of efficient retrieval and reuse of MMUs.
The Reuse Services support both the retrievability and the customiza-
tion of training material. The functionalities offered by the Reuse
Services include conversion tools to reuse material originally available in
a format different from the desired one. With the conversion facility, the
user who is examining a particular monomedia unit may convert that unit
into any of many different formats (see Figure 11.5 Converter).
Coordination Services
The coordination services manage the interdependencies between activi-
ties performed by multiple actors. Components of the Coordination
Service (see Figure 11.7 AME components) include:

• Activities are sets of tasks for achieving a goal.

• Roles specify the responsibilities and duties of people.
• Workspaces contain resources associated with roles.
214 Chapter 11

Figure 11.4-Tw o C o m p o n en ts of CIS: MMU is multimedia unit.

Instructional Presentational

Figure 11.5 -S creen o nto Media Units: This screen dump from the OSCAR sy s-
tem show s som e of the features of the CIS, particularly media units.
Course Reuse 215

Figure 11.6-C onverter: Screen dump from the OSCAR system which presents
information about a particular image or bitmap and gives the user an option to
convert that bitmap into a variety of formats.

• Messages are objects that flow between the role instances associ-
ated with an activity.
• Information Units are used in building messages.
• Rules constrain the behavior of components.

Roles, people, workspaces, information units and messages are rep-

resented as objects and are stored in the Organizational Manual. In
OSCAR the Organizational Manual and other information germane to
coordination are stored in the CIS.
For the development and maintenance of the courseware reuse
library, OSCAR defines several roles and activities. Prominent roles
include collector, selector, populator, indexer, indexing language expert,
and quality assurer. First material for the library must be collected by the
‘collector.’ Then a ‘selector’ decides what of the collected material is of
appropriate quality to go into the library (Rada et al, 1987).
216 Chapter 11

Figure 11.7-AME C o m ponents: The relationships among roles, m essage, activ-

ities, and other com ponents of AME are indicated here.

THE ORGANIZATION

■activity

organizational
manual

message

The populator prepares the material for entry into the library and
physically enters it. This may involve scanning material or converting
formats. The indexers assign index terms to the library. Simultaneously,
the indexers work with the indexing language experts to create an index-
ing language. As the library and its index grows, maintaining the index-
ing language becomes itself a job (Mili and Rada, 1988). The quality
assurer does quality control and specialists on quality are needed to cor-
respond with every other role just mentioned.
For the Coordination Services all intermediate products can be treat-
ed as messages. For example, when an indexer proposes changes to an
indexing language expert, a message is created in the indexer workspace
using a template from the organizational manual. The message records
Course Reuse 217

information about the person who created it, the role the creator was play-
ing, and the time it was created. The indexer completes the message.
The workspace tries to determine which person should deal with the
message next based on attributes of the message. In this case the work-
space forwards the message to the indexing language expert workspace
and tells the indexing language expert role that a message is awaiting
attention. If the message can be processed, the role instance locks it until
the process finishes.
The indexing language expert workspace retrieves an ‘assessment of
proposal’ template from the organizational manual. By default, the per-
son performing the role would fill-in the details in the appropriate infor-
mation unit of the message. However, some of the fields within the infor-
mation unit in the message may be filled-in automatically by the role
agent. After the person or the role agent fills-in the fields, the workspace
unlocks the message and informs the current information unit that it is
complete. At this stage, the information unit triggers its rules which check
the validity of the field values and determines which will be the new cur-
rent unit and which role will process it. The message then routes itself to
the appropriate workspace.
This circuit is repeated until all the information units are completed.
At this point the message is considered complete and the next message is
activated and routed to the appropriate workspace. In this way, indexing
language maintenance is supported by the computer.
The preceding sketch of indexing language maintenance is only a
small part of library maintenance. The ‘reuse assurance role’ monitors the
extent to which authors are using the library. A search librarian helps the
author find material. In the OSCAR scenario, searching and browsing the
CIS is supported by computer programs, but experience suggests that
human assistance would also be important.

Educ ational Object E c o n o m i e s

In addition to the aviation industry, other organizations are concerned
about the standardization of educational technology. Educom is an asso-
ciation of higher education institutions that tries to improve the use of
technology in education. Educom has produced a standard called the
Instructional Management Systems (IMS) Metadata Specification
(Educom, 1997). This specification is directed toward describing learning
resources that are accessible, or perhaps just catalogued, online. The IMS
Metadata Specification consists of three primary parts: a dictionary of
218 Chapter 11

terms, a description of learning resource types, and a system for manag-

ing the Specification. The IMS Dictionary identifies the terms that con-
stitute IMS Metadata. These are the terms that are used to label the learn-
ing resources. IMS Metadata is broken down into fields and correspond-
ing values. All of the proposed available fields are defined in the dictio-
nary and their values are enumerated. These fields include author, cred-
its, interactivity level, learning level, objectives, platform, prerequisites,
price code, user rights, and user support. The hope of Educom is that all
higher education institutions will use this metadata format to characterize
their online educational material. Educom is working with the World
Wide Web Consortium in the introduction of metadata information into
the specification of the World Wide Web itself so that this metadata stan-
dard is conformant with other efforts at standardizing metadata formats
across all web content.
This interest in obtaining wide usage of components across the web
is echoed by other organizations in various ways. For instance, Apple
Corporation has led the way in organizing an Educational Objects
Economy (EOE). This library of reusable objects could be indexed with
the IMS Metadata format to increase the accessibility of the information
to various communities.
An EOE is a community of people working together to improve the
quality and availability of web-based learning materials. Apple, NSF, uni-
versities, publishers, and many others have created a first exemplar EOE
(EOE, 1997) in June 1997. A key part of an EOE is web site technology
that helps empower community members to work together. An EOE web
site must allow members to easily gather, share, and add value to web-
based materials of interest to the community. The technology required to
set up an EOE is relatively straightforward. However, creating a vibrant
community that is actively achieving its goals, and reflecting that activi-
ty through the web site, is a challenging task.
Fundamentally an EOE is a community o f communities; that is, a
community of educators (and learners), developers, and businesses,
focused on the creation and collaboration of educational activities which
include pieces of Java software in them. The EOE is funded by a joint
National Science Foundation and Defense Advanced Research Projects
Administration grant.
The History of EOE
Apple has researched a number of authoring tools but realized that no
matter how good or easy-to-use an authoring tool is, any authoring tool
will only address a certain percentage of the population. Not everyone is
Course Reuse 219

interested in learning to use these tools. Further, while authoring tools can
empower individuals to create educational objects, they do not help an
author answer the question “does what I want to create already exist?”
Because of this, duplication of effort is common.
To address the issues of duplication of effort, lack of organization,
and the (relatively) small authoring community, an on-line community
and searchable resources are needed. From a developer’s perspective, the
EOE can help creators of Java educational applets know what has already
been created and by whom. The EOE is also intended to help educators
and learners access this material and the creators of the Java applets.
Working together, the educators, learners, and developers can collaborate
to enhance existing material and produce new innovations. The EOE
vision relies on a strong, diverse community of users and creators who
form small partnerships to modify something that exists or create some-
thing completely new.
After four months of operation, the EOE had a library of over 1,000
pointers to Java applets, over 25% of which made source code available.
In addition, about 100 people had signed up to be members of the com-
munity. The organizers of EOE believe that over time a whole class of
domain-specific education communities will start to develop around
repositories and directories. Accordingly, the EOE have made the infra-
structure available for download for anyone who’d like to use it to start
their own EOE.
EOE Plans
The EOE started as a directory of freely available resources on the web
with a community of people who are willing to work together to share and
add value to these resources. Nevertheless, long-term EOE encourages
the development of EOE-related businesses and for-profits. Just as
libraries do not put bookstores out of business, but spur demand for books
through a more literate population, the EOE of free resources should
expand the market for “for-fee” educational resources. For example,
teachers who start using the EOE would to be able to know which EOE
objects are associate with chapters in the textbooks that they are using in
their classes. So publishers might provide indices from their textbooks to
be freely available, and for fee web resources that could be augments to
the printed textbook. Meta-data and micropayment systems are part of the
infrastructure that is being developed to support these sorts of
businesses.
The EOE has worked with developers to produce different types of
license agreements for sharing source code. For example, if a developer
220 Chapter 11

wants to use objects from the EOE (perhaps developed at a university)

and incorporate those into a product, a certain license would best meet the
needs of the developer and the university creator of the original educa-
tional objects. The type of license is called an intellectual capital appre-
ciation license and allows source code to be shared, as long as bug fixes
and ports of the original code are shared back with the community.

Ep ilogue
Courseware is a kind of software and courseware reuse problems are a
particular case of software reuse problems. This chapter has examined
two courseware reuse tools and experience with their use. As was the case
for software reuse at IBM, HP, and Motorola, one general impression is
that the tools might be simple to fit into the workflow for initial course-
ware reuse efforts.
A model of courseware development via reuse from a courseware
library has been elaborated. This model has been contrasted to a model of
courseware development without reuse. A major challenge for course-
ware reuse which is not confronted for software reuse in general concerns
the wide variety of incompatible media formats. The challenges of con-
verting courseware components from one format to another have been
largely overcome through the provision of various conversion tools. The
conceptual overview of the library contents has been divided into two
high-level types, namely a media view and a contents view. Neither alone
supports adequate retrieval but both together do.
If a courseware library is developed and is only used by one author to
develop one piece of courseware, then the efficiency of the reuse process
will be very low. A reusable courseware library is most efficient when it
is used to develop numerous courses. As the costs of developing and
maintaining a multimedia courseware library are relatively high, a small
firm might best choose a simple facility and try to quickly realize some
benefit from the system. Larger firms may be able to afford larger start-
up investments in the library. The critical factor in cost efficiency is a
repeated use of the library which will depend in part on the firm’s man-
agement policy.
Chapter 12
Conclusion

Software reuse is an important aspect of controlling and reducing soft-

ware costs and improving quality. Successful reuse depends on both man-
agerial and engineering concerns. The engineering concerns are with the
representation of software assets and their manipulation. The managerial
concerns are with the plans of an institution and with its handling of its
human resources. The costs and benefits of reuse are multitudinous.
Nevertheless currently reusability, when it takes place is usually the result
of informal methods and chance rather than a powerful driving force
behind software development. A reusability driven development method-
ology should be utilized for software, so that existing projects both reuse
existing components and create new components to be reused in future
projects.
The engineering of assets can be viewed from multiple perspectives.
In one view assets are created, managed, and utilized. In another view,
assets are organized, retrieved, and reorganized (see Figure 12.1
Principles of Reuse). In any case, these perspectives must account for
both the activities of people and of assets.

Representations
Traditionally reuse focuses on the reuse of code only. This requires least
effort from the developer and offers the most immediate returns, when
successful. It also has its roots in the component libraries associated with
languages like Fortran, or in systems such as X Windows with its widget
code that implements buttons and windows and is easily accepted by
developers. The code is pre-written, pre-documented and pre-tested.
221
222 Chapter 12

However more than code can and should be reused, if full reuse is to be
achieved. All information produced during the software life-cycle should
be reusable to some extent and tools should be available to the developer
to help him or her in the reuse of this information. Typically, the knowl-
edge used and produced at the earlier development stages of software
tends to be expressed and presented in a human or human manipulate
language, while in the later stages of the development process represen-
tations are closer to, or actually are, computer languages. Neither form is
problem-free for reuse.
Often the software library will not have a suitable component (code
is very specific). Developers may find the component difficult to under-
stand. Any changes other than very minor ones may involve reverse-engi-
neering the component to reach a state where it can be reliably modified.
Often the testing advantage is lost, since the component has to be modi-
fied or is being used in an environment different enough from its devel-
opment domain to warrant retesting.

Industry View
The increased size of the global market increases the potential for the
number of units to be sold. This permits a business to justify increased
capital investment in a product while lowering per-unit price, if penetra-
tion of a large percentage of the now larger potential market can be
ensured. Penetration, though, is crucially linked to being first to the mar-
ket. Software developers, therefore, find themselves in a situation of cop-
ing with the commodity pricing of high-capitalization software with mar-
ket share strongly linked to the speed of introduction. This trend is favor-
able to software reuse because reuse practices support the economical
capitalization of development effort in a manner that can accelerate the
introduction of new products to the market.
Experience in software development has frequently shown that the
challenge to software reuse is less the development of new programming
languages or technologies, but rather the way an organization rewards
software reuse on the part of its software engineers. Motorola software
engineers in one division were given financial rewards for storing assets
in a library and then given significant further rewards each time the asset
was used in another product. Those incentives helped that division
become the premier example of software reuse in Motorola.
Conclusion 223

Figure 12.1-P rinciples of R euse: The software reuse-cycle. Reusable compo-

nents are added to the library system , the 'organization' being performed by an
indexer. On the formulation of queries the system retrieves com ponents and pre-
sents them back to the developer. The developer then modifies or reorganizes
these retrieved com ponents, perhaps retrieving further com ponents if needs
change and adding new material to create a new product.
224 Chapter 12

Projects at 75Mhave involved various sophisticated object-oriented

approaches to creating assets, but one of the most potent conclusions of
the IBM experiences was that tools and methods should integrate seam-
lessly into the work environment. The greatest impact on reuse came
when IBM software engineers could have the reuse library at their finger-
tips—they could easily move between relevant library contents and the
problem solving for which reuse was relevant.
The mere presence of a usable library is sometimes “good enough”
and additional investment in cataloguing mechanisms and search tools
may provide little payback. This argues for purchasing a library tool or
outsourcing a reuse library service and focusing one’s own investment on
the contents of the library rather than the nature of the tool.
There is another side to the industry reuse story. Customers, not just
a company’s own software teams, may want to have access to reusable
software libraries. In the World Wide Web market, Microsoft, Netscape,
and others are trying to gain market share with customers who want to
gain access to reusable code libraries for building interactive web sites.
Having components in standardized languages that can interpolate in
standard ways with various web-related functionalities is important to
such reuse libraries. So some of these software houses feel compelled to
compete in being able to label their products as standard in a way that
befits the generation of customer-accessible reuse libraries.

G o v er n m e n t View
Companies often see their approach to internal software reuse standards
as important to their competitive advantage. Some of these companies
will keep these software reuse standards confidential. Government agen-
cies are more likely to want to share reuse libraries with the public.
Government agencies have played a particularly active role in advancing
reuse standards and libraries that are shared with the public.
By law, United States government procurements are required to be
fair, a virtue valued beyond even effectiveness. In general, government
cannot award a follow-on contract to a company simply because it per-
formed well on the predecessor program—a fair competition among
interested parties is required and the award will be made based on some
combination of proposed actions and estimated cost rather than track
record. In this sort of contracting environment, government has an essen-
tial need to ensure that one contractor can reuse the products of previous
contracts.
Conclusion 225

The U.S. Department o f Defense spends 30 billion dollars a year on

software. The military may buy software from many suppliers and yet
wants what it buys from one supplier to be accessible for reuse by anoth-
er supplier. The military has developed software reuse guidelines that can
be used to standardize contractor performance. One salient such project
from the the Department of Defense Advanced Research Projects Agency
is called STARS.
One o f the key documents from STARS is the Conceptual
Framework fo r Reuse Processes (CFRP). CFRP defines a conceptual
framework for reuse in terms of the processes involved. The framework
is intended to be generic with respect to domains, organizations, eco-
nomic sectors, methodologies, and technologies. The CFRP identifies the
processes involved in reuse and describes at a high level how those
processes operate and interact. The management of reuse is described
within a spiral of plan, enact, and learn (see Figure 12.2 Reuse Cycle).
For instance, in planning one proposes measurements of library assets
and their use. These measures then become integral to the evaluation of a
reuse project and learning how to change the next plan.

Figure 12 .2 -R eu se Cycle: This cycle shows the organizational process of reuse

that involves planning, enacting, and learning from the experience to plan better
for the next enactm ent.
226 Chapter 12

Another STARS document is intended as a planning aid for reuse-

based projects. It provides a set of dimensions for characterizing current
reuse practice and a suggested process performing the characterization.
Both of these STARS documents effectively describe principles, but
implementation details are left to the organizations which want to adopt
STARS. There is a huge gap between the general principles for how an
organization might operate so as to achieve software reuse and the spe-
cific details of a company’s implementation.

C o s t s and B e n e f it s
Reuse may involve significant change to traditional practice, and there
are a number of challenges to overcome in achieving its full benefits.
Making software that is reusable generally requires investment above and
beyond that required for a one-time system. This effort goes into making
the software more flexible, ensuring its quality, and providing additional
documentation. Each organization must make decisions about how the
investment is supported.
Today’s usual contracting methods can create a disincentive for con-
tractors to reuse existing software or to provide software for reuse by oth-
ers. Legal issues arise over liabilities and warranties. Responsibility for
maintenance must be identified.
Reuse should reduce maintenance cost. Because proven parts are
used, expected defects are fewer. Also, there is a smaller body of software
to be maintained. For example, if a maintenance organization is respon-
sible for several different systems with a common graphic user interface,
only one fix is required to correct a problem in the user interface rather
than one for each system.
Reuse should improve interoperability among systems. Through the
use of single implementations of interfaces, systems will be able to more
effectively interoperate with other systems. For example, if multiple com-
munications systems use a single software package to implement one
standard communication protocol, it is very likely that they will be able
to interact correctly—more so than when each package is written by a dif-
ferent company but is supposed to follow the same standard.
Another benefit of reuse is support for rapid prototyping. A library of
reusable components provides an effective basis for quickly building
application prototypes. With these prototypes the software group can get
customer feedback on the capability of the system and revise the require-
ments as dictated by the customer.
Conclusion 227

With reuse on a small scale—for example, use of a library of mathe-

matical functions—the effort saved from a single reuse is not great; pay-
off comes from the widespread reuse that is possible. On a large scale,
entire subsystems, such as an aircraft pilot subsystem, may be reused.
However, the opportunities for reuse of a given component are more lim-
ited. Large-scale reuse can pay for itself even if a component is only
reused once or twice, because of the amount of effort saved.
The effectiveness of reuse will be far greater in some software com-
panies than in others. If a software company or department exclusively
develops one kind of application, for example spreadsheets, then it is in
the interest of that company to build staff training around a reuse method-
ology since they will be able to build a library of commonly used spread-
sheet components quite quickly. Here it can be expected that projects will
be able to make use of large numbers of these components. Companies
which have no specialization and deal with a large variety of projects
with few common elements have less to gain from reuse.

A n a lo g y to Traditional Libraries
Software reuse could not have occurred more than about 50 years ago
because there was no software. Document reuse has, however, occurred
for centuries, at least. One domain of document reuse is scientific
research. There reuse by reference is fundamental. A quality research
journal article typically contains citations to about 20 other journal
articles.
A small research team may maintain its own small library.
Investment in this library may include in the first instance the purchase of
subscriptions to some journals. A member of the team may be assigned
on a part-time basis to somehow organize the journals in the library so
that others can find them.
As research teams cooperate and see the advantage to larger libraries,
they may pool their resources. In the extreme case, the national govern-
ment is convinced to establish a comprehensive library. One example of
such a library within the medical domain is the National Library o f
Medicine (NLM) in the U.S.A. NLM subscribes to all 20,000 of the
world’s biomedical journals. A continual and extensive quality assess-
ment of these journals selects the 3,000 best from the 20,000 and every
article within those 3,000 is indexed with about 10 concepts from a the-
saurus (Bachrach and Charen, 1978). The thesaurus itself contains about
100,000 concepts and is maintained by a full-time staff of about 10
228 Chapter 12

people. The indexing section of NLM employs about 400 full-time, pro-
fessional indexers. The results of indexing are distributed world-wide via
paper publications, electronic network and CD-ROM. In short, the
national level effort to maintain a kind of reuse library is a massive effort.
Prior to the summer of 1997, NLM charged users a small fee for hourly
connect time to the online database. Since the summer of 1997 access to
this online library is completely free to anyone in the wold.
The parallels of the traditional library situation to the software reuse
situation are instructive. Software teams that begin a reuse effort will nat-
urally start with a small library. Comparable to the journal article citation
for software might be a call to a program in the library. As the size of the
software library and the number of its users grows, the importance of a
systematic approach to the library also increases. National or internation-
al efforts may ultimately be the most appropriate.
Researchers who use the NLM system may also write journal articles
which would ultimately be indexed in the NLM system. For publicly-
funded, medical researchers a quantitative measure of success is the num-
ber of published, journal articles. For commercially-funded, medical
researchers the objective may instead be to suggest methods or products
which the commercial body can later exploit on the marketplace.
Accordingly, the commercially-funded researcher may be forbidden from
publishing some research results. For instance, a drug company may not
want its researchers to publish work about the new drug which the com-
pany is investigating.
Much software is made by companies that do not want to freely con-
tribute their products to a library for other companies to use. The exam-
ple of national libraries of research literature suggests an approach to
software reuse. The government could require that successful bidders for
a government software development contract would provide the product
to a public reuse library. This kind of approach is being taken by the
American Department of Defense and may be an important step in the
wider acceptance of software reuse methods.

Ep ilo g ue
The US Army finished in 1997 an extensive survey of Army personnel
responsible for software reuse (Army, 1997b). The survey covered the
major areas of Reuse Management, Reuse Education, Domain Analysis,
Domain Implementation, and Reusable Asset Acquisition. These are the
major areas of interest as regards reuse. The results of the study are con-
Conclusion 229

sistent with the experiences of other organizations and are the basis for
the final recommendations of this book.
Many projects reported that they had created a working group to
address reuse-related issues and were using reuse language in Requests
for Proposals. However, overall adherence to reuse management guide-
lines varied widely from one part of the organization to another part of the
organization. The recommendation is for further establishment of con-
nections among projects so that reuse efforts can be further harmonized.
The greatest potential for improvement was documented in the area
of education. Very few employees have received any significant level of
formalized reuse education. However, 70% of staff requested reuse edu-
cation. Extension of reuse education opportunities should be a high pri-
ority.
The results of the domain analysis part of the survey was to highlight
the importance of high-level domain analysis. This domain analysis
should occur not only within an army such as “command and control” but
across areas to highlight opportunities for horizontal reuse—namely,
reuse across areas. Such further domain analysis would be consistent with
the emphasis in software engineering on frameworks or patterns which
require high level domain analysis activities. The areas of the organiza-
tion which show the most overlap in the domain analysis results should
be the most appropriate for reuse across areas.
Within domain implementation, both opportunistic and systematic
reuse activities were reported. To further promote a systematic approach
which contributes to greater cost benefits, reuse needs to be incorporated
earlier in the software development life cycle. This approach must
include varied types of products, such as requirements, designs, architec-
tures, models, application program interfaces, schema, and tests. For each
of these different product types, a common set of reuse metrics must be
developed, documented, collected, and evaluated.
With regard to Reusable Asset Acquisition, an effort needs to be made
to extend the availability of reuse repositories and encourage quality
donations via an incentive program. This will facilitate an increase in sys-
tematic reuse as more products of higher quality and various types are
made available. The increasing availability of information across com-
puter networks, particularly the web, leads to the prediction that the con-
tents of reuse repositories will improve in quality and increase in size.
However, efforts to reduce the cost of acquisitions implies a reduction in
the ability to require reuse features in delivered products. The tension
remains between the desire to get a product finished and the desire to con-
tribute a flexible asset to a reuse library.
230 Chapter 11

This book does not per se provide reusable software assets. It does
provide a kind of domain analysis of the area of software reuse itself.
Furthermore, it serves an education function. The book is available for
free across the Internet. The book is also part of an online course. The
goal of the author is to work with others to build a virtual information
technology college for which reuse will be a fundamental tenet.
Contributors to the Virtual Information Technology College (Rada,
1997) will include students, teachers, and administrators. Additionally,
software developers can contribute to the College by providing software
assets that become part of the College. These assets must be provided in
such a way that they are open to inspection and fit into the domain model
for the College. The infrastructure of the College will be a kind of library
of reusable software modules itself.
The financial incentive for contributing to the infrastructure will be
based on a revenue sharing scheme. The College will be self-financing
and each contributed asset that is used will earn a certain percentage of
the revenue stream that comes to the College. Of course, this same rev-
enue stream has to pay the human teachers and administrators of the
College, but the software is expected to play a very active role in the run-
ning of the College and the developers of such software need to be ade-
quately rewarded. Normally an organization has difficulty in adequately
defining the financial incentive to software reuse activities but this chal-
lenge will be very directly addressed by the Virtual Information
Technology College. Other virtual organizations could follow this same
model.
Students in the College will be able to examine the infrastructure of
their own college to see examples of systematic software reuse. Software
reuse will be a key topic in education in this new college. Students that
graduate from this College will be better acclimated to a culture o f reuse
and will contribute more effectively to reuse within other organizations.
Appendix I
S elected G lossary

A
application domain: The knowledge and concepts that pertain to a par-
ticular computer application area. Examples include battle management,
avionics, and nuclear physics. Each application domain can be decom-
posed into more specialized subdomains where the decomposition is
guided by the overall purpose or mission of systems in the domain.
application engineering: The development or evolution of a system to
meet particular application requirements.
application generator: A software tool that generates software work
products from nonprocedural user specifications of desired capability.
asset: A unit of information of value to a software engineering enterprise.
Assets can include a wide variety of items, such as software life cycle
products, domain models, processes, documents, and case studies.
asset base: A coherent set of assets, addressing one or more domains and
residing in one or more asset libraries.

C
certification: The process of determining to what extent something can be
trusted to satisfy its requirements without error.
chiefprogrammer team: A group of people who work together under the
guidance of a chief programmer with key support from the team’s librar-
ian.
component: Synonymous with asset.
231
232 Appendix I

constructive cost model: An empirical model of software development

effort that is based on several attributes of the anticipated software prod-
uct, such as its size.
courseware: Software for instructional purposes which often includes
multimedia.

D
design: The process of defining the software structure, components, mod-
ules, interfaces, and data for an application system to satisfy specified
requirements.
document: Any information product, such as a requirements document or
a computer program.
document-oriented system: A system in which the integrity of documents
is paramount and their available structure in, for instance, Tables of
Contents, are needed to provide overviews. In such a system documents
are often located by a string search.
domain: An area of activity or knowledge. A number of different classi-
fication schemes have been proposed for domains; some of the classes of
domains that have been identified include: application, horizontal, and
vertical.
domain analysis: The process of identifying, collecting, organizing, ana-
lyzing, and modeling domain information by studying and characterizing
existing systems, underlying theory, domain expertise, emerging technol-
ogy, and development histories within a domain of interest. A primary
goal is to produce domain models to support the development and evolu-
tion of domain assets.
domain engineering: The development and evolution of domain-specific
knowledge and assets to support the development and evolution of appli-
cation systems in a domain. Includes engineering of domain models,
architectures, components, generators, methods, and tools.
domain model: A definition of the characteristics of existing and envi-
sioned application products within a domain in terms of what the prod-
ucts have in common and how they may vary.
domain-specific reuse: Reuse in which the reusable assets, the develop-
ment processes, and the supporting technology are appropriate to, and
perhaps developed or tailored for, the application domain for which a sys-
tem is being developed.
Selected Glossary 233

G
generation: A technique or method that involves generating software
work product from nonprocedural user specifications of desired capabil-
ity.

H
horizontal domain: The knowledge and concepts that pertain to particu-
lar functional capabilities that can be utilized across more than one appli-
cation domain. Examples include user interfaces, database systems, and
statistics. Most horizontal domains can be decomposed into more spe-
cialized subdomains where the decomposition is often guided by charac-
teristics of the solution software.

I
interpretive indexing: The assignment of concepts to a document to indi-
cate its fundamental meaning.

L
legacy systems: Software systems in domains of interest that can impart
legacy knowledge about the domains and feed domain analysis or reengi-
neering efforts to produce domain assets or new application systems.
library: A collection of components, together with the procedures and
support functions required to provide the components to users.
library data model: The information (sometimes called meta-data) that
describes the structure of the data in an asset library.
life cycle: The stages a software or software-related product passes
through from its inception until it is no longer useful.
life cycle model: A model describing the processes, activities, and tasks
involved in the development and maintenance of software and software
related products, spanning the products’ life cycles.

M
methodology: A set or system of methods and principles for achieving a
goal such as producing a software system.
234 Appendix I

‘Not Invented Here’ Syndrome: The situation when developers are

unwilling to reuse software that was developed elsewhere because it was
‘not invented here’. Software engineers enjoy the creative aspects of their
profession, and can feel that these are diminished when reusing someone
else’s software.

O
object-oriented system: A system in which objects and their relations are
paramount. Hierarchical relations are particularly important as they sup-
port inferencing along inheritance paths.
opportunistic reuse: The ad hoc reuse of assets in the development of
software systems using a software development process that has not been
altered to accommodate systematic reuse. In opportunistic reuse, the
developer determines where reuse can be applied to develop a software
system without the organized use of domain engineering products during
successive stages of a software engineering process.
organizing: The collecting, analyzing, indexing and storing of informa-
tion so that it can be easily accessed later.

P
portability: The extent to which a software component originally devel-
oped on one computer and operating system can be used on another com-
puter and operating system.
precision: A measure of the ability to reject non-relevant materials.
process: A description of a series of steps, actions, or activities to bring
about a desired result.
process-driven software engineering: An approach in which software is
developed or evolved in accordance with well defined, repeatable
processes that are subject to continuous measurement and improvement
and are enforced through management policies.

Q
query: A request for identification of a set of assets, expressed in terms
of a set of criteria which the identified items must satisfy.
Selected Glossary 235

R
recall: measures the ability of a system to retrieve relevant documents.
reorganizing: The tailoring of information to suit a new purpose after that
information has been first organized into a library and then retrieved from
that library.
requirement: A condition or capability that must be met or possessed by
a software system or software-related product.
retrieval system: an automated tool that supports classification and
retrieval of assets.
reusability: the extent to which information is able to be reused.
reuse: The application of existing information. In software engineering,
reuse usually involves the application of information encoded in soft-
ware-related work products. A simple example of the reuse of software
work products is reuse of subroutine libraries for string manipulations or
mathematical calculations. A simple example of the reuse of information
not encoded in software work products is consultation with a human
expert to obtain desired knowledge.
reuse-based software engineering: An approach to software-intensive
system development in which systems are constructed principally from
existing software assets rather than through new development.
reuse cycle: One pass through the Reuse Planning, Enactment, and
Learning processes in a particular reuse program.
reuse infrastructure: The collection of capabilities that is needed to sup-
port and sustain reuse projects within a reuse program. Includes tools and
technology; organizational structure, policies, and procedures; and edu-
cation and training.
reuse library: A set of assets and associated services for accessing and
reusing the assets. A library typically consists of assets, corresponding
asset descriptions, a library data model, and a set of services (manual or
automated) for managing, finding, retrieving, and reusing assets. Such
services can include reuse consultation services.
reuse library interoperability: The ability of two or more distinct, hetero-
geneous Software reuse Libraries to dynamically provide access to the
other’s Assets, Asset descriptions, and other available information.
reuser: An individual or organization that reuses assets, reverse engi-
neering: The process of analyzing a computer system’s software to iden-
tify components and their interrelationships.
236 Appendix I

S
software engineering environment: The computer hardware, operating
system, tools, and encoded processes and rules that an individual soft-
ware engineer works with to develop a software system.
specification: A document or formal representation that prescribes, in a
precise manner, the requirements, design, behavior, or other characteris-
tics of a software product.

T
tailoring: The process of adapting products for application in new, spe-
cific situations.
thesaurus: A set of concepts in which each concept may have hierarchi-
cal and associative relations to other concepts. A concept is labeled with
a preferred term. Synonymous or non-preferred terms are also provided.
traceability: The characteristic of software-related products that docu-
ments the derivation path.

W
word frequency indexing: An automatic assignment of words to a docu-
ment based on their frequency of occurrence in the documents.
A p p e n d i x II
References

William Agresti, “Framework for a Flexible Development Process,” New

Paradigms for Software Development, edited by William Agresti, pp.
11-14, IEEE, New York, 1986.
Hanne Albrechtsen, “Software Concepts: Knowledge Organisation and
the Human Interface,” Tools for Knowledge Organisation and the
Human Interface, pp. 48-63, INDEKS Verlag, Frankfurt, Germany,
1990.
Army Reuse Center “Library Tool Demonstration”
http://arc_www.belvoir.army.mil/demos2.htm, 1997.
Army Reuse Center, Reuse Technology Assessment Report for the
Department o f the Army, HQ USAISSC, Fort Belvoir, VA, April 30,
and also at http://arc_www.belvoir.army.mil/, 1997b.
A. Avner, “Production of computer-based instructional materials,” Issues
in Instructional Systems Development, Edited by H.F. O’Neil, Jr, pp.
133-180, Academic Press, New York, 1979.
AICC (1995) “Courseware Interchange Guidelines and
Recommendations” from Aviation Industry CBT Committee
Courseware Interchange, AGR 007, Version 1.0 by Courseware
Technology Subcommittee at http://www.aicc.org/ agr007.htm
AICC (1997) “Computer Managed Instruction Guidelines and
Recommendations” from Aviation Industry CBT Committee
Computer Managed Instruction, AGR 006, Version 1.1 by CMI
Subcommittee at http://www.aicc.org/agr006.htm

237
238 Appendix II

C. Bachrach, T. Charen, “Selection of MEDLINE Contents, the

Development of its Thesaurus, and thelndexing Process,” Medical
Informatics, Vol. 3, N 3, pp. 237-254, 1978.
T. F. Baker, “Chief Programmer Team management of production
programming,” IBM Systems Journal, Vol. 11, N 1, 1972.
James Baldo, Jr., James Moore, David Rine “Software Reuse Standards”
StandardView, 5, 2, pp. 50-57, June 1997.
R. Balzer “Transformational Implementation: An Example,” IEEE
Transactions on Software Engineering, Vol. 7, pp. 3-14, January
1981.
Paul G. Bassett Framing Software Reuse: Lessons from the Real World
Yourdon Press: New Jersey, 1997.
Don Batory, Vivek Singhal, Marty Sirkin, Jeff Thomas, “Scalable
Software Libraries,” ACM SIGSOFT ‘93, Vol. 18, N 5, pp. 191-199,
December 1993.
D. Bauer, “A Reusable Parts Center,” IBM Systems Journal, 32, 4, pp.
620-624, 1993.
T. E. Bell, D C Bixler, M E Dyer, “An Extendable Approach to Computer
Aided Software Requirements Engineering,” IEEE Transactions
Software Engineering, Vol. 3, N 1, pp. 49-60, 1977.
Bell Canada Trillium - Telecom Product Development Process Capability
Model, Bell Northern Research, Nortel, 1994.
James Bigelow, “Hypertext and CASE,” IEEE Computer, pp. 23-27,
March 1988.
T.J. Biggerstaff, “Design Recovery for Maintenance and Reuse,”
Computer, pp. 36-49, July 1989.
B. W. Boehm, “Software Engineering Economics,” Prentice-Hall,
Englewood Cliffs, New Jersey, 1981.
Boeing Company, IBM Federal Systems Company, Unisys Corporation,
STARS Conceptual Framework for Reuse Processes (CFRP'),
Volume 1: Definition, Version 3.0, United States Air Force, Hanscom
Air Force Base, Massachusettes, October 25, 1993.
Boeing Company Reuse Strategy Model: Planning Aid for Reuse-based
Projects, CDRL 5159, Task U03, STARS Program, Contract
#F19628-88-D-0028, July 31, 1993
Grady Booch Object-Oriented Analysis and Design with Applications,
2nd edition, Redwood City, CA: Benjamin Cummings, 1994.
References 239

James M. Boyle, Monagur N. Muralidharan, “Program Reusability

through Program Transformation,” IEEE Transactions on Software
Engineering, Vol. 10(5), pp. 574-588, September 1984.
F. Brooks, The Mythical Man-Month, Addison-Wesley, 1975.
Davide Brugali, Giuseepe Menga, Amund Aarsten “The Framework Life
Span” Communications o f the ACM, 40, 10, pp 65-68, 1997
Bruce A. Burton, Rhonda Wienk Aragon, Stephen A. Bailey, Kenneth D.
Koehler, Lauren A. Mayes, “The Reusable Software Library,” IEEE
Software, 4, pp. 25-33, July 1987.
Gianluigi Caldiera, Victor R. Basili, “Identifying and Qualifying
Reusable Software Components,” Vol. 24, N 2, pp. 61-70, IEEE
Software, 1991.
Brad Campbell, Joseph M. Goodman, “HAM: A General Purpose
Hypertext Abstract Machine,” Communications o f the ACM, Vol. 31,
N 7, pp. 856-861, July 1988.
Lionel Cartwright, “AISE Software Portability Project - Review of Step
2,” AISE Year Book, pp. 94-97, 1985.
J. M. Caruso, D R Hancock, “The business case for reuse,” IBM Systems
Journal, Vol. 32, N 4, pp. 567-594, 1993.
Chaomei Chen, Roy Rada, “A Conceptual Model for Supporting
Collaborative Authoring and Reuse,” Knowledge Organization, Vol.
21, N 2, pp. 88-93, 1994.
Alistair Cockbum, “The Interaction of Social Issues and Software
Architecture,” Communications o f the ACM, 59, 10, pp 40-46, 1996.
National Library and Information Associations Council, Guidelines for
Thesaurus Structure, Construction and Use, American National
Standards Institute, New York, 1980.
N. Delisle, M. Schwartz, “Neptune: A Hypertext System for CAD
Applications,” Proceedings o f ACM SIGMOD International
Conference on Management o f Data, pp. 132-143, 1986.
DoD (Department of Defense) Software Reuse Initiative, DoD Software
Reuse Vision and Strategy. Technical Report 1222-04-210/40, Center
for Software Reuse Operations, Alexandria, Virginia, 1992.
DoD (Department of Defense) Software Reuse Initiative, DoD Software
Executive Primer, Center for Software Reuse Operations,
Alexandria, Virginia, 1995.
240 Appendix II

DoD (Department of Defense) Software Reuse Initiative, Software Reuse

Business Model Technical Report, Center for Software Reuse
Operations, Alexandria, Virginia, 1995.
F. DeRemer, H Kron, “Programming-in-the-large versus programming-
in-the-small,” IEEE Transactions on Software Engineering, Vol. 2,
pp. 80-86, 1976.
Chris Edwards, Nigel Savage, Ian Walden, Information Technology and
the Law, MacMillan Publishers Ltd., London, 1990.
EOE “What is the Educational Object Economy” Educational Object
Economies, http://trp.research.apple.com, 1997.
Educom “IMS Metadata Executive Summary” IMS Metadata,
http://www.imsproject.org/ metadata/MDexec.html, 1997.
Mohamed Fayad and Douglas C Schmidt “Object-Oriented Application
Frameworks” Communications o f the ACM, 40, 10, pp 32-38, 1997
Martin Fowler, Analysis Patterns: reusable object models, Addison
Wesley: Massachusetts, 1997
W.B. Frakes, P.B. Gandel, “Representing Reusable Software,”
Information Software Technology, Vol. 32, N 10, pp. 653-664,
December, 1990.
D. Garlan, R Allen, J Ockerbloom “Architectural Mismatch: Why reuse
is so hard” IEEE Software, November, 1995
Adele Goldberg, Steve Abell, David Leibs “The LearningWorks
Development and Delivery Frameworks” Communications o f the
ACM, 40, 10, pp 78-81, 1997
R Goldman-Segall, “Interpreting Video Data: Introducing a ‘Significance
Measure’ to Layer Descriptions,” Journal o f Educational Multimedia
and Hypermedia, Vol. 2, N 3, pp. 261-281, 1993.
Michael Gordon, Manfred Kochen, “Recall-Precision Trade-Off: A
Derivation,” Journal o f the American Society for Information
Science, Vol. 40, N 3, pp. 145-151, 1989.
C. Green, S. Westfold, “Knowledge-Based Programming Self-Applied,”
Machine Intelligence, Vol. 10, New York, Wiley, 1982.
M. L. Griss, “Software Reuse: from library to factory,” IBM Systems
Journal, 32, 4, pp. 548-566, 1993.
Ralph E Johnson “Frameworks=(Components+Pattems)”
Communications o f the ACM, 40, 10, pp 39-42, 1997
M. Halstead, “Elements of Software Science,” Elsevier, New York, 1977.
References 241

Jean Hartmann, David J. Robson, “Techniques for Selective

Revalidation,” IEEE Software, pp. 31-36, 1990.
Philip A. Hausler, Mark G. Pleszkoch, Richard C. Linger, R. Hevner,
“Using Function Abstraction to Understand Program Behavior,”
IEEE Software, pp. 55-63, January 1990.
K Hayashi and A Sekijima, “Mediating interface between hypertext and
structured documents,” Electronic Publishing: origination, dissemi-
nation and design, Vol. 6, N 4, pp. 423-434, 1993.
J. Heidepriem, “Trends in Process Control of Metal Rolling,”
Proceedings o f the 11th IFAC World Congress, Vol. 11, pp. 138-147,
Tallinn/Estland, 1990a.
Robert R. Holibaugh, Sholom G. Cohen, Kyo C. Kang, Spencer Peterson,
“Reuse where to begin and why,” Proceedings o f Tri-Ada ’89, pp.
266-277, ACM Press, New York, 1989.
IEEE Standards Committee, “IEEE Standard for Software Quality
Assurance Plans,” IEEE, New York, 1981.
IEEE Software Engineering Standards Committee, Strategy Statement,
August 20, 1995.
IMSL “Library User’s Manual 1.0 Edition,,” Houston, Texas, 1987.
ISO “Documentation - Command for interactive text searching (ISO/DIS
8777),” 1986.
T. Capers Jones, “Measuring Programming Quality and Productivity,”
IBM Systems Journal, Vol. 17, N 1, pp. 39-63, 1978.
T. Capers Jones, “Reusability in Programming: A Survey of the State of
the Art,” IEEE Transactions on Software Engineering, Vol. 10, N 5,
pp. 488-494, September 1984.
Rebecca Joos, “Software Reuse at Motorola,” IEEE Software, Vol. 11,
N 5, pp. 42-47, September, 1994.
Gail E. Kaiser, David Garlan, “Melding Software Systems from Reusable
Building Blocks,” IEEE Software, pp. 17-24, July 1987.
Simon Kaplan, Yoelle Maarek, “Incremental Maintenance of Semantic
Links in Dynamically Changing Hypertext,” Interacting with
Computers, Vol. 2, N 3, pp. 337-366, 1990.
Susan Katz, “Glossary of Software Reuse Terms,” NIST Special
Publication 500-222, National Institute of Standards and Technology
(NIST),1994.
242 Appendix II

B. W. Kemighan, R Pike, “The Unix Programming Environment,”

Prentice-Hall, Englewood Cliffs, New Jersey, 1984.
George L. Kovacs, “Software Reuse and Standardization for SMEs—the
CIM-EXP Perspective” StandardView, 5, 2, pp. 58-60, 1997.
C. W. Kreuger, “Software reuse,” ACM Computing Surveys, Vol. 24, N 2,
p p .131-183, 1992.
Rrishnamurthy, Balachander. Practical Reusable Unix Software. John
Wiley & Sons, 1995.
J. Lahore, G. Dworkin, “Information Technology: The Challenge to
Copyright,” Sweet and Maxwell, London, U.K., 1984.
Manfred Lenz, Hans Albrecht Schmid, Peter Wolf, “Software Reuse
Through Building Blocks,” IEEE Software, pp. 34-42, July 1987.
Lim, Wayne C, Managing Software Reuse. Prentice Hall, 1995.
C. Lung, J.E. Urban, “Integration of domain analysis and analogical
approach for software reuse,” Proceedings o f the 1993 ACM/SIGAPP
Symposium on Applied Computing, Edited by E Deaton, K.M.
George, H Bergel, G Hedrick, pp. 48-53, ACM Press, New York,
1993.
Stan Magee and Leonard Tripp, Software Engineering Standards and
Specifications: An Annotated Index and Directory, Global
Professional Publications, Denver, 1994.
U. Margiotta, R. Picco, “An item banking service: pre-project for a
national system of evaluation,” tools, Proceedings o f the NATO
Research Workshop, Editted by D.A. Leclercq, J.E. Bruno, pp. 12-18,
Springer-Verlag, Berlin, Germany, 1993.
I.M. Marshall, W.B. Samson, P.I. Dugard, “Multimedia courseware cost
modelling,” European Cost Modelling Conference ‘94, pp. 27.1-
27.18, 1994.
Yoshihiro Matsumoto, “A Software Factory: An Overall Approach to
Software Production,” Tutorial: Software Reusability, pp. 155-178,
IEEE Computer Society Press, 1987.
G. M. McCue, “IBM’s Santa Teresa Laboratory - Architectural Design
for Program,” Development, IBM Systems Journal, Vol. 17, pp. 4-25,
1978.
Bertran Meyer, Object-Oriented Software Construction, Prentice Hall
International, Hempstead, England, 1988.
References 243

Hafedh Mili, “SoftClass: An Object-Oriented Tool for Software Reuse,”

Proceedings o f TOOLS USA (9 f Santa Barbara, California, 1991.
Hafedh Mili, Roy Rada, Weigang Wang, Karl Strickland, Cornelia
Boldyreff, Lene Olsen, Jan Witt, Jurgen Heger, Wolfgang Scherr,
Peter Elzer, “Practitioner and SoftClass: A Comparative Study of
Two Software Reuse Research Projects,” Journal o f Systems and
Software, Vol. 25, N 2, pp. 147-171, 1994.
Hafedh Mili, Fatma Mili, Ali Mili, “Software Reuse: Issues and Research
Directions,” IEEE Transactions on Software Engineering, Vol. 21,
No. 6, June 1996 .
Hafedh Mili, Roy Rada, “Merging Thesauri: Principles and
Evaluation,’’/E'EE Transactions on Pattern Analysis and Machine
Intelligence, Vol. 10,N 2, pp. 204-220, 1988.
Harlan D. Mills, Richard C. Linger, Alan R. Hevner, Principles o f
Information System Analysis and Design, Academic Press, 1986.
James Moore and Roy Rada “Organizational Badge Collecting”
Communications o f the ACM, 39, 8 pp 17-21, August 1996.
National Bureau of Standards (NBS), Guidelines for Documentation o f
Computer Programs and Automated Systems, FIPS Publication 38,
1976.
J. M. Neighbors, “DRACO: A Method for Engineering Reusable
Software Systems,” Software Reusability, Concepts and Models, Vol.
1, pp. 295-320, ACM Press, New York, 1989 (from the 1984 article
in IEEE Transactions on Software Engineering, Vol. 10).
Jakob Nielson, Coordinating User Interfaces for Consistency, Academic
Press, 1989.
S.H. Oh, Y.J. Lee, M.H Kim, “Knowledge-based software components
for qualitative measurement of DBMS,” Proceedings the 2nd
international conference on Expert Systems for Development, pp. 69-
73, IEEE Computer Society Press, Los Alamitos, California, 1994.
Paramax Systems Corporation, Direction-Level Handbook: Central
Archive for Reusable Defense Software (CARDS), STARS-AC-
04104/001/00, September 24, 1992.
D. Pamas, “The Role of Program Specification,” Research Directions in
Software Technology, Edited by P. Wegner, MIT Press, Cambridge,
Massachusetts, 1979.
244 Appendix II

A Pentland, R Picard, G Davenport, R Welsh, “The BT/MIT Project on

Advanced Image Tools for Telecommunications: an Overview,”
Proceedings 2nd International Conference on Image
Communications, 1993.
D. Persico, L. Sarti, Viarengo, “Browsing a Database of Multimedia
Learning Material,” Interactive Learning International, Vol. 8, pp.
213-235, 1992.
Jeffrey Poulin, Measuring Software Reuse: principles practices and
economic models, Addison Wesley, 1997
Ruben Prieto-Diaz, Peter Freeman, “Classifying Software for
Reusability,” IEEE Software, pp. 6-16, January 1987.
Defense Information Systems Agency (DISA), Domain Analysis and
Design Process, Version 1 Technical Report, 1222-04-210/301.1,
Center for Information Management, Software Reuse Program,
Arlington, Virginaia, March, 1993.
Roy Rada, Hypertext: from Text to Expertext, McGraw-Hill, London,
1991.
Roy Rada, “Hypertext writing and document reuse: the role of a
semantic net,” Electronic Publishing, Vol. 3, N 3, pp. 3-13, 1990.
Roy Rada, George S Carson, Chris Haynes “Standards: the Role of
Consensus “ Communications o f the ACM, 37, 3 pp 15-16, April
1994
Roy Rada, Weigang Wang, Hafedh Mili, Jurgen Heger, Wolfgang Scherr,
“Software Reuse: from Text to Hypertext,” Software Engineering
Journal, pp. 311-321, September 1992.
Roy Rada, Interactive Media, Springer-Verlag, New York, 1995.
Roy Rada, Geeng-Neng You, “Balanced Outlines and Hypertext,”
Journal o f Documentation, Vol. 48, N 1, pp. 20-44, March 1992.
Roy Rada, Barbara Keith, Marc Burgoine, Steven George, David Reid,
“Collaborative Writing of Text and Hypertext,” Hypermedia, Vol. 1,
N 2, pp. 93-110, 1989.
Roy Rada, Joyce Backus, Tom Giampa, Subash Goel, Christina Gibbs,
“Computerized Guides to Journal Selection,” Information
Technology and Libraries, Vol. 6, N 3, pp. 173-184, 1987.
Roy Rada and John Berg “Standards: Free or Sold?” Communications o f
the ACM, 38, 2 pp 22-21, February 1995
References 245

Roy Rada “Systems for Reusing Hypermedia Courseware,” Multimedia

Tools and Applications, 2 pp 53-78, 1996.
Roy Rada Virtual Education Manifesto http://www.gnacademy.org/,
Hypermedia Solutions Limited, 1997
S. R. Ranganathan, Prolegomena to Library Classification, 3rd Edition.,
Asion Publishing House: Bombay, India, 1937.
Charles Rich, Richard Waters, “Automatic Programming: Myths and
Prospects,” IEEE Computer, pp. 40-51, August 1988.
SAIS/ASSET “Asset Source for Software Engineering Technology”
http://www.asset.com/, 1997.
Douglas Schmidt, Mohamed Fayad, Ralph Johnson “Introduction to
Software Patterns” Communications o f the ACM, 39, 10, pp. 36-39,
1996.
Software Technology for Adaptable Reliable Systems (STARS), The
Reuse-Oriented Software Evolution (ROSE) Process Model, Version
0.5, Unisys STARS Technical Report STARS-UC-05155/001/00,
Advanced Research Projects Agency, STARS Technology Center,
Arlington, Virginia, July, 1993.
Software Technology for Adaptable Reliable Systems (STARS),
Organisation Domain Modelling (ODM), Volume I - Conceptual
Foundations, Process and Workproduct Descriptions, Version 0.5 -
DRAFT, Unisys STARS, Advanced Research Projects Agency,
STARS Technology Center, Arlington, Virginia, July, 1993b.
Spencer Ruigaber, Stephen B. Ombum, Richard J. LeBlanc Jr.,
“Recognising Design Decisions in Programs,” IEEE Software, pp.
46-54, January 1990.
Gerard Salton, Michael McGill, “Introduction to Modem Information
Retrieval,” McGraw-Hill, New York, 1983.
C. Saurel, “An Expert System Aiding Development Engineering
Software Packages,” Expert System and their Applications, Avignon,
France, 1985.
SESC Software Engineering Standards Committee, Master Plan for
Software Engineering Standards, Version 1.0, IEEE Standards
Committee, December 1, 1993,
P.M. Senge, The Fifth Discipline, Doubleday/Currency, New York, 1990.
Geoffrey Leslie Simons, “What is Software Engineering?,” NCC
Publications, Manchester, England, 1987.
246 Appendix II

D. Smith, G Kotik, S Westfold, “Research on knowledge-based software

environments at Kestrel Institute,” IEEE Transactions on Software
Engineering, Vol. 11, pp. 1278-1295, November 1985.
Software Productivity Consortium Domain Engineering Guidebook,
Version 01.00.03, SPC-92019-CMC, December 1992.
Ian Sommerville, Software Engineering, 5th Edition, Addison-Wesley,
Reading, Massachusetts, 1996.
Giancarlo Succi, Luigi Benedicenti, Paolo Predonzani, Tullio Vemazza
“Standardizing the Reuse of Software Processes” StandardView; 5, 2,
pp. 74-83, 1997
GTE Government Systems, NATO Standard for Management o f a
Reusable Software Component Library, NATO Communications and
Information Systems Agency, Brussels, Belgium, March 1992a.
GTE Government Systems, NATO Standard for Software Reuse
Procedures, NATO Communications and Information Systems
Agency, Brussels, Belgium, March 1992b.
GTE Government Systems, NATO Standard for Development o f
Reusable Software Components, NATO Communications and
Information Systems Agency, Brussels, Belgium, March 1992c.
J. R. Tiro, H Gregorius, “Management of Reuse at IBM,” IBM Systems
Journal, Vol. 32, N 4, pp. 612-615, 1993.
W. Tracz, “Software Reuse Myths,” ACM SIGSOFT Software
Engineering Notes, Vol. 13, N l,pp. 17-21, 1988.
Will Tracz Confessions o f a Used Program Salesman: Institutionalizing
Software Reuse. Addison-Wesley, 1995.
Virginia Center of Excellence for Software Reuse and Technology
Transfer, Reuse Adoption Guidebook. Technical Report SPC-92051-
CMC, Software Productivity Consortium, Herndon, Virginia,
November, 1992.
USAF (United States Armed Forces) Guidelines for Successful
Acquisition and Management o f Software Intensive Systems:
Weapons Systems, Command and Control Systems, Management
Information Systems, Department of the Air Force, Software
Technology Support Center, February 1995.
USAF (United States Armed Forces) Software Reuse Guidelines, ASQB-
GI-90-015, U.S. Army Institute for Research in Management
Information, Communications and Computer Sciences, April 1990.
References 247

M. Wasmund, “Implementing Critical Success Factors in Software

Reuse,” IBM Systems Journal, Vol. 32, N 4, pp. 595-611, 1993.
G. M. Weinberg, The Psychology o f Computer Programming, Van
Nostrand, New York, 1971.
Edmond Weiss, “USABILITY: Stereotypes and Traps,” Text, ConText,
and HyperText, Edited by E Barrett, pp. 175-185, MIT Press:
Cambridge, Massachusetts, 1988.
Scott N. Woodfield, David W Embley, Del T Scott, “Can Programmers
Reuse Software?,” IEEE Software, pp. 52-59, July 1987.
Surya B. Yadav, Ralph R. Bravoco, Akemi T Chatfield, T M Rjkumar,
“Comparison of Analysis Techniques for Information Requirements
Determination,” Communications o f the ACM, Vol. 31, N 9, pp.
1090-1097, 1988.
United States Navy (USN), Weapon System Software Development,
MIL-STD-1679, 1976.
Wieringa, R.B. and R.J. Feenstra. Information Systems: Correctness and
Reusability—Selected Papers from the IS-CORE Workshop,
Amsterdam, September 1994. World Scientific, 1995.
P. J. Williams, P Hammond, “The Creation of Electronic Visual Archives
for Teaching and Learning,” Proceedings o f the 12th UK
Eurographics Conference, 1994.
William Wong “A Management Overview of Software Reuse,” NIST
Special Publication 500-142, National Institute of Standards and
Technology (NIST), 1986.
William Wong “Management Guide to Software Reuse,” NIST Special
Publication 500-155, National Institute of Standards and Technology
(NIST), 1988
R. T. Yeh, P Zave, “Specifying Software Requirements,” Proceedings
IEEE, Vol. 68, N 9, pp. 1077-85, Institute of Electrical and
Electronics Engineers, New York, 1980.
Clement T. Yu, Gerard Salton, “Effective Information Retrieval Using
Term Accuracy” Communications o f the ACM, 20, 3, pp 135-142,
1997.
A. Zanger (editor) Andrew View Newsletter, Volume 5, Number 2,
ftp://ftp.andrew.cmu.edu/pub/AUIS/NEWSLETTERS/ASCII/96
Summer.ascii, 1996
 Index

A A p p lic a tio n -in d e p e n d e n t d ata

A B B . S e e A se a B ro w n B o v eri. stru ctu res, 174
A b stra c tio n a l stages, 127 A p p lic a tio n -o rie n te d d escrip tio n s, 163
A c c e ssio n A p p lic a tio n s softw are, 2
cost, 65 A p p lic a tio n -sp e c ific m eth o d s, 104
tim e, 65 A p p lic a tio n -sp e c ific se gm ents, 179
A rc h itectu re . S e e C o m p u te r A id e d S oftw a re
A c c o u n tin g m eth o d s, 188
A C M , 39 E n g in e erin g ; R euse.
A R PA . S e e A d v a n c e d R e search P ro je cts
A c tiv ities, 213
A gency.
A c tiv ity g rap h , 45
A se a B ro w n B o v e ri (A B B ) Steel W orks,
A ctiv ity -b a se d co stin g , 40 , 41
A d a, 79, 100, 101 198, 199
P ra c titio n e r u sa g e, 183-185
A d a-ty p e p se u d o lan g u ag e, 114
A sse ssm e n t, 53. S e e a ls o C a p ab ility
A d v a n c e d R e search P ro je cts A g e n c y (A R PA ),
7 6 -7 7 , 225 assessm en t; R e u sab le
co m ponents,
A ero sp ac e A p p lic a tio n s asse ssm e n t criteria,
m ech an ism , 83
re u sa b le so ftw are g u id e, 79
m eth o d s. S e e P rocess.
A IS E . S e e A m e ric a n A sso c ia tio n o f Iro n an d
A S S E T . S e e A sset S ource fo r S oftw a re
S teel E n g in e ers.
E n g in e e rin g T echnology.
A m e ric a n A sso c ia tio n o f Iro n and
A sse t S o u rce fo r S o ftw a re E n g in e erin g
S teel E n g in e ers (A IS E ), 183, 184
T ech n o lo g y (A S S E T ), 122
A m e ric a n N a tio n al S tan d ard s In stitu te (A N S I),
28 A ssets, 231. S e e a ls o S oftw a re assets,
A N S I J-0 1 6 , 84 acce p ta n ce, 60
acq u isitio n , 60
A N S I Jo in t S tan d ard 016
b ase, 231
T ech n ical A d v iso ry G ro u p , 33
b ro k er, 69
A m e ric a n stan d ard s, 2 8 -2 9
catalo g in g , 60
A n d re w h elp sy stem , 116, 118-120
creatio n , 52, 55-60, 62
A n d rew T oolkit, 118
en g in eerin g p ersp e c tiv e s, 221
A N S I. S e e A m e ric a n N a tio n a l S tan d ard s
im p lem en tatio n , 56
In stitu te.
library, 47
A n tic ip a te d tailo rin g , 62
A n tic ip a te d target, 62 m an ag em en t, 52, 55, 57-61
p ro c e sse s, 60-61
A p p le, 218
sp e cificatio n , 56
A p p licatio n
u tilizatio n , 52, 55, 58, 60-63, 127, 132
d o m ain , 97, 231
A sy m m e trix C o rp o ratio n , 205
e n g in eerin g , 231
A ttrib u te /v a lu e p airs, 152
g en erato r, 177, 231

249
250 Index

A ttrib u tiv e relatio n , 95 C e rtific atio n , 231

A u d it, 68 CFR P. S e e C o n c ep tu al F ra m e w o rk fo r R euse
A u g u sta S pA , 211 P ro c esses.
A u stra lia n M a ritim e In te llig e n t S u p p o rt C h ie f p ro g ram m er, 37
T erm in al, 182 team , 37, 231
A uthor. S e e O rig in al author. C IM -E X P , 198
A u th o rin g so ftw are, 201 C IS. S e e C o m m o n In fo rm a tio n Space.
A u th o rin g sy stem v en d o r, 20 4 C lasse s, 23
A u to m atic in d ex in g , 93 C lassificatio n . S e e F a c e te d classificatio n ,
AW T, 104 sch em a. S e e P e d a g o g ic a l c la ssificatio n
sch em a.
B C lie n t in teractio n , 40
C M . S e e C o n fig u ra tio n m an ag em en t.
B a ck u p p ro g ram m er, 37
C M M . S e e C a p ab ility M a tu rity M odel.
B a se d o cu m en ts, 74, 84
C O B O L p ro g ram s, 182
B asic In tero p e ra b ility D a ta M o d e l (B ID M ), 76
C O C O M O . S e e C o n s tru c tiv e C O st M O del.
B A S IC lan g u ag e, 193
C ode. S e e S ource code,
B B /L X , 192
c o u n tin g tool, 190
B e an s, 104
g en erato rs, 139-142
B e n e v o le n t o rg an izatio n , 69
m o d u les, 134
B ID M . S e e B a sic In te ro p e ra b ility D ata M o d el.
o rg an izatio n , 101-104
B la c k b o x , 23
C o h e siv en ess, 131
B o fo rs E le ctro n ics, 182
C o llecto r, 207
B o o tstrap , 31
C o m m e rc ia l cases, 181-182
B o tto m -u p d e v elo p m en t, 176
C o m m itte e o f E u ro p e a n N o rm a liz a tio n , 28
B u ild in g b lo ck s, 192. S e e a ls o C + + b u ild in g
C o m m o n C o m m a n d L an g u ag e (C C L ), 165
b lo ck s; L E G O b u ild in g b lo ck s.
C o m m o n In fo rm a tio n Space (C IS), 211-213,
B u sin ess p a tte rn s, 105
2 1 5 ,2 1 7
B u sin e ss-a re a m a n ag ers, 79
C o m m u n icatio n , 204
co sts, 43
C
p ath s, 188
C, 100, 137, 198. S e e a ls o O b jectiv e C. sp ace, 211
so ftw are p a ck ag e , 184 C o m m u n ities, com m unity, 218
C + + , 101, 103, 138, 198 C o m p o n e n t sustainability. S e e R e trie v e d
b u ild in g b lo ck s, 193 c o m p o n e n t sustainability.
C co d e, 137, 179 C o m p o n en ts, 110, 231. S e e a ls o D o cu m en ts;
p ro g ra m , 129 P ro p o se d com p o n en t; R e u sab le com p o n en ts;
C A I. S e e C o m p u te r-A id e d In stru ctio n . R e u sab le p a ra m e tric com p o n en t; S oftw are
C a n d id a te u sa g e, 74 co m p o n en ts,
C a p a b ility a ssessm en t, 85 c lassificatio n , 173
C a p ab ility M a tu rity M o d e l (C M M ), 31 c o m p o sin g , 133
C a p italiza tio n . S e e D ev elo p m en t. c o st-effectiv en ess, 61
C A R D S D ire c tio n L ev el H an d b o o k , 84 quality, 143
C a m e g ie -M e llo n U n iv ersity , S o ftw are refe re n c e in co rp o ratio n , 61
E n g in e e rin g In stitu te, 31 so u rces, 91
C A S E . S e e C o m p u te r A id e d S o ftw are sy stem s, 105
E n g in e erin g . C o m p o sitio n , 133-139
C ase stu d ies, 181 C o m p o sitio n a l ap p ro ach , 176
C a sh in cen tiv e sch em e, 197 C o m p u te r A id e d S oftw a re E n g in e erin g
C C L . S e e C o m m o n C o m m a n d L an g u ag e. (C A S E ), 149-154. S e e a ls o H ypertext,
C E A C . S e e C o st E stim atin g A lg o rith m for a rc h itectu re s, 150-151
C o u rse w are . to o ls, 172, 173, 180, 182
Index 251

to o ls e x p o rt files, 172 D ata m o d el. S e e L ibrary; R e u se L ib rary

C o m p u te r-a id e d d esig n to o l In tero p erability.
a ssessm en t, 41 D ata stru ctu res, 4. S e e a ls o A p p licatio n -
C o m p u te r-A id e d In stru c tio n (C A I), 93 in d e p e n d e n t d ata structures.
C o n c ep ts D atab ase, 149. S e e a ls o L iteratu re d atabase.
m o d el, 158, 165 facilitie s, 150
so u rces, 91 D a ta -flo w diag ram s, 20
C o n c ep tu al F ra m e w o rk fo r R e u se P ro c esses D ec o m p o sitio n , 21
(C F R P ), 76, 77, 84, 225 D efects, 194
C o n c ep tu al re q u irem en ts, 18 D ep a rtm e n t o f E nergy, 69
C o n d itio n al co m p ilatio n , 133 D ep th -first trav ersal, 109, 169
C o n fig u ra tio n m a n a g e m e n t (C M ), 85 D e scrip to rs, 97
tool. S e e S o u rce code. D esig n , 15, 40, 232. S e e a ls o S oftw are life
C o n fo rm an ce, 75 cy cle; T op-dow n design,
C o n sisten cy , 177 d ecisio n s, 129
C o n stru c tiv e co st m o d el, 232 d o cu m en ts, 163
C o n s tru c tiv e C O st M O d el m eth o d o lo g y , 128
(C O C O M O ), 42, 46 to o l assessm en t. S e e C o m p u te r-a id e d d esign
C o n v e rsio n p ro g ram , 137 to o l assessm ent.
C o o rd in atio n , 186. S e e C o u rse w are D e v elo p ers
reu se. e x p ectatio n s, 128
serv ices, 2 1 3 -2 1 7 train in g , 2
sp ace, 211 D e v elo p m en t. S e e Info rm atio n ,
C o o rd in atio n se rv ices, 216 effo rt, c a p italizatio n , 222
C o p y rig h t, 66, 67, 202 ex p lo itatio n , co m p ariso n . S e e In te g ra te d
C o st E stim a tin g A lg o rith m fo r C o u rse w are R a d io lo g ical Services,
(C E A C ), 202 life cy cle, 6
C o sts/b en efits. S e e S o ftw a re reen g in eerin g . m eth o d o lo g y , 5
co m p ariso n . S e e R e u se fram ew o rk . p ro c e ss, m o d ifica tio n , 187
C o u rse d e sc rip tio n file, 203 task s, structure, 172
C o u rse stru ctu re file, 203 D e w e y D ecim al system , 97
C o u rse -d e p e n d e n t p ara m e te rs, 202 D ig ital lib ra ries, 122
C o u rse -in d e p e n d e n t p ara m e te rs, 202 D ire c tio n setting, 53
C o u rse w are , 2 0 1 , 232 D ire c tio n -le v e l h an d b o o k . S e e R e u sab le
d e v elo p m en t, 201, 220 D e fe n se Softw are.
elem en ts, re c o m m e n d e d fo rm ats, 203 D isin c e n tiv e , 226
library, c o n v ersio n , 207 D istrib u te d in fo rm a tio n system s, 122
C o u rse w are reu se, 201 D o cu m en tatio n , 24. S e e a ls o L o w -in v e stm e n t
c o o rd in atio n , 2 1 1-217 d o cu m en tatio n ; S o ftw a re life cycle; T extual
p ro b lem s, 22 0 d o cu m en tatio n ,
sta n d ard s, 2 0 2-205 editor, 37
C ritical su c cess facto rs, 186 ev alu atio n , 75
C ro ss-o v er o p erato r, 144 in v estm en t, 26
C ro ss-p ro je c t c o m m u n icatio n , 192 o u tlin es, 94-97
C u rren cy criterio n , 75 reorganization, 130-132
C u rricu lu m , e stab lish m en t, 187 re triev al, 111-112
C u sto m e r-o rie n te d p ro g ram . S e e In stitu te o f sta n d ard s, 173
E le c tric a l an d E le ctro n ic E n g in eers. sy stem . S e e U N IX .
D o c u m e n t-o rie n te d re triev al, 111, 125
D D o c u m e n t-o rie n te d system , 97, 232
D o cu m en ts, 91, 232. S e e a ls o B a se docu m en t;
D ata d efin itio n , 174
D esig n ; N o n -c o d e docu m en ts; N o rm a tiv e
252 Index

d o cu m en ts; O v e rv ie w d o cu m en ts; F
R e q u irem en ts; S o ftw a re-related
F acet, 100
d o cu m en ts, term , 100
co m p o n en ts, 109 F a c e te d c lassificatio n , 9 9-101, 198
o u tlin e, 94 F ile m o d e, 158
re o rg a n iz atio n , 131
F iles, 203
D oD . S e e U n ite d S tates D e p a rtm e n t o f
F ilters, 137
D efen se.
F in a n c ia l in cen tiv e, 230
D o m ain , 23 2 . S e e a ls o H o rizo n tal d o m ain ,
F in g e rtip reuse, 191, 198
an aly st, 7
F o rm a t co n v erters, 210
e n g in eerin g , 232
F o rtran , 221
im p lem en tatio n , 229
F o u rth G e n eratio n L an g u ag es, 176
m o d elin g , 7, 56
F ra m e w o rk co ncepts, 51
m o d els, 9 7 -1 0 1 , 106, 232 F ra m ew o rk s, 104-105. S e e a ls o G en eric
D o m ain an aly sis, 6-7, 184, 22 9 , 232 fram ew ork; R e u se fram ew o rk ; S oftw a re
p ro c e sse s, 56
P ro d u c tiv ity C onsortium .
sta n d ard , 84
F re e -te x t retriev al, 111
D o m ain E n g in e e rin g G u id eb o o k , 79
F u ll-te x t se arc h in g , 112
D o m a in -re la te d in fo rm atio n , 154
F u n c tio n a l testin g , 24
D o m a in -sp e c ific ap p ro ach , 49
D o m a in -sp e c ific k its, 194
G
D o m a in -sp e c ific reu se, 232
k its, 196 G en e ra te d p ro g ram s, 139
D R A C O , 175, 176 G e n eratio n , 232
G e n erativ e ap p ro ach , 5, 176
E G en eric fram ew o rk , 51
G en eric p ack ag e s, 132
E d u catio n , 187, 197
G IF, 137
E d u catio n al m eth o d o lo g y /m o tiv a tio n , 3
G lo b al d e p en d en c ie s, 192
E d u catio n al o b ject e c o n o m ies (E O E ), 2 1 7 -2 2 0
G lo b al w o rk sp ace s, 153
histo ry , 2 1 8 -2 1 9
G o p h er, 120
p lan s, 2 1 9 -2 2 0
G o v e rn m e n t agen cies, 224
E d u catio n al o b jects, 219
G o v e rn m e n t p ro c u re m e n ts, 224
E m b e d d ed firm w are p ro d u cts, 194
G rass ro o ts phase. S e e M o to ro la reuse.
E n g in e erin g , 1. S e e a ls o D o m ain ; R ev erse
G ra ss-ro o ts p ro ject, 191
e n g in eerin g ; S o ftw a re reen g in eerin g ,
G ro u p p ro d u ctiv ity , 39
c o n cen s, 221
G T E A sse t M a n a g e m e n t P ro g ram m e, 182
p e rsp ec tiv es. S e e A ssets.
G u id an ce, 75
E n g lish , 100
G u id e fo r R e u sab le S oftw are. S e e A ero sp ac e
E n te rp rise. S e e S m all en terp rise.
A p p licatio n s asse ssm e n t criteria.
E O E . S e e E d u catio n al o b je c t eco n o m ies.
G u id elin es fo r S u ccessfu l A c q u isitio n and
E u ro p ean C o m m issio n , 154
M a n a g e m e n t o f S o ftw a re In ten siv e S ystem s.
E u ro p ean U n io n , 66
S e e S oftw are In ten siv e S ystem s.
E v a lu atio n
criteria, 74-75
H
stag e, 68
E x cep tio n s, 23 H A M . S e e H y p ertex t A b stra c t M achine.
E x e cu tab le co d e, 61 H ard w a re p latfo rm s, 211
E x istin g re la te d sta n d ard s, 7 4 -80 H e u ristic m eth o d s, 174
E x p ectatio n s, 72-74. S e e a ls o U se r H ew le tt-P a c k a rd (H P ), 178-181, 199, 220
ex p ectatio n s. co rp o ra te reu se strategy, 193
E x te rn al sy stem b eh av io r, 17 H P -V E E , 196
E x tra c tio n alg o rith m , 172 reu se, 193-196
Index 253

H ie ra rc h ic a l im p lem en tatio n , 193 In d ex in g , 91-93. S e e a ls o A u to m atic indexing;

H ie ra rc h ic a l relatio n , 95 In terp retiv e in d ex in g ; L an g u ag e
H ig h -lev el in terface , 164 m a in ten an ce; S tru c tu ral in dexing; W ord
H ig h -lev el lan g u ag e, 139 freq u e n cy indexing,
H ig h -lev el o rg an izatio n , 97 co n cep ts, 92
H ig h -lev el ou tlin e, 94 la n g u ag e, 217
H ig h -lev el p ro g ra m m in g lan g u ag es, 101 In fo rm atio n , 75
H ig h -lev el query, 164 d ev elo p ers, 25
H ig h -le v e l sy stem d esig n , 35 d e v elo p m en t, 25
H isto ric d e v elo p m en t, 163 life cy cle, 5
H L Q S , 164, 165, 173 sy stem s. S e e D istrib u te d in fo rm atio n
H o riz o n ta l d o m ain , 233 sy stem s,
HP. S e e H ew lett-P ack ard . u n its, 215, 217
H y p ertex t, 7-11, 150, 201 In fo rm a tio n R e triev al S ystem , 125
C A S E , 152-154 In fo rm a tio n -in te n siv e con tex t, 51
sy stem , 10 In frastru ctu re, 40, 219. S e e a ls o R euse,
tech n o lo g y , 185 im p le m e n ta tio n p ro c e sse s, 54
H y p e rte x t A b stra c t M a ch in e (H A M ), 152 p la n n in g , 53
In h ib ito rs, 194
I In n o v a tio n E x p lo ra tio n p ro cesses, 55
In p u t/o u tp u t, 174
IB M , 29, 86, 181, 199, 2 2 0 , 22 4
In stitu te o f E le ctrical a n d E le ctro n ic E n g in e ers
ex istin g tech n iq u e s/k n o w le d g e , 186
(IE E E ), 2 8 - 3 0 ,7 1 ,7 2 , 76, 80
reu sa b le p arts cen ter, 192-193
cu sto m e r-o rie n te d p ro g ram , 32-34
reu se, 185-186
sta n d ard s d o cu m en t, 18
w o rld w id e cam p aig n , 185
In stru c tio n a l M a n a g e m e n t S ystem s (IM S ),
IB M B o b lin g e n e x p erien ce, 186-192
2 1 7 ,2 1 8
e x ecu tio n , 190-191
In stru c tio n a l tem p lates, 201
p lan , v a lid atio n , 187-190
In te g ra te d e n v iro n m en t, 150
step s, 186-187
In te g ra te d P ro je ct S u p p o rt E n v iro n m e n t (IP S E ),
IB M C o rp o rate R e u se C o u n c il, 185
150, 151
IB M R e u se T ech n o lo g y C enter, 186
In te g ra te d R a d io lo g ic a l S ervices (IR S),
IB M R e u se T ech n o lo g y S u p p o rt C enter,
205-211
185, 189
d e v e lo p m e n t/e x p lo ita tio n , co m p ariso n ,
Ico n ix S o ftw a re, 173
2 0 7 -209
Idio m s. S e e P ro cess.
m e d ia in d ex /tab le o f con ten ts, co m p ariso n ,
IEC . S e e In te rn a tio n a l E le c tro te c h n ic a l
209-211
C o m m issio n .
sy stem arch itectu re , 2 0 6-207
IE E E . S e e In stitu te o f E le ctrical an d E le ctro n ic
In telle ctu al capital ap p re c ia tio n licen se, 220
E n g in e e rs.Im p a c t c riterio n , 75
In te n d e d function, 86
Im p le m e n ta tio n , 15. S e e a ls o A ssets;
In te ra c tio n -o rie n te d in d iv id u als, 38
H ie ra rc h ic a l im p lem en tatio n ; S o ftw a re life
In te rco n n e ctio n s, 152
cycle.
In te rfa c e A rch itect, 179, 180
p ro cesses. S e e In frastru ctu re,
X W indow , 178
stag e, 68
In terfaces, 177, 193. S e e a ls o S tab le in terfaces,
Im p le m e n ta tio n -o rie n te d d e scrip tio n s, 163
b in d in g s, 163
IM S. S e e In stru ctio n al M a n a g e m e n t S y stem s.
sp e cificatio n , 23
In cen tiv e p ro g ram s, 188
In tern al sy stem beh av io r, 17
ru n n in g , 187
In tern atio n al E le c tro te c h n ic a l C o m m issio n
In c re m e n ta l ch an g e, 199
(IE C ), 29, 32, 33, 86
In d ex te rm m o d e, 158
In te rn atio n al life c y cle p ro c e ss fram ew o rk , 33
Ind ex er, 207
w o rk sp a c e , 216
254 Index

In tern atio n al O rg an izatio n o f S tan d ard s (IS O ), d ata m o d elin g p ro c e sse s, 59

28 facility, ad m in istra tio n /o p e ra tio n , 59
IS O 12207, 2 9 -3 1 , 39, 84, 85, 87 in tero p eratio n support, 59
Intern et, 122 o p e ratio n p ro cesses, 58
Intero p erab ility , 204, 226. S e e a ls o R e u se p ro cesses, 58-60
lib rary ; R e u se L ib ra ry In tero p erab ility . size, 123
In te ro p e ra tio n su p p o rt. S e e Library. so ftw are, 209
In terp retiv e in d ex in g , 91, 233 sy stem , 124
IPS E . S e e In te g ra te d P ro je c t S u p p o rt U sag e support, 60
E n v iro n m en t. L ife cy cle, 233. S e e a ls o D ev elo p m en t;
IR S. S e e In te g ra te d R a d io lo g ic a l S ervices. In fo rm atio n ; S oftw a re develo p m en t;
ISO . S e e In te rn a tio n a l O rg an izatio n o f S o ftw are life cycle; W aterfall life cycle,
S tan d ard s. m o d el, 34, 233
ISO 12207. S e e In te rn atio n al O rg an izatio n o f p ro c e ss fram ew ork. S e e In te rn atio n al life
S tan d ard s. cy cle p ro cess fram ew ork.
Iterativ e read ju stm en t, 191 L iteratu re datab ase, 189
L o cal w o rk sp ace s, 153
J L o g ic elem en ts, 203
L o w -in v e stm e n t d o c u m en tatio n , 26
Ja p an ese tra in in g p ro c ed u res, 111
L o w -lev el code, 101
Ja v a ap p lets, 219
Ja v a B e an s, 105
M
Ja v a so ftw are, 218
JP E G , 137 M a in te n an ce, 15. S e e a ls o S oftw are life cycle;
JT C 1 , 86 S o ftw a re m ain ten an ce,
ch an g es, 187
K cost, 65
effe ctiv e n ess, 188
K D S I. S e e K ilo D e liv e re d S o u rce In stru ctio n s.
m an co m m and. S e e U N IX .
K ilo D e liv e re d S o u rce In stru ctio n s (K D S I), 42
K n o w led g e. S e e IB M . M a n ag em en t, 35. S e e a ls o A sset; R euse;
a c q u isitio n , 56 R e u se -o rie n te d m an ag em en t,
g u id elin es, 229
L p ro cesses. S e e P roject,
stru ctu re, 36
L an g u ag e m a in ten an ce, in d ex in g , 217 su p p o rt, 185
L an g u a g e /sy ste m exper, 37 sy stem , 204, 205
L arg e scale su b sy stem s, 227 M a n u fa c tu rin g ap p ro ach , 195
L e a d -in term s, 97 M a n y U sin g and C reatin g H y p e rm e d ia
L e am in g W o rk s, 205 (M U C H ), 155, 168-170
L eg acy sy stem s, 233 M a ste r P lan. S e e S o ftw a re E n g in e erin g
L E G O b u ild in g b lo ck s, 195 S tan d ard s C om m ittee.
L E G O S y stem s, 194 M aster Road Map. See Software Engineering
L e sso n lau n ch , 204 S tan d ard s C om m ittee.
L ib rarian , 37 M atu rity , 188
L ib raries, 201. S e e a ls o D ig ital lib raries; M e d ia M e d ia fo rm ats, 220
lib raries; N a tio n a l lib ra ries; R e u se library; M e d ia in d ex, 210
T rad itio n al lib raries; V ideo lib raries. tab le o f contents, com p ariso n . S e e
L ibrary, 176, 192, 22 4 , 233. S e e a ls o A ssets; In te g ra te d R a d io lo g ic a l S ervices.
S m all library, M e d ia lib ra ries, 202
b en efit, 209 M e d ia ty p es, 206
co n ten ts, a rc h iv in g /b ack u p , 59 M e ssag es, 23, 215
co st effe ctiv e n ess, 209 M e ta d a ta sp e cificatio n , 217
d ata m o d el, 233 M e ta d a ta system s, 219
Index 255

M e th o d o lo g ies, 233. S e e a ls o M ix e d O b je c t m an ag em en t, 151

m e th o d o lo g ies. O b je c t P asc al, 103
M ic ro p a y m e n t sy stem s, 219 O b je c tiv e C , 103
M ic ro so ft F o u n d a tio n C lasse s, 104 O b jectiv es re la tio n sh ip s file, 203
M ix e d m eth o d o lo g ie s, 128 O b je c t-o rie n te d lan g u ag es, 101, 103
M M U . S e e M u ltiM e d ia U n it. O b je c t-o rie n te d m eth o d o lo g y , 104
M o d e lin g . S e e P ro c ess; S o ftw a re p ro je c t O b je c t-o rie n te d p a ra d ig m , 39
m o d elin g . O b je c t-o rie n te d p ro g ra m m in g , 103
M o d u le In te rc o n n e c tio n L an g u ag es, 139 O b je c t-o rie n te d p ro g ra m s, 193
M o tiv atio n , 181, 187 O b je c t-o rie n te d re triev al, 125
M o to ro la, 86, 196, 220 O b je c t-o rie n te d so ftw are, 103
M o to ro la reu se, 196-197 d e v elo p m en t, 170
g rass ro o ts p h ase, 197 O b je c t-o rie n te d system s, 97, 234
to p d o w n p h ase, 197 d e v elo p m en t, 122
M U C H . S e e M a n y U sin g an d C reatin g O b je c t-o rie n te d te c h n iq u es, 106
H y p erm ed ia. O b jects, 103. S e e a ls o E d u c a tio n a l objects.
M u ltiM e d ia U n it (M M U ), 213 O ffice In fo rm a tio n R e triev al S ystem (O IR S ),
21
N O IR S . S e e O ffice In fo rm a tio n R e triev al
S ystem .
N A S A . S e e N atio n a l A ero n au tics an d S p ace
A d m in istratio n . O L E , 105

N atio n a l A ero n a u tic s an d S p ace A d m in istra tio n O p en S y stem fo r C o lla b o ra tiv e A u th o rin g and
(N A S A ), 69 R e u se (O S C A R ), 211-217
N atio n a l In stitu te o f S tan d ard s an d T echnology, se rv ices, 211
80 O p en D o c, 105
N a tio n al lib ra ries, 228 O p e ra tin g system s, 151, 211, 212
N a tio n a l L ib ra ry o f M e d ic in e (N L M ), 2 2 7 , 228 O p p o rtu n istic reu se, 234
N a tio n a l S cien ce F o u n d a tio n (N S F ), 218 O p tical ch a ra c te r re c o g n itio n softw are, 207
N A TO . S e e N o rth A tla n tic T reaty O rg an izatio n . O rg an ism s, 144
N a tu ra l lan g u ag e req u irem en ts, 18 O rg an izatio n , 86, 89, 91. S e e a ls o B e n ev o len t
N E C S o ftw a re E n g in e e rin g L ab o rato ry , 182 o rg an izatio n ; C o d e organ izatio n ; H ig h -lev el
N ep tu n e , 152, 154 o rg an izatio n ; S o ftw a re team o rganization.
N e t sa v in g N S R , 65 O rg an izin g , 234
N e tscap e, 22 4 O rig in al author, 142
N L M . S e e N a tio n a l L ib rary o f M e d icin e. O S C A R . S e e O p en S y stem fo r C o lla b o ra tiv e
N o n -c o d e d o cu m en ts, 130 A u th o rin g an d R euse.
N o n -h ie ra rc h ic a l relatio n , 95 O u tlin e -e x tra c tio n , form , 103
N o n -o p e ra tio n a l re q u ire m e n ts, 19 O u tlin es, 168. S e e a ls o D o c u m en tatio n ;
N o n -p re fe rre d term s, 97, 98 D o cu m en ts; H ig h -lev el o utline,
N o n -te c h n ic a l facto rs, 68 re latio n s, 95
N o rm a tiv e ad v ice, 74 O v e rv ie w do cu m en ts, 118
O w n er, 66
N o rm a tiv e d o cu m en ts, 74
N o rth A tla n tic T reaty O rg an izatio n (N A TO ),
5 1 ,8 6
P
N o t In v e n te d H ere S y n d ro m e , 234 P ack ag es, 114. S e e a ls o G en eric p ack ag e s.
N SF. S e e N a tio n a l S cien ce F o u n d atio n . P arad o x . S e e R e o rg an izin g .
N S R . S e e N e t sa v in g N S R . P ara lle l-p ro c e ssin g com puter, 42
P a ra m e te rs, 137
O P arts cen ters, 192
resp o n sib ility , 191
O b je c t eco n o m ies. S e e E d u catio n al o b ject
P arts so u rces, 187
eco n o m ies.
P aten ts, 67
 256 Index

P attern s, 105. S e e a ls o B u sin ess p attern s. H ig h -le v e l p ro g ra m m in g languages.

P C X , 137 P ro g ra m m in g tech n o lo g ie s, 2
P ed ag o g ical cla ssific a tio n sch em a, 213 P ro g ram s. S e e G e n e ra te d p ro g ra m s.e le m e n ts.
P e in e -S a lz g itte r Steel W orks, 183 S e e S o ftw a re E n g in e e rin g S tandards
P la n n in g stage, 68 C o m m ittee.
P L /S , 192, 193 reo rg a n iz atio n , 132-139
P o licy sta n d ard s, 82 re triev al, 112-116
P o p u lato r, 207 tra n sfo rm a tio n , 140, 141
P o rtab ility , 234 P ro je ct
P o rta b le P ix M a p (P P M ), 137 ad m in istrato r, 37
P o st-re u se testin g , 142-143 c o n tro l activ ities, 54
P o ten tial n ew stan d ard s, 82-85 in itia tio n activ ities, 54
P o w erT o o ls, 173 m a n a g e m e n t p ro c e sse s, 54, 55
P P M . S e e P o rta b le P ix M ap . m o n ito rin g activ ities, 54
P ra ctices, 84 p erfo rm a n c e , 54
set, 83 p la n n in g , 53-54
P ra ctitio n er, 149, 154-167, 180 re tire m e n t activ ities, 54
case study, 183 reu se team leader, 185-186
P ro je ct, 181, 184 P ro je ct O b se rv a tio n p ro c e sse s, 55
to o ls, 184, 185 P ro je c t-o rie n te d p la n n in g , 52
u sag e. S e e A se a B ro w n B o v e ri Steel W orks. P ro p o se d c o m p o n en t, 60
P ra c titio n e r R e u se S u p p o rt S y stem (P R E S S ),
154-156, 168. S e e a ls o P R E S S T IG E ; Q
PRESSTO .
Q uality, 2. S e e a ls o C om p o n en ts.
q u estio n n a ire s, 171
circles, 69
to o lk it, 156
Q uery, 23 4
P re cisio n , 122, 234
Q u e stio n n aires, 158. S e e a ls o P ra c titio n e r
trad e-o ff. S e e R e call/p recisio n .
R e u se S u p p o rt S ystem ; P R E S S T IG E .
P re fe rre d term s, 97, 98
co n stru c tio n cost, 185
P re -re g iste re d h a n d le r o b jects, 104
P R E S S . S e e P ra c titio n e r R e u se S u p p o rt
R
S ystem .
P R E S S T IG E , 155, 158-168, 184, 185 R a n k in g , 111
q u e stio n n a ire, 163 R a y th e o n M issile S ystem s, 182
P R E S S T O , 155, 157-158, 168 R e call, 122, 235
re trie v a l fu n ctio n , 158 R e c a ll/p re c isio n , trad e-o ff, 123
P rim a ry b u sin e ss, 27 R e c o rd -k e e p in g fu n ctio n s, 95
P rin c ip les, d escrip tio n , 226 R e le v an ce, 75
P ro c ess, 23 4 R e o rg an izatio n , 89, 127, 145. S e e a ls o
asse ssm e n t m eth o d s, 31-32 D o c u m en tatio n ; P rogram .
fram ew o rk . S e e In tern atio n al life R e o rg an izin g , 235
cy cle p ro c e ss fram ew o rk , stage, p arad o x , 144
id io m s, 50-52 R e p ack ag in g , 171
m o d elin g , 39-41 R e p resen tatio n s, 221 -222
so u rces, 50-52 R e q u irem en ts, 235. S e e a ls o C on c ep tu al
stan d ard , 84 re q u irem en ts; N a tu ra l lang u ag e
P ro c e ss-d riv e n so ftw are e n g in eerin g , 2 34 req u irem en ts,
P ro d u ctiv ity , 2, 40. S e e P ro g ra m m e r d o cu m en t, 18
p ro d u ctiv ity . R e search team , 227
P ro fitab ility , 40 R e so u rce allo catio n , 40
P ro g ra m m e r p ro d u ctiv ity , 44 R eth in k . S e e S oftw a re develo p m en t.
P ro g ra m m in g lan g u ag es, 22, 128. S e e a ls o R e triev al, 89, 107, 210. S e e a ls o
Index 257

D o c u m en tatio n ; D o cu m e n t-o rie n te d leg al issues, 66-67

re triev al; F re e -te x t retriev al; O b ject- sa v in g s, 70
o rie n te d retriev al; P ro g ram ; S o ftw are, R e u se library, 107, 192, 193, 235
fu n ctio n . S e e P R E S S T O . in tero p erab ility , 235
m o n ito rin g , 122-124 R e u se L ib rary In tero p e ra b ility
se arc h es, 107 d ata m o d el, 76
s p e cificatio n , 107-110 G ro u p (R IG ), 76
sy stem s, 116-122, 325. S e e a ls o In fo rm atio n . R e u se P lan n in g G roup, 71, 87
R e trie v e d c o m p o n en t su stain ab ility , 128-129 R e u se p ro c e sse s, 83
R e u sab le asset acq u isitio n , 229 c o n cep tu al fram ew o rk , 69
R e u sab le co m p o n en ts, 157 efficiency, 220
a ssessm en t, 85 R e u se S ervices, 213
tra n sfo rm a tio n , 173 R e u se S tra te g y M ode l, 77
R e u sab le D efen se S o ftw are, R e u se T echnology S u p p o rt C enter. S e e IB M
d ire c tio n -le v e l h an d b o o k , 77 R e u se T echnology S u p p o rt C enter.
R e u sa b le p a ra m e tric c o m p o n en t, 179 R e u se -b a se d softw are e n g in eerin g , 235
R e u sab le S o ftw a re A sse t B ro k erag e S erv ices, R e u se d lines, 189
122 R e u se -o rie n te d d e v e lo p m e n t m eth o d o lo g ie s, 5
R e u se, 235. S e e a ls o C o u rse w a re reu se; R e u se -o rie n te d m an a g e m e n t, 198
D o m a in -sp e c ific reu se; F in g ertip reu se; R eu ser, 235
H ew le tt-P a c k a rd reu se; IB M reu se; R e v erse en g in eerin g , 56, 129, 222
M o to ro la reu se; O p p o rtu n istic reuse, R e w ard s softw are reu se, 222
a rc h itectu re , 211-213 R IG . S e e R e u se L ib rary In teroperability.
c h am p io n in g , 68 R isk s, 65
co m m u n ic a tio n s, 188 R o les, 7 2 ,2 1 3
cu ltu re, 230 R u les, 215
cy cle, 235 R u n -tim e arch itectu re , 104
d efin itio n , 3-5 R u n -tim e co ncept, 4
en actm en t, 54-55
e n g in eerin g , 50 S
in frastru ctu re, 235
SA IC . S e e S cience A p p lic a tio n s In te rn atio n al
in stru ctio n s, 62
C o rp o ratio n .
in v estm en t, 64
Sav in g s. S e e R e u se fram ew ork.
learn in g , 54-55
S ch ed u lin g , 4 4-46
m an a g e m e n t, 50, 52-5 5 , 57
S cien ce A p p licatio n s In te rn atio n al
p la n n in g , 52-54
C o rp o ra tio n (S A IC ), 122
p rin c ip le s, 83
S cien tific resea rch , 227
sp ace, 211
S co p in g , 53
sta n d ard s, 86
S em an tics, 114, 171, 175
task fo rc e , 197
S erv ice life, 65
team leader. S e e P ro ject,
S E SC . S e e S oftw are E n g in e e rin g S tan d ard s
testin g . S e e P o st-re u se testin g ,
C o m m ittee.
to o ls. S e e S o ftw a re reu se tools,
S G M L , 168
ty p es, 5-6
S m all en terp rise, 198
w ritin g , 168
S m all library, 194, 2 27, 228
R e u se A d o p tio n G u id eb o o k . S e e S o ftw a re
S m alltalk , 173
P ro d u c tiv ity C o n so rtiu m .
S m alltalk 80, 103
R e u se co st, 65
S o ftC lass, 149, 170-176
effe ctiv e n ess, 64
re la te d system , 175-176
R e u se fram ew o rk , 49
S o ftln d e x , 171
c o sts/b en efits, co m p a riso n , 63-66
S oftT ext, 171-173
im p act, 68-69
S o ftw a re. S e e A p p lic a tio n s softw are.
258 Index

ch ip , 23 in d u stry view , 2 2 2 -2 2 4
c lien t req u ire m e n ts, 15 rec o m m e n d a tio n s, 229
co n fig u ra tio n m an ag em en t, 122 S o ftw a re re e n g in eerin g , in tro d u c tio n , 1
d o m ain a rch itectu re , 83 n eed , 1-3
e n g in eers, 27, 197, 209 S o ftw a re reuse, 127. S e e a ls o R e w a rd s softw are
factory, 196 reu se.
item s, c la s sificatio n /retriev al, 89 p ractice, 75
m ain te n a n c e , 27 to o ls, 149
p ro je c t m o d elin g , 42 -4 4 S o ftw a re R e u se B u sin e ss M ode l, 78
to o ls, 150 S o ftw a re R e u se G u id elin es, 79
u se rs, 73 S o ftw a re R e u se In itiativ e, 77
S o ftw a re assets, 121 S o ftw a re team o rg an izatio n , 35-39
m a n ag ers, 73 S o ftw a re T echnology fo r A d a p ta b le R e liab le
S o ftw a re co m p o n en ts, 99, 125, 172 S y stem s (ST A R S ), 51, 77, 84, 225, 226
d escrip tio n s, 171 S o ftw a re -re la te d d o cu m en ts, 60
S o ftw are C risis, 1 S o rtin g , 111
S o ftw a re d e v elo p m en t, 36 S o u rce co de, 152
cy cle, 24 co n fig u ra tio n m a n a g e m e n t tool, 190
life c y c le , 112, 125 S p ecializatio n , 132-133, 227
reth in k , 3 S p ecificatio n , 236
S o ftw a re e n g in eerin g , 198. S e e a ls o P ro c ess- SP IC E . S e e S oftw a re P ro c ess Im p ro v e m e n t and
d riv e n so ftw are en g in eerin g ; R e u se-b ase d C a p a b ility dE te rm in atio n .
so ftw are en g in eerin g , SQ L , 172
e n v iro n m en t, 236 rela tio n a l d atab ase m a n a g e m e n t system , 155
S o ftw are E n g in e e rin g In stitu te. S e e S tab le in terface s, 104
C a m e g ie -M e llo n U n iv ersity . S tan d ard izatio n , 78
S o ftw a re E n g in e e rin g S tan d ard s C o m m ittee effo rts, 74
(S E S C ), 32, 33, 76 su itab ility, 85
M a ste r P lan , 33, 71, 72, 80, 82 S tan d ard s, 71, 202. S e e a ls o A m erican
M a ste r R o a d M ap, 80, 81 sta n d ard s; C o u rse w are reuse;
P ro g ra m E le m e n ts, 80, 81 D o c u m en tatio n ; D o m a in analysis;
Survey, 33 E x istin g re lated sta ndards; P o licy
T echnic S tan d ard s, 80, 81 sta n dards; P o te n tia l n e w standards;
S o ftw a re In ten siv e S y stem s, a cq u isitio n / P ro c ess; R euse; S o ftw a re life cycle,
m a n a g e m e n t g u id elin es, 78 a p p licatio n , 187
S oftw a re life cycle, 13, 15, 94, 107, 222 co n se rv a tiv e ap p ro ach , 82
d esig n , 2 0 -2 2 d ev e lo p m e n t o rg an izatio n s, 86
im p lem en tatio n , 22-23 e x p ectatio n s, 71
m ain ten an ce, 27 in tern atio n a l reco g n itio n , 87
req u irem en ts, 17-19 k in d s, 88
stan d ard s, 2 8 -3 4 rec o m m e n d a tio n s, 80-86
te stin g /d o c u m e n ta tio n , 2 4 -2 7 reje c te d altern ativ es, 85-86
S oftw a re P ro c ess Im p ro v e m e n t an d C a p a b ility STA R S. S e e S oftw are T echnology for
d E te rm in a tio n (S P IC E ), 3 2 -3 4 , 85, 87 A d a p ta b le R e liab le S ystem s.
S oftw a re P ro d u c tiv ity C o n so rtiu m , 79 S tart-u p costs, 63
R e u se A d o p tio n G u id eb o o k , 79, 84 S teel m ills, 183
S y n th esis fram ew o rk , 79 S trin g searc h in g , 116
S oftw a re ree n g in e e rin g S tru c tu ral in d ex in g , 93
co n clu sio n , 221 S tru c tu ral testin g , 24
c o sts/b en efits, 2 2 6 -2 2 7 S tru c tu re clashes, 103
g o v e rn m e n t view , 2 2 4 -2 2 6 S tru c tu re relatio n , 95
S tu d en t, p erfo rm a n c e , 205
Index 259

S u b h ead in g s, attrib u te in h erita n ce, 94 T raceab ility, 236

S u b ro u tin es, 189 T rad ers, 187
S u b sy stem s. S e e L arg e scale su b sy stem s. T rad itio n al libraries, 227-2 2 8
S u ccess facto rs. S e e C ritical su ccess facto rs. T rain in g p ro ced u res. S e e Ja p a n e se tra in in g
S u p er-o b ject, 174 p ro c ed u res.
S u p p o rt p a ttern s, 105 T ran sfo rm atio n s, 139, 173-175
S u p p o rt to o ls, 190 T rilliu m targets, 80
S u p p o rtin g to o ls, access, 187
S y m o b lic p ro d u ct, 2 U
S y n tactic ru les, 140
U n a n tic ip a te d tailo rin g , 62
S y stem arch itectu re . S e e In teg rated
U n a n tic ip a te d target, 62
R a d io lo g ic a l Serv ices.
U n ite d S tates A rm ed F o rc es (U S A F ), 78-79
S y stem co m m u n icatio n , to p o lo g y , 144
U n ite d S tates A rm y, 121, 228
S y stem d esig n . S e e H ig h -le v e l sy stem desig n .
U n ite d S tates D ep a rtm e n t o f D e fe n se (D oD ),
S y stem req u irem en ts, 20
29, 77-78, 87, 225, 228
S o ftw a re R e u se In stitu te R e u se B u sin e ss
T
M o d e l, 84
T able o f c o n ten ts, 94, 97, 2 0 9 , 210. S e e a ls o U n iv e rsa l D e fe n se S ystem s, 182
In te g ra te d R a d io lo g ical S ervices. U N IX , 100, 119, 136, 153
T ailoring, 132, 236. S e e a ls o A n tic ip a te d d o c u m e n ta tio n sy stem , 9
ta ilo rin g ; U n a n tic ip a te d tailo rin g . m a n co m m an d , 116-118
T ask -o rien ted in d iv id u als, 38, 39 o p e ra tin g system , 151, 157
T echnic S tan d ard s. S e e S o ftw a re E n g in e erin g p ro g ram s, 179
S tan d ard s C o m m ittee. sy stem s, 116, 137
T ech n iq u es. S e e IB M . U N IX p ip e, 137
T ech n o lo g y fo rec astin g , 56 fu n ctio n , 101
T ek tro n ix , 152 sy stem , 133
T em p lates, 133. S e e a ls o In stru ctio n al U SA F. S e e U n ite d S tates A rm e d F o rces.
tem p lates. U sag e, p a ttern s, 82
T ension, 125 U se r ex p ectatio n s, 72
T erm inology, 80, 81 U ser in terface g enerator, 176-180
T erm s, in co n sisten cy , 111 U se r su p port, 26
T esting, 15, 24. S e e a ls o F u n c tio n a l testin g ; tech n o logy, 25
P o st-re u se testin g ; S o ftw a re life cy cle.; U tilizatio n . S e e A sset.
S tru c tu ral testin g .
T esting strateg ies, 142 V
Textual d o c u m en tatio n , 172
V alid atio n, 40
T h esau ri, 9 7 -9 9 , 126, 131
V D M , 139
T h esau ru s, 109, 112, 125, 166, 236
V id eo lib ra ries, 202
lin k s, 163
V ien n a D e v e lo p m e n t M o d e l, 114
to o l, 165
V irtu al In fo rm a tio n T echn o lo g y C o lleg e, 230
TIFF, 137
V isual B A S IC , 178
T im e-to -m a rk et, red u ctio n , 194
V M S , 153
Tool ty p es, 190
T o o lb o o k , 2 05, 207, 211
W
T o o lsm ith , 37
Top d o w n p h ase. S e e M o to ro la reuse. W A IS in fo rm atio n se rvers, 121
T o p -d o w n ap p ro ach , 98 W aterfall life cycle, 139
T o p -d o w n d esig n , 20 W eb. S e e W orld W ide W eb.
T opic m o d el, 97 W eb -b ased m aterials, 218
T o p -lev el d e sig n d o cu m en ts, 127 W eb -related fu n ctio n alities, 224
T o sh ib a F u c h u S o ftw a re Facto ry , 181 W e b s te r’s D ictionary, 1
260 Index

W h ite b o x es, 105

W id g et, 178
W ild card s, 112
W ord fre q u e n c y in d ex in g , 236
W ork activ ities, 24
W ork flow , 198
W o rk sp aces, 2 1 3 , 217. S e e a ls o G lo b al
w o rk sp a c e s; L o cal w o rk sp ace s.
W orld W id e W eb (W eb / W W W ), 120-122,
126, 224
W o rld w id e S o ftw a re R e so u rc e D irecto ry , 122
W W W . S e e W orld W id e W eb.

X
X B itm ap s, 137
X W in d o w s, 221. S e e a ls o In terface A rch itect,
x m an , 119

Y
Y ellow P ag es, 191

Z
Z -S ch em a, 114, 139