This wiki is locked. Future workgroup activity and specification development must take place at our new wiki. For more information, see this blog post about the new governance model and this post about changes to the website.

ems:Baseline

Domain entities: ems:Project, ems:Scenario, ems:Estimate, ems:Baseline, ems:Measurement

Description

An ems:Baseline resource defines the scenario for running a project, and a set of estimates based on that scenario that will be used to monitor the project. When a new ems:Baseline resource is created, it becomes the current baseline for its project.

Baselines are used to establish a basis for tracking progress against a plan. A baseline should be established when the project is initiated, and at key points throughout the project. The purpose of the baseline is to establish the most up-to-date estimates for the project. A baseline should accurately reflect the best available information about the state of the project and provide management with the best available prediction of project schedule, cost, quality, etc. Managers are therefore encouraged to update the baseline whenever a significant event occurs, e.g. the end of an iteration or the achievement of a key milestone.

Whenever a new baseline resource is created, it becomes the current baseline for the project (see ems:currentBaseline). The previous baseline resources are still available for analysis. The sequence of baselines provides valuable information about the accuracy of the estimates and the health of the project. Ideally, the baselines should converge over time. Each new baseline should reduce the uncertainty of the estimates. The reduction of uncertainty over time is sometimes referred to as the Cone of Uncertainty.

The time sequence of baselines for a given project can be determined by inspecting their dcterms:created property which gives a timestamp of when the baseline resource was created. After a baseline resource is created, it SHOULD only be modified to correct errors. Any significant change, such as the addition of a new estimate or the adoption of a new scenario, SHOULD be recorded by the creation of a new baseline resource.

A service provider SHOULD also maintain a revision history of each resource so that the detailed changes can be audited. The ability to view the revision history of each resource lets managers detect process tampering actions such as retroactively changing old estimates or baselines to reflect project actuals.

In the absence of revision histories, change control processes SHOULD be put in place, e.g. to prevent changes to resources after they are included in a baseline.

Properties

An ems:Baseline resource contains the Standard Properties and the following properties:

Property Range Type Occurrence Edits Description
dcterms:identifier datatype xsd:string exactly-one read-only The short identifier for this baseline within its list.
ems:baselineList resource ems:BaselineList exactly-one read-only The baseline list that this baseline belongs to.
ems:project resource ems:Project exactly-one read-write The project that this resource is a baseline for.
ems:scenario resource ems:Scenario exactly-one read-write The scenario for running the project.
ems:estimate resource ems:Estimate zero-or-more read-write The estimates based on the scenario that will be used to monitor the project.

dcterms:identifier

See Domain Entities, dcterms:identifier.

ems:baselineList

See Domain Entities, ems:{entity}List.

ems:project

This property links to the project, an ems:Project resource, that the baseline is for. We'll refer to this as the baselined project.

ems:scenario

This property links to the scenario, an ems:Scenario resource, that has been adopted for running the project. We'll refer to this as the adopted scenario.

The value of ems:project property of the adopted scenario MUST be the baselined project.

ems:estimate

This property links to an estimate, an ems:Estimate resource, that will be used for montoring the project. We'll refer to such an estimate as an adopted estimate.

The set of adopted estimate SHOULD NOT contain contradicting predictions, for example, two estimates that predict very different distributions for the same metric. Resolving contradicting predictions is outside the scope of this specification.

The adopted scenario MUST be equal to or an ancestor of the value of the ems:scenario property of each adopted estimate.

Examples

Comments

Add your comments here:

 
Topic revision: r8 - 25 Nov 2010 - 20:00:11 - ArthurRyman
 
This site is powered by the TWiki collaboration platform Copyright � by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Contributions are governed by our Terms of Use
Ideas, requests, problems regarding this site? Send feedback