Pragmatic Approaches to Software Reuse at BNR, Ltd.
Steven Fraser
Software Reuse Program,
Computing Research Laboratory,
Bell-Northern Research Ltd. Box 3511,
Station C, Ottawa, Ontario, Canada. K1Y 4H7
sdfraser@bnr.ca
Abstract
An overview of our research on software reuse is presented in the context
of BNR's large software legacy of more than 15 million lines of real-time
software. Some of the general research areas under investigation include:
software cloning; software indexing; reuse metrics; and reuse project
management.
Keywords: metrics, cloning, project management
1 Introduction
BNR develops a wide range of telecommunication products for public/private
networks. DMS (Digital Multiplex System) is an evolving central office switch
system with over 15 million lines of code developed by over 1200 designers
located at labs worldwide and released two to three times a year. Reuse is
part of our development strategy: there is one development process (BCS
- Batch Change Supplement) across all sites; development tools have
consistent look and feel; and a proprietary software library system
maintains versioned requirements, designs and software. BNR
software designers participate at all stages of the software
development cycle, i.e. requirements analysis, design,
implementation, designer testing, and problem resolution. BNR's
software process is primarily focused on the development of
enhancements and extensions to a system that requires a very high
degree of reliability and customer satisfaction.
2 Software Cloning and Indexing for Reuse
Several different strategies for reuse are applied:
design model reuse (reuse of designs for different, but similar
applications); switch operating system base utilities (reuse of
components and architectures); code cloning, re-engineering
and designer reuse. Designer reuse is the somewhat obvious reuse
of expertise by individual designers. Re-engineering has been
applied at several levels, first to split off common functionality for
reuse, e.g. utilities, and second to improve performance, which is
often seen as an obstacle to reuse in real-time systems. Code
cloning, a form of copy-and-edit, provides tremendous leverage. For
example, risk is minimized in making modifications to
the production system while facilitating specialization for new
applications, e.g. template reuse. The down-side of cloning is rapid
code growth and increased complexity.
A CD-ROM based tool has been made available to designers to assist
them in rapidly locating relevant software with keyword searches.
However, further research is required to determine the influences of
templates on the effectiveness of reuse. We have observed that the
cultural problems are as important (if not more so) than the technical
issues: Designers must be able to trust and quickly understand
software written by others.
3 The Designer as Customer?
Within the DMS BCS delivery process there are several levels of customer: The
primary customer is the end-user of a telephony feature while the secondary
end-user is a telephone operating company. Customers within BNR such as
designers who reuse software written by others are not really considered as
customers because they are not an obvious source of revenue. Consideration of
the individual designer and project teams as the customer for software reuse
could result in substantial development savings. The benefits of reuse,
particularly in the short-term, are difficult to visualize in a production
environment driven by short development cycles and limited market windows.
The initial impetus must be driven by a global-corporate perspective of the
benefits.
From a designer perspective, there are a number of reuse inhibitors
that must be addressed before a cultural evolution can proceed.
First we assume that the distinction between reuse producers and
reuse consumers is important - probably to the extent that designers
designing for reuse will be different from those designing with reuse.
Why should this be the case? While it is possible to specify a
methodology for building with reuse, only general guidelines can be given
for design for reuse. The incentives and cultures appear to be different.
For example, application designers can follow a general methodology for
design with reuse, i.e.they can design and build robust software reusing
components (following the principles of software engineering,
e.g. reviews, inspections, testplans). Our experience has indicated
that designers, require extensive application or system experience
and motivation for effective reuse contributions. Application
designers are also driven by the narrow market windows which
govern their deliverables. Usually they don't have time to
experiment or consider applications beyond the scope of their
current deliverables. Additionally, no time is available to support
and educate other designers since this would reduce the time
available for feature development.
Experience and specialized expertise are essential for designers to be
considered as reuse specialists. For reuse to be explicitly provided,
it must become a deliverable with specific cost objectives, e.g. internal
client groups with target application areas and cost benefits. This is done
within BNR and is partly due to the critical mass of both design staff and
feature families (large application areas) that can benefit from reuse. As
the reuse methodology matures, a culture will develop that will promote reuse
on more of a day-to-day basis. However, this culture will only become evident
during the transition between the current regime of reuse-by-convenience and
a regime where reuse-by-process is standard.
4 Software Reuse Metrics
Software metrics are used to determine the cost of software development and its maintenance. Metrics generally evaluated include:
* development interval: time to market
* productivity: designer output
* quality: defect rates
To promote reuse, rather than simply suggesting that software be developed for reuse (which really doesn't tell the designer what or how to do reuse), it is
more instructive to develop metrics that measure the expected outputs of
software reuse. For example measure: the increased productivity; the number
of reusable components; and the quality of components built from reusable
components.
Metrics based on information gathered by surveys administered to members of our design groups in the postmortem phase of each BCS development cycle will be
evaluated, e.g. as an on-line questionnaire designed for rapid completion with
minimal effort. It is assumed that the information collected by this process
can be correlated to determine where reuse has met with success. Components
are assumed to include: functional requirements, design documents, code,
test plans, and other documentation components that might be reused. Proposed
survey questions focus on component evaluations, e.g. component: almost reused, but wasn't (why?); reused as-is; reused with minor modifications; reused with
major modifications (cloned); re-engineered to improve performance; merged with other similar components; and components created without any reuse.
5 Reuse Process Management
Part of our research on software reuse has focused on how the software
development process can be enhanced to improve reuse. Evaluation of the
process steps has highlighted the importance of analogies to help designers
understand the problems at hand. These analogies include:
* Standard forms? Unlike integral calculus, software engineering has not
evolved to the point where detail can be avoided entirely. For example,
tables of software forms are not readily available for easy identification
nor are software simplification techniques standard. A civil engineer, for example, does not go back to first principles to derive solutions to
general integral forms. Instead the problem is reduced to a standard form
by a simplification technique, such as integration by parts; partial
fractions; or coordinate transformations. Then an analytic solution can
be derived from a set of tables or a numerical solution calculated.
Software reuse has not evolved to this level of standardization either
from a solution framework perspective or standard software forms.
This is probably a characteristic of the immaturity of software engineering as a discipline rather than software reuse specifically.
* With Reuse or For Reuse? The analogy of plastic building blocks appears
appropriate. A child, when given blocks to play with, can implement the
most innovative designs. However, if a child is asked to create a new
block type, the interest and the motivation would not be there (nor are
the necessary skills and production facilities). In software reuse, the
analogy is that designers have different personal values and motivating
influences. These should be recognized and fostered. Core reuse groups
can be created to specialize in facilitating reuse. With this model of
reuse, the necessary rework and support required is viewed as an important
deliverable, rather than an overhead that can be sacrificed to meet market
pressures.
From our experience, it is not possible to stop the product delivery process to introduce reuse in one step. The greatest challenge with our research is to
introduce the benefits of a planned program of software reuse without
jeopardizing current market deliverables. A balance must be struck between
resources required to meet today's deadlines and those required for the for
system longevity.
6 Summary
Several pragmatic approaches to software reuse have been presented. We close
with the observations that:
* software reuse presents major cultural-process challenges that require
significant management commitment for success (reuse will not just happen).
* software reuse is not free: business decisions must be taken in context to determine the appropriate strategy for success (not everything is
reusable everywhere).
* a greater emphasis should be placed on the evolution of process and
research into the cultural factors that currently inhibit reuse.
7 About the Author
Steven Fraser is on staff at Bell-Northern Research's Computing Research
Laboratory (CRL) in Kanata, Ontario. The CRL provides BCE (Bell Canada
Enterprises) with a dedicated centre of computing expertise and serves as a
bridge from the research community to product development. Fraser is currently responsible for a research program on software reuse from both technical and
cultural perspectives. Since joining BNR in 1987, Fraser has contributed to
the Telos project, an OO-based CASE-Design Tool and to BNR's BCS software
development process. He completed his doctoral studies at McGill University
in Electrical Engineering in the spring of 1987. His research focused on the
validation of natural language specifications, particularly those of the
Graphics Kernel System (GKS). He holds a Master's degree from Queen's
University at Kingston in applied Physics and a Bachelor's degree from McGill
University in Physics and Computer Science.
In addition to research interests Fraser currently serves as the Chair of BNR's Ottawa Lab Council and the Secretary of its Corporate Lab Council. He is an
avid photographer and opera "buff" - averaging over 40 operas a year (he is
