Software Project Planning

Infsy 570

Dr. R. Ocker

SWE economics analysis (Boehm, 84): throughout the software lifecycle, there

are many decision situations involving limited resources

Examples feasibility phase

– how much should we invest in analyses? plans and requirements phase

– how rigorously should we specify requirements? design phase:

– should we use existing sw which does not completely meet the requriements?

test phase:– how much testing is enough?

Analyzing risk and uncertainty can apply basic micro economic analysis to

these questions in sw engineering, must make decisions

under conditions of uncertainty can reduce uncertainty, and therefore make

better decisions, by buying information e.g. prototyping is a way of buying

information to reduce uncertainty about risky functionality

Question must ask:

How much information-buying is enough?

Project Planning

sw project management process begins with project planning

objective of sw project planning - to provide a framework for manager to make reasonable estimates of resources, costs and schedules

project estimation

first step in project planning

estimate resources, cost, and schedule for sw development project

requires experience and access to historical information

project estimation

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

risk - measured by degree of uncertainty in quantitative estimates

project estimation

evolutionary process models - iterative view of development

possible to revise the estimate estimates made at beginning of sw

project should be updated regularly estimates should define “best case” and

“worst case”

Activities associated with project planning Software scope resources project estimation decomposition

1. software scope

want to establish a project scope that is unambiguous and understandable at management and technical levels

describes:– function– performance – constraints– interfaces– reliability

2. resources

must estimate resources required to accomplish the development effort

fig. 5.2 development resources pyramid

a. hw and sw tools

foundation of resources pyramid, provides infrastructure to support development

sw engineering environment must prescribe the time-frame required

for hw and sw verify that these resources will be

available

b. reusable sw components

next level, can reduce development costs

reuse considerations often ignored can greatly reduce development time

c. people - top of pyramid

select skills needed

each resource specified with 4 characteristics 1. description of resource 2. statement of availability 3. chronological time resource will be

needed 4. duration of time resource used

3. project estimation

cost estimates must be provided up front

but... the longer we wait, the more we know, and the better our estimates

a. use of decomposition techniques: divide and conquer approach decompose project into major functions

and related swe activities cost and effort estimates performed in

stepwise fashion

b. empirical estimation models

can complement decomposition techniques or used alone

model is based on historical data examples: LOC, FP SW cost estimation relies on good

historical data

4. decomposition techniques

decompose the problem (i.e., sw project estimation) into set of smaller problems

from chp. 3 - 2 types of decomposition a. decomposition of the problem b. decomposition of the process before decomposition, must understand project

scope and generate estimate of project size accuracy of estimate strongly influenced by

accuracy of size estimate

Problem-based estimation

direct measure - LOC indirect measure - FP a. begin with bounded statement of sw scope b. decompose sw into problem functions that

can each individually be estimated c. apply sizing measure to each function

– e.g. LOC, FP, OO (classes, objects) d. apply baseline productivity metrics (e.g.,

LOC/pm, FP/pm)

decomposition

decomposition is different for LOC vs. FP:

for LOC - decomposition must be detailed

for FP - looking at input, output, inquiries, data files, interfaces etc.

planner uses historical data or intuition (not recommended)

estimation

make 3 estimates for each function: optimistic, most likely, pessimistic then compute 3 point or expected value see 5.1 then apply historical LOC or FP

productivity data (e.g. FP/pm)

Process-based estimation

most common technique for estimating project

process is decomposed into a small set of activities or task

effort required to complete each is estimated

Process-based estimation

a. determine sw functions using project scope document

b. meld sw process activities and functions determine sw process activities that

must be performed for each function functions and process activities can

be part of a table - see fig 3.2

Process-based estimation

c. apply average labor rates to the effort estimated for each process activity

d. compute costs and effort for each function and software process activitey

can perform process-based estimate independently of LOC or FP

then have 2-3 estimates of cost and effort to compare and reconcile

5. empirical estimation models

The COCOMO Model: Constructive Cost Model [Boehm, 1984]

hierarchy of 3 increasingly detailed software estimation models:

model 1

Basic COCOMO model computes effort and cost estimated as

LOC

model 2

Intermediate COCOMO model computes effort and cost using a set of

cost drivers includes subjective assessments of

product, hw, personnoel, and project attributes

model 3

Advanced COCOMO model incorporates the intermediate version

with an assessment of the cost dirver’s impact on each step (analysis, design, etc.)

Steps for intermediate level (see Boehm, 1984 for detailed example):

Four steps

Step 1 - Nominal effort estimation determine project’s development mode

(organic, semidetached, embedded) estimate size of the project

Step 2 - Determine effort multipliers 15 cost drivers within model - each has

a rating scale and a set of effort multipliers which modifies step 1 estimate

Step 3 - Estimate development effort compute estimated development effort

= nominal effort X product of effort multipliers for 15 cost driver attributes

Step 4 - Estimate related project factors model has additional costing estimation

relationships for computing dollar cost of project and for breakdown by lifecycle phase and by type of project acitivity

can estimate project schedule

9 Management Guidelines for better cost estimating (Lederer and Prasad)

paper reports results of survey on cost estimating practices of 115 computer professionals

Need for better estimates

63% of all large projects (over $50,000) significantly overrun cost estimates

only 25% of projects completed at cost reasonably close to project estimate

Guidelines

Based on results of survey, authors developed 9 guidelines for better cost estimation

1. Assign the initial estimating task to the final developers 2 approaches: a. separate-function approach

– use experienced group of estimators to conduct the feasibility study and prepare initial project estimate

b. combined-function approach– final analysts and programmers prepare initial

estimate during feasibility study– get more accurate estimates with this approach

2. Delay finalizing the initial estimate until the end of a thorough study

often prepare initial cost estimate at beginning of project and then revise it (repeatedly) during the project

found that revision of estimate does not increase accuracy

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!

3. Anticipate and control user changes when lots of changes, like trying to

estimate cost of a moving target 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!

4. Monitor the progress of the proposed project

5. Evaluate project progress by using independent auditors most projects usually monitored by

those involved in it more accurate estimates occur when

independent auditors are present

6. Use the estimate to evaluate project personnel cost estimating used more for project

planning and control than for evaluation of personnel

could use positive rewards for personnel who provide accurate estimates and for those that meet the estimates

7.Computing management should carefully study and approve the cost estimate need to conduct a cost/benefit review

before system development begins

8. Rely on documented facts, standards, and simple arithmetic formulas rather than guessing, intuition, personal memory, and complex formulas.

greater accuracy found when do the above

less accuracy when rely on intuition and personal memory, which is customary

9. Don’t rely on cost estimating software for an accurate estimate. packages don’t improve estimation, and

lower the satisfaction level of the estimators

Words of wisdom

there is no way a cost estimation technique can compensate for the lack of definition or understanding of the sw job to be done

Words of wisdom

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

Words of wisdom

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