oslc-ccm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-ccm] Feedback on change management
- From: "Jim Amsden" <jamsden@us.ibm.com>
- To: "OSLC CCM TC (oslc-ccm@lists.oasis-open.org)" <oslc-ccm@lists.oasis-open.org>
- Date: Tue, 28 Jun 2016 17:08:57 -0400
Martin,
Excellent points, all, thanks. On a
quick read, items 1-5 could be included in the CM specification, but might
be better handled as vendor-specific extensions. The CM domain specification
is intended to capture common vocabulary terms to foster interoperability
and integration. The points you raise below may be considered to be specific
to a particular change management approach of which there is much variability.
I suggest we look at these in the TC meeting and discuss which ones reflect
common CM approaches that could be incorporated into the domain specification,
and consider others as useful extensions.
Regarding your incidental items, there
are a number of significant issues raised regarding oslc_cm:state that
we need to discuss that will likely address these issues.
Looks like we've got some good CM agenda
items to discuss.
Jim Amsden, Senior Technical Staff Member
OSLC and Linked Lifecycle Data
919-525-6575
From:
"Sarabura, Martin"
<msarabura@ptc.com>
To:
"OSLC CCM TC (oslc-ccm@lists.oasis-open.org)"
<oslc-ccm@lists.oasis-open.org>
Date:
06/28/2016 12:37 PM
Subject:
[oslc-ccm] Feedback
on change management
Sent by:
<oslc-ccm@lists.oasis-open.org>
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
|
Dr.
Martin Sarabura Technical Fellow
+1 519.502.4819 msarabura@ptc.com
ptc.com |
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]