[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [plcs-dex] Assignment of Time properties - to task or person?
Thanks Gordon,
you are quite correct in stating the requirements, but
the modelling aspect is not always 1:1 with reality, nor is it always efficient
to do so. At the task level this is effectively a quantity measure (of time) of
a required resource (type of person) who has a certain skill. At the
planning level, more or less time might be allotted depending upon other factors
not applicable at the time the effort was predicted. Hence it is (task-wise) a
quantity (time) that has to be associated with the resource_item (person),
rather than the actual time taken or the time allotted to the task itself in any
particular plan.
My earlier solution was correct, but not optimal.
Having discussed with Leif G. we both realised that rather than use an
assigned_property, we should really use a resource_property, on the principle
that the time required is a property of the required resource - and that most
assigned_properties are assigned to products, not resources (but there's no hard
rule anywhere to state this).
The revised slide is attached.
This raised some questions about how to separate the
functions of task and activity representation across the Dexs, and the
separation between them. Tasks can (and are) defined as part of the support
solution against the design of the product. Activities entered into a plan are
defined with an individual occurrence of the product in mind and provide the
authority for either a typical (set) of activities to be carried out, or an
identified subset of the typical, or perhaps identified tasks within several
typical sets (or even a combination).
The level of refinement and specification
of resources realized for a planned activity, however, cannot reproduce
those defined at levels below that of the task. That is, there is not a
direct equivalent of a task_element (or subtype) within the model for
activities. In order to achieve this requires re-creating the task and it's
components.
The model supports typical activities or groupings of
tasks to an instance of activity_method through activity_method_realization
relationships. Hence a typical activity might be defined to address a specific
issue or maintenance requirement. Within Dex4, at the planning level the whole
of the typical_activity may be authorized to proceed as a work item. However,
equally as likely, is that the typical activity will be approved, but only
specific tasks (or task_elements) within will be authorized through an
applied_activity_assignment.
Where there are no typical activities defined, the
model allows the planned activity to identify a (single) task as it's
chosen_method, and to identify the task_elements to be carried out through an
instance of applied_activity_assignment (as necessary). However, this is
unsatisfactory if more than one task is required for the activity. [Thus
the reasoning behind a Typical Activity]. There is one other mechanism that can
achieve this, but requires the use of a hierarchical structure (one deep) built
using activity_method_relationships between both sub-activities and tasks on one
hand and activity_relationships between the main <planned> activity and
the sub-activities.
While the prior mechanism for dealing with sets of
tasks makes use of activity_method as a collector, and is perhaps simpler, if
this is not present within Dex3, it will hinder interoperation. However, the
latter mechanism would require an almost mirroring of the task structure
revealing a more complicated model, but one which might provide the ability to
assign resource refinements at the level of task_elements when planning.
Task elements are important when considering planning
for multiple tasks since some tasks will naturally overlap in some of their
initial preparation elements or closedown operations. E.g. 3 tasks dealing with
a car engine might require the bonnet(hood) to be opened in preparation as the
first task_element in a sequence, but this element only needs to be planned for
once if the activities can be scheduled together. Hence, authorising only those
required is of interest.
Of course different planning systems will have
different capabilities and requirements in these matters. For basic planning
systems it could be assumed that resource realizations will apply to those
defined at the task_method_version level and all those elements subsumed,
whereas for those systems planning in greater detail, realized
resources may be applied at either the task_method_version or at the
individual task_element level.
The use of a typical activity does not preclude the
ability to define a hierarchy of (sub)activities to further identify resources
being realized at the level of task_elements, but the exclusion of
activity_method from Dex3 to
regards,
Tim
From: Gordon Robb Sent: 30 January 2006 08:48 To: Tim Turner; 'plcs-dex@lists.oasis-open.org' Subject: RE: [plcs-dex] Assignment of Time properties - to task or person? Tim,
In
respect to a DEX 4 requirement I would consider that the recipients require to
know the skill set and man hour duration required to complete the
task.
In
respect to Air Technical Publications each work card provides the skill set
and man-hours required therefore your option 2 is the better
option
On
feedback of the task [DEX 9] the recipients may have used 2 men and done it in 2
hours, and/or used a higher skill set [technician/artificer]
Gordon
From: Tim Turner Sent: 30 January 2006 08:36 To: 'Gyllström Leif'; Tim Turner; 'plcs-dex@lists.oasis-open.org' Subject: RE: [plcs-dex] Assignment of Time properties - to task or person? Thanks Leif,
I found several different approaches in Dex3 & task
related capabilities, but my example seems not to fit squarely into these. We
are not dealing with the actual time (as recorded) here either (yet), though I
see your point regarding the realized/actuals.
It is not possible to create a
required_resource_by_resource_item for time, as this is not defined as a
resource_item. That is, time itself, cannot be modelled as a resource on it's
own. The only mechanism appears to be through another resource_item, like
you mention, which was my clumsy way of explaining option 1. Having defined
a type_of_person representation already, I can also use the
(mandatory) type_of_person_definition to point at using the
assigned_property.described_element. As you also hinted, person &
organization etc., are also in the property assignment select type
list.
I attach 2 slides to illustrate, but I think your third way
- is my option 1.
But of course I could be missing your entire
point...
regards,
Tim
NB -
On an entirely separate note (to ALL), is there general consensus that where
quantity information is not provided for an item (e.g. resource), that by
default only a single item is inferred?
From: Gyllström Leif [mailto:leif.gyllstrom@aerotechtelub.se] Sent: 30 January 2006 03:43 To: Tim Turner; plcs-dex@lists.oasis-open.org Subject: RE: [plcs-dex] Assignment of Time properties - to task or person? Tim I'd say that you shall
use a third alternative : -
Required_resource, and
assign a property to Required resource representing planned required
time -
Resource_as_realized
and assign a property to Resource_as_realized representing actual
time Then you can use a
consistent approach regardless of whether you use a Person, Type_of_person,
Oragnization or Organization_type as
the Resource Regards Leif From: Tim Turner [mailto:tjt@lsc.co.uk]
The
time required to perform a task, by 1 (mechanic) person is 4
hours. Looking at the model, I see that it
is possible for me to represent this in one of two ways;
1.
By modelling the duration as an assigned_property of the (resource)
type_of_person_definition - i.e. 1 mechanic required for 4 hours
or, 2.
By again modelling the duration as an assigned_property, but this time
associated with the task_method_version_assignment
instance. The
fundamental question is whether the time required (duration) should be a
function of the task, or as a function of the
person. Note: this task may be assigned to
more than one item through the task_method_version_assignment. However, the time
required is for each task, thus option 2 forces each item to have it's own
task_method_version_assignment and a repetition of the duration property for
each. The alternative, option 1, assigning the duration to the resource_property
would appear to make more sense, since the duration may change if the skill
level of the person assigned changed. Is
this in agreement with other modeller views? Kind regards,
NB.
Option 2 might be used where the effort is defined in terms of each item that
the task is defined/used with. E.g. if for item a) the task takes 4 hours, but
for item b) the time is 5 hours. Option 1 appears best used if the
time is the same for all items that the task is applicable to.
************************************************************************* DISCLAIMER:
***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in
this message is confidential and may be legally privileged. It is intended
solely for the addressee. Access to this message by anyone else is
unauthorised. If you are not the intended recipient, any disclosure,
copying, or distribution of the message, or any action or omission taken by you
in reliance on it, is prohibited and may be unlawful. Please immediately
contact the sender if you have received this message in error. This e-mail
originates from LSC Group. Registered in England & Wales No 2275471
Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG
DISCLAIMER: ***SECURITY LABEL: NOT PROTECTIVELY MARKED*** The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. This e-mail originates from LSC Group. Registered in England & Wales No 2275471 Registered Office: Devonport Royal Dockyard, Devonport, Plymouth, PL1 4SG
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]