1. T. E. Potok - University of Tennessee CS 594 Software Engineering Lecture 4 Dr. Thomas E. Potok potokte@ornl.gov 865-574-0834

2. 2 Software Engineering CS 594T. E. Potok - University of Tennessee Agenda  Review  More on PERT  Software Lifecycle Models

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

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

7. 7 Software Engineering CS 594T. E. Potok - University of Tennessee Beta or Triangular?  At 35 weeks – 32% with Triangular – 65% with Beta  80% Completion – 39 Weeks – 47 Weeks  Accuracy Matters!!

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

9. 9 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 10 Software Engineering CS 594T. E. Potok - University of Tennessee Diagramming Problems  Diagram can be ambiguous several proposals to fix – Enhanced PERT diagrams – Activity Networks – Petri Nets

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

13. T. E. Potok - University of Tennessee Negotiation

14. 14 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 15 Software Engineering CS 594T. E. Potok - University of Tennessee Win-Win Win – LoseWin-Win Lose-LoseLose-Win Your Goal Opponent’s Goal

16. 16 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 17 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 18 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 19 Software Engineering CS 594T. E. Potok - University of Tennessee More tactics  Hot potato – Give you their problem  Counter – Test for validity

20. 20 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 21 Software Engineering CS 594T. E. Potok - University of Tennessee 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 3 rd party who is perceived as neutral, arbitration

22. 22 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 23 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 24 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 25 Software Engineering CS 594T. E. Potok - University of Tennessee Negotiations  There are many approaches and styles  Be aware of the tactics  Practice when you have a chance

26. T. E. Potok - University of Tennessee Software Life-Cycle Models

27. 27 Software Engineering CS 594T. E. Potok - University of Tennessee Life-Cycle  The stages of a software development project as it goes from inception to completion – Requirements – Design – Code – Test – Maintenance

28. 28 Software Engineering CS 594T. E. Potok - University of Tennessee Phase Matrix

29. 29 Software Engineering CS 594T. E. Potok - University of Tennessee Waterfall 1 2

30. 30 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 31 Software Engineering CS 594T. E. Potok - University of Tennessee Example  For our warehouse project here is what a waterfall life-cycle would look like

32. 32 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 33 Software Engineering CS 594T. E. Potok - University of Tennessee Iterative Approach 1 2

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

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

39. 39 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 40 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 41 Software Engineering CS 594T. E. Potok - University of Tennessee Example - Alternative Evaluation  What can go wrong with the AMI project?  Alternatives  Risks  Plan

42. 42 Software Engineering CS 594T. E. Potok - University of Tennessee Do the work  Design  Code  Test  Keeping the objectives, alternatives, and risks in mind

43. 43 Software Engineering CS 594T. E. Potok - University of Tennessee 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. 44 Software Engineering CS 594T. E. Potok - University of Tennessee Summary  PERT – Triangular distributions – Beta distributions – Problems  Software Lifecycle Models – Waterfall – Iterative – Spiral