CSE Senior Design ICSE Senior Design I

Your Plan: EstimationYour Plan: Estimation

Instructor: Manfred HuberInstructor: Manfred Huber

This presentations was derived from the textbook used for this class, McConnell, This presentations was derived from the textbook used for this class, McConnell, Steve, Steve, Rapid DevelopmentRapid Development, Chapter 8, further expanded on by Mike O’Dell and Mr. , Chapter 8, further expanded on by Mike O’Dell and Mr.

Tom Rethard for this course.Tom Rethard for this course.

3

2

Estimations and SchedulingEstimations and Scheduling

Discussion: Case Study 8.1 (pp. 164-165) Has this ever happened to you (work/school)? What was the underlying problem? What should Carl have done?

Estimating the job by: Seat of the pants, or A proven, rational process?

3

3

OverviewOverview

The Software-Estimation Story (Synopsis)Estimation-Process OverviewSize EstimationEffort EstimationSchedule EstimationBallpark Schedule EstimatesEstimate Refinement

3

4

The Software Estimation StoryThe Software Estimation Story**

Software/System development, and thus estimation, is a process of gradual refinement.

Can you build a 3-bedroom house for $100,000? (Answer: It depends!)

Some organizations want cost estimates to within ± 10% before they’ll fund work on requirements definition. (Is this possible?)

Present your estimate as a rangerange instead of a “single point in time” estimate.

The tendency of most developers is to under-estimate and over-commit!

* Copyright 2007, Chris Weber, The DSW Group Ltd.

3

5

Estimate-Convergence GraphEstimate-Convergence Graph

Initialproduct

definition

Approvedproduct

definition

Requirementsspecification

Architecturedesign

specification

Detaileddesign

specification

Productcomplete

1.0

0.25

4

2

0.5

1.5

0.67

1.25

0.81.0

0.6

1.6

1.25

0.8

1.15

0.85

1.1

0.9

Project Cost(effort and size) Project

Schedule

High Estimate

High Estimate

Low Estimate

Low Estimate

Actual CostActual Cost

3

6

Estimation vs. ControlEstimation vs. Control

Initially, customers want morecustomers want more than they can afford, somethingsomething’’s gotta gives gotta give…

Pro

duct

Siz

e/F

eatu

res

Evolution of Project(fixed resources)

Initially availableresources

Initially desiredfeature set

Features

Resources

Evolution of Project(fixed requirements)

Initially availableresources

Initially desiredfeature set Features

Resources

Developers and customers must choose between estimation accuracy and project control.

Pro

duct

Siz

e/F

eatu

res

3

7

Cooperation, Cooperation, RefinementRefinement Explain to stakeholders that you will have better better

estimatesestimates at each project milestone. You can’t estimate what you don’t know.

ActualSchedule

Estimated Schedule

Minimum actual schedule

Actual schedule = Estimated Schedule

Estimate too high:costs higher due

to Parkinson’s law

Estimate too low:

costs higher dueto planning

inefficiencies andmistakes

Estimate Estimate ConvergenceConvergence

3

8

Estimation-Process OverviewEstimation-Process Overview

Step 1: Estimate the sizesize of the product (lines of code or function points)

Step 2: Estimate the efforteffort (man-months)

Step 3: Estimate the scheduleschedule(calendar months)

Step 4 (Meta-Step): Provide estimates in ranges and periodically (periodically (frequentlyfrequently) refine) refine the ranges to provide increasing precision as the project progresses

3

9

Size EstimationSize Estimation

Use an algorithmic approach, that estimates a program’s size from its features

Use size-estimation softwareCompare to similar projects in your

organization, by pieces.Software programs and algorithmic

approaches should be calibrated to your environment.

3

10

Estimation tipsEstimation tips

Avoid off-the-cuff Avoid off-the-cuff estimates Allow time for the estimate (do it right!) Use data from previous projects Use developer-based estimates Estimate by walk-through Estimate by categories Estimate at a low-level of detail Don’t forget/omit common tasks Use software estimation tools Use several different techniques, and compare the results Evolve estimation practices as the project progresses

3

11

Function-Point EstimationFunction-Point EstimationBased on number of

Inputs(screens, dialogs, controls, messages)

Outputs(screens, reports, graphs, messages)

Inquiries(I/O resulting in a simple, immediate output)

Logical internal files(Major logical groups of end-user data, controlled by program)

External interface files(Files controlled by other programs that this program uses. Includes logical data that enters/leaves program)

3

12

Function-Point MultipliersFunction-Point MultipliersFunction Points

Program Low Medium HighCharacteristic Complexity Complexity ComplexityNumber of inputs 3 4 6Number of outputs 4 5 7Inquiries 3 4 6Logical internal files 7 10 15External interface files 5 7 10

Sum these to get an “unadjusted function-point total”

Multiply this by an “influence multiplier” (0.65 to 1.35),based on 14 factors from data communication to ease ofinstallation.

All of this gives a total function-point count.Use this with Jones’ First-Order Estimation Practice, orcompare to previous projects for an estimate

3 Jones First-Order Estimate: Jones First-Order Estimate: Influence Multipliers Influence Multipliers

General System General System Characteristic Characteristic Brief DescriptionBrief Description

1. Data communications How many communication facilities are there to aid in the transfer or exchange of information with the application or system?

2. Distributed data processing

How are distributed data and processing functions handled?

3. Performance Was response time or throughput required by the user?

4. Heavily used configuration How heavily used is the current hardware platform where the application will be executed?

5. Transaction rate How frequently are transactions executed daily, weekly, monthly, etc.?

6. On-Line data entry What percentage of the information is entered On-Line?

7. End-user efficiency Was the application designed for end-user efficiency?

8. On-Line update How many ILF’s are updated by On-Line transaction?

9. Complex processing Does the application have extensive logical or mathematical processing?

10. Reusability Was the application developed to meet one or many user’s needs?

11. Installation ease How difficult is conversion and installation?

12. Operational ease How effective and/or automated are start-up, back-up, and recovery procedures?

13. Multiple sites Was the application specifically designed, developed, and supported to be installed at multiple sites for multiple organizations?

14. Facilitate change Was the application specifically designed, developed, and supported to facilitate change?

13

3

14

Effort EstimationEffort Estimation

Use estimation software to create an effort estimate directly from size estimate

Use McConnell’s schedule tables (Tables 8-8 through 8-10)

Use your organization's historical dataUse algorithmic approach (COCOMO,

Putnam)

3

15

Schedule EstimationSchedule Estimation

Rule-of-thumb equation schedule in months = 3.0 * man-months 1/3

This equation implies an optimal team size. Use estimation software to compute the schedule from

your size and effort estimates Use historical data from your organization Use McConnell’s Tables 8-8 through 8-10 to look up a

schedule estimate based on the size estimate Use the schedule estimation step from one of the

algorithmic approaches (e.g., COCOMO) to get a more fine tunes estimate than the “Rule of thumb” equation.

3

16

JonesJones’’ First-Order Estimation First-Order Estimation

Kind of Software Best in Class Average Worst in Class

Systems 0.43 0.45 0.48

Business 0.41 0.43 0.46

Shrink-wrap 0.39 0.42 0.45

Take the function-point total and raise it to the appropriate power.Example:

350 function pointsaverage shrink-wrap development organization

3500.42 12 calendar months

This method works well for quick reality checks. (No magic!)

Organization’s Skills/Abilities

3

17

Ballpark Schedule EstimatesBallpark Schedule Estimates Usable, concrete information is either:

embedded in expensive software-estimation systems in books with dozens of equations and multipliers

McConnell’s tables tables describe systems software business software shrink-wrap software

Size in lines of codelines of code Accuracy of McConnell’s tables… better than seat

of the pants, but should be validated.

3

18

Shortest Possible ScheduleShortest Possible Schedule

Probability ofCompleting

Exactly on theScheduled Date

Scheduled Completion Date

Shortestpossible

schedule

Impossible schedule

• This tables assumes:- Top 10% of talent pool, all motivated, no turnover- entire staff starts working on Day 1, & continue until project released- advanced tools available to everyone- most time-efficient development methods used- requirements completely known, and do not change

Table 8.8Table 8.8High Risk of late High Risk of late

completion.completion.

3

19

Efficient Schedules (Table 8-9)Efficient Schedules (Table 8-9)

This table assumes: Top 25% of talent pool Turnover < 6% per year No significant personnel conflicts Using efficient development practices from Chap 1-5 Note that less effort required on efficient schedule tables

For most projects, the efficient schedules represent “best-case”

3

20

Nominal Schedules (Table 8-10)Nominal Schedules (Table 8-10)

This table assumes: Top 50% of talent pool Turnover 10-12% per year Risk-management less than ideal Office environment only adequate Sporadic use of efficient development practices

Achieving nominal schedule may be a 50/50 bet.

3

21

Estimate Presentation StylesEstimate Presentation Styles

Plus-or-minus qualifiers“6 months, +3 months, -2

months” Ranges

“5-9 months” Risk quantification

“6 months...+1 month for late subcontractor,+0.5 month for staff sickness,etc...”

CasesBest case April 1Planned case May 15Current case May 30Worst case July

15

Coarse dates and time periods“3rd quarter 97”

Confidence factorsApril 1 5%

May 15 50%

July 1 95%

3

22

Schedule Estimation - ExampleSchedule Estimation - Example Software Project Size and Productivity ApproachSoftware Project Size and Productivity Approach

Low Side High Side(Aggressive) (Conservative)

Size Estimate 10000 LOC 30000 LOC

Productivity 400 LOC/PM 200 LOC/PM

Effort 25 PM 150 PM

Duration 5 months 30 months(5 person team)

McConnell Table 8-10 (p. 196), Nominal Schedule, System ProductMcConnell Table 8-10 (p. 196), Nominal Schedule, System Product

Duration 10 months 16 months

3

23

Schedule Estimation - ExampleSchedule Estimation - Example Rule of Thumb (Duration = 3 x PMRule of Thumb (Duration = 3 x PM1/31/3))

Low Side High Side(Aggressive) (Conservative)

3 x 251/3 = 3 x 1501/3 =Duration 8.8 (9) months 15.9 (16) months

# FnPts

Inputs 10 40

Outputs 5 25

Inquiries 10 40

Logical Int. Files 3030

Logical Ext. Files 214

149(unadj.)

Use Influence Multiplier of 1.2

Therefore:

1.2 x 149 180 adjusted fn points

Assuming Nominal Skills, System Product, Jones’s First Order says:

Duration = 180.45 = 10.35 months

Function Points, with JonesFunction Points, with Jones’’s First Order Schedule Estimation (Medium s First Order Schedule Estimation (Medium complexity project – Table 8-2)complexity project – Table 8-2)

3

24

Schedule Estimation - ExampleSchedule Estimation - Example

Basic CoCoMoBasic CoCoMo8181 Estimation Coefficients, based on project Estimation Coefficients, based on project type/complexity:type/complexity:

CoCoMoCoCoMo8181 – nominal, semi-detached – nominal, semi-detachedLow Side High Side(Aggressive) (Conservative)

Effort - PM E = 3.0(10)1.12 E = 3.0(30)1.12

E = a(SLOC)b = 68.45 PM = 135.36 PM

Duration – months E = 2.5(69).35 E = 2.5(136).35

D = c(E)d = 11 months = 14 months

Coefficient a b c d

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

Embedded 3.6 1.20 2.5 0.32

Note: Also try CoCoMo-II

3

25

Schedule Estimation - ExampleSchedule Estimation - Example

ComparingComparingAggressive Conservative

Size and Productivity 5 months 30 months

McConnell Tables 10 months 16 months

Rule of Thumb 9 months 16 months

CoCoMo 11 months 14 months

Function Points/Jones’s 10.35 months

Sanity Test (Weiss & Wysocki, 1992)Sanity Test (Weiss & Wysocki, 1992)

E = (O + 4M + P) / 6, where O = optimistic, M = Nominal, P = Pessimistic

Therefore, our E = (5 + 44 + 30) / 6 = 79/6 = 13.17 (14) months

3

26

Schedule Estimation - ExampleSchedule Estimation - Example

Simplified Hybrid ApproachSimplified Hybrid Approach

1. Estimate sizesize using Adjusted Function Point total and

Source Lines-Of-Code per Function Point

2. Estimate efforteffort using Simplified CoCoMo (1.4 x KSLOC)

3. Estimate timetime to completion using Rule-of-Thumb

3

27

Schedule Estimation - ExampleSchedule Estimation - Example

Lines-of-Code per Function Point*Lines-of-Code per Function Point*

*Source: Capers Jones, Software Productivity Research

Language Approximate LOC/Function Point

C 130

Java 55

C++ 50

Visual Basic 30

Power Builder 15

HTML 15

Package, e.g. Excel, Access, …

10-40

3

28

Schedule Estimation - ExampleSchedule Estimation - Example

Our ExampleOur Example

Size: Size: Adjusted Function Points x SLOC/Function Point, Adjusted Function Points x SLOC/Function Point, assuming C++assuming C++

180 x 50 = 9000 SLOC180 x 50 = 9000 SLOC

Effort:Effort: 1.4 x KSLOC = 1.4 x 9 = 13.5 1.4 x KSLOC = 1.4 x 9 = 13.5

Time:Time: 3.0 x 13.5 3.0 x 13.51/3 1/3 = 7.14 months= 7.14 months

3

29

Estimate RefinementEstimate Refinement

Estimate can be refined only with a more refined definition of the software product

Developers often let themselves get trapped by a “single-point” estimate, and are held to it (Case study 8-1) Impression of a slip over budget is created when

the estimate increasesWhen estimate ranges decrease as the project

progresses, customer confidence is built-up.

3

30

Estimate RefinementEstimate Refinement

Discussion: Case Study 8-2 Contrast this with Case Study 8-1 What was done right, up front How often, and when was the estimate refined? What was the result?

3 RecommendationsRecommendations

Do not depend on a single cost or schedule estimate.

Use several Use several estimating techniques or cost models, comparecompare the results, and determine the reasons for any large variations.

Document the assumptions Document the assumptions made when making the estimates.

MonitorMonitor the project to detect when assumptions that turn out to be wrong jeopardize the accuracy of the estimate.

Maintain a historical databasehistorical database

31

3

32

ConclusionsConclusions

Estimate accuracy is directly proportionaldirectly proportional to product definition. Before requirements specification, product is very vaguely

defined More effort, variety of approaches/methodsMore effort, variety of approaches/methods used in

estimating = better estimates. Use rangesUse ranges for estimates and gradually refine

(tighten) them as the project progresses. Measure progress and compareMeasure progress and compare to your historical

data Refine… Refine… RefineRefine… Refine… Refine!!!