How to use the DLS CRO Issue Management Tool
In the past the Central Reporting Office (CRO) provided this tool to manage problem reporting, investigation and resolution when local resolution was not possible. Although the responsibility for problem resolution now lies with the SESAR Deployment Manager, it has been agreed that the current tool should continue to be used to track problems. To avoid making too many changes the tool will continue to include some references to the CRO (for example each ticket has a 'CRO' prefix) and will continue to be referred to as the CRO Issue Management Tool (CIMT).
This tool is based on a commercial issue tracking application called JIRA. The tool is used to manage problem reporting and requests for interoperability testing and is now available for use. Below is an explanation of how the tool should be used. A short video is also available. If you do not have a login for the tool and think you need one please email us.
- 1 Basic Concepts
- 2 The Problem Report Workflow
- 3 The Inter-operability Testing Workflow
- 4 Some useful JIRA features
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 issues.
- Security Levels. These determine which users may see individual issues.
- Issue types. The concept of an 'issue' is central to JIRA. We have defined a limited set of issue types.
Types of Issue
JIRA manages 'issues'. For managing problem reporting and investigation three types of issue have been defined: i) a problem report ii) a problem investigation and iii) a sub-task, and for managing interoperability testing requests a fourth type of issue is defined iv) an interop testing request.
- Problem reports are used to record problems with any part of the data link services implementation. Typically these are raised by link stakeholders and describe the observed problem.
- Problem investigations are used to confidentially record the ongoing investigation of a problem report. A problem investigation will be linked with the corresponding problem report but access will be restricted to people directly involved in the investigation to protect confidentiality. As the investigation progresses the corresponding problem report may be updated to report progress. Log files etc. will normally be attached to problem investigations to keep them confidential.
- 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).
- Interop testing request (ITRs) are used to request the support of the Data Link testing Facility at EEC Brétigny for inter-operability testing of ATN/VDL-M2/CPDLC Airborne and Ground systems prior to their operational use.
The following roles are defined:
- Registered users: A person who is considered a trudted member of the data link community and has been given access to the issue management tool. Each organisation participating in the implementation of the data link services is expected to have at least one registered user.
- Reporter: The registered user who created the issue.
- Assignee: The registered user who is currently responsible for the issue.
- Coordinator. This person is responsible for managing the overall process and is assigned the responsibility for a problem report if it is not assigned directly by the reporter. The Coordinator has the right to then assign the PR to other registered users to analyse.
- Datalink Test Facility Manager. This person is responsible for managing the interoperability testing and will be assigned all interop testing request type issues.
- CRO Core Team. This was used in the past to make the tickets available to the CRO team. This role still exists in the tool but there is no longer a CRO core team analysing any problems; the 'CRO Core team' will be a member of the DPMF team that manages CIMT and may assign tickets to other registered users for resolution..
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 issue. A group is defined for each organisation which will include all 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.
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 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 community, users are requested to make the PRs visible to all 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.
- None. When this security level is selected the PR will be visible to all registered users.
The Problem Report Workflow
The workflow for a problem report issue is as shown in the diagram below and is the standard workflow for JIRA and is hopefully self-explanatory. 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.
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 or assigned to another user for action.
- 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.
Raising a Problem Report
Creating an issue
It's really simple to create a problem report. Simply click on the 'create issue' link at the top right hand corner of the starting dashboard, as illustrated below.
You will then be presented with the problem report form to fill in as shown below. It consists of a single form with a number of tabs. The contents of the various tabs and fields are described in the next section.
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.
|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 users 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.|
The Inter-operability Testing Workflow
The workflow for an inter-operability testing request is as shown in the diagram below.
Here is a description of what it means when a interoperability testing request has a particular status:
- OPEN.The request is assigned to the Datalink Test Facility Manager.
- RESOLVED with Resolution Completed or Rejected. The test session has been Completed or the test request has been Rejected
- CLOSED. After the test session has been resolved
Raising a Testing Request
Creating Issue First
It's really simple to create a Testing request. Simply click on the 'create issue' link at the top right hand corner of the starting dashboard as for Problem Reporting
Creating an Interop Testing Request
Select Interop Testing Request in the ‘Issue Type’ field, as illustrated below. You will then be presented with the Interop Testing request form to fill in as shown below. It consists of a single form with a number of tabs. The contents of the various tabs and fields are described in the next section.
The Interop Testing Request Form
Contents of an Inter-operability Testing Request An Interop Testing Request consists of a set of fields presented on seven different tabs within a window. Common Tabs Five of the tabs are common to all kind of requests. The fields on each tab, their possible values and what those values mean are explained in the table below.
|Request Description||Summary||Free text||A title for the request|
|Description||Free text||A detailed description of the request|
|Requestor||Free text||Name and organisation plus email address of the requester.|
|Request Start Date||Date format dd/mmm/yy||Date for start of testing period, selected from calendar|
|Expected Duration||Free text||Expected duration of the testing period|
|Attachment||Any type of file||Used to attach files to the testing request (e.g. Inter-operability Test Plan, Architecture description)|
|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 if the testing is related to any registered CRO Problem Report.|
|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 testing.|
|Priority||Priority||Major||A request related to an issue that has a significant operational impact on the provision of datalink services|
|Medium||A request related to an issue having an operational impact on the provision of datalink services|
|Minor||All other requests.|
|Visibility||Security Level||Reporter and CRO Core Team||Only the reporter and the CRO core team will be able to see this request.|
|Organisation and CRO Core||Only other members of the reporters organisation and the CRO core team will be able to see the request.|
|CRO members||All registered members of the CRO will be able to see this request.|
|None||Any anonymous user can see the ITR. Note at the moment there is no intention to have anonymous users but this option is preconfigured by JIRA and can't be removed.|
Three Tabs are customised according to the type of request, which could be:
- Test Env Air side : Air side testing environment (Avionics Vemdors, OEMS, Airlines, CRO),
- Test Env Ground side: Ground side testing environment (for ANSPs, Industrial Partners, CRO),
- Test Env A/G: Air/Ground testing environment (CSPs, CRO):
Only one Tab can be selected for a single test request and one Tab selection will lead to a customised form to be displayed. The customised forms and associated fields are detailed below:
Test Env Air side Form
Test Env Ground side Form
Test Env A/G Form
Some useful JIRA features
The problem reporting tool has a number of useful features 'out of the box'. A few are highlighted below, but the documentation for JIRA is available on line and pretty good.
- Comments. Comments may be added to an issue at any stage.
- Notifications. Emails will be sent to the reporter and assignee whenever anything changes on the problem report.
- Search. There is a rich search facility that allows you to set up complex searches and save them as filters.
- Watch. It is also possible to 'watch' a problem report that is of particular interest to you. When you watch a problem report you will be sent email notifications of any changes. You have to be eligible to see a problem report before you will be able to watch it.
- Dashboards. It is possible to configure your start screen to contain a number of gadgets to show you information that is of particular interest to you.