OSID - osid.tracking Package Description

Package osid.tracking

Title Tracking Open Service Interface Definitions

Version 3.0.0

Description

Package	osid.tracking
Description	The Tracking OSID provides a means for tracking `Issues.` The Tracking OSID is part of a service cluster that includes the Resourcing OSID, Ontology OSID, Workflow OSID, and Process OSID. Each of these services defines a set of service operations to construct an overall work management system. Issues `Issues` are `OsidRelationships` between a customer and a `Queue.` The effective dates of the `Issue` represent the opening and closing of the `Issue.` An `Issue` defines some built-in states indicating if the `Issue` is resolved, waiting for a response, or blocked on another `Issue.` Additional states can be modeled orchestrating the Process OSID or through the Workflow OSID. `Issues` can be related to each other in various ways. Subtask Issues `Issues` can be created off of other `Issues` in the `SubtaskIssueAdminSession.` The subtask is an Issue in itself which can have its own relationships including additional subtasks. A Tracking OSID Provider may prevent the resolution of a master issue unless all the subtask `Issues` have been resolved. Duplicate Issues `Issues` can be linekd to each other to indicate that two Issues are duplicates of each other. A Tracking OSID Provider may implement a behavior to replicate operations across duplicate issues. Branched Issues A branched `Issue` is created from a root `Issue` where new tasks need to be assigned and tracked separately but it is desirable to link these new tasks to the data in the root `Issue.` The difference between a subtask and a branched `Issue` is that a branched `Issue` is independent of the root `Issue.` Blocking Issues Blocking `Issues` indicate an `Issue` is blocked in the resolution of another `Issue` . Log Entries `Issues` have logs to provide a record of actions and comments. Queues A `Queue` is an `OsidGovernator` that governs the constraints and processing of a set of `Issues.` All Issues belong to one `Queue.` Topics The Ontology OSID can be orchestrated with the Tracking OSID to assign a topic ( `Subject` ) to an `Issue.` The orchestration requires relating a `Queue` to an `Ontology` and can be explicitly managed using the `OntologyAssignmentSession.` An `Ontology` serves to restrict the set of topics an `Issue` can be assigned. An `Issue` is defined as having a single topic that is directly accessible from an `Issue` that may be assigned directly in the Tracking OSID. However, a view of the hierarchy of assignable topics can be created using the Ontology OSID where the `Ontology` `Id` is orchestrated with the `Queue` `Id` . For convenience, a simple non-hierarchical list of topics can be accessed directly in the Tracking OSID. To summarize, assignment of pre-determined flat lists of topics can be performed directly in the Tracking OSID while managing the set of assignable topics or viewing the topics in a hierarchy is performed using the Ontology OSID. Issue States Issues define a set of basic states to indicate if they are new, reopened, closed, or resolved. To create other states requires the Process OSID where a `Queue` `Id` is orchestrated with a `Process` Id. To view the flow of an Issue through its steps to resolution, the Workflow OSID can be used for a more sophisticated view and tighter management controls through a custom state model. Assigning Resources Issues can be assigned a Resource which generally represents the person assigned to the case. Simple Resource management is provided by the IssueResourcingSession. More sophisticated Resource management and automated resource matching and assignment may be orchestrated using the Resourcing OSID. When using the Resourcing OSID for automated assignment it may be useful to manage competencies based on experience with the topic of an `Issue` to determine the best match with a `Resource.` In this scenario, orchestrationof the Resourcing OSID with the Learning OSID should be considered which involves linking a `Subject` in the Ontology OSID with an `Objective` in the Learning OSID. A tracking service has many aspects that can be independently integrated and consequently the Tracking OSID is at the intersection of several other OSIDs. Front Office Cataloging `Queues` and `Issues` may be organized into federatable `OsidCatalogs.`

The Tracking OSID provides a means for tracking Issues. The Tracking OSID is part of a service cluster that includes the Resourcing OSID, Ontology OSID, Workflow OSID, and Process OSID. Each of these services defines a set of service operations to construct an overall work management system.

Issues

Issues are OsidRelationships between a customer and a Queue. The effective dates of the Issue represent the opening and closing of the Issue. An Issue defines some built-in states indicating if the Issue is resolved, waiting for a response, or blocked on another Issue. Additional states can be modeled orchestrating the Process OSID or through the Workflow OSID.

Issues can be related to each other in various ways.

Subtask Issues

Issues can be created off of other Issues in the SubtaskIssueAdminSession. The subtask is an Issue in itself which can have its own relationships including additional subtasks. A Tracking OSID Provider may prevent the resolution of a master issue unless all the subtask Issues have been resolved.

Duplicate Issues

Issues can be linekd to each other to indicate that two Issues are duplicates of each other. A Tracking OSID Provider may implement a behavior to replicate operations across duplicate issues.

Branched Issues

A branched Issue is created from a root Issue where new tasks need to be assigned and tracked separately but it is desirable to link these new tasks to the data in the root Issue. The difference between a subtask and a branched Issue is that a branched Issue is independent of the root Issue.

Blocking Issues

Blocking Issues indicate an Issue is blocked in the resolution of another Issue .

Log Entries

Issues have logs to provide a record of actions and comments.

Queues

A Queue is an OsidGovernator that governs the constraints and processing of a set of Issues. All Issues belong to one Queue.

Topics

The Ontology OSID can be orchestrated with the Tracking OSID to assign a topic ( Subject ) to an Issue. The orchestration requires relating a Queue to an Ontology and can be explicitly managed using the OntologyAssignmentSession. An Ontology serves to restrict the set of topics an Issue can be assigned.

An Issue is defined as having a single topic that is directly accessible from an Issue that may be assigned directly in the Tracking OSID. However, a view of the hierarchy of assignable topics can be created using the Ontology OSID where the Ontology Id is orchestrated with the Queue Id . For convenience, a simple non-hierarchical list of topics can be accessed directly in the Tracking OSID.

To summarize, assignment of pre-determined flat lists of topics can be performed directly in the Tracking OSID while managing the set of assignable topics or viewing the topics in a hierarchy is performed using the Ontology OSID.

Issue States

Issues define a set of basic states to indicate if they are new, reopened, closed, or resolved. To create other states requires the Process OSID where a Queue Id is orchestrated with a Process Id. To view the flow of an Issue through its steps to resolution, the Workflow OSID can be used for a more sophisticated view and tighter management controls through a custom state model.

Assigning Resources

Issues can be assigned a Resource which generally represents the person assigned to the case. Simple Resource management is provided by the IssueResourcingSession. More sophisticated Resource management and automated resource matching and assignment may be orchestrated using the Resourcing OSID.

When using the Resourcing OSID for automated assignment it may be useful to manage competencies based on experience with the topic of an Issue to determine the best match with a Resource. In this scenario, orchestrationof the Resourcing OSID with the Learning OSID should be considered which involves linking a Subject in the Ontology OSID with an Objective in the Learning OSID.

A tracking service has many aspects that can be independently integrated and consequently the Tracking OSID is at the intersection of several other OSIDs.

Front Office Cataloging

Queues and Issues may be organized into federatable OsidCatalogs.