Estimation Telecon, 2009-07-17

Attendees

AndyBerner, ArthurRyman, LawrencePutnamJr, ScottBosworth, SteveAbrams

Minutes

1. Review working draft of EMS 1.0 Part 0: Primer - Arthur

Provider/Consumer Architecture in EMS 1.0

We discussed the architecture of the EMS 1.0 spec, which is that the PPM tools are service providers and the software estimation tools are service consumers. We need to make this more apparent.

We also discussed where and how resources are stored, and agreed that this is a separate concern from their representation. The data model is expressed as a collection of RDF triples which express relations bewteen resources. The resource URIs may be managed by a set of one or more servers. Statements about how long resources persist, whether they are copied, etc. go beyond the data model and need to be included in the service description where appropriate.

[ ACTION ] ArthurRyman to describe the architecture in an Architecture section near the beginning of the Primer. DONE

Explicit Collections in Resource Design

ArthurRyman initially used explicit collection resources, e.g. a Project has an EstimationAssumptionsCollection? which has EstimateAssumptions? members. This is clean and uniform, but leads to extra levels of indirection and deeply nested XML (when resources are inlined in RDF/XML). ArthurRyman used a simplified approach in the Primer examples, i.e. a Project contains zero or more EstimationAssumptions? members. This makes the XML more compact and readable.

SteveAbrams remarked that CM used explicit collections and that we should review the situation across the OSLC workgroups and define some best practices to achieve consistency across the spec.

[ ACTION ] SteveAbrams to add this topic to the OSLC Leads Meeting this Monday, 11:00AM EST. DONE

[ ACTION ] ArthurRyman to provide EMS examples. DONE

[ ACTION ] SteveAbrams to ask SteveSpeicher for CM examples.

Investment Risk

We reviewed the section on Investment Risk which introduced representations of probability distributions using TriangularDistribution? and QuantileFunction? resource types. LawrencePutnamJr agreed that QuantileFunction? was a good way to express estimates. The ability to control the level of detail in a QuantileFunction? by specifying the numberOfQuantiles property was consider to be very useful. Typically, the number of quantiles would be 10, i.e. deciles.

Getting Estimation Assumptions Automatically

AndyBerner posted comments expressing concern about the utility of trying to automate the collection of inputs to estimates. He had two concerns. First, the types of input vary between estimation tool vendors and models. Second, many assumptions are expressed in free form text and are attached to requirements and project plans, e.g. in a Project Vision document.

We agreed that although there were many differences between what vendors used as inputs, there were some widely used inputs, e.g. size, and it is useful to specify how to represent these in a machine-processible way.

We also agreed that the estimator would have access to other sources of text information. The estimation assumptions for a project could contain links to other documents, requirements, etc.

We discussed the workflow, i.e. how assumptions get created and used. The Primer describes the scenario where the assumptions are included in the the project proposal. However, it is equally possible that the estimator could define other assumptions for use in estimating alternate modes of running the project. The estimation tool could add these new assumptions to the project.

Next Steps

The description of the Initiating use case in the Primer is now complete. Next step is to add the Re-estimating use case to the Primer.

[ ACTION ] ArthurRyman to add the Reestimating use case to the Primer. DONE - page created and outline completed

2. Reestimating use case - Andy

Not covered.

3. Other Business - All

None.

Comments

Add your comments here: