1 / 41

Software Engineering

Software Engineering. Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL. Agenda. Project Midterm dates Risks Risk management. Risk. A very popular notion, but little studied Low risk projects are easy Only the courageous are willing to take on high-risk project

Download Presentation

Software Engineering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL T. E. Potok - University of Tennessee

  2. Agenda • Project • Midterm dates • Risks • Risk management T. E. Potok - University of Tennessee

  3. Risk • A very popular notion, but little studied • Low risk projects are easy • Only the courageous are willing to take on high-risk project • You aren’t really doing your job if you don’t take on some risk T. E. Potok - University of Tennessee

  4. What is risk • Risks within a nuclear power plant • Meltdown • Radiation leak • Loss of power • Safety violation T. E. Potok - University of Tennessee

  5. Two components of risk • Potential loss or impact • What is the impact of a potential risk • If it happens, what is the result • Catastrophic - substantial loss of life, money, or property • Major - Significant injury, loss of money, or property • Minor - Mild injury, loss of money, or property • Trivial - Minimal injury, loss of money, or property T. E. Potok - University of Tennessee

  6. Two components of risk • Probability of occurrence • What is the probability that the risk will occur • How likely is it that the risk will occur • Quite likely - will occur • Likely - Probably will occur • Unlikely - Probably will not occur • Rare - Very unlikely T. E. Potok - University of Tennessee

  7. Impact Vs Probability High Probability and High Impact T. E. Potok - University of Tennessee

  8. Impact Vs. Probability • Nuclear meltdown is so rare (well almost) that even a catastrophic impact is acceptable • Likewise, a very probable even, such as a safety violation will have such a minor impact that it too is acceptable • Problems arises when a major problem is likely to occur T. E. Potok - University of Tennessee

  9. What to do with risks? • Reduce or avoid the impact of the risk • Put nuclear plants in low populated areas • Build plants with strong containment walls • Reduce or avoid the probability of the risk occurring • Install failsafe systems to prevent a meltdown • Train personnel on how to react in emergency situations T. E. Potok - University of Tennessee

  10. Software Risks Management • Objective: Identify, address, and eliminate software risks before they become a threat to the successful software operation • Actions • Risk Assessment • Risk identification • Risk Analysis • Risk Prioritization • Risk Control • Risk management planning • Risk resolution • Risk monitoring T. E. Potok - University of Tennessee

  11. Risk Identification • Checklists • Resource • Right people • Right equipment • Enough money • Schedules • Driven by economy • Driven by politics • Technology • Available • Maturity level • Requirements • Stability • Complexity T. E. Potok - University of Tennessee

  12. Resources • Wrong skills or experience • If you need Java code written, and no one knows Java, you are in trouble • Wrong leader • Leader is a great programmers, but does not know how to manage a project • Team conflicts • Two or more members compete more than collaborate • Team dynamics • A low output team should not be counted on for a high risk, complex project T. E. Potok - University of Tennessee

  13. Schedules • Schedules can be set by a variety of factors • Y2K fixes needs to be finished by Dec 31, 1999 • Political considerations - A politician want the software to work before an election • Economic considerations - Software sales can help the stockholder’s report • Technical - Software engineering estimates • Competition - Competitor drive the schedules • Because a schedule is set does not mean that it can be accomplished T. E. Potok - University of Tennessee

  14. Technology • Some technologies are mature and reasonable to implement • Databases • Basic applications • Searching and sorting • Some are not • NP complete problems • Semantic understanding • Reasoning/thinking T. E. Potok - University of Tennessee

  15. Requirements • Not known or clearly stated at the beginning of the project • The requirements shift or change during the project • Gold-plating - I am good at database, and every solution I offer has a database in it • Unspecified interfaces T. E. Potok - University of Tennessee

  16. Risk Analysis • Once risks have been identified, what do you do with them? • Analyze what risks you need to worry about • Plan based on analysis • But first, some background... T. E. Potok - University of Tennessee

  17. General Probability TheoryFrom M. A. Vouk • Basics • The probability of an event A occurring is between 0 and 1: • The probability of the entire sample space is 1 P(S) = 1 The probability of the union of two mutually exclusive events is the sum of their probabilities T. E. Potok - University of Tennessee

  18. Venn Diagrams A A Set A and its complement A B Mutually Exclusive Events T. E. Potok - University of Tennessee

  19. More diagrams S A B Intersection of events A and B T. E. Potok - University of Tennessee

  20. Probability of Two Events A and B are not mutually exclusive A and B are mutually exclusive T. E. Potok - University of Tennessee

  21. Example • The probability of working in the computer field is 60% • The probability of graduating with CS degree is 70% • The probability of either is 80%, the probability of BOTH is: • A = “finding a job in the computer field” • B = “student graduates in CS” = .6 + .7 - .8 = .5, or 50% T. E. Potok - University of Tennessee

  22. Example S = 20% AUB = 80% A = 60% B = 70% Intersection of events A and B = 50% T. E. Potok - University of Tennessee

  23. Conditional Events • The event A occurs under the condition that B has occurred • Example: You get a CS degree, Event B, what is your chance of finding a job in the field, Event A? • = .5/.7 = .71, or 71%, up from 60% T. E. Potok - University of Tennessee

  24. Independence • Two events are said to be independent iff the joint probability is 0. • Bayes’ Rule T. E. Potok - University of Tennessee

  25. Example • A - We need to increase disk space with ISP • B - We need the ISP to support video • Probability of A is 80%, B is 60%, and A and B are independent events • .8 x.6 = .48, or a 48% chance of both A and B occurring T. E. Potok - University of Tennessee

  26. Further Example • Four independent events must take place for the project to be successful • Software from vendor A, 90% • Hardware from vendor B, 80% • Design from vendor C, 90% • Successful code from vendor D, 70% • Looks like the project is in good shape • What is the probability of success? • .9*.8*.9*.7 = .45, less than 50% T. E. Potok - University of Tennessee

  27. Back to Risk • Expected loss from a risk can be defined as: • Probability of loss X loss if the event occurs • If you repeated this event many times, on average you would expect to loss this much • Provides a way of comparing risks • Provides a way of financially quantifying risk T. E. Potok - University of Tennessee

  28. Example • Project 1 • Estimated project cost: $500,000 • Estimated profit: $100,000 • Risk: Interfaces not understood • Loss $500,000 + money invested in the project • Assume $750,000 • Probability of risk: 30% • Expected loss of $225,000!! • Clearly this project is not worth the risk T. E. Potok - University of Tennessee

  29. However,... • If we can determine the interfaces • Work at AMI to test in interfaces (feasibility study) • Risk: Project not doable • Loss $500,000 + money invested in the project • Assume $550,000, ($50,000 for feasibility) • Probability of risk: 10%, we are confident it will work • Expected loss of $55,000 • Expected profit of $45,000. May be worth doing. T. E. Potok - University of Tennessee

  30. Decision Trees } $100,000 Easy .1 $-150,000 Hard .1 $0 Build Undoable .8 $-200,000 Check Writing Problem } Easy .5 $100,000 Experiment $72,500 $45,000 Hard .5 Reject } $-5000 $-5,000 T. E. Potok - University of Tennessee

  31. Risk Prioritization • Risks with the highest expected losses are usually the highest priority • Intangibles • Loss of prestige • Loss of a key customer • Loss of reputation T. E. Potok - University of Tennessee

  32. Risk list • Keep track of the top 10 risks on a project • Prioritize the list • based on expected loss • expert assessment • Develop action plans for each risk • Review the list on a regular basis T. E. Potok - University of Tennessee

  33. Risk Management Planning • For the highest priority risks • Identify ways of reducing probability of occurrence • Buy information • Inspect or monitor • Test T. E. Potok - University of Tennessee

  34. Buying Information • Spend money to understand the problem better • Research - what has been done in the past, what are others doing • Prototypes - develop a system to test risk probabilities • Buy COTS to solve the problem T. E. Potok - University of Tennessee

  35. Example • Reducing the risk of the interface problem • Spend some time researching foundation and quicken • Prototype solutions against each • Review the results with the customer • Look for commercial software packages that already does this • The more you spend, the more you understand the risks, and the less profit you make T. E. Potok - University of Tennessee

  36. Monitoring and Inspecting • To prevent unauthorized check writing • Establish a manual process of reviewing the audit logs • Incorporate two distinct methods for generating and analyzing the logs • Flag questionable transactions • Shut down the system until validation has been received T. E. Potok - University of Tennessee

  37. Testing • Establish a series of test scripts based on fraudulent transactions • Review the scripts with financial experts to ensure accuracy • Test the software so that it works fully with the script • Test manual procedures as well T. E. Potok - University of Tennessee

  38. Reducing the Potential Loss • Contingency plans • Plan what to do, if a problem does arise • Simple, but rarely done • Rework to reduce obvious risk • Keep things simple! T. E. Potok - University of Tennessee

  39. Example • Develop an audit trail • If not doable • Have the function be performed by the AMI accountant • Use the database or quicken logging function • Print a copy of each check written T. E. Potok - University of Tennessee

  40. Rework • Rework is typically viewed as a waste of time and resources • However, in high risk situations, rework may be necessary to reduce or eliminate risks • The iterative process involves a good deal of rework, but the project risks are usually found early. T. E. Potok - University of Tennessee

  41. Summary • Risks Analysis • Probability • Risk management • Risk reduction T. E. Potok - University of Tennessee

More Related