Lecture03-spm

7/27/2019 Lecture03-spm

1/86

Software Project Management

Software Project Management

Lecture 3

Size and Cost Estimation


2/86

Overview

Different level of estimation Project Evaluation

Software Project Management 2

Size Estimation

Cost Estimation


3/86

Different level of estimation

Before decision to do a project The estimation is coarse


Profit? Good to the organization? etc.

After decision to go ahead

More detailed size and cost estimations arerequired


4/86

Project Evaluation

A high level assessment of the project to see whether it is worthwhile to proceed

with the ro ect


to see whether the project will fit in thestrategic planning of the wholeorganization


5/86


6/86

Project Evaluation - Who

Senior management Project manager/coordinator



7/86

Project Evaluation - When

Usually at the beginning of the project e.g. Step 0 of Step Wise Framework



8/86

Project Evaluation - What

Strategic assessment Technical assessment



9/86

Project Evaluation - How

Cost-benefit analysis Cash flow forecasting


- Risk analysis


10/86

Strategic Assessment

Used to assess whether a project fits in thelong-term goalof the organization

Usually carried out by senior management


Needs a strategic plan that clearly defines theobjectives of the organization

Evaluates individual projects against the

strategic plan or the overall businessobjectives


11/86

Strategic Assessment (contd)

Programme management suitable for projects developed for use in

the or anization


Portfolio management

suitable for project developed for other

companies by software houses


12/86

SA Programme Management

Individual projects as components of aprogramme within the organization

Programme as a group of projects that are


managed in a coordinated way to gainbenefits that would not be possible werethe projects to be managed independently

by D.C. FernsJournal of Project Management

Aug. 1991


13/86

SA Programme ManagementIssues

Objectives How does the project contribute to the

lon -term oalof the or anization?


Will the product increase the marketshare? By how much?


14/86


15/86

SA Programme ManagementIssues (contd)

Organization structure How does the product affect the existing

or anizational structure? the existin


workflow? the overall business model?


16/86


17/86


18/86

SA Portfolio Management

suitable for product developed by asoftware company for an organization

ma need to assess the roduct for the


client organization Programme management issues apply

need to carry out strategic assessmentfor the providing software company


19/86


20/86


21/86

Economic Assessment

Why? Consider whether the project is the best


Prioritise the projects so that theresources can be allocated effectively if

several projects are underway


22/86


23/86


24/86

EA Cost-benefit Analysis(contd)

Costs Development costs


Operational costs


25/86

EA Cost-benefit Analysis(contd)

Benefits Direct benefits


Intangible benefits


26/86


27/86


28/86


29/86


30/86

Cost-benefit EvaluationTechniques

Net profit= Total income Total costs


= Time taken to break even

Return on Investment (ROI)

%100investmenttotal

profitannualaverage=


31/86

Cost-benefit EvaluationTechniques NPV

Net present value (NPV) It is the sum of the present values of all

future amounts.


Present valueis the value which afuture amount is worth at present

It takes into account the profitability ofa project and the timing of the cashflows


32/86


33/86


34/86

Cost-benefit EvaluationTechniques NPV (contd)

Issues in NPV Choosing an appropriate discount rate is

difficult


Ensuring that the rankings of projects arenot sensitive to small changes in discountrate


35/86


Guidelines: Use the standard rate prescribed by the

or anization


Use interest rate + premium rate Use a target rate of return

Rank the projects using various discountrates


36/86


Disadvantage May not be directly comparable with

earnin s from other investments or the


costs of borrowing capital


37/86


38/86


39/86


40/86

Estimation

Why? to define the project budgetand to refine the product to realize the


Who? the manager

What? size and cost

When? always How? techniques and models


41/86

Issues related to Estimation

Difficult to make accurate estimation Better to have previous data and analyze the

actual values against their estimates so that


you know how accurate you are Even better to have previous data of the

whole organization so that you know how

accurate the estimation method, if any, usedwithin the organization is


42/86

Positive Attitude TowardsEstimation

Use your estimation as a guide tomanage your project


,

your estimation based on the currentstatus of the project


43/86

Estimation Approaches

Expert judgementAsk the knowledgeable experts

Estimation b analo


Use the data of a similar and completed

project

Pricing to win Use the price that is low enough to win the

contract


44/86

Estimation Approaches(contd)

Top-down An overall estimate is determined and then broken

down into each component task


Bottom-up The estimates of each component task are

aggregated to form the overall estimate

Algorithmic model Estimation is based on the characteristics of the

product and the development environment.


45/86

Size Estimation

Problems related to size estimation Size Estimation Model



46/86

Problems related to sizeestimation

Nature of software Novel application of software


Lack of homogeneity of projectexperience

Subjective nature of estimation

Political implications within theorganization


47/86

Function Point Analysis (FPA)

Developed by A. Albrecht in IBMAim: To estimate the LOC of a system


LOC of system

= FP of system LOC-per-FP of the

language

F i P i A l i


48/86

Function Point Analysis(contd)

Idea: Software system consists of fivemajor components (or, external usertypes)


External input types External output types

Logical internal file types

External interface file types External inquiry types


49/86

Function Point Analysis - Steps

Identify each instance of each externaluser type in the proposed system


,

medium or low complexity

Assign the FP of each instance

FP of the system = sum of FP ofindividual components


50/86

Function Point Analysis

Number of FPs ComplexityExternal user type Low Average High


x erna npu ype

External output type 4 5 7

Logical internal file type 7 10 15

External interface file type 5 7 10

External inquiry type 3 4 6


51/86

F ti P i t A l i


52/86

Function Point Analysis(contd)

Other issues The assignment of level of complexity is

rather sub ective


International FP User Group (IFPUG)imposes rules on assigning the level ofcomplexity to individual external user types


53/86

Object Point Analysis

Similar to function point analysis Used on 4GL development projects


more readily identifiable if the system isbuilt on high-level application building

tools


54/86

Object Point Analysis Steps

Identify the number of screens, reportsand 3GL components


,

and DifficultAssign the weight accordingly

Calculate the total object pointsTotal OP = sum of individual OP weighting

Object Point Analysis Steps


55/86

Object Point Analysis Steps(contd)

Deduct the reused objects (r% reused)NOP = OP (1 r%)

Identif the roductivit rate of both


developer and CASE Productivity rate = average of the two

PRs

Calculate the effortEffort = NOP / Productivity Rate



56/86

Object Point Analysis Screens

Number and source of data tables

Number of Total < 4

Total < 8

-

Total 8+


contained

,

5 client)

< 3 Simple Simple Medium

3 7 Simple Medium Difficult

8+ Medium Difficult Difficult



57/86

Object Point Analysis Reports

Number and source of data tables

Number of Total < 4

Total < 8

-

Total 8+


contained

,

5 client)

< 2 Simple Simple Medium

2 or 3 Simple Medium Difficult

> 3 Medium Difficult Difficult



58/86

Object Point Analysis Complexity Weightings

Complexity

Type of object Simple Medium Difficult


Screen 1 2 3

Report 2 5 8

3GL component N/A N/A 10



59/86

Object Point Analysis Productivity Rate

Verylow Low Nominal High VeryHigh


v r

experienceand capability

4 7 13 25 50

CASEmaturity andcapability

4 7 13 25 50


60/86

Object Point Analysis Issues

Adopted in Boehms COCOMO II in theapplication composition stage




61/86

Object Point Analysis Example

See separate handout



62/86

Cost Estimation

Cost Estimation Model COCOMO II


Constructive Cost Model II


63/86

Constructive Cost Model II

(COCOMO II)

A parametric cost model Important aspects of software projects are

characterized b variables or arameters


Once the value of the parameters aredetermined, the cost can be computedfrom an equation


64/86

COCOMO II (contd)

Recognizes different approaches tosoftware development


, .


65/86

A history of COCOMOs

COCOMOoriginally proposed by Boehmin 1981, now called COCOMO 81


In 1995, Boehm proposed COCOMO II


66/86

COCOMO II

A family of models Uses different models in 3 different stages

of the ro ect


3 stages: application composition, earlydesign and post architecture

Supports estimation early in the process

Allows further detailed estimation after thesystem architecture has been defined


67/86

The Application Composition


68/86

The Application Composition

Stage

Estimation at the early stage Corresponding to exploratory work such


Uses object points to estimate the sizeof the product


69/86

The Early Design Stage

Estimate after the requirementsspecification is completed and possiblywith some design


Use the basic model equation Estimate the size by FPs (preferred) or

KSLOC

Estimate scale factor and effortmultiplier



70/86

y g g

Scale Factor

Estimation of the scale factorA combined effect of 5 parameters


Process flexibility

Architecture risk resolution

Team cohesion Process maturity



71/86

y g g

Scale Factor (contd)

ParameterVery Low

(0.05)

Low

(0.04)

Nominal

(0.03)

High

(0.02)

Very High

(0.01)

Extra High

(0.00)

PrecedentednessThoroughly

unprecedentedLargely

unprecedentedSomewhat

unprecedentedGenerallyfamiliar

Largelyfamiliar

Thoroughlyfamiliar


Development

flexibilityRigorous

Occasional

relaxation

Some

relaxation

General

conformity

Some

conformity

General

goals

Architecture riskresolution

Little

20%

Some

40%

Often

60%

Generally75%

Mostly

90%

Full

100%

Team cohesion

Very difficult

interactions

Some difficult

interactions

Basically

cooperative

Largely

cooperative

Highly

Cooperative

Seamless

interactions

Process maturity Level 1 Level 2 Level 2+ Level 3 Level 4 Level 5



72/86

y g g

Scale Factor (Contd)

Calculate the scale factor based on theequation

=


.



73/86

y g g

Effort Multiplier

7 factors in Effort Multiplier product Reliability and ComPleXity (RCPX)

required reusability (RUSE)


Platform DIFficulty (PDIF) PERSonnel capability (PERS)

PeRsonnel EXperience (PREX)

FaCILities available (FCIL) SChEDule pressure (SCED)



74/86

y g g

Effort Multiplier (contd)

Assess each factor byVery low, low, nominal, high, very high,

and extra hi h


Assign each factor using a valuebetween 0.5 and 1.5 (inclusive)

EM is the product of all these values



75/86

Effort Multiplier (contd)

Early Design Very Low Extra High

RCPX 0.5 1.5


PDIF 0.5 1.5PERS 1.5 0.5

PREX 1.5 0.5

FCIL 1.5 0.5

SCED 1.5 0.5



76/86

Example




77/86

The Post-architecture Stage

Estimation after the softwarearchitecture has been defined

he same basic model e uation


Size estimation by KSLOC (preferred) orFPs

Same scale factor estimation

17 factors in EM (7 in early designstage)



78/86

Effort Multiplier

17 factors in 4 different categories

Product attributes


Personnel attributes Project attributes



79/86

Effort Multiplier

Product attributes

Required reliability (RELY)*


Product complexity (CPLX)* Required reuse (RUSE)**

Documentation (DOCU)

*Relate to RCPX in early design stage



80/86

EAF (Contd)

Platform attributes

execution TIME constraint (TIME)*

*


Platform VOLatility (PVOL)**Related to Platform DIFficulty (PDIF) in

early design stage



81/86

EAF (Contd)

Personnel attributes

Analyst CAPabilities (ACAP)^

*


Programmer CAPabilities (PCAP)^ Personnel EXPerience (PEXP)*

programming Language/Tool EXperience

(LTEX)*

Personnel CONtinuity (PCON)^



82/86

EAF (Contd)

Project attributes

use of software TOOLs (TOOL)*


communications (SITE)**Relate to FCIL in early design model


83/86

EAF Relations

Early Design Post-Architecture

RCPX RELY, DATA, CPLX, DOCU


PDIF TIME, STOR, PVOLPERS ACAP, PCAP, PCON

PREX AEXP, PEXP, LTEX

FCIL TOOL, SITE

SCED SCED



84/86

Example




85/86

COCOMO II (contd)

Advantages

Good improvementover COCOMO

Disadvantages

Still immature,diverse projects in


Good match for

iterativedevelopment,modern technology,and managementprocess

a a ase

Hard to believe thatit will be any morereliable than theoriginal COCOMOmodel


86/86

References

Hughes, B., and Cotterell, M. (1999) Software

project management, 2nd ed., McGraw Hill Pfleeger, S.L. (1998) Software Engineering:


,

Royce, W. (1998) Software ProjectManagement: A Unified Framework, AddisonWesley

Center for Software Engineering, USC (1999)COCOMO II Model Definition Manual.

Lecture03-spm

Documents

Transcript of Lecture03-spm