Issue Tracking and Risk Management John D. McGregor Module 10 Session 1 Issue Tracking and Risk

Risk Every engineering discipline has techniques for managing risk. The Capability Maturity Model of the SEI provides a CMMI practice area on risk appings/pdfs/upload/RSKMv1-3.pdf

Risk-2 Risk is about uncertainty If we are certain about something – And we are correct – great – And we are incorrect – that is a problem not a risk Otherwise we are uncertain about something – There is a probability of a situation occurring – If it does happen there are consequences – There are things we can do to either Reduce the possibility Reduce the impact

Risk-3 Risk is affected by many factors – Time – the further in the future an event is the less certain we can be about the outcome – Velocity – the faster the knowledge in an area is changing the less certain we can be – Importance – the more important a function is the greater the consequences of failure

Uncertainty in reqspec uncertainty [ volatility costImpact scheduleImpact familiarity riskIndex proportionalRiskIndex maturityIndex ]

Uncertainty in assurance case ::= claim claimID ( : "Descriptive title" )? ( '(' ')' )? for [ ( assert ( argument )? ( rationale )? ( )* ( issues ("explanation")+ )? ]

Specific Goal/Specific Practices SG 1 Prepare for Risk Management SP 1.1 Determine Risk Sources and Categories SP 1.2 Define Risk Parameters SP 1.3 Establish a Risk Management Strategy SG 2 Identify and Analyze Risks SP 2.1 Identify Risks SP 2.2 Evaluate, Categorize, and Prioritize Risks SG 3 Mitigate Risks SP 3.1 Develop Risk Mitigation Plans SP 3.2 Implement Risk Mitigation Plans

Prepare for Risk Management Determine Risk Sources and Categories Uncertain requirements Unprecedented efforts (i.e., estimates unavailable) Infeasible design Competing quality attribute requirements that affect solution selection and design Unavailable technology Unrealistic schedule estimates or allocation Inadequate staffing and skills Cost or funding issues Uncertain or inadequate subcontractor capability Uncertain or inadequate supplier capability Inadequate communication with actual or potential customers or with their representatives Disruptions to the continuity of operations Regulatory constraints (e.g. security, safety, environment)

Prepare for Risk Management Define Risk Categories The following factors can be considered when determining risk categories: Phases of the project’s lifecycle model (e.g., requirements, design, manufacturing, test and evaluation, delivery, disposal) Types of processes used Types of products used Project management risks (e.g., contract risks, budget risks, schedule risks, resource risks) Technical performance risks (e.g., quality attribute related risks, supportability risks)

Prepare for Risk Management Define Risk Parameters Risk likelihood (i.e., probability of risk occurrence) Risk consequence (i.e., impact and severity of risk occurrence) Thresholds to trigger management activities

Prepare for Risk Management Establish a Risk Management Strategy The scope of the risk management effort Methods and tools to be used for risk identification, risk analysis, risk mitigation, risk monitoring, and communication Project specific sources of risks How risks are to be organized, categorized, compared, and consolidated Parameters used for taking action on identified risks, including likelihood, consequence, and thresholds Risk mitigation techniques to be used, such as prototyping, piloting, simulation, alternative designs, or evolutionary development The definition of risk measures used to monitor the status of risks

Identify and Analyze Risks Identify Risks Examine each element of the project work breakdown structure. Conduct a risk assessment using a risk taxonomy. Interview subject matter experts. Review risk management efforts from similar products. Examine lessons learned documents or databases. Examine design specifications and agreement requirements.

Identify and Analyze Risks Evaluate, Categorize, and Prioritize Risks Each risk is evaluated and assigned values according to defined risk parameters, which can include likelihood, consequence (i.e., severity, impact), and thresholds. The assigned risk parameter values can be integrated to produce additional measures, such as risk exposure (i.e., the combination of likelihood and consequence), which can be used to prioritize risks for handling.

Identify and Analyze Risks Evaluate, Categorize, and Prioritize Risks Low Medium High Negligible Marginal Significant Critical Catastrophic

Identify and Analyze Risks Evaluate, Categorize, and Prioritize Risks A relative priority is determined for each risk based on assigned risk parameters. Clear criteria should be used to determine risk priority. Risk prioritization helps to determine the most effective areas to which resources for risks mitigation can be applied with the greatest positive impact on the project.

Mitigate Risks Develop Risk Mitigation Plans A critical component of risk mitigation planning is developing alternative courses of action, workarounds, and fallback positions, and a recommended course of action for each critical risk. The risk mitigation plan for a given risk includes techniques and methods used to avoid, reduce, and control the probability of risk occurrence; the extent of damage incurred should the risk occur (sometimes called a “contingency plan”); or both. Risks are monitored and when they exceed established thresholds, risk mitigation plans are deployed to return the affected effort to an acceptable risk level. If the risk cannot be mitigated, a contingency plan can be invoked.

Mitigate Risks Implement Risk Mitigation Plans Risk avoidance: changing or lowering requirements while still meeting end user needs Risk control: taking active steps to minimize risks Risk transfer: reallocating requirements to lower risks Risk monitoring: watching and periodically reevaluating the risk for changes in assigned risk parameters Risk acceptance: acknowledging risk but not taking action

Risk tracking Monitor the status of each risk periodically and implement the risk mitigation plan as appropriate.

Issue Tracking

scenario The system test team files a formal test report which is sent to the requirements team. There are several defects in different requirements. These are broken into issues and tracked.

Agile development Issue tracking can be very useful fo rqucik moving, self-organizing teams Issue tracking can be very useful fo rqucik moving, self-organizing teams bielicki/issue-tracking-fits-agile bielicki/issue-tracking-fits-agile

Issue Tracking A project has many questions, pending decisions, and assigned actions from meetings. These items fall through the cracks of most process definitions. Using a tool makes it less likely something will be forgotten until it causes a major delay.

Regular committees The Change Control Board meets periodically. Change requests should have been entered into some system such as this before the meeting and members should have read them. During the meeting brief results can be entered directly; more extensive notes later They have their own section in the tracker. They may assign an issue to any team for further study.

Access Using a web-based interface allows a widely distributed community to use the information and contribute as well.

Ad hoc meetings Issues should be collected from these meetings but often they are not.

Trac This is a Standalone

Mylyn

Bugzilla

Integrated development environment IDE – you see it all the time but in the last few modules we have looked at pieces of it in detail Various of the issue tracking systems fit better or worse with the other tools we have already identified. The issue tracker’s ability to play nicely with the other tools is an important criteria in selecting a tool.

Example evaluation form Look at a couple of evaluation matrices solutions/alternatives-evaluation-matrix

Jira n-jira-tutorial-1/ n-jira-tutorial-1/