\documentstyle[12pt]{article} \topmargin=-0.25in \textheight=8.75in
\oddsidemargin=-0.25in \evensidemargin=-0.25in \textwidth=7.0in

\begin{document}

\title{Pragmatic Approaches to Software Reuse\\
at BNR, Ltd.}

\author{Steven Fraser\\ \,\\Software Reuse Program,\\Computing
Research Laboratory,\\Bell-Northern Research Ltd.\\Box  3511,
Station C,\\Ottawa, Ontario, Canada.  K1Y 4H7\\ \,\\
sdfraser@bnr.ca}

\date{}
\maketitle

\begin{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.

\vspace{0.3in}
\noindent {\bf Keywords:} metrics, cloning, project management
\end{abstract}

\section{Introduction}

\indent\indent 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.

\section{Software Cloning and Indexing for Reuse}

\indent\indent 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 {\it 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 {\it
cloning\/}, a form of  {\it 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.

\section{The Designer as Customer?}

\indent\indent 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 {\it
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 {\it for reuse\/} will be
different from those designing {\it with reuse\/}.
Why should this be the case? While it is possible to specify a
methodology for building {\it with reuse\/}, only general guidelines
can be given for design {\it 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 {\it 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 {\it reuse-by-
convenience\/} and a regime where  {\it reuse-by-process\/} is
standard.

\section{Software Reuse Metrics}

\indent\indent Software metrics are used to determine the cost of
software development and its maintenance.  Metrics generally
evaluated include:

\begin{itemize}

\item  development interval: time to market

\item  productivity: designer output

\item  quality: defect rates

\end{itemize}

To promote reuse, rather than simply suggesting that software be
developed for  reuse (which really doesn't tell the designer {\it
what\/} or {\it 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.

\section{Reuse Process Management}

\indent\indent 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:

\begin{itemize}

\item  {\bf Standard forms?\/} Unlike integral calculus, software
engineering  has  not evolved to the point where detail can be
avoided entirely.  For example, tables of {\it software forms\/} are
not readily available for easy identification nor are {\it 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.

\item  {\bf 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.  {\it 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. \end{itemize}

From our experience, it is not possible to stop the product delivery
process to  introduce {\it 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.

\section{Summary}

\indent\indent Several pragmatic approaches to software reuse have
been presented.   We close with the observations that:

\begin{itemize}

\item  software reuse presents major cultural-process challenges
that require  significant management commitment  for success (reuse
will not just happen).

\item  software reuse is not free:  business decisions must be taken
{\it in context\/}   to determine the appropriate strategy for success
(not everything is reusable everywhere).

\item  a greater emphasis should be placed on the evolution of
process and research   into the {\it cultural factors\/} that currently
inhibit reuse.

\end{itemize}


\section{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 always looking for "opera"tunities)!

\end{document}


