Risk Management is a hot-button topic in the regulated software environment. We have a good product risk management system (14971 compliant) but the new direction is "risk-based processes" spreading risk management to the entire process not just product. Any hints, tips, tricks, thoughts on this topic. The basic thought is great but I am having a hard time getting my arms around the task and even stating the objectives of the project beyond a superfacial statement.
As I understand it Risk based processes, is basically prioritizing the work that is done within the process according to the risk it has if it is done or not done.
For example in the SDLC there may be a planning phase where one of the deliverables is functional requirements, the requirement can be prioritized to determine the risk to the product if this requirement is not included or not met.
In the testing phase you can prioritize the testing done based on the risk of certain functionality not being tested or fully tested. As far as I can tell from the reading I have done ideally the same risk as applied in "normal" risk management should be done but to be quite honest I would see this as very time consuming.
I have seen articles on risk based testing around for several years and many of those imply the same idea as the few articles I have seen on risk based processes.
So far, for me, this is just a new phrase, for prioritizing what you do, and basing what you do in a time frame on the priority. I am assuming that it is a new marketing tool for those that can charge for educating us in it.
[ QUOTE ]
I am assuming that it is a new marketing tool for those that can charge for educating us in it.
[/ QUOTE ]
That's a little harsh. Risk Management has been an integral part of project planning and control for a long tome, and it dovetails well into testing. It's true that the result of the Risk-Based approach is prioritization. But how you go about that prioritization is the important part. There's an excellent (and not especially new" book on the subject by Rick Craig and Stephen Jaskiel. I didn't write the book, but I have certainly learned a lot from it.