By this point you should have defined the defect lifecycle (states) and required fields, and installed ClearDDTS. Before making ClearDDTS available to your organization, make any customizations you mapped out during the planning process. Also create any new classes and the projects appropriate for your site.
Note: If you do not plan on customizing ClearDDTS classes or forms, skip to the Creating and customizing projects and Customizing security sections of Step 3.
Several classes are provided with ClearDDTS. See the directories below
~ddts/class for details. If your process closely resembles the process
defined in one of the supplied classes, make changes to that class as appropriate.
You can also create a new class to begin the implementation. Choose an existing class that is most similar to the class that you have designed, and customize from there. This is much easier than creating a class from scratch. To create a new class, use the adminbug clas command. See Chapter 5, Maintaining Classes and Projects, in the ClearDDTS Administrator's Guide for a description of adminbug clas.
Complete the following steps to customize the state-related files in your class directory:
Modify the master.tmpl file to implement your new states and the fields associated with them. Before continuing, be sure you understand how the master.tmpl file works by reading Chapter 7, Understanding the Master Template File, in the ClearDDTS Administrator's Guide. Once you are familiar with the master.tmpl file you can add to and modify the states in the file.
The master.tmpl file is a collection of fields organized into sections. There is one section for each state plus an initialization section and a cleanup section. Each state section begins with a field called <X>-fields, where <X> is the letter representing the state. Conditional logic and goto statements control which fields are executed by determining which state sections are visited.
To add a new state and its associated fields:
The concept of earlier and later states comes from the order of state transitions
in your state diagram. The order of state transitions in ClearDDTS is determined
by the logic within the field derivations. There is also the concept of
mainstream and off-line states. Mainstream states follow the normal flow
of a defect through the life cycle (for example, from Opened to Assigned
to Resolved). Off-line states happen outside the normal flow (for example,
from Opened to Postponed) and can often send a defect back to an earlier
state. Check the logic carefully for all states to ensure that transitions
happen correctly according to your state diagram.
Creating new field derivations in the master.tmpl file inserts the new data into the flat file in the allbugs directory, making it available for display, however, it does not insert new data into the ClearDDTS SQL database. To use the new fields in reports, sorting, or querying you must modify the SQL database to include them.
To modify the database, edit the database schema file. See Chapter 13, Managing and Customizing the ClearDDTS Database, in the ClearDDTS Administrator's Guide for details.
Create the projects that correspond to the process you documented in Step 1: Planning. Use projects to group defects that correspond to individual products or components of a product. To add a new project use the adminbug aprj command. This command leads you through a multiple step set-up process, then broadcasts the new project to the ClearDDTS network. Creating a project involves:
entering a unique name, description, and optionally a part number for the project determining the class to which the project belongs identifying which, if any, remote sites can modify defects in the project (see Step 5: Distribution, for a caution about this feature) establishing a notification list of users who are notified when defects in the project enter a particular state setting up project security to determine who can move defects in the project from state to state
For a detailed explanation of the prompts and options for the aprj
command see Chapter 5, Maintaining
Classes and Projects, in the ClearDDTS Administrator's Guide.
ClearDDTS supports several types of security. To complete your customization of ClearDDTS, read Chapter 12, Managing ClearDDTS Security, in the ClearDDTS Administrator's Guide, to learn how to implement security in your environment. Types of security include:
HTTP (web) security controls access to ClearDDTS via the web Write Access Control determines who is allowed to make changes to defect records based on project (see Creating and customizing projects early in this section) Read Access Control determines who may view defects Field-level security (xddts specific) Note: If you plan on using the webddts interface, carefully read the section on HTTP (web) security in Chapter 12.
[TOC] [Step 1: Planning] [Step 2: Installation] [Step 3: Customization] [Step 4: User Access] [Step 5: Distribution]