Project management
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Project management

on

  • 561 views

 

Statistics

Views

Total Views
561
Views on SlideShare
561
Embed Views
0

Actions

Likes
1
Downloads
7
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Project management Presentation Transcript

  • 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. 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. 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. 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. 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. How it should go Requirements Analysis Design Implementation System Testing Delivery and InstallationBernd Bruegge Component-Based Software Engineering 6
  • 7. How it often goes Requirements Analysis D E L A Y VaporwareBernd Bruegge Component-Based Software Engineering 7
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Another Project Organization:Egoless Programming Team(Weinberg) Analyst Tester Programmer Designer LibrarianBernd Bruegge Component-Based Software Engineering 33
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Web Masterv Maintain team home pagev Keep track of meeting historyv Keep track of design rationaleBernd Bruegge Component-Based Software Engineering 46
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Writing the SPMPv Example of a full SPMP for the OWL project w http://cascade1.se.cs.cmu.edu/15-413/courseDocs/spmpF96.htmlBernd Bruegge Component-Based Software Engineering 66
  • 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. 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. 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. 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. 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. 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. “In fact, both of them had.” Box 1 Box 2Bernd Bruegge Component-Based Software Engineering 73
  • 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. 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. 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. 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. 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. 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. 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. Event-Driven Modes of Communicationv Request for Clarificationv Change Requestv Resolution of IssueBernd Bruegge Component-Based Software Engineering 81
  • 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. Asynchronous Communication Mechanismsv E-Mailv Newsgroupsv Webv Lotus NotesBernd Bruegge Component-Based Software Engineering 83
  • 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. Review ofDocumentsDatabase Bernd Bruegge Component-Based Software Engineering 85
  • 86. NewReview FormBernd Bruegge Component-Based Software Engineering 86
  • 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. Reviewer Notificationv Selected reviewers get e-mailBernd Bruegge Component-Based Software Engineering 88
  • 89. Status of Document ReviewBernd Bruegge Component-Based Software Engineering 89
  • 90. Reviewersadd theirComments Bernd Bruegge Component-Based Software Engineering 90
  • 91. Originator NotificationBernd Bruegge Component-Based Software Engineering 91
  • 92. Final Recipient NotificationBernd Bruegge Component-Based Software Engineering 92
  • 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. Accepted Document w/ Action ItemsBernd Bruegge Component-Based Software Engineering 94
  • 95. SPMP Action ItemsBernd Bruegge Component-Based Software Engineering 95
  • 96. Summaryv Communication Modes vs Communication Mechanismsv Scheduled Communicationsv Asynchronous Communicationsv Team review of documents with Lotus NotesBernd Bruegge Component-Based Software Engineering 96