1. Software Process Dynamics USC CSCI 510: Software Management and Economics November 18, 2009 Dr. Raymond Madachy rjmadach@nps.edu

2. 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. 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. 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. 5 The Software Process Dynamics Field 1991 Software Project Dynamics book, Abdel-Hamid and Madnick, MIT –A single model 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, 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. 6 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

7. 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. 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. 9 Model Elements

10. 10 Model Elements (continued)

11. 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. 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. 13 System Diagram

14. 14 System Diagram (continued)

15. 15 Effects of Inspections 3:18 PM 10/21/28 0.0075.00150.00225.00300.00 Days 1: 0.00 13.00 26.00 1: total manpower rate2: total manpower rate 1 1 1 1 2 2 2 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

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

17. 17 Derivation of Phase Specific Cost Driver

18. 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. 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. 20 Future Combat Systems (FCS) Network

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

23. 23 Model Input Control Panel

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

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

27. 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. 28 Sample Test Results (cont.)

29. 29 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 Spiral Hybrid Model Conclusions and Future Work

30. 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. 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. 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. 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. 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. 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. 36 Software Process and Product product defect flows effort and schedule calculation with dynamic COCOMO variant

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

38. 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. 39 Market Share Production Function and Feature Sets Cases from Example 1

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

41. 41 Sales Production Function and Reliability Cases from Example 1

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

43. 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. 44 Control Panel and Simulation Results Unperturbed Reference Case Case 2 Case 1 Descope Descope + Lower Reliability

45. 45 Case Summaries CaseDelivered Size (Function Points) Delivered Reliability Setting Cost ($M) Delivery Time (Years) Final Market Share ROI Reference Case: Unperturbed 7001.04.782.128%1.3 Case 1: Descope at Time = ½ years 5501.03.701.728%2.2 Case 2: Descope and Lower Reliability at Time = ½ years 550.923.301.512%1.0

46. 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. 47 Cost Components 3-year time horizon

48. 48 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 Conclusions

49. 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. 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. 51 Backup Slide Outline Research introduction –Processes and system dynamics –Example model structures and system behaviors –Brooks’s Law model demonstration –Software Process Dynamics book chapters Examples –Inspection model supplement –Software cost and quality tradeoff simulation tool (NASA) –Process concurrence modeling

52. 52 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. Terminology

53. 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. 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. 55 Process Modeling Characterization Matrix and Examples Example Litton studies in [Madachy et al. 2000]

56. 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. 57 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

58. 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. 59 Software Process Control System Software Process Software Artifacts Requirements, resources etc. internal project feedback external feedback from operational environment Software Development or Evolution Project

60. 60 A Software Process

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

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

63. 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. 64 Backup Slide Outline Research introduction –Processes and system dynamics –Example model structures and system behaviors –Brooks’s Law model demonstration –Software Process Dynamics book chapters Examples –Inspection model supplement –Software cost and quality tradeoff simulation tool (NASA) –Process concurrence modeling

65. 65 Error Co-flows

66. 66 Learning Curve

67. 67 Example Levels and Rates Levels Rates

68. 68 Example Auxiliaries

69. 69 Software Product Chain Cycle time per task = transit time through relevant phase(s) Cycle time per phase = start time of first flowed entity - completion time of last flowed entity

70. 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. 71 Personnel Chain

72. 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. 73 Software Production Structure Combines task development and personnel chains. Production constrained by productivity and applied personnel resources.

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

75. 75 Typical Behavior Patterns

76. 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. 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. 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. 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. 80 Third Order Delay A series of 1st order delays Graphs show water levels over time in each tank tank 1 starts full

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

82. 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. zero goal positive goal Analytically: Level = Goal + (Level 0 - Goal)e -t/tc rate = (goal - present level)/time constant

83. 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. 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 level*constant Analytically: exponential growth: Level = Level 0 e at exponential decay: Level = Level 0 e -t/TC

85. 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. 86 Backup Slide Outline Research introduction –Processes and system dynamics –Example model structures and system behaviors –Brooks’s Law model demonstration –Software Process Dynamics book chapters Examples –Inspection model supplement –Software cost and quality tradeoff simulation tool (NASA) –Process concurrence modeling

87. 87 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. An effective teaching tool

88. 88 Model Diagram and Equations

89. 89 Model Output for Varying Additions 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) Days Function points/day

90. 90 Backup Slide Outline Research introduction –Processes and system dynamics –Example model structures and system behaviors –Brooks’s Law model demonstration –Software Process Dynamics book chapters Examples –Inspection model supplement –Software cost and quality tradeoff simulation tool (NASA) –Process concurrence modeling

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

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

93. 93 3. MODEL STRUCTURES AND BEHAVIOR FOR SOFTWARE PROCESSES 3.1Introduction 3.2Model Elements 3.3Generic Flow Processes 3.4Infrastructures and Behaviors 3.5Software Process Chain Infrastructures 3.6Major References 3.7Chapter 3 Summary 3.8Exercises

94. 94 4. PEOPLE APPLICATIONS 4.1INTRODUCTION 4.2OVERVIEW OF APPLICATIONS 4.3PROJECT WORKFORCE MODELING 4.4EXHAUSTION AND BURNOUT 4.5LEARNING 4.6TEAM COMPOSITION 4.7OTHER APPLICATION AREAS 4.8MAJOR REFERENCES 4.9CHAPTER 4 SUMMARY 4.1EXERCISES

95. 95 5. PROCESS AND PRODUCT APPLICATIONS 5.1INTRODUCTION 5.2OVERVIEW OF APPLICATIONS 5.3PEER REVIEWS 5.4GLOBAL PROCESS FEEDBACK (SOFTWARE EVOLUTION) 5.5SOFTWARE REUSE 5.6COMMERCIAL OFF-THE-SHELF SOFTWARE (COTS) - BASED SYSTEMS 5.7SOFTWARE ARCHITECTING 5.8QUALITY AND DEFECTS 5.9REQUIREMENTS VOLATILITY 5.1SOFTWARE PROCESS IMPROVEMENT 5.11MAJOR REFERENCES 5.12PROVIDED MODELS 5.13CHAPTER 5 SUMMARY 5.14EXERCISES

96. 96 6. PROJECT AND ORGANIZATION APPLICATIONS 6.1INTRODUCTION 6.2OVERVIEW OF APPLICATIONS 6.3INTEGRATED PROJECT MODELING 6.4SOFTWARE BUSINESS CASE ANALYSIS 6.5PERSONNEL RESOURCE ALLOCATION 6.6STAFFING 6.7EARNED VALUE 6.8MAJOR REFERENCES 6.9PROVIDED MODELS 6.1CHAPTER 6 SUMMARY 6.11EXERCISES

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

98. 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. 99 Examples of Provided Models (Ch. 6 Only)......

100. 100 Backup Slide Outline Research introduction –Processes and system dynamics –Example model structures and system behaviors –Brooks’s Law model demonstration –Software Process Dynamics book chapters Examples –Inspection model supplement –Software cost and quality tradeoff simulation tool (NASA) –Process concurrence modeling

101. 101 Validation to Empirical Data Using 329 Litton inspections and 203 JPL inspections Project/Test CaseTest 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. 102 Sample Project Progress Trends From [Madachy 94] 8:18 AM 11/3/28 0.0075.00150.00225.00300.00 Days 1: 2: 3: 4: 5: 0.00 266.65 533.30 0.00 266.63 533.27 0.00 266.63 533.27 0.00 0.50 1.00 0.00 130.12 260.25 1: cum tasks design…2: cum tasks coded3: tasks tested4: fraction done5: actual completio… 1 1 1 1 22 2 2 333 3 44 4 4 55 5 5 task graphs: Page 1

103. 103 Error Multiplication Effects

104. 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. 105 Monte-Carlo Example Results of varying inspection efficiency:

106. 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. 107 Backup Slide Outline Research introduction –Processes and system dynamics –Example model structures and system behaviors –Brooks’s Law model demonstration –Software Process Dynamics book chapters Examples –Inspection model supplement –Software cost and quality tradeoff simulation tool (NASA) –Process concurrence modeling

108. 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. 109 Software Cost/Quality Simulation Tradeoff Tool Demo

110. 110 Backup Slide Outline Research introduction –Processes and system dynamics –Example model structures and system behaviors –Brooks’s Law model demonstration –Software Process Dynamics book chapters Examples –Inspection model supplement –Software cost and quality tradeoff simulation tool (NASA) –Process concurrence modeling

111. 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. 112 Trying to Accelerate Software Development development rate software tasks restricted channel flow tasks to develop completed tasks personnel (partially adapted from Putnam 80)

113. 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. 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. 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. 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. 117 Internal Concurrence Examples Simple conversion task where tasks can be partitioned with no communication Complex system development where tasks are dependent due to required inter-task communication. initial work on important segments; other segments have to wait until these are done region of parallel work less parallel integration

118. 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. 119 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 External Concurrence Examples

120. 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. 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. 122 Example: Development from Scratch

123. 123 Architecture Approach Comparison Opportunity for increased task parallelism and quicker elaboration

124. 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 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). = *

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

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

127. 127 Simulation Results and Sample Lessons flat Rayleigh COTS pulse at front N/A 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

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

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