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: Re: [oslc-ccm] Chanage management types and properties

Feedback included inline below...

Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> 

> From: Samuel Padgett/Durham/IBM@IBMUS
> To: oslc-ccm@lists.oasis-open.org
> Date: 03/12/2014 09:56 AM
> Subject: [oslc-ccm] Chanage management types and properties
> Sent by: <oslc-ccm@lists.oasis-open.org>
> I've asked Nick to add a topic to tomorrow's CCM call to discuss the 
> following questions on change management types. I thought I'd weigh in 
> before the meeting to start the discussion.
> 1. Should we have a common parent ChangeRequest that other types 
> I propose we don't. For one, the Task and ReviewTask types are not 
> necessarily change requests. We could call it something else, but what 
> that be? Second, it's not clear to me what the value really is. You can 
> infer that a defect is a change request if it's a subclass, but I'm not 
> what use case that supports.
> Considering backwards compatibility: providers can declare resources 
> both the new 3.0 type and the 2.0 change request type for compatibility 
> 2.0 consumers. If we make the new types sublasses of change request, 
what is
> the impact?


I think it doesn't make sense to bake the "is a" hierarchy requirement. 
Instead implementations can simply multi-type their resources wherever it 
makes sense.

> 2. Should we have a list of common properties for all types or define 
> properties for each type?
> I suggest we have one list of common change management properties. Most 
> types have the same properties with only a few that might be specific to 
> type (like severity for defect). You can see this when you look at our 
> spreadsheet that catalogs the properties in real change management 
> https://docs.google.com/spreadsheet/ccc?
> key=0AsgaoPBj7epTdGotZjBsY19HZTJrS3dZRDJHbExQSlE&hl=en#gid=0


Follows DRY principles (Don't Repeat Yourself), even if Resource Shapes do 
not support this type of reuse today.  I have given that as a use case for 
future Resource Shape development.

> For context, here is the list of the proposed types from the contributed 

> draft 3.0 change management specification:
> ### Resource: Defect
> A software or product defect. Used by QM tools to report defects in 
> * **Name:** `Defect`
> * **Type URI** `http://open-services.net/ns/cm#Defect`
> ### Resource: Enhancement
> A request for new functionality.
> * **Name:** `Enhancement`
> * **Type URI** `http://open-services.net/ns/cm#Enhancement`
> ### Resource: ReviewTask
> A request to make a changes and review the change. A review task can be 
> by RM tools [to request and approve changes to requirements](
> services.net/wiki/change-management/Change-Management-of-Requirements/), 
> it might be used by QM tools to review test plans and test cases.
> * **Name:** `ReviewTask`
> * **Type URI** `http://open-services.net/ns/cm#ReviewTask`
> ### Resource: Task
> An executable and trackable activity. Tasks can be used in many context. 
> QM tool that create tasks to write test plans and test cases is one 
> * **Name:** `Task`
> * **Type URI** `http://open-services.net/ns/cm#Task`
> -- 
> Samuel Padgett | IBM Rational | spadgett@us.ibm.com
> Eclipse Lyo: Enabling tool integration with OSLC

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