Page 118 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Principles of Software Engineering

Notes schedule, personnel, resource, customer, and requirements problems and their impact on a
software project. Project complexity, size, and the degree of structural uncertainty were also
defined as project 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, interfacing, 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 an excellent product or system that no one really wants
2. Building a product that no longer fits into the overall business strategy for the company
3. Building a product that the sales force does not understand how to sell
4. Losing the support of senior management due to a change in focus or a change in people
and
5. Losing budgetary or personnel commitment. It is extremely important to note the simple
categorization would not 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.

5.9.1 Risk Identification
Risk identification is a systematic attempt to specify threats to the project plan. By identifying
known and predictable risks, the project manager takes a first step toward avoiding them when
possible and controlling them when necessary.

There are two distinct types of risks for each of the categories that are generic risks and product-
specific risks. Generic risks are a potential threat to every software project. Product-specific risks
can only be identified by those with a clear understanding of the technology, the people, and the
environment that is specific to the project at hand. To identify product-specific risks, the project
plan and the software statement of scope are examined and an answer to the following question
is developed: “what special characteristics of this product may threaten our project plan?”
Both generic and product-specific risks should be identified systematically. Tom glib drives this
point home when he states: “if you do not actively attack the risks they will actively attack you”.
One method for identifying risks is to create a risk item checklist. The Checklist can be used for
risk identification and focuses on some subset of known and predictable risks in the following
generic subcategories.
• Product Size: Risks associated with the overall size of the software to be built or modified.

• Business Impact: Risk associated with constraints imposed by management or the
marketplace.

112 LOVELY PROFESSIONAL UNIVERSITY