Estimation and Measurement Telecon, 2010-01-15

See Weekly Meeting Logistics for telecon information.

Previous telecon 2010-01-08

Next telecon 2010-01-22

Attendees

AndyBerner, ArthurRyman, DaveJohnson, LawrencePutnamJr, LeeFischman

Regrets

ScottBosworth

Minutes

0. Introductions

DaveJohnson joined us today. He is replacing SteveAbrams

1. Implementation Status - all

ArthurRyman: IBM is implementing a prototype of an EMS 1.0 service provider. It is being built on the Jazz Foundation Server. So far, no show-stoppers. Our plan is to work for another two weeks. That should give us enough feedback about the implementability of the specification.

LawrencePutnamJr: Please clarify who is implementing the service provider. Is this the software estimation tools or the PPM tools?

ArthurRyman: The spec is written from an architectural point of view in which the service provider, e.g. MetricServer, is a separate product. In reality, the service provider would probably be integrated with the software estimation tools or the PPM tools or both. The service is simply a middleman that enables all the other tools to collaborate. The service doesn't know how to estimate or manage projects. The service simply defines a set of resource types and their formats, and provides a REST API for accessing them.

The scenarios we have developed for the Primer illustrate how the various tools might use the service. However, the spec does not dictate what other tools do with the resources they get from the service. For example, PFGenious is a portfolio management tool, e.g. like Rational Focal Point, and would be interested in the estimates to understand the cost and risk of the project. TaskPhocus is a project management tools, e.g. like Rational Project Conductor or Rational Team Concert, and would be interested in the estimates to track progress. Guestimator 101 is a software estimation tool, e.g. like QSM SLIM or Galorath SEER, and would be interested in the scenarios and measurements in order to estimate, reestimate, and calibrate.

It is very desirable for tools to be able to be used in many configurations and combinations with other tools. The goal of EMS 1.0 is to provide a REST API that reduces the cost of integration. If a tool becomes an EMS 1.0 service consumer, then it can collaborate with any other tools that are also EMS 1.0 service consumers. The EMS 1.0 service provider simply enables the collaboration.

We should not discuss specific product plans here. However, I think it's OK to say that it would make sense for a suite of PPM tools to be EMS 1.0 service consurmers to include a shared EMS 1.0 service provider. Similarly, it would also make sense for software estimation tools to be both consumers and providers. This allows both sets of tools to be used in other configurations. It is definitely a goal of OSLC in general to produce specs that are readily implementable in a variety of technologies.

This leaves open the question of what happens when you have more than one EMS 1.0 service provider, e.g. one from the PPM vendor and another one from the software estimation tool vendor. The only EMS 1.0 restriction in this situation is that all the resources related to one project must be created in the same service. However, different projects could be created in different services. So technically, the services could coexist. In practice, customers like to reduce their server administration burden, so it is likely that a given customer would just use one service for their organization.

I'd also like to point out that implementing an EMS 1.0 service provider includes providing other capabilities that we are not going to spell out in the EMS 1.0 spec. These include administration, authentication, access control, etc. Customers may base their decision on which EMS 1.0 service provider to use in production on how well it fits in with their general server architecture. For example, a Jazz shop may prefer a Jazz service whereas a .NET shop may prefer a .NET service. It is therefore beneficial to how a wide variety of service provider implementations since that would enable the use of the service consumers in more environments. The service consumers are technology neutral.

LawrencePutnamJr: The Primer examples use simple numeric metrics. We believe it is also useful for software estimation tools to generate work breakdown structures (WBS). Should we define a REST API on the PPM tools to allow software estimation tools to create WBS in them?

ArthurRyman: Agreed, WBS are useful. The Primer is using the numeric metric examples for simplicity. We should now move on to more realistic examples, like WBS.

However, it is not in the scope of the EMS 1.0 spec to define the interfaces on the PPM tools. It is within the scope of our parent Software Project Management topic area to define those interfaces. IBM proposed this Estimation and Measurement workgroup as a starting point since we thought it was very important to integrate estimation tools. We anticipate additional workgroups to define other PPM APIs. For the purposes of EMS 1.0, we can suggest what PPM tools and estimation tools should do with the resources. By delegating the detailed behavior to the responsible tool, we in fact simplify life for the other tools. Each tool only has to learn how to interact with the EMS 1.0 service provider.

2. Primer Status - ArthurRyman

ArthurRyman began the review of Act 3. Execution of the Monitoring and Controlling scenario.

LawrencePutnamJr: The scenario shows a request for defect arrival rate, but that is a core metric that would be estimated initially for the portfolio management tool. That is how SLIM works. It generates all the core metrics.

ArthurRyman: The purpose of this scenario to demonstrate how the project manager might request additional estimates for KPIs that were not present in the initial estimate. I agree that our spec can suggest best practices such as which metrics are the most valuable to estimate, but we cannot dictate that.

If you'd like us to change the metric used in this example pls suggest another one. For example, test coverage, build frequency, etc. might be useful process indicators.

3. WBS Scenarios and Requirements Discussion - all

Timed out here. Defer this to next week.

4. Other Business

None.

Comments

Add your comments here: