jira standard client - indra · on one side this allows indra technicians to work homogeneously and...

JIRA Standard Client

ObjectivesIntroductionStandard JIRA Client

AccessUser profilesTypes of issue

Functional SupportCorrectiveFeature RequestBig Feature Request

Parameters and issues window of the JIRA-ClientClient dashboardChange of the interface language

Integration between Standard JIRA-Client and JIRA-MInd-ALMIntroductionMapping between fieldsMapping between status


Practical case of a work cycle of a requestCreating a task by the clientProgress of the issue performed by the supporting team and monitoring by the client Reopening of a task by the clientAcceptance and closing of a task by the clientCanceling tasksDeleting tasks

Automatic calculation of datesSetting dependencies between datesSetting deadlines in the calculation of datesStatus in which the issue is stoppedExample of automatic calculation of dates

Standard JIRA Client with client approvalsIssue fields of Standard JIRA Client with ApprovalsIssue types

Workflow of Functional Support issuesWorkflow of Corrective issuesWorkflow of Feature Request issuesWorkflow of Big Feature Request issues

Integration between Standard JIRA-Client with Approvals and JIRA-MInd-ALMMapping between fieldsMapping between status of Standard JIRA-Client with Approvals and JIRA-MInd-ALM


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

IntroductionThe platform ( ) has a standard parameterization, accessible for any operation whichStandard JIRA Client hereafter abbreviated JIRA-Client 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

). On one side this allows Indra technicians to work homogeneously and in a standard way by using the developing technical lifeIRA-MInd-ALMcycle of MInd. Furthermore, the clients benefits from the possibility to monitor the progress of their requests in the JIRA-Client environment. Bothsystems 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 withina service. The types of requests are associated to four types of products: , , and Functional Support Corrective Feature Request 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 theequivalent 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 sessionhttps://jira4client.indra.esin another MInd tool, a log in with credentials (user name and password) will be required.

https://jira4client.indra.es

User profiles

There are two user profiles for JIRA-Client:

The is in charge to create the requests (Functional Support, Corrective, Feature Request or Big Feature Request). User of the service 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 can not create new requests. It is a profile oriented to monitor and supervise. Responsible of the service

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 supportingactivities 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 or the status Stop Deletedcan be reached from any status (except from the status ). The following caption shows the color coding used in the previous image toClosedshow who is responsible for each transition.

Corrective:Definition It refers to any software error produced in acompletion of the appropriate changes to fix the malfunction in systems. maintained

productive environment already approved by the client. It includes also those errors that do not require software delivery. The following imageshows 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

of issues.


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


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.

The fields that describe the JIRA-Client issues are:

Name of the field Description

Key Number of the JIRA request.

Summary Descriptive header of the request.

Description Detailed description of the request.

Type Type of product (Functional Support, Corrective, Feature Request orBig Feature Request).

Component(s) It represents the module or application to which the request belongs.

Priority It states the priority of the request.

Affected Version(s) Version affected by the request.

Status Status of the request within the workflow of its issue type.

Resolution It shows how successful the request has been solved. If the field isnot filled, JIRA will not mark the request as finished. In order to closea request (status this field is mandatory.Closed),

Assignee User who has the request assigned. It can be reassigned at any laterstage to another user that has the authorization on the component ofthe issue.

Reporter The user that has registered the issue.

Comments 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, insertcomments, 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 buttonsthat are applicable in the current status.

Placed left under the issue menu, the of the issue are presented, including the main parameters of the issue and the current status of theDetailsissue.

In the lower part of the section could additionally be displayed some tabs. For example, the tab presents the Details Estimation Estimated and the .Hours Billed Hours

Below the Details section is placed the area with the detailed description of the request.Description

In the lower part of the issue window is located the section . It contains several tabs with information of the issue changes. The nextActivityimage shows the tab . It accommodates the comments added from the JIRA-Client as well as those inserted by the Indra supportingCommentsteam 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

Under the section is the section, which includes all the relevant dates around the issue.People Dates

The date fields available for each issue are detailed next:

Name of the Field Description

Due Agreed delivery date.

Created Date when the issue was registered.

Request DateCreation Date added manually showing the real date of the client request.

Response DateCommitment Expected and agreed date to focus on analysis or start of theactivities to resolve the request.

Planned Start Date For Feature Requests, date required when changing to the Estimated status. For Correctives and Supports, is the date expected/Planned

to change to the status.In Progress

End DatePlanned Mandatory when changing to the status . It willEstimated/Plannedtake by default the value of . It can be however modifiedDueafterwards.

Start Date Automatic. It is the real start date, that is, the date that the status haschanged to . Although it is a date assigned automatically,In Progressit can be changed afterwards by the profile.Assignee

End Date Automatic. It takes the value of the time when the issue statuschanges to . Indeed, it is the real date of the requestDelivereddelivery.

Although it is a date assigned automatically, it can be changedafterwards by the user with the profile Assignee.

Resolved Automatic. It takes the time when the issue status changes to ,Closedthat is, the date when the request has been closed.

Updated Automatic. It takes the time when the last change was performed.

Attended Automatic. Date when the Indra supporting team registers thebeginning of the jobs associated with the issue.

Further parameters of the issues are described in the following table:JIRA-Client

Name of the field Description

ClientKey Number of client request, that is, the code that identifies the requestfor the client.

ExclusionSLA It points out whether the issue should be excluded on the SLAcalculation. This parameter can take the values or .Si/Yes No

ReasonsExclusionSLA It contains the comments explaining the reason of the SLA exclusion.

Deliveries Number of deliveries until the issue is approved.

Defects 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 whichthe 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:

1.- First, select the option from the user menu, which is placed at the top right corner of any JIRA-Client window:Profile

2.- In the section, there is an icon with a pencil image (see below), please select it to edit.Preferences

3.- Select from the drop down list the one desired for the user interface. Finish this last step by clicking on the button.Language Update

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

IntroductionThe integration between Standard JIRA Client and JIRA-MInd-ALM makes possible for the operation supporting team of Indra towork homogeneously and in a standard way with the technical development cycle of MInd. At the same time, this integration allows the client togain 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 fieldsThe following table shows the mapping of fields between JIRA-Client requests and JIRA-MInd-ALM issues. The column shows with anDirectionarrow 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

is marked with . irection X

Field JIRA-Client Direction Field JIRA-MInd-ALM Comment

Summary Summary

Description Description

Type Issue Type

Status Status The values will be updatedfollowing the correlation betweenstatus explained in the section M

.apping between status

Assignee X Assignee In JIRA-MInd-ALM, the assigneeis set by default to the leader ofthe component to which theissue 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 systemusing the field Due Delivery

.Date

Due Delivery Date Due Delivery Date Due delivery date providedaccording to the client time zone.

Request Creation Date Received

Commitment Response Date Commitment Response Date

Updated X Updated

Attended Attended When the issue inJIRA-MInd-ALM changes fromthe status to the New Previous

or status,Study Working on itthe moment in which thattransition has taken place isregistered in the fieldAttendedof the issue in JIRA-MInd-ALMand 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 arelinked, their associated issues inJIRA-MInd-ALM are also linked (

.)vice versa

Key External Issue ID The field ofExternal Issue IDJIRA-MInd-ALM issue shows the

of the associated issue inKeyJIRA-Client.

External Issue ID Key The field of External Issue ID JI issue shows the oRA-Client key

f the associated in issue JIRA-MInd-ALM.

Comments Comments From JIRA-Client are transferredall the comments toJIRA-MInd-ALM with theexception the one that isprovides in the transitiContinueon from the status.Stop

From JIRA-MInd-ALM istransferred to JIRA-Client thecomment of the transitioDelivern.

Resolution Resolution When the request in JIRA-Clientchanges from the or Delivered A

status to the stpproved Closedatus, the value of the Resolutio

field will be sent to the n Resolut field of the associated issueion

in the JIRA-MInd-ALM.

When the request in JIRA-Client,by means of the transitioRejectn, changes from the statClosedus to the status, the Deliveredvalue of the field willResolutionbe sent to the field ofResolutionthe associated issue in theJIRA-MInd-ALM, and this valuewill be .Unresolved

When the request inJIRA-MInd-ALM, by means ofthe transition, changesCancelfrom the status to theStop Clos

status, the value of the ed Resol field will be sent to the ution Res

field of the associatedolutionissue in JIRA-Client, and thisvalue will be .Invalid

Resolution Comments Resolution Comment The comment added in thesection iresolution of the request n JIRA-Client will be sent to theresolution comment of JIRA-MInd-ALM.

Stop Reason Stop Reason It is transferred fromJIRA-MInd-ALM to JIRA-Client,but only when takes the Client

value.Doubts

Stop Comment Stop Comment It is transferred fromJIRA-MInd-ALM to JIRA-Client,but only when the Stop Reasonfield has the valuClient Doubtse.

Continue Reason X - It only exists in JIRA-Client and avalue must be selected when the

transition is performedContinuefrom the status.Closed

Continue Comment Comments In JIRA-Client when thetransition is performedContinue starting from the status, theStopcomment provided in the Contin

field, and not inue Commentthe field of theCommenttransition, will be the one that willbe sent to the sectioCommentsn of JIRA-MInd-ALM.

Reject Reason Reopen Reason For any selected value inJIRA-Client in the Reject

field, the Reason Reopen in JIRA-MInd-ALMReason

always displays the value.OtherThis field is selected inJIRA-Client when a transition isperformed from the statuCloseds to the status.Delivered

Reject Comment Reopen Comment It is registered in the transition R performed in JIRA-Client.eject

Reopen Reason Reopen Reason For any selected value inJIRA-Client, in the Reopen


always displays the value.OtherThis field is selected inJIRA-Client when a transition isperformed from the stDeliveredatus to the status.Reopened

Reopen Comment Reopen Comment It is registered in the transition R performed in JIRA-Client.eopen

SLA Exclusion SLA Exclusion

SLA Exclusion Reason SLA Exclusion Reason

Deliveries Deliveries

Defects Defects

Client Key Client Key

Sold Units Sold Units

Mapping between statusFollowing sections show, for each issue type, the correspondence between JIRA-Client and JIRA-MInd-ALM status.

Functional Support

JIRA-Client

(Functional Support)

Propagation JIRA-MInd-ALM


New New

Previous Study Previous Study

In Progress Working on it, Testing

Delivered Delivered

Approved x Delivered

Reopened Reopened

Stop Stop

Deleted Deleted

Closed Closed

Corrective

JIRA-Client

(Corrective)


(Corrective)

New New



Delivered Delivered

Reopened Reopened

Stop Stop

Deleted Deleted

Closed Closed

Feature Request

JIRA Client

(Feature Request)

Propagation JIRA-MInd

(Feature Request)

New New

Previous Study Previous Study, Technical Estimated,Estimated, Approved Estimated

Estimated/Planned Planned

Estimation Planning Approved Approved Plan


Delivered Delivered


Reopened Reopened

Stop Stop

Deleted Deleted

Closed Closed

Big Feature Request

JIRA Client

(Big Feature Request)



New New

Previous Study Previous Study, Technical Estimated

Estimated Estimated

Estimation Approved Approved Estimated

Planning Planning

Estimation Planning Approved Approved Plan

Design Development In Functional Analysis

Design Approval Pending Analysis in Approval


Delivered Delivered


Reopened Reopened

Stop Stop

Deleted Deleted

Closed Closed

Practical case of a work cycle of a request

Creating a task by the clientIf the access to JIRA-Client takes place with a profile, the top right part of the window will present a button . ByUser of the Service Create issueclicking on it, it will trigger the process to create a new request (issue).

After clicking on the button, a window pops up. The form requires several items of information so the issue can be properlyCreate issueregistered. 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 placethrough two drop down lists.

Further input fields are grouped in tabs. The tab called contains the general data of the issue: Field Tab Summary, Description, Component,, etc.Priority

The type of issue can only be changed if the status is still .New

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

The tab allows selecting the and (formatted in the time zone of the client). Nevertheless,Dates Commitment Response Date Due Delivery Date the expected start and end dates should not be filled in, as the planning is performed by Indra supporting team.

The tab holds the field . This field can be filled with the key used by the client reference to identify the request. Keys Key Client

The 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.EstimationThe field cannot be edited because the estimation is done by Indra supporting team. Estimated Hours

By clicking the button , the window is closed. The a pop-up message appears and communicate the successful creation ofCreate Create Issuethe 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 located on the top right corner of any JIRA window. Just enter the text and press to start the search.Search Return

The takes to the where will be listed all the issues that contains in their or fields the textQuick Search Issue Navigator Summary Descriptioninserted in the . If the desired issue is displayed in the list, just click on it to display its details. In order to see the issue in anQuick Searchextended window, the issue key must be clicked (see below in red).

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 or Assignee Re of the issue. In this case, the user needs to visit first the list called and then click on the name or key of the issue. porter Assigned to Me

The new created issue window shows a structure as shown below.

Progress of the issue performed by the supporting team and monitoring by theclient Indra supporting team is in charge of managing the issues created automatically in JIRA-MInd-ALM starting from the creation of issues inJIRA-Client. The responsible of the component receives an email notification for each new created issue. Other users of the project can observethe creation of a new issue through the of the JIRA Project. Activity Stream

The new issue corresponds to one of the operation categories of Indra Services (Functional Support, Corrective, Feature Request or Big FeatureRequest)

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 of the issue menu. In case the user accessing JIRA is the one who , the button can be usedAssign has to take charge of it Assign To Mein order to self-assigning the issue.

The button opens a new pop-up window that allows choosing the responsible of the issue from the service list of users.Assign

This window also enables adding a comment, which will be sent automatically by email to the user together with the assignment notification.

After finishing that step, in the section of the issue it will be displayed the person who has been assigned to that issue ( field).People Assignee

The management of the issue will be done as any other service issue, that is, following the workflow and advancing through the issue resolutionprocess. The transition indicates the beginning of the preliminary study. Analyze

The transition opens a pop-up window, which allows changing the assignee and the version of the issue. Additionally, it enables adding aAnalyzecomment related to the transition.

The section of the issues window presents the new status ( ).Details Previous Study

Likewise, the comment, which has been added in the transition, can be viewed in the list of of the section. Comments Activity

After that step in JIRA-MInd-ALM, the client can see the update to the status in the JIRA-Client. The user assigned to the request Previous Studyin JIRA-Client and the will also receive an email notification informing about the change of status. reporter

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

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.

When the supporting team is going to start the work associated to the request, the transition must be performed.Working on it

In case of Corrective requests, the transition window will present the following fields:

After inputing the amount of hours estimated for the issue (field of the previous image), the section of theTotal Estimate Hours Time Trackingissue will show the estimated, the remaining and the logged hours.

The users of JIRA-Client will also see that the issue has changed to status, which means the work have already started. In Progress

When Indra supporting team finishes the development of the solution, they will perform the transition to show that the test phase starts. Test

The transition changes the status of the JIRA-MInd-ALM issue to . Test Testing

Note that the JIRA-Client status has not changed.

Once the test phase has successfully finished, the supporting team runs the transition in JIRA-MInd-ALM. Deliver

The transition Deliver in JIRA-MInd-ALM leads to the status . Delivered

The status will also appear in JIRA-Client as the status. This way, andDelivered Delivered the client will be aware that the work is fully completedhave to evaluate it to either accept it (transition ) or reject it (transition ).Close Issue Reopen

Reopening of a task by the clientUsing the button of the JIRA-Client issue, the client can reject the issue delivered by the Indra supporting team.Reopen

In the transition window, the client has to select a value for the field.Reopen Reopen Reason

It is also required to insert a comment explaining the detailed reasons for reopening the issue ( ). Reopen Comment

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 and the technical support team will be informed that the client hasReopenedrejected the deliverable and hence rework is required. The support team can view in the tab the client reasons and the comments forStop/Rejectreopening the request.

Acceptance and closing of a task by the clientIn order to accept the deliverable, the client has to press the button .Close Issue

The transition window requires the user to select the type of resolution applicable to the issue. The options can be found on the Close Issue Res drop down list.olution

The field of the issue will be automatically filled in. Furthermore, it is optional to add a comment related to the closing of the issue.End Date

Once the form has been completed, the user can click on the button , and the status of the issue will be updated to . Close issue Closed

The supporting team will accordingly view the status of the issue associated in JIRA-MInd-ALM changed to This way they will know thatClosed.the client has accepted the work done.

By means of the transition button, if any nonconformity is detected, the client can reopen the issue.Reject

Canceling tasksAt 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 ( and fields) should be filled in the transition window. Stop Reasons Stop Comment Stop

Once in the status, if the issue finally is going to be closed permanently without concluding the work, the transition must be called. Stop Cancel

This transition requires recording the reasons for canceling.

Thus, the issue in JIRA-MInd-ALM will remain in the status and with the value in the field .Closed Invalid Resolution

Likewise, the associated issue in the JIRA-Client remains with the status and it shows the value in the field Closed Invalid Resolution.

Deleting tasks mistake Sometimes a task can be created by (eg duplicate is inserted). , , be In this case from JIRA-MInd-ALM the Delete transition can performed

erased to mark the issue as .

is requested In the window transition an explanatory comment of the reasons to delete the issue.

status is as the has Once the transition is , inaccepted JIRA-MInd-ALM, the issue shown in the following image (Deleted) and no menu option en statusabled, it can no longer get out of this .

can Similarly, in JIRA-Client, will be seen that the issue is in the Deleted status and neither on this issue 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

, component and value of the . type, priority Project Parameter 4: . The service calendarService calendar set of days and timetable in which the service is operational and within deadlines are computed

is set by the Indra supporting team, for more information about this procedure visit the chapter Defining calendar and timetable of a of the .Service 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 accountin 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 of thearea JIRA Project. ( This area has three sections Dat

, and ) side.e Setter Product Priority Hours Stop Status Issue which are accessed via tabs located at the top

https://mind.indra.es/display/MIND/Practical+Case+of+Services+with+JIRA+and+MInd-ES#PracticalCaseofServiceswithJIRAandMInd-ES-DefiningcalendarandtimetableofaService

https://mind.indra.es/display/MIND/Practical+Case+of+Services+with+JIRA+and+MInd-ES#PracticalCaseofServiceswithJIRAandMInd-ES-DefiningcalendarandtimetableofaService

the In the Dates Management section, the dependence between origin and target dates is configured. Later, in the Product Priority Hours section,. to deadlines use on the dependences can be specified in the Dates Management section are registered the In the section Stop Status Issue 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 within the established deadlines.

The dependence between two dates is specified in the Date Setter section using the steps listed below.

1.- ( field) In the Add/Update Dates ,Configuration form the type of issue Issue Type on which is going to be established the dependence. between dates must be selected two dates : the field ) from Also, must be selected date (Source field 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 field, Action 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 by the user (can be edited E . option)ditable . In order to confirm the established dependences in the form, the Save button must be pressed

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 be can removed by clicking on its Delete button

In cases where the dependence is set to Copy typeto , 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 The system allows providing different terms depending on the priority given to the issuecomponent which the issue belongs to and the value of the field. Project Parameter 4 To set these deadlines, the Product Priority Hours sectionshould 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

, the component ( ), the value of calculation, the date field automatically calculated ( fieldTarget ), the issue priority ( )Priority field Component fieldthe (if exists any available value for that JIRA Project) and iProject Parameter 4 fields must n the Hours and Minutes 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 the To accept the entered deadlines values buttonSave Configuration must be clicked

After that a message informs that the configuration has been saved successfully, the new row of the saved configuration can be seen in the Curre. sectionnt Configuration

The process can be repeated in order to insert all the deadlines for all the priorities.

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

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

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

1.- type ( ) with a ( ) priority and assign to the fieldn ofCreate a issue Big Feature Request Gran Evolutivo Minor Simple Request Created Datea value ( ). for example last Monday at 9:01 am

2.- if the option of the issue window menu is accessed, in the tab can be Once is created the issue , Edit Dates seen that starting from the Req uest Creation Date (Monday 9:01) the field has been automatically calculated ( ). Commitment Response Date 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.

with JIRAStandard Client approvalsclient 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.

through This version of Standard JIRA Client (hereinafter Standard JIRA Client )with Approvals is accessed 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 JIRAStandard Client with Approvals When editing any issue in JIRAStandard 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 otherKeys/Claves/Chaves Clave Cliente Comentarioavailable fields.

The additional fields ( , , ) allow registering the contact data of the client person that hasReporter Name Reporter Telephone Reporter eMailperformed the request.

Likewise, in the edit window there is a tab called that is not presentCompromiso de Servicio/Service Commitment/Compromisso de serviçoin the . The fields provided by this tab can be seen in the following image.Standard JIRA Client

Below is the meaningexplained of these fields :

Estimation delivery commitment: deadline by committed Indra's team for having performed the issue estimation (entering in the Pending Approval status).Estimation approval: date on which the client approves the estimate (transition from the status to the Approval Pending Estimation

status).ApprovedPlanning delivery commitment: deadline by Indra's team for having made the issue planning (having reached thecommitted Plan

status).Approval PendingPlanning approval: (transition from the status to the date on which the client approves the planning Plan Approval Pending Planning

status).ApprovedUser validation: (transition from the status to the status) date on which the client accepts the work done Delivered Approved .Released: (transition from the status to the statu has date on which the work done been made available to the client In Process Delivereds) to accept it (change to the status) or to reject it (or change to the status)Approved Reopened .

Issue typesThe provided issue types in are same as in Standard JIRA Client with Approvals 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 type with is the same as the of . The approvalFunctional Support Approvals Functional Support Standard JIRA Clientby the customer is represented by the status which is after the status, this allows the client explicitly indicate whether toApproved Deliveredapprove the tasks associated with functional support. However, as seen in the workflow, there is also the possibility to go directly to the st Closedatus from the status Delivered .

(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 . However, otherStandard JIRA Clienttransitions are responsibility of the Indra supporting team and are triggered by transitions performed in . The following legendJIRA-MInd-ALMshows the color codes used in the previous picture to reflect who has the responsibility of each transition.

Workflow of Corrective issuesThe workflow of the issue type with versus the issue type of differs in that after the Corrective Approvals Corrective Standard JIRA Client Delivere

status has two additional status ( and ) d Approved Into Production that allow the client explicitly indicate whether to approve the changesand reflect its into production. However, there is also the possibility to go directly to the status from the the associated with corrective Closed Deliv

statusered .


Workflow of Feature Request issues

The issues have, at the end of their workflow, the status for denoting the client approval ( and ) asFeature Request Approved Into Productionhappens in the issues. Furthermore, have a more detailed estimation and planning process. In that version withCorrective Feature Requestsapprovals of , can be explicitly denoted by the client the approval or rejection of the estimation (from the Standard JIRA Client Approval Pendingstatus) and later the approval or rejection of the planning (from the status).Planing Approval Pending


Workflow of Big Feature Request issues

The issue type has the same status as the issue type, but also, adds to status ( and Big Feature Request Feature Request Design Development) in order to denote when the Indra supporting team is in the design phase and when it is waiting for client approval orDesign Approval Pending

rejection of the design.


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 sDirectionhows 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 bothsystems, the takes the value . Direction X

Field JIRA-Client Direction Field JIRA-MInd-ALM Comment

Summary Summary

Description Description

Type Issue Type

Status Status The values will be updatedfollowing the correlation betweenstatus explained in the section Mapping between status ofStandard JIRA-Client with

.Approvals and JIRA-MInd-ALM

Assignee X Assignee In JIRA-MInd-ALM, the assigneeis set by default to the leader ofthe component to which theissue 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 systemusing the field Due Delivery

.Date

Due Delivery Date Due Delivery Date Due delivery date providedaccording to the client time zone.

Request Creation Date Received

Commitment Response Date Commitment Response Date

Updated X Updated

Attended Attended When the issue inJIRA-MInd-ALM changes fromthe status to the New Previous

or status,Study Working on itthe moment in which thattransition has taken place isregistered in the fieldAttendedof the issue in JIRA-MInd-ALMand 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 field takes the valueStart Date

from the moment in which thetransition, in feature requests, tothe or to the Previous Study W

status and, inorking on itfunctional supports andcorrectives, to the Working on it.

In JIRA-Client the Real Start takes the value of theDate

moment in which the issuearrives to the statusIn Progress.

Real End Date Real End Date Takes the value of the momentin which the issue inJIRA-MInd-ALM arrives to the D

status and its value iselivereddeleted if the issue is reopened.

Resolved Resolved Takes the current date of themoment when in JIRA-Client isset a value for the fiResolutioneld when changing to the Close

status from the d Delivered, or .Approved Into Production

If the issue is rejected in theJIRA-Client, the fieldResolvedloses its value.

Estimation DeliveryCommitment

Estimation DeliveryCommitment

Although it is sent from JIRA-Clie , it nt to JIRA -MInd-ALM is editab le in both systems.

Estimation Approval Estimation Approval Although it is sent from JIRA-Clie , it nt to JIRA -MInd-ALM is editab le in both systems. In feature

request issues, in JIRA-Client itis only editable until the transitionof estimate approval isperformed. If in that transition ithas not been assigned anyvalue, it will take the date inwhich the transition has beenperformed.

Planning DeliveryCommitment

Planning DeliveryCommitment

Although it is sent from JIRA-Clie , it nt to JIRA -MInd-ALM is editab le in both systems.

Plannig Aproval Plannig Aproval Although it is sent from JIRA-Clie , it nt to JIRA -MInd-ALM is editab le in both systems. In feature

request issues, in JIRA-Client itis only editable until the transitionof planning approval isperformed. If in that transition ithas not been assigned anyvalue, it will take the date inwhich the transition has beenperformed.

User validation User validation Although it is sent from JIRA-Clie , it nt to JIRA -MInd-ALM is editab le in both systems. If in the Clos transition it has not beene

assigned any value, it will takethe date in which the transitionhas been performed.

If the value has not beenmanually provided, in the Rejecttransition will be deleted thevalue that had beenautomatically assigned in the Cl

transition.ose

Released Released Although it is sent fromJIRA-Client to JIRA -MInd-ALM,it is editable in both systems. If inthe transition it has notClosebeen assigned any value, it willtake the date in which thetransition has been performed.Even if the issue is laterreopened, the value of this datewill remain.

Attachments Attachments

Labels X Labels

Issue Links Issue Links When two JIRA-Client issues arelinked, their associated issues inJIRA-MInd-ALM are also linked (

.)vice versa

Key External Issue ID The field ofExternal Issue IDJIRA-MInd-ALM issue shows the

of the associated issue inKeyJIRA-Client.

External Issue ID Key The field of External Issue ID JI issue shows the oRA-Client key

f the associated in issue JIRA-MInd-ALM.

Comments Comments From JIRA-Client are transferredall the comments toJIRA-MInd-ALM with theexception the one that isprovides in the transitiContinueon from the status.Stop

From JIRA-MInd-ALM istransferred to JIRA-Client thecomment of the transitioDelivern.

Resolution Resolution When the request in JIRA-Clientchanges from the or Delivered A

status to the stpproved Closedatus, the value of the Resolutio

field will be sent to the n Resolut field of the associated issueion

in the JIRA-MInd-ALM.

When the request in JIRA-Client,by means of the transitioRejectn, changes from the statClosedus to the status, the Deliveredvalue of the field willResolutionbe sent to the field ofResolutionthe associated issue in theJIRA-MInd-ALM, and this valuewill be .Unresolved

When the request inJIRA-MInd-ALM, by means ofthe transition, changesCancelfrom the status to theStop Clos

status, the value of the ed Resol field will be sent to the ution Res

field of the associatedolutionissue in JIRA-Client, and thisvalue will be .Invalid

Resolution Comments Resolution Comment The comment added in thesection resolution of the request of JIRA-Client will be sent to theresolution comment of JIRA-MInd-ALM.

Stop Reason Stop Reason It is transferred fromJIRA-MInd-ALM to JIRA-Client,but only when takes the Client

value.Doubts

Stop Comment Stop Comment It is transferred fromJIRA-MInd-ALM to JIRA-Client,but only when takes the Stop

has the Reason Client Doubtsvalue.

Continue Reason X - It only exists in JIRA-Client and avalue must be selected when the

transition is performedContinuefrom the status.Closed

Continue Comment Comments In JIRA-Client when thetransition is performedContinue starting from the status, theStopcomment provided in the Contin

field, and not inue Commentthe field of theCommenttransition, will be the one that willbe sent to the sectioCommentsn of JIRA-MInd-ALM.

Reject Reason Reopen Reason For any selected value inJIRA-Client in the Reject


always displays the value.OtherThis field is selected inJIRA-Client when a transition isperformed from the statuCloseds to the status.Delivered

Reject Comment Reopen Comment It is registered in the transition R performed in JIRA-Client.eject

Reopen Reason Reopen Reason For any selected value inJIRA-Client, in the Reopen


always displays the value.OtherThis field is selected inJIRA-Client when a transition isperformed from the stDeliveredatus to the status.Reopened

Reopen Comment Reopen Comment It is registered in the transition R performed in JIRA-Client.eopen

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 eMail Reporter eMail

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 and .Standard JIRA Client with Approvals JIRA-MInd-ALM

Functional Support

JIRA Client with Approvals




New New



Delivered Delivered


Reopened Reopened

Stop Stop

Deleted Deleted

Closed Closed

Corrective


(Corrective)


(Corrective)

New New



Delivered Delivered


Into Production x Delivered

Reopened Reopened

Stop Stop

Deleted Deleted

Closed Closed

Feature Request


(Feature Request)


(Feature Request)

New New


Evaluate Estimation Estimated

Approval Pending (Send to Approved*)


Planning Planning

Planning Approval Pending (Send to Approved*)

Planning Approved Approved Plan


Delivered Delivered



Reopened Reopened

Stop Stop

Deleted Deleted

Closed Closed

Big Feature Request





New New


Evaluate Estimation Estimated

Approval Pending (Send to Approved*)


Planning Planning

Planning Approval Pending (Send to Approved*)

Planning Approved Approved Plan

Design Development In Functional Analysis

Design Approval Pending Analysis in Approval

In Process Working on it, Testing

Delivered Delivered



Reopened Reopened

Stop Stop

Deleted Deleted

Closed Closed

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

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

jira standard client - indra · on one side this allows indra technicians to work homogeneously and...

Documents