\section{Background} 

Ad-hoc white-box reuse can be found in almost every
organization~\cite{Poulin97}.  This approach provides some up-front
savings in time, but its benefit is limited to the development phase
because the modified component has to undergo the remaining life cycle
phases as a new component.  Even during the development phase,
modifying a software component for adaptation introduces a learning
cost, the cost of understanding what the software component does and
how it does it.  This adaptation cost is often assumed to be linear
Constructive Cost Model \cite{COCOMOII}, but a study by Selby on 2,954
NASA software modules indicated that the learning curve is
non-linear~\cite{Selby89}. Accidental software reuse, therefore,
offers marginal benefits and low economic risk.

A more aggressive reuse approach, namely systematic black-box reuse,
leads to higher initial costs, therefore a higher economic risk, but
it also offers increased benefits~\cite{Poulin97}. 

Studies on projects developed by Motorola~\cite{Joos94},
Hewlett-Packard~\cite{GrissWosser95}, and various European
organizations~\cite{MorisioEt02} agree with Incorvaia and Davis on the
following factors that seem to contribute to successful reuse
projects:
\begin{itemize}
\item Top management involvement and support
\item Changing the organization’s culture to reuse 
\item Use of standards 
\item Reuse within a well-defined domain 
\item A library or centralized component repository 
\item Reuse related tools 
\item Well-defined software engineering methods 
\item Training on reuse 
\item Reuse-driven incentives
\end{itemize} 
Results from the above case studies reported benefits including higher
quality.

\subsection{On the Quality of Reusable Components} 
Most theories and empirical studies also conclude that software reuse
results in higher quality.  Lim reports a 51-percent reduction in
defect density in a reuse project by Hewlett-Packard compared to new
code, and states that "defect fixes from each reuse accumulate,
resulting in higher quality"~\cite{Lim94}.  A similar statement and
same reasoning is encountered in~\cite{LynexLayzell97}.  In another
study on Ericsson, Mohagheghi found that reuse reduced the defect
density by 50 percent in unmodified code, and a smaller reduction was
achieved by modified components~\cite{MohagheghiEt04}.
Another studied claimed a 50 to
80\% reuse level and a compression of the schedule by a factor of 3 to
5~\cite{IncorvaiaDavis90}. 

Reuse may not require elaborate infrastructure.
In one study by Incorvaia and
Davis~\cite{IncorvaiaDavis90}, the performance of six projects was analyzed.
These projects were developed by five organizations: Digital
Equipment Corporation (DEC), BTG Inc., the U.S. Army, Raytheon
Company, and Hartford Insurance.  
Contrary to the hypotheses of most
reuse experts, unplanned reuse be highly
beneficial.  
For example, BTG Inc., claimed a 50 to
80\% reuse level and a compression of the schedule by a factor of 3 to
5, following an ad-hoc strategy.

Higher quality is certainly an exploitable benefit, therefore 
it is not surprising that agencies like the FAA, which certifies the
software in airborne systems, seek benefit from reuse.  One concern
about reuse by agencies that develop and support safety-critical
systems is the risk involved in reusing software components and how to
mitigate it.  The FAA has tight regulations on reusable software
components and therefore
provides a process to approve reused software life cycle data~\cite{FAA8110.49}.
Reusable software components have to be certified, and the FAA has
strict regulations to approve software reuse.  This agency states that
a reusable component may be approved for integration in a larger
system if: "1) There is no adverse effect on original system safety
margins, and 2) There is no adverse effect on original operational
capability UNLESS accompanied by a justifiable increase in safety."
The order also states that the FAA will not approve a reusable
software component if its reuse: "1) Adversely affects safety, 2)
Exceeds a pre-approved range of data or parameters, or 3) Exceeds an
equipment performance characteristic."

The FAA also addresses the changes to reusable software components, that
is, how white-box reuse affects the certification of the component~\cite{FAA04AC}.
New certification of the modified software
component has to be attained before it is approved for reuse.

Rigorous measures like the FAA's may appear unnecessary in most
industrial circumstances, but safety-critical and mission-critical
software systems have failed in the past due to reuse.  

On the other hand, Leveson and
Turner~\cite{LevesonTurner93} report a series of accidents partially
attributed to software reuse in a different context.  In their study,
they explain how software from the medical electron accelerator
for irradiation of certain cancers, the Therac-6 into the Therac-25,
the environment changed by switching from hardware-controlled
safety features to a more software-oriented approach.  Software reuse
in such a different context affected the performance of
safety-critical components. "Reuse of Therac-6 design features
or modules may explain some of the problematic aspects of the 
Therac-25 software~\cite{LevesonTurner93}.  At least two people died
as a consequence of the Therac-25 malfunctions, and other people
suffered life-threatening burns.  

The explosion of the Ariane 5
rocket, launched by the European Space Agency (ESA) in 1996, serves as
another example where software reuse was partially responsible for
loss, in this case the loss of the rocket and its cargo, valued at
\$500 million.  A report by the Inquiry Board set up by ESA to analyze
the incident concludes that the erroneous flight path and subsequent
breakup and explosion of the spacecraft 40 seconds after lift off was
caused by a failure in the flight control system, particularly in the
Inertial Reference System ~\cite{Lions96Ariane}.

%In the documents,
%the board explains how the reuse of Ariane 4 inertial reference system
%in Ariane 5 inherited a limit in the horizontal velocity.  This limit
%was exceeded by Ariane 5 as it had a higher initial acceleration and a
%different lift off trajectory.  This contextual change from Ariane 4 to
%Ariane 5 caused a limit violation that resulted in the complete loss
%of guidance and attitude information 30 seconds after lift off, leaving
%the entire system inoperable.
Adequate analysis and testing of the
inertial reference system could have detected the potential failure,
but it is possible it was not done since the system was reused from
the successful Ariane 4.  Therefore it could have (wrongly) been
assumed that the software was correct.

%\subsection{Reuse at NASA}

Even at NASA, software reuse plays a significant role in developing their
systems. For instance, spacecrafts communicate back and forth with
ground stations in Earth. A subsystem, often called Command and Data
Handling (C\&DH), performs this task by executing a series of software
functions.  This component is often reused by similar new missions.
More information about the extent and nature of software reuse in NASA
spacecraft systems is presented in~\cite{orrego06,orrego07}.

Like in industry, software reuse at NASA also presents risks.  Such risks are
significantly greater for space missions, where even a single
software component can result in catastrophic mission failure.  This
was the case of the Mars Climate Orbiter (MCO).  Approximately nine months
after launch, communication was lost as MCO was occulted by Mars on
Mars Orbit Insertion (MOI). 
MCO reused the "Small Forces" file from Mars Global Surveyor (MGS),
but introduced a new vendor-supplied thruster equation, which returned
data values in metric units, N-s \cite{Leveson04}.  This
resulted in the MCO approaching too close to Mars, and either burning
up in the Martian atmosphere, or failing to achieve Mars orbit and
entering heliocentric orbit.


In summary, reuse is not always beneficial or always dangerous. Rather, the value
of reuse needs to be assessed on a case-by-case basis. In the sequel, we show how
to perform such assessments using our
AI search engine.

