DEX: (D004) work_package_definition — Work Package Definition Date: 2007/09/14 16:11:29
Revision: 1.86
CoverContentsAbstractIntroductionTermsScopePLCS Activity ModelBusiness OverviewInformation OverviewInformation RequirementsPLCS RepresentationCapabilitiesTemplatesSchemasReference DataConformanceBibliography

Issue raised against: work_package_definition

OTHER issues

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: RBN-1 by Rob Bodington (06-06-21) minor_technical issue
Resolution: Accept. Status: open

You should use the templates in the EXPRESS_G diagrams - that way we ensure that model is used consistently. For example Fig 10 should use the templates for assigning an approval to a work order, rather than enumerating the express. The assigning_approval template recommends that dates are assigned to approvals, rather than using the date attributes. Similarly in most other figures. Furthermore, a number of sections describe generic usages of the model. For example, typical activity, work orders, and concessions. These should either make reference to the capabilities, or the text used should be be added to the relevant capability.

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

It would be better to hyperlink to DEXs rather than referring to them by name. Use dex_ref XML element e.g.task_set.

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

The section "Documenting the Definition of activities" states:

The definition of an Activity has been harmonized with the mechanism defined for defining tasks (see DEX 3), to enable a consistent, interoperable approach. This effectively treats the definition as a Document attached to the Activity identified.

I could not find this in DEX 3, and further more I would have thought that the definition of an activity should be done by assigning a document to an activity_method.

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

There are three "Activity_method Identification" sections after Fig 33 - two of which are empty.

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

The template "representing_lifecycle_opportunity" does not exist

Open issue Issue: RBN-6 by Rob Bodington (06-07-05) minor_technical issue
Resolution: Accept. Status: open

The dex.xml does not conform to the DTD

Open issue Issue: RBN-7 by Rob Bodington (06-07-05) minor_technical issue
Resolution: Accept. Status: open

The DEX states:

The Approval_assignment links the Work_order to an Approval. The Approval_assignment shall in these circumstances be classified as a "Work_order_approval" (urn:plcs:rdl:std:Work_order_approval) (a sub-class of "Approval_assignment_role" (urn:plcs:rdl:std:Approval_assignment_role)).

I am not sure that there is a requirement to use reference data to make a distinction between what is being approved. It is sufficient to just the Approval_assignment with no classification as specified in the templates.

Open issue Issue: RBN-8 by Rob Bodington (06-07-05) minor_technical issue
Resolution: Accept. Status: open

The description of the work order states that a work_order should be classified as a "Change_order" (urn:plcs:rdl:std:Change_order) - i.e. work order involves a configuration change Where are the capability states that Configuration_change should be used instead.

Open issue Issue: RBN-9 by Rob Bodington (06-07-05) minor_technical issue
Resolution: Accept. Status: open

The DEX states that the issue date of the work order is represented by classifying the date assignment by Work_order_issue_date. Is it appropriate for sub classify the dates according to what they used for? Why not just use Date_actual_release? This provides a more generic solution.