1
Marco Vieira
Departamento de Eng. Informática Universidade de Coimbra [email protected] 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 [email protected] C
MU
/UC
M
SE
Questions/Comments?