Template:— referencing_task (ref_task) | Date: 2009/04/26 18:00:55 Revision: 1.20 |
This section specifies the template referencing_task.
NOTE An explanation of a template and the associated instantiation path is provided in the Template overview section.
This template describes how to reference to a task specification.
A task specification is a structured procedural description of how to do something. A task specification does not plan, schedule, or record what is done. A typical support solution comes with a library of tasks for the support of the product, such as would be collected together in a maintenance manual. The template for referencing a task specification enables the user to reference a complete task - for example, from the manual - without having to reproduce the details of the task. These tasks may be referenced in a maintenance schedule or a statement of work.
This template assumes that each task specification is known by a unique identifier. To ensure uniqueness, the identifier is given the context of the organization that owns the identifier.
NOTE 1 There are potentially two other requirements for ways of referencing a task. Firstly, for some organizations, task numbers are unique only in the context of a particular product, and the organization may reuse the same numbers for different tasks on different product lines. This template does not allow explicit refrence to the product, however this requirement could be met by identifying the project controlling each product as an organization in its own right, which is then a component organization of the wider organization. Secondly, an organization may assign task numbers on the basis of the usage of its product within a particular end product. For example, the provider of an altimeter may provide provide a set of calibration tasks tailored to the particular aircraft it is fitted to. This could be catered for through a variant identifier rather than citing the end product explicitly, however variants are out of scope of this template. This is not to say these work rounds will be appropriate in every case, and it would be better if additional referencing templates were created. However, at the time of writing, there are no actual requirements for such templates.
The definition of a task specification may evolve over the lifetime of the support solution. This evolution is controlled by creating separate versions of a task, and declaring them fit for use, e.g. by a formal issue process. This template describes how to reference the different versions of a task specification. The version number is required. In product environments which do not record task version identifier, the recommended practice is that the version identifier be set to 1.
In the process of drafting a new version, a task specification will frequently go through several iterations. The reference to such iterations is outside the scope of this template, which is limited to the usage phase of the task specification.
A task specification may be customised for different environments, for its use with a particular product, or for a particular maintenance organization. The term variant is used to indicate a minor variation from the specification which is in use at the same time as other such variants - that is, unlike versions, variants do not supercede each other. The specification of variants, either by reference to context or by variant identifier is beyond the scope of this template.
To identify a task, the reference must explicitly include the task identifier and its version identifier. This template does not support rule based references, such as "the latest authorized version".
The use of the term version for evolution sequence and variant for concurrent variation is consistent throughout this series of specifications. However, business terminology varies widely, with terms such as version, variant, issue, revision and mark used in no consistent way. It is therefore expected that the business which use the standard will map against their terminology to that of the standard, to ensure that the standard is used consistently.
The overall description of the model is given in the capability for representing_task. The subset of the model shown here shows only the entities and attributes that need be populated to reference the task. In particular the optional attribute content is omitted, and the attribute set (S[0..?) objective is omitted (assigning objectives will be the subject of a separate template). Both Task_method and Task_method_version are subtypes of Activity_method.
In referencing a task, the target entity is the Task_method_version, that is, every reference to a task is to a specific version of the task. Referencing Task_method_version requires the instantiation of the Task_method which it is a version of, and which carries the task identifier. The Task_method_version carries the version identifier.
target
is the parameter to which the
Task_method
is bound.
target
is the parameter to which the
Task_method_version
is bound.
Entity in path | Value | Inherited from |
Task_method.name | '/IGNORE' | Activity_method.name |
Task_method.description | '/IGNORE' | Activity_method.description |
Task_method.consequence | '/IGNORE' | Activity_method.consequence |
Task_method.purpose | '/IGNORE' | Activity_method.purpose |
Task_method_version.name | '/IGNORE' | Activity_method.name |
Task_method_version.description | '/IGNORE' | Activity_method.description |
Task_method_version.consequence | '/IGNORE' | Activity_method.consequence |
Task_method_version.purpose | '/IGNORE' | Activity_method.purpose |
© OASIS 2010 — All rights reserved