You are on page 1of 73

Object-Oriented Software Engineering

Conquering Complex and Changing Systems

Chapter 11, Project Management

Outline
j j j j j j j j j j j

Concepts and terminology Purpose of Software Project Management Plans Structure of a Project Management Plan Project responsibilities Team structures Project planning Work breakdown structure Communication Management Dependencies Schedule Project Management Tools
Object-Oriented Software Engineering: Conquering Complex and Changing Systems 2

Bernd Bruegge & Allen Dutoit

Reference:
 Bruegge&Dutoit, Chapter 12


http://notesbruegge.in.tum.de/PAID2/schedule/ProjectManagement011599.pdf

What is not covered in this lecture?


 Communication Management, Meeting Management  Bruegge & Dutoit, Chapter 4


http://notesbruegge.in.tum.de/PAID2/schedule/ProjectCommunication112598.pdf

 Cost estimation


Reference: Software engineering economics, Barry Boehm, Prentice Hall 1981

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Laws of Project Management


j

Projects progress quickly until they are 90% complete. Then they remain at 90% complete forever. When things are going well, something will go wrong. When things just cant get worse, they will. When things appear to be going better, you have overlooked something. If project content is allowed to change freely, the rate of change will exceed the rate of progress. Project teams detest progress reporting because it manifests their lack of progress.

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

How it should go
Requirements Analysis Design

Implementation

System Testing

Delivery and Installation

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

How it often goes


Requirements Analysis

D E L A Y Vaporware
6

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Software Project Management Plan


j

Software Project:
 All technical and managerial activities required to deliver the deliverables to the client.  A software project has a specific duration, consumes resources and produces work products.  Management categories to complete a software project:  Tasks, Activities, Functions

Software Project Management Plan:


 The controlling document for a software project.  Specifies the technical and managerial approaches to develop the software product.  Companion document to requirements analysis document: Changes in either may imply changes in the other document.  SPMP may be part of project agreement.

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Project Agreement
j

Document written for a client that defines:


 the scope, duration, cost and deliverables for the project.  the exact items, quantities, delivery dates, delivery location.

j j j

Can be a contract, a statement of work, a business plan, or a project charter. Client: Individual or organization that specifies the requirements and accepts the project deliverables. Deliverables (= Work Products that will be delivered to the client):
    Documents Demonstrations of function Demonstration of nonfunctional requirements Demonstrations of subsystems

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Project Agreement vs Problem Statement


Client (Sponsor) Manager Project Team

Problem Statement Project Agreement


Bernd Bruegge & Allen Dutoit

Software Project Management Plan

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Project Management Activities (continued on next slide)


Initiation Problem statement definition

Initial top-level design

Initial milestones planning

Team formation

Communication infrastructure setup

Project kickoff

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

10

Project kickoff Steady state

Status monitoring

Risk management

Project replanning

Project agreement

Termination

Installation

Client acceptance test

Postmortem

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

11

Project: Functions, Activities and Tasks


f1:Function p:Project f2:Function

a1:Activity

a2:Activity

a3:Activity

a2.1:Activity

a2.2:Activity

a2.3:Activity

t1:Task

t2:Task

t3:Task

t4:Task

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

12

Functions
j

Activity or set of activities that span the duration of the project


f1:Function p:Project f2:Function

a1:Activity

a2:Activity

a3:Activity

a2.1:Activity

a2.2:Activity

a2.3:Activity

t1:Task
Bernd Bruegge & Allen Dutoit

t2:Task

t3:Task

t4:Task
13

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Functions
j

Examples:
     Project management Configuration Management Documentation Quality Control (Verification and validation) Training

j j

Question: Is system integration a project function? Mapping of terms: Project Functions in the IEEE 1058 standard are called Integral processes in the IEEE 1074 standard. We call them cross-development processes

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

14

Tasks
f1:Function p:Project f2:Function

a1:Activity

a2:Activity

Smallest unit of work subject to management Small enough for adequate planning and tracking Large enough to avoid micro management
15

a2.1:Activity

a2.2:Activity

t1:Task

t2:Task

t3:Task

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Tasks
j

Smallest unit of management accountability


 Atomic unit of planning and tracking  Finite duration, need resources, produce tangible result (documents, code)

Specification of a task: Work package


    Name, description of work to be done Preconditions for starting, duration, required resources Work product to be produced, acceptance criteria for it Risk involved

Completion criteria
 Includes the acceptance criteria for the work products (deliverables) produced by the task.

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

16

Task Sizes
j

Finding the appropriate task size is problematic


 Todo lists from previous projects  During initial planning a task is necessarily large  You may not know how to decompose the problem into tasks at first  Each software development activity identifies more tasks and modifies existing ones

Tasks must be decomposed into sizes that allow monitoring


 Work package usually corresponds to well defined work assignment for one worker for a week or a month.  Depends on nature of work and how well task is understood.

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

17

Examples of Tasks
j j j j j j j j j

Unit test class Foo Test subsystem Bla Write user manual Write meeting minutes and post them Write a memo on NT vs Unix Schedule the code review Develop the project plan Related tasks are grouped into hierarchical sets of functions and activities. Action item

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

18

Action Item
j j

Definition: A task assigned to a person that has to be done within a week or less Action items
 Appear on the agenda in the Status Section (See lecture on communication)  Cover: What?, Who?, When?

Example of action items:


 Florian unit tests class Foo by next week  Marcus develops a project plan before the next meeting  Bob posts the next agenda for the Simulation team meeting before Sep 10, 12noon.  The VIP team develops the project plan by Sep 18

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

19

Activities
f1:Function p:Project f2:Function

a1:Activity

a2:Activity

Major unit of work with precise dates Consists of smaller activities or tasks Culminates in project milestone.
20

a2.1:Activity

a2.2:Activity

t1:Task

t2:Task

t3:Task

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

Activities
j j

Major unit of work Culminates in major project milestone:


 Internal checkpoint should not be externally visible  Scheduled event used to measure progress

Activities may be grouped into larger activities:


 Establishes hierarchical structure for project (phase, step, ...)  Allows separation of concerns  Precedence relations often exist among activities (PERT Chart)

Milestone often produces baseline:


 formally reviewed work product  under change control (change requires formal procedures)

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

21

Examples of Activities
j

Major Activities:
        Planning Requirements Elicitation Requirements Analysis System Design Object Design Implementation System Testing Delivery

Activities during requirements analysis:


     Refine scenarios Define Use Case model Define object model Define dynamic model Design User Interface

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

22

Structure of a Software Project Management Plan


Front Matter 1. Introduction 2. Project Organization 3. Managerial Process 4. Technical Process 5. Work Elements, Schedule, Budget Optional Inclusions

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

23

SPMP Part 0: Front Matter


j j j j

Title Page Revision sheet (update history) Preface: Scope and purpose Tables of contents, figures, tables

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

24

SPMP Part 1: Introduction


1.1 Project Overview
 Executive summary: description of project, product summary

1.2 Project Deliverables


 All items to be delivered, including delivery dates and location

1.3 Evolution of the SPMP


 Plans for anticipated and unanticipated change

1.4 Reference Materials


 Complete list of materials referenced in SPMP

1.5 Definitions and Acronyms

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

25

SPMP Part 2: Project Organization


2.1 Process Model
 Relationships among project elements

2.2 Organizational Structure


 Internal management, organization chart

2.3 Organizational Interfaces


 Relations with other entities

2.4 Project Responsibilities


 Major functions and activities; nature of each; whos in charge

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

26

Process Model
j

Shows relationships among


       Functions, activities, tasks Milestones Baselines Reviews Work breakdown structure Project deliverables Sign-offs

j j

Visualization of process model Project Management Aids


 MS Project (Microsoft)  MAC Project (Claris)  EasyTrak (Planning Control International)

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

27

Example of an Organization Chart

Client

Management

Consultants

Cross-functional Teams

Development Teams

Architecture HCI

Logbook Maintenance

Web Master Documentation Configuration Mgt Vehicle Travel VIP Infrastructure Team

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

28

Project Roles
j j j j j j j j j j

Planner Analyst Designer Programmer Tester Maintainer Trainer Document Editor Web Master Configuration Manager

j j j j

Group leader Liaison Minute Taker Project Manager

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

29

Project Roles
j

Management roles
 Organization and execution of the project within constraints. Examples: project manager, team leader.

Development roles
 Specification, design and construction of subsystems. Examples: Analyst, system architect, implementor.

Cross functional roles


 Coordination of more than one team. Example: API Engineer, configuration manager, tester

Consultant roles
 Support in areas where the project participants lack expertise. Examples: End user, client, application domain specialist ( problem domain), technical consultant (solution domain).

Promoter roles
 Promote change through an organization.
Object-Oriented Software Engineering: Conquering Complex and Changing Systems 30

Bernd Bruegge & Allen Dutoit

Promoter Roles
j j

Promoters are self appointed individuals who identify themselves with the outcome of the project. They are member of the corporate organization and may not necessarily be directly involved with the project. Instead, they are interfaces to the rest of the corporate organization. Because of the power, knowledge of technology, or familiarity with the projects processes, they are able to promote and push specific changes through the organization.

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

31

Power Promoter
j j

j j

Also called executive champion Pushes the change through the existing organizational hierarchy.  not necessarily at the top of the organization, but must have protection from top level management, otherwise project opponents might be able to prevent the success of the project. Tasks:  constantly identify difficulties, resolve issues, and communicate with the project members, especially with the developers. Example at project level: Project Manager. Example at corporate level: Chief Executive Officer (CEO).

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

32

Knowledge Promoter
j j j

Also called the technologist, Promotes change arising in the application domain or the solution domain. Usually associated with the power promoter. Tasks: Acquire information iteratively, understand the benefits and limitations of new technologies, and argue its adoption with the other developers. Example at project level: System architect.
 Reports to project manager  Does not have any direct subordinate in the reporting hierarchy  Has final say over all technical decisions in the system.

Example at corporate level: Chief Technical Officer (CTO).

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

33

Process Promoter
j j j j

The process promoter has intimate knowledge of the projects processes and procedures. The process promoter is in constant interaction with the power promoter to get consensus on the overall goals. Tasks: Bridge between the power and knowledge promoters, who often do not speak or understand the same language. Example at project level: Development lead. Responsible for the administrative aspects of a project, including planning, milestones definition, budgeting and communication infrastructure. Example at corporate level: Chief Information Officer (CIO

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

34

Project Management: Hierarchical Project Organization


Control Flow Information Flow

Chief Executive First Level Manager (Front-Line Manager)

Project Members

A wants to talk to B: Complicated Information Flow A wants to make sure B does a certain change: Complicated Controlflow

Basis of organization: Complicated information and control flow across hierarchical boundaries
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 35

Example of Hierchical Organization: Chief Programmer Team


Chief Programmer

Assistant Chief Programmer

Senior Programmer

Librarian

Administration

Tester

Junior Programmer

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

36

Another Project Organization: Egoless Programming Team (Weinberg)


Analyst

Tester

Programmer

Designer

Librarian

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

37

Project-Based Project Organization


Project Leader Coaches Subsystem Team A Subsystem Team Subsystem Team B Team Members

A wants to talk to B: Communication Flow A wants to make sure B does a certain change: Decision Flow

Basis of organization: Nonlinear information flow across dynamically formed units


Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 38

Associations in organizational structures


j

Reporting association:
 Used for reporting status information

Decision association
 Used for propagating decisions

Communication association
 Used for exchanging information needed for decisions (e.g., requirements, design models, issues).

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

39

Observations on Management Structures


j

Hierarchical structures
 Reports, Decides and Communicates-With all mapped on the same association  Do not work well with iterative and incremental software development process  Manager is not necessarily always right

Project-based structures
 Reports, Decides and Communicates-Withare different associations  Cut down on bureaucracy reduces development time  Decisions are expected to be made at each level  Hard to manage

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

40

Hierarchical Structure
j

Projects with high degree of certainty, stability, uniformity and repetition.


 Requires little communication  Role definitions are clear

When?
 The more people on the project, the more need for a formal structure  Customer might insist that the test team be independent from the design team  Project manager insists on a previously successful structure

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

41

Project-Based Structure
j

Project with degree of uncertainty


 Open communication needed among members  Roles are defined on project basis

When?
 Requirements change during development  New technology develops during project

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

42

Assigning Responsibilities To People


Team A To Do List for the Project Item 1 Item 2 Item 3 Item 4 Item 5 Item 6 Item 7 Item 8 Item 9 Role 3 Item 3 Item 6 Item 8 Role 1 Item 1 Item 2 Item 9 Role 2 Item 4 Item 5 Item 7 Person A Role 1 Role 2

Person B

Role 3

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

43

Possible Mappings of ToDos to People


j

One-to-One
 Ideal but often not worth to be called a project

Many-to-Few
 Each project member assumes several roles ("hats")  Danger of overcommittment  Need for load balancing

Many-to-"Too-Many"
 Some people don't have significant roles  Bystanders  Loosing touch with project

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

44

Team Formation
j

Top level Design


 Rough Subsystem Decomposition (before requirements analysis)  Done during Predevelopment phase

j j

Team Formation done after Top Level Design Heuristics:


 One team for each subsystem  One cross-functional task per team  5-7 members per team

Be prepared to iterate the team formation after system design when the subsystem decomposition is baselined

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

45

Project Roles: Coach


j j j j j j j

Listen to gripes from individual teams Review weekly team reports Attend weekly project meetings Schedule and prepare meetings with client Insist that guidelines are followed Assign presentations (in-class project meetings, client review, client acceptance test) Resolve conflicts if they cannot be resolved otherwise

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

46

Project Role: Group leader


j

Responsible for intra-group communication (Meeting Management: Primary Facilitator)


      Run the weekly project meeting Post agenda before meeting Define and keep track of action items (who, what, when) Measure progress (Enforce milestones) Deliver work packages for the tasks to the project management Present problems and status of team to project manager

The group leader has to be rotated among members of the team.

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

47

Group Leader: Create an Agenda


j j j j j

Purpose of Meeting Desired Outcome Information Sharing Information Processing Meeting Critique

Action Items (Check Previous Meeting)

Issues (Check Previous Meeting & BBoards)


Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 48

Project Role: Liaison


j

Responsible for inter-group communication


 Make available public definitions of subsystem developed by the team to the architecture teams (ensure consistency, etc)  Coordinate tasks spanning more than one group with other teams

j j

Responsible for team negotiations Examples: API Engineer, Configuration manager

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

49

Project Role: Planner


j j

Plans and tracks the activities of an individual team and has the following responsibilities. Define project plan for team:
 PERT chart, resource table and GANTT chart showing work packages  Enter project plan into project management tool

j j

Make project plan available to management Report team status to project manager No explicit planner in PAID. Responsibilities assumed by coaches

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

50

Project Role: Document Editor


j j j j

Collect, proofread and distribute team documentation Submit team documentation to architecture team Collect agendas Take minutes at meetings

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

51

Web Master
j j j

Maintain team home page Keep track of meeting history Keep track of design rationale

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

52

Web Master:
j

Publish Meeting Information on Team Homepage


 Must contain Agenda, minutes, action items and issues  Possibilities:


One HTML document per meeting, with anchors (maintained by one role) Separate HTML documents for Agenda, Minutes, etc (maintained by several roles) Agenda Agenda Agenda Minutes Minutes Minutes Action Items Action Items Action Items Issues Issues Issues

Date 9/9/96 9/16/96

http://cascade1.se.cs.cmu.edu/ 15-413/homePagesTeams/UserInterface/www/index.htm
Bernd Bruegge & Allen Dutoit Object-Oriented Software Engineering: Conquering Complex and Changing Systems 53

SPMP Part 3: Managerial Processes


3.1 Management Objectives and Priorities
 Philosophy, goals and priorities

3.2 Assumptions, Dependencies, Constraints


 External factors

3.3 Risk Management


 Identifying, assessing, tracking, contingencies for risks

3.4 Monitoring and Controlling Mechanisms


 Reporting mechanisms and formats, information flows, reviews

3.5 Staffing Plan


 Needed skills (what?, how much?, when?)

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

54

Examples of Assumptions
j j j j

There are enough cycles on the development machines Security will not be addressed There are no bugs in Together-J, the CASE Tool recommended for the project A demonstration of the Starnetwork system will be given by the client

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

55

Examples of Dependencies
j j

The database team depends on the EPC database provided by DaimlerChrysler The automatic code generation facility in the CASE tool depends on JDK. The current release of Together-J supports only JDK 1.1.6

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

56

Examples of Constraints
j j j j j j

The length of the project is 3 months. limited amount of time to build the system The project consists of beginners. It will take time to learn how to use the tools Not every project member is always up-to-date with respect to the project status The use of UML and a CASE tool is required Any new code must be written in Java The system must use Java JDK 1.1.6

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

57

Risk Management
j

Risk: Members in key roles drop the course.


 Contingency: Roles are assigned to somebody else. Functionality of the system is renegotiated with the client.

Risk: One subsystem does not provide the functionality needed by another subsystem.
 Contingency: ?

Risk: The project is falling behind schedule.


 Contingency: Extra project meetings are scheduled.

Risk: Ibutton runs only under JDK 1.2


 Contingency: ?

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

58

SPMP Part 4: Technical Process


4.1 Methods, Tools and Techniques
 Computing system, development method, team structure, etc.  Standards, guidelines, policies.

4.2 Software Documentation


 Documentation plan, including milestones, reviews and baselines.

4.3 Project Support Functions


 Plans for functions (quality assurance, configuration management).

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

59

SPMP Part 5: Work Elements


5.1 Work Packages (Work breakdown structure)
 Project decomposed into tasks; definitions of tasks

5.2 Dependencies
 Precedence relations among functions, activities and tasks

5.3 Resource Requirements


 Estimates for resources such as personnel, computer time, special hardware, support software.

5.4 Budget and Resource Allocation


 Connect costs to functions, activities and tasks.

5.5 Schedule
 Deadlines, accounting for dependencies, required milestones

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

60

Creating Work Packages


j

Work Breakdown Structure (WBS) (Section 5.1)


 Break up project into activities (phases, steps) and tasks.  The work breakdown structure does not show the interdependence of the tasks

The identification of the work breakdown structure is an instance of object identification and associating these objects

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

61

WBS Trade-offs
j j

Work breakdown structure influences cost and schedule Thresholds for establishing WBS in terms of percentage of total effort:
 Small project (7 person-month): at least 7% or 0.5 PM  Medium project (300 person-month): at least 1% or 3 PMs  Large project (7000 person-month): at least 0.2 % or 15 PMs

Determination of work breakdown structure is incremental and iterative


WBS Schedule
Source: Software Engineering Economics, Barry W. Boehm p. 47, Prentice Hall, N.J., 1981

Cost
(Time, $$)

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

62

Dependencies and Schedule (SPMP Section 5.2 + 5.5)


j j

An important temporal relation: must be preceded by Dependency graphs show dependencies of the tasks (hierarchical and temporal)
 Activity Graph:
 

Nodes of the graph are the project milestones Lines linking the nodes represent the tasks involved Nodes are tasks and milestones Lines represent temporal dependencies

 Schedule Chart (MS-Project):


 

j j

Estimate the duration of each task Label dependency graph with the estimates

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

63

Project Management Tools for Work Packages


j

Visualization Aids for Project Presentation


 Graphs (Schedule), Trees (WBS)  Tables (Resources)

Task Timeline
 Gantt Charts: Shows project activities and tasks in parallel. Enables the project manager to understand which tasks can be performed concurrently.

Schedule Chart (PERT Chart)


 Cornerstone in many project management tools  Graphically shows dependencies of tasks and milestones


PERT: Program Evaluation and Review Technique A PERT chart assumes normal distribution of tasks durations Useful for Critical Path Analysis CPM: Critical Path Method
Object-Oriented Software Engineering: Conquering Complex and Changing Systems 64

Bernd Bruegge & Allen Dutoit

Project: Building a House


j

Activity 1: Landscaping the lot  Task 1.1: Clearing and grubbing  Task 1.2: Seeding the Turf  Task 1.3: Planting shrubs and trees Activity 2: Building the House  Activity 2.1 : Site preparation  Activity 2.2: Building the exterior  Activity 2.3: Finishing the interior Activity 2.1 : Site preparation  Task 2.1.1: Surveying  Task 2.1.2: Obtaining permits  Task 2.1.3: Excavating Task 2.1.4: Obtaining materials
Object-Oriented Software Engineering: Conquering Complex and Changing Systems 65

Bernd Bruegge & Allen Dutoit

Activity 2: Building a House, ctd


j

Activity 2.2: Building the exterior  Task 2.2.1: Foundation  Task 2.2.2: Outside Walls  Task 2.2.3: Exterior plumbing  Task 2.2.4: Exterior electrical work  Task 2.2.5: Exterior siding  Task 2.2.6: Exterior painting  Task 2.2.7: Doors and Fixtures  Task 2.2.8: Roof

Activity 2.3 : Finishing the Interior  Task 2.3.1: Interior plumbing  Task 2.3.2: Interior electrical work  Task 2.3.3: Wallboard  Task 2.3.4: Interior painting  Task 2.3.5: Floor covering  Task 2.3.6: Doors and fixtures

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

66

Activity Graph for Activity Building a House


STAR T Build Outside Wall Surveying 1.2 1.1 Excavation 1.3 Buy Materials 1.4 Lay Foundation 2.1 Build Outside Install Exterior Plumbing 2.3 Install Exterior Electrical 2.4 Install Exterior Siding 2.5 Paint Exterior 2.6 Install Exterior Doors 2.7 Install Flooring Install Roo ng 2.8 3.4 3.6 3.3 Paint Interior 3.5 Install Interior Doors 3.2 Install Wallboard 2.2 Wall

Install Interior Plumbing 3.1 Install Interior Electrical

2.6
Bernd Bruegge & Allen Dutoit

FINISH
67

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

PERT Chart Example for "Building a House"


12/3/94 12/21/94 Install Interior Plumbing 0 12 0 15 1/11/95 Install Wallboard 1/22/95 Paint Interior 0 11 1/22/95 Install Flooring 8/27/94 8/27/94 START 0 0 8/27/94 Request Permits 0 15 12/3/94 Start Time 8/29/94 Legend Slack Time Duration
Bernd Bruegge & Allen Dutoit

Building a House:
MS Project PERTcy Chart with Duration of Activities (Pfleeger 2.3)

Install Interior Electrical 0 9

2/8/95 Install Interior Doors 0 7

9/17/94 Survey ing

10/1/94 Excava tion

10/15/94 Buy Material

11/5/94 Lay Founda tion Build Outside Wall 0 20 1/19/95

0 18 Install Roofing 1/19/95

2/16/95 FINISH 0 0

12 3

0 10

0 10

0 15

12 9 1/12/95 Paint Exterior 12 5 12/17/94 12/31/94 Install Exterior Electrical 12 10 12 8 Install Exterior Siding 15 6

Install Exterior Doors

Install Exterior Plumbing 12 10

0 0

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

68

Slack Time and Critical Path


j

Slack Time
 Available Time - Estimated (Real) Time for a task or activity  Or: Latest Start Time - Earliest Start Time

Critical Path
 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 & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

69

How do you become a good project planner?


j

Establish a project plan


 Start with the plan based on your experience with the last project(s)

j j j

Keep track of activities and their duration Determine difference between planned and actual performance Make sure to do a post-mortem
 Lessons learned  Ask developers for feedback  Write a document about what could have been improved

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

70

Writing the SPMP


j j

Example full SPMPs OWL project


 http://cascade1.se.cs.cmu.edu/15-413/courseDocs/spmpF96.html

JAMES project
 http://cascade1.se.cs.cmu.edu/JAMES/J_courseDocs/SPMP/SPMP1. 0.html

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

71

Project Management Heuristics


j

Make sure to be able to revise or dump a project plan


 Complex system development is a nonlinear activity

If project goals are unclear and complex use team-based project management. In this case
 Avoid GANTT charts and PERT charts for projects with changing requirements  Dont look too far into the future

j j

Avoid micro management of details Dont be surprise if current project management tools dont work:
 They were designed for projects with clear goals and fixed organizational structures

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

72

Project Management Summary


j

Get agreement among customers, managers and teams


    Problem statement Software project management plan Project agreement Make sure agreement allows for iteration

j j j

Organization Structures SPMP Project planning


 Start with work breakdown structure (WBS)  Identify dependencies and structure: Tasks, activities, functions

Tools and Techniques


 GANTT, Dependency graph, Schedule, Critical Path Analysis  Be careful with tools in projects with a lot of change

Bernd Bruegge & Allen Dutoit

Object-Oriented Software Engineering: Conquering Complex and Changing Systems

73

You might also like