This action might not be possible to undo. Are you sure you want to continue?
• 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 establish a cost database for future estimation.Cost estimation objectives • To establish a budget for a software project. • To monitor progress against that budget by comparing planned with estimated costs. • To provide a means of controlling project costs. • Cost estimation and planning/scheduling are closely related activities.
• Effort costs (the dominant factor in most projects) – The salaries of engineers involved in the project. lighting. staff restaurant. – Social and insurance costs. • Travel and training costs. – Costs of networking and communications. • Effort costs must take overheads into account – Costs of building. – Costs of shared facilities (e. etc.g library.). .Software cost components • Hardware and software costs. heating.
Estimation Techniques .Traditional Project Management Approaches • • • • • • • Guesstimating Delphi Technique Time Boxing Top-Down Bottom-Up Three point Analogous Estimates (Past experiences) .
Unfortunately. many inexperienced project managers tend to guesstimate. or guess at the estimates. . because it is quick and easy.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. do another iteration until consensus is reached . can be averaged – If not.Delphi Technique • Involves multiple.
Time Boxing • A “box” of time is allocated for a specific activity. or deliverable • Can focus a team if used effectively • Can demoralize a team if not used effectively . task.
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. 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 Function Points .
SD = (c-a)/6 a = the optimistic estimate b = normal estimate c = pessimistic estimate . Pessimistic • Equations for expected value (E). and the standard deviation (SD) are: – E = (a + 4b + c)/6.Three Point • Use a weighted average approach or beta probability distribution approach to capture three point estimates for each work package – Optimistic. Normal.
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 Test Results Report 6.3 Analyze results 6.Estimates are made for each activity in the WBS 6.4 Prepare test results report and presentation 6. or combination of techniques.5 Present test results to client 6.2.1 Review test plan with client 6.2.2 Carry out test plan 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.2. with the exception of guestimating! .2.2.
Estimating Techniques Software Engineering Approaches • Lines of Code (LOC) • Function Points • COCOMO .
in most environments automatically – Facilitate a lessons-learned process .Task Sizing – Lines of Code • Has been one of the most used methods • Based on historical results • Effort. 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. dollars. documentation. software bugs.
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 .Lines of Code .
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 .
For example output complexity is determined by the number of elements involved.Process of Function Points Step 1: Count the number of business functions within each of the following categories: user inputs. 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. inquiries.65 + 0. or complex. and external interfaces Step 2: Determine the complexity level of each function as simple. Step 5: Compute the Value Adjustment Factor (VAF) Step 6: Compute adjusted function point total using the formula [Unadjusted total x (0. user outputs. medium. any complex calculations or complex process logic and the number of data structures.01 x VAF)] .
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 .
7 hrs – Documentation (.1 – Dollars ($105.50) = 27.50) = 44.Function Points • Next: calculate the total adjusted function points: Unadjusted total x (0.10 per f/point) (1102.04 per f/point) (1102.50) = 1.01 x VAF) or 1050 x (0.01 x 40) = 1102.75 .49 hrs effort per f/point) (1102.65 + 0.50) = $115.025 bugs per f/point) (1102.65 + 0.25 pages per f/point) (1102.5 bugs – User Instructed Rework (.872.63 pages – Bugs (.50) = 275.642.50 • Results – Effort = (1.
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 .
Iterative/Incremental. 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. • Models available on website and algorithms are published. RAD. frameworks and components. etc. O-O application distribution. COTS packages.
and many changes expected. tighter deadlines. stable development environments.COCOMO • Consists of three project types described as: – Organic – small project teams. large project teams. and more changes expected. few constraints. few changes expected – Semidetached – medium sized project teams. still a fairly stable development environment – Embedded – largest of the three in all categories. known familiar technology. complex development environment . very tight deadlines. some innovation. little innovation. constraints and deadlines are few. constant innovation. many constraints.
5 x Effort0.35 • Embedded – Effort = 3.0 x KLOC1.12 – Duration = 2.32 .6 x KLOC1.4 x KLOC1.5 x Effort0.38 • Semidetached – Effort = 3.05 where KLOC = 1000 lines of code – Duration = 2.5 x Effort0.20 – Duration = 2.COCOMO Effort Sizing • Organic: – Effort = 2.
12 = 3.6) 1.21 .COCOMO – Effort Example • Semi-Detached 10.600 Java LOC = 200 FP * 53 Effort = 3.0 * KLOC1.0 * (10.12 = 42.
26 = 4.21 / 9.26 months People Required = Effort / Duration = 42.COCOMO Duration Example Duration = 2.21)0.5 *(42.5 * Effort0.55 .35 = 2.35 = 9.
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 .
cooperation) • Ignores personnel turnover issues • Based on historical data which may be obsolete • Used only to estimate the development effort.COCOMO Issues • Ignores documentation and other requirements • No compensation for customer attributes (availability. implementation) are not accounted for . knowledge. other phases of the project (planning.
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 .
This action might not be possible to undo. Are you sure you want to continue?
We've moved you to where you read on your other device.
Get the full title to continue reading from where you left off, or restart the preview.