Difference between revisions of "How to use the CRO Problem Reporting tool"
Line 55: | Line 55: | ||
|- | |- | ||
| REOPENED | | REOPENED | ||
− | | The problem | + | | The problem requires further investigation. Previously proposed resolutions may have proved ineffective or not possible to implement. |
|- | |- | ||
|} | |} |
Revision as of 16:05, 2 March 2012
This tool is based on a commercial issue tracking application called JIRA, which has been specially configured to meet the needs of the CRO.
Basic Concepts
There are a number of basic concepts that need to be defined before the workflow can be described.
- Roles. These are used in the definitions of privileges and notifications etc.
- Groups. These define groups of users and are used primarily to control access to problem reports.
- Security Levels. These determine which users may see individual problem reports.
- Issue types. The concept of an 'issue' is central to JIRA. We have defined a limited set of issue types for use by the CRO.
Roles
The following roles are defined:
- CRO registered users: A person who is considered a member of the CRO and has been given access to the problem report database. Each organisation participating in the implementation of the data link services is expected to have at least one CRO registered user.
- Reporter: The CRO registered user who created the problem report.
- Assignee: The CRO registered user who is currently responsible for the problem report.
- CRO Coordinator. This person is responsible for managing the overall process. They will be assigned the responsibility for a problem report when it is first assigned to the CRO. They have the right to then assign the PR to members of the CRO Core team to analyse.
- CRO Core Team. This is the team of subject matter experts (SMEs) at EUROCONTROL who will analyse the problem reports submitted to the CRO. They are all CRO registered users.
Groups
There are a number of different groups of people defined. These groups are used when determining which registered users should be allowed to see a particular problem report. A group is defined for each organisation which will include all CRO registered users working for that organisation and the CRO Core Team. For example a group will be defined for "DFS+CRO Core" to include all registered users from DFS and the CRO core team members.
Security Levels
It is recognised that the contents of some PRs may be sensitive, and as such the person reporting it may not want it to be made available to the whole CRO community. So it will be possible to restrict the visibility of PRs to be just the person reporting the problem and the CRO core team (who will not make specific details about the problem available to others). However in the interests of generally improving awareness among the CRO community, users are requested to make the PRs visible to all CRO registered users whenever possible.
The following security levels are defined. They determine which users may see any particular problem report.
- Reporter and CRO Core. This is the default security level applied when a problem report is first created. It restricts the visibility to just the user that raised the problem report and the CRO core team.
- Organisation members and CRO. When this security level is selected the problem report will be visible to all CRO registered users from the same organisation as the reporter and the CRO core team.
- All CRO members. When this security level is selected the PR will be visible to all CRO registered users.
Types of Issue
JIRA manages 'issues'. For use by the CRO two types of issue have been selected: i) a problem report and ii) a sub-task. Problem reports are used to record problems with any part of the data link services implementation. Sub-tasks are used to break down the work that may be required to resolve a particular problem report. Sub-tasks are used to record actions and assign them to individuals. They are always associated with a parent problem report, but in many ways are treated the same as problem reports within the tool (as it is based on tracking 'issues' and both problem reports and sub-tasks are types of issue).
The Problem Report Workflow
The workflow for a problem report issue is as shown in the diagram below. The workflow is designed to accomodate the inclusion of problem reports that may be analysed and resolved locally (i.e. without sending the problem report to the CRO for investigation). Whilst the problem report is in the OPEN state it is under the responsibility of the local CRO member. If the problem is resolved locally then the resolution can be recorded against the problem report and the report closed by the local CRO member. It is hoped that local CRO members will record their problems in the CRO tool even if they are resolved and closed locally, in order to allow the CRO to maintain an overall picture of the problems being raised within the community. If the problem cannot be resolved locally then the problem report is assigned to the CRO and the CRO Core team becomes responsible for resolving and then closing the issue.
Statuses
Here is a description of what it means when a problem report has a particular status (note the Create status is a starting state and is only shown for completeness):
OPEN | The PR is assigned to the reporter. At this stage the PR may be investigated locally. |
ASSIGNED TO CRO | The PR is assigned to the CRO Core team for investigation and resolution. The CRO coordinator will assign the PR to the appropriate SME to investigate. |
RESOLVED | A resolution to the problem has been identified and may have been implemented. |
CLOSED | The problem has been solved, any proposed solutions have been implemented and no further action is required. |
REOPENED | The problem requires further investigation. Previously proposed resolutions may have proved ineffective or not possible to implement. |