SOFTWARE RISKS

Although there has been considerable debate about the proper definition for software
risk, there is general agreement that risk always involves two characteristics.

• Uncertainty—the risk may or may not happen; that is, there are no 100% probable
risks.1
• Loss—if the risk becomes a reality, unwanted consequences or losses will
occur.
When risks are analyzed, it is important to quantify the level of uncertainty and the
degree of loss associated with each risk. To accomplish this, different categories of
risks are considered.
Project risks threaten the project plan. That is, if project risks become real, it is
likely that project schedule will slip and that costs will increase. Project risks identify
potential budgetary, schedule, personnel (staffing and organization), resource, customer,
and requirements problems and their impact on a software project. In Chapter
5, project complexity, size, and the degree of structural uncertainty were also
defined as project (and estimation) risk factors.
Technical risks threaten the quality and timeliness of the software to be produced.
If a technical risk becomes a reality, implementation may become difficult or impossible.
Technical risks identify potential design, implementation, interface, verification,
and maintenance problems. In addition, specification ambiguity, technical
uncertainty, technical obsolescence, and "leading-edge" technology are also risk factors.
Technical risks occur because the problem is harder to solve than we thought
it would be.
Business risks threaten the viability of the software to be built. Business risks often
jeopardize the project or the product. Candidates for the top five business risks are
(1) building a excellent product or system that no one really wants (market risk),
(2)building a product that no longer fits into the overall business strategy for the company
(strategic risk),
 (3) building a product that the sales force doesn't understand how to sell,
(4) losing the support of senior management due to a change in focus ora change in people (management risk),
(5) losing budgetary or personnel commitment(budget risks).
It is extremely important to note that simple categorization
won't always work. Some risks are simply unpredictable in advance.
Another general categorization of risks has been proposed by Charette.
Known risks are those that can be uncovered after careful evaluation of the project
plan, the business and technical environment in which the project is being developed,
and other reliable information sources (e.g., unrealistic delivery date, lack of
documented requirements or software scope, poor development environment). Predictable
risks are extrapolated from past project experience (e.g., staff turnover, poor
communication with the customer, dilution of staff effort as ongoing maintenance
requests are serviced). Unpredictable risks are the joker in the deck. They can and do
occur, but they are extremely difficult to identify in advance.