Software Engineering

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

T. E. Potok - University of Tennessee

Agenda
Project Midterm dates Risks Risk management

Software Engineering CS 594

T. E. Potok - University of Tennessee

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 arent really doing your job if you dont take on some risk

Software Engineering CS 594

T. E. Potok - University of Tennessee

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

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

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

Impact Vs Probability
Risk - Impact Vs. Probability
100 90 80 70
Impact

High Probability and High Impact

60 50 40 30 20 10 0 0 10 20 30 40 50 Probability 60 70 80 90 100

Software Engineering CS 594

T. E. Potok - University of Tennessee

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

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

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 management planning Risk resolution Risk monitoring

Risk Control

Software Engineering CS 594

T. E. Potok - University of Tennessee

10

Risk Identification

Checklists

Resource

Right people Right equipment Enough money Driven by economy Driven by politics Available Maturity level Stability Complexity
T. E. Potok - University of Tennessee 11

Schedules

Technology

Requirements

Software Engineering CS 594

Resources

Wrong skills or experience

If you need Java code written, and no one knows Java, you are in trouble
Leader is a great programmers, but does not know how to manage a project Two or more members compete more than collaborate A low output team should not be counted on for a high risk, complex project

Wrong leader

Team conflicts

Team dynamics

Software Engineering CS 594

T. E. Potok - University of Tennessee

12

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 stockholders 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 NP complete problems Semantic understanding Reasoning/thinking

Some are not

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:

0 P(A) 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
P(A 1 A 2 ) P(A 1 ) P(A 2 )

Software Engineering CS 594

T. E. Potok - University of Tennessee

17

Venn Diagrams
A A Set A and its complement

A Mutually Exclusive Events

Software Engineering CS 594

T. E. Potok - University of Tennessee

18

More diagrams

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

P[A B] P[A] P[B] P[A B]

A and B are mutually exclusive

P[A B] P[A] P[B]

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

P[A B] P[A] P[B] P[A B] = .6 + .7 - .8 = .5, or 50%

Software Engineering CS 594 T. E. Potok - University of Tennessee 21

Example
S = 20% AUB = 80% A = 60%
A B

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

P[ A B] P[A B] for P[B] 0 P[B]

Example: You get a CS degree, Event B, what is your chance of finding a job in the field, Event A?
P[A B] = .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.

P[A B] P[A] P[B]

Bayes Rule
P[A] P[ A B k ] P[B k ]
k 1 n

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
P[A B] P[A] P[B]

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

E[A] P[A] L[A]

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

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!!

Risk: Interfaces not understood

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.

T. E. Potok - University of Tennessee 29

Software Engineering CS 594

Decision Trees
$100,000 $0 Build $-200,000 $100,000 $45,000 Reject $-5,000
Software Engineering CS 594 T. E. Potok - University of Tennessee

} }
}

$-150,000

Check Writing Problem

Experiment

$72,500

$-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 Keep things simple!

Rework to reduce obvious risk

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