Skip to main content

22.04.04 - Risk Management

Software Risks​

Risk Requirements for Software​

Requirements & Specs were all about 'should' and 'shall'

Shall Not requirements​

Functional Requirements​

  • What should not happen
  • What should happen for non-correct usage or errors
  • E.g. putting negative number shouldn't give them money back

Non-functional requirements​

  • Define the reliability and availability of software
  • Saying software shouldn't break at 20,000 then software shouldn't break at anything less

Risk Decomposition​

  • Might be several ways that a risk can occur
  • Sometimes best solution to solve a problem, not the best for that problem but the best for all related problems
  • If you collect shall-not specifications: can make it part of your collective design decisions

Risk reduction​

1) Hazard Avoidance - so it cannot occur 2) Hazard Detection & Removal - so systems recover nicely 3) Damage Limitation - so the impact is limited

These are design issues that might affect at the start

Risk-based release tests​

  • Test plan might be driven by these
  • Might dictate choice of hardware, or database software
  • Might mean designing to optimise/minimise use of those

Security Concerns​

Also security related issues, what were the most valuable parts of system which people want to get hold of.

  • Identify possible routes to this information
  • Especially relevant for APIs, which purposefully give access

Project Risks​

Concerns​

  1. Deliver the software to the customer on schedule
  2. Keep overall costs within budget
  3. Deliver software that means the customers expectations
  4. Maintain a happy and well-functioning dev team

Risk Analysis​

  • Most important jobs for a project manager:
    • Considering and preparing for possible problems in the future
    • For the project going smoothly
  • All risks should be listed, and a strategy considered

Risk types​

  • Technology
  • People
  • Organisational
  • Tools
  • Requirements
  • Estimation

Risk Prioritisation​

Probability of it:

  • very low (<10%)
  • low (10-25%)
  • moderate (25-50%)
  • high (50-75%)
  • very high (>75%) The effect of it:
  • catastrophic (project fail)
  • serious (expense/delays)
  • tolerable (in contingency)
  • insignificant (don't care)

Risk Planning​

  • Avoidance strategies - actions taken to reduce the risk happening. Best one to have (backups)
  • Minimisation strategies - reducing the impact if it happens
  • Contingency plans - what you will do/change if it happens

Risk Monitoring​

Still need to monitor the risk, even after planning Need to check to see if any of the following appear to be happening | Risk Type | Potential Indicators | |----------------|----------------------------------------------------------------------------------------------------------------| | Technology | Late delivery of hardware or support software; many reported technology problems. | | People | Poor staff morale; poor relationships amongst team members; high staff turnover. | | Organisational | Organizational gossip; lack of action by senior management. | | Tools | Reluctance by team members to use tools; complaints about CASE tools; demands for higher-powered workstations. | | Requirements | Many requirements change requests; customer complaints. | | Estimation | Failure to meet agreed schedule; failure to clear reported defects. |