9 Project Management

v 8 September 1994
TUM
Lecture Notes on
Project Management
Bernd Bruegge
Technische Universität München
Lehrstuhl für Angewandte Softwaretechnik
14 July 1998
Bernd Bruegge Component-Based Software Engineering 12

Odds and Ends I
v 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 Management

Odds and Ends II
v 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 5
v Lecture next Tuesday:
w Software Lifecycle
u Reading: Bruegge-Dutoit Ch 3

Outline of Lecture
v Concepts and terminology

v Purpose of Software Project Management Plans
v Structure of a Project Management Plan
v Project responsibilities
v Team structures
v Project planning
v Work breakdown structure
v Communication Management
v Dependencies
v Schedule
v Project Management Tools

Laws of Project Management
v 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.

How it should go
Requirements
Analysis
Design
Implementation
System Testing
Delivery and Installation

How it often goes
Requirements
Analysis
D
E
L
A
Y
Vaporware

Software Project Management Plan
v 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, Functions
v 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.
Project Agreement
v 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 subsystems

Project Agreement vs Problem Statement
Client Manager Project Team

(Sponsor)
Problem
Statement Software Project
Management Plan
Project
Agreement

Project: Functions, Activities and Tasks
Function
Project
Function
Activity Activity Activity
Task Task Task Task

Functions
v Activity or set of activities that span the duration of the
project
Function
Project
Function
Task Task Task Task

Functions
v Examples:
w Project management
w Configuration Management
w Documentation
w Quality Control (Verification and validation)
w Training
v 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 processes

Tasks
Function
Project
Function
• Smallest unit
Activity Activity Activity of work subject
to management
• Small enough for
adequate planning
Task Task Task Task
and tracking
• Large enough
to avoid micro
management
Tasks
v 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 involved
v Completion criteria
w Includes the acceptance criteria for the work products
(deliverables) produced by the task.

Task Sizes
v 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 ones

Examples of Tasks
v Unit test class “Foo”

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

Action Item
v Definition: A task assigned to a person that has to be

done within a week or less
v 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 18

Activities
Function
Project
Function
Activity Activity Activity • Major unit of work

with precise dates
• Consists of smaller
activities or tasks
Task Task Task Task
• Culminates in project
milestone.
Activities
v Major unit of work v Activitites may be

v 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
concerns
v 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)

Examples of Activities
v 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 Delivery

Structure of a Software Project Management Plan
v 0. Front Matter
v 1. Introduction
v 2. Project Organization
v 3. Managerial Process
v 4. Technical Process
v 5. Work Elements, Schedule, Budget
v Optional Inclusions

SPMP Part 0: Front Matter
v TitlePage
v Revision sheet (update history)
v Preface: Scope and purpose
v Tables of contents, figures, tables

SPMP Part 1: Introduction
v 1.1 Project Overview

w Executive summary: description of project, product
summary
v 1.2 Project Deliverables
w All items to be delivered, including delivery dates
and location
v 1.3 Evolution of the SPMP
w Plans for anticipated and unanticipated change
v 1.4 Reference Materials
w Complete list of materials referenced in SPMP
v 1.5 Definitions and Acronyms
SPMP Part 2: Project Organization
v 2.1 Process Model

w Relationships among project elements
v 2.2 Organizational Structure
w Internal management, organization chart
v 2.3 Organizational Interfaces
w Relations with other entities
v 2.4 Project Responsibilities
w Major functions and activities; nature of each; who’s
in charge

Process Model
v 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-offs

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 Team

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)

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 Ferry
VIP 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)
Project Responsibilities
v Planner v Group leader

v Analyst v Liaison
v Designer v Minute Taker
v Programmer v Project Manager
v Tester
v Maintainer
v Trainer
v Document Editor
v Web Master
v Configuration Manager

Project Management: Hierarchical Project
Organization
Chief Executive
Team Leaders
Project Members
Basis of organization:
Hierarchical information flow across corporate boundaries

Example of Hierchical Organization:
Chief Programmer Team
Chief Programmer
Assistant
Chief Programmer
Senior Programmer Librarian Administration Tester
Junior Programmer

Another Project Organization:
Egoless Programming Team(Weinberg)
Analyst
Tester Programmer
Designer Librarian

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 units
Observations on Management Structures
v Egoless structures don't work well
w "Ownership" is important
v Hierarchical information flow does not work

well with iterative and incremental software
development process
w Manager is not necessarily always right
v Project-based structures
w Cut down on bureaucracy reduces development time
w Decisions are expected to be made at each level
w Hard to manage

Hierarchical Structure
v Projects with high degree of certainty,

stability, uniformity and repetition.
wRequires little communication
wRole definitions are clear
v 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 structure
Project-Based Structure
v Project with degree of uncertainty

wOpen communication needed among
members
wRoles are defined on project basis
v When?
wRequirements change during development
wNew technology develops during project

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 8

Possible Mappings of ToDos to People
v One-to-One
w Ideal but often not worth to be called a project
v Many-to-Few
w Each project member assumes several roles ("hats")
w Danger of overcommittment
w Need for load balancing
v Many-to-"Too-Many"
w Some people don't have significant roles
w Bystanders
w Loosing touch with project

Project Roles: Coach
v Listen to gripes from individual teams

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

Project Role: Group leader
v 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 manager
v The group leader has to be rotated among members
of the team.
Group Leader: Create an Agenda
v Purpose of Meeting
v Desired Outcome
v Information Sharing
v Information Processing
v Meeting Critique
Action Items
(Check Previous
Meeting)
Issues
(Check Previous
Meeting & BBoards)

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 teams
v Responsible for team negotiations

Project Role: Planner
v 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 Project
v Make project plan available to management
v Report group project status to group leader
No explicit planner in JAMES. Responsibilities

assumed by group leaders

Project Role: Document Editor
v Collect,proofread and distribute team

documentation
v Submit team documentation to Architecture
team
v Collect agendas
v Take Minutes at meetings

Web Master
v Maintain team home page

v Keep track of meeting history
v Keep track of design rationale

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 Issues

SPMP Part 3: Managerial Processes
v 3.1 Management Objectives and Priorities

w Philosophy, goals and priorities
v 3.2 Assumptions, Dependencies, Constraints
w External factors
v 3.3 Risk Management
w Identifying, assessing, tracking, contingencies for risks
v 3.4 Monitoring and Controlling Mechanisms
w Reporting mechanisms and formats, information flows,
reviews
v 3.5 Staffing Plan
v Needed skills (what?, how much?, when?)

Examples of Assumptions
v There are enough cycles on the development machines
v Security will not be addressed
v There are no bugs in the CASE Tool recommended for
the project
v A demonstration of the X system will be given by the
client
v The CAD Model of the seat will be made available by the
client

Examples of Dependencies
v The VIP team depends on the vehicle subsystem

provided by the vehicle team
v 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.2

Examples of Constraints
v The length of the project is 3 months. limited amount of

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

Risk Management
v 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 not
v Risk: The project is support JDK 1.1
falling behind schedule. w Contingency: ?
w Contingency: Extra project
meetings are scheduled.

SPMP Part 4: Technical Process
v 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).

SPMP Part 5: Work Elements
v 5.1 Work Packages (Work breakdown structure)

w Project decomposed into tasks; definitions of tasks
v 5.2 Dependencies
w Precedence relations among functions, activities and tasks
v 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 milestones

Creating Work Packages
v 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 tasks
v WBS identification is an instance of object identification

WBS Trade-offs
v Work breakdown structure influences cost and schedule

v 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 PMs
v 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, $$)

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 dependencies
v Estimate the duration of each task
v Label dependency graph with the estimates

Project Management Tools for Work Packages
v 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 Method

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 Acceptance

Project: Building a House
v 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 trees
v Activity 2: Building the House
w Activity 2.1 : Site preparation
w Activity 2.2: Building the exterior
w Activity 2.3: Finishing the interior
v Activity 2.1 : Site preparation
w Task 2.1.1: Surveying
w Task 2.1.2: Obtaining permits
w Task 2.1.3: Excavating
v Task 2.1.4: Obtaining materials

Activity 2: Building a House, ctd
v 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: Roof

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

Slack Time and Critical Path
v Slack Time
w Available Time - Estimated (“Real”) Time for a task or activity
w Or: Latest Start Time - Earliest Start Time
v 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.

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 duration
v Determine difference between planned and actual
performance
v Make sure to do a post-mortem
w Lessons learned
w Ask developers for feedback
w Write a document about what could have been improved

Writing the SPMP
v Example of a full SPMP for the OWL project

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

Project Management Heuristics
v Make sure to be able to revise or dump a project plan

w Complex system development is a nonlinear activity
v 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 future
v Avoid micro management of details
v Don’t be surprise if current project management tools
don’t work:
w They were designed for projects with clear goals and fixed
organizational structures

Project Management Summary
v Get agreement among customers, managers and teams

w Problem statement
w Software project management plan
w Project agreement
w Make sure agreement allows for iteration
v Team Structures
v Project planning
w Start with work breakdown structure (WBS)
w Identify dependencies and structure: Tasks, activities, functions
v Tools and Techniques
w GANTT, Dependency graph, Schedule, Critical Path Analysis

Communication Management
v Communication in distributed Teams

v Communication Modes
v Communication Mechanisms
v Scheduled Communications
v Communication workflow
w Example: Distributed Document Review with Lotus Notes

A Communication Example
v "Two missile electrical boxes manufactured by

different contractors were joined together by a pair of
wires.
Box 1 Pair of Wires Box 2

A Communication Example ctd
v Thanks to a particular thorough preflight check, it was

discovered that the wires had been reversed."
Box 1 Box 2

After the Crash...
v ...
v "The postflight analysis revealed that the contractors
had indeed corrected the reversed wires as instructed."

“In fact, both of them had.”
Box 1 Box 2

Communication is Important
v Communication Mode:
Type of information exchange that has defined
objectives and scope
w Scheduled: Planned Communication
w Event Driven:Unplanned Communication
v 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.
Classification of Communication
Communication supports Communication

mode is supported by mechanism
Scheduled Event driven Synchronous Asynchronous
Client review Problem reporting Smoke signals Fax

Scheduled Modes of Communication
v 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)
v Walkthrough (Informal)
w Objective: Increase quality of subsystem
w Developer presents to team members Informal, peer-
to-peer
u To be scheduled by each team
v Inspection (Formal)
w Objective: Compliance with (functional and
nonfunctional) requirements
w Developer answers questions from the reviewers
u Client Acceptance Test (December 9, 1997)

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

Meeting as Scheduled and Synchronous
Communication
v Purpose of Meeting
w Why do we meet?
v Desired Outcome
w What do we want to achieve?
v Information Sharing
w Action Items
v Information Processing
w Open Issues
Action Items
v Meeting Critique (From previous
meeting)
Issues
(From previous
meetings and
BBoards)
v 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 Manual
v Postmortem Review
w Objective: Describe Lessons Learned
u Final Homework (December 16, 1997)

Event-Driven Modes of Communication
v Request for Clarification

v Change Request
v Resolution of Issue

Synchronous Communication Mechanisms
v Hallway conversation
w Unplanned face-to-face meeting
v Questionaire and structured interviews
v Meeting
w Planned Face-to-Face Meeting, Telephone conversation
v Groupware
w Same time, different location groupware

Asynchronous Communication Mechanisms
v E-Mail
v Newsgroups
v Web
v Lotus Notes

Example of Asynchronous Documentation:
Document Review
v Fill out a review form

v Attach document to be reviewed
v Distribute the review form to reviewers
v Wait for comments from reviewers
v Review comments
v Create action items from selected comments
v Revise document and post the revised version
v Iterate the review cycle
Example:
w “Review of Documents” Database in JAMES Project

Review of
Documents
Database

NewReview Form

Fill out the Review Form
v Select reviewers
v Select the document to be reviewed
v Add comments to reviewers
v Determine deadline

Reviewer Notification
v Selected reviewers get e-mail

Status of Document Review

Reviewers
add their
Comments

Originator Notification

Final Recipient Notification

Document Editor & Web Master Tasks
v Editor reviews comments

v Editor selects reviewed comments
v Web Master posts reviewed document and action items
v Team members complete their action items
v Editor integrates changes
v Editor posts changed document on the review database
for the next review cycle

Accepted Document w/ Action Items

SPMP Action Items

Summary
v Communication Modes vs Communication Mechanisms

v Scheduled Communications
v Asynchronous Communications
v Team review of documents with Lotus Notes

9 Project Management

Uploaded by

Copyright:

Available Formats

9 Project Management

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9 Project Management

Uploaded by

Copyright:

Available Formats

v 8 September 1994

Bernd Bruegge Component-Based Software Engineering 12

v Book on CBSE Homepage

Bernd Bruegge Component-Based Software Engineering 2

Bernd Bruegge Component-Based Software Engineering 3

v Concepts and terminology

Bernd Bruegge Component-Based Software Engineering 4

v When things are going well, something will go

v If project content is allowed to change freely, the rate

v Project teams detest progress reporting because it

Bernd Bruegge Component-Based Software Engineering 5

Delivery and Installation

Bernd Bruegge Component-Based Software Engineering 6

Bernd Bruegge Component-Based Software Engineering 7

v Software Project Management Plan:

Bernd Bruegge Component-Based Software Engineering 9

Client Manager Project Team

Bernd Bruegge Component-Based Software Engineering 10

Activity Activity Activity

Activity Activity Activity

Task Task Task Task

Bernd Bruegge Component-Based Software Engineering 11

Activity Activity Activity

Activity Activity Activity

Task Task Task Task

Bernd Bruegge Component-Based Software Engineering 12

v Question: Is system integration a project function?

v Mapping of terms: Project Functions in the IEEE 1058

Bernd Bruegge Component-Based Software Engineering 13

Bernd Bruegge Component-Based Software Engineering 15

v Finding the appropriate v Tasks must be

Bernd Bruegge Component-Based Software Engineering 16

v Unit test class “Foo”

Bernd Bruegge Component-Based Software Engineering 17

v Definition: A task assigned to a person that has to be

Bernd Bruegge Component-Based Software Engineering 18

Activity Activity Activity • Major unit of work

v Major unit of work v Activitites may be

Bernd Bruegge Component-Based Software Engineering 20

v Major Activities: v Activities during

Bernd Bruegge Component-Based Software Engineering 21

Bernd Bruegge Component-Based Software Engineering 22

Bernd Bruegge Component-Based Software Engineering 23

v 1.1 Project Overview

v 2.1 Process Model

Bernd Bruegge Component-Based Software Engineering 25

v Shows relationships v Visualization of

Bernd Bruegge Component-Based Software Engineering 26

Client Management Consultants

Cross-functional Teams Development Teams

Configuration Mgt Travel

Bernd Bruegge Component-Based Software Engineering 27

Bernd Bruegge Component-Based Software Engineering 28

VIP Team HCI Team Web Master Team Configuration

v Planner v Group leader

Bernd Bruegge Component-Based Software Engineering 30

Bernd Bruegge Component-Based Software Engineering 31

Senior Programmer Librarian Administration Tester

Bernd Bruegge Component-Based Software Engineering 32

Bernd Bruegge Component-Based Software Engineering 33