How to use the CRO Problem Reporting tool
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. When moving through the various statuses, for those problem reports that the user is permitted to see they will be presented with buttons giving them the options to move the problem report into the next state, and may be prompted to complete additional information when doing so.
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.
Contents of a Problem Report
A problem report consists of a set of fields presented on four different tabs within a window. The fields on each tab, their possible values and what those values mean are all explained in the table below.
Tab | Field | Values | Meaning |
---|---|---|---|
Problem Description | Summary | Free text | A title for the problem |
Description | Free text | A detailed description of the problem | |
Environment | Free text | A description of the specific environment in which the problem occurs, e.g. which type of aircraft, which type of groundstation etc. | |
Attachment | Any type of file | Used to attach files to the problem report | |
Linked Issues | Select one of: 'blocks', 'is blocked by', 'clones', 'is cloned by', 'duplicates', 'is duplicated by', and 'relates to' and then select the appropriate problem report | Indicates other PRs which are related | |
Affected area | Impacted Areas | A series of check boxes identifying parts of the overall system e.g. CPDLC service, controller HMI, specifications and standards | Check the boxes which indicate which aspects of the overall system are impacted by the problem. |
Priority | Priority | Major | A problem that has a significant operational impact on the provision of datalink services |
Medium | A problem having an operational impact on the provision of datalink services | ||
Minor | All other problems. | ||
Visibility | Security Level | Reporter and CRO Core Team | Only the reporter and the CRO core team will be able to see this PR. |
Organisation and CRO Core | Only other members of the reporters organisation and the CRO core team will be able to see the PR. | ||
CRO members | All registered members of the CRO will be able to see this PR. | ||
None | Any anonymous user can see the PR. Note at the moment there is no intention to have anonymous users but this option is preconfigured by JIRA and can't be removed. |
Other useful features
The problem reporting tool has a number of useful features 'out of the box'. A few are highlighted below, but the [ https://confluence.atlassian.com/display/JIRA/JIRA+User%27s+Guide documentation] for JIRA is available on line and pretty good.