T. E. Potok - University of Tennessee CS 594 Software Engineering Lecture 4 Dr. Thomas E. Potok [email protected] 865-574-0834

T. E. Potok - University of Tennessee

CS 594Software Engineering

Lecture 4

Dr. Thomas E. [email protected]

865-574-0834

Software Engineering CS 594


2

Agenda

Review More on PERT Software Lifecycle Models



3

Further PERT Analysis

Triangular distribution works, but there may be a more accurate method

Beta distributions have traditionally been used to represent variability in a PERT network



4

Beta Vs. TriangularBeta Vs Triangular Distribution

0.000

0.010

0.020

0.030

0.040

0.050

0.060

0 10 20 30 40 50 60 70

Duration

Pro

bab

ility

Triangular

Beta



5

Beta Distribution

Four parameters– Min value– Max value– 2 shape parameters

Shape parameters adjusted to general shape needed.

Distribution very flexible, not specific to software

Works well with simulation



6

Cumulative ComparisonCumulative Beta Vs. Triangular Dist

0.000

0.100

0.200

0.300

0.400

0.500

0.600

0.700

0.800

0.900

1.000

15 25 35 45 55

Duration

Pro

bab

ilit

y

Triangular

Beta



7

Beta or Triangular?

At 35 weeks– 32% with Triangular – 65% with Beta

80% Completion– 39 Weeks– 47 Weeks

Accuracy Matters!!



8

Problems with PERT

Critical path not always clear When variability taken into account the

critical path may not be the shortest path

The Non-CP tasks may take longer than the CP tasks

Critical Path Min Ave MaxTask A 2 3 4Task B 2 3 4Task C 2 3 4Total 6 9 12

Non-CP Min Ave MaxTask A 1 2 10Task B 1 2 10Task C 1 2 10Total 3 6 30



9

More problems

Adding minimum, average, and maximum values assumes that the tasks are independent.– Task A and Task B are not related to each

other in any way.– Yet if Task A is delayed, then Task B may be

compressed to make up the time.– If Task A finished early, then Task B may be

delayed If tasks are dependent, then PERT may

provide a poor estimate



10

Diagramming Problems

Diagram can be ambiguous several proposals to fix– Enhanced PERT diagrams– Activity Networks– Petri Nets



11

PERT Summary

Even with the problems, PERT is very widely used

Problems can hinder accuracy, however, can provide a reasonable estimate

Estimates can be generated quickly and easily.



12

Where are we?

We have covered how to generate requirements

How to determine project size, and duration– COCOMO - General– PERT - Detailed

Now we look at how to organize the software project


Negotiation



14

Negotiating

Summary of Roger Dawson’s “The Secret of Power Negotiating”– 1) Always negotiating– 2) Anything you ever want is owned by someone

else – 3) Predictable responses to negotiation gambits

• Yes on the first offer– 4) Three critical factors in all negotiations

• Power• Information• Time

– 5) People are different



15

Win-WinWin – Lose Win-Win

Lose-Lose Lose-WinYour Goal

Opponent’sGoal



16

How to provide a win-win

You don’t always have to have a winner and a loser– Look at all the issues, don’t narrow it

down to one issue– People don’t want the same thing– Help them to get what THEY want



17

Stages of negotiations

Stage 1: What does your opponent want? “What exactly are you looking for?”

Stage 2: Find our all that you can about your opponent

Stage 3: Reach for compromise acceptable to both



18

Tactics

Nibbling– You can get more after everything has been

agreed to– You reinforce decisions that you make– Don’t ask for everything up front, leave

some things to nibble Counter

– Make them feel cheap– “You got a great deal, lets not quibble over

trivial things”



19

More tactics

Hot potato – Give you their problem

Counter– Test for validity



20

More tactics

Higher authority– Always have a higher authority you have to get

approval from– “I have to run this by my management first”

Counter– Remove resort to higher authority– “Is there any reason why you can not make a

decision today?” Counter – Counter

– Ego “Surely they follow your recommendations”– “And you will recommend this proposal to them”



21

More Tactics

Impasse– “We may do business, but we will

NEVER…”– Let set that issue aside, and talk about

other issues– Resolve little issues to gain momentum

Deadlock– Bring in a 3rd party who is perceived as

neutral, arbitration



22

More Tactics

Good guy/Bad guy– First guy is a hard nose who is called away– Second guy is friendly and offers to help– Closes on minor points, then major points– “What do you think the bad guy would go

for” Counter

– “Come on, you aren’t going to play good guy/bad guy with me are you?”



23

More Tactics

Never jump at a first offer– Always go through the process so that your

opponents feels that he has won Feel, Felt, Found

– Always agree with responses to a proposal – “I understand how you feel…”– “Just about everyone I know has felt that

ways…”– “However, when we really look at it, we have

found that it is the best way to go”



24

More Tactics

Don’t act too sophisticated– Reduces competitive threat, they want

to help you Value of services rapidly diminishes

after they have been performed– Ask for similar concession immediately

Learn to walk away Flinch



25

Negotiations

There are many approaches and styles

Be aware of the tactics Practice when you have a chance


Software Life-Cycle Models



27

Life-Cycle

The stages of a software development project as it goes from inception to completion– Requirements– Design– Code– Test– Maintenance



28

Phase Matrix

Part 1 Part 2 Part 3 Part 4Requirments Requirments Requirments RequirmentsDesign Design Design DesignCode Code Code CodeTest Test Test TestMaintenance Maintenance Maintenance Maintenance



29

Waterfall

Part 1 Part 2 Part 3 Part 4Requirments Requirments Requirments RequirmentsDesign Design Design DesignCode Code Code CodeTest Test Test TestMaintenance Maintenance Maintenance Maintenance

1

2



30

Waterfall

Royce introduced the Waterfall Model in the late 1970’s.– You move down the waterfall, but not

up– You move from phase to phase when

documentation is complete– Standard life-cycle model most people

think of– Well suited for mature projects



31

Example For our warehouse project here is

what a waterfall life-cycle would look likePhase Start End

Requirements Definition January 20, 1999 February 4, 1999Requirements Approval February 4, 1999 February 4, 1999Design Definition February 4, 1999 March 2, 1999Design Review March 2, 1999 March 4, 1999Design Approval March 4, 1999 March 4, 1999Code Definition March 4, 1999 April 2, 1999Code Review April 2, 1999 April 8, 1999Code Approval April 8, 1999 April 8, 1999Unit Test April 8, 1999 April 20, 1999Unit Test Approval April 20, 1999 April 20, 1999Function Test April 21, 1999 April 30, 1999Functilon Test Approval April 30, 1999 April 30, 1999System Test May 1, 1999 May 15, 1999System Test Approval May 15, 1999 May 15, 1999System Acceptance May 15, 1999 May 15, 1999



32

Summary

Strengths– Very strong control the project– Nice paper trail– Similar process followed in engineering

Weaknesses– Not well suited to change– Develops the entire project– Hard to redirect



33

Iterative Approach

Part 1 Part 2 Part 3 Part 4Requirments Requirments Requirments RequirmentsDesign Design Design DesignCode Code Code CodeTest Test Test Test

1

2



34

Iterative

Fully build a part of the project Review the part with the

customers or users Fix any problems Begin on the next part Apply lessons learned to next part



35

Example

Phase Start EndMeet with customer January 20, 1999 January 20, 1999Define first iteration January 21, 1999 January 22, 1999Design January 22, 1999 January 25, 1999Code January 25, 1999 February 15, 1999Test February 15, 1999 February 20, 1999Demonstrate to customer February 20, 1999 February 20, 1999Plan iteration 2 February 21, 1999 February 22, 1999…



36

Summary

Strengths– Well suited to changing requirements– Customer can “see” project

developing– Find problems early

Weaknesses– Weakly controlled process– When do you stop?– Architecture must be stable



37

Spiral Model

Complex, risk driven model Three new phases added

– 1) Determining objectives; alternatives, and constraints;

– 2) Evaluating alternatives and identifying and resolving risks;

– 3) Planning the next phases. Recommit after every cycle



38

Spiral Model

Part 1 Part 2 Part 3 Part 4Objective Objective Objective Objective

Alternatives Alternatives Alternatives AlternativesRequirments Requirments Requirments RequirmentsDesign Design Design DesignCode Code Code CodeTest Test Test TestPlan Plan Plan Plan



39

Objectives Determining objectives; alternatives, and

constraints; Define phase

– Objectives– Alternatives– Constraints

Example– Objective: Print checks from existing databases– Constraints: Database specification– Alternatives:

• 1) Develop a solution using Quicken facilities• 2) Build separate screen that work with Quicken• 3) Replace Quicken component



40

Alternatives

Evaluate alternatives, identifying and resolving risks;

What is the best alternative, and how can the risks be dealt with– Can the risk be avoided?– Can the impact of the risk be

lessened?



41

Example - Alternative Evaluation What can go wrong with the AMI project? Alternatives Risks Plan



42

Do the work

Design Code Test Keeping the objectives,

alternatives, and risks in mind



43

Planning

Planning the next phases– You have better information– New problems and risks– A better idea of the feasibility of the

project Recommit after every cycle

– Should the project be continued?



44

Summary

PERT– Triangular distributions– Beta distributions– Problems

Software Lifecycle Models– Waterfall– Iterative– Spiral

Documents

T. E. Potok - University of Tennessee CS 594 Software Engineering Lecture 4 Dr. Thomas E. Potok [email protected] 865-574-0834