Software Development: Tools and Processes. Lecture - 16: Estimation

Transcription

1 Software Development: Tools and Processes Lecture - 16: Estimation

2 Estimating methods analogy method direct estimating method Delphi technique PERT-type rolling window Constructivist Cost Model (CoCoMo) Function Point

3 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?

4 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!

5 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?

6 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

7 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...

8 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

9 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

10 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

11 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

12 What is Software estimation Effort Estimation Can be done through: Gut Feeling Previous Experience Estimation model

13 Software estimation There are two approaches to estimation: Top-Down approach Bottom-Up approach

14 Characteristics: Top Down Approach 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

15 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

16 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

17 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

18 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 = months Duration = 2.5 X = 16.6 months

19 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

20 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

21 Module classification criteria

22 Module classification After calculating the coding effort, calculate the effort required for other phasesactivities: Requirement Analysis Design Build etc

23 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

24 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.

25 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

26

27 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

28 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

29 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

30 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