# software project planning infsy 570 dr. r. ocker

Post on 22-Dec-2015

214 views

Embed Size (px)

TRANSCRIPT

- Slide 1
- Software Project Planning Infsy 570 Dr. R. Ocker
- Slide 2
- SWE economics analysis (Boehm, 84): n throughout the software lifecycle, there are many decision situations involving limited resources
- Slide 3
- Examples n feasibility phase how much should we invest in analyses? n plans and requirements phase how rigorously should we specify requirements? n design phase: should we use existing sw which does not completely meet the requriements? n test phase: how much testing is enough?
- Slide 4
- Analyzing risk and uncertainty n can apply basic micro economic analysis to these questions n in sw engineering, must make decisions under conditions of uncertainty n can reduce uncertainty, and therefore make better decisions, by buying information n e.g. prototyping is a way of buying information to reduce uncertainty about risky functionality
- Slide 5
- Question must ask: n How much information-buying is enough?
- Slide 6
- Project Planning n sw project management process begins with project planning n objective of sw project planning - to provide a framework for manager to make reasonable estimates of resources, costs and schedules
- Slide 7
- project estimation n first step in project planning n estimate resources, cost, and schedule for sw development project n requires experience and access to historical information
- Slide 8
- project estimation n estimation is risky business - lots of uncertainty due to: project complexity project size degree of structural uncertainty - degree to which requirements are solidified availability of historical information n risk - measured by degree of uncertainty in quantitative estimates
- Slide 9
- project estimation n evolutionary process models - iterative view of development n possible to revise the estimate n estimates made at beginning of sw project n should be updated regularly n estimates should define best case and worst case
- Slide 10
- Activities associated with project planning n Software scope n resources n project estimation n decomposition
- Slide 11
- 1.software scope n want to establish a project scope that is unambiguous and understandable at management and technical levels n describes: function performance constraints interfaces reliability
- Slide 12
- 2.resources n must estimate resources required to accomplish the development effort n fig. 5.2development resources pyramid
- Slide 13
- a. hw and sw tools n foundation of resources pyramid, provides infrastructure to support development n sw engineering environment n must prescribe the time-frame required for hw and sw n verify that these resources will be available
- Slide 14
- b. reusable sw components n next level, can reduce development costs n reuse considerations often ignored n can greatly reduce development time
- Slide 15
- c. people - top of pyramid n select skills needed
- Slide 16
- each resource specified with 4 characteristics n 1. description of resource n 2. statement of availability n 3. chronological time resource will be needed n 4. duration of time resource used
- Slide 17
- 3.project estimation n cost estimates must be provided up front n but... the longer we wait, the more we know, and the better our estimates
- Slide 18
- a. use of decomposition techniques: n divide and conquer approach n decompose project into major functions and related swe activities n cost and effort estimates performed in stepwise fashion
- Slide 19
- b. empirical estimation models n can complement decomposition techniques or used alone n model is based on historical data n examples: LOC, FP n SW cost estimation relies on good historical data
- Slide 20
- 4.decomposition techniques n decompose the problem (i.e., sw project estimation) into set of smaller problems n from chp. 3 - 2 types of decomposition n a. decomposition of the problem n b. decomposition of the process n before decomposition, must understand project scope and generate estimate of project size n accuracy of estimate strongly influenced by accuracy of size estimate
- Slide 21
- Problem-based estimation n direct measure - LOC n indirect measure - FP n a. begin with bounded statement of sw scope n b. decompose sw into problem functions that can each individually be estimated n c. apply sizing measure to each function e.g. LOC, FP, OO (classes, objects) n d. apply baseline productivity metrics (e.g., LOC/pm, FP/pm)
- Slide 22
- decomposition n decomposition is different for LOC vs. FP: n for LOC - decomposition must be detailed n for FP - looking at input, output, inquiries, data files, interfaces etc. n planner uses historical data or intuition (not recommended)
- Slide 23
- estimation n make 3 estimates for each function: n optimistic, most likely, pessimistic n then compute 3 point or expected value n see 5.1 n then apply historical LOC or FP productivity data (e.g. FP/pm)
- Slide 24
- Process-based estimation n most common technique for estimating project n process is decomposed into a small set of activities or task n effort required to complete each is estimated
- Slide 25
- Process-based estimation n a. determine sw functions using project scope document n b. meld sw process activities and functions n determine sw process activities that must be performed for each function n functions and process activities can be part of a table - see fig 3.2
- Slide 26
- Process-based estimation n c. apply average labor rates to the effort estimated for each process activity n d. compute costs and effort for each function and software process activitey n can perform process-based estimate independently of LOC or FP n then have 2-3 estimates of cost and effort to compare and reconcile
- Slide 27
- 5.empirical estimation models n The COCOMO Model: Constructive Cost Model [Boehm, 1984] n hierarchy of 3 increasingly detailed software estimation models:
- Slide 28
- model 1 n Basic COCOMO model n computes effort and cost estimated as LOC
- Slide 29
- model 2 n Intermediate COCOMO model n computes effort and cost using a set of cost drivers n includes subjective assessments of product, hw, personnoel, and project attributes
- Slide 30
- model 3 n Advanced COCOMO model n incorporates the intermediate version with an assessment of the cost dirvers impact on each step (analysis, design, etc.)
- Slide 31
- Steps for intermediate level (see Boehm, 1984 for detailed example): n Four steps
- Slide 32
- Step 1 - Nominal effort estimation n determine projects development mode (organic, semidetached, embedded) n estimate size of the project
- Slide 33
- Step 2 - Determine effort multipliers n 15 cost drivers within model - each has a rating scale and a set of effort multipliers which modifies step 1 estimate
- Slide 34
- Step 3 - Estimate development effort n compute estimated development effort = nominal effort X product of effort multipliers for 15 cost driver attributes
- Slide 35
- Step 4 - Estimate related project factors n model has additional costing estimation relationships for computing dollar cost of project and for breakdown by lifecycle phase and by type of project acitivity n can estimate project schedule
- Slide 36
- 9 Management Guidelines for better cost estimating (Lederer and Prasad) n paper reports results of survey on cost estimating practices of 115 computer professionals
- Slide 37
- Need for better estimates n 63% of all large projects (over $50,000) significantly overrun cost estimates n only 25% of projects completed at cost reasonably close to project estimate
- Slide 38
- Guidelines n Based on results of survey, authors developed 9 guidelines for better cost estimation
- Slide 39
- 1.Assign the initial estimating task to the final developers n 2 approaches: n a.separate-function approach use experienced group of estimators to conduct the feasibility study and prepare initial project estimate n b.combined-function approach final analysts and programmers prepare initial estimate during feasibility study get more accurate estimates with this approach
- Slide 40
- 2.Delay finalizing the initial estimate until the end of a thorough study n often prepare initial cost estimate at beginning of project and then revise it (repeatedly) during the project n found that revision of estimate does not increase accuracy n people seem to look to the original estimate, not the revised estimate, when judging cost estimation accuracy - - so better to be right the first time!
- Slide 41
- 3.Anticipate and control user changes n when lots of changes, like trying to estimate cost of a moving target n estimators need to thoroughly understand user requirments before they estimate its cost should be able to reduce and control frequent change requests discourage unnecessary user changes - charge extra!
- S

Recommended