CS 594 Software Engineering Lecture 4

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

2. Agenda • Review • More on PERT • Software Lifecycle Models T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

4. Beta Vs. Triangular T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

6. Cumulative Comparison T. E. Potok - University of Tennessee

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

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 T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

10. Diagramming Problems • Diagram can be ambiguous several proposals to fix • Enhanced PERT diagrams • Activity Networks • Petri Nets T. E. Potok - University of Tennessee

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. T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

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

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 T. E. Potok - University of Tennessee

15. Win-Win Your Goal Opponent’s Goal T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

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” T. E. Potok - University of Tennessee

19. More tactics • Hot potato • Give you their problem • Counter • Test for validity T. E. Potok - University of Tennessee

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” T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

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?” T. E. Potok - University of Tennessee

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” T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

25. Negotiations • There are many approaches and styles • Be aware of the tactics • Practice when you have a chance T. E. Potok - University of Tennessee

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

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

28. Phase Matrix T. E. Potok - University of Tennessee

29. Waterfall 1 2 T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

31. Example • For our warehouse project here is what a waterfall life-cycle would look like T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

33. Iterative Approach 2 1 T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

35. Example T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

38. Spiral Model T. E. Potok - University of Tennessee

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 T. E. Potok - University of Tennessee

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? T. E. Potok - University of Tennessee

41. Example - Alternative Evaluation • What can go wrong with the AMI project? • Alternatives • Risks • Plan T. E. Potok - University of Tennessee

42. Do the work • Design • Code • Test • Keeping the objectives, alternatives, and risks in mind T. E. Potok - University of Tennessee

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? T. E. Potok - University of Tennessee

44. Summary • PERT • Triangular distributions • Beta distributions • Problems • Software Lifecycle Models • Waterfall • Iterative • Spiral T. E. Potok - University of Tennessee