Lecture 9 & 10 - Effort Estimation

8/17/2019 Lecture 9 & 10 - Effort Estimation

1/41

Software EortEstimationLecture 9 & 10


2/41

S E G 3 3 0 0 A & B W 2 0

0 4

R . L .

r o ! e r

t

2


3/41

What makes a successful

project?Delivering:

• agreed functionality

• on time

• at the agreed cost

• with the required quality

Stages:

1 set targets

! "ttempt to achieve targets

#$% what if the targets are not achieva&le?


4/41

Some pro&lems with estimating

• Su&jective nature of much of estimating• 't may &e difficult to produce evidence to support your precise

target

• (olitical pressures

• )anagers may wish to reduce estimated costs in order to win

support for acceptance of a project proposal• *hanging technologies

• these &ring uncertainties+ especially in the early days when thereis a ,learning curve-

• (rojects differ

• ./perience on one project may not &e applica&le to another


5/41

0ver and underestimating

• (arkinson-s 2aw: ,Work e/pands to fill the time availa&le-• "n overestimate is likely to cause project to take longer

than it would otherwise

• Wein&erg-s 3eroth 2aw of relia&ility: ,a software project

that does not have to meet a relia&ility requirement can

meet any other requirement-


6/41

#asis for successful

estimating• 'nformation a&out past projects

• 4eed to collect performance details a&out past project: how

&ig were they? 5ow much effort6time did they need?

• 4eed to &e a&le to measure the amount of work involved

• %raditional si7e measurement for software is ,lines of code- 8 &ut this can have pro&lems


7/41

" ta/onomy of estimating

methods• #ottomup activity &ased+ analytical

• (arametric or algorithmic models eg function points

• ./pert opinion just guessing?

• "nalogy case&ased+ comparative

• (arkinson and ,price to win-


8/41

(arameters to &e .stimated

• Si7e is a fundamental measure of work

• #ased on the estimated si7e+ two parameters are

estimated:

• .ffort

• Duration

• .ffort is measured in personmonths:

• 0ne personmonth is the effort an individual can typically

put in a month


9/41

)easure of Work

• %he project si7e is a measure of the pro&lem comple/ity

in terms of the effort and time required to develop the

product

• %wo metrics are used to measure project si7e:

• Source 2ines of *ode 9S20*• ;unction point 9;(

• ;( is nowadays favoured over S20*:

• #ecause of the many shortcomings of S20*


10/41

)ajor Shortcomings of S20*

• Difficult to estimate at start of a project

• 0nly a code measure

• (rogrammerdependent

• Does not consider code comple/ity


11/41

#ottomup versus topdown

• #ottomup

• use when no past project data

• identify all tasks that have to &e done 8 so quite timeconsuming

• use when you have no data a&out similar past projects

• %opdown

• produce overall estimate &ased on project cost drivers

• &ased on past project data

• divide overall estimate &etween jo&s to &e done


12/41

#ottomup estimating

1 #reak project into smaller and smaller components

! Stop when you get to what one person can do in

one6two weeks 8 it depends on si7e of the project 8 ;or

agile projects &ring it to one day or even in hours


13/41

%opdown estimates

• (roduce overallestimate using effort

driver9s

• distri&ute proportions

of overall estimate to

components

"esi#n co"e

o$era%% ro'ect

test

.stimate

1>> days

ie

days

ie

days

=>

ie => days


14/41

"lgorithmic6(arametric

models• *0*0)0 9lines of code and function points e/amples of

these

• (ro&lem with *0*0)0 etc:

#uess a%#orit(m estimate

&ut what is desirediss)stem

c(aracteristica%#orit(m estimate


15/41

(arametric models the need

for historical data• simplistic model for an estimate

estimated effort @ 9system si7e 6 productivity

• eg

system si7e @ lines of code

productivity @ lines of code per day

• productivity @ 9system si7e 6 effort

• &ased on past projects


16/41

Parametric models

Some mo"e%s focus on tas* or s)stem si+e e.#.

,unction oints,s ori#ina%%) use" to estimate Lines of -o"erat(er t(an eort

mo"e%

4um&erof file types

4um&ers of input

and output transaction types

,system

si7e-


17/41

(arametric models

• 0ther models focus on productivity: eg *0*0)0• 2ines of code 9or ;(s etc an input

Systemsi7e

(roductivity

factors

.stimated effort


18/41

./pert judgement

• "sking someone who is familiar with and knowledgea&le

a&out the application area and the technologies to

provide an estimate

• (articularly appropriate where e/isting code is to &e

modified• Aesearch shows that e/perts judgement in practice

tends to &e &ased on analogy


19/41

.stimating &y analogy

source cases

attri&ute values

effort

attri&ute values ?????target case

attri&ute values

attri&ute values

attri&ute values

attri&ute values

attri&ute values

effort

effort

effort

effort

effort Select case

with closet attribute

values

Use effort

from source as

estimate


20/41

Stages: identify

• Significant features of the current project

• previous project9s with similar features

• differences &etween the current and previous projects

• possi&le reasons for error 9risk

• measures to reduce uncertainty


21/41

)achine assistance for

source selection 9"4B.2

4 u

m & e r o f

i n p

u t s

4um&er of outputs

target

Source "

Source #

.uclidean distance @ sq root 99't 's! C 90t 0s

!

't's

0t0s


22/41

(arametric models

We are now looking more closely at four parametric models:

1. Albrecht/IFPUG function points

! Symons6)ark '' function points


23/41

"l&recht6';($B function

points• "l&recht worked at '#) and needed a way of measuring

the relative productivity of different programminglanguages

• 4eeded some way of measuring the si7e of anapplication without counting lines of code

• 'dentified five types of component or functionality in aninformation system

• *ounted occurrences of each type of functionality inorder to get an indication of the si7e of an information

system


24/41

"l&recht6';($B function points continued

;ive function types

1 2ogical interface file 92'; types 8 equates roughly to adatastore in systems analysis terms *reated and accessed&y the target system

! ./ternal interface file types 9.'; 8 where data is retrieved

from a datastore which is actually maintained &y a differentapplication


25/41

"l&recht comple/ity multipliers

./ternal user

types

2ow

comple/ity

)edium

comple/ity

5igh comple/ity

.' < = F

.0 = G

.E < = F

2'; G 1> 1

.'; G 1>


26/41

./amples

Pa$roll application has%

1. &ransaction to input' a(en an elete e(plo$eeetails ) an *I that is rate of (eiu( co(ple+it$

,. A transaction that calculates pa$ etails fro( ti(esheetata that is input ) an *I of high co(ple+it$

-. A transaction of (eiu( co(ple+it$ that prints out pa$toate etails for each e(plo$ee ) *O

4. A file of pa$roll etails for each e(plo$ee ) assesse asof (eiu( co(ple+it$ IF

0. A personnel file (aintaine b$ another s$ste( is

accesse for na(e an aress etails ) a si(ple *IFhat 2oul be the FP counts for these3


27/41

;( counts

1 )edium .' = ;(s

! 5igh comple/ity .' F ;(s


28/41

*0*0)0H1

• #ased on industry productivity standards data&ase isconstantly updated

• "llows an organi7ation to &enchmark its softwaredevelopment productivity

• asic (oel

effort 5 c + si6e7

• * and k depend on the type of system: organic+ semidetached+ em&edded

• Si7e is measured in ,kloc- ie %housands of lines of code


29/41

*0*0)0H1

• 0rganic• Small teams

• ;le/i&le layout requirements

• ;amiliar inhouse development environment

• .m&edded )ode

• %ight constraints• *hanges to the system are costly

• Semidetached• *om&ination of organic and em&edded modes


30/41

%he *0*0)0 constants

$ste( t$pe c 7

0rganic 9&roadly+information systems

!= 1>

Semidetached 11!

.m&edded 9&roadly+ realtime

k e/ponentiation 8 ,to the power ofI-adds disproportionately more effort to the larger projects

takes account of &igger management overheads


31/41

Development effort multipliers 9dem

"ccording to *0*0)0+ the major productivity drivers include:

Prouct attributes% required relia&ility+ data&ase si7e+ productcomple/ity

Co(puter attributes% e/ecution time constraints+ storage constraints+virtual machine 9J) volatility

Personnel attributes% analyst capa&ility+ application e/perience+ J)e/perience+ programming language e/perience

Pro9ect attributes% modern programming practices+ software tools+schedule constraints


32/41

$sing *0*0)0 development effort

multipliers 9dem

"n e/ample: for analyst capa&ility:

• "ssess capa&ility as very low+ low+ nominal+ high or very high

• ./tract multiplier:

very low 1=F

low 11Knominal 1>>

high 0.80

very high >G1

• "djust nominal estimate eg H> @ !FH staff months


33/41

*0*0)0 '' "n updated version of *0*0)0:

• %here are different *0*0)0 '' models for estimating at the

,early design- stage and the ,post architecture- stage when the

final system is implemented We-ll look specifically at the first

• %he core model is:

pm @ "9si7e9sf /em1 /em2 /em3I.

w(ere pm erson mont(s A is 2.94 size is num!erof t(ousan"s of %ines of co"e sf is t(e sca%e factoran" em is an eort mu%ti%ier


34/41

*0*0)0 '' Scale factor #ased on five factors which appear to &e particularly sensitive to

system si7e1 (recedentedness 9(A.* Degree to which there are past

e/amples that can &e consulted

! Development fle/i&ility 9;2.L Degree of fle/i&ility thate/ists when implementing the project


35/41

*0*0)0 '' Scale factorvalues

Driver Jery low 2ow 4om

inal

5igh Jery

high

./tra

high

(A.* F!> =KF >>

;2.L >G => = !>< 1>1 >>>

A.S2 G>G F =!= !H< 1=1 >>>

%.") =H =>>

()"% GH> F!= =FH >>


36/41

./ample of scale factor

• " software development team is developing an applicationwhich is very similar to previous ones it has developed

• " very precise software engineering document lays down verystrict requirements (A.* is very high 9score 1!=

• ;2.L is very low 9score >G

• %he good news is that these tight requirements are unlikely tochange 9A.S2 is high with a score !H


37/41

Scale factor calculation

%he formula for sf is

sf @ # C >>1 / M scale factor values

ie sf @ >K1 C >>1

N 91!= C >G C !H< C !1K C F!=

@ 1>HG'f system contained 1> kloc then estimate would &e !K= /

1>1>HG @


38/41

.ffort multipliers

"s well as the scale factor effort multipliers are alsoassessed:

A*(L (roduct relia&ility and comple/ity

A$S. Aeuse required

(D'; (latform difficulty(.AS (ersonnel capa&ility

;*'2 ;acilities availa&le

S*.D Schedule pressure


39/41

.ffort multipliers

./tra low Jery low 2ow 4ominal 5igh Jery high ./trahigh

A*(L >=K >F> >H< 1>> 1K 1>> 1>G 11 1!=

(D'; >HG 1>> 1!K 1H1 !F1

(.AS !1! 1F! 1!F 1>> >H< >F< >>

(A.L 1K 1> >HG >G= >F!

;*'2 1=< 1 11> 1>> >HG >G< >F!

S*.D 1=< 11= 1>> 1>> 1>>


40/41

./ample

• Say that a new project is similar in most characteristics to those thatan organi7ation has &een dealing for some time

• e+cept

• the software to &e produced is e/ceptionally comple/ and will &eused in a safety critical system

• %he software will interface with a new operating system that iscurrently in &eta status

• %o deal with this the team allocated to the jo& are regarded ase/ceptionally good+ &ut do not have a lot of e/perience on thistype of software


41/41

./ample continued

A*(L very high 1K1

(D'; very high 1H1

(.AS e/tra high >>

(A.L nominal 1>>

"ll other factors are nominalSay estimate is

Documents

Lecture 9 & 10 - Effort Estimation