Software Engineering Dr Thomas E Potok Adjunct Professor

Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL

Agenda Project Ø Midterm dates Ø Risk management Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 2

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 3

What is risk Ø Risks within a nuclear power plant – – Meltdown Radiation leak Loss of power Safety violation Software Engineering CS 594 T. E. Potok - University of Tennessee 4

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 5

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 6

Impact Vs Probability High Probability and High Impact Software Engineering CS 594 T. E. Potok - University of Tennessee 7

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 Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 8

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 9

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 10

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

Resources Ø Wrong skills or experience – Ø Wrong leader – Ø Leader is a great programmers, but does not know how to manage a project Team conflicts – Ø If you need Java code written, and no one knows Java, you are in trouble 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 Software Engineering CS 594 T. E. Potok - University of Tennessee 12

Schedules Ø Schedules can be set by a variety of factors – – – Ø Y 2 K 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 Software Engineering CS 594 T. E. Potok - University of Tennessee 13

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 14

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 Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 15

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. . . Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 16

General Probability Theory From 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 Software Engineering CS 594 T. E. Potok - University of Tennessee 17

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

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

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

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% Software Engineering CS 594 T. E. Potok - University of Tennessee 21

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

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% Software Engineering CS 594 T. E. Potok - University of Tennessee 23

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

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 25

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% Software Engineering CS 594 T. E. Potok - University of Tennessee 26

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 27

Example Ø Project 1 – – Ø Risk: Interfaces not understood – – Ø Estimated project cost: $500, 000 Estimated profit: $100, 000 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 Software Engineering CS 594 T. E. Potok - University of Tennessee 28

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. Software Engineering CS 594 T. E. Potok - University of Tennessee 29

Decision Trees. 1 asy E $100, 000 Build Check Writing Problem Experiment Und oa ble. 8 Easy Har . 5 d. 5 } $-150, 000 $45, 000 } $72, 500 $-5, 000 Hard. 1 } $0 $-200, 000 $100, 000 Reject Software Engineering CS 594 T. E. Potok - University of Tennessee $-5000 30

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 31

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 Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 32

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

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 34

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 35

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 Software Engineering CS 594 T. E. Potok - University of Tennessee 36

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 Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 37

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! Software Engineering CS 594 T. E. Potok - University of Tennessee 38

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 Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 39

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. Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 40

Summary Risks Analysis Ø Probability Ø Risk management Ø Risk reduction Ø Software Engineering CS 594 T. E. Potok - University of Tennessee 41