Estimation and Measurement Telecon, 2010-04-09

See Weekly Meeting Logistics for telecon information.

Previous telecon 2010-04-02

Next telecon 2010-04-16

Attendees

AndrewCanham, AndyBerner, ArthurRyman, LawrenceMandel, LeeFischman

Minutes

1. Implementation Status - All

LawrenceMandel has picked up the prototype previously development by Rational and will continue its development.

2. Review of REST API Data Models - ArthurRyman

We reviewed the following data models:

The Service Root

Domain Entity Lists

Domain Entity ems:Project

Baselining Across Subprojects

AndrewCanham: If a project has subprojects, how do you handled baselining across all the subprojects?

ArthurRyman: The EMS 1.0 spec does not provide a way to represent the project-subproject structure. It's limited to describing estimates and measurements for "atomic" projects, i.e. with opaque structure. The project-subproject structure would have to be handled by another tool, e.g. a project management tool, that was a consumer of the EMS 1.0 service. The consumer tool would use the EMS 1.0 REST API to individually baseline each of the subprojects in the master project.

The Meaning of ems:isClosed

ArthurRyman: This is not a lifecycle state since that information should be represented in measurements of the project. It is an indicator that the project has been closed from a data update viewpoint, and that calibration tools can use the project as a stable source of historical data.

Domain Entity ems:Scenario

Write-Once Properties

AndyBerner: The ems:project property is conceptually write-once. However, the spec says it's read-write in order to allow for error correction. There should be separate admin mechanisms for correctly errors. I think making it write-once would be appealing.

ArthurRyman: I agree, and this particular case was one of the motivations for defining write-once properties. However, people may want to correct errors without needing admin assistance. If this property was write-once, a user would have to delete the scenario and recreate it with the correct project reference. I'd like to poll the others about how they feel about making this property write-once.

• AndrewCanham - I prefer read-write
• LeeFischman - no preference
• LawrenceMandel - no preference

ArthurRyman: Since there is no strong preference to change this, let's revisit this after we complete the first pass of reviewing all the data models

Can Scenarios Span Projects?

LawrenceMandel: Can a scenario involve more than one project, e.g. doing a resource tradeoff between several projects?

ArthurRyman: No, a scenario represents an alternate way to run a single project. In your example, a portfolio management tool would have to create the alternate resource allocation scenarios for each project and manage their relations. For example, suppose you need to make a tradeoff between projects A and B. Create two scenarios for project, and title them "Accelerate A" and "Accelerate B". Similarly, create two scenarios for project B and title them the same way. Now the estimator does 4 estimates. The portofolio manager evaluates the estimates but groups the two "Accelerate A" estimates together and the two "Accelerate B" estimates together and then chooses either group.

The Meaning of ems:isActive

AndrewCanham: This property doesn't seem valuable since the user interface of a project management tool should send the list of scenarios to be estimated.

ArthurRyman: That is possible but it would require a richer user interface than the one we used in the Initiating a Project scenario in the Primer. In this scenari, the estimator just received the URL of the project to be estimated. The estimation tool then does a query on the scenario list to get all the scenarios defined for the project. The estimation tool would examine to the value of the ems:isActive property to determine if a given scenario was still being actively considered. Alternatively, the estimation tool could query the scenario list for just the active scenarios for the project. This would have the following syntax:

http://braintwistors.example.com/ems10/Scenario?oslc.where=ems:project{dc:identifier=4201} and ems:isActive=true 

AndyBerner: Is marking a scenario as inactive like doing a soft delete?

ArthurRyman: No, it may still be useful to retain inactive scenarios as a record of the decisions made in the project.

AndyBerner: Wouldn't you normally only have one active scenario?

ArthurRyman: No, since we expect projects to be periodically reestimated throughout their life. Suppose you initiate the project by considering three scenarios. Maybe one of them assumes a project duration of 6 months. Suppose 8 months have elapsed and you need to reestimate. You'd mark that 6 month scenario is inactive since there is no point in reestimating it. Now you have 2 active scenarios.You'd probable create more scenarios now to evaluate alternate ways of completing the project.

Next Steps

We'll continue with weekly reviews. Reviewers should read the data models and post questions to the mailing list.

Comments

Add your comments here: