Capability (C046):— representing_variance Date: 2007/06/22 12:22:11
Revision: 1.30

Issue raised against: representing_variance

OTHER issues


Open issue Issue: RBN-2 by Rob Bodington (06-06-27) minor_technical issue
Resolution: Accept. Status: open

The template assigning_supported_justification should really be defined in the capability representing_justification


Open issue Issue: RBN-3 by Rob Bodington (06-06-27) minor_technical issue
Resolution: Accept. Status: open

In the template assigning_supported_justification, the descriptor assigned to the justification should be optional.


Open issue Issue: RBN-4 by Rob Bodington (06-06-27) minor_technical issue
Resolution: Accept. Status: open

The template assigning_condition should really be defined in the capability representing_condition


Open issue Issue: RBN-5 by Rob Bodington (06-06-27) minor_technical issue
Resolution: Accept. Status: open

In the template assigning_supported_justification, does it make sense to classify both the justification_assignment and the justification_support_assignment


Open issue Issue: TJT-1 by Tim Turner (07-02-2) minor_technical issue
Resolution: Accept. Status: open

Thanks Peter, this was the original intention variance was just a parking place until there was time/effort to update the other capability. regards, Tim From: Peter Bergström [mailto:peter.bergstrom@eurostep.com] Sent: 31 January 2007 11:17 To: plcs-dex@lists.oasis-open.org Subject: [plcs-dex] justifications I have removed template assigning_supported_justification from capability representing_variance. Instead, I’m in the process of creating two new templates in capability representing_justification. They are together identical to the old template, but I split it in two for two reasons: 1) For simple justifications, it is enough to describe them in a text string, using asg_descriptor. [Tim Turner] ok 2) It is now possible to assign more than one item as supporting the justification, each with its own classification. [Tim Turner] Agreed - I should have left that item open! The two new templates are assigning_justification and assigning_justification_support_item. [Tim Turner] Fine - only issue is documenting the /ignore(s) for the former of these that Fig 1 of the latter, gives the impression that more entities are instantiated than actually are (perhaps only show the justification entity, not all the others covered by the other template?). The capability representing_variance needs to be updated to reflect this, as well as the DEX work_package_definition. [Tim Turner] True Peter Bergström Eurostep


Open issue Issue: PBM-1 by Peter Bergström (2007-01-23) editorial issue
Resolution: Accept. Status: open

This capability has two editors. I suggest one is removed.

OTHER issues


Closed issue Issue: AMS-1 by annmeads (04-03-03) minor_technical issue
Resolution: Accept. Status: closed

One type of concession/variance is the decision to re-schedule an activity to a later date. This could be modelled as a Justification on the Activity_happening relationship between Activity and Activity_actual. Can this capability provide Activity_actual and Activity_happening?
Comment: (Rob Bodington 04-09-29)
An Activity_actual represents an Activity that has happened. I do not see why you would want to specify a variance against an activity that has happened in the past. The variance would be against the planned activity (Activity) and or the assignment of the planned activity to a product.
Comment: (Ann Meads 04-09-29)
This was how we modelled UMMS concessions upon advice from Nigel Shaw. However, I think you are correct in your analysis. If it makes sense to assign a justification to a 'new' date_or_date_time_assignment to the (planned) activity and this is covered by a capability, the issue is resolved.


Closed issue Issue: TRO-1 by Trisha Rollo (05-01-19) minor_technical issue
Resolution: Accept. Status: closed

Figure 1 states that (Condition) is the "conditions under which concession applicable" and (Justification) is "reasons for concession" however figure 2 shows the(Condition) bit as being the "reasons for concession"
Comment: (Rob Bodington 05-01-19)
Corrected the diagram


Closed issue Issue: RBN-1 by Rob Bodington (05-01-19) minor_technical issue
Resolution: Accept. Status: closed

Under reasons for Concession, 3rd paragraph, last line; this example is surely conditional which is only meant to be applicable for conditional concessions
Comment: (Rob Bodington 05-01-19)
Agreed - modified the example


Closed issue Issue: NN-1 by Nigel Newling (05-11-17) minor_technical issue
Resolution: Accept. Status: closed

Document is assigned to Approval for both reasons for concessions and documented conditions, both with the classification of Concession. How would you distinguish them?
Comment: (Tim Turner 06-04-16)
New ref data provided for distihguishing between documents for, concession, justification and conditions.


Closed issue Issue: NN-2 by Nigel Newling (05-11-17) minor_technical issue
Resolution: Accept. Status: closed

Do we both populate the actual_date attribute and use Date_or_date_time_assignment with Calendar_date?
Comment: (Tim Turner 06-04-16)
No, the local calendar dates are optional, so we should ignore them and be consistent by applying the dates through assignment of ref.data.


Closed issue Issue: NN-3 by Nigel Newling (05-11-17) minor_technical issue
Resolution: Accept. Status: closed

Should a related capability be representing_product_as_individual?
Comment: (Tim Turner 06-04-16)
The application of the capability is separate from the definition of its use. Relating all capabilities based upon possible usage is probably not practical, nor the norm as far as I'm aware.