Software Development: Tools and Processes Lecture - 16: Estimation - - PowerPoint PPT Presentation

Software Development: Tools and Processes

Lecture - 16: Estimation

Estimating methods

• analogy method
• direct estimating method
• Delphi technique
• PERT-type
• ‘rolling window’
• Constructivist Cost Model (CoCoMo)
• Function Point

Estimate based on similar project/task – similar type of application – overall size of application – scope of system - functions, operations etc. Advantages: – quick - good for bids/quotations – effective in specialist environments Disadvantages?

Analogy method

Most detailed technique - relies on breakdown: – use of work breakdown structure or outline – decompose downwards, summate upwards – estimates of labour-intensive activities are based

• n a number of labour units

Difficulties in direct estimating: – insufficient data for breakdown at start – time & effort consuming – cost of estimate vs. value of having estimate – method of carrying out task or number of resource units may change after estimate is made!

Direct estimating method

Delphi technique

Estimates ‘gathered’ & synthesized into total:

• each estimator given specification of task(s)
• estimates given independently/anonymously
• summary of all estimates circulated to all
• estimators re-estimate based on others’

Advantages

• overcomes ‘personal’ factors
• allows ‘climb-down’ without loss of face
• ‘quiet’ people have estimates considered too

Disadvantages?

Single-figure time estimate likely to be ‘wrong’:

– probabilistic estimates - for a range of values

• 15 days +/- 4 days

– involve team to make range of estimates of each task

• time O - most optimistic (shortest) estimate
• time M - most likely (average or frequent) estimate
• time P - most pessimistic (longest) estimate

– adjust to single value (O + 4M + P)/6 = estimate – adjust for productivity: – summate all values on critical path

‘PERT-type’ Estimating

Rolling -window Estimates

As accurate as they need to be at the time: – ‘ball park’

• early stages
• little detailed information available

– comparative

• when enough is known to compare with similar tasks

– final

• ‘best’ estimate when detailed design work done

– actual

• 100% accurate when the task is complete & recorded!

Accuracy improves as knowledge improves...

Software estimation

• Most difficult part of software project management
• Theoretically it is possible to execute a project

first and compute the cost at the end of the project.

• But No one wants to be involved before knowing

about expected cost

Software estimation

Effort and scheduling estimation is done for two reasons: For Business Reasons

– Proposals are prepared and judged – Contracts rely on these – Essential for viable business options

For Project Management Reasons

– Basic goal of project management – cost and time – Fundamental requirement for effective project plans

Relationship of Effort and Cost

• Cost estimates depend upon effort estimates
• Cost is usually proportional to the effort

required. True for other disciplines?

• Effort estimates is converted to actual cost

using rates for per unit effort

• A project estimated to be of 100 man-days

completed in 100 man days – What about the Quality of Estimate?

• Accuracy of the estimates depend on the

point where effort is estimated

What is Software estimation

Effort Estimation Can be done through:

• Gut Feeling
• Previous Experience
• Estimation model

Software estimation

There are two approaches to estimation:

• Top-Down approach
• Bottom-Up approach

Top Down Approach

Characteristics:

• Info about the project: size of software
• Can be used for conversion or re-engineering projects
• Generally built from data of completed projects
• Completed projects give actual size & actual effort
• The size of the whole software is estimated
• The effort for this is estimated using some equations
• Effort for different activities/phases are determined as % of total

Methodology:

• The size is calculated in LOC or Function Points
• The productivity level is fixed for the project (size dependent)
• Get the over all effort estimate
• Use the effort distribution data from process capability baseline

Calculating the software size

COCOMO model for estimation:

• First estimates the effort based on size only
• Corrects the estimates based on value of 15

different parameters Function Points model for estimation:

• Unadjusted function point count
• Adjustment of size based on 14 different

system characteristics

Constructivist Cost Model (CoCoMo)

• common model that has been around a long time
• based on lines of code (LOC) or thousands of lines of code

(KLOC)

• CoCoMo has three forms:

simple intermediate detailed

• based on the following formula

PM = c (KLOC) k * M

Constructivist Cost Model (CoCoMo)

Project judged as simple, moderate or embedded

Simple PM = 2.4(KLOC)1.05 * M Moderate PM = 2.4(KLOC)1.12 * M Embedded PM = 3.6(KLOC)1.20 * M

Constructivist Cost Model (CoCoMo)

Example

COCOMO formulas for person-months of effort and development time in chronological orders are as follows:- Person-months = 2.4 KLOC1.05 = E for effort Duration (months) = 2.5 X E 0.38 For a job requiring 50,000 lines of code Person-months = 2.4 X 50 1.05 = 145.925 months Duration = 2.5 X 145.925 0.38 = 16.6 months

Constructivist Cost Model (CoCoMo)

Advantages:

• derived from ‘close analysis of 100s of s/w projects’
• claims to have been validated in practice
• has been subject to three major updates

Disadvantages

• based on KLOCs
• not available at start of project!
• does not apply to ‘non-S/W’ parts of project
• not clear how tools affects estimating
• appears to reward inefficiency

Bottom Up Approach

Characteristics:

• Info about the project: list of tasks
• Estimates are obtained for parts of project
• This approach is activity-based estimation
• Gets direct estimates of effort – explicit size estimates not required
• This approach can work without past data using experience
• Useful when project has mix of languages, technologies

Limitations:

• One may miss some important activities
• Estimation of overhead tasks like project management is difficult
• These are tedious to apply

Methodology:

• Divide the software into major programs
• Each unit is classified as complex, medium or simple (criteria ?)
• Build effort for each type of units is calculated (experience, data)
• Total no of units in each category gives the Build Phase Effort
• The effort for other phases & activities is percentage of coding. (PCB)
• Refine the estimates based on project specific factors

Module classification criteria

Module classification

After calculating the coding effort, calculate the effort required for other phasesActivities:

• Requirement Analysis
• Design
• Build …etc

Function Point Analysis (FPA)

Characteristics:

• Function points (FPs) are one additional software project management

tool

• FPs measure the size of software project’s work output
• FPs do not measure the effort required to build the software
• FPs evaluate the size of functional user requirements delivered by

software

• FPs measure what the software must do from user perspective
• All software satisfy user requirements, therefore these can be measured

in FPs

• FPs are independent of physical implementation and languages and thus

can be used to normalize the productivity

Methodology:

• Identify the application boundary
• Software is divided into five logical components based
• n user requirements
• Each of the components are categorized as low,

medium, and complex

• Each of the components are assigned “some” function

pts (refer FPC manual)

• Determine the value of adjustment factor based in user

business constraints and system characteristics e.g. performance, reusability, distributed applications, multiple sites etc.

Function Point Analysis (FPA)

Function Point Analysis (FPA)

The five Logical Components are:

• Internal Logical files (ILFs) – logical persistent entities e.g. a

student entity in a course registration software

• External Interface files (EIFs) – logical persistent entities

referenced by this software but maintained by other software e.g. reference to a flat file created by other application

• External Inputs (EIs) – logical business processes used to

maintain the data of an ILF e.g. adding a student to the database is a user function

• External Outputs (Eos) – logical business processes that

result in data leaving the application boundary e.g. report, data files, screen alerts

• External Queries (EQs) – logical business processes that

result in “data retrieval which leave the application”. These are question and answer pair that result in data retrieval

Function Point Computation

UFP = count-total * (0.65 +(0 .01 * SUM(Fi))

UFP = Unadjusted Function Points Fi = complexity adjustment values

Adjusted Function points = UFP * Adjustment Factor

Complexity Adjustment Values

Will vary from organisation but include

• reliable backup & recovery factors
• data communications requirements
• distributed processing functions
• performance requirements
• operational environment
• on-line data entry requirements
• multiple screen requirements
• on-line master file update requirements
• input, output , file or inquiry complexity
• internal processing complexity
• reusability requirements
• conversion & installation requirements
• multiple installation/inter-organizational

requirements

• ease of use and change requirements

Applications of function points

• Measure of a number of SW attributes

Productivity = AFP / person-month Quality = defects / AFP Cost = $ / AFP Document = pages of documentation / AFP

• Estimating

can get figures of previous costs, etc / AFP

Function Point Analysis (FPA)

Example: Create an application to store the students data including name, address, roll no., DOB, phone no. User should be able to add new students, update the information, and delete student records. The software should provide a weekly report of students whose information has

• changed. User should be able to browse the student’s

data.

• ILF – one: student one*7 = 7 FPs
• EI – three: add, update, delete three*3 = 9 FPs
• EO – one: report one*4 = 4 FPs
• EQ – one: browse one*3 = 3FPs