OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-ccm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Feedback on change management

Jim and Nick, I asked my in-house experts to review the change management spec to see if there would be any discrepancies between the spec and our PTC implementations. For the most part the model fit with our models. What follows are notes regarding the differences.


1. We have a notion of a "Change Notice" which is typically created by a review board based on an earlier change request. The change notice serves two purposes: It authorizes tasks and is the container for the tasks. The Types allowed by the spec do not seem to have an equivalent concept as our change notice.


2. We model the change management process as a waterfall, with problem reports leading to change requests leading to change notices leading to tasks. (Certain tasks can be created at all points, which I will discuss in the next point). Each step down the chain is affected by what came before it. To model these dependencies I assume the "affectsPlanItem" relationship can be used: A problem report (either a defect or an enhancement) is related to a change request via affectsPlanItem, and so on down the chain. I have a couple of issues with this:

a) affectsPlanItem is rather vague and if it is a reference to the abstract base class ChangeRequest then why not call it affectsChangeRequest? In fact, is the intention to reference this abstract class at all or is the specific type ChangeRequest mentioned because it really is supposed to refer to Change Requests? Some guidance around this relationship is probably a good idea. The description is vague and Range is unspecified.

b) OSLC references are uni-directional and having the upstream artifact reference the downstream artifact via affectsPlanItem is appropriate. But if so, then what is the purpose of affectedByDefect? This seems to be pointing in the opposite direction - that is, from the change request backwards to the defect which spawned it. Is there any need for affectedByDefect at all?


3. We have three types of task: Workflow, Change and Review. 

- Workflow tasks include the creation of other tasks, creation of change notices from change requests, and so on. They can be created at any point in the waterfall.

- Change tasks affect work products such as tests, requirements, documents, models and source code. They are attached to change notices only.

- Review tasks can also be created at any point in the waterfall but most often are related to change tasks.


Tasks may have references to the affected resource and the resultant - like "before" and "after" pictures. The tracksChangeSet relationship does not model this adequately. There may be more than one change set, and the original and final views can be inferred only (with some difficulty) from the references.

4. Tasks may be ordered on the parent. We would need to have an ordinal to model this correctly. Of course we could indicate that adding an ordinal is a reasonable extension of the spec but I think it is significant enough that it should be mentioned in a normative section of the document.


5. We have quite a few more states than those listed in section 3.6 - and our customers may have even more yet. For example, "In Review", "Rejected", "Duplicate", "Cancelled", etc. I think we should at least have a non-normative section indicating that extensions are likely; perhaps we should add a few more states to the normative section?



Other things I noticed that are incidental to our review but worth mentioning:

1. The description of oslc_cm:state is Used to indicate the state of the change request. This property is read-only, but could be changed using OSLC Actions. Since the Actions TC is currently suspended perhaps it may be better to reference the section of Core docs that talks about using "other means" to change values when the spec says the value is read-only.


2. oslc_cm:state; section 3.6 refers to Status but the term used everywhere else is State.


3. I'd appreciate if we could improve the resolution of the UML diagram in the vocabulary document.


4. Section 2.1.18 of vocabularity typo "sererity" instead of "severity"


5. The UML diagram in vocabulary says that oslc_cm:tracksChangeSet references zero or more instances of oslc_scm:ChangeSet; the documentation says it references oslc_config:ChangeSet. I believe the latter is correct however oslc_config is not referenced anywhere in the document.


Regards, Martin




PTC Logo

Dr. Martin Sarabura
Technical Fellow

+1 519.502.4819




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]