HD28
.M414
$2.
Center for Information Systems Research
Massachusetts
Institute of
Technology
Sloan School of Management
77 Massachusetts Avenue
Cambridge, Massachusetts, 02139
AN INTEGRATIVE APPROACH TO MODELING
THE SOFTWARE MANAGEMENT PROCESS:
A BASIS FOR IDENTIFYING PROBLEMS
AND
EVALUATING TOOLS AND TECHNIQUES
Tarek K. Abdel-Hamid
Stuart E. Madnick
October 1982
CISR WP #95
Sloan WP #1366-82
T.
K. Abdel-Hamid, S. E.
Madnick
1982
Center for Information Systems Research
Sloan School of Management
Massachusetts Institute of Technology
Submitted for publication in the Proceedings of the IEEE Workshop on
Software Engineering Technology Transfer April 25-27, 1983
,
\
I
N*-
1
tts
I.
INTRODUCTION: THE PROBLEM
The past two decades have
large
number
software
of
witnessed
development
of
a
tools and techniques for
engineering
improving the production of software
the
systems.
As
result
a
of
developments, software project managers today have at their
these
potentially
disposal an abundance of sophisticated tools that are
useful
in
helping
them
And the
increase their ef f f ectiveness.
number of these techniques continues to increase each year.
Still,
"most software projects fail"
organizations
are
(McClure,
1981).
finding that their people are still developing
the same expensive, bug-ridden, unmaintainable software that
were
developing
Many
they
before the new software engineering tools (e.g.,
structured programming) were introduced (Yourdon, 1979).
A question that has frequently been raised
so)
is:
who is to
blame?
Does
the
fault
(and appropriately
lie
the
in
themselves, or are the tool-users, especially management
,
tools
the real
culprit?
0745321
In the literature, there is an abundance of arguments on both
For example, Thayer (1979)
sides of the issue.
argued
that
the
problems we are facing in software production are, largely, due to
a
lack
effective
of
project management.
management
other
the
On
"... management is to blame for
revolution."
It
failure
the
poor job in selling the new techniques,
training, and in general
follow-through.
engineering
his
of
(1979)
sees
opinion
that
structured
the
management did a
in providing the necessary
providing
in
is
in most companies,
feels that,
He
Yourdon
hand,
"villain."
real
the
as
tools (especially) in the area of software
needed
the
support
and
And as a result, some argue, most of the software
tools,
and methodologies that have been
techniques,
available for practical use for a long time, languish on the shelf
like a good product which does not sell.
While there is certainly some validity in both arguments,
we
feel that the "true" answer lies somewhat between the two.
What we
necessarily
a new
which
feel
a
breed of
is
is
missing
still
"super-capable"
infeasible
software
increasing
is
not
managers
project
(and
anyway), but rather a much needed
model, perspective if you will, of
decide when,
needed
set of new specific software engineering tools, nor
probably
management,
much
and
software
development
project
that can help both managers and researchers to better
where,
number
and
of
how
to
use
(or
software-engineering
that are already available.
It
is
interesting
not
use)
the
ever
tools and techniques
that
(even)
more
3
I
than
a
decade
ago
Aaron
(1970)
commented
problems because we didn't know how to manage
that
"We ran into
what
we
had,
not
because we lacked the techniques themselves."
Today's software development project managers are faced
a
situation
general
that
new
often
have
more
a
makes
it
heterogeneous
how
important
This
workforce.
less and less obvious how healthy or
sick their organizations actually are.
obvious
organizations
products, offer new services, incorporate additional
technologies, and
complexity
continuously becoming more
been
Their software development
complex (Singer, 1982).
develop
has
with
various
It
also
makes
it
less
known problems are, and what the
second- and third-order consequences of some set
of
will be.
such as the use of some software engineering tool
The consequenses of this situation are
actions
predictable
(Kotter,
1978):
Since they lack confidence in their assessment of the risks
techniques,
improvement
and benefits of organizational
managers quite often choose not to use them. As a result,
seriously
are
techniques
useful
many
potentially
Even when they are used, they are sometimes
underutilized.
used inappropriately. Managers select the wrong techniques,
Then,
or
the wrong time or in the wrong way.
use them at
they tend to
fulfilled,
when their expectations are not
become even less willing to experiment with organizational
improvement tools.
Our
software
objective
development
in
this
managers
research
and
effort
researchers
another specific software engineering tool, but
useful
way
of
is
provide
(not
instead)
both
with
with
yet
a
thinking about organizational improvement issues.
Our aim is to develop an integrative
management
of
software
project
that can help them answer the difficult questions they
need to raise
improvement
model
when
assessing
organizational
health,
selecting
tools (from the many that are already available), and
implementing their choices.
II. AN INTEGRATIVE SYSTEM DYNAMICS COMPUTER MODEL
OF SOFTWARE PROJECT MANAGEMENT
In a special issue
of
IEEE
the
Transactions
Software
on
Engineering on Project Management, Merwin (1978) asserted that:
What is still needed is the overall management fabric which
allows the senior project manager to understand and lead
major data processing development efforts.
At MIT's Center for Information Systems Research
are
currently
engaged
in
"overall management fabric."
develop
we
research project to develop such an
a
Specifically, our
objective
is
to
an integrative system dynamics computer model of software
development project management.
helpful
(CISR),
to
software
would
be
researchers
in
Such a model (we feel)
development
managers
and
handling the ever increasing complexities of software
production,
and thereby improve their abilities in identifying more accurately
both
their more important problems, as well as the more effective
solutions to those problems.
Models
which
are
usually
abstractions of real-world systems
simplified
but
formal
have been effectively used,
many
for
years
now,
research, management
complex
specific
is
by practitioners in fields like operations
and
science,
systems
analysis
decision problems (Cleland and King, 1975).
important to realize, here, that we, on
other
the
to develop a general -type of model.
attempting
handle
to
hand,
It
are
Can such a model,
one might ask, have any widespread applicability?
an
In
constraints
investigation
empirical
of
EDP
departments
in
objectives
the
of
industries, Hallam
various
(1975)
found high goal congruence and high
i.e.,
a
and
congruence
constraint
high degree of agreement was found among all types of EDP
And based on
departments studied regarding goals and constraints.
the findings of his study Hallam then concluded that:
The primary beneficiary of the description here of EDP goals
and constraints
is the model builder interested in modeling
found among all
the EDP management process.
The agreement
types of EDP departments regarding goals and constraints
indicates that a
should encourage model builders, since it
general
EDP
department
model
should have widespread
applicability.
(underlining ours)
In the remainder of this section,
for
the
characteristic
three
we would like now to
"features"
of
together differentiate our modeling approach
others
the
in
area
of
(2)
model
it
is
a
computer
model;
(1)
it
and
that
engineering.
software
characteristic features being:
model, which
our
from
is
an
(3)
it
of
The
integrative
is a
argue
many
three
model;
system dynamics
Why an Integrative Model:
II.l.
first
Let us start off by
demonstrating
that
we
are
not
(completely) alone in believing that building an integrative model
of
development
software
project management is not an infeasible
venture:
functions,
actions,
I believe that by combining the various
and interactions of software development management and
overlaying them on a framework of a standard management
model,
a model of a generalized software engineering project
(Thayer, 1979)
management system can be identified.
The integrative feature of our
project
managers
two
in
model
important ways.
software
help
should
First,
it
should help
them diagnose more accurately what is causing and what has lead to
problems
whatever
primarily,
have
they
"alerting"
by
identified.
It
would
that,
do
managers to all the relevant facets of
software production e.g., human as well as technological.
Because "interactions and interdependencies are common in all
social
systems,
necessitate
one
of
the
organizations
an
and
are
complicating
major
which
factors
overall system concept" (Cleland and King, 1975),
major
difficulties
facing
both
students
of
and managers trying to improve their functioning is
the lack of such overview models
(Schein, 1980).
Many studies have indicated that managers often deal with the
problems they encounter
in
terms of
mental
models
that
do
not
necessarily include all the elements or aspects of the problematic
situation.
Technically
trained managers,
in particular,
tend to
underestimate the influences of their internal social
organizational performance (Kotter, 1978).
the
problem
software
achieving
of
with
technical
the
(e.g., desining, coding,
...
By explicitly
reliability.
planning
and
staffing
of software development
processes
integrative
in an
etc.)
on
Consider, for example,
incorporating the managerial functions of
together
systems
model,
a
manager is "prompted" to investigate not only the technical issues
but also the implications of:
of software reliability,
*
Pressures
begin coding before the design is completed
to
because of tight schedules.
*
Insufficient emphasis on programmer education and training.
matching
Poor
*
abilities
programmers'
of
with
job
assignments.
(In a study reported by Myers
(1976), the above three factors
contributed more to the generation of serious software errors than
did any weaknesses
processes.
implementation,
design,
the
in
or
)
The second way in which the integrative feature of our
should
rational
testing
helpful
be
basis
interventions,"
is
for
and
for
that
it
would
assessing
managers with
provide
their
a
"improvement
feasible
identifying
model
probable
impact once
implemented.
Again, by providing a comprehensive
should
help
managers
assess
the
world
view,
second-
and
the
model
third-order
consequences of some set of actions.
The chain of effects in going from
(e.g., hiring more people)
intervention
then to second- and third-order
particular
a
managerial
to immediate consequences
consequences
created
newly
and
problems
is one of the pervasive characteristics of modern social
systems.
Quite literally, in such systems everything
(Cleland
else
everything
who
King,
trying
are
to
can
improve
on
That is why, many
1975).
models
overview
researches assert that
managers
and
depends
be
major
aids
to
organizations'
their
effectiveness (Schein, 1980).
For
example,
software
the
contemplating hiring more people to speed up
be
manager
project
a
who
is
late project, would
"prompted" by our integrative model to investigate the dynamic
implications of such
*
decision on things such as:
a
the human communication overhead, and the effect of that on
productivity, and
*
the time
and
allocated
effort
by
the
experienced
and
productive team members to train new personnel.
1
1. 2.
Why a Computer Model
Using an integrative model merely to "alert" managers to
the
important
essential,
undoubtedly
aspects
of
a
problem,
is definitely not enough.
contain
a
all
while clearly useful and
Because such
a
model
large number of components with
a
will
complex
10
network of interrelationships, we
effective
means
must
in
addition
provide
an
to determine both accurately and efficiently the
dynamic behavior implied by such component interactions.
Since the ultimate aim is to explain and predict the behavior
organizations,
of
not
of
individual components,
it
is
necessary to have a method which allows us to construct and
manipulate a total
organization.
Computer
simulation
techniques provide one such method.
(Cohen and Cyert, 1963)
Computer models have been, of course, widely used to simulate
many of our complex technological systems.
Our social systems are
far more complex and harder to understand than
systems.
Why,
then,
computer models
experiments"
of
on
do
social
these
our
technological
we not use the same approach of making
systems
models
conducting
and
before
we
try
"laboratory
new policies and
procedures?
The answer is often stated that our knowledge of social
But
systems is insufficient for constructing useful models.
what justification can there be for the apparent assumption
that we do not know enough to construct models but believe we
do know enough to directly design new social systems by
I
am
passing laws and starting new social programs?
useful
models
make
we
now
know
enough
to
suggesting that
do
Conversely, we do not know enough to
of social systems.
design the most effective social systems directly without
But
first going through a model-building experimental phase.
is
and substantial supporting evidence
I
am confident,
the proper use of models of
that
beginning to accumulate,
and
laws,
social systems can lead to far better systems,
programs.
(Forrester, 1971)
Experience from working with managers
indicates
that
relationships
resources,
they
and
are
to determine accurately the
many
environments
generally able to specify the detailed
interactions
and performance.
in
among
managerial
policies,
However, managers are usually unable
dynamic
behavior
implied
by
these
11
relationships.
Human intuition, studies have shown, is illsuited
for calculating the consequences of a large number of interactions
over time (Richardson and Pugh, 1981).
Unlike
mental model, a system dynamics computer
a
model
can
and effeciently trace through time the implications of a
reliably
messy maze of interactions.
And it can do that without
stumbling
over phraseology, emotional bias, or gaps in intuition (Richardson
and Pugh, 1981)
By utilizing computer simulation techniques in this
effort
thus,
we,
strengths
the
of
relationships
computer
'
combine
then
the strengths of the manager with the
computer.
within
research
The
software
the
calculates
the
manager
aids
by
specifying
project managent system, the
dynamic
consequences
these
of
relationships.
1
1. 3.
Why a System Dynamics Model
System
dynamics
is
the
application
of
feedback
control
systems principles and techniques to managerial and organizational
problems (Roberts, 1981).
Most succinctly, feedback is the transmission and
information.
is on
The emphasis,
the return.
will later be
A feedback
influenced
by
return
of
inherent in the word feedback itself,
loop exists whenever an action taker
the
consequences
of
his
or
her
12
Feedback
actions.
loops
divide
naturely
into two categories,
which are labeled deviation-amplifying feedback (DAF) or
and
loops,
deviation-counteracting
feedback
(DCF)
positive
or negative
loops.
It is pertinent that we think
in
terms
of
loops
feedback
because (Weick, 1979):
cause-effect relationships that exist in organizations
causal
Sometimes these
dense and often circular.
circuits cancel the influences of one variable on another,
and sometimes they amplify the effects of one variable on
of causal relationships that
is
the network
another.
It
organizations and that
in
the controls
impose many of
organization.
It is the patterns of
stabilize or disrupt the
much
of what happens in
account
for
these causal links that
these causal
visible,
directly
not
organizations. Though
organizations
in
happens
of
what
for
more
patterns account
than do some of the more visible elements such as machinery,
timeclocks,
The
are
.
.
A point which is important in particular to
of
the
application
deviation-amplifying feedback (DAF) to management, concerns the
between
distinction
(1)
the initial event (from outside a loop)
which starts the deviation amplifying process in motion,
the
and
(2)
While
dynamics of the feedback process which perpetuates it.
the initial event is important in determining the direction of the
subsequent deviation amplification, the feedback process
important
to
an understanding of the system (Ashton,
initial event sets in motion
final
effects
original push.
quite
out
a
of
is
1976).
cumulative process which
can
more
The
have
proportion to the magnitude of the
The push might even be withdrawn after a time, and
still a permanent change will remain or even the process of change
will continue without a new balance in sight.
A
further
problem
13
is
after
that,
difficult,
if
some
period
of
time
has
elapsed,
not impossible, to discover the initial
it
may be
event.
An
interesting example of this has been provided by Wender (1968):
fat
and
pimply
... a
adolescent
may
withdraw in
embarrassement and fail to acquire social skills;
in
adulthood,
acne and obesity may have disappeared but low
self-esteem, withdrawal, and social ineptitude may remain.
Social withdrawal and low self esteem are apt to stay fixed
because the DAF chain now operates:
social ineptitude leads
to
rejection,
which leads to lowered self-esteem, greater
withdrawal, less social experience, and greater ineptitude.
What has initiated the problem is no longer sustaining it. A
knowledge of the problem's origin would not be expected to
alter the currently operative loop unless such insight served
to motivate behavioral change ...
Finding the initial event (acne and obesity) may have less
usefulness than understanding the current sustaining feedback
mechanism. Furthermore, in some instances the initial event
may have left no traces of
its
existence and may be
undiscoverable.
It
because
is no wonder,
they
then, that "most mangers
forget to think in circles.
I
get
into
trouble
mean this literally.
Managerial problems persist because managers continue
to
that
independent
there
are
such things as unilateral causation,
believe
and dependent variables, origins, and terminations" (Weick, 1979).
14
III. AN EXAMPLE APPLICATION OF THE MODEL
A first version of our
computer
dynamics
of software development project management has already been
model
developed.'
and
integrative system
The model is presented and discussed
Madnick, 1982a).
(Abdel-Hamid
in
And in (Abdel-Hamid and Madnick, 1982b) the
model was used to investigate the
dynamics
of
project
software
scheduling.
conclude
It would be useful to
discussion
of
this
report
with
a
quick
the results of our second paper, as this would put
the concepts and ideas we've been discussing so far
perceptible form of
a
in
the
more
specific example application.
As mentioned above the specific problem area studied was that
of software project scheduling.
The software industry
is
young,
growing, and marked by rapid change in technology and application.
It
is
not surprising, then,
resources
(including
undeveloped.
In
the
the
last
that the ability to estimate project
time
few
resource)
is
still
relatively
years there has been a surge in
15
activity to develop quantitative resource estimation methods e.g.,
TRW
such currently available quantitative techniques
Because
1980).
are
(Putnam,
COCOMO model (Boehm, 1981) and Putnam's SLIM model
s
tailored
usually
first,
project/organizational
emphasize
techniques
set
imperfect,
necessity
the
of
to
via the planning and control
data
project
collect
continuously
limited
a
and second, are (still)
types,
such
the developers of
to
activities, compare estimates to actuals, and use the
results
to
"tune" the estimating tools (Boehm, 1981).
clearly
shown
and
significantly
influenced
the
incentives produced by the
system(s)
1981).
(Weil,
by
the
pressures,
In
particular,
the
real
make
take
to
perceptions,
and
planning
organization's
schedules was found to affect
achieved,
choose
they
actions
organizations,
years
people
that
decisions
the
that
few
past
the
Meanwhile research findings over
knowledge
progress
of
in
are
and
control
project
that
rate
have
is
well as the progress and problems that are reported
as
upward in the organization.
feedback
What this implies is the existence of a
below),
whereby
an
estimation
loop
produces
technique
(see
project
schedules, which affect the decisions and actions of the technical
performers
performance,
and
their
which
this
managers,
eventually
is
fed
in
turn
into
affects
work
the organization's
projects' database to influence future estimations.
16
Estimation
Method
Performance
Schedules
Ac t ions
Decisions^
Control
Notice that the above feedback loop integrates many different
It integrates technical as
aspects of software development.
as
human
planning
aspects,
managerial as well as production
system
dynamics
perspective
important to realize,
perspective
limited
more
is quite
well
as
Such
aspects.
an
scheduling
the
of
aspects, and
control
as
well
integrative
problem,
it
different from the more common
is
and
views the scheduling problem as
which
merely that of producing "better" estimates.
But what does the existence of such
a
feedback loop mean?
Is
it good or bad?
To most of us, the answers to
such
questions
will
not
be
intuitively obvious i.e., we can not answer them (with confidence)
merely
is not
on the basis of our private mental models.
The human mind
adapted to correctly anticipate the dynamic consequences of
between
interactions
(Forrester, 1971),
Unlike
a
the
parts
of
a
complex
social
system
such as that of software project management.
mental model,
a
computer model
through time the implications of
a
can
reliably
trace
messy maze of interactions.
17
Our computer model was thus utilized to conduct a "laboratory
experiment" to investigate the implications of the above
feedback
The experiment involved a hypothetical situation in which a
loop.
undertakes
company
sequence
a
software
ten
of
identical size.
It is assumed that an estimation tool
scheduling
projects.
the
database"
Once tuned,
and
used
is used
in
...
are
etc.)
into
fed
an
"tune" the estimation tool.
to
and
estimate the next project,
is then used to
it
of
each project is completed, its
After
statistics (e.g., size, total time,
"experience
projects
so
on.
After
experiment
the
completed
was
i.e.,
running
after
through the ten projects, we were surprised to observe that in all
the schedule was always overrun, as shown in the figure
projects,
Notice
below.
"PROJECTi")
that
with
a
previous one (i.e.,
always
overrun
longer
scheduled
"PROJECTi +1")
,
management
)
,
and
time
for
the
next
frequently
systems.
project
(i.e.,
and so on.
The (surprising) phenomenon we ecountered
been
would
"PROJECTi"
still
causing management to use an even
schedule,
duration
(e.g.,
longer scheduled duration than the
slightly
"PROJECTi-1"
its
project
each
started
observed
system
in
It has been termed
that
one
has
dynamics studies of social
Policy
"The
is
Resistence
Social
of
Systems," "Shifting the Burden to the Intervener," and "Addiction"
among
other
things.
While
a
(Abdel-Hamid and Madnick, 1982b)
full explanation is presented in
it
suffices here to draw
a
simple
18
Months
80
4"
Actual
Pro j ec
t
Dura t io
70
60
Est ima ted
Project Duration
50
40
30
PROJECT!
123456789
j
analogy to what was going on.
of
1
i
»
]0
caffeine addiction, whereby an addict has to consume
amount of
alertness.
caffeine
As
per
day
problem
And that is the (familiar)
to
maintain
a
certain
a
certain
level
of
time goes on, the burden of maintaining alertness
will keep shifting from the normal physiological body processes to
the externally supplied caffeine dose.
The result, of course,
is
that higher and higher doses will be required to maintain the same
level of alertness.
19
IV. CONCLUSION
This paper is a report on
an
ongoing
research
project
at
MIT's Center for Information Systems Research (CISR) to develop an
integrative system dynamics computer model of software development
management.
project
managers
development
We feel that such a model can help software
researchers
and
answer
difficult
the
questions they need to raise when assessing organizational health,
selecting
software engineering "improvement tools" (from the many
that are already available), and in implementing their choices.
Our modeling approach is different from that of many
In
section
we
(II)
argue
for
the attractiveness of the three
characterisic "features" of our model, namely, that
integrative
,
(2)
computer
,
In
section
(III)
it
is
an
(1)
and (3) system dynamics model.
A first version of our model has already been
used.
others.
we
developed
and
discuss some of the results of its
first application, to the problem of software project scheduling.
20
studies
Currently we are conducting field
organizations
that
are
involved
at
a
number
the production of software
in
systems.
The data gathered will be used to develop a second
detailed
model.
follow.
In the first,
we
will
problems,
use
the
which
model
the
to
uncover
management
organization "feel" are causing cost and schedule
a
more
Two planned applications of the model will then
"people-management"
second
of
of
overruns.
any
one
The
application of the model will be to evaluate the impact of
comprehensive
(and
expensive)
project
planning
and
control
system that has been recently installed in another organization.
21
BIBLIOGRAPHY
1.
Aaron,
Software
"The Super-Programmer Project."
J. D.
Rome
1969
Report on the
Engineering Techniques;
Conference
Editted by J. N. Buxton and B. Randell.
Brussels, Belgium: NATO Science Committee, 1970.
.
2.
of
Software
"A Model
Abdel-Hamid, T. K. and Madnick, S. E.
Project Management Dynamics." The Sixth Int'l Computer
Software and Applications Conference (COMPSAC) November
,
8-12, 1982a.
3.
"The Dynamics of
and Madnick,
S. E.
Abdel-Hamid, T. K.
Dynamis
A
System
Scheduling:
Software
Project
Perspective." The Third International Conference on
Also to
1982b.
December 13-15,
Information Systems
appear in an early 1983 issue of the Communications of
the ACM
,
.
4.
"Deviation-Amplifying Feedback and Unintended
Ashton,
R. H.
Systems."
Accounting
Management
Consequences
of
4
Vol.
and
Society
Accounting, Organization
1, No.
(1976).
,
"Software."
Science
February, 1982.
5.
Bacon, G.
6.
Boehm,
7.
Cleland,
Systems Analysis and Project
D. I.
and King, W. R.
McGraw Hill, 1975.
Management
New York:
,
Englewood
B. W.
Software Engineering Economics
Prentice-Hall, Inc., 1981.
Cliffs, New Jersey:
.
.
8.
"Computer Models in Dynamic
and Cyert, R. M.
By
Behavioral Theory of the Firm
Economics."
A
Englewood Cliffs, New
R. M. Cyert
and J. G. March.
Jersey:
Prentice-Hall, Inc., 1963.
Cohen, K. J.
.
9.
IEEE Tr.
Cooper, J.D.
"Corporate Level Software Management."
on Software Management
SE-4.
No. 4, (July, 1978).
,
10.
A Claim Settled and a
"Naval Ship Production:
No. 6,
Vol. 10,
Interfaces,
Framework
Built."
Cooper,
K.
G.
22
(Dec. 1980).
11.
Forrester,
J. W.
"Counterintuitive
Behavior
Systems." Technology Review January, 1971.
of
Social
,
12. Gehring,
P.
and Pooch, U. W.
F.
"Software
13. Hallam,
S. F.
"An Empirical Investigation of
the Objectives
and
Constraints
of
Electronic
Data
Processing
Departments." Academy of Management Journal
Vol. 18,
No. 1, (March, 1875).
,
14. Kotter,
J. P.
Organizational
Dynamics:
Intervention
Reading, Massachusetts:
Publishing Company, 1978.
Diagnosis and
Addison-Wesley
.
15.
Lave, C. A.
and March,
the Social Sciences
16. McClure, C. L.
New York:
J. G.
.
An Introduction to models in
Harper & Row, 1975.
New York:
Managing Software Development and Maintenance
Van Nostrand Reinhold Company, 1981.
.
Software Management."
IEEE
17. Merwin, R. E.
"Guest Editorial
on Software Engineering
SE-4, No. 4 (July, 1978).
TR.
,
18. Myers,
G.
Software Reliability
J.
.
New York:
John Wiley
&
Sons, 1976.
19.
"Misproject Management:
Reality." California Management
Powers, R. F.
and Dickson,
Opinions,
Myths,
and
Review Spring, 1973.
G. W.
,
20.
Putnam,
"Software Cost Estimation and
Life-Cycle
L. H.
Control:
Getting the Software Numbers," IEEE Computer
Society, IEEE Catalog No.
EHO 165-1, 1980.
21.
Introduction to System
Richardson, G. P.
and Pugh III, A. L.
Dynamo
Cambridge,
Modeling
with
Dynamics
Massachusetts: The MIT Press, 1981.
.
22. Roberts,
E.
York:
23.
The Dynamics of Research and Development
Harper & Row Publishers, 1964.
D.
Roberts,
Managerial Applications of
E. B.,
ed.
The MIT
Dynamics
Cambridge, Massachusetts:
1981.
.
24.
25.
Schein,
E. H.
Englewood
1980.
Scott,
.
New
System
Press,
3rd edition.
Organizational Psychology
Prentice-Hall,
Inc.,
New Jersey:
.
Cliffs,
"Predicting Programmers
R. F.
and Simmons,
D. B.
IEEE Tr.
Group Productivity: A Communication Model."
on Software Engineering
SE-1, No. 4, (Dec, 1975).
,
23
26.
Singer,
L. M.
The Data Processing Manager's Survival Manual
New York: John Wiley & Sons, 1982.
27.
Thayer,
"Modeling a Software Engineering
R. H.
Project
Management
System."
Unpublished Ph.D. dissertation,
University of California, Santa Barbara, 1979.
28. Weick,
.
K. E.
The Social Psychology of Organizing
2nd
Reading,
Massachusetts:
edition.
Addison-Wesley
Publishing Company, 1979.
.
"Industrial Dynamics and Management Information
Systems."
Managerial Applications of System Dynamics
Edited by E. B. Roberts. Cambridge, Massachusetts: The
MIT Press, 1981.
29. Weil, H. B.
.
P. H.
"Vicious and Virtuous Circles:
The Role of
Deviation-Amplifying
Feedback
in
the
origin and
Perpetuation of Behavior." Psychiatry Nov., 1968.
30. Wender,
,
31.
Yourdon, E.
World
,
"The Second Structured
Vol. 12, No. 3, (1979).
Revolution."
Software
O^
Date Due
i
Lib-26-67
HD28.M414 no.1366- 82
Abdel-Hamid, T/An integrative approach
745324
0*BKS
00 1505
3
TOflO
DDE E30 Mbl