Step 1: Planning

ClearDDTS allows you to freely dictate the life cycle and form for a defect (bug). As provided, ClearDDTS contains a user-configurable state model with a small number of required fields. From this basic design you can customize ClearDDTS with your own classes, state models and fields. To understand the use of classes, states, and projects in ClearDDTS read Chapter 1, Understanding ClearDDTS Operation, in the ClearDDTS Administrator's Guide and Chapter 2, Learning the Basics, in the ClearDDTS User's Guide.

With ClearDDTS, you can define a set of state transitions and associated fields for various defect classes. The software class is uniquely customized to perform defect tracking. It is implemented as a standard life cycle and form, and incorporates resources such as IEEE, DOD, and Case Communique. Use the software class as example when planning your customizations. The examples provided throughout this guide are based on the software class.

Before you begin customizing ClearDDTS, there are several issues to address. Use the following steps to plan your ClearDDTS implementation:

Note: To evaluate what ClearDDTS can do as shipped you can skip to Step 2: Installation. After installation, just test the features, but do not put ClearDDTS into full production. This can give you a better understanding of how you will want to customize the product for your environment. After testing, return here to begin planning your data and network implementation.

Planning your process, form, and fields

Learn basic ClearDDTS operation including how defects are classified, the defect life cycle, naming conventions, and network operation. In particular, understand the role of classes and projects in ClearDDTS and how they can be organized to meet your needs. Read Chapter 1 of the ClearDDTS Administrator's Guide and Chapters 1 and 2 of the ClearDDTS User's Guide.

Formalize your current process. Document the process you want to implement, including what classes and projects are necessary, who is notified of submissions of or changes to defects, what states are included in your defect life cycle, and how defects proceed through your process. Keep the number of classes, projects, and states to a minimum to keep your installation simple and easy to manage. It helps to include the end users when planning the design. Including their input in the formalization process improves the effectiveness of your ClearDDTS implementation.

Do not make customizations to ClearDDTS at this point. For now, concentrate on formulating a process that tracks the required information intuitively. Start with your own process or review the examples for an existing ClearDDTS class and work from there.

Draw the state diagram which portrays how defects move through your model. This diagram helps you to understand your process and also can uncover any errors. (See Chapter 2, Learning the Basics, in the ClearDDTS User's Guide for an example.)

Use a past-tense model for your state diagram. For example, move to the Resolved state AFTER you have fixed a defect, not before. A bug in the Assigned state HAS BEEN assigned to the engineer; it is not ready TO BE assigned. This type of state diagram is much easier to implement and is more intuitive to use.

List the necessary fields and group each with a certain state. For instance, the Resolver-name goes with the (R)esolved state and the Engineer field goes with the (A)ssigned state. Each field should logically belong to only one state with few exceptions.

For each field you should decide what the appropriate values can be. This includes whether to have a set of available choices (pick lists), what the appropriate values are, and whether the field is required or optional upon entry.

Plan your layout. For the UNIX X-interface, xddts, decide how and where each field should be placed (assume a 23 x 80 character window). This will be the format in which defects are entered and viewed. For the web interface, webddts, decide how fields should be grouped and the order they should appear on the web pages.

Develop a logical naming convention for your projects. Each project name must be unique and should be easily identified. This is particularly important if you are working in a multisite environment and plan on sharing project information between sites. For example, project names might include abbreviated organization names to clearly identify the site to which a project belongs.

Planning your network

Determine the layout of your ClearDDTS network and how sites will interact to make the implementation process flow smoothly.

Determine the number of sites (machines) on which to install ClearDDTS and choose their site (machine) IDs. See Chapter 1, Understanding ClearDDTS Operation, in the ClearDDTS Administrator's Guide for a description of how a distributed ClearDDTS network operates. Each site can function independently with local customizations as well as be completely interoperable.

Check your environment and be sure you have sufficient disk space, memory, and CPU speed. See Chapter 1, Installing ClearDDTS, in the ClearDDTS Installation and Licensing Guide for a list of requirements.

Determine how data is shared between sites. For each project, this includes determining which site owns the project and which other sites can access that project's data. For information on the way sites share information see Chapters 3 through 5 in the ClearDDTS Administrator's Guide.

Determine whether to use the ClearDDTS built-in SQL database or an external Oracle database. When choosing a database, consider the volume of records you expect to enter. You may notice improved performance with the Oracle database with record volumes of 15,000 or more.

Plan you web server implementation (or changes to your existing web server) to support the ClearDDTS web interface. Accessing ClearDDTS through the web requires a web server running on a UNIX platform that supports ClearDDTS. It is preferable to have the web server on the same UNIX host as the ClearDDTS server. However, they can be on different hosts if the web server host is a UNIX platform supported by ClearDDTS and has NFS access to the ClearDDTS server.

Determine security requirements including HTTP security setup and who can have read and write privileges at the project and individual defect levels. For a list of the types of security available see Chapter 12, Managing ClearDDTS Security, in the ClearDDTS Administrator's Guide.

[TOC] [Step 1: Planning] [Step 2: Installation] [Step 3: Customization] [Step 4: User Access] [Step 5: Distribution]