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

Slides:



Advertisements
Similar presentations
Chapter 7 Project Management
Advertisements

Extreme Programming Alexander Kanavin Lappeenranta University of Technology.
Seal the Deal by Negotiating a Win Offer and respond with confidence. Heighten the speed and skill with which you build win-win agreements.
Software Process Models
CEN nd Lecture CEN 4021 Software Engineering II Instructor: Masoud Sadjadi Software Process Models.
Software Process Models
SE503 Advanced Project Management Dr. Ahmed Sameh, Ph.D. Professor, CS & IS Project Uncertainty Management.
Basic Project Planning and Estimation 2/5/2007 Keith Rome
T. E. Potok - University of Tennessee Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL.
Alternative Software Life Cycle Models By Edward R. Corner vol. 2, chapter 8, pp Presented by: Gleyner Garden EEL6883 Software Engineering II.
Applied Software Project Management INTRODUCTION Applied Software Project Management 1 5/20/2015.
Software Engineering. How many lines of code? Average CS1004 assignment: 200 lines Average CS4115 project: 5000 lines Corporate e-commerce project: 80,000.
Software Engineering.
Object-oriented Analysis and Design
Chapter 1 Software Development. Copyright © 2005 Pearson Addison-Wesley. All rights reserved. 1-2 Chapter Objectives Discuss the goals of software development.
Fundamentals of Information Systems, Second Edition
Applied Software Project Management 1 Introduction Dr. Mengxia Zhu Computer Science Department Southern Illinois University Carbondale.
CS3500 Software Engineering Agile Software Development (1) Agile software development, proposed in 2001 by the non-profit Agile Alliance, has four basic.
Software Development Life Cycle (SDLC)
S/W Project Management Software Process Models. Objectives To understand  Software process and process models, including the main characteristics of.
IT Systems Analysis & Design
Copyright (c) 2003 CPTTM 1 Common fears of a software development manager Common fears of a software development manager: –Deadline.
#17 - Involve Users in the Development Model of Multinational Corporations - Is it worth it? Experience Report IRCSE '08: IDT Workshop Friday 31 October.
Techniques for Negotiating Win- Win Agreements KW050.
CS 360 Lecture 3.  The software process is a structured set of activities required to develop a software system.  Fundamental Assumption:  Good software.
Developing Software MGMT Summer 2012 Night #8.
Project Tracking. Questions... Why should we track a project that is underway? What aspects of a project need tracking?
T. E. Potok - University of Tennessee Software Engineering Dr. Thomas E. Potok Adjunct Professor UT Research Staff Member ORNL.
COMP 208/214/215/216 Lecture 3 Planning. Planning is the key to a successful project It is doubly important when multiple people are involved Plans are.
Quick Recap.
University of Virginia Software Development Processes (CS340 John Knight 2005) 1 Software Development Processes.
Yazd University, Electrical and Computer Engineering Department Course Title: Advanced Software Engineering By: Mohammad Ali Zare Chahooki The Project.
Listening and Negotiations. What is the first sales skill you should learn?
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
T. E. Potok - University of Tennessee CS 594 Software Engineering Lecture 3 Dr. Thomas E. Potok
13-January-2003cse LifeCycle © 2003 University of Washington1 Lifecycle CSE 403, Winter 2003 Software Engineering
1 Software Development Software Engineering is the study of the techniques and theory that support the development of high-quality software The focus is.
© Bennett, McRobb and Farmer Avoiding the Problems Based on Chapter 3 of Bennett, McRobb and Farmer: Object Oriented Systems Analysis and Design.
Systems Analysis and Design in a Changing World, Fourth Edition
Fundamentals of Information Systems, Second Edition 1 Systems Development.
Cmpe 589 Spring 2006 Lecture 2. Software Engineering Definition –A strategy for producing high quality software.
CS 5150 Software Engineering Lecture 7 Requirements 1.
1-1 Software Development Objectives: Discuss the goals of software development Identify various aspects of software quality Examine two development life.
Requirements CS121 Spring Administrivia new student: Guillermo artist: Jackie Wijaya.
Software Life-Cycle and Models
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
Lecture 2 System Development Lifecycles. Building a house Definition phase Analysis phase Design phase Programming phase System Test phase Acceptance.
Negotiating More Profit In Your Business. n Never Jump at the first offer.
Trade Management  Module 8.  Main Topics:  Negotiation Process.
CS223: Software Engineering Lecture 4: Software Development Models.
Problem Solving, Decision Making, Negotiation and Compromise
CS223: Software Engineering Lecture 5: Software Development Models.
(M) Chapter 12 MANGT 662 (A): Procurement, Logistics and Supply Chain Design Purchasing and Supply Chain Analysis (1/2)
Negotiation Concepts Applied to Real Estate Transactions
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Software Lifecycle Models A software lifecycle model is a standardised format for planning organising, and running a new development project.
Presented by Thomas J. Dixon | INTRODUCTION TO NEGOTIATION CONCEPTS.
44222: Information Systems Development
By : Hisham Kahlifa Shreef Foda Khaled monir Tamer medhat Supervisor : Dr Doaa Nabil.
Software Lifecycle Models Place of Testing in Software Lifecycle 1.
Week # 4 Quality Assurance Software Quality Engineering 1.
 Son Nguyen, YM & Skype: ng_thanhson.
TK2023 Object-Oriented Software Engineering
Lecture 3 Prescriptive Process Models
CS 5150 Software Engineering
V-Shaped SDLC Model Lecture-6.
SDLC Model A framework that describes the activities performed at each stage of a software development project.
Software life cycle models
Gathering Systems Requirements
Gathering Systems Requirements
Presentation transcript:

T. E. Potok - University of Tennessee CS 594 Software Engineering Lecture 4 Dr. Thomas E. Potok

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

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

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

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

T. E. Potok - University of Tennessee Negotiation

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

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

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

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

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

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

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

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

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

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

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