Presentation on theme: "CIS 375 Bruce R. Maxim UM-Dearborn"— Presentation transcript:
1 CIS 375 Bruce R. Maxim UM-Dearborn Risk ManagementCIS 375Bruce R. MaximUM-Dearborn
2 What is Risk?Risks are potential problems that may affect successful completion of a software project.Risks involve uncertainty and potential losses.Risk analysis and management are intended to help a software team understand and manage uncertainty during the development process.
3 Risk Strategies Reactive strategies Proactive strategies very common, also known as fire fightingproject team sets resources aside to deal with problemsteam does nothing until a risk becomes a problemProactive strategiesrisk management begins long before technical work starts, risks are identified and prioritized by importanceteam builds a plan to avoid risks if they can or to minimize risks if they turn into problems
4 Software Risks - 1 Project risks Technical risks Business risks threaten the project planTechnical risksthreaten product quality and the timeliness of the scheduleBusiness risksthreaten the viability of the software to be built (market risks, strategic risks, management risks, budget risks)
5 Software Risks - 2 Known risks Unknown risks predictable from careful evaluation of current project plan and those extrapolated from past project experienceUnknown riskssome problems will simply occur without warning
6 Risk Analysis Risk identification Risk projection Risk assessment impact of risks/likelihood of risk actually happeningRisk assessmentwhat will change if risk becomes problemRisk management
7 Risk Identification Product-specific risks Generic risks the project plan and software statement of scope are examined to identify any special characteristics of the product that may threaten the project planGeneric risksare potential threats to every software productproduct sizecustomer characteristicsdevelopment environmenttechnology to be built
8 Risk Projection The risk drivers affecting each risk component are classified according to their impact categorypotential consequences of each undetected software fault or unachieved project outcome are described
10 Risk EstimationEstablish a scale indicating perceived likelihood of risk occurringDetermine consequences.Estimate impact of consequences on project (for each risk).Note overall accuracy of risk projection (to avoid misunderstandings).
11 PS Risks Estimated size of project in LOC or FP 80% 2 ** CategoryProbabilityImpactRMMMEstimated size of project in LOC or FPPS80%2**Lack of needed specialization increases defects and reworksST50%Unfamiliar areas of the product take more time than expected to design and implementDEDoes the environment make use of a database35%3Components developed separately cannot be integrated easily, requiring redesign25%Development of the wrong software functions requires redesign and implementationDevelopment of extra software functions that are not needed20%Strict requirements for compatibility with existing system require more testing, design, and implementation than expectedOperation in unfamiliar software environment causes unforeseen problemsEV4Team members do not work well togetherKey personnel are available only part-time
12 Risk Table Construction - 1 List all risks in the first column of the tableClassify each risk and enter the category label in column twoDetermine a probability for each risk and enter it into column threeEnter the severity of each risk (negligible, marginal, critical, catastrophic) in column four.
13 Risk Table Construction - 2 Sort the table by probability and impact valueDetermine the criteria for deciding where the sorted table will be divided into the first priority concerns and the second priority concernsFirst priority concerns must be managed (a fifth column can be added to contain a pointer into the RMMM document)
14 CATEGORY \ COMPONENTSPERFORMANCESUPPORTCOSTSCHEDULECATASTROPHIC1Failure to meet would result in mission failureFailure results in increased costs and schedule delays with expected values in excess of $500K2Significant degradation to non-achievement of technical performanceNon-responsive or unsupportable softwareSignificant, financial shortages, budget overrun likelyUnachievable delivery dateCRITICALFailure to meet the requirement would degrade system performance to a point where mission success is questionableFailure results in operational delays and/or increased costs with expected value of $100K to $500kSome reduction in technical performanceMinor delays in software modificationsSome shortage of financial resources, possible overrunsPossible slippage in delivery date
15 CATEGORY \ COMPONENTSPERFORMANCESUPPORTCOSTSCHEDULEMARGINAL1Failure to meet the requirement would result in degradation of secondary missionCosts, impacts, and/or recoverable schedule slips with expected value of $1K to $100K2Minimal to small reduction in technical performanceResponsive software supportSufficient financial resourcesRealistic, achievable schedule NEGLIGIBLEFailure to meet the requirement would create inconvenience or nonoperational impactError results in minor cost and/or schedule impact with expected value of less than $1KNo reduction in technical performanceEasily supportable softwarePossible budget underrunEarly achievable date
16 Risk Assessment - 1Define referent levels for each project risk that can cause project terminationperformance degradationcost overrunsupport difficultyschedule slippageAttempt to develop a relationship between each risk triple (risk, probability, impact) and each of the reference levels.
17 Risk Assessment - 2Predict the set of referent points that define a region of termination, bounded by a curve or areas of uncertainty.Try to predict how combinations of risks will affect a referent level
19 Risk RefinementProcess of restating the risks as a set of more detailed risks that will be easier to mitigate, monitor, and manage.CTC (condition-transition-consequence) format may be a good representation for the detailed risks (e.g. given that <condition> then there is a concern that (possibly) <consequence>).
20 RMMM - 1 Risk mitigation Risk monitoring proactive planning for risk avoidanceRisk monitoringassessing whether predicted risks occur or notensuring risk aversion steps are being properly appliedcollect information for future risk analysisdetermining which risks caused which problems
21 RMMM - 2 Risk Management contingency planning actions to be taken in the event that mitigation steps have failed and the risk has become a live problem
22 Risk Mitigation Example Risk: loss of key team membersDetermine causes of job turnover.Eliminate causes before project starts.After project starts, assume turnover is going to occur and work to ensure continuity.Make sure teams are organized and distribute information widely.Define documentation standards and be sure documents are produced in a timely manner.Conduct peer review of all work.Define backup staff.
23 Risk Information Sheets Alternative to RMMM plan in which each risk is documented individually.Often risk information sheets (RIS) are maintained using a database system.RIS componentsrisk id, date, probability, impact, descriptionrefinement, mitigation/monitoringmanagement/contingency/triggerstatusoriginator, assigned staff member
24 Safety and HazardsRisks are also associated with software failures that occur in the field after the development project has ended.Computers control many mission critical applications today (weapons systems, flight control, industrial processes, etc.).Software safety and hazard analysis are quality assurance activities that are of particular concern for these types of applications