Software Risk Management

Part of any software project worth its salt is an analysis of risk. Many times unfortunately this analysis gets short shrift and as a consequence the project manager is essentially playing high stakes poker.

What is software risk? In essence it's the chance of something going wrong in the development of some software. It's the danger of failure, of loss (usually monetary), of producing something that isn't what was required. By identifying the risks in a software project, assessing their likelihood, and monitoring them, we can avoid or minimize drastic harm through a risk actually occurring.

In January 1991, Barry Boehm, then at DARPA, wrote an article called Software Risk Management: Principles and Practices for IEEE Software. In it he identified 10 software risks

1. Personnel shortfalls
2. Unrealistic schedules and budgets
3. Developing the wrong budgets and properties
4. Developing the wrong UI
5. Gold-plating (aka Feature creep)
6. Continuing stream of requirements changes
7. Shortfalls in externally furnished components
8. Shortfalls in externally performed tasks
9. Real-time performance shortfalls
10. Straining computer-science capabilities

Of these risks, which ones do we, Developer Express, help mitigate (or, possibly, exacerbate)?

Obviously, as far as you're concerned, if you own our products we are going to feature greatly with regard to possible external risks. How do we help mitigate those risks for you?

First of all, I'd argue, is our subscription model. Not only are you mitigating the budget risk by subscribing, you are also receiving a stream of minor and major updates for a full year. Bugs will be fixed, new features will be added, and so on. And you won't have to wait too long in general for these updates -- we release minor updates approximately every three weeks on average. (It could be argued that the regular updates are a risk unto themselves -- should I update? should I wait? What happens to the stability of my software if I do update? Etc.)

Even better, if the bug you've happened to encounter is particularly heinous -- it has no good workaround for example -- and we've fixed it, the support team will usually provide interim fixed dlls for you to use until the next minor update is released.

Second, as just mentioned, our support team will help you find workarounds for bugs or for features we don't currently have. This is almost like having a temporary developer finding quick code solutions, maybe not fully fleshed out, that keep your development going. Our searchable Support Center and Knowledgebase feature highly in this risk mitigation as well.

Third, you can purchase a subscription to our control and framework libraries with source code. Many customers do this to alleviate the risk that we disappear. Others do it so that they can learn our design and coding techniques and apply them to their own code. Still more actually change the code for their own purposes to remove features or add new ones. No matter why the source code is purchased, having it is ultimately a risk mitigator.

Another risk we can help mitigate, almost accidentally as it were, is personnel shortfalls. Because we have been in the industry such a long time, you'll find it easier to find and employ developers that have used our products and that are expert in them.

Of course, I won't pretend that it's all good news when using DevExpress' libraries. You may find a problem or require a feature that we are not going to fix or provide, or at least not to your deadline or timetable. To counter this, I would certainly advise that you perform an in-depth evaluation of the products before you start down the road of actually using them: Download, Compare, Decide. The more in-depth an evaluation you perform, the less likely you'll find roadblocks at a later stage and the lower your risk. For example, if your requirement is for an MDI application, it makes sense to try out the controls you're evaluating in that environment.

Doing this in more breadth is known as prototyping. Prototyping is a great technique that helps alleviate many other risks as well, not necessarily those devoted to external factors. For instance, prototyping will help nail your UI, help you understand possible performance issues, reduce the risk of feature creep. Our UI controls are very amenable to prototyping; in fact, possibly too amenable, since it's hard to throw away a good-looking polished prototype.

When managing software risk, you have two main activities: assessment and control. Assessment is identifying the risks, estimating their likelihood and the potential loss from each. Dr Charles Suscheck, with whom I worked some five years ago, used to use a simple numeric scale for each of these, say a scale of 1 to 5 for the probability of occurrence, and a scale of 1 to 10 for the potential loss. If you multiply these values together, you'll get a rank for each risk. High rank means high probability and big loss, medium rank means high likelihood and low cost or vice versa, low rank means low possibility and low cost.

The result of this assessment is usually a ranked list of risks. After that it's a case of how to control these risks.You've got to come up with plans and strategies to mitigate these risks. Obviously the most highly ranked risks have to be continually monitored and rigorously controlled, medium risks less often (and have less detailed strategies for mitigation), and usually the lowest ranked risks are pretty much ignored.

Anyway, if nothing else, I hope this post convinces you to assess and manage the risk in your current software project. I also hope that I've convinced you that owning DevExpress' products is not exposing you to large risk, but instead is helping alleviate the risk in your project.

Free DevExpress Products - Get Your Copy Today