Topic5 Project Estimates

8/14/2019 Topic5 Project Estimates

1/38


2/38


3/38


4/38

Cost estimation objectives

To establish a budget for a software project. To provide a means of controlling project costs. To monitor progress against that budget by

comparing planned with estimated costs. To establish a cost database for future

estimation. Cost estimation and planning/scheduling are closely related

activities.


5/38

Software cost components

Hardware and software costs. Travel and training costs.

Effort costs (the dominant factor in most projects) The salaries of engineers involved in the project; Social and insurance costs.

Effort costs must take overheads into account Costs of building, heating, lighting.

Costs of networking and communications. Costs of shared facilities (e.g library, staff restaurant, etc.).


6/38

Estimation Techniques - TraditionalProject Management Approaches

Guesstimating Delphi Technique

Time Boxing Top-Down Bottom-Up Three point

Analogous Estimates (Past experiences)


7/38

Guestimating

Estimation by guessing or just picking numbers out of the air isnot the best way to derive a projects schedule and budget.Unfortunately, many inexperienced project managers tend toguesstimate, or guess at the estimates , because it is quickand easy.


8/38

Delphi Technique

Involves multiple, anonymous experts Each expert makes an estimate

Estimates compared If close, can be averaged If not, do another iteration until consensus is reached


9/38

Time Boxing

A box of time is allocatedfor a specific activity, task, ordeliverable

Can focus a team if usedeffectively

Can demoralize a team if notused effectively


10/38

Top-Down

Top & middle managersdetermine overall projectschedule &/or cost

Lower level managers areexpected to breakdownschedule/budget estimatesinto specific activities (WBS)


11/38

Bottom-Up

Schedules & budgets areconstructed from WBS

Starts with people who willbe doing the work

Schedules & budgets arethe aggregate of detailedactivities & costs


12/38

Analogous Estimates

Use information from previous, similar projects as abasis for estimation Usually done in a Top -down approach Have 3 or 4 experts review requirements Make sure you have the experience and that the two

systems are very similar Can use time, or LOC, or Function Points


13/38

Three Point

Use a weighted average approach or beta probability distributionapproach to capture three point estimates for each work package Optimistic, Normal, Pessimistic

Equations for expected value (E), and the standard deviation (SD) are: E = (a + 4b + c)/6; SD = (c-a)/6

a = the optimistic estimateb = normal estimate

c = pessimistic estimate


14/38

Three Point Adds the element of risk into its calculations SMEs determine three types of estimates:

Most Likely

Optimistic Pessimistic

Next the SME uses the weighted average formula


15/38

Three Point ExampleWeighted average =8 workdays + 4 X 10 workdays + 24 workdays = 12 days

6

where:optimistic time= 8 daysmost likely time = 10 days pessimistic time = 24 days

Therefore, youd use 12 days on the schedule instead of 10when using this technique.

E = (a + 4b + c)/6


16/38

6.2 Test Results Report6.2.1 Review test plan with client 1 day6.2.2 Carry out test plan 5 days6.2.3 Analyze results 2 days6.2.4 Prepare test results report and presentation 3 days

6.2.5 Present test results to client 1 day6.2.6 Address any software issues or problems 5 days

Estimates are made for eachactivity in the WBS

How did we come up with these estimates? Using a technique,or combination of techniques, with the exception of guestimating!


17/38

Estimating Techniques -Software Engineering Approaches

Lines of Code (LOC) Function Points

COCOMO


18/38

Task Sizing Lines of Code

Has been one of the most used methods Based on historical results Effort, dollars, documentation, software bugs, and

number of resources Advantages

Can be very quick and inexpensive to generate Can be done early in the process

Universal metric Can be generated easily, in most environments

automatically Facilitate a lessons-learned process


19/38

Lines of Code - Disadvantages

Must compensate for technology differences Cant be done well unless relevant history exists Must determine what counts as a line of code What level of resource is generating the code No industry standards Need to distinguish between auto-generated

code and original work Needs to be continually updated


20/38

Function Points Analysis

used to estimate time and dollars based on thegenerated system requirements specification

A function point measures the size of a businessfunction that the new system needs to have such as aninput screen or report

Function Point analysis can be done at any point in theproject but are not considered accurate until late inthe planning phase


21/38

Process of Function PointsStep 1 : Count the number of business functions within each of the

following categories: user inputs, user outputs, inquiries, datastructures, and external interfaces

Step 2 : Determine the complexity level of each function as simple,medium, or complex. For example output complexity is determinedby the number of elements involved, any complex calculations orcomplex process logic and the number of data structures.

Step 3 : Assign weights for each level of complexity within eachcategory

Step 4 : Multiply each function by its weight and then sum each

product to obtain the total unadjusted function points.Step 5 : Compute the Value Adjustment Factor (VAF)Step 6 : Compute adjusted function point total using the formula

[Unadjusted total x (0.65 + 0.01 x VAF)]


22/38

Example


23/38

Next Step: compute the value adjustmentfactor based on the following table

0 = no effect1 = incidental2 = moderate3 = average4 = significant

5 = essential


24/38

Function Points Next : calculate the total adjusted function points:

Unadjusted total x (0.65 + 0.01 x VAF) or1050 x (0.65 + 0.01 x 40) = 1102.50

Results

Effort = (1.49 hrs effort per f/point) (1102.50) = 1,642.7 hrs

Documentation (.25 pages per f/point) (1102.50) = 275.63pages

Bugs (.025 bugs per f/point) (1102.50) = 27.5 bugs User Instructed Rework (.04 per f/point) (1102.50) = 44.1 Dollars ($105.10 per f/point) (1102.50) = $115,872.75


25/38

Uses for Function Points

# of pages of documentation per FP Levels of effort per FP (person months) Level of expertise per FP (expert, novice) Cost per FP

New derivative called Feature Points or ObjectPoints


26/38

Advantages with Function Points It is independent of programming language and technology It can be used early in the project life cycle at the end of the

requirements discovery phase or design phase A wealth of research exists to support the process

Impact of scope changes easier for all to comprehend andtrack Organizations can track their own results and improve the

function point estimates

It can be used in any development environment


27/38

Issues with Function Points

Requires many subjective evaluations (complexity ratings andenvironmental factors)

Accuracy is greatly increased only after the detailed designphase or after a few project iterations have been performed

Takes some time (training) to perfect and can vary dependingon who is doing the calculations due to personal bias


28/38

COCOMO

COnstructive COst MOdel First developed by Barry Boehm in 1981 Most widely accepted models available today Revised into version II in 1995 Version II setup to handle new development

methodologies; RAD, Iterative/Incremental, COTSpackages, O-O application distribution, frameworksand components, etc.

Models available on website and algorithms arepublished. Commercial software exists


29/38

COCOMO Consists of three project types described as:

Organic small project teams, little innovation, constraintsand deadlines are few, stable development environments,known familiar technology, few changes expected

Semidetached medium sized project teams, someinnovation, few constraints, tighter deadlines, and morechanges expected, still a fairly stable developmentenvironment

Embedded largest of the three in all categories, largeproject teams, constant innovation, many constraints, verytight deadlines, and many changes expected, complexdevelopment environment


30/38

COCOMO Effort Sizing

Organic: Effort = 2.4 x KLOC1.05 where KLOC = 1000 lines of code Duration = 2.5 x Effort 0.38

Semidetached Effort = 3.0 x KLOC1.12 Duration = 2.5 x Effort 0.35

Embedded Effort = 3.6 x KLOC1.20 Duration = 2.5 x Effort 0.32


31/38

COCOMO Effort Example

Semi-Detached

10,600 Java LOC = 200 FP * 53

Effort = 3.0 * KLOC1.12

= 3.0 * (10.6) 1.12

= 42.21


32/38

COCOMO Duration Example

Duration = 2.5 * Effort 0.35

= 2.5 *(42.21) 0.35

= 9.26 months

People Required = Effort / Duration= 42.21 / 9.26

= 4.55


33/38

COCOMO Advantages

Can be Quick Can be done early in the project

Can be tailored to fit any organization Can be applied at different phases of the life cycle Many models exist to aid organizations in getting started


34/38

COCOMO Issues

Ignores documentation and other requirements No compensation for customer attributes (availability, knowledge,

cooperation) Ignores personnel turnover issues Based on historical data which may be obsolete Used only to estimate the development effort, other phases of the project

(planning, implementation) are not accounted for

Wh i


35/38

What can cause inaccurateestimates?

Scope changes Overlooked tasks Poor developer-

usercommunication

Poor understandingof project goals

Insufficient analysis

No (or poor)methodology

Changes in team

Red tape Lack of project control Not identifying or

understanding impactof risks


36/38

Other Factors to Consider When Estimating

Rate at which requirements may change Experience & capabilities of project team Process or methods used in development Specific activities to be performed

Programming languages or development tools to be used Probable number of bugs or defects & removal methods Environment or ergonomics of work space Geographic separation of team across locations Schedule pressure placed on the team

b


37/38

How can estimates beimproved?

Experience!

Lessons learned Best Practices

Revision Monitor Focus on deliverables Control


38/38

Questions?

Documents

Topic5 Project Estimates