>aVEV
HD28
.M414
IMAR 16 1988
U ,^$0-U
ALFRED
P.
WORKING PAPER
SLOAN SCHOOL OF MANAGEMENT
MODELING THE DYNAIIICS OF
SOFTWARE PROJECT MANAGEMENT
Tarek K. Abdel-Hamid
Stuart E. Madnick
February 1988
#WP 1980-88
MASSACHUSETTS
INSTITUTE OF TECHNOLOGY
50 MEMORIAL DRIVE
CAMBRIDGE, MASSACHUSETTS 02139
MODELING THE DYNAMICS OF
SOFTWARE PROJECT MANAGEMENT
Tarek K. Abdel-Hamid
Stuart E. Madnick
February 1988
#WP 1980-88
MODELING THE DYNAMICS OF SOFTWARE PROJECT MfiNRGEMENT
By
Tarek K. Obdel-Hamid
Naval Postgraduate School
Stuart E. Madnick
Massachusetts Institute of Technology
January,
1988
Submitted for publication to the Cornrnunication5_of_the_QCM
.
ARIES
1
MODELING THE DYNAMICS OF SOFTWARE PROJECT MANAGEMENT
Abstract
The development of software systems has been marked by cost
overruns, late deliveries, poor reliability, and users' dissatisfaction.
The problems persist in spite of significant advances in the software
engineering field to tackle the technological hurdles of software
production. In recent years, the managerial aspects of software
development have been gaining increasing recognition as being at the
cores of both the problem and the solution.
The objective of this paper is twofold. First, we present a research
paradigm for the study of software project management that is grounded in
the feedback systems principles of system dynamics. Feedback processes
are universal in social systems in general, and we show how, when applied
to software project management, they do provide a powerful lens to view
and understand software project behavior.
Second, we summarize the stream of research findings obtained to
date. A system dynamics model of software project management has been
developed and is being used to study and predict the dynamic implications
of an array of managerial policies and procedures pertaining to the
management of software development.
,
;
INTRODLJCTigN
i
,
The impressive improvements that are continuously being made in the
cost-effect -veness of computer hardware are causing an enormous expansion in
the number of applications for which computing is becoming a feasible and
^
economical solution. This,
in turn,
is placing greater and greater demands
for the development and operation of computer software systems.
conservative estimate indicates
software each decade, or
(Musa,
a
a
A
"tenfold increase in the demand for
hundred fold increase between 1965 and 1985"
1985).
The growth of the software industry has not, however,
been painless.
The
record shows that the development of software has been marked by cost
overruns,
late deliveries,
[(Buckley and Poston,
poor reliability,
198A),
and users'
(Ramamoorthy et al.,
1984),
dissatisfaction
and
(Newport,
1986)3.
In an effort to bring discipline to the development of software systems.
attempts have been made since the early 1970s to apply the rigors of science
and engineering to the software production process.
This lead to significant
advances in the technol^ogy of software production (e.g., structured
programming,
structured design,
formal verification,
language design for more
reliable coding, diagnostic compilers, and so forth).
The fnaDi9§!!i§i aspects of software development,
on the other hand,
have
attracted much less attention from the research community [(Thayer et al.
1981),
(Zmud,
and
1960),
(Beck and Perkins,
19S3)].
,
Cooper (1976) provides an
insightful explanation for the reasons why:
Perhaps this is so because computer scientists believe that management
per se is not their business, and the management professionals assume
that it is the computer scientists' responsibility.
This "deficiency" in the field's research repertoire is being blamed by
a
growing number of researchers and practitioners for the £§!!iiitence of the
difficulties in producing software systems [(Pooch and Gehring,
(Thomsett,
1980),
and
(Weinberg,
1982)].
fl
1980),
chief concern expressed is that,
as of yet, we still lack a fundamental understanding of the software
development process,
find
without such an understanding the possibility or
likelihood of any significant gains on the managerial front is questionable
[(Basili,
1982)
and
(McKeen,
1983):.
This paper reports on a stream of research designed to address the above
Specifically,
concerns.
our goal
is to develop a comprehensive system
dynamics model of the software development process that enhances our
understanding
of,
provide insight into,
and make predictions about the
process by which software development is managed. The following examples
illustrate some of the critical management decisions that have been addressed
in this research effort:
1.
ft
project is behind schedule.
roviBB completion date,
staff,
Possible management actions include:
hold to planned completion date but hire more
hold to planned completion date but work current staff overtime.
etc.
£.
What are the implications of these alternatives?
How much effort should be expended on quality assurance and how does
that affect completion time and total cost?
3.
The impact of different effort distributions among project phases
(e.g.,
should the division of effort between' development and testing be
60:20 or 60:A0 percent?)
A.
The reasons for and implications of the differences between
productivity,
5.
actual, productivity,
potent ial^
and Be!2£?ived productivity.
Why does the "90>i syndrome" chronically recur?
In the remaining parts of this paper we present and discuss the
integrative dynamic model of software project management that has been,
developed.
We will provide an overview of both the model's structure and its
behavior followed by
presentation,
a
however,
discussion of the insights gained. We begin our
by first
presenting arguments for the utility of the
system dynamics modeling approach in the study of software project
management.
t
Ib!i_yiEH_CDMPLEXITY_gF_THE_SDFTWqRE_PRDJECT_MflN9^
Project management is often based on the simplistic "mental picture"
captured by the single-loop model shown in Figure
1
(Roberts,
1981).
The
model portrays how project work is accomplished through the utilization of
(1)
project resources (manpower,
accomplished on the project,
system.
forecast
it
facilities,
is reported
equipment),
(3)
fls
(2)
through some project control
Such reports cumulate and are processed to create the
cor.Tplet icr. tirr.E
remaining on the job.
work is
(A)
project's
by adding to the current date the indicated time
Assessing the job's remaining time involves figuring
out the magnitude of the effort
(e.g.,
be remaining to complete the project,
in man-days)
believed by management to
the level of manpower working on the
(c.)
SCHELULED COMPLETION
DATE
(1)
1
(6)
PEOPLE & OTHER
PROJECT RESOURCES
RESOURCE CHANGE &
ALLOCATION DECISION
t
WORK RATE
(2)
P^PORTED PROGPJISS
FORECAST COMPLETION
DATE
(3)
(A)
Figure (1)
A MODEL OF SOFTWARE PROJECT MANAGEMENT
.
and the perceived productivity of the project team.
project,
loop 15 completed
as the difference,
(closed)
scheduled completion date and the
adjustments
What
simple,
is
(6)
(A)
if any,
The feedback
between the
(5)
forecast completion date causes
in the magnitude or allocation of the project's resources.
attractive about the above model is that
and manageable.
But
is
it
it
is reasonable,
an adequate model of the dynamics of
software project management?
The software project management system is a far more complex conglomerate
of interdependant variables that are interrelated in various nonlinear
fashions.
By excluding vital aspects of the real software project
environment,
the above model could seriously misguide the unsuspecting
software manager. To see how,
decisions pondered in
a
let
us consider just a few of the many typical
software project environment.
8^^iD3_[22!Z§_E?2Ei§_t2_§_i§t§_BC2i?£i'
mental picture of Figure
"^^^
suggests a direct relationship between adding people resources
the rate of work on the project,
i.e.,
arid
1
increasing
the highnr the level of project
resources the higher the work rate. This ignores one vital aspect of software
' project
dynamics,
namely,
that adding more people often leads to higher
communication and training overheads on the project, which can in turn dilute
the project team's productivity.
Lower productivity trarislates into lower
progress rates, which can, therefore, delay the late project even further.
This,
in turn,
can trigger an additional round of workforce additions and
another pass around this "vicious cycle.
"
These dynamic forces create the
phenomenon often referred to as "Brooks' Law",
to a late software project makes
In Figure £a we,
therefore,
it
i.e.,
later (Brooks,
amend Figure
1
that adding more people
1978).
by incorporating the vital
link between the workforce level and productivity.
B^iyiliD3_tLl£_i£!:?^yl?_2f_»_t**?_E!:?i?Ei' finothtr p«rt of tht rt*l •yetam
that is ignored by Figure
1
concerns the impact of intangible project
SCHEDULED COMPLETION DATE
SCHEDULED COMPLETION DA'E
i
i
= ?00l£ & 0'"E9
PROJECT RESOURCES
RESOURCE CHANGE &
ALLOCATION OECiSiON
PEOPLE & OTHER
PROJECT resource:
RESOURCE CHANGE 8
ALLOCATION DECISION
A
PRODUCTIVITY
SCHEDULE
PRESSURE
-
/
PRODUCTIVITY
t
WORK RATE
FORECAST COMPLETION
.*DATE
WORK
FORECAST COMPLETION
-*DATE
PE'ORTEO PROGRESS
RATE
REPORTED PROGRE
(a)
\
SCHEDULEDCOMPLETiON DATE
,
SCHEDULEDCOMPLETiON DAT;
PEOPLE & OTHER
PPO.ECT RESOURCES
RESOURCE CHANGE &
ALLOCATION DECISION
A
i
RESOURCE CHANGE &
ALLOCATION DECISION
PEOPLE &OT"ER
PROJECT RESOURCES
'
TURNOVER
T
SCHEDULE
SC-iEDULE
-PRODUCTIVITY
PRESSURE
PRESSURE
A
WORK
RATE
REWORK
REWORK
PERCEIVED
^
REAL PROGRESS
PROGRESS
=
ORECAST COMPLETION
DATE
<-
REPORTED PROGRESS
FORECAST COMPLETION
DATE
^
"REPORTED PROGRESS
BIAS'DELAY
(0
id)
Ficure
(2 )
AMEND>!ENTS TO THE PROJECT MANAGEMENT MODEL
pressures (e.g.,
schedule pressures) on the software developers'
For example,
decisions.
actions and
when faced with schedule pressures that arise as a
software developers typically respond by
project falls behind schedule,
putting in longer hours and by concentrating more on the essential tasks of
the job (Ibrahim,
1978).
In one experiment,
Boehm (1981) found that the
devoted to project work increased by as much as
number of man-hours
100/'.
This additional link between schedule pressure and productivity is captured
in Figure 2b.
The impact of schedule pressures on software development
to the above relatively direct role.
visible roles. For example,
Schedule pressures
as Figure 2c suggests,
cari
is not
limited
also play less
schedule pressures can
increase the error rate of the project team and thus the amount of rework on
t
the project
[(Radice,
1982)
and
1983)].
(Mills,
People under time pressure don't work better, they just work faster ...
In the struggle to deliver any software at all, the first casuality has
been consideration of the quality of the software delivered (DeMarco,
1SB2).
The rework necessary to correct such software errors obviously diverts
the project team'
can have
Also,
a
effort from making progress on new project tasks,
s
and thus
significant negative impact on the project's progress rate.
consider the impact of schedule pressure on the workforce turnover
rate (Figure 2c).
There is evidence to suggest that workforce turnover
increases when scheduling pressures persist in an organization (Freedland,
1987).
This can be quite costly,
since
a
higher turnover rate translates into
lower productivity on the project.
EiniiiY:
bi2y_B§§iiY_U§t§_i§_a_Late_Software_Project ? Because software
remains largely intangible during most of the development process (Saber,
1982),
it
is often
the project.
difficult for project managers to assess real progress on
To the extent that the perceived progress rate differs from the
real progress rate,
an error
m
perceivec cumulative progress will gradually
accumulate (Figure 2d). Furthermore,
bias,
often in the form of overopt
and delay in gathering and processing control
imisrn,
information additionally
distorts the reported progress. This undoubtedly poses yet another
complication that is too real for the software project manager to exclude
from
a
model of the process.
'
e!^_Ib!Ii§BBII!^i_iYSTEM_DYN9MICS_PERSPECTIVE_DF_SgFTW9RE_DEVEL
The above discussion illustrates that there are
variables,
process.
both tangible and intangible,
Furthermore,
that
a
large number of
impact the software development
these variables are not independent,
one another in complex fashions.
Perhaps most importantly,
but are related to
understanding the
^iba^iSr o^ such systems is complex far beyond the capacity of human
intuition (Roberts,
fl
1S81).
major deficiency in much of the research to date on software project
management has been the inability to integrate our knowledge of the micro
components of the software development process such as scheduling,
productivity,
and staffing to derive implications about the behavior of the
total socio-technical system
(Thayer,
1979).
In the research effort
in this paper we build upon and extend what has been learnt
described
about the micro
components,
to construct a holistic model of the software development
process.
integrates the multiple functions of software development,
It
including both the management-type functions (e.g.,
staffing)
designing,
fi
planning,
as well as the software production-type activities
coding,
reviewing,
controlling,
(e.g.,
testing).
second unique feature of our modeling approach is the use of the
feedback principles of system dynamics to structure and clarify the complex
web of dynamically interacting variables. Feedback is the process in which
action taken by
thing.
a
ar\
person or thing will eventually affect that person or
Examples of such feedback systems in the software project environment
have alreaay been demonstrated in the above discussion and are evident in
Figures
1
and 2.
The significance and applicabilty of the feedback systems concept to
managerial systems has been substantiated by a large number of studies
(Roberts,
1981).
For example,
Weick (1979) observes that,
The cause-effect relationships that exist in organizations are dense and
often circular. Sometimes these causal circuits cancel the influences of
one variable on another, and sometimes they amplify the effects of one
variable on another. It is the network of causal relationships that
impose many of the controls in organizations and that stabilize or
disrupt the organization. It is the patterns of these causal links that
account for much of what happens in organizations. Though not directly
visible, these causal patterns account for more of what happens in
organizations than do some of the more visible elements such as
machinery, timeclocks, ...
One of the pioneering works in the field is Roberts'
doctoral dissertation,
which involved the development of
(1964)
a
published
comprehensive
system dynamics model of R&D project management. The model traces the full
lifecycle of
a
single
project,
RfiD
the R&D product, the firm,
atid
incorporates the interactions between
and the customer.
Roberts'
work spurred a large
number of system dynamics studies of project management phenomena. For
example.
Nay (1965)
and Kelly
on multi-project environments.
(1970)
extended Roberts'
work in their research
Richardson (1982) took a different tack,
focusing on the development group.
His model reproduces the dynamics of a
development group over an eight year period as
a
continuous stream of
products are developed and placed into production.
While the bulk of the system dynamics modeling work in the project
management area has been devoted to the R&D environment,
the applicability of
the methodology to the domain of software production has been alluded to in
the literature [e.g.,
(Snyder and Cox,
(Graham,
1985)].
1962),
(Lehman,
1978),
(Putnam,
1980),
Perhaps this should come as no surprise,
and
since "the
stages of research and development are similar in many respects to the stages
of software analysis and design (Gehring and Pooch,
1977).
In the remaining sections of this paper we demonstrate how the system
dynamics modeling technique was extended to the software project domain.
MQDEL_STRLICTLIRE_PND_BEH«VigR
Before describing the model and experiments performed,
there are several
points that are important to clarify. First, due to its length and complexity
only
a
paper.
portion of the entire model can be presented and explained in this
For more details the reader is referred to
(fibdel-Hamid and Madnick,
d;^narni_cs
of software projects;
the project,
Second,
1988)3.
that
[
(fibdel-Hamid,
198A)
the focus of this research is on the
aspects that change during the life of
is,
such as workforce level and productivity,
rather than aspects that
are decided once and usually remain constant throughout the project,
choice of programming language.
about what the model
is and
Third,
is not
relevant because this research,
is
it
necessary to have
intended to accomplish.
a
such as
perspective
This is particularly
as is most system dynamics work,
is primarily
intended to provide understanding of the dynamic behavior of a project
how variables like workforce-level and productivity change over time
'
rather than to provide goint^gred i_ct
and
i_on5
(e. g.
,
(e.-g.
arid
,'
why)
of the number of errors
generated).
The model was developed on the basis of field interviews of software
project managers in five organizations.
This was complemented by an extensive
database of empirical findings from the literature. Figure
model's four subsystems, namely:
(2)
(1)
depicts the
the Human Resource Management Subsystem;
the Software Production Subsystem;
the Planning Subsystem.
3
(3)
the Controlling Subsystem; and
(4)
The figure also illustrates some of the
intcrrclct icr.ships among the four subsystems.
iyi_yyMBN_5iSDyRCE_MflN0GEMENT_SyBSYSTEM
The Human Resource Management Subsystem,
shown in Figure
4,
captures the
Human
resource
management
WofK
force
avaiiacie
Work
force
neecaed
Software
proauction
SciTeduie
Planning
Controlling
tftcrt
V.
remaining
Figure
(3)
THE SYSTEM DYNAMICS MODEL'S FOUR SUBSYSTEMS
HIRING
tvEKACe
DtLAT
ASSIMILATION
HIREDY
o
AVERACC
EMPLOYMENT
OELAT
TIME
ASIMDY
AVEMPT
:UL
WFNEW
:^
HiRERT
i
HIRING
'
RATE
«>.
WFEXP
NEv.LV
HIRED
WORKFORCE
'
\,
z_
WORKFORCE
/iSlMRT
OUITRT
workforce
OUIT RATE
ASSimilAIIC^
RATE
NEWTRR
NEWLl" HIRED
TRANSFER HATE
EXPTRR
/
EKPERifNCEO
TRANSFER RATE
.V-^
-^
TRNSDY
TRANSFER
DELAT
TRNSDY
TRANSFER
DELAT
o
/
"^
^
Ficure
THE
r
ExPEPiE>KEO
HU>L\N'
WI-NLtU
WORKFORCE
LEVEL NEEDED
\
)
/
(A)
RESOURCE MANAGEMENT SUBSYSTEM
-o
"
i3
hiring,
training,
assimilation,
and transfer of the human resource.
The schematic converitions used in Figure
used in system dynamics models,
A
are the standard conventions
the quantities appearing in such models
fill
can be classified in two broad groups: constants, whose values cannot change
at all
in the course of a simulation,
whose values can. The
and variables,
symbol for a constant is shown below:
constant
\
\
Model variables are one of three types,
"auxiliary" variables,
fl
ieyel^
namely,
is an accumulation,
"level," "rate," and
or
ar\
integration,
time of flows or changes thkt come into and go out of the level.
increasing and decreasing
WORKFORCE" is
a
decreased by the
a
level are called rates.
level of people that
is
Thus,
over
The flows
"NEWLY HIRED
increased by the "HIRING RATE" and
"WORKFORCE flSSIMILflTION ROTE.
Rates and levels are represented as shown below:
SOURCE
*
LEVEL
-g
RATE
'^^^^
RATE
The cloud-like symbols represent sources and si^nks for the "stuff" that
flowc
ir.tc
and out of levels.
For example,
for a level of workforce these
cloudlike symbols represent where people come from when they are hired and
where they go after leaving the project.
Their presence indicate that the
real-world accumulations they represent lie outside the boundary of the
syEtern being modeled.
The flows that are controlled by the rates are either information flows
or physical
flows.
We will use the two types of arrow designators shown
below:
INFORMATION FLOWS
>
OTHER FLOWS
(e. g.
,
People)
Levels and rates are sufficient,
in a system dynamics model.
Usually,
in principle,
however,
it
is
to represent all variables
very difficult to write
rate equation without first doing some (often complex) algebraic
computations.
These additional algebraic computations are termed
"auxiliaries." Thus,
auxilikry variables, as their name implies,
aid in the
formulation of rate equations. For example, the "HIRING RATE" equals the
"WORKFORCE GAP"
(an
auxiliary which is equal to the difference between the
"WORKFORCE LEVEL NEEDED" and the current "TOTAL WORKFORCE") divided by the
"HIRING DELAY". Auxiliary variables are represented by
Finally,
a
circular symbol.
variables that are defined in sectors of the model other than
the one(s) diagrammed are represented by enclosing the variable name in
parentheses as shown,
bclcv-;.
VARIABLE
FROM
ANOTHER SECTOR
a
Returning to Figure
A,
notice that the project's total workforce is
comprised of two workforce levels, namely,
"Experienced Workforce,"
version. of the model,
(In the current
more finely divided into four,
not two,
"Newly Hired Uorkforce" and
levels.
workforce is
for this
However,
presentation the simpler structure of Figure 4 is quite sufficient to
demonstrate the basic ideas.) Segregating the workforce into these two
categories of employees is necessary for two reasons.
First,
newly added team
members are less productive (on the average) than the "old timers"
1980).
and Zawacki,
Secondly,
it
(Cougar
allows us to capture the training processes
involved in assimilating the new members into the project team.
On deciding upon the total workforce level desired,
consider
number of factor^.
a
One important factor,
project managers
of course,
is the
project's completion date. Os part of the planning subsystem (to be discussed
later),
management determines the workforce level that
necessary to complete the project on time.
'.
In addition,
is also given to the stability of the workforce.
project members,
Thus,
it
believes is
though,
consideration
before adding new
management contemplates the duration for which the new
members will be needed.
In general,
the relative weights given to workforce
stability versus on-time completion change with the stage of project
completion.
For example,
toward the end of the project there could be
considerable reluctance to bring in new people.
This reluctance arises from
the realization that there just wouldn't be enough time to acquaint the new
people with the mechanics of the project,
team,
ar.d
tram
thErr,
;r.
integrate them into the project
the necessary technical areas.-
Figure 5 demonstrates the workforce staffing pattern in an example model
output.
(NfiSR,
It
depicts the model's simulation of NASA's DE-0 software project
1963).
The project was conducted at the Gocdard Space Flight Center
—
p^
^
1/1
> >
>
>
r>«
u w u o u
O
O
OC
C
O *y
'-^
rsi
(1)
ESTIMATED SCHEDIUJ: IN
DAYS
^
^-f
C)
PERCEIVED PROJECT SIZE
IN KESl
c o o c
O
O—
o
^..
^
/
X
.
^
rs.
fN
-
ESTIMATED PROJECT COST
IN MAN-DAYS
^-.--"
(3>
(5)
WORKFORCE
^
ACTUAL FRACTION OF /
MA.N-DAY ON PROJECT^'
/
(PEOPLE)
V
.''
o ooo o
100
:oo
DESICN PHASE-
^
^
(^
300
•COOINC PHASE
DE-fi'
H
"Estimated Schedule in Days"
5 actual "Estimated Project Cost in Man-Days"
f ul 1-t itne-equi valent people)
s actual "Workforce"
DE-R' 5 actual
DE-ft'
380
(
MODEL SIMULfiTION OF THE
DE-fl
PROJECT
TL'iE
(DAYS)
I?
<GSFC)
to design,
implement,
and test
a
software system for processing
telemetry data and providirig attitude aet errninat ion and control for the
The project's size was £A, 000 delivered source instruction (£A
satellite.
KDSI),
DE-fl
the development and target operations machines were the IBM S/360-95
and the programming language was FORTRfiN»
and -75,
Initially,
the project was
estimated to require 1,100 man-days and to be completed in 320 working days.
The actual results were 2,200 man-days and 560 days,
respectively.
The model's results conformed quite accurately to the project's actual
behavior (represented by the
points in the figure).
Notice that the
project's workforce pattern differs from the "typical" pattern discussed in
the literature,
the concave type curve that rises,
i.e.,
peaks,
and then
drops back to lower levels as the project proceeds towards the system testing
phase (Boehm,
1981).
Because
NflSfi'
s
the completion of the DE-fi sbftware,
Specifically,
tolerated.
90 days before launch,
fls
launch of the DE-fl satellite was tied to
serious schedule slippages were not
all software was required to be accepted and frozen
this date was approached,
pressures developed that
overrode normal workforce stability considerations. That
is,
project
'.management became increasingly willing to "pay any price" necessary to avoid
overshooting the 90-day-bBf ore-launch date.
as the figure
into a management that was increasingly willing to add more
indicates,
people.
This translated,
[In
(flbdel-Hamid,
1986a)
we investigate whether such a staffing
policy did or did not contribute to the project's late completion.]
Id£_iQEiy85£_?RQDyCTION_SL!PSYSTEM
This subsystem models the software devel_o2rnent process.
maintenance phases of the -cftwarc lifecyclc arc,
thus,- not
The operation and
included.
development lifecycle phases incorporated include the designing,
testing phases.
excluded.
The
coding,
and
Notice that the initial recuirementi d»finltlon phaeg i§ al§a
There are two reasons for this.
The primary reason relates to the
desire to focus this study on the "eriOogerious" software develC'pmerit
orgariizat ion i.e.,
professionals,
the project mariagers and the software development
and how the2.r policies,
decisions,
actions,
etc.
affect the
success/failure of software development. The requirements definition phase
was,
thus,
excluded since in many enviroriment s the definition of user
requirements is not totally within the control of the software development
group (McGowan and McHenry,
1980).
Second,
"finalysis to determine
requirements is distinguished as an activity apart from software development.
Technically,
the product of analysis is non-procedural
functional)"
(McGowan and McHenry,
(i.e.,
the focus is
1980).
On overview of the Software Production Subsystem is shown in Figure
the software is developed,
is also reviewed to detect
it
detected during development,
however,
fis
any errors e.g.,
using quality assurance activities such as structured walkthroughs.
detected through such activities are reworked.
6.
Errors
Not all software errors &rB
some "escape" detection until the
testing phase.
One of the subsystem's more interesting components is that of software
V productivity,
'
which is expanded
m
Figure
7.
Its structure is based on the
work of the psychologist Ivan Steiner (1972). Sterner'
s
model can simply be
stated as follows:
Productivity
=
Potential Productivity
-
Losses Due to Faulty Process
where losses due to faulty process refer to a group's communication and
motivation losses.
EeitDtiii-ECQ^yEiiyitY: According to Steiner, Eotential_ productivity is
defined as "the maximum level of productivity that can occur when an
individual or group ...
a
.v.akes
the best possible use of its resources".
function of two sets of factors,
complexity,
the nature of the task
(e.g.,
database sire) and the group's resources (e.g.,
capabilities,
software tools).
It
product
personnel
The effects of such factors on software
is
D
c^
/
^
SOFTWARE DEVELOPMENT
PRODUCTIVITY
Q
/
/
^
SOFTWARE
DEVELOPMENT
RATE
ERROR
^
^
[>
SOFTWARE
DEVELOPED
GENERATIONt>|q
RATE
ERRORS THi\T
ERRORS
ESCAPED
(manpow^r^
ERRORS
ESCAPE
RATE
/'quality assuranc^
I
^
\
\
SOFTWARE
TESTING
[><r
~=*I>|C1
RJi.TE
ERRORS
DETECTION &
CORRECTION
RATE
EFFORT
]
\
\
ERRORS
DETECTION
^C>f3cORRECTI-
RATE
\
I
SOFTWARE TESTIN
PRODUCTIVITY
SOFTWARE
TESTED
ERRORS DETECTI
& CORRECTED
IN TEST'G PH-i.;
Fieure
(G)
IKE SOFTWARE PRODUCTION SUBSYSTEM
ERRORS DETECT!
& CORRECTED
IN DEV'T PH.'^SI
o
<
rr
2.1
proauct 1 VI t y have
beer:
(Scott and Simmons,
widely investigated in the literature [e.g.,
(Chrysler,
1374),
1?7B),
and
see
1981)].
(Boenm,
Notice that while most of the above factors do vary from organization to
organization (e.g., availability of software tools,
personnel capability) and
from project to project within a single organization (e.g.,
complexity,
product
database size) they, however, tend to remain constant throughout
the development lifecycle of any single project.
This means that in studying
the dynamics of software productivity during the lifecycle of a
Bil^t i^cul^ar
software project, which is our concern here, the above variables can be
assumed to remain constant.
In the model,
such factors are captured through
the model's nominal potential productivity parameters.
The "Overage Nominal Potential Productivity" for the workforce as a whole
is the weighted average of two nominal
potential productivity parameters,
to represent that of the average t>iE§!2iiDS^ staff member,
represents that of the average newiy tllH?^ employee.
one
and the second
They represent the
maximum level of software development productivity that can be attained for
specific project situation (i.e.,
''.
'
organization)
at
a
specific project within
by the respective employee type
a
specific
(whether experienced or new),
some point in the project.
The "Byt!2§S§ Nominal Potential Productivity" is not
a
constant,
it
changes dynamically throughout the lifecycle as the workforce experience mix
changes,
and as the workforce learns from working on the project
(Weinberg,
1982).
U2§5§5_5y§_t2_E§yii.ii_E'!Z2£§§iii' Actual
productivity rarely equals
potential productivity due to losses caused by communication and motivation
overheads.
The effects of
cor.i.'Municat
ion and motivation losses have a
multiplicative effect. Motivation factors first influence the fraction of
man-day devoted to project work.
matters,
coffee-breaks,
Since time is often lost on personal
and other miscellaneous non-project related
a
a-
this fracticin will usually have a value less than
activities,
Communication losses, then,
52li^§li2-lI^E§-U9§=ii'
1.
take further "cuts," as we explain below,
discern the dynamic effects of motivation
''"'-'
losses on productivity we need
to distinguish between those factors
(again)
that tend to remain constant during the life of any one particular project
and those that change throughout the lifecycle.
factors discussed in the literature (e.g.,
level of responsibility,
advancement,
Many of the motivational
possibility for growth and
and salary)
are factors that
characterize the overall organizational setting and climate.
In our
such non-dynamic factors are implicitly incorporated within the
formulation,
definition of the potential productivity parameters.
"Another motivation approach which is particularly appropriate to the
data processing area is goal setting"
(Bartol and Martin,
1982).
The authors
suggest that project goals And schedules play an important motivational role
throughout the life of
(1981),
a
software project. This was corroborated by Boehm
who found that schedule pressures and project deadlines can
significantly expand/contract the project members'
'.
"slack time" ...
the time lost on off-project activities such as coffee-breaks,
business,
which is
personal
non-project communication.
The "Nominal Fraction of a Man-Day on Project" represents the fraction of
daily hours allocated to project-related work in the
In designating a value for this parameter one
absence of schedule pressures.
can draw upon a large volume of research findings.
The findings are clustered
withm
the 50-705C range [e.g.,
50-60VC
1980),
S0%
findings,
(Thadhani,
50>;
and
igSA),
(Brooks,
70-/
(Boehm,
1978),
1981)].
(Pooch and Gehring,
On the basis of these
the value of "f^ominal Fractior. of a Man-Day on Project" is set
model to 0.60.
the average,
That
is,
only 0.5
X
in an
3 =
S-hour day,
A. 8
full-time employee allocates,
tf'.f
on
hours to the project.
This loss in productivity does not,
the life of the project.
a
in
of course,
remain constant throughout
Schedule pressures can push the "Bctual_ Fraction of
a
Man-Day on Projec:" to both higher values
well as to lower values
tunaer positive schedule pressure)
as
(under negative schedule pressure).
Positive schedule pressures
perceived to be behind schedule.
CB.r\
arise in
a
project whenever the project
When confronted with such
a
is
situation,
software developers tend to work harder by allocating more man-hours to the
project in an attempt to compensate for the perceived "delinquency" and bring
the project back on schedule [(DePree,
But what
19BA)
and
if such a situation persists ...
harder indefinitely^ The answer,
(Ibrahim,
1978)].
would workers be willing to work
based on common sense and confirmed by our
field study results was overwhelmingly no.
Our findings indicate that there are
limits for how long employees are willing to work at an above-normal rate.
Workers savor their slack time (e.g.,
personal business),
coffee breaks,
social communications,
and they typically will not tolerate a prolonged
deprivation of such "breathers."
fi
compressed slack time,
them (psychologically more so than physically)
therefore,
in the sense that
their tolerance level for continued over-working,
it
exhausts
cuts into
significant portion of
(fi
ttie
detailed productivity structure in the model is devoted to handling these
intangible dynamic forces.)
Negative schedule pressures,
rare)
occasions when
happens,
scope.
for example,
a
on the other hand,
project is perceived to be ahead of schedule.
This
when management initially over-estimates the project's
When project members perceive some excesses
not all,
arise on those (probably
of these excesses tend to get
goldplating and/or "undei— work"
m
the schedule,
parts,
if
"absorbed" by the workers in the form of
[(DeF'ree,
19BA)
and
(Ibrahim,
1976)].
For
example:
... if the software cost or schedule estimate for nesting a milestone is
higher than the ideal, Parkinson's Law indicates that people will use the
extra time for ... personal activities, catching up on the mail, etc
(Boenm,
1981).
ftnalogous to the case of positive schedule pressure,
there are limits on
how much "fat" employees would be willing, or allowed,
excesses are translated into cuts
limits,
t£iiii_P!:!t_i2-Q5[!!'i!!:!!!!i£§ti£Il_Q^§!l-§£^
a
Mari-Day on Project" captures the
factors only.
Additionally,
•
Beyond these
project's schedule.
in the
"^^^
to absorb.
value of the "Pctual Fraction of
losses in productivity due to motivational
losses in productivity due to communication
Communication overhead is the drop in productivity of
overhead may be incurred.
the average team member caused by the losses incurred in communicating
(verbally as well as non-verbal ly) with others on the project.
The nature of the relationship between communication overhead and team size
has been investigated by several authors.
It
is
widely held that commuriicat ion
2
overhead increases
[(Brooks,
1978),
iri
proportion to n
(Mills,
1376),
,
where
n
is the
(Scott and Simmons,
size of the team
1975),
(Shooman,
13B5),
and
f
(Zelkowitz,
1978)].
The dynamic behavior of* the "fiCTURL FRfiCTION OF
the DE-fl project is depicted in Figure
5.
fl
MON-DRY ON PROJECT" for
Notice the "spike" that occurs as the
end-of-development milestone is approached. To understarid the causes of this'
behavior,
started,
we need first to observe
(also in Figure 5)
its true size was underestimated by
Project Size" starts at
16 KDSI
"new" job tasks were discovered,
estimated man-days,
fls
is
35V-,
that wheri the project
(The value of "Perceived
and eventually rises to 24.4 KDSI.)
fls
the
upward adjustments were made in the project's
typically the case, however, the
man-day adjustments
were not quite enough. This created a deficit in the project's budget which
became visible only towards the end of the development phase when the
development work was almost finished and the man-days close to used
fls
the man-day deficit became visible,
harder and longer hours in
ar,
up.
the project team reacted by working
attempt to bring the project back on track.
translates in the model into the higher values of the "Actual Fraction of
Man-Day on Project." But as was explained above,
an above-normal work rate indefinitely.
This
a
project teams do not maintain
The persistence of the work backlog.
thus,
eventually overwhelms the workforce's intensified efforts,
and arourid day
300 arrangements were made to adjustment both the project's man-day estimate
and its schedule.
IHE_CgNTRDL_SUBSYSTEM
Decisions made in any organizational setting are based on what information
is actually available to the decision fnaker(s).
information is inaccurate.
actual or true state,
Often,
this available
Apparent conditions may be far removed from the
depending on the information flows that are being used
and the amount of time lag and distortion in these information flows
(Forrester,
1961).
True project progress is a good example of a project variable that is often
difficult to assess (see Figure 6).
Because software is basically an intangible
product during most of the Development process,
performance in programming
...
It
"It
is difficult
to measure
is difficult to evaluate the status of
intermediate work such as undebugged programs or design specification and'their
potential value to the complete project
How,
then,
is progress measured
"
(Mills,
19S3).
in a software project? Our own field study
findings corroborate those reported in the literature,
namely,
especially in the iarl_ier phases of software development,
that progress,
is measured by the
rate of expenditure of resources rather than by some count»of accomplishments
(DeMarco,
1582).
Baber (1982) explains:
It is essentially impossible for the programmers to estimate the fraction
of the program completed. What is A5^ of a program'' Worse yet, what is 455C
of three programs? How is he to guess whether a program is ^0% or 50%
complete'' The easiest way for the programmer to estimate such a figure is
to divide the amount of time actually spent on the task to date by the time
budgeted for that task. Only when the program is almost finished or when
th£ allocated time budget is almost used up will ne be able to recognize
that the calculated figure is wrong.
When progrest in ths earlier phassB of software development,
by the rate of expenditure of resources,
is measured
status reporting ends up being
t OF PROJECT
V
ESOURCES CONSUMEOr ^
^
1
CUMULATIVE TASKS
DEVELOPED
'
SOFTWARE
PRODUCTIVITY
HAN-DAYS
REMAINING
Flgyre_^e2
CONTROLLING iuBSYSTEM
^^
nothing more than an ecnc of the original plan.
One "infanious" consequence of
this IS the "30% syndrome phenomenon." Baber (138£)
pt-ovides the following
description of the problem:
... estimates of the fraction of the work completed (increase) as
originally planned until a level of about 80-90% is reached, the
programmer's individual estimates then increase only very slowly until
the task is actually completed.
There is ample evidence in the literature on the pervasiveness of the 90S
syndrome in software development projects (DeMarco,
is depicted
in the simulated DE-ft project
in the earlier phases of the project
13B£).
in Figure 9.
Its manifestation
By measuring progress
by the rate of expenditure of resources,
status reporting ended up being nothing more than an "illusion" that the
project was right on target.
stages (e.g., when
B0-'30'A
However,
as the project approached
of the resources are consumed),
its final
discrepancies
between the percent of tasks accomplished and the percent of resources
expended became increasingly more apparent,
fit
the same time,
project members
became increasingly able to perceive how productive the workforce has
actually been.
This results in a better appreciation of the amount of effort
actually remaining,
'
fls
this appreciation developed,
discount the project's progress rate.
Thus,
it
started to,
in effect,
although the project members
proceeded towards the final stages of the project at a high work rate because
of schedule pressures,
their net progress rate slowed down corisiderably.
This
continued until the project completed.
IHi_E!=9b!NING_£yPSYSTEM
In the Planning Subsystem,
time,
staffing,
(e.g.,
for completion
man-days) are made at the beginning of the project.
estimates are then revised,
example,
initial project estimates
to handle
a
as necessary,
These
throughout the project's life. For
project that is perceived to be behind schedule,
be revised to add more people,
extend the schedule,
Planning Subsystem is depicted in Figure
10.
plans can
or do a little of both.
The
/
, -
V
WORKFORCE
CEILING ON
-^ TCTiu
\
WORKFORCE
I
"
1 M4N-DAYS i
^ "a remaining
Y
'
TIME
PERCEIVED
LEVEL
STILL
r*^
.
\
-cL-
\
AVERAGE DAILY
MANPOWER
.\
PER STAFF
\.
AVERAGE
ASSIMILATION
DELAY
MAXIMUM TC.ERABlE
COMPLETION DAT'.
- -
-C TIME C>~
\
\
\
N
~>J
SCmEDulEO
COMPLETION
DATE
K /
J\/
RATE OF
ADJUSTING
V\
SChEDuuE
\
SCHEDULE
ADJUSTMENT
TIME
6
Figure_1101
PLANKIKG SUBSYSTEM
^-•
^,
REMAINING
Ely
dividing the value of "Man-Days Remaining"
by the "Time Rernaining"
a
any point
at
in the project,
manager can determine the "Indicated Workforce
Level." This represents the workforce size believed to be necessary and
sufficient to complete the project on time.
If this
indicated workforce size
turns out to be lower than the value of the actual workforce level on the
project,
excessive employees would simply be transferred out of the project
indicated by the TRANSFER ROTES of Figure A).
If on the other hand,
(as
the
opposite is true, then this would indicate a need to add more people.
Hiring decisions are not determined,
scheduling considerations.
the workforce.
For example,
project,
however,
solely on the basis of
Consideration is typically given to the stability of
Different organizations weigh this factor to various extents.
workforce stability had relatively little weight in
as we saw.
NftSfi'
s DE-fi
Such organizational differences are captured in the model
by the policy variable termed "Willingness to Change Workforce Level," and
whose form is organization-specific.
By dividing the value of the "Workforce Level Sought"
the above set of factors is contemplated)
'
(that emerges after-
into the value of the "Man-Days
Remaining," management determines the time
it
perceives is required to complete
the project.
it
can be used to adjust the
Once this,
in turn,
is known,
project's "Scheduled Completion Date," if necessary.
Referring back to Figure
5,
notice how project
DE-fl' s
management was
inclined not to adjust the project's scheduled completion date during most of
the development phase of the project.
project,
Adjustments,
in the earlier phases of the
were instead made to the project's workforce level.
not atypical.
It
arises,
according to DeMarco (19B2)
This behavior is
because of political
reasons:
Once an original estimate is made, it's all too tempting to pass up
•ubitQutnt opportunitiei to oitimtt* by simpls sticking with your previous
numbers. This often happens even when you know your old estimates are
suDstant ial ly off. There are a few different possible explanations for this
effect: It's too early to show slip ... If I re-estimate now, I risk having
to do it again later (and looking bad twice) ... fis you can see, all such
H
reasons are political in nature.
With this discussion of the model's Planriing Subsystem we conclude our
overview presentation of the model's structure and behavior.
MQDEL_VALIDQIION
The process of judging the validity of a system dynamics model includes a
number of objective tests (Richardson and Pugh,
~ E§£§_^3l,idi_ty.
1981)].
They include:
To test the fit between the rate/level/feedback structure
of the model and the essential characteristics of the real system.
This was
confirmed by the software project managers involved in the study.
~ 5iEiiE§tion_of_reference_modes.
reproduce the various reference behavior modes characterising
§!2^2SilJ9!:!§iy
the system under study.
patterns such as the
"90"/
To test whether the model can
Reference modes include problematic behavior
'
syndrome," and observed responses to past policies such as
DE-fl' 5
scheduling behavior, etc.
~ i>it!2i!I!§_EeD^iti2!2_§i[!]yi§ti2!li§'
To test whether the model behaves
reasonably under extreme conditions or extreme policies,
'
model that
fl
does not behave reasonably under extreme conditions (e.g., hiring delay
equals to zero)
is suspect,
because one may not be certain when aspects
of extreme conditions may crop up in o>'dinary runs.
~ Cisg-ity^Y'
The DE-fl project case-study which was conducted after the
model was completely developed,
validating model behavior.
(NflSfl
constituted an important element in
was not one of the five organizations
studied during model development.) The fact that the model was able to
replicate some unusual behavior e.g.,
in the staffing area,
in addition
to the more traditional workforce patterns observed in the five project
environments studied during the development of the model,
indicates its
robustness,
"finy
one of these test by itself is certainly inaaequate as an indicator
Taken together,
of moflel validity.
(Richardson and Pugh,
(however),
they are a formidable filter"
1381).
i]<EliOIMENTS_yNDERTftKEN_flNp_IMPLICflTigNS_OF_RESLILT5
"In software engineering it
is remarkably eaey to propose
remarkably difficult to test them" (Weiss,
1979).
argued for the desirability of having
thus,
a
ideas and hypotheses in software engineering
hypotheses and
Many in the field have,
laboratory tool for testing
(Thayer,
1979).
The computer simulation tools of system dynamics provide us with such an
experimentation vehicle. The effects of different assumptions and
environmental factors can be tested.
systems,
In the model
unlike the real
system,
the effect of changing one factor can be observed while all other
factors are held unchanged.
Internally,
the model provides complete control
of the system's organizat loVfal structure,
to various events
Currently,
(Forrester,
the model
its policies,
1961).
is being used to study and
implications of managerial policies and procedures
development process in
a
and its sensitivities
variety of areas.
predict the dynamic
or\
the software
Examples of experiments performed
and insights gained include:
In
(fibdel-Hamid and Madnick,
1986)
we investigated ways in which schedule
estimation techniques are evaluated. For example, consider the case of a
software project for which two software estimation techniques have been
proposed.
Technique
man-days.
The concern of top management was for accuracy of prediction.
decision ^as
.v.cde
ft
predicts 2,000 man-days, technique B predicts 3,000
to use technique
fi.
When the project was
man-days were actually needed (15S more than predicted).
decieion to use techniquB
was,
in fact,
fi,
is top
cor.-.pleted,
£300
In reviewing the
management correct to conclude that
the more accurate estimator?
The
it
.
The answer is "not necessarily." If the project had been initiated with
the 3,000 fnan-day estimate of technique
pressures,
hiring plans,
project.
B,
there would be
a
difference
in the
and perceptions that affect how people behave on the
The study results indicated that conducting the project with the
3,000 man-day estimate would have resulted
m
a
2,800 rnan-days (3% less than
predict ion)
The experimental results demonstrated how "a different schedule creates a
different project." That
is,
if a software project were conducted twice using
two different initial schedule estimations,
significantly different in nature (e.g.,
time,
workforce pattern,
necessarily judge
accurately
2.
a
the outcomes could be
in terms of the actual
completion
productivity). This also indicates that one
cari
not
new software estimation tool strictly on the basis of how
estimates historical projects.
it
Uncover i_ng_d^5functibnal__con5eguence5_of_5ome_cur
gol^ici_es^
In (flbdel-Hamid and Madnick,
practices in
'',
'
organization,
a
major U.S.
1986)
used.
In the particular
minicomputer manufacturer-.
software project managers use Boehm'
come up with intial project estimates,
a judgemental
we investigated the project scheduling
s
(1381)
COCDMO model to
which are then adjusted upwards using
"safety factor" to come up with the project estimates actually
The purpose of the experiment was to investigate the implications of
this safety factor policy.
Our results confirmed the value of the safety factor policy in improving
estimation accuracy.
One simulation showed that the estimation error which
would have been 33% had been reduced to S% by this policy. But,
the first experiraent,
this case,
as noted in
the different estimates created different projects.
the safety factor policy resulted in a
A3*/
cost
increase.
Thus,
this more accurate estimation technique results in more costly projects.
Which technique is "better"?
It
depends upon whether "better" means more
In
accurate or least costly. For the first
management had
tirne
a
realizatiori of
the "cost" of their more accurate schedule estimation policy.
(flbdel-Hamid,
In
ISSSb),
we investigated the cost effectiveness of
various levels of software quality assurance on total development costs.
Increasing the amount of quality assurance
(Qfl)
activities directly adds new
costs which are presumably more than compensated by
testing.
Is there an "optimal" amount of
Qft
a
reduction in rework and
for a project?
Effects considered in this experiment included error generation rate
factors,
such as schedule pressures and phase of project,
factors,
such as productivity,
error types,
and error detection
error density. The results showed
that even with the same initial man-day requirements estimation,
the percent
of the effort allocated to QO dramatically affects the actual man-days used
to complete the project.
In'one case studied,
the resulting total project
cost ranged from 3,770 man-days to 5,000 man-days with the optimal
allocation being
IS'A
Qfi
of the development effort.
This investigation was particularly important since
it
provides the first
capability to quantitatively analyze the costs and benefits of
beyond controlled experimentation,
Qfl
policies
which is usually very costly and too time
consuming to be practical.
^-
E!22yi^i!llS_D§i:i_iD§i9t!t§_i!Ili£_§£f tySH^.EHQJiSt-Elll^D^L^glli^-
One such phenomenon we examined in (fibdel-Hamid,
which states that adding manpower to
(Brooks,
1978).
Brooks'
a
igSSa)
is
"Brooks'
late software project makes it
Law has been widely cited in the liteT'ature,
Law,"
later
but how
widely applicable is it?
Cur object ivs in thiz, c;;pcr;m2i-,t w^s to investigate the applicability of
Brooks'
projects
law to the environment of med
(i.«.
,
i
ufii-si
zed application-type software
projects that are 15-100 KDSI in size).
results showed that while adding more people to
a
The expenr.^ental
late project of this type
)
does cause
later.
it
to become more costly,
does not always cause
it
The increase in the cost of the project
is caused
it
to complete
by the increased
training and communication overheads, which in effect decrease the average
productivity of the workforce and thus increase the project's cost in
man-days.
For the project's schedule to also suffer,
the drop in productivity
must be severe enough and late enough in the project's lifecycle to render an
additional person's net_cumul_ative contribution to the project to
effect,
a
be,
in
negative contribution. Our experimental results indicate that this
happens only where management's willingness to add new staff members persists
until the very final stages of the testing phase.
5.
Qther_EKgeri_ment5^
Some of the other experiments conducted investigated issues such as:
- the
portability of software estimation models (e.g., why do
many estimatibn models fail to retain their level of accuracy
when transported from the originating organization to another
organization?)
- the implications of staffing assignment
is it
alternatives (e.g.,
better to assign people full-time to a project or
part-t ime?
- the impact
phases (e.g.,
of different effort distributions among project
should the division of effort between development
and testing be 60:20 or 60:A0 percent?)
- the reasons for and implications of the differences between
E9t§Dti§i pt"oduct ivity,
actual_ productivity,
and Eercei_ved
product ivity.
-
the basis for the "30S syndrome"
phencr.ieciCi-.
(partially
explained in the Qont rol__5ubsYstern section of this paper).
CDNCLUSION
1
The objective of this research effort is to enhance our understand ing of
the software development process and how
it
To achieve this,
is managed.
we
adopted an integrative system dynamics view of the software development
process.
There are three principal features that characterise our research
paradigm, which we would like to reiterate in these concluding remarks.
First,
we emphasize the integrati^ve perspective. .We have attempted to
demonstrate how the software management system is
a
conglomerate of
interrelated and interdependent functions, fiction taken by one subsystem
(e.g.,
human resource management) can be traced throughout the entire
management system (e.g., software production,
Furthermore,
and control).
the behavior of an individual subsystem in isolation may be very
different from its behavior when
the lesson of Brooks'
Second,
planning,
it
interacts with other subsystems (e.g.,
Law).
our research approach is grounded in the feedback systems
principles of system dynamics.
Feedback processes are universal in social
systems in general,
and we attempted to show how,
project management,
they do provide a powerful
software project behavior.
It
is no wonder,
when applied to software
lens to view and understand
then,
that
"most (software) managers get into trouble because they forget to think
in circles. I mean this literally. Managerial problems persist because
managers continue to believe that there are such things as unilateral
causation, independent and dependent variables,
terminations" (Weick, 1979).
Si[!iyi§li2!l'i
^^^ third principal feature,
is an
origins,
and
effective tool to handle
the high complexity of such integrative feedback models.
Simulation's
particular advantage is its greater fidelity in modeling processes, making
possible both more complex models and models of more complex systems.
It
also allows for vicarious experimentation.
Controlled experiments in
(Myers,
the ^rea of software development tend to be costly and time coriSuming
1978).
Furthermore,
even when
it
can be afforded "...
the isolation of the
effect and the evaluation of the impact of any given practice within
a
large.
:
.
complex and
198c).
dyriarnic
project environment can be exceedingly difficult"
In addition to permitting
less costly and less
t
(Glass,
irne-consurning
simulation-type models make "perfectly" controlled
experimentation,
experimentation possible.
Finally,
a
we can indeed confirm that the very, process of constructing such
simulation model can be useful in several other ways (Schultz and Sullivan,
1972)
1.
vague generalizations crumble when put to the test
Confrontation
of modeling.
2.
Explication
assumptions must be made explicit,
precise in order to build
3.
4.
a
and
simulation model.
the tendency to a holistic approach in simulation
Expansion
forces
a
logical,
broadening of one's horiron,
a
looking into other relevant
fields for ideas,
hnd
Communication
problem-oriented simulation lead to jumpimg of
disciplinary boundaries,
'
less parochialism.
'
BIBLIOGROPHY
T. K.
"The Dynamics of Software Development Project
Management: On Integrative System Dynamics Perspective." Unpublished
Ph.D. dissertation, Sloan School of Management, MIT, January, 198A.
1.
ftbdel-Harnid,
2.
flbdel-Hamid,
3.
Rbdel-Hamid, T. K. "The Economics of Software Quality Assurance: ft
Simulation-Based Case Study." Accepted for publication in the MIS_
Quarterly, 1988b.
4.
Abdel-Hamid,
5.
Rbdel-Hamid, T. K. and Madnick, S. E. Sof tware_P::o ject _Manacement
Englewood Cliffs, New Jersey: Prentice-Hall, Inc., to be published
"The Dynamics of Software Project Staffing: ft System
Dynamics Based Simulation Approach." Accepted for publication in
I_EEE_Transact ion§_on_Software_Engineeri_nn, ISBBa.
T. K.
"Impact of Schedule Estimation
T. K, and Maanick, S. E.
Softv,are Project Behavior." IEEE_Bof twarc, (July, 19a£).
in 1988.
6.
Baber, R. L. Sof tware_Ref l_ect ed.
Company, 1932.
New York: North Holland Publishing
on
7.
V. R. "Improving Methodology and Productivity through Practical
Measurement." fi lecture at the Wang Institute of Graduate Studies,
Basili,
Mass.,
Lowell,
Nov.,
1982.
and Perkins, I.E. "ft Survey of Software Engineering Practice:
Tools, Methods, and Results. " IEEE_Transact i^ons_gn_Software_
(Sept., 1962).
i!:!ai!2§§!:iDe» ^°^- SE-9, No, 5,
e.
Beck,
9.
Boehm,
10.
Brooks,
L. L.
B. W. Software_Ensin?§!!iD3_iE9D9[Di^ii Englewood Cliffs, New Jersey:
Prentice-Hall, Inc., 1981.
F. P. Ihe_Mythical_Man_Month. Reading, Mass:
Publishing Co.
1978.
fiddi son-Wesley
,
11.
Buckley,
and Poston,
F.
R.
i2ft5§!I?_iDSi!I!§§!Zi!I!Si
12.
13.
"Software Quality Assurance." iEiE_Trans;
(January,
on
36-Al.
198A),
Chrysler, E. "Some Basic Determinants of Computer Programmer
Productivity." Commuracat ion5_of_the_9CM, Vol. £1, No. 6,
1978), 472-463.
(Jurie,
"Corporate Level Software Management." iiii_l!;ansaction5
J. D.
2D_S2ftware_Ensini§niD9) Vol. SE-4, No. 4, July, 1978.
Cooper,
;
14.
Cougar,
and Zawacki,
^^^ York:
J. D.
E§!2§2DD§i'
15.
DeMarco,
R.
M2ti^§ti!ll9_§D^_t!!§!l;§91!23_Q2l!]2ytg!2
ft,
John Wiley
&
Sons,
Control_l_i_ng_Software_Project5.
T.
Inc.,
1960.
New York: Yourdon Press,
Inc.,
1982.
*
16.
DePree, R. W. "The Long and Short of Schedules.
1964), 131-134.
17.
Forrester,
*
J. W.
I,!l!du5tri_al__Dynami_c5.
"
Cambridge,
Datamation,
*
(June 15,
Mass: The MIT Press,
1961.
16.
15,
19.
1967,
"What You Should Know fibout Programmers." Datamati_on,
pp. 91-102.
R. L.
"Software Development Information System." Journal__of
Freedland,
Ibrahim,
M.
iY§t§[!]§_t!!!i!2i9iQ]iDt)
20.
Jensen,
R. W.
N. J.
21.
:
and Tonies,
Prentice-Hall,
(Dec,
C. C.
1978),
34-39.
Software_Engi_neering.
Inc.,
March
Englewood Cliffs,
1979.
Kelly, T.J. "The Dynamics of R&D Project Management." Unpublished
M.S. Thesis, MIT, Sloan School of Management, Cambridge,
Massachusetts,
1970.
"Successful Development Strategies for Business Rpplicaticn
Systems." MIS_Ouarterly, Sept., 1983.
22.
McKeen,
23.
Mills,
24.
Musa,
J. D.
H. D.
Software_Producti_vity.
Canada: Little,
Brown
&
Co.,
J. D.
"Software Engineering: The Future of R Profession."
Software, January, 1965, 55-62.
1953.
I.EEE
.
25.
NfiSP.
"Software Development History for Dyriarnics Explorer (DE) fittitude
Ground Support System (flGSS)." GSFC Code 580, June, 19B3.
£6.
Nay,
"Choice and Allocation in Multiple Markets: A Research and
Development Systems Analysis." Unpublished M.S. Thesis, MIT, Dept.
of Electrical Engineering, Cambridge, Massachusetts, 1965.
£7.
Newport,
J.N.
John P. Jr.
13£-1A£.
"A Growing Gap in Software." Fortune,
April £8,
1986,
£8.
U. W. and Gehring, P.F. Jr. "Toward a Management Philosophy for
Software Development. " In 9d^§D£§§_iD_Q222yl§!2_B!!!23!2§'f[!]iDS_
M§D§3§!5?D1- Edited by T. A. Rullo. Philadelphia, PA: Heyden & Sons,
Pooch,
Inc.,
1980.
"Productivity Measures in Software." Ihg_i£onomi^c5_gf
lDf2!2[!]§t.i9D_Pl!9£§§§iDSi_QB§!!§ti9D§i P!!9SII§[!}[!!iD2i §Dd Soft war §_
Models. Volume II. Edited by R. Goldberg and H. Lorin. New york:
John Wiley & Sons, Inc., 1982.
£9.
Radice,
50.
Ramamoorthy, C. V. et al. "Software Engineering: Problems and
Perspectives." Qomguter, Oct., 1984.
31.
Richardson, G. P. and Pugh,
y9deiin§_with_Dynamo.
3£.
A.
Roberts,
E. B.
Harper
Roberts,
34.
Schein, E. H.
Cliffs,
Introduct i_on_to_Sy5tern_Dynami_cs
Mass: The MIT Press, 1981.
IhP_Dyn§m^cs_of_Re5earch_and_Deyel_ogment
Row,
196A.
.
New York:
\
,
Scott,
R. F.
Qr3§Dii§ti9D§i_E5y£!l!9i9QYN. J.
:
Prentice-Hall,
and Simmons,
B. D.
Technique." Datamation,
36.
III.
Cambridge,
(ed.). Manager ial__Aggl^ication5_gf_Sy5tem_Dynarini^C5.
E. B.
Cambridcje, Mass: The MIT Press, 1981.
35.
35.
&
G. L.
Shell,
R. L.
Inc.,
3rd edition.
Englewood
1980.
"Programmer Productivity and the Delphi
(May,
197A),
71-73.
"Work Measurement for Computer Programming Operations."
(Oct., 1972), 32-36.
Indu5tri_al__Engi_neeri_n9,
37.
38.
Shooman, M. L. Sof tware_Engi neer i_ng_-_De5i gnj
~
New York: McGraw-Hill, Inc., 1963.
Steiner,
I.D.
Groug_Proces5_and_Product
i_yity.
Re]^iabi_l_i_ty_and_Managernent
~
~
New York: Academic Press,
1972.
59.
Tausworthe,
Cliffs,
R. C.
N.J.
Standardi_2ed_Deyel_OBrnent_of_Cornguter_Software.
:
Prentice-Hall,
Inc.,
Englewood
1977.
R. H.
"Modeling a Software Engineering Project Managaeniant
System." Unpublished Ph.D. dissertation, University of California,
Santa Barbara, 1979.
'iC.
Thayer,
Al.
Thayer,
"Major Issues in Software Engineering Project
R. H. et al.
Management." iiii_l!!3nsact i_ori5_on_Software_Erici_nBe;2i!l'Si Vol. SE-7,
No.
A,
July,
1981.
A2.
Thomsett,
R.
E!§£Bi§_E!!I2i§2i_?!li!I!§9?t!!i!l!i"
^^"^
York:
Yourdon Press,
Inc.,
1980.
A3.
Weick, K. E. l!2e_5ocial^_Psychol.ogY_c.f _Organirat i^on. 2nd edition.
Mass: Aadison-Wesley Publishing Co., Inc., 1979.
A4.
Weinberg, G. M. yD^?!;5tandins_the_Profes5i_onal_Progr§mmer.
Brown & Co., Inc., 1982.
A5.
Weiss,
46.
Zelkowitz,
47.
Boston: Little,
D. M.
"Evaluating Software Development by Error finalysis.
2f_Sy5tems_and_Software, Vol. 1, 1979, 57-70.
M. V.
Surve;^5,
Zmud,
Reading,
"
Journal^
"Perspectives on Software Engineering." QoQlEylinS
Vol.
10,
No.
2,
(June,
1978).
"Management of Large Software Development Efforts."
Qy5!:t§!:i^i '^ol> ^> No. 2, June 1980, 45-56.
R. W.
MI^S
We aooreciate the contribution of each of the individuals in
t
the oraanizations providinq nersn^ctives and data to this research effort.
In
addition, ve thank Robert Zmud, Chris Kemerer, and the anonymous reviewers,
v/hose suggestions
have improved this article's ornanization and readability.
Work reported herein was suonorted, in part, by NASA research nrant
NAGW-448.
k5dh
102
Date Due
SEP-
15
B
MftY
061394
3
1
tgs"?
''MiZ'^
DEC 27 "^''^
'
\1
noy 22
991
Lib-26-
3 -.06
J'*'*'^"ffill
^^3 5ls