software project planning infsy 570 dr. r. ocker

Download Software Project Planning Infsy 570 Dr. R. Ocker

Post on 22-Dec-2015

214 views

Category:

Documents

1 download

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