Assigning X to Y or Y to X

["Barker, Sean (UK)" <sean.barker@baesystems.com>]

In PLCS, the question has arisen several times on whether we should
assign X to Y or Y to X. For example, assign a resource to a
task_element via a task_element_assignment or via a
resource_item_assignment. Or a contract to a task_method via a
task_method_assigment or a contract_assignment.

This ability to do things either way round is not uncommon in PLCS.
Currently we have no principled way of deciding which way to do this
(and Leif G and I are not perfectly in accord - [disagree is too strong]
on which way round for task_element to resource).

Looking at this from a configuration control viewpoint, and using the
example of task_method, the boundary of "task_method" (while beyond the
scope of the standard) needs to be determinate. That is, it must be
possible to decide whether a change to an association requires a new
version of a task_method. My preference would be to say "if the
association is part of the [configuration] definition of the item, then
use the association tied to the item, otherwise, use the opposite sense.
An alternative way of expressing this is to say that the association is
from the dependent to the free-standing item, with the role being
defined relative to the dependent item (the task_method "uses" the
resource - the resource may have several other uses).

That is, where a task_method uses a resource_item, then changing the
resource may require a reissue of the task_method - in this instance use
a task_method_association. Where a resource defines, say, a preparation
task (such as calibrate), then changing the preparation method changes
the definition of the resource, and in which case use
resource_item_association.

Similarly, where a contract cites a task_method, then use a
contract_assignment. A task_method_assignment to a contract would only
be used if the task_method actually created the contract.

There are two possible problems with this approach. Firstly there may
not be a two-way option. Secondly, the configuration control scope may
change from business to business. In the first case, we must live with
this - it simply means that the configuration implications of the
relationship will need spelling out in any exchange agreement.

In the second case we can make the assertion stronger in the negative.
That is, using the item association is an assertion that the item is not
part of the configuration of the target. In the case of a task using a
resource, the use of task_element_assignment is an assertion that a
change to that assignment does not affect the definition of the resource
(but it may well affect the definition of the task).