Transcript Lecture for Chapter 13, Configuration Management

Using UML, Patterns, and Java
Object-Oriented Software Engineering
Chapter 14: Project Management
Outline

Work breakdown structure
 What is it?
 Building a work breakdown structure

Project scheduling
 Dependency diagrams
 Estimating task durations

Project organization
 Types of organizations
 Communications infrastructure


Software Project Management Plan (SPMP)
Overview of project control activities
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
3
Work Breakdown Structure

The hierarchical representation of all the tasks in a project is called
the work breakdown structure (WBS). First Version of a UML
Model
Work Breakdown Structure

Task
*
But Tasks are Parts of Activities. What would be a better model?
Work Breakdown Structure
*
Work
Task
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
*
Activity
8
Tasks

Smallest unit of management accountability
 Atomic unit of planning and tracking
 Tasks have 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.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
9
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
project baselines:

Activitites may be grouped into
larger activities:
 Establishes hierarchical
structure for project (phase,
step, ...)
 Allows separation of concerns
 Precedence relations often exist
among activities
 formally reviewed work product
 under change control (change
requires formal procedures)
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
10
Creating Work Breakdown Structures

Two major philosophies
 Activity-oriented decomposition (“Functional decomposition”)




Write the book
Get it reviewed
Do the suggested changes
Get it published
 Result-oriented (“Object-oriented decomposition”)




Chapter 1
Chapter 2
Chapter 3
Which one is best for managing? Depends on project type:




Development of a prototype
Development of a product
Project team consist of many unexperienced beginners
Project team has many experienced developers
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
11
Developing Work Breakdown Structures


There are several different approaches to develop and display a work
breakdown structure. Each is effective under different circumstances
Approaches to break activities into detail by
 Product component approach

Examples: Design documents, manuals, the running system
 Functional approach

Analysis, design, implementation, integration, testing, delivery, reviews
 Geographical area

Examples: USA team, China team, India team, ...
 Organizational approach

Research, product development, marketing, sales
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
13
When to use what approach

Distributed teams:
 Geographical area approach

Experienced teams:
 Product component approach

Project has mostly beginners or project manager is inexperienced:
 Functional approach

Project is a continuation of previously successful projects, no change
in requirements, no new technology
 Organizational approach

When you choose an approach, stick with it to prevent possible
overlap in categories
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
14
How do you develop a good WBS?

Top down approach:
 Start at the highest, top level activities and systematically develop
increasing levels of detail for all activities.

Brainstorming:
 Generate all activities you can think of that will have to be done and then
group them into categories.

Which one you use depends on
 how familiar you and your team are with the project,
 whether similar projects have successfully been performed in the past, and
 how many new methods and technologies will be used.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
15
The Top Down WBS approach





Specify all activities required for the entire project to be finished
Determine all task required to complete each activity
If necessary specify subactivities required to complete each task
Continue in this way until you have adequately detailed your project.
Approach is good if
 You are or your team is familiar with the problem.
 You have successfully managed a similar project in the past
 You are not introducing new methodologies, methods or tools
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
16
Top-down example: Architecture-centric approach






Work with architect to come up with a tentative top-level design
(software architecture) at the beginning of the project and use this
decomposition to determine the work breakdown structure.
Top-level decomposition can be functional or object-oriented.
This approach is a deviation from traditional practices and may be
feasible in certain domains with emerging standard architectures.
This architecture is used strictly for decomposing the project tasks.
Architecture must be revisited during system design after
requirements analysis.
Project tasks may also be reorganized to reflect the changed
architecture.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
17
The Brainstorming WBS approach


On a single list, write any activities you think will have to be
performed for your project.
Brainstorming means you







Don’t worry about overlap or level of detail
Don’t discuss activity wordings or other details
Don’t make any judgements
Write everything down
Then study the list and group activities into a few major categories
with common characteristics.
If appropriate group activities under a smaller number of tasks
Consider each category you have created and use the top-down WBS
approach to determine any additional activities you may have
overlooked.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
18
Displaying Work Breakdown Structures


Three different formats are usually used
Organization-chart format:
 Effectively portrays an overview of your project and the hierarchical
relationships of different activities and tasks.

Outline format
 Subactivities and tasks are indented

Bubble format
 The bubble in the center represents your project
 Lines from the center bubble lead to activities
 Lines from activities lead to tasks
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
19
Prepare Report
Prepare Report
Prepare
Draft Report
Review
Draft Report
Org-Chart Format
Write
Final Report
Prepare
Final Report
Print
Final Report
1.0 Prepare draft report
2.0 Review draft report
3.0 Prepare final report
3.1 Write final report
3.2 Print final report
Outline Format
Review
Final Report
Review
Draft Report
Prepare
Report
Bubble Format
Review
Draft Report
Modified from Bruegge & Dutoit’s originals
Write
Final Report
Object-Oriented Software Engineering: Using UML, Patterns, and Java
Print
Final Report
20
Best format for displaying WBS?

Org-chart format:
 Often good for a “bird view” of the project (executive summaries,...)
 Less effective for displaying large numbers of activities

Outline format:
 Easier to read and understand if WBS contains many activities

Bubble format:
 Effective for supporting the brainstorming process
 Not so good for displaying work breakdown structures to audiences who are not familiar
with the project.
 Use bubble format to develop the WBS, then turn it into Org-Chart or outline format.

In large projects:
 Use a combination of org-chart and outline formats:


Display activities in org-chart format,
Display subactivities and tasks in outline format.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
21
Heuristics for developing high quality WBS

Involve the people who will be doing the work in the development of the WBS
 In particular involve the developers

Review and include information from work breakdown structures that were
developed for similar projects
 Use a project template if possible

Use more than one WBS approach
 Do project component and functional approach simultaneously
 This allows you often to identify overlooked activities

Make assumptions regarding uncertain activities
 Identify risky activities
 These are often the activities that whose times are hard to estimate

Keep your current work breakdown structure current
Update your WBS regularly
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
22
Heuristic: Use Templates

Try to derive the WBS from a template, either an existing one or one
that you start developing with this project.
 A template reflects the cumulative experience gained from doing
numerous projects of a particular type.
 Using templates can save you time and improve your accuracy

When developing templates, develop them for frequently performed
tasks (reviews, meetings, …). “Checklists”
 Develop and modify your WBS templates from previous projects that
worked, not from plans that looked good.
 Use templates as starting points, not as ending points
 Continually update your templates to reflect the experience gained from
performing different projects.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
23
Heuristic: Develop always more than one WBS

Consider to create more several different hierarchies with different
categories for your work breakdown structure.
 Having two or more different perspectives helps you identify activities you
may overlook.

Good starting point are the following hierarchies:
 Entity-oriented decomposition
 Activity-oriented decomposition

Example: You are running your first object-oriented project.
 Develop a WBS based on the project documents
 Develop a WBS based on the software process activities
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
24
WBS Based on Project Documents
(Entity-oriented)
<<Name>>
Project
Problem
Statement
- Write Introduction
- Write Requirements
- Write Constraints
- ...
Modified from Bruegge & Dutoit’s originals
Project
Agreement
- Write Requirements
- Write Constraints
- Write Acceptance Criteria
- Promise delivery date
RAD
- Write Introduction
- Describe Functional
Model
- Describe Object Model
- Describe Dynamic
Model
...
Object-Oriented Software Engineering: Using UML, Patterns, and Java
SDD
- Write Design Goals
- Write Hardware
Software mapping
-Write boundary
conditions
- Write Data Manageme
- Write Open Issues
...
25
WBS Based on Software Process
(Activity-oriented)
<<Name>>
Project
Project
Initiation
- Establish guidelines
- Formulate requirements
with client
- Establish scenarios
- Write project agreement
Planning
- Determine WBS
- Determine dependencies
between tasks
- Write SPMP
- Assign teams to
subsystems
- Establish project calendar
Analysis
- Brainstorm on
application domain objects
- Develop class diagram
- Partition objects into
boundary, entity and
control objects
- Develop use cases
Design
- Develop Models
- Write code
- Present problems to
coach
- Give status reports
- Write RAD
- Write SDD
- Write ODD
Question: Which activities mentioned in the WBS based on Project documents
is left out in the WBS based on Software Process?
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
26
Heuristic: Identifying Risky activities



When you identify activities for a work breakdown structure, you
can also identify the risks in your project.
Risks are usually associated with “unknown information”.
Unknown information comes in two flavors
 A known unknown: Information that you don’t have but someone else does.

Find out who has the information and determine what the information is.
(Interviews, Phone calls, tasks analysis)
 An unknown unknown: Information that you don’t have because it does not
yet exist.


Develop contingency plans for each of these risks.
These contingency plans need be followed when you find out the information does
not exist.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
27
Choose a single WBS format



Writing the WBS in different formats is good, because it allows you
to identify activities that you may have overlooked
However, after you identify these activities add them to either WBS
Choose a single WBS format to be used in the SPMP and for your
project:
 Nothing confuses people fast than trying to use two different work
breakdown structures to describe the same project.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
30
How Detailed should the WBS be?

Sometimes the activities are not clear at all, especially in software
projects:
 Unclear requirements and/or changing requirements
 Dependency on technology enablers that appear or are promised to appear
after project kickoff
 Simultaneous development of hardware and software (“concurrent
engineering”)

A project plan, especially for an innovative software project, should
not address details beyond 3 months.
 Even for the first 3 months project activities might not all be detailable,
for example when the requirements are unclear or change or introduction
of technology enablers is expected.

How should we describe a WBS for a longer project?
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
31
Doing a WBS for Long-Term Projects


When developing a work breakdown structure for a long-term
project (longer than 3 months), introduce at least two phases
Phase 1 (3 months): Plan your WBS in detail
 Here list all activities that take two weeks or less to complete

Phase 2, Phase 3, … (n-months) Plan the WBS for these phases in
less and less detail
 Here list activities that you estimate will take between one and two
months

At the end of phase 1, revise the phase 2 activities to the two week
level for the next 3 months.
 Modify any future activities as necessary based on the results of your first
three months work.

Continue to revise the SPMP this way throughout the project.
(SPMP as an “evolving” document)
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
32
Outline

Work breakdown structure
 What is it?
 Building a work breakdown structure

Project scheduling
 Dependency diagrams
 Estimating task durations

Project organization
 Types of organizations
 Communications infrastructure


Software Project Management Plan (SPMP)
Overview of project control activities
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
33
From the WBS to the Dependency Diagram

The work breakdown structure does not show any temporal
dependence among the activities/tasks
 Can we excavate before getting the permit?
 How much time does the whole project need if I know the individual times?

What can be done in parallel?
 Are there any critical actitivites, that can slow down the project significantly?

Temporal dependencies are shown in the dependency diagram
 Nodes are activities
 Lines represent temporal dependencies
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
34
Dependency Diagrams (Overview)




Dependency diagrams consist of 3 elements
Event (also called milestone): A significant occurrence in the life of a project.
Activity: Work required to move from one event to the next.
Span time ( also called duration or elapsed time): The actual calendar time required
to complete an activity.
 Span time parameters: people’s availability, parallelizability of the activity, availability of
nonpersonnel resources, ….


Dependency Diagram are drawn as a connected graph of nodes and arrows.
2 commonly used diagram notations to display dependency diagrams:
 1) Activity-on-the-arrow (Mealy automaton)
 2) Activity-in-the-node (Moore automaton)
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
35
Why Dependency Diagrams?

Example:
 You are assigned a project consisting of 10 activities which take one week
each to be completed.
 How long does the project take?


When projects have more than 15-20 activities, one cannot to
compute the schedule in the head any more.
Dependency Diagrams are a formal notation to help in the
construction and analysis of complex schedules
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
36
1) Activity-on-the-arrow Diagram Notation
Activity
A
Event (Milestone
or Deliverable)
RAD
B
t
Event (Milestone
or Deliverable)
Span Time
System Design
SDD
T1 = 4 weeks
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
37
PERT





PERT is an activity-on-the-arrow notation
PERT = Program Evaluation and Review Technique
Developed in the 50s to plan the Polaris weapon system in the USA.
PERT allows to assign optimistic, pessimistic and most likely
estimates for the span times of each activity.
You can then compute the probability to determine the likelihood that
overall project duration will fall within specified limits.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
38
2) Activity-in-the-node Diagram Notation
Activity
A Node is either an event or an activity.
Distinction: Events have span time 0
A
tA = 0
B
tB = 0
C
tC = 0
Event (Milestone
or Deliverable)
Event (Milestone
or Deliverable)
Milestone boxes are often highlighted by double-lines
RAD
available
t=0
Modified from Bruegge & Dutoit’s originals
System Design
t = 2 weeks
Object-Oriented Software Engineering: Using UML, Patterns, and Java
SDD
available
t=0
39
Example of an Activity-in -the -Node Diagram
Activity 1
Activity 2
t1 = 5
t2 = 1
Start
t=0
End
t=0
Activity 3
t3 = 1
Modified from Bruegge & Dutoit’s originals
Activity 4
Activity5
t4 = 3
5= 2
Object-Oriented Software Engineering: Using UML, Patterns, and Java
40
What do we do with these diagrams?

Compute the project duration
Determine activities that are critical to ensure a timely delivery

Analyse the diagrams

 to find ways to shorten the project duration
 To find ways to do activities in parallel

2 techniques are used
 Forward pass (determine critical paths)
 Backward pass (determine slack time)
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
41
Definitions: Critical Path and Slack Time

Critical path:
 A sequence of activities that take the longest time to complete
 The length of the critical path(s) defines how long your project will take to
complete.

Noncritical path:
 A sequence of activities that you can delay and still finish the project in the
shortest time possible.

Slack time:
 The maximum amount of time that you can delay an activity and still
finish your project in the shortest time possible.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
42
Example of a critical path
Activity 1
Activity 2
t1 = 5
t2 = 1
Start
t=0
End
t=0
Activity 3
t3 = 1
Activity 4
Activity5
t4 = 3
t55 = 2
Critical path in bold face
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
43
Definitions: Start and Finish Dates

Earliest start date:
 The earliest date you can start an activity

Earliest finish date:
 The earliest date you can finish an activity

Latest start date:
 The latest date you can start an activity and still finish the project in the
shortest time.

Latest finish date:
 The latest date you can finish an activity and still finish the project in the
shortest time.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
44
2 Ways to Analyze Dependency Diagrams

Forward pass: Goal is the determination of critical paths
 Compute earliest start and finish dates for each activity
 Start at the beginning of the project and determine how fast you can
complete the activites along each path until you reach the final project
milestone.

Backward pass: Goal the determination of slack times
 Compute latest start and finish dates activity
 Start at the end of your project, figure out for each activity how late it can
be started so that you still finish the project at the earliest possible date.

To compute start and finish times, we apply 2 rules
 Rule 1: After a node is finished, we can proceed to the next node(s) that is
reachable via a transition from the current node.
 Rule 2: To start a node all nodes must be complete from which transitions
to that node are possible.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
45
Forward Path Example
Activity 1
Activity 2
t1 = 5
t2 = 1
Start
t=0
End
t=0
Project Duration = 7
Activity 3
tA3 = 1
Activity
A1
A2
A3
A4
A5
Earliest Start(ES)
Start of week 1
Start of week 6
Start of week 1
Start of week 2
Start of week 6
Modified from Bruegge & Dutoit’s originals
Activity 4
Activity5
tA4 = 3
t5 = 2
Earliest Finish(EF)
End of week 5
End of week 6
End of week 1
End of week 4
End of week 7
Object-Oriented Software Engineering: Using UML, Patterns, and Java
46
Backward Path Example
Activity 1
Activity 2
t1 = 5
t2 = 1
Start
t=0
End
t=0
Project Duration = 7
Activity 3
tA3 = 1
Activity
A1
A2
A3
A4
A5
Latest Start(LS)
Start of week 1
Start of week 7
Start of week 2
Start of week 3
Start of week 6
Modified from Bruegge & Dutoit’s originals
Activity 4
Activity5
tA4 = 3
t5 = 2
Latest Finish(LF)
End of week 5
End of week 7
End of week 2
End of week 5
End of week 7
Object-Oriented Software Engineering: Using UML, Patterns, and Java
47
Computation of slack times

Slack time ST of an activity A:
 STA = LSA - ESA
 Subtract the earliest start date from the latest start date for each activity
Example: STA4 = 3 - 2 = 1
Slack times on the same path influence each other.
Example: When Activity 3 is delayed by one week, activity 4 slack
time becomes zero weeks.
Activity 1
Activity
A1
A2
A3
A4
A5
Slack time
0
1
1
1
0
Modified from Bruegge & Dutoit’s originals
Activity 2
Activity 2
tt2 =
1
2= 1
t1 = 5
Start
t=0
End
t=0
Activity 3
Activity 4
Activity5
tA = 1
tA4 = 3
t5 = 2
Object-Oriented Software Engineering: Using UML, Patterns, and Java
48
Path types in dependency graphs



Critical path: Any path in a dependency diagram, in which all
activities have zero slack time.
Noncritical path: Any path with at least one activity that has a
nonzero slack time.
Overcritical path: A path with at least one activity that has a negative
slack time.
 Overcritical paths should be considered as serious warnings: Your plan
contains unreal time estimates


Any dependency diagram with no fixed intermediate milestones has at
least one critical path.
A project schedule with fixed intermediate milestones might have no
critical path
 Example: The analysis review must be done 1 month after project start, the
estimated time for all activities before the review is 3 weeks.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
49
Frequently used formats for dependency graphs

Milestone View (“Key-Events report”):
 A table that lists milestones and the dates on which you plan to reach
them.

Activities View:
 A table that lists the activities and the dates on which you plan to start and
end them

Gantt chart View:
 A graphical illustrating on a timeline when each activity will start, be
performed and end.

Combined Gantt Chart and Milestone View:
 The Gantt Chart contains activities as well as milestones.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
50
Key-Events Report (example)
Date
August 26
October 16
October 26
November 7
November 20
Nov 26
Dec 11
Milestone
Project Kickoff (with Client)
Analysis Review
System Design Review
Internal Object Design Review
Project Review (with Client)
Internal Project Review
Acceptance Test (with Client)
Good for introduction of SPMP and high executive briefings
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
51
Activities View
Date
Jul 17-Aug 23
Aug 26 - Sep 24
Sep 11-Oct 8
Oct 9 - Oct 26
Oct 28-Nov 7
Nov 8 - Nov 20
Nov 22 - Dec 4
Dec 4 - Dec 10
Dec 11- Dec 18
Project Phases
Preplanning Phase
Project Planning
Requirements Analysis
System Design
Object Design
Implementation & Unit Testing
System Integration Testing
System Testing
Post-Mortem Phase
Good during developer meetings
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
52
Gantt Chart
Activity 1
Activity 2
Activity 3
Activity 4
Activity 5
0
Easy to read
Modified from Bruegge & Dutoit’s originals
1
2
3
4
5
6
7
Time (in weeks after start)
Object-Oriented Software Engineering: Using UML, Patterns, and Java
53
Gantt Chart
with milestones
Project Start
Activity 1
Activity 2
Activity 3
Design Review
Activity 4
Activity 5
Project Finish
0
1
Good for reviews.
Modified from Bruegge & Dutoit’s originals
2
3
4
5
6
7
Time (in weeks after start)
Object-Oriented Software Engineering: Using UML, Patterns, and Java
54
Two Types of Gantt Charts

Person-Centered View

 To determine people‘s load
Joe
A1
A2
Activity-Centered View
 To identify teams working
together on the same tasks
A3
A1
Joe, Toby
Mary
Toby
A1
Clara
A3
A3
A2
Joe
A3
Clara, Toby, Joe
Time
Time
Choose one view, stay with it. Usually base the view on the WBS structure
Managing Experienced Teams: Person-centered view
Managing Beginners: Activity oriented view
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
55
Tools support for Establishing Schedules

Tool support for
 Graphical user interface for entering activity data
 Automatic computation of critical paths
 Multiple views (PERT, Gantt, table views) and switching between these
views

Many products available. Examples
 Fast Track (http://www.aecsoft.com)

Main view: Gantt Charts
 Microsoft Project


PERT Charts, Gantt Charts, combined Milestone/Gantt Charts
Tool use and training beyond the scope of this class
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
56
How to develop an Initial Project Schedule


Identify all your activities (reuse a template if possible)
Identify intermediate and final dates that must be met
 Assign milestones to these dates





Identify all activities and milestones outside your project that may
affect your project’s schedule
Identify “depends on” relationships between all these identified
activities
Draw a dependency diagram for all identified activities and
relationships
Analyze the diagram to determine critical paths and slack times of
noncritical paths.
Example: Establish a schedule for system integration testing
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
58
Determining 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
activitity identifies more tasks
and modifies existing ones
Modified from Bruegge & Dutoit’s originals

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: Using UML, Patterns, and Java
68
How to reduce the planned project time

Recheck the original span time estimates
 Ask other experts to check the estimates
 Has the development environment changed? (batch vs interactive systems, desktop
vs laptop development)

Hire more experienced personnel to perform the activities
 Trade-off: Experts work fast, but cost more

Consider different strategies to perform the activities
 Consider to Buy a work product instead of building it (Trade-off: Buy-vs-build)
 Consider extern subcontractor instead of performing the work work internally

Try to find parallelizable activites on the critical path
 Continue coding while waiting for the results of a review
 Risky activity, portions of the work may have to be redone.

Develop an entirely new strategy to solve the problem
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
69
Typical Mistakes when Developing Schedules


The “Backing in” Mistake
Using Fudge Factors
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
70
The “Backing in” Mistake

Definition “Backing In”:
 You start at the last milestone of the project and work your way back
toward the starting milestone, while estimating durations that will add up
to the amount of the available time

Problems with Backing in:
 You probably miss activities because your focus is on meeting the time
constraints rather than identifying the required work
 Your span time estimates are based on what you allow activites to take, not
what they actually require
 The order in which you propose activities may not be the most effective
one.

Instead, start with computing all the required times and then try to
shorten the project duration
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
71
Using Fudge Factors

Parkinson formulated this law for project completion:
 Work tends to expand to fill the time allotted for it.

Fudge factor:
 A fudge factor is the extra amount of time you add to your best estimate of
span time “just to be safe”.
 Example: Many software companies double their span time estimates.

Don’t use fudge factors because of Parkinson’s law.
 If an activity takes 2 weeks, but you add a 50% fudge factor, chances are
almost zero that it will be done in less then 3 weeks.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
72
Heuristics for dealing with time
1. First Set the Project Start Time =>
 Determines the planned project time
 Determine the critical path(s)
2. Then try to reduce the planned project time
 If you want to get your project done in less time, you need to consider
ways to shorten the aggregate time it takes to complete the critical path.

Avoid fudge factors
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
73
Outline

Work breakdown structure
 What is it?
 Building a work breakdown structure

Project scheduling
 Dependency diagrams
 Estimating task durations

Project organization
 Types of organizations
 Communications infrastructure


Software Project Management Plan (SPMP)
Overview of project control activities
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
75
Organization


Definition Organization: A set of organizational units and their
different relationships with each other.
Organizational units can be organized according to many different
categories, for example by function or by project type. Typical
examples of organizational units:
 Functional organization: Research, Development, Marketing, Sales
 Project organization: Project 1, Project 2, ….

A organization usually has 3 different types of relationships between
organizational units.
 Reporting structure: To report status information
 Decision structure: To propagating decisions
 Communication structure: To exchange of information
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
76
Functional Organization


Definition: In a functional organization participants are grouped
into so-called departments, each of which addresses a function.
Examples of departments:
 Traditional businesses: Research, development, production, sales, finance.
 In software companies the departments correspond to the activities in the
software process: Analysis, design, integration, testing departments.

Key properties:
 Projects are usually pipelined through the departments of a functional
organization. The project starts in research, then it moves to development,
then it moves to production, ….
 Only a few participants are involved in the complete project.
 Separate departments often address the same cross-functional needs
(Examples: configuration management, IT infrastructure)
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
78
Properties of Functional Organizations

Advantages:
 Members of a department have a good understanding of the functional area they
support.
 Departments don‘t compete with another to get the support of their support
teams

Disadvantages:
 Because each department has its own support team, different work procedures
and reporting systems are the rule.
 It is difficult to make major investments in equipment and facilities.



Example: Two departments with a budget of 50,000 Euro each need a printer that costs
100,000 Euro.
Both need only 50% of the maximum capacity.
Neither department can buy it, because they don‘t have sufficient funds.
 High chance for overlap or duplication of work among departments
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
80
Project Organization


In a project organization participants are grouped into projects,
each of which has a problem to be solved within time and budget.
Key properties:
 Teams are assembled for a project as it is created. Each project has a
project leader.
 All participants are involved in the complete project.
 Teams are disassembled when the project terminates
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
81
Properties of Project Organizations

Advantages
 Very responsive to new project requests (because the project is newly
established and can be tailored around the problem)
 New people can be hired/selected who are very familiar with the problem
or who have special capabilities.
 There is no waste of staff workload

Disadvantages:
 Teams cannot be assembled rapidly. Often it is difficult to manage the
staffing/hiring process.
 Because there are “no predefined lines”, roles and responsibilities need to
be defined at the beginning of the project
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
82
Matrix Organization


In a matrix organization, participants from different departments of the functional
organizastion are assigned to work on projects as they are created.
The project manager and team members may be assigned to the project for <= 100 %
of their time
Executive Office
Finance
Project A
Production
Sales
Marketing
Participants of Project A
Project B
Project C
Modified from Bruegge & Dutoit’s originals
Participants of Project B
Object-Oriented Software Engineering: Using UML, Patterns, and Java
83
Properties of Matrix Organizations

Advantages:
 Teams for projects can be assembled rapidly
 Scarce expertise can be applied to different projects as needed
 Consistent work and reporting procedures can be used for projects of the
same type.

Disadvantages:
 Team members usually are not familiar with each
 Team member have different working styles
 Team members must get used to each other
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
84
New Challenges in Matrix Organizations

Team members must respond to two different bosses with different focus:
 Focus of the functional manager: Assignments to different projects, performance
appraisal
 Focus of the project manager: Work assignments, project team support

Team members working on multiple projects have competing demands for their
time
 Team members working on more than one project have even more project
members to report to
 Some people who have claim on the team member’s time may be at similar levels
in the organization’s hierarchy

Multiple work procedures and reporting systems are used by different team
members
 Development of common procedures needs to be addressed at project kickoff time
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
85
When to use a Functional Organization

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
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
86
When to Use a Project or Matrix Organization

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
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
87
Metamodel for Organizations
Functional
Organization
Project
Organization
Matrix
Organization
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
88
Key Roles in Organizations




Project Manager: The person ultimately responsible for the
successful completion of the project
Project Team Member: Participants who are responsible for
performing individual activities and tasks (in a project or matrix
organization)
Functional Manager: The team member‘s supervisor in the
department (in a functional organization)
Upper management: People in charge of the departments or
projects
In the following we focus only on roles in project and matrix
organizations
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
89
Relationships between Roles



Organizations can have many different types of associations
between roles
The three most important associations for project organizations are:
Reporting, decision making and communicating
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).
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
90
Hierarchical Organization



Often also called centralized organization. Examples: Military, church, traditional
businesses.
Key property: The organization has a tree structure. Decisions are made at the
root and communicated to the leaf nodes. The decision association is also used for
reporting and communication.
Advantages:
 Centralized control over project selection
 One set of management and reporting procedures for all project participants
across all projects
 Established working relationships among people
 Clearly established lines of authority to set priorities and resolved conflicts
 Authority to pressure people to honor their action items
 Clearly defined career path
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
93
Hierarchical Project Organization
Information Flow
Chief Executive
Control Flow
First Level Manager
(“Front-Line Manager”)
A
B
Project Members
A wants to talk to B: Complicated Information Flow
B wants to make sure A does a certain change: Complicated Controlflow
Basis of organization:
Complicated information and control flow
across hierarchical boundaries
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
94
Disadvantages of Hierarchical Organizations

Slow response time
 The process of evaluating and approving change requests often takes too
long because of long reporting/decision lines.

Difficult to manage the workload of the people:
 People are assigned fulltime to the organization, but projects don’t’ come
in a smooth stream.
 Project request might not require the people who are available or their
expertise.

Unfamiliarity with application or solution domain area
 People are usually hired for their technical proficiency in a specialty that
the organization normally performs.
 They often have only limited experience, if the problem to be solved is
outside of their field of expertise.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
96
Nonhierarchical Organizations

Key property: The organization has a general graph structure with
different edges for the decision, reporting and communication flows.
Decisions can be made at various nodes in the graph.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
97
Nonhierarchical Project Organization
Project
Leader
Coaches
Subsystem Team
A
Subsystem Team
Subsystem Team
B
Team
Members
A wants to talk to B: Communication Flow
B wants to make sure A does a certain change: Decision Flow
Basis of organization:
Nonlinear information flow across dynamically formed units
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
98
Observations on Organizational Structures

Hierarchical structure
 “Reports”, “Decides” and “Communicates-With” all mapped on the same
association
 Does 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
 Cuts down on bureaucracy
 Reduces development time
 Decisions are expected to be made at each level
 Hard to manage
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
100
Heuristics for Project Managers
1. Create team identity
 Clarify team vision and working relationships
 Define team procedures (meeting management, configuration management, system
integration strategy)
 Clarify each participant‘s authority
 Make sure your team is functioning
 Be sure only one person is assigned as project manager
2. Create team member buy-in
 Get commitment to the project goals (tough in matrix environment)
 Get to know other people‘s style
3. Get support from the environment
 Get a project champion (for example a power promoter)
4. Develop general procedures for
 Conflict resolution
 Communication between teams and project leaders, communication with upper
management and for communication with the client
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
101
Outline

Work breakdown structure
 What is it?
 Building a work breakdown structure

Project scheduling
 Dependency diagrams
 Estimating task durations

Project organization
 Types of organizations
 Communications infrastructure


Software Project Management Plan (SPMP)
Overview of project control activities
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
102
IEEE Std 1058: Standard for Software Project
Management Plans (SPMP)

What it does:
 Specifies the format and contents of software project management plans.
 It provides a standard set of abstractions for a project manager or a whole
organization to build its set of practices and procedures for developing
software project management plans
 Abstractions: Project, Function, Activities, Tasks

What it does not do:
 It does not specify the procedures or techniques to be used in the
development of the plan
 It does not provide examples .
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
103
Software Project Management Plan Template







0. Front Matter
1. Introduction
2. Project Organization
3. Managerial Process
4. Technical Process
5. Work Elements, Schedule, Budget
Optional Inclusions
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
104
Outline

Work breakdown structure
 What is it?
 Building a work breakdown structure

Project scheduling
 Dependency diagrams
 Estimating task durations

Project organization
 Types of organizations
 Communications infrastructure


Software Project Management Plan (SPMP)
Overview of project control activities
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
105
Project Control



Project management does not end with the creation of the project plan.
Project management is responsible for project control during the steady state phase
of the project.
Project control activities
 Project tracking


Development teams are kept accountable for executing their assigned tasks according
to plan.
The plan must be evolved as new tasks are uncovered or estimated tasks durations are
corrected.
 Risk monitoring


Contingency plans are drawn up as risks become serious threats to the successful
completion of the project.
Examples include: shifting priorities, reorganizing teams, redefining the problem
statement, modifying the project schedule, etc.
 Quality control

Software quality metrics are tracked to ensure that defects are being found.
 Configuration management
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
106
Identifying When a Project Goes Off-Track

Determine what went wrong: Why is your project got off
track?
 Behind schedule
 Overspending of resource budgets
 Not producing the desired deliverables

Identify the Reason(s):







You are new on the job, this is your first project, and you made mistakes
Key people left the teams or new ones are joining it
Key people lost interest or new ones entered the picture
The requirements have changed
New technology has emerged
The business objectives have changed
Organizational priorities have shifted (for example after a merger)
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
107
Heuristics to get a project back on track

Reaffirm your plan





Refocus team direction and commitment





Reaffirm your key people
Reaffirm your project objectives
Reaffirm the activities remaining to be done
Reaffirm roles and responsibilities
Revise estimates, develop a viable schedule
Modify your personnel assignments
Hold a midproject kickoff session
Closely monitor and control performance for the remainder of the project
Get practical experience
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
108
Summary

Software engineering is a problem solving activity
 Must develop quality software for a complex problem within a limited time while
things are changing







We need system models (object models, dynamic models, etc.) and management
models (WBS, dependency diagrams, issue models, etc.)
WBS: Set of activities to do (“use cases”)
Dependency diagram: identify dependency relationships between activities
Schedule: Dependency diagram with estimates of task durations
Development teams may be organized by function or by project
Communication infrastructure is also needed for reporting, decision propagation,
and exchanging information
Project control is the project management role during the steady state portion of the
software project.
Modified from Bruegge & Dutoit’s originals
Object-Oriented Software Engineering: Using UML, Patterns, and Java
109