8--Estimation Chapter An accurate schedule estimate is part of the foundation of maximum development speed. Without an accurate schedule estimate, there is no foundation for effective planning and no support for rapid development/ Coming up with a perfect estimate doesn't do any good if you can't get the estimate accepted. I. The Software-Estimation Story
1. When constructing software, you can't tell exactly how much it is going to cost until you know exactly what "it" is. 2. If you want to build to a budget, you have to be very flexible about the product characteristics. 3. Whether you build to a budget or not, software development is a process of gradual refinement, so some imprecision is unavoidable. The only way to refine the product concept and thereby the estimate is to actually build the software. 4. Estimates can be refined over the course of a project. Promise your customer that you will provide more refined estimates at each stage. The basic software-estimation story is that software development is a process of gradual refinement. You begin with a fuzzy picture of what you want to build and then spend the rest of the project trying to bring that picture into clearer focus. Software development is a process of making increasingly detailed decisions. You refine the product concept into a statement of requirements, the requirements into a preliminary design, the preliminary design into a detailed design, and the detailed design into working code. Most software customers initially want more than they can afford. This means they have to bend either their ideas about the product or their ideas about the resources they are willing to commit. Software builders face a choice between estimation accuracy and project control. If you can be flexible about the product characteristics, you can have some control over cost and schedule and can "build to budget". Help your customers by telling them about the parts of the project that you are able to estimate. Tell them where the next landmark is. If customers want the shortest possible schedule, they should not pressure you to lower your estimates or to provide them with misleadingly precise estimates. An estimate that is either too low or too high will result in a longer-than-optimal actual schedule. Shortest-possible software schedules are achieved by creating the most accurate estimates possible, not the most precise. I. Estimation-Process Overview
The process of creating an accurate development schedule consists of three steps: 1. 2. 3. 4. II. Estimate the size of the product (number of lines of code or function points). Estimate the effort (man-months) Estimate the schedule (calendar months) Provide estimates in ranges and periodically refine the ranges to provide increasing precision as the project progresses. Size Estimation
You can estimate the size of a project in any of several ways: 1. Use an algorithmic approach, such as function points, that estimates program size from program features. 2. Use size-estimation software that estimates program size from your description of program features (screens, dialogs, files, database tables, and so on). 3. Estimate each major piece of the new system as a percentage of the size of a similar piece of a similar project. A. Function-Point Estimation See class lectures. B. Estimation Tips
1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Avoid off-the-cuff estimates Allow time for the estimate, and plan it Use data from previous projects Use developer-based estimates Estimate by walk-through Estimate by categories Estimate as a low level of detail Don't omit common tasks Use software estimation tools Use several different estimation techniques, and compare the results Change estimation practices as the project progresses
C. Estimate Presentation Styles The way you present an estimate initially can have a huge impact on what happens when the estimate needs changing later. Software estimation usually involves a great deal of risk and uncertainty, and a good estimate captures that risk and uncertainty. Some techniques for presenting schedule estimates: 1. Plus-or-minus qualifiers 2. Ranges 3. Risk quantification--when you document the sources of uncertainty in your estimates, you provide your customers with information they can use to reduce the risks to the project and you lay the groundwork for explaining schedule changes if any of the risks materialize. 4. Cases--present your estimates for best case, worst case, planned case, and current case. III. Effort Estimation
You'll need an effort estimate in order to know how many people to pout on your project; and having an effort estimate makes it easy to derive the schedule estimate. Some ways to convert a size estimate into an effort estimate: 1. Use estimation software to create an effort estimate directly from the size software. 2. Use the schedule tables in Chapter 8 3. Use your organization's historical data to determine how much effort previous project of the estimated size have taken. 4. Use an algorithmic approach such as the COCOMO model to convert a lines-of-code estimate into an effort estimate. IV. Schedule Estimation
Some alternatives 1. Schedule in months = 3.0 * man-months1/3 2. Use estimation software to compute the schedule from your size and effort estimates Use historical data from your organization Use schedule tables Using one of the above alternatives and a periodic refinement approach allow you to quit using padding. An estimate range with periodic refinements says, "The estimates are good, but it's not possible for an estimate to be precise at this stage in the project. It will become more precise as we go along." 1. Commitment-Based Scheduling A few organizations proceed directly from requirements to scheduling without creating intermediate effort estimates. They typically do so within a commitment-based culture in which each developer is asked to make a schedule commitment rather than a schedule estimate. Advantages of this include: (1) It increases developers' buy-in to schedule (2) it tends to result in high morale for the period immediately following the commitment, and (3) tends it to elicit a lot of voluntary overtime from the developers. Weaknesses include (1) developers' estimates tend to be optimistic, which results in estimation errors. Commitment-based planning as it is commonly practices does not help to achieve short schedules.
2. Jones's First-Order Estimation Practice Uses an adjustment of the function point size-estimate. V. Ballpark Schedule Estimates +One of the toughest obstacles to meaningful software scheduling is that usable, concrete information about software scheduling is hared to come by. Uses schedules to develop estimates that are better than gut instinct. You can reduce overall project cost by lengthening the schedule and reducing the team size. Line-of-code measurements have come under attack, and some people suggest using "function points" instead. Be sure that your planned schedule is at least as long as the shortest possible schedule in a table. Anything shorter is an impossible schedule! Shortest possible schedules Assume: 1. Your team has drawn its talent from the top 10 percent of the talent pool 2. The project has ideal project management 3. Advanced software tools are available 4. Developers have unlimited access to computer resources 5. The office environment is ideal 6. The entire project team is located within the same immediate area 7. All necessary communications tools are integrated into the work environment 8. Supplemental communications technologies are available when needed 9. The most time-efficient development methods and development tools are used 10. Requirements are completely know 11. Requirements don't change These schedules have been compressed as much as possible Two facts of life 1. There is a shortest possible schedule, and you can't beat it. At some point, adding more developers slows a project down. 2. Costs increase rapidly when you shorten the schedule below nominal. Most researchers have concluded that it isn't possible to achieve a schedule compression factor lower than about 0.75 or 0.80. What this means is that there is a limit to how much you can reduce a schedule by adding people and requiring more overtime. Also, if you're willing to lengthen your schedule slightly, you can reduce the cost of your project by reducing the team size disproportionately. Efficient Schedules Given that the shortest possible schedules are out of reach for nearly all organizations, efficient schedules or nominal schedules are a more realistic alternative. Assumptions--Assume that you do most things right. 1. Your team has drawn its talent from the top 25 percent of the talent pool (both analysts and developers) 2. Everyone has worked with the programming language and environment for a few years 3. Turnover is less than 6 percent per year 4. There is shared consensus about the mission 5. No significant conflicts 6. Staffed using an efficient staffing pattern 7. Efficient user of programming tools 8. Use of modern programming practices 9. Active risk management 10. Excellent physical environment 11. Integrated use of communication tools 12. Use of rapid development practices These schedules can be compressed up to 25 percent Nominal Schedules Intended for use on average schedules. Most projects are average.
Assumptions 1. Your team has drawn its talent from the top 50 percent of the talent pool 2. The average team member has some familiarity with the programming language and the environment, but not necessarily extensive familiarity 3. The team has, on average, had some experience in the application area 4. These teams might not gel 5. The team might experience some conflicts 6. They can experience turnover of from 1--12 percent per year 7. Programming tool...