Transcript Software Project Management

SW Project Management
WBS and Project Estimation
INFO 420
Dr. Jennifer Booker
INFO 420
Chapter 6
1
Time for the details…
Now we have outlined the project in its
charter, clarified it with a scope
description, and thought about the right
organization needed to manage it
 Time to figure out the details of what is
needed to make this project work

INFO 420
Chapter 6
2
Project time management

This is formally (PMBOK) known as
project time management, which includes
definition – what tasks are needed
to produce project scope deliverables
 Activity sequencing – put them in order
 Activity resource estimation – who needs
to perform the tasks? How many of them?
 Activity
INFO 420
Chapter 6
3
Project time management
duration estimation – calendar time
for each task
 Schedule development – put together a
schedule with all the above information in it
 Schedule control – define processes to
control changes to the schedule
 Activity

For now we’ll focus on activity definition
and estimation
INFO 420
Chapter 6
4
WBS

A Work Breakdown Structure (WBS) gives
a hierarchical structure to project tasks
 Allows

more detail to be added later
The WBS decomposes the work to be
done to accomplish each deliverable
 Each
smaller unit is a work package, which
may have a person assigned to manage it
INFO 420
Chapter 6
5
WBS Overview
Since the scope defined the deliverables,
the WBS’ work packages can each be
focused on creating some deliverable
 Project (task number 0)

 [for

each] Phase (tasks 1.0, 2.0, 3.0, …)
[for each] Deliverable (tasks 1.1, 1.2, 1.3, 2.1, …)
Task(s) to create deliverable (tasks 1.1.1, 1.1.2, etc.
 Milestone - Approval of deliverable (follows task, 1.1.3)


INFO 420
Milestone – end of phase review (follows e.g. 1.4)
Chapter 6
6
WBS Overview

Each phase might have many deliverables
 The
number of tasks to create a deliverable
could be from one to dozens

Milestones are major decision points,
typically to approve a deliverable, or
approve the end of a phase
 Milestones
have zero duration
 Milestones are great focal points for the team
INFO 420
Chapter 6
7
WBS Overview
Tasks associated with the SDLC typically
are grouped into life cycle phases or
iterations or time boxes
 Some support tasks for project processes
might run throughout the project (project
management, CM, risk management, etc.)

 But
INFO 420
they still focus on producing deliverables
Chapter 6
8
WBS Overview

Some deliverables could entail many
individual items, such as test results, or
documentation, or logical design
 It’s
up to you to determine exactly what is
needed for that project to fulfill that category
of deliverable – a key judgment call
 Then define the steps needed to produce and
approve each deliverable
INFO 420
Chapter 6
9
Naming tasks

For everything below the Phase level in
the WBS, start task and milestone names
with a verb
 “Data
Flow Diagram” doesn’t tell me if you’re
creating it, reviewing it, getting it approved,
updating it, or something else
 The package level task might be to “Develop
Data Flow Diagram” for example
INFO 420
Chapter 6
10
Milestones

Milestones also provide a stopping point
to reflect on the project’s progress
 Phase
milestones allow consideration if
continuing the project is really a good idea
 Milestones are a risk management tool
 By getting customer (sponsor?) involvement,
they also help manage expectations and get
an outside quality review
INFO 420
Chapter 6
11
WBS guidelines

Some general rules to help produce a
better WBS
 WBS

What do these tasks produce?
 WBS

INFO 420
is deliverable oriented
supports the MOV
All lower level tasks should be enough to
complete the next higher level task
Chapter 6
12
WBS guidelines
 Pick
a good consistent level of detail
 Get experts to help develop the WBS

Who knows what tasks are really needed?
 Keep
track of lessons learned to develop a
better WBS the next time
INFO 420
Chapter 6
13
Estimation

After defining the tasks, next estimate how
much effort is needed for each
 This
is the hardest part of software project
management

Often a blend of approaches is used –
don’t rely on one method
 Eggs,
INFO 420
one basket, that problem
Chapter 6
14
Estimation

We’ll look at several approaches for doing
task estimation
 Guesstimating
 Delphi
technique
 Time boxing
 Top-down estimating
 Bottom-up estimating
INFO 420
Chapter 6
15
Guesstimating

Often estimations are made without any
formal basis, so we politely call them
guesstimates
 Don’t
do this!
 Often fails to account for key tasks, produces
optimistic estimates, or may be flat out wrong
INFO 420
Chapter 6
16
Delphi technique

This is an average-expert-guessconsensus method for estimating
 1.
Collect some experts
 2. Ask them to estimate the tasks
 3. Compare the estimates
 4. Ask them why some estimates were much
higher or lower than the others
INFO 420
Chapter 6
17
Delphi technique
 5.
Repeat steps 2-4 until the estimates are
fairly close
 6. Average the estimates, and use that for
your answer

Sounds dopey?
 Maybe,
but it’s fairly accurate, though time
consuming to generate
INFO 420
Chapter 6
18
Time boxing

Time boxing, in this context, refers to
setting a fixed duration for the task
 Get
as much done as possible during that
time box
 Time’s up? You’re done.

Often used when strict time constraints
exist, but scope may suffer
INFO 420
Chapter 6
19
Top-down estimating

Often projects are given a broad budget
($X and Y months)
 Can
use this to break down how much time
and effort each phase gets, and allocate effort
to tasks accordingly
 McConnell (ISBN 1556159005) has guidance on
the percent of a project’s effort and schedule
devoted to each phase; or see heuristics
INFO 420
Chapter 6
20
Bottom-up estimating
Many projects are estimated from the
bottom up, i.e. estimate each task
individually, and add them up!
 Often exceeds the overall budget for a
project, so top-down and bottom-up are
both used to find a happy medium

INFO 420
Chapter 6
21
Other approaches

Analogous estimation estimates tasks
based on similar past projects
 Often

very accurate, but needs history!
Personally, I’ve noted that estimates follow
a kilo-to-lb scaling rule
 If
you know how long a task should take,
double it and add a little more
INFO 420
Chapter 6
22
Brooks’ Law

“Adding people to a late software project
makes it later”
 --
from the legendary Mythical Man-Month
book by Frederick Brooks

Why?
INFO 420
Chapter 6
23
Metrics
Metrics just refers to measuring something
 In the context of software development,
we want to measure important aspects of
what we’re developing

 Size
 Effort
(hence cost)
 Schedule
 Quality (defects)
INFO 420
Chapter 6
24
Size

The two main measures of software size
are Lines of Code (LOC) or function points
 LOC
has the strongest correlation to
development time and effort. Period.

Need to define consistent rules for ‘what is a LOC’
 Function
points are a language-independent
measure of system complexity and size
INFO 420
Chapter 6
25
Function points

Function points are an internationally
recognized way to measure system size
 Based
on counting how many and how
complex parts of the system will be

Types of parts are
 Internal
logical files
 External interface files
INFO 420
Chapter 6
26
Function points
 External
inputs
 External outputs
 External inquiries
Each part is measured on a hi/med/lo
complexity scale, and has function points
assigned
 Then add up the raw function points

INFO 420
Chapter 6
27
Function points

Assess 14 general system characteristics
(GSC) on a scale from 0 to 5 (not present
to strong influence)
 The
GSC score contributes to an adjustment
factor, which is multiplied by the raw total
function point count

Got that?
 Or
INFO 420
can estimate equivalent LOC from FP
Chapter 6
28
COCOMO
Several tools have been developed for
estimating software projects
 A famous and free one is COCOMO

 First
published by Barry Boehm (USC, 1981)
 Based on the type and size of product, team
expertise, and many other factors
 Not terribly accurate, but better than a guess
INFO 420
Chapter 6
29
Heuristics

A heuristic is a rule of thumb, just sounds
better
 Such

as my kilo-to-lb scaling rule
Lots of heuristics are available, but their
accuracy and relevance to your project is
questionable
INFO 420
Chapter 6
30
Estimation tools

There are other estimation tools out there
 SLIM
 Cost*Xpert
 Etc.

None are as accurate as having historic
data, but they’re better than a wild guess
INFO 420
Chapter 6
31
So what’s the best way to
estimate?
There is no one answer; that’s why this is
the hardest part of software management!
 Try several approaches, and throw out
outliers
 Be wary of adjusting estimates to get ‘the
right answer’ to make your boss happy

INFO 420
Chapter 6
32