Software Project Planning Infsy 570 Dr. R. Ocker

Download Software Project Planning Infsy 570 Dr. R. Ocker

Post on 22-Dec-2015




1 download

Embed Size (px)


<ul><li> Slide 1 </li> <li> Software Project Planning Infsy 570 Dr. R. Ocker </li> <li> Slide 2 </li> <li> SWE economics analysis (Boehm, 84): n throughout the software lifecycle, there are many decision situations involving limited resources </li> <li> Slide 3 </li> <li> 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? </li> <li> Slide 4 </li> <li> 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 </li> <li> Slide 5 </li> <li> Question must ask: n How much information-buying is enough? </li> <li> Slide 6 </li> <li> 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 </li> <li> Slide 7 </li> <li> 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 </li> <li> Slide 8 </li> <li> 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 </li> <li> Slide 9 </li> <li> 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 </li> <li> Slide 10 </li> <li> Activities associated with project planning n Software scope n resources n project estimation n decomposition </li> <li> Slide 11 </li> <li> 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 </li> <li> Slide 12 </li> <li> 2.resources n must estimate resources required to accomplish the development effort n fig. 5.2development resources pyramid </li> <li> Slide 13 </li> <li> 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 </li> <li> Slide 14 </li> <li> b. reusable sw components n next level, can reduce development costs n reuse considerations often ignored n can greatly reduce development time </li> <li> Slide 15 </li> <li> c. people - top of pyramid n select skills needed </li> <li> Slide 16 </li> <li> 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 </li> <li> Slide 17 </li> <li> 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 </li> <li> Slide 18 </li> <li> 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 </li> <li> Slide 19 </li> <li> 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 </li> <li> Slide 20 </li> <li> 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 </li> <li> Slide 21 </li> <li> 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) </li> <li> Slide 22 </li> <li> 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) </li> <li> Slide 23 </li> <li> 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) </li> <li> Slide 24 </li> <li> 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 </li> <li> Slide 25 </li> <li> 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 </li> <li> Slide 26 </li> <li> 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 </li> <li> Slide 27 </li> <li> 5.empirical estimation models n The COCOMO Model: Constructive Cost Model [Boehm, 1984] n hierarchy of 3 increasingly detailed software estimation models: </li> <li> Slide 28 </li> <li> model 1 n Basic COCOMO model n computes effort and cost estimated as LOC </li> <li> Slide 29 </li> <li> 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 </li> <li> Slide 30 </li> <li> 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.) </li> <li> Slide 31 </li> <li> Steps for intermediate level (see Boehm, 1984 for detailed example): n Four steps </li> <li> Slide 32 </li> <li> Step 1 - Nominal effort estimation n determine projects development mode (organic, semidetached, embedded) n estimate size of the project </li> <li> Slide 33 </li> <li> 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 </li> <li> Slide 34 </li> <li> Step 3 - Estimate development effort n compute estimated development effort = nominal effort X product of effort multipliers for 15 cost driver attributes </li> <li> Slide 35 </li> <li> 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 </li> <li> Slide 36 </li> <li> 9 Management Guidelines for better cost estimating (Lederer and Prasad) n paper reports results of survey on cost estimating practices of 115 computer professionals </li> <li> Slide 37 </li> <li> 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 </li> <li> Slide 38 </li> <li> Guidelines n Based on results of survey, authors developed 9 guidelines for better cost estimation </li> <li> Slide 39 </li> <li> 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 </li> <li> Slide 40 </li> <li> 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! </li> <li> Slide 41 </li> <li> 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! </li> <li> Slide 42 </li> <li> 4.Monitor the progress of the proposed project </li> <li> Slide 43 </li> <li> 5.Evaluate project progress by using independent auditors n most projects usually monitored by those involved in it n more accurate estimates occur when independent auditors are present </li> <li> Slide 44 </li> <li> 6.Use the estimate to evaluate project personnel n cost estimating used more for project planning and control than for evaluation of personnel n could use positive rewards for personnel who provide accurate estimates and for those that meet the estimates </li> <li> Slide 45 </li> <li> 7.Computing management should carefully study and approve the cost estimate n need to conduct a cost/benefit review before system development begins </li> <li> Slide 46 </li> <li> 8.Rely on documented facts, standards, and simple arithmetic formulas rather than guessing, intuition, personal memory, and complex formulas. n greater accuracy found when do the above n less accuracy when rely on intuition and personal memory, which is customary </li> <li> Slide 47 </li> <li> 9.Dont rely on cost estimating software for an accurate estimate. n packages dont improve estimation, and lower the satisfaction level of the estimators </li> <li> Slide 48 </li> <li> Words of wisdom n there is no way a cost estimation technique can compensate for the lack of definition or understanding of the sw job to be done </li> <li> Slide 49 </li> <li> Words of wisdom n there is no magic formula that will provide an easy and accurate substitute for the process of thinking through and fully understanding the nature of the software product to be developed </li> <li> Slide 50 </li> <li> Words of wisdom n unless a software project has clear definitions of its key milestones and realistic estimates of the time and money it will take to achieve them, there is no way that a project manager can tell whether the project is under control or not </li> </ul>