1. 1 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 Chapter 6 Feasibility and Risk Management

2. 2 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 What is a Feasibility Study  A study for determining the potential development of a software system.  Organizational Feasibility  Technical Feasibility  Financial Feasibility  Risk Management

3. 3 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 What is a Feasibility Study  Organizational Feasibility  Who supports the development of this software  Who will pay.  Who is the missionary.

4. 4 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 What is a Feasibility Study  Technical Feasibility  New technology  New technology for our group  More than one vendor involved  Complex network software

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 What is a Feasibility Study Financial Feasibility Cost and Benefits Tangible costs Tangible benefits savings of emp. time, personnel, travel Intangible benefits marketing

6. 6 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 What is a Feasibility Study Cost and Benefits Tangible costs Hardware Costs –test,target Software Costs – test,target People Costs – development, training,staff, managementcontractors

7. 7 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 What is a Feasibility Study People Costs – development actual dev, conversion, maint. LOC 8 loc per day – new dev - estimate FPA measure the weight of a piece of developed or undeveloped software developed or undeveloped software 1 hour per function point

8. 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 What is a Feasibility Study FPA - Function Count simple ave complex external inputs346 external outputs457 external outputs457 external inquiry346 external inquiry346 internal file71015 internal file71015 external interfaces5710 external interfaces5710

9. 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 What is a Feasibility Study FPA Function Count total from values or weight of software adjusted with application factor evaluation data communications distributed functions performanceheavily used configuration transaction rateon-line data entry end user efficiencyon-line update complex processingreusability installation easeoperational ease multiple sitesfacilitation of change

10. 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 What is a Feasibility Study FPA Processing complexity = PC PC Adjustment PCA =.65 + (0.01*PC) TOTAL Adjusted FPA = FC * PCA

11. 11 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 What is a Feasibility Study BENEFITS TANGIBLE Performance Functionality Capacity INTANGIBLE Accuracy Decisions Competitive Edge Service

12. 12 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 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?

13. 13 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 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

14. 14 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 What is a Feasibility Study ACTIVITIES MAN PROF SUPPORT Ea Writing/Rev 1015 5 20 Typing 0 02540 Seeking Info 6 91050 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 of new system

15. 15 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 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

16. 16 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 What is a Feasibility Study Nc and Pc 1@90,000 10@60,000 5@30,000 ACTIVITIES MAN PROF SUPP Ea Writing/Rev 10 15 5 20 Typing 0 0 2540 Seeking Info 6 9 1050

17. 17 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 What is a Feasibility Study Sc = Fraction of time saved by an employee of category c by automation effort Sc = Tca*EaManagers save 10%*20% = 2% Nc and Pc 1@90,000 10@60,000 5@30,000 Sc ACTIVITIES MAN PROF SUPP Ea MAN PROF SUPP Writing/Rev 10 15 5 20 23 1 Typing 0 0 2540 0 0 10 Seeking Info 6 9 1050 3 4.5 5

18. 18 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 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 and 5 clerical

19. 19 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 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 = NcPcSc Managers Savings for writing= 1*90,000*2% = 450.00

20. 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 What is a Feasibility Study ACTIVITIES MAN PROF SUPP MAN PROF SUPP Sa Writing/Rev 2 3 1450 18,000 1,500 18,950 Typing 0 0 10 0 0 15,000 15,000 Seeking Info 3 4.5 5675 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?

21. 21 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 What is a Feasibility Study ACTIVITIES MAN PROF SUPP Sa Writing/Rev 450 18,000 1,500 18,950 Typing 0 0 15,000 15,000 Seeking Info 675 27,000 7,500 35,175 Sa = Total Savings for that activity S = 69,125 is the total savings per year

22. 22 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 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?

23. 23 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 Feasibility  Now we know how to calculate cost and tangible benefits.  How about the risk  Risk is inversely proportional to risk.

24. 24 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 Project Risks What can go wrong? What is the likelihood? What will the damage be? What can we do about it?

25. 25 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 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 and applied when the risk strikes  crisis management—failure does not respond to applied resources and project is in jeopardy

26. 26 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 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

27. 27 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 RISK Risk Management Paradigm control identify analyze plan track

28. 28 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 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

29. 29 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 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 k. Problems in subcontracting

30. 30 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 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

31. 31 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 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

32. 32 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 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

33. 33 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 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

34. 34 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 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

35. 35 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 Risk Areas Gold Plating Risk Management Techniques a. Requirements Scrubbing b. Prototyping requirements c. Cost Benefit Analysis d. Design to cost

36. 36 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 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

37. 37 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 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

38. 38 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 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 …..

39. 39 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 Risk Areas 9. Real Time Performance Shortfalls a. Software works but is TOO slow b. Software requires too many interfaces to work timely

40. 40 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 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 i. Problem is TOO big

41. 41 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 Risk Areas 10. 10.Computer Science Capabilities a. Technical Analysis b. Cost benefit analysis c. Prototyping d. Modeling e. Reference Checking f. Performance analysis g. Sizing Analysis

42. 42 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 Risk Management Model R F = P F + C F - P F * C F Three Step Process 1. Identify the Area(s) or Risk 2. Partition each risk area into critical factors 3. Examine the consequences of failure

43. 43 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 Risk Management Model Example: 1. Identify the Area(s) or Risk Changes in Requirements

44. 44 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 Risk Management Model 2. Partition each risk area into critical factors (why are you concerned) a. List factors b. Determine evaluation of the factors

45. 45 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 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

46. 46 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 Risk Management Model 2. Partition each risk area into critical factors b. Determine evaluation of the factors SRS Quality Change Control Client Concurrence

47. 47 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 Risk Management Model 2. b. Determine evaluation of the factors SRS Quality 0.50 Change Control 0.30 Client Concurrence0.20

48. 48 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 Risk Management Model 2. b. Determine evaluation of the factors - SRS Quality 0.1Minor Corrections Required 0.3Some SRS problems - issues being addressed - plan in place 0.5Significant problems - activity is trying to resolve 0.7Significant problems - not able to resolve 0.9Significant problems - no plan

49. 49 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 Risk Management Model 2. b. Determine evaluation of factors - Change Control 0.1Control Board Hierarchy - Strong Discipline 0.3Control Board Hierarchy - Weak Discipline 0.5No established procedures - informal procedures currently working 0.7Formal procedures ignored - informal procedures currently not working 0.9No change control process in place

50. 50 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 Risk Management Model 2. b. Determine evaluation factors -Client Concurrences 0.1Agreed to acceptance criteria 0.3Working on agreements 0.5New requirements surface with no agreements 0.7No one concerned about cost and schedule 0.9No control of users changes

51. 51 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 Risk Management Model 3. Examine the consequences of failure (what might happen if you disregard) a. List consequences b. Determine evaluation of the consequences

52. 52 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 Risk Management Model 3. a. List consequences Example: Cost Schedule Performance

53. 53 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 Risk Management Model 3. b. Determine evaluation of the consequences Cost0.60 Schedule0.20 Performance0.20

54. 54 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 Risk Management Model 3. b. Determine evaluation consequences Cost 0.1 Within budget 0.3 1-5% increase 0.5 5-20% increase 0.720-40% increase 0.8Greater than 40% increase

55. 55 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 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.7Greater than 3 months 0.9Greater than 6 months

56. 56 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 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.7Significant reduction ….. 0.9Product is unusable, client reject

57. 57 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 Risk Management Model R F = P F + C F - P F * C F One way to do this is not to use the percentages: P F = sum of values assigned to each factor/ number of factors

58. 58 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 Risk Management Model R F = P F + C F - P F * C F P F = sum of values assigned to each factor/ number of factors Example: suppose evaluation was SRSquality 0.5 Change Control 0.9 Client Concurrence 0.9

59. 59 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 Risk Management Model R F = P F + C F - P F * C F P F = sum of values assigned to each factor/ number of factors Example: SRS 0.5, ChCn 0.9, Cl Co 0.9 (0.5 + 0.9 + 0.9) / 3 =.76

60. 60 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 Risk Management Model R F = P F + C F - P F * C F C F = sum of values assigned to each consequence/ number of consequences Example: suppose evaluation was Cost 0.5 Schedule 0.9 Performance 0.8

61. 61 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 Risk Management Model R F = P F + C F - P F * C F C F = sum of values assigned to each consequence/number of consequences Example: Cost 0.5, Schedule 0.9, Performance 0.8 (0.5 + 0.9 + 0.8) / 3 =.70

62. 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 Risk Management Model R F = P F + C F - P F * C F R F = 0.76 + 0.70 - 0.76*0.70 R F = 1.46 - 0.532 R F = 0.928

63. 63 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 Risk Management Model P F 1.0 0.8 0.7 0.6 0.4 0.3 0.2 0.2 0.3 0.4 0.6 0.7 0.8 1.0 C F

64. 64 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 Risk Management Model R F = P F + C F - P F * C F Using the percentages: P F = 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

65. 65 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 Risk Management Model R F = P F + C F - P F * C F Using the percentages: C F = 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

66. 66 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 Risk Management Model R F = P F + C F - P F * C F R F = 0.70 + 0.62 - 0.70*0.62 R F = 1.32 - 0.434 R F = 0.886

67. 67 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 Risk Management Model P F 1.0 0.8 0.7 0.6 0.4 0.3 0.2 0.2 0.3 0.4 0.6 0.7 0.8 1.0 C F

68. 68 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 Risk Management Model Avoid Prevent Assume Transfer Research

69. 69 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 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

70. 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 Risk Management Model Cost Performance Measurements Technical Performance Measurements PV F = P F * Cost of problem PV F = 0.20 * 0.6 million (cost of slipage) PV F = 120,000

71. 71 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 Risk Management Model Risk Measurement Tools 1. Actual Expenses vs Planned Expenses 2. Actual Milestones vs Planned Milestones 3. TPM

72. 72 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 Risk Management Model Objectives Introduction Risk Areas Risk Management Model Risk Containment Examples

73. 73 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 Building a Risk Table RiskProbabilityImpactRMMM RiskMitigationMonitoring&Management

74. 74 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 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

75. 75 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  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? Risk Mitigation, Monitoring, and Management

76. 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 Risk Due to Product Size estimated size of the product in LOC or FP? estimated size of the product in LOC or FP? estimated size of product in number of programs, estimated size of product in number of programs, files, transactions? percentage deviation in size of product from percentage deviation in size of product from average for previous products? size of database created or used by the product? size of database created or used by the product? number of users of the product? number of users of the product? number of projected changes to the requirements number of projected changes to the requirements for the product? before delivery? after delivery? amount of reused software? amount of reused software? Attributes that affect risk:

77. 77 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 Risk Due to Business Impact affect of this product on company revenue? affect of this product on company revenue? visibility of this product by senior management? visibility of this product by senior management? reasonableness of delivery deadline? reasonableness of delivery deadline? number of customers who will use this product number of customers who will use this product interoperability constraints interoperability constraints sophistication of end users? sophistication of end users? amount and quality of product documentation that amount and quality of product documentation that must be produced and delivered to the customer? governmental constraints governmental constraints costs associated with late delivery? costs associated with late delivery? costs associated with a defective product? costs associated with a defective product? Attributes that affect risk:

78. 78 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 Risks Due to the Customer Have you worked with the customer in the past? Have you worked with the customer in the past? Does the customer have a solid idea of requirements? Does the customer have a solid idea of requirements? Has the customer agreed to spend time with you? Has the customer agreed to spend time with you? Is the customer willing to participate in reviews? Is the customer willing to participate in reviews? Is the customer technically sophisticated? Is the customer technically sophisticated? Is the customer willing to let your people do their 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 Does the customer understand the software engineering process? Questions that must be answered:

79. 79 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 Risks Due to Process Maturity Have you established a common process framework? Have you established a common process framework? Is it followed by project teams? Is it followed by project teams? Do you have management support for Do you have management support for software engineering Do you have a proactive approach to SQA? Do you have a proactive approach to SQA? Do you conduct formal technical reviews? Do you conduct formal technical reviews? Are CASE tools used for analysis, design and Are CASE tools used for analysis, design and testing? Are the tools integrated with one another? Are the tools integrated with one another? Have document formats been established? Have document formats been established? Questions that must be answered:

80. 80 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 Technology Risks Is the technology new to your organization? Is the technology new to your organization? Are new algorithms, I/O technology required? Are new algorithms, I/O technology required? Is new or unproven hardware involved? Is new or unproven hardware involved? Does the application interface with new software? Does the application interface with new software? Is a specialized user interface required? Is a specialized user interface required? Is the application radically different? Is the application radically different? Are you using new software engineering methods? Are you using new software engineering methods? Are you using unconventional software development Are you using unconventional software development methods, such as formal methods, AI-based approaches, artificial neural networks? Are there significant performance constraints? Are there significant performance constraints? Is there doubt the functionality requested is "do-able?" Is there doubt the functionality requested is "do-able?" Questions that must be answered:

81. 81 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 Staff/People Risks Are the best people available? Are the best people available? Does staff have the right skills? Does staff have the right skills? Are enough people available? Are enough people available? Are staff committed for entire duration? Are staff committed for entire duration? Will some people work part time? Will some people work part time? Do staff have the right expectations? Do staff have the right expectations? Have staff received necessary training? Have staff received necessary training? Will turnover among staff be low? Will turnover among staff be low? Questions that must be answered:

82. 82 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 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 Scheduled milestone reviews with hardware group Contingency plan: Modification of testing strategy to accommodate delay using Modification of testing strategy to accommodate delay using software simulation software simulation Estimated resources: 6 additional person months beginning 7-1-96 Recording Risk Information