MSDN Magazine - January 2009 - (Page 42)

tains statements or questions such as, “Do I have my ID?” and “Have I checked to see if my flight is on time?” Over the years, many people and organizations have created software risk taxonomies. One such list was created by Barry Boehm, an early pioneer and a well-known researcher in the area of soft- Boehm’s taxonomy provides you with a starting point to begin thinking about risks. ware project risk. In 1989 Boehm identified a top 10 software risk taxonomy, and he updated the list in 1995. The 1995 version of the top 10 software project risk taxonomy is listed here: 1. Personnel shortfalls 2. Schedules, budgets, process 3. Commercial off-the-shelf software, external components 4. Requirements mismatch 5. User interface mismatch 6. Architecture, performance, quality 7. Requirements changes 8. Legacy software 9. Externally performed tasks 10. Straining computer science It should be apparent to you that Boehm’s top 10 risk list does not immediately identify risks. Rather, the taxonomy merely provides you with a starting point to begin thinking about risks that apply to your software project. For example, the first risk, “Personnel shortfalls,” encompasses have many different possible risks related to staffing. Your project simply may not have enough engineers to create your application or system. Or a key engineer may leave the project halfway through the project’s schedule. Or the engineering staff may not have the technical skills needed for the project. And so on. Most of the top 10 risk categories should be familiar to you, except for perhaps the 10th risk category, “straining computer science.” This is somewhat of a catch-all category and covers tasks related to things such as technical analysis, cost-benefit analysis, and prototyping. Another commonly used software risk taxonomy list was created by the Software Engineering Institute (SEI). The SEI is one of 36 federally funded research and development centers in the U.S. These research centers are rather strange hybrid organizations which are funded by public money, but sell products and services. The SEI software risk taxonomy was created in 1993 and consists of approximately 200 questions. For example, question #1 is, “Are the requirements stable? If no, what is the effect on the system (quality, functionality, schedule, integration, design, testing)?” Question #16 is, “How do you determine the feasibility of algorithms and designs (prototyping, modeling, analysis, simulation)?” You can find the SEI risk taxonomy in an appendix to the document at www.sei.cmu.edu/pub/ documents/93.reports/pdf/tr06.93.pdf. Risk Resources for more on risk, see these MSDN Magazine columns: “Test Run: Competitive Analysis Using MAGIQ” msdn.microsoft.com/magazine/cc300812 “Test Run: The Analytic Hierarchy Process” msdn.microsoft.com/magazine/cc163785 42 msdn magazine In scenario-based software risk identification, you imagine yourself in different roles, create scenarios for those roles, and identify what could go wrong in each scenario. Using the airplane trip analogy I described previously, you might mentally trace the steps you will be taking on your trip. For example, “First I drive to the airport. Then I park my car. Next, I check in at the airline counter.” This scenario process could reveal many risks including traffic delays due to road construction or an accident, parking unavailability, forgetting your ID, and so on. In a software project environment, some common roles used for scenario-based risk identification are users, developers, testers, sales people, software architects, and project managers. A user scenario might be something along the lines of, “First, I install the application. Next, I launch the application.” In many cases a risk identification scenario maps directly to a test case. Scenario-based risk identification roles are not necessarily people. Roles can be software modules or subsystems too. For example, suppose you have some C# object that performs encryption and decryption. You can imagine that the object is the role and create scenarios such as, “First I accept some input and instantiate myself. Next I accept some input and pass it to my encrypt method.” There has been less research on scenario-based software risk identification than on taxonomy-based identification. The research paper found at iag.pg.gda.pl/iag/download/Miler-Gorski_Risk_Identification_Patterns.pdf presents a good overview of the field and proposes an interesting, theoretical, pattern-based approach to risk identification. In addition to taxonomy-based and scenario-based risk identification strategies, a third approach is a specification-based strategy. In this approach you closely examine each feature and process in your product or system specification documents and attempt to identify what can go wrong. Using the airplane trip analogy, you might carefully examine a detailed trip itinerary which was created by a travel agent. Imagine that one of your specification documents for a Web application states that you intend to use an outside contractor to produce the various Help files for the application. An external project dependency can give rise to a long list of risks. What if the contractor fails to deliver on time? What if the contractor’s work quality does not meet your subjective standards? There is no single, optimal risk identification strategy, as each has pros and cons. Risk taxonomies are an excellent way to begin the process of identifying the risks in your software project. They provide a somewhat mechanical way to get started in the sense that you simply start examining each question or statement in the taxonomy. Taxonomies also help you to distribute the risk identificaTest Run http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr06.93.pdf http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr06.93.pdf http://iag.pg.gda.pl/iag/download/Miler-Gorski_Risk_Identification_Patterns.pdf http://msdn.microsoft.com/magazine/cc300812 http://msdn.microsoft.com/magazine/cc163785

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.