This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: Software processes as risk models Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

To the computer security specialist, one of the basic tools is the threat model. This is a model that gives you an idea of where, when and how an attacker is likely to compromise a system's security. The model must be clear and simple, because all security decisions must relate to it in some way. For instance, the threat model to which we owe innovations such as SSL is the "man-in-the-middle" model.

In large part, methods such as Extreme Programming, the Unified Process or the Dynamic Systems Development Method (DSDM) are the expression of a model. The model concerns the main risks that face a broad category of software projects, and drives your risk management activities. In this view, the key differences between one method and another are the type of risk they take to be most important.

What distinguishes XP, for instance, is that it pays serious attention to human risks, such as burnout, bad expectations management, or "job security" (a.k.a. truck number) issues; it stresses particularly the risk of low internal quality; it is heterodox in contending that, in the presence of comprehensive automated testing, overcomplex design is more of a risk than simplistic design; and it places a lot of importance on schedule risk.

If you look at defined software processes as risk models, you might come up with different answers to questions such as "Which process to choose", "Can we mix and match practices from different processes", or "Which practices should we begin using first".

The first thing you would do is review the risks that your projects have been most vulnerable to. Then you would look at how candidate models address these risks. You would focus on the practices which deal with your top risks, and try to mitigate the meta-risk of adopting new practices by assessing the effectiveness of your favorite methodology in a "laboratory" setting - practicing on a toy project or small pilot, attending a workshop, etc. Lastly, you would look for any risks introduced by your candidate method, and whether you need to do anything about these.