R I S K I D E N T I F I C AT I O N Risk identification is a systematic attempt to specify threats to the project plan (esti-
6.3 R I S K I D E N T I F I C AT I O N Risk identification is a systematic attempt to specify threats to the project plan (esti-
mates, schedule, resource loading, etc.). By identifying known and predictable risks, the project manager takes a first step toward avoiding them when possible and con- trolling them when necessary.
There are two distinct types of risks for each of the categories that have been pre- Although generic risks
sented in Section 6.2: generic risks and product-specific risks. Generic risks are a are important to
potential threat to every software project. Product-specific risks can be identified only consider, usually the
product-specific risks by those with a clear understanding of the technology, the people, and the environ- cause the most
ment that is specific to the project at hand. To identify product-specific risks, the proj- headaches. Be certain
ect plan and the software statement of scope are examined and an answer to the to spend the time to
following question is developed: "What special characteristics of this product may identify as many
threaten our project plan?" product-specific risks as
possible. 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—risks associated with constraints imposed by management or the marketplace.
• Customer characteristics—risks associated with the sophistication of the cus- tomer and the developer's ability to communicate with the customer in a timely manner.
Risk item checklist • Process definition—risks associated with the degree to which the software process has been defined and is followed by the development organiza- tion.
• Development environment—risks associated with the availability and quality of the tools to be used to build the product.
• Technology to be built—risks associated with the complexity of the system to
be built and the "newness" of the technology that is packaged by the system. • Staff size and experience—risks associated with the overall technical and
project experience of the software engineers who will do the work. The risk item checklist can be organized in different ways. Questions relevant to each
of the topics can be answered for each software project. The answers to these ques- tions allow the planner to estimate the impact of risk. A different risk item checklist format simply lists characteristics that are relevant to each generic subcategory. Finally,
a set of “risk components and drivers" [AFC88] are listed along with their probability a set of “risk components and drivers" [AFC88] are listed along with their probability
A number of comprehensive checklists for software project risk have been pro- “Risk management is
posed in the literature (e.g., [SEI93], [KAR96]). These provide useful insight into generic project management
risks for software projects and should be used whenever risk analysis and manage- for adults.” ment is instituted. However, a relatively short list of questions [KEI98] can be used
Tim Lister
to provide a preliminary indication of whether a project is “at risk.”
6.3.1 Assessing Overall Project Risk
The following questions have derived from risk data obtained by surveying experi- enced software project managers in different part of the world [KEI98]. The questions are ordered by their relative importance to the success of a project.
? 1. Have top software and customer managers formally committed to support
Is the
software
the project?
project we’re
2. Are end-users enthusiastically committed to the project and the
working on at serious risk? system/product to be built?
3. Are requirements fully understood by the software engineering team and their customers?
4. Have customers been involved fully in the definition of requirements?
5. Do end-users have realistic expectations?
6. Is project scope stable?
7. Does the software engineering team have the right mix of skills?
8. Are project requirements stable?
9. Does the project team have experience with the technology to be implemented?
10. Is the number of people on the project team adequate to do the job? Risk Radar is a risk management database
WebRef
11. Do all customer/user constituencies agree on the importance of the project that helps project
and on the requirements for the system/product to be built? managers identify, rank, and communicate project
If any one of these questions is answered negatively, mitigation, monitoring, and risks. It can be found at
management steps should be instituted without fail. The degree to which the proj-
www.spmn.com/ rsktrkr.html
ect is at risk is directly proportional to the number of negative responses to these questions.
6.3.2 Risk Components and Drivers
The U.S. Air Force [AFC88] has written a pamphlet that contains excellent guidelines for software risk identification and abatement. The Air Force approach requires that the project manager identify the risk drivers that affect software risk components— The U.S. Air Force [AFC88] has written a pamphlet that contains excellent guidelines for software risk identification and abatement. The Air Force approach requires that the project manager identify the risk drivers that affect software risk components—
• Performance risk—the degree of uncertainty that the product will meet its requirements and be fit for its intended use.
• Cost risk—the degree of uncertainty that the project budget will be maintained.
• Support risk—the degree of uncertainty that the resultant software will be easy to correct, adapt, and enhance.
• Schedule risk—the degree of uncertainty that the project schedule will be maintained and that the product will be delivered on time.
The impact of each risk driver on the risk component is divided into one of four impact categories—negligible, marginal, critical, or catastrophic. Referring to Figure 6.1 [BOE89],
Components
Schedule Category
Failure to meet the requirement
Failure results in increased costs
1 would result in mission failure
and schedule delays with expected values in excess of $500K
Catastrophic
Significant
Nonresponsive or
Significant financial Unachievable
degradation to
unsupportable
shortages, budget IOC
2 nonachievement
software
overrun likely
of technical performance
Failure to meet the requirement would
Failure results in operational delays
1 degrade system performance to a point
and/or increased costs with expected
where mission success is questionable
value of $100K to $500K
Critical
Some reduction
Minor delays in
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