SW Project Management WBS and Project Estimation - PowerPoint PPT Presentation

Loading...

PPT – SW Project Management WBS and Project Estimation PowerPoint presentation | free to download - id: 56362a-NjFiM



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

SW Project Management WBS and Project Estimation

Description:

SW Project Management WBS and Project Estimation INFO 420 Glenn Booker Time for the details Now we have outlined the project in its charter, clarified it with a ... – PowerPoint PPT presentation

Number of Views:70
Avg rating:3.0/5.0
Slides: 33
Provided by: gle991
Learn more at: http://cci.drexel.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SW Project Management WBS and Project Estimation


1
SW Project ManagementWBS and Project Estimation
  • INFO 420
  • Glenn Booker

2
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

3
Project time management
  • This is formally (PMBOK) known as project time
    management, which includes
  • Activity 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?

4
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 well focus on activity definition and
    estimation

5
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

6
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)

7
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

8
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

9
WBS Overview
  • Some deliverables could entail many individual
    items, such as test results, or documentation, or
    logical design
  • Its 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

10
Naming tasks
  • For everything below the Phase level in the WBS,
    start task and milestone names with a verb
  • Data Flow Diagram doesnt tell me if youre
    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

11
Milestones
  • Milestones also provide a stopping point to
    reflect on the projects 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

12
WBS guidelines
  • Some general rules to help produce a better WBS
  • WBS 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

13
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

14
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 dont rely
    on one method
  • Eggs, one basket, that problem

15
Estimation
  • Well look at several approaches for doing task
    estimation
  • Guesstimating
  • Delphi technique
  • Time boxing
  • Top-down estimating
  • Bottom-up estimating

16
Guesstimating
  • Often estimations are made without any formal
    basis, so we politely call them guesstimates
  • Dont do this!
  • Often fails to account for key tasks, produces
    optimistic estimates, or may be flat out wrong

17
Delphi technique
  • This is an average-expert-guess-consensus 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

18
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 its fairly accurate, though time
    consuming to generate

19
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
  • Times up? Youre done.
  • Often used when strict time constraints exist,
    but scope may suffer

20
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 projects effort and schedule
    devoted to each phase or see heuristics

21
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

22
Other approaches
  • Analogous estimation estimates tasks based on
    similar past projects
  • Often very accurate, but needs history!
  • Personally, Ive 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

23
Brooks Law
  • Adding people to a late software project makes
    it later
  • -- from the legendary Mythical Man-Month book by
    Frederick Brooks
  • Why?

24
Metrics
  • Metrics just refers to measuring something
  • In the context of software development, we want
    to measure important aspects of what were
    developing
  • Size
  • Effort (hence cost)
  • Schedule
  • Quality (defects)

25
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

26
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

27
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

28
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

29
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

30
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

31
Estimation tools
  • There are other estimation tools out there
  • SLIM
  • CostXpert
  • Etc.
  • None are as accurate as having historic data, but
    theyre better than a wild guess

32
So whats the best way to estimate?
  • There is no one answer thats 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
About PowerShow.com