How to use the DLS CRO Issue Management Tool

From WikiLink
Revision as of 16:15, 8 February 2018 by Disaac (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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.

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 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.


Roles

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..

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 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.

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 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.

JIRA workflow.jpg

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 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.

Creating an issue

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.

The Problem Report Form

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.

Contents of a problem report
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 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.

ITR workflow.png

Statuses

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.

Creating an ITR issue

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.

Contents of a problem report
Tab Field Values Meaning
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.

Customised Tabs

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 Air side form

Test Env Ground side Form

Test Env Ground side form

Test Env A/G 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.