Risk Management
| Ref. # | Risk | Probability (1-5) | Impact (1-5) |
|---|---|---|---|
| - | Requirements | ||
| Risk 01 | Are requirements changing even as the product is being produced? | 2 | 3 |
| Risk 02 | Requirements missing or incompletely specified | 3 | 3 |
| Risk 03 | Requirements unclear or in need of interpretation | 4 | 4 |
| Risk 04 | Requirements not leading to the product the customer has in mind | - | - |
| Risk 05 | Requirements that are technically difficult to implement | 3 | 4 |
| Risk 06 | Requirements that specify something never done before or beyond the experience of program personne | 1 | 1 |
| Risk 07 | Concerns with system size or complexity | 1 | 1 |
| - | Design | ||
| Risk 08 | Potential problems in designing to meet functional requirements | 3 | 3 |
| Risk 09 | Design and/or implementation are difficult to achieve | 3 | 2 |
| Risk 10 | Internal interfaces (hardware and software) are not well defined and controlled | 4 | 3 |
| Risk 11 | Stringent response time or throughput requirements | 3 | 3 |
| Risk 12 | Product difficult or impossible to test | 2 | 2 |
| Risk 13 | Hardware limits the ability to meet any requirements | 4 | 2 |
| Risk 14 | Problems with software used in the program but not developed by the program | 2 | 2 |
| - | Code and Unit Test | ||
| Risk 15 | Implementation of the design is difficult or impossible | 2 | 2 |
| Risk16 | Design specifications are not in sufficient detail to write code | 1 | 1 |
| - | Engineering Specialties | ||
| Risk 17 | Implementation is difficult to understand or maintain | 2 | 2 |
| - | Development Process | ||
| Risk 18 | Implementation is difficult to understand or maintain | 2 | 2 |
| Risk 19 | Process is not suited to the development mode | 1 | 1 |
| Risk 20 | Project members are not experienced in use of the proces | 5 | 2 |
| - | Development System | ||
| Risk 21 | Project personnel do not find the development system easy to use | 3 | 2 |
| Risk 22 | Project personnel have not used the development system before | 3 | 2 |
| Risk 23 | Definition and acceptance requirements are not defined for delivering the system to the customer | - | - |
| - | Management Process | ||
| Risk 24 | Program is not managed according to a plan | 4 | 4 |
| Risk 25 | Program organized not effectively; roles and reporting relationships not well defined | 4 | 3 |
| Risk 26 | Bad interface with the customer and the customer is not very involved in decisions regarding functionality and operation | - | - |
| - | Management Method | ||
| Risk 27 | Management metrics not defined and development progress not well-tracked | 2 | 2 |
| Risk 28 | Project personnel not trained and used appropriately | 1 | 1 |
| Risk 29 | No adequate procedures and resources to assure product quality | 3 | 3 |
| Risk 30 | Change procedures or version control, including installation site(s) are not adequate | 1 | 1 |
| - | Work Environment | ||
| Risk 31 | Project lacks awareness of mission or goals, communication of technical information among peers and managers | 3 | 3 |
| - | Resources | ||
| Risk 32 | Project schedule inadequate or unstable | 3 | 5 |
| Risk 33 | Staff inexperienced, lack domain knowledge, lack skills, or is not adequately sized | 3 | 3 |
| - | Contract | ||
| Risk 34 | Program has critical dependencies on outside products or services | 2 | 3 |
| - | Program Interfaces | ||
| Risk 35 | Customer problems such as a lengthy document-approval cycle, poor communication, or inadequate domain expertise | - | - |
| Risk 36 | Politics causing a problem for the program | - | - |
Risk management matrix retrieved from documentation provided by Professor Richard Thomas for CSSE3002 semester one 2018. [01] Department of Energy Quality Managers Software Quality Assurance Subcommittee, "Software Risk Management:A Practical Guide”, Source/production information, Eb. 2000. [Online]. [Accessed: Jul. 09, 2018].
| Risk | Outcome | Risk factor | Mitigation Plan |
|---|---|---|---|
| Risk 03 | Requirements unclear or in need of interpretation: 1. The assigned work is unclear 2. The degree of depth regarding certain sections is unclear | IN | Monitoring: Asking the lecturer when unclear of requirements. Risk Reduction: Working with up to date information on the task |
| Risk 05 | Requirements that are technically difficult to implement: 1. Unable to scrape steam for data | H | Monitoring : Making sure we don’t waste too much time trying to get it to work Risk reduction : Having a backup plan if we can’t get the scraper to work |
| Risk 10 | Not being able to use our code due to internet issues | H | Monitoring: 1. Checking wifi signal constantly 2. Keeping up to date with the latest news from the IT department about the wifi problem. Risk Reduction: 1. Using ethernet cords when available and attempting to rely less on web-based programs |
| Risk 25 | Some people due to language barriers being assigned tasks that were not well suited to their abilities, i.e programmer doing design documentation | H | Monitoring: Every person in the group will still help out with other tasks outside of there given role so that everything is spread out Risk Reduction: Having floating roles, meaning having team members that do multiple roles at different times, some do documentation and then switch with coding when relevant and appropriate in time. |
| Risk 32 | Project schedule inadequate or unstable 1. Defined deadline for the project is inadequate and not given enough time for work they are asking for 2. Constant unexpected deadlines appearing from thin air | IN | Monitoring: 1. Paying close attention to what we think we should be doing 2. Asking the lecturer if anything is ever unclear. Risk Reduction: Confirming with the lecturer to ensure our understanding of the schedule is correct with his understanding |