INFO 638Lecture #21 Software Project Management WBS Approaches

INFO 638Lecture #22 WBS Approaches  There are three major approaches to structuring a WBS Noun-type approaches Verb-type approaches Organizational approaches

INFO 638Lecture #23 Noun-type approaches  The noun-type approach means the WBS is structured by the physical or functional components of the project In a client-server system, the client and server’s development could each be top level WBS activities In assembling a car, each major subsystem could be a WBS activity (drivetrain, body, cabin, suspension,...)

INFO 638Lecture #24 Verb-type approaches  Verb-type approaches focus on the processes in the project Most common for software development, this includes using each phase of the life cycle as a top level WBS activity – Requirements Analysis, High Level Design, Low Level Design, Coding, various kinds of Testing, etc. Could define WBS by project objectives  Shows how close project is to completion

INFO 638Lecture #25 Organizational approaches  The organizational approach groups activities by who does them Could be based on geographic location, department, etc. Might be good for a distributed development team, to help make it clear what each group is supposed to do

INFO 638Lecture #26 Showing the WBS  The WBS can be shown as an organization chart-like structure (p. 93)  This gives an overview of all the activities

INFO 638Lecture #27 Naming WBS Tasks  The tasks in a WBS (and ideally, the activities too) should start with a verb  Include tasks to plan the project, conduct the actual work of the project, make decisions, etc. Task names might include ‘Prepare test plan,’ ‘Conduct system test,’ ‘Write test report,’ ‘Approve system release’

INFO 638Lecture #28 WBS Numbering  [This section isn’t part of Wysocki]  Tasks and activities are often given unique identification numbers to help do cost accounting and generate status summaries In Microsoft Project, you can add a column called WBS which will automatically follow this numbering

INFO 638Lecture #29 WBS Numbering  The goal of a WBS is to structure activities to allow for unique identification and tracking of existing activities, while being expandable to allow for new ones  The WBS numbers are a series of numbers separated by periods, used to identify tasks on a project

INFO 638Lecture #210 WBS Number Format  The highest level of each major task is a “whole” number (1.0, 2.0, …)  The duration of major tasks (1.0) is the span of all tasks under it (e.g. 1.1 to 1.3)  Lower level tasks are components of their higher level task (2.1 is part of 2.0), hence a short WBS number (2.1) is a higher level task than a long WBS number (2.1.2)

INFO 638Lecture #211 WBS Number Example  For example 1.0 Risk Management Activities  1.1 Develop Risk Management Plan  1.2 Approve Risk Management Plan  1.3 Conduct Ongoing Risk Management  Task 1.0 is the highest level task shown; composed of tasks 1.1 to 1.3  Note that lower levels are indented

INFO 638Lecture #212 WBS Numbering  Numbers above nine under one task just keep counting (e.g. 1.8, 1.9, 1.10, 1.11, …)  The WBS numbers allow new tasks to be inserted where needed, such as tasks 1.1.1, and 1.4 in the RM example, and yet uniquely identifies each task.  A WBS can use as many digits as needed (e.g )

INFO 638Lecture #213 Typical Software WBS  A typical waterfall life cycle project might use a WBS that follows the life cycle phases 1.0 Do Requirements Analysis 2.0 Conduct High Level Design 3.0 Conduct Low Level Design 4.0 Conduct Coding and Unit Testing 5.0 Conduct Integration and System Testing

INFO 638Lecture #214 Typical Software WBS  While that handles the development life cycle activities, often support activities will be broken out into separate WBS elements 6.0 Perform Quality Assurance 7.0 Conduct Configuration Management 8.0 Conduct Project Management  This is a hybrid of the verb and organizational WBS approaches

INFO 638Lecture #215 Typical Software WBS  Then, within each of the top level WBS activities, you decide what activities and tasks are needed Within requirements analysis, what will you do to accomplish that?  Examine legacy system documentation?  Conduct interviews?  Study similar systems?  Describe use cases?

INFO 638Lecture #216 OO WBS  The top level WBS for an object oriented (OO) project might follow the Rational Unified Process life cycle phases 1.0 Conduct Inception Phase 2.0 Conduct Elaboration Phase 3.0 Conduct Construction Phase 4.0 Conduct Transition Phase

INFO 638Lecture #217 OO WBS  For an OO project, you may not need separate top level WBS entries for support tasks, if they are integrated into each phase  Then each phase has iterations, and you need to determine how long they are (eventually) and what tasks happen inside each iteration

INFO 638Lecture #218 OO WBS 1.0 Conduct Inception Phase  1.1 Conduct iteration I insert tasks for this iteration insert tasks for this iteration  1.2 Conduct iteration I insert tasks for this iteration 2.0 Conduct Elaboration Phase  2.1 Conduct iteration E you get the idea

INFO 638Lecture #219 WBS Summary  There is no one perfect correct way to generate a WBS for a given project Many solutions could work well It is common to blend the noun, verb, and organizational structures  Such as use the verb approach for the top level WBS, then noun or organizational for lower level elements