MSDN Magazine - January 2009 - (Page 39)

DR. JAmEs mccAffREy TesT Run Analyzing Project Exposure And Risk Using PERIL All software projects face risks. A risk is an event, which may or may not occur and which causes some sort of loss. The relationship between risk and software testing is straightforward. Because, except in rare situations, you cannot exhaustively test a software system, risk analysis reveals issues that can cause the most loss. You can use this information to help prioritize your testing effort. In this month’s column, I present practical techniques you can use to identify and analyze the risks involved with a software project. Let’s begin. Imagine a hypothetical situation in which you are developing an ASP.NET Web-based application of some sort. Figure 1 illustrates some of the key ideas and problems associated with software risk analysis. The overall process of risk analysis involves identifying your risks, estimating how likely each risk is, determining the loss associated with each risk, and combining likelihood and loss information into a value called risk exposure. According to the example data in Figure 1, the risk that “User IDs can be viewed” has the highest exposure, so other factors being equal, you would likely want to make it a top priority to test for this to prevent the risk from becoming a reality. But how can you identify risks? How can you estimate risk probability and loss? Can you still perform risk analysis if you cannot estimate risk probability and loss? Although there have been several efforts to formalize and standardize risk analysis terminology, in practice different terms tend to be used in different problem domains. I will use the term “risk analysis” to mean computing risk exposure by multiplying the risk probability or likelihood by the risk loss, or to mean the overall process of identifying, analyzing, and managing software project risk. In spite of the fact that risk analysis is a critically important part of software development, based on my experience, many risk analysis techniques are not widely known in the software testing community. If you search the Web, you will find tens of thousands of references on software risk analysis. However, the majority of these references either address risk analysis at a very high level and do not present practical techniques or present just one specific risk analysis technique and do not explain how the technique fits into an overall risk analysis framework. I’ll present you with both an overview of risk analysis and useful techniques you can employ immediately in your software development environment. In the sections of this column, I describe two meta-risks that are common to all software projects. Then I present three ways you can identify specific risks associated with your software project and Figure 1 Risk Analysis Risk Overall response time too slow Web server fails User IDs can be viewed Probability 0.20 0.25 0.10 Loss $4,000.00 $5,000.00 $50,000.00 Exposure $800.00 $1,250.00 $5,000.00 three ways to analyze risk. In particular, I will introduce you to an interesting new risk analysis technique called Project Exposure using Ranked Impact and Likelihood (PERIL) that is especially useful in a software development environment. I conclude with a brief discussion of risk management. I believe that the techniques presented here will become an extremely valuable addition to your software testing, development, and management tool kit. Meta-Risks Two special types of software project risk analyses are what I call time and cost meta-risk analyses. Traditional project management defines a concept which has different names including “the project management triple constraint” and “the project management triangle.” The idea is, in short, that virtually every project has three limiting factors: cost, schedule, and scope. Cost is how much money you have to spend on the project, schedule is how long you have to complete the project, and scope is the set of required project features and their quality. The three project constraints have a variety of aliases. For example, cost is also referred to as budget or money. Schedule is often called time or duration. And scope is sometimes called features, or quality, or even features/quality. Notice that this last features/ quality constraint can be (and often is, in fact) considered to be two distinct constraints. A key notion is that a change in any one of the constraints will likely cause a change in one or both of the other two constraints. For example, if you are developing a software application, and you are suddenly required to finish the project in a shorter amount of time than originally planned, you probably will have to spend more money (for example, to buy additional resources or outsource part Send your questions and comments for James to testrun@microsoft.com. Code download at code.msdn.microsoft.com/mag200901TestRun. January 2009 39 http://code.msdn.microsoft.com/mag200901TestRun

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.