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

Thu Sep 24 17:34:15 EDT 2009

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-metrics_open-services.net/attachments/20090924/551844f6/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/20090924/551844f6/attachment.gif>