Presentation on theme: "Software Engineering II Work Breakdown Structures"— Presentation transcript:
1Software Engineering II Work Breakdown Structures TUMProf. Bernd Brügge, Ph.DTechnische Universität MünchenInstitut für InformatikLehrstuhl für Angewandte Softwaretechnik3 May 2005
2Where are we?In the last lecture we focused on general software project management issues and configuration managementHow do we structure a project?How do we deal with change?We introduced the SPMP and SCMPFocus on specific software project management issuesToday’ lecture: Decomposition of workWhat are the units of tasks to be done?Tomorrow’s exercise:WBS Exercise (Advanced Home Dispatch Project)Project Manager: JohannesBross, AccentureMay 10: Project estimation: How long do these tasks take?May 24: Project organization: Who is doing these tasks?June 7: Scheduling : How long does it take to finish them?Project estimation and scheduling are difficult topics, because of the inherent problems of software development.Estimation and scheduling is easy if the WBS is well known, and does not change.They are much harder, when the estimates are way off, which is typical for many software projects, especially at the beginning of the project. At this time, only rarely are the tasks and their estimated times completely known. So if a project manager has to make an estimate at the beginning of a project, which is typical in today’s project approval climate - nobody let’s you start a project, if you tell them that your budget is unknown, it is rare, if they can make the right estimate. New project management models allow developers to participate in the estimates. For example, in XP, the estimates for unit implmenetation and testing is done by the developer. The planner simply aggregates these numbers.and the schedule needs to be adjustedAnAs scheduling example we will establish the schedule for a system test.
3Outline of today’s class Determining Work and Tasks SizesWork Breakdown Structure (WBS)Different Approaches for developing WBSsNotations for Work Breakdown StructuresHeuristics and examples for WBSStarting with templatesHow to identify workWhat do you do with risky tasks?Using WBS in large projectsHow detailed should a WBS be?How can you plan the tasks of a long project when things are unknown or changing all the time?Different Approaches are functional or object-oriented, so we have the same dichotomy as in object-oriented vs functional decomposition when modeling systems.
4What is the problem? Your boss: “How long will this take?” “As long as I can do itwithin 6 months, I keepmy promise.”You: “Between 1 and 6 months.”Say the following sentences before animating the clouds:People are not happy when you respond that way.You figure: Finishing anytime before six months will meet your promise.Your boss figures: With some hard work he can be done in a month!In reality, it is often even worse: You don’t have the slightest clue how long it will take, because you don’t know the work to be done!!!Now add the clouds, and then proceed to the solution: divide and conquer first!“With hard work, he cando it in 1 month.”
5What is the problem? Your boss: “How long will this take?” “I have not theslightest clue, if it ispossible at all.”You: “Between 1 and 6 months.”“Even if it is possible,I don’t know, how longit will take.”Say the following sentences before animating the clouds:People are not happy when you respond that way.You figure: Finishing anytime before six months will meet your promise.Your boss figures: With some hard work he can be done in a month!In reality, it is often even worse: You don’t have the slightest clue how long it will take, because you don’t know the work to be done!!!Now add the clouds, and then proceed to the solution: divide and conquer first!Solution: Use divide and conquerTo give a good answer you have to break the work down into activities for which you try to get timing estimatesOnly if you can get good estimates can you compute the estimated project duration
6Activities to obtain good time estimates Identify the work that needs to be doneWork breakdown structure (WBS), SPMP Section 5. 1Identify the dependency between work unitsDependency Graph, SPMP Section 5.2Estimate the duration of the work to be doneSchedule, SPMP Section 5.5
7Software Project Management Plan 0. Front Matter1. Introduction2. Project Organization (Lecture on May 24)3. Managerial Process4. Technical Process5. Work Elements, Schedule, Budget5.1 Work Breakdown Structure (WBS) (Today)5.2 Dependencies between tasks (Today)5.3 Resource Requirements (Lecture on May 24)5. 4 Budget (Lecture on May 10)5.5 Schedule (Lecture on June 7)Optional Inclusions
8Software Project Management Plan 0. Front Matter1. Introduction2. Project Organization (Lecture on May 24)3. Managerial Process4. Technical Process5. Work Elements, Schedule, Budget5.1 Work Breakdown Structure (WBS) (Today)5.2 Dependencies between tasks (Today)5.3 Resource Requirements (Lecture on May 24)5. 4 Budget (Lecture on May 10)5.5 Schedule (Lecture on June 7)Optional Inclusions
9What are the activities that are needed to build a house? Let‘s Build a HouseWhat are the activities that are needed to build a house?
10First Step: Identify the work to be done SurveyingExcavationRequest PermitsBuy MaterialLay foundationBuild Outside WallInstall Exterior PlumbingInstall Exterior ElectricalInstall Interior PlumbingInstall Interior ElectricalInstall WallboardPaint InteriorInstall Interior DoorsInstall FloorInstall RoofInstall Exterior DoorsPaint ExteriorInstall Exterior SidingBuy PizzaThe similar activity is object and function identification! (here activity identification)A technique that we learned is Abbot’s technique (no relgious belief, more a technique that can be used when writers block occurs or as a completeness check.Initially finding these tasks is a brainstorming activity.Similar to activities used during requirements engineering and analysis
11Second Step: Hierarchically organize the tasks Building the house consists ofPrepare the building siteBuilding the ExteriorBuilding the InteriorPreparing the building site consists ofSurveyingExcavationBuying of materialLaying of the foundationRequesting permitsFinding this organization involves categorization and refinement.Good after brainstorming, not during brainstorming
12Third Step: Identify dependencies between tasks The work breakdown structure does not show any dependence among the activities/tasksCan we excavate before getting the permit?How much time does the whole project need if I know the individual times?What can be done in parallel?Are there any critical actitivites, that can slow down the project significantly?Dependencies like these are shown in the dependency graphNodes are activitiesLines represent temporal dependencies
13Building a House (Dependency Graph) InstallInstallInstallInteriorInteriorWallboardThe activity„Buy Material“ mustPrecede the activity„Lay foundation“PlumbingElectricalPaintInteriorInstallInteriorInstallDoorsFlooringLaySTARTSurveyExcavaBuildBuyFoundaOutsideFINISHingtionMaterialtionWallInstallRoofingInstallExteriorDoorsRequestPaintExteriorInstallInstallInstallExteriorExteriorExteriorPlumbingElectricalSiding
14Fourth step: Map tasks onto time Estimate starting times and durations for each of the activities in the dependency graphCompute the longest path through the graph: This is the estimated duration of your project
15Building a House (Schedule, PERT Chart) 12/3/9412/21/941/11/95Each Activity has a start time and an estimated durationInstallInstallInstallInteriorInteriorWallboardPlumbingElectrical1/22/9512159PaintInterior2/8/95111/22/95InstallInteriorInstallDoorsFlooring10/15/9411/5/9478/27/948/27/949/17/9410/1/942/16/95LayBuild18STARTSurveyExcavaBuyFoundaOutside1/19/95FINISHingtionMaterialtionWallInstallRoofing1/19/951210310152012Install9ExteriorDoors8/27/9415Request1/12/956PermitsPaintExterior1512512/3/9412/17/9412/31/94Start TimeInstallInstallInstall8/29/94ExteriorExteriorExteriorLegendPlumbingElectricalSidingDuration1212128Slack Time1010
16How do we get good estimate times? Estimation of starting times and durations is crucial for setting up a plan.In the lecture on Scheduling we will discuss methods and heuristics on how to do it and how to establish a software project schedule.First let us learn a few more technical terms defined in the SPMP IEEE Std 1058
17Recall Definitions from Lecture 1 Project:A Project has a duration and consists of functions, activities and tasksWork Package:A description of the work to be accomplished in an activity or taskWork Product:Any tangible item that results from a project function, activity or task.Project Baseline:A work product that has been formally reviewed and agreed upon.A project baselines can only be changed through a formal change procedureProject Deliverable:A work product to be delivered to the customer“formally reviewed and agreed upon” does not mean a baseline is frozen! Avoid this term by any means!
18Activities, Tasks and Functions Activity: A a major unit of work with precise dates that consists of smaller activities or tasks. It culminates in a project milestone.Task: Smallest unit of work subject to management. Small enough for adequate planning and tracking. Large enough to avoid micro managementProject Function: An activity or set of activities that span the duration of the project
19Tasks Smallest unit of management accountability Atomic unit of planning and trackingTasks have finite duration, need resources, produce tangible result (documents, code)The description of a task is done in a work packageName, description of work to be donePreconditions for starting, duration, required resourcesOther work packages that need to be completed before this task can be started.Work products to be produced, acceptance criteria for itRisk involvedCompletion criteriaIncludes the acceptance criteria for the work products (deliverables) produced by the task.
20Determining Task Sizes Finding the appropriate task size is problematicTodo lists and templates from previous projectsDuring initial planning a task is necessarily largeYou may not know how to decompose the problem into tasks at firstEach software development activitity identifies more tasks and modifies existing onesTasks must be decomposed into sizes that allow monitoringDepends on nature of work and how well task is understood.Work package usually corresponds to well defined work assignment for one worker for a week or two.Work assignments are also called action items
21Work Breakdown Structure **TaskActivityWork Breakdown Structure: The aggregation of all the workto be performed in a project. Often called WBS
22Approaches to Develop Work Breakdown Structures Product component approachStructure the work based on the work productsExamples: Design documents, manuals, the delivered system,…Functional approachStructure the work based on development activities and project functionsExamples: Analysis, design, implementation, integration,…There are several different approaches to develop and display a work breakdown structure.Each is effective under different circumstancesApproaches to break activities into detail byGeographical area approachStructure the work based on geographical locationExamples: Munich team, Pittsburgh team, off-shore team,…Organizational approachStructure the work based on the organizational structureExample: R&D department, predevelopment, product development, marketing, sales,…
23When to use what Approach The teams are distributed over the continent:Geographical area approachThe teams consist of experienced developers:Product component approachThe project has mostly beginners or an unexperienced project manager:Functional approachThe project is a continuation of a previously successful project, there are no changes in the requirements and no new technology enablersOrganizational approachWhatever approach you choose, stick with it to prevent possible overlap in categoriesAt the end of this slide: “If you don’t stick with the approach, your workbreakdown structure will lead to double work and unmanageable tasks (tasks that are managed by more than one person: The geographical boss and the product manager, for example. “
24Mixing different Approaches is bad Consider the WBS for an activity „Prepare report“Functional approach:Write draft reportHave draft report reviewedWrite final reportProduct component approach:Chapter 1Chapter 2Chapter 3Mixed approach:Why is this bad?Answer to question at the end of the slide:“Prepare the final version of Chapter 3” can be included in either in the task: “Chapter 3” or in the task “Write final report”
25How do you develop a good WBS? Top down approach:Start at the highest, top level activities and systematically develop increasing levels of detail for all activities.Bottom up approach (“Brainstorming”):Generate all activities you can think of that will have to be done and then group them into categories.Which one you use depends onhow familiar you and your team are with the project,whether similar projects have successfully been performed in the past, andhow many new methods and technologies will be used.BreakExample for previous slide: You are at the beach, you are building a sandcastl e, somebody else too, soon you are noticing that the wall, your wall!, is used by the oterh kid. War! Sandwar! This type of war is typical, if you mix approaches, for example if you mix the functional WBS with the product component approach.
26The Top Down WBS Development Specify all activities required for the entire project to be finishedDetermine all tasks required to complete each activityIf necessary, specify sub-activities required to complete each taskContinue in this way until you have adequately detailed your project.Approach is good ifYou are familiar with the problem (or your team)You have successfully managed a similar project in the pastYou are not introducing new methodologies, methods or tools
27The Brainstorming WBS Development On a single list, write any activities you think will have to be performed for your project.Brainstorming means youDon’t worry about overlap or level of detailDon’t discuss activity wordings or other detailsDon’t make any judgementsWrite everything downThen study the list and group activities into a few major categories with common characteristicsIf appropriate, group identified activities into higher level activitiesConsider each category you have created and use the top-down WBS development to determine any additional activities you may have overlooked.
28Displaying Work Breakdown Structures Three different formats are usually usedOrganization-chart formatEffectively portrays an overview of your project and the hierarchical relationships of different activities and tasks.Outline formatSubactivities and tasks are indentedBubble formatThe bubble in the center represents your projectLines from the center bubble lead to activitiesLines from activities lead to tasks
29Prepare Report 1.0 Prepare draft report 2.0 Review draft report Final ReportWritePrintPrepare Report1.0 Prepare draft report2.0 Review draft report3.0 Prepare final report3.1 Write final report3.2 Print final reportOrg-Chart FormatOutline FormatReviewDraft ReportPrepareReportFinal ReportPrintWriteBubble Format
30What is the best display format for WBS? Organization-chart format:Often good for a “bird view” of the project (executive summaries,...)Less effective for displaying large numbers of activitiesOutline format:Easier to read and understand if WBS contains many activitiesBubble format:Effective for supporting brainstormingNot so good for displaying work breakdown structures to audiences who are not familiar with the project.In large projects:Use bubble format to develop the WBS, then turn it into Organization-chart or Outline format.Display activities in Organization-chart format,Display subactivities and tasks in Outline format
31Heuristics for developing high quality WBS Involve the people who will be doing the work in the development of the WBSIn particular involve the developersReview and include information from work breakdown structures that were developed for similar projectsUse a project template if possibleQuestion: using more than one WBS approach? Did we not just say a few moments ago, that it is not good to use more than one approach? Notice the difference between developing a WBS and using it for tracking a project.Large projects: Keep your current work breakdown structure current, update your WBS regularlyUse more than one WBS approachDo project component and functional approach simultaneouslyThis allows you often to identify overlooked activitiesMake assumptions regarding uncertain activitiesIdentify risky activitiesThese are often the activities whose times are hard to estimate
32Choose a single WBS Approach Develop the WBS with different approaches. This is good, because it allows you to identify activities that you may overlook otherwiseChoose a single WBS approach to be used in the SPMP and for your project:Nothing confuses people fast than trying to use two different work breakdown structures to describe the same project.However, after you identify these activities add them to one WBS approach
33How Detailed should the WBS be? Sometimes the activities are not clear at all, especially in software projects, because of:Unclear requirements and/or changing requirementsDependency on technology enablers that are promised to appear after project kickoffSimultaneous development of hardware and software (“concurrent engineering”)Heuristic: A project plan, especially for an innovative software project, should not address details beyond 3 months.Even for the first 3 months project activities might not all be detailable, for example when the requirements are unclear or change or introduction of technology enablers is expected.How should we describe a WBS for a longer project?
34Doing a WBS for Long-Term Projects When developing a work breakdown structure for a long-term project (longer than 3 months), introduce at least two phasesPhase 1 (3 months): Plan your WBS in detailList all activities that take two weeks or less to completePhase 2, Phase 3, … (n-months) Plan the WBS for these phases in less and less detailList activities that will take between one and two monthsAt the end of phase 1, revise the phase 2 activities and plan them on the two week level for the next 3 months.Modify any future activities as necessary based on the results of your first three months work.Continue to revise the SPMP this way throughout the project. (The SPMP is an “evolving” document)
36Phases and large Projects Project-Initiation PhaseSteady State PhaseInitial Planning phaseProject-Termination Phase
37Project-Initiation Phase: To-Do List ActivitiesMeet with client, develop visionary scenario for problem statementDevelop initial top level design: System as a set of subsystemsEstablish staffing plan (flat staffing, ramping up)Identify human resources: existing employees, new employeesHire team membersAssign a subsystem to each team. Establish additional cross-functional teams (e.g. architecture, docuementation, demo)Write problem stateement (with client and other stake holders; if possible, involve project participants early)Write initial SPMP with WBS, without schedule, without budgetFred Brooks, The mythical monthsGet project plan approvedKick project off with 2 documents: Problem statement and SPMPDuration of project-initiation-phase: Between 2-4 weeksWhen? Before project kickoff
38Initial Planning Phase: To-Do List ActivitiesDo scouting on technology enablers that might influence the design or nonfunctional requirementsRevise requirements and initial top level design if necessaryRevise team structure, reassign team members if necessaryRevise WBS and dependenciesEstablish cost and scheduling informationAgree with client on requirements, duration and cost of the projectWrite the “project agreement” (companion document to the SPMP)Duration: About 2 weeks time.When: After project kickoff, often called “planning phase”, Parallel to “requirements elicitation phase”The scouting is often called innovation managementThe project agreement should not be written too early. Good heuristics: After a first analysis of the requirements, ideally after the requirements analysis phase.
39Project-Termination Phase Do a project-review: “What went right, what went wrong”also often called “project post-mortem review”Based on input from the post-mortem sessionRevise your software process, identify in particular any new activities that happened in the projectRevise your project kickoff activitiesRevise the SPMP template (to be reused for your next project)
40Where are we? SPMP IEEE Std 1058 0. Front Matter 1. Introduction 2. Project Organization3. Managerial Process4. Technical Process5. Work Elements, Schedule, Budget5.1 Work Breakdown Structure (WBS)5.2 Dependencies between tasks5.3 Resource Requirements5. 4 Budget ( => Lecture on cost estimation)5.5 ScheduleOptional Inclusions
41Readings Literature used for this class [IEEE Std 1058] Standard for Software Project Management PlansStanley E Portny, Project Management for Dummies, Hungry Minds, 2001, ISBN X[Bruegge-Dutoit 2000], Chapter 11 Project Management
42Exercises Homework (Optional, Due May 10): Model activities, functions and tasks as a UML class diagram (Start with drawings and definitions from slides of the first and tis lecture and extend Figure 11-2 in [Bruegge-Dutoit])Tomorrow’s exercise (with Jens Bross, Accenture)Develop a WBS for the Project “Advanced Home Dispatch”The Problem Statement was handed out yesterdayParticipation is mandatory for those taking the course for creditSuccessful participation contributes 15% to your grade
43Summary Different approaches to develop a WBS Product ApproachFunctional ApproachGeographical ApproachOrganizational ApproachTop down and bottom up WBS developmentHeuristics for developing good WBSWBS for Large Projects
45Heuristic: Use Templates Try to derive the SPMP from a templateA template reflects the cumulative experience gained from doing numerous projects of a particular type.Using templates can save you time and improve your accuracyWhen developing templates, develop them for frequently performed tasks (reviews, meetings, …).Develop “Checklists”:Develop and modify your WBS templates from previous projects that worked, not from plans that looked good.Use templates as starting points, not as ending pointsContinually update your templates to reflect the experience gained from performing different projects.
46Heuristic: Develop always more than one WBS Consider to create more several different hierarchies with different categories for your work breakdown structure.Having two or more different perspectivies helps you identify activities you may overlook.Good starting point are the following hierarchies:Entity-oriented decompositionActivity-oriented decompositionExample: You are running your first object-oriented project.Develop a WBS based on the project documentsDevelop a WBS based on the software process activities
47Heuristic: Identifying Risky activities When you identify activities for a work breakdown structure, you can also identify the risks in your project.Risks are usually associated with “unknown information”.Unknown information comes in two flavorsA “known unknown”: Information that you don’t have but someone else does.Find out who has the information and determine what the information is. (Interviews, Phone calls, tasks analysis)An “unknown unknown”: Information that you don’t have because it does not yet exist.Develop contingency plans for each of these risks.These contingency plans need be followed when you find out the information does not exist.Describe these risks in SPMP 3.3 Risk Management
48Risk Management Examples Risk: Members in key roles leave the project.Contingency Plan?Roles are assigned to somebody else. Functionality of the system is renegotiated with the client.Risk: The project is falling behind schedule.Extra project meetings are scheduled.Risk: Team 1 cannot provide functions needed by team 2.A: We drop the functionality.B: The liaisons of both teams get together to solve this problemRisk: The planned PDA will not be available.We will use an IPAQ instead.
49Risk Management Examples ctd Risk: The selection of the database system takes too much timeContingency Plan?The Database team uses a bridge pattern and provides a test stub to be used by the other teams for data access while the selection process goes on.Risk: The customer is not available for discussing and reviewing the user interface during development.Make the design decisions that we feel are appropriateRisk: No suitable wireless library can be found.The wireless team develops its own library
51WBS Based on Software Process (Activity-oriented) <<Name>>ProjectProjectInitiationPlanningAnalysisDesign- Establish guidelines- Formulate requirements with client- Establish scenarios- Write project agreement- Determine WBS- Determine dependencies between tasks- Write SPMP- Assign teams to subsystems- Establish project calendar- Brainstorm on application domain objects- Develop class diagram- Partition objects into boundary, entity and control objects- Develop use cases- Develop Models- Write code- Present problems to coach- Giove status reports- Write RAD- Write SDD- Write ODDQuestion: Which activities mentioned in the WBS based on Project documentsis left out in the WBS based on Software Process?
52Estimates for establishing WBS Establishing an WBS in terms of percentage of total effort:Small project (7 person-month): at least 7% or 0.5 Person Months (PM)Medium project (300 person-month): at least 1% or 3 PMsLarge project (7000 person-month): at least 0.2 % or 15 PMsSource: Barry Boehm, Software Economics (rather dated now)