Estimation and Measurement Telecon, 2010-04-23

See Weekly Meeting Logistics for telecon information.

Previous telecon 2010-04-16

Next telecon 2010-04-30

Attendees

AndyBerner, AndrewCanham, ArthurRyman, LawrenceMandel

Regrets

LeeFischman

Minutes

1. Implementation Status - All

LawrenceMandel has found a potentially applicable vocabulary for project life cycles. He will investigate further and post his findings to the mailing list.

2. Review of REST API Data Models - ArthurRyman

ems:Scenario

We had a long discussion on how changes in a scenario would impact estimates based on them. For example, is an estimate is created and later the scenario gets modified, then the estimate may become invalid. In general, when one web resource depends on another web resource, they may get out of synch.

The resolution of this issue is that the spec should make clear that any reference of an estimate (or any other resource) to a scenario (or any other resource) implicitly refers to a specific revision of the scenario. The applicable revision is that which is the current revision at the time the referring resource is created or modified. The revision history and audit trail for all resources is assumed to be implementation-dependent and not specified in EMS 1.0.

An implementation should maintain a revision history for each resource. It should be possible to get a list of revision numbers and their timestamps for any resource. To determine the revision of, say, a scenario that was used by an estimate, look at the creation date of the estimate and find the revision of the scenario that was the current revision at that time. This applies to the ems:scenario property of ems:Estimate, the ems:extendsScenario property of ems:Scenario, and most of the properties of ems:Baseline.

ACTION: ArthurRyman will add notes to the spec explaining that references are implicitly to the revisions in effect at the time the reference is created. DONE

ems:Baseline

The main issue here is the integrity constraint that relates the adopted scenario and the adopted estimates. We agreed to modify this constraint to allow more flexibility that naturally arises with the addition of the ems:extendsScenario. The ems:extendsScenario property is like a hasParent property. We relax the constraint to require only that each adopted estimate have the adopted scenario as an ancestor.

ACTION: ArthurRyman will update the constraint on estimates and scenarios in baseline: each adopted estimate must have the adopted scenario as an ancestor DONE

Comments

Add your comments here: