jira demo
DESCRIPTION
Jira Demo. 2007-01-09 Blame Tony Edgin. Overview. What is Jira? Requirement states Terminology Jira demo. Jira. General-purpose issue management system Web-based Integrates with wikis and revision tracking systems Highly configurable Extensible. Requirement State Chart. - PowerPoint PPT PresentationTRANSCRIPT
Jira Demo
2007-01-09
Blame Tony Edgin
Overview
• What is Jira?
• Requirement states
• Terminology
• Jira demo
Jira
• General-purpose issue management system
• Web-based
• Integrates with wikis and revision tracking systems
• Highly configurable
• Extensible
Requirement State Chart
Requirement States
• Proposed – A requirement has been requested by entering it into Jira.
• Accepted-waiting – A requirement has been evaluated and found suitable for implementation.
• Accepted-in development – A requirement has been scheduled for inclusion in the next baseline. This includes testing.
Requirement States continued
• Released – A requirement is satisfied by the current release of the product.
• Rejected – A requirement that is not or is no longer appropriate for the product.
Proposed Requirement Transitions
• Accept accepted-waiting - The requirement has been reviewed and found to be appropriate for the product.
• Reject rejected - The requirement has been reviewed and found to be inappropriate for the product.
Accepted-Waiting Requirement Transitions
• Develop accepted-in development – The project manager schedules this requirement for the next baseline.
• Modify proposed – The project lead realizes there is an issue with the requirement. It needs to be modified or clarified.
• Reject rejected – The project lead determines that the requirement is no longer appropriate for implementation
Accepted-In Development Requirement Transitions
• Release released – The requirement is added to the next release of the product.
• Postpone accepted-waiting – The requirement has been removed from inclusion in the next baseline.
• Modify proposed – The project engineers realize there is an issue with the requirement. It needs to be modified or clarified.
• Reject rejected – The project lead determines that the requirement is no longer appropriate for implementation
Released Requirement Transition
• Deprecate rejected – The requirement is outdated and will not be supported in future baselines.
Terminology
• Source - A person, policy, standard, or other any other thing capable of defining or constraining the product or its development.
• Reporter – A member of the software group who acts as a advocate for the source. I.e. the person who enters the requirement into Jira. The reporter may also be the source.
Terminology continued
• Project lead – A member of the software group who takes responsibility for the outcome of the project.
• Component lead – A member of the software group who takes responsibility for a portion of a project.
• Assignee – A member of the software group who takes responsibility for the satisfaction of a requirement.
• Watcher – A member of the software group who is interested in being notified when a requirement is updated.
Terminology continued
• Requirement – A requirement which comes from a source.
• Derived Requirement – A requirement which is results from another requirement.
Terminology continued
• Issue – Something Jira tracks. For us, it is either a requirement or a derived requirement.
• Sub-task – An issue which is part of another issue. For us, this is a derived requirement.
Terminology continued
• Workflow – The set of all states and their transitions for a requirement.
• Status – The state of a requirement within a workflow.
• Workflow Action – A status transition for a requirement.
Terminology continued
• Fix Version – The name of the first release containing the requirement.
• Component – A collection of related requirements which forms part of a project. A requirement may belong to any number of components.
• Category – A collection of related projects.
Terminology continued
• Resolution – When a requirement reaches an end-state, it is considered resolved. A resolution is a categorization of how the requirement was resolved. Released and rejected requirements have resolutions.
Rejected Resolutions
• Unclear – The meaning of the requirement cannot be assertained..
• Duplicate – The requirement has already been proposed.
• Inconsistent – The requirement conflicts with the existing set of requirements.
• Not verifiable – The requirement cannot be objectively tested.
• Not traceable – The requirement cannot be traced to a source.
• Not appropriate - The requirement does not support the science goals of the telescope.
Released Resolutions
• Satisfied – The requirement is satisfied by the current release of the product.
• Deprecated – The requirement is no longer supported by the product.
Jira Demo Prelude
• Demo will be brief. Jira’s online help is very good
• Location: http://jira.lbto.arizona.edu/jira
• Login: LDAP username and password– Homework: Let me know if you can’t. I had to
guess at your usernames
Jira Demo
• Home*
• Category and project creation done by the software manager
• Project Lead assigned by the software manager
• Component creation done by project lead*
• Component lead assigned by project lead*
Jira Demo continued
• Feature creation*
• Derived requirement creation*
• Commenting verses editing
• Requirement workflow*
• Linking issues*– Only conflicts supported by us
• Referring to other issues*
Jira Demo continued
• What would you like to see?
• What are your concerns?