RISK REFINEMENT During early stages of project planning, a risk may be stated quite generally. As time
6.5 RISK REFINEMENT During early stages of project planning, a risk may be stated quite generally. As time
passes and more is learned about the project and the risk, it may be possible to refine the risk into a set of more detailed risks, each somewhat easier to mitigate, monitor, and manage.
What is a ? What is a
good way to
format [GLU94]. That is, the risk is stated in the following form:
describe a risk?
Given that <condition> then there is concern that (possibly) <consequence>. Using the CTC format for the reuse risk noted in Section 6.4.2, we can write: Given that all reusable software components must conform to specific design standards
and that some do not conform, then there is concern that (possibly) only 70 percent of the planned reusable modules may actually be integrated into the as-built system, resulting in the need to custom engineer the remaining 30 percent of components.
This general condition can be refined in the following manner: Subcondition 1. Certain reusable components were developed by a third party with no
knowledge of internal design standards. Subcondition 2. The design standard for component interfaces has not been solidified
and may not conform to certain existing reusable components. Subcondition 3. Certain reusable components have been implemented in a language that
is not supported on the target environment. The consequences associated with these refined subconditions remains the same (i.e.,
30 percent of software components must be customer engineered), but the refinement helps to isolate the underlying risks and might lead to easier analysis and response.
6 . 6 R I S K M I T I G AT I O N , M O N I T O R I N G , A N D M A N A G E M E N T
All of the risk analysis activities presented to this point have a single goal—to assist the project team in developing a strategy for dealing with risk. An effective strategy must consider three issues:
“If I take so many • risk avoidance precautions, it is
because I leave • risk monitoring nothing to chance.”
• risk management and contingency planning
Napolean
If a software team adopts a proactive approach to risk, avoidance is always the best strategy. This is achieved by developing a plan for risk mitigation. For example, assume
that high staff turnover is noted as a project risk, r 1 . Based on past history and man- that high staff turnover is noted as a project risk, r 1 . Based on past history and man-
have a critical impact on project cost and schedule. To mitigate this risk, project management must develop a strategy for reducing turnover. Among the possible steps to be taken are
WebRef
An excellent FAQ on risk • Meet with current staff to determine causes for turnover (e.g., poor working management can be
conditions, low pay, competitive job market). obtained at
www.sei.cmu.edu/
• Mitigate those causes that are under our control before the project
organization/
starts.
programs/sepm/ risk/risk.faq.html
• Once the project commences, assume turnover will occur and develop tech- niques to ensure continuity when people leave.
• Organize project teams so that information about each development activity is widely dispersed.
• Define documentation standards and establish mechanisms to be sure that documents are developed in a timely manner.
• Conduct peer reviews of all work (so that more than one person is "up to speed”). • Assign a backup staff member for every critical technologist.
As the project proceeds, risk monitoring activities commence. The project manager monitors factors that may provide an indication of whether the risk is becoming more or less likely. In the case of high staff turnover, the following factors can be monitored:
• General attitude of team members based on project pressures. “We are ready for an
• The degree to which the team has jelled. unforseen event that
• Interpersonal relationships among team members. may or may not occur.”
• Potential problems with compensation and benefits.
Dan Quayle
• The availability of jobs within the company and outside it. In addition to monitoring these factors, the project manager should monitor the effec-
tiveness of risk mitigation steps. For example, a risk mitigation step noted here called for the definition of documentation standards and mechanisms to be sure that doc- uments are developed in a timely manner. This is one mechanism for ensuring con- tinuity, should a critical individual leave the project. The project manager should monitor documents carefully to ensure that each can stand on its own and that each imparts information that would be necessary if a newcomer were forced to join the software team somewhere in the middle of the project.
Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. Continuing the example, the project is Risk management and contingency planning assumes that mitigation efforts have failed and that the risk has become a reality. Continuing the example, the project is
It is important to note that RMMM steps incur additional project cost. For exam- ple, spending the time to "backup" every critical technologist costs money. Part of If RE for a specific risk
risk management, therefore, is to evaluate when the benefits accrued by the RMMM is less than the cost of
steps are outweighed by the costs associated with implementing them. In essence, risk mitigation, don’t
the project planner performs a classic cost/benefit analysis. If risk aversion steps for try to mitigate the risk
but continue to high turnover will increase both project cost and duration by an estimated 15 per- monitor it.
cent, but the predominant cost factor is "backup," management may decide not to implement this step. On the other hand, if the risk aversion steps are projected to increase costs by 5 percent and duration by only 3 percent management will likely put all into place.
For a large project, 30 or 40 risks may identified. If between three and seven risk management steps are identified for each, risk management may become a project in itself! For this reason, we adapt the Pareto 80–20 rule to software risk. Experience indicates that 80 percent of the overall project risk (i.e., 80 percent of the potential for project failure) can be accounted for by only 20 percent of the identified risks. The work performed during earlier risk analysis steps will help the planner to determine which of the risks reside in that 20 percent (e.g., risks that lead to the highest risk exposure). For this reason, some of the risks identified, assessed, and projected may not make it into the RMMM plan—they don't fall into the critical 20 percent (the risks with highest project priority).
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more