Overview

The ptdev template supports a typical software development process. Typical of this process is the bundling of numerous bug fixes into a particular software release. This model assumes the follow organizations are involved in the defect tracking process:

Engineering
Responsible for performing engineering development tasks necessary to handle the request.

QA
Verifies that the request has been successfully implemented by the Engineering organization.

Build
Places the updated files into the final product package.

Data Record

The data record contains the following fields. Note that you can customize the database by adding to or removing fields, or changing any pulldown menu values. Field names with an asterisk are required by the system and cannot be removed from the data record.

PRN*	Numeric record identifier. Assigned at the time the record is created.
Title	A one line text summary of the problem report. Set at the time the record is created.
Product*	Identifies the product the problem record has been reporter for. Set at the time the record is created.
Platform	Describes the hardware or software platform the problem occurs on. Examples are the operating system (e.g. Windows 95), or the CPU (e.g. Intel Compatible). Set at the time the record is created.
Reported In Version	Version number of the product that the problem occurs on. Set at the time the record is created.
Request Type	Classifies the problem report. Possible values are: Bug, Contract Requirement,Customer Feedback, Customer Problem, Enhancement. Set at the time the record is created.
Severity	Describes how serious the problem is. Set at the time the record is created.
Description	Full description of the problem. Ideally describes the nature of the problem and how to reproduce the behavior. Set at the time the record is created.
Reported By*	Name of the user that reported the problem. Initially set to the name of the current user logged in. Set at the time the record is created.
Date Reported	The date the record was created. Automatically initialized, and set at the time the record is created.
Workaround	Describes how to work around the reported problem. Set at the time the record is created.
Status*	Current state of the problem record. Changes as the record is processed through the workflow.
Substatus	Describes the the condition of the record in the current state. Possible values are: None, In Progress. Optionally set by each user while processing the record.
Assigned To*	User the record is currently assigned to for processing. Set either manually or automatically during processing of the workflow.
Estimated Size	Used to enter an estimated amount of time it will take for an engineer to fix the problem.
Released in Version	Identifies the release number of the product that the fix for the problem report will be included in.
Fix - Close Date	Date when the problem record was fixed. Set by Engineering when the problem is fixed. Automatically initialized to the current date/time.
Fix-Close Description	A Description of the action taken by an engineer to fix the problem. Set by Engineering when the problem is fixed.
Priority	Describes the relative importance of handling this record compared to other records entered in the system.
Deleted*	Has the record been deleted.

Workflow

The workflow implemented by the ptdev database is as follows:

1. State 1 - Reported
   When a record is created, it is set to the state "Reported", and assigned to the user named "process_mgr". It is assumed process_mgr is responsible for looking at all incoming problem reports and deciding whether to start the process for the record (by changing the state to "Scheduled" and assigning it to the engineering manager) or to defer processing (by placing it into the "Deferred" or "Closed" states). After the process_mgr user has decided that to process a record, he/she changes the state of the record to "Scheduled" and assigns the record to the "eng_mgr" user by using the Task operation.

   This is implemented by defining Reported as the default state when a record is added, assigning the process_mgr user as the manager for the Reported state, defining the Status and Assignee field to be presented for the Task operation on the Reported state, and by assigning eng_one as the manager for the Scheduled state.

2. State 2 - Scheduled
   The eng_mgr user is assumed to be a manager responsible for assigning tasks to development engineers for resolution. The eng_mgr user decides to assign the record to the "eng_one" user by using the Task operation. This places the record in the "In Development" state.

   This is implemented by defining the "In Development" state as the next state for "Scheduled", and defining the Assignee field to be presented for the Task operation on the "Scheduled" state.

3. State 3 - In Development
   eng_one makes the changes necessary to address the problem reported in the record and marks the task complete using the Task operation, which allows eng_one to enter a description of the fix, advances the state of the record to "Fixed", and assigns the record to the "qa_mgr" user.

   This is implemented by defining "Fixed" as the next state for "In Development", defining the Fix-Close date and Fix-Closed description to be presented for the Task operation on the "In Development" state, and defining the qa_mgr user as the manager for the Fixed state.

4. State 4 - Fixed
   Once the record has entered the "Fixed" state, the qa_mgr user assigns the record to the QA engineer "qa_one" and advances the state to "In QA" by using the Task operation.

   This is implemented by defining "In QA" as the next state for "Fixed", and defining the Assignee field to be presented for the Task operation on the "Fixed" state.

5. State 5 - In QA
   qa_one verifies that the problem report has been resolved, and then uses the Task operation to advance the state to "Tested" and assigns the record to the "bld_mgr" user.

   This is implemented by defining "Tested" as the next state for "In QA", and defining the user "bld_mgr" as the manager for the Tested state.

6. State 6 - Tested
   The bld_mgr user is assumed to be the user in charge of packaging the product for release, and responsible for ensuring that all the desired fixes are included in the release. bld_mgr does what is necessary to make sure that the fix for the record is included in the release, and the advances the state of the record to "Released" using the Task operation.

   This is implemented by defining "Released" as the next state for "Tested", and defining the user "process_mgr" as the manager for the Released state.

7. State 7 - Released
   This state indicates that processing of the record is complete.

8. State 8 - Closed
   This state indicates that the record will not be processed.

9. State 9 - Deferred
   This state indicates the decision on whether or not to process the record has been deferred until a future date.

Email Notification

The ptdev template is set up to notify users as follows:

On Add or Delete Record
Both the current assignee, and the manager for the current state are notified.

On Change of State
The manager for the new state is notified.

On Change of Assignment
Both the previous and current assignee are notified of the change, and the manager for the current state is notified.

Security

The ptdev template assumes a very simple security model reflecting a workgroup situation where all users are considered knowledgeable in use of the system and are trusted to perform the appropriate actions. As such, all manager and users have been given access to all operations except the admin operations, which are only available to the Admin user.

Since no restrictions are placed on any users as far as visibility of records, all users are able to see any record. This is implemented by setting Enable Record-Level Security option under General Preferences in the Administration Task page to No.