\section{Introduction}
We need to better understand software reuse.
In theory, 
reuse can lower
development cost, increase productivity, improve maintainability, boost
quality, reduce risk, shorten life cycle time, lower training costs,
and achieve better software
interoperability~\cite{Trauter98,Poulin97}.  However, in practice,
studies have shown that reuse is not always the best choice: it may be
hard to implement, and the benefits of reuse
cannot be reliably quantified~\cite{Trauter98}.
Also, in some cases, reuse has
resulted in
economic loses~\cite{Lions96Ariane} and even personal injury and
loss of life~\cite{LevesonTurner93}.
%Prior attempts to classify software reuse practices in order to characterize successes
%rely in the amount of modification a software component requires to be
%part of the new system.  For instance, if a software artifact is
%reused without modification, it is classified as {\em black-box} reuse and considered a best
%reuse practice.  On
%the other hand, if the piece of software requires any change to become
%suitable for use in a different project, then it is considered
%{\em white-box} reuse, and its benefits may be limited~\cite{Poulin97}.
%
%Software reuse is also classified as {\em systematic}, meaning that the
%reused components were intentionally developed to be reusable, or
%{\em accidental}, meaning that the reused artifact was originally developed
%for a single use but reused when the opportunity arise.  The latter
%is also known as {\em ad-hoc reuse} and is sometimes reported as
%re-engineering, not reuse~\cite{Poulin97}.
%
%Even with this more specific classification scheme and the theory 
%pointing to systematic black-box reuse as a clear winner, it has been
%found that approaching reuse is more complicated than it appears. For instance, when
%tuning COCOMO II using the multiple regression approach, the
%regression results produce a negative slope for the coefficient 
%associated with the project parameter for reuse processes called
%"RUSE"~\cite{Chulani98a}. This means that, according to local data,
%developing reusable software components costs less than developing
%them for one use. This result contradicts 12 published studies 
%documenting the high initial cost of systematically developing for 
%reuse~\cite{Poulin97}.
%
%In addition, ad-hoc white-box reuse has been found to be highly beneficial
%in some instances~\cite{IncorvaiaDavis90}, contradicting most experts
%opinions.
%These contradictions and the mixed success and failure results reported throughout the
%literature beg the question: 
%\bi
%\item Can we predict software reuse success based on what we know about a project?
%\ei
%In order to address this question, we need to define {\em success} in
%terms of software reuse processes. We believe that a successful reuse
%process should result in the realization of its most valuable and quantifiable
%reported benefits of reuse: reduce effort (cost and schedule), and improve quality.
%We therefore study predictors for effort {\em and} defects using:
%\begin{itemize}
%\item
%The COQUALMO defect estimation model~\cite[p254-268]{boehm00b};
%\item
%The  COCOMO effort estimation model~\cite[p29-57]{boehm00b}; 
%\end{itemize}
%
%These models use dozens of variables, not all of which are known with certainty.
%Furthermore, COCOMO and COQUALMO estimates are most accurate {\em after} the models been
%tuned to local data. Access to local tuning data is difficult, to say the least, but
%fortunately, there are alternatives to this problem~\cite{me08c}. STAR is a
%simulated annealer plus a Bayesian post-processor that explores
%{\em the space of possible local tunings} within software estimation models.
%This tool was first presented in~\cite{me07f}, and returns a minimal set 
%of project decisions that most reduce effort and defects using COCOMO and
%COCUALMO models.
%STAR ranks project decisions by their effects on effort
%and defects. A suitable tool for the goal at hand.
%%%%%%%END OF PARAGRAPHS TO BACKGROUND FOR CONF
%In this study we will further constrain project parameters to inject the
%effects of software reuse in increments as described in \fig{rchange}.

Process simulations can be used to assess the value of reuse in a particular project.
Traditionally, such simulators are commissioned using using data collected
from a particular organization (e.g.~\cite{raffo95}).
Often, such local data is hard to collect. Accordingly, we have been
been exploring an AI method called STAR that reduce the need for calibration from local data.
To understand STAR, note that project estimates are
some function of the project
options and the internal model calibration variables. Conceptually, we can write this as:
\[estimate = project * calibration\]
The estimate variance is hence a function of {\em variance in the project 
options} and the {\em space of possible calibrations}. Traditional approaches 
use historical data to reduce the space of possible calibrations (e.g. 
using regression). In our approach, we leave the calibration variables 
unconstrained and instead use an AI search engine to reduce the space 
of possibilities in the project options. In numerous studies (including 
one reported last year at ICSP'08 and elsewhere~\cite{me07f,me08c,me09a}) we showed that 
this methods can yield estimates close to those seem using traditional 
methods, without requiring  a time consuming data collection exercise.

In this paper, we use STAR to comparatively asses 13 possible changes to a project.
\fig{rchange} shows four changes to a project based on reuse while
\fig{dchange} defines some alternatives. These alternatives are drastic changes a 
project manager could implement in an effort to reduce effort, schedule 
and defects in a particular project~\cite{boehm99}.
Our results will that show some projects gain the most benefit from applying reuse, there
are often other changes (such as those listed in \fig{dchange}) that can be more effective.
Hence, we recommend assessing the value of reuse on a project-by-project basis.
Process simulation tools are useful for making such an assessment and tools
like STAR are especially useful when there 
is insufficient data for local calibration.


\begin{figure}[!t]
{\scriptsize
\begin{tabular}{c@{~}p{.4\linewidth}p{.5\linewidth}}
&{\bf Reuse Iteration} & {\bf Description}\\\hline
&First reuse & Using software from a previous project for the first time.\\\hline
&Second reuse & Reusing software from a previous project for the second time\\\hline
&Third reuse & Reusing the same software in a new project for the third time.\\\hline
&Fourth reuse & Reusing software using a mature reuse approach, tools, and personnel.\\\hline
\end{tabular}
\caption{Process changes imposed by implementing reuse incrementally.}\label{fig:rchange}}
\end{figure}
%further constrain project parameters to inject the
%effects of software reuse in increments as described in \fig{rchange}.
\begin{figure}[!t]
{\scriptsize
\begin{tabular}{c@{~}p{.4\linewidth}p{.5\linewidth}}
&{\bf Drastic change} & {\bf Possible undesirable impact}\\\hline
1&Improve personnel & Firing and re-hiring personnel leading to wide-spread union unrest.\\\hline
2&Improve tools, techniques, or  
development platform & Changing operating systems, IDEs, coding languages\\\hline
3&Improve precedentness / \newline development flexibility &
Changing the goals
of the project and the development method.\\\hline
4&Increase architectural \newline analysis /  risk resolution &
Far more elaborate early life cycle analysis.\\\hline
5&Relax schedule  & Delivering the system later.\\\hline
6&Improve process maturity & May be expensive in the short term.\\\hline
7&Reduce 
functionality & Delivering less than expected.\\\hline
8&Improve the team & Requires effort on team building.\\\hline
9&Reduce quality 
& Less user approval, smaller market.\\\hline
\end{tabular}
\caption{Nine drastic changes from~\cite{boehm99}.}\label{fig:dchange}}
\end{figure}

In the remainder of this paper, we present background information about
software reuse and process estimation models. Then we 
document the simulation approach utilized to evaluate the effects
of adopting software reuse compared to alternative strategies for two NASA
case studies.

