Conquering Complex and Changing Systems
Object-Oriented Software Engineering
Chapter 11,
Project Management
Outline











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
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
2

Reference:
 Bruegge&Dutoit, Chapter 12


http://notesbruegge.in.tum.de/PAID2/schedule/ProjectManagement011599.pdf
What is not covered in this lecture?
 Communication Management, Meeting Management
 Bruegge & Dutoit, Chapter 4

http://notesbruegge.in.tum.de/PAID2/schedule/ProjectCommunication112598.pdf
 Cost estimation

Reference: Software engineering economics, Barry Boehm, Prentice Hall
1981
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
3
Laws of Project Management

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 can’t get worse, they will. When things
appear to be going better, you have overlooked something.

If project content is allowed to change freely, the rate of
change will exceed the rate of progress.

Project teams detest progress reporting because it
manifests their lack of progress.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
4
How it should go
Requirements
Analysis
Design
Implementation
System Testing
Delivery and Installation
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
5
How it often goes
Requirements
Analysis
D
E
L
A
Y
Bernd Bruegge & Allen Dutoit
Vaporware
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
6
Software Project Management Plan

Software Project:
 All technical and managerial activities required to deliver
the deliverables to the client.
 A software project has a specific duration, consumes
resources and produces work products.
 Management categories to complete a software project:
 Tasks, Activities, Functions

Software Project Management Plan:
 The controlling document for a software project.
 Specifies the technical and managerial approaches to
develop the software product.
 Companion document to requirements analysis document:
Changes in either may imply changes in the other
document.
 SPMP may be part of project agreement.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
7
Project Agreement

Document written for a client that defines:
 the scope, duration, cost and deliverables for the project.
 the exact items, quantities, delivery dates, delivery location.



Can be a contract, a statement of work, a business plan, or a
project charter.
Client: Individual or organization that specifies the
requirements and accepts the project deliverables.
Deliverables (= Work Products that will be delivered to the
client):




Documents
Demonstrations of function
Demonstration of nonfunctional requirements
Demonstrations of subsystems
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
8
Project Agreement vs Problem Statement
Client
(Sponsor)
Problem
Statement
Project
Agreement
Bernd Bruegge & Allen Dutoit
Manager
Project Team
Software Project
Management Plan
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
9
Project Management Activities
(continued on next slide)
Initiation
Problem statement
definition
Initial top-level
design
Team formation
Initial milestones
planning
Communication
infrastructure setup
Project kickoff
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
10
Project kickoff
Steady state
Status monitoring
Risk management
Project replanning
Project agreement
Termination
Installation
Bernd Bruegge & Allen Dutoit
Client acceptance test
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
Postmortem
11
Project: Functions, Activities and Tasks
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
Bernd Bruegge & Allen Dutoit
a2:Activity
a2.2:Activity
t2:Task
t3:Task
a3:Activity
a2.3:Activity
t4:Task
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
12
Functions

Activity or set of activities that span the duration of the project
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
Bernd Bruegge & Allen Dutoit
a2:Activity
a2.2:Activity
t2:Task
t3:Task
a3:Activity
a2.3:Activity
t4:Task
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
13
Functions

Examples:





Project management
Configuration Management
Documentation
Quality Control (Verification and validation)
Training

Question: Is system integration a project function?

Mapping of terms: Project Functions in the IEEE 1058
standard are called Integral processes in the IEEE 1074
standard. We call them cross-development processes
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
14
Tasks
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
Bernd Bruegge & Allen Dutoit
a2:Activity
a2.2:Activity
t2:Task
t3:Task
• Smallest unit
of work subject
to management
• Small enough for
adequate planning
and tracking
• Large enough
to avoid micro
management
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
15
Tasks

Smallest unit of management accountability
 Atomic unit of planning and tracking
 Finite duration, need resources, produce tangible result (documents,
code)

Specification of a task: Work package





Name, description of work to be done
Preconditions for starting, duration, required resources
Work product to be produced, acceptance criteria for it
Risk involved
Completion criteria
 Includes the acceptance criteria for the work products
(deliverables) produced by the task.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
16
Task Sizes

Finding the appropriate task
size is problematic
 Todo lists from previous
projects
 During initial planning a
task is necessarily large
 You may not know how to
decompose the problem into
tasks at first
 Each software development
activity identifies more tasks
and modifies existing ones
Bernd Bruegge & Allen Dutoit

Tasks must be decomposed
into sizes that allow
monitoring
 Work package usually
corresponds to well defined
work assignment for one
worker for a week or a
month.
 Depends on nature of work
and how well task is
understood.
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
17
Examples of Tasks









Unit test class “Foo”
Test subsystem “Bla”
Write user manual
Write meeting minutes and post them
Write a memo on NT vs Unix
Schedule the code review
Develop the project plan
Related tasks are grouped into hierarchical sets of functions and
activities.
Action item
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
18
Action Item


Definition: A task assigned to a person that has to be done
within a week or less
Action items
 Appear on the agenda in the Status Section (See lecture on
communication)
 Cover: What?, Who?, When?

Example of action items:
 Florian unit tests class “Foo” by next week
 Marcus develops a project plan before the next meeting
 Bob posts the next agenda for the Simulation team meeting before
Sep 10, 12noon.
 The VIP team develops the project plan by Sep 18
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
19
Activities
f1:Function
p:Project
f2:Function
a1:Activity
a2.1:Activity
t1:Task
Bernd Bruegge & Allen Dutoit
a2:Activity
a2.2:Activity
t2:Task
• Major unit of work
with precise dates
• Consists of smaller
activities or tasks
t3:Task
• Culminates in project
milestone.
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
20
Activities


Major unit of work
Culminates in major project
milestone:
 Internal checkpoint should
not be externally visible
 Scheduled event used to
measure progress

Milestone often produces
baseline:

Activities may be grouped
into larger activities:
 Establishes hierarchical
structure for project (phase,
step, ...)
 Allows separation of
concerns
 Precedence relations often
exist among activities (PERT
Chart)
 formally reviewed work product
 under change control (change
requires formal procedures)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
21
Examples of Activities

Major Activities:









Planning
Requirements Elicitation
Requirements Analysis
System Design
Object Design
Implementation
System Testing
Delivery
Bernd Bruegge & Allen Dutoit
Activities during
requirements analysis:





Refine scenarios
Define Use Case model
Define object model
Define dynamic model
Design User Interface
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
22
Structure of a Software Project Management Plan
Front Matter
1. Introduction
2. Project Organization
3. Managerial Process
4. Technical Process
5. Work Elements, Schedule, Budget
Optional Inclusions
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
23
SPMP Part 0: Front Matter




Title Page
Revision sheet (update history)
Preface: Scope and purpose
Tables of contents, figures, tables
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
24
SPMP Part 1: Introduction
1.1 Project Overview
 Executive summary: description of project, product summary
1.2 Project Deliverables
 All items to be delivered, including delivery dates and location
1.3 Evolution of the SPMP
 Plans for anticipated and unanticipated change
1.4 Reference Materials
 Complete list of materials referenced in SPMP
1.5 Definitions and Acronyms
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
25
SPMP Part 2: Project Organization
2.1 Process Model
 Relationships among project elements
2.2 Organizational Structure
 Internal management, organization chart
2.3 Organizational Interfaces
 Relations with other entities
2.4 Project Responsibilities
 Major functions and activities; nature of each; who’s in charge
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
26
Process Model

Shows relationships among







Functions, activities, tasks
Milestones
Baselines
Reviews
Work breakdown structure
Project deliverables
Sign-offs
Bernd Bruegge & Allen Dutoit


Visualization of process
model
Project Management Aids
 MS Project (Microsoft)
 MAC Project (Claris)
 EasyTrak (Planning Control
International)
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
27
Example of an Organization Chart
Client
Management
Cross-functional Teams
Architecture
HCI
Consultants
Development Teams
Logbook
Maintenance
Web Master
Documentation
Configuration Mgt
Vehicle
Travel
VIP
Infrastructure Team
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
28
Project Roles










Planner
Analyst
Designer
Programmer
Tester
Maintainer
Trainer
Document Editor
Web Master
Configuration Manager
Bernd Bruegge & Allen Dutoit




Group leader
Liaison
Minute Taker
Project Manager
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
29
Project Roles

Management roles
 Organization and execution of the project within constraints.
Examples: project manager, team leader.

Development roles
 Specification, design and construction of subsystems. Examples:
Analyst, system architect, implementor.

Cross functional roles
 Coordination of more than one team. Example: API Engineer,
configuration manager, tester

Consultant roles
 Support in areas where the project participants lack expertise.
Examples: End user, client, application domain specialist ( problem
domain), technical consultant (solution domain).

Promoter roles
 Promote change through an organization.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
30
Promoter Roles



Promoters are self appointed individuals who identify
themselves with the outcome of the project.
They are member of the corporate organization and may not
necessarily be directly involved with the project. Instead, they
are interfaces to the rest of the corporate organization.
Because of the power, knowledge of technology, or familiarity
with the project’s processes, they are able to promote and push
specific changes through the organization.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
31
Power Promoter





Also called executive champion
Pushes the change through the existing organizational hierarchy.
 not necessarily at the top of the organization, but must have
protection from top level management, otherwise project
opponents might be able to prevent the success of the project.
Tasks:
 constantly identify difficulties, resolve issues, and
communicate with the project members, especially with the
developers.
Example at project level: Project Manager.
Example at corporate level: Chief Executive Officer (CEO).
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
32
Knowledge Promoter




Also called the technologist,
Promotes change arising in the application domain or the solution
domain. Usually associated with the power promoter.
Tasks: Acquire information iteratively, understand the benefits
and limitations of new technologies, and argue its adoption with
the other developers.
Example at project level: System architect.
 Reports to project manager
 Does not have any direct subordinate in the reporting hierarchy
 Has final say over all technical decisions in the system.

Example at corporate level: Chief Technical Officer (CTO).
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
33
Process Promoter





The process promoter has intimate knowledge of the projects
processes and procedures.
The process promoter is in constant interaction with the power
promoter to get consensus on the overall goals.
Tasks: Bridge between the power and knowledge promoters,
who often do not speak or understand the same language.
Example at project level: Development lead. Responsible for
the administrative aspects of a project, including planning,
milestones definition, budgeting and communication
infrastructure.
Example at corporate level: Chief Information Officer (CIO
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
34
Project Management: Hierarchical Project
Organization
Control Flow
Chief Executive
Information Flow
First Level Manager
(“Front-Line Manager”)
A
B
Project Members
A wants to talk to B: Complicated Information Flow
A wants to make sure B does a certain change: Complicated Controlflow
Basis of organization:
Complicated information and control flow
across hierarchical boundaries
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
35
Example of Hierchical Organization:
Chief Programmer Team
Chief Programmer
Assistant
Chief Programmer
Senior Programmer
Librarian
Administration
Tester
Junior Programmer
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
36
Another Project Organization:
Egoless Programming Team (Weinberg)
Analyst
Tester
Programmer
Designer
Bernd Bruegge & Allen Dutoit
Librarian
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
37
Project-Based Project Organization
Project
Leader
Coaches
Subsystem Team
A
Subsystem Team
Subsystem Team
B
Team
Members
A wants to talk to B: Communication Flow
A wants to make sure B does a certain change: Decision Flow
Basis of organization:
Nonlinear information flow across dynamically formed units
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
38
Associations in organizational structures

Reporting association:
 Used for reporting status information

Decision association
 Used for propagating decisions

Communication association
 Used for exchanging information needed for decisions (e.g.,
requirements, design models, issues).
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
39
Observations on Management Structures

Hierarchical structures
 “Reports”, “Decides” and “Communicates-With” all mapped on the
same association
 Do not work well with iterative and incremental software
development process
 Manager is not necessarily always right

Project-based structures
 “Reports”, “Decides” and “Communicates-With”are different
associations
 Cut down on bureaucracy reduces development time
 Decisions are expected to be made at each level
 Hard to manage
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
40
Hierarchical Structure

Projects with high degree of certainty, stability, uniformity and
repetition.
 Requires little communication
 Role definitions are clear

When?
 The more people on the project, the more need for a formal
structure
 Customer might insist that the test team be independent from the
design team
 Project manager insists on a previously successful structure
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
41
Project-Based Structure

Project with degree of uncertainty
 Open communication needed among members
 Roles are defined on project basis

When?
 Requirements change during development
 New technology develops during project
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
42
Assigning Responsibilities To People
Team A
“To Do” List for the Project
• Item 1
• Item 2
• Item 3
Role 1
Item 1
Item 2
Item 9
• Item 5
• Item 6
• Item 7
• Item 9
Bernd Bruegge & Allen Dutoit
Role 1
Role 2
Item 4
Item 5
Item 7
• Item 4
• Item 8
Person A
Role 3
Item 3
Item 6
Item 8
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
Role 2
Person B
Role 3
43
Possible Mappings of ToDos to People

One-to-One
 Ideal but often not worth to be called a project

Many-to-Few
 Each project member assumes several roles ("hats")
 Danger of overcommittment
 Need for load balancing

Many-to-"Too-Many"
 Some people don't have significant roles
 Bystanders
 Loosing touch with project
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
44
Team Formation

Top level Design
 “Rough” Subsystem Decomposition (before requirements analysis)
 Done during Predevelopment phase


Team Formation done after Top Level Design
Heuristics:
 One team for each subsystem
 One cross-functional task per team
 5-7 members per team

Be prepared to iterate the team formation after system design
when the subsystem decomposition is baselined
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
45
Project Roles: Coach







Listen to gripes from individual teams
Review weekly team reports
Attend weekly project meetings
Schedule and prepare meetings with client
Insist that guidelines are followed
Assign presentations (in-class project meetings, client review,
client acceptance test)
Resolve conflicts if they cannot be resolved otherwise
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
46
Project Role: Group leader

Responsible for intra-group communication (Meeting
Management: Primary Facilitator)







Run the weekly project meeting
Post agenda before meeting
Define and keep track of action items (who, what, when)
Measure progress (Enforce milestones)
Deliver work packages for the tasks to the project management
Present problems and status of team to project manager
The group leader has to be rotated among members of the team.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
47
Group Leader: Create an Agenda





Purpose of Meeting
Desired Outcome
Information Sharing
Information Processing
Meeting Critique
Action Items
(Check Previous
Meeting)
Issues
(Check Previous
Meeting & BBoards)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
48
Project Role: Liaison

Responsible for inter-group communication
 Make available public definitions of subsystem developed by the
team to the architecture teams (ensure consistency, etc)
 Coordinate tasks spanning more than one group with other teams


Responsible for team negotiations
Examples: API Engineer, Configuration manager
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
49
Project Role: Planner


Plans and tracks the activities of an individual team and has
the following responsibilities.
Define project plan for team:
 PERT chart, resource table and GANTT chart showing work
packages
 Enter project plan into project management tool


Make project plan available to management
Report team status to project manager
No explicit planner in PAID. Responsibilities assumed by
coaches
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
50
Project Role: Document Editor




Collect, proofread and distribute team documentation
Submit team documentation to architecture team
Collect agendas
Take minutes at meetings
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
51
Web Master



Maintain team home page
Keep track of meeting history
Keep track of design rationale
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
52
Web Master:

Publish Meeting Information on Team Homepage
 Must contain Agenda, minutes, action items and issues
 Possibilities:


One HTML document per meeting, with anchors (maintained by one
role)
Separate HTML documents for Agenda, Minutes, etc (maintained by
several roles)
Date
Agenda
Minutes
Action Items
Issues
9/9/96
Agenda
Minutes
Action Items
Issues
9/16/96
Agenda
Minutes
Action Items
Issues
http://cascade1.se.cs.cmu.edu/
15-413/homePagesTeams/UserInterface/www/index.htm
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
53
SPMP Part 3: Managerial Processes
3.1 Management Objectives and Priorities
 Philosophy, goals and priorities
3.2 Assumptions, Dependencies, Constraints
 External factors
3.3 Risk Management
 Identifying, assessing, tracking, contingencies for risks
3.4 Monitoring and Controlling Mechanisms
 Reporting mechanisms and formats, information flows, reviews
3.5 Staffing Plan
 Needed skills (what?, how much?, when?)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
54
Examples of Assumptions




There are enough cycles on the development machines
Security will not be addressed
There are no bugs in Together-J, the CASE Tool recommended
for the project
A demonstration of the Starnetwork system will be given by the
client
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
55
Examples of Dependencies


The database team depends on the EPC database provided by
DaimlerChrysler
The automatic code generation facility in the CASE tool
depends on JDK. The current release of Together-J supports
only JDK 1.1.6
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
56
Examples of Constraints






The length of the project is 3 months. limited amount of time to
build the system
The project consists of beginners. It will take time to learn how
to use the tools
Not every project member is always up-to-date with respect to
the project status
The use of UML and a CASE tool is required
Any new code must be written in Java
The system must use Java JDK 1.1.6
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
57
Risk Management

Risk: Members in key roles
drop the course.

 Contingency: Roles are
assigned to somebody else.
Functionality of the system is
renegotiated with the client.

Risk: The project is falling
behind schedule.
 Contingency: Extra project
meetings are scheduled.
Bernd Bruegge & Allen Dutoit
Risk: One subsystem does
not provide the
functionality needed by
another subsystem.
 Contingency: ?

Risk: Ibutton runs only
under JDK 1.2
 Contingency: ?
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
58
SPMP Part 4: Technical Process
4.1 Methods, Tools and Techniques
 Computing system, development method, team structure, etc.
 Standards, guidelines, policies.
4.2 Software Documentation
 Documentation plan, including milestones, reviews and baselines.
4.3 Project Support Functions
 Plans for functions (quality assurance, configuration management).
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
59
SPMP Part 5: Work Elements
5.1 Work Packages (Work breakdown structure)
 Project decomposed into tasks; definitions of tasks
5.2 Dependencies
 Precedence relations among functions, activities and tasks
5.3 Resource Requirements
 Estimates for resources such as personnel, computer time, special
hardware, support software.
5.4 Budget and Resource Allocation
 Connect costs to functions, activities and tasks.
5.5 Schedule
 Deadlines, accounting for dependencies, required milestones
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
60
Creating Work Packages

Work Breakdown Structure (WBS) (Section 5.1)
 Break up project into activities (phases, steps) and tasks.
 The work breakdown structure does not show the interdependence
of the tasks

The identification of the work breakdown structure is an
instance of object identification and associating these objects
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
61
WBS Trade-offs


Work breakdown structure influences cost and schedule
Thresholds for establishing WBS in terms of percentage of total
effort:
 Small project (7 person-month): at least 7% or 0.5 PM
 Medium project (300 person-month): at least 1% or 3 PMs
 Large project (7000 person-month): at least 0.2 % or 15 PMs

Determination of work breakdown structure is incremental and
iterative
WBS
Schedule
Source: Software Engineering
Economics, Barry W. Boehm
p. 47, Prentice Hall, N.J., 1981
Cost
(Time, $$)
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
62
Dependencies and Schedule
(SPMP Section 5.2 + 5.5)


An important temporal relation: “must be preceded by”
Dependency graphs show dependencies of the tasks
(hierarchical and temporal)
 Activity Graph:


Nodes of the graph are the project milestones
Lines linking the nodes represent the tasks involved
 Schedule Chart (MS-Project):




Nodes are tasks and milestones
Lines represent temporal dependencies
Estimate the duration of each task
Label dependency graph with the estimates
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
63
Project Management Tools for Work Packages

Visualization Aids for Project Presentation
 Graphs (Schedule), Trees (WBS)
 Tables (Resources)

Task Timeline
 Gantt Charts: Shows project activities and tasks in parallel. Enables
the project manager to understand which tasks can be performed
concurrently.

Schedule Chart (PERT Chart)
 Cornerstone in many project management tools
 Graphically shows dependencies of tasks and milestones


PERT: Program Evaluation and Review Technique
– A PERT chart assumes normal distribution of tasks durations
– Useful for Critical Path Analysis
CPM: Critical Path Method
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
64
Project: Building a House




Activity 1: Landscaping the lot
 Task 1.1: Clearing and grubbing
 Task 1.2: Seeding the Turf
 Task 1.3: Planting shrubs and trees
Activity 2: Building the House
 Activity 2.1 : Site preparation
 Activity 2.2: Building the exterior
 Activity 2.3: Finishing the interior
Activity 2.1 : Site preparation
 Task 2.1.1: Surveying
 Task 2.1.2: Obtaining permits
 Task 2.1.3: Excavating
Task 2.1.4: Obtaining materials
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
65
Activity 2: Building a House, ctd

Activity 2.2: Building the exterior
 Task 2.2.1: Foundation
 Task 2.2.2: Outside Walls
 Task 2.2.3: Exterior
plumbing
 Task 2.2.4: Exterior
electrical work
 Task 2.2.5: Exterior siding
 Task 2.2.6: Exterior painting
 Task 2.2.7: Doors and
Fixtures
 Task 2.2.8: Roof
Bernd Bruegge & Allen Dutoit

Activity 2.3 : Finishing the Interior
 Task 2.3.1: Interior
plumbing
 Task 2.3.2: Interior electrical
work
 Task 2.3.3: Wallboard
 Task 2.3.4: Interior painting
 Task 2.3.5: Floor covering
 Task 2.3.6: Doors and
fixtures
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
66
Activity Graph for Activity “Building a House”
STAR T
Build Outside
Wall
1.2
Surveying
1.1
Excavation
1.3
Buy Materials
1.4
Lay Foundation
2.1
Build Outside
2.2
Install Exterior Plumbing
Wall
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
2.6
Install Exterior Doors
2.7
2.8
3.6
2.6
Bernd Bruegge & Allen Dutoit
3.4
Install Roo¼ ng
Paint Interior
3.5
Install Interior Doors
FINISH
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
67
PERT Chart Example for "Building a House"
12/3/94
12/21/94
Install
Interior
Plumbing
Building a House:
0
12
MS Project PERTcy
Chart with Duration of
Activities (Pfleeger 2.3)
1/11/95
Install
Interior
Electrical
0
15
Install
Wallboard
1/22/95
0
9
Paint
Interior
0
11
2/8/95
Install
Interior
Doors
1/22/95
Install
Flooring
8/27/94
9/17/94
8/27/94
Survey
ing
START
0
0
10/1/94
Excava
tion
0
10
12
3
10/15/94
Buy
Material
0
10
11/5/94
Lay
Founda
tion
0
15
Build
Outside
Wall
1/19/95
0
18
Install
Roofing
0
20
0
Install 0
Exterior
Doors
Paint
Exterior
0
15
12
5
12/3/94
Slack Time
Duration
0
0
12/17/94
12
10
12/31/94
Install
Exterior
Siding
Install
Exterior
Electrical
Install
Exterior
Plumbing
8/29/94
Legend
Bernd Bruegge & Allen Dutoit
1/19/95
15
6
1/12/95
Request
Permits
2/16/95
FINISH
12
9
8/27/94
Start Time
0
7
12
10
12
8
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
68
Slack Time and Critical Path

Slack Time
 Available Time - Estimated (“Real”) Time for a task or activity
 Or: Latest Start Time - Earliest Start Time

Critical Path
 The path in a project plan for which the slack time at each task is
zero.
The critical path has no margin for error when performing the
tasks (activities) along its route.
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
69
How do you become a good project planner?

Establish a project plan
 Start with the plan based on your experience with the last project(s)



Keep track of activities and their duration
Determine difference between planned and actual performance
Make sure to do a post-mortem
 Lessons learned
 Ask developers for feedback
 Write a document about what could have been improved
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
70
Writing the SPMP


Example full SPMPs
OWL project
 http://cascade1.se.cs.cmu.edu/15-413/courseDocs/spmpF96.html

JAMES project
 http://cascade1.se.cs.cmu.edu/JAMES/J_courseDocs/SPMP/SPMP1.
0.html
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
71
Project Management Heuristics

Make sure to be able to revise or dump a project plan
 Complex system development is a nonlinear activity

If project goals are unclear and complex use team-based project
management. In this case
 Avoid GANTT charts and PERT charts for projects with changing
requirements
 Don’t look too far into the future


Avoid micro management of details
Don’t be surprise if current project management tools don’t
work:
 They were designed for projects with clear goals and fixed
organizational structures
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
72
Project Management Summary

Get agreement among customers, managers and teams







Problem statement
Software project management plan
Project agreement
Make sure agreement allows for iteration
Organization Structures
SPMP
Project planning
 Start with work breakdown structure (WBS)
 Identify dependencies and structure: Tasks, activities, functions

Tools and Techniques
 GANTT, Dependency graph, Schedule, Critical Path Analysis
 Be careful with tools in projects with a lot of change
Bernd Bruegge & Allen Dutoit
Object-Oriented Software Engineering: Conquering Complex and Changing Systems
73