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
- Personnel shortfalls
- Unrealistic schedules and budgets
- Developing the wrong budgets and properties
- Developing the wrong UI
- Gold-plating (aka Feature creep)
- Continuing stream of requirements changes
- Shortfalls in externally furnished components
- Shortfalls in externally performed tasks
- Real-time performance shortfalls
- 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
The following free DevExpress product offers remain available. Should you have any questions about the free offers below, please submit a ticket via the
DevExpress Support Center at your convenience. We’ll be happy to follow-up.