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
Analogy method 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?
Direct estimating 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 on 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!
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?
‘PERT-type’ Estimating 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
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 KLOC 1.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
Function Point Analysis (FPA) Methodology: • Identify the application boundary • Software is divided into five logical components based on 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) 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(F i )) UFP = Unadjusted Function Points F i = complexity adjustment values Adjusted Function points = UFP * Adjustment Factor
Recommend
More recommend
