Getting Started

Documentation

Glish

Learn More

Programming

Contact Us

Version 1.9 Build 1367

News	FAQ
Search	Home

Defect handling

All defects are tracked in a defect tracking system, currently ClearDDTS (Rational). Sub-queues are established for the different geographical regions (Europe, North America, and Australia at present). If not resolved by a regional representative, defects are forwarded to the main defect queue. Defects are graded by severity, subject to the following criteria:

Severity 1: A catastrophic and unrecoverable error.

Severity 2: Severely broken, and no work-around.

Severity 3: A defect that needs to be fixed, but there is a work-around.

Severity 4: A defect that has a small impact, and is easy to work around.

Severity 5: A minor error or enhancement request.

In addition to defect reporting, enhancement requests can also be made through the defect tracking system.

Defect handling etiquette is as follows:

• On receiving an assigned defect, developers are expected to respond with a message to the user acknowledging and opening the defect. The cause of the defect does not necessarily need to be determined at this stage.

• Any changes in severity need to be explained briefly to the user.

• The severity of the defect is its classification. Severity 1 and 2 defects require a rapid response.

• Each developer is expected to devote up to 20% of development time to defect correction, but no more. Defect time should be assigned as evenly as possible throughout the development cycle. If a large number of defects accumulate in a specific area, additional time may be scheduled in the development cycle as a separate target.

• Defects are not a mechanism for revising planning in mid-course or for assigning the time of fellow developers in the consortium. Defects are aimed at code already in the system, at some degree of completeness and advertised for use.

• All previously postponed defects will be re-opened at the start of each development cycle.

• All resolved defects need to be verified by the submitter or by a developer assigned in each geographic region to verify defects submitted from end-users. Verification should not be denied for frivolous reasons. In the event of dead-lock, project management will make a final decision on closing a particular defect.

• Defects submitted by developers within the project are held to a higher standard than those submitted by external users. They are expected to be accompanied by rudimentary debugging or differential testing.