Overview
The Web Site Development template supports a traditional web site development
process. Typical of this process is the immediate posting
of bug fixes to the web site being developed and maintained.
This model assumes the following organizations are involved
in the defect tracking process:
Development
Responsible for performing development tasks
necessary to handle the request.
QA
Verifies that the request has been successfully implemented
by the Development organization.
Build
Places the updated files onto the live server.
Projects
A default project called "Web Site Development"
is available in this template and is visible to all
user groups. This project can be customized
and additional projects can be added via the
Projects
section.
Forms
A default form called "Issue" is available in this
template, is associated with the "Web Site Development" Project
and is visible to all user groups.
This form can be customized and additional
forms can be added via the
Forms
section.
Fields
The Issue form contains the following fields. Note that
you can customize the database by adding to or removing
fields, or changing any pulldown menu values via the
Fields section.
Field names
with an asterisk are required by the system and cannot
be removed from any form(s).
PRN* |
Numeric record identifier. Assigned
at the time the issue is created. |
Title |
A one line text summary of the
problem. Set at the time the issue is created. |
Product* |
Identifies the product related to the
issue has been reported. Set at the time the
issue is created. |
Last Updated Date* |
The date and time the issue was last modified.
Set automatically as the issue is processed through the workflow. |
Browser |
Identifies the browser type related to the
issue that has been reported. Set at the time the
issue is created. |
Platform |
Describes the hardware or
software platform where the issue occurs. An example
is the operating system (e.g. Windows XP). Set at the time
the issue is created. |
Problem URL |
URL of the web page where the issue
was found. Set at the time the issue is created. |
Request Type |
Classifies the issue. Possible values are: Bug, Contract
Requirement, Customer Feedback, Customer
Problem, Enhancement. Set at the time the issue
is created. |
Severity |
Describes the relative impact of the
issue. Set at the time the issue is
created. |
Description |
Full description of the
issue. Ideally describes the nature of the
problem and how to reproduce the behavior.
Set at the time the issue is created. |
Reported By* |
Name of the user that
reported the issue. Initially set to the
name of the current user logged in. Set at
the time the issue is created. |
Date Reported |
The date the issue was
created. Automatically initialized, and set
at the time the issue is created. |
Workaround |
Describes how to work
around the reported issue. Set at the time
the issue is created. |
Status* |
Current state of the
issue. Changes as the issue is
processed through the workflow. |
Substatus |
Describes the
condition of the issue in the current state.
Possible values are: None, In Progress. Optionally
set by each user while processing the issue. |
Assigned To* |
User the issue is currently
assigned to for processing. Set either manually
or automatically during processing of the
workflow. |
Operating System |
The operating system installed on the machine of the
user who reported the issue. Set automatically when the ticket
is created using the
AutoFill feature. |
Reporter's Web Browser |
The browser installed on the machine of the
user who reported the issue. Set automatically when the ticket
is created using the
AutoFill feature. |
Screen Size |
The screen size set on the machine of the
user who reported the issue. Set automatically when the ticket
is created using the
AutoFill feature. |
Estimated Size |
Used to enter an estimated
amount of time it will take for a developer
to fix the issue. |
Fix Date |
Date when the issue
was fixed. Set by Development when the issue is
fixed. Automatically initialized to the current
date/time. |
Fix Detail |
A Description of the action taken
by a developer to fix the issue. Set by Development
when the problem is fixed. |
Test Date |
Date when the fix
was tested. Set by QA when the fix for the issue is
tested. Automatically initialized to the current
date/time. |
Test Description |
A Description of the action taken
by a QA Engineer to test the fix. Set by QA
when the fix is tested. |
Test URL |
A URL where the fix can be tested. Set by
Developer when the issue is fixed. |
Priority |
Describes the relative importance
of handling this issue compared to other issues
entered in the system. |
Close Date |
Date when the issue
was closed. Set by Process Manager when no development
work will be done on an issue. Automatically
initialized to the current date/time. |
Close Detail |
A Description of the reason for closing
an issue. Set by the Process Manager when no development
work will be done on an issue. |
Defer Reason |
Describes the reason an issue will
not be worked on until a later date. |
Duplicate Record # |
Lists the record number of another
previously-entered issue in the database which describes the
same problem. |
Date Released |
Date when the fix for the issue
was released. Set by the Build Manager when the fix for the
issue is released. Automatically initialized to the current
date/time. |
Deleted* |
Denotes whether the issue has been deleted. |
Workflows
It is assumed that issues will be processed and moved through the workflow
process by using the Task operation. A default workflow called
"Web Site Issue Process" is available
in this template and is associated with the "Issue" Form and
is in use in the "Web Site Development" Project.
You can customize the Web Site Issue Process
workflow or add additional workflows via the
Workflows section.
- State 1 - Reported
When an issue is created, it is set to the state
Reported, and assigned to the Process Manager
(process_mgr). It is assumed that the Process Manager
is responsible
for looking at all incoming issues and
deciding how to process each one from a list of
possible workflow paths. The Process Manager can choose one of the
following:
- Start the process for the issue by selecting the transition called
Schedule. This transition will assign the issue to the Development Manager
(dev_mgr) and place the issue in the Scheduled state. The Process Manager
can also enter a Priority for the issue
when choosing this transition.
- Defer the processing of the issue by selecting the transition called
Defer. This transition will place the issue in the Deferred state and
assign it to the state manager of that state (process_mgr). The Process Manager
can review
deferred issues at a later time and decide whether processing will
resume.
- Close the issue by selecting the transition called Close. This
transition will place the issue in the Closed state and assign it to TBD
(no one - since this issue will not be processed any further). The Process Manager
will be required to enter a reason
the issue was closed in the Close Detail field. The Close Date will be updated
automatically.
- Mark the issue as a duplicate of another issue by selecting the
transition called Mark Duplicate. This transition will place the issue
in the Duplicate State and assign it to TBD (no one - since this issue
will not be processed any further). The Process Manager will be required to
enter the issue number of the original issue that describes the
same problem.
This is implemented by:
Workflow Properties
- Defining Reported as the Default Add
State when an issue is added
- Assigning the process_mgr user as the manager for
the Reported and Deferred states
- Assigning dev_mgr as the manager for the Scheduled state
Transitions
- Defining transitions to move an issue to the Scheduled and
Deferred states where the assignee is the State Manager
for each respective state.
- Defining transitions to move an issue to the Closed and Mark
Duplicate states where the assignee is TBD for each transition.
Task Fields
- Configuring Priority (optional) to be presented during
the task operation for the transition to the Scheduled state.
- Configuring Defer Reason (required) to be presented during the task
operation for the transition to the Deferred state.
- Configuring Close Detail (required) and Close Date (read only and initialized)
to be presented
during the task operation for the transition to the Closed state.
- Configuring Duplicate Record # (required) to be presented during the task
operation for the transition to the Mark Duplicate state.
- State 2 - Scheduled
The Development Manager (dev_mgr) is assumed to be a manager
responsible for assigning tasks to the developers
for resolution.
The Development Manager uses the transition Assign to Developer
to assign the
issue to a developer (dev_one),
a member of the "Developers" user group.
This places the issue in the In Development
state. The Development Manager can also decide to defer a
issue by choosing the Defer transition, which will place the issue
in the Deferred state and assign it to the Process Manager (process_mgr).
This is implemented by:
Transitions
- Defining a transition to move an issue to the
In Development state with the assignee to be chosen
from a list of developers (User Group called "Developers")
- Defining a transition to move an issue to the Deferred
state with the state manager as the assignee
Task Fields
- Configuring Defer Reason (required) to be presented during the
task operation for the transition to the Deferred state
- State 3 - In Development
The Developer (dev_one) assigned to the issue
makes the changes necessary to address the problem and can either
update any progress made on the issue using the Update transition or
can mark the
task complete using the transition called Mark Fixed. The Mark Fixed
transition allows the
Developer to enter a description as well as a URL to
be used by QA to test the fix, advances
the state of the issue to Fixed, and
assigns the issue to the QA Manager (qa_mgr). The Fix Date will be automatically
set to the current date and time.
This is implemented by:
Workflow Properties
- Defining the qa_mgr as the manager for the Fixed
state
Transitions
- Defining a transition with New State set to
In Development and New Assignee set to "<Same Assignee>"
- Defining a transition to move an issue to the
Fixed state where the assignee is the State Manager
Task Fields
- Configuring Fix Detail (required) to be presented during the Task operation for the
Update transition. The Description field is presented as a read only
task field for the Developer's reference when choosing this transition.
- Configuring the Fix Date (read only and initialized), Fix Detail (required),
and Test URL (optional) to
be presented during the Task operation for the transition to the
Fixed state. The Description field is presented as a read only
task field for the Developer's reference when choosing this transition.
- State 4 - Fixed
Once the issue has entered the Fixed state,
the QA Manager (qa_mgr) assigns the issue to the
QA Engineer (qa_one), a member of the QA user group, and advances the state
to In Test by using the transition called Assign to QA Engineer.
This is implemented by:
Transitions
- Defining a transition to move an issue to the
In Test state with the assignee to be chosen
from a list of QA Engineers (User Group called "QA")
- State 5 - In Test
The QA Engineer (qa_one) verifies that
the problem has been resolved, and
then uses the transition Mark Tested to advance the
issue to the Tested state and assigns the issue
to the Build Manager (bld_mgr). If a problem
has not been resolved and needs to be returned to
Development, the QA Engineer can move the issue back to the
In Development state and assign it to the developer
who worked on the issue by using the Reject transition.
For each of these possible
paths, the QA Engineer enters information in the Test Description
and Test URL fields. The Test Date is automatically updated.
This is implemented by:
Workflow Properties
- Configuring bld_mgr to be the manager of the
Tested state
Transitions
- Defining a transition to move an issue to the Tested
state where the assignee is the state manager
- Creating a transition to move an issue to the
In Development state or <Previous State>
where the assignee is the
Last Assignee for the New State.
Task Fields
- Configuring Test Date (read only and initialized), Test Description (required),
and Test URL (optional) to be
presented during the Task operation for the transitions
to the In Development and Tested states. The Fix Detail field is
presented as a read only task field for the QA Engineer to reference
when selecting this transition.
- State 6 - Tested
The Build Manager (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. The Build Manager does what is necessary to
make sure that the fix for the issue is included
in the release, then advances the state of the
issue to Released using the transition Release. The
Date Released field is automatically updated.
This is implemented by:
Transitions
- Defining a transition to move the issue to the Released
state where the assignee is TBD ("no one" as the processing for
this issue has been completed).
Task Fields
- Configuring Date Released (read only and initialized) as a
field to be presented during the task operation for the
transition to the Released state
- State 7 - Released
This state indicates that processing of the issue
is complete.
- State 8 - Closed
This state indicates that the issue will not
be processed.
- State 9 - Deferred
This state indicates the decision on whether or not
to process the issue has been deferred until a future
date. The Process Manager can update an issue in this state
by using the Update transition. The Update transition will
keep the issue in the Deferred state and assigned to the
same user (process_mgr). The fields Defer Reason and
Priority are presented as optional
fields during the task operation. The Process Manager is
required to enter a history comment to describe what was
changed within the issue when using the Update transition.
The Process Manager can decide to begin processing a
issue by choosing the Schedule transition, which will place the
issue in the Scheduled state and assign it to the State Manager
(dev_mgr).
The Process Manager
can set the Priority field when choosing this transition.
This is implemented by:
Transitions
- Defining a transition called Update with Deferred selected as the
New State (same state), <Same Assignee> set as the New Assignee
and history comment required
- Creating a transition to move the issue to the Scheduled state
and assign it to the state manager
Task Fields
- Configuring Defer Reason and Priority to be presented
during the task operation for the transition to update a deferred issue
- Configuring Priority to be presented during the
task operation for the Schedule transition
Sample Saved Charts
A set of sample saved charts are included in this template.
Click here
to see details of these sample metrics.
Email Notification
The Web Site Development template is set up to notify users as
follows:
On Add or Delete of a Record
The current assignee, the manager for
the current state, and the reporter of the issue are notified
On Change of State to Released, Deferred, Duplicate or Closed
The user who reported the issue is notified when an issue is moved to
a state where processing is stopped
On Change of Assignment
Both the current assignee and the manager for
the current state of the issue are notified
Security
The Web Site Development template assumes a very simple security
model reflecting a workgroup situation where all users are able
to see any issue. This is implemented by setting
Enable Record Visibility option under General
Preferences in the Administration Task page to
No.
In addition, the privileges related to editing the field of the issues have
been removed from users that are not managers or Admin.
With this configuration, users can rely on the Task operation to move issues
through the workflow. This can be changed within the
User Accounts section of the Admin page.
NetResults Tracker © 1997-2014 NetResults Corporation. All rights reserved.