MSDN Magazine - January 2009 - (Page 40)

Create Application Determine Requirements Code and Test Deploy Application Design and Code Front End Design and Code Logic Middle Tier Design and Code Database Back End Figure 2 Work Breakdown Structure of the project) or cut some features or quality. If the budget for your project is cut, then you will likely have to extend the time to finish the project, remove some features, or lower the quality of your project. Using the project management triangle paradigm, because software testing is designed to improve the quality of a system, it follows that the two highest levels of risk in a software project are that the project does not finish on time and that the project runs over budget. There is a relatively simple but effective way to estimate the overall schedule and cost risks to a software project. Let’s look just at the time/schedule meta-risk (analyzing budget/cost risk works in exactly the same way). The first step in a high-level meta-risk analysis is to break your overall project into smaller, more manageable chunks of activities. For example, suppose you are working on a small Web application project, and the project must be completed in 30 working days. You begin the meta-risk analysis by listing all the activities involved (optimistic + (4 * best-guess) + pessimistic) / 6 in the project. The most common approach here is to create what is called a work breakdown structure (WBS), which you can see So for the Deploy Application task, the mean estimated time for in Figure 2. You create a top-level task that consists of the entire completion is: mean = (3 + 4*8 + 13) / 6 project. Then you break that task into a number of smaller sub= 48 / 6 tasks, typically about three to seven tasks. You repeat the process, = 8.0 days. decomposing each sub-task into smaller sub-tasks until you reach Notice that a Beta mean is just a weighted average with weights 1, the appropriate level of granularity for your environment. 4, and 1. Therefore, the variance of a Beta distribution is given by The bottom level, leaf node tasks are sometimes called work pack- this formula: ages. Exactly how you decompose your tasks and how granular you ((pessimistic - optimistic)/6)² make your WBS depends on a number of factors. For example, in an So for the Deploy Application task the variance is: variance = ((13 - 3) / 6)² agile development environment, you may well decide that a simple = (10/6)² two-level deep work breakdown structure meets your needs. Or, if = (1.6667)² = 2.78 days² you are working on a very large, complex software project using a The overall standard deviation for the project is the square root of traditional software development lifecycle methodology, you may the sum of the activity variances. Thus, in this example, the equahave tens of thousands of work packages. You can create a small WBS by hand, use generic productivity tion looks like the following: std. deviation = sqrt(5.44 + 1.78 + 2.25 + 2.78) tools such as Microsoft Office Excel, or use sophisticated tools such = sqrt(12.25) as Microsoft Office Project. A WBS does not contain sequencing, = 3.50 days time, or cost information. In other words, a WBS tells you what must be done, but not in Design and Code Logic Middle Tier what order, and does not tell you how long Determines Design and Code Deploy each task will take or how much each will Requirements Database Back End Application cost. After you create your work breakdown Design and Code Front End structure, typically the next step is to use the work packages to create what is called a precedence diagram. Figure 3 Precedence Diagram 40 msdn magazine Test Run The precedence diagram adds sequencing information. The diagram shown in Figure 3 indicates that the Requirements task must be completed before the Database Back End task, which in turn must be completed before both the Middle-Tier task and the Front-End task can begin. These last two tasks can be performed in parallel according to the precedence diagram. Finally, both the Middle-Tier task and the Front-End task must be completed before the Deploy Application task can begin. After creating a precedence diagram with its sequencing information, the next step in a time meta-risk analysis is to estimate the time required for each individual work package. Although you can estimate each time as a single data point, a better approach is to supply three estimates—an optimistic estimate, a best-guess estimate, and a pessimistic estimate. OK, but just where do such estimates come from? Determining time and cost estimates is by far the most difficult part of software project meta-risk analyses. There are many ways to estimate activity time and cost. You can use historical experience, educated guesses, sophisticated math models, and so on. The techniques you use will depend upon your particular situation. Regardless of the method you use, estimating the time and cost of a set of smaller activities is much easier than estimating the time and cost of one monolithic activity. The table in Figure 4 shows an example time risk meta-analysis. When you are analyzing optimistic, best-guess, and pessimistic time data, you usually use a simple mathematical distribution called the Beta distribution. The mean, or average, of a Beta distribution is computed as this:

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.