DOC PREVIEW
USC CSCI 599 - 9_7_99

This preview shows page 1-2-3-4-5-6 out of 18 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 18 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

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

USC CSCI 599 - 9_7_99

Documents in this Course
Week8_1

Week8_1

22 pages

Week2_b

Week2_b

10 pages

LECT6BW

LECT6BW

20 pages

LECT6BW

LECT6BW

20 pages

5

5

44 pages

12

12

15 pages

16

16

20 pages

Nima

Nima

8 pages

Week1

Week1

38 pages

Week11_c

Week11_c

30 pages

afsin

afsin

5 pages

October5b

October5b

43 pages

Week11_2

Week11_2

20 pages

final

final

2 pages

c-4

c-4

12 pages

0420

0420

3 pages

Week9_b

Week9_b

20 pages

S7Kriegel

S7Kriegel

21 pages

Week4_2

Week4_2

16 pages

sandpres

sandpres

21 pages

Week6_1

Week6_1

20 pages

4

4

33 pages

Week10_c

Week10_c

13 pages

fft

fft

18 pages

LECT7BW

LECT7BW

19 pages

24

24

15 pages

14

14

35 pages

Week9_c

Week9_c

24 pages

Week11_67

Week11_67

22 pages

Week1

Week1

37 pages

LECT3BW

LECT3BW

28 pages

Week8_c2

Week8_c2

19 pages

Week5_1

Week5_1

19 pages

LECT5BW

LECT5BW

24 pages

Week10_b

Week10_b

16 pages

Week11_1

Week11_1

43 pages

Week7_2

Week7_2

15 pages

Week5_b

Week5_b

19 pages

Week11_a

Week11_a

29 pages

LECT14BW

LECT14BW

24 pages

T7kriegel

T7kriegel

21 pages

0413

0413

2 pages

3

3

23 pages

C2-TSE

C2-TSE

16 pages

10_19_99

10_19_99

12 pages

s1and2-v2

s1and2-v2

37 pages

Week10_3

Week10_3

23 pages

jalal

jalal

6 pages

1

1

25 pages

T3Querys

T3Querys

47 pages

CS17

CS17

15 pages

porkaew

porkaew

20 pages

LECT4BW

LECT4BW

21 pages

Week10_1

Week10_1

25 pages

wavelet

wavelet

17 pages

October5a

October5a

22 pages

p289-korn

p289-korn

12 pages

2

2

33 pages

rose

rose

36 pages

Week10_2

Week10_2

28 pages

Week7_3

Week7_3

37 pages

Load more
Download 9_7_99
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view 9_7_99 and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view 9_7_99 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?