Software Risk Management

30 April 2008

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.

6 comment(s)

Lot of FUD!! Personnel risk is the highest!

1 May, 2008


>Second, as just mentioned, our support team will help you find workarounds for bugs or for features we don't currently have

I think you'll find that that should read:

"Second, as just mentioned, our support team will help you find workarounds for bugs or *use-case specific solutions* for features we don't currently have"


1 May, 2008

I think it is important to talk more about risks in software development.  And I will be the first to say that the DexExpress .NET controls that we are using for out product are top rate, as is their evolution and support.  First rate.

But, when we start to talk about risks, I have to start to think in the long term.  Our last software product (which we are still selling) started its life in the '90s.  Our new products all use DevExpress .NET win form controls and I hope in 10 years they will still be a fresh as they are today because the software products will likely still be in use.

Using a product like DevExpress commits you to a long term relationship with the vendor.  UI code permeates our production code (our objects know how to represent themselves in the UI).  So like it not, we are in business together for the next few years.

This is where I see the risk of using 3rd party components (or the use of a development framework - like .NET in general).  We are betting DevExpress will be around and performing for some time to come.  And everyone who choses a development platform or a 3rd party component set must make the same type of long term commitment and must therefore perform real risk analysis.

1 May, 2008
Julian Bucknall (DevExpress)


A little simplistic, no? All software risk is personnel related? Even thinking just about the software projects I've been involved in, there were failures (read, late delivery) due to devs, but many issues were related to misunderstanding of requirements (or rapid change of requirements), feature creep, non-understanding of the problem space, and so on. Browsing Code Complete again (say the chapters in the 20s) shows studies that it's never a single point of failure.

Cheers, Julian

1 May, 2008
Julian Bucknall (DevExpress)


Good point: I agree completely. To mitigate this kind of risk ("our software relies on X"), it's best to try and nail down X as much as possible, say by buying the source. Of course, if X is the OS -- say your product was written for Win95 -- you might have some problems, so you've got to have some kind of evolution plan to move your software into the future.

Cheers, Julian

1 May, 2008
Chuck Suscheck

Thanks for the shout out in this article.  I recently went to an agile talk on risk and surprisingly enough the same old risk probability versus cost is still being used.

3 March, 2009

Please login or register to post comments.