[OSLC-Metrics] You can?t GET the EstimationAssumptions from an OSLC Service

Fri Sep 25 09:09:17 EDT 2009

This is helpful!   The distinction you make is a good one.  Let me comment 
on each but this isn't the end of the story I don't think. 

1.  I agree that the Scenario--that is the inputs that form the basis for 
a particular estimate--will likely be a combination of machine 
understandable information (pick lists, numeric values for particular 
types of things, URL's perhaps) and free-form text (maybe, but let's 
assume that for now.)  And I agree that ultimately there should be a 
resource description of this.  (I'll explain "ultimately" in a second). 
But I don't agree that the estimation tool gets this in advance.  The 
estimator puts together the scenario in the estimation tool based on 
information from a variety of sources chosen based on the proprietary 
model of the particular estimation tool in use.  Then it is used by the 
estimation tool for the computation.  The scenario is "owned" by the 
estimation tool, so there's no GET from the portfolio management tool to 
start the process--that's the change to the primer I was writing about. 
For archiving/audit purposes, the estimation tool must be able to produce 
the scenario at a later time (i.e. answer "what did you use to derive the 
estimate") so the estimation tool must keep history.  The estimation 
vendors in the workgroup said they do this in their tools.  It may not be 
currently available through a REST interface, but it is obviously 
available in ways their customers are satisfied with.  That's why I said 
"ultimately"---ultimately, the spirit of OSLC says it should be available 
through a REST interface, but the estimation tools providing their own 
data through REST was not in scope of V1.   (Note that it would be great 
if the various OSLC interfaces to the various ALM tools including 
project/portfolio mangement could provide a lot of the data each vendor 
needs!!!  But since that's proprietary to the vendor, it cannot be defined 
as a specific OSLC call.)

2.  I agree there's no restriction on the people involved--I expect more 
people than the portfolio manager and the estimator are 
involved---architect, business analyst/business stakeholders (for 
priorities if that's not available from the portfolio manager), quality 
manager etc.  Also, data is gathered from whatever system holds history 
(but what data???)   But the work to gather the information from these 
folks is coordinated in the estimation tool--again, cause what's needed in 
specifics is proprietary.

The heart of what I'm saying is that the estimation tool is more than just 
the engine that does the computation--it's also the tool that in this case 
has the UI and stores the data, so it doesn't GET the scenario from 
another tool.  It would be very valuable if there are interfaces to other 
tools (plural) so that each estimation vendor can use OSLC can get pieces 
that vendor's tool needs electronically from other ALM tools.

We'll face a similar issue when we talk about the Project Control use case 
(which unless it was on some calls I missed, we haven't yet discussed), 
with the issue of gathering actuals.

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

Re: [OSLC-Metrics] You can?t GET the EstimationAssumptions from an OSLC 
Service 

Arthur Ryman 
to:
oslc-metrics, Andrew J Berner
09/25/2009 07:35 AM

Andy,

I think there are 2 issues here which may be getting confused.

1. Can we represent the Scenarios to be estimated in a 
machine-understandable way or is this purely free-form text?

2. Where do the Scenarios come from - the portfolio mgr, the project mgr, 
or the estimator?

For #1 - I believe we did agree that the information that defines a 
Scenario is a combination of machie-understandable and 
human-understandable information. In any case, it is important to have 
Scenario resources that describe the assumptions that an estimate is based 
on.

For #2 - there is no restriction on who creates the assumptions. I think 
another valid use case is as follows:

1. portfolio manager creates Scenario1 and requests an estimate
2. estimator performs the estimate but Scenario1 is not feasible
3. estimator creates Scenario2 and estimates that
4. portfolio manager adopts Scenario2

Arthur Ryman, IBM DE
Chief Architect, Rational Project and Portfolio Management
Office: 905-413-3077, Cell: 416-939-5063
Assistant: Nancy Barnes, 905-413-4182 

Arthur Ryman/Toronto/IBM at IBMCA 
Sent by: oslc-metrics-bounces at open-services.net
09/24/2009 07:00 PM

To
Andrew J Berner <ajberner at us.ibm.com>
cc
oslc-metrics at open-services.net, oslc-metrics-bounces at open-services.net
Subject
Re: [OSLC-Metrics] You can?t GET the EstimationAssumptions from an OSLC 
Service

Andy, 

I'll add this to the agenda for tomorrow. 

Arthur Ryman, IBM DE
Chief Architect, Rational Project and Portfolio Management
Office: 905-413-3077, Cell: 416-939-5063
Assistant: Nancy Barnes, 905-413-4182 

Andrew J Berner/Dallas/IBM at IBMUS 
09/24/2009 05:34 PM 

To
Arthur Ryman <ryman at ca.ibm.com> 
cc
oslc-metrics at open-services.net, oslc-metrics-bounces at open-services.net 
Subject
Re: [OSLC-Metrics] You can?t GET the EstimationAssumptions from an OSLC 
ServiceLink

We did not agree on this.  We agreed to put off the discussion in the 
interest of looking at the rest of the primer, and we never got back to 
it.   The change in name doesn't affect my issues, which are that 
gathering the inputs to the estimate is done in the estimation tool, and 
consists of feeds from multiple other tools (one of which is the portfolio 
management tool) plus discussions, interpretations, and other means the 
estimator uses to get the inputs SPECIFIC to a particular estimation tool. 
 What one estimation suite needs and where it gets it is different from 
another, so the portfolio management tool cannot have this "packaged up" 
as a resource. 

So rather than the estimation tool GETting the inputs, after all the work 
is done in the estimation tool, the estimation tool could POST the inputs 
for baselining purposes (in which case the fact that it's different for 
different estimation tools is OK), attached to the results and altogether 
that combination of inputs (call it Scenario if you wish) and outputs is 
the Estimation Run (in the terms of the data model).   There is a very 
interesting question, then--when the portfolio manager sees the results of 
multiple estimates (which is what I describe in my revision to the 
primer), what aspects of the Scenario (i.e. what inputs) is of interest so 
the portfolio manager can understand what she's choosing from?  Whether 
this last question affects the spec also is interesting:  does the 
estimation tool select which inputs are of interest, or does it just post 
them all, and the portfolio management tool chooses what to do with that? 

I'm not sure where in our discussions we address issues like this; I 
understand better what the primer is for, and maybe it doesn't go there, 
but it needs to be discussed in order to decide what's useful in the spec. 

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 

Re: [OSLC-Metrics] You can?t GET the EstimationAssumptions from an OSLC 
Service

Arthur Ryman 
to: 
Andrew J Berner 
09/24/2009 03:46 PM

Cc: 
oslc-metrics, oslc-metrics-bounces

Andy, 

I don't understand your Subject. You certainly can GET this data. It's a 
web resource. 

We discussed this topic previously and agreed that the assumptions were a 
mixture of structured and free-form information, including links to other 
documents or web resources. 

We also agreed last week that a better name for this resource is Scenario. 
There will in general be several Scenarios that represent alternate modes 
of executing the project. Each Scenario may be estimated by one or more 
tools. Based on the estimates, the project will adopt one Scenario as the 
way to execute the project. This occurs at Initiation and at Reestimation. 
The Scenario assumptions and the Estimates based on them will get 
baselined. 

Arthur Ryman, IBM DE
Chief Architect, Rational Project and Portfolio Management
Office: 905-413-3077, Cell: 416-939-5063
Assistant: Nancy Barnes, 905-413-4182 
Andrew J Berner <ajberner at us.ibm.com> 
Sent by: oslc-metrics-bounces at open-services.net 
09/19/2009 07:55 AM 

To
oslc-metrics at open-services.net 
cc

Subject
[OSLC-Metrics] You can?t GET the EstimationAssumptions from an OSLC 
Service

A question I raised about the Project Initiation primer a while back may 
have gotten lost and may be the reason we weren?t ?on the same page? in 
our discussion of my edits yesterday.  The primer simplies the situation 
by saying (in the sequence diagram, the XML, and the text) that the 
estimation suite GETS an XML representation of EstimationAssumptions from 
the Portfolio Management tool.  I disagree with that, and I wrote why on 
the Wiki ( 
http://open-services.net/bin/view/Main/MetricsEMS10PrimerInitiating?sortcol=table;up=#Comments 
) . 

At the time, Scott Bosworth suggested it may be worth while to see if some 
of the estimation assumptions can come through individual GET calls to the 
PPM tools, and the answer to that is almost certainly yes.  But that?s 
complicated too, because different estimation vendors need different 
information.  If we had a full API to the Portfolio Management tool, then 
each estimation vendor could GET what ever it needs that happens to be in 
the PPM tool.   So we can refine the question: ?Are there some of the 
estimation assumptions that are common to multiple estimation tools that 
can come through GET calls to the PPM tools?  The answer to that is also 
almost certainly ?yes?, and perhaps we can attack those and include them 
in the V1 spec we?re defining.   Some are easy, for example, schedule 
constraints (?the project can take no more than 6 months?).  Automating 
GETting that, rather than the estimator typing it based on looking at the 
PPM UI, is a ?nice to have?.  So where could there be more compelling 
value in automating GETTING info from PPM (or, equivalently PPM Posting it 
somewhere the estimation tool can get at)? The hard issues are size and 
the various parameters that affect productivity.  The latter is I believe, 
the most varied between the estimation tools (maybe not, and we can try to 
discuss and find out).  So I focused on ?size?, which, if I understand 
what I?ve learned from Larry and Lee and other sources, is the hardest 
input to come by.  And unlike ?schedule? which is sometimes a constraint, 
size is ALWAYS a key input, thus there would be value in automating it. 

That was my goal in the discussion of ?scope vs. size?.  I fundamentally 
believe the estimation tool needs ?size? and the PPM tool has ?scope?, so 
the question becomes ?what can be in the OSLC interface to help 
communicate scope in a way that can be translated to size through 
automation.?  That would be valuable. 

Maybe it doesn?t go in the Primer and should be documented elsewhere, but 
it?s a question worth discussing in detail, or else put out of scope for 
V1, in which case I don?t think there?s much left about ?estimation 
assumptions? that can profitably go into V1. 

We had a start on this:  Larry suggested (based on my question, so that 
also biases it) that a list of high level business requirements, under any 
of the usual guises as ?Business Needs? (the Focal Point term), or ?Epics? 
(the Scrum term) or ?Features? (the RUP term) or whatever term you want, 
qualified by some measure of complexity and priority, would be a good 
input for getting comparative (I assume) size.  Lee didn?t disagree (but 
I?m not convinced Lee actually agreed and we didn?t have time left to 
discuss in depth).  Since I?m an amateur at formal estimation, it sounded 
good to me.   

Is that good enough to be put into the V1 spec as a ?SCOPE? resource 
sub-resource of the project, and the estimation tool can automate GETting 
that scope information from the PPM tool through OSLC? 

One further note:  There is in fact a need to package up the ?estimation 
assumptions? used actually used by the estimation tool in a particular 
estimation run for archiving/auditing purposes, and this has always been 
in Arthur's data model.  Organizations may be called upon, even years 
later, to justify why they planned the project the way they did.  This was 
discussed very early in our work, in fact at the initial live meeting in 
Lexington.  From what Larry and Lee said at that meeting, their estimation 
tools currently do this.  Maybe not in an ?OSLC? way, but good enough for 
customers right now.  So I don?t think this is worth being ?POSTED?  or 
GETTED? anywhere else in XML format as part of the V1 effort?eventually, 
maybe.  And it?s probably easy to do if we need to, because it?s just for 
?human readable? purposes as far as I know, assuming you consider 
compliance auditors human. 

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
_______________________________________________
OSLC-Metrics mailing list
OSLC-Metrics at open-services.net
http://open-services.net/mailman/listinfo/oslc-metrics_open-services.net
_______________________________________________
OSLC-Metrics mailing list
OSLC-Metrics at open-services.net
http://open-services.net/mailman/listinfo/oslc-metrics_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-metrics_open-services.net/attachments/20090925/5122bb91/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 821 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-metrics_open-services.net/attachments/20090925/5122bb91/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 821 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-metrics_open-services.net/attachments/20090925/5122bb91/attachment-0001.gif>