9 Project Management

Bernd Bruegge Component-Based Software Engineering 1

v 8 September 1994

2

Bernd BrueggeTechnische Universität München

Lehrstuhl für Angewandte Softwaretechnik

TUM

Lecture Notes on Project Management

14 July 1998


Odds and Ends I

v Book on CBSE Homepagew 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 gowrong. When things just can’t get worse, they will.When things appear to be going better, you haveoverlooked something.

v If project content is allowed to change freely, the rateof change will exceed the rate of progress.

v Project teams detest progress reporting because itmanifests their lack of progress.


How it should go

RequirementsAnalysis

Implementation

Design

System Testing

Delivery and Installation


How it often goes

RequirementsAnalysis

D

E

L

A

YVaporware


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, consumesresources 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 todevelop the software product.

w Companion document to requirements analysisdocument: Changes in either may imply changes in theother 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 therequirements 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 tothe client:w Documents

w Demonstrations of function

w Demonstration of nonfunctional requirements

w Demonstrations of subsystems


Project Agreement vs Problem Statement

Manager Project TeamClient(Sponsor)

Problem Statement

Project Agreement

Software ProjectManagement Plan


Project: Functions, Activities and Tasks

Project

Activity ActivityActivity

Function

Function

Activity Activity Activity

Task TaskTask Task


Functions

Function

FunctionProject

Activity

Task Task

Activity Activity

ActivityActivityActivity

TaskTask

v Activity or set of activities that span the duration of theproject


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 1058standard are called Integral processes in the IEEE 1074standard. We call them cross-development processes


Tasks

Function

FunctionProject

Activity

Task

Activity Activity

Activity Activity Activity

Task TaskTask

• Smallest unitof work subjectto management

• Small enough foradequate planningand tracking

• Large enoughto avoid micromanagement


Tasks

v Smallest unit of management accountabilityw Atomic unit of planning and tracking

w Finite duration, need resources, produce tangible result(documents, code)

v Specification of a task: Work packagew 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 criteriaw Includes the acceptance criteria for the work products

(deliverables) produced by the task.


Task Sizes

v Finding the appropriatetask size is problematicw Todo lists from previous

projects

w During initial planning atask is necessarily large

w You may not know how todecompose the probleminto tasks at first

w Each softwaredevelopment activitityidentifies more tasks andmodifies existing ones

v Tasks must bedecomposed into sizesthat allow monitoringw Work package usually

corresponds to welldefined work assignmentfor one worker for a weekor a month.

w Depends on nature ofwork and how well task isunderstood.


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 offunctions and activities.

v Action item


Action Item

v Definition: A task assigned to a person that has to bedone within a week or less

v Action itemsw 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 meetingbefore Sep 10, 12noon.

w The VIP team develops the project plan by Sep 18


Activities

Activity

Function

FunctionProject

Task

• Major unit of workwith precise dates

• Culminates in project milestone.

Task TaskTask

Activity Activity

Activity Activity Activity• Consists of smaller activities or tasks


Activities

v Major unit of work

v Culminates in majorproject milestone:w Internal checkpoint should

not be externally visible

w Scheduled event used tomeasure progress

v Milestone often producesbaseline:w formally reviewed work

product

w under change control (changerequires formal procedures)

v Activitites may begrouped into largeractivities:w Establishes hierarchical

structure for project(phase, step, ...)

w Allows separation ofconcerns

w Precedence relations oftenexist among activities(PERT Chart)


Examples of Activities

v Major Activities:wPlanning

wRequirementsAnalysis

wSystem Design

wObject Design

w Implementation

wSystem Testing

wDelivery

v Activities duringrequirements analysis:wRefine scenarios

wDefine Use Casemodel

wDefine object model

wDefine dynamicmodel

wDesign User Interface


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

v Revision sheet (update history)

v Preface: Scope and purpose

v Tables of contents, figures, tables


SPMP Part 1: Introduction

v 1.1 Project OverviewwExecutive summary: description of project, product

summary

v 1.2 Project DeliverableswAll items to be delivered, including delivery dates

and location

v 1.3 Evolution of the SPMPwPlans for anticipated and unanticipated change

v 1.4 Reference MaterialswComplete list of materials referenced in SPMP

v 1.5 Definitions and Acronyms


SPMP Part 2: Project Organization

v 2.1 Process ModelwRelationships among project elements

v 2.2 Organizational Structurew Internal management, organization chart

v 2.3 Organizational InterfaceswRelations with other entities

v 2.4 Project ResponsibilitieswMajor functions and activities; nature of each; who’s

in charge


Process Model

v Shows relationshipsamongw Functions, activities,

tasks

wMilestones

wBaselines

wReviews

wWork breakdownstructure

wProject deliverables

wSign-offs

v Visualization ofprocess model

v Project Management Aids

wMS Project (Microsoft)

wMAC Project (Claris)

wEasyTrak (PlanningControl International)


Example of an Organization Chart

Client Management Consultants

Cross-functional Teams

Logbook

Maintenance

Vehicle

Travel

VIP

Development Teams

Infrastructure Team

Architecture

HCI

Web Master

Documentation

Configuration Mgt


Clients, Managers and Consultants

ClientDieter Hege

Brigitte Pihulak

ManagementMalcolm BauerBernd Bruegge

Allen DutoitBrian CavalierSam Perman

Isabel Torres-YebraAlfonso Guerrero- Galan

Infrastructure TeamStephan Schoenig (CMU)Joyce Johnstone (CMU)Andreas Doerner (DB)

Arno Schmackpfeffer (DB)

ConsultantsKlaus EitzenbergerManfred Mueller

Juergen Bortolazzi,Claus Czymmek


Development and Cross-functional Teams

Logbook TeamAaron Wald

Herbert Stiel

Michael Poole

MichaelScheinholtz

Nathaniel Woods

Pradip Hari

Uhyon Chung

Vehicle Team Andrew Wang

HodaMoustaphaJaewoo YouOgnjenMartinovicPaul StadlerTze Bin LohWilliam Ferry

Travel Team Ann Sluzhevsky

Bin ZhouChristopherChiappaGordon ChengJohn DoeKalyana PrattipatiMichael Samuel

HCI Team Darren Mauro

Gordon ChengIdan WaismanPaul StadlerSteve SprangTze Bin LohYenni Kwek

Web Master Team

Uhyon Chang(Logbook)

Aveek Datta(Maintenance)

Tze Bin Loh(Simulation)

Kalyana Prattipati(Travel)

MaintenanceTeam

Arjun CholkarAveek DattaDarren MauroJoel SlovacekSteve SprangVincent MakYenni Kwek

VIP Team Christopher

LumbEric FarngIdan WaismanLi-Lun ChengPatrick ToolePhillip EzoltVenkateshNatarajan

ConfigurationMgt Team

Michael Poole(Logbook)

Darren Mauro(Maintenance)

William Ferry(Simulation)

Chris Chiappa(Travel)

Eric Farng (VIP)


Project Responsibilities

v Planner

v Analyst

v Designer

v Programmer

v Tester

v Maintainer

v Trainer

v Document Editor

v Web Master

v Configuration Manager

v Group leader

v Liaison

v Minute Taker

v Project Manager


Project Management: Hierarchical ProjectOrganization

Chief Executive

Team Leaders

Project Members

Basis of organization:Hierarchical information flow across corporate boundaries


Example of Hierchical Organization:Chief Programmer Team

Chief Programmer

Librarian Administration Tester

Junior Programmer

AssistantChief Programmer

Senior Programmer


Another Project Organization:Egoless Programming Team(Weinberg)

Analyst

Designer Librarian

Tester Programmer


Project-Based Project Organization

Project Leader

Team Leaders

Team Members

Basis of organization:Nonlinear information flow across dynamically formed units

Subsystem Team Subsystem Team Subsystem Team


Observations on Management Structures

v Egoless structures don't work wellw "Ownership" is important

v Hierarchical information flow does not workwell with iterative and incremental softwaredevelopment processwManager is not necessarily always right

v Project-based structureswCut down on bureaucracy reduces development time

wDecisions are expected to be made at each level

wHard 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 beindependent from the design team

wProject manager insists on a previouslysuccessful structure


Project-Based Structure

v Project with degree of uncertaintywOpen 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

• Item 1

• Item 2

• Item 3

• Item 4

• Item 5

• Item 6

• Item 7

• Item 8

• Item 9

Item 1Item 2Item 9

Role 1

Item 4Item 5Item 7

Role 2

Item 3Item 6Item 8

Role 3

Person A

Person B

Role 1

Role 2

Role 3


Possible Mappings of ToDos to People

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

v Many-to-FewwEach project member assumes several roles ("hats")

wDanger of overcommittment

wNeed for load balancing

v Many-to-"Too-Many"wSome people don't have significant roles

wBystanders

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


Project Role: Group leader

v Responsible for intra-group communication(Meeting Management: Primary Facilitator)wRun the weekly project meeting

wPost agenda before meeting

wDefine and keep track of action items (who, what,when)

wMeasure progress (Enforce milestones)

wDeliver work packages for the tasks to the projectmanagement

wPresent problems and status of team to project manager

v The group leader has to be rotated among membersof the team.


Group Leader: Create an Agenda

Action Items(Check Previous

Meeting)

Issues(Check Previous

Meeting & BBoards)

v Purpose of Meeting

v Desired Outcome

v Information Sharing

v Information Processing

v Meeting Critique


Project Role: Group Liason (Architecture, HCI)

v Responsible for inter-group communicationwMake available public definitions of subsystem

developed by the team to the architecture teams(ensure consistency, etc)

wCoordinate tasks spanning more than one groupwith other teams

v Responsible for team negotiations


Project Role: Planner

v Plans the activities of an individual team and hasthe following responsibilities.

v Define project plan for team:wPERT chart, resource table and GANTT chart showing

work packages

wEnter 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. Responsibilitiesassumed by group leaders


Project Role: Document Editor

v Collect, proofread and distribute teamdocumentation

v Submit team documentation to Architectureteam

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:

Date

9/9/96

Agenda Minutes Action Items Issues

Agenda Minutes Action Items Issues

9/16/96 Agenda Minutes Action Items Issues

v Publish Meeting Information on Team Homepage

wMust contain Agenda, minutes, action items andissues

wPossibilities:u One HTML document per meeting, with anchors

(maintained by one role)

u Separate HTML documents for Agenda, Minutes, etc(maintained by several roles)


SPMP Part 3: Managerial Processes

v 3.1 Management Objectives and Prioritiesw Philosophy, goals and priorities

v 3.2 Assumptions, Dependencies, Constraintsw External factors

v 3.3 Risk Managementw Identifying, assessing, tracking, contingencies for risks

v 3.4 Monitoring and Controlling Mechanismsw 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 forthe project

v A demonstration of the X system will be given by theclient

v The CAD Model of the seat will be made available by theclient


Examples of Dependencies

v The VIP team depends on the vehicle subsystemprovided by the vehicle team

v The automatice code generation facility in the CASE toolRose/Java depends on JDK. The current release ofRose/Java supports only JDK 1.0.2


Examples of Constraints

v The length of the project is 3 months. limited amount oftime to build the system

v The project consists of beginners. It will take time tolearn how to use the tools

v Not every project member is always up-to-date withrespect 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 keyroles drop the course.w Contingency: Roles are

assigned to somebody else.Functionality of the systemis renegotiated with theclient.

v Risk: The project isfalling behind schedule.w Contingency: Extra project

meetings are scheduled.

v Risk: One subsystemdoes not provide thefunctionality needed byanother subsystem.w Contingency: ?

v Risk: Rose will notsupport JDK 1.1w Contingency: ?


SPMP Part 4: Technical Process

v 4.1 Methods, Tools and Techniquesw Computing system, development method, team structure, etc.

w Standards, guidelines, policies.

v 4.2 Software Documentationw Documentation plan, including milestones, reviews and

baselines.

v 4.3 Project Support Functionsw 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 Dependenciesw Precedence relations among functions, activities and tasks

v 5.3 Resource Requirementsw Estimates for resources such as personnel, computer time,

special hardware, support software.

v 5.4 Budget and Resource Allocationw Connect costs to functions, activities and tasks.

v 5.5 Schedulew 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 interdependenceof 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 percentageof 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 isincremental and iterative

WBS Schedule

Cost (Time, $$)

Source: Software Engineering Economics, Barry W. Boehmp. 47, Prentice Hall, N.J., 1981


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 Presentationw Graphs (Schedule), Trees (WBS)

w Tables (Resources)

v Task Timelinew Gantt Charts: Shows project activities and tasks in parallel.

Enables the project manager to understand which tasks can beperformed concurrently.

v Schedule Chart (PERT Chart)w Cornerstone in many project management tools

w Graphically shows dependencies of tasks and milestonesu 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 theexterior

w Task 2.2.1: Foundation

w Task 2.2.2: Outside Walls

w Task 2.2.3: Exteriorplumbing

w Task 2.2.4: Exteriorelectrical work

w Task 2.2.5: Exterior siding

w Task 2.2.6: Exteror painting

w Task 2.2.7: Doors andFixtures

w Task 2.2.8: Roof

v Activity 2.3 : Finishing theInterior

w Task 2.3.1: Interiorplumbing

w Task 2.3.2: Interiorelectrical work

w Task 2.3.3: Wallboard

w Task 2.3.4: Interiorpainting

w Task 2.3.5: Floor covering

w Task 2.3.6: Doors andfixtures


Activity Graph for Activity “Building a House”

1.11.2

1.4

1.3

2.1

2.2

3.1

3.2

3.3

3.4

2.3

2.4

2.5

2.6

2.82.7

3.5

3.6

2.6

Install Exterior Plumbing Install Interior Plumbing

Build Outside Wall

Lay Foundation

Buy Materials

Excavation

SurveyingBuild Outside Wall

START

Install Exterior Electrical

Install Exterior Siding

Paint Exterior

Install Exterior Doors Install Roofing

Install Interior Electrical

Install Wallboard

Install Flooring Paint Interior

Install Interior Doors

FINISH


PERT Chart Example for "Building a House"

Start Time

Slack Time

MS Project PERTcy Chart with Duration of Activities (Pfleeger 2.3)

Duration

Building a House:

START

8/27/94

00

Request Permits

8/27/94

150

Surveying

8/27/94

312

Excavation

9/17/94

100

Legend

8/29/94

00

Buy Material

10/1/94

100

Lay Foundation

10/15/94

150

Build Outside

Wall

11/5/94

200

Install Exterior Plumbing

12/3/94

1012

Install Interior Plumbing

12/3/94

120

Install Exterior Electrical

12/17/94

1012

Install Interior

Electrical

12/21/94

150

Install Exterior

Siding

12/31/94

812

Install Wallboard

1/11/95

90

Paint Exterior

1/12/95

512

Install Roofing

1/19/95

912

InstallFlooring

1/22/95

180

Paint Interior

1/22/95

110

Install Interior

Doors

2/8/95

70

Install Exterior

Doors

1/19/95

615

FINISH

2/16/95

00


Slack Time and Critical Path

v Slack Timew Available Time - Estimated (“Real”) Time for a task or activity

w Or: Latest Start Time - Earliest Start Time

v Critical Pathw 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 performingthe tasks (activities) along its route.


How do you become a good project planner?

v Establish a project planw 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 actualperformance

v Make sure to do a post-mortemw 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 projectw 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 planw Complex system development is a nonlinear activity

v If project goals are unclear and complex use team-basedproject management. In this casew 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 toolsdon’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 teamsw Problem statement

w Software project management plan

w Project agreement

w Make sure agreement allows for iteration

v Team Structures

v Project planningw Start with work breakdown structure (WBS)

w Identify dependencies and structure: Tasks, activities, functions

v Tools and Techniquesw 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 workfloww Example: Distributed Document Review with Lotus Notes


A Communication Example

v "Two missile electrical boxes manufactured bydifferent contractors were joined together by a pair ofwires.

Pair of WiresBox 1 Box 2


A Communication Example ctd

v Thanks to a particular thorough preflight check, it wasdiscovered that the wires had been reversed."

Box 1 Box 2


After the Crash...

v ...

v "The postflight analysis revealed that the contractorshad 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

wEvent Driven:Unplanned Communication

v Communication MechanismTool or procedure that can be used to transmit or

receive information

w Synchronous: Sender and Receiver are available at thesame time

wAsynchronous: Sender and Receiver are notcommunicating at the same time.


Classification of Communication

Communication mode

Scheduled Event driven

Client review Problem reporting

Communication mechanism

Synchronous Asynchronous

Smoke signals Fax

supports

is supported by


Scheduled Modes of Communication

v Problem DefinitionwObjective: Present Goals & Requirements

(Functional, Nonfunctional) and Constraintsu Problem Statement Presentation (JAMES Example: August 26, 97)

v Project Review: Focus on System ModelwObjective: Assess status and review subsystem

interfacesu Analysis Review (October 16, 1997)

u Object Design Review (November 11 & 13, 1997)

u Implementation Review (November 25, 1997)

v Client Review: Focus on RequirementswObjective: Brief Client of Progress, Confirm Changes

in Requirementsu System Design Review (October 23, 1997)



v Walkthrough (Informal)wObjective: Increase quality of subsystem

wDeveloper presents to team members Informal, peer-to-peer

u To be scheduled by each team

v Inspection (Formal)

wObjective: Compliance with (functional andnonfunctional) requirements

wDeveloper answers questions from the reviewersu Client Acceptance Test (December 9, 1997)



v Status Review:w Objective: Find deviations from schedule and

correct them or identify new issues

wPart of every team meeting (Status)

v Brainstorming:

wObjective: Generate and evaluate large number ofsolutions for a problem

wPart of every team meeting (Discussion)


Meeting as Scheduled and SynchronousCommunication

Action Items(From previous

meeting)

Issues(From previousmeetings and

BBoards)

v Purpose of Meetingw Why do we meet?

v Desired Outcomew What do we want to achieve?

v Information Sharingw Action Items

v Information Processingw Open Issues

v Meeting Critique



v ReleasewThe 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 ReviewwObjective: 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 conversationw Unplanned face-to-face meeting

v Questionaire and structured interviews

v Meetingw Planned Face-to-Face Meeting, Telephone conversation

v Groupwarew 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 ofDocumentsDatabase


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


Reviewersadd theirComments


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