4.Software Estimation

8/8/2019 4.Software Estimation

http://slidepdf.com/reader/full/4software-estimation 1/30

Software Estimation

Tutorial

Presented by Dongwon Kang

ⓒ KAIST SE LAB 2008



Contents

Introduction

Overview of the estimation process

Sizing methods

Source lines of code

Function point

Use case point

Effort estimation methods

Algorithmic models

Expert judgment

Analogy

Best practices for estimation

2 / 29ⓒ KAIST SE LAB 2008



Introduction (1/3)

What is software estimation?

Predicting the resources required for a software developmentprocess

• Effort / cost / schedule

Why do we estimate?

No estimate, no plan and control Crucial to go/no-go decisions on a software project

Essential to establish a budget for a software project

…

ⓒ KAIST SE LAB 2008 3 / 29



Introduction (2/3)

Difficulties in software estimation

Average project exceeded 90% of budget and 120% of schedule

• Standish Group of 8,380 projects (1994)

55% of projects exceeded budget

• 24 companies that developed large distributed systems (1994)




Introduction (3/3)

Why is the estimation so inaccurate?

Uncertainty is unavoidable when predicting the future

• Requirements – often unstable and vague

• Design – preferences of architecture and design may vary

• Implementation – language and development environment

• Testing – degree of extensiveness• Deployment - user acceptance

• Personnel - experience & expertise

• Technology - Multi-platform or not

Finding all the factors affecting a project is almost impossible

Most factors are hard to quantify

We need systematic approaches to help to reduce theinaccuracy of estimates!




Overview of the estimation process (1/2)

6 / 29

Requirements

Environmental andbusiness factors

Staff Skill andAvailability

Define Project(Products, Process)

Identify andEvaluate Risks

Estimate Cost and

Schedule

Work Breakdown Structure

Project Estimate Project PlanBudget andSchedule

Perform PlannedActivities

Project Actuals

Status and Estimateto Complete

Compare Plannedand Actual Values

Organization’s

Historical DataCalibrate

DocumentedEstimation Models

Improve ProcessUpdateProcedures andChecklists

Close out report

Re-estimate Costand Schedule

Changes inRequirements,Design andEnvironment

Revised Inputs

Enhancements

BEFORE

DURING

AFTER

Total Estimation cycle

Source : R. Stutzke, “Estimating Software-intensive Systems”



Overview of the estimation process (2/2)

Bottom-upestimation

history data

Experts

Estimating project size

Algorithmic Models

Expert judgment

Analogy

Algorithmic Models

Expert judgment

Analogy

Top-down

estimation

…

SLOC

Function Point

Use Case Point

…

Projectcharacteristics

Estimating effort

Estimated effort

Apply productivity


Technical view using various techniques



Software Sizing Methods

Estimating Source Lines of Code

Function Point

Use case Point




Estimating Source Lines of Code

Characteristics

Traditional method to measure software size

Developers view of the software

How to estimate?

Experience

Previous / existing system size

Breaking system into pieces (bottom up)

Problems with SLOC estimation

Hard to reflect the complexity

Hard to consider environmental considerations (language, etc.)

“Measuring programming progress by

lines of code is like measuring aircraft

building progress by weight”

Bill Gatesⓒ KAIST SE LAB 2008 9 / 29



Function Point (1/4)

Characteristics

User (functional) view of software

• Calculated from system requirements

• Counts attributes of the planned system

– Inputs, outputs, inquiries, internal logical files, external interface files

Standard is maintained by IFPUG

In Korea, FP is used as a pricing standard of software development

Internal Files

External Inputs

External

Outputs

System Boundary

External Interface File


ExternalInquiries




Attributes

External Inputs (EI)

• Control or business information coming from out of system boundary

– Ex) user input / sensor data

External Outputs (EO)

• Derived data from calculation or applying algorithms, sent to outside – Ex) graphics, reports

External Inquiry (EQ)

• A process that retrieves data from ILF or EIF, including no calculation

Internal Logical Files (ILF)

• Data that reside within application boundary – Ex) database, masterfile

External Interface Files (EIF)

• Data that reside outside the application and is maintained by anotherapplications, used for reference purposes only

– Ex) help message, reference dataⓒ KAIST SE LAB 2008 11 / 29



Calculating unadjusted function point (UFP)

Calculating adjusted function point (AFP)( )

(VAF considers characteristics of the environment and complexity of product)

Low Avg. High

External Input __ x 3 __ x 4 __ x 6

External Output __ x 4 __ x 5 __ x 7

Internal Logical File __ x 7 __ x 10 __ x 15

External Interface File __ x 5 __ x 7 __ x 10External Inquiry __ x 3 __ x 4 __ x 6

3

1

5

1i j

ijij xwUFP

VAF UFP AFP

14

1

01.065.0

i

ir VAF



(Weight is given by the number of data types, number of fields, etc.)



1. Data communications2. Distributed functions3. Performance4. Heavily used configuration5. Transaction rate

6. Online data entry7. End user efficiency8. Online update9. Complex processing10. Reusability11. Installation ease

12. Operational ease13. Multiple sites14. Facilitates change

5 – Very Influential

0 – No Influence


Value adjustment factor (VAF)




Use Case Point (1/2)

Characteristics

Sizing based on use-cases

• Intuitive to stakeholders and project team

• Traceable for controlling projects

Derived from function points

Consider actors, use-cases, technical factors and environmentalfactors




Use Case Point (2/2)

Calculating Unadjusted Use Case Point (UUCP)

UUCP = UAW + UUCW

• Unadjusted Actor Weights (UAW) = ∑(# Actors* weight factor)

– Weight is decided by complexity of communication with actors

• Unadjusted Use Case Weights (UUCW) = ∑(# Use Cases* weight

factor)

– Weight is decided by # of transactions

Calculating adjusted Use Case Point (UCP)

UCP = UUCP * TCF * EF

• Technical Complexity Factor (TCF) = 0.6+0.01*Tfactor

– Derived from Function Points• Environmental Factor (EF) = 1.4 + (-0.03*EFactor)

– Based on the interview from Objectory




Comparison of sizing methods

SLOC Function Point Use Case Point

Viewpoints Developer User (functionality) User (functionality)

Collecting phase Early After basic requirementanalysis

After identifying usecases

Understandability ofconcepts

Easy Not intuitive and difficultto communicate

Relatively easy

Ease of collecting data

from previous projects

Easy to automate Difficult to automate Requires use-case

document

Subjectivity ofestimation

High Relatively objective, butstill easy to get biasedaccording to estimators

Subjective creation ofuse cases

Expertise needed forestimation

Experience needed Specialized trainingneeded

None

Limitations Unable to reflectcomplexity

/ Dependent onlanguages

/ not suitable for web orIDE

Hard to reflect internalcomplexity

/ Time consuming / Hard to apply to acorrective maintenanceproject

Granularity of use casesmay vary according toanalysts




Estimation Method

Techniques for estimation

Algorithmic models

Expert judgment

Analogy

Top-down and bottom-up estimation




Algorithmic models (1/3)

Characteristics

Use a mathematical formulae for estimation

• Yielded from analysis of historical data

• Regression is widely used for algorithmic models

Calibration using local history data is strongly required

• Project environments vary according to the characteristics of eachorganization

• Information of a new project environment need to be updated to themodel





Example - COCOMO II

Application composition model

• Used when software is prototyped or composed from existing parts

• Utilizing Object Point, similar to Function Point, and productivityinformation

– Counting the number of screens, reports and 3GL modules

Early design model

• Used when requirements are available but design has not yet started

Post-architecture model

• Used once the system architecture has been designed and moreinformation about the system is available

Reuse model

• Used to compute the effort of integrating reusable components





Example - COCOMO II (Cont’d)

Early design model and post-architecture model utilize the form offormula “Effort = A x SizeB x M”

• For sizing, SLOC or FP is used

• A: organization-dependent constant

• B: scale factors

– Factors affecting the effort in an exponential manner

• M: effort Multipliers

– Supports four categories - product factors, platform factors,personnel factors, project factors

– Early design model supports 7 factors, while post-architecture model

supports 17 factors, according to the available amount of information




Expert judgment

Characteristics

Utilize personal expertise and experience in estimation

One of the most commonly used method for estimation

• Not requires preparation such as data and models

Example - Wideband Delphi

1. Coordinator explains the project 2. Coordinator calls a group meeting to discuss estimation issues

3. Experts fill out estimation forms anonymously

4. Coordinator distributes a summery of the estimates

5. Coordinator calls a group meeting to discuss points where theirestimates varied widely

6. Experts fill out forms again anonymously and Step 4 to 6 areiterated for as many rounds as appropriate




Characteristics

Effort is estimated by comparing the project to a similar project inthe same application domain

Estimation can be done either at the total project level or at asubsystem level

Process 1. Selection of analogous projects

2. Assessing similarities and differences

3. Adjust the estimate using the difference

4. Consideration of any special cases

5. Creating the estimate

Analogy

(http://www.ecfc.u-net.com)




Comparison of estimation techniques

Algorithmic models Expert judgment Analogy

Approach Building statistical model Depending on experts’opinion

Measuring similarity andadjustment

Need for data Yes (for calibration) No Yes

Need for expert Low High Low

Strong point Objective, repeatable,analyzable formula

/ Suitable for sensitivityanalysis

Relatively cheapestimation

/ Accurate if expertshave direct experienceof similar systems

Based on actualexperience on a project

Week point Weak against exceptionalcircumstances

/ calibrated to past, notfuture

/ No better thanparticipants

/ The result may bebiased

Requires accuratedetails on many pastprojects/ Doesn’t work if similar

project doesn’t exist / Hard to define thesimilarity betweenprojects




Top-down and bottom-up estimation (1/4)

Any of above approaches may be used top-down or

bottom-up

Top-down

Starts at the system level and assess the overall systemfunctionality and how this is delivered through sub-systems

Does not consider details at first• Usable without knowledge of the architecture and the components

• Can underestimate the cost of solving difficult low-level technicalproblems




Bottom-up Start at the component level and estimate the effort required for

each component

Usable when the architecture of the system is known andcomponents identified

Accurate if the system has been designed in detail

May underestimate the costs of system level activities such asintegration and documentation





Process-based estimation

Most commonly-used technique for project estimation

Project is broken down into a relatively small set of tasks and theeffort required to accomplish each task is estimated

• Bottom up estimation

Process

• Begins with outlining software functions obtained from the projectscope

• Once functions and activities are identified, the planner estimates theeffort (person-months) required to accomplish each activity perfunction

• Average labor rates are then applied to the estimated efforts(i.e. cost per unit effort - may vary per task)

• Cost and effort for each function and activity (row and column totals)are computed as the last step





Activity CC PlanningRisk

analysisEngineering Release CE Totals

Task → Anal. Design Code Test

Function ↓

UICF 0.75 2.50 0.40 5.00 n/a 8.653DGA 0.50 4.00 0.60 2.00 n/a 7.10

CGDF 0.50 4.00 1.00 3.00 n/a 8.50

DBM 0.50 3.00 1.00 1.50 n/a 6.00

PCF 0.25 2.00 0.75 1.50 n/a 4.50

DAM 0.50 2.00 0.50 2.00 n/a 5.00

Totals .25 .25 .25 3.00 17.50 4.25 15.00 34.80

% effort 1% 1% 1% 7% 45% 12% 40%

Process-based estimation (Cont’d)

Example – CAD software

CC: Customer communicationCE: Customer evaluation

UICF: User interface and control facilities3DGA: Three-dimensional geometric analysisCGDF: Computer graphics display facilitiesDBM: Database managementPCF: Peripheral control functionDAM: Design analysis modules





Best practices for estimation (1/2)

Estimate early and often!

Cost estimation should be done throughout the software life cycle

• Allow refinement according to changes

Select experts with similar experience on the project

Ask justification

Can help to reduce mistakes in consideration of estimation

Gather and analyze historical data

Must perform calibration when using algorithmic models

Do a final assessment of cost estimation at the end of the

project Identify problems in estimation




Best practices for estimation (2/2)

Avoid informal estimates due to the pressure from

management Allow time for estimation and plan for it

Use developer-based estimates

Manager based estimates are easy to be biased to the positive side

and not to reflect the realistic development environment

Estimate at a low level of detail, if possible

Can be more accurate with considering details




Q & A?

Documents

4.Software Estimation