\section{Preliminaries}
\input{cocomo}

\subsection{The Models: COCOMO and COQUALMO} 

For this study we use two USC 
software process models.
The COQUALMO software {\em defect} predictor~\cite[p254-268]{boehm00b}
models
two processes (defect introduction and defect removal)
for three phases (requirements, design, and coding).  
Also, the
COCOMO software {\em effort} and development {\em time} predictor~\cite[p29-57]{boehm00b}
estimates
development months (225 hours) and calendar months and includes all coding,
debugging, and management activities.
COCOMO assumes that
effort is exponentially proportional to some {\em scale factors} and
linearly proportional to some {\em effort multipliers}.  

From our perspective, these models have several
useful features.
Unlike other models such as PRICE-S~\cite{park88}, 
SLIM~\cite{putnam92}, or SEER-SEM~\cite{jensen83},
the COCOMO family of models
is fully described in the literature. Also, at least
for the effort model, there exist  baseline results~\cite{chulani99}. 
Also,
we work extensively with government agencies writing software.
Amongst those agencies, these models are frequently used to generate
and justify budgets.
Further,
The space of possible tunings within COCOMO \& COQUALMO
is well defined. Hence, it is possible
to explore the space of possible tunings.

The process simulation community (e.g., Raffo~\cite{raffo05c}) studies
models far more elaborate than COCOMO or COQUALMO. 
For example, COCOMO \& COQUALMO assume linear parametric equations
while other researchers explore other forms:
\bi
\item
discrete-event models~\cite{kelton02};
\item
system dynamics models~\cite{hamid91}; 
\item
state-based models~\cite{martin00};
\item
rule-based programs~\cite{mi90}; 
\item standard programming constructs
such as those used in Little-JIL~\cite{cass00}.
\ei
These rich modeling frameworks
allow the representation of 
detailed insights into an organization. However,  the effort required
to tune them is non-trivial. For example, Raffo spent two years
tuning and validation one such model to one particular site~\cite{raffo95}.
Also, we have found that 
the estimation variance of COCOMO
can be reduced via intelligent selection of input variables,
even allowing for full variance in the tuning parameters.
We would consider switching to other models if it could
be shown that the variance of these other models could be
controlled just as easily.




Our models use the features presented in \fig{cparams}.
This figure lists a variety of project {\em features} with the 
{\em range}
\{very low, low, nominal, high, very high, extremely high\} or
$\{vl=1, l=2, n=3, h=4, vh=5, xh=6\}$.
For specific projects, not all features are known with
certainty.  For example, until software is completed, the exact size of
a program may be unknown. Hence, exploring our effort, schedule, and defect models
requires exploring a large trade-space of possible model inputs. 

%%%% COCOMO PARAMS GO HERE
%%%% END COCOMO PARAMS



\subsection{Effect of Reuse on Model Parameters}

The effects of
ad-hoc software reuse can be mapped to changes to settings to the COCOMO 
parameters. For
instance, programmers capability (pcap) inherently increases
every time a piece of software is reused given that in the process the
same programmer is employed. This is the case with NASA spacecraft
software, where reuse can be found within the same software
development company and where the software modules are signed by the
same developers \cite{orrego05}. Similarly, we can assume direct
inherent effects to the analyst capability (acap), the application
experience (apex), the analyst capability (acap), the precedence of
the software (prec), the process maturity (pmat), and the language
and tool experience (ltex). On the other hand, the software platform
must remain fairly unchanged throughout reuses so software pieces can 
be reused with ease. For this reason we assume that platform volatility
has to decrease as a piece of software is reused from project to project.

In summary, \fig{rhow} shows the constraints we claim software reuse imposes
on model parameters. 


\begin{figure}[!t]
{\scriptsize
\begin{tabular}{c@{~}p{.4\linewidth}p{.5\linewidth}}
&{\bf Incremental Reuse} 
& {\bf Effects on Projects} \\\hline

1& First Reuse & acap = 3; apex = 3 ; pcap = 3 \newline 
                 prec  = 3 ; pmat = 3 ; ltex = 3; pvol = 3 \\\hline
2& Second Reuse & acap = 4; apex = 4 ; pcap = 4 \newline 
                 prec  = 4 ; pmat = 4 ; ltex = 4; pvol = 2 \\\hline
3& Third Reuse & acap = 5; apex = 5 ; pcap = 5 \newline 
                 prec  = 5 ; pmat = 5 ; ltex = 5; pvol = 1 \\\hline
4& Fourth Reuse & acap = 6; apex = 6 ; pcap = 6 \newline 
                 prec  = 6 ; pmat = 6 ; ltex = 6; pvol = 1
\end{tabular}
}
\caption{Implementing software reuse incrementally.
}\label{fig:rhow}
\end{figure}



\subsection{Defining the Alternatives to Reuse}



Similarly to the constraints imposed by the incremental software reuse strategies,
\fig{how} defines the values we imposed on each case study as part
of each drastic change. 
Most of the values in \fig{how} are self-explanatory with two exceptions.
Firstly, the 
$kloc*0.5$ in ``reduce functionality'' means that,  when imposing this drastic change,
we only implement half the system.
Secondly, most of the features fall in the range one to five.
However, some have minimum values of 2 or higher (e.g., $pvol$ in ``improve tools/tech/dev''),
and some have maximum values of 6 (e.g., $site$ in ``improve tools/tech/dev'').
This explains why some of the drastic changes result in values other than one or five.

To impose a drastic change on a case study,
if that change refers to feature $X$ (in the right-hand column of \fig{how}),
then we
first
(a)~removed $X$ from the values and ranges of the case study (if it was present); then
(b)~added the changes of \fig{how} as fixed values for that case study.

\begin{figure}[!b]
{\scriptsize
\begin{tabular}{c@{~}p{.5\linewidth}p{.4\linewidth}}
&{\bf Drastic change} 
& {\bf Effects on Projects} \\\hline

1&Improve personnel 
& 
acap = 5; pcap = 5;
                    pcon = 5 \newline 
                    apex  = 5 ;
                    plex = 5 ;
                    ltex = 5 \\\hline
2&Improve tools, techniques, or  development platform 
& 
    time = 3; 
                    stor = 3\newline
                    pvol = 2;
                    tool = 5\newline
                    site = 6\\\hline
3&Improve precedentness / development flexibility 
&
prec = 5;
flex = 5
\\\hline
4&Increase architectural analysis /  risk resolution 
&resl = 5
\\\hline
5&Relax schedule  
& 
    sced = 5      
\\\hline

6&Improve process maturity 
& pmat = 5
\\\hline

7&Reduce \newline
functionality 
& 
 data = 2; 
                    kloc  * 0.5
\\\hline
8&Improve the team 
&
team = 5 
\\\hline

9&Reduce quality 
& 
  rely = 1 ;
                    docu = 1\newline
                    time = 3 ;
                    cplx = 1
\end{tabular}
}
\caption{Implementing drastic changes.
}\label{fig:how}
\end{figure}
