Lecture Notes On Project-Management

v
8 September 1994
TUM
Lecture Notes on Project Management

Bernd Bruegge
Technische Universitt Mnchen Lehrstuhl fr 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 u u u u u
Chapter 1, Introduction Chapter 3, Software Lifecycle Chapter 5, Project Communication Chapter 6, Requirements Elicitation Chapter 7, Requirements Analysis Chapter 9, Design Rationale Chapter 8 System Design Chapter 4 Project Management
w Chapters available on August 15:

u u
Bernd Bruegge
Odds and Ends II

v
Lecture Today:
w Finish System Design w Project Management (No reading available yet)
Lecture on Wednesday:
w Communication & Meeting Management
u
Reading: Bruegge-Dutoit Ch 5
Lecture next Tuesday:

w Software Lifecycle
u
Reading: Bruegge-Dutoit Ch 3
Bernd Bruegge
Outline of Lecture
v v v v v v v v v v v
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
Component-Based Software Engineering 4
Bernd Bruegge
Laws of Project Management

v
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
How it should go
Requirements Analysis Design
Implementation
System Testing
Delivery and Installation
Bernd Bruegge
How it often goes

Requirements Analysis
D E L A Y Vaporware
7
Bernd Bruegge
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
Software Project Management Plan:

w The controlling document for a software project. w Specifies the technical and managerial approaches to develop the software product. w Companion document to requirements analysis document: Changes in either may imply changes in the other document. w SPMP may be part of project agreement.
Bernd Bruegge
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 v v
Client: Individual or organization that specifies the requirements and accepts the project deliverables. Can be a contract, a statement of work, a business plan, or a project charter. Deliverables (= Work Products that will be delivered to the client:
w w w w Documents Demonstrations of function Demonstration of nonfunctional requirements Demonstrations of subsystems
Bernd Bruegge
Project Agreement vs Problem Statement

Client (Sponsor) Manager Project Team
Problem Statement Project Agreement

Bernd Bruegge
Software Project Management Plan
10
Project: Functions, Activities and Tasks
Function Project Function
Activity Activity Task
Activity Activity Task Task
Activity Activity Task
Bernd Bruegge
11
Functions
v
Activity or set of activities that span the duration of the project

Activity
Activity
Activity
Activity Activity Activity Task Task Task Task

Bernd Bruegge Component-Based Software Engineering 12
Functions
v
Examples:
w w w w w Project management Configuration Management Documentation Quality Control (Verification and validation) Training
v v
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
13
Tasks
Function Project Function Smallest unit of work subject to management Small enough for adequate planning and tracking Large enough to avoid micro management
Activity
Activity
Activity Activity
Activity Activity
Task Task Task Task
Tasks
v
Smallest unit of management accountability

w Atomic unit of planning and tracking w Finite duration, need resources, produce tangible result (documents, code)
Specification of a task: Work package

w w w w 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
w Includes the acceptance criteria for the work products (deliverables) produced by the task.
Bernd Bruegge
15
Task Sizes
v
Finding the appropriate task size is problematic

w Todo lists from previous projects w During initial planning a task is necessarily large w You may not know how to decompose the problem into tasks at first w Each software development activitity identifies more tasks and modifies existing ones
Tasks must be decomposed into sizes that allow monitoring

w Work package usually corresponds to well defined work assignment for one worker for a week or a month. w Depends on nature of work and how well task is understood.
Bernd Bruegge
16
Examples of Tasks
v v v v v v v v v
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
17
Action Item
v v
Definition: A task assigned to a person that has to be done within a week or less Action items
w Appear on the agenda in the Status Section (See lecture on communication) w Cover: What?, Who?, When?
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
Bernd Bruegge
18
Activities
Activity
Activity
Activity
Major unit of work with precise dates Consists of smaller activities or tasks Culminates in project milestone.
Activity Activity Activity Task Task Task Task
Bernd Bruegge
19
Activities
v v
Major unit of work Culminates in major project milestone:

w Internal checkpoint should not be externally visible w Scheduled event used to measure progress
Activitites may be grouped into larger activities:

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

w formally reviewed work product w under change control (change requires formal procedures)
Bernd Bruegge
20
Examples of Activities
v Major
Activities:
v Activities
w Planning w Requirements Analysis w System Design w Object Design w Implementation w System Testing w Delivery
during requirements analysis:

w Refine scenarios w Define Use Case model w Define object model w Define dynamic model w Design User Interface
Bernd Bruegge
21
Structure of a Software Project Management Plan

v v v v v v v
0. Front Matter 1. Introduction 2. Project Organization 3. Managerial Process 4. Technical Process 5. Work Elements, Schedule, Budget Optional Inclusions
Bernd Bruegge
22
SPMP Part 0: Front Matter

v Title
Page v Revision sheet (update history) v Preface: Scope and purpose v Tables of contents, figures, tables
Bernd Bruegge
23
SPMP Part 1: Introduction

v 1.1
Project Overview Project Deliverables Evolution of the SPMP Reference Materials Definitions and Acronyms
w Executive summary: description of project, product summary

v 1.2
w All items to be delivered, including delivery dates and location

v 1.3 v 1.4 v 1.5
Bernd Bruegge
w Plans for anticipated and unanticipated change w Complete list of materials referenced in SPMP
SPMP Part 2: Project Organization

v 2.1 v 2.2 v 2.3 v 2.4
Process Model Organizational Structure Organizational Interfaces Project Responsibilities
w Relationships among project elements w Internal management, organization chart w Relations with other entities w Major functions and activities; nature of each; whos in charge
Bernd Bruegge
25
Process Model
v Shows
among
relationships
v Visualization
v
of process model
Project Management Aids w MS Project (Microsoft) w MAC Project (Claris) w EasyTrak (Planning Control International)
w Functions, activities, tasks w Milestones w Baselines w Reviews w Work breakdown structure w Project deliverables w Sign-offs
Bernd Bruegge
26
Example of an Organization Chart
Client
Management
Consultants
Cross-functional Teams
Development Teams
Architecture HCI Web Master Documentation Configuration Mgt
Logbook Maintenance Vehicle Travel VIP
Infrastructure Team
Bernd Bruegge
27
Clients, Managers and Consultants

Management Malcolm Bauer Bernd Bruegge Allen Dutoit Brian Cavalier Sam Perman Isabel Torres-Yebra Alfonso Guerrero- Galan
Client Dieter Hege Brigitte Pihulak
Consultants Klaus Eitzenberger Manfred Mueller Juergen Bortolazzi, Claus Czymmek
Infrastructure Team Stephan Schoenig (CMU) Joyce Johnstone (CMU) Andreas Doerner (DB) Arno Schmackpfeffer (DB)
Bernd Bruegge
28
Development and Cross-functional Teams

Logbook Team
Aaron Wald Herbert Stiel Michael Poole MichaelScheinholtz Nathaniel Woods Pradip Hari Uhyon Chung
Maintenance Team
Arjun Cholkar Aveek Datta Darren Mauro Joel Slovacek Steve Sprang Vincent Mak Yenni Kwek
Vehicle Team
Andrew Wang Hoda Moustapha Jaewoo You Ognjen Martinovic Paul Stadler Tze Bin Loh William Ferry
Travel Team
Ann Sluzhevsky Bin Zhou Christopher Chiappa Gordon Cheng John Doe Kalyana Prattipati Michael Samuel
VIP Team
Christopher Lumb Eric Farng Idan Waisman Li-Lun Cheng Patrick Toole Phillip Ezolt Venkatesh Natarajan
HCI Team
Darren Mauro Gordon Cheng Idan Waisman Paul Stadler Steve Sprang Tze Bin Loh Yenni Kwek
Web Master Team

Uhyon Chang (Logbook) Aveek Datta (Maintenance) Tze Bin Loh (Simulation) Kalyana Prattipati (Travel)
Configuration Mgt Team

Michael Poole (Logbook) Darren Mauro (Maintenance) William Ferry (Simulation) Chris Chiappa (Travel) Eric Farng (VIP)
29
Bernd Bruegge
Project Responsibilities
v v v v v v v v v v
Planner Analyst Designer Programmer Tester Maintainer Trainer Document Editor Web Master Configuration Manager
v v v v
Group leader Liaison Minute Taker Project Manager
Bernd Bruegge
30
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
Bernd Bruegge
32
Another Project Organization: Egoless Programming Team(Weinberg)

Analyst
Tester
Programmer
Designer
Librarian
Bernd Bruegge
33
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.

w Requires little communication w Role definitions are clear
v When?
w The more people on the project, the more need for a formal structure w Customer might insist that the test team be independent from the design team w Project manager insists on a previously successful structure
Project-Based Structure
v Project
with degree of uncertainty
w Open communication needed among members w Roles are defined on project basis
v When?
w Requirements change during development w New technology develops during project
Bernd Bruegge
37
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 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
38
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
Bernd Bruegge
40
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.

Bernd Bruegge
Group Leader: Create an Agenda

v v v v v
Purpose of Meeting Desired Outcome Information Sharing Information Processing 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
Bernd Bruegge
43
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
Bernd Bruegge
45
Web Master
v Maintain
team home page v Keep track of meeting history v Keep track of design rationale
Bernd Bruegge
46
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) Separate HTML documents for Agenda, Minutes, etc (maintained by several roles)
Agenda Agenda Minutes Minutes Action Items Action Items Issues
Date 9/9/96
Issues
9/16/96
Agenda
Minutes
Action Items
Issues
47
Bernd Bruegge
SPMP Part 3: Managerial Processes

v
3.1 Management Objectives and Priorities

w Philosophy, goals and priorities
3.2 Assumptions, Dependencies, Constraints

w External factors
3.3 Risk Management

w Identifying, assessing, tracking, contingencies for risks
3.4 Monitoring and Controlling Mechanisms

w Reporting mechanisms and formats, information flows, reviews
v v
3.5 Staffing Plan Needed skills (what?, how much?, when?)
Bernd Bruegge
48
Examples of Assumptions
v v v v v
There are enough cycles on the development machines Security will not be addressed There are no bugs in the CASE Tool recommended for the project A demonstration of the X system will be given by the client The CAD Model of the seat will be made available by the client
Bernd Bruegge
49
Examples of Dependencies
v
The VIP team depends on the vehicle subsystem provided by the vehicle team 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
Bernd Bruegge
50
Examples of Constraints
v v v v v v
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
Bernd Bruegge
51
Risk Management
v
Risk: Members in key roles drop the course.

w 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.
w Contingency: ?
v v
Risk: The project is falling behind schedule.

w Contingency: Extra project meetings are scheduled.
Risk: Rose will not support JDK 1.1

w Contingency: ?
Bernd Bruegge
52
SPMP Part 4: Technical Process

v
4.1 Methods, Tools and Techniques

w Computing system, development method, team structure, etc. w Standards, guidelines, policies.
4.2 Software Documentation

w Documentation plan, including milestones, reviews and baselines.
4.3 Project Support Functions

w Plans for functions (quality assurance, configuration management).
Bernd Bruegge
53
SPMP Part 5: Work Elements

v
5.1 Work Packages (Work breakdown structure)

w Project decomposed into tasks; definitions of tasks
5.2 Dependencies
w Precedence relations among functions, activities and tasks
5.3 Resource Requirements

w Estimates for resources such as personnel, computer time, special hardware, support software.
5.4 Budget and Resource Allocation

w Connect costs to functions, activities and tasks.
5.5 Schedule
w Deadlines, accounting for dependencies, required milestones
Bernd Bruegge
54
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
WBS identification is an instance of object identification
Bernd Bruegge
55
WBS Trade-offs
v v
Work breakdown structure influences cost and schedule 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
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
56
Dependencies and Schedule (Section 5.2 + 5.5)

v v
An important temporal relation: must be preceded by Dependency graphs show dependencies of the tasks (hiercharchical and temporal)
w Activity Graph:
u u
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
w Schedule Chart (MS-Project):

u u
v v
Estimate the duration of each task Label dependency graph with the estimates
Bernd Bruegge
57
Project Management Tools for Work Packages

v
Visualization Aids for Project Presentation

w Graphs (Schedule), Trees (WBS) w Tables (Resources)
Task Timeline
w 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)

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 CPM: Critical Path Method
Bernd Bruegge
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
Bernd Bruegge
59
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 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 Activity 2.1 : Site preparation w Task 2.1.1: Surveying w Task 2.1.2: Obtaining permits w Task 2.1.3: Excavating Task 2.1.4: Obtaining materials
Bernd Bruegge
Activity 2: Building a House, ctd

v
Activity 2.2: Building the exterior w Task 2.2.1: Foundation w Task 2.2.2: Outside Walls w Task 2.2.3: Exterior plumbing w Task 2.2.4: Exterior electrical work w Task 2.2.5: Exterior siding w Task 2.2.6: Exteror painting w Task 2.2.7: Doors and Fixtures w Task 2.2.8: Roof
Activity 2.3 : Finishing the Interior w Task 2.3.1: Interior plumbing w Task 2.3.2: Interior electrical work w Task 2.3.3: Wallboard w Task 2.3.4: Interior painting w Task 2.3.5: Floor covering w Task 2.3.6: Doors and fixtures
Bernd Bruegge
61
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.3 Install Exterior Electrical 2.4 Install Exterior Siding 2.5 Paint Exterior 2.6 Install Exterior Doors 2.7 2.2 Install Interior Plumbing 3.1 Install Interior Electrical 3.2 Install Wallboard 3.3 Paint Interior Install Flooring 3.5 3.4 Install Roong Install Interior Doors 2.8 3.6
2.6
Bernd Bruegge
FINISH
62
PERT Chart Example for "Building a House"

12/3/94 12/21/94 1/11/95 Install Wallboard 0 9 1/22/95 Paint Interior 0 11 1/22/95 2/8/95 Install Interior Doors 0 7 2/16/95 FINISH 1/19/95 0 Install 0 Exterior Doors 15 6
Building a House:
MS Project PERTcy Chart with Duration of Activities (Pfleeger 2.3)
0 12
Install Interior Plumbing 0 15
Install Interior Electrical
Install Flooring 8/27/94 8/27/94 9/17/94 START 0 0 Survey ing 12 3 8/27/94 Request Permits 0 15 12/3/94 Start Time 8/29/94 Legend Slack Time Duration
Bernd Bruegge
10/1/94
10/15/94
11/5/94 Build Outside Wall 0 20 1/19/95
Excava tion 0 10
Buy Material 0 10
Lay Founda tion 0 15
0 18
Install Roofing 12 9 1/12/95 Paint Exterior 12 5
12/17/94
12/31/94 Install Exterior Siding 12 8

63
Install Exterior Plumbing 12 10
Install Exterior Electrical 12 10
0 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
Critical Path
w The path in a project plan for which the slack time at each task is zero.
The critical path has no margin for error when performing the tasks (activities) along its route.
Bernd Bruegge
64
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 v v
Keep track of activities and their duration Determine difference between planned and actual performance 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
Bernd Bruegge
65
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
Bernd Bruegge
66
Project Management Heuristics

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

w Complex system development is a nonlinear activity
If project goals are unclear and complex use team-based project management. In this case
w Avoid perfect GANTT charts and PERT charts w Dont look too far into the future
v v
Avoid micro management of details Dont be surprise if current project management tools dont work:
w They were designed for projects with clear goals and fixed organizational structures
Bernd Bruegge
67
Project Management Summary

v
Get agreement among customers, managers and teams

w w w w Problem statement Software project management plan Project agreement Make sure agreement allows for iteration
v v
Team Structures Project planning

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

w GANTT, Dependency graph, Schedule, Critical Path Analysis
Bernd Bruegge
68
Communication Management
v v v v v
Communication in distributed Teams Communication Modes Communication Mechanisms Scheduled Communications Communication workflow
w Example: Distributed Document Review with Lotus Notes
Bernd Bruegge
69
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
Bernd Bruegge
70
A Communication Example ctd
Thanks to a particular thorough preflight check, it was discovered that the wires had been reversed."
Box 1
Box 2
Bernd Bruegge
71
After the Crash...

v v
... "The postflight analysis revealed that the contractors had indeed corrected the reversed wires as instructed."
Bernd Bruegge
72
In fact, both of them had.
Box 1
Box 2
Bernd Bruegge
73
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 mode
supports is supported by
Communication mechanism
Scheduled
Event driven
Synchronous
Asynchronous
Client review
Problem reporting
Smoke signals
Fax
Bernd Bruegge
75
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 u u
Analysis Review (October 16, 1997) Object Design Review (November 11 & 13, 1997) Implementation Review (November 25, 1997)
v Client
Review: Focus on Requirements
w Objective: Brief Client of Progress, Confirm Changes in Requirements

u
Bernd Bruegge
System Design Review (October 23, 1997)


v Walkthrough
(Informal)
w Objective: Increase quality of subsystem w Developer presents to team members Informal, peerto-peer
u
To be scheduled by each team
Inspection (Formal) w Objective: Compliance with (functional and nonfunctional) requirements w Developer answers questions from the reviewers
u
Client Acceptance Test (December 9, 1997)
Bernd Bruegge
77

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)
Bernd Bruegge
78
Meeting as Scheduled and Synchronous Communication

v
Purpose of Meeting
w Why do we meet?
Desired Outcome
w What do we want to achieve?
Information Sharing
w Action Items
Information Processing
w Open Issues
Meeting Critique
Action Items (From previous meeting)

Issues (From previous meetings and BBoards)
Bernd Bruegge
79

v Release
w The result of each software development activity

u u u u u u
Software Project Management Plan (SPMP) Requirements Analysis Document (RAD) System Design Document (SDD) Object Design Document (ODD) Test Manual User Manual
v Postmortem
u
Review
w Objective: Describe Lessons Learned

Final Homework (December 16, 1997)
Bernd Bruegge
80
Event-Driven Modes of Communication

v v v
Request for Clarification Change Request Resolution of Issue
Bernd Bruegge
81
Synchronous Communication Mechanisms

v
Hallway conversation
w Unplanned face-to-face meeting
v v
Questionaire and structured interviews Meeting

w Planned Face-to-Face Meeting, Telephone conversation
Groupware
w Same time, different location groupware
Bernd Bruegge
82
Asynchronous Communication Mechanisms

v v v v
E-Mail Newsgroups Web Lotus Notes
Bernd Bruegge
83
Example of Asynchronous Documentation: Document Review

v v v v v v v v
Fill out a review form Attach document to be reviewed Distribute the review form to reviewers Wait for comments from reviewers Review comments Create action items from selected comments Revise document and post the revised version Iterate the review cycle Example:
w Review of Documents Database in JAMES Project
Bernd Bruegge
84
Review of Documents Database
Bernd Bruegge
85
NewReview Form
Bernd Bruegge
86
Fill out the Review Form

v v v v
Select reviewers Select the document to be reviewed Add comments to reviewers Determine deadline
Bernd Bruegge
87
Reviewer Notification
v
Selected reviewers get e-mail
Bernd Bruegge
88
Status of Document Review
Bernd Bruegge
89
Reviewers add their Comments
Bernd Bruegge
90
Originator Notification
Bernd Bruegge
91
Final Recipient Notification
Bernd Bruegge
92
Document Editor & Web Master Tasks

v v v v v v
Editor reviews comments Editor selects reviewed comments Web Master posts reviewed document and action items Team members complete their action items Editor integrates changes Editor posts changed document on the review database for the next review cycle
Bernd Bruegge
93
Accepted Document w/ Action Items
Bernd Bruegge
94
SPMP Action Items
Bernd Bruegge
95
Summary
v v v v
Communication Modes vs Communication Mechanisms Scheduled Communications Asynchronous Communications Team review of documents with Lotus Notes
Bernd Bruegge
96

Lecture Notes On Project-Management

Uploaded by

Document Information

Original Title

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

Lecture Notes On Project-Management

Uploaded by

Copyright:

Available Formats

v

Lecture Notes on Project Management

Component-Based Software Engineering

Odds and Ends I

Book on CBSE Homepage

w Chapters available on August 15:

Component-Based Software Engineering

Odds and Ends II

Lecture next Tuesday:

Component-Based Software Engineering

Laws of Project Management

Component-Based Software Engineering

Delivery and Installation

Component-Based Software Engineering

How it often goes

Component-Based Software Engineering

Software Project Management Plan

Software Project Management Plan:

Component-Based Software Engineering

Document written for a client that defines:

Component-Based Software Engineering

Project Agreement vs Problem Statement

Problem Statement Project Agreement

Software Project Management Plan

Component-Based Software Engineering

Project: Functions, Activities and Tasks

Function Project Function

Activity Activity Task

Activity Activity Task Task

Activity Activity Task

Component-Based Software Engineering

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

Activity Activity Activity Task Task Task Task

Component-Based Software Engineering

Task Task Task Task

Smallest unit of management accountability

Specification of a task: Work package

Component-Based Software Engineering

Finding the appropriate task size is problematic

Tasks must be decomposed into sizes that allow monitoring

Component-Based Software Engineering

Component-Based Software Engineering

Example of action items:

Component-Based Software Engineering

Activity Activity Activity Task Task Task Task

Component-Based Software Engineering

Major unit of work Culminates in major project milestone:

Activitites may be grouped into larger activities:

Milestone often produces baseline:

Component-Based Software Engineering

during requirements analysis:

Component-Based Software Engineering

Structure of a Software Project Management Plan

Component-Based Software Engineering

SPMP Part 0: Front Matter

Component-Based Software Engineering

SPMP Part 1: Introduction

w Executive summary: description of project, product summary

w All items to be delivered, including delivery dates and location

SPMP Part 2: Project Organization

Process Model Organizational Structure Organizational Interfaces Project Responsibilities

Component-Based Software Engineering

Component-Based Software Engineering