less likely it will be to take risks. Thus, the more mature the organization, the more likely it is for a software team in that organization to do risk analysis of software. This leads us to the justification for doing a risk analysis.
Why do a Risk Analysis?
Daniel Kamm writes in "An Introduction to Risk/Hazard Analysis for Medical Devices" that in the medical industry, risk analysis is done for the following reasons:
- Risk analysis is required by law.
- Identification of device design problems prior to distribution eliminates costs associated with recalls.
- Risk analysis offers a measure of protection from product liability damage awards. 4.
- Regulatory submissions checklists (PMA and 510k) used by the FDA now call for inclusion of risk analysis.
- It is the right thing to do.
Some of these reasons could also apply to software risk analysis and disaster recovery planning in that risk analysis offers protection from product liability damages. Also, it is cheaper to fix a software defect found in the development stage rather than after customers find the defect. The risk analysis process could be part of disaster recovery planning.
Similarly, in software development, risk analysis provides the foundation for the entire test planning effort. It should be included as an integral part of the test plan as a method to guide the test team in determining the order of testing. The argument here is that testing reduces risks associated with software development, and the software risk analysis allows us to prioritize those features and requirements with the highest risk. If we test the high risk items first, we have reduced the overall risk of the software release significantly. Risk analysis also allows the test team to set expectations about what can be tested in the given amount of time.
What are the risks associated with software development? Jones mentions sixty software risks in his book, Assessment and Control of Software Risks . Among these are cost overruns, canceled projects, high maintenance costs, false productivity claims, low quality, missed schedules, and low user satisfaction. The cause of low user satisfaction comes from inadequate requirements in the sense that software may have been built without adequately considering the needs of the user community. This leads us to the scope of risk analysis.
Scope of the Risk Analysis
This paper addresses software risk analysis. The method I present is limited to assessments of software requirement specifications and features. It does not refer to more general software risks mentioned above.
Who does the software risk analysis? Typically, software risk analysis involves everyone involved with the software development lifecycle. The users, business analysts, developers, and software testers are all involved in conducting risk analysis. However, it is not always possible to have everyone's input, especially that of the users. In that case, the testers should conduct the software risk analysis as early as possible in the software development lifecycle (sdlc). Typically, risk analysis is done in the requirements stage of the SDLC.
In the literature, two indicators have been proposed as indicators of risk: the expected impact of failure and the likelihood of failure. Let's talk about these in turn.
Expected Impact Indicator
According to Craig and Jaskiel, "The software team should ask the question, 'What would be the impact on the user if this feature or attribute failed to operate correctly?'"
Impact is usually expressed in terms of money or the cost of failure. For each requirement or feature, it is possible to assign a value to each requirement in terms of the expected impact of the failure of that requirement or feature. Assign a value of