Risk is everywhere in the software creation process.
For example, should you invest resource in writing formal user requirements specifications, functional specifications and acceptance test plans. Or do you risk the project overrunning when it doesn't quite do what the customer expects and you have to make a number of late changes?
Should you take time at the start of a small project to write unit tests before any other code. Or do you risk a drawn out testing phase later on?
In financial markets risk is measured using a number of statistical methods but how would you go about measuring the risk in the examples mentioned above?
If you know the customer that you are delivering the product to, you may know how forgiving (or not!) that they are. If you have a good relationship with the client you may be able to get away with a number of severity 3 or 4 bugs.
When dealing with an unknown customer assume the risk is high. And the larger the development, the larger the risk. With a high risk project you should aim to employ as many good software development practices as possible.
(Thanks to Esko for the excellent photo)
Posts
1 comment:
Good, thought provoking post. The level of process you follow, and the risk you are willing to take, will vary based upon your your target customers and the market you are delivering software in.
If you have a chance, check out my blog post on why the funcional spec is often overkill:
http://johnfmoore.wordpress.com/2009/03/14/read-it-here-first-the-functional-spec-is-dead-or-should-be/
Let me know what you think.
John
http://johnfmoore.wordpress.com
Post a Comment