%\section{Preliminaries}
\input{cocomo}

\section{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 validating one of such models 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. 


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

A final assumption on the size of the software comes from the
observation that the progressive reuse of software components allows
the construction of more sizeable systems. For instance, when looking
at NASA Space fligh software, new systems commonly result in bigger
and more complex software, usually about 50\% more lines of code \cite{orrego07}.
Of this kloc increase NASA developers may only be able to save a small percentage
of the size of the code base by reusing components due to their ad-hoc,
white-box reuse approach, which results in sizeable modification of the
original code \cite{orrego06}.
In our simulations we therefore assume that the code base increases
from system to system by 25\%.

\fig{rhow} shows the constraints we claim software reuse imposes on
model parameters for a given project. In the figure the variable $X_L$
represents the lowest value in the range of the model variable X.
Similarly, $X_H$ represents the highest value for the X variable.  In
order to impose the constraint of reuse in a particular project we
increase the $X_L$ and lower the $X_H$ for the particular variable X
according to the logic above. For instance, let's say that for a particular
project $P$, pcap ranges between 2 and 4, and pvol ranges between 3 and 5. 
In this case, PCAP$_L=2$, PCAP$_H=4$, PVOL$_L=3$, and PVOL$_H=5$. if we
imposed a ``Second Reuse'' strategy, pcap would be set to 3 (PCAP$_L+1$), and
pvol would be set to 4 (PVOL$_H-1$).


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

1& First Reuse  & acap = ACAP$_L$ ; apex = APEX$_L$ ; pcap = PCAP$_L$; prec = PREC$_L$ \newline 
                  pmat = PMAT$_L$ ; ltex = LTEX$_L$ ; pvol = PVOL$_H$; kloc = KLOC$_L$ \\\hline
2& Second Reuse & acap = ACAP$_L$+1 ; apex = APEX$_L$+1 ; pcap = PCAP$_L$+1 ; prec = PREC$_L$+1 \newline 
                  pmat = PMAT$_L$+1 ; ltex = LTEX$_L$+1 ; pvol = PVOL$_H$-1 ; kloc = KLOC$_L$*1.25 \\\hline
3& Third Reuse  & acap = ACAP$_L$+2 ; apex = APEX$_L$+2 ; pcap = PCAP$_L$+2 ; prec = PREC$_L$+2 \newline 
                  pmat = PMAT$_L$+2 ; ltex = LTEX$_L$+2 ; pvol = PVOL$_H$-2 ; kloc = KLOC$_L*(1.25)^2$ \\\hline
4& Fourth Reuse & acap = ACAP$_L$+3 ; apex = APEX$_L$+3 ; pcap = PCAP$_L$+3 ; prec = PREC$_L$+3 \newline 
                  pmat = PMAT$_L$+3 ; ltex = LTEX$_L$+3 ; pvol = PVOL$_H$-3 ; kloc = KLOC$_L*(1.25)^3$ \\\hline
\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}[!t]
{\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}
