1. University of Southern California Center for Software Engineering CSE USC 3/11/02 1 New System Dynamics Models Ray Madachy madachy@usc.edu USC-CSE Annual Research Review March 11, 2002

2. University of Southern California Center for Software Engineering CSE USC 3/11/02 2 Introduction Brief review of past student projects from CS599 Software Process Modeling Software process concurrence modeling Upgraded Brooks’s Law model to include team partitioning

3. University of Southern California Center for Software Engineering CSE USC 3/11/02 3 CS599 Software Process Modeling Student Term Projects Previously reported at 2000 USC-CSE Research Review: –Dynamics of architecture development process in MBASE inception and elaboration phases –COTS glue code development and integration dynamics –Reuse and language-level effects in software development –CMM-based software process improvement strategies –Application of RAD techniques to pre-IPO Internet companies See supplementary slides at end for some highlights

4. University of Southern California Center for Software Engineering CSE USC 3/11/02 4 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

5. University of Southern California Center for Software Engineering CSE USC 3/11/02 5 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

6. University of Southern California Center for Software Engineering CSE USC 3/11/02 6 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.

7. University of Southern California Center for Software Engineering CSE USC 3/11/02 7 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

8. University of Southern California Center for Software Engineering CSE USC 3/11/02 8 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

9. University of Southern California Center for Software Engineering CSE USC 3/11/02 9 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

10. University of Southern California Center for Software Engineering CSE USC 3/11/02 10 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 the HR portal development using two different development approaches 1) from scratch and 2) with an existing HR base architecture.

11. University of Southern California Center for Software Engineering CSE USC 3/11/02 11 Example: Human Resources Portal Development from Scratch

12. University of Southern California Center for Software Engineering CSE USC 3/11/02 12 Architecture Approach Comparison Opportunity for increased task parallelism and quicker elaboration

13. University of Southern California Center for Software Engineering CSE USC 3/11/02 13 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).

14. University of Southern California Center for Software Engineering CSE USC 3/11/02 14 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

15. University of Southern California Center for Software Engineering CSE USC 3/11/02 15 External Concurrence Model the time profile of tasks ready to elaborate ~ “ideal” staffing curve shape

16. University of Southern California Center for Software Engineering CSE USC 3/11/02 16 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

17. University of Southern California Center for Software Engineering CSE USC 3/11/02 17 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:

18. University of Southern California Center for Software Engineering CSE USC 3/11/02 18 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 empirical data needed on concurrence relationships from the field for a variety of projects

19. University of Southern California Center for Software Engineering CSE USC 3/11/02 19 Brooks’s Law Model Refinement Initial Brooks’s Law model covered communication overhead and training losses (see supplement at end) –applied at Litton to supplement mid-project staffing decisions The initial model (like Abdel-Hamid’s) assumed a single team and calibrated the communication overhead for a maximum team size of 30 people Per Fred Brooks: “A model must account for the fact that the work must be repartitioned, a process I have often found to be nontrivial.” We now have several solutions that model the mechanics of team re-partitioning as the overall staff grows up to 100 people

20. University of Southern California Center for Software Engineering CSE USC 3/11/02 20 Partitioning Modeling Details Communication overhead is split into two components: intra-team overhead and inter-team overhead Partitioned team size is a parameter or variable function Results verified against: –normalized data on productivity as a function of team size from Conte, Dunsmore and Shen 1986 –normalized COCOMO productivity as function of team size

21. University of Southern California Center for Software Engineering CSE USC 3/11/02 21 References USC-CSE Web Sites rcf.usc.edu/~madachy/spd –available models and portions of forthcoming book: Madachy R, Boehm B, Software Process Dynamics, IEEE Computer Society Press, Washington, D.C. sunset.usc.edu/classes/cs599_99 –CS599 Software Process Modeling Course (includes final reports and other system dynamics links) Madachy R, Tutorial: Cost/Schedule/Process Modeling via System Dynamics, Proceedings of the 14th International Forum on COCOMO and Software Cost Modeling, Los Angeles, CA, October 1999

22. University of Southern California Center for Software Engineering CSE USC 3/11/02 22 Supplements CS599 Student Project Summaries Initial Brooks’s Law Model

23. University of Southern California Center for Software Engineering CSE USC 3/11/02 23 MBASE Architecting Modeling Goals Investigate the dynamics of architecture development during early MBASE lifecyle phases Identify nature of process concurrence in early MBASE phases Understand impact of collaboration and prototyping on lifecycle parameters

24. University of Southern California Center for Software Engineering CSE USC 3/11/02 24 MBASE Architecting Model Features Schedule as independent variable Contains iterative process structures Covers sequentiality and concurrency –phases: requirements and architecture/design –activities: initial completion, coordination, quality assurance, iteration Demand-based resource allocation External and internal precedence constraints Calibrated to CS577A data

25. University of Southern California Center for Software Engineering CSE USC 3/11/02 25 MBASE Architecting Causal Loop

26. University of Southern California Center for Software Engineering CSE USC 3/11/02 26 COTS Modeling Goals To understand glue code development and COTS integration process and their correlation To determine efficient starting points of glue code development and COTS integration To calibrate the component parameters from COCOTS To analyze the impact of new parameters such as ratio of new and updated COTS component and number of COTS component

27. University of Southern California Center for Software Engineering CSE USC 3/11/02 27 COTS Model Causal Loop

28. University of Southern California Center for Software Engineering CSE USC 3/11/02 28 Reuse and High Level Language Modeling Goals –investigate project reuse dynamics productivity and effort of individual phases –understand effects of different language levels Model features –rework included –learning curve formulations –increased training for higher level languages

29. University of Southern California Center for Software Engineering CSE USC 3/11/02 29 Reuse Model Causal Diagram

30. University of Southern California Center for Software Engineering CSE USC 3/11/02 30 CMM-Based Software Process Improvement Study Goal: to research and produce a system dynamics model for software process improvement based on the CMM model Provides insights into complex process behavior –help evaluate different approaches Support planning, tracking and prediction –reduce costs –reduce cycle time –reduce defects Based on the scenario of a Xerox S/W development group working from just assessed as a Level 2 organization moving towards achieving Level 3.

31. University of Southern California Center for Software Engineering CSE USC 3/11/02 31 Process Improvement Model Structure

32. University of Southern California Center for Software Engineering CSE USC 3/11/02 32 Internet RAD Modeling Goal: investigate dynamics of rapid Internet development Surveyed companies to determine major impact factors Model features –modified evolutionary delivery lifecycle with small teams for schedule minimization –outsourcing considerations –defect detection and elimination short term and long-term feedback –includes Internet preview and web-site personalization –model sectors: Specification and Design, Outsourcing, Development, Integration and Personalization, Human Resources

33. University of Southern California Center for Software Engineering CSE USC 3/11/02 33 Brooks’ 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.

34. University of Southern California Center for Software Engineering CSE USC 3/11/02 34 Model Diagram and Equations

35. University of Southern California Center for Software Engineering CSE USC 3/11/02 35 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