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

Cost estimation objectives

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

Software cost components

Hardware and software costs. Travel and training costs. Effort costs (the dominant factor in most projects)
The salaries of engineers involved in the project; Social and insurance costs.

Effort costs must take overheads into account

Costs of building, heating, lighting. Costs of networking and communications. Costs of shared facilities (e.g library, staff restaurant, etc.).

Estimation Techniques - Traditional Project Management Approaches

Guesstimating Delphi Technique Time Boxing Top-Down Bottom-Up Three point Analogous Estimates (Past experiences)

Guestimating

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

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

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

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

Analogous Estimates
Use information from previous, 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, or LOC, or Function Points

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

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

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, youd use 12 days on the schedule instead of 10 when using this technique.

Estimates are made for each activity in the WBS

6.2 Test Results Report 6.2.1 Review test plan with client 6.2.2 Carry out test plan 6.2.3 Analyze results 6.2.4 Prepare test results report and presentation 6.2.5 Present test results to client 6.2.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, or combination of techniques, with the exception of guestimating!

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

Task Sizing Lines of Code

Has been one of the most used methods Based on historical results Effort, dollars, documentation, software bugs, 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, in most environments automatically Facilitate a lessons-learned process

Lines of Code - Disadvantages

Must compensate for technology differences Cant 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

Process of Function Points

Step 1: Count the number of business functions within each of the following categories: user inputs, user outputs, inquiries, data structures, and external interfaces Step 2: Determine the complexity level of each function as simple, medium, or complex. 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 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. Step 5: Compute the Value Adjustment Factor (VAF) Step 6: Compute adjusted function point total using the formula [Unadjusted total x (0.65 + 0.01 x VAF)]

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.65 + 0.01 x VAF) or
1050 x (0.65 + 0.01 x 40) = 1102.50 Results

Effort = (1.49 hrs effort per f/point) (1102.50) = 1,642.7 hrs Documentation (.25 pages per f/point) (1102.50) = 275.63 pages Bugs (.025 bugs per f/point) (1102.50) = 27.5 bugs User Instructed Rework (.04 per f/point) (1102.50) = 44.1 Dollars ($105.10 per f/point) (1102.50) = $115,872.75

Uses for Function Points

# of pages of documentation per FP Levels of effort per FP (person months) Level of expertise per FP (expert, novice) Cost per FP

New derivative called Feature Points or Object Points

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

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; RAD, Iterative/Incremental, COTS packages, O-O application distribution, frameworks and components, etc. Models available on website and algorithms are published. Commercial software exists

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

COCOMO Effort Sizing

Organic:
Effort = 2.4 x KLOC1.05 where KLOC = 1000 lines of code Duration = 2.5 x Effort0.38

Semidetached
Effort = 3.0 x KLOC1.12 Duration = 2.5 x Effort0.35

Embedded
Effort = 3.6 x KLOC1.20 Duration = 2.5 x Effort0.32

COCOMO Effort Example

Semi-Detached 10,600 Java LOC = 200 FP * 53 Effort = 3.0 * KLOC1.12 = 3.0 * (10.6) 1.12 = 42.21

COCOMO Duration Example

Duration = 2.5 * Effort0.35 = 2.5 *(42.21)0.35 = 9.26 months People Required = Effort / Duration = 42.21 / 9.26 = 4.55

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

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, other phases of the project (planning, implementation) are not accounted for

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?