Lecture2-2012dp-004 - LTHcs.lth.se/fileadmin/cs/Dietmar_Pfahl/Lecture2-2012dp-004.pdf · 2012-03-19 4 ETSF01 / Lecture 2, 2012 COCOMO II – Example ETSF01 / Lecture 2, 2012 Example

2012-03-19

1

ETSF01 / Lecture 2, 2012

ETSF01: Software Engineering Process –

Economy and Quality

Dietmar Pfahl Lund University


Software Project Management

Chapter 5 Software effort estimation


Estimation Techniques – Main Types

Cost/Schedule Estimation Techniques

Expert Judgment Algorithmic/ Parametric Models

Empirical Factor Models: - COCOMO / COCOMO II - ESTIMACS - PRICE S - Softcost - DOTY - CheckPoint - etc.

Constraint Models: - SLIM - Jensen Model - COPMO - etc.

Analogy

Machine Learning: - Case-Based Reasoning - Collaborative Filtering - Classification Systems - etc.

Other

Parkinson’s Law Pricing-to-Win Top-Down Estimation Bottom-Up Estimation

- Delphi-Method - Planning Poker - …


Parametric Models – Simple Examples

•  Estimated effort = Estimated system size / Productivity1 –  E.g., system size estimated in kloc (kilo lines of code) –  E.g., productivity calculated as average from past projects:

•  Productivity1i = System sizei [kloc] / Efforti [person-day] •  Estimated time = Estimated system size / Productivity2

–  Productivity2i = (System sizei [kloc]) / Timei [day]

Model Estimated

System Size (new project)

Average Productivity (old projects)

Estimated Effort (or Time)


Parametric model example: COCOMO

•  COCOMO = Constructive Cost Model •  Size measure (KLOC, FP) & productivity factors as input

COCOMO Model

Estimated System

size

Productivity factors

Estimated Effort (or Time)


COCOMO – Introduction

•  COCOMO (Constructive Cost Model) – 1981 –  Model based on

•  estimated size of the new system and •  cost drivers that affect productivity.

•  COCOMO II – 2000 –  Enhanced version, accounts for changes in

software engineering technology, including •  object-oriented software, •  software created following spiral or

evolutionary development models, •  software reuse, •  components off-the-shelf (COTS).

Prof. Barry Boehm, USC

2012-03-19

2


COCOMO – 1981

•  The original COCOMO is a collection of three models: –  Basic model – applied during feasibility study –  Intermediate model – applied after requirements

acquisition –  Advanced model – applied after design is

complete •  All three models take the form:

where –  E is effort in person-months –  Tdev is the development time in months –  S is size measured in thousands of lines of code

(or DSI*) –  EAF is the effort adjustment factor (equals 1 in

the Basic model) –  Factors a, b, c and d depend on the

development mode.

*DSI = Delivered Source Instructions

b ddevE aS EAF T cE= × =


Basic COCOMO – Effort Equations

•  Organic mode: PM = 2.4 (KDSI) 1.05 •  Semi-detached mode: PM = 3.0 (KDSI) 1.12

•  Embedded mode: PM = 3.6 (KDSI) 1.20

Enom = a(Size)b

EAF = 1

•  PM = Person-Months •  KDSI = Kilo Delivered Source Instructions (~KLOC)


Effort-Time Trade-Off

Person Effort = 4 person-days (pd)

1 1 1 1

Person Effort = 4 pd

1 1 1 1

?

Person Effort = 4 pd

1

1 1

1 ?

COCOMO

Source: B. Boehm: Software Engineering Economics, Prentice-Hall, 1981.

Day

Day

Day ?

COCOMO Intermediate model: Effort Adjustment Factor à Schedule (SCED)

b ddevE aS EAF T cE= × =


COCOMO II


COCOMO II – Three Sub-Models

•  COCOMO II includes a three-stage series of models: –  Application Composition Model: Used during the earliest

development phases, usually involving prototyping •  replaces Basic COCOMO

–  Early Design Model: Used during the next development phases, usually involving exploration of architectural alternatives or incremental development strategies

•  replaces Intermediate COCOMO –  Post-Architecture Model: Used once the project has a

defined life-cycle architecture, typically providing more accurate and detailed information for adjusting cost drivers

•  replaces Advanced COCOMO


COCOMO II – Early Design Model (EDM)

•  The Early Design model equation is:

•  The effort adjustment factor (EAF) is the product of seven effort multipliers.

•  SFi: Scale Factor i a = 2.94

•  If unadjusted function point count (UFC) is used for sizing, this value is converted to KLOC.

( )5

12.45 0.91 0.01b

ij

E KLOC EAF b SF=

= × × = + ∑( ) EAFKLOCaE b ××=

2012-03-19

3


COCOMO II – EDM Effort Multipliers (Cost Drivers)

•  The effort adjustment factor (EAF) for the Early Design Model is the product of 7 effort multipliers/modifiers (which are further refined into 17 cost drivers in the Post-Architecture model)

Cost Driver

Description Represent Combined Post-Architecture Cost Drivers

1 RCPX Product reliability and complexity RELY, DATA, CPLX, DOCU 2 RUSE Required reusability RUSE 3 PDIF Platform difficulty TIME, STOR, PVOL 4 PERS Personnel capability ACAP, PCAP, PCON 5 PREX Personnel experience AEXP, PEXP, LTEX 6 FCIL Facilities available TOOL, SITE 7 SCED Schedule pressure SCED


COCOMO II – EDM Cost Drivers (Effort Multipliers)

Extra low

Very low Low Nom-inal

High Very high

Extra high

RCPX 0.49 0.60 0.83 1.00 1.33 1.91 2.72

RUSE 0.95 1.00 1.07 1.15 1.24

PDIF 0.87 1.00 1.29 1.81 2.61

PERS 2.12 1.62 1.26 1.00 0.83 0.63 0.50

PREX 1.59 1.33 1.12 1.00 0.87 0.74 0.62

FCIL 1.43 1.30 1.10 1.00 0.87 0.73 0.62

SCED 1.43 1.14 1.00 1.00 1.00

Default


COCOMO II – EDM Scale Factors

Scale Factors (SF): •  Precedentedness (PREC) – [0 .. 6.20]

–  Degree to which system is new and past experience applies •  Development Flexibility (FLEX) – [0 .. 5.07]

–  Need to conform with specified requirements •  Architecture/Risk Resolution (RESL) – [0 ... 7.07]

–  Degree of design thoroughness and risk elimination •  Team Cohesion (TEAM) – [0 .. 5.48]

–  Need to synchronize stakeholders and minimize conflict •  Process Maturity (PMAT) – [0 .. 7.80]

–  SEI CMM process maturity rating

( )5

12.45 0.91 0.01b

ij

E KLOC EAF b SF=

= × × = + ∑


COCOMO II – EDM SF Ratings

• Scale Factor (SF) Ratings SF Very

Low Low Nominal High Very

High Extra High

Precedentedness PREC 6.20 4.96 3.72 2.48 1.24 0.00

Development/Flexibility FLEX 5.07 4.05 3.04 2.03 1.01 0.00 Architecture/Risk Resolution

RESL 7.07 5.65 4.24 2.83 1.41 0.00

Team Cohesion TEAM 5.48 4.38 3.29 2.19 1.10 0.00 Process Maturity PMAT 7.80 6.24 4.68 3.12 1.56 0.00

Default

( )5

12.45 0.91 0.01b

ij

E KLOC EAF b SF=

= × × = + ∑


COCOMO II – Early Design Model Effort Estimates

0

2000

4000

6000

8000

10000

12000

14000

0 100 200 300 400 500 600 700 800 900 1000

KLOC

Pers

on-M

onth

B-VL

B-L

B-N

B-H

B-VH

B-EH

( )5

12.45 0.91 0.01b

ij

E KLOC EAF b SF=

= × × = + ∑

[0 … 6.20] [0 … 5.07] [0 … 7.07] [0 … 5.48] [0 … 7.80]

b=1 b=0.91

b=1.23

b=1.10

( ) EAFKLOCaE b ××=


Example: EDM Scale Factor TEAM

•  Elaboration of the TEAM rating scale: –  Use a subjective weighted average of the characteristics to

account for project turbulence and entropy due to difficulties in synchronizing the project's stakeholders.

–  Stakeholders include users, customers, developers, maintainers, interfacers, and others

2012-03-19

4


COCOMO II – Example


Example – Scale factors

•  The software development team develops an application which is very similar to previous ones it has developed.

Information relevant for Scale Factors: •  A very precise software engineering document lays down

very strict requirements. à PREC is ‘very high’ (score 1.24) à FLEX is ‘very low’ (score 5.07)

•  The good news is that these tight requirements are unlikely to change (àRESL is ‘high’ with a score 2.83).

•  The team is tightly knit (TEAM has ‘high’ score of 2.19), but processes are informal (so PMAT is ‘low’ and scores 6.24)

( )5

12.45 0.91 0.01b

ij

E KLOC EAF b SF=

= ! ! = + "( ) EAFKLOCaE b !!=


Example – Scale factors

•  The formula for SF is –  b = 0.91 + 0.01 × Σ scale factor values

= 0.91 + 0.01 × (1.24 + 5.07 + 2.83 + 2.19 + 6.24) = 1.0857

•  If the estimated system size equals 10 KLOC and EAF=1, then the effort estimate is

2.94 x 101.0857 = 35.8 person-months (= 716 person-days) •  Note that for larger systems, the effect of the scale factor

becomes over-proportionally stronger Twice as large: 2.94 x 201.0857 = 76 person-months

( )5

12.45 0.91 0.01b

ij

E KLOC EAF b SF=

= ! ! = + "( ) EAFKLOCaE b !!=


Example – Effort multipliers /1

•  The new project is similar in most characteristics to the projects that the organization has been dealing with in the past, …

•  except –  the software to be produced is very complex and will be

used in a safety critical system; –  the software will interface with a new operating system

that is currently in beta status; –  to deal with this, the team allocated to the job is

regarded as exceptionally good, but does not have a lot of experience with this type of software.

( )5

12.45 0.91 0.01b

ij

E KLOC EAF b SF=

= ! ! = + "( ) EAFKLOCaE b !!=


Example – Effort multipliers /2

•  RCPX very high 1.91 •  PDIF very high 1.81 •  PERS extra high 0.50 •  PREX nominal 1.00 •  All other factors are ‘nominal’ (i.e., equal to 1.00)

•  With estimated size = 10 KLOC and b = 1.0857 the unadjusted effort estimate (using EAF=1) was

–  E = 35.8 person-months •  With effort multipliers (EAF) applied, this becomes:

–  E = 35.8 x 1.91 x 1.81 x 0.5 = 61.9 person-months

( )5

12.45 0.91 0.01b

ij

E KLOC EAF b SF=

= ! ! = + "( ) EAFKLOCaE b !!=


Function Points

2012-03-19

5


Function-Oriented Size Measures

•  Functionality is one aspect of software size. The assumption is that a product with more functionality is larger in size and thus needs more effort to be developed.

•  The first function-oriented measure was proposed by Albrecht (1979~1983).

–  He suggested a size measurement approach called the Function Point (FP) method.

•  Function points (FPs) measure the amount of functionality in a system based upon the system specification.

à Estimation before implementation!

Specification

Architectural Design

Implementation

Module Test

Integration Test

Acceptance Test

Micro Design


Parametric Model – Functional Size

•  Models for estimating Function Points:

–  Albrecht / IFPUG Function Points –  Mark II Function Points –  COSMIC Function Points

Model

Number of file types

Numbers of input and output transaction types

‘System size’ (Function Points)


IFPUG Function Point Counting Elements


Albrecht/IFPUG FPs – Elements

Five function types 1.  Internal logical file (ILF)* types – equates roughly to a data store in

systems analysis terms. Created and accessed by the target system. 2.  External interface file (EIF) types – where data is retrieved from a

data store which is actually maintained by a different application. 3.  External input (EI) types – input transactions which update internal

software files 4.  External output (EO) types – transactions which extract and display

data from internal computer files. Generally involves creating reports. 5.  External inquiry (EQ) types – user initiated transactions which

provide information but do not update software files. Typically, the user inputs some data that guides the system to the information the user needs.

* Note: ILF is sometmies called ’Logical Internal File’ (à LIF)


Weigthed ILF

Weighted EIF

Weighted EI

Weighted EO

IFPUG Function Point Counting Big Picture

Unadjusted and Unweighted Function Count

L A H

# EI # ILF # EIF # EQ # EO

Weighted EQ

14 Adjustment Factors

Adjusted FP Count

Unadjusted Function Points (UFP)

Complexity Adjustment

Weighting of functional (technical) complexities

Step 2

Step 1b

Step 1a

L A H L A H L A H L A H

=

=

+ + + +

+ + + +

Adjusted Function Points Value Adjustment Factor (VAF))


Weigthed ILF

Weighted EIF

Weighted EI

Weighted EO



L A H


Weighted EQ


Adjusted FP Count




Step 2

Step 1b

Step 1a


=

=

+ + + +

+ + + +


2012-03-19

6


Albrecht/IFPUG FPs – Complexity Multipliers

Function types Low complexity

Medium complexity

High complexity

EI 3 4 6

EO 4 5 7

EQ 3 4 6

EIF 5 7 10

ILF 7 10 15


IFPUG FP Counting: Weighting of Technical Complexity


_____ __ x15 = _____ __ x10 = _____ __ x 7 = _____ Internal Logical Files (ILF)

_____ __ x10 = _____ __ x 7 = _____ __ x 5 = _____ External Interface Files (EIF)

_____ __ x 6 = _____ __ x 4 = _____ __x 3 = _____ External Inquiries (EQ)

_____ __ x 7 = _____ __ x 5 = _____ __ x 4 = _____ External Outputs (EO)

_____ __ x 6 = _____ __ x 4 = _____ __ x 3 = _____ External Inputs (EI)

Sum high average low

Complexity Elements


Albrecht/IFPUG FPs – Example /1

Payroll application has: 1.  A transaction to add, update and delete employee details à

an EI rated to be of medium complexity 2.  A transaction that calculates pay details from timesheet data

that is input à an EI rated to be of high complexity 3.  A transaction that prints out pay-to-date details for each

employee à an EO rated to be of medium complexity 4.  A personnel file maintained by another system is accessed for

name and address details à a simple EIF 5.  A file of payroll details for each employee à an ILF rated to

be of medium complexity What would be the FP count for such a system?


Albrecht/IFPUG FPs – Example /2

1 Medium EI 4 FPs 1 High complexity EI 6 FPs 1 Medium complexity EO 5 FPs 1 Simple EIF 5 FPs 1 Medium complexity ILF 10 FPs Total 30 FPs

•  If previous projects delivered 5 FPs per person-day, implementing the above should consume 30/5 = 6 person-days


IFPUG Unadjusted FP Count (UFC)

•  A complexity rating is associated with each count using function point complexity weights

•  Special case: Item

Weighting Factor Simple Average Complex

External inputs (à NEI) 3 4 6

External outputs (à NEO) 4 5 7

External inquiries (à NEQ) 3 4 6

External interface files (à NEIF) 5 7 10

Internal logical files (à NILF) 7 10 15

ILFEIFEQEOEI NNNNNUFC 107454 ++++=

Low High Complexity


Weigthed ILF

Weighted EIF

Weighted EI

Weighted EO

IFPUG Function Point Counting: Complexity Assessment Details


L A H


Weighted EQ


Adjusted FP Count




Step 2

Step 1b

Step 1a


=

=

+ + + +

+ + + +


2012-03-19

7


IFPUG Function Types – Complexity Assessment

Data Function Types Transaction Function Types

Internal Logical Files (ILF)

External Interface Files (EIF)

External Input (EI)

External Output

(EO)

External Inquiry

(EQ)

Elements evaluated for technical complexity assessment

REcord Types (RET): User recognizable sub groups of data elements within an ILF or an EIF. It is best to look at logical groupings of data to help identify them.

File Type Referenced (FTR): File type referenced by a transaction. An FTR must be an Internal Logical File (ILF) or External Interface File (EIF).

Data Element Types (DET): A unique user recognizable, non-recursive (non-repetitive) field containing dynamic information. If a DET is recursive then only the first occurrence of the

DET is considered not every occurrence.


IFPUG Internal Logical File – Complexity Assessment

•  Identify number of Record Types (RET)

•  Identify number of Data Element Type (DET)

•  Determine complexity (à used to calculate FP count)

ILF #DET

1-19 20-50 > 50

#RET 1 low (7) low (7) average (10)

2-5 low (7) average (10) high (15) > 5 average (10) high (15) high (15)


IFPUG Internal Logical File – Example

Employee -  Name -  ID -  Birth Date -  Payment Reference

1 RET 4 DET

ILF #DET

1-19 20-50 > 50

#RET

1 low (7) low (7) average (10)

2-5 low (7) average (10) high (15)

> 5 average (10) high (15) high (15)

ILF: “Employee” =


Weigthed ILF

Weighted EIF

Weighted EI

Weighted EO



L A H


Weighted EQ


Adjusted FP Count




Step 2

Step 1b

Step 1a


=

=

+ + + +

+ + + +



IFPUG Value Adjustment Factor (VAF) /1

•  Value Adjustment Factor (VAF) is a weighted sum of 14 Factors (General System Characteristics (GSC) or Technical Complexity Adjustments (TCA)):

F1 Data Communications F2 Distributed Data Processing F3 Performance F4 Heavily Used Configuration F5 Transaction Rate F6 On-line Data Entry F7 End-User Efficiency F8 On-line Update F9 Complex Processing F10 Reusability F11 Installation Ease F12 Operational Ease F13 Multiple Sites F14 Facilitate Change


FP: Advantages – Summary

•  Can be counted before design or code documents exist (but a specification is needed)

•  Can be used for estimating project cost, effort, schedule early in the project life-cycle

•  Helps with contract negotiations •  Is standardized (though several competing

standards exist)

2012-03-19

8


FP vs. LOC

•  A number of studies have attempted to relate LOC and FP metrics (Jones, 1996).

•  The average number of source code statements per function point has been derived from case studies for various programming languages.

•  Languages have been classified into different levels according to the relationship between LOC and FP.


IFPUG FP: Critique – Summary

•  FP is a subjective measure (à counting items, complexity weights)

•  Requires a full software system specification –  But there exist “light-weight” alternatives à Object Point, Use

Case Point

•  Appropriateness of the basic unit of FP is unclear •  Difficult to apply to maintenance (enhancement) projects •  Not suitable for “complex” software, e.g., real-time and

embedded applications –  Proposed solution: COSMIC FP / Feature Points


Rest of this week

•  Read textbook chapter 5 •  Suggested exercises:

–  5.2 (page 107), 5.3 (page 109), 5.11 (page 123), 5.15.2 (page 126), and 5.15.4-6 (page 127)

•  Read Project Mission •  Write & submit project plan (PP) •  Meet project supervisors


Next weeks (until after Easter Break)

•  Read textbook chapters 2 and 6 •  Work on first iteration:

– Tool Version 1 (TV1) – Burndown Chart (EC1) – Draft User Manual (UM)

•  Meet project supervisors

Documents

Lecture2-2012dp-004 - LTHcs.lth.se/fileadmin/cs/Dietmar_Pfahl/Lecture2-2012dp-004.pdf · 2012-03-19 4 ETSF01 / Lecture 2, 2012 COCOMO II – Example ETSF01 / Lecture 2, 2012 Example