Defect Management Process
A deliverable (e.g. work product) is baselined when it reaches a predefined milestone in its development. This milestone involves transferring the product from one stage of development to the next. As a work product moves from one milestone to the next, defects in the deliverable have a much larger impact on the rest of the system, and making changes becomes much more expensive. A deliverable is subject to configuration management (e.g., change control) once it is "baselined."
For purposes of this model, a defect is defined as an instance of one or more baselined product components not satisfying their given set of requirements. Thus errors caught before a deliverable is baselined would not be considered defects. For example, if a programmer had responsibility for both the programming and the unit testing of a module, the program would not become baselined until after the program was unit tested. Therefore a bug discovered during unit testing would not be considered a defect. If, on the other hand, an organization decided to separate the coding and unit testing, it might decide to baseline the program after it was coded, but before it was unit tested. In this case, a bug discovered during unit testing would be considered a defect (See Figure below).
Even for organizations that do not recognize this concept, a deliverable is, for practical purposes, baselined when the deliverable passes to the next stage of development. For example, developers should consider a program specification baselined when a programmer uses it as the basis to code a program. A program should be considered baselined when developers pass it on for integration testing. Finally, developers should consider a requirements specification baselined if it is being used as the basis for a technical design.
The concept of baselining is important because it requires an organization to decide both the level of formality that is appropriate, and the point in the process when the formality takes effect. In general, a deliverable should be baselined when changes to the deliverable, or defects in the deliverable, can have an impact on deliverables other people are working on.
Deliverable baselining involves the following activities:
Identify Key Deliverables: Select those deliverables that will be baselined and the point within the development process where the deliverable will be baselined.
Define Standards for Each Deliverable: Set the requirements for each deliverable and the criteria that must be met before the deliverable can be baselined.