 |
 |
 |
RISK MANAGEMENT
Let us start by defining Risk. Risk is the probability that an unfavorable event will occur. In a Risk Analysis, the impact of a potential threat is quantified.
In software development projects, it is important to do a formal risk analysis on various aspects like Customer Risk, Manpower Risk, Hardware Risk, Technology Risk. Typical questions which need to be answered are :
* What risks confornt the current situation?
* What is the probability of loss from them?
* How much are the losses likely to cost?
* What might be the losses if the worst happened?
* What alternative choices exists to avert the risk?
* How can the potential losses be eliminated or reduced?
* Will the alternatives produce other Risks?
If your attrition rate is very high, you a manpower risk or if you are executing a project using untried technology risk. The usual practice is to have a risk evaluation from or checklist which outlines all the likely risks evaluation from or checklist which analysis, we should have identified all the risks associated with them and quantified them. The objective of quantifying risk is to understand the impact and the relative importance of various risks.
Let us start by defining Risk. Risk is the probability that an unfavorable event will occur. In a Risk Analysis, the impact of a potential threat is quantified.
In software development projects, it is important to do a formal risk analysis on various aspects like Customer Risk, Manpower Risk, Hardware Risk, Technology Risk. Typical questions which need to be answered are :
* What risks confornt the current situation?
* What is the probability of loss from them?
* How much are the losses likely to cost?
* What might be the losses if the worst happened?
* What alternative choices exists to avert the risk?
* How can the potential losses be eliminated or reduced?
* Will the alternatives produce other Risks?
If your attrition rate is very high, you a manpower risk or if you are executing a project using untried technology risk. The usual practice is to have a risk evaluation from or checklist which outlines all the likely risks evaluation from or checklist which analysis, we should have identified all the risks associated with them and quantified them. The objective of quantifying risk is to understand the impact and the relative importance of various risks.
These requirements are then transformed into actual values and scripts that are ready for execution. These executable tests are run against the software, denoted P in the figure, and the results are evaluated to determine if the tests reveal a fault in the software.
These activities may be carried out by one person or by several, and the process is monitored by a test manager. One of a test engineer’s most powerful tools is a formal coverage criterion. Formal coverage criteria give test engineers ways to decide what test inputs to use during testing, making it more likely that the tester will find problems in the program and providing greater assurance that the software is of high quality and reliability. Coverage criteria also provide stopping rules for the test engineers. The technical core of this book presents the coverage criteria that are available, describes how they are supported by tools (commercial and otherwise), explains how they can best be applied, and suggests how they can be integrated into the overall development process. Software testing activities have long been categorized into levels, and two kinds of levels have traditionally been used. The most often used level categorization is based on traditional software process steps. Although most types of tests can only be run after some part of the software is implemented, tests can be designed and constructed during all software development steps. The most time-consuming parts of testing are actually the test design and construction, so test activities can and should be carried out throughout development. The second-level categorization is based on the attitude and thinking of the testers.
These activities may be carried out by one person or by several, and the process is monitored by a test manager. One of a test engineer’s most powerful tools is a formal coverage criterion. Formal coverage criteria give test engineers ways to decide what test inputs to use during testing, making it more likely that the tester will find problems in the program and providing greater assurance that the software is of high quality and reliability. Coverage criteria also provide stopping rules for the test engineers. The technical core of this book presents the coverage criteria that are available, describes how they are supported by tools (commercial and otherwise), explains how they can best be applied, and suggests how they can be integrated into the overall development process. Software testing activities have long been categorized into levels, and two kinds of levels have traditionally been used. The most often used level categorization is based on traditional software process steps. Although most types of tests can only be run after some part of the software is implemented, tests can be designed and constructed during all software development steps. The most time-consuming parts of testing are actually the test design and construction, so test activities can and should be carried out throughout development. The second-level categorization is based on the attitude and thinking of the testers.
Risk Management