CASEVision/Tracker 2.0 is a highly flexible tool that enables software organizations to create their own systems for tracking bugs and enhancement requests. There is no need to change your current method of making and tracking requests. Unlike commercial off-the-shelf systems, which are usually limited to a specific methodology and are difficult to modify, Tracker systems can be built from the ground up or from one of the starter systems provided.
The starter systems are rtsquery, a full-featured tracking system, and sample1, a more rudimentary system that can be used as a building block.
This chapter covers these topics:
Tracker terminology
Tracker design tools
Tracker design cycle
To understand Tracker system design, it is helpful to know a few of the terms used in Tracker. The term request refers to the type of data that you are tracking in the system, typically bug reports or requests for enhancement (RFE). A full report contains all the information associated with the request, such as submitter, owner, priorities, and dates.
The program that a user runs to access a request is an application. A view is a window for inspecting or changing a request. An application generally has a main view with most of the request information and one or more auxiliary views (see definition below). The main view is special in several ways: it appears when you first start the application, whereas auxiliary views are windows that open from the Views menu in the main view. Exiting the main view exits the entire application, while exiting an auxiliary view merely closes that one window.
Figure 1-1 shows rtsquery, the starter application provided by Silicon Graphics Inc., which is a typical Tracker main view.
The main sections of the window are labeled. Report #, Description, and Type in the request form area represent typical fields.
If you want different main views for different types of users, you can create supplementary applications. A supplementary application uses the same request database as the main application but has a different main view and potentially different auxiliary views. Supplementary applications can serve as filters for users doing specific tasks that don't require all of the fields (see definition below).
Auxiliary views supplement the main view and are used for special data or for users who require limited information or functionality. RTSfiles, for example in Figure 1-2, lets users enter the names of files in which a bug has been located into its three fields: Found in:, Resolved in:, and Fixed Releases:. The bug itself is listed at the top.
Within a window, there are display areas, which are groupings of related fields, enclosed by boxes. A field is a piece of information in a request. A field that has multiple lines may have a sash control. A sash is a small square “knob” near the right edge of a window that lets users change the size of a multi-line field by dragging it up or down. Fields are discussed in detail in “Field Declarations” and display areas are discussed in “View Declarations” in Chapter 2.
A transition is an operation performed through a view that changes the request either in terms of status or data. Transitions are accessed from the Modes menu in the view's control bar (see Figure 1-1). Note that the selections “Query” and “Display” also appear in the Modes menu but are used for inspection rather than request modification.
A transition can have associated rules and actions. A rule is a required condition necessary for the transition to take place. For example, rtsquery requires a description entry for submitting requests. An action is an operation performed as part of the transition. For example, when a request is submitted, the submit date changes to the current date.
Transitions are discussed in detail in “Transition Declarations” in Chapter 2.
A Tracker request tracking system has a graphical user interface (GUI) and a database of requests. Tracker provides these tools for designing a system:
process description language (PDL)
data manipulation language (DML)
Tracker application generator (tvgen)
Tracker X resources file (app-defaults)
At the heart of a Tracker request tracking system is the PDL file, a file coded in the process description language. A single PDL file can define a complete request tracking system, including the data to be recorded, the operations allowed on that data, rules controlling those operations, automatic actions performed by the system, and the application from which users can access the request database. The PDL is discussed in Chapter 2, “Using the Process Description Language (PDL).”
The data manipulation language (DML) is an interface to the Tracker database. It is similar to SQL and other fourth-generation database query languages. All queries and database transactions are made through the DML. The system administrator controls access to the database through the DML, and can set permissions for individuals who need to make modifications to the database using DML. Figure 1-3 illustrates database access in Tracker.
Most users access the database from a Tracker application window (generated from a PDL file). You can also access the DML directly from a shell for more complex queries on the database, report generation, and batch database modifications. The DML is hidden from users in the GUI. Database access is discussed in Chapter 3, “Using the Data Manipulation Language (DML).”
The tvgen program generates Tracker application files from PDL files, as shown in Figure 1-4. It produces a script containing user-editable views, a Tracker database with supporting files and directories, an app-defaults file containing user interface resources, and help files. Field and transition definitions are stored in the database. After you run tvgen, you can make changes to any of the new files.
Finally, each user must run tvinstall to create links to the application files. Installation using tvgen and tvinstall is described in Chapter 4, “Tutorial–A Basic Tracking System.”
The app-defaults file lets you fine-tune many aspects of the appearance and behavior of the applications. Tracker provides a number of predefined features that can be selected through the PDL. You can make other adjustments to the app-defaults file as well before distributing the complete applications to the users. For more information, see “Customizing Resources” in Chapter 6, “Advanced Design Techniques.”
The designer of the request tracking system typically performs the following steps to build a request tracking system for an organization:
Identify all the information to be tracked, the users, groups, and any special needs they have.
Define the desired request tracking and approval process. In particular, define the different states of a request as it goes through the process. (A state transition or data flow diagram may be useful.)
The state transition diagram for requests in the rtsquery system is shown in Figure 1-5.
Determine whether to use one of the starter systems supplied by Silicon Graphics or build a new system from scratch.
Note: As with other programming methods, sometimes it is easier to modify an existing system than to create a new one. Develop a PDL file to match the desired process.
Compile the PDL file and specify the request database by using the tvgen utility.
tvgen checks the syntax, creates an empty database if necessary, loads the PDL into the request database, takes care of on-line help, and stores the application in a subdirectory called tools for mounting or copying to other systems.
The application's name is based on the name of the main view defined in the PDL file, shifted to all lower case (the convention for IRIX commands). For more information, see the tvgen man page.
Provide further customization if desired.
Typical customizations at this point include resource settings in the app-defaults file (named tools/Tracker.adinstall) or addition of any external scripts used by applications. For more information, see Chapter 6, “Advanced Design Techniques.”
Let users access the new application.
The tools subdirectory, created in the database directory by tvgen, should be copied or NFS-mounted onto each user's system (it does not matter where). Then, run the script tvinstall on the user's system to complete the installation.
When the system is fully installed, the user can start the application generated by tvgen by entering its name on the command line.