14.1 Things You Can Do with Tools That You Can t Do Manually


14.1 Things You Can Do with Tools That You Can't Do Manually

Software estimation tools allow you to perform several kinds of estimation-related work that you can't readily perform manually.

Simulating project outcomes Software estimation tools can perform sophisticated statistical simulations, and these simulations can help project stakeholders understand the scope of work. Figure 14-1 shows an example of simulated software project outcomes.

image from book
Figure 14-1: A tool-generated simulation of 1,000 project outcomes. Output from Construx Estimate.

In the plot, the solid black lines indicate the 50/50, or median, schedule and effort. The dashed black lines represent the 25th percentile and 75th percentile outcomes.

The estimation software accounts for several sources of variability:

  • Variation in productivity

  • Variation in program size, possibly decomposed into multiple modules

  • Variation in rates of staff buildup

For each simulated outcome, the software uses a statistical technique called Monte Carlo simulation to go through 100-point probability distributions and simulate one possible outcome each for productivity, size, and staff buildup. The software then computes one estimated point in the scatter plot from these three factors. To create the entire scatter plot, the software goes through this cycle 1,000 times. You can see why you wouldn't want to do this by hand!

Different tools use different approaches, and some of the tools that are more expensive than Construx Estimate will use more sophisticated techniques.

Probability analysis Chapter 1, "What Is an ‘Estimate'?" explained the fallacies of estimating with terms like "90% confident." When the estimates are created using judgment, such expressions are inherently error-prone. But when the estimates are generated using an estimation tool calibrated with historical data, numeric percentages are better supported and more meaningful. In Figure 14-1, for example, the effort of 45 staff months is 75% likely, because 75% of simulated projects took less than 45 staff months.

Table 14-1 shows an example of a tool-calculated probability analysis for project effort. The "nominal" mentioned in the third column refers to the 50% likely estimate of 20 staff months.

Table 14-1: Example of Project Effort Probabilities Computed by Estimation Software

Probability

Effort Will Be Less Than or Equal To

Difference from Nominal Effort Estimate

10%

7

-64%

20%

10

-50%

30%

13

-37%

40%

16

-20%

50%

20

0%

60%

26

30%

70%

37

84%

80%

58

189%

90%

142

611%

The most interesting aspects of this table are the very large increases in effort to move from 70% to 80% or 80% to 90% confidence. With judgment-based techniques, very few estimators would multiply their nominal estimate by a factor of 6 to compute the 90% confident estimate, but that is what's needed in this particular case. (These numbers can't be used generally; they are computed from the specific assumptions entered into the estimation software.)

Figure 14-2 shows a graphical depiction of the data in the table.

image from book
Figure 14-2: Example of probable project outcomes based on output from estimation software.

Accounting for diseconomies of scale Estimation tools automatically account for differences in project sizes and the effect of size on productivity.

Accounting for creeping requirements Requirements growth is such a common issue that most commercial estimation tools include an allowance for requirements growth over the course of a project.

Estimation of less common software issues Estimation tools typically support estimating size of requirements documents, size of design documents, number of test cases, number of defects, mean time to failure, and numerous other quantities.

Calculation of planning options and integration with planning tools Some software estimation tools will allow you to allocate effort across requirements, design, construction, test, and debugging activities, and they'll support dividing the project into as many iterations as you see fit. These sorts of calculations are tedious to perform by hand but easy to do with the right tool support. Some tools also integrate well with Microsoft Project and other project-planning tools.

What-if analysis Estimation tools allow you to quickly revise your estimation assumptions and to see the effect on the estimate. The necessary computations can be performed instantly on a computer but would be time-consuming and errorprone if performed by hand.

Referee for unrealistic project expectations Suppose that your boss has insisted that you complete a project in 50 staff months and 11 calendar months, and suppose that you've created the estimate shown in Figure 14-3. The blue rectangle in the lower left corner of the plot shows your boss's constraints on effort and schedule. The scatter plot of 1,000 simulated project outcomes shows that only 8 of 1,000 project outcomes fall within the specified constraints. This is a visually compelling argument against trying to complete this project within those constraints!

Acting as an objective authority when revising estimation assumptions A common, unhealthy dynamic in software estimation occurs when a stakeholder rejects an initial estimate because it is too high. The stakeholder sometimes proposes a few minor feature cuts and then expects disproportionate reductions in the project's cost and schedule. A variation on this theme is slightly increasing the team size and then hoping for a large reduction in schedule.

image from book
Figure 14-3: In this simulation, only 8 of the 1,000 outcomes fall within the desired combination of cost and schedule.

Estimation software can serve as an impartial third party in arbitrating the effects of such changes. Without the tool, you are the person who must tell the stakeholder that his or her adjustments to the cost and schedule aren't supported by the feature cuts. With the tool, you can sit down on the same side of the table as the stakeholder and let the tool play the "bad cop" that tells the stakeholder that his or her changes don't produce as much reduction in the cost and schedule as was hoped for.

Figure 14-4 shows an example of the computed tradeoffs between project effort and schedule—that is, the amount of increased staff needed to shorten a schedule, or the savings in effort if the schedule can be lengthened. You might have better luck if the tool says that you need to increase staff from 20 staff months to 26 staff months to achieve a 1-month reduction in schedule than if you simply assert the same thing.

image from book
Figure 14-4: Calculated effect of shortening or lengthening a schedule.

Sanity-checking estimates created with the art of estimation The best estimators use multiple estimation approaches and then look for convergence or spread among the estimates. An estimate created with a commercial tool can provide one of those estimates.

Estimating large projects The larger the project being estimated, the less appropriate it is to rely solely on the art of estimation. Large projects should rely on a commercial software estimation tool to provide at least one of the estimates used to create and compare estimates.

Tip #64 

Use an estimation software tool to sanity-check estimates created by manual methods. Larger projects should rely more heavily on commercial estimation software.




Software Estimation. Demystifying the Black Art
Software Estimation: Demystifying the Black Art (Best Practices (Microsoft))
ISBN: 0735605351
EAN: 2147483647
Year: 2004
Pages: 212

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net