Chapter 6 Feasibility and Risk Management These courseware
Chapter 6 Feasibility and Risk Management These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 1
What is a Feasibility Study A study for determining the potential development of a software system. Organizational Feasibility Technical Feasibility Financial Feasibility Risk Management These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 2
What is a Feasibility Study Organizational Feasibility Who supports the development of this software Who will pay. Who is the missionary. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 3
What is a Feasibility Study Technical Feasibility New technology for our group More than one vendor involved Complex network software These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 4
What is a Feasibility Study Financial Feasibility Cost and Benefits Tangible costs Tangible benefits savings of emp. time, personnel, travel Intangible benefits marketing These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 5
What is a Feasibility Study Cost and Benefits Tangible costs Hardware Costs –test, target Software Costs – test, target People Costs – development, training, staff, management contractors These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 6
What is a Feasibility Study People Costs – development actual dev, conversion, maint. LOC FPA 8 loc per day – new dev - estimate measure the weight of a piece of developed or undeveloped software 1 hour per function point These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 7
What is a Feasibility Study FPA - Function Count simple ave complex external inputs external outputs external inquiry internal file external interfaces 3 4 3 7 5 4 10 7 6 15 10 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 8
What is a Feasibility Study FPA Function Count total from values or weight of software adjusted with application factor evaluation data communications performance transaction rate end user efficiency complex processing installation ease multiple sites distributed functions heavily used configuration on-line data entry on-line update reusability operational ease facilitation of change These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 9
What is a Feasibility Study FPA Processing complexity = PC PC Adjustment PCA =. 65 + (0. 01*PC) TOTAL Adjusted FPA = FC * PCA These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 10
What is a Feasibility Study BENEFITS TANGIBLE Performance Functionality Capacity INTANGIBLE Accuracy Decisions Competitive Edge Service These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 11
What is a Feasibility Study BENEFITS You have a staff who compose letters, etc and they currently use yellow pads to write up information, the local library to search information and a clerical staff to type the information. Suppose you want to calculate the benefit of Giving everyone a Word Processor with internet search capabilities Will this be of benefit? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 12
What is a Feasibility Study BENEFITS We have the following activities in this task Writing/Rev, Typing, Seeking Info You have the following people involved in doing these activities MANAGERS, PROFESSIONAL , SUPPORT what percentage of their time is spent on those activities These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 13
What is a Feasibility Study ACTIVITIES MAN PROF SUPPORT Ea Writing/Rev 10 15 5 20 Typing 0 0 25 40 Seeking Info 6 9 10 50 Ea = Average fraction of time employees spend on activity a that can be eliminated Tca = Average fraction of time spent by employee of category c on activity of type a Ex: Managers spend 10 percent of time writing/revising and 0 percent typing 20 percent of the Writing/Revising can be eliminated as a result These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are ofprovided newwithsystem permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 14
What is a Feasibility Study Nc = Number of employees in category c 1 Manager, 10 professionals and 5 clerical Pc = Average annual payment to each employee in category c for wages and fringe benefits. Managers make 90, 000 , Professionals make 60, 000 and Support make 30, 000 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 15
What is a Feasibility Study Nc and Pc 1@90, 000 10@60, 000 5@30, 000 ACTIVITIES MAN SUPP Ea Writing/Rev 10 15 5 20 Typing 0 0 25 40 Seeking Info 6 9 10 50 PROF These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 16
What is a Feasibility Study Sc = Fraction of time saved by an employee of category c by automation effort Sc = Tca*Ea Managers save 10%*20% = 2% Nc and Pc 1@90, 000 10@60, 000 ACTIVITIES MAN PROF SUPP Ea Writing/Rev 10 15 5 20 Typing 0 0 25 Seeking Info 6 9 10 Sc 5@30, 000 MAN PROF SUPP 2 3 1 40 0 0 10 50 3 4. 5 5 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 17
What is a Feasibility Study Tca = Average fraction of time spent by employee of category c on activity of type a Managers spend 10 percent of time writing/revising and 0 percent typing Ea = Average fraction of time employees spend on activity a that can be eliminated 20 percent of the Writing/Revising can be eliminated as a result of new system Nc = Number of employees in category c 1 Manager, 10 professionals clerical These courseware materialsand are to be 5 used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 18
What is a Feasibility Study S = Total Savings Pc = Average annual payment to each employee in category c for wages and fringe benefits. Managers make 90, 000 , Professionals make 60, 000 and Support make 30, 000 Sca = Nc. Pc. Sc Managers Savings for writing= 1*90, 000*2% = 450. 00 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 19
What is a Feasibility Study ACTIVITIES MAN PROF SUPP MAN Writing/Rev 2 3 1 450 Typing 0 0 10 0 Seeking Info 3 4. 5 5 675 PROF SUPP Sa 18, 000 1, 500 18, 950 0 15, 000 27, 000 7, 500 35, 175 Sa = Total Savings for that activity S = 69, 125 is the total savings per year What will be the cost of the word processing equipment? ? What will these people do with the extra time they have? ? Will that be productive? ? ? i. e. produce more money for the company? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 20
What is a Feasibility Study ACTIVITIES MAN PROF SUPP Sa Writing/Rev 450 18, 000 1, 500 18, 950 Typing 0 0 Seeking Info 675 15, 000 27, 000 7, 500 35, 175 Sa = Total Savings for that activity S = 69, 125 is the total savings per year These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 21
What is a Feasibility Study What will be the cost of the word processing equipment? ? What will these people do with the extra time they have? ? Will that be productive? ? ? i. e. produce more money for the company? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 22
Feasibility Now we know how to calculate cost and tangible benefits. How about the risk Risk is inversely proportional to risk. These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 23
Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 24
Reactive Risk Management project team reacts to risks when they occur mitigation—plan for additional resources in anticipation of fire fighting fix on failure—resource are found applied when the risk strikes crisis management—failure does not respond to applied resources and project is in jeopardy These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 25
Proactive Risk Management formal risk analysis is performed organization corrects the root causes of risk TQM concepts and statistical SQA examining risk sources that lie beyond the bounds of the software developing the skill to manage change These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 26
Risk Management Paradigm control track RISK identify plan analyze These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 27
Risk Areas 1. Personnel Shortfall 2. Unrealistic Schedule and Budget 3. Wrong Software Functionality 4. Wrong User Interfaces 5. Gold Plating 6. Requirement Changes 7. Shortfalls in Procured Software 8. Shortfalls in Procured Tasks 9. Real Time Performance Shortfalls 10. Computer Science Capabilities These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 28
Risk Areas 1. Personnel Shortfall a. Not enough personnel b. Personnel not trained c. Personnel used for other projects d. Personnel scheduling e. Personnel commitment f. Experience level of personnel g. Positional level of personnel h. Personnel assigned to other job descriptions i. Poor personnel agreements j. Lack of training, cross-training These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 k. Problems in subcontracting 29
Risk Areas Personnel Shortfall Risk Management Techniques a. Staffing with appropriate personnel b. Job Matching c. Team Building d. Securing personnel agreements e. Rescheduling personnel f. Hiring new personnel g. Training personnel h. Procuring usable subcontracts These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 30
Risk Areas 2. Unrealistic Schedule and Budget a. Schedule is too short b. Schedule is incorrectly structured c. Budget is too small d. Budget is not allocated properly These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 31
Risk Areas 2. Unrealistic Schedule and Budget Risk Management Techniques a. Multi-source costs and schedule b. Design to cost, schedule c. Incremental development d. Software Reuse e. Requirements Scrubbing f. Re-negotiations These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 32
Risk Areas 3, 4. Wrong Software Functionality and User Interfaces a. Wrong focus b. Wrong mission c. Wrong users d. Wrong data, functions, interfaces e. No acceptance procedure These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 33
Risk Areas 3, 4. Wrong Software Functionality and User Interface Risk Management Techniques a. Organizational Analysis b. ISP - Mission statement building c. Define users for approvals d. Prototyping e. Early user manual procedures development f. Establish acceptance procedure These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 34
Risk Areas Gold Plating Risk Management Techniques a. Requirements Scrubbing b. Prototyping requirements c. Cost Benefit Analysis d. Design to cost These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 35
Risk Areas 6. Requirement Changes a. Change in user requirements b. Change in system requirements c. Change in mission d. Change in user acceptance procedures e. Change in environment These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 36
Risk Areas 6. Requirement Changes Risk Management Techniques a. High Change Threshold b. Information Hiding c. Incremental Development d. Change Deferral e. Tight change control f. Agreement of acceptance criteria These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 37
Risk Areas 7, 8. Shortfalls in Procured Software Shortfalls in Procured Tasks a. Not completed correctly b. Not right software c. Not documented d. Not on time e. Not within budget …. . These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 38
Risk Areas 9. Real Time Performance Shortfalls a. Software works but is TOO slow b. Software requires too many interfaces to work timely These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 39
Risk Areas 9. Real Time Performance Shortfalls a. Simulation b. Benchmarking c. Modeling d. Prototyping e. Tuning f. Problem does not complete in time g. Problem does not compute correctly These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 i. Problem is TOO big 40
Risk Areas 10. Computer Science Capabilities a. Technical Analysis b. Cost benefit analysis c. Prototyping d. Modeling e. Reference Checking f. Performance analysis g. Sizing Analysis These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 41
Risk Management Model RF = P F + C F - P F * CF Three Step Process 1. Identify the Area(s) or Risk 2. Partition each risk area into critical factors 3. Examine the consequences of failure These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 42
Risk Management Model Example: 1. Identify the Area(s) or Risk Changes in Requirements These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 43
Risk Management Model 2. Partition each risk area into critical factors (why are you concerned) a. List factors b. Determine evaluation of the factors These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 44
Risk Management Model 2. Partition each risk area into critical factors a. List the factors (why are you concerned) SRS Quality Change Control Client Concurrence These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 45
Risk Management Model 2. Partition each risk area into critical factors b. Determine evaluation of the factors SRS Quality Change Control Client Concurrence These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 46
Risk Management Model 2. b. Determine evaluation of the factors SRS Quality 0. 50 Change Control 0. 30 Client Concurrence 0. 20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 47
Risk Management Model 2. b. Determine evaluation of the factors - SRS Quality 0. 1 Minor Corrections Required 0. 3 Some SRS problems - issues being addressed - plan in place 0. 5 Significant problems - activity is trying to resolve 0. 7 Significant problems - not able to resolve 0. 9 Significant problems - no plan These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 48
Risk Management Model 2. b. Determine evaluation of factors - Change Control 0. 1 Control Board Hierarchy - Strong Discipline 0. 3 Control Board Hierarchy - Weak Discipline 0. 5 No established procedures informal procedures currently working 0. 7 Formal procedures ignored informal procedures currently not working 0. 9 No change control process in place These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 49
Risk Management Model 2. b. Determine evaluation factors -Client Concurrences 0. 1 Agreed to acceptance criteria 0. 3 Working on agreements 0. 5 New requirements surface with no agreements 0. 7 No one concerned about cost and schedule 0. 9 No control of users changes These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 50
Risk Management Model 3. Examine the consequences of failure (what might happen if you disregard) a. List consequences b. Determine evaluation of the consequences These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 51
Risk Management Model 3. a. List consequences Example: Cost Schedule Performance These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 52
Risk Management Model 3. b. Determine evaluation of the consequences Cost 0. 60 Schedule 0. 20 Performance 0. 20 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 53
Risk Management Model 3. b. Determine evaluation consequences Cost 0. 1 Within budget 0. 3 1 -5% increase 0. 5 5 -20% increase 0. 7 20 -40% increase 0. 8 Greater than 40% increase These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 54
Risk Management Model 3. b. Determine evaluation consequences Schedule 0. 1 Within plan 0. 3 Minor slip - 1 month 0. 5 1 -3 month slip 0. 7 Greater than 3 months 0. 9 Greater than 6 months These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 55
Risk Management Model 3. b. Determine evaluation consequences Performance 0. 1 Minimal consequences manageable 0. 3 Small reduction in product performance, and functionality 0. 5 Some reduction …. . 0. 7 Significant reduction …. . 0. 9 Product is unusable, client reject These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 56
Risk Management Model RF = P F + C F - P F * CF One way to do this is not to use the percentages: PF = sum of values assigned to each factor/ number of factors These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 57
Risk Management Model RF = P F + C F - P F * CF PF = sum of values assigned to each factor/ number of factors Example: suppose evaluation was SRS quality 0. 5 Change Control 0. 9 Client Concurrence 0. 9 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 58
Risk Management Model RF = P F + C F - P F * CF PF = sum of values assigned to each factor/ number of factors Example: SRS 0. 5, Ch. Cn (0. 5 + 0. 9) / 3 0. 9, Cl Co 0. 9 =. 76 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 59
Risk Management Model RF = P F + C F - P F * CF CF = sum of values assigned to each consequence/ number of consequences Example: suppose evaluation was Cost Schedule 0. 5 0. 9 Performance 0. 8 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 60
Risk Management Model RF = P F + C F - P F * CF CF = sum of values assigned to each consequence/number of consequences Example: Cost 0. 5, (0. 5 + 0. 9 + 0. 8) / 3 Schedule 0. 9, Performance 0. 8 =. 70 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 61
Risk Management Model RF = P F + C F - P F * CF RF = 0. 76 + 0. 70 - 0. 76*0. 70 RF = 1. 46 - 0. 532 RF = 0. 928 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 62
Risk Management Model PF 1. 0 0. 8 0. 7 0. 6 0. 4 0. 3 0. 2 0. 3 0. 4 0. 6 0. 7 0. 8 1. 0 CF These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 63
Risk Management Model RF = P F + C F - P F * CF Using the percentages: PF = 0. 50 * value for factor 1 (0. 5) + 0. 30 * value for factor 2 (0. 9) + 0. 20 * value for factor 3 (0. 9) = 0. 25 + 0. 27 + 0. 18 = 0. 70 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 64
Risk Management Model RF = P F + C F - P F * CF Using the percentages: CF = 0. 60 * value for factor 1 (0. 5) + 0. 20 * value for factor 2 (0. 9) + 0. 20 * value for factor 3 (0. 8) = 0. 30 + 0. 18 + 0. 16 = 0. 62 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 65
Risk Management Model RF = P F + C F - P F * CF RF = 0. 70 + 0. 62 - 0. 70*0. 62 RF = 1. 32 - 0. 434 RF = 0. 886 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 66
Risk Management Model PF 1. 0 0. 8 0. 7 0. 6 0. 4 0. 3 0. 2 0. 3 0. 4 0. 6 0. 7 0. 8 1. 0 CF These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 67
Risk Management Model Avoid Prevent Assume Transfer Research These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 68
Risk Management Model Avoid - If the risk is too great, a contractor may decline to bid on or accept a job. Transfer A contractor my assign the risk to another contractor Research These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 69
Risk Management Model Cost Performance Measurements Technical Performance Measurements PVF = PF * Cost of problem PVF = 0. 20 * 0. 6 million (cost of slipage) PVF = 120, 000 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 70
Risk Management Model Risk Measurement Tools 1. Actual Expenses vs Planned Expenses 2. Actual Milestones vs Planned Milestones 3. TPM These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 71
Risk Management Model Objectives Introduction Risk Areas Risk Management Model Risk Containment Examples These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 72
Building a Risk Table Risk Probability Impact RMMM Risk Mitigation Monitoring & Management These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 73
Building the Risk Table Estimate the probability of occurrence Estimate the impact on the project on a scale of 1 to 5, where 1 = low impact on project success 5 = catastrophic impact on project success sort the table by probability and impact These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 74
Risk Mitigation, Monitoring, and Management mitigation—how can we avoid the risk? monitoring—what factors can we track that will enable us to determine if the risk is becoming more or less likely? management—what contingency plans do we have if the risk becomes a reality? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 75
Risk Due to Product Size Attributes that affect risk: • estimated size of the product in LOC or FP? • estimated size of product in number of programs, files, transactions? • percentage deviation in size of product from average for previous products? • size of database created or used by the product? • number of users of the product? • number of projected changes to the requirements for the product? before delivery? after delivery? • amount of reused software? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 76
Risk Due to Business Impact Attributes that affect risk: • affect 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 • interoperability constraints • sophistication of end users? • amount and quality of product documentation that must be produced and delivered to the customer? • governmental constraints • costs associated with late delivery? • costs associated with a defective product? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 77
Risks Due to the Customer Questions that must be answered: • • Have you worked with the customer in the past? Does the customer have a solid idea of requirements? Has the customer agreed to spend time with you? Is the customer willing to participate in reviews? • Is the customer technically sophisticated? • Is the customer willing to let your people do their job—that is, will the customer resist looking over your shoulder during technically detailed work? • Does the customer understand the software engineering process? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 78
Risks Due to Process Maturity Questions that must be answered: • Have you established a common process framework? • Is it followed by project teams? • Do you have management support for software engineering • Do you have a proactive approach to SQA? • Do you conduct formal technical reviews? • Are CASE tools used for analysis, design and testing? • Are the tools integrated with one another? • Have document formats been established? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 79
Technology Risks Questions that must be answered: • Is the technology new to your organization? • Are new algorithms, I/O technology required? • Is new or unproven hardware involved? • Does the application interface with new software? • Is a specialized user interface required? • Is the application radically different? • Are you using new software engineering methods? • Are you using unconventional software development methods, such as formal methods, AI-based approaches, artificial neural networks? • Are there significant performance constraints? • Is there doubt the functionality requested is "do-able? " These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 80
Staff/People Risks Questions that must be answered: • • Are the best people available? Does staff have the right skills? Are enough people available? Are staff committed for entire duration? Will some people work part time? Do staff have the right expectations? Have staff received necessary training? Will turnover among staff be low? These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 81
Recording Risk Information Project: Embedded software for XYZ system Risk type: schedule risk Priority (1 low. . . 5 critical): 4 Risk factor: Project completion will depend on tests which require hardware component under development. Hardware component delivery may be delayed Probability: 60 % Impact: Project completion will be delayed for each day that hardware is unavailable for use in software testing Monitoring approach: Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using software simulation Estimated resources: 6 additional person months beginning 7 -1 -96 These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 5/e and are provided with permission by R. S. Pressman & Associates, Inc. , copyright © 1996, 2001 82
- Slides: 82