A Control-Theoretic Aid to Managing the Construction Phase in Incremental
Software Development (Extended Abstract)
Scott D. Miller
Department of Computer Science; Purdue University
millersd@cs.purdue.edu
Advisors: Aditya P. Mathur (CS) & Raymond A. DeCarlo (ECE)
1. Research Overview
We propose to adapt the techniques of state-
modeling and feedback control from the discipline of
Control Engineering to the tasks of software process
modeling and software process control as they appear in
Software Engineering. The scope of our investigation is
focused on the construction phase (as per the Rational
Unified Process) as it occurs in industrial incremental
software development.
2. Contributions
The completion of this project will yield the fol-
lowing contributions: i) A customizable, quantitative,
software process simulation whose output is a predic-
tion of the project schedule which will result if the
development process is left to execute unaltered; ii)
A model (re-)calibration technique capable of captur-
ing productivity trends as they develop during the con-
struction phase resulting in adaptive process modeling;
and iii) A control technique capable of determining
the parameter changes required in the model to drive
the model output (i.e. plots of the remaining work
over time) to the best (with respect to a convex perfor-
mance index, and a linearized, discretized version of the
model) approximation of a given “desired” output. This
provides a quantitative set of data to support manage-
ment decision-making.
2.1. Motivation
It is currently estimated that the IT industry loses
$60 billion – $70 billion per year in the United States
due to budget over-runs, project cancellation, poor
quality/reliability, and consequent litigation [7]. The
literature reports a set of factors linked to software
project failure, among which are: i) the failure to mon-
itor project progress/milestones; and ii) inadequate re-
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
source estimation [7].
These factors are exacerbated by conflicts of inter-
est, e.g. i) developers are reluctant to report the fail-
ure to achieve schedule objectives to management when
it may impact future performance evaluations or com-
pensation incentives; e.g. ii) managers may experience
pressure from competitors (or perhaps upper manage-
ment) to lower the project overhead and may conse-
quently attempt to stretch resources beyond their capa-
bility. In these cases, a set of quantitative tools may
provide a much-needed objective view into the devel-
opment process, its true progress, and the likelihood
of project success given the current resource alloca-
tions. Furthermore, given a prediction of deviation out-
side control limits, a quantitative process control tool
could help to determine the best method of salvaging
the project, or whether it would be more cost-effective
to cancel the project.
3. Problems and Current Approaches
3.1. Modeling and Simulation
In this discussion we shall focus on what Scacchi
distinguishes as descriptive models [12] which answer
the question, “what is the character of the process that I
have?” e.g. [3, 5]. The problems associated with build-
ing descriptive models may be stated in terms of the bal-
ance between the level of detail captured by the model,
the ability to calibrate the model, and the ability to an-
alyze the model. Bounding the spectrum of predictive
modeling and simulation techniques are the COCOMO
family of models [3], and the in-house, organization-
specific system dynamics models developed using com-
mercial tools such as Extend1 In the case of COCOMO,
the result is a single scalar project effort estimate—
some detail may be added back into the prediction by
1 Extend is a registered trademark of Imagine That, Inc.
 use of statistical/heuristic tables that divide the effort
estimate into effort per phase. Analysis of the impact of
a parameter change in the COCOMO model is simple
given its closed form. On the other end of the spectrum
are the custom system dynamics models; such systems
offer the temptation to capture finer-grained process de-
tail at the cost of larger data needs (e.g. calibration of
multiple probability distributions) and near-opacity to
analysis.
With nearly a half-century of literature on predic-
tive modeling, there are too many techniques to cover
here. Our intent here is to identify the balance be-
tween model detail, data requirements, and analytical
transparency, as a criterion for evaluation. Two related
works, however, require attention here.
Madnick and Abdel-Hamid [1] are credited with an
early attempt at applying state modeling techniques for
modeling software processes. Their work predicts pro-
cess behavior from a much higher level (i.e. the behav-
ior of the waterfall development phases.)
Recently, Cangussu [5] proposed a state-based
model of the software System Test Phase and applied
a simple control technique to aid the manager of a test
process in mitigating schedule slippage. The model has
been industrially validated, and the controller has been
demonstrated through simulation. We have proposed
an improved controller [11] for the model given in [5]
which, as with our present work, is based on Model Pre-
dictive Control [4].
3.2. Control
Literature in Software Process Control has focused
on the task of monitoring and adjusting software pro-
cesses so that they remain within acceptable limits of
operation. Among the approaches are statistical pro-
cess control e.g. [6, 9], defined by the philosophy that
“...as long as you perform a process consistently it will
demonstrate consistent results...” [6], discrete event and
hybrid simulations with the familiar “what-if” mecha-
nism for determining process change [10], and process
simulation for the purpose of process comprehension
[2].
Statistical process control requires the reuse of pro-
cess in order to attempt to reproduce the past results.
For projects crossing into new domains the statistical
baseline may be invalid or inappropriate, making adap-
tation a desirable attribute.
The discrete-event and hybrid simulation methods
support this on-line re-calibration, but often support
only the familiar trial-and-error method for determining
appropriate process changes. Given a complex model,
the trials required may be time consuming, and without
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
knowledge of the parameter sensitivity and interaction,
the “what-if” process may be chaotic.
4. Our Approach
4.1. Process Modeling and Simulation
We have identified seven processes which dominate
the effort-consumption during the construction phase;
these are feature coding, test case coding, test case ex-
ecution: new tests, test case execution: regression, fail-
ure analysis, feature correction, and test case correc-
tion. We begin by building a model of the flows between
these processes; each process produces work product
and by-products which flow to the other processes for
processing/consumption. This flow model provides the
framework for descriptions of the construction phase;
it is customized to a particular process by defining the
flow rates as a set of functions in the productivities of
the processes.
4.1.1. Modeling Process Productivity. Software de-
velopment is a set of information processing activi-
ties. As such, we build a common model of produc-
tivity based on three assumptions: i) Productivity is im-
pacted by the size of the workload. Based on the phe-
nomenon of ‘flow’ [8], productivity is reduced if the
workload of a process becomes either too large or too
small; ii) There is information-processing inertia. This
is the idea that, given a demand for increased produc-
tivity, one must acclimate to the new pace, i.e. instanta-
neous productivity change is not possible; and iii) There
is information-processing resistance: is not possible to
achieve an arbitrary productivity increase—there is a re-
sistance which yields diminishing returns on productiv-
ity improvement effort.
4.1.2. The State-Model Representation. State-
modeling begins by identifying the set of quantities
which impact the behavior of the system, and proceeds
by specifying the manner in which the quantities
change over time (typically using differential equa-
tions.) In our case, we track the productivity, work
arrival, and derivatives of these, for each process. To
maintain a quality model, we also track quantities
derived from these to support fault-injection- and
test-failure- submodels.
4.1.3. Modeling Work Arrival. The work-arrival rate
(or in-flow) for a process is allowed to be any scalar
function defined in the set of state variables. This is the
manner by which one may customize the flow model to
a particular development process.
 4.1.4. The Fault and Failure Submodels. Based on
the commonality of defect density metrics, we have
adopted a linear fault injection model. The test-failure
submodel is based on the Lotka-Volterra predator-prey
population model [13] as used in [5] where the failure
model has been industrially validated in the context of
test failure/fault removal progress prediction.
4.1.5. Modeling Discrete Events. Consider that the
project schedule specifies when collections of features
are to be implemented by the coders, also, some pro-
cesses may block until the completion of artifacts from
other processes. Thus upon certain events, additional
work items will enter the processes, in turn propagating
work item flow to the other processes. These events
may be specified as any boolean combination of in-
equalities in the state variables. They are relaxed and in-
corporated into the productivity differential equations,
and thus are automatically observed during simulation.
4.1.6. Simulation. The system of differential equa-
tions which describe the model are solved numerically,
yielding plots of the work items remaining in the system
over time—a representation of the schedule.
4.2. Process Control
Our approach to process control is based on Model
Predictive Control (MPC) [4], a technique suited to in-
corporate a changing environment and, indeed, chang-
ing goals.
4.2.1. Performance Index. Our performance index is
constructed to quadratically penalize deviations from
the given “desired state trajectory” and the magnitude of
the control input; the minimization of the performance
index balances the cost of making the process changes,
against that expected with no changes.
4.2.2. Linearization and Discretization. Evaluating
the performance index requires the future state trajec-
tory. By linearizing and discretizing the model equa-
tions, we can derive a series of step-matrices that con-
vert the state at time t to the state at time t + 1; by
applying these rules recursively, and substituting this
representation of the future state trajectory into the per-
formance index, we arrive at a (convex) program to be
minimized over the control variables.
4.3. Calibration
The model is intended to be calibrated from data
generated by the current project; thus repetition of the
calibration algorithm allows the model to adapt as the
Proceedings of the 30th Annual International Computer Software and Applications Conference (COMPSAC'06)
0-7695-2655-1/06 $20.00 © 2006
process dynamics change, or simply to acquire a better
calibration as more data becomes available.
5. Current Progress
We have completed the modeling framework de-
scribed in § 5.1, and have implemented the basic min-
imization of the performance index in § 4.2.2. We are
currently working on the following tasks: i) Generating
the model calibration routines; ii) Planning the valida-
tion study; iii) Developing more sophisticated resource
constraints in the controller/minimization routine.
References
[1] T. Abdel-Hamid and S. E. Madnick. Software Project
Dynamics. Prentice Hall, 1991.
[2] C. Andersson, L. Karlsson, J. Nedstam, M. Host, and
B. Nilsson. Understanding software processes through
system dynamics simulation: a case study. In Proceed-
ings of the Ninth Annual IEEE International Conference
and Workshop on the Engineering of Computer-Based
Systems, pages 41 – 48, April 2002.
[3] B. W. Boehm et al. Software Cost Estimation with Co-
como II. Prentice Hall, 2000.
[4] E. F. Camacho and C. Bordons. Model Predictive Con-
trol. SpringerPublication, January 2004.
[5] J. W. Cangussu, R. A. DeCarlo, and A. P. Mathur. A for-
mal model of the software test process. IEEE Transac-
tions on Software Engineering, 28(8):782 – 796, August
2002.
[6] D. Card. Statistical process control for software? IEEE
Software, 11:95 – 97, May 1994.
[7] R. N. Charette. Why software fails. IEEE Spectrum,
42(9):42–49, September 2005.
[8] M. Csikszementmihalyi and I. S. Csikszementmihalyi,
editors. Optimal Experience: psychological studies of
flow in consciousness. Cambridge University Press,
1988.
[9] P. Jalote and A. Saxena. Optimum control limits for
employing statistical process control in software pro-
cess. IEEE Transactions on Software Engineering,
28(12):1126 – 1134, December 2002.
[10] R. Martin and D. Raffo. Application of a hybrid process
simulation model to a software development project. In
Proceedings of PROSIM, pages 237–246, July 2000.
[11] S. D. Miller, R. A. DeCarlo, A. P. Mathur, and J. W.
Cangussu. In Press. a control-theoretic approach to the
management of the software system test phase. Journal
of Systems and Software., 2006.
[12] W. Scacchi. Process models in software engineering.
Encyclopedia of Software Engineering, 2nd Edition,
John Wiley and Sons, Inc., October 2002.
[13] V. Volterra. Variazioni e fluttuazioni del numero
d’individui in specie animali conviventi. Mem. R. Ac-
cad. Naz. dei Lincei. Ser. VI, 2, 1926.