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. This configuration is also necessary for the use of OSEE Review.

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 in outside OSEE (eg. code files in a Git repository), 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 Definition Configuration

Purpose

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

Ats Workflow Definition 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

Workflow Configuration

To create a new Workflow Configuration, use File-\>New-\>Other .. OSEE ATS-\>Workflow Configuration. Give the new workflow a namespace which reflects the relevant area and purpose and pick the most appropriate available starting workflow to base the new one on.
Workflows can be edited using the ATS Workflow Configuration Editor. States and their transitions can be edited through this interface. Other modifications will need to be edited through Work Flow Definition attributes and relations.
State changes can also be edited directly by opening the Workflow Definition with the Artifact Editor. "Transition" is a multi-valued attribute which is used to define the available transitions between states. Transitions take the form {SourceState};{Transition};{DestinationState}
Available transitions are:

ToPage
ToPageAsDefault
ToPageAsReturn

A new transition is created by adding a new value to the attribute using the green + to the right of "Transition" and an existing transition is deleted using the red x to the right of it.
States in the transition list must exist as Work Pages named with the following syntax: {WorkflowDefinitionName}.{NameOfState}

e.g. osee.ats.CustReqWorkflow contains a transition "Endorse;ToPage;Cancelled" so Work Pages osee.ats.CustReqWorkflow.Endorse and osee.ats.CustReqWorkflow.Cancelled must exist or an exception will be generated when opening the Workflow Definition in the Workflow Configuration Editor.

Do not make changes using the Artifact Editor and the Workflow Configuration Editor in the same editing session or OSEE may become confused as to which state is which.

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.