Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Project management


Published on

Published in: Education
  • Be the first to comment

Project management

  1. 1. v 8 September 1994 TUM Lecture Notes on Project Management Bernd Bruegge Technische Universität München Lehrstuhl für Angewandte Softwaretechnik 14 July 1998Bernd Bruegge Component-Based Software Engineering 12
  2. 2. Odds and Ends Iv Book on CBSE Homepage w See Post by Allen Duoit on July 13 u Chapter 1, Introduction u Chapter 3, Software Lifecycle u Chapter 5, Project Communication u Chapter 6, Requirements Elicitation u Chapter 7, Requirements Analysis u Chapter 9, Design Rationale w Chapters available on August 15: u Chapter 8 System Design u Chapter 4 Project ManagementBernd Bruegge Component-Based Software Engineering 2
  3. 3. Odds and Ends IIv Lecture Today: w Finish System Design w Project Management (No reading available yet)v Lecture on Wednesday: w Communication & Meeting Management u Reading: Bruegge-Dutoit Ch 5v Lecture next Tuesday: w Software Lifecycle u Reading: Bruegge-Dutoit Ch 3Bernd Bruegge Component-Based Software Engineering 3
  4. 4. Outline of Lecturev Concepts and terminologyv Purpose of Software Project Management Plansv Structure of a Project Management Planv Project responsibilitiesv Team structuresv Project planningv Work breakdown structurev Communication Managementv Dependenciesv Schedulev Project Management ToolsBernd Bruegge Component-Based Software Engineering 4
  5. 5. Laws of Project Managementv Projects progress quickly until they are 90% complete. Then they remain at 90% complete forever.v When things are going well, something will go wrong. When things just can’t get worse, they will. When things appear to be going better, you have overlooked something.v If project content is allowed to change freely, the rate of change will exceed the rate of progress.v Project teams detest progress reporting because it manifests their lack of progress.Bernd Bruegge Component-Based Software Engineering 5
  6. 6. How it should go Requirements Analysis Design Implementation System Testing Delivery and InstallationBernd Bruegge Component-Based Software Engineering 6
  7. 7. How it often goes Requirements Analysis D E L A Y VaporwareBernd Bruegge Component-Based Software Engineering 7
  8. 8. Software Project Management Planv Software Project: w All technical and managerial activities required to deliver the deliverables to the client. w A software project has a specific duration, consumes resources and produces work products. w Management categories to complete a software project: u Tasks, Activities, Functionsv Software Project Management Plan: w The controlling document for a software project. w Specifies the technical and managerial approaches to develop the software product. w Companion document to requirements analysis document: Changes in either may imply changes in the other document. w SPMP may be part of project agreement.Bernd Bruegge Component-Based Software Engineering 8
  9. 9. Project Agreementv Document written for a client that defines: w the scope, duration, cost and deliverables for the project. w the exact items, quantities, delivery dates, delivery location.v Client: Individual or organization that specifies the requirements and accepts the project deliverables.v Can be a contract, a statement of work, a business plan, or a project charter.v Deliverables (= Work Products that will be delivered to the client: w Documents w Demonstrations of function w Demonstration of nonfunctional requirements w Demonstrations of subsystemsBernd Bruegge Component-Based Software Engineering 9
  10. 10. Project Agreement vs Problem Statement Client Manager Project Team (Sponsor) Problem Statement Software Project Management Plan Project AgreementBernd Bruegge Component-Based Software Engineering 10
  11. 11. Project: Functions, Activities and Tasks Function Project Function Activity Activity Activity Activity Activity Activity Task Task Task TaskBernd Bruegge Component-Based Software Engineering 11
  12. 12. Functionsv Activity or set of activities that span the duration of the project Function Project Function Activity Activity Activity Activity Activity Activity Task Task Task TaskBernd Bruegge Component-Based Software Engineering 12
  13. 13. Functionsv Examples: w Project management w Configuration Management w Documentation w Quality Control (Verification and validation) w Trainingv Question: Is system integration a project function?v Mapping of terms: Project Functions in the IEEE 1058 standard are called Integral processes in the IEEE 1074 standard. We call them cross-development processesBernd Bruegge Component-Based Software Engineering 13
  14. 14. Tasks Function Project Function • Smallest unit Activity Activity Activity of work subject to management Activity Activity Activity • Small enough for adequate planning Task Task Task Task and tracking • Large enough to avoid micro managementBernd Bruegge Component-Based Software Engineering 14
  15. 15. Tasksv Smallest unit of management accountability w Atomic unit of planning and tracking w Finite duration, need resources, produce tangible result (documents, code)v Specification of a task: Work package w Name, description of work to be done w Preconditions for starting, duration, required resources w Work product to be produced, acceptance criteria for it w Risk involvedv Completion criteria w Includes the acceptance criteria for the work products (deliverables) produced by the task.Bernd Bruegge Component-Based Software Engineering 15
  16. 16. Task Sizesv Finding the appropriate v Tasks must be task size is problematic decomposed into sizes w Todo lists from previous that allow monitoring projects w Work package usually w During initial planning a corresponds to well task is necessarily large defined work assignment w You may not know how to for one worker for a week decompose the problem or a month. into tasks at first w Depends on nature of w Each software work and how well task is development activitity understood. identifies more tasks and modifies existing onesBernd Bruegge Component-Based Software Engineering 16
  17. 17. Examples of Tasksv Unit test class “Foo”v Test subsystem “Bla”v Write user manualv Write meeting minutes and post themv Write a memo on NT vs Unixv Schedule the code reviewv Develop the project planv Related tasks are grouped into hierarchical sets of functions and activities.v Action itemBernd Bruegge Component-Based Software Engineering 17
  18. 18. Action Itemv Definition: A task assigned to a person that has to be done within a week or lessv Action items w Appear on the agenda in the Status Section (See lecture on communication) w Cover: What?, Who?, When?v Example of action items: w Florian unit tests class “Foo” by next week w Marcus develops a project plan before the next meeting w Bob posts the next agenda for the Simulation team meeting before Sep 10, 12noon. w The VIP team develops the project plan by Sep 18Bernd Bruegge Component-Based Software Engineering 18
  19. 19. Activities Function Project Function Activity Activity Activity • Major unit of work with precise dates Activity Activity Activity • Consists of smaller activities or tasks Task Task Task Task • Culminates in project milestone.Bernd Bruegge Component-Based Software Engineering 19
  20. 20. Activitiesv Major unit of work v Activitites may bev Culminates in major grouped into larger project milestone: activities: w Internal checkpoint should w Establishes hierarchical not be externally visible structure for project (phase, step, ...) w Scheduled event used to measure progress w Allows separation of concernsv Milestone often produces w Precedence relations often baseline: exist among activities w formally reviewed work (PERT Chart) product w under change control (change requires formal procedures)Bernd Bruegge Component-Based Software Engineering 20
  21. 21. Examples of Activitiesv Major Activities: v Activities during w Planning requirements analysis: w Requirements w Refine scenarios Analysis w Define Use Case w System Design model w Object Design w Define object model w Implementation w Define dynamic model w System Testing w Design User Interface w DeliveryBernd Bruegge Component-Based Software Engineering 21
  22. 22. Structure of a Software Project Management Planv 0. Front Matterv 1. Introductionv 2. Project Organizationv 3. Managerial Processv 4. Technical Processv 5. Work Elements, Schedule, Budgetv Optional InclusionsBernd Bruegge Component-Based Software Engineering 22
  23. 23. SPMP Part 0: Front Matterv TitlePagev Revision sheet (update history)v Preface: Scope and purposev Tables of contents, figures, tablesBernd Bruegge Component-Based Software Engineering 23
  24. 24. SPMP Part 1: Introductionv 1.1 Project Overview w Executive summary: description of project, product summaryv 1.2 Project Deliverables w All items to be delivered, including delivery dates and locationv 1.3 Evolution of the SPMP w Plans for anticipated and unanticipated changev 1.4 Reference Materials w Complete list of materials referenced in SPMPv 1.5 Definitions and AcronymsBernd Bruegge Component-Based Software Engineering 24
  25. 25. SPMP Part 2: Project Organizationv 2.1 Process Model w Relationships among project elementsv 2.2 Organizational Structure w Internal management, organization chartv 2.3 Organizational Interfaces w Relations with other entitiesv 2.4 Project Responsibilities w Major functions and activities; nature of each; who’s in chargeBernd Bruegge Component-Based Software Engineering 25
  26. 26. Process Modelv Shows relationships v Visualization of among process model w Functions, activities, v Project Management Aids tasks w MS Project (Microsoft) w Milestones w MAC Project (Claris) w Baselines w EasyTrak (Planning w Reviews Control International) w Work breakdown structure w Project deliverables w Sign-offsBernd Bruegge Component-Based Software Engineering 26
  27. 27. Example of an Organization Chart Client Management Consultants Cross-functional Teams Development Teams Architecture Logbook HCI Maintenance Web Master Documentation Vehicle Configuration Mgt Travel VIP Infrastructure TeamBernd Bruegge Component-Based Software Engineering 27
  28. 28. Clients, Managers and Consultants Management Malcolm Bauer Bernd Bruegge Allen Dutoit Brian Cavalier Sam Perman Consultants Isabel Torres-Yebra Klaus Eitzenberger Client Alfonso Guerrero- Galan Manfred Mueller Dieter Hege Juergen Bortolazzi, Brigitte Pihulak Claus Czymmek Infrastructure Team Stephan Schoenig (CMU) Joyce Johnstone (CMU) Andreas Doerner (DB) Arno Schmackpfeffer (DB)Bernd Bruegge Component-Based Software Engineering 28
  29. 29. Development and Cross-functional Teams Logbook Team Maintenance Vehicle Team Travel Team Aaron Wald Team Andrew Wang Ann Sluzhevsky Arjun Cholkar Hoda Bin Zhou Herbert Stiel Aveek Datta Moustapha Christopher Michael Poole Darren Mauro Jaewoo You Chiappa MichaelScheinholtz Joel Slovacek Ognjen Gordon Cheng Steve Sprang Martinovic John Doe Nathaniel Woods Vincent Mak Paul Stadler Kalyana Prattipati Pradip Hari Yenni Kwek Tze Bin Loh Michael Samuel Uhyon Chung William FerryVIP Team HCI Team Web Master Team Configuration Darren Mauro Mgt Team Christopher Lumb Gordon Cheng Uhyon Chang Michael Poole Eric Farng Idan Waisman (Logbook) (Logbook) Idan Waisman Paul Stadler Darren Mauro Steve Sprang Aveek Datta Li-Lun Cheng (Maintenance) (Maintenance) Patrick Toole Tze Bin Loh Yenni Kwek Tze Bin Loh William Ferry Phillip Ezolt (Simulation) Venkatesh (Simulation) Natarajan Kalyana Prattipati Chris Chiappa (Travel) (Travel) Eric Farng (VIP)Bernd Bruegge Component-Based Software Engineering 29
  30. 30. Project Responsibilitiesv Planner v Group leaderv Analyst v Liaisonv Designer v Minute Takerv Programmer v Project Managerv Testerv Maintainerv Trainerv Document Editorv Web Masterv Configuration ManagerBernd Bruegge Component-Based Software Engineering 30
  31. 31. Project Management: Hierarchical ProjectOrganization Chief Executive Team Leaders Project Members Basis of organization: Hierarchical information flow across corporate boundariesBernd Bruegge Component-Based Software Engineering 31
  32. 32. Example of Hierchical Organization:Chief Programmer Team Chief Programmer Assistant Chief Programmer Senior Programmer Librarian Administration Tester Junior ProgrammerBernd Bruegge Component-Based Software Engineering 32
  33. 33. Another Project Organization:Egoless Programming Team(Weinberg) Analyst Tester Programmer Designer LibrarianBernd Bruegge Component-Based Software Engineering 33
  34. 34. Project-Based Project Organization Project Leader Team Leaders Subsystem Team Subsystem Team Subsystem Team Team Members Basis of organization: Nonlinear information flow across dynamically formed unitsBernd Bruegge Component-Based Software Engineering 34
  35. 35. Observations on Management Structuresv Egoless structures dont work well w "Ownership" is importantv Hierarchical information flow does not work well with iterative and incremental software development process w Manager is not necessarily always rightv Project-based structures w Cut down on bureaucracy reduces development time w Decisions are expected to be made at each level w Hard to manageBernd Bruegge Component-Based Software Engineering 35
  36. 36. Hierarchical Structurev Projects with high degree of certainty, stability, uniformity and repetition. wRequires little communication wRole definitions are clearv When? wThe more people on the project, the more need for a formal structure wCustomer might insist that the test team be independent from the design team wProject manager insists on a previously successful structureBernd Bruegge Component-Based Software Engineering 36
  37. 37. Project-Based Structurev Project with degree of uncertainty wOpen communication needed among members wRoles are defined on project basisv When? wRequirements change during development wNew technology develops during projectBernd Bruegge Component-Based Software Engineering 37
  38. 38. Assigning Responsibilities To People Project To Do List Role 1 Person A • Item 1 Item 1 • Item 2 Item 2 Item 9 Role 1 • Item 3 • Item 4 Role 2 Role 2 Item 4 • Item 5 Item 5 • Item 6 Item 7 Person B • Item 7 • Item 8 Role 3 • Item 9 Item 3 Role 3 Item 6 Item 8Bernd Bruegge Component-Based Software Engineering 38
  39. 39. Possible Mappings of ToDos to Peoplev One-to-One w Ideal but often not worth to be called a projectv Many-to-Few w Each project member assumes several roles ("hats") w Danger of overcommittment w Need for load balancingv Many-to-"Too-Many" w Some people dont have significant roles w Bystanders w Loosing touch with projectBernd Bruegge Component-Based Software Engineering 39
  40. 40. Project Roles: Coachv Listen to gripes from individual teamsv Review weekly team reportsv Attend weekly project meetingsv Schedule and prepare meetings with clientv Insist that guidelines are followedv Assign presentations (in-class project meetings, client review, client acceptance test)v Resolve conflicts if they cannot be resolved otherwiseBernd Bruegge Component-Based Software Engineering 40
  41. 41. Project Role: Group leaderv Responsible for intra-group communication (Meeting Management: Primary Facilitator) w Run the weekly project meeting w Post agenda before meeting w Define and keep track of action items (who, what, when) w Measure progress (Enforce milestones) w Deliver work packages for the tasks to the project management w Present problems and status of team to project managerv The group leader has to be rotated among members of the team.Bernd Bruegge Component-Based Software Engineering 41
  42. 42. Group Leader: Create an Agendav Purpose of Meetingv Desired Outcomev Information Sharingv Information Processingv Meeting Critique Action Items (Check Previous Meeting) Issues (Check Previous Meeting & BBoards)Bernd Bruegge Component-Based Software Engineering 42
  43. 43. Project Role: Group Liason (Architecture, HCI)v Responsible for inter-group communication w Make available public definitions of subsystem developed by the team to the architecture teams (ensure consistency, etc) w Coordinate tasks spanning more than one group with other teamsv Responsible for team negotiationsBernd Bruegge Component-Based Software Engineering 43
  44. 44. Project Role: Plannerv Plans the activities of an individual team and has the following responsibilities.v Define project plan for team: w PERT chart, resource table and GANTT chart showing work packages w Enter project plan into MS Projectv Make project plan available to managementv Report group project status to group leader No explicit planner in JAMES. Responsibilities assumed by group leadersBernd Bruegge Component-Based Software Engineering 44
  45. 45. Project Role: Document Editorv Collect,proofread and distribute team documentationv Submit team documentation to Architecture teamv Collect agendasv Take Minutes at meetingsBernd Bruegge Component-Based Software Engineering 45
  46. 46. Web Masterv Maintain team home pagev Keep track of meeting historyv Keep track of design rationaleBernd Bruegge Component-Based Software Engineering 46
  47. 47. Web Master:v Publish Meeting Information on Team Homepage w Must contain Agenda, minutes, action items and issues w Possibilities: u One HTML document per meeting, with anchors (maintained by one role) u Separate HTML documents for Agenda, Minutes, etc (maintained by several roles) Date Agenda Minutes Action Items Issues 9/9/96 Agenda Minutes Action Items Issues 9/16/96 Agenda Minutes Action Items IssuesBernd Bruegge Component-Based Software Engineering 47
  48. 48. SPMP Part 3: Managerial Processesv 3.1 Management Objectives and Priorities w Philosophy, goals and prioritiesv 3.2 Assumptions, Dependencies, Constraints w External factorsv 3.3 Risk Management w Identifying, assessing, tracking, contingencies for risksv 3.4 Monitoring and Controlling Mechanisms w Reporting mechanisms and formats, information flows, reviewsv 3.5 Staffing Planv Needed skills (what?, how much?, when?)Bernd Bruegge Component-Based Software Engineering 48
  49. 49. Examples of Assumptionsv There are enough cycles on the development machinesv Security will not be addressedv There are no bugs in the CASE Tool recommended for the projectv A demonstration of the X system will be given by the clientv The CAD Model of the seat will be made available by the clientBernd Bruegge Component-Based Software Engineering 49
  50. 50. Examples of Dependenciesv The VIP team depends on the vehicle subsystem provided by the vehicle teamv The automatice code generation facility in the CASE tool Rose/Java depends on JDK. The current release of Rose/Java supports only JDK 1.0.2Bernd Bruegge Component-Based Software Engineering 50
  51. 51. Examples of Constraintsv The length of the project is 3 months. limited amount of time to build the systemv The project consists of beginners. It will take time to learn how to use the toolsv Not every project member is always up-to-date with respect to the project statusv The use of UML and a CASE tool is requiredv Any new code must be written in Javav The system must use Java JDK 1.1Bernd Bruegge Component-Based Software Engineering 51
  52. 52. Risk Managementv Risk: Members in key v Risk: One subsystem roles drop the course. does not provide the w Contingency: Roles are functionality needed by assigned to somebody else. another subsystem. Functionality of the system w Contingency: ? is renegotiated with the client. v Risk: Rose will notv Risk: The project is support JDK 1.1 falling behind schedule. w Contingency: ? w Contingency: Extra project meetings are scheduled.Bernd Bruegge Component-Based Software Engineering 52
  53. 53. SPMP Part 4: Technical Processv 4.1 Methods, Tools and Techniques w Computing system, development method, team structure, etc. w Standards, guidelines, policies.v 4.2 Software Documentation w Documentation plan, including milestones, reviews and baselines.v 4.3 Project Support Functions w Plans for functions (quality assurance, configuration management).Bernd Bruegge Component-Based Software Engineering 53
  54. 54. SPMP Part 5: Work Elementsv 5.1 Work Packages (Work breakdown structure) w Project decomposed into tasks; definitions of tasksv 5.2 Dependencies w Precedence relations among functions, activities and tasksv 5.3 Resource Requirements w Estimates for resources such as personnel, computer time, special hardware, support software.v 5.4 Budget and Resource Allocation w Connect costs to functions, activities and tasks.v 5.5 Schedule w Deadlines, accounting for dependencies, required milestonesBernd Bruegge Component-Based Software Engineering 54
  55. 55. Creating Work Packagesv Work Breakdown Structure (WBS) (Section 5.1) w Break up project into activities (phases, steps) and tasks. w The work breakdown structure does not show the interdependence of the tasksv WBS identification is an instance of object identificationBernd Bruegge Component-Based Software Engineering 55
  56. 56. WBS Trade-offsv Work breakdown structure influences cost and schedulev Thresholds for establishing WBS in terms of percentage of total effort: w Small project (7 person-month): at least 7% or 0.5 PM w Medium project (300 person-month): at least 1% or 3 PMs w Large project (7000 person-month): at least 0.2 % or 15 PMsv Determination of work breakdown structure is incremental and iterative Source: Software Engineering WBS Schedule Economics, Barry W. Boehm p. 47, Prentice Hall, N.J., 1981 Cost (Time, $$)Bernd Bruegge Component-Based Software Engineering 56
  57. 57. Dependencies and Schedule (Section 5.2 + 5.5)v An important temporal relation: “must be preceded by”v Dependency graphs show dependencies of the tasks (hiercharchical and temporal) w Activity Graph: u Nodes of the graph are the project milestones u Lines linking the nodes represent the tasks involved w Schedule Chart (MS-Project): u Nodes are tasks and milestones u Lines represent temporal dependenciesv Estimate the duration of each taskv Label dependency graph with the estimatesBernd Bruegge Component-Based Software Engineering 57
  58. 58. Project Management Tools for Work Packagesv Visualization Aids for Project Presentation w Graphs (Schedule), Trees (WBS) w Tables (Resources)v Task Timeline w Gantt Charts: Shows project activities and tasks in parallel. Enables the project manager to understand which tasks can be performed concurrently.v Schedule Chart (PERT Chart) w Cornerstone in many project management tools w Graphically shows dependencies of tasks and milestones u PERT: Program Evaluation and Review Technique – A PERT chart assumes normal distribution of tasks durations – Useful for Critical Path Analysis u CPM: Critical Path MethodBernd Bruegge Component-Based Software Engineering 58
  59. 59. GANTT Chart Example for OWL Project 8/9/96 9/6/96 10/4/96 11/1/96 11/29/96 12/27/96 Start Planning Phase Requirements Analysis Phase System Design Phase Analysis Review Object Design Project Review Implementation & Unit Testing Object Design Review System Integration Internal Project Review Client AcceptanceBernd Bruegge Component-Based Software Engineering 59
  60. 60. Project: Building a Housev Activity 1: Landscaping the lot w Task 1.1: Clearing and grubbing w Task 1.2: Seeding the Turf w Task 1.3: Planting shrubs and treesv Activity 2: Building the House w Activity 2.1 : Site preparation w Activity 2.2: Building the exterior w Activity 2.3: Finishing the interiorv Activity 2.1 : Site preparation w Task 2.1.1: Surveying w Task 2.1.2: Obtaining permits w Task 2.1.3: Excavatingv Task 2.1.4: Obtaining materialsBernd Bruegge Component-Based Software Engineering 60
  61. 61. Activity 2: Building a House, ctdv Activity 2.2: Building the v Activity 2.3 : Finishing the exterior Interior w Task 2.2.1: Foundation w Task 2.3.1: Interior w Task 2.2.2: Outside Walls plumbing w Task 2.2.3: Exterior w Task 2.3.2: Interior plumbing electrical work w Task 2.2.4: Exterior w Task 2.3.3: Wallboard electrical work w Task 2.3.4: Interior w Task 2.2.5: Exterior siding painting w Task 2.2.6: Exteror painting w Task 2.3.5: Floor covering w Task 2.2.7: Doors and w Task 2.3.6: Doors and Fixtures fixtures w Task 2.2.8: RoofBernd Bruegge Component-Based Software Engineering 61
  62. 62. Activity Graph for Activity “Building a House” START Build Outside Wall Surveying 1.2 1.1 Excavation 1.3 Buy Materials 1.4 Lay Foundation 2.1 Build Outside Wall Install Exterior Plumbing 2.2 Install Interior Plumbing 2.3 3.1 Install Exterior Electrical Install Interior Electrical 2.4 3.2 Install Exterior Siding Install Wallboard 2.5 3.3 Paint Exterior Install Flooring Paint Interior 2.6 3.4 3.5 Install Exterior Doors Install Roofing Install Interior Doors 2.7 2.8 3.6 2.6 FINISHBernd Bruegge Component-Based Software Engineering 62
  63. 63. PERT Chart Example for "Building a House" 12/3/94 12/21/94 1/11/95 Install Install Install Interior Interior Wallboard Plumbing Electrical Building a House: 0 0 0 1/22/95 12 15 9 Paint MS Project PERTcy Interior Chart with Duration of Activities (Pfleeger 2.3) 0 2/8/95 11 1/22/95 Install Interior Install Doors Flooring 0 10/15/94 11/5/94 7 8/27/94 8/27/94 9/17/94 10/1/94 0 2/16/95 Lay Build 18 START Survey Excava Buy 1/19/95 FINISH Founda Outside ing tion Material tion Wall Install 0 Roofing 1/19/95 0 0 12 0 0 0 0 10 10 Install 0 3 15 20 12 9 Exterior Doors 8/27/94 15 Request 1/12/95 6 Permits Paint 0 Exterior 15 12 5 12/3/94 12/17/94 12/31/94 Install Install Install Start Time 8/29/94 Exterior Exterior Exterior Legend Plumbing Electrical Siding 12 12 12 Slack Time 0 8 10 10 Duration 0Bernd Bruegge Component-Based Software Engineering 63
  64. 64. Slack Time and Critical Pathv Slack Time w Available Time - Estimated (“Real”) Time for a task or activity w Or: Latest Start Time - Earliest Start Timev Critical Path w The path in a project plan for which the slack time at each task is zero.The critical path has no margin for error when performing the tasks (activities) along its route.Bernd Bruegge Component-Based Software Engineering 64
  65. 65. How do you become a good project planner?v Establish a project plan w Start with the plan based on your experience with the last project(s)v Keep track of activities and their durationv Determine difference between planned and actual performancev Make sure to do a post-mortem w Lessons learned w Ask developers for feedback w Write a document about what could have been improvedBernd Bruegge Component-Based Software Engineering 65
  66. 66. Writing the SPMPv Example of a full SPMP for the OWL project w Bruegge Component-Based Software Engineering 66
  67. 67. Project Management Heuristicsv Make sure to be able to revise or dump a project plan w Complex system development is a nonlinear activityv If project goals are unclear and complex use team-based project management. In this case w Avoid perfect GANTT charts and PERT charts w Don’t look too far into the futurev Avoid micro management of detailsv Don’t be surprise if current project management tools don’t work: w They were designed for projects with clear goals and fixed organizational structuresBernd Bruegge Component-Based Software Engineering 67
  68. 68. Project Management Summaryv Get agreement among customers, managers and teams w Problem statement w Software project management plan w Project agreement w Make sure agreement allows for iterationv Team Structuresv Project planning w Start with work breakdown structure (WBS) w Identify dependencies and structure: Tasks, activities, functionsv Tools and Techniques w GANTT, Dependency graph, Schedule, Critical Path AnalysisBernd Bruegge Component-Based Software Engineering 68
  69. 69. Communication Managementv Communication in distributed Teamsv Communication Modesv Communication Mechanismsv Scheduled Communicationsv Communication workflow w Example: Distributed Document Review with Lotus NotesBernd Bruegge Component-Based Software Engineering 69
  70. 70. A Communication Examplev "Two missile electrical boxes manufactured by different contractors were joined together by a pair of wires. Box 1 Pair of Wires Box 2Bernd Bruegge Component-Based Software Engineering 70
  71. 71. A Communication Example ctdv Thanks to a particular thorough preflight check, it was discovered that the wires had been reversed." Box 1 Box 2Bernd Bruegge Component-Based Software Engineering 71
  72. 72. After the Crash...v ...v "The postflight analysis revealed that the contractors had indeed corrected the reversed wires as instructed."Bernd Bruegge Component-Based Software Engineering 72
  73. 73. “In fact, both of them had.” Box 1 Box 2Bernd Bruegge Component-Based Software Engineering 73
  74. 74. Communication is Importantv Communication Mode: Type of information exchange that has defined objectives and scope w Scheduled: Planned Communication w Event Driven:Unplanned Communicationv Communication Mechanism Tool or procedure that can be used to transmit or receive information w Synchronous: Sender and Receiver are available at the same time w Asynchronous: Sender and Receiver are not communicating at the same time.Bernd Bruegge Component-Based Software Engineering 74
  75. 75. Classification of Communication Communication supports Communication mode is supported by mechanism Scheduled Event driven Synchronous Asynchronous Client review Problem reporting Smoke signals FaxBernd Bruegge Component-Based Software Engineering 75
  76. 76. Scheduled Modes of Communicationv Problem Definition w Objective: Present Goals & Requirements (Functional, Nonfunctional) and Constraints u Problem Statement Presentation (JAMES Example: August 26, 97)v Project Review: Focus on System Model w Objective: Assess status and review subsystem interfaces u Analysis Review (October 16, 1997) u Object Design Review (November 11 & 13, 1997) u Implementation Review (November 25, 1997)v Client Review: Focus on Requirements w Objective: Brief Client of Progress, Confirm Changes in Requirements u System Design Review (October 23, 1997)Bernd Bruegge Component-Based Software Engineering 76
  77. 77. Scheduled Modes of Communicationv Walkthrough (Informal) w Objective: Increase quality of subsystem w Developer presents to team members Informal, peer- to-peer u To be scheduled by each teamv Inspection (Formal) w Objective: Compliance with (functional and nonfunctional) requirements w Developer answers questions from the reviewers u Client Acceptance Test (December 9, 1997)Bernd Bruegge Component-Based Software Engineering 77
  78. 78. Scheduled Modes of Communicationv Status Review: w Objective: Find deviations from schedule and correct them or identify new issues w Part of every team meeting (Status)v Brainstorming: w Objective: Generate and evaluate large number of solutions for a problem w Part of every team meeting (Discussion)Bernd Bruegge Component-Based Software Engineering 78
  79. 79. Meeting as Scheduled and SynchronousCommunicationv Purpose of Meeting w Why do we meet?v Desired Outcome w What do we want to achieve?v Information Sharing w Action Itemsv Information Processing w Open Issues Action Itemsv Meeting Critique (From previous meeting) Issues (From previous meetings and BBoards)Bernd Bruegge Component-Based Software Engineering 79
  80. 80. Scheduled Modes of Communicationv Release w The result of each software development activity u Software Project Management Plan (SPMP) u Requirements Analysis Document (RAD) u System Design Document (SDD) u Object Design Document (ODD) u Test Manual u User Manualv Postmortem Review w Objective: Describe Lessons Learned u Final Homework (December 16, 1997)Bernd Bruegge Component-Based Software Engineering 80
  81. 81. Event-Driven Modes of Communicationv Request for Clarificationv Change Requestv Resolution of IssueBernd Bruegge Component-Based Software Engineering 81
  82. 82. Synchronous Communication Mechanismsv Hallway conversation w Unplanned face-to-face meetingv Questionaire and structured interviewsv Meeting w Planned Face-to-Face Meeting, Telephone conversationv Groupware w Same time, different location groupwareBernd Bruegge Component-Based Software Engineering 82
  83. 83. Asynchronous Communication Mechanismsv E-Mailv Newsgroupsv Webv Lotus NotesBernd Bruegge Component-Based Software Engineering 83
  84. 84. Example of Asynchronous Documentation:Document Reviewv Fill out a review formv Attach document to be reviewedv Distribute the review form to reviewersv Wait for comments from reviewersv Review commentsv Create action items from selected commentsv Revise document and post the revised versionv Iterate the review cycle Example: w “Review of Documents” Database in JAMES ProjectBernd Bruegge Component-Based Software Engineering 84
  85. 85. Review ofDocumentsDatabase Bernd Bruegge Component-Based Software Engineering 85
  86. 86. NewReview FormBernd Bruegge Component-Based Software Engineering 86
  87. 87. Fill out the Review Formv Select reviewersv Select the document to be reviewedv Add comments to reviewersv Determine deadlineBernd Bruegge Component-Based Software Engineering 87
  88. 88. Reviewer Notificationv Selected reviewers get e-mailBernd Bruegge Component-Based Software Engineering 88
  89. 89. Status of Document ReviewBernd Bruegge Component-Based Software Engineering 89
  90. 90. Reviewersadd theirComments Bernd Bruegge Component-Based Software Engineering 90
  91. 91. Originator NotificationBernd Bruegge Component-Based Software Engineering 91
  92. 92. Final Recipient NotificationBernd Bruegge Component-Based Software Engineering 92
  93. 93. Document Editor & Web Master Tasksv Editor reviews commentsv Editor selects reviewed commentsv Web Master posts reviewed document and action itemsv Team members complete their action itemsv Editor integrates changesv Editor posts changed document on the review database for the next review cycleBernd Bruegge Component-Based Software Engineering 93
  94. 94. Accepted Document w/ Action ItemsBernd Bruegge Component-Based Software Engineering 94
  95. 95. SPMP Action ItemsBernd Bruegge Component-Based Software Engineering 95
  96. 96. Summaryv Communication Modes vs Communication Mechanismsv Scheduled Communicationsv Asynchronous Communicationsv Team review of documents with Lotus NotesBernd Bruegge Component-Based Software Engineering 96