An integrative approach to modeling the software ... - DSpace@MIT

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