Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "OSEE/ATS/Users Guide/Usage"

(ATS New Action Wizard)
Line 1: Line 1:
=Report a Bug=
+
=ATS New Action Wizard=
  
==Purpose==
+
==Part One==
  
A quick way to report a bug against a view or editor.
+
===Title===
  
==How to do it==
+
This text will be the title for the action being created. This is a required field.
  
Select the bug button ([[Image:bug.gif]]) from the toolbar at the top
+
===Select Actionable Items===
of the view or editor that has the problem. A wizard will come up to provide guidance
+
 
through the rest of the steps.
+
Expand the tree and pick the appropriate item or items associated with this action.  
 +
 
 +
===Filter===
 +
 
 +
Removes items from the Impacted Items tree which do not match the specified filter. Clearing the filter will restore the complete list of items in the tree.
 +
 
 +
==Part Two==
 +
 
 +
===Description===
 +
 
 +
Enter the detailed description for the action.
 +
 
 +
===Change Type===
 +
 
 +
Choose the type of change for the action:
 +
 
 +
# Improvement: This action is an improvement to an existing component or functionality, or new functionality for an existing system.
 +
# Problem: This action describes a problem with existing functionality.
 +
# Support: This action required user support, no product changes required.
 +
 
 +
===Priority===
 +
 
 +
Choose the significance of the action. See this [[OSEE/ATS/Users_Guide/Usage#Priorities for classifying problems|table]] for a description of various priority levels.
 +
 
 +
===Deadline===
 +
 
 +
Pick a date when this action should be resolved.
 +
 
 +
===Validation Required===
 +
 
 +
Select this checkbox if the action requires validation once it is resolved.
 +
 
 +
===User Community===
 +
 
 +
Choose the group or groups affected by this action. Use the ctrl or shift keys to select multiple items.  
  
 
=Priorities for classifying problems=
 
=Priorities for classifying problems=
Line 343: Line 377:
  
 
[http://127.0.0.1:4441/help/topic/org.eclipse.osee.framework.ui.skynet/reference/OSEE%20Branch%20Differences.pdf OSEE Differeces Diagram]
 
[http://127.0.0.1:4441/help/topic/org.eclipse.osee.framework.ui.skynet/reference/OSEE%20Branch%20Differences.pdf OSEE Differeces Diagram]
 +
 +
=Report a Bug=
 +
 +
==Purpose==
 +
 +
A quick way to report a bug against a view or editor.
 +
 +
==How to do it==
 +
 +
Select the bug button ([[Image:bug.gif]]) from the toolbar at the top
 +
of the view or editor that has the problem. A wizard will come up to provide guidance
 +
through the rest of the steps.
 +
 +
[[Category:OSEE]]

Revision as of 18:29, 10 September 2009

ATS New Action Wizard

Part One

Title

This text will be the title for the action being created. This is a required field.

Select Actionable Items

Expand the tree and pick the appropriate item or items associated with this action.

Filter

Removes items from the Impacted Items tree which do not match the specified filter. Clearing the filter will restore the complete list of items in the tree.

Part Two

Description

Enter the detailed description for the action.

Change Type

Choose the type of change for the action:

  1. Improvement: This action is an improvement to an existing component or functionality, or new functionality for an existing system.
  2. Problem: This action describes a problem with existing functionality.
  3. Support: This action required user support, no product changes required.

Priority

Choose the significance of the action. See this table for a description of various priority levels.

Deadline

Pick a date when this action should be resolved.

Validation Required

Select this checkbox if the action requires validation once it is resolved.

User Community

Choose the group or groups affected by this action. Use the ctrl or shift keys to select multiple items.

Priorities for classifying problems

Priority Description MIL-STD-498 Description
1 Prevents end users from performing an essential task that results in work stoppages. The impact to project cost/schedule requires an immediate resolution and a special release may be necessary. a.Prevent the accomplishment of an operational or mission essential capability

b.Jeopardize safety, security, or other requirement designated "critical"

2 Adversely affects end users from performing an essential task. Significant impact to project cost/schedule with resolution needed within 3 weeks. a. Adversely affect the accomplishment of an operational or mission essential capability and no work-around solution is known.

b. Adversely affect technical, cost, or schedule risks to the project or to life cycle support of the system, and no work-around solution is known.

3 Hinders end users from performing an essential task or a capability is behind schedule. Impact to project cost/schedule with resolution needed within 6 weeks. a. Adversely affect the accomplishment of an operational or mission essential capability but a work-around solution is known.

b. Adversely affect technical, cost, or schedule risks to the project or to life cycle support of the system, but a work-around solution is known.

4 Minor impact to end users or is a capability being developed per schedule. Can be resolved per normal release schedule. a. Result in user/operator inconvenience or annoyance but does not affect a required operational or mission essential capability.

b. Result in inconvenience or annoyance for development or support personnel, but does not prevent the accomplishment of those responsibilities.

5 An inconvenience or annoyance. Can be resolved as schedule and budget permits. Any other effect

OSEE Spell Checking

Spell check.jpg

Purpose

Enable data entered in OSEE to be spell checked.

How to do it

As data is entered into OSEE spell-checked fields, a blue line will be displayed if the word is not recognized. Only lowercase words or words with only the first character capitalized will be spell checked. Acronyms, words with special characters, numbers, and single letter words will be ignored.

Main Dictionary

OSEE has a main dictionary included in its release. See below for its source, copyright information, and credits.

Additional Released Dictionaries

Additionally dictionaries can be added to OSEE via extension points. These can only be modified by hand and thus included in normal release cycle.

Run-time Global Dictionary

Each OSEE user is able to add words to a Global dictionary stored in the database by right-clicking on the word underlined in blue and selecting to save global. These words are stored in the "Global Preferences" artifact and will then be shown as a valid word in all users' spell checking.

Run-time Personal Dictionary

Each OSEE user is able to add words to their Personal dictionary stored in the database by right-clicking on the word underlined in blue and selecting to save personal. These words are stored in the user's "User" artifact and will then be shown as a valid word only for that user.

Peer To Peer Review Workflow

Purpose

The Peer To Peer Review is a lightweight review type that enables interactive one-on-one reviews where two people sit at a single computer and review, disposition and resolve the issues as they are found. This review type does not require (but does allow) defects to be logged. This review type can be created as a stand-alone review or attached to any workflow. When attached to a workflow, it is related to a state and can be set as a "blocking" review that will keep the workflow from continuing until the review is completed.

State Machine

PeerToPeerReviewStateMachine.JPG

How to do it

Stand-Alone Peer To Peer Review
From ATS Navigator, filter on "peer" and select "New Peer To Peer Review". Enter required fields and select transition to start the review.
Workflow Related Peer To Peer Review
From any ATS workflow editor, select "Create a Peer To Peer Review" in the left column of the workflow editor. This will create the review and attach it to the current state. Enter required fields and select transition to start the review.

Prepare State

PeerToPeerReviewEditorPrepare.jpg

This state allows the user to create the peer to peer review. Enter the required information and transition to Review to start the review. All review participants will be automatically assigned to the review state upon transition.

Field Description
Title Enter a descriptive title for this review.
Review Roles Add roles and select the appropriate user. This review type requires at least one Author and one Reviewer.
Location of review materials Enter a description of the review materials, or simply drag in files to be reviewed from the workspace. If files are dropped in this box, the java package name (if appropriate), file name and a space to enter in the repository version will be provided.
Description Information necessary to make an informed decision.
Blocking Review If not a stand-alone review, this field will be enabled for entry. Select Yes if this review must be completed before the parent workflow can transition.
Need By Date the review should be completed.

Review State

PeerToPeerReviewEditorReview.jpg

This state allows the users to review the materials, log any defects and allows for the author to resolve and close any defects.

Field Description
Review Roles Add or remove participants as needed. See Prepare State description for more information.
Review Defect Defects are not required, but can be entered. Defects must be dispositioned and closed before the review can be completed.
Resolution Any notes or further information can be entered here.

Decision Review Workflow

Purpose

The Decision Review is a simple review that allows one or multiple users to review something and answer a question. This review can be created, and thus attached, to any reviewable state in ATS. In addition, it can be created automatically to perform simple "validation" type reviews during a workflow.

State Machine

DecisionReview.JPG

How to do it

From any active state, select "Create a Decision Review" in the left column of the workflow editor. This will create the review and attach it to the current state. Then, proceed to "Prepare State" to entering the necessary information required for this review.

Prepare State

DecisionReviewPrepare.jpg

This state allows the user to create the decision review. Enter the required information and transition to Decision to start the review. All transitioned to assignees will be required to perform the review.

Field Description
Title Enter the question that is to be answered by the reviewers. For example: "Do you think we should buy this software?"
Decision Review Options Enter all the options that are available for selection. Each line is a single decision option in the format answer;state;<userId>, where
  • answer = Yes, No, Maybe, ...
  • state = Followup or Completed (this will be the state to transition to if the answer is chosen)
  • <userId> = userId of the user to assign the state to transition to. UserIds are only valid for Followup state, as the Completed state has no assignees. (Note that multiple users can be specified as follows: <userId1><userId2>)
Description Information necessary to make an informed decision.
Blocking Review "Yes" if this review must be completed before the parent workflow can transition.
Need By Date the decision must be made.

Decision State

DecisionReviewDecision.jpg

This state allows the user to review the description or materials and choose their decision.

Field Description
Question The question to be answered as part of this review.
Decision The decision made by the user.
Resolution Any notes or information as to why the decision was made.

Followup State

This state allows for followup action to be taken based on the decision.

Field Description
Resolution Any notes or information as to why the decision was made.

Configure ATS for Change Tracking

Purpose

ATS is used to track any type of change throughout the lifecycle of a project. Below are the steps to configure ATS for tracking something new.

How to do it

  • Review "ATS Overview" to understand ATS Concepts, Terms and Architecture. Pay special attention to ATS Terms.
  • Determine what Actionable Items (AIs) need to be available to the user to select from. This can be anything from a single AI for tracking something like a tool or even an activity that needs to be done to a hierarchical decomposition of an entire software product or engineering program.
    • Considerations:
      • Item should be in the context of what the user would recognize. For example, OSEE ATS World View versus something unknown to the user such as AtsWorldView.java.
      • Decompose AI into children AI when it is desired to sort/filter/report by that decomposition.
    • Actionable Item attributes to be configured:
      • Name: Unique name that the user would identify with.
      • Active: yes (converted to "no" when AI is no longer actionable)
    • Actionable Item relations to be configured:
      • TeamActionableItem: relate to Team Definition that is responsible for performing the tasks associated with this AI. Note that if this relation is not set, ATS will walk up the Default Hierarchy to find the first AI with this relation.
  • Determine the teams that are going to perform the tasks that are associated with the AIs selected by the user.
    • Considerations:
      • Use separate teams if certain changes are to be managed by different leads.
      • Use separate teams if one team's completion and releasing is independent of another's.
      • Use separate teams if team members are separate.
      • Use separate teams if different workflows are required for one set of AIs than another.
    • Team attributes to be configured:
      • Name: Unique team name that is distinguishable from other teams in a list.
      • Description: Full description of the team and it's scope.
      • Active: yes (converted to "no" when AI is no longer actionable)
      • Team Uses Versions: yes if team workflows are going to use the build management and release capabilities of ATS.
      • Full Name: Extended name for the team. Expansion of acronym if applicable.
    • Team relations to be configured:
      • TeamActionableItem: relation to all AIs that this team is responsible for.
      • Work Item.Child: WorkFlowDefinition artifact configures the state machine that this team works under. Note that if this relation is not set, ATS will walk up the Default Hierarchy to find the first AI with this relation.
      • TeamLead: User(s) that are leading this team. These users will be assigned to the Endorse state of the Team Workflow upon creation of an Action by a user. Providing multiple leads reduces bottlenecks. First lead to handle the Team Workflow wins.
      • TeamMember: User(s) that are members of the team. These users will be shown first as preferred assignees and have the ability to privileged edit a Team Workflow for the team they belong to.
  • Choose existing WorkFlowDefinition or create new WorkFlowDefinition to be used by the team and relate it to Team Definition (as above). This can be done through File->New->Workflow Configuration. Enter a namespace and a default workflow will be created and can be edited.
  • Create version artifacts necessary (if using versions) and relate them to Team Definition (as above)
    • If branching of artifacts is going to be used (see below), configure versions with their appropriate parent branch id.
  • Determine if Branching within one of the states in the workflow is desired/required and configure as appropriate.
    • Considerations:
      • Branching is necessary if objects to change are stored in OSEE as artifacts. If so, OSEE ATS can create a working branch off the parent branch, allow user to modify artifacts and then commit these changes when complete, reviewed and authorized (as necessary). If objects are stored outside OSEE (eg. code files checked into SVN), this option is not necessary.
    • Configure ATS workflow for branching:
      • Create AtsStateItem extension specifying which state the branching will occur. This is normally in the Implement state of a workflow.
      • Create root branch and import documents that will be managed through define and tracked through ATS.
      • Set all Version artifacts "Parent Branch Id" attribute to the branch id of the root branch (or child branches, if using multi-branching)
      • If only a single branch is to be used OR versioning is NOT configured to be used, the "Parent Branch Id" should be s

Configure Team Definition

Purpose

The Team Definition artifact specifies leads and members that are assigned to work on related Actionable Items.

How to do it

  • Team Definitions should match company organizational structure.
  • Attributes
    • Name: [uniquely recognizable team name]
    • ats.Full Name: [optional full name]
    • ats.Description: [desc]
    • ats.Active: [yes]
    • ats.Team Uses Version: [yes if want to use release/build planning]
  • Relations
    • DefaultHeirarchy: Relate to parent team or top level "Teams"
    • TeamDefinitionToVersion: Relate to current and future VersionArtifacts
    • TeamLead: Relate to one or more team leads. These individuals will have privileged edit and perform the Endorse state by default.
    • TeamMember: Relate to one or more team members. These individuals will have ability to priviledged edit Workflows created by themselves against the team they belong to.
    • Work Item.Child: Relate to a single "Work Flow Definition" artifact that defines the workflow that will be used for this team.

Configure Actionable Items (AI)

Purpose

Actionable Items provide the end user with a selection of things impacted by the Action. They are related to the Team that is responsible for performing the work.

How to do it

  • AIs should not be deleted. Instead, use the ats.Active attribute to deactivate the AI. If an AI must be deleted, search for all "ats.Actionable Item" attributes that have the value of the AI's guid. These must be changed to another AI before deletion.
  • Actionable Item tree can be created to the level at which actions are to be written. Usually a component decomposition. In the case of UIs, create one for each view or window.
  • Attributes
    • Name: [uniquely recognizable team name]
    • ats.Active: [yes]
  • Relations
    • DefaultHeirarchy: Relate to parent team or top level "Actionable Items" artifact.
    • TeamActionableItem: Relate to team responsible for performing tasks. Team can be related to parent and all children will have team by default.

Workflow Configuration

Purpose

To create a new workflow configuration that ATS uses to move an Action through it's specific workflow.

Ats Workflow Configuration artifacts.

ATS uses four main artifacts to configure a workflow for use by a Team.

  • Work Flow Definition specifies the states, their transitions and the state that represents the beginning of the workflow.
  • Work Page Definition defines the a single state of the Work Flow Definition.
  • Work Widget Definition defines a single widget and its corresponding attribute that the value will be stored in. It also provides some layout capabilities for that widget.
  • Work Rule Definition defines certain rules that can be applied to Work Pages and Team Definitions.

How to do it

  • Workflows can be created using the ATS Workflow Configuration Editor (0.6.0 release). States and their transitions can be edited through this interface. Other modifications will need to be edited through Work Flow Definition attributes and relations.
  • Work Pages, Widgets and Rules are currently edited through the attributes and relations using the default Artifact Editor. See links above to set the proper values.
  • Configurations can also be created through the java. An example of this can be seen by looking at the org.eclipse.osee.ats.config.demo plugin. This plugin, and the DemoDatabaseConfig.java class, shows how to programatically generate work flows, pages, rules and widgets to configure ATS. This configuration will be generated during a database initialization.

Configure ATS for Help

Purpose

To configure ATS workflows to use the integrated help system. ATS help useds a combination of widget tooltip, static help pages and dynamic help content configured through extended plugins.

How to do it

  • Workflow Page Help
  • Workflow Widget Help
    • Declared tooltip is shown as tooltip when hover over label
    • Double-Click label pops open html dialog if help contextId and pluginId are set
    • Double-Click label pops open tooltip
    • Top down order of obtaining help content
      • Setting tooltip in IStateItem interface
      • Work Widget Definitions in Work Data attribute value of XWidget=...tooltip="put help here"
      • ATSAttributes.java declarations

OSEE Branching and Differences Diagrams

OSEE Branching Diagram

OSEE Differeces Diagram

Report a Bug

Purpose

A quick way to report a bug against a view or editor.

How to do it

Select the bug button (Bug.gif) from the toolbar at the top of the view or editor that has the problem. A wizard will come up to provide guidance through the rest of the steps.

Back to the top