INFO 420Chapter 6 1 SW Project Management WBS and Project Estimation INFO 420 Glenn Booker.

32
INFO 420 Chapter 6 1 SW Project Management WBS and Project Estimation INFO 420 Glenn Booker

Transcript of INFO 420Chapter 6 1 SW Project Management WBS and Project Estimation INFO 420 Glenn Booker.

INFO 420 Chapter 6 1

SW Project ManagementWBS and Project Estimation

INFO 420Glenn Booker

Chapter 6 2INFO 420

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

Chapter 6 3INFO 420

Project time management

This is formally (PMBOK) known as project time management, which includesActivity definition – what tasks are needed

to produce project scope deliverablesActivity sequencing – put them in orderActivity resource estimation – who needs

to perform the tasks? How many of them?

Chapter 6 4INFO 420

Project time management

Activity 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

For now we’ll focus on activity definition and estimation

Chapter 6 5INFO 420

WBS

A Work Breakdown Structure (WBS) gives a hierarchical structure to project tasksAllows more detail to be added later

The WBS decomposes the work to be done to accomplish each deliverableEach smaller unit is a work package, which

may have a person assigned to manage it

Chapter 6 6INFO 420

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)

Milestone – end of phase review (follows e.g. 1.4)

Chapter 6 7INFO 420

WBS Overview

Each phase might have many deliverablesThe 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 phaseMilestones have zero durationMilestones are great focal points for the team

Chapter 6 8INFO 420

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 they still focus on producing deliverables

Chapter 6 9INFO 420

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

Chapter 6 10INFO 420

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

Chapter 6 11INFO 420

Milestones

Milestones also provide a stopping point to reflect on the project’s progressPhase milestones allow consideration if

continuing the project is really a good ideaMilestones are a risk management toolBy getting customer (sponsor?) involvement,

they also help manage expectations and get an outside quality review

Chapter 6 12INFO 420

WBS guidelines

Some general rules to help produce a better WBSWBS is deliverable oriented

What do these tasks produce?

WBS supports the MOV All lower level tasks should be enough to

complete the next higher level task

Chapter 6 13INFO 420

WBS guidelines

Pick a good consistent level of detailGet 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

Chapter 6 14INFO 420

Estimation

After defining the tasks, next estimate how much effort is needed for eachThis is the hardest part of software project

management Often a blend of approaches is used –

don’t rely on one methodEggs, one basket, that problem

Chapter 6 15INFO 420

Estimation

We’ll look at several approaches for doing task estimationGuesstimatingDelphi techniqueTime boxingTop-down estimatingBottom-up estimating

Chapter 6 16INFO 420

Guesstimating

Often estimations are made without any formal basis, so we politely call them guesstimatesDon’t do this!Often fails to account for key tasks, produces

optimistic estimates, or may be flat out wrong

Chapter 6 17INFO 420

Delphi technique

This is an average-expert-guess-consensus method for estimating1. Collect some experts2. Ask them to estimate the tasks3. Compare the estimates4. Ask them why some estimates were much

higher or lower than the others

Chapter 6 18INFO 420

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

Chapter 6 19INFO 420

Time boxing

Time boxing, in this context, refers to setting a fixed duration for the taskGet as much done as possible during that

time boxTime’s up? You’re done.

Often used when strict time constraints exist, but scope may suffer

Chapter 6 20INFO 420

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

Chapter 6 21INFO 420

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

Chapter 6 22INFO 420

Other approaches

Analogous estimation estimates tasks based on similar past projectsOften 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

Chapter 6 23INFO 420

Brooks’ Law

“Adding people to a late software project makes it later”-- from the legendary

Mythical Man-Month book by Frederick Brooks

Why?

Chapter 6 24INFO 420

Metrics

Metrics just refers to measuring something In the context of software development,

we want to measure important aspects of what we’re developingSizeEffort (hence cost)ScheduleQuality (defects)

Chapter 6 25INFO 420

Size

The two main measures of software size are Lines of Code (LOC) or function pointsLOC 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

Chapter 6 26INFO 420

Function points

Function points are an internationally recognized way to measure system sizeBased on counting how many and how complex

parts of the system will be Types of parts are

Internal logical filesExternal interface files

Chapter 6 27INFO 420

Function points

External inputsExternal outputsExternal inquiries

Each part is measured on a hi/med/lo complexity scale, and has function points assigned

Then add up the raw function points

Chapter 6 28INFO 420

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 can estimate equivalent LOC from FP

Chapter 6 29INFO 420

COCOMO

Several tools have been developed for estimating software projects

A famous and free one is COCOMOFirst published by Barry Boehm (USC, 1981)Based on the type and size of product, team

expertise, and many other factorsNot terribly accurate, but better than a guess

Chapter 6 30INFO 420

Heuristics

A heuristic is a rule of thumb, just sounds betterSuch as my kilo-to-lb scaling rule

Lots of heuristics are available, but their accuracy and relevance to your project is questionable

Chapter 6 31INFO 420

Estimation tools

There are other estimation tools out thereSLIMCost*XpertEtc.

None are as accurate as having historic data, but they’re better than a wild guess

Chapter 6 32INFO 420

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