Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Chapter 6






Total Views
Views on SlideShare
Embed Views



1 Embed 1

http://www.slideshare.net 1



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

Chapter 6 Chapter 6 Presentation Transcript

  • 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 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
  • 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?
  • 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
  • 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
  • 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)
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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, one basket, that problem
  • Estimation
    • We’ll look at several approaches for doing task estimation
      • Guesstimating
      • Delphi technique
      • Time boxing
      • Top-down estimating
      • Bottom-up estimating
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Brooks’ Law
    • “Adding people to a late software project makes it later”
      • -- from the legendary Mythical Man-Month book by Frederick Brooks
    • Why?
  • 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)
  • 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
  • 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
  • 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
  • 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
    • 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
  • 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
  • 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
  • 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