University of Southern California
Center for Systems and Software Engineering
(Systems and) Software Process Dynamics
Ray Madachy
USC Center for Systems and Software Engineering
madachy@usc.edu
Annual Research Review
March 18, 2008
3/18/08
©USC-CSSE
1
University of Southern California
Center for Systems and Software Engineering
Dealing with Systems and Software
Engineering Complexities
• The evaluation of process strategies for the
architecting and engineering of complex systems
involves many interrelated factors.
• Effective systems and software engineering requires a
balanced view of technology, business or mission
goals, and people.
• System dynamics is a rich and integrative simulation
framework used to quantify the complex interactions
and the strategy tradeoffs between cost, schedule,
quality and risk.
Everything is connected to everything
Anonymous
3/18/08
©USC-CSSE
2
University of Southern California
Center for Systems and Software Engineering
Systems and Software Engineering Challenges
• What to build? Why? How well?
– Stakeholder needs balancing, business case
• Who to build it? Where?
– Staffing, organizing, outsourcing
• How to build? When; in what order?
– Construction processes, methods, tools, components, increments
• How to adapt to change?
– In user needs, technology, marketplace
• How much is enough?
– Functionality, quality, specifying, prototyping, test
See relevant application models in Software Process Dynamics
chapters 4-6
3/18/08
©USC-CSSE
3
University of Southern California
Center for Systems and Software Engineering
The Software Process Dynamics Field
• 1991 Software Project Dynamics book, Abdel-Hamid and
Madnick, MIT
– A single model
– Useful tradeoff insights, some mischaracterizations
• 1990’s Growing number of applications and commercial
modeling tools
• 1998 Annual ProSim Workshop start
• 1999 Refereed journal articles start
• 2000’s Many applications, few modeling principles
• 2008 Software Process Dynamics book, Madachy, USC
– Modeling techniques and principles, model building blocks, entire models,
review of extensive model applications
3/18/08
©USC-CSSE
4
University of Southern California
Center for Systems and Software Engineering
Software Process Dynamics
Table of Contents
Part 1 - Fundamentals
Chapter 1 – Introduction and Background
Chapter 2 – The Modeling Process with System Dynamics
Chapter 3 – Model Structures and Behavior for Software Processes
Part 2 – Applications and Future Directions
Chapter 4 – People Applications
Chapter 5 – Process and Product Applications
Chapter 6 – Project and Organization Applications
Chapter 7 – Current and Future Directions
Appendices – Statistics of Simulation, Annotated Bibliography, Provided Models
3/18/08
©USC-CSSE
5
University of Southern California
Center for Systems and Software Engineering
System Dynamics Principles
• Major concepts
– Defining problems dynamically, in terms of graphs over time
– Striving for an endogenous, behavioral view of the significant dynamics
of a system
– Thinking of all real systems concepts as continuous quantities
interconnected in information feedback loops and circular causality
– Identifying independent levels in the system and their inflow and outflow
rates
– Formulating a model capable of reproducing the dynamic problem of
concern by itself
– Deriving understandings and applicable policy insights from the resulting
model
– Implementing changes resulting from model-based understandings and
insights.
• The continuous view
– Individual events are not tracked
– Entities are treated as aggregate quantities that flow through a system
3/18/08
©USC-CSSE
6
University of Southern California
Center for Systems and Software Engineering
System Dynamics Strengths / Weaknesses
• Strengths
– Provides a global system perspective and the ability to analyze combined strategies
– Enables analysis of integrated process factors and feedback loops (e.g. holistic
enterprise models, positive and negative feedback, process delays, process
concurrence)
– Finding the right process balance (e. g., quality assurance levels, staffing levels)
– Adapting to change; strategic long-term policy analysis
– Can model inherent tradeoffs between schedule, cost and quality
– Attractive for schedule analysis accounting for critical path flows, task
interdependencies and bottlenecks not available with static models or PERT/CPM
methods
• Weaknesses
– Assumption of homogeneity of entities; cannot attach attributes to individual
entities
– Sequential activities difficult to represent
– Queuing and other discrete statistics not captured
3/18/08
©USC-CSSE
7
University of Southern California
Center for Systems and Software Engineering
System Dynamics Notation
• System represented by x’(t)= f(x,p).
• x: vector of levels (state variables), p: set of parameters
• Legend:
level
source/sink rate
information link
auxiliary variable
defects
• Example system:
defect generation
rate
undetected defects
defect escape
rate
defect detection rate
defect detection
efficiency
detected defects
3/18/08
©USC-CSSE
8
University of Southern California
Center for Systems and Software Engineering
Model Elements
Element
level
rate
level
information link
Description
Process Instances
An accumulation over time, also
called a stock or state variable. A
storage device for material, energy,
information.
Flows; the “actions” in a system that
often represent policies. They exist
with and effect the changes in levels.
source/
rate
sink
iary variable
information link
level
source/
auxiliary variable
rate
sink
Represent infinite supplies or
repositories, indicating real-world
accumulations outside boundary of
the system being modeled
information link
3/18/08
©USC-CSSE

work artifacts (requirements, tasks,
lines of code, documentation pages)
 defect levels
 personnel levels
 effort expenditure
 revenue
 software productivity rate
 defect generation rate
 personnel hiring and de-allocation
 learning rate
 burn rate
 source of requirements
 software delivered to customers
 employee hiring sources and attrition
sinks
9
University of Southern California
Center for Systems and Software Engineering
level
Model Elements (continued)
source/
rate
sink
Element
Description
information link
level
auxiliary variable
/
Process Instances
Converters of input to output that
elaborate detail of stock and flow
structure. They often represent
“score-keeping” variables.
Information linkages.
rate
 quantitative goals or planned values
 constants like average delay times
 percent of job completion
 defect density
 progress and status information for
decision making
 linking process parameters to other
information link
vaariables
uxiliary variable
3/18/08
©USC-CSSE
10
University of Southern California
Center for Systems and Software Engineering
Brooks’s Law Model
•
•
“Adding manpower to a late software
project makes it later” [Brooks 75].
A simple model based on the
following assumptions:
– New personnel require training by
experienced personnel to come up
to speed
– More people on a project entail
more communication overhead
– Experienced personnel are more
productive then new personnel, on
average.
3/18/08
©USC-CSSE
11
University of Southern California
Center for Systems and Software Engineering
Brooks’s Law Model Output
Function points/day
Days
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)
3/18/08
©USC-CSSE
12
University of Southern California
Center for Systems and Software Engineering
Brooks’s Law Dynamics
3/18/08
©USC-CSSE
13
University of Southern California
Center for Systems and Software Engineering
References
• Abdel-Hamid T, Madnick S, Software Project
Dynamics, Englewood Cliffs, NJ, Prentice-Hall,
1991
• Madachy R, Software Process Dynamics,
Wiley/IEEE Press, Hoboken NJ, 2008
USC Web Sites
• http://csse.usc.edu/softwareprocessdynamics
• http://rcf.usc.edu/~madachy/spd
3/18/08
©USC-CSSE
14