Initiating a project: Act 1. Setup, Act 2. Estimation, Act 3. Completion, Investment Risk, Summary
Contents
The ProjectList Resource
Project Resources
Scenario Resources
Summary Sequence Diagram
Initiating a Project
Project initiation is the first phase in the lifecycle of a project. This is where the project comes into existence in order to satisfy some set of business requirements. The set of business requirements satisfied by a project is referred to as its scope.
A project might create a new product, enhance an existing product, or perform maintenance on it. The project requirements define the desired capability of the software to be developed. Let us assume that the business benefits associated with the requirements are understood. The first task of the project manager is to establish the project plan, including the resource requirements, cost, schedule, and risk. The plan is combined with the business value to form a business case. If the benefits outweigh the costs, and the risk is acceptable, then the project is feasible and is likely to get approved.
Software estimation tools enter here by taking the project assumptions as input, and predicting a set of metrics as output. The project assumptions are the constraints under which a project is to be executed. A set of project assumptions is sometimes referred to as a scenario. In practice, several scenarios may be estimated and compared before one is selected. For example, one scenario may be to fix the size and duration as inputs, and estimate effort from them, while another scenario may only specify size as input, and estimate the best combination of effort and duration from that. In Agile projects, duration and effort (based on a fixed team) are the inputs, and size (in story points) is estimated. EMS 1.0 allows any combination of inputs and outputs.
Consider the following highly simplified example. In this example the project inputs are size and duration and the output is effort. Rather than continuing to talk in the purely abstract, we’ll use personas to illustrate this and other scenarios. Our personas are engaged in the development of a fictional project, Tsunami 1.0, being planned by BrainTwistors Corp. Tsunami is a Japanese logic puzzle and BrainTwistors Corp. is a US-based game website that generates revenue by selling advertising for game stores. BrainTwistors Corp. is planning to create a web version of Tsunami since this will drive traffic to the website and increase advertising revenue. Future plans include developing free iPhone, BlackBerry, and Nintendo DS versions, and charging for puzzle downloads.
Size Assumption
The size of the project measures how much capability is produced by it. We therefore need a way to convert the project scope into a size. We also need a way to measure the size as embodied by the resulting software. In this model we’ll use the count of source lines of code created or modified in the project to measure the size of the project. This metric is referred to as effective source lines of code (ESLOC). ESLOC is certainly measureable, but it’s relation to business requirements is not direct.
A much more plausible measure of size is function points. Fortunately, experience has shown that there is a reasonable correlation between functions points and lines of code for a given programming language (e.g. see Function Point Languages Table). We can therefore translate the business requirements into function points and then apply a suitable gearing factor to produce an ESLOC value as the project size.
The BrainTwistors Corp. game designers have come up with a design for Tsunami 1.0 and have worked with the software architects to translate it first into function points and then ESLOC. The size assumption for Tsunami 1.0 is:
size = 50,000 ESLOC
Duration Assumption
Duration is the elapsed calendar time of a project. In general, duration may be either an input assumption, or an output of the estimation process. Duration is certainly measurable and may be measured in days, weeks, months, or years.
For Tsunami 1.0, time to market is critical since BrainTwistors Corp. needs to drive more traffic to its website in order to achieve its advertising revenue target for the coming fiscal year. The project must be completed within six months. The duration assumption is therefore:
duration = 6 months
Project Portfolio Management
Since businesses always have limited financial and human resources, it is a best practice to apply portfolio management techniques to select the best ways to invest these resources in new projects. Project portfolio management tools enable proposals for new projects to be prioritized based on their business value, alignment with strategic goals, and risk.
BrainTwistors Corp. uses the web-based PfGenius project portfolio management tool. PfGenius lets businesses create and prioritize project proposals, and review the execution status of running projects. PfGenius has built-in workflow capability to enact the project portfolio management processes. A BrainTwistors Corp. product manager, Pedro Mendelzohn, has created the proposal for the Tsunami 1.0 project in PfGenius, quantified the business benefits, and added its size and duration assumptions. Pedro predicts that Tsunami 1.0 will generate 500,000 USD of additional advertising revenue if shipped in six months. The business benefits are therfore:
benefit = 500,000 USD
The next step in the project initiation process is to estimate the effort and cost. In PfGenius, Pedro changes the state of the Tsunami 1.0 project proposal to “Requires Software Estimate”. This state transition results in a notification being sent to Syd Ethan, the person in the software estimator role, informing him that he needs to work on a proposal.
Note that the workflow and notification mechanisms used depend on the tool and are beyond the scope of the EMS 1.0 specification.
Using EMS 1.0
Fortunately, PfGenius implements the EMS 1.0 specification so it can easily integrate with software estimation tools, making the job of the software estimator very simple. PfGenius is in fact a consumer of EMS 1.0 services and has been configured by the BrainTwistors Corp. system administrator to send EMS 1.0 service requests to MetricServer, a performance management tool that is a provider of EMS 1.0 services. BrainTwistors Corp. uses MetricServer to manage the estimates and measurements for all of its software development projects. MetricServer has been deployed in the BrainTwistors Corp. network at the following URI:
http://braintwistors.example.com/ems10
Note that in this scenario we have used a tool architecture in which the EMS 1.0 service provider is separate from the PPM and software estimation tools. This is done to clarify the roles and to treat the PPM and software estimation tools on an equal footing as consumers of the EMS 1.0 service. It is perfectly valid for the PPM or software estimation tools to be EMS 1.0 service providers.
Continuing with this scenario, when Pedro changes the state of the project proposal in PfGenius to “Requires Software Estimate”, PfGenius in fact first creates a resource for the project in MetricServer using its EMS 1.0 service. MetricServer creates a new Project resource and returns its URI to PfGenius. PfGenius then creates some Scenario resources for the project. Each Scenario describes an alternate mode for the project. The software estimator should create an estimate for each scenario so that the portfolio manager can analyse the feasible alternatives and select the best one.
After creating the Project and Scenario resources, the proposal is ready for the software estimator to begin work. PfGenius includes the new Project resource URI in the notification message it sends to the software estimator.
The Service Resource
In EMS 1.0, a new Project resource is created by POSTing a representation of the project to the ProjectList URI. We’ll now describe how an EMS 1.0 service consumer like PfGenius finds the ProjectList URI.
As stated above, BrainTwistors Corp. has deployed MetricServer, an EMS 1.0 service provider. Consumers of an EMS 1.0 service find its ProjectList URI and other information by sending at GET request to the URI of the service. The response is a representation of a Service resource that describes the EMS 1.0 service provider. Here is the response from MetricServer:
Listing of Service Resource
<?xml version="1.0"?>
<ems:Service xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:ems="http://open-services.net/ns/ems#"
rdf:about="http://braintwistors.example.com/ems10">
<dcterms:title rdf:parseType="Literal">BrainTwistors Corp. MetricServer
</dcterms:title>
<dcterms:description rdf:parseType="Literal">
This service implements
the OSLC Estimation and
Measurement Service (EMS) 1.0 specification at
BrainTwistors Corp.
</dcterms:description>
<ems:baselineList rdf:resource="http://braintwistors.example.com/ems10/Baseline" />
<ems:estimateList rdf:resource="http://braintwistors.example.com/ems10/Estimate" />
<ems:measurementList
rdf:resource="http://braintwistors.example.com/ems10/Measurement" />
<ems:projectList rdf:resource="http://braintwistors.example.com/ems10/Project" />
<ems:scenarioList rdf:resource="http://braintwistors.example.com/ems10/Scenario" />
<!--
Other properties of this resource have been omitted for brevity.
-->
</ems:Service>
The ProjectList Resource
The URI of the ProjectList resource is the object of Service resource’s ems:projectList property. In general, each type of resource managed by the EMS 1.0 service provider has a List resource that is given by a corresponding property of the Service resource.
The ProjectList URI in MetricServer is:
http://braintwistors.example.com/ems10/Project
Note that the syntax of the ProjectList URI and all other URIs in an EMS 1.0 service provider are not specified by the EMS 1.0 specification. In EMS 1.0, all URIs are opaque and must be discovered by examining the responses returned by the service provider. The only exception is that new URIs may be formed by appending valid query parameters to certain URIs. See EMS 1.0 Query Syntax and Semantics for details.
In addition to its use for Project resource creation, the ProjectList URI can be queried to return the list of all Project resources, or selected subsets of it, using GET requests with optional query parameters. See EMS 1.0 Query Syntax and Semantics for a description of the query syntax supported by List resources. Here is the result of a GET request on the ProjectList URI:
Listing of ProjectList Resource
<?xml version="1.0"?>
<ems:ProjectList xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:ems="http://open-services.net/ns/ems#"
rdf:about="http://braintwistors.example.com/ems10/Project">
<dcterms:title rdf:parseType="Literal">BrainTwistors Corp. Project List
</dcterms:title>
<dcterms:description rdf:parseType="Literal">
This is the list of all
Project resources contained in
the BrainTwistors Corp. MetricServer web
application.
</dcterms:description>
<ems:service rdf:resource="http://braintwistors.example.com/ems10" />
<ems:memberProject
rdf:resource="http://braintwistors.example.com/ems10/Project/2009" />
<ems:memberProject
rdf:resource="http://braintwistors.example.com/ems10/Project/3707" />
<ems:memberProject
rdf:resource="http://braintwistors.example.com/ems10/Project/3998" />
<!--
Other members of this resource have been omitted for brevity.
-->
</ems:ProjectList>
Project Resources
PfGenius sends a POST request to the ProjectList URI in MetricServer to create a representation of the project there. This representation contains a brief description of the project. MetricServer creates the new project resource and returns its URI to PfGenius. The following example shows the XML representation of the EMS 1.0 Project resource:
Listing of Tsunami 1.0 Project Representation
<?xml version="1.0"?>
<ems:Project xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:ems="http://open-services.net/ns/ems#">
<dcterms:title rdf:parseType="Literal">Tsunami 1.0</dcterms:title>
<dcterms:description rdf:parseType="Literal">
The goal of this project
is to create a web version of
Tsunami, a Japanese logic puzzle, in
order to drive traffic to the
BrainTwistors Corp. website and increase
advertising revenue. Future
plans include developing free iPhone,
BlackBerry, and Nintendo DS
versions, and charging for puzzle
downloads.
</dcterms:description>
<!--
Other properties of this resource have been omitted for brevity.
-->
</ems:Project>
MetricServer returns the following URI for the new Project resource:
http://braintwistors.example.com/ems10/Project/4201
If PfGenius itself provided REST services for project portfolio management, there would be a resource for the Tsunami 1.0 project there too. PfGenius would include this URI in the POST request to MetricServer. This would establish a two-way link between PfGenius and MetricServer that relates the resources that decribe these different aspects of the Tsunami 1.0 project. The resource in PfGenius describes the investment aspects of the project while the resource in MetricServer describes its estimation and measurement aspects. In general, there may be many resources needed to describe the various aspects of the Tsunami 1.0 project, with each resource possibly being hosted in a different service. For example, when the project proposal gets approved, another resource may be created in the project management service to represent the execution aspects of the project.
When MetricServer creates the new Project resource it assigns it some other properties in addition to a URI. These include the creation date, the creator, and a short local project identifier. Here is the response to a GET request on the new Project resource URI:
Listing of Project 4201 Resource
<?xml version="1.0"?>
<ems:Project xmlns:dcterms="http://purl.org/dc/terms/"
xmlns:ems="http://open-services.net/ns/ems#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
rdf:about="http://braintwistors.example.com/ems10/Project/4201">
<dcterms:title rdf:parseType="Literal">Tsunami 1.0</dcterms:title>
<dcterms:description rdf:parseType="Literal">
The goal of this project
is to create a web version of
Tsunami, a Japanese logic puzzle, in
order to drive traffic to the
BrainTwistors Corp. website and increase
advertising revenue. Future
plans include developing free iPhone,
BlackBerry, and Nintendo DS
versions, and charging for puzzle
downloads.
</dcterms:description>
<dcterms:identifier>4201</dcterms:identifier>
<ems:projectList rdf:resource="http://braintwistors.example.com/ems10/Project" />
<!--
Other properties of this resource have been omitted for brevity.
-->
</ems:Project>
Note that the Project resource URI now appears as value of the rdf:about attribute of the ems:Project element. Note also the automatically assigned short local identifier, 4201, which is the value of the dc:identifier element.
Scenario Resources
After successfully creating the new Project resource, PfGenius creates a new EMS 1.0 Scenario resource for the project. The Scenario resource contains the set of assumptions that are the inputs to the cost estimate. PfGenius POSTs the representation of the Scenario resource to the ScenarioList URI in order to create the new Scenario resource. The ScenarioList URI for MetricServer is:
http://braintwistors.example.com/ems10/Scenario
The following example shows the XML representation of the EMS 1.0 Scenario resource:
Listing of ASAP Scenario Representation
<?xml version="1.0"?>
<ems:Scenario xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:ems="http://open-services.net/ns/ems#">
<dcterms:title rdf:parseType="Literal">Deliver Tsunami 1.0 ASAP</dcterms:title>
<dcterms:description rdf:parseType="Literal">
Deliver Tsunami 1.0 as
soon as possible so we can
capture more of the market. Do whatever it
takes to deliver it in 6
months. We think the minimum functional
content will take around
50,000 ESLOC of Java to implement.
</dcterms:description>
<ems:project rdf:resource="http://braintwistors.example.com/ems10/Project/4201" />
<ems:assumes>
<ems:MeasureDistribution>
<dcterms:title rdf:parseType="Literal">Total Duration in Months</dcterms:title>
<ems:metric
rdf:resource="http://open-services.net/ns/ems/metric#Duration" />
<ems:unitOfMeasure
rdf:resource="http://open-services.net/ns/ems/unit#Month" />
<ems:distribution>
<ems:PointEstimate>
<ems:numericValue rdf:datatype="http://www.w3.org/2001/XMLSchema#double">6</ems:numericValue>
</ems:PointEstimate>
</ems:distribution>
</ems:MeasureDistribution>
</ems:assumes>
<ems:assumes>
<ems:MeasureDistribution>
<dcterms:title rdf:parseType="Literal">Total Size in ESLOC</dcterms:title>
<ems:metric rdf:resource="http://open-services.net/ns/ems/metric#Esloc" />
<ems:unitOfMeasure
rdf:resource="http://open-services.net/ns/ems/unit#Loc" />
<ems:distribution>
<ems:PointEstimate>
<ems:numericValue rdf:datatype="http://www.w3.org/2001/XMLSchema#double">50000</ems:numericValue>
</ems:PointEstimate>
</ems:distribution>
</ems:MeasureDistribution>
</ems:assumes>
<!--
Other properties of this resource have been omitted for brevity.
-->
</ems:Scenario>
MetricServer returns the following URI for the new Scenario resource:
http://braintwistors.example.com/ems10/Scenario/5721
A GET of the above URI gives the following result:
Listing of Scenario 5721 Resource
>?xml version="1.0"?<
<ems:Scenario xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dcterms="http://purl.org/dc/terms/" xmlns:ems="http://open-services.net/ns/ems#"
rdf:about="http://braintwistors.example.com/ems10/Scenario/5721">
<dcterms:title rdf:parseType="Literal">Deliver Tsunami 1.0 ASAP</dcterms:title>
<dcterms:description rdf:parseType="Literal">
Deliver Tsunami 1.0 as
soon as possible so we can
capture more of the market. Do whatever it
takes to deliver it in 6
months. We think the minimum functional
content will take around
50,000 ESLOC of Java to implement.
</dcterms:description>
<dcterms:identifier>5721</dcterms:identifier>
<ems:scenarioList rdf:resource="http://braintwistors.example.com/ems10/Scenario" />
<ems:project rdf:resource="http://braintwistors.example.com/ems10/Project/4201" />
<ems:assumes>
<ems:MeasureDistribution>
<dcterms:title rdf:parseType="Literal">Total Duration in Months</dcterms:title>
<ems:metric
rdf:resource="http://open-services.net/ns/ems/metric#Duration" />
<ems:unitOfMeasure
rdf:resource="http://open-services.net/ns/ems/unit#Month" />
<ems:distribution>
<ems:PointEstimate>
<ems:numericValue rdf:datatype="http://www.w3.org/2001/XMLSchema#double">6</ems:numericValue>
</ems:PointEstimate>
</ems:distribution>
</ems:MeasureDistribution>
</ems:assumes>
<ems:assumes>
<ems:MeasureDistribution>
<dcterms:title rdf:parseType="Literal">Total Size in ESLOC</dcterms:title>
<ems:metric rdf:resource="http://open-services.net/ns/ems/metric#Esloc" />
<ems:unitOfMeasure
rdf:resource="http://open-services.net/ns/ems/unit#Loc" />
<ems:distribution>
<ems:PointEstimate>
<ems:numericValue rdf:datatype="http://www.w3.org/2001/XMLSchema#double">50000</ems:numericValue>
</ems:PointEstimate>
</ems:distribution>
</ems:MeasureDistribution>
</ems:assumes>
<!--
Other properties of this resource have been omitted for brevity.
-->
</ems:Scenario>
Note that the URI appears as the value of the rdf: about attribute of the ems:Scenario element, and the automatically assigned short identifier, 5721, appears as the value of the dc:identifier attribute. In general, the portfolio manager may create many scenarios for the project. Alternatively, the software estimator may create scenarios. The EMS 1.0 does not specify who creates the scenarios, only that each scenario describes the project assumptions that are used as inputs to an estimate. Furthermore, it is possible that a given scenario will be estimated by more than one tool. For example, it may be of interest to compare the estimates produced by two tools for consistency. REST API Notes
In the above example, new resources were created by POSTing XML representations to corresponding List URIs, i.e. to create a project, POST a Project representation to the ProjectList URI, and to create a scenario, POST a Scenario representation to the ScenarioList URI. This pattern is used throughout the EMS 1.0 specification. Each type of resource has a corresponding List URI. In addition to being used for creation, the List URI may be queried to GET lists of resources of the given type that satisfy specified conditions. For example, the ScenarioList URI may be queried to GET the list of all Scenario resources that are defined for a specified Project resource.
Summary Sequence Diagram
The following sequence diagram summarizes Act 1:
The next step is for the software estimator, Syd Ethan, to create an estimate for the scenario.
Next: Act 2. Estimation
Category:EMS Primer
