Software Process Dynamics

1
Software Process Dynamics

• USC CSCI 510 Software Management and Economics
• November 18, 2009
• Dr. Raymond Madachy
• rjmadach_at_nps.edu

2
Agenda

• Introduction
• Example applications
• Inspection model
• Spiral hybrid process model for
  Software-Intensive System of Systems (SISOS)
• Value-based product model with DoD analogs
• Backup slides
• Introduction, background and examples

3
Research Background

• 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, mission
  or business 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.

4
Systems and Software Engineering Challenges

• What to build? Why? How well?
• Stakeholder needs balancing, mission/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

5
The Software Process Dynamics Field

• 1991 Software Project Dynamics book,
  Abdel-Hamid and Madnick, MIT
• A single model
• 1990s Growing number of applications and
  commercial modeling tools
• 1998 Annual ProSim Workshop start
• 1999 Refereed journal articles start
• 2000s Many applications, few modeling
  principles, challenges of SISOS scalability and
  adaptability
• 2008 Software Process Dynamics book, Madachy,
  USC
• Modeling techniques and principles, model
  building blocks, entire models, review of
  extensive model applications

6
Software Process DynamicsTable of Contents

• Part 1 - Fundamentals
• Chapter 1 Introduction and Background
• Chapter 2 The Modeling Process with System
  Dynamics
• Chapter 3 Model Structures and Behaviors 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 and References
• Appendix A- Introduction to Statistics of
  Simulation
• Appendix B- Annotated Bibliography
• Appendix C- Provided Models

7
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

8
System Dynamics Notation

• System represented by x(t) f(x,p).
• x vector of levels (state variables), p set of
  parameters
• Legend
• Example system

9
Model Elements
10
Model Elements (continued)
11
Agenda

• Introduction
• Example applications
• Inspection model
• Spiral hybrid process model for
  Software-Intensive System of Systems (SISOS)
• Value-based product model with DoD analogs
• Backup slides
• Introduction, background and examples

12
Inspection Model Example

• Research problem addressed
• What are the dynamic effects to the process of
  performing inspections?
• Model used to evaluate process quantitatively
• Demonstrates effects of inspection practices on
  cost, schedule and quality throughout lifecycle
• Can experiment with changed processes before
  committing project resources
• Benchmark process improvement
• Support project planning and management
• Model parameters calibrated to Litton and JPL
  data
• Error generation rates, inspection effort,
  efficiency, productivity, others
• Model validated against industrial data

13
System Diagram
14
System Diagram (continued)
15
Effects of Inspections

• Qualitatively matches generalized effort curves
  for both cases from Michael Fagan, Advances in
  software inspections, IEEE Transactions on
  Software Engineering, July 1986

16
Inspection Policy Tradeoff Analysis

• Varying error generation rates shows diminishing
  returns from inspections

17
Derivation of Phase Specific Cost Driver
18
Agenda

• Introduction
• Example applications
• Inspection model
• Spiral hybrid process model for
  Software-Intensive System of Systems (SISOS)
• Value-based product model with DoD analogs
• Backup slides
• Introduction, background and examples

19
Spiral Hybrid Process Introduction

• The spiral lifecycle is being extended to address
  new challenges for Software-Intensive Systems of
  Systems (SISOS), such as coping with rapid change
  while simultaneously assuring high dependability
• A hybrid plan-driven and agile process has been
  outlined to address these conflicting challenges
  with the need to rapidly field incremental
  capabilities
• A system-of-systems (SOS) integrates multiple
  independently-developed systems and is very
  large, dynamically evolving, unprecedented, with
  emergent requirements and behaviors
• However, traditional static approaches cannot
  capture dynamic feedback loops and interacting
  phenomena that cause real-world complexity (e.g.
  hybrid processes, project volatility, increment
  overlap and resource contention, schedule
  pressure, slippages, communication overhead,
  slack, etc.)
• A system dynamics model is being developed to
  assess the incremental hybrid process and support
  project decision-making
• Both the hybrid process and simulation model are
  being evolved on a very large scale incremental
  project for a SISOS (U.S. Army Future Combat
  Systems)

20
Future Combat Systems (FCS) Network
21
Scalable Spiral Model Increment Activities

• Organize development into plan-driven increments
  with stable specs
• Agile team watches for and assesses changes, then
  negotiates changes so next increment hits the
  ground running
• Try to prevent usage feedback from destabilizing
  current increment
• Three team cycle plays out from one increment to
  the next

22
Spiral Hybrid Model Features

• Estimates cost and schedule for multiple
  increments of a hybrid process that uses three
  specialized teams (agile re-baseliners,
  developers, VVers) per the scalable spiral
  model
• Considers changes due to external volatility and
  feedback from user-driven change requests
• Deferral policies and team sizes can be
  experimented with
• Includes tradeoffs between cost and the timing of
  changes within and across increments, length of
  deferral delays, and others

23
Model Input Control Panel
24
Model Overview

• Built around a cyclic flow chain for capabilities
• Arrayed for multiple increments
• Each team is represented with a level and
  corresponding staff allocation rate
• Changes arrive a-periodically via the volatility
  trends time function and flow into the level for
  capability changes
• Changes are processed by the agile team and
  allocated to increments per the deferral policies
• Constant or variable staffing for the agile team
• For each increment the required capabilities are
  developed into developed capabilities and then
  VVed into V Ved capabilities
• Productivities and team sizes for development and
  VV calculated with a Dynamic COCOMO variant and
  continuously updated for scope changes
• Flow rates between capability changes and V
  Ved capabilities are bi-directional for
  capability kickbacks sent back up the chain
• User-driven changes from the field are identified
  as field issues that flow back into the
  capability changes

25
Volatility Cost Functions

• The volatility effort multiplier for construction
  effort and schedule is an aggregate multiplier
  for volatility from different sources (e.g. COTS,
  mission, etc.) relative to the original baseline
  for increment
• The lifecycle timing effort multiplier models
  increased development cost the later a change
  comes in midstream during an increment

26
Sample Response to Volatility

• An unanticipated change occurs at month 8 shown
  as a volatility trend 1 pulse
• It flows into capability changes 1 which
  declines to zero as the agile team processes the
  change
• The change is non-deferrable for increment 1 so
  total capabilities 1 increases
• Development team staff size dynamically responds
  to the increased scope

27
Sample Test Results

• Test case for two increments of 15 baseline
  capabilities each
• A non-deferrable change comes at month 8 (per
  previous slide)
• The agile team size is varied from 2 to 10 people
• Increment 1 mission value also lost for agile
  team sizes of 2 and 4

28
Sample Test Results (cont.)
29
Spiral Hybrid Model Conclusions and Future Work

• System dynamics is a convenient modeling
  framework to deal with the complexities of a
  SISOS
• A hybrid process appears attractive to handle
  SISOS dynamic evolution, emergent requirements
  and behaviors
• Initial results indicate that having an agile
  team can help decrease overall cost and schedule
• Model can help find the optimum balance
• Will obtain more empirical data to calibrate and
  parameterize model including volatility and
  change trends, change analysis effort, effort
  multipliers and field issue rates
• Model improvements
• Additional staffing options
• Rayleigh curve staffing profiles
• Constraints on development and VV staffing
  levels
• More flexible change deferral options across
  increments
• Increment volatility balancing policies
• Provisions to account for (timed)
  business/mission value of capabilities
• Additional model experimentation
• Include capabilities flowing back from developers
  and VVers
• Vary deferral policies and volatility patterns
  across increments
• Compare different agile team staffing policies
• Continue applying the model on a current SISOS
  and seek other potential pilots

30
References

• Abdel-Hamid T, Madnick S, Software Project
  Dynamics, Englewood Cliffs, NJ, Prentice-Hall,
  1991
• Boehm B, Huang L, Jain A. Madachy R, The ROI of
  Software Dependability The iDAVE Model, IEEE
  Software Special Issue on Return on Investment,
  May/June 2004
• Boehm B, Software Engineering Economics.
  Englewood Cliffs, NJ, Prentice-Hall, 1981
• Boehm B and Huang L, Value-Based Software
  Engineering A Case Study, IEEE Computer, March
  2003
• Boehm B., Abts C., Brown A.W., Chulani S., Clark
  B., Horowitz E., Madachy R., Reifer D., Steece
  B., Software Cost Estimation with COCOMO II,
  Prentice-Hall, 2000
• Boehm B., Turner R., Balancing Agility and
  Discipline, Addison Wesley, 2003
• Boehm B., Brown A.W., Basili V., Turner R.,
  Spiral Acquisition of Software-Intensive Systems
  of Systems, CrossTalk. May 2004
• Boehm B., Some Future Trends and Implications
  for Systems and Software Engineering Processes,
  USC-CSE-TR-2005-507, 2005
• Brooks F, The Mythical Man-Month, Reading, MA,
  Addison-Wesley, 197
• Chulani S, Boehm B, Modeling Software Defect
  Introduction and Removal COQUALMO (COnstructive
  QUALity MOdel), USC-CSE Technical Report 99-510,
  1999
• Forrester JW, Industrial Dynamics. Cambridge,
  MA MIT Press, 1961
• Kellner M, Madachy R, Raffo D, Software Process
  Simulation Modeling Why? What? How?, Journal of
  Systems and Software, Spring 1999

31
References (cont.)

• Madachy R, A software project dynamics model for
  process cost, schedule and risk assessment, Ph.D.
  dissertation, Department of Industrial and
  Systems Engineering, USC, December 1994
• Madachy R, System Dynamics and COCOMO
  Complementary Modeling Paradigms, Proceedings of
  the Tenth International Forum on COCOMO and
  Software Cost Modeling, SEI, Pittsburgh, PA, 1995
  
• Madachy R, System Dynamics Modeling of an
  Inspection-Based Process, Proceedings of the
  Eighteenth International Conference on Software
  Engineering, IEEE Computer Society Press, Berlin,
  Germany, March 1996
• Madachy R, Tarbet D, Case Studies in Software
  Process Modeling with System Dynamics, Software
  Process Improvement and Practice, Spring 2000
• Madachy R, Simulation in Software Engineering,
  Encyclopedia of Software Engineering, Second
  Edition, Wiley and Sons, Inc., New York, NY, 2001
  
• Madachy R, Integrating Business Value and
  Software Process Modeling, Proceedings of
  SPW/ProSim 2005, Springer-Verlag, May 2005
• Madachy R, Boehm B, Lane J, Spiral Lifecycle
  Increment Modeling for New Hybrid Processes,
  Journal of Systems and Software, 2007 (to be
  published)
• Madachy R., Software Process Dynamics, Wiley-IEEE
  Computer Society, 2008
• Reifer D., Making the Software Business Case,
  Addison Wesley, 2002
• Richardson GP, Pugh A, Introduction to System
  Dynamics Modeling with DYNAMO, MIT Press,
  Cambridge, MA, 1981
• USC Web Sites
• http//rcf.usc.edu/madachy/spd
• http//csse.usc.edu/softwareprocessdynamics
• http//sunset.usc.edu/classes/cs599_99

32
Agenda

• Introduction
• Example applications
• Inspection model
• Spiral hybrid process model for
  Software-Intensive System of Systems (SISOS)
• Value-based product model with DoD analogs
• Backup slides
• Introduction, background and examples

33
Value-Based Model Background

• Purpose Support software business
  decision-making by experimenting with product
  strategies and development practices to assess
  real earned value
• Description System dynamics model relates the
  interactions between product specifications and
  investments, software processes including quality
  practices, market share, license retention,
  pricing and revenue generation for a commercial
  software enterprise

34
Model Features

• A Value-Based Software Engineering (VBSE) model
  covering the following VBSE elements
• Stakeholders value proposition elicitation and
  reconciliation
• Business case analysis
• Value-based monitoring and control
• Integrated modeling of business value, software
  products and processes to help make difficult
  tradeoffs between perspectives
• Value-based production functions used to relate
  different attributes
• Addresses the planning and control aspect of VBSE
  to manage the value delivered to stakeholders
• Experiment with different strategies and track
  financial measures over time
• Allows easy investigation of different strategy
  combinations
• Can be used dynamically before or during a
  project
• User inputs and model factors can vary over the
  project duration as opposed to a static model
• Suitable for actual project usage or flight
  simulation training where simulations are
  interrupted to make midstream decisions

35
Model Sectors and Major Interfaces

• Software process and product sector computes the
  staffing and quality over time
• Market and sales sector accounts for market
  dynamics including effect of quality reputation
• Finance sector computes financial measures from
  investments and revenues

36
Software Process and Product
effort and schedule calculation with dynamic
COCOMO variant
product defect flows
37
Finances, Market and Sales
investment and revenue flows
software license sales
market share dynamics including quality
reputation
38
Quality Assumptions

• COCOMO cost driver Required Software Reliability
  is a proxy for all quality practices
• Resulting quality will modulate the actual sales
  relative to the highest potential
• Perception of quality in the market matters
• Quality reputation quickly lost and takes much
  longer to regain (bad news travels fast)
• Modeled as asymmetrical information smoothing via
  negative feedback loop

39
Market Share Production Function and Feature Sets
Cases from Example 1
40
DoD Analog Mission Effectiveness Production
Function and Feature Sets
41
Sales Production Function and Reliability
Cases from Example 1
42
DoD Analog Product Illity Production Function
Reliability or Other Product Illity Rating
43
Example 1 Dynamically Changing Scope and
Reliability

• Shows how model can assess the effects of
  combined strategies by varying the scope and
  required reliability independently or
  simultaneously
• Simulates midstream descoping, a frequent
  strategy to meet time constraints by shedding
  features
• Three cases are demonstrated
• Unperturbed reference case
• Midstream descoping of the reference case after ½
  year
• Simultaneous midstream descoping and lowered
  required reliability at ½ year

44
Control Panel and Simulation Results
Descope
Case 1
Unperturbed Reference Case
Descope Lower Reliability
Case 2
45
Case Summaries
Case Delivered Size (Function Points) Delivered Reliability Setting Cost (M) Delivery Time (Years) Final Market Share ROI
Reference Case Unperturbed 700 1.0 4.78 2.1 28 1.3
Case 1 Descope at Time ½ years 550 1.0 3.70 1.7 28 2.2
Case 2 Descope and Lower Reliability at Time ½ years 550 .92 3.30 1.5 12 1.0
46
Example 2 Determining the Reliability Sweet Spot

• Analysis process
• Vary reliability across runs
• Use risk exposure framework to find process
  optimum
• Assess risk consequences of opposing trends
  market delays and bad quality losses
• Sum market losses and development costs
• Calculate resulting net revenue
• Simulation parameters
• A new 80 KSLOC product release can potentially
  increase market share by 15-30 (varied in model
  runs)
• 75 schedule acceleration
• Initial total market size 64M annual revenue
• Vendor has 15 of market
• Overall market doubles in 5 years

47
Cost Components
3-year time horizon
48
Value-Based Model Conclusions

• To achieve real earned value, business value
  attainment must be a key consideration when
  designing software products and processes
• Software enterprise decision-making can improve
  with information from simulation models that
  integrate business and technical perspectives
• Optimal policies operate within a multi-attribute
  decision space including various stakeholder
  value functions, opposing market factors and
  business constraints
• Risk exposure is a convenient framework for
  software decision analysis
• Commercial process sweet spots with respect to
  reliability are a balance between market delay
  losses and quality losses
• Model demonstrates a stakeholder value chain
  whereby the value of software to end-users
  ultimately translates into value for the software
  development organization

49
Value-Based Model Future Work

• Enhance product defect model with dynamic version
  of COQUALMO to enable more constructive insight
  into quality practices
• Add maintenance and operational support
  activities in the workflows
• Elaborate market and sales for other
  considerations including pricing scheme impacts,
  varying market assumptions and periodic upgrades
  of varying quality
• Account for feedback loops to generate product
  specifications (closed-loop control)
• External feedback from users to incorporate new
  features
• Internal feedback on product initiatives from
  organizational planning and control entity to the
  software process
• More empirical data on attribute relationships in
  the model will help identify areas of improvement
• Assessment of overall dynamics includes more
  collection and analysis of field data on business
  value and quality measures from actual software
  product rollouts

50
Agenda

• Introduction
• Example applications
• Inspection model
• Spiral hybrid process model for
  Software-Intensive System of Systems (SISOS)
• Value-based product model with DoD analogs
• Backup slides
• Introduction, background and examples

51
Backup Slide Outline

• Research introduction
• Processes and system dynamics
• Example model structures and system behaviors
• Brookss Law model demonstration
• Software Process Dynamics book chapters
• Examples
• Inspection model supplement
• Software cost and quality tradeoff simulation
  tool (NASA)
• Process concurrence modeling

52
Terminology

• System a grouping of parts that operate together
  for a common purpose a subset of reality that is
  a focus of analysis
• Open, closed
• Software Process a set of activities, methods,
  practices and transformations used by people to
  develop software.
• Model an abstract representation of reality.
• Static, dynamic continuous, discrete
• Simulation the numerical evaluation of a
  mathematical model.
• System dynamics a simulation methodology for
  modeling continuous systems. Quantities are
  expressed as levels, rates and information links
  representing feedback loops.

53
Why Model Systems?

• A system must be represented in some form in
  order to analyze it and communicate about it.
• The models are abstractions of real or conceptual
  systems used as surrogates for low cost
  experimentation and study.
• Models allow us to understand systems/processes
  by dividing them into parts and looking at how
  the parts are related.
• We resort to modeling and simulation because
  there are too many interdependent factors to be
  computed, and truly complex systems cannot be
  solved by analytical methods.

54
Software Process Models

• Used to quantitatively reason about, evaluate and
  optimize the software process.
• Demonstrate effects of process strategies on
  cost, schedule and quality throughout lifecycle
  and enable tradeoff analyses.
• Can experiment with changed processes via
  simulation before committing project resources.
• Provide interactive training for software
  managers process flight simulation.
• Encapsulate our understanding of development
  processes (and support organizational learning).
• Benchmark process improvement when model
  parameters are calibrated to organizational data.
• Process modeling techniques can be used to
  evaluate other existing descriptive
  theories/models.
• Force clarifications, reveal discrepancies, unify
  fields

55
Process Modeling Characterization Matrix and
Examples
Example Litton studies in Madachy et al. 2000
56
System Dynamics Approach

• Involves following concepts Richardson 91
• 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.
• Dynamic behavior is a consequence of system
  structure

57
Systems Thinking

• A way to realize the structure of a system that
  leads to its behavior
• Systems thinking involves
• Thinking in circles and considering
  interdependencies
• Closed-loop causality vs. straight-line thinking
• Seeing the system as a cause rather than effect
• Internal vs. external orientation
• Thinking dynamically rather than statically
• Operational vs. correlational orientation
• Improvement through organizational learning takes
  place via shared mental models
• The power of models increase as they become more
  explicit and commonly understood by people
• A context for interpreting and acting on data
• System dynamics is a methodology to implement
  systems thinking and leverage learning efforts

58
Software Processes and System Dynamics

• Software development and evolution are dynamic
  and complex processes
• Interrelated technology, business, and people
  factors that keep changing
• E.g. development methods and standards,
  reuse/COTS/open-source, product lines,
  distributed development, improvement initiatives,
  increasing product demands, operating
  environment, volatility, resource contention,
  schedule pressure, communication overhead,
  motivation, etc.
• System dynamics features
• Provides a rich and integrative framework for
  capturing process phenomena and their
  relationships
• Complex and interacting process effects are
  modeled using continuous flows interconnected in
  loops of information feedback and circular
  causality
• Provides a global system perspective and the
  ability to analyze combined strategies
• 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
• Enables low cost process experimentation
• System dynamics is well-suited to deal with the
  complexities of software processes and their
  improvement strategies

59
Software Process Control System
Software Development or Evolution Project
Software Process
Software Artifacts
Requirements, resources etc.
internal project feedback
external feedback from operational environment
60
A Software Process
61
Modeling Process Overview

• Iterative, cyclic

policy implementation
system understandings
policy analysis
problem definition
simulation
model conceptualization
model formulation
62
Modeling Stages and Concerns
context symptoms reference behavior
modes model purpose system boundary feedback
structure model representation model
behavior reference behavior modes
problem definition model conceptualization
model formulation simulation evaluation
63
The Continuous View

• Individual events are not tracked
• Entities are treated as aggregate quantities that
  flow through a system
• can be described through differential equations
• Discrete approaches usually lack feedback,
  internal dynamics

64
Backup Slide Outline

• Research introduction
• Processes and system dynamics
• Example model structures and system behaviors
• Brookss Law model demonstration
• Software Process Dynamics book chapters
• Examples
• Inspection model supplement
• Software cost and quality tradeoff simulation
  tool (NASA)
• Process concurrence modeling

65
Error Co-flows
66
Learning Curve
67
Example Levels and Rates
Levels Rates
68
Example Auxiliaries
69
Software Product Chain
Cycle time per phase start time of first
flowed entity - completion time of last flowed
entity
Cycle time per task transit time through
relevant phase(s)
70
Error Detection and Rework Chain

• Cost/schedule/quality tradeoffs available when
  defects are represented as levels with the
  associated variable effort and cycle time for
  rework and testing as a function of those levels.

71
Personnel Chain
72
Feedback Loops

• A feedback loop is a closed path connecting an
  action decision that affects a level, then
  information on the level being returned to the
  decision making point to act on.

73
Software Production Structure

• Combines task development and personnel chains.
• Production constrained by productivity and
  applied personnel resources.

74
Example Delay Structure and Behavior

• Delays are ubiquitous in processes and important
  components of feedback systems
• outflow rate level / delay time

75
Typical Behavior Patterns
76
General System Behaviors

• Behaviors are representative of many known types
  of systems.
• Knowing how systems respond to given inputs is
  valuable intuition for the modeler
• Can be used during model assessment
• use test inputs to stimulate the system
  behavioral modes

77
System Order

• The order of a system refers to the number of
  levels contained.
• A single level system cannot oscillate, but a
  system with at least two levels can oscillate
  because one part of the system can be in
  disequilibrium.

78
Example System Behaviors

• Delays
• Goal-seeking Negative Feedback
• First-order Negative Feedback
• Second-order Negative Feedback
• Positive Feedback Growth or Decline
• S-curves

79
Delays

• Time delays are ubiquitous in processes
• They are important structural components of
  feedback systems.
• Example hiring delays in software development.
• the average hiring delay represents the time that
  a personnel requisition remains open before a new
  hire comes on board

80
Third Order Delay

• A series of 1st order delays
• Graphs show water levels over time in each tank

tank 1 starts full
81
Delay Summary
input output
Delay order Pulse input Step
input 1 2 3 Infinite (pipeline)
82
Negative Feedback

• Negative feedback exhibits goal seeking behavior,
  or sometimes instability
• May represent hiring increase towards a staffing
  goal. The change is more rapid at first and
  slows down as the discrepancy between desired and
  perceived decreases. Also a good trend for
  residual defect levels.

positive goal

• rate (goal - present level)/time constant

zero goal
Analytically Level Goal (Level0 - Goal)e
-t/tc
83
Orders of Negative Feedback

• First-order Negative Feedback
• Second-order Negative Feedback
• Oscillating behavior may start out with
  exponential growth and level out. It could
  represent the early sales growth of a software
  product that stagnates due to satisfied market
  demand, competition or declining product quality.

84
Positive Feedback

• Positive feedback produces a growth process
• Exponential growth may represent sales growth (up
  to a point), Internet traffic, defect fixing
  costs over time
• rate present levelconstant

Analytically exponential growth
LevelLevel0eat exponential decay
LevelLevel0e-t/TC
85
S-Curves

• S-curve graphic display of a quantity like
  progress or cumulative effort plotted against
  time that exhibits an s-shaped curve. It is
  flatter at the beginning and end, and steeper in
  the middle. It is produced on a project that
  starts slowly, accelerates and then tails off as
  work tapers off
• S-curves are also observed in the ROI curve of
  technology adoption, either time-based return or
  in production functions that relate ROI to
  investment.

86
Backup Slide Outline

• Research introduction
• Processes and system dynamics
• Example model structures and system behaviors
• Brookss Law model demonstration
• Software Process Dynamics book chapters
• Examples
• Inspection model supplement
• Software cost and quality tradeoff simulation
  tool (NASA)
• Process concurrence modeling

87
Brookss Law Modeling Example

• Adding manpower to a late software project makes
  it later Brooks 75.
• We will test the law using 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.
• An effective teaching tool

88
Model Diagram and Equations
89
Model Output for Varying Additions
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)
90
Backup Slide Outline

• Research introduction
• Processes and system dynamics
• Example model structures and system behaviors
• Brookss Law model demonstration
• Software Process Dynamics book chapters
• Examples
• Inspection model supplement
• Software cost and quality tradeoff simulation
  tool (NASA)
• Process concurrence modeling

91
1. INTRODUCTION AND BACKGROUND

• Foreword by Barry Boehm
• Preface
• 1.1 Systems, Processes, Models and Simulation
• 1.2 Systems Thinking
• 1.3 Basic Feedback Systems Concepts Applied to
  the Software Process
• 1.4 Brookss Law Example
• 1.5 Software Process Technology Overview
• 1.6 Challenges for the Software Industry
• 1.7 Major References
• 1.8 Chapter 1 Summary
• 1.9 Exercises

92
2. THE MODELING PROCESS WITH SYSTEM DYNAMICS

• 2.1 System Dynamics Background
• 2.2 General System Behaviors
• 2.3 Modeling Overview
• 2.4 Problem Definition
• 2.5 Model Conceptualization
• 2.6 Model Formulation and Construction
• 2.7 Simulation
• 2.8 Model Assessment
• 2.9 Policy Analysis
• 2.10 Continuous Model Improvement
• 2.11 Software Metrics Considerations
• 2.12 Project Management Considerations
• 2.13 Modeling Tools
• 2.14 Major References
• 2.15 Chapter 2 Summary
• 2.16 Exercises

93
3. MODEL STRUCTURES AND BEHAVIOR FOR SOFTWARE
PROCESSES

• 3.1 Introduction
• 3.2 Model Elements
• 3.3 Generic Flow Processes
• 3.4 Infrastructures and Behaviors
• 3.5 Software Process Chain Infrastructures
• 3.6 Major References
• 3.7 Chapter 3 Summary
• 3.8 Exercises

94
4. PEOPLE APPLICATIONS
4.1 INTRODUCTION
4.2 OVERVIEW OF APPLICATIONS
4.3 PROJECT WORKFORCE MODELING
4.4 EXHAUSTION AND BURNOUT
4.5 LEARNING
4.6 TEAM COMPOSITION
4.7 OTHER APPLICATION AREAS
4.8 MAJOR REFERENCES
4.9 CHAPTER 4 SUMMARY
4.1 EXERCISES
95
5. PROCESS AND PRODUCT APPLICATIONS
5.1 INTRODUCTION
5.2 OVERVIEW OF APPLICATIONS
5.3 PEER REVIEWS
5.4 GLOBAL PROCESS FEEDBACK (SOFTWARE EVOLUTION)
5.5 SOFTWARE REUSE
5.6 COMMERCIAL OFF-THE-SHELF SOFTWARE (COTS) - BASED SYSTEMS
5.7 SOFTWARE ARCHITECTING
5.8 QUALITY AND DEFECTS
5.9 REQUIREMENTS VOLATILITY
5.1 SOFTWARE PROCESS IMPROVEMENT
5.11 MAJOR REFERENCES
5.12 PROVIDED MODELS
5.13 CHAPTER 5 SUMMARY
5.14 EXERCISES
96
6. PROJECT AND ORGANIZATION APPLICATIONS
6.1 INTRODUCTION
6.2 OVERVIEW OF APPLICATIONS
6.3 INTEGRATED PROJECT MODELING
6.4 SOFTWARE BUSINESS CASE ANALYSIS
6.5 PERSONNEL RESOURCE ALLOCATION
6.6 STAFFING
6.7 EARNED VALUE
6.8 MAJOR REFERENCES
6.9 PROVIDED MODELS
6.1 CHAPTER 6 SUMMARY
6.11 EXERCISES
97
7. CURRENT AND FUTURE DIRECTIONS

• 7.1 Introduction
• 7.2 Simulation Environments and Tools
• 7.3 Model Structures and Component-Based Model
  Development
• 7.4 New and Emerging Trends for Applications
• 7.5 Model Integration
• 7.6 Empirical Research and Theory Building
• 7.7 Mission Control Centers and Training
  Facilities
• 7.8 Chapter 8 Summary
• 7.9 Exercises

98
Appendices

• Appendix A Introduction to Statistics of
  Simulation
• A.1 RISK ANALYSIS AND PROBABILITY
• A.2 PROBABILITY DISTRIBUTIONS
• A.4 ANALYSIS OF SIMULATION INPUT
• A.5 EXPERIMENTAL DESIGN
• A.6 ANALYSIS OF SIMULATION OUTPUT
• A.7 MAJOR REFERENCES
• A.8 APPENDIX A SUMMARY
• A.9 EXERCISES
• Appendix B Annotated System Dynamics
  Bibliography
• Appendix C Provided Models

99
Examples of Provided Models (Ch. 6 Only)
...
100
Backup Slide Outline

• Research introduction
• Processes and system dynamics
• Example model structures and system behaviors
• Brookss Law model demonstration
• Software Process Dynamics book chapters
• Examples
• Inspection model supplement
• Software cost and quality tradeoff simulation
  tool (NASA)
• Process concurrence modeling

101
Validation to Empirical Data

• Using 329 Litton inspections and 203 JPL
  inspections

Project/Test Case Test Effort Reduction Test Schedule Reduction
Litton Project a compared to previous project 50 25
Test case 11 with Litton productivity constant and job size compared to test case 1.3 with Litton parameters 48 19
Test case 1.1 compared to test case 1.3 48 21
Project/Test Case Effort Ratio of Rework to Preparation and Meeting
Litton project .47
JPL projects .45
Test case 1.1 .49
Simulated ROI within 15 of actual ROI
102
Sample Project Progress Trends

• From Madachy 94

1 cum tasks design
2 cum tasks coded
3 tasks tested
4 fraction done
5 actual completio
1
1
2
3
4
5
533.30
2
533.27
3
533.27
1
4
1.00
5
5
260.25
1
266.65
2
266.63
3
266.63
4
0.50
5
130.12
1
2
1
0.00
2
0.00
3
0.00
4
4
0.00
1
2
2
3
3
3
4
4
5
5
5
0.00
0.00
75.00
150.00
225.00
300.00
818 AM 11/3/28
Days
task graphs Page 1
103
Error Multiplication Effects
104
Risk Analysis

• A deterministic point estimate from a simulation
  run is only one of many actual possibilities
• Simulation models are ideal for exploring risk
• test the impact of input parameters
• test the impact of different policies
• Monte-Carlo analysis takes random samples from an
  input probability distribution

105
Monte-Carlo Example

• Results of varying inspection efficiency

106
Contributions of Inspection Model

• Demonstrated dynamic effects of performing
  inspections.
• Validated against empirical industry data
• New knowledge regarding interrelated factors of
  inspection effectiveness.
• Demonstrated complementary features of static and
  dynamic models.
• Techniques adopted in industry.

107
Backup Slide Outline

• Research introduction
• Processes and system dynamics
• Example model structures and system behaviors
• Brookss Law model demonstration
• Software Process Dynamics book chapters
• Examples
• Inspection model supplement
• Software cost and quality tradeoff simulation
  tool (NASA)
• Process concurrence modeling

108
Software Cost/Quality Tradeoff Tool (NASA)

• Orthogonal Defect Classification (ODC) COQUALMO
  system dynamics model working prototype
• ODC defect distribution pattern per JPL studies
  Lutz and Mikulski 2003
• Includes effort estimation
• Includes tradeoffs of different detection
  efficiencies for the removal practices per type
  of defect

109
Software Cost/Quality Simulation Tradeoff Tool
Demo
110
Backup Slide Outline

• Research introduction
• Processes and system dynamics
• Example model structures and system behaviors
• Brookss Law model demonstration
• Software Process Dynamics book chapters
• Examples
• Inspection model supplement
• Software cost and quality tradeoff simulation
  tool (NASA)
• Process concurrence modeling

111
Process Concurrence Introduction

• Process concurrence the degree to which work
  becomes available based on work already
  accomplished
• represents an opportunity for parallel work
• a framework for modeling constraint mechanics
• Increasing task parallelism is a primary RAD
  opportunity to decrease cycle time
• System dynamics is attractive to analyze schedule
• can model task interdependencies on the critical
  path

112
Trying to Accelerate Software Development
software tasks
tasks to
develop
personnel
restricted channel flow
development rate
(partially adapted from Putnam 80)
completed
tasks
113
Limited Parallelism of Software Activities

• There are always sequential constraints
  independent of phase
• analysis and specification figure out what
  you're supposed to do
• development of something (architecture, design,
  code, test plan, etc.)
• assessment verify/validate/review/debug
• possible rework recycle of previous activities
• These can't be done totally in parallel with more
  applied people
• different people can perform the different
  activities with limited parallelism, but
  downstream activities will always have to follow
  some of the upstream

114
Lessons from Brooks in The Mythical Man-Month

• Sequential constraints imply tasks cannot be
  partitioned.
• applying more people has no effect on schedule
• Men and months are interchangeable only when
  tasks can be partitioned with no communication
  among them.

115
Process Concurrence Basics

• Process concurrence describes interdependency
  constraints between tasks
• can be an internal constraint within a
  development stage or an external constraint
  between stages
• Describes how much work becomes available for
  completion based on previous work accomplished
• Accounts for realistic bottlenecks on work
  availability
• vs. a model driven solely by resources and
  productivity that can finish in almost zero time
  with infinite resources
• Concurrence relations can be sequential,
  parallel, partially concurrent, or other
  dependent relationships

116
Internal Process Concurrence

• Internal process concurrence relationship shows
  how much work can be done based on the percent of
  work already done.
• The relationships represent the degree of
  sequentiality or concurrence of the tasks
  aggregated within a phase.

117
Internal Concurrence Examples
less parallel integration
region of parallel work
initial work on important segments other
segments have to wait until these are done
Complex system development where tasks are
dependent due to required inter-task
communication.
Simple conversion task where tasks can be
partitioned with no communication
118
External Process Concurrence

• External process concurrence relationships
  describe constraints on amount of work that can
  be done in a downstream phase based on the
  percent of work released by an upstream phase.
• See examples on following slide
• More concurrent processes have curves near the
  upper left axes, and less concurrent processes
  have curves near the lower and right axes.
• Tasks can be considered to be the number of
  function points demonstrable in their
  phase-native form

119
External Concurrence Examples
1 - a linear lockstep concurrence in the
development of totally independent modules 2 -
S-shaped concurrence for new, complex
development where an architecture core is
needed first 3 - highly leveraged instantiation
like COTS with some glue code development 4 -
a slow design buildup between phases
120
Roles Have Different Mental Models

• Differing perceptions upstream and downstream
  (Ford-Sterman 97)
• Group visualization helps identify disparities to
  improve communication and reduce conflict.

121
RAD Modeling Example

• One way to achieve RAD is by having base software
  architectures tuned to application domains
  available for instantiation, standard database
  connectors and reuse.
• The next two slides contrast the concurrence of
  an HR portal development using two different
  development approaches 1) from scratch and 2)
  with an existing HR base architecture.

122
Example Development from Scratch
123
Architecture Approach Comparison
Opportunity for increased task parallelism and
quicker elaboration
124
Rayleigh Curve Applicability

• Rayleigh curve was based on initial studies of
  hardware research and development
• projects resemble traditional waterfall
  development for unprecedented systems
• Rayleigh staffing assumptions dont hold well for
  COTS, reuse, architecture-first design patterns,
  4th generation languages or staff-constrained
  situations
• However an ideal staffing curve is proportional
  to the number of problems ready for solution
  (from a product perspective).

125
Process Concurrence Advantages

• Process concurrence can model more realistic
  situations than the Rayleigh curve and produce
  varying dynamic profiles
• Can be used to show when and why Rayleigh curve
  modeling doesnt apply
• Process concurrence provides a way of modeling
  constraints on making work available, and the
  work available to perform is the same dynamic
  that drives the Rayleigh curve
• since the staff level is proportional to the
  problems (or specifications) ready to implement

126
External Concurrence Model
the time profile of tasksready to elaborate
ideal staffing curve shape
127
Simulation Results and Sample Lessons
flat Rayleigh COTS
pulse
at front
Critical customer decision delays slow progress
- e.g. cant design until timing
performance specs are known Early stakeholder
concurrence enables RAD - e.g. decision on
architectural framework or COTS package
N/A
128
Additional Considerations

• Process concurrence curves can be more precisely
  matched to the software system types
• COTS by definition should exhibit very high
  concurrence
• Mixed strategies produce combined concurrence
  relationships
• E.g. COTS first thennew development

129
Process Concurrence Conclusions

• Process concurrence provides a robust modeling
  framework
• a method to characterize different approaches in
  terms of their ability to parallelize or
  accelerate activities
• Gives a detailed view of project dynamics and is
  relevant for planning and improvement purposes
• a means to collaborate between stakeholders to
  achieve a shared planning vision
• Can be used to derive optimal staffing profiles
  for different project situations
• More generally applicable than the Rayleigh curve
• More empirical data needed on concurrence
  relationships from the field for a variety of
  projects