Estimation and Measurement Service Version 1.0 (EMS 1.0): Primer

Status

This document is a Review Draft.

Please send comments about this document to the public OSLC community mailing list or add comments to the this wiki page.

Abstract

This document describes the Open Services for Lifecycle Collaboration (OSLC) Estimation and Measurement Service Version 1.0 (EMS 1.0), a REST API that enable the integration of software estimation tools with other tools used in the software development lifecycle. This document is a non-normative primer which is intended to serve as an easily-read introduction to the normative specification. For full details see REST API.

Introduction

The goal of EMS 1.0 is to enable integration between software estimation tools and other tools used in the software development lifecycle, especially project management tools. In this context, a project is a time-bounded work effort that produces some unique result. The development of a major or minor release of a product or application is a good example of a project. The job of the software development manager is to steer the project towards completion on time, within budget, with good quality, and delivering the required capabilities.

It is common knowledge within the software industry that managing software projects is difficult. Each project is unique and is often complex. The underlying technology changes rapidly, the business environment is dynamic, and requirements alter during the course of the project. Project managers need to be able to accurately assess the progress and health of projects. Simply asking developers for their status is often insufficient to accurately judge the true state of the project. This is where estimation and measurements come in. Project managers augment the verbal status reports from the development team with quantitative measurements on the project and the artifacts being produced. These measurements are then compared to the estimates to determine if the project is progressing as planned. If the measurements disagree with the estimate, the project manager diagnoses the root cause and takes corrective action to steer the project back on course, or, in the absence of a feasible corrective action, informs the project sponsors that the project is off course and then replans the project.

Architecture

Provider and Consumer Roles

The EMS 1.0 specification describes a REST API that enable collaboration between project and portfolio management (PPM) tools and software estimation tools. The architecture is described in terms of an estimation and measurements service provider that is consumed by both the PPM and software estimation tools consume the services. However, PPM and software estimation tools may also provide this service. This specification does not dicate the product architecture, only the REST API. See the discussion of REST API Architecture for more deatils.

RDF

The EMS 1.0 specification uses Resource Description Framework (RDF) to describe the data model and to define XML resource representations. RDF/XML is used to define the syntax of the XML request and response bodies of its REST API. However, implementors are free to use any implementation technology, and other resource representations, e.g. JSON, are supported.

Scenarios

The remainder of this primer illustrates the features of EMS 1.0 using project management scenarios. We use personas to make the scenarios more realistic and easier to follow. A persona is a fictious person who plays the role of an actor in one or more scenarios. Personas will be introduced as required to illustrate the scenarios. Refer to Personas for a full description of the personas used in this primer.

The examples used are highly simplified in order to convey the underlying concepts as clearly as possible. The full details are described in the normative specification, REST API.

• Initiating a Project
• Monitoring and Controlling a Project
• Reestimating a Project
• Closing a Project
• Calibrating an Organization

Comments

Add your comments here: