Project Estimation

Topic 5

Learning outcome
• To introduce Software estimation and its objectives • To describe Software Estimation techniques • To explore Estimation issue, factor and improvement

Software cost estimation
Predicting the resources required for a software development process

• To monitor progress against that budget by comparing planned with estimated costs. . • To establish a cost database for future estimation.Cost estimation objectives • To establish a budget for a software project. • To provide a means of controlling project costs. • Cost estimation and planning/scheduling are closely related activities.

• Effort costs must take overheads into account – Costs of building. – Costs of shared facilities (e. – Costs of networking and communications. heating. – Social and insurance costs. etc. . staff restaurant.).g library.Software cost components • Hardware and software costs. • Effort costs (the dominant factor in most projects) – The salaries of engineers involved in the project. • Travel and training costs. lighting.

Traditional Project Management Approaches • • • • • • • Guesstimating Delphi Technique Time Boxing Top-Down Bottom-Up Three point Analogous Estimates (Past experiences) .Estimation Techniques .

or guess at the estimates. Unfortunately. because it is quick and easy. many inexperienced project managers tend to guesstimate.Guestimating Estimation by guessing or just picking numbers out of the air is not the best way to derive a project’s schedule and budget. .

anonymous experts • Each expert makes an estimate • Estimates compared – If close. can be averaged – If not.Delphi Technique • Involves multiple. do another iteration until consensus is reached .

or deliverable • Can focus a team if used effectively • Can demoralize a team if not used effectively . task.Time Boxing • A “box” of time is allocated for a specific activity.

Top-Down • Top & middle managers determine overall project schedule &/or cost • Lower level managers are expected to breakdown schedule/budget estimates into specific activities (WBS) .

Bottom-Up • Schedules & budgets are constructed from WBS • Starts with people who will be doing the work • Schedules & budgets are the aggregate of detailed activities & costs .

or LOC.Analogous Estimates • Use information from previous. or Function Points . similar projects as a basis for estimation – Usually done in a “Top-down” approach – Have 3 or 4 experts review requirements – Make sure you have the experience and that the two systems are very similar – Can use time.

and the standard deviation (SD) are: – E = (a + 4b + c)/6. Normal. SD = (c-a)/6 a = the optimistic estimate b = normal estimate c = pessimistic estimate . Pessimistic • Equations for expected value (E).Three Point • Use a weighted average approach or beta probability distribution approach to capture three point estimates for each work package – Optimistic.

Three Point • Adds the element of risk into its calculations • SME’s determine three types of estimates: – Most Likely – Optimistic – Pessimistic • Next the SME uses the weighted average formula .

you’d use 12 days on the schedule instead of 10 when using this technique. .Three Point Example Weighted average = 8 workdays + 4 X 10 workdays + 24 workdays = 12 days 6 E = (a + 4b + c)/6 where: optimistic time= 8 days most likely time = 10 days pessimistic time = 24 days Therefore.

2.2. or combination of techniques.2 Test Results Report 6.Estimates are made for each activity in the WBS 6.2.2 Carry out test plan 6.5 Present test results to client 6.6 Address any software issues or problems 1 day 5 days 2 days 3 days 1 day 5 days How did we come up with these estimates? Using a technique.4 Prepare test results report and presentation 6.2.2.3 Analyze results 6. with the exception of guestimating! .2.1 Review test plan with client 6.

Estimating Techniques Software Engineering Approaches • Lines of Code (LOC) • Function Points • COCOMO .

dollars. in most environments automatically – Facilitate a lessons-learned process . and number of resources • Advantages – – – – Can be very quick and inexpensive to generate Can be done early in the process Universal metric Can be generated easily.Task Sizing – Lines of Code • Has been one of the most used methods • Based on historical results • Effort. documentation. software bugs.

Lines of Code .Disadvantages • • • • • • Must compensate for technology differences Can’t be done well unless relevant history exists Must determine what counts as a line of code What level of resource is generating the code No industry standards Need to distinguish between auto-generated code and original work • Needs to be continually updated .

Function Points Analysis • used to estimate time and dollars based on the generated system requirements specification • A function point measures the size of a business function that the new system needs to have such as an input screen or report • Function Point analysis can be done at any point in the project but are not considered accurate until late in the planning phase .

user outputs.65 + 0. data structures.Process of Function Points Step 1: Count the number of business functions within each of the following categories: user inputs. or complex. inquiries. Step 3: Assign weights for each level of complexity within each category Step 4: Multiply each function by its weight and then sum each product to obtain the total unadjusted function points. For example output complexity is determined by the number of elements involved. any complex calculations or complex process logic and the number of data structures. Step 5: Compute the Value Adjustment Factor (VAF) Step 6: Compute adjusted function point total using the formula [Unadjusted total x (0.01 x VAF)] . medium. and external interfaces Step 2: Determine the complexity level of each function as simple.

Example .

Next Step: compute the value adjustment factor based on the following table 0 = no effect 1 = incidental 2 = moderate 3 = average 4 = significant 5 = essential .

Function Points • Next: calculate the total adjusted function points: Unadjusted total x (0.04 per f/point) (1102.01 x VAF) or  1050 x (0.25 pages per f/point) (1102.75 .872.50) = 275.50) = 44.63 pages – Bugs (.50) = 27.5 bugs – User Instructed Rework (.50) = 1.65 + 0.642.7 hrs – Documentation (.50) = $115.1 – Dollars ($105.65 + 0.025 bugs per f/point) (1102.01 x 40) = 1102.49 hrs effort per f/point) (1102.50 • Results – Effort = (1.10 per f/point) (1102.

novice) Cost per FP • New derivative called “Feature Points” or “Object Points” .Uses for Function Points • • • • # of pages of documentation per FP Levels of effort per FP (person months) Level of expertise per FP (expert.

Advantages with Function Points • It is independent of programming language and technology • It can be used early in the project life cycle at the end of the requirements discovery phase or design phase • A wealth of research exists to support the process • Impact of scope changes easier for all to comprehend and track • Organizations can track their own results and improve the function point estimates • It can be used in any development environment .

Issues with Function Points • Requires many subjective evaluations (complexity ratings and environmental factors) • Accuracy is greatly increased only after the detailed design phase or after a few project iterations have been performed • Takes some time (training) to perfect and can vary depending on who is doing the calculations due to personal bias .

• Models available on website and algorithms are published. O-O application distribution. COTS packages. Iterative/Incremental. etc. RAD. Commercial software exists .COCOMO • • • • • COnstructive COst MOdel First developed by Barry Boehm in 1981 Most widely accepted models available today Revised into version II in 1995 Version II setup to handle new development methodologies. frameworks and components.

constraints and deadlines are few. and more changes expected.COCOMO • Consists of three project types described as: – Organic – small project teams. few changes expected – Semidetached – medium sized project teams. many constraints. stable development environments. few constraints. some innovation. still a fairly stable development environment – Embedded – largest of the three in all categories. and many changes expected. known familiar technology. complex development environment . little innovation. very tight deadlines. constant innovation. large project teams. tighter deadlines.

32 .12 – Duration = 2.5 x Effort0.5 x Effort0.4 x KLOC1.05 where KLOC = 1000 lines of code – Duration = 2.35 • Embedded – Effort = 3.38 • Semidetached – Effort = 3.20 – Duration = 2.6 x KLOC1.COCOMO Effort Sizing • Organic: – Effort = 2.5 x Effort0.0 x KLOC1.

12 = 42.12 = 3.6) 1.0 * (10.0 * KLOC1.21 .COCOMO – Effort Example • Semi-Detached 10.600 Java LOC = 200 FP * 53 Effort = 3.

21 / 9.55 .26 = 4.21)0.35 = 9.26 months People Required = Effort / Duration = 42.5 *(42.35 = 2.5 * Effort0.COCOMO Duration Example Duration = 2.

COCOMO Advantages • • • • • Can be Quick Can be done early in the project Can be tailored to fit any organization Can be applied at different phases of the life cycle Many models exist to aid organizations in getting started .

other phases of the project (planning. implementation) are not accounted for .COCOMO Issues • Ignores documentation and other requirements • No compensation for customer attributes (availability. knowledge. cooperation) • Ignores personnel turnover issues • Based on historical data which may be obsolete • Used only to estimate the development effort.

What can cause inaccurate estimates? • Scope changes • Overlooked tasks • Poor developeruser communication • Poor understanding of project goals • Insufficient analysis • No (or poor) methodology • Changes in team • Red tape • Lack of project control • Not identifying or understanding impact of risks .

Other Factors to Consider When Estimating • • • • • • • • • Rate at which requirements may change Experience & capabilities of project team Process or methods used in development Specific activities to be performed Programming languages or development tools to be used Probable number of bugs or defects & removal methods Environment or ergonomics of work space Geographic separation of team across locations Schedule pressure placed on the team .

How can estimates be improved? • Experience! – Lessons learned – Best Practices • • • • Revision Monitor Focus on deliverables Control .

Questions? .