risk-management-in-software-engineering
# Reactive Versus Proactive Risk strategies
- Reactive
- crisis management mode –> burnout
- Proactive
- more intelligent
- potential risks are identified long before technical work is initiated.
- probability and impact are assessed and ranked by importance
- can be used to reduce technical debt
# Software risks
- Risk
- uncertainty
- Loss
- Project risks
- budgeting
- scheduling
- staffing and organization
- requirements disarray
- project complexity
- structural uncertainty
- Technical risks
- Design, Implementation, Interface, Verification, & Maintenenance problems
- Specification ambiguity
- technical uncertainty
- technical obsolescence
- usage of new technologies
- Business risks
- building a product no one wants (market risk)
- building a product that doesn’t fit into business strategy (strategic risk)
- building a product that the sales team doesn’t know how to sell (sales risk)
- losing the support of senior execs (management risk)
- budget cuts (budget risks)
# Seven Principles of Risk Management
- Maintain a global perspective
- Take a forward-looking view.
- Encourage open communication
- Integrate
- Emphasize a continuous process
- Develop a shared product vision
- Encourage teamwork
# Risk Identification
- Generic risks
- Product-specific risks
- 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
- stakeholder characteristics: risks associated with the sophistication of the stakeholders and the developer’s ability to communicate with stakeholders in a timely manner.
- process definition: risks associated with the degree to which the software process has been defined and is followed by the development organization.
- 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.
# Assessing Overall Project Risk
- Have managers formally committed to support the project?
- Are end users committed to the product to be built?
- Are requirements fully understood by the software engineering team and its customers?
- Have customers been involved fully in the definition of requirements?
- Do end users have realistic expectations?
- Is the project scope stable?
- Does the software engineering team have the right mix of skils?
- Are project requirements stable?
- Does the project team have experience with the technology to be implemented?
- Is the number of people on the project team adequate to do the job?
- Do all users agree on project importance?
# Risk Components and drivers
Source: U.S. Air Force [AFC88]
- Performance risk: the degree of uncertainty that the product will meet its requirements and be fit for 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.
- Types of risk: negligible, marginal, critical, catastrophic
# Risk Projection/Risk estimation
- Establish a scale that reflects the perceived likelihood of a risk
- Delineate the consequences of the risk
- Estimate the impact of the risk on the project and the product.
- Assess the overall accuracy of the risk projection so that there will be no misunderstandings
# Example Risk table
Risk | Category | Probability | Impact | RMMM |
---|---|---|---|---|
Size estimate may be significantly low | PS | 60% | 2 | |
Larger number of users than planned | PS | 30% | 3 | |
Less reuse than planned | PS | 70% | 2 | |
End users resist system | BU | 40% | 3 | |
Delivery deadline will be tightened | BU | 50% | 2 | |
Funding will be lost | CU | 40% | 1 | |
Customer will change requirements | PS | 80% | 2 | |
Technology will not meet exceptions | TR | 30% | 1 | |
Lack of training on tools | DE | 80% | 3 | |
Staff inexperienced | ST | 30% | 2 | |
Staff turnover will be high | ST | 60% | 2 |
# Risk Probability
- can be determined by making individual estimates and then developing a single consensus value
- can use fuzzy logic to determine the characteristics that make software projects that are prone to failure.
- a weighted average can be used if one risk component has more significance for a project.
- fuzzy logic is a type of logic that recognizes more than simple true and false values. with fuzzy logic, propositions can be represented with degrees of truthfulness and falsehood. fuzzy logic has proven to be useful in artificial intelligence applications that involve making decisions involving incomplete or uncertain information.