5. Measurement n Estimation I

8/9/2019 5. Measurement n Estimation I

1/43

Measurement and Estimation

Measurement andEstimation I

MCS8301 - Software EngineeringManagement

1


2/43

Software Cost Estimation

Estimating Software Cost and Effort

Objectives:

aspect of Software

Includes cost, effort, and size, and indirectlyschedule


MCS8301 - Software EngineeringMana ement

2

ows t e re at on etween t e a ove ent t es


3/43

Purpose of Cost estimation

To estimate how much software-engineering time will berequired to do some work.

The difference in time from the start date to the enddate of a task or ro ect.

Development effort

The amount of labour used in person-monthsor

person-days.

To convert an estimate of development effort to anamoun o money:

You multiply it by the weighted average cost



3

engineer for a month (or a day).


4/43

Principles of effective Cost Estimation

Principle 1: Divide and conquer.

To make a better estimate ou should divide the

project up into individual subsystems.

Then divide each subsystem further into the activities

that will be required to develop it.

Next, you make a series of detailed estimates foreach individual activit .

And sum the results to arrive at the rand total



4

estimate for the project.


5/43


6/43


Principle 3: Base your estimates on past experiencecombined with knowledge of the current project.

similarities with a past project: You can expect it to take a similar amount of work.

Base your estimates on the personal judgementof yourexperts

or

Use algorithmic modelsdeveloped in the softwareindustry as a whole by analyzing a wide range of

. They take into account various aspects of a projectssize and complexity, and provide formulas to



6

compute anticipated cost.


7/43


Principle 4: Be sure to account for differenceswhen.

Different software developers Different types of customers and users Different technology

Different domains



7


8/43


Principle 5: Anticipate the worst case and plan forcontingencies.

If the project runs into difficulty, then the criticalfeatures are more likel to have been com leted

Make three estimates:

Optimistic (O) Imagining a case of everything going perfectly

Likely (L)

Allowing for typical things going wrong Pessimistic



8

Accounting for everything that could go wrong


9/43


. Use several different techniques and compare the

results.

If there are discrepancies, analyze your calculationsto discover what factors are causing the differences.se e e p ec n que o a n e op n on o

experts without necessarily bringing them face to

face).Several individuals initially make cost estimates in

private.

discrepancies.

Each individual re eatedl ad usts his or her



9

estimates until a consensus is reached.


10/43

work progresses

s you a more eta s to t e pro ect.

As the requirements changes occur.

As the risk management process



10

.


11/43

Estimation

Schedule and Cost

Size determines how much effort is required.

changing the resource allocation.

Manpower and months are not fully interchange-



11

.


12/43

Cost Estimation

Cost estimation is related to effort estimation and is necessary forscheduling/planning.

- .

15% of large projects never deliver.

Classic Methods for Cost Estimation

Theoretical (Models based on theory)

Advanced Methods for Cost Estimation

Artificial Intelligence (AI) Component-Based Reuse (CBR)



12

e eve opment ec n ques e ase et o s


13/43


14/43

Meta-Model

,

come up with its own model with proper set offactors

Based on an empirical method, i.e. use ofprev ous ata to est mate new pro ects

algorithmic, analogy, experts,

Theoretical methods use global assumptions



14


15/43

Model Format

Background or base equation

of the project.

Project factors (e.g. Cost Drivers in COCOMO)

and actual project effort in database projectsdocumented set of ro ects com leted.

Use the model to redict the effort.



15


16/43

Background Equation

Total and new lines of code and modules

Measures of effort

- -

Form of the equation

* . = Development Effort 2. E = a * Sb

*b

. Calculating the equation parameters which can



16


17/43

Project Factors

Choosing a set of factors

Grouping and compressing this data

Incorporating the factors to predictdeviation from base-line



17


18/43

Groups of Factors

Methodology

Top down design Formal documentation

Chief programmer teams

Unit development folders



18

orma ra n ng


19/43

Groups of Factors

Complexity

Customer-initiated design changesApplication process

Internal communicationExternal communication



19


20/43

Groups of Factors

Programmer qualifications

Programmer experience with machine

Programmer experience with language

Measurement and

Estimation IMCS8301 - Software Engineering

Mana ement

20


21/43

Incorporating Factors

. .

regression - measuring the degree to whichone inde endent variable correlates to thedependent variableto find the effect of

factors

Considering only Methodology and,

Low and High binary attributes we canestimated development effort as:



21

Effort = SizeA * 10B


22/43

Applying the Model

Estimate the size of the project code

Estimate the effort using base-line (the modelbased on baseline (minimum) characteristics.

Estimate factors (methodology, complexity,

Compute the factors-incorporated estimate

(improvement of the baseline estimate)



22


23/43

Some Estimation Methods issues

Parkinson's Law The project costs whatever resources are available Advantages:

Disadvantages: System is usually unfinished

Algorithmic Cost Modelling

Cost is estimated as a mathematical function of product,by project managers

The function is derived from a study of historical costing

Most commonly used product attribute for cost estimation isLOC (code size)



23

values.


24/43

Some Estimation Methods issues contd

One or more experts in both software development and the

application domain use their experience to predict software costs.Process iterates until some consensus is reached.

Advantages: Relatively cheap estimation method. Can be accurate if

experts have direct experience of similar systems Disadvantages:

Very inaccurate if there are no experts!

r c ng to w n The project costs whatever the customer has to spend on it Advantages:

ou ge e con rac Disadvantages: The probability that the customer gets the system he or she



24

. Costs do not accurately reflect the work required


25/43

Cost-Estimation Techniques



25


26/43

Software Cost Estimation Accuracy



26


27/43

Algorithmic Models

Allow you to systematically estimate development.

Based on an estimate of some other factor that,

The number of use cases

The number of classes in the domain model

prototype user interface



27


28/43

gor m c o e s

like the following:

st nstruct ve e :

Effo rt E = a + b N c

S iz e S = W 1

F1

+ W2

F2

+ W3

F3

+



28


29/43

COCOMO ns ruc ve s e Basic (gives an initial estimate of man-months and

develo ment time

Early stages of Project MMNOM= a * KDSIb ; (Time in man-months) TDEV = c * MMDEVd (Development Schedule)

Intermediate (gives a more detailed estimate for small

Main development phases

Detailed (which gives a more detailed estimates forlarge projects).



29

Effect of different factors on individual phases.


30/43

Intermediate COCOMO

Step-1: Nominal effort (MM) estimation as a

- driver attributes

Step-3: Estimate development efforts

Step-4: Use additional factors to determine cost,



30

, ,


31/43

Development Mode for Model

Or anic Stable and in-house familiar ro ects unconstrained MMNOM= 3.2 * KDSI1.05 TDEV = 2.5 * MMDEV 0.38

Semidetached (Intermediate between Organic and Embedded Mode)

MMNOM= 3.0 * KDSI1.12 TDEV = 2.5 * M 0.35

Embedded (More ambitious, unique and constrained projects)

MMNOM= 2.8 * KDSI1.20 TDEV = 2.5 * MMDEV 0.32

The coefficients used are ad usted for each to cater for the a re ate effect

of the cost of factors.



31

environments.


32/43

Development Effort Multipliers

Boehm recommends using the 15 Cost Factors above to evaluate each Projectwith each factor being assessed as being Very Low, Low, Nominal, High, Very



32

High or Extra High (plus definitions) and associated with multiplying factor.


33/43

The Rayleigh-Putnam Curve

ses a nega ve exponen a curve as an n ca or o cumu a vestaff-power distribution over time during a project.

, , ,

languages, methodology, quality assurance procedures.standards etc. It is determined on the basis of historical dataast ro ects .

C is determined from project size, area under effort curve, and

project duration.



33


34/43

The Rayleigh-Putnam Curve contd

Rating: C = 2000 -- poor, C = 8000 -- good, C.

Effort and productivity change whendevelo ment time varies between 2 and 3

years:



34


35/43

Difficulties of Software Cost Estimation

Complexity

Not enou h effort for estimation

Infrequency

Lack of experience

Underestimation bias

Human nature

Goals not estimates



35

g er managemen


36/43

CBR in Effort Estimation

Case-Based Reasoning (CBR) uses analogical

Retrieving solutions to a target problem from

Mapping the source elements to target spaceo strong t eoret ca mo e

Ill-defined, incomplete, and inconsistentdomain rules

Appropriate for software estimation



36


37/43

IF

Staff size of source is small

ANDStaff size of target is large

Increase the effort estimation by 20%



37


38/43

COCOMO-2

Problems with original COCOMO

COTS and re-use Object-Oriented Programming (OOP)

COCOMO-2 defines three stages

Design -



38


39/43

- z

Stage 1

Unadjusted Function Points Stages 2 and 3

Source lines of code



39

ages an


40/43

New Cost Drivers

Team cohesion

Software developed for reuse

Software process maturity (somewhat

practices)

Multi-site development (somewhat replacing



40

.


41/43

Other Differences

Non-linear re-use modeling

Scalin

Scaling factors instead of models

Size-dependent productivity range



41

S li


42/43

Scaling Effort = A SizeB

B > 1: diseconomies of scale (Dis-economies of scale occurwhen a business grows so large that the costs per unitincrease.

B = 1: linear B < 1: economies of scale

In Ada-COCOMO B varies between 1.04 to 1.24 depending on

projects progress in reducing diseconomies of scale via risk, , ,process maturity.

-

B = 1.01 + 0.01 Wi Precedentedness, flexibility, risk resolution, team cohesion,



42

and process maturity.


43/43

Variations of COCOMO Model

Estimation without the cost drivers in person-per-

- -

The intermediate model is more accurate than thebasic model.



43

5. Measurement n Estimation I

Documents

Transcript of 5. Measurement n Estimation I