The Risk Table Risk Management
7.9.1 The Risk Table
The Risk Table is a tool that allows software engineer to identify and manage risks within the software development project. Table 41 shows an example of a risk table. Risks Identified Category Probability Impact RMMM Project Size Estimates may be too low. PS 60 2 A large number of group of end-users are not identified. PS 30 3 No components are reused. PS 70 2 Members of the steering committee are not interested in the project. BU 40 3 Project deadline is not negotiable. BU 50 2 Staff turnover will be high ST 60 1 … … … … … Table 41: Sample Risk Table First column lists down all possible risk including those that are most likely not to happen. Each risk are then categorized. Categorization identifies the type of risks, and they are briefly enumerated below. 1. Product Size. These are risks that are related to the overall size of the software that needs to be developed. 2. Business Impact. These are risks that are related to the constraints imposed by management or market. 3. Customer Characteristics. These are risks that are related to end-user’s requirements and the ability of the development team to understand and communicate with them. 4. Process Definition. These are risks that are related to the software process and how the people involved in the development effort are organized. 5. Development Environment. These are risks that are related to the availability and quality of the tools that are used to develop the software. 6. Technology. These are risks that are related to the complexity of the system and the degree of newness that is part of the software. 7. Staff Size and Experience. These are risk that are related to the overall technical and project experience of the software engineers. The probability value of the risk is identified as a percentage value of it occurring. Next, the impact of the risk when it occurs is identified. It is assessed using the following values. 1- Catastrophic. It would result in failure to meet the requirements and non- acceptance of the software. 2- Critical. It would result in failure to meet the requirements with system Software Engineering 328 J.E.D.I performance degration to the point of mission success is questionable. 3- Marginal. It would result in failure to meet the requirements would result in degration of secondary mission. 4- Negligible. It would result in inconvenience or usage problems. The last column contains the RMMM Risk Mitigation, Monitoring and Management plan for each risk. It contains the following components: 1. Risk ID. It is a unique identification number that is assigned to the risk. 2. Description. It is a brief description of the risk. 3. Risk Context. It defines the condition by which the risk may be realized. 4. Risk Mitigation and Monitoring. It defines the steps that need to be done in order to mitigate and monitor the risk. 5. Contingency Plan. It defines the steps that need to be done when the risk is realized.7.9.2 Risk Identification Checklist
Parts
» | Komputasi | Suatu Permulaan
» Quality Focus Process Method Tools
» What is quality? How do we define quality?
» Software Quality Characteristics of a Well-engineered Software
» Software Quality Assurance Activities Formal Technical Reviews
» Types of Software Process Models
» Understanding Systems | Komputasi | Suatu Permulaan
» End-users Understanding People in the Development Effort
» What is documentation? Criteria for Measuring Usability of Documents
» Abstraction Encapsulation Review of Object-oriented Concepts
» Modularity Hierarchy Review of Object-oriented Concepts
» Project Assignment Object-oriented Process Model
» Modeling Activity Unified Modeling Language UML
» UML Baseline Diagrams Unified Modeling Language UML
» Requirements Engineering Concepts | Komputasi | Suatu Permulaan
» Inception Requirements Engineering Tasks
» Elaboration Negotiation Requirements Engineering Tasks
» Specification Validation Requirements Engineering Tasks
» Management Requirements Engineering Tasks
» Scenario Modeling Requirements Analysis and Model
» Requirements Model Validation Checklist
» InvoiceNumber : Numeric Here, an attribute named InvoiceNumber contains a numeric value.
» Ternary association which is a relationship of three or more objects of
» The Analysis Model Analysis Model Validation Checklist
» Requirements Traceability Matrix RTM
» Requirements Metrics | Komputasi | Suatu Permulaan
» The Design Model Design Engineering Concepts
» Describing the Package Diagram Developing the Architectural Design
» Software Architecture Validation Checklist
» Developing the Data Design Model
» Report Design Interface Design
» Forms Design Interface Design
» Basic Component Design Principles Component-level Design Guidelines
» Component Diagram Developing the Software Component
» Project Assignment Design Model Validation Checklist
» Mapping the Design Deliverables to the Requirements Traceability Matrix Design Metrics
» Creating the Data Design Model Creating the Interface Design Creating the Control Design
» Project Assignment Programming Standards and Procedures
» Using Pseudocodes Control Structure Guidelines Documentation Guidelines
» Implementing Packages | Komputasi | Suatu Permulaan
» Abstract Classes Implementing Controllers
» Interfaces Why do we use Interfaces?
» Interface vs. Abstract Class Interface vs. Class Creating Interfaces
» Relationship of an Interface to a Class Inheritance among Interfaces
» Implementing Java Database Connectivity JDBC
» AWT GUI Components Implementing the Graphical User Interface
» Layout Managers Implementing the Graphical User Interface
» Controlling the Version of the Software
» Introduction to Software Testing
» White-Box Testing Techniques Software Test Case Design Methods
» Black-Box Testing Techniques Software Test Case Design Methods
» Testing your Programs | Komputasi | Suatu Permulaan
» Test-driven Development Steps Test-driven Development Methodology
» Testing Java Classes with JUnit
» Testing the System | Komputasi | Suatu Permulaan
» Mapping the Software Testing Deliverable to the RTM Test Metrics
» Project Assignment Software Project Management
» Problem Identification and Definition
» The Project Team Structure Project Responsibility Chart
» Project Work Breakdown Structure WBS
» Work Breakdown Schedule Format
» Size-oriented Metrics- Lines of Codes LOC Function-Oriented Metrics: Function Points FP
» Project Estimations | Komputasi | Suatu Permulaan
» The Risk Table Risk Management
» Risk Identification Checklist Risk Management
» Baseline Software Configuration Tasks
» Writing the Project Plan Project Assignment Case Tools
Show more