Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionLast revisionBoth sides next revision | ||
78:dependentelements [2021/12/14 20:03] – emr | 78:dependentelements [2023/11/17 15:56] – [Behavior of readiness checks with work product states] ndn | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== States for Work Products ====== | ====== States for Work Products ====== | ||
+ | |||
+ | Work Product represents the artifact, outcome, or a deliverable created or consumed during the process. In the overall context of a process, a work product progresses through various states due to increased maturity or added content. This state change can happen within a workflow or through the course of different workflows during the product or program lifecycle. For example, a work product like ' | ||
+ | |||
+ | Similar to other modeled process elements, '' | ||
+ | ===== Create a work product state ===== | ||
+ | |||
+ | There are two ways to add a new state to a work product: | ||
+ | |||
+ | **1.** **Model them while modeling a work product as an input/ | ||
+ | |||
+ | Type in the name of a work product and click or tap on the right arrow next to the work product. | ||
+ | |||
+ | {{ https:// | ||
+ | |||
+ | Next type in the name of the state as shown in ** <font inherit/ | ||
+ | < | ||
+ | |||
+ | {{ https:// | ||
+ | |||
+ | **2. ****Model a list within a work product and reuse them in an activity or a workflow** | ||
+ | |||
+ | To add a set of states to a work product, navigate to that work product and click or tap on ' | ||
+ | |||
+ | {{https:// | ||
+ | |||
+ | **Note:** For consistent interpretation across the user base, it is recommended to provide a description of what this state means by clicking or tapping on three dots next to the newly added state as shown in** | ||
+ | < | ||
+ | |||
+ | {{ https:// | ||
+ | |||
+ | The work products states can also be created and assigned to work products through other process elements like '' | ||
+ | ===== Use a work product state ===== | ||
+ | |||
+ | Once the work product states have been created for a work product, they can be used and reused for any activity where the work product is an input or an output. For the work product, ' | ||
+ | |||
+ | {{ https:// | ||
+ | |||
+ | On clicking or tapping on the right arrow next to this work product, the modeler can then view all available states (draft, under review, and approved) for this work product to select one or even assign this work product as output without any state. | ||
+ | |||
+ | {{https:// | ||
+ | |||
+ | In this example, the modeler selects the ' | ||
+ | |||
+ | {{https:// | ||
+ | |||
+ | ===== ' | ||
+ | |||
+ | Modelers can continue using the commenting feature for work products. To add a comment, the modeler has to be click or tap on the three dots of a work product used as an output or an input and select 'Edit Comment' | ||
+ | |||
+ | **Note**: Once the comment has been entered, hit on return or Enter key of your touch screen/ | ||
+ | |||
+ | This comment is a free text field and is not reusable. Hence, any state updates to work products should not be added as a comment, but modeled using the work product '' | ||
+ | |||
+ | {{ https:// | ||
+ | |||
+ | Unlike commenting, state feature allows synchronization of a change (like renaming of state name) across Stages just like any other process element ('' | ||
+ | ===== Tailoring of a Work Product State ===== | ||
+ | |||
+ | Work Product states can be tailored in or out, like any other process element. This can be done by selecting specific states using the right arrow selection next to the work product. This tailoring allows further refinement of allowable states in a given project type. | ||
+ | |||
+ | {{ https:// | ||
===== Reporting API Extensions ===== | ===== Reporting API Extensions ===== | ||
Line 9: | Line 70: | ||
* '' | * '' | ||
* '' | * '' | ||
+ | ===== Behavior of readiness checks with work product states ===== | ||
+ | |||
+ | Process version readiness checks that check **association constraints** run **only on the work product** itself, not independently on each state. The input for an association constraint check will be the associations of the work product itself, merged with the associations of all states. For instance: | ||
+ | |||
+ | * "Each work product is an input to at least one activity": | ||
+ | |||
+ | The same behavior is also applied for association constraints of type " | ||
+ | |||
+ | * "Each activity must have exactly one responsible role": It is sufficient that the activity itself (or any step) has one responsible role. Different steps must not have different responsible roles. | ||