This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

Estimation and Measurement Telecon, 2010-01-22

See Weekly Meeting Logistics for telecon information.

Previous telecon 2010-01-15

Next telecon 2010-01-29

Attendees

AndyBerner, ArthurRyman, DaveJohnson, LawrencePutnamJr, LeeFischman

Regrets

ScottBosworth has a new workgroup in this timeslot.

Minutes

1. Implementation Status - all

ArthurRyman - Rational is prototyping the spec usng the Jazz Foundation SDK. Nothing difficult to implement so far, except for the use of nested properties in the proposed OSLC simple query syntax which is not natively supported by the SDK. It should be not too much effort to exhance the parser.

2. Primer Status - ArthurRyman

ArthurRyman began the review of Act 3. Execution of the Monitoring and Controlling but we did not finish this.

ACTION: Everyone should review Act 3 and post comments to the mailing list.

DONE 2010-01-29. No issues raised.

3. WBS Scenarios and Requirements Discussion - all

We did not review Work Breakdown Structures.

ACTION: Everyone should review the WBS discussion and post comments to the mailing list.

DEFERRED until the REST API spec is drafted.

4. Other Business

There was a general consensus that the Primer had enough content to enable us to proceed with the nomative EMS 1.0 spec. We'll defer elaboration of the remaining scenarios.

ACTION: ArthurRyman to edit the main EMS 1.0 spec, adding descriptions of all the anticipated properties.

STARTED.

LeeFischman suggested that we only have telecons as required, and make more use of the mailing list. No objections. We will have a telecon next week.

ArthurRyman discussed the relation of the resources in the EMS 1.0 service to other project-related resources. Projects are complex real-world entities and have many aspects. The EMS 1.0 service only manages the resources related to the estimation and measurement aspects of the project. Other services will manage other aspects, e.g. portfolio management, project management, requirements management, etc. Each service may store links to related resources. In addition, we should introduce a common project name property, e.g. oslc:project, to tie these together. The value of this property is a URI that is used to identify the project. The EMS 1.0 spec will define properties to link an ems:Project resource to its associated project resources in closely-related services, e.g. ems:portfolioProject, ems:workProject.

AndyBerner expressed concern that the Scenario and Estimate resources were not clearly defined and distinguishable. Do we need both? The intension was that a given Scenario may have multiple estimates, e.g. from different estimation tools.

ACTION: AndyBerner will clarifiy his concerns about Scenario versus Estimate and post his comments on the mailing list.

DONE 2010-01-29.

Comments

Add your comments here:

 
Topic revision: r5 - 02 Feb 2010 - 13:52:39 - ArthurRyman
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback