THE DYNAMICS OF SOFTWARE PROJECT SCHEDULING

Full text

(1)

REPO/Trs AND

ARTICLES

THE DYNAMICS OF

SOFTWARE PROJECT

SCHEDULING

TAREK K, ABDEL.HAMID and STUART E, MADNICK

Massachusetts Institute

of Technology

Tarek K. Abdel-Hamid' s pres- ent research interests include the management of software development projects, appli- cation of system dynamics to software engineering. Stuart E. Madnick's research in- cludes system design method- ologies, management infor- mation systems and database computers. He is an associate

editor of TODS, a trustee of the VLDB Foundation, a for- mer member of the board of governors of the IEEE Com- puter Society, and a founding

member and past chairman of the IEEE Technical Com-

mittee on Database Engineering.

Authors' Present Address: Tarek K. Abdel-Hamid and Stuart E. Madnick, Center for Information Systems Research, MIT, Sloan School of Management, 50 Memorial Drive, Cambridge, MA 02139. Madnick @ MIT-Multics Permission to copy without fee all or part of this material is granted provided that the copies are not made or dis- tributed for direct commer- cial advantage, the ACM co- pyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Com- puting Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. © 1983 ACM 0001-0782/83/ 0500-0340500.75. 1. T H E D Y N A M I C S O F S O F T W A R E P R O J E C T S C H E D U L I N G : A N I N T R O D U C T I O N T h e s o f t w a r e i n d u s t r y is y o u n g , g r o w i n g , a n d m a r k e d b y r a p i d c h a n g e in t e c h n o l o g y a n d a p p l i c a t i o n . It is n o t sur- prising, t h e n , t h a t t h e a b i l i t y to e s t i m a t e p r o j e c t re- s q u r c e s , i n c l u d i n g t h e t i m e r e s o u r c e , is still r e l a t i v e l y u n d e v e l o p e d . In a r e c e n t s t u d y i n v e s t i g a t i n g t h e m a j o r p r o b l e m a r e a s f a c e d b y s o f t w a r e p r o j e c t m a n a g e r s t o d a y , " . . . t h e a b i l i t y to e s t i m a t e a c c u r a t e l y t h e r e s o u r c e s re- q u i r e d to a c c o m p l i s h a s o f t w a r e d e v e l o p m e n t " a n d " . . . t h e a b i l i t y to e s t i m a t e a c c u r a t e l y t h e d e l i v e r y t i m e o n a s o f t w a r e d e v e l o p m e n t " w e r e t w o of t h e t h i r t e e n " d e f i n i t e " p r o b l e m a r e a s i d e n t i f i e d [8].

The problem of resource estimating of computer pro- gram system development is fundamentally qualitative rather than quantitative. We don't understand what has to be estimated well enough to make accurate estimates. Quantitative analyses of resources will augment our qual- itative understanding of program system development, but such analyses will never substitute for this under- standing [1]. T h i s is w h y w h e n m e t h o d s of e s t i m a t i n g a r e r a n k e d , t h e list is h e a d e d by w h a t A a r o n c a l l e d t h e e x p e r i e n c e m e t h o d - - e s t i m a t e s t h a t a r e l a r g e l y b a s e d o n h u m a n j u d g e m e n t s g a i n e d t h r o u g h p r e v i o u s e x p e r i e n c e s w i t h s o f t w a r e p r o j e c t s [1]. In t h e last f e w y e a r s t h e r e h a s b e e n a s u r g e in a c t i v i t y to d e v e l o p " q u a n t i t a t i v e " r e s o u r c e e s t i m a t i o n m e t h o d s , for e x a m p l e , T R W ' s C O C O M O m o d e l [3] a n d P u t n a m ' s SLIM [5]. A c l o s e r look, h o w e v e r , r e v e a l s t h a t " a t h e a r t " s u c h m e t h o d s a r e still of t h e e x p e r i e n c e type, s i n c e t h e y all get c a l i b r a t e d u s i n g h i s t o r i c a l d a t a o n c o m p l e t e d soft- w a r e p r o j e c t s .

F o r e x a m p l e :

The initial COCOMO m o d e l . . , was calibrated using 12 completed projects. The resulting model was then evalu- ated with respect to a fairly uniform sample of 36 proj- ects, primarily aerospace applications, producing fairly good agreement between estimates and a c t u a | s . . .

The calibration and evaluation of COCOMO has not relied heavily on advanced statistical techniques. After trying to apply advanced statistical techniques to software cost estimation, and after observing similar efforts by oth- ers, I have become convinced that the software field is currently too primitive, and software cost driver interac- tions too complex, for standard statistical techniques to make much headway; and that more initial progress

ABSTRACT: Software project scheduling is one of the major problem areas faced by software project managers today. While several quantitative software project resource and schedule es- timation methods have been de- veloped, such techniques raise some important, but as yet unre- solved, dynamic issues. A sys- tems dynamics (SD) approach is used to analyze several key dy- namic software project schedul- ing issues.

(2)

REPORTS AND ARllCLES

could be made by trying to formulate empirically the

nature of the interactions between cost drivers, using functional forms which reflected the best available per- spectives and data on software life-cycle phenomenology. Because the c u r r e n t l y a v a i l a b l e q u a n t i t a t i v e t e c h n i q u e s are u s u a l l y t a i l o r e d to a l i m i t e d set of p r o j e c t / o r g a n i z a - tional types and are still imperfect, the d e v e l o p e r s of such t e c h n i q u e s e m p h a s i z e the n e c e s s i t y to c o n t i n u o u s l y collect project data via the p l a n n i n g a n d control activi- ties, c o m p a r e e s t i m a t e s to actuals, a n d use the results to i m p r o v e the e s t i m a t i n g tools.

F u r t h e r m o r e , r e s e a r c h findings o v e r the past few y e a r s have c l e a r l y s h o w n that the decisions that p e o p l e m a k e in organizations a n d the actions t h e y choose to take are s i g n i f i c a n t l y i n f l u e n c e d by the pressures, perceptions, and i n c e n t i v e s p r o d u c e d by the o r g a n i z a t i o n ' s p l a n n i n g and control system(s) [9]. In p a r t i c u l a r , k n o w l e d g e of p r o j e c t s c h e d u l e s was found to affect the real progress

rate that is a c h i e v e d , as well as the progress and prob- lems that are r e p o r t e d u p w a r d in the organization.

W h a t this i m p l i e s is the e x i s t e n c e of a f e e d b a c k loop (see Figure 1): an e s t i m a t i o n t e c h n i q u e p r o d u c e s project schedules, w h i c h affect the decisions a n d actions of the t e c h n i c a l p e r f o r m e r s a n d t h e i r managers, w h i c h in t u r n

I'-st imot ion

y

Method

Per formonce

Schedules

Act ions, Y

Decisions

FIGURE 1. Scheduling Feedback Loop.

affect w o r k p e r f o r m a n c e , w h i c h e v e n t u a l l y is fed into the o r g a n i z a t i o n ' s p r o j e c t s ' d a t a b a s e to i n f l u e n c e f u t u r e estimations.

But w h a t does the e x i s t e n c e of s u c h a f e e d b a c k loop m e a n ? Is it good or bad? To most of us, the a n s w e r s to such questions will not be i n t u i t i v e l y obvious, that is, w e c a n n o t a n s w e r t h e m w i t h c o n f i d e n c e m e r e l y on the basis of our p r i v a t e m e n t a l models. T h e h u m a n m i n d is not a d a p t e d to c o r r e c t l y a n t i c i p a t e the d y n a m i c conse- q u e n c e s of i n t e r a c t i o n s b e t w e e n the parts of a c o m p l e x societal s y s t e m [4], such as that of software project m a n - agement. T h e most f a m i l i a r e x a m p l e in the l i t e r a t u r e is p e r h a p s "Brooks' Law.' W h e n a project falls b e h i n d s c h e d u l e , m a n a g e r s often a t t e m p t to s p e e d up the project by a d d i n g m o r e people. Brooks suggests that m a n a g e r s fail to a n t i c i p a t e the d y n a m i c c o n s e q u e n c e s of s u c h an action, for e x a m p l e , the i n c r e a s e in the c o m m u n i c a t i o n o v e r h e a d a n d the n e e d to d i v e r t p r o d u c t i v e t i m e of the c u r r e n t p e r s o n n e l to the t r a i n i n g of the n e w people. The net effect is that the project m a y a c t u a l l y fall f u r t h e r b e h i n d schedule.

A Systems D y n a m i c s Model is i m p o r t a n t b e c a u s e " U n - like a m e n t a l model, a s y s t e m d y n a m i c s c o m p u t e r m o d e l can r e l i a b l y trace t h r o u g h t i m e the i m p l i c a t i o n s of a n y m e s s y m a z e of a s s u m p t i o n s a n d i n t e r a c t i o n s " [6]. It can do so w i t h o u t s t u m b l i n g o v e r phraseology, e m o t i o n a l bias, or gaps in intuition. Even for those gifted few w h o can c o r r e c t l y a n s w e r the a b o v e questions on the basis of m e r e intuition, a formal s y s t e m d y n a m i c s m o d e l can p r o v i d e a p o w e r f u l c o m m u n i c a t i o n tool that can m i n i - mize m i s u n d e r s t a n d i n g and m i s c o m m u n i c a t i o n .

In the r e m a i n d e r of this p a p e r w e will e l a b o r a t e the a b o v e a r g u m e n t further. We will a t t e m p t to d e m o n s t r a t e h o w the modeling, s i m u l a t i o n , a n d analysis t e c h n i q u e s of s y s t e m d y n a m i c s (SD) can be p o w e r f u l tools in s t u d y - ing the c o m p l e x a r e a of software project m a n a g e m e n t in general, and the s c h e d u l i n g issues d i s c u s s e d a b o v e in p a r t i c u l a r .

2. COMPUTER MODELING OF S O C I A L SYSTEMS: THE SYSTEM DYNAMICS PERSPECTIVE

People would never attempt to send a sp/lceship to the moon without first testing the equipment by constructing prototype models and by computer simulation of the an- ticipated space trajectories. No company would put a new kind of household appliance or electronic computer into production without first making laboratory tests. Such models and laboratory tests do not guarantee against fail- ure, but they do identify many weaknesses which can then be corrected before they cause full-scale disasters.

Our social systems are far more complex and harder to understand than our technological systems. Why, then, do we not use the same approach of making models of social systems and conducting laboratory experiments on those models before we try new laws and government programs in real life? The answer is often stated that our knowledge of social systems is insufficient for construct- ing useful models. But 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 di- rectly design new social systems by passing laws and starting new social programs? I am suggesting that we now do know enough to make useful models of social systems. Conversely, we do not know enough to design the most effective social systems directly without first going through a model-building experimental phase. But I am confident, and substanci~ ! supporting evidence is be- ginning to accumulate, that the proper use of models of social systems can lead to far better systems, laws, and programs [4].

Indeed, it is now possible to use the modeling, s i m u l a - tion, a n d s y s t e m analysis t e c h n i q u e s of s y s t e m d y n a m i c s in the l a b o r a t o r y to c o n s t r u c t m o d e l s of m a n a g e r i a l sys- tems. Such m o d e l s are o b v i o u s l y simplifications of the a c t u a l social s y s t e m s but can be far m o r e c o m p r e h e n s i v e t h a n the m e n t a l m o d e l s that are o t h e r w i s e used.

S y s t e m D y n a m i c s (SD) is the a p p l i c a t i o n of f e e d b a c k control systems p r i n c i p l e s and t e c h n i q u e s to m a n a g e r i a l and o r g a n i z a t i o n a l problems. T h e SD p h i l o s o p h y rests on a b e l i e f that the b e h a v i o r (or t i m e history) of an organi- zational e n t i t y is p r i n c i p a l l y c a u s e d b y its structure. The s t r u c t u r e includes, not o n l y the p h y s i c a l aspects, but m o r e i m p o r t a n t l y , the policies a n d traditions, b o t h tangi- ble a n d intangible, that d o m i n a t e decision m a k i n g in the o r g a n i z a t i o n a l entity. S u c h a s t r u c t u r a l f r a m e w o r k con- tains sources of amplification, t i m e lags, a n d i n f o r m a t i o n f e e d b a c k s i m i l a r to those found in c o m p l e x e n g i n e e r i n g systems.

The s y s t e m d y n a m i c s a p p r o a c h begins w i t h an effort to u n d e r s t a n d the s y s t e m of forces that has c r e a t e d a p r o b l e m a n d c o n t i n u e s to s u s t a i n it. R e l e v a n t d a t a are g a t h e r e d u s u a l l y from a v a r i e t y of sources, for e x a m p l e , l i t e r a t u r e , i n f o r m e d people, etc. As soon as a r u d i m e n - t a r y m e a s u r e of u n d e r s t a n d i n g has b e e n a c h i e v e d , a for- mal m o d e l is developed. This m o d e l is i n i t i a l l y in the format of a set of logical d i a g r a m s s h o w i n g c a u s e - a n d - effect relationships. As soon as is feasible, the visual m o d e l is t r a n s l a t e d into a m a t h e m a t i c a l version. The m o d e l is e x p o s e d to criticism, revised, e x p r e s s e d again,

(3)

REPO/Trs AND A/Tr/CLES

and so on, in an i t e r a t i v e process that c o n t i n u e s as long as it proves to be useful. Just as the m o d e l is i m p r o v e d as a result of successive e x p o s u r e s to critics, a s u c c e s s i v e l y b e t t e r u n d e r s t a n d i n g of the p r o b l e m is a c h i e v e d by the p e o p l e w h o p a r t i c i p a t e in the process.

Such an a p p r o a c h forces those i n v o l v e d in s y s t e m de- sign to m a k e explicit and t h o r o u g h l y test the a s s u m p - tions that u n d e r l i e t h e i r design decisions: the n a t u r e of p r o b l e m s , t h e i r causes, the c o n s e q u e n c e s of a l t e r n a t i v e actions, a n d h o w v a r i o u s h u m a n , m a n a g e r i a l , economic, a n d o p e r a t i o n a l factors interrelate. Weil reports that his e x p e r i e n c e has s h o w n that this is a v e r y v a l u a b l e proc- ess; people are r e a l l y quite s u r p r i s e d w h e n it t u r n s up things no one had t h o u g h t of before, i n c o r r e c t a s s u m p - tions, and differences of o p i n i o n a b o u t cause a n d effect

[9].

Roberts has stated that p e o p l e ' s

. . . intuition about the probable consequences of pro- posed policies frequently proves to be less reliable than the model's meticulous mathematical approach . . . This is not surprising as it may first appear. Management systems contain as many as 100 or more variables that are known to be related to one another in various nonlinear fashions. The behavior of such a system is complex far beyond the capacity of intuition. Computer simulation is one of the most effective means available for supplementing and correcting human intuition [7].

S y s t e m d y n a m i c s is suitable for a d d r e s s i n g c e r t a i n k i n d s of c o m p l e x problems. In a d d i t i o n to c o m p l e x i t y , such p r o b l e m s h a v e at least two features in c o m m o n . First, t h e y are d y n a m i c , that is, t h e y i n v o l v e q u a n t i t i e s that c h a n g e o v e r t i m e a n d that can, therefore, be ex- p r e s s e d in t e r m s of graphs of v a r i a b l e s o v e r time. Oscil- lating levels of e m p l o y m e n t in an i n d u s t r y , a d e c l i n e in a city's tax base a n d q u a l i t y of life, a n d the d r a m a t i c a l l y rising p a t t e r n of h e a l t h care costs are all d y n a m i c prob- lems [6]. Cost o v e r r u n s , slippages in s c h e d u l e d c o m p l e - tion dates, and the v a r i a b i l i t y in p r o d u c t i v i t y are s o m e of the d y n a m i c p r o b l e m s that can arise in a software pro- ject.

A s e c o n d f e a t u r e of the p r o b l e m s to w h i c h the s y s t e m d y n a m i c s p e r s p e c t i v e applies i n v o l v e s the n o t i o n of feed- back. "Most s u c c i n c t l y , f e e d b a c k is the t r a n s m i s s i o n and r e t u r n of information. The e m p h a s i s , i n h e r e n t in the w o r d f e e d b a c k itself is on the r e t u r n " [6]. A f e e d b a c k s y s t e m exists w h e n e v e r an action t a k e r will later be in- f l u e n c e d by the c o n s e q u e n c e s of his or h e r actions. T h e c o n s e q u e n c e s m a y be q u i c k a n d d i r e c t l y a p p a r e n t in re- sults p r o d u c e d , for e x a m p l e , w h e n the h i r i n g of ten m o r e p r o g r a m m e r s i n c r e a s e s the p r o g r a m m e r s ' w o r k f o r c e to a c e r t a i n d e s i r e d level, w h i c h in t u r n feeds b a c k to affect the h i r i n g rate, that is, stopping f u r t h e r hiring. Or the c o n s e q u e n c e s m a y be d e l a y e d t h o u g h d i r e c t l y a p p a r e n t in results p r o d u c e d , for e x a m p l e , w h e n a software devel- o p m e n t m a n a g e r ' s d e c i s i o n to use a p a r t i c u l a r p a c k a g e to e s t i m a t e h i s / h e r h u m a n r e s o u r c e r e q u i r e m e n t s affects the p r o j e c t ' s c o m p l e t i o n t i m e a n d cost, w h i c h in t u r n i n f l u e n c e s the m a n a g e r ' s later e s t i m a t i o n p r o c e d u r e . Fi- nally, the c o n s e q u e n c e s m a y be both d e l a y e d a n d quite i n d i r e c t in p e r c e i v e d results, for e x a m p l e , w h e n a deci- sion to i n c r e a s e the software d e v e l o p m e n t b u d g e t leads to the h i r i n g of h i g h e r q u a l i t y m a n a g e r s a n d a n a l y s t s / p r o g r a m m e r s , w h o m a y t h e n d e v e l o p i m p r o v e d products, w h i c h m a y e n h a n c e the c o m p a n y ' s c o m p e t i t i v e position, in t u r n i n c r e a s i n g sales a n d / o r profits, w h i c h m a y t h e n i n f l u e n c e the decision on the software d e v e l o p m e n t

budget. In all these cases a "closing of the loop" occurs. A delay, w h e t h e r short or long, i n t e r v e n e s b e t w e e n ini- tial action and f e e d b a c k results. Closed loops a n d t i m e d e l a y s in c o n s e q u e n c e s are c h a r a c t e r i s t i c of all f e e d b a c k processes.

It is a p p a r e n t from the above that the m a n a g e m e n t of software d e v e l o p m e n t is a p r i m e c a n d i d a t e for applica- tion of the s y s t e m d y n a m i c s m e t h o d . It c l e a r l y is com- plex, it is d y n a m i c , and it does e x h i b i t f e e d b a c k b e h a v - ior.

In [2] we discuss, in some detail, a s y s t e m d y n a m i c s m o d e l w e d e v e l o p e d of software project m a n a g e m e n t . The m o d e l was d e v e l o p e d to be a tool in i n v e s t i g a t i n g the m a n y m a n a g e r i a l p r o b l e m s that s e e m to be plaguing software d e v e l o p m e n t activities in most organizations, for e x a m p l e , cost and s c h e d u l e o v e r r u n s . In p a r t i c u l a r , the m o d e l serves as a " s k e l e t o n " on top of w h i c h "cus- t o m " m o d e l s can be built to fit different o r g a n i z a t i o n a l / project settings.

In Sec. 4 w e use the m o d e l to a n a l y z e the d y n a m i c s of software project s c h e d u l i n g , an e x e r c i s e we hope will p r o d u c e some insights into the issues raised in Sec. 1. To set the stage for this discussion, w e will c h a r a c t e r i z e , n e x t in Sec. 3, the software project (which w e will sim- ply call EXAMPLE) to be used in our analysis.

3. C H A R A C T E R I Z I N G THE " E X A M P L E " S O F T W A R E PROJECT

One of the a t t r a c t i v e features of a c o m p u t e r m o d e l is its high versatility. By s i m p l y c h a n g i n g a few m o d e l p a r a m - eters, for e x a m p l e , one can easily s i m u l a t e a w i d e range of software project types. The software project EXAM- PLE involves the d e v e l o p m e n t of a 400,000 DSI system. (DSI stands for " D e l i v e r e d S o u r c e I n s t r u c t i o n s . " See [3] for a c o m p l e t e definition.) All of the m o d e l ' s g r a p h i c a l output, will be in t e r m s of the unit, task, w h e r e a task is

o 0 O O O c~O 0(5

~ o O o o

o o o o o I ~ I

-~o at}- Currently Perceived

P r o j e c t S i z e 0 0 0 0 0 O O O ( 5 ( 5 o Loo o ~, 1 - - r--~. Or'-- ScheduIed D u r a t i o n , ' / 0 0 0 0 0 0 0 0 0 ~O 0 0 d _ _ W o r k force

,'5 W

0 ~ 0 0 ~ n ,,'~ .n ~<r .,2" ,9" Cumulatlve

,~

Tosks Wor.d ~ , 2 0 0 0 0 0 0 0 0 0 0 ,.~ O ~ O o ~ -- ,,2_~ o''

.¢"

,'Y~--- c 0 ~t

/z

D,scovered ~-

,~

/

R e w o t W o°°o°q° ~" I I 0 0 0 0 0 0 0 00 I0000 2 0 0 0 0 O ° T i m e ( m o n t h s ) o I 3 0 0 0 0 W W o r k f o r c e ( p e o p l e ) C , C u m u l o t l v e T a s k s WorWed (TosWs) D ~ D i s c o v e r e d Rework (Tosks) S ~ Scheduled O u r a f l o n ( m o n t h s ) T ' C o s t ( $ 1 , O O O )

P : Currently Perceived Project Size (Tasks)

(4)

REPORTS AND ART/CLES

equivalent to 400 DSI. (Our project is, thus, of size 1000 tasks.) The development period modeled begins at the beginning of the product design phase and ends at the end of the integration and test phase. We deliberately excluded the requirements definition/specification phase so we could incorporate the use of TRW's COn- structive COst MOdel (COCOMO) [3]. That is, we assume that management will use COCOMO to estimate the ef- fort in man-months (MM), the total development time in months (TDEV), and the staff size (SS).

In this section we characterize our EXAMPLE software project. We will do it in a stepwise fashion. We will start with an "ideal" project situation and then, step-by-step, add increments of "reality."

Step (1): The "Flawless" Project

In the ideal case, managemenrs estimate of the project's size will be exactly on target, that is, 400,000 DSI or 1000 tasks. Using the (Basic form of the) COCOMO model, an estimate of the effort in man-months (MM) can then be made.

MM = 2.4 (DSI/1000) '.°'~

= 2.4 (400,000/1000) 1°5 = 1295 man-months

From this an estimate of the project's total develop- ment time (TDEV) can be calculated.

TDEV = 2.5 (MM) ":m

= 2.5 (1295) "38 = 38 months

Finally, the average staff size (SS) is determined. SS = MM/TDEV

= 34 people

The dynamic behavior of the "flawless" project situa- tion is shown in Figure 2. The project's scheduled com- pletion duration is set to 38 months and a workforce of 34 people is assembled (e.g., during the requirements/ specification phase). As can be seen, the project proceeds "smoothly" and is completed on schedule at a total cost of $7,810,600. (It is assumed that a rather uniform effort is required throughout the project. This simplifying as- sumption will be relaxed in a later version of the model in which the software lifecycle will be explicitly divided into three phases: design, coding, and testing.)

Unfortunately the project behavior of Figure 2 is rarely

0.4 0.3 ~: 0.2 .,'e 0.1 0 . 0 v 0 . 0 0.2 0.4 0.6 0.8 1.0

Fraction of Tasks Completed FIGURE 3. Assumed Shape of FERR.

(if ever) realized in real organizations. It will, therefore, only serve us as a reference point for further analysis.

Step (2): Introducing Rework

Not all work done in the course of a large software pro- ject is errorless. Some fraction of the work will be less than satisfactory (e.g., inconsistent design, defective code, etc.) and must be redone. The unsatisfactory work may not be discovered right away, however. For some time it passes unrecognized, until the need for reworking the tasks shows up. The discovery of unsatisfactory work that needs reworking can, of course, cause major disrup- tions in a software project (e.g., people are diverted from new tasks to redoing old ones) and is, therefore, a signifi- cant element of the software development environment.

In the model, the generation of rework is regulated by FERR, which is the fraction of work that is erroneous. For example, a value of FERR equal to 0.1 means that 10 percent of the tasks completed in a particular unit of time will be defective, and will thus require reworking. FERR is not modeled as a constant, however. It is a variable that changes during the life of the project. Fig-

oooo~o o . o d o O o ~ o oOddo ~0-~0- - oooO~ o o .oo Q ~ Q O o O ~ O o o o ooo8O o ° 0 ~ OoO~O o , o o o o o ~ 8 q g ~ oOOQU 0 d o 1 ,~ I I Currently Perceived Project Size so S' / , / / / / s , / Scheduled p / - - Work force ~ ." / / / / / Curnulotive / / Tosks / Worked } / i / I0.000 20.000 T i m e ( m o n t h s ) 30000 I /

FIGURE 4, Introducing Rework.

ure 3 depicts the assumed relationship between FERR and the fraction of tasks completed.

The rationale for making FERR a variable in this fash- ion is the realization that tasks near the beginning of a large software project (e.g., design) are much different from those near the end (e.g., documentation). Near the beginning, the project is being defined, different ap- proaches are being explored, ideas are on the drawing board, etc. Near the end, the tasks are more like finish- ing touches: assembling documentation, typing reports, and so on. The likelihood of performing work that must be redone is, thus, modeled to be greater at the begin- ning of the project than at the end.

The behavior of the model is shown in Figure 4. At the bottom of the figure, the level of rework perceived (i.e., discovered) throughout the life of the project is shown. The generation of rework means, of course, that more effort will be required to complete the project satisfactor-

(5)

REPORTS AND AR'r/CLES 8oo~o o o 0 O O o O o ° ° 0 ° ° ] Oo° o 8 8 ooo~o oo8~o 8ooo 8 o o O ~ o o o o . o o o o o d o 8 o o o o o o oo o

Cur rently Perceived .

Scheduled ~/, C)UTOtlO n ~ ' / ." / .... .-°" ,/ ~ . ~ . / " / Cumula,,ve .° / Tasks ." ~" Worke d " ~ s " / . f o" / I0 OOO 20 OO0 FIGURE 5. 50000 4O000 50O00 Time (months)

Introducing Personnel Turnover.

ily. After month 13 enough rework is discovered to cause management to start hiring more people in order to meet the initial scheduled completion date. This policy con- tinues until month 29, when management chooses in- stead to extend the project's target completion date and slow down the hiring of new people. The project eventu- ally completes after 41.5 months, at a total cost of $9,024,700.

Step (3): Introducing Personnel Turnover

In this run we divert even further from the flawless project situation. I n addition to the generation of re- work, we introduce the effect of personnel turnover. In the flawless project run it was assumed that people do not quit (after all, who would quit an ideal project?). For this run, we assume that the average employment time is 24 months. As shown in Figure 5, the project is ad- versely affected, finishing even later at month 51 and at a higher cost of $9,582,400.

Step (4): Introducing Estimating Error

In the flawless project we assumed that management's estimate of the project's size was exactly on target, that is, 1000 tasks. Obviously this is too optimistic an assump- tion. o o o ~ O o O O O ~ o O O O Curren~ly Percelved o ...

'"-L._/

/ ,

0°o%

/

..-2."

8 . . . . - - Scheduled

~ . ~

J~ -- . / s / / O o o o o o 8

- /

/ >

0°°°8 / Cu~ulahve s J Tosks #" ooo~o o o ~0,.d "~." / s o ° o ~ 8 / I / ~N~N~ / 5 / " ~ C o s t S## /Rework O,scove,ea

o od~',~ I0 000 20OOO 5 0 0 0 0 40OO0 5OOOO

O

O Time (months)

d

FIGURE 6. Introducing Estimating Error.

For this run, we assume that management initially estimates the system's size to be 320,000 DSI or 800 tasks, that is, 20 percent lower than the real size of 400,000 DSI or 1000 tasks. The resulting project behavior is shown in Figure 6. The project completes in 51 months but at the slightly higher cost of $9,757,200.

Notice that the "currently perceived project size" starts at 800 tasks, but as the project progresses and the level of uncertainty decreases, it is adjusted upwards until at about month 35 "currently perceived project size" is in fact equal to 1000 tasks--the true project size. As management learns about the upward adjustments in the project's size, it adjusts its workforce upwards to the level it perceives is sufficient to complete the project within the scheduled 35 months. However, unexpected problems arise, for example, a system integration test fails miserably, which will necessitate the reworking of tasks believed to be successfully completed. When such disruptions occur towards the end of the project, man- agement is reluctant to hire new employees, and there is almost no other alternative but to extend the scheduled completion date, as shown in Figure 6.

In the next section we will use EXAMPLE to analyze the dynamics of software project scheduling. In all our subsequent simulation runs we will maintain our pro- ject's present level of "realism," that is, include rework, personnel turnover, and underestimation.

4. THE DYNAMICS OF SOFTWARE PROJECT SCHEDULING: A SIMULATION EXPERIMENT

In Sec. 1 we suggested that project schedules create pres- sures, perceptions, and incentives that affect the deci- sions and actions of the technical performers and their managers, that this in turn affects work performance, which is all eventually fed into the organization's proj- ects' database to influence future scheduling activities. We also suggested that the dynamic consequences of such a feedback loop are not intuitively obvious. The modeling, simulation, and analysis techniques of system dynamics were then proposed as a powerful tool to relia- bly deduce and analyze the dynamic behavior of com- plex feedback systems, such as that of managing software projects. In this section we use our system dynamics model of software project management to conduct a lab- oratory experiment to investigate the software project scheduling issues raised in Sec. 1.

The experiment involves a hypothetical situation in

which a company undertakes a sequence of ten identical

software projects, all identical to project EXAMPLE of Sec. 3. On the first such project, EXAMPLE1, the com- pany (lacking the experience) underestimates the size of the project by 20 percent, that is, estimates the project's size to be only 800 tasks. Using the (TRW calibrated) COCOMO model, the project's total effort and duration are then estimated to be 1025 m a n - m o n t h s and 35 months, respectively. But as we have already seen in Sec. 3 (Figure 6), the project actually consumes 1626 m a n - m o n t h s and is completed in 51 months.

After completing project EXAMPLE1, the following is learned:

• Project EXAMPLE1 is really 1000 (and not 800) tasks.

• It consumes 1626 man-months. • It takes 51 months to complete.

(6)

REPORTS A N D ART/CLES

T h e C O C O M O m o d e l ' s " g u a r d i a n " in the c o m p a n y t h e n notes that h a d a n a c c u r a t e e s t i m a t e of project size (i.e., 1000 tasks) b e e n m a d e , C O C O M O ' s e s t i m a t e s for effort a n d project d u r a t i o n w o u l d h a v e b e e n 1295 m a n - m o n t h s a n d 38 m o n t h s , respectively. K n o w i n g t h a t COCOMO is an i m p e r f e c t e s t i m a t i o n tool that n e e d s to be c o n t i n u o u s l y i m p r o v e d , a d j u s t m e n t s are m a d e s u c h that for a n y f u t u r e projects i d e n t i c a l to EXAMPLE1 esti- mates of 1626 m a n - m o n t h s a n d 51 m o n t h s w o u l d be p r o d u c e d .

Some t i m e later w h e n project EXAMPLE2 (which is i d e n t i c a l to EXAMPLE1) comes along, m a n a g e m e n t will be in a position to b e t t e r e s t i m a t e its true size. In fact, w e a s s u m e t h a t EXAMPLE2's size will be e s t i m a t e d per- fectly, that is, to be 1000 tasks. F u r t h e r m o r e , the n o w " i m p r o v e d " C O C O M O m o d e l will p r o d u c e e s t i m a t e s of 1626 m a n - m o n t h s a n d 51 m o n t h s for EXAMPLE2's total effort a n d d u r a t i o n , respectively. Based on these figures, m a n a g e m e n t d e t e r m i n e s that a staff size of 32 will be r e q u i r e d .

C o n d u c t i n g project EXAMPLE2 u n d e r s u c h c i r c u m - stances p r o d u c e s the b e h a v i o r of Figure 7. The project s t i l l finishes late, 56 m o n t h s after it started, a n d is 5 m o n t h s b e h i n d the " i m p r o v e d " s c h e d u l e .

W h e n w e r e p e a t e d the a b o v e s e q u e n c e of actions a n d reactions eight m o r e times for projects EXAMPLE3 t h r o u g h EXAMPLEIO, w e w e r e s u r p r i s e d to observe t h a t the s c h e d u l e was o v e r r u n in e a c h case. As a r e s u l t m a n - a g e m e n t s t a r t e d each project (e.g., EXAMPLEi) w i t h a slightly longer s c h e d u l e d d u r a t i o n t h a n the p r e v i o u s one (i.e., EXAMPLEi-1). However, EXAMPLEi w o u l d still o v e r r u n its s c h e d u l e , w h i c h c a u s e d m a n a g e m e n t to use [ I I t i I ..°°° Curr~tly PercelveO Project Size Scheduled J Duro lion I I l l • s S • i s ! • • ~ Work force ...,.-.~.~ - ~-- - - ~ . . ~ . Cumulotive s ° Tosks l * ~ wor~ld ~ . • Cost ~ / D~seove~e~

o o o O OOO 20000 30000 4000O 5OOOO

8 Time (months)

d

FIGURE 7. EXAMPLE 2 [Notice change in the COST scale],

an e v e n longer s c h e d u l e d d u r a t i o n for the n e x t project. T h e results for the ten s i m u l a t i o n r u n s are s h o w n in Figure 8.

It s e e m s o u r f e e d b a c k loop t u r n e d out to be q u i t e a villain, p r o d u c i n g d e v a s t a t i n g effects, e s p e c i a l l y o v e r the long run. Notice t h a t EXAMPLE1 was c o m p l e t e d in 51 m o n t h s , w h i l e n i n e projects later, EXAMPLE10 com- p l e t e d in 81.25 months! A v e r y significant d e t e r i o r a t i o n indeed.

The, s u r p r i s i n g p h e n o m e n o n w e o b s e r v e d is one t h a t has b e e n f r e q u e n t l y e n c o u n t e r e d in s y s t e m d y n a m i c s studies of real organizations. It has b e e n t e r m e d " T h e

o o o o o o 0 O O o O o O O o 0 o 0 o o o o o o , ~ o . §ooog o o ~ o o o g

==

|

80 70 60 50 40 30 I 1 2 - Actual Project Duration _ / ~ / / Project Duration _ / /

/

/

I I I I I I I 1- 3 4 5 6 7 8 9 1 0 v EXAMPLE i

FIGURE 8. Results of the Ten Simulation Runs.

Policy Resistance of Social S y s t e m s , " "Shifting the Bur- d e n to the I n t e r v e n o r , " a n d " A d d i c t i o n , " a m o n g o t h e r things. A s i m p l e e x a m p l e of s u c h a p h e n o m e n o n is t h a t of caffeine addiction, w h e r e b y an a d d i c t has to c o n s u m e a c e r t a i n a m o u n t of caffeine p e r d a y to m a i n t a i n a cer- tain level of alertness. As t i m e goes on the b u r d e n of m a i n t a i n i n g a l e r t n e s s will k e e p shifting from the n o r m a l physiological b o d y processes to the e x t e r n a l l y s u p p l i e d caffeine dose. T h e result, of course, is that h i g h e r a n d h i g h e r doses will be r e q u i r e d to m a i n t a i n t h e s a m e level of alertness.

F o r r e s t e r put it this way:

Social systems are inherently insensitive to most policy changes that people select in an effort to alter the behav- ior of the system. In fact, a social system tends to draw our attention to the very points at which an attempt to intervene will fail. Our experience, which has been de- veloped from contact with simple systems, leads us to look close to the symptoms of trouble for a cause. When we look, we discover that the social system presents us with an apparent cause that is plausible according to what we have learned from simple systems. But this ap- parent cause is usually a coincident occurrence that, like the trouble symptom itself, is being produced by the feed- back-loop dynamics of a larger system [4].

In our e x p e r i m e n t w e saw h o w looking at the s y m p - toms of t r o u b l e (i.e., s c h e d u l e overruns) for a cause a n d opting for the most a p p a r e n t one, n a m e l y , that s c h e d u l e s w e r e too tight, might l e a d to r e l a x i n g the schedules. H o w e v e r , this t u r n s out to be q u i t e ineffective in c u r i n g t h e s y s t e m ' s p r o b l e m a t i c b e h a v i o r .

A n a t t r a c t i v e f e a t u r e of s y s t e m d y n a m i c s m o d e l s is the a b i l i t y to c o n d u c t s i m u l a t i o n e x p e r i m e n t s in w h i c h w e can isolate the effects of factors w e suspect are c a u s i n g the p r o b l e m a t i c b e h a v i o r . By e x p l o r i n g the b e h a v i o r gen- e r a t e d b y i n d i v i d u a l f e e d b a c k loops a n d b y v a r i o u s com- b i n a t i o n s of loops in a model, t h e m o d e l e r can p r e c i s e l y p i n p o i n t the s t r u c t u r e r e s p o n s i b l e for the b e h a v i o r .

By c o n d u c t i n g s u c h e x p e r i m e n t a t i o n w i t h our model, w e w e r e able to i d e n t i f y the real cause of the persisting s c h e d u l e o v e r r u n p r o b l e m in o u r m o d e l e d software de- v e l o p m e n t project. It t u r n e d out to be a c o n s e q u e n c e of the i n t e r a c t i o n b e t w e e n m a n a g e m e n t ' s h i r i n g / f i r i n g pol- icy a n d the " e l u s i v e " n a t u r e of software errors.

W h e n d e c i d i n g u p o n the n u m b e r of e m p l o y e e s , m a n - a g e m e n t (in the model) takes into a c c o u n t the p e r c e i v e d t i m e r e m a i n i n g for the project. T o w a r d the e n d of the

(7)

REPORTS AND ART~I.ES

project, for example, management would be very reluc- tant to bring in new people, even though the perceived time and effort remaining imply more people are needed. It would just take too much time to acquaint new people with the mechanics of the project, integrate them into the project team, and train them in the necessary techni- cal areas.

While such a policy may sound perfectly reasonable, and may in fact be successfully employed in many areas of managerial endeavour, it does pose certain risks (our model reveals) when applied to the software develop- ment area. As was mentioned in Sec. 3, not all work done in the course of a large software project is errorless. Some fraction of the work will be less than satisfactory and must be redone. The unsatisfactory work is not dis- covered right away, however. For some time it passes unrecognized, until the need for reworking the tasks in- volved shows up. When the unsatisfactory work does get discovered, it usually causes major disruptions. The problems, however, are particularly devastating when this happens towards the end of the project, for example, at system integration testing, when management (under the above hiring/firing policy) is very reluctant to hire new employees. When this happens, management will have almost no other alternative but to extend the pro- ject's scheduled completion date.

There is still, though, an interesting and as yet unan- swered question: Why was the system so "unresponsive" to the "schedule relaxing policy?" The answer is because

of the

compensating property

of complex societal sys-

tems. Changes in most (but certainly not all) parameters in one part of such systems may weaken or strengthen some feedback loop, but the multiloop nature of complex feedback systems will, in most cases, "naturally"

strengthen or weaken other loops to compensate [6]. In our particular software project situation, extending the project's schedule weakens the strength of the schedule pressure in the system, to which the hiring loop (for one) simply compensates by causing the project to start with a smaller workforce. For example, in EXAMPLE2, on the basis of an estimated project duration of 51 months, management starts the project with 32 people. When supplied with the more generous and presumably more accurate estimate of 56 months for EXAMPLE3, manage- ment simply (and rationally) factors that in the decision h~aking process, and then determines that a workforce of 29 people (1626 MM/56 months) is needed.

5. CONCLUSIONS

It is clear from the above discussion that viewing the problem of software project scheduling as simply a prob- lem of generating improved schedules is too limited a view, and one which can in fact lead to a serious long term deterioration in an organization's effectiveness in

managing its software projects. Our own research efforts, as well as those of others, have convinced us that the project management of software development is a very complex undertaking in which a complex network of interrelationships and interactions exists. It is, therefore, essential that software project managers adopt an

inte-

grative

perspective or model of software project dynam-

ics in order to effectively answer the difficult questions they need to raise when assessing their organizations' health, selecting improvement interventions, and imple- menting their choices. Such an integrative model would be useful to alert managers to all the important elements or aspects of a problematic situation, and to help them assess the second- and third-order consequences of some set of actions.

However, such an integrative model will undoubtedly contain a large number of components with a complex network of interrelationships: What would still be needed is an effective means to determine both accu- rately and efficiently the dynamic behavior implied by such component interactions. We feel (and hopefully have demonstrated) that the computer-based simulation techniques of system dynamics can be a powerful tool to do just that.

REFERENCES

1. Aaron, J. D. Estimating resources for large programming systems. Soft-

ware Engineering: Concepts and Techniques. Edited by J. M. Buxton,

P. Naur, and B. Randell. Litton Educational Publishing, Inc., 1976. 2. Abdel-Hamid, T. K. and Madnick, S. E. A model of software project

management dynamics. The Sixth lnt'l Computer Software and Appli- cations Conference (COMPSAC), November 8-12, 1982.

3. Boehm, B. W. Software Engineering Economics, Prentice-Hall, Inc., En- glewood Cliffs, New Jersey, 1981.

4. Forrester, J. W. Counterintuitive behavior of social systems. Technol- ogy Review, January, 1971.

5. Putnam, L. H. Software cost estimation and life-cycle control: Getting the software numbers. IEEE Computer Society, IEEE Catalog No. EHO 165-1, 1980.

6. Richardson, G. P. and Pugh lIl, A. L. Introduction to System Dynamics Modeling with Dynamo. The MIT Press, Cambridge, Massachusetts, 1981.

7. Roberts, E. B.,'Ed. Managerial Applications of System Dynamics. The MIT Press, Cambridge, Massachusetts, 1981.

8. Thayer, R. H., Pyster, A. B., and Wood, R. C. Major issues in software engineering project management. IEEE Trans. on Software Engineer- ing, July, 1981, pp. 333-342.

9. Weil, H. B. Industrial dynamics and management information systems. Managerial Applications of System Dynamics. Edited by E. B. Rob- erts. The MIT Press, Cambridge, Massachusetts, 1981.

CR Categories and Subject Descriptors: D.2.9 [Software Engineering]:

Management--cost elimination; K.6.1 [Management of Computing and

Information Systems]: Project and People Management--management techniques

General Terms: Management

Additional Key Words and Phrases: software project scheduling, com- puter simulation, system dynamics

Received 6/82; revised 9/82; accepted 10/82

Figure

Updating...

References

Updating...

Related subjects :