Você está na página 1de 96

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

Bernd Bruegge Component-Based Software Engineering 2


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

Bernd Bruegge Component-Based Software Engineering 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

Bernd Bruegge Component-Based Software Engineering 4


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.

Bernd Bruegge Component-Based Software Engineering 5


How it should go

Requirements
Analysis

Design

Implementation

System Testing

Delivery and Installation

Bernd Bruegge Component-Based Software Engineering 6


How it often goes

Requirements
Analysis

D
E
L
A
Y
Vaporware

Bernd Bruegge Component-Based Software Engineering 7


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.
Bernd Bruegge Component-Based Software Engineering 8
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

Bernd Bruegge Component-Based Software Engineering 9


Project Agreement vs Problem Statement

Client Manager Project Team


(Sponsor)

Problem
Statement Software Project
Management Plan
Project
Agreement

Bernd Bruegge Component-Based Software Engineering 10


Project: Functions, Activities and Tasks

Function
Project
Function

Activity Activity Activity

Activity Activity Activity

Task Task Task Task

Bernd Bruegge Component-Based Software Engineering 11


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

Function
Project
Function

Activity Activity Activity

Activity Activity Activity

Task Task Task Task

Bernd Bruegge Component-Based Software Engineering 12


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

Bernd Bruegge Component-Based Software Engineering 13


Tasks
Function
Project
Function

• Smallest unit
Activity Activity Activity of work subject
to management
Activity Activity Activity
• Small enough for
adequate planning
Task Task Task Task
and tracking
• Large enough
to avoid micro
management
Bernd Bruegge Component-Based Software Engineering 14
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.

Bernd Bruegge Component-Based Software Engineering 15


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

Bernd Bruegge Component-Based Software Engineering 16


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

Bernd Bruegge Component-Based Software Engineering 17


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

Bernd Bruegge Component-Based Software Engineering 18


Activities

Function
Project
Function

Activity Activity Activity • Major unit of work


with precise dates
Activity Activity Activity
• Consists of smaller
activities or tasks
Task Task Task Task
• Culminates in project
milestone.
Bernd Bruegge Component-Based Software Engineering 19
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)

Bernd Bruegge Component-Based Software Engineering 20


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

Bernd Bruegge Component-Based Software Engineering 21


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

Bernd Bruegge Component-Based Software Engineering 22


SPMP Part 0: Front Matter

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

Bernd Bruegge Component-Based Software Engineering 23


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
Bernd Bruegge Component-Based Software Engineering 24
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

Bernd Bruegge Component-Based Software Engineering 25


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

Bernd Bruegge Component-Based Software Engineering 26


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

Bernd Bruegge Component-Based Software Engineering 27


Clients, Managers and Consultants

Management
Malcolm Bauer
Bernd Bruegge
Allen Dutoit
Brian Cavalier
Sam Perman Consultants
Isabel Torres-Yebra Klaus Eitzenberger
Client Alfonso Guerrero- Galan Manfred Mueller
Dieter Hege Juergen Bortolazzi,
Brigitte Pihulak Claus Czymmek

Infrastructure Team
Stephan Schoenig (CMU)
Joyce Johnstone (CMU)
Andreas Doerner (DB)
Arno Schmackpfeffer (DB)

Bernd Bruegge Component-Based Software Engineering 28


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)
Bernd Bruegge Component-Based Software Engineering 29
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

Bernd Bruegge Component-Based Software Engineering 30


Project Management: Hierarchical Project
Organization

Chief Executive

Team Leaders

Project Members

Basis of organization:
Hierarchical information flow across corporate boundaries

Bernd Bruegge Component-Based Software Engineering 31


Example of Hierchical Organization:
Chief Programmer Team

Chief Programmer

Assistant
Chief Programmer

Senior Programmer Librarian Administration Tester

Junior Programmer

Bernd Bruegge Component-Based Software Engineering 32


Another Project Organization:
Egoless Programming Team(Weinberg)

Analyst

Tester Programmer

Designer Librarian

Bernd Bruegge Component-Based Software Engineering 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
Bernd Bruegge Component-Based Software Engineering 34
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

Bernd Bruegge Component-Based Software Engineering 35


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
Bernd Bruegge Component-Based Software Engineering 36
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

Bernd Bruegge Component-Based Software Engineering 37


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

Bernd Bruegge Component-Based Software Engineering 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

Bernd Bruegge Component-Based Software Engineering 39


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 Component-Based Software Engineering 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 Component-Based Software Engineering 41
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)

Bernd Bruegge Component-Based Software Engineering 42


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 Component-Based Software Engineering 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

Bernd Bruegge Component-Based Software Engineering 44


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 Component-Based Software Engineering 45


Web Master

v Maintain team home page


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

Bernd Bruegge Component-Based Software Engineering 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)
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

Bernd Bruegge Component-Based Software Engineering 47


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

Bernd Bruegge Component-Based Software Engineering 48


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

Bernd Bruegge Component-Based Software Engineering 49


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

Bernd Bruegge Component-Based Software Engineering 50


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

Bernd Bruegge Component-Based Software Engineering 51


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.

Bernd Bruegge Component-Based Software Engineering 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.
v 4.2 Software Documentation
w Documentation plan, including milestones, reviews and
baselines.
v 4.3 Project Support Functions
w Plans for functions (quality assurance, configuration
management).

Bernd Bruegge Component-Based Software Engineering 53


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

Bernd Bruegge Component-Based Software Engineering 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

v WBS identification is an instance of object identification

Bernd Bruegge Component-Based Software Engineering 55


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

Bernd Bruegge Component-Based Software Engineering 56


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

Bernd Bruegge Component-Based Software Engineering 57


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

Bernd Bruegge Component-Based Software Engineering 58


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 Component-Based Software Engineering 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
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

Bernd Bruegge Component-Based Software Engineering 60


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

Bernd Bruegge Component-Based Software Engineering 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.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
Bernd Bruegge Component-Based Software Engineering 62
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

Bernd Bruegge Component-Based Software Engineering 63


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.

Bernd Bruegge Component-Based Software Engineering 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 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

Bernd Bruegge Component-Based Software Engineering 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 Component-Based Software Engineering 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
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

Bernd Bruegge Component-Based Software Engineering 67


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

Bernd Bruegge Component-Based Software Engineering 68


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

Bernd Bruegge Component-Based Software Engineering 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 Component-Based Software Engineering 70


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

Bernd Bruegge Component-Based Software Engineering 71


After the Crash...

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

Bernd Bruegge Component-Based Software Engineering 72


“In fact, both of them had.”

Box 1 Box 2

Bernd Bruegge Component-Based Software Engineering 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.
Bernd Bruegge Component-Based Software Engineering 74
Classification of Communication

Communication supports Communication


mode is supported by mechanism

Scheduled Event driven Synchronous Asynchronous

Client review Problem reporting Smoke signals Fax

Bernd Bruegge Component-Based Software Engineering 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 Analysis Review (October 16, 1997)
u Object Design Review (November 11 & 13, 1997)
u Implementation Review (November 25, 1997)

v Client Review: Focus on Requirements


w Objective: Brief Client of Progress, Confirm Changes
in Requirements
u System Design Review (October 23, 1997)
Bernd Bruegge Component-Based Software Engineering 76
Scheduled Modes of Communication
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)

Bernd Bruegge Component-Based Software Engineering 77


Scheduled Modes of Communication

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 Component-Based Software Engineering 78


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)
Bernd Bruegge Component-Based Software Engineering 79
Scheduled Modes of Communication

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)

Bernd Bruegge Component-Based Software Engineering 80


Event-Driven Modes of Communication

v Request for Clarification


v Change Request
v Resolution of Issue

Bernd Bruegge Component-Based Software Engineering 81


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

Bernd Bruegge Component-Based Software Engineering 82


Asynchronous Communication Mechanisms

v E-Mail
v Newsgroups
v Web
v Lotus Notes

Bernd Bruegge Component-Based Software Engineering 83


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

Bernd Bruegge Component-Based Software Engineering 84


Review of
Documents
Database

Bernd Bruegge Component-Based Software Engineering 85


NewReview Form

Bernd Bruegge Component-Based Software Engineering 86


Fill out the Review Form

v Select reviewers
v Select the document to be reviewed
v Add comments to reviewers
v Determine deadline

Bernd Bruegge Component-Based Software Engineering 87


Reviewer Notification
v Selected reviewers get e-mail

Bernd Bruegge Component-Based Software Engineering 88


Status of Document Review

Bernd Bruegge Component-Based Software Engineering 89


Reviewers
add their
Comments

Bernd Bruegge Component-Based Software Engineering 90


Originator Notification

Bernd Bruegge Component-Based Software Engineering 91


Final Recipient Notification

Bernd Bruegge Component-Based Software Engineering 92


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

Bernd Bruegge Component-Based Software Engineering 93


Accepted Document w/ Action Items

Bernd Bruegge Component-Based Software Engineering 94


SPMP Action Items

Bernd Bruegge Component-Based Software Engineering 95


Summary

v Communication Modes vs Communication Mechanisms


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

Bernd Bruegge Component-Based Software Engineering 96

Você também pode gostar