Estimation Telecon, 2009-04-21

See Estimation and Measurement Meetings for meeting logistics.

Agenda and Minutes

Attendees

ArthurRyman, LawrencePutnamJr, Jim Koslow, AndyBerner, PeterHaumer, StevePitschke, MurrayCantor, ScottBosworth, VikrantKaulgud, LeeFischman

1. Introductions

Since this is our first telecon, let's take a few minutes to introduce ourselves.

• Larry - QSM, interested in integrating QSM estimation tools with other develop tools, e.g. from IBM Rational
• Jim - Galorath, business alliance manager, also interested in integration
• Andy - IBM Rational lead architect for ISV enablement
• Peter - IBM Rational lead architect for Measured Capability Improvement Framework (MCIF), interested in control framework
• Steve - IBM Rational dev lead for integration of ISV estimation tools with new project management tool
• Murray - IBM Rational lead for Governance solution, member of CTO team
• Scott - IBM Rational lead for OSLC, member of CTO team
• Vikrant - Accenture, interested in project management, estimation, data mining of development tools
• Arthur - IBM Rational, chief architect for Project and Portfolio Management, will lead this workgroup initially
• Lee - Galorath, will act as point of contact for Galorath

Arthur is initiating this workgroup, but it should not be viewed as an IBM-run workgroup. Looking for co-leaders. Larry volunteered to co-lead.

2. Workgroup Goals

Let's discuss our goals and establish a plan for the workgroup.

The primary goal is to define services that enable the integration of estimation tools with other development tools in order to support the key use cases that have been identified and agreed to.

In general, service interfaces could be defined on both the estimation tools and the development tools. However, as an initial simplification, we'll adopt an architecture where the development tools provide the services and the estimation tools act as clients to those services.

Our target is to have initial implementations this year. However, the specifications may not be final. Product support statements are independent of the level of maturity of the specifications at OSLC, e.g. a product may elect to support a draft spec or may decline to support a final spec.

3. Use Case Prioritization

We have several use cases proposed. Are there more? Let's prioritize the list.

We reviewed the four use cases: Initiating, Monitoring and Controlling, Re-estimating, and Closing. There was general agreement that these were the main use cases.

During the discussion it became apparent that we should also include a Calibrating use case to bootstrap the models before they are used for new projects. Calibrating entails mining data for the historic project records of an organization.

ACTION: Arthur to add a use case for Calibrating. DONE 2009-04-21

Murray raised some additional use cases that dealt with an orginizations ability to use estimates, and to analyse their overall improvements over time across mulitple projects.

ACTION: Murray to add these additional uses cases for discussion at future telecons.

There was agreement that the Monitoring and Controlling use case be given the highest priority since the ability to control projects has high value. In order to proceed on this, we should gather information about which metrics are most useful. The following general categories were identified:

• size
• schedule
• effort
• defects

This leads into our next topic since we should adopt standard definitions for these metrics where they exist.

ACTION: Each estimation vendor should identify the most useful metrics for project control and record them on a wiki page.

There was some concern over using the wiki since many workgroup memberslack experience. In order to get over the learning curve, Arthur and Scott volunteered to provide 1-1 coaching. Arthur will create pages for each vendor.

ACTION: Arthur to create a software metrics page for each vendor. DONE 2009-04-21. See MetricsAccenture, MetricsGalorath, MetricsQSM, MetricsPriceSystems.

4. Applicable Standards

Are there any applicable standards we can use, e.g. to define metrics or project properties?

We need to all agree on the definition of software metrics since we are exchanging data. We should cite applicable standards if they exist, e.g. from IEEE or SEI. If no standard exists, we'll supply our own definitions here.

ACTION: Each estimation vendor should cite any applicable standards in their list of key software metrics.

5. Information Model

Arthur posted a draft information model to establish concepts. You can download it as a zip. See also MetricsModel.

Timed out here.

Next week

Expand the Monitoring and Controlling use case. What do estimation tool users do?

Comments

Add your comments here: