Estimation and Measurement Telecon, 2010-05-14

See Weekly Meeting Logistics for telecon information.

Previous telecon 2010-05-07

Next telecon TBD

Attendees

AndrewCanham, AndyBerner, ArthurRyman, LawrenceMandel

Minutes

1. Implementation Status - All

LawrenceMandel - I am currently developing the ems:Project resource implementation.

ArthurRyman - We should provide the partial implementation to the Reporting workgroup so they can use it for testing of the OSLC Reporting Specifications V1.0 which is currently in the Convergence phase.

2. Review of REST API Standard URIs - ArthurRyman

We continued the review of EMS 1.0 REST API Standard URIs.

ArthurRyman - I moved build metrics from productivity into reliablily since it measures the reliability of the build. However, it does not measure the reliability of the product so this is not a great fit.

AndrewCanham - I think build metrics are a better fit for productivity since they reflect the productivity of the team. However, the test metrics don't really measure team productivity, just the efficiency of the process.

ArthurRyman - I agree. I was attempting to fit all metrics in the five core metric categories, but this is not a good fit for process metrics. We can create another metric class for process metrics. They measure the development process. Productivity and reliability should only measure the end result, not the process, i.e. how fast was the product produced, how reliable is the product. Process metrics should measure the development process.

ACTION - ArthurRyman will create a process metric class and move build and test metrics into it

AndyBerner - As I stated in my recent email, customers will often use custom metrics for size. Can we provide a mechanism for them to define associated metrics that are based on their custom size metrics? For example, instead of providing a URI, provide properties that define the metric.

ArthurRyman - In RDF, the approach is to create a URI for every important concept, so customers should create URIs for their custom metrics. Using QUDT they could also define the semantics of their metrics. QUDT allows you to define quantities and units of measure. In essence, we are defining a new measurement system. We are introducing new quantities and units for software, e.g. SLOC, builds, defects, that are analogous to the usual units used in science and engineering, e.g. length, electric charge, luminosity. We could define our EMS 1.0 system using the QUDT ontology and then customers could extend it semantically.

ACTION - ArthurRyman will investigate the use of QUDT to describe the EMS 1.0 measurement system

ACTION - ArthurRyman will create a new process metric category and move the build and test metrics there.

3. NASA and TopQuadrant QUDT Ontology - ArthurRyman

NASA and TopQuadrant have published QUDT - Quantities, Units, Dimensions, and Data Types, an ontology that defines units of measure. We can use the time and currency unit definitions. They have also developed other software ontologies that might be useful.

We looked at the parts of the QUDT ontology that define currency units.

4. Review OSLC Core Simple Query Syntax - ArthurRyman

We depend on parts of the query syntax, e.g. to search for scenarios for a project.

Not covered this week.

Comments

Add your comments here: