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

[Andrew J Berner]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-metrics_open-services.net/attachments/20090919/6cc355bb/attachment-0003.html>