JIRA Standard Client. Objectives

Transcription

1 JIRA Standard Client Objectives Introduction Standard JIRA Client Access User profiles Types of issue Functional Support Corrective Feature Request Big Feature Request Parameters and issues window of the JIRA-Client Client dashboard Change of the interface language Integration between Standard JIRA-Client and JIRA-MInd-ALM Introduction Mapping between fields Mapping between status Functional Support Corrective Feature Request Big Feature Request Practical case of a work cycle of a request Creating a task by the client Progress of the issue performed by the supporting team and monitoring by the client Reopening of a task by the client Acceptance and closing of a task by the client Canceling tasks Deleting tasks Automatic calculation of dates Setting dependencies between dates Setting deadlines in the calculation of dates Status in which the issue is stopped Example of automatic calculation of dates Standard JIRA Client with client approvals Issue fields of Standard JIRA Client with Approvals Issue types Workflow of Functional Support issues Workflow of Corrective issues Workflow of Feature Request issues Workflow of Big Feature Request issues Integration between Standard JIRA-Client with Approvals and JIRA-MInd-ALM Mapping between fields Mapping between status of Standard JIRA-Client with Approvals and JIRA-MInd-ALM Functional Support Corrective Feature Request Big Feature Request Objectives This document aims to explain the standard solution built in the MInd Suite to assist in the needs of operations to deal with the management of cu stomer demand.

2 Introduction The platform Standard JIRA Client ( hereafter abbreviated JIRA-Client ) has a standard parameterization, accessible for any operation which request it. It is linked with the internal JIRA of the ALM (Application Life-cycle Management) of the MInd Suite (named onwards in this document J IRA-MInd-ALM). On one side this allows Indra technicians to work homogeneously and in a standard way by using the developing technical life cycle of MInd. Furthermore, the clients benefits from the possibility to monitor the progress of their requests in the JIRA-Client environment. Both systems are integrated in real time through web services. In case the standard solution is not suitable for a particular operation, a customized configuration can be requested. The JIRA-Client offers the designated users by the client the possibility to create tasks (issues) for denoting a work request to be achieved within a service. The types of requests are associated to four types of products: Functional Support, Corrective, Feature Request and Big Feature Request. When client users create an issue in JIRA-Client, it will automatically push the creation of an associated issue in JIRA-MInd-ALM (of the equivalent type Functional Support, Corrective, Feature Request or Big Feature Request). Standard JIRA Client Access The access to Standard JIRA Client takes place through the URL where if the user has not previously opened a session in another MInd tool, a log in with credentials (user name and password) will be required.

3 User profiles There are two user profiles for JIRA-Client: The User of the service is in charge to create the requests (Functional Support, Corrective, Feature Request or Big Feature Request). This user will track the progress of the tasks and can accept or reject the actions and jobs done by the Indra support team. The Responsible of the service can not create new requests. It is a profile oriented to monitor and supervise. Types of issue The four types of issue defined in JIRA-Client are associated with the four categories of requests that the client can demand (Functional Support, Corrective, Feature Request or Big Feature Request). The following sections explain their specific features and display their specific workflows. Functional Support Definition: this type of issue encompasses those activities aimed to solve consultation and the extraction of information through the supporting activities such as upload, process or massive gathering of data, etc. The following image shows the workflow to this type of issues. (In order to see the image enlarged it must be clicked) Some of the transitions of this workflow fall into the domain of the client responsibility and are consequently done from the JIRA-Client. However, some other transitions are responsibility of Indra supporting team and will be performed in JIRA-MInd-ALM. The status Stop or the status Deleted can be reached from any status (except from the status Closed). The following caption shows the color coding used in the previous image to show who is responsible for each transition.

4 Corrective Definition : completion of the appropriate changes to fix the malfunction in maintained systems. It refers to any software error produced in a productive environment already approved by the client. It includes also those errors that do not require software delivery. The following image shows the workflow of this type of issues. (In order to see the image enlarged it must be clicked) Feature Request Definition: this type of issue relates to the low complexity or low size improvement and evolution of the existing applications, including new functionalities, adaptation of the existing ones, and improving the general quality of those. The following diagram shows the workflow to this type

5 of issues. (In order to see the image enlarged it must be clicked) Big Feature Request Definition: this type of issue relates to the high complexity or large size improvement and evolution of the existing applications, including new functionalities, adaptation of the existing ones, and improving the general quality of those. The following diagram shows the workflow to this type of issues.

6 (In order to see the image enlarged it must be clicked) Parameters and issues window of the JIRA-Client All the information belonging to a particular JIRA-Client issue is gathered in a window with the format presented in the following image.

7 The fields that describe the JIRA-Client issues are: Name of the field Key Summary Description Type Component(s) Priority Affected Version(s) Status Resolution Assignee Reporter Comments Description Number of the JIRA request. Descriptive header of the request. Detailed description of the request. Type of product (Functional Support, Corrective, Feature Request or Big Feature Request). It represents the module or application to which the request belongs. It states the priority of the request. Version affected by the request. Status of the request within the workflow of its issue type. It shows how successful the request has been solved. If the field is not filled, JIRA will not mark the request as finished. In order to close a request (status Closed), this field is mandatory. User who has the request assigned. It can be reassigned at any later stage to another user that has the authorization on the component of the issue. The user that has registered the issue. Free text to record any information during the progress of the work. The top part of the window shows the project icon, the name of the project, the key assigned to the issue and the summary given to the issue. The JIRA-Client issue displays a menu at the top of the window, which allows for example to: edit the issue's fields, change the assignee, insert comments, insert a link and attach files. On the right side of the menu, and depending on the status of the issue, there are the transition buttons that are applicable in the current status.

8 Placed left under the issue menu, the Details of the issue are presented, including the main parameters of the issue and the current status of the issue. In the lower part of the section Details could additionally be displayed some tabs. For example, the tab Estimation presents the Estimated Hours and the Billed Hours. Below the Details section is placed the Description area with the detailed description of the request. In the lower part of the issue window is located the section Activity. It contains several tabs with information of the issue changes. The next image shows the tab Comments. It accommodates the comments added from the JIRA-Client as well as those inserted by the Indra supporting team in the associated issue in JIRA-MInd-ALM. The section presents the and the of the issue. Additionally, the section lets adding those users People Assignee Reporter Watchers that should receive notifications about the changes of the issue.

9 Under the People section is the Dates section, which includes all the relevant dates around the issue. The date fields available for each issue are detailed next: Name of the Field Due Created Request Creation Date Commitment Response Date Planned Start Date Description Agreed delivery date. Date when the issue was registered. Date added manually showing the real date of the client request. Expected and agreed date to focus on analysis or start of the activities to resolve the request. For Feature Requests, date required when changing to the Estimated /Planned status. For Correctives and Supports, is the date expected to change to the In Progress status. Planned End Date Mandatory when changing to the status Estimated/Planned. It will take by default the value of Due. It can be however modified afterwards. Start Date End Date Automatic. It is the real start date, that is, the date that the status has changed to In Progress. Although it is a date assigned automatically, it can be changed afterwards by the Assignee profile. Automatic. It takes the value of the time when the issue status changes to Delivered. Indeed, it is the real date of the request delivery. Although it is a date assigned automatically, it can be changed afterwards by the user with the profile Assignee. Resolved Automatic. It takes the time when the issue status changes to, Closed that is, the date when the request has been closed.

10 Updated Attended Automatic. It takes the time when the last change was performed. Automatic. Date when the Indra supporting team registers the beginning of the jobs associated with the issue. Further parameters of the JIRA-Client issues are described in the following table: Name of the field Key Client SLA Exclusion SLA Exclusion Reasons Deliveries Defects Description Number of client request, that is, the code that identifies the request for the client. It points out whether the issue should be excluded on the SLA calculation. This parameter can take the values Si/Yes or No. It contains the comments explaining the reason of the SLA exclusion. Number of deliveries until the issue is approved. Number of defects identified during the user tests. Estimated Hours Initially expected hours to complete the request. Billed Hours Amount of billed hours to the client by the issue work. Client dashboard By default, the client has access to a dashboard that shows the status of the supervised applications. It also allows accessing the issues in which the client is involved. Change of the interface language It is possible to change the user interface language in the JIRA -Client. To achieve this, next steps must be followed:

11 1.- First, select the option Profile from the user menu, which is placed at the top right corner of any JIRA-Client window: 2.- In the Preferences section, there is an icon with a pencil image (see below), please select it to edit.

12 3.- Select from the Language drop down list the one desired for the user interface. Finish this last step by clicking on the Update button. The system will remember the preferred language, so from that moment onwards the user will view the interface in the language selected. Integration between Standard JIRA-Client and JIRA-MInd-ALM

13 Introduction The integration between Standard JIRA Client and JIRA-MInd-ALM makes possible for the operation supporting team of Indra to work homogeneously and in a standard way with the technical development cycle of MInd. At the same time, this integration allows the client to gain a feedback channel through the JIRA-Client environment to be informed about the progress of the requests. The integration between both systems takes place in real time and via web services. Mapping between fields The following table shows the mapping of fields between JIRA-Client requests and JIRA-MInd-ALM issues. The column Direction shows with an arrow the direction of the information flow when there are changes in values. In case there is no relation between the fields of both systems, the D irection is marked with X. Field JIRA-Client Direction Field JIRA-MInd-ALM Comment Summary Summary Description Description Type Issue Type Status Status The values will be updated following the correlation between status explained in the section M apping between status. Assignee X Assignee In JIRA-MInd-ALM, the assignee is set by default to the leader of the component to which the issue belongs to. Reporter X Reporter

14 Component/s Component/s Affect Version/s X Affect Version/s Priority Priority Created Created Due Due Date Date calculated by the system using the field Due Delivery Date. Due Delivery Date Due Delivery Date Due delivery date provided according to the client time zone. Request Creation Date Received Commitment Response Date Commitment Response Date Updated X Updated Attended Attended When the issue in JIRA-MInd-ALM changes from the New status to the Previous Study or Working on it status, the moment in which that transition has taken place is registered in the Attended field of the issue in JIRA-MInd-ALM and JIRA-Client. Planned Start Date Planned Start Date Planned End Date Planned End Date Attachments Attachments Labels Labels Issue Links Issue Links When two JIRA-Client issues are linked, their associated issues in JIRA-MInd-ALM are also linked ( vice versa). Key External Issue ID The field External Issue ID of JIRA-MInd-ALM issue shows the Key of the associated issue in JIRA-Client. External Issue ID Key The field External Issue ID of JI RA-Client issue shows the key o f the associated issue in JIRA-MI nd-alm. Comments Comments From JIRA-Client are transferred all the comments to JIRA-MInd-ALM with the exception the one that is provides in the Continue transiti on from the Stop status. From JIRA-MInd-ALM is transferred to JIRA-Client the comment of the Deliver transitio n.

15 Resolution Resolution When the request in JIRA-Client changes from the Delivered or A pproved status to the Closed st atus, the value of the Resolutio n field will be sent to the Resolut ion field of the associated issue in the JIRA-MInd-ALM. When the request in JIRA-Client, by means of the Reject transitio n, changes from the Closed stat us to the Delivered status, the value of the Resolution field will be sent to the Resolution field of the associated issue in the JIRA-MInd-ALM, and this value will be Unresolved. When the request in JIRA-MInd-ALM, by means of the Cancel transition, changes from the Stop status to the Clos ed status, the value of the Resol ution field will be sent to the Res olution field of the associated issue in JIRA-Client, and this value will be Invalid. Resolution Comments Resolution Comment The comment added in the section resolution of the request i n JIRA-Client will be sent to the resolution comment of JIRA-MInd-ALM. Stop Reason Stop Reason It is transferred from JIRA-MInd-ALM to JIRA-Client, but only when takes the Client Doubts value. Stop Comment Stop Comment It is transferred from JIRA-MInd-ALM to JIRA-Client, but only when the Stop Reason field has the Client Doubts valu e. Continue Reason X - It only exists in JIRA-Client and a value must be selected when the Continue transition is performed from the Closed status. Continue Comment Comments In JIRA-Client when the transition Continue is performed starting from the Stop status, the comment provided in the Contin ue Comment field, and not in the Comment field of the transition, will be the one that will be sent to the Comments sectio n of JIRA-MInd-ALM. Reject Reason Reopen Reason For any selected value in JIRA-Client in the Reject Reason field, the Reopen Reason in JIRA-MInd-ALM always displays the Other value. This field is selected in JIRA-Client when a transition is performed from the Closed statu s to the Delivered status. Reject Comment Reopen Comment It is registered in the transition R eject performed in JIRA-Client.

16 Reopen Reason Reopen Reason For any selected value in JIRA-Client, in the Reopen Reason field, the Reopen Reason in JIRA-MInd-ALM always displays the Other value. This field is selected in JIRA-Client when a transition is performed from the Delivered st atus to the Reopened status. Reopen Comment Reopen Comment It is registered in the transition R eopen performed in JIRA-Client. SLA Exclusion SLA Exclusion SLA Exclusion Reason SLA Exclusion Reason Deliveries Deliveries Defects Defects Client Key Client Key Sold Units Sold Units Mapping between status Following sections show, for each issue type, the correspondence between JIRA-Client and JIRA-MInd-ALM status. Functional Support JIRA-Client (Functional Support) New Previous Study Propagation JIRA-MInd-ALM (Functional Support) New Previous Study In Progress Working on it, Testing Delivered Delivered Approved x Delivered Reopened Stop Deleted Closed Reopened Stop Deleted Closed Corrective JIRA-Client (Corrective) New Previous Study Propagation JIRA-MInd-ALM (Corrective) New Previous Study

17 In Progress Delivered Reopened Stop Deleted Closed Working on it, Testing Delivered Reopened Stop Deleted Closed Feature Request JIRA Client (Feature Request) New Previous Study Estimated/Planned Propagation JIRA-MInd (Feature Request) New Previous Study, Technical Estimated, Estimated, Approved Estimated Planned Estimation Planning Approved In Progress Approved Plan Working on it, Testing Delivered Delivered Approved x Delivered Reopened Stop Deleted Closed Reopened Stop Deleted Closed Big Feature Request JIRA Client (Big Feature Request) New Previous Study Propagation JIRA-MInd-ALM (Big Feature Request) New Previous Study, Technical Estimated Estimated Estimated Estimation Approved Planning Estimation Planning Approved Design Development Design Approval Pending Approved Estimated Planning Approved Plan In Functional Analysis Analysis in Approval

18 In Progress Delivered Working on it, Testing Delivered Approved x Delivered Reopened Stop Deleted Closed Reopened Stop Deleted Closed Practical case of a work cycle of a request Creating a task by the client If the access to JIRA-Client takes place with a User of the Service profile, the top right part of the window will present a button Create issue. By clicking on it, it will trigger the process to create a new request (issue). After clicking on the Create issue button, a window pops up. The form requires several items of information so the issue can be properly registered. The first step is to select the project to which the new issue is going to belong and its type of issue. These two actions take place through two drop down lists. The type of issue can only be changed if the status is still New. Further input fields are grouped in tabs. The tab called Field Tab contains the general data of the issue: Summary, Description, Component, Priority, etc.

19 The People tab requires inputing the user who initially will be the Assignee of the issue.

20 The Dates tab allows selecting the Commitment Response Date and Due Delivery Date (formatted in the time zone of the client). Nevertheless, the expected start and end dates should not be filled in, as the planning is performed by Indra supporting team. The Keys tab holds the field Key Client. This field can be filled with the key used by the client reference to identify the request.

21 The Estimation tab allows adding the amount of the billed hours for the jobs associated to this issue. The client can modify this value at any time. The Estimated Hours field cannot be edited because the estimation is done by Indra supporting team. By clicking the button Create, the Create Issue window is closed. The a pop-up message appears and communicate the successful creation of the new issue. This message contains a hyperlink to access the window of the recently created issue. There is another way to access the window of the new created issue (or for that purpose to access any other issue) by using the field Quick Search located on the top right corner of any JIRA window. Just enter the text and press Return to start the search. The Quick Search takes to the Issue Navigator where will be listed all the issues that contains in their Summary or Description fields the text inserted in the Quick Search. If the desired issue is displayed in the list, just click on it to display its details. In order to see the issue in an extended window, the issue key must be clicked (see below in red).

22 Finally, another way to access the issue details takes place from the dashboard of the JIRA-Client. To do so, the user must be the Assignee or Re porter of the issue. In this case, the user needs to visit first the list called Assigned to Me and then click on the name or key of the issue. The new created issue window shows a structure as shown below.

23 Progress of the issue performed by the supporting team and monitoring by the client Indra supporting team is in charge of managing the issues created automatically in JIRA-MInd-ALM starting from the creation of issues in JIRA-Client. The responsible of the component receives an notification for each new created issue. Other users of the project can observe the creation of a new issue through the Activity Stream of the JIRA Project. The new issue corresponds to one of the operation categories of Indra Services (Functional Support, Corrective, Feature Request or Big Feature Request)

24 The process starts as soon as the responsible of the component assigns the issue to its current responsible. This activity is achieved through the button Assign of the issue menu. In case the user accessing JIRA is the one who has to take charge of it, the button Assign To Me can be used in order to self-assigning the issue. The button Assign opens a new pop-up window that allows choosing the responsible of the issue from the service list of users.

25 This window also enables adding a comment, which will be sent automatically by to the user together with the assignment notification. After finishing that step, in the section People of the issue it will be displayed the person who has been assigned to that issue ( Assignee field). The management of the issue will be done as any other service issue, that is, following the workflow and advancing through the issue resolution process. The transition Analyze indicates the beginning of the preliminary study. The transition Analyze opens a pop-up window, which allows changing the assignee and the version of the issue. Additionally, it enables adding a comment related to the transition.

26 The section Details of the issues window presents the new status ( Previous Study). Likewise, the comment, which has been added in the transition, can be viewed in the list of Comments of the Activity section. After that step in JIRA-MInd-ALM, the client can see the update to the status Previous Study in the JIRA-Client. The user assigned to the request in JIRA-Client and the reporter will also receive an notification informing about the change of status.

27 The change of status can also be seen in the section Activity of the JIRA-Client Issue.

28 The client user in JIRA-Client can add a comment to the issue using the tab Comments. In JIRA-Mind-ALM the new added comment (done by the client in JIRA-Client) will be pushed and added to the list of comments.

29 When the supporting team is going to start the work associated to the request, the transition Working on it must be performed. In case of Corrective requests, the transition window will present the following fields:

30 After inputing the amount of hours estimated for the issue (field Total Estimate Hours of the previous image), the section Time Tracking of the issue will show the estimated, the remaining and the logged hours. The users of JIRA-Client will also see that the issue has changed to In Progress status, which means the work have already started. When Indra supporting team finishes the development of the solution, they will perform the transition Test to show that the test phase starts.

31 The transition Test changes the status of the JIRA-MInd-ALM issue to Testing. Note that the JIRA-Client status has not changed. Once the test phase has successfully finished, the supporting team runs the transition Deliver in JIRA-MInd-ALM.

32 The transition Deliver in JIRA-MInd-ALM leads to the status Delivered. The status Delivered will also appear in JIRA-Client as the Delivered status. This way, the client will be aware that the work is fully completed and have to evaluate it to either accept it (transition Close Issue) or reject it (transition Reopen).

33 Reopening of a task by the client Using the button Reopen of the JIRA-Client issue, the client can reject the issue delivered by the Indra supporting team. In the Reopen transition window, the client has to select a value for the Reopen Reason field. It is also required to insert a comment explaining the detailed reasons for reopening the issue ( Reopen Comment).

34 Once this transition is accomplished, the status of the JIRA-Client will change to Reopened. After that, the status of the JIRA-MInd-ALM also changes to Reopened and the technical support team will be informed that the client has rejected the deliverable and hence rework is required. The support team can view in the Stop/Reject tab the client reasons and the comments for reopening the request.

35 Acceptance and closing of a task by the client In order to accept the deliverable, the client has to press the button Close Issue. The Close Issue transition window requires the user to select the type of resolution applicable to the issue. The options can be found on the Res olution drop down list. The End Date field of the issue will be automatically filled in. Furthermore, it is optional to add a comment related to the closing of the issue.

36 Once the form has been completed, the user can click on the button Close issue, and the status of the issue will be updated to Closed. The supporting team will accordingly view the status of the issue associated in JIRA-MInd-ALM changed to Closed. This way they will know that the client has accepted the work done.

37 By means of the Reject transition button, if any nonconformity is detected, the client can reopen the issue. Canceling tasks At any stage of the process if the work done on an issue has stopped, the Indra supporting team can execute the transition Stop. The reasons and details of this discontinuation ( Stop Reasons and Stop Comment fields) should be filled in the Stop transition window.

38 Once in the Stop status, if the issue finally is going to be closed permanently without concluding the work, the transition Cancel must be called. This transition requires recording the reasons for canceling. Thus, the issue in JIRA-MInd-ALM will remain in the Closed status and with the value Invalid in the field Resolution.

39 Likewise, the associated issue in the JIRA-Client remains with the status Closed and it shows the value Invalid in the field Resolution. Deleting tasks Sometimes a task can be created by mistake (eg duplicate is inserted). In this case, from JIRA-MInd-ALM, the Delete transition can be performed to mark the issue as erased. In the transition window is requested an explanatory comment of the reasons to delete the issue.

40 Once the transition is accepted, in JIRA-MInd-ALM, the issue status is as the shown in the following image (Deleted) and has no menu option en abled, it can no longer get out of this status. Similarly, in JIRA-Client, will be seen that the issue is in the Deleted status and neither on this issue can be performed any operational action. Automatic calculation of dates MInd includes in JIRA some utilities for establishing the automatically calculation of the dates of the issues of each JIRA Project. In that automatic calculation of any date four factors are involved: Date of origin for the calculations : date from which the other date is computed. Calculation deadlines: period of time from the date of origin for obtaining the date to be calculated. These limits are given for each issue type, priority, component and value of the Project Parameter 4. Service calendar : set of days and timetable in which the service is operational and within deadlines are computed. The service calendar is set by the Indra supporting team, for more information about this procedure visit the chapter Defining calendar and timetable of a Service of the Practical Case of Services with JIRA and MInd-ES. Status of the issue in which can be considered stopped : the time that the issue remains in those status will not be taken into account in the deadline calculations. Following chapters will focus on configuration and usage of these functionalities. Setting dependencies between dates The specific configuration of calculating dates is performed in the Dates Management area of the JIRA Project. This area has three sections ( Dat e Setter, Product Priority Hours and Stop Status Issue ) which are accessed via tabs located at the top side.

41 In the Dates Management section, the dependence between the origin and target dates is configured. Later, in the Product Priority Hours section, deadlines to use on the dependences can be specified in the Dates Management section. In the section Stop Status Issue are registered the stat us that should be considered the issue as stopped and therefore the time that the issue remains in that status should not be taken into account wit hin the established deadlines. The dependence between two dates is specified in the Date Setter section using the steps listed below. 1.- In the Add/Update Dates Configuration form, the type of issue ( Issue Type field) on which is going to be established the dependence between dates must be selected. Also, two dates must be selected : the date field (Source field) from which the calculations are going to be performed and the date field (Target field) which is automatically calculated from the previous one. In addition, in the Action field, must be specified whether the target date will take the same value as the source (Copy to option) or the period specified in the Priority Product Hours section must be added to it (Calculated option). In addition, can be established whether the target field can be edited by the user ( E ditable option). In order to confirm the established dependences in the form, the Save button must be pressed.

42 2.- After the previous step, the system displays a message informing that the configuration has been saved successfully. 3.- After closing the previous message, in the Current Configuration list, can be seen how the dependence has been recorded. If necessary, any previously established dependence can be removed by clicking on its Delete button.

43 In cases where the dependence is set to Copy to type, no additional configuration is required. But, if the dependence is of Calculated type, deadl ines to apply must be assigned. This additional configuration is detailed in the following section. Setting deadlines in the calculation of dates As explained in the previous section, when dependencies between two dates of Calculated type have been declared, the periods to be used for the calculation of the target date must be specified. The system allows providing different terms depending on the priority given to the issue, the component which the issue belongs to and the value of the Project Parameter 4 field. To set these deadlines, the Product Priority Hours section should be accessed and there must be selected in the top drop down the type of issue (Issue Type) on which is to be performed the automatic calculation, the date field automatically calculated ( Target field), the issue priority ( Priority field), the component ( Component field), the value of the Project Parameter 4 (if exists any available value for that JIRA Project) and in the Hours and Minutes fields must be set the period in hours and minutes. Thus, the target date is calculated by adding to the original date and the deadline set by considering only the working hours that have been specified in the service calendar. To accept the entered deadlines values the Save Configuration button must be clicked.

44 After a message that informs that the configuration has been saved successfully, the new row of the saved configuration can be seen in the Curre nt Configuration section. The process can be repeated in order to insert all the deadlines for all the priorities.

45 Status in which the issue is stopped The Stop Status Issue tab allows establishing for each type of issue the status in which the issue must be considered as stopped. The time that the issue remains in those status will not be taken into account in the deadline calculations.

46 In the Current Configuration section can be viewed the status that have been configured as stopped for each type of issue.

47 Example of automatic calculation of dates Once the JIRA Project has been set up as mentioned in the previous paragraphs, the following example will show how when creating an issue so me dates are automatically calculated. 1.- Create an issue of Big Feature Request type ( Gran Evolutivo) with a Minor ( Simple) priority and assign to the Request Created Date field a value ( for example last Monday at 9:01 am).

48 2.- Once the issue is created, if the Edit option of the issue window menu is accessed, in the Dates tab can be seen that starting from the Req uest Creation Date (Monday 9:01) the Commitment Response Date field has been automatically calculated ( Friday at 9:01 ). The difference bet ween both dates are four full calendar days of the service, because for the Minor priority had been established a term of 32 hours and the servi ce schedule has 8 working hours a day. Standard JIRA Client with client approvals For operations that request it, an additional version of Standard JIRA Client is available. This version has features that allow the client to perform additional approvals of the different phases of the requests. This version of Standard JIRA Client (hereinafter Standard JIRA Client with Approvals ) is accessed through the same url that Standard JIRA C lient and has the same user profiles. Their characteristics are described in the following sections. Issue fields of Standard JIRA Client with Approvals When editing any issue in Standard JIRA Client with Approvals, it can be seen that there are some additional fields than in Standard JIRA Client. In the tab, in addition to the y fields, as can be seen in the following image, there are other Keys/Claves/Chaves Clave Cliente Comentario available fields.

49 The additional fields ( Reporter Name, Reporter Telephone, Reporter ) allow registering the contact data of the client person that has performed the request. Likewise, in the edit window there is a tab called Compromiso de Servicio/Service Commitment/Compromisso de serviço that is not present in the Standard JIRA Client. The fields provided by this tab can be seen in the following image.

50 Below is explained the meaning of these fields : Estimation delivery commitment: committed deadline by Indra's team for having performed the issue estimation (entering in the Pendin g Approval status). Estimation approval: date on which the client approves the estimate (transition from the Approval Pending status to the Estimation Approved status). Planning delivery commitment: committed deadline by Indra's team for having made the issue planning (having reached the Plan Approval Pending status). Planning approval: date on which the client approves the planning (transition from the Plan Approval Pending status to the Planning Approved status). User validation: date on which the client accepts the work done (transition from the Delivered status to the Approved status). Released: date on which the work done has been made available to the client (transition from the In Process status to the Delivered statu s) to accept it (change to the Approved status) or to reject it (or change to the Reopened status). Issue types The provided issue types in Standard JIRA Client with Approvals are same as in Standard JIRA Client (Functional Support, Corrective, Feature Request and Big Feature Request ), although they have differences in workflows and properties. These differences are described in the following sections. Workflow of Functional Support issues The workflow for issues of Functional Support type with Approvals is the same as the Functional Support of Standard JIRA Client. The approval by the customer is represented by the Approved status which is after the Delivered status, this allows the client explicitly indicate whether to approve the tasks associated with functional support. However, as seen in the workflow, there is also the possibility to go directly to the Closed st atus from the Delivered status.

51 (In order to see the image enlarged it must be clicked) Some of the transitions within this workflow are responsibility of the client and are performed from Standard JIRA Client. However, other transitions are responsibility of the Indra supporting team and are triggered by transitions performed in JIRA-MInd-ALM. The following legend shows the color codes used in the previous picture to reflect who has the responsibility of each transition. Workflow of Corrective issues The workflow of the Corrective issue type with Approvals versus the Corrective issue type of Standard JIRA Client differs in that after the Delivere d status has two additional status ( Approved and Into Production ) that allow the client explicitly indicate whether to approve the changes associated with the corrective and reflect its into production. However, there is also the possibility to go directly to the Closed status from the Deliv ered status. (In order to see the image enlarged it must be clicked)

52 Workflow of Feature Request issues The Feature Request issues have, at the end of their workflow, the status for denoting the client approval ( Approved and Into Production) as happens in the Corrective issues. Furthermore, Feature Requests have a more detailed estimation and planning process. In that version with approvals of Standard JIRA Client, can be explicitly denoted by the client the approval or rejection of the estimation (from the Approval Pending status) and later the approval or rejection of the planning (from the Planing Approval Pending status). (In order to see the image enlarged it must be clicked)

53 Workflow of Big Feature Request issues The Big Feature Request issue type has the same status as the Feature Request issue type, but also, adds to status ( Design Development and Design Approval Pending) in order to denote when the Indra supporting team is in the design phase and when it is waiting for client approval or rejection of the design. (In order to see the image enlarged it must be clicked)

54 Integration between Standard JIRA-Client with Approvals and JIRA-MInd-ALM Mapping between fields The following table shows the mapping of fields between JIRA-Client with Approvals requests and JIRA-MInd-ALM issues. The column Direction s hows with an arrow the direction of the information flow when there are changes in values. In case there are no relation between the fields of both systems, the Direction takes the value X. Field JIRA-Client Direction Field JIRA-MInd-ALM Comment Summary Summary Description Description Type Issue Type Status Status The values will be updated following the correlation between status explained in the section M apping between status of Standard JIRA-Client with Approvals and JIRA-MInd-ALM. Assignee X Assignee In JIRA-MInd-ALM, the assignee is set by default to the leader of the component to which the issue belongs to. Reporter X Reporter Component/s Component/s Affect Version/s X Affect Version/s Priority Priority Created Created Due Due Date Date calculated by the system using the field Due Delivery Date. Due Delivery Date Due Delivery Date Due delivery date provided according to the client time zone. Request Creation Date Received

55 Commitment Response Date Commitment Response Date Updated X Updated Attended Attended When the issue in JIRA-MInd-ALM changes from the New status to the Previous Study or Working on it status, the moment in which that transition has taken place is registered in the Attended field of the issue in JIRA-MInd-ALM and JIRA-Client. Planned Start Date Planned Start Date Planned End Date Planned End Date Real Start Date X Real Start Date In JIRA-MInd-ALM the Real Start Date field takes the value from the moment in which the transition, in feature requests, to the Previous Study or to the W orking on it status and, in functional supports and correctives, to the Working on it. In JIRA-Client the Real Start Date takes the value of the moment in which the issue arrives to the In Progress status. Real End Date Real End Date Takes the value of the moment in which the issue in JIRA-MInd-ALM arrives to the D elivered status and its value is deleted if the issue is reopened. Resolved Resolved Takes the current date of the moment when in JIRA-Client is set a value for the Resolution fi eld when changing to the Close d status from the Delivered, Approved or Into Production. If the issue is rejected in the JIRA-Client, the Resolved field loses its value. Estimation Delivery Commitment Estimation Delivery Commitment Although it is sent from JIRA-Clie nt to JIRA -MInd-ALM, it is editab le in both systems. Estimation Approval Estimation Approval Although it is sent from JIRA-Clie nt to JIRA -MInd-ALM, it is editab le in both systems. In feature request issues, in JIRA-Client it is only editable until the transition of estimate approval is performed. If in that transition it has not been assigned any value, it will take the date in which the transition has been performed. Planning Delivery Commitment Planning Delivery Commitment Although it is sent from JIRA-Clie nt to JIRA -MInd-ALM, it is editab le in both systems.

56 Plannig Aproval Plannig Aproval User validation User validation Although it is sent from JIRA-Clie nt to JIRA -MInd-ALM, it is editab le in both systems. In feature request issues, in JIRA-Client it is only editable until the transition of planning approval is performed. If in that transition it has not been assigned any value, it will take the date in which the transition has been performed. Although it is sent from JIRA-Clie nt to JIRA -MInd-ALM, it is editab le in both systems. If in the Clos e transition it has not been assigned any value, it will take the date in which the transition has been performed. If the value has not been manually provided, in the Reject transition will be deleted the value that had been automatically assigned in the Cl ose transition. Released Released Although it is sent from JIRA-Client to JIRA -MInd-ALM, it is editable in both systems. If in the Close transition it has not been assigned any value, it will take the date in which the transition has been performed. Even if the issue is later reopened, the value of this date will remain. Attachments Attachments Labels X Labels Issue Links Issue Links When two JIRA-Client issues are linked, their associated issues in JIRA-MInd-ALM are also linked ( vice versa). Key External Issue ID The field External Issue ID of JIRA-MInd-ALM issue shows the Key of the associated issue in JIRA-Client. External Issue ID Key The field External Issue ID of JI RA-Client issue shows the key o f the associated issue in JIRA-MI nd-alm. Comments Comments From JIRA-Client are transferred all the comments to JIRA-MInd-ALM with the exception the one that is provides in the Continue transiti on from the Stop status. From JIRA-MInd-ALM is transferred to JIRA-Client the comment of the Deliver transitio n.

57 Resolution Resolution When the request in JIRA-Client changes from the Delivered or A pproved status to the Closed st atus, the value of the Resolutio n field will be sent to the Resolut ion field of the associated issue in the JIRA-MInd-ALM. When the request in JIRA-Client, by means of the Reject transitio n, changes from the Closed stat us to the Delivered status, the value of the Resolution field will be sent to the Resolution field of the associated issue in the JIRA-MInd-ALM, and this value will be Unresolved. When the request in JIRA-MInd-ALM, by means of the Cancel transition, changes from the Stop status to the Clos ed status, the value of the Resol ution field will be sent to the Res olution field of the associated issue in JIRA-Client, and this value will be Invalid. Resolution Comments Resolution Comment The comment added in the section resolution of the request of JIRA-Client will be sent to the resolution comment of JIRA-MInd-ALM. Stop Reason Stop Reason It is transferred from JIRA-MInd-ALM to JIRA-Client, but only when takes the Client Doubts value. Stop Comment Stop Comment It is transferred from JIRA-MInd-ALM to JIRA-Client, but only when takes the Stop Reason has the Client Doubts value. Continue Reason X - It only exists in JIRA-Client and a value must be selected when the Continue transition is performed from the Closed status. Continue Comment Comments In JIRA-Client when the transition Continue is performed starting from the Stop status, the comment provided in the Contin ue Comment field, and not in the Comment field of the transition, will be the one that will be sent to the Comments sectio n of JIRA-MInd-ALM. Reject Reason Reopen Reason For any selected value in JIRA-Client in the Reject Reason field, the Reopen Reason in JIRA-MInd-ALM always displays the Other value. This field is selected in JIRA-Client when a transition is performed from the Closed statu s to the Delivered status. Reject Comment Reopen Comment It is registered in the transition R eject performed in JIRA-Client.

58 Reopen Reason Reopen Reason For any selected value in JIRA-Client, in the Reopen Reason field, the Reopen Reason in JIRA-MInd-ALM always displays the Other value. This field is selected in JIRA-Client when a transition is performed from the Delivered st atus to the Reopened status. Reopen Comment Reopen Comment It is registered in the transition R eopen performed in JIRA-Client. SLA Exclusion SLA Exclusion SLA Exclusion Reason SLA Exclusion Reason Deliveries Deliveries Defects Defects Client Key Client Key Sold Units Sold Units Reporter Name Reporter Name Reporter Telephone Reporter Telephone Reporter Reporter Mapping between status of Standard JIRA-Client with Approvals and JIRA-MInd-ALM The following sections show, for each type of issue, the equivalence between status of Standard JIRA Client with Approvals and JIRA-MInd-ALM. Functional Support JIRA Client with Approvals (Functional Support) New Previous Study Propagation JIRA-MInd-ALM (Functional Support) New Previous Study In Progress Delivered Working on it, Testing Delivered Approved x Delivered Reopened Stop Deleted Closed Reopened Stop Deleted Closed Corrective

59 JIRA Client with Approvals (Corrective) New Previous Study Propagation JIRA-MInd-ALM (Corrective) New Previous Study In Progress Delivered Working on it, Testing Delivered Approved x Delivered Into Production x Delivered Reopened Stop Deleted Closed Reopened Stop Deleted Closed Feature Request JIRA Client with Approvals (Feature Request) New Previous Study Propagation JIRA-MInd-ALM (Feature Request) New Previous Study, Technical Estimated Evaluate Estimation Estimated Approval Pending Estimation Approved Planning Planning Approval Pending Planning Approved In Progress Delivered (Send to Approved*) Approved Estimated Planning (Send to Approved*) Approved Plan Working on it, Testing Delivered Approved x Delivered Into Production x Delivered Reopened Stop Deleted Closed Reopened Stop Deleted Closed

60 * -> Send to Approved is not a status, it is a transition that can be performed in the JIRA-MInd-ALM issues. When performing this transition, the JIRA-MInd-ALM issue do not changes the status, but the related issue in the Standard JIRA Client with Approvals will change its status as shown in the previous table. Big Feature Request JIRA Client with Approvals (Big Feature Request) New Previous Study Propagation JIRA-MInd-ALM (Big Feature Request) New Previous Study, Technical Estimated Evaluate Estimation Estimated Approval Pending Estimation Approved Planning Planning Approval Pending Planning Approved Design Development Design Approval Pending In Process Delivered (Send to Approved*) Approved Estimated Planning (Send to Approved*) Approved Plan In Functional Analysis Analysis in Approval Working on it, Testing Delivered Approved x Delivered Into Production x Delivered Reopened Stop Deleted Closed Reopened Stop Deleted Closed

61 * -> Send to Approved is not a status, it is a transition that can be performed in the JIRA-MInd-ALM issues. When performing this transition, the JIRA-MInd-ALM issue do not changes the status, but the related issue in the Standard JIRA Client with Approvals will change its status as shown in the previous table.