Brian Sidharta, Aleksandra Faust, Larry Knox, Saurabh Gandotra

Project dbViZ

HW1 Change Management – CS329 – Spring 2003

6 February 2003

This document describes the Change Management Policy for the dbViZ project.

How bugs are registered.

We will be using Bug Tracking System provided by SourceForge.net for bug reporting and tracking.

Who will report bugs?

  • Users
  • dbViZ Team

Bugs entered by Users will be subject to verification to filter invalid bugs. This verification will be performed by any of the team members. Bugs reported by the team will not be subject to verification since the team is considered to have greater knowledge about the system.

To report a bug with dbViZ:

  1. Go to:
  2. Examine the list of bugs presented there. Check if the bug you are about to report is already reported. If not proceed.
  3. Click on Submit New.
  4. Enter your bug information. The category is the module in the application that the bug refers to. The group is the version of the application in which the bug is observed. Assign an approximate priority for the request. Give a brief title to your bug that will summarize the problem.
  5. Describe the problem in detail and describe how to produce it. Also list what platform you are running on. Provide any screen shots that can be helpful. Tell us if you were able to repeat the bug.
  6. If you log in, the system will notify you when the bug is fixed. You can opt to submit bug as anonymous.
  7. Submit the bug.

Developer requirements when updating bugs

Developers must follow several requirements when changing the status of a bug to assure that the tracking system is consistent.

  • The priority should not be changed by developers without prior approval from the change management group.
  • The assignee should not be changed by developers without prior approval from the Project Manager.
  • When changing the status to closed or deleted, the resolution should be updated, and a comment should be added briefly describing the reasoning behind the status and resolution changes.

How feature requests are submitted.

We will be using Feature Request Tracking System provided by SourceForge.net for feature request reporting and tracking.

Who can request features?

  • Users
  • dbViZ Team

Feature requests entered by users will be subject to verification to assure duplicate feature requests are removed from the system. The verification is also for identifying and resolving conflicts and/or overlaps between different feature requests.

The verification step is not needed for team-submitted feature requests, because it is assumed the team members know more about the application and would not enter a redundant feature request.

To submit a feature request for dbViZ:

  1. Go to:
  2. Examine the list of feature requests presented there. Check if the feature request you are about to report is already reported. If not proceed.
  3. Click on Submit New.
  4. Enter your feature request information. The category is the module in the application that the bug refers to. The group is the version of the application in which the bug is observed. Assign an approximate priority for the request. Give a brief title to your feature request that will summarize the item.
  5. Describe the request in detail including why you believe the request should be fulfilled. If the feature request is complicated, citing samples where the feature exists in other applications may be useful.
  6. If you log in, the system will notify you when the feature request is implemented. You can opt to submit feature requests anonymously.
  7. Submit the feature request.

Developer requirements when updating feature requests

Developers must follow several requirements when changing the status of a feature request to assure that the tracking system is consistent.

  • The priority should not be changed by developers without prior approval from the change management group.
  • The assignee should not be changed by developers without prior approval from the Project Manager.
  • When changing the status to closed or deleted, a comment should be added briefly describing the reasoning behind the status change.

How to decide which feature requests/bugs will be implemented next

A change management group will prioritize the bugs and features requests. This prioritization determines the order in which bugs and feature requests are implemented.

The change management group will consist of:

  • A proxy customer (formed of team members).
  • Project Manager.

Bugs will be prioritized using the following criteria:

  • Defects where modules fail or are inaccessible are high priority and should be resolved within 2-3 days.
  • Medium-severity defects such as component failures and data problems should be resolved with in 5-7 days
  • Low-severity defects such as cosmetic errors will be handled on a case-to-case basis.
  • The priority assigned by the defect submitter will be given some consideration.

Feature requests will be prioritized using the following criteria:

  • Whether the feature can be practically implemented in the current version. A counter-example of this is whether the feature can be more easily implemented in a later version.
  • Time and resource cost of implementing the feature vs. cost of not implementing the feature.
  • The priority assigned by the feature request submitter will be given some consideration.

How to determine if a feature/bug has been implemented, and in what version

People can determine the status of bugs and feature requests using the Sourceforge Tracking System.

To determine the status of a bug or feature request:

  1. For bugs, go to:
    For feature requests, go to:
  2. Find the desired feature request or bug. If its status is open, the item has not yet been addressed.
  3. Determine whether the bug/feature request has been implemented. For bugs, check the resolution fieldand commentsto determine the outcome. For feature requests, check the comments. As all changes to the item’s status are logged with a timestamp, the version that the item was implemented in can be derived from the timestamp when the item was closed by a developer. In the case of releases (branches), one can determine the version by combining the closing timestamp with the group name(the version in which the item was observed).

1