Softenr-5

(1)

Software Engineering

Project Management &

Estimation

(2)

(3)

(4)

(5)

(6)

(7)

(8)

(9)

Example: FP Approach

The estimated number of FP is derived:

FP

FP_estimated_estimated = count-total = count-total xx [0.65 + 0.01 [0.65 + 0.01 xxSS (F (F_i_i)])] FP

FP_estimated_estimated = 386 = 386

organizational average productivity = 6.5 FP/pm.

burdened labor rate = $8000 per month, approximately $1230/FP.

Based on the FP estimate and the historical productivity data,

(10)

Process-Based Estimation

The most common technique for estimating a project is to base the estimate on the process that will be used.

That is, the process is decomposed into a relatively small

set of tasks and the effort required to accomplish each task is estimated.

If process-based estimation is performed independently of LOC or FP estimation, we now have two or three estimates for cost and effort that may be compared and reconciled.

(11)

Process-Based Estimation

Obtained from “process framework” Obtained from “process framework”

application functions

framework activities

Effort required to accomplish

(12)

12

Process-Based Estimation Example

Activity Task Function UICF 2DGA 3DGA DSM PCF CGDF DAM Totals % effort

CC Planning _AnalysisRisk Engineering Construction Release CE Totals analysis design code test

0.25 0.25 0.25 3.50 20.50 4.50 16.50 46.00

1% 1% 1% 8% 45% 10% 36%

CC = customer communication CE = customer evaluation 0.50 0.75 0.50 0.50 0.50 0.25 2.50 4.00 4.00 3.00 3.00 2.00 0.40 0.60 1.00 1.00 0.75 0.50 5.00 2.00 3.00 1.50 1.50 1.50 8.40 7.35 8.50 6.00 5.75 4.25 0.50 2.00 0.50 2.00 5.00

n/a n/a n/a n/a n/a n/a n/a

Based on an average burdened labor rate of $8,000 per

month,

(13)

Tool-Based Estimation

project characteristics project characteristics

calibration factors calibration factors

(14)

Es

ti

m

ati

o

n

fo

rm

u

la

Historical data are thenused to compute the effort required to develop the system.

LOC estimate= N x LOCavg + [(Sa/Sh – 1) + (Pa/Ph – 1)] x LOCadjust

where

N : actual number of use cases

LOCavg : historical average LOC per use case for this type of subsystem

LOCadjust : represents an adjustment based on n percent of LOCavg where n is defined locally and represents the difference between this project and “average” projects

Sa : actual scenarios per use case

Sh : average scenarios per use case for this type of subsystem Pa : actual pages per use case

(15)

Estimation with Use-Cases

use cases scenarios pages Êscenarios pages LOC LOC estimate

e subsystem 6 10 6 Ê 12 5 560 3,366

subsystem group 10 20 8 Ê 16 8 3100 31,233

e subsystem group 5 6 5 Ê 10 6 1650 7,970

Ê Ê Ê Ê

stimate Ê Ê Ê Ê 42,568

User interface subsystem Engineering subsystem group Infrastructure subsystem group Total LOC estimate

Using 620 LOC/pm as the average productivity for systems of this type

and a burdened labor rate of $8000 per month, the cost per line of code is

approximately $13. Based on the use-case estimate and the historical

(16)

16

Empirical Estimation

Models

General form:

effort = tuning coefficient * sizeexponent

usually derived

as person-months

of effort required

either a constant or

a number derived based

on complexity of project

usually LOC but

may also be

(17)

Constructive Cost Model

(COCOMO)

• _{Introduced by Barry Boehm}

• _{Widely used for effort and cost estimation} • _{3 models:}

– _{Basic COCOMO}

– _{Intermediate COCOMO}

– _{Advanced COCOMO}

• _{Select a model for estimation, identify ‘mode’}

(18)

18

Project Categories

Category Size Innovation Constraints Team

Organic mode Small Little Not tight Good

Semi-detached mode

Large Greater Tight Mixed

Embedded mode

(19)

-Basic COCOMO

• _{Computes software development effort (and}

cost) as function of program size expressed in estimated lines of code

• _Model:

Category ab bb cb db

Organic 2.4 1.05 2.5 0.38

Semi-detached 3.0 1.12 2.5 0.35

(20)

20

Basic COCOMO Equations

where

• _{E is effort in person-months}

• _{D is development time in months}

• _{kLOC is estimated number of lines of code}

b

d b

b b

E

c

D

kLOC

a

E

(21)

Example

Types of Components

Complexity # of

Compots

Complex Factor

Est. Count

L A H

External Inputs 3 4 6 15 3 45

Internal outputs 4 5 7 18 4 72

External Inquiries 3 4 6 14 3 42

Internal files 7 10 11 16 6 96

External Interface

5 7 10 15 7 105

Total Count 360

VAF=42

(22)

22

Intermediate COCOMO

• _{computes software development effort as a}

function of program size and a set of “cost

drivers” that include subjective assessments of product, hardware, personnel, and project

attributes

• _{Give rating to 15 attributes, from “very low” to}

“extra high”, find effort multipllier (from table) and product of all effort multipliers gives an

(23)

Cost driving Attributes

Category Cost Driven Attributes

Product attributes

•Required reliability

•_{Database size}

•Product complexity

Computer attributes

•_{Execution time constraint} •Main storage constraint

•_{Virtual machine volatility} •_{Computer turnaround time}

Personnel attributes

•_{Analyst capability, Programmer capability} •_{Applications experience}

•Virtual machine experience

•_{Programming language experience}

(24)

(25)

Intermediate COCOMO Equation

• _where

• _{E is effort in person-months,}

• _{kLOC is estimated number of lines of code}

• _{EAF is the product of all selected adjustment Factors}

Category a_i b_i

Organic 3.2 1.05

Semi-detached 3.0 1.12

Embedded 2.8 1.20

EAF

kLOC

a

E

bi

i



(26)

KDSI= Thousand Delivered Source Instructions

EAF= Effort

Adjustment Factor

(27)

Components Number LOC per Co KLOC

EI 10 200

EO 12 180

IF 12 500

II 8 450

Reports 8 200

Size

Characteristics Level EAF

Calculate Size and then select Characteristics from table and

(28)

28

COCOMO-II

• _{COCOMO II is actually a hierarchy of estimation}

models that address the following areas:

• _{Application composition model.}_{Used during the early stages}

of software engineering, when prototyping of user interfaces, consideration of software and system interaction, assessment of performance, and evaluation of technology maturity are paramount.

• _{Early design stage model.}_{Used once requirements have been}

stabilized and basic software architecture has been established.

• _{Post-architecture-stage model.}_{Used during the construction}

(29)

The Software Equation

A dynamic multivariable model

E = [LOC x B

E = [LOC x B0.3330.333/P]_/P]33 x (1/t_{x (1/t}44)₎

where

E = effort in person-months or person-years

t = project duration in months or years

B = “special skills factor”

P = “productivity parameter”

(30)

30

Estimation for OO Projects-I

• Develop estimates using effort decomposition, FP analysis, and

any other method that is applicable for conventional applications.

• Using object-oriented requirements modeling (Chapter 6),

develop use-cases and determine a count.

• _{From the analysis model, determine the number of key classes}

(called analysis classes in Chapter 6).

• Categorize the type of interface for the application and develop a

multiplier for support classes: – Interface type Multiplier

– No GUI 2.0

– Text-based user interface 2.25

– GUI 2.5

(31)

Estimation for OO Projects-II

• _{Multiply the number of key classes (step 3) by the}

multiplier to obtain an estimate for the number of support classes.

• _{Multiply the total number of classes (key + support)}

by the average number of work-units per class. Lorenz and Kidd suggest 15 to 20 person-days per class.

• _{Cross check the class-based estimate by multiplying}

(32)

32

Estimation for Agile Projects

• _{Each user scenario (a mini-use-case) is considered separately for}

estimation purposes.

• _{The scenario is decomposed into the set of software engineering tasks}

that will be required to develop it.

• _{Each task is estimated separately. Note: estimation can be based on}

historical data, an empirical model, or “experience.”

– Alternatively, the ‘volume’ of the scenario can be estimated in LOC, FP or some other volume-oriented measure (e.g., use-case count).

• _{Estimates for each task are summed to create an estimate for the}

scenario.

– Alternatively, the volume estimate for the scenario is translated into effort using historical data.

• _{The effort estimates for all scenarios that are to be implemented for a}

(33)

The Make-Buy Decision

system X

system X reusereuse

simple (0.30) simple (0.30)

difficult (0.70) difficult (0.70)

minor

minor changeschanges (0.40) (0.40) major major changes changes (0.60) (0.60) simple (0.20) simple (0.20) complex (0.80) complex (0.80) major

major changeschanges (0.30)(0.30) minor

minor changeschanges (0.70) (0.70) $380,000 $380,000 $450,000 $450,000 $275,000 $275,000 $310,000 $310,000 $490,000 $490,000 $210,000 $210,000 $400,000 $400,000 buy buy contract contract

without changes (0.60) without changes (0.60)

with changes (0.40) with changes (0.40)

(34)

34

Computing Expected Cost

((path probability) path probability) x (estimated path cost_{(estimated path cost}) ) i

i ii

For example, the expected cost to build is:

expected cost = 0.30 ($380K) + 0.70 ($450K)

similarly,

expected cost = $382K expected cost = $267K expected cost = $410K

build

reuse buy contr

expected cost =

= $429 K

(35)

Summary

• _{Estimation provides a better way to evaluate}

the process on the basis of Cost and Effort.

• _{Using sizing attributes FP and are calculated.} • _{Tool based is a good approach.}

• _{Cost is the function of effort.}

• _{We can use Basic, intermediate or advanced}

CoComMo models.

(36)

Make-References

1- These slides are designed to accompany Software

Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill