DOC PREVIEW
U-M CIS 375 - Risk Management
Course Cis 375-
Pages 24

This preview shows page 1-2-23-24 out of 24 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 24 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Risk ManagementWhat is Risk?Risk StrategiesSoftware Risks - 1Software Risks - 2Risk AnalysisRisk IdentificationRisk ProjectionRisk ImpactRisk EstimationPowerPoint PresentationRisk Table Construction - 1Risk Table Construction - 2Slide 14Slide 15Risk Assessment - 1Risk Assessment - 2Project TerminationRisk RefinementRMMM - 1RMMM - 2Risk Mitigation ExampleRisk Information SheetsSafety and Hazards1Risk ManagementCIS 375Bruce R. MaximUM-Dearborn2What 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.3Risk Strategies•Reactive strategies–very common, also known as fire fighting–project team sets resources aside to deal with problems–team does nothing until a risk becomes a problem•Proactive strategies–risk management begins long before technical work starts, risks are identified and prioritized by importance–team builds a plan to avoid risks if they can or to minimize risks if they turn into problems4Software Risks - 1•Project risks–threaten the project plan•Technical risks–threaten product quality and the timeliness of the schedule •Business risks–threaten the viability of the software to be built (market risks, strategic risks, management risks, budget risks)5Software Risks - 2•Known risks–predictable from careful evaluation of current project plan and those extrapolated from past project experience•Unknown risks–some problems will simply occur without warning6Risk Analysis•Risk identification•Risk projection–impact of risks/likelihood of risk actually happening•Risk assessment–what will change if risk becomes problem•Risk management7Risk Identification•Product-specific risks–the project plan and software statement of scope are examined to identify any special characteristics of the product that may threaten the project plan•Generic risks–are potential threats to every software product•product size•customer characteristics•development environment•technology to be built8Risk Projection•The risk drivers affecting each risk component are –classified according to their impact category–potential consequences of each undetected software fault or unachieved project outcome are described9Risk Impact•Risk components–performance–cost–support–schedule•Risk impact–negligible–marginal–critical–catastrophic10Risk Estimation1. Establish a scale indicating perceived likelihood of risk occurring2. Determine consequences.3. Estimate impact of consequences on project (for each risk).4. Note overall accuracy of risk projection (to avoid misunderstandings).11RisksCategory Probability Impact RMMMEstimated size of project in LOC or FPPS80% 2 **Lack of needed specialization increases defects and reworksST 50% 2 **Unfamiliar areas of the product take more time than expected to design and implementDE 50% 2 **Does the environment make use of a database DE 35% 3 Components developed separately cannot be integrated easily, requiring redesignDE 25% 3 Development of the wrong software functions requires redesign and implementationDE 25% 3 Development of extra software functions that are not neededDE 20% 3 Strict requirements for compatibility with existing system require more testing, design, and implementation than expectedDE 20% 3 Operation in unfamiliar software environment causes unforeseen problemsEV 25% 4 Team members do not work well together ST 20% 4 Key personnel are available only part-time ST 20% 412Risk Table Construction - 1•List all risks in the first column of the table•Classify each risk and enter the category label in column two•Determine a probability for each risk and enter it into column three•Enter the severity of each risk (negligible, marginal, critical, catastrophic) in column four.13Risk Table Construction - 2•Sort the table by probability and impact value•Determine the criteria for deciding where the sorted table will be divided into the first priority concerns and the second priority concerns•First priority concerns must be managed (a fifth column can be added to contain a pointer into the RMMM document)14CATEGORY \ COMPONENTS PERFORMANCE SUPPORT COST SCHEDULECATASTROPHIC 1 Failure to meet would result in mission failureFailure results in increased costs and schedule delays with expected values in excess of $500K 2Significant degradation to non-achievement of technical performanceNon-responsive or unsupportable softwareSignificant, financial shortages, budget overrun likelyUnachievable delivery dateCRITICAL 1 Failure 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 $500k 2Some reduction in technical performanceMinor delays in software modificationsSome shortage of financial resources, possible overrunsPossible slippage in delivery date15CATEGORY \ COMPONENTS PERFORMANCE SUPPORT COST SCHEDULEMARGINAL 1 Failure to meet the requirement would result in degradation of secondary missionCosts, impacts, and/or recoverable schedule slips with expected value of $1K to $100K 2 Minimal to small reduction in technical performanceResponsive software supportSufficient financial resourcesRealistic, achievable schedule NEGLIGIBLE 1 Failure to meet the requirement would create inconvenience or nonoperational impactError results in minor cost and/or schedule impact with expected value of less than $1K 2 No reduction in technical performanceEasily supportable softwarePossible budget underrunEarly achievable date16Risk Assessment - 1•Define referent levels for each project risk that can cause project termination– performance degradation–cost overrun–support difficulty–schedule slippage•Attempt to develop a relationship between each risk triple (risk, probability, impact) and each of the reference levels.17Risk Assessment - 2•Predict 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 level18Project Termination19Risk Refinement•Process of restating the risks as a set of more detailed risks that will be easier to mitigate, monitor, and manage.•CTC


View Full Document

U-M CIS 375 - Risk Management

Course: Cis 375-
Pages: 24
Download Risk Management
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Risk Management and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Risk Management 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?