agile estimation 3_Мел Росс

Rosso-Llopart ©2013 1

Other Estimation Techniques

Part III

Mel Rosso-Llopart Carnegie Mellon University


Agenda

Other Estimation on estimation − Techniques − Exercises on estimation

Improving your Estimates − Case study – Estimation as a tool

Wrapup


D2-L2

© GIMETO, LLC

3

Session Objectives

Define what an estimate is one more time Definitions have been given to give perspective on how

many ways an estimate can viewed Define what metrics are and what metrics are

appropriate for software projects to improve future estimates

Cover what we have discussed make good estimates for software projects


D2-L2

© GIMETO, LLC

4

What is an estimate?

Estimate noun [C] “an approximate calculation or judgement of the size, value, amount, cost, etc. of something” Cambridge Dictionary

So how do we improve our approximations?

Historical Data of course


D2-L2

© GIMETO, LLC

5

How You Can Tell A Good Estimation Technique You can teach it You can use it in all phases of your work You can use it on all components You can use statistical evaluation of its results You can extend it into the future You can evaluate its accuracy


Estimate uncertainty

x

2x

4x

0.5x

0.25x

Feasibility Requirements Design Code Delivery


Inputs and Outputs to the Estimation Process

Classical view of software estimation process [Vigder/Kark]

Cost Estimation Process

Effort

Cost

Schedule

Size Estimator

Size Product Specs

Complexity Constraints Personnel Skill Environment

Size Drivers

Project Estimate

COST DRIVERS


Productivity

The output-input ratio within a time period with due consideration for quality.

Standard Productivity = outputs/inputs Software Productivity Process Productivity = (Size in SLOC) / (Effort)^(1/3)

x (Time)^(4/3)*

* Larry Putnam, QVC


Why is this important?

1) Time is part of the productivity relationship. 2) Time is a very important part with the exponents saying it

has four times the weight of Effort. So the longer it takes the more impact on productivity. Is this a good or bad impact?


Basic estimation process

First figure out what are the similarities Then look for differences

− Use these to determine the effort needed

Does effort equal progress? Amount of time invested

equal progress?


First look for “similarities” Have we done something similar Do we have data on that project How long ago was it

− Geometric loss of understanding

Do we still have the expertise − Expertise does not last

Do we have the artifacts from that project − Can we read them


Next look for “differences”

Do we understand the differences Do we have expertise in this new area

− Training cost time and money − Can we get the expertise quickly

Do we have a proxy for this difference − Have we done something similar on other projects


Function points Function point count modified by complexity of the project FPs can be used to estimate LOC depending on a language factor LOC = AVC * number of function points AVC is a language-dependent factor FPs can be very subjective, depend on estimator Automatic function-point counting maybe impossible


Function Point Estimation Step One – 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 ____


Function Point Basics Count the following: inputs outputs inquiries – Get info only logical internal files – Save state external interfaces Apply “simple, average, complex” multipliers (Low, Medium, High) Apply the 14 adjustment factors (such as designed for reuse? in a heavy traffic environment? etc.)


Function Points (14 factors)

Compute the technical complexity factor (TCF) Assign a value from 0 (“not

present”) to 5 (“strong influence throughout”) to each of 14 factors such as transaction rates, portability

Add 14 numbers ⇒ total degree of influence (DI)

TCF = 0.65 + 0.01 × DI

Technical complexity factor (TCF) lies between 0.65 and 1.35

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


Converting Function Points to Lines of Code

Source: Quality Software Management (http://www.qsm.com/FPGearing.html)

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


Function Points

FP are dimensionless numbers FP can have multiple uses as metrics: pages/FP defects/FP Cost/FP LOC/FP


The Downside of Function Points Difficult to be consistent across the set of counters Does not reflect internal complexity very well Adjustments needed Symons on complexity1 Reifer for real-time systems2 Must be converted to LOC; database needed for each language (Organizational) There is hope: IFPUG – Release of counting standard, but you must be member

1 - Reifer, Donald J., Asset-R IFPUG Spring Conference, Baltimore, Maryland, April, 1991. 2 - Symons, Charles R., Mark II Function Points IEEE Transactions on Software Engineering, Vol. SE-14, no. 1, January 1988


Algorithmic code modelling A formulaic approach based on historical cost information and which is generally based on the size of the software Examples are: Putnam’s Software Life-cycle Model (SLIM) COCOMO COCOMO II Advantages: Its results are repeatable Objectiveness

Disadvantages: Some subjective input is needed


Putnam’s Software LIfe-cycle Model (SLIM) Putnam used Software and

manpower-build Equation This method makes use of

a so-called Rayleigh curve to estimate project effort, schedule and defect rate

Supported by Quantitative Software Management (QSM)

www.qsm.com

D1-L3

© GIMETO, LLC

22 Most Common Size Estimation

Techniques The WAG Estimation by analogy Small Grain and Large Grain

“All analogy methods require a local, idiosyncratic, database”

Expert experience

D1-L3

© GIMETO, LLC

23

WAG - Wild Altogether Guess

Totally new environment No historical data No expertise in this area No experts to contact Research turns up no information …Guess, but make sure you record this

D1-L3

© GIMETO, LLC

24

Estimation by analogy

The method: The project manager identifies the

values of certain “similarity dimensions” dimensions are derived from the software

specification include application type, size of application,

language used, etc. The project manager compares with

other “similar projects” for a final estimate

D1-L3

© GIMETO, LLC

25

Estimation by analogy (2)

Advantages Data is derived in an easily understandable way Complex domain-knowledge is not required, since

information depends on historical data Avoids problems commonly associated with

knowledge elicitation (i.e. erroneous estimation) Can be applied at a very early stage in production

D1-L3

© GIMETO, LLC

26

Estimation by analogy (3) Disadvantages You need a historical database that contains a large

variety of past projects The accuracy of this method is directly related to

the size and quality of the database available There is generally no guarantee that the historical

information about any specific project is completely accurate

Any inaccuracies contained in the historical data will have an effect on the estimation for the current project

D1-L3

© GIMETO, LLC

27

Experts judgment Expert judgment involves consulting with human experts

to use their experience and understanding of a proposed project to provide an estimate for the cost of the project. The expert can factor in differences between past

project experiences and requirements of the proposed project

The expert can also factor in project impacts caused by new technologies, applications, and languages

Expert judgment always compliments other estimation methodologies

the estimates are no better than the expertise and judgment of the expert (hard to document)

D1-L3

© GIMETO, LLC

28 Parametric Or Algorithmic Methods

The algorithmic method uses equations to create software estimates

Advantages: being able to generate repeatable results easily modifying input data easily refining and customizing formulas understanding of the estimating methods as

formulas can be analyzed

D1-L3

© GIMETO, LLC

29

Technique comparison

May overlook system level costs

Requires more effort

More detailed basis More stable Fosters individual commitments

Bottom-up

Less detailed basis Less stable

System level focus Efficient

Top-down

Generally produces large overruns.

Often gets the contract Price to win

Reinforces poor practice Correlates with some experience Parkinson’s Law

Level of experience Based on representative experience Analogy

No better than participants Biases, incomplete recall

Assessment of representative, interactions, exceptional circumstance

Expert judgment

Subjective inputs Assessment of exceptional

circumstances Calibrated to past, not future

Objective, repeatable, analyzable formula

Efficient, good for sensitivity analysis Objectively calibrated to experience

Algorithmic Model

Weakness Strengths Method


Case Study Discussion

Estimation as a Tool


Discussion Questions What are the major decisions that the manager

must make to help him with his estimation problem?

What would you have done differently if you were in the manager’s place?

What estimation techniques from the case can you identify that are being used?

What information about estimation did you gather that you did not already know?


Questions? Comments?


Improving your Estimation Techniques

Mel Rosso-Llopart Carnegie Mellon University


D2-L2

© GIMETO, LLC

34

As a reminder, an estimate is:

Estimate noun [C] “an approximate calculation or judgement of the size, value, amount, cost, etc. of something” Cambridge Dictionary

So how do we improve our approximations?

Historical Data of course…and therefore metrics.


Agenda

Metrics and Estimation Cost estimation revisited Process maturity


D2-L2

© GIMETO, LLC

36

Metrics and Estimation

As you decide on your estimation process Remember you need data for it You need to be able to teach it You need everyone to understand it

Or it will fail to be used and improve what you do


D2-L2

© GIMETO, LLC

37

Scope of Software Metrics

Software Metrics have two main fields of application: Measure/assessment of a software product

or process e.g. a baseline – where are we now

Estimation of critical features involved in a software project (e.g. a future estimate) …And the reason why we are looking at this topic


D2-L2

© GIMETO, LLC

38

Software Product/Process Measurement

An integral part of the Project Plan Aims to provide data which can be used to better

evaluate (control) the production of software “You cannot control what you cannot measure” Tom de Marco (1982)


D2-L2

© GIMETO, LLC

39

The Need for Software Metrics

Software Production suffers from Excessive Costs Low Productivity Poor Quality Lack of Standards, Professionalism Poor estimates of when, what and how much


D2-L2

© GIMETO, LLC

40

The Need for Software Metrics.... Software production suffers...because we

fail to: Set measurable targets Measure the ‘real’ costs in projects Quantify the quality

Understand when it is “good enough” Properly evaluate new tools and techniques Use our own estimates


Cost Estimation Process (Revisited)


Effort

Cost

Schedule

Size Estimator

Size Product Specs

Complexity Constraints Personnel Skill Environment

Size Drivers

Historical Data

Project Estimate

Project Actuals


D2-L2

© GIMETO, LLC

42


To estimate the Cost of a system We can better know the cost if we know the size

of the system Typical size measures are: LOC – Lines of Code FP – Function Points


D2-L2

© GIMETO, LLC

43

Software Size and Complexity Estimating/Measuring Software Size Measures must be:

Useful for planning Precise Automatically countable

Estimate must be: Available early in the life-cycle

Estimation of Effort Requires system complexity understanding

For example: COCOMO II


D2-L2

© GIMETO, LLC

44

Software Metrics & Process Maturity

Critical activities for a mature process Set goals Measure progress Evaluate whether the goals have been met

Metrics provide input for planning measure the developed product measure the development process


D2-L2

© GIMETO, LLC

45

Define

Appropriate metrics for your group Keep in mind that data collection costs money Rule of thumb < 3% of project cost

Create a place to save data properly Make it a habit to use data early and often in

projects “Take care of schedule and budget will take

care of itself” Adtranz project binder cover


D2-L2

© GIMETO, LLC

46

Summary

You should be able to define what metrics are appropriate for software projects to improve future estimates

Understand the need for estimates at many times during the software development projects


Wrap Up

Software Estimation Concepts (Agile) Other Estimation techniques Improving your estimation


Software Estimation Concepts Summary

What an estimate is and what it is not. The basic estimation techniques for Agile

− Planning poker − Time boxing

How to use the estimation data Concept of relative size estimation


Other Estimation Techniques Summary

Function points – Father of many techniques − Use case Points − Object points

None unit based estimation Analogy estimation Expert Judgement Algorithmic modeling

− Cocomo, Slim, others


Improving your estimation Summary

Using metrics and historical data to improve estimation

What are good metrics What do you look for in estimation techniques Who should the data be for


References

Mike Cohn, “Agile Estimation and Planning”, Prentice Hall, 2006.

Watts Humphrey, “Introduction to the Personal Software Process”, Addison-Wesley, 1997.

Steve McConnell, “Software Estimation Demystifying the Black Art”, Microsoft press, 2006.

agile estimation 3_Мел Росс

Technology

impossible rossollopart

qvc rossollopart

accuracy rossollopart

software projectsrossollopart

ufp tcfrossollopart

function point estimation

number of function points

number of function points