Ch11lect Project Management

Object-Oriented Software Engineering
Conquering Complex and Changing Systems

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
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.
How it should go
Requirements
Analysis
Design
Implementation
System Testing
Delivery and Installation
How it often goes
Requirements
Analysis
D
E
L
A
Y
Vaporware
Software Project Management Plan
♦ 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.
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
Project Agreement vs Problem Statement
Client Manager Project Team

(Sponsor)
Problem
Statement Software Project
Management Plan
Project
Agreement
Project Management Activities
(continued on next slide)
Initiation
Problem statement
definition
Initial top-level Initial milestones

design planning
Communication
Team formation infrastructure setup
Project kickoff
Project kickoff
Steady state
Status monitoring Risk management
Project replanning Project agreement
Termination
Installation Client acceptance test Postmortem
Project: Functions, Activities and Tasks
f1:Function
p:Project
f2:Function
a1:Activity a2:Activity a3:Activity
a2.1:Activity a2.2:Activity a2.3:Activity
t1:Task t2:Task t3:Task t4:Task
Functions
♦ Activity or set of activities that span the duration of the project
f1:Function
p:Project
f2:Function
a1:Activity a2:Activity a3:Activity
a2.1:Activity a2.2:Activity a2.3:Activity
t1:Task t2:Task t3:Task t4:Task

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
Tasks
f1:Function
p:Project
f2:Function
• Smallest unit
a1:Activity a2:Activity of work subject
to management
a2.1:Activity a2.2:Activity • Small enough for

adequate planning
and tracking
t1:Task t2:Task t3:Task
• Large enough
to avoid micro
management
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.
Task Sizes
♦ Finding the appropriate task ♦ Tasks must be decomposed

size is problematic into sizes that allow
 Todo lists from previous monitoring
projects  Work package usually
 During initial planning a corresponds to well defined
task is necessarily large work assignment for one
 You may not know how to worker for a week or a
month.
decompose the problem into
tasks at first  Depends on nature of work
 Each software development and how well task is
understood.
activity identifies more tasks
and modifies existing ones
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
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
Activities
f1:Function
p:Project
f2:Function
a1:Activity a2:Activity
• Major unit of work
with precise dates
a2.1:Activity a2.2:Activity
• Consists of smaller
activities or tasks
t1:Task t2:Task t3:Task
• Culminates in project
milestone.
Activities
♦ Major unit of work ♦ Activities may be grouped

♦ Culminates in major project into larger activities:
milestone:  Establishes hierarchical
structure for project (phase,
 Internal checkpoint should
step, ...)
not be externally visible
 Allows separation of
 Scheduled event used to
concerns
measure progress
 Precedence relations often
♦ Milestone often produces exist among activities (PERT
baseline: Chart)
 formally reviewed work product
 under change control (change
requires formal procedures)
Examples of Activities
♦ Major Activities: ♦ Activities during

 Planning requirements analysis:
 Requirements Elicitation  Refine scenarios
 Requirements Analysis  Define Use Case model
 System Design  Define object model
 Object Design  Define dynamic model
 Implementation  Design User Interface
 System Testing
 Delivery
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
SPMP Part 0: Front Matter
♦ Title Page
♦ Revision sheet (update history)
♦ Preface: Scope and purpose
♦ Tables of contents, figures, tables
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
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
Process Model
♦ Shows relationships among ♦ Visualization of process

 Functions, activities, tasks model
 Milestones ♦ Project Management Aids
 Baselines  MS Project (Microsoft)
 Reviews  MAC Project (Claris)
 Work breakdown structure  EasyTrak (Planning Control
 Project deliverables International)
 Sign-offs
Example of an Organization Chart
Client Management Consultants
Cross-functional Teams Development Teams
Architecture Logbook
HCI
Maintenance
Web Master
Documentation Vehicle
Configuration Mgt Travel
VIP
Infrastructure Team
Project Roles
♦ Planner ♦ Group leader

♦ Analyst ♦ Liaison
♦ Designer ♦ Minute Taker
♦ Programmer ♦ Project Manager
♦ Tester
♦ Maintainer
♦ Trainer
♦ Document Editor
♦ Web Master
♦ Configuration Manager
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.
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.
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).
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).
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
Project Management: Hierarchical Project
Organization
Control Flow
Information Flow Chief Executive
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
Basisof
oforganization:
organization:
Complicated
Complicatedinformation
informationand
andcontrol
controlflow
flow
across
acrosshierarchical
hierarchicalboundaries
boundaries
Example of Hierchical Organization:
Chief Programmer Team
Chief Programmer
Assistant
Chief Programmer
Senior Programmer Librarian Administration Tester
Junior Programmer
Another Project Organization:
Egoless Programming Team (Weinberg)
Analyst
Tester Programmer
Designer Librarian
Project-Based Project Organization
Project
Leader
Coaches
Subsystem Team Subsystem Team Subsystem Team
A B Team
Members
A wants to talk to B: Communication Flow

A wants to make sure B does a certain change: Decision Flow
Basis
Basisof
oforganization:
organization:
Nonlinear
Nonlinearinformation
informationflow
flowacross
across dynamically
dynamicallyformed
formedunits
units
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).
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
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
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
Assigning Responsibilities To People
Team A
“To Do” List for the Project
Role 1
Person A
• Item 1 Item 1
• Item 2 Item 2
Item 9 Role 1
• Item 3
• Item 4 Role 2 Role 2
Item 4
• Item 5
Item 5
• Item 6 Item 7
Person B
• Item 7
• Item 8
Role 3
• Item 9
Item 3 Role 3
Item 6
Item 8
Possible Mappings of ToDos to People
♦ 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
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
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
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.
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)
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
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
Project Role: Document Editor
♦ Collect, proofread and distribute team documentation

♦ Submit team documentation to architecture team
♦ Collect agendas
♦ Take minutes at meetings
Web Master
♦ Maintain team home page

♦ Keep track of meeting history
♦ Keep track of design rationale
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
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?)
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
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
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
Risk Management
♦ Risk: Members in key roles ♦ Risk: One subsystem does

drop the course. not provide the
 Contingency: Roles are functionality needed by
assigned to somebody else. another subsystem.
Functionality of the system is  Contingency: ?
renegotiated with the client.
♦ Risk: Ibutton runs only
♦ Risk: The project is falling
under JDK 1.2
behind schedule.
 Contingency: ?
 Contingency: Extra project
meetings are scheduled.
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).
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
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
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
Source: Software Engineering
WBS Schedule Economics, Barry W. Boehm
p. 47, Prentice Hall, N.J., 1981
Cost
(Time, $$)
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
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
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
Activity 2: Building a House, ctd
♦ Activity 2.2: Building the exterior ♦ Activity 2.3 : Finishing the Interior
 Task 2.2.1: Foundation  Task 2.3.1: Interior
 Task 2.2.2: Outside Walls plumbing
 Task 2.2.3: Exterior  Task 2.3.2: Interior electrical
plumbing work
 Task 2.2.4: Exterior  Task 2.3.3: Wallboard
electrical work  Task 2.3.4: Interior painting
 Task 2.2.5: Exterior siding  Task 2.3.5: Floor covering
 Task 2.2.6: Exterior painting  Task 2.3.6: Doors and
 Task 2.2.7: Doors and fixtures
Fixtures
 Task 2.2.8: Roof
Activity Graph for Activity “Building a House”
START
Build Outsid e Wall

Surveying
1.2 1.1
Excavation
1.3
Buy M aterials
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 Roo¼ng
Install Interior Doors
2.7 2.8 3.6
2.6
FINISH
PERT Chart Example for "Building a House"
12/3/94 12/21/94 1/11/95
Install Install Install
Interior Interior Wallboard
Plumbing Electrical
Building a House:
0 0 0 1/22/95
12 15 9 Paint
MS Project PERTcy
Interior
Chart with Duration of
Activities (Pfleeger 2.3) 0 2/8/95
11
1/22/95 Install
Interior
Install Doors
Flooring
0
10/15/94 11/5/94 7
8/27/94 8/27/94 9/17/94 10/1/94 0 2/16/95
Lay Build 18
START Survey Excava Buy 1/19/95 FINISH
Founda Outside
ing tion Material
tion Wall Install
0 Roofing 1/19/95 0
0 12 0 0 0
0 10 10 Install 0
3 15 20 12
9 Exterior
Doors
8/27/94
15
Request 1/12/95
6
Permits Paint
0 Exterior
15 12
5
12/3/94 12/17/94 12/31/94
Install Install Install

Start Time 8/29/94
Exterior Exterior Exterior
Legend Plumbing Electrical Siding
12 12 12
Slack Time 0 8
10 10
Duration 0
Slack Time and Critical Path
♦ 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.
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
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
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
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

Ch11lect Project Management

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Ch11lect Project Management

Hochgeladen von

Copyright:

Verfügbare Formate

Object-Oriented Software Engineering

Conquering Complex and Changing Systems

♦ Concepts and terminology

♦ What is not covered in this lecture?

♦ When things are going well, something will go wrong.

♦ If project content is allowed to change freely, the rate of

♦ Project teams detest progress reporting because it

Delivery and Installation

♦ Software Project Management Plan:

Client Manager Project Team

Initial top-level Initial milestones

Status monitoring Risk management

Project replanning Project agreement

Installation Client acceptance test Postmortem

a1:Activity a2:Activity a3:Activity

a2.1:Activity a2.2:Activity a2.3:Activity

t1:Task t2:Task t3:Task t4:Task

a1:Activity a2:Activity a3:Activity

a2.1:Activity a2.2:Activity a2.3:Activity

t1:Task t2:Task t3:Task t4:Task

♦ Question: Is system integration a project function?

♦ Mapping of terms: Project Functions in the IEEE 1058

a2.1:Activity a2.2:Activity • Small enough for

♦ Finding the appropriate task ♦ Tasks must be decomposed

♦ Unit test class “Foo”

♦ Definition: A task assigned to a person that has to be done

♦ Major unit of work ♦ Activities may be grouped

♦ Major Activities: ♦ Activities during

1.1 Project Overview

2.1 Process Model

♦ Shows relationships among ♦ Visualization of process

Client Management Consultants

Cross-functional Teams Development Teams

Configuration Mgt Travel

♦ Planner ♦ Group leader

♦ Promoters are self appointed individuals who identify

♦ Also called the technologist,

♦ The process promoter has intimate knowledge of the projects

First Level Manager

A wants to talk to B: Complicated Information Flow

Senior Programmer Librarian Administration Tester

Subsystem Team Subsystem Team Subsystem Team

A wants to talk to B: Communication Flow

♦ Projects with high degree of certainty, stability, uniformity and

♦ Project with degree of uncertainty

♦ Top level Design

♦ Listen to gripes from individual teams

♦ Responsible for intra-group communication (Meeting

♦ Responsible for inter-group communication

♦ Responsible for team negotiations

♦ Plans and tracks the activities of an individual team and has

No explicit planner in PAID. Responsibilities assumed by

♦ Collect, proofread and distribute team documentation

♦ Maintain team home page

Date Agenda Minutes Action Items Issues

9/9/96 Agenda Minutes Action Items Issues

9/16/96 Agenda Minutes Action Items Issues

3.1 Management Objectives and Priorities

♦ There are enough cycles on the development machines

♦ The database team depends on the EPC database provided by

♦ The length of the project is 3 months. limited amount of time to

♦ Risk: Members in key roles ♦ Risk: One subsystem does

4.1 Methods, Tools and Techniques