Software Process Dynamics

Software Process Dynamics
Dr. Raymond Madachy Naval Postgraduate School INCOSE San Diego Chapter Meeting March 21, 2018

Agenda Introduction Example applications Backup slides Overview
Process models and system dynamics Example applications Brooks’s Law model Inspection model Value-based product model Spiral hybrid process model for Software-Intensive System of Systems (SISOS) Backup slides Introduction, background and examples

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.

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

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 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

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.

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 e.g. with E. Clark, CPLX up, schedule up, but effort down

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. Dynamic behavior is a consequence of system structure The continuous view Individual events are not tracked Entities are treated as aggregate quantities that flow through a system, and can be described through differential equations Discrete approaches usually lack feedback, internal dynamics

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

System Dynamics Notation
System represented by x’(t)= f(x,p). x: vector of levels (state variables), p: set of parameters Legend: Example system:

Model Elements

Model Elements (continued)

Example Levels and Rates

Example Auxiliaries

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)

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.

Personnel Chain

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.

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

Example Delay Structure and Behavior
Delays are ubiquitous in processes and important components of feedback systems outflow rate = level / delay time

Typical Behavior Patterns

Brooks’s 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. Model illustrates software management lessons

Brooks’s Law Dynamics Causal Loop Diagram with Feedback Time Trends

Model Diagram and Equations

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)

Brooks’s Law Model Online
Run or clone the model at

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

System Diagram

System Diagram (continued)

Effects of Inspections
3:18 PM 10/21/28 0.00 75.00 150.00 225.00 300.00 Days 1: 13.00 26.00 1: total manpower rate 2: total manpower rate 1 2 task graphs: Page 7 1: with inspections, 2: without inspections Qualitatively matches generalized effort curves for both cases from Michael Fagan, Advances in software inspections, IEEE Transactions on Software Engineering, July 1986

Inspection Policy Tradeoff Analysis
Varying error generation rates shows diminishing returns from inspections:

Derivation of Phase Specific Cost Driver

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

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

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

Software Process and Product
effort and schedule calculation with dynamic COCOMO variant product defect flows

Finances, Market and Sales
investment and revenue flows software license sales market share dynamics including quality reputation

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

Market Share Production Function and Feature Sets
Cases from Example 1

DoD Analog: Mission Effectiveness Production Function and Feature Sets
Added Mission Effectiveness Percent

Sales Production Function and Reliability
Cases from Example 1

DoD Analog: Product Illity Production Function
Reliability or Other Product Illity Rating

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

Control Panel and Simulation Results
Descope Case 1 Unperturbed Reference Case Descope + Lower Reliability Case 2

Case Summaries Case Delivered Size (Function Points) 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 3.70 1.7 2.2 Case 2: Descope and Lower Reliability .92 3.30 1.5 12%

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

Cost Components 3-year time horizon

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

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

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)

Future Combat Systems (FCS) Network

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

Spiral Hybrid Model Features
Estimates cost and schedule for multiple increments of a hybrid process that uses three specialized teams (agile re-baseliners, developers, V&V’ers) 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

Model Input Control Panel

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 V&V’ed into V & V’ed capabilities Productivities and team sizes for development and V&V calculated with a Dynamic COCOMO variant and continuously updated for scope changes Flow rates between capability changes and V & V’ed 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

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

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 * [1] refers to increment #1

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

Sample Test Results (cont.)

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 V&V 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 V&V’ers 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

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

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.

Process Modeling Characterization Matrix and Examples
Example Litton studies in [Madachy et al. 2000]

Systems Thinking A way to realize the structure of a system that leads to it’s 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

Software Process Control System
Software Development or Evolution Project Software Process Software Artifacts Requirements, resources etc. internal project feedback external feedback from operational environment

A Software Process

Modeling Process Overview
Iterative, cyclic policy implementation system understandings policy analysis problem definition simulation model conceptualization model formulation

Modeling Stages and Concerns
context; symptoms reference behavior modes model purpose system boundary feedback structure model representation model behavior problem definition model conceptualization model formulation simulation evaluation

Error Co-flows

Learning Curve

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

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.

Example System Behaviors
Delays Goal-seeking Negative Feedback First-order Negative Feedback Second-order Negative Feedback Positive Feedback Growth or Decline S-curves

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

Third Order Delay A series of 1st order delays
Graphs show water levels over time in each tank tank 1 starts full

Delay order Pulse input Step input
Delay Summary input output Delay order Pulse input Step input 1 2 3 Infinite (pipeline)

Negative Feedback positive goal zero goal
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

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.

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 level*constant Analytically: exponential growth: Level=Level0eat exponential decay: Level=Level0e-t/TC

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.

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 Brooks’s 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

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

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

OVERVIEW OF APPLICATIONS 4.3 PROJECT WORKFORCE MODELING
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 EXERCISES

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 SOFTWARE PROCESS IMPROVEMENT 5.11 MAJOR REFERENCES 5.12 PROVIDED MODELS 5.13 CHAPTER 5 SUMMARY 5.14 EXERCISES

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 CHAPTER 6 SUMMARY 6.11 EXERCISES

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

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

Examples of Provided Models (Ch. 6 Only)
. . .

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 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

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: 533.30 1 2 3 4 5 2: 533.27 3: 533.27 1 4: 1.00 5: 260.25 5 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: 0.00 4 5: 0.00 1 2 3 4 5 2 3 4 5 3 0.00 75.00 150.00 225.00 300.00 task graphs: Page 1 Days 8:18 AM 11/3/28

Error Multiplication Effects

Simulation models are ideal for exploring risk
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

Monte-Carlo Example Results of varying inspection efficiency:

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.

Processes and system dynamics Example model structures and system behaviors Software Process Dynamics book chapters Examples Inspection model supplement Spiral hybrid process model for Software-Intensive System of Systems (SISOS) Software cost and quality tradeoff simulation tool (NASA) Process concurrence modeling

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

Software Cost/Quality Simulation Tradeoff Tool Demo

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

Trying to Accelerate Software Development
software tasks tasks to develop personnel restricted channel flow development rate (partially adapted from Putnam 80) completed tasks

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

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.

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

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.

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

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

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

Roles Have Different Mental Models
Differing perceptions upstream and downstream (Ford-Sterman 97) Group visualization helps identify disparities to improve communication and reduce conflict.

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.

Example: Development from Scratch

Architecture Approach Comparison
Opportunity for increased task parallelism and quicker elaboration

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 don’t 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). = *

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 doesn’t 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

External Concurrence Model
the time profile of tasks ready to elaborate ~ “ideal” staffing curve shape

Simulation Results and Sample Lessons
flat Rayleigh COTS pulse at front Critical customer decision delays slow progress - e.g. can’t design until timing performance specs are known Early stakeholder concurrence enables RAD - e.g. decision on architectural framework or COTS package N/A

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 then new development:

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

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 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 , 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

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

Software Process Dynamics

Similar presentations

Presentation on theme: "Software Process Dynamics"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Software Process Dynamics

Similar presentations

Presentation on theme: "Software Process Dynamics"— Presentation transcript:

Similar presentations

About project

Feedback