-
Type:
Improvement
-
Status: Closed
-
Priority:
Major
-
Resolution: Unresolved
-
Labels:None
-
Resolution:
There are 2 different level of scenarios raised during meeting on April, 22.
- Simple change log
- Transactional change (baseline, change-set)
We have to define our scenario and model for PROMCODE.
There are candidate external definitions for each scenario: - TRS for simple change log
- Configuration Management for transactional change
One scenario:
1. At the status meeting in a project team, check the status of progress and quality.
- Take a snapshot including all items.
- Check actual end date of each Work Item, result of Measurement, and Issues status.
- See differences between the latest and previous snapshot.
- If necessary, update planned start and end date of Work Items
2. At the meeting with stakeholders (customers), check the status with the latest snapshot, - If necessary, update (remove, add, change) Scope Items and related items.
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Hiroyuki Yoshida [ yuki.yoshida ] |
In the meeting on May 7, we have discussed about Change
- Change is common notion among any resources though PROMCODE has unique for contract between supplier and customer like SOW (Statement of Work)
- We should focus on the core model of project management for software contract
- It seems we can utilize OSLC Configuration Management as optional to manage the changes in PROMCODE
The conclusion at the time was that we should remove the Change from initial model of PROMCODE.
Yoshida-san will remove the Change from the spec.
I've just uploaded a revised version of domain model.
https://www.oasis-open.org/apps/org/workgroup/oslc-promcode/download.php/53099/PROMCODE%20Domain%20Model%2020140521.pptx
Changes are:
1. remove "Change" and related links
2. rename the link between Measurement and Measure as "observes" from "has"
In addition to out discussion in the meeting on May 7, the reason I think why we should remove "Change" from our domain model is as follows.
In the model of our base document, a Change represents a relation between superseded and superseding ManagedItems.
But in our scenarios, most typical changes of ManagedItems are changes of their properties, not replacements by another ManagedItems.
Changes of ManagedItems should be managed by versions of each item and configurations of them which is the way we expect the CCM Specification will provide.
(This issue may be closed now.)
Model has been updated by Yoshida-san.
We all have agreed the new model, so I close this issue.
| Resolution | Removed Change resource from the model. We will look into configuration management specification. | |
| Status | New [ 10000 ] | Closed [ 6 ] |
References:
Tracked Resource Set (TRS) specification: http://open-services.net/wiki/core/TrackedResourceSet-2.0/
OASIS OSLC Configuration Management TC: https://wiki.oasis-open.org/oslc-ccm/