You are on page 1of 5

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
Contributed by ProjectConnections.com Staff
ProjectConnections.com Template
www.ProjectConnections.com
Software Bug Fix WBS Overview

SW Bug Fix WBS - Overview

WBS Tasks Task Description


Section Title
Bug Report submitted /
assigned
Starting task of the bug fix “project.” The defect is assigned by the
Assignment of bug to specific SW manager, Project Manager, QA manager, etc.
engineer
If using a defect tracking system, the assigned engineer changes
Bug Database status the defect in the tracking system to indicate “assigned” and adds
updated to ASSIGNED - add his or her name as the “assignee.”
engr name

Section Title
Problem Investigation and
Analysis
WBS “filler” for work time. If using the MS Project file, delete this
Work time for Investigation task and fill in the correct time in the “duration” field for each task.
Self explanatory
Evaluate (read) the error or
bug report
If using a defect tracking system, the assigned engineer changes
Bug Database status the defect in the tracking system to indicate “Investigation” or the
updated to INVESTIGATION next step after assigned.
There may be bug reports with different symptoms but the same
Investigate any other similar cause. There may be different areas of the software system that
bug reports 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
Talk to the bug report as much information as possible.
submitter
Talk to the SW Quality Assurance folks or the test group and see if
Talk to the test or SQA group any of them have seen the symptom or have any ideas.
about similar bugs
Do a quick code review. This may not be possible until later. If the
Read the code generating problem is already apparent, save this step until later or perform the
the bug (code review) activity in steps.
Set up the lab or borrow the test systems lab and replicate the bug.
Replicate the error or 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
Check for possible side could be file corruption, device failure, etc.
effects
Get the test plan or software test suite and see if the test software
Test with current test tools or catches the bug. This will indicate whether and how the test plan
plan to see if bug is caught needs updating later after the error is corrected.
Continued next page

Copyright 2004 Emprend Inc./ ProjectConnections.com Page 2


Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained
Contributed by ProjectConnections.com Staff
ProjectConnections.com Template
www.ProjectConnections.com
Software Bug Fix WBS Overview

SW Bug Fix WBS - Overview (continued)

WBS Tasks Task Description


Section Title
Problem Investigation and
Analysis (continued)
Not all bugs are “bad.” Some bugs are perception. The submitter
Determine the desired believes the software system behaves differently than expected. If
expectations 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
Read the documentation 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,
Talk with the QA and Design particularly those that have experience with error handling in the
engineers about the problem 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
Create strategy or plan of specific area of the bug and possible solutions. Think out the
approach “whys” ahead of time when planning the investigation.
Get a second opinion on your strategy or plan from someone else.
Review Plan with Sr. Engr or A more senior engineer or manager is a good candidate.
SW Mgr
If, during your investigation and analysis, you have discovered a
Release work around work-around that provides the customer with an interim solution to
solution if known or available 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.

Continued next page

Copyright 2004 Emprend Inc./ ProjectConnections.com Page 3


Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained
Contributed by ProjectConnections.com Staff
ProjectConnections.com Template
www.ProjectConnections.com
Software Bug Fix WBS Overview

SW Bug Fix WBS - Overview (continued)

WBS Tasks Task Description


Section Title
Fix the Bug
WBS “filler” for work time. If using the MS Project file, delete this
Work time for Fix task and fill in the correct time in the “duration” field for each task.
Get the software from the source code control database.
Check software out of SW
Source Control system
Duplicate the bug in your local test environment where you have
Replicate error or bug in test control over the variables.
environment
Write a new test procedure or automated text that duplicates the
Create new test to check for bug (if necessary).
bug
Self-explanatory. This task may need expansion for your particular
Fix bug situation.
There may be side effects from the bug fix. These need to be
Fix any side effects “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
Test bug fix with new SW 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,
Code review changes with and in the long run, cheapest method of producing high quality
Sr. Engr or Other engr software products.
Promote your fixed software to the software source code control
Check in code to SW Source system with the bug report # and brief, but clear, explanation of
Control system what was fixed and why.
If an automated test case was written, promote your test software
Check in test code to SW to the software source code control system with the bug report #
Source Control system and the information about the source code that got checked in.
Change the status in the bug tracking database to “submitted” or
Bug Database status whatever term you use. In some environments, this will be
updated to SUBMITTED “Complete” or “Done.”

Continued next page

Copyright 2004 Emprend Inc./ ProjectConnections.com Page 4


Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained
Contributed by ProjectConnections.com Staff
ProjectConnections.com Template
www.ProjectConnections.com
Software Bug Fix WBS Overview

Clean up 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
Work time for clean up task and fill in the correct time in the “duration” field for each task.
Update the user documentation to technical publications. Inform
Update User Documentation customer service of the changes also.
Let the authorities know that the job is completed.
Communicate status to Proj
Mgr, SW Mgr or QA Mgr
Make any final changes to the defect tracking system database.
Close bug (unless
SUBMITTED passes control
to QA)

Copyright 2004 Emprend Inc./ ProjectConnections.com Page 5


Permission for Members to use personally as long as a ProjectConnections.com attribution is maintained