The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• ems:unitOfMeasure

The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• ems:unitOfMeasure

Licensed Materials (See https://www.oasis-open.org/policies-guidelines/ipr) - Property of OASIS.
Copyright OASIS 2014. All Rights Reserved.

The namespace URI for this vocabulary is:

http://open-services.net/ns/promcode#

This page lists the RDF classes, properties, and individuals that make up the OSLC PROMCODE vocabulary. Following W3C best practices, this information is available as HTML (this page) and as RDF.

Details about how this page was generated, and other related material, can be found in the wiki article Publishing RDF Vocabularies on jazz.net.

Description:

The OSLC PROMCODE vocabulary defines scope items, work items, artifacts, issues and other related project management concepts that arise in contracted delivery projects. In contracted delivery, an acquirer specifies work to be performed by a supplier. This is a DRAFT vocabulary. It is under review by the OASIS OSLC PROMCODE Technical Committee.

Prefixes used in this document:

Classes defined by this vocabulary:

Artifact, Issue, ManagedItem, Measure, Measurement, ScopeItem, WorkItem

Properties defined by this vocabulary:

actualEndDate, actualSize, actualStartDate, actualValue, composedBy, date, measures, observes, phase, plannedEndDate, plannedSize, plannedStartDate, plannedValue, producedBy, relates, representedBy, requiredBy

actualSize

promcode:actualSize is an RDF property.

actualSize is a measurement of the actual size of a scope item. Note that there is no way to specify the unit of measure used for size. This property should be replaced by a term from the OSLC Estimation and Measurement Service vocabulary.

actualValue

promcode:actualValue is an RDF property.

actualValue is a property of measure resources. It is the actual value of a measurement.

Artifact

promcode:Artifact is an RDF class.

An artifact is a work product that is produced in a project. An artifact may be physical or digital.

composedBy

promcode:composedBy is an RDF property.

composedBy is a relation between managed items of the same type. It expresses a composition relation between the subject and object. The subject is part of the object. For example, a child work item is composed by its parent work. This property is used to link managed items to each other. Note that this property is closely related to dcterms:isPartOf. It should be regarded as a subproperty of dcterms:isPartOf.

date

promcode:date is an RDF property.

date is a property of measurements. It is the date on which the measurement was made.

Issue

promcode:Issue is an RDF class.

An issue is a situation that must be resolved in order to meet the objectives of a project. Failure to resolve the situation may result in negative consequences for the project, such as a schedule delay.

ManagedItem

promcode:ManagedItem is an RDF class.

A managed item is a scope item, work item, artifact, issue, or some other entity that is part of a project. Managed item resources use dcterms:type to specify concrete subclasses. This practice is deprecated in OSLC Core 3.0.

Measure

promcode:Measure is an RDF class.

A measure is an observation of some measurable aspect of an artifact. A measure consists of planned and actual values. The rate of progress in developing an artifact is assessed by comparing the actual value to the planned value. Note that measure resources use dcterms:type to specify what is being measured. This practice is deprecated in OSLC Core 3.0. This class is related to similar classes in the OSLC EMS vocabulary which should be used instead.

Measurement

promcode:Measurement is an RDF class.

A measurement measures some aspect of an artifact at some point in time. This class is related to similar classes in the OSLC EMS vocabulary which should be used instead.

measures

promcode:measures is an RDF property.

measures is a relation between measurements and artifacts. A measurement measures an artifact. Note that this property is related to similar properties in the OSLC EMS specification which should by used instead.

observes

promcode:observes is an RDF property.

observes is a relation bewteen measurements and measures. A measurement observes a measure. Note that is property is related to similar properties in the OSLC EMS specification which should by used instead.

phase

promcode:phase is an RDF property.

phase is an optional property of work items. Its value is a literal string that names the phase of the project. Typical phase names include Analysis, Design, and Implementation. Note that it is better to represent identify phases as resources. The OSLC EMS vocabulary defines some common phases.

plannedSize

promcode:plannedSize is an RDF property.

plannedSize is an estimate of the planned size of a scope item. Note that there is no way to specify the unit of measure used for size. This property should be replaced by a term from the OSLC Estimation and Measurement Service vocabulary.

plannedValue

promcode:plannedValue is an RDF property.

plannedValue is a property of measure resources. It is the planned value of a measurement.

producedBy

promcode:producedBy is an RDF property.

producedBy is a relation between artifacts and scope items or work items. Artifacts are produced in the course of implementing scope and work items.

relates

promcode:relates is an RDF property.

relates is a relation between issues and managed items. An issue may relate one or more managed items. Note that that property is closely related to dcterms:relation and should be regarded as a subproperty of it.

representedBy

promcode:representedBy is an RDF property.

representedBy is a relation between work items and people. A work item may be represented by a person who acts as the contact for the work item. This person is responsible for the progress of this work item. This person may or may not actually do the required work.

requiredBy

promcode:requiredBy is an RDF property.

requiredBy is a relation between work items and managed items. A work item may be required by a scope item or an artifact.

ScopeItem

promcode:ScopeItem is an RDF class.

A scope item defines the work to be included in or excluded from a project. It defines the boundaries of the project.

WorkItem

promcode:WorkItem is an RDF class.

A work item describes work to be performed in a project delivery contract. It adds detail to the description of work that is described by a scope item. These details typically include cost, schedule, and resource requirements. The set of all work items in a project form a work breakdown structure.

OSLC Estimation and Measurement Service (EMS) Vocabulary

The namespace URI for this vocabulary is:

http://open-services.net/ns/ems#

This document lists the RDF classes, properties, and individuals that are defined by this vocabulary. Following W3C best practices, this vocabulary is available as HTML (this document) and as RDF source.

More details about how this page was generated, and other related material, can be found in OSLC Core URI Naming Guidance.

Status

This document is a Draft Specification.

Introduction

Estimation plays an important role at several phases of the software development lifecycle. We’ll focus on the following use cases:

• Initiating
  • Develop the initial project parameters of scope, cost, schedule, and quality and see if they align with business owner expectations.
  • Ideally base the estimate on similar completed projects.
• Monitoring and Controlling
  • Capture metrics and compare them with control limits.
  • Take corrective action when an unacceptable variance occurs
• Reestimating
  • Periodically, e.g. at the end of each iteration, reestimate the project based on the actuals.
• Closing
  • Capture the final project metrics and record them for use by future projects.
• Calibrating
  • Analyse past projects to define estimation model parameters that reflect the actual capabilities of a development organization.

Each of these use cases is described in more detail below.

Initiating

A project proposal requires a business case which includes the cost, schedule, and risk estimates for these. The risk estimates are typically provided as a decile step function of the probability distribution of the estimated quanity, e.g. duration, cost, size.

The main actors are business owner and the estimator. For future reference, a business owner is the requestor of the proposed functionality and an estimator is the person responsible for estimating the project. This individual is skilled in the use of estimation models and tools, but may not have detailed domain knowledge of the project being estimated. The estimator will work with individuals who understand the project scope, complexity, architecture, and team capabilties to establish the assumptions upon which the estimate it based. These assumptions, e.g. project duration, peak staffing, new and changed lines of code, etc., become part of the project proposal and are compared to business owner expectations for alignment. Proposal risk can be determined based on the alignment of te estimate and the business owner expectations.

The estimator pulls the project parameters from the proposal, works with an estimation tool, and attaches the estimates to the proposal. The estimate typically provides the time and cost elements of the business case. The uncertainly in these estimates contribute to the overall investment risk of the project. The cost and risk are then used by the portfolio manager judge the desirability of the project. Projects that have high risk must also have a high return on investment (ROI) in order to be attractive.

Monitoring and Controlling

All projects have measurable properties, i.e. metrics, that can be monitored throughout the project lifecycle in order to assess progress, health, and risk. The project plan describes how generic metrics such as labor expense, staffing levels, and task completion are expected to change over the lifecycle of the project. Since these metrics cannot be predicted with complete accuracy, a certain amount of variance is normal. Project managers control projects by monitoring these metrics, detecting unacceptable variances, diagnosing the root cause, and taking corrective action.

Software projects have a large additional set of metrics, such as code size, defect rate, test success, etc., that provide additional insight into the project as it evolves. It is therefore natural to treat the estimates for these software metrics as also being part of the project plan.

A software metric estimate is a time series of values that predict the lifecycle of a metric over some part of the project lifecycle. The estimate includes both the predicted value (most likely) and the error bounds (high and low values) to establish the control limits for the measurement. Project actuals for these metrics are automatically collected from software tool repositories, e.g. defect metrics are collected from change management systems, source code size metrics are collected from software configuration management systems, effort metrics are collected from time accounting systems and schedule metrics are collected from project management tools.

The main actor is the project manager or an analyst in a project office. Here we regard teams leads who are responsible for monitoring and controlling their teams as effectively acting in the capacity of a project manager.

The project manager or analyst periodically compares the actuals to the estimates. They may use business intelligence techniques such as dashboards and charts with automatic alerts to detect unacceptable variances. The control limits can be used to colour dashboard widget ranges as green, yellow, and red to indicate the degree to which the control limits are approached or exceeded. If the actuals diverge from the estimates, then the project manager diagnoses the cause and takes corrective actions.

Business intelligence techniques such as drill down and drill through allow the project manager to explore the metric space and understand the root cause of variances. Drilling down into the data enables the project manager to isolate the source of the variance. Estimates are typically performed using a coarse grained product breakdown structure. In order to establish estimates and control limits below this level of granularity, components could use average values from their parent component. For example, suppose the total defect estimate for a 100 KLOC component is 2000 +/- 200. The average defect density is therefore 20 defects per KLOC. If this component is composed of two child components of sizes 70 KLOC and 30 KLOC, then their defect totals could be estimated at 1400 +/- 140 and 600 +/- 60. If 80 defects were reported for the 30 KLOC component, then an alert would be raised even though the density for the parent component might be within the control limits.

Monitoring and controlling iterative projects have an ongoing need for estimation of the time-to-complete ( TTC). Ideally, each iteration should reduce the uncertainty of ontime delivery. This uncertainty is measured by the variance in the current estimate of the TTC. Iterative programs begin with an intial iteration plan ideally designed to reduce the TTC as rapidly as possible. At each iteration boundary the iteration plan is reset based on the results achieved to-date and the remaining variance in the TTC. Hence, the project team needs to have an ongoing view of the variance in the estimate of the TTC along with the remaining program content (components, work items, …) that most contribute to the variance.

Some large programs, essentially a team of project teams do iteration planning at the program level at a given time frequency. Each team then adopts a higher frequency iteration plan or adopts an agile process to ensure they meet their commitments to the current iteration. In this case, they need to roll-up the team estimate of TTC to the overall program estimate. In particular, the relationship of program estimate variance and the teams’ estimate variances is needed to support the program iterations. In some cases the teams may be adopting bottom-up estimation methods based on their work items, while the program may be using top-down approaches. This calls for a method of relating bottom-up and top-down estimate.

Reestimating

Software metric estimates are not goals – they are simply a tool to make project outcomes more predictable. For example, the estimated defect discovery rate for a project depends on both the defect injection rate and the efficiency of the defect removal processes. If in the course of a project, few defects are discovered, this could be good news or bad news. It’s good news if the development team is injecting fewer defects and bad news if the testing is inadequate. The project manager must determine which is the case. If in fact the testing is good and the defect injection rate is low, then the defect estimates should be redone. Knowing the actual defect rates affects the cost of the project and the downstream support costs.

Estimates should therefore be revised to incorporate actuals so that they reflect reality better.

The main actor is either the project manager, if the project assumptions are still valid, or the estimator if the project assumptions need to be updated. In both cases we need to incorporate the actuals to produce a better estimate to completion.

At selected points in the lifecycle of the project, e.g. the end of an iteration, the project manager or estimator pulls the project parameters and actuals into an estimation tool, produces an updated estimate, and revises the project plan. This new plan becomes the baseline against which future actuals are compared.

As the project progresses it will grow a baseline history. The project manager may also wish to view and compare the baselines to determine if the estimates are converging and the uncertainty is being reduced. If the project is under control, then the estimates should converge. At the end of the project, all the metrics will atain actual values so the uncertainty is zero.

See Reestimation use case description.

Closing

The safest way to estimate a project is to base it on a similar completed project. For example, a quarterly maintenance release of a product will likely be similar to the previous quarterly maintenance release of the same product if it is executed by the same time. Estimation models should therefore incorporate the actual performance of the development organization on past projects.

The main actor is the estimator or metrics analyst since knowledge of estimation models, software metrics and tools is required.

When a project finishes, the project manager formally closes it. This may involve collecting summary data. At this point it may be of interest to analyse the project by benchmarking it against the other projects in the historical database:

• Did the project perform better than the norm?
• If the project improved or got worse, what was the cause?
• Have there been any significant trends?

After the project manager closes the project, the estimator pulls the final project data into a metrics repository and the estimation tool and recalibrates the model. The updated model is now ready for use in estimating future projects.

Calibrating

Estimation models contain parameters that can be selected to more closely describe the actual performance of a development organization. The process of selecting the best parameters is known as calibration. This task is performed by assembling a database of past projects, classifying them into groups that share similar characteristics, and computing the set of model parameters that fit each group best.

The main actor is the estimator since skill with an estimation tool is required. The estimator collects the historical data, loads it into an estimation tools, and performs the classification. The estimation tool then applies algorithms to compute the model parameters that best fit the data. Each group of similar projects will have its own set of model parameters.

Calibration is typically done when a development organization adopts an estimation tool. In the absence of calibrating the tool using the organization’s own data, users of the tool will have to rely on model parameters computed by the tool vendors based on data collected from other organizations, which may not accurately reflect the organization’s capabilities. Calibration is therefore highly desirable.

After the initial bulk calibration, an organization should incrementally update the model parameters when new projects are completed. See the Closing use case.

Comments

Added business owner to the initiating scenario and brought in to other actors like analysts in project offices or metrics analysts to controlling and closing scenarios.

Added Calibrating use case.

The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• ems:unitOfMeasure

The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• [ems:unitOfMeasure]((http://open-services.net/ns/ems#unitOfMeasure)

The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• ems:unitOfMeasure

The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• ems:unitOfMeasure

The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• ems:unitOfMeasure

The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• ems:unitOfMeasure

The following terms will be finalized:

• ems:Measure
• ems:Metric
• ems:metric
• ems:numericValue
• ems:observes
• ems:unitOfMeasure

The following terms will be finalized:

• ems:observes
• ems:Measure
• ems:metric
• ems:unitOfMeasure
• ems:numericValue

The following terms will be finalized:

• ems:observes
• ems:Measure
• ems:metric
• ems:unitOfMeasure
• ems:numericValue

[TOC]

Introduction

The goal of this effort is to define a common set of software estimation and measurement resources, their representation formats, and a RESTful Web service API for accessing them for in the context of software project management to enable the collaboration of multiple tools that provide and consume estimates across the development lifecycle.

Status

As of 2013-02-27

• The Performance Monitoring specification is using a subset of terms from the EMS Vocabulary. We will propose to move this subset of term to the Finalization stage
• Progress on implementations has been suspended pending resource availability.
• The mailing list is being used for implementation discussion.
• Implementation Status is being used to report implementation status.
• Telecons will be held as required for discussion.
  • See [[Meeting Agendas and Minutes]] for telecon details.
• Metric Definitions is complete.
• [[Software Estimation Use Cases | Use Cases]] is complete.
• [[Estimation and Measurement Service Version 1.0: REST API | REST API]] is in the convergence phase.

Approach

The specifications will be developed by:

1. establishing [[Software Estimation Use Cases | Use Cases]],
2. collecting common Metrics Definitions,
3. developing a [[Estimation and Measurement Service Version 1.0 Primer | Primer]] to illustrate and elaborate the use cases, and
4. specifying the [[Estimation and Measurement Service Version 1.0: REST API | REST API]] in full detail for implementors.

Working Documents

Refer to Working Documents for the list of working documents and related design considerations.

Milestones

Feedback

[[Specification comments and issues]]

Mailing List

Metrics
General Open Services

[TOC]

Introduction

The goal of this effort is to define a common set of software estimation and measurement resources, their representation formats, and a RESTful Web service API for accessing them for in the context of software project management to enable the collaboration of multiple tools that provide and consume estimates across the development lifecycle.

Status

As of 2013-02-27

• The [[http://open-services.net/wiki/performance-monitoring/ | Performance Monitoring]] specification is using a subset of terms from the EMS Vocabulary. We will propose to move this subset of term to the Finalization stage
• Progress on implementations has been suspended pending resource availability.
• The mailing list is being used for implementation discussion.
• Implementation Status is being used to report implementation status.
• Telecons will be held as required for discussion.
  • See [[Meeting Agendas and Minutes]] for telecon details.
• Metric Definitions is complete.
• [[Software Estimation Use Cases | Use Cases]] is complete.
• [[Estimation and Measurement Service Version 1.0: REST API | REST API]] is in the convergence phase.

Approach

The specifications will be developed by:

1. establishing [[Software Estimation Use Cases | Use Cases]],
2. collecting common Metrics Definitions,
3. developing a [[Estimation and Measurement Service Version 1.0 Primer | Primer]] to illustrate and elaborate the use cases, and
4. specifying the [[Estimation and Measurement Service Version 1.0: REST API | REST API]] in full detail for implementors.

Working Documents

Refer to Working Documents for the list of working documents and related design considerations.

Milestones

Feedback

[[Specification comments and issues]]

Mailing List

Metrics
General Open Services

[TOC]

Introduction

The goal of this effort is to define a common set of software estimation and measurement resources, their representation formats, and a RESTful Web service API for accessing them for in the context of software project management to enable the collaboration of multiple tools that provide and consume estimates across the development lifecycle.

Status

As of 2012-01-10:

• Progress on implementations has been suspended pending resource availability.
• The mailing list is being used for implementation discussion.
• Implementation Status is being used to report implementation status.
• Telecons will be held as required for discussion.
  • See [[Meeting Agendas and Minutes]] for telecon details.
• Metric Definitions is complete.
• [[Software Estimation Use Cases | Use Cases]] is complete.
• [[Estimation and Measurement Service Version 1.0: REST API | REST API]] is in the convergence phase.

Approach

The specifications will be developed by:

1. establishing [[Software Estimation Use Cases | Use Cases]],
2. collecting common Metrics Definitions,
3. developing a [[Estimation and Measurement Service Version 1.0 Primer | Primer]] to illustrate and elaborate the use cases, and
4. specifying the [[Estimation and Measurement Service Version 1.0: REST API | REST API]] in full detail for implementors.

Working Documents

Refer to Working Documents for the list of working documents and related design considerations.

Milestones

Feedback

[[Specification comments and issues]]

Mailing List

Metrics
General Open Services

Status

This document is a Draft Specification.

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 enables 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 [[Estimation and Measurement Service Version 1.0: REST API | 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 enables 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. 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 [[EMS 1.0 REST API Architecture | 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 [[EMS 1.0 Primer: Personas | 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, [[Estimation and Measurement Service Version 1.0: REST API | REST API]].

• [[EMS 1.0 Primer: Initiating a Project | Initiating a Project]]
• [[EMS 1.0 Primer: Monitoring and Controlling a Project | Monitoring and Controlling a Project]]

The following scenarios will be elaborated at a later date:

• [[EMS 1.0 Primer: Reestimating a Project | Reestimating a Project]]
• [[EMS 1.0 Primer: Closing a Project | Closing a project]]
• [[EMS 1.0 Primer: Calibrating an Organization | Calibrating an Organization]]

[[Category:EMS Primer]]

[TOC]

Status

This is a Draft Specification.

Overview

This scenario illustrates how EMS 1.0 may be used in the process of initiating a project. The main actors in this scenario are a portfolio manager and a software estimator. The scenario is divided into three acts.

In [[EMS 1.0 Primer: Initiating a Project: Setup | Act 1]] the portfolio manager, Pedro Mendelzohn, receives a proposal for a new software development project. Pedro sets up the project by entering some assumptions about its size and duration, and then requests an estimate.

In [[EMS 1.0 Primer: Initiating a Project: Estimation | Act 2]] the software estimator, Syd Ethan, receives the request for an estimate and uses a software estimation tool to predict the amount of effort required.

In [[EMS 1.0 Primer: Initiating a Project: Completion | Act 3]] Pedro reviews the effort estimate and applies labour rates to it to produce a cost estimate for inclusion in the business case of the project proposal.

The above three acts are highly simplified and omit the important concept of [[EMS 1.0 Primer: Initiating a Project: Investment Risk | investment risk]]. We discuss the uncertainties inherent in the project assumptions and estimates, and describe how these may be represented using probability distributions. The resulting cost estimate is also a probability distribution whose statistical variance is a measure of investment risk.

We conclude the discussion of this scenario with a [[EMS 1.0 Primer: Initiating a Project: Summary | summary]] of the interactions between the actors and tools in a sequence diagram.

The details of this scenario are described in the following sections:

• [[EMS 1.0 Primer: Initiating a Project: Setup | Act 1. Setup]] - The portfolio manager sets up the project proposal and requests an estimate.
• [[EMS 1.0 Primer: Initiating a Project: Estimation | Act 2. Estimation]] - The software estimator develops estimates for several alternate ways of running the project and reviews them with the portfolio manager.
• [[EMS 1.0 Primer: Initiating a Project: Completion | Act 3. Completion]] - The portfolio manager analyses the cost-benefit-risk tradeoffs and selects the best alternative. This establishes the project baseline for cost, schedule, etc., and completes the process.
• [[EMS 1.0 Primer: Initiating a Project: Investment Risk | Investment Risk]] - The uncertainty in estimates is a measure of investment risk.
• [[EMS 1.0 Primer: Initiating a Project: Summary | Summary]] - The interactions between the actors are summarized in a sequence diagram.

Comments

Add your comments here:

Re: “Software estimation tools enter here by taking the project assumptions as input, and producing a plan as output. Consider the following highly simplified model. In this model the project inputs are size and duration. The output is effort. ” I suspect this is NOT something we will be automating any time soon. Perhaps some specific parts of it could, and that MAY have value. The example misses two critical points that affect whether we can automate through OSLC the “project assumptions as an input to the estimate”:

1) In general, the basic way estimation suites work is subtly different from this – I THINK, estimation suite vendors, please comment: A particular estimation tool has a “model” (I believe that’s the term used) of the input “parameters” (as in “parametric estimation”) needed to produce an estimate of schedule and effort/cost for the project(and perhaps other things). This is the “normal” path, but they can be and are “used in reverse” with contraints, as in this example…you can constrain the project by schedule (‘it must finish in 12 months or less’, or even “it must finish before VS Live 2002 so Grady Booch can demo it on stage with Bill Gates”) or effort (well, maybe team size–“there can be no more than 20 people assigned to this project”) and by using “what if” analysis, see what size/scope can be completed under those constraints with a given quality level or variations on this. Underneath is a relationship between our “four categories of metrics”– size, schedule, effort, and quality. But the parameters in the model–the “assumptions”– vary from tool to tool: Is “language coded in” a parameter, is “industry” (e.g. banking vs. A & D) a parameter etc.?

2) My experience is that these assumptions and contraints are specified in “free form text” within some kind of Vision document. Some project management systems (RPM, CA whatever Niku is now, Primavera I think—first one was LBMS back in the early 90’s!) allow such a document to be an attachment to the project. Other times this is in a requirements management system (RequisitePro, Rational Requirements Composer, I think also DOORS, not, I believe Calibre). And the “project assumptions” are all over the map, and not necessarily inputs to estimation: “We will market this initially in the Southwest United States and France” But in neither case, whether it’s in the project management tool or a requirements management tool is it in a form that can be used for automation. If the Project Management system provides it as a blob/bytestream in the return of a GET method, it will have to be parsed from its original Japanese, Norwegian, or maybe even English to find the inputs to the estimate. Not likely in this round of work :)

However—are the SOME assumptions/constraints we can identify as “general enough” for all estimation tools and can be structured so they aren’t just in text? Probably, but is this a fruitful line of investigation, or will the results of doing so still not be enough automation of the inputs to the estimate to justify it this round of work? This is a prioritization question for our group as much as it is a technical question.

– Main/AndyBerner - 17 Jul 2009

The portfolio/project manager can get a useful, more detailed description of effort from the estimation tool. Type “MetricsEffortEstimateDetail” in the Jump box at the top of this page.

– Main/AndyBerner - 28 Jul 2009

I presume that the Scenario Resource (containing the set of assumptions that become inputs to the estimate) could be extensible (its properties). For example, if a vendor comes up with a model that enriches estimation power by including skills and experience of developers (people) available in a project… that they could add those as properties in the scenario resource

– Main/LucinioSantos - 27 Jan 2010

[[Category:EMS Primer]]