1

Marco Vieira

Departamento de Eng. Informática Universidade de Coimbra mvieira@dei.uc.pt C

MU

/UC

M

SE

CMU|UC Professional Master of Software Engineering

Estimation Techniques in Software Projects

2

Outline

n  The Software Estimation problem n  What is estimation? n  Why estimate? n  When estimate?

n  Process oriented estimation techniques n  The WAG – Wild Altogether Guess n  Estimation by analogy n  Experts judgment n  Wideband Delphi

n  Parametric or algorithmic estimation methods n  Function Points

3

Bad estimation J

http://wiefling.com/wordpress/wp-content/uploads/2008/02/ohcrap10.jpg

4

What is Software Estimation?

n  The American Heritage Dic., 2nd College Edition, 1985: 1. A tentative evaluation or rough calculation 2. A preliminary calculation of the cost of a project 3. A judgment based upon one’s impressions; opinion

n  When someone asks for an “estimate” he is often asking for a commitment or for a plan to meet a target

n  This is wrong!!!

An estimate is a prediction of how long a project will take or how much it will cost

5

Why do we need to estimate?

n  Standish Report (http://www.sdtimes.com/content/article.aspx?ArticleID=30247)

n  Only 35% of the projects can be considered successful n  i.e., on time, on budget, meeting user expectations

n  46% of the projects are considered “challenged” n  i.e., either had costs or schedule overruns or did not fully meet user

needs

n  19% of project never complete n  i.e., canceled or finished but not used

n  We need to improve this scenario!

6

Why are we so bad at estimating?

n  Systems complexity n  Infrequency n  Underestimation bias n  Complexity vs size

n  ~50 000 SLOC in a pace maker n  ~10 000 000 SLOC in OpenOffice.org n  ~40 000 000 SLOC in Windows XP

n  Very fast changes over time n  Requirements, market, people, etc

n  Unrealistic goals n  Must be done by June!

2

7

What do we need to estimate?

n  Size

n  Effort

n  Cost

8

Estimation uncertainty

9

When should we estimate?

n  During the bid n  Short duration n  As fast as possible n  Reduced knowledge about the problem

n  At project Start n  Create a project plan n  Allocate resources n  Detailed estimation

n  During the project n  Handle change

10

Estimate in the bid

n  No “real” money evolved n  But it costs money!!! n  The cost of losing the bid n  The cost of performing the estimation

n  Key issue: n  Compare with available history on other projects

n  Must be performed as quickly and cheaply as possible n  Market do not wait for you n  You are investing in something you are not sure to win

n  How important is it? n  Critical!!! n  Decisive to win the bid n  It defines the money you will have to run the project

11

Decisive during bid…

n  Identify critical requirements n  The ones that really determine the development effort n  Pareto rule (80-20)?

n  Create a rough estimate n  But precise enough!!!

n  Apply history to improve estimates

n  Apply reuse to improve estimates

n  Understand the effort needed to bid on a project

n  To determining the development effort: n  First look for “similarities”… n  … then look for “differences”… n  … and create a conceptual design!

12

Conceptual design

n  The goal is to better understand the problem n  Key requirements n  Draft architecture n  Experiments!

n  Estimate the parts n  Easier than estimate the full piece at once

n  Never confuse conceptual with actual design n  Conceptual design is meant for estimating n  It will be redo if you win the bid

3

13

Estimate before you begin the work

n  More information than during the bid n  Team n  Technology n  Processes n  Requirements n  …

n  The goal is to create a detailed estimate n  The estimation result may be different from the one got in the bid n  Understand why

n  Needed to create a project plan

14

Estimate as you go…

n  Have customers ever changed requirements? n  All the time!

n  Some reasons to revise: n  Correct errors n  Reflect changes in assumptions n  Reflect changes in project scope n  Reflect changes in the project calendar n  Reflect changes in the team n  Respond to changes in the approach taken

to complete an activity n  …

n  The goal: understand where you are!

15

Estimation approaches

n  Process oriented techniques n  Based on a well defined process

n  Parametric or algorithmic methods n  Based on historical data

16

Some process oriented size estimation techniques

n  The WAG – Wild Altogether Guess

n  Estimation by analogy

n  Experts judgment

n  Wideband Delphi

17

WAG - Wild Altogether Guess

n  Extremely useful when dealing with a totally new area

n  No historical data is available

n  No expertise in this new area

n  No experts to contact

n  Research turns up no information

n  The only solution is… n  Guessing! n  But make sure you record everything…

18

Estimation by analogy

n  Identify the “similarity dimensions” n  Based on the software specification

n  Include application type, size of application, language used, etc.

n  Compare with other “similar projects”

n  Small grain estimation n  Do it by considering small pieces of the project

n  Large grain estimation n  Do it by considering large pieces of the project

4

19

Experts judgment

n  Involves consulting with human experts to use their experience and understanding of a project

n  Pay attention to the differences between past projects and the proposed project

n  Pay attention impacts caused by new technologies, applications, and languages

n  Nice complement to other estimation methodologies

n  The estimates are as good as the expertise and judgment of the expert

n  Hard to define and document

20

Wideband Delphi

n  Six step process 1. Planning

n  Define the scope of the problem n  Break large problems into smaller

2. The Kick-off n  Handle the problem to the estimation team

3. Individual preparation n  Individual estimates on problem parts n  All assumptions are written down

4. Estimation Meeting n  Team gets together

5. Assembling Tasks n  Put together the estimates on the several parts

6. Review Results n  Team reviews the final results

21

Wideband Delphi estimation meeting

n  Moderator collects the estimates for the part being estimated n  Estimates are anonymous n  Data is presented as a average or a line with all estimates

n  The estimate is discussed and assumptions are presented

n  Moderator ask for a new estimate

n  Values are again presented to the team and discussed

n  The process end when: n  Four rounds are completed n  The estimates “converged” n  The meeting time is complete n  All participants are unwilling to change their estimates

n  15-20 minutes per item discussed 22

Rounds in Wideband Delphi

X X X X X X X Round #4 X X X X X X X Round #3

X X X X X X X Round #2

10 20 30 40 50 60 70 80 X X X X X X X Round #1

23

Some rules…

n  Use an heterogeneous team n  Different points-of-view are important

n  Write down and discuss assumptions n  Critical!

n  Make anonymous estimates n  Avoids the “follow the boss” approach

n  Never estimate too large tasks n  Be sure the team is comfortable with the granularity of the task

being estimated

24

Parametric or Algorithmic Methods

n  Uses equations to create software estimates

n  Pros: n  Able to generate repeatable results n  Easy to modify input data n  Easy to refine and customize formulas

n  Disadvantages: n  Questionable results when estimating future projects with new

technologies n  Equations are unable to deal with exceptional conditions such as

exceptional teamwork

5

25

Function points

n  Based on the program characteristics n  External inputs n  External outputs n  User interactions n  External interfaces n  Files used

n  A weight is associated to each of these characteristics

n  FP count is modified by the complexity of the project

n  Can be used to estimate LOC based on a language factor n  LOC = AVC * number of function points n  AVC is a well-defined language-dependent factor

n  FPs can be very subjective n  Depend on the estimator

26

Estimate the system size

System Elements and their Complexity Description Low Medium High Total Inputs __x 3 __x 4 __x 6 ____ Outputs __x 4 __x 5 __x 7 ____ Queries __x 3 __x 4 __x 6 ____ Files __x 7 __x 10 __x 15 ____ Program __x 5 __x 7 __x 10 ____ Interfaces

TOTAL UNADJUSTED FUNCTION POINTS ____

27

Compute the technical complexity factor (TCF)

n  Assign a value from 0 to 5 to each of 14 factors n  0 → Not present n  5 → Strong influence

n  Add 14 numbers n  Total degree of influence (DI) n  TCF = 0.65 + 0.01 x DI

n  Technical complexity factor (TCF) lies between 0.65 and 1.35

n  The number of function points (FP) is given by n  FP = UFP x TCF

28

Convert FP to SLOC

Language LOC/Function Code Point

Access C C++ COBOL Excel HTML JAVA Javascript Oracle Perl Powerbuilder SQL VBScript Visual Basic Web Scripts

35 162 66 77 47 47 62 58 30 60 32 40 36 47 44

Source: Quality Software Management (www.qsm.com)

29

Calculate FP…

n  FP = UFP x [0.65 + 0.01 x DI]

n  Total degree of influence? n  Assume a moderately complex product n  DI = 42

n  FP? n  54

n  How may lines of Java Code? n  3348 SLOC

Simple Average ComplexExternal Inputs (EI) 3 x 3 4 6 = 9External Outputs (EO) 2 x 4 5 7 = 8External Inquiries (EI) 2 x 3 4 6 = 6Internal Logical Files (ILF) 1 x 7 10 15 = 7External Interface Files (EIF) 4 x 5 7 10 = 20UFP 50

Weigthting FactorInformation Domain Value Count

Marco Vieira

Departamento de Eng. Informática Universidade de Coimbra mvieira@dei.uc.pt C

MU

/UC

M

SE

Questions/Comments?