The Product Design Team will submit new feature and change requests for future development. Additionally, bugs may be found during customer support sessions that will be submitted for resolution by the support team.

Any Arts Management Systems team (Support, Management, Development) may, in the course of the day, interact with customers. Issues logged by these groups in FogBugz may include defects with step-by-step instructions about how to recreate the defect, and sample data if necessary (see the section below entitled Secure Storage System).

Feature and change requests will also be submitted to the Product Design Team.

The software quality assurance team ensures that the software we develop passes our rigorous internal testing before it is released. Issues are validated to ensure that the developer has completed the necessary work and that the reported issue is solved in a manner consistent with the product design and customer expectations.

The issues reported from SQA will include refinements to existing issues, new issues caused by a break to existing code, and change requests.

After SQA has completed their testing of a release and prior to releasing that version, products will undergo a few days of User Acceptance Testing. The Arts Management Systems Beta Management Team manages this process with representatives from various Arts Management Systems departments participating in the test effort. The focus is on customer use model testing and is an unscripted process.

Issues logged during user acceptance testing will have step-by-step instructions to recreate and sample data if necessary (see the section below entitled Secure Storage System).

Issues across applications can also be found by developers. These issues may be discovered while working on other issues, or just in use of the product. When an issue is discovered it is the responsibility of the developer to log the new issue even if it is something that is fixed while completing another task. This level of record keeping will ensure that there is accountability for the changes in the applications.

Each issue is assigned a Target Release Date which is the expected release for the change. This assignment is based on the severity of the reported issue, source of the reported issue, and customer priority. Tasks will be assigned to each developer and should be started based on the Target Release Date and priority. If the issue does not have a Target Release assigned, it is possible it is deferred to a future release.

Severity

Within a Target Release tasks should be accomplished based on severity. However, new features and change requests should be implemented prior to bug fixing.

Severity is assigned by the Development Manager

1	Fix Immediately	Critical issue causes a system crash, data loss or corruption. The system becomes unstable or unusable. No workaround exists. Items of this nature should be fixed immediately in a patch release.
2	Fix next point release	Problem of a serious nature causes the software to operate in an unpredictable or detrimental manner with a serious adverse impact to the user. Major functionality is missing or broken. Workaround exists but is unacceptable.
3	Fix in point release if possible, incremental otherwise	A moderate problem causes system functionality to degrade with a moderate adverse impact to the user. Minor functionality is missing or broken. An acceptable workaround to the problem exists.
4	Fix next incremental release	The problem is not detrimental to the operation of the system. It is scheduled for correction in a future major release.
5	Fix if Time	The problem is not detrimental to the operation of the system and will be addressed for the proposed version if there is time. Can be deferred to any subsequent version
6	Undecided	Priority or severity has not been assigned yet
7	Rejected	Issue has been reported that has been determined as either not a bug, how the system operates, or has simply been rejected.