Early Draft Version 4/99

Software Process Dynamics

Raymond J. Madachy

Barry W. Boehm

IEEE Computer Society Press


This book is designed for software engineering professionals and students who are interested in understanding the dynamics of software development, assessing and optimizing process strategies. The importance of process and project dynamics is hard to refute given the well-known (but too often ignored) combined effects of schedule pressure, experience, work methods such as reviews and quality assurance activities, task underestimation, bureaucratic delays, demotivating events, other socio-technical phenomena and the feedback therein. These complex and interacting process effects are elegantly modeled with system dynamics using continuous quantities interconnected in loops of information feedback and circular causality. Knowledge of the interrelated technical and social factors coupled with simulation tools can provide a means for organizations to improve their processes.

The objectives of this book are to:

- Review the field of software process modeling with system dynamics.
- Describe the systems thinking paradigm for developing increasingly deep understandings of software process structures.
- Support business case development using simulation and show application examples.
- Show basic building blocks and model infrastructures for software development processes.
- Describe the modeling process, including calibration of models to software metrics data.
- Show recent developments on how others have used the principles of system dynamics to analyze and improve their processes.
- Provide sufficient introductory material including exercises and executable models on an enclosed CD-ROM and the Internet. Software practitioners who are brand new to simulation can immediately get their hands dirty and start modeling. Students can learn at their own pace, delving into the models as deeply as time and interest dictate.
- For the experienced software process simulationist, provide more detail of critical implementation issues and future research motivations.

The book is almost entirely new material and synthesizes all previous work in the area. There has been much growth in the field, and this book addresses the need to communicate findings. It summarizes more than 40 publications from researchers and practitioners experienced in modeling actual processes in organizations. It is written to be a self-contained learning experience, and the ultimate reference for modeling practitioners. The sections are structured so that readers can approach the subject from several perspectives, and gain valuable knowledge for further study and practice depending on their needs.

We will provide a constructive understanding of process dynamics. Where appropriate, we will present guidelines for process improvement and general software management strategies. These suggestions represent our compiled experience and research in the field (common threads include risk management and concentrating on people). Our perspective in the book will be the dynamics of software development, and we will attempt to describe best practices from that view. Some of these practices will be illuminated through simulation experiments herein, and some will become foci of further study.

Readers may be involved in software process improvement, project planning and management, software implementation, strategic corporate planning, organizational learning, or simply desire to understand the interrelated factors of software development. They do not need sophisticated math skills, but a passing knowledge of integration concepts will make the introductory material easier. Readers will increase their understanding of the complexities of software development and be able to use system dynamics for modeling and improving processes in their particular organizations. This book may serve as an upper-level or graduate textbook for any of the following courses: Software Engineering, Software Project Management, Software Process Modeling, System Simulation or related subjects.

Book Organization and Highlights

This section provides a sequential outline of topics with selected highlights. Each chapter includes numerous graphics, charts and tables to help illustrate the material. The book is also supplemented with an interactive web site containing the sample models and exercises.

Chapter 1 establishes the context and foundation of the book. It presents an introduction and background including motivational issues and a capsule history of the field. Definition of terms are provided for reference throughout the book and there is a brief discussion on how models can be used to quantitatively evaluate the process before project implementation. The chapter ends with a simple motivational example of modeling Brooks’s Law.

An overview of system dynamics is provided in Chapter 2. Basic simulation principles are first discussed, and then system dynamics theory as a specific simulation methodology. The concepts of systems thinking are introduced, so one can see how system dynamics implements them to leverage learning efforts and improve organizational performance. The underlying mathematical formulation of system dynamics is discussed with its ramifications for software process models.

Chapter 3 describes the modeling process, which is iterative and cyclic. The activities of problem definition, model formulation including calibration, simulation, evaluation, validation, communication to others, and challenging the model for the next iteration are elaborated on. Since simulation is both art and science, guidelines and modeling heuristics are discussed. It is seen that there is much in common with software engineering principles in general such as iteration, abstraction, aggregation, etc., yet there are also aspects of simulation that require somewhat different skills.

This chapter also details the multi-perspective validation of system dynamics models, which is of paramount importance before drawing policy conclusions from simulation experiments. Different modeling tools and environments are overviewed to help modelers in choosing appropriate tools for their different needs (more details and vendor contacts are provided in Appendix A).

Chapter 4 presents the fundamentals of simulation analysis. Statistical methods are used to handle the stochastic inputs and outputs of simulation models. The chapter discusses the principles of probability distributions, sample size, confidence intervals and experimental design applied to continuous system simulation.

Chapter 5 discusses model structures and behavior in more depth than Chapter 2, with a focus on the software process. Included is a detailed description of levels, flows, auxiliaries, infrastructures, and feedback loops. As state variables, level instances include various software work artifacts, defect levels, personnel levels, effort expenditure, schedule date and others. An important contribution of this chapter is the explication of basic flow processes for software development. Together with prototypical feedback loops such as learning, these infrastructures can be used to develop models relevant to any software process. This section also illustrates a major advantage in system dynamics models over other modeling techniques: inherent cost and quality tradeoffs.

Software process applications are discussed in Chapter 6. An overview of applications and research to-date is provided, including history, a list of different implementations, and critiques of the various work. Examples from the field are shown with sample insights. It is seen that applications range from evaluating the process for different work methods and development models, sometimes focusing on specific phases and activities, to metrics benchmarking, post-mortem analysis, evaluation of process improvement investments, personnel training, stimulating dialogues for shared mental models, integration with cost estimation models, knowledge-based assistance and examining management heuristics.

A host of insights derived from models are discussed for both process optimization and project management issues. These include development model tradeoffs, optimal staffing for various activities, the setbacks required for process improvement, diminishing returns of inspections, the internal workings of Brooks's Law, the leverage of experienced staff, schedule compression workings, project estimation processes, reuse, and others related to interdependent process factors.

Common structures for software processes ferreted out of the major models are documented in this chapter. These include example process chains used in the models, which conceptually are instantiations of the generic infrastructures in Chapter 5.

The chapter ends with comparisons of alternative modeling approaches. Discrete approaches that track individual events for software processes are contrasted with continuous modeling, as well as static modeling (typified by most current cost models) versus dynamic modeling.

Chapter 7 shows the thread of simulation modeling with actual model implementations and worked out examples. These examples should be of particular value to system dynamics novices, and more experienced modelers can study them for additional ideas. All the examples are also contained on the accompanying web site. Calibration examples illustrate "rubber hitting the road", as sample effort data and defect profiles are used to calibrate model portions. This demonstrates the linkage to organizational metrics collection and analysis.

The first example is the development of a simple project model. Iterative enhancements for Brooks's Law, inspections and incremental development follow. A proposed generic model is then detailed, that employs virtually all of the building blocks previously described. Additional exercises are provided at the end for readers or students to work out.

This chapter also discusses risk and variance analysis afforded by simulation models. It is stressed here that deterministic point estimates are of limited value, and the prudent practitioner looks at the range of possible values. Monte-Carlo simulation and other examples are shown.

Chapter 8 describes case studies performed at Litton Guidance and Control Systems to investigate managerial process issues at various organizational levels. These include models of resource contention among projects, Brooks's Law and hiring issues, domain learning, product-line reuse processes and a detailed inspection model. Insights provided by the models have supported decision-making at different levels and helped galvanize process improvement efforts.

Chapter 9 provides directions for future work. These include model structures, common models and component reusability, model usability, process model selection, knowledge-based techniques, object orientation, related simulation research and industrial data analysis.

Appendix A identifies additional resources for further information and assistance. These include public domain models, vendor contacts and their simulation packages, instructional videos, World-Wide Web sites and more.

Appendix B presents a maturity model for software process simulation based on the structure of key process areas in the Software Engineering Institute’s Capability Maturity Model. This model is intended to be a set of guidelines for organizations to employ simulation in an effective manner.

The annotated bibliography in Appendix C lists and summarizes over 60 references including books, articles, and web sites. This is a complete set of references for the field including general references for system dynamics. We will continue to update the references on the Internet.

Finally, Appendix D lists the simulation models available with this book on the IEEE web site. Each model is also addressed earlier in the book, either reviewed or used to demonstrate concepts in the book.

We would like to extend our sincere appreciation to all the other people who contributed to this work. The first author initially learned system dynamics for physiological modeling in a graduate biomedical engineering course at UCSD in 1982 under the excellent direction of Drs. Alan Schneider and James Bush. This book would not be complete without the accomplishments of {list of researchers: Dr. Vic Basili for crucial early suggestions, Scott Duncan, Dietmar Pfahl, Dr. David Raffo, Dr. Marc Kellner, Dr. Manny Lehman, Stan Rifkin, Litton personnel including Dr. Denton Tarbet, Frank Harvey, Roy Nakahara, other Litton mgt, reviewers, Cheryl Baltes, Matt Loeb, other IEEE CS personnel, wife}.

Though the field of software process modeling with system dynamics is relatively new, much is happening in conjunction with other process improvement initiatives. The reader is urged to browse the companion web site at http://www.ieee.org/xx/spmsd for updates, and it is hoped that some of the exercises in this book will be used as a basis for further research. Your comments on this book and experiences with modeling actual processes are of great interest to these authors, and your feedback will help in developing the next edition. The author's addresses are

Dr. Raymond J. Madachy
Litton Guidance and Control Systems
5500 Canoga Ave.
Woodland Hills, CA 91376-6698
email: madachyr@littongcs.com


USC Center for Software Engineering
Computer Science Department
University of Southern California
Los Angeles, CA 90089-0781
email: madachy@usc.edu

Dr. Barry W. Boehm
USC Center for Software Engineering
Computer Science Department
University of Southern California
Los Angeles, CA 90089-0781
email: boehm@sunset.usc.edu


Book Organization and Highlights

1 Introduction and Background
1.1 Systems, Processes, Models and Simulation
1.2 Software Process Technology Overview
1.2.1 Process Modeling Modeling Approaches System Dynamics Process Model Characterization
1.2.2 Process Lifecycle Models
1.2.3 Process Improvement
1.3 Systems Thinking and Organizational Learning
1.3.1 System Dynamics vs. Systems Thinking
1.4 Brooks’s Law Example
1.4.1 Brooks's Law Model Behavior
1.5 System Dynamics Challenges for the Software Industry
1.6 Exercises

2 System Dynamics Overview
2.1 Levels
2.1.1 Sources and Sinks
2.2 Rates
2.3 Auxiliaries
2.4 Connectors and Feedback Loops
2.5 Model Notations
2.6 Substructures
2.6.1 Coincident Flows
2.7 Test Functions
2.8 General System Behaviors
2.8.1 Delays
2.8.2 Goal-seeking Negative Feedback First-order Negative Feedback Second-order Negative Feedback
2.8.3 Positive Feedback Growth or Decline
2.8.4 Coupled Feedback Loops
2.8.5 Mathematical Formulation of System Dynamics
2.9 Summary of General Principles
2.10 Exercises

3 The Modeling Process
3.1 Basic steps and guidelines
3.1.1 Problem Definition Defining the Purpose Reference Behavior
3.1.2 Model Conceptualization Causal loop diagrams Identification of System Boundary
3.1.3 Model Formulation Process Elicitation
3.1.4 Simulation Steady-state Conditions
3.1.5 Evaluation Model Validation
3.1.6 Sensitivity Analysis
3.1.7 Communication
3.1.8 Re-assessment and Improvement
3.2 Data Collection
3.3 Modeling Tools
3.3.1 DYNAMO
3.3.2 Ithink and Stella
3.3.3 Vensim
3.3.4 Powersim
3.3.5 Extend
3.3.6 Other
3.3.7 Tool Extensions and New Directions
3.4 Summary of Modeling Heuristics
3.5 Exercises

4 Simulation Analysis
4.1 Analysis of Simulation Input
4.1.1 Goodness-of-Fit Tests
4.2 Analysis of Simulation Output
4.3 Exercises

5 Model Structures and Behavior for Software Processes
5.1 Model Elements
5.1.1 Levels Sources and Sinks
5.1.2 Rates
5.1.3 Auxiliaries
5.1.4 Connectors and Feedback Loops
5.2 Model Infrastructures
5.2.1 Basic Flow Processes for Software Development Software Product Transformations Co-flows Defects Effort Expenditure Defect Detection and Rework Defect Propogation Personnel Pool Learning Curve Cost/Quality Tradeoff
5.2.2 Combined Processes Production
5.2.3 Process Maturity Modeling
5.3 Typical Process Behaviors and Dynamic Effects
5.3.1 Standard Feedback Types Simple Goal Attainment Oscillating exponential growth and decay
5.3.2 S-curves
5.3.3 Hiring Delays
5.3.4 Team Size
5.3.5 Staffing Profiles Rectangular Rayleigh Curve
5.4 Submodels
5.5 Exercises

6 Software Process Applications
6.1 Background and Previous Work
6.1.1 Process Evaluation
6.1.2 Flight Simulators
6.1.3 Integration with cost estimation models
6.1.4 Knowledge-based assistance
6.1.5 Sample Insights
6.1.6 Academic Uses
6.1.7 Tool vendors
6.1.8 Examining heuristics
6.1.9 Miscellaneous Applications
6.2 Common Structures
6.2.1 Example Software Process Chains Software Product Chain Defects Personnel Feedback loops Learning curve
6.3 Comparison of Modeling Approaches
6.3.1 Continuous and Discrete
6.3.2 Static and Dynamic Example of Complementary Paradigms
6.4 Exercises

7 Model Implementations and Examples
7.1 Introductory Example
7.1.1 Model Development Model Parameterization Model Calibration Model Validation
7.2 Steady State Behavior
7.3 Sensitivity Analysis
7.4 Risk Analysis
7.4.1 Monte-Carlo Simulation and Confidence Level Example
7.5 Model Enhancement - Brooks's Law
7.6 Model Enhancement - Inspections
7.6.1 Calibration to Inspection Data
7.7 Model Enhancement - Incremental Development
7.8 Learning
7.9 Motivation Burnout
7.10 Norden/Rayleigh Manpower Distribution
7.11 A Global Feedback Model
7.12 A Reuse Model
7.13 A Proposed Generic Model
7.14 Exercises

8 Litton Case Studies
8.1 Overview
8.2 Implementation
8.4 Inspection Model
8.5 Core Software Reuse Model
8.6 Summary and Conclusions

9 Directions for Future Work
9.1 Update of Future Directions in Software Project Dynamics
9.2 Model Structures
9.3 Software Process Issues
9.4 Common Models and Component Reusability
9.5 Object Orientation
9.6 Usability
9.7 Lifecycle Process Model Selection
9.8 Knowledge-based Assistants
9.9 Related Simulation Research
9.10 Industrial Data Analysis
9.11 Future Projections
9.12 Exercises

Appendix A: Additional Resources
Publications and Conferences
Tool Vendors
Professional Societies

Appendix B: Software Process Modeling Maturity

Appendix C: Annotated System Dynamics Bibliography
General System Dynamics References
Software Process Applications

Appendix D: Available Models



  1. Introduction and Background



    Software development is a dynamic and complex process as there are many interacting factors throughout the lifecycle that impact the final cost, schedule and quality. Unfortunately these effects are rarely accounted for on software projects. Knowledge gleaned from a global perspective that considers these interactions can be represented in executable simulation models that serve as a common understanding of an organization’s processes. Systems thinking, as a way to find and bring to light the structure of the organizational system which influences its dynamic behavior, together with system dynamics as a simulation methodology provide critical skills to manage complex software development. System dynamics was developed 30 years ago by Jay Forrester at MIT to improve organizational structures and processes [Forrester 61], but is just recently being applied in software engineering settings. It provides an integrative framework for capturing the myriad process phenomena and their relationships.

    Use of simulation is increasing in many disparate fields due to constantly improving computer capabilities. Simulations are computationally intensive, so they are much more cost-effective than in the past. The simulation process involves designing a system model and carrying out experiments with it. The purpose of these "what if" experiments is to determine how the real or proposed system performs and to predict the effect of changes to the system as time progresses. Simulation is an efficient communication tool to show how a process works while stimulating creative thinking about how it can be improved. The modeling process itself is beneficial; it is generally acknowledged that much of the reward of modeling is gained in the early stages to gather data, pose questions, brainstorm and understand processes, etc.

    There are many practical benefits to perform simulation in organizations. Besides individual project planning, simulation can help evaluate long-run investment and technology strategies. It can support organizational learning by making models explicit in a group setting, where all participants can contribute and buy-in to the model. Such collaboration can go a long way to effect teambuilding. Simulation can also be used in individual training, since participants can interact with executing models in real-time to see the effects of their decisions.

    Another significant motivation is that simulation can help reduce the risk of software development. Particularly when used and cross-checked with other complementary perspectives that embody different assumptions, system dynamics modeling can minimize the uncertainties of development. Previously unforeseen "gotchas" will be brought to the forefront and mitigated through careful planning.

    System dynamics modeling can provide insights by investigating virtually any aspect of the software process at a macro or micro level. For example, companies who are looking for ways to accelerate their processes can assess various Rapid Application Development (RAD) techniques through simulation. Organizations can likewise focus on other specific aspects such as development cost, product quality, or the myriad tradeoffs between cost, schedule and quality. Planners and managers can assess the consequences of alternative strategies such as reuse, re-engineering, prototyping, incremental development, evolutionary development, or other process options before actual implementation.

    This book is about modeling software processes using system dynamics. The field has sometimes been called software project dynamics, which is the name of the first book on the subject [Abdel-Hamid-Madnick 91]. However, that term is limiting in the sense that system dynamics can be applied to situations outside of project boundaries such as continuous product line development, organizational reuse processes contributing to many projects, or other macro processes. Simulation can be used for personnel training, so process flight simulation is sometimes used to invoke the analogy of pilots honing their skills in simulators to reduce risk, with the implicit lesson that software managers should do the same. The methods may on occasion be referred to as dynamic process simulation or simply dynamic simulation.

    Alternative titles for this book could be The Learning Software Organization or Software Process Systems Thinking depending on the camp de jour. Organizational learning in the context of a software process involves translating the common "mental model" of the process into a working simulation model that serves as a springboard for increased learning and improvement. The title Software Process Modeling with System Dynamics is meant to capture the traditional bare essence of the subject - the application of system dynamics modeling to software process and project phenomena (a project is considered an execution of a process).

    There are other excellent references on system dynamics modeling that one could use to learn from, but why should a harried software engineer studying the software process spend so much time with examples outside of his/her field? This book uses examples solely from the software process domain to minimize modeling skill transfer time. Organizational learning and systems thinking are also well-documented elsewhere (see the popular books by Peter Senge and collaborators [Senge 90], [Senge et al. 94], and others listed in Appendix C), so proselytizing will be kept to a minimum while we attempt to describe how the rubber meets the road.

    1. Systems, Processes, Models and Simulation



      Important terminology for the field is defined in this section. A systems orientation is crucial to understanding the concepts herein, so system will first be defined generally as a subset of reality that is a focus of analysis. Technically, systems contain multiple components that interact with each other and perform some function together that can't be done by individual components. In simulation literature, a system is typically defined as "a collection of entities, e.g., people or machines, that act and interact together toward the accomplishment of some logical end" [Law-Kelton 91]. Forrester's system definition is very close: "a grouping of parts that operate together for a common purpose" [Forrestor 68].

      Systems exist on many levels; one person's system is another person's subsystem. Since systems are influenced by other systems, no system is isolated from external factors. How to define system boundaries for meaningful analysis is discussed later in this book.

      Systems are classified as "open" if the outputs have no influence on the inputs; open systems are not aware of their past performance. A "closed" system is also called a feedback system, whereby it is influenced by its own behavior through a loop that uses past actions to control future action. The distinction between open and closed systems is particularly important in the context of system dynamics.

      A software process is a set of activities, methods, practices and transformations used by people to develop software. This is a general definition as defined and commonly accepted in the Software Engineering Institute’s Capability Maturity Model (SEI CMM) [xx]. The software process is the system under study in the context of this book.

      A system can be characterized by 1) parameters that are independent measures that configure system inputs and structure, and 2) variables which depend on parameters and other variables. Parameters in human systems are directly controllable. The collection of variables necessary to describe a system at any point in time is called the state of the system. Examples of state variables for a software process are the number of personnel executing the process; the amount of software designed, coded and tested; the current number of defects, etc.

      Real world systems can be classified as static or dynamic depending on whether the state variables change over time. The state of a static system doesn't change over time, while the state of a dynamic system does. Dynamic systems can be further classified as continuous, discrete or combined based on how their variables change over time. Variables change continuously over time in a continuous system, while they change instantaneously at separated time points in a discrete system. A lake is an example of a continuous system since its depth changes continuously as a function of inflows and outflows, while a computer store would be considered discrete since the number of customers changes in discrete quantities. A software process arguably has continuous quantities (e.g. personnel experience and motivation) and discrete ones (size, defects, etc.)

      Whether a system is represented as continuous or discrete depends on the analyst's purpose. Some discrete systems can be assumed to be continuous for easy representation. Many would consider a software process to be a system with discrete entities since it can be described by the number of people working, number of units/lines/objects produced, defects originated, etc. However, much difficulty will be avoided if each entity does not need to be traced individually. Hence, the approach in this book and system dynamics in general is to treat the "flow" of the software process as continuous.

      A system must be represented in some form in order to analyze it and communicate about it. A model in the broadest sense is a representation of reality, ranging from physical mockups to graphical descriptions to abstract symbolic models. A model in the context of this book is a logical description of how a process (system) behaves. The models are abstractions of real or conceptual systems used as surrogates for low cost experimentation and study.

      All classes of systems may be represented by any of the model types. A discrete model is not always used to represent a discrete system and vice-versa. The choice of model depends on the specific objectives of a study. Models of the software process are either static where time plays no role or dynamic where a system evolves over time. The dynamic process models described this book are classified as symbolic, or mathematical ones.

      Dynamic process models can be discrete, continuous, or a combination. The essential difference is how the simulation time is advanced. Continuous systems modeling such as system dynamics always advances a constant delta time. Since variables may change within any time interval in a continuous system, the delta increment is very small and time-dependent variables are recomputed at the end of each time increment. Discrete modeling normally is event-based. State changes occur in discrete systems at aperiodic times depending on the event nature, at the beginning and end of event activities. The simulation time is advanced from one event to the next in a discrete manner.

      Models may be deterministic with no probabilistic components or stochastic ones with randomness in the components. Few, if any, software processes are wholly deterministic. Stochastic models produce output that is random and must be handled as such with independent runs. Each output constitutes an estimate of the model characteristics.

      Simulation is the numerical evaluation of a mathematical model describing a system of interest. Many systems are too complex for closed-form analytical solutions, hence simulation is used to exercise models with given inputs to see how the system performs. Simulation can be used to explain system behavior, improve existing systems or to design new systems too complex to be analyzed by spreadsheets or flowcharts. Finally, system dynamics is a simulation methodology for modeling continuous systems. Quantities are expressed as levels, rates and information links representing feedback loops. System dynamics is described in much more detail later.

        1. Process Model Characterization

        Software process modeling can be used in a wide variety of situations as demonstrated in Table 1.2.1. The matrix structure was originated by Kellner [xx] as a framework for characterizing modeling problems and relevant modeling work in terms of scope (what is covered) and purpose (why). System dynamics can be used to address virtually every category, and the table contains some example applications referenced in this book. More details on the specific categorizations can be found in [Kellner-Madachy-Raffo 1998].

        The matrix can also be used to place the result variables of a simulation study in the proper categorization cell. A result variable is a primary output of a process simulation. Typical result variables for software process simulation include effort, cycle time, defect levels, staffing requirements over time, return on investment (ROI), throughput, productivity, and queue lengths. Many of these variables may be reported for the entire simulation or any portion thereof. Some result variables are best looked at as continuous functions (e.g., staffing requirements), while others only make sense at the end of the process being simulated (e.g., ROI).

        As with choosing a modeling approach, the questions and issues being addressed largely determine the choice of result variables. For example, technology adoption questions often suggest an economic measure such as ROI; operational management issues often focus on the traditional project management concerns of effort, cycle time, and defect level. It is common to produce multiple result variables from a single simulation model.

        Table 1: Process Modeling Characterization Matrix and Examples

        Scope /
        Portion of lifecycle Development project Multiple, concurrent projects Long-term product evolution Long-term organization
        Strategic management     product-line reuse strategy   projected headcount, business growth
        Planning stage-based cost/schedule estimation project cost/schedule/quality estimation reuse costs   projected workload 
        Control and operational management stage tracking earned value tracking product-line change control    
        Process improvement and technology adoption RAD process tradeoffs 

        peer review optimization 

        phase defect levels

        peer review effects on project

        RAD process tradeoffs

        inter-project reuse processes product-line reuse strategies  

        overtime effects

        process concurrence rework levels resource sharing tradeoffs

        cycle times

        maintenance size and effort trends organizational behavior 
        Training and learning   managerial metrics training      

        1. Brooks’s Law Example

      A small motivational example of modeling Brooks’s Law will be described. In the early software engineering classic The Mythical Man-Month, Fred Brooks stated:

      Adding manpower to a late software project makes it later [Brooks 75].

      His explanation for the law was the additional linear overhead needed for training new people and the nonlinear communication overhead (a function of the square of the number of people). These effects have been widely accepted and observed by others. The simple model in Figure 1.4.1 describes the situation, and will be used to test the law. This model is described below assuming no background in systems dynamics. Detail on model notations and equations are discussed in the next chapter.

      The model is conceived around the following basic assumptions:

      It is built on two connected flow chains representing software development and personnel. The software development chain assumes a level of requirements that need to be implemented (shown as the upper left box in Figure 1.4.1). The requirements are transformed into developed software at the software development rate (rates are shown as the circular pipe valve symbols). The level of developed software represents progress made on implementing the requirements. Project completion is when developed software equals the initial requirements. Software size is measured in function points, and the development rate is in function points/person-day.

      The software development rate is determined by the levels of personnel in the system: new project personnel who come onto the project at the personnel allocation rate, and experienced personnel who have been assimilated (trained) into the project at the assimilation rate. Further variables in the system are shown as circles in the diagram. Documentation commentary for the model is shown underneath each equation in Figure 1.4.2. Note that the time-based level equations are automatically generated by visually laying out the levels and rates.

      Figure .1: Simple Brooks’s Law Model

      Figure .2: Simple Brooks’s Law Model Equations

      1. Brooks's Law Model Behavior

In order to start out simple and understand the primary influences in the model, it is a high-level depiction of a level-of-effort project. There are no explicit policy provisions for assessing whether the project is already late (subsequent sections will cover status tracking), and the model will be exercised by adding more people via the personnel allocation rate. This will allow for tracking the software development rate over time and assessing the final completion time to develop the requirements under different hiring conditions. All parameters are set to reasonable approximations as described below and in the equation commentary. The overall model represents a nominal case, and would require calibration to specific project environments.

As time progresses, the number of requirements decreases since it represents requirements still left to implement. These requirements are processed over time at the software development rate and become developed software, so requirements decline as developed software rises. The software development rate is constrained by several factors: the nominal productivity of a person, the communication overhead %, and the number of personnel. The number of personnel equals the new project personnel plus the experienced personnel minus the amount of experienced personnel needed for training the new people. The communication overhead % is expressed as a nonlinear function of the total number of personnel that need to communicate (.06*n2), which is the same formulation described in [Abdel-Hamid-Madnick 91]. The experienced personnel needed for training is the training overhead percentage as a fraction of a full-time equivalent experienced personnel. The default of .25 indicates one quarter of an experienced person is needed to train a new person until they are fully assimilated.

The bottom structure for the personnel chain models the assimilation of new project personnel at an average rate of 20 days. In essence, a new person is trained by one fourth of an experienced person for an average of 20 days until they become experienced in the project.

The nominal productivity is set to 1, with the productivities of new and experienced personnel set to .8*nominal productivity and 1.2*nominal productivity respectively as a first-order approximation.

Steady state conditions are present in the model when no additional people are added. These conditions are necessary to validate a model before adding perturbations (this validation is shown in Section 7.3). The default behavior of the model shows a final completion time of 274 days to develop 500 function points with a constant staff of 20 experienced personnel.

Figure .1: Sensitivity of Software Development Rate to Varying Personnel Allocation Pulses
(1: no extra hiring, 2: add 5 people on 100th day, 3: add 10 people on 100th day)

Figure 1.4.2 now shows some interesting effects. With an extra staff of five people (curve #2), the development rate nosedives, then recovers after a few weeks to slightly overtake the default rate and actually finishes sooner at 271 days. However, when 10 people are added the overall project suffers (curve #3). The initial productivity loss takes longer to stabilize, the final productivity is lower with the larger staff and the schedule time elongates to 296 days. The plunge and smooth recovery seen on both are the training effect. The extra staff gains in the first case are greater than the communication losses, but going from 20 to 30 people in the second case entails a larger communication overhead compared to the potential productivity gain of having more people.

The model has now shown a rudimentary example of Brooks’s Law, and further shows that the law holds only under certain conditions (Brooks did not mean to imply that the law held in all situations). There is a threshold of new people that can be added until the schedule suffers. Note that only schedule time was analyzed here, and that effort increased in both cases of adding people. The effort would also be taken into account for a true project decision (though schedule may often be the primary performance index regardless of the cost).

The model uses simplified assumptions and boundaries, and can be refined in several ways. The parameters for communication overhead, training overhead, assimilation rate and other formulations of personnel allocation are also important for a thorough sensitivity analysis. A myriad of different combinations can and should still be tested. This model is analyzed in more detail in Section xx to illustrate the principles of sensitivity analysis, and other sections show enhancements to it.

This exercise has demonstrated that a small-scale and simple model can help shed light on process phenomena. Even though the model contains fairly simple formulations, the dynamic time trends would be very time consuming for a person to manually calculate and all but impossible to mentally figure. Based on the insight provided, we may now clarify Brooks’s Law. Adding manpower to a late software project makes it later if too much is added too late. That is when the additional overhead is greater than productivity gains due to the extra staff.

This model is a microcosm of the system dynamics experience. Simplifying assumptions are made that coincide with the simple purpose of this model. The reader may need some faith at first since rationale for the full model formulation was not yet given. Many aspects of the model can be challenged further such as the following:

All of these issues will be addressed in subsequent sections that elaborate this Brooks's Law model and others.

Appendix D: Available Models

The following models are provided to registered book owners on the IEEE web site. The Ithink run-time model player can also be loaded to run them. Many more models implemented by different tools can be obtained from links on the web site and other sources listed in Appendix A. Table D-1 lists elaborate models for industrial and/or academic use that are reviewed in section xx, while Table D-2 lists the smaller demonstration models used as examples throughout the book.

Table D-1: Elaborate Models

Model Filename Author(s) / Source Major focus Notes
SEASauth.itm Steven Burke organizational process improvement See section xx
inspect.itm Ray Madachy dynamic project effects of incorporating inspections
abdel_hamid.itm Margaret Johnson an Ithink version of Abdel-Hamid's software project dynamics model
John Tvedt
project.itm Doug Sycamore three increment project model
Iona Rus

Table D-2: Demonstration Models

Model Filename Author(s) / Source Major focus Notes
rayleigh.itm Rayleigh curve staffing rate
rayleigh interactive.itm interactive user control of requirements influx to gauge impact on Rayleigh curve staffing rate
rayleigh array.itm array structure to model incremental development
rayleigh COCOMO.itm Rayleigh curve calibrated to COCOMO®
incremental.itm increment phasing example
resource allocation.itm modified from High Performance Systems example resource allocation infrastructure tasks with the greatest backlog receive proportionally greater resources ("squeaky wheel gets the grease")
human resources.itm
production.itm simple software production structure  contains single stock for personnel pool
global feedback.itm illustration of global feedback to software process (simplified version of Wernick-Lehman 98 model)
dynamic behaviors.itm example structures that produce typical dynamic behaviors
brooks.itm Brooks's Law example
learning curves.itm demonstration and comparison of learning curve formulations
reuse.itm demonstrates reuse economy
delay tests.itm demonstrates different time delay structures to represent software development
example1.itm example project that combines software product development (see production.itm) with personnel chain
example1 reuse.itm adds software reuse to product development and personnel pool in example1.itm
example1 incremental.itm adds incremental development structure to example1.itm
project contention.itm models the contention of senior developers between projects in terms of project transference losses 
system development.itm modified from High Performance Systems detailed model of combined hardware/software development  also includes competition and market factors
product.itm modified from High Performance Systems product production infrastructure includes target inventory and experience effects
perceived quality.itm modified from High Performance Systems models perceived quality Includes delay for adjusting perceptions
single tier personnel chain.itm modified from High Performance Systems single tier hiring and quitting infrastructure Includes target growth percentage and replacing for attritions
interact.itm modified from High Performance Systems detailed organizational model showing interactions between human resources, finance, product quality and clients
two tier personnel chain.itm modified from High Performance Systems two tier hiring and quitting infrastructure
rookie.itm modified from High Performance Systems simple rookie and pro personnel chain
wrkchain.itm modified from High Performance Systems work flow main chain infrastructure whereby tasks undergo inspections includes resources applied
hrprod.itm modified from High Performance Systems human resources productivity infrastructure includes levels for motivation, knowledge and experience
hrchain.itm modified from High Performance Systems human resources main chain infrastructure includes 3 levels of personnel experience, promotion delays, and quitting fractions