[OSLC-Metrics] You can?t GET the EstimationAssumptions from an OSLC Service
Arthur Ryman
ryman at ca.ibm.com
Thu Sep 24 19:00:58 EDT 2009
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
Service
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/9bc65c9b/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/9bc65c9b/attachment.gif>
More information about the Oslc-Metrics
mailing list