[oslc-Metrics] Reminder: EMS 1.0 REST API Review Continues 2010-05-14

[Arthur Ryman]

Andy,

The NASA QUDT ontology really consists of two parts. The first part models 
the concepts involved in measurement systems. There are a small number of 
these URIs. The second part instantiates these concepts for specific 
measurement systems like SI or ISO currencies. There are a large number of 
these URIs.

In our spec, we are mainly describing a concrete set of metrics, which is 
like defining a new measurement system. We could describe this using the 
QUDT model. Then customers would have a clean and semantic way to extend 
it. I'll dig more into QUDT to see how complex doing this is. 

I see this use of QUDT as an optional aspect of the EMS spec, i.e. we 
don't require the EMS service to do anything meaningful with the QUDT 
metadata since it currently treats all metric and unit URIs are opaque. 
However, a more sophisticated estimation tool certainly could do some 
useful things with the QUDT metadata, e.g. perform semantically correct 
conversions between compatible units. Our spec would define the basic 
units (like. metre, second, kilogram) and customers could define new units 
(like rod, fortnight, ton).

Regards, 
___________________________________________________________________________ 

Arthur Ryman, PhD, DE


Chief Architect, Project and Portfolio Management

IBM Software, Rational

Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube







From:
Andrew J Berner/Dallas/IBM at IBMUS
To:
Arthur Ryman <ryman at ca.ibm.com>
Cc:
oslc-metrics at open-services.net, larry_putnam_jr at qsm.com
Date:
05/14/2010 12:04 AM
Subject:
Re: [oslc-Metrics] Reminder: EMS 1.0 REST API Review Continues  2010-05-14


I see the agenda item about NASA having standard units of measure.  That's 
good, and I look forward to hearing about it.

But we may be putting too much emphasis on standard metrics and units.  I 
believe in most cases, size metrics will be custom, based on the project 
type and estimation tool model.

For example, I was recently involved in a meeting with Larry, showing how 
QSM deals with certain types of projects such as SAP customization, and 
the metrics that can be used for this   It's an example of how each 
customer, perhaps with some help from the tool vendor, will be setting up 
how they do measure size for particular situations.  There will be 
consistency within a customer organization---that's how the tool can get 
calibrated over time--but not necessarily from customer to customer and 
certainly not from tool to tool.  The standard metrics help when 
applicable, but we cannot expect one tool to understand the "child 
scenario" of another tool.  That's why "story points" or "ideal days" can 
be used as a measure of size:  while not standard across the industry (my 
5 story points don't equal your 5 story points), they can be calibrated 
within a particular organization to measure relative size.

Lee, you've given some talks about "normalizing"...I unfortunately 
couldn't come, but I suspect it's related: how the tool internally can 
translate whatever metric a customer uses to an standard (perhaps "ESLOC") 
that it can use to compare projects industry wide.  Do I have that at all 
right?

So again, lets indeed hear about the NASA standards, and they can be 
included in the spec to be used when appropriate, but the spec can't in 
any way depend on standardization of these metrics, nor expect that 
scenarios for one tool can be transferred to another. 

Andy Berner
Lead Architect, ISV Technical Enablement and Strategy
IBM Rational Business Development
972 561-6599
ajberner at us.ibm.com

Ready for IBM Rational software partner program - 
http://www.ibm.com/isv/rational/readyfor.html




From:
Arthur Ryman <ryman at ca.ibm.com>
To:
oslc-metrics at open-services.net
Date:
05/13/2010 10:44 PM
Subject:
[oslc-Metrics] Reminder: EMS 1.0 REST API Review Continues      2010-05-14
Sent by:
oslc-metrics-bounces at open-services.net



The agenda is posted at [1]

[1] http://open-services.net/bin/view/Main/MetricsMeeting20100514

Regards, 
___________________________________________________________________________ 


Arthur Ryman, PhD, DE


Chief Architect, Project and Portfolio Management

IBM Software, Rational

Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063
Twitter | Facebook | YouTube





_______________________________________________
Oslc-Metrics mailing list
Oslc-Metrics at open-services.net
http://open-services.net/mailman/listinfo/oslc-metrics_open-services.net