cs599 9/7/991University of Southern CaliforniaCenter for Software EngineeringC S EUSCCS599 Software Process ModelingWeek 2Ray MadachySeptember 7, 1999cs599 9/7/992University of Southern CaliforniaCenter for Software EngineeringC S EUSCOutline• Boehm: Using Process Models to AnalyzeRapid Application Development• Software Process Modeling Overview(continued from last week)• System Dynamics Fundamentals• Brookes’s Law Introduction• Brookes’s Law Model– overview– experimentation– homeworkcs599 9/7/993University of Southern CaliforniaCenter for Software EngineeringC S EUSCSoftware Process Models• Enable process experimentation via simulationwithout tying up valuable resources– tradeoff analyses and process optimization• Models can be used to quantitatively evaluate thesoftware process– demonstrate effects of process strategies on cost, schedule andquality throughout lifecycle– can experiment with changed processes before committing projectresources– interactive training for software managers; “process flightsimulation”– implement process re-engineering– continually calibrate models with latest datacs599 9/7/994University of Southern CaliforniaCenter for Software EngineeringC S EUSCSoftware Process Models (cont.)• Encapsulate our understanding of developmentprocesses (and support organizational learning).• Benchmark process improvement since modelparameters are calibrated to organizational data.cs599 9/7/995University of Southern CaliforniaCenter for Software EngineeringC S EUSCSystem 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 dynamicsof a system– thinking of all real systems concepts as continuous quantitiesinterconnected in information feedback loops and circular causality– identifying independent levels in the system and their inflow and outflowrates– formulating a model capable of reproducing the dynamic problem ofconcern by itself– deriving understandings and applicable policy insights from the resultingmodel– implementing changes resulting from model-based understandings andinsights.• Dynamic behavior is a consequence of systemstructurecs599 9/7/996University of Southern CaliforniaCenter for Software EngineeringC S EUSCApplicability to Software Processes• Since software development is a dynamic and complex processwith many factors, system dynamics is well-suited to analysis ofsoftware process improvement strategies– global system perspective– accounts for process feedback effects– can model inherent tradeoffs between schedule, cost and quality– accounts for critical path flows to analyze schedule as opposed totraditional cost reduction analyses– enables low cost process experimentationcs599 9/7/997University of Southern CaliforniaCenter for Software EngineeringC S EUSCSystem Dynamics Notationn System represented by x’(t)= f(x,p).• x: vector of levels (state variables), p: set of parametersn Legend:n Example system:level 1inflow1level 2outflowauxiliaryinflow2levelrateauxiliary variableinformation linksource/sinkcs599 9/7/998University of Southern CaliforniaCenter for Software EngineeringC S EUSCModel Components• Level– An accumulation over time, also called stock or state variable. A storagedevice for material, energy, information.– Snapshot test: stop time and freeze flows in actual system. Levelvariables are those that still exist and have meaning in snapshot; theaccumulations can be measured.– Software process level instances:• Work artifacts (requirements, tasks, lines of code, documentation pages)• Defect levels• Personnel levels• Effort expenditure• Schedule date• Otherscs599 9/7/999University of Southern CaliforniaCenter for Software EngineeringC S EUSCModel Components (continued)• Rates– flows; the “actions” in a system– inseparable from levels– effect the changes in levels• Sources and sinks– their presence indicates that the real-world accumulations occur outsideboundary of the system being modeled– represent infinite supplies or repositories• Auxiliaries– converters of input to output– they elaborate detail of stock and flow structure– often represent “score-keeping” variables• Connectors– information linkagescs599 9/7/9910University of Southern CaliforniaCenter for Software EngineeringC S EUSCSoftware Product Transformationstasks designedtasks requiredrqts generation ratedesign ratetasks codedcoding ratetasks testedtesting rateCycle time per task = transit time through relevant phase(s)Cycle time per phase = start time of first flowed entity - completion time of last flowed entitycs599 9/7/9911University of Southern CaliforniaCenter for Software EngineeringC S EUSCCost/Schedule/Quality Tradeoffs• Inherent in system dynamics models that represent defects as levels, andinclude the associated variable effort and cycle time for rework and testing as afunction of those levelserror generation rateundetected errorserrorsdetected errorsreworked errorserror detection rateerror escape raterework ratecum rework effortrework manpower raterework effort per errorcs599 9/7/9912University of Southern CaliforniaCenter for Software EngineeringC S EUSCBrooks’ Law Modeling Example• “Adding manpower to a late softwareproject makes it later” [Brooks 75].• We will test the law using a simple modelbased on the following assumptions:– new personnel require training by experiencedpersonnel to come up to speed– more people on a project entail more communicationoverhead– experienced personnel are more productive then newpersonnel, on average.cs599 9/7/9913University of Southern CaliforniaCenter for Software EngineeringC S EUSCModel Diagram and Equationscs599 9/7/9914University of Southern CaliforniaCenter for Software EngineeringC S EUSCModel Output for Varying AdditionsSensitivity 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)DaysFunction points/daycs599 9/7/9915University of Southern CaliforniaCenter for Software EngineeringC S EUSCBrooks’s Law Homework• Preliminary reading for homework problem:– Brooks: The Mythical Man-Month, pp. 16-26, 231-232, 273-275– Software Process Dynamics, Section 1.4 Brooks’s Law Example– Briand et al.: Explaining the Cost of European Space and
View Full Document