Contributed by ProjectConnections.

com Staff
ProjectConnections.com Template
www.ProjectConnections.com
Software Bug Fix WBS Overview

Template: SW Bug Fix WBS - Overview

What: The Software Bug Fix Work Breakdown Structure, or SW Bug Fix WBS, is a simple
WBS that can be used for very small software projects, software maintenance or enhancement
projects or bug fix (a.k.a. – “defect correction”) tasks. The WBS will be overkill for some very
small projects, but in those cases can still be used as a checklist. The scope is targeted at
projects involving primarily one person, with some additional support from other team members
or support persons, such as a project manager, project leader, SW QA Manager, etc.
Each company has its own method or philosophy on how to approach bug fixes. This document
does not cover the complete range of possibilities but provides a typical approach and a good
reference. The WBS is written in mostly “common” language and terminology. It can be used
by a project manager or a development manager as a starting point.
NOTE: Projectconnections.com has a series of Software Release Life Cycle process
documents for the large, complex, multi-project, releases involving large groups of people.

Why: Sometimes the project manager needs a document for discussion with various
members of the team. If some of the software project members are doing “planned” bug fixes,
minor re-engineering project, small enhancements or on-going system maintenance, the project
manager can use the WBS as a schedule template for the team members performing these
activities.
This file can be used as an educational tool for new software engineers and a “best practice”
reminder tool for more experienced developers. When tailored to your environment, it will be a
very detailed step-by-step of your process of how your group believes defect correction should
be handled. Many of the steps are designed to ensure that changes are reviewed appropriately
before implemented, that bug fixing work is not duplicated, that impacts of the bug fix
implementation on the existing system operation are considered

How: The SW Bug Fix WBS can be used as a tem plate by any department performing
software maintenance or bug fixing activities in any programming language.
The tables in this file provide the sections of a Work Breakdown Structure, along with the task
titles and descriptions of each task. This file can be used alone; or if you plan to use MS Project
for creating your WBS and schedule, you can use our related MS Project file with the same
Work Breakdown sections and tasks.
Even if you don’t use this as a detailed “planning tool” in the normal sense of a WBS, you can
use it as a checklist or guideline for steps that should be taken by your development or
maintenance team members.
• Review the WBS. An explanation of each activity is provided in the following
pages.
• Delete any task that will not be used for your situation. For example, there are some task
entries dealing with checking out defect reports from the defect tracking system (or –
checking out bug reports from the database). If the company does not use a defect tracking
system, then just delete these task entries.
• Adjust the order of activities if needed to fit your situation. For instance, if you believe the
“bug generating code” review during the investigation and analysis portion may be too early
in the sequence f and more investigation is necessary before the engineer knows what code
to look at. Just move the task to a later part of the investigation effort.

Copyright 2004 Emprend Inc./ ProjectConnections.com Page 1

Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained

ProjectConnections.com Template
Software Bug Fix WBS Overview
WBS Tasks
Bug Report submitted /
assigned
Assignment of bug to specific SW manager, Project Manager, QA manager, etc.
engineer
Bug Database status
updated to ASSIGNED - add
engr name
Problem Investigation and
Analysis
Work time for Investigation
Evaluate (read) the error or
bug report
Bug Database status
updated to INVESTIGATION
Investigate any other similar
bug reports
Talk to the bug report
submitter
Talk to the test or SQA group
about similar bugs
Read the code generating
the bug (code review)
Replicate the error or bug
Check for possible side
effects
Test with current test tools or
plan to see if bug is caught
Continued next page
Copyright 2004 Emprend Inc./ ProjectConnections.com
Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained
Contributed by ProjectConnections.com Staff
www.ProjectConnections.com
SW Bug Fix WBS - Overview
Task Description
Section Title
Starting task of the bug fix “project.” The defect is assigned by the
If using a defect tracking system, the assigned engineer changes
the defect in the tracking system to indicate “assigned” and adds
his or her name as the “assignee.”
Section Title
WBS “filler” for work time. If using the MS Project file, delete this
task and fill in the correct time in the “duration” field for each task.
Self explanatory
If using a defect tracking system, the assigned engineer changes
the defect in the tracking system to indicate “Investigation” or the
next step after assigned.
There may be bug reports with different symptoms but the same
cause. There may be different areas of the software system that
are affected by the bug and different people report it and submit it
into different sections of the bug database.
If possible, talk to the person who submitted the bug report and get
as much information as possible.
Talk to the SW Quality Assurance folks or the test group and see if
any of them have seen the symptom or have any ideas.
Do a quick code review. This may not be possible until later. If the
problem is already apparent, save this step until later or perform the
activity in steps.
Set up the lab or borrow the test systems lab and replicate the bug.
Follow the instructions from the bug report on what the original bug
submitter provided about system, environment and activities.
Some bugs, by their nature, indicate possible side effects. These
could be file corruption, device failure, etc.
Get the test plan or software test suite and see if the test software
catches the bug. This will indicate whether and how the test plan
needs updating later after the error is corrected.
Page 2

ProjectConnections.com Template
Software Bug Fix WBS Overview
SW Bug Fix WBS - Overview (continued)
WBS Tasks
Problem Investigation and
Analysis (continued)
Determine the desired
expectations
Read the documentation
Talk with the QA and Design
engineers about the problem
Create strategy or plan of
approach
Review Plan with Sr. Engr or
SW Mgr
Release work around
solution if known or available
Continued next page
Copyright 2004 Emprend Inc./ ProjectConnections.com
Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained
Contributed by ProjectConnections.com Staff
www.ProjectConnections.com
Task Description
Section Title
Not all bugs are “bad.” Some bugs are perception. The submitter
believes the software system behaves differently than expected. If
the desired requirements (operation etc.) are ambiguous or
unknown, now is a good time to determine what “fix” will solve the
problem (if any fix is even necessary).
It’s always a good idea to see if the documentation covers the bug
or eliminates the need for a bug fix. For example, when designing
certain software (and hardware) the documentation may say:
“Does not work on Manufacturer X hardware executing Windows
98” – and thus the bug written on Windows 98 operation is null
Talk with staff members who are familiar with the software system,
particularly those that have experience with error handling in the
software system. They may be able to provide some hints on what
is wrong and why. They may also provide hints about possible side
effects from proposed fixes.
Determine your debugging techniques and plans for finding the
specific area of the bug and possible solutions. Think out the
“whys” ahead of time when planning the investigation.
Get a second opinion on your strategy or plan from someone else.
A more senior engineer or manager is a good candidate.
If, during your investigation and analysis, you have discovered a
work-around that provides the customer with an interim solution to
the problem, communicate that to customer support. Determine if
the work around IS the bug fix or if the software still will need to be
changed.
Page 3

ProjectConnections.com Template
Software Bug Fix WBS Overview
SW Bug Fix WBS - Overview (continued)
WBS Tasks
Fix the Bug
Work time for Fix
Check software out of SW
Source Control system
Replicate error or bug in test
environment
Create new test to check for
bug
Fix bug
Fix any side effects
Test bug fix with new SW
Code review changes with
Sr. Engr or Other engr
Check in code to SW Source
Control system
Check in test code to SW
Source Control system
Bug Database status
updated to SUBMITTED
Continued next page
Copyright 2004 Emprend Inc./ ProjectConnections.com
Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained
Contributed by ProjectConnections.com Staff
www.ProjectConnections.com
Task Description
Section Title
WBS “filler” for work time. If using the MS Project file, delete this
task and fill in the correct time in the “duration” field for each task.
Get the software from the source code control database.
Duplicate the bug in your local test environment where you have
control over the variables.
Write a new test procedure or automated text that duplicates the
bug (if necessary).
Self-explanatory. This task may need expansion for your particular
situation.
There may be side effects from the bug fix. These need to be
“okayed” if they are questionable. Remember that a software
system with a large installed base may have undocumented
expectations of the software. Check with the customer support
folks as to whether any side effects are acceptable or need fixing.
Do a build and generate a version of the complete software with the
fixed bug. Test this new software. NOTE: Sometimes, bugs are in
the system configuration or another area and the software system
or sub-system does not have to be rebuilt.
Always have someone look over your code. This is the easiest,
and in the long run, cheapest method of producing high quality
software products.
Promote your fixed software to the software source code control
system with the bug report # and brief, but clear, explanation of
what was fixed and why.
If an automated test case was written, promote your test software
to the software source code control system with the bug report #
and the information about the source code that got checked in.
Change the status in the bug tracking database to “submitted” or
whatever term you use. In some environments, this will be
“Complete” or “Done.”
Page 4

ProjectConnections.com Template
Software Bug Fix WBS Overview
Clean up
Work time for clean up
Update User Documentation
Communicate status to Proj
Mgr, SW Mgr or QA Mgr
Close bug (unless
SUBMITTED passes control
to QA)
Copyright 2004 Emprend Inc./ ProjectConnections.com
Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained
Contributed by ProjectConnections.com Staff
www.ProjectConnections.com
Section Title
NOTE: In some environments, some of the “clean up” activities will
have to precede the Bug database status being updated.
WBS “filler” for work time. If using the MS Project file, delete this
task and fill in the correct time in the “duration” field for each task.
Update the user documentation to technical publications. Inform
customer service of the changes also.
Let the authorities know that the job is completed.
Make any final changes to the defect tracking system database.
Page 5