Types of risk

9.1 Types of risk

Technical, managerial, operational, environment, and testing risks all represent threats to the success of a software product. While other risks exist, these are the most prevalent, identifiable, and addressable in a software development or maintenance project.

9.1.1 Technical risk

The first type of risk a software project faces is that of the problem itself. Two major questions need to be asked: (1) Do we really know what the problem is? and (2) Is the problem solvable?

Defining the problem is done during the business analysis and software requirement gathering and definition phase. Too often, a software project is begun with only a vague suggestion of the business needs to be addressed and the outcomes expected. Thus, at the very outset, developers are aiming at a hazy and moving target. They do not know where they are going or how to get there, but they are on the way. The quality practitioner has the responsibility of assisting management to ensure that a complete definition of the business needs and subsequent software requirements is provided. This is not to say that all requirements must be known prior to the start of any work, but all must be known prior to claiming that the project is complete.

Just because a problem is known does not mean it can be solved. Solutions may be too expensive or could turn out to be a negative contribution to the overall business. These risks need to be analyzed and the problem defined during the project initiation period.

Another aspect of technical risk is the potential that the desired solution to the business need is beyond current technological capabilities. While the teleportation of the Star Trek crew is a viable solution on a television program, that technology is not readily available today. Although not expected to be an expert in all technologies, the quality practitioner is responsible for ensuring that technology questions are answered by the appropriate people.

If a company does not know what the real problem is or whether it is beyond the scope of current technology, the project is doomed before it starts. Ensuring that technical risks are addressed is an important area of responsibility for quality practitioners.

9.1.2 Managerial risk

The following managerial risks are faced throughout the life of the project:

  • Schedule risk;

  • Financial risk;

  • Personnel risk;

  • Quality risk;

  • CM risk.

9.1.2.1 Schedule risk

Perhaps the biggest risk in project management is scheduling and then managing that schedule. Schedule risk starts with the initial (and often unchangeable) estimates of the size, criticality, complexity, importance, necessity, and feasibility of a project. Stories abound of runaway projects that are woefully late or incomplete.

Quality practitioners should be closely involved in the estimation process to aid in the schedule determination. They should also counsel management to monitor and adjust the schedule as the software is designed, coded, and tested. Each step along the way should provide better visibility into the development effort, with associated better schedule reality.

9.1.2.2 Financial risk

Clearly tied to schedule risk is financial risk. Poorly estimated and determined schedules will have a negative effect on the veracity of financial estimates. This is not to say that schedules are the only contributor to financial risk. Many of the same factors affecting schedule estimation are also factors in financial estimation. These must be considered when project cost estimation is performed.

Another financial risk is incorrect or neglected consideration of the costs involved in merely deciding to accept or undertake a project. Yet another major financial risk is faced when the project overruns its schedule or budget.

The quality practitioner has the task of bringing to decision-making, action-capable management information regarding the threat and occurrence of financial risks.

9.1.2.3 Personnel risk

While technical risk occurs due to problem understanding and technological capabilities, it may roll over into personnel risk. Project management and quality practitioners should ask the following questions:

  • Do we have sufficient staff to address the problem?

  • Do we have sufficient skills to solve the problem?

Too few or inexperienced staff can threaten the successful completion of a project.

9.1.2.4 CM risk

Developing and delivering a product requires that all parts of the product are mutually consistent and meet the currently approved product requirements. This is obvious if the product is a stand-alone software product. However, software is virtually never stand-alone. At the very least, it must perform its functions on a computational platform in the company of other software, such as an operating system. In some projects, the software is a part of a larger system that may involve other software and include hardware as parts of the deliverable product.

From the smallest software change to the largest total system, ensuring that the delivered software is correct for its surroundings is a major CM risk. The quality practitioner will work with developers, management, and CM practitioners to help ensure that configuration concerns do not pose threats to the project's success.

9.1.2.5 Quality risk

It would be nice to think that all projects result in software that exhibits zero defects and delivers exactly as expected. Not only is this almost never the case, but it is sometimes not desirable from a business perspective. None of the managerial risks can be solved independently of the others. Overrunning the budget to achieve schedule goals or acquire training for staff, lengthening the schedule to provide better CM, hiring costly but specialized staff to increase quality and so on show the interactions among the risks.

An important risk question is, how good must the delivered product be? Trade-offs often exist between quality and timeliness or cost. In some cases, the business decision is to deliver a product that is close to its quality goals in order to meet market pressures or customer demands. In other cases, the criticality of the product dictates that budget or schedule or both be exceeded to deliver a high-quality product.

It is the quality practitioner's role to ensure that all aspects of a situation are considered when making trade-off decisions involving product quality. Parties to the trade-off decisions may include management, marketing, finance, user, operations, and so on, depending on the specific situation.

9.1.2.6 Project monitoring

Managerial risks are best addressed by recognizing threats and then monitoring the project to detect a threat's occurrence. Initial recognition of the threat potential should lead to intentional planning for addressing the risk. As the project proceeds, continuous monitoring of the risk potential will expose those risk situations and call for the execution of risk management plans.

The quality practitioner can play a large role in assisting in identifying risk potential, planning how to address encountered risk situations, and executing risk responses.

9.1.3 Operational risk

The following are three important operational risks:

  1. Inadequate user education or training;

  2. Misuse, intentional or unintentional, of the product;

  3. Inadequate maintenance of the product.

9.1.3.1 User education

User education is the most easily addressed of the three risks. Understanding the role of the user as the project is being initiated is expected. This understanding should indicate potential training or educational requirements for the correct and skillful use of the new product. The quality practitioner may be called on to assess training needs, try the product to find potential user confusion or error, or even conduct a dry run and operate the product using only the provided user manual or instructions.

9.1.3.2 Software Misuse

A more difficult risk to address is misuse of the product by its intended user. Anticipation of, and built-in software protection against, common unintentional mistakes on the part of the user is a risk response that is often possible.

The intentional misuse of the product usually cannot be foreseen and is hard to stop even if it can be foreseen. In these cases, clear statements of the proper scope and use of the product and specific cautions about the potential results of misuse may be a company's only defense.

The daunting role of the quality practitioner is to keep management aware of the potential for and possible consequences of product misuse.

9.1.3.3 Maintenance

Maintenance of software products is often more risk laden than the original development. Both quality control and quality assurance practitioners have direct roles in identifying and addressing maintenance risks.

The quality control practitioner's role is to make certain that every maintenance activity is checked, tested, reviewed, and configuration managed prior to the completion of the maintenance action.

The quality assurance practitioner's role is to monitor maintenance activities to detect signs of defect-prone portions of the product, identify weaknesses in the maintenance process, and anticipate potential, but as-yet unencountered, maintenance problems.

9.1.4 Environment risk

The best software systems in the world are not useful if they cannot run. This seems like a rather basic concept, but the security of the data center itself is often the last area that an organization is concerned about. The data center is at constant risk from fire and water damage, and if any precautions are taken, it is usually in this area. Beyond that, most data centers overlook the potential for interrupted processing due to severe damage. Unfortunately, few data centers make provisions for temporary processing facilities in the case of damage to the center.

A formal risk analysis will expose the various types of damage to which the specific data center is vulnerable and the degree of protection that is appropriate.

There are many physical risks that may threaten a particular data center. Fire is the most widely acknowledged threat, and provisions are nearly universal for prevention, detection, and extinguishing of fire. A second commonly recognized threat is water, usually from above in the form of rain leakage or a burst water pipe. Here, too, provisions for detection and protection are common. Unfortunately, protection frequently stops once fire and water issues are addressed because other risks are not recognized or given credence. A risk analysis can point out additional risks that may require protection against.

Such an analysis may show that the potential for severe weather damage is a real factor in hurricane and tornado areas, as well as in areas where heavy snow can damage roofs. The potential for fire damage may be shown to exist not only within the data center, but immediately outside it in such areas as adjacent warehouses or offices. The proximity of landing aircraft or railroad sidings presents the possibility of damage from accidents outside the center. Electrical power transmission lines in the immediate vicinity could break in a storm and fall onto or into the data center.

Intentional damage is a real threat as well. A recently discharged employee flooded his former employer's data center by going to the building's top floor and opening the fire hose connection. This occurred on a weekend when the bulk of the building was deserted. By the time the basement data center noticed the water's arrival, there was sufficient water on the way to flood the center with five feet of water. A risk analysis performed prior to the installation of the data center may have warned against placing the data center in the basement, where water would have nowhere else to go. A second data center had no thought of intentional damage being done to it until a terrorist bomb destroyed a nearby data center. Again, risk analysis could have shown the danger of building the data center in its current location.

Not all risks are preventable. In fact, some are inevitable and no real prevention can be provided. Others will cause such little negative effect that they can be ignored. Each risk must, however, be identified before such judgments can be made. Risk analyses help the diligent data center determine the best places to spend its protection dollars. It is equally as important to determine that a particular factor is of little or negligible risk as it is to find those factors that do present risk. Once the risks and their costs of occurrence known, preventive or protective action can be taken.

9.1.5 Testing risk

The quality control practitioner plays a key role in addressing the testing of risk. A well-constructed test plan and test process combine to reduce incomplete or redundant testing. However, the question of how much testing is enough falls to the responsible risk identifier and responder.

When to stop testing involves consideration of the types of defects still being detected by testing, the penalty to be suffered if such defects are encountered by the user, the cost of additional testing, and so on. The quality assurance practitioner will analyze the defect detection experience of the quality control activities. Consideration will be given to the potential for delivering unknown or undetected defects; the consequences of delivering known but uncorrected defects; and the costs associated with continued testing.

The results of the analysis will be presented to responsible management for the final decision as to whether to accept the risk or end testing.



Practical Guide to Software Quality Management
Practical Guide to Software Quality Management (Artech House Computing Library)
ISBN: 1580535275
EAN: 2147483647
Year: 2002
Pages: 137
Authors: John W. Horch

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net