11_SoftwareRisks
-
Upload
api-3775463 -
Category
Documents
-
view
104 -
download
1
Transcript of 11_SoftwareRisks
![Page 1: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/1.jpg)
Risk Analysis and Management
![Page 2: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/2.jpg)
Look Out!!
• If you don't actively attack the risks, they will actively attack you.– Tom Gilb
![Page 3: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/3.jpg)
Risk Characteristics
• uncertainty – an risk may or may not happen
• loss – an risk has unwanted consequences or losses
![Page 4: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/4.jpg)
Risk Definitions• Risk is the potential for realization of unwanted
negative consequences of an event. – [Rowe, William D. An Anatomy of Risk 1988]
• Risk is the measure of the probability and severity of adverse effects.
– [Lowrance, William W. Of Acceptable Risk 1976]
• Risk is the possibility of suffering loss, injury, disadvantage, or destruction. – [Webster's Third New International Dictionary 1981]
![Page 5: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/5.jpg)
MIS Risks
Risk Occurrences
Creeping user requirements 80
Excessive schedule pressure 65
Low quality 60
Cost Overruns 55
Inadequate Conf. Control 50
![Page 6: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/6.jpg)
System Software Risks
Risk Occurrence
Long schedule 70
Inadequate cost estimation 65
Excessive paperwork 60
Error-prone modules 50
Cancelled Projects 35
![Page 7: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/7.jpg)
Commercial Software Risks
Risk Occurrences
Inadequate User documentation
70
Low User satisfaction 55
Excessive time to market 50
Harmful competitive actions 45
Litigation expenses 30
![Page 8: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/8.jpg)
Defense Software Risks
Risk Occurrences
Excessive paperwork 90
Low productivity 85
Long Schedules 75
Creeping user requirements 70
Unusable software 45
![Page 9: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/9.jpg)
Contract Software Risks
Risk Occurrences
High Maintenance costs 60
Contractor Vs Client frictions 50
Creeping user requirements 45
Unanticipated acceptance criteria
30
Legal ownership 20
![Page 10: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/10.jpg)
End-user Software Risks
Risk Occurrences
Non-transferable applications 80
Hidden errors 65
Non maintainable software 60
Redundant applications 50
Legal Ownership 20
![Page 11: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/11.jpg)
Risk Analysis
– Risk Identification– Risk Projection– Risk Assessment– Risk Management
![Page 12: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/12.jpg)
Risk Identification
• Project Risks • Technical Risks • Business Risks
![Page 13: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/13.jpg)
Project Risks
• Potential budgetary, schedule, personnel, resources, customer and requirements problems and their impact.
• Project complexity, size and structural uncertainty are determining factors.
![Page 14: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/14.jpg)
Technical Risks
• Potential design, implementation, interfacing, verification and maintenance problems.
• Specification ambiguity, technical uncertainty, technical obsolescence and leading edge technology.
![Page 15: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/15.jpg)
Business Risks • Market Risk
– building a product that no one really wants.
• Product Risks– building a product that no longer fits into the
overall product strategy for the company.– building a product that the sales force doesn't
understand how to sell.
• Management Risk: – losing the support of senior management due to a
change in focus or people.
• Budget Risk– losing budgetary or personnel commitment.
![Page 16: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/16.jpg)
Risk-item checklist
• Product size• Business impact• Customer characteristics• Process definition• Development environment• Technology to be built• Staff size and experience
![Page 17: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/17.jpg)
Product size risks
• Estimated size of the product in LOC or FP?
• Estimated size of product in number of programs, files, and transactions?
• Percentage of deviation in size of product from average for previous products?
• Size of database created or used by the product?
![Page 18: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/18.jpg)
Product size risks
• Number of users of the product?• Number of projected changes to
the requirements for the product?• Number of changes before
delivery? After delivery?• Amount of reused software?
![Page 19: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/19.jpg)
Business impact risks• Effect of this product on company revenue?• Visibility of this product by senior
management?• Reasonableness of delivery deadline?• Number of customers who will use this
product and the consistency of their needs relative to the product?
• Number of other products or systems with which this product must be interoperable?
• Sophistication of end users?
![Page 20: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/20.jpg)
Business impact risks• Amount and quality of product
documentation that must be produced and delivered to the customer?
• Governmental regulatory constraints on the construction of the product?
• Costs associated with late delivery?• Costs associated with a defective
product?
![Page 21: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/21.jpg)
Customer characteristics risks
• Have you worked with the customer in the past?
• Does the customer have a solid idea of what is required? Will the customer agree to spend time in FAST meetings to identify project scope?
• Is the customer willing to establish rapid communication links with the developer?
![Page 22: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/22.jpg)
Customer characteristic risks• Is the customer willing to participate in
reviews?• Is the customer technically
sophisticated in the product area?• Is the customer willing to let your
people do their job i.e., will the customer resist looking over your shoulder during detailed technical work?
• Does the customer understand the SE process?
![Page 23: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/23.jpg)
Process definition risks• Does your senior management support a
written policy statement that defines a process for software development?
• Are specific documentation formats defined?
• Are formal technical reviews of the SRS, design, test procedures and test cases and code conducted regularly?
• Is SCM used to maintain consistency among system /software requirements, design, code, and test cases?
![Page 24: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/24.jpg)
Process definition risks• Is more than 90 % of your code written
in a high-order language?• Are software tools used to support
planning and tracking activities?• Are CASE tools used to support the
software analysis and design process, prototyping, test support, documentation?
• Are quality and productivity metrics collected for all software projects?
![Page 25: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/25.jpg)
Technology risks• Is the technology to be built new to your
organization?• Do the customer’s requirements
demand the creation of new algorithms or input or output technology?
• Does the software interface with new or unproven hardware?
• Does the software to be built interface with vendor-supplied software products that are unproven?
![Page 26: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/26.jpg)
Technology risks• Does the software to be built interface with
a database system whose function and performance have not been proved in this application area?
• Is a specialized user interface demanded by product requirements?
• Do requirements for the product demand the creation of program components that are unlike any previously developed by your organization? What percentage of components are new?
![Page 27: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/27.jpg)
Technology risks• Do requirements demand the use of new
analysis, design, or testing methods?• Do requirements demand the use of
unconventional software development methods, such as formal methods, AI based approaches, or artificial neural networks?
• Do requirements put excessive performance constraints on the product?
• Is the customer uncertain that the functionality requested is “doable”?
![Page 28: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/28.jpg)
Checklist for staffing risk• Are the best people available? • Are enough (too many) people available? • Do the people have the right combination of
skills? • Have staff members received the necessary
training? • Is the staff committed for the entire project
duration? • Will some staff members only be part time? • Will staff turnover be low enough for continuity?
![Page 29: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/29.jpg)
Risk Projection (Estimation)
• Attempts to rate each risk in two ways: – Likelihood that the risk is real. – Consequences of the problems
associated with the risk, should it occur.
![Page 30: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/30.jpg)
Risk projection activities
• Establishing a scale that reflects the perceived likelihood of a risk: Boolean, qualitative, quantitative
• Delineating the consequences of a risk.
• Establishing the impact of the risk on the project and the product.
• Noting the overall accuracy of the risk projection.
![Page 31: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/31.jpg)
Probability Quantification
impossible toimprobable
probable frequent value
Prob. value (0, 0.4) (0.4, 0.7) (0.7, 1)Performance ------------- -------------Cost ------------- -------------Schedule ------------- -------------support ------------- -------------
![Page 32: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/32.jpg)
Risk Drivers
Performance Cost Schedule support
Requirements Requirements Resources Design
Constraints Personnel Need dates Responsibilities
Technology Reusable SW Technology Tools, env
Dev. approach Tools, env Requirements Supportability
![Page 33: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/33.jpg)
Impact Assessment
Performance Cost Schedule support
Catastrophic
Critical
Marginal
negligible
![Page 34: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/34.jpg)
Risk Assessment
frequent probable improbable impossible
Prob. value (0.7, 1) (0.4, 0.7) (0, 0.4) 0
catastrophic
critical
marginal
negligible
HIGH
MODERATE
LOW
NONE
![Page 35: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/35.jpg)
Factors affecting Impact• Risks are weighted by perceived impact and
then prioritized. Three factors affect impact: • The nature of the risk indicates the
problems that are likely if it occurs. • The scope of a risk combines its severity
with its overall distribution. • The timing of a risk determines when and
for how long the impact will be felt. • The importance of risk impact and
probability is linked to their effect on management concerns.
![Page 36: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/36.jpg)
Risk Assessment
Risks can be represented as a set of triplets of the form: [r,l,x] where – r is risk – l is the likelihood (probability) of
the risk – x is the impact of the risk.
![Page 37: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/37.jpg)
Risk Assessment
During risk assessment the following actions occur: – An examination of the accuracy of the
estimates made during risk projection. – A prioritization of the risks that have
been uncovered. – A preliminary examination of the ways
to control and/or avert likely risks.
![Page 38: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/38.jpg)
Risk Referent Level • At a certain level of risk, or a combination
of risks, a project will have to be terminated.
• A risk referent level has a single point, called the referent or break point, at which time the decision to proceed or terminate are equally acceptable.
• Cost, schedule, support and performance represent typical risk referent levels.
![Page 39: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/39.jpg)
Risk Referent Level
Projected cost overrun
Pro
ject
ed s
ched
ule
over
run
Referent point
High risk area
![Page 40: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/40.jpg)
Risk Assessment Checklist
• Define the risk referent levels for the project. Referents are stated as a probability of failure or the probability of success level for each individual risk or the system as a whole.
• A value should be agreed upon where it is decided that a project should not continue.
![Page 41: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/41.jpg)
The system risk referent can be: • an aggregate of individual risks, or one or
more prioritized high impact risks • Attempt to develop a relationship between
each [r,l,x] and each of the referent levels. • Predict the set of referent points that
define a region of termination, bounded by a curve or areas of uncertainty.
• Try to predict how compound combinations of risks will affect a referent level.
![Page 42: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/42.jpg)
Risk Evaluation Outcomes
Comparing the evaluated risk against its risk referent has three possible outcomes:
1.Acceptable : the evaluated risk is less than the referent.
2.Impossible : the evaluated risk is much greater than the referent.
3.Infeasible : the evaluated risk is greater than, but almost equal to, the referent.
![Page 43: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/43.jpg)
What is Risk Management?
• Making informed decisions by consciously assessing what can go wrong and the severity of its impact.
• A comprehensive risk management strategy, as part of total quality management approach, aims at anticipating and eliminating all the causes of risk
![Page 44: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/44.jpg)
Why Do Risk Management
– Eliminate surprises– Anticipate issues - prevent
problems– Begin programs on the "right"
foot and stay on track– Reach business goals
![Page 45: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/45.jpg)
SEI Risk Management Paradigm
![Page 46: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/46.jpg)
RMMP Outline
I. Introduction II. Risk analysis III. Risk managementIV. Appendixes
![Page 47: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/47.jpg)
RMMP - Introduction A. Scope and purpose of documentB. Overview
1. Objectives, 2. Risk aversion priorities
C. Organization1. Management, 2. Responsibilities, 3. Job descriptions
D. Aversion program description1. Schedule, 2. Major milestones and reviews, 3. Budget
![Page 48: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/48.jpg)
RMMP - Risk analysis
A. Identification1. Survey or risks, a. Sources of risk, 2. Risk taxonomy
B. Risk estimation1. Estimate probability of risk, 2. Estimate consequence of risk, 3. Estimation criteria, 4. Possible sources of estimation error
C. Evaluation1. Evaluation methods to be used, 2. Method assumptions and limitations, 3. Risk referents, 4. Results
![Page 49: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/49.jpg)
RMMP - Risk management
A. RecommendationsB. Risk aversion optionsC. Risk aversion recommendationsD. Risk monitoring procedures
![Page 50: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/50.jpg)
IV. Appendixes
A. Risk estimate of the situationB. Risk abatement plan
![Page 51: 11_SoftwareRisks](https://reader031.fdocuments.us/reader031/viewer/2022013011/54652073b4af9f5a2d8b46f7/html5/thumbnails/51.jpg)
References
• Assessment and Control of Software Risks– Capers Jones
• http://www.baz.com/kjordan/swse625/htm/tp-rm.htm
• http://www.leitner.org/courses/du/isys420-0103/risks.pdf
• http://www.sei.cmu.edu/organization/programs/sepm/risk/