Notices

Copyright © OASIS Open © 2017. All Rights Reserved.

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/policies-guidelines/trademark for above guidance.


Table of Contents

1. Introduction

This section is non-normative.

1.1 Background and Motivation

Global software delivery is commonplace today. With ever increasing competitiveness, such as faster delivery, competitive cost, and skill availability, it is becoming common for software delivery to be done by collaboration of multiple organizations. Effective collaboration between the multiple organizations require activities to be managed and data to be shared across organizational boundaries. The management of software delivery can be highly challenging due to the diversity of the development process, method, tools and platforms used by organizations participating in the project [SPMC]. As a result, both the information shared and the management used are usually unique to each organization. Typically, manual operations are performed in exchanging proprietary information and in coordinating activities; resulting in inefficient, error-prone and inflexible operations. As the number of organizations involved in software delivery increases, the need for more systematic and open standards-based information sharing and coordination becomes critical. PROMCODE (PROject Management of Contracted Delivery) is an open specification for exchanging project management data across organizational boundaries [PROMCODE13]. PROMCODE leverages OSLC specifications [OSLCCore3] and defines a set of interface specifications as abstraction of data exchanged in many real projects [PROMCODE14].

1.2 Problem and Solution Framework

PROMCODE is intended to provide a common interface to exchange the management data across the organizational boundaries. Figure 1 illustrates a generic model of collaborative software development. A set of organizations, including A, B1, …, Bn, C11, …, C1m, …Cnm, are working together to deliver a software system. We assume two roles between any two organizations working together, that is, acquirer and supplier. The goal of PROMCODE specification is to provide an open standard interface to exchange the management data between acquirer and supplier. Therefore, we only use the role of acquirer and supplier throughout this specification. Here, we assume the schema of management data and its management tool of each organization is different.

Fig. 1 Collaborative Software Development

1.3 PRMCODE Architecture

Figure 2 illustrates an abstract model of the PROMCODE Architecture. The goal of PROMCODE Architecture is to enable to exchange the project management data through the PROMCODE specification between multiple different data models of project management, which are used in multiple different organizations under different management models.

To meet the goal, the PROMCODE specification consists of two layers: PROMCODE Domain Model and PROMCODE Resource as illustrated in Figure 2. The PROMCODE Domain Model is an abstract definition of the structure of the project management data to be exchanged. The Domain Model is derived from common knowledge of project management [PMBOK5] and practice of contracted delivery of software and systems [PROMCODE13], [PROMCODE14].

The PROMCODE Resource defines the data schema of the Domain Model data in terms of RDF resources. The PROMCODE Architecture assumes OSLC Core 3.0 [OSLCCore3] and W3C LDP (Linked Data Platform) [LDP] as the underlying platform. Therefore, the PROMCODE resource is defined based on the OSLC Core 3.0 and W3C LDP.

The PROMCODE client and server are adapters to coordinate the mapping of the organization-specific data model from and to PROMCODE resource, respectively. The interaction between the clients and servers is based on the Resource-Oriented manner [ROA] with HTTP [HTTP11].

For example, Supplier B1 and B2 map their project management data into B1-specific PM Data and B2-Specific PM Data to PROMCODE Resource through their PROMCODE Servers. Acquirer A can collect the project management data of Suppliers B1 and B2 by mapping the PROMCODE Resource of B1 and B2 to A-Specific PM Data. Therefore, PROMCODE Specification can avoid the combinatorial complexity of converting data across the different data models. With PROMCODE specification, Acquirer can collect the project status in real-time with a high degree of traceability [PROMCODE13].

Fig. 2 PROMCODE Architecture

2. Normative and Non-normative

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

3. Terminology

Terminology is based on OSLC Core 3.0 [OSLCCore3], W3C Linked Data Platform [LDP], W3C's Architecture of the World Wide Web [WEBARCH] and Hyper-text Transfer Protocol [HTTP11].

Acquirer
Acquirer is an entity to acquire software and/or system(s).
Supplier
Supplier is an entity to supply software and/or system(s) to be delivered to an Acquirer.
Project
Project is a temporary endeavor undertaken to create unique software and/or system(s) [PMBOK5].
Project Management
Project Management is the application of knowledge, skills, tools, techniques, to project activities to meet project requirements [PMBOK5].
PROMCODE Resource
PROMCODE Resource is an LDP Resource [LDP] to represent project management data.
PROMCODE Service
PROMCODE service is a service to exchange project management data defined by the PROMCODE resource.
PROMCODE Server
PROMCODE Server is an OSLC Server [OSLCCore3], which complies with the LDP Server that also supports the capabilities defined by the PROMCODE specification. See Server [HTTP11] and LDP Server [LDP].
PROMCODE Client
PROMCODE Client is an OSLC Client [OSLCCore3], which complies with the LDP Client that uses the capabilities defined by the PROMCODE specification. See Client [HTTP11] and LDP Client [LDP].

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].

4. PROMCODE Domain Model Specification

This section is non-normative.

4.1 Domain Model

Fig. 3 PROMCODE Domain Model illustrates PROMCODE Domain Model denoted by a UML class diagram.
Fig. 3 PROMCODE Domain Model

In this figure, if no multiplicity is shown on an association end, it implies a multiplicity of zero to unlimited (0 .. *). The multiplicity of an attribute is also omitted for simplification. While its default is a multiplicity of zero to one (0 .. 1), there are exceptional cases where the multiplicity is exactly 1 in which it will be explicitly described as such in the subsequent part of this section.

Each of the following subsections describes each class in the domain model. A name of class starts with a capital letter such as ScopeItem, WorkItem, Artifact, and so on. We will use a class name as a countable noun to denote an instance entity of the class such as a ScopeItem, WorkItems, this Artifact, and so on.

4.1.1 ScopeItem

A ScopeItem is an entity that represents a scope of work from the acquirer's view of a software development contract. It represents a unit of value to be accomplished by the software suppliers in the contract will develop. For example, it may represent a function required, a use case in which the software will be used, a requirement which the acquirer expects, or a screen which will provide some concrete function to the user of the software.

A ScopeItem is not an activity and therefore it cannot be started nor ended. A ScopeItem has size property that is used to determine a contract size between an acquirer and a supplier. This property is not used to track the progress of work. In this sense, a ScopeItem is very different from an Artifact or a WorkItem.

An acquirer can use a set of ScopeItems as managed units to manage a whole scope of development. Both an acquirer and a supplier also use a set of ScopeItems to estimate the scale of development and so the size of each ScopeItem should be estimated. There should be agreement between an acquirer and a supplier on what kind of ScopeItem should be used and on how large each ScopeItem is. Change of some ScopeItem or its estimated size needs another agreement. A ScopeItem can be decomposed into finer grained ScopeItems to be used in detailed management. In that case, a coarse grained ScopeItem may be used to aggregate a set of finer grained ScopeItems.

  • Super Class
    • ManagedItem
  • Attributes
    • plannedSize: Decimal [0 .. 1]
      • An estimated size agreed by both an acquirer and a supplier. The metric and unit of size should be preliminarily agreed on between an acquirer and a supplier. They can be specified as metricOfScopeItemSize and unitOfScopeItemSize of a Project if necessary.
    • actualSize: Decimal [0 .. 1]
      • An actual size agreed by both an acquirer and a supplier.
  • Links
    • isPartOf: ScopeItem [0 .. 1]
      • An ancestor of this ScopeItem.

4.1.2 WorkItem

A work item describes an activity to be performed in a software development contract. It adds details to the description of the 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 forms a work breakdown structure.

A WorkItem is an entity to represent the supplier's internal activity. For example, it may represent a development phase such as analysis, design, implementation, or test. It may also represent a finer grained activity such as document writing, reviewing, or coding. A WorkItem is a managed unit of activity required to implement a ScopeItem or to produce an Artifact.

Progress of a WorkItem is managed by comparing planned and actual dates on which it is started and ended.

A WorkItem can be decomposed into finer grained WorkItems to be used in detailed management. A coarse grained WorkItem is used to aggregate a set of finer grained WorkItems.

  • Super Class
    • ManagedItem
  • Attributes
    • plannedStartDate: DateTime [0 .. 1]
      • A planned date to start this WorkItem.
    • actualStartDate: DateTime [0 .. 1]
      • An actual date to start this WorkItem.
    • plannedEndDate: DateTime [0 .. 1]
      • A planned date to end this WorkItem.
    • actualEndDate: DateTime [0 .. 1]
      • An actual date to end this WorkItem.
  • Links
    • representedBy: Person [0 .. 1]
      • A person responsible for the progress of this WorkItem who may or may not actually do this WorkItem.
    • isPartOf: WorkItem [0 .. 1]
      • An ancestor of this WorkItem.
    • requiredBy: ScopeItem [0 .. 1]
      • A ScopeItem such that this WorkItem is required to implement it.
    • requiredBy: Artifact [*]
      • Artifacts such that this WorkItem is required to produce them. For example, producing specification documents requires interviewing users, writing the initial version, reviewing, reflecting the review comments, approving, and so on.

4.1.3 Artifact

An artifact is a work product that is produced in a project such as design documents, source code, test report, and so on. An artifact may be physical or digital.

An Artifact is produced for a WorkItem or a ScopeItem.

An Artifact can be measured using Measure, and their measured values may vary at each point of time on a Project. The quality of an Artifact is managed by comparing targeted and actual Measures.

An Artifact can be decomposed into finer grained Artifacts to be used in detailed management. A coarse grained Artifact may be used to aggregate a set of finer grained Artifacts.

  • Super Class
    • ManagedItem
  • Links
    • isPartOf: Artifact [0 ..1]
      • An ancestor of this Artifact.
    • producedFor: WorkItem [*]
      • WorkItems which require to produce this Artifact.
    • producedFor: ScopeItem [*]
      • ScopeItems which require to produce this Artifact.
    • targets: Measure [*]
      • Measures planned for this Artifact. Before project execution, the acquirer and the supplier determine which type of measure should be used. Once selected, the measures are traced until project completion. One Artifact can target zero or more Measures.

4.1.4 Risk

A risk is a potential problem that must be controlled before it occurs in order to meet the objectives of a project. Failure to control the situation may result in negative consequences for the project, such as a schedule delay.

After a Risk actually occurs, it typically becomes an Issue.

  • Super Class
    • ManagedItem
  • Attributes
    • identifiedDate: DateTime [0 .. 1]
      • An identified date of this Risk.
  • Links
    • identifiedBy: ManagedItem [*]
      • ManagedItems which identify this Risk. A Risk may be identified by one or more ManagedItems.
    • stateOfRisk: State [0 .. 1]
      • A state of this Risk.

4.1.5 Issue

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

  • Super Class
    • ManagedItem
  • Attributes
    • raisedDate: DateTime [0 .. 1]
      • A raised date of this Issue.
  • Links
    • raisedBy: ManagedItem [*]
      • ManagedItems which raise this Issue. An issue may be raised by one or more ManagedItems.
    • stateOfIssue: State [0 .. 1]
      • A state of this Issue.

4.1.6 ManagedItem

ManageItem is a super class which abstracts five classes, that is, ScopeItem, WorkItem, Artifact, Risk, and Issue.

  • Attributes
    • identifier: String [1]
      • An identifier of this ManagedItem.
    • sequenceNumber: Decimal [0 .. 1]
      • A unique number which represents an order of instances in each subclass of this ManagedItem.
    • title: String [0 .. 1]
      • A name of this ManagedItem.
    • description: String [0 .. 1]
      • A text which describes of this ManagedItem.

4.1.7 Plan

A plan is a collection, or a snapshot, of managed entities which is agreed on between an acquirer and a supplier at project initiation and at the timing when a plan is changed.

A Plan is a ManagedItemCollection which is a collection of planned ScopeItems, WorkItems, and Artifacts together with targeting Measures.

  • Super Class
    • ManagedItemCollection

4.1.8 Report

A report is a collection, or a snapshot, of managed entities which is created by a supplier for project monitoring.

A Report is a ManagedItemCollection which is a collection of ScopeItems, WorkItems, and Artifacts together with associated Measurements and Measures. It represents the situation of the Project on a specific date.

  • Super Class
    • ManagedItemCollection
  • Links
    • correspondsTo: Plan [0 .. 1]
      • A Plan of this Report. A Report is created to the corresponding Plan. If the Plan is changed, the Report is created to the new Plan.

4.1.9 RiskCollection

A risk collection is a collection, or a snapshot, of risks.

Only Risks can be collected in a RiskCollection. It may collect all Risks of the Project on a specific date, all Risks of some category such as in certain state or with priority above some value, and all Risks related to specific ScopeItem.

  • Super Class
    • ManagedItemCollection

4.1.10 IssueCollection

An issue collection is a collection, or a snapshot, of issues.

Only Issues can be collected in an IssueCollection. It may collect all Issues of the Project on a specific date, all Issues of some category such as in certain state or with priority above some value, and all Issues related to specific ScopeItem.

  • Super Class
    • ManagedItemCollection

4.1.11 ManagedItemCollection

ManagedItemCollection is a super class which abstracts four kinds of collections of managed entities, that is, Plan, Report, RiskCollection, and IssueCollection. A ManagedItemCollection must belong to a Project.

  • Attributes
    • identifier: String [1]
      • An identifier of this ManagedItemCollection.
    • title: String [0 .. 1]
      • A name of this ManagedItemCollection.
    • date: DateTime [0 .. 1]
      • A date on which this ManagedItemCollection collects ManagedItems. More specific definition of date is left to a project.
  • Links
    • collects: ManagedItem [*]
      • ManagedItems included in this ManagedItemCollection. A ManagedItemCollection collects any type of ManagedItems such as ScopeItems, WorkItems, Artifacts, Risks, and Issues.
    • belongsTo: Project [1]
      • A Project which this ManagedItemCollection belongs to. A Project has several snapshots until completion. Sometimes a supplier or an acquirer operates several Projects in parallel. The supplier or the acquirer needs to identify which snapshot belongs to which Project.

4.1.12 Measure

A measure is an observation of some measurable quality aspect of an artifact.

A Measure has a metric such as "number of lines of codes (LOC)", "number of found bugs", and so on.

It also has a unit which defines the unit of the numbered value, for example, "1" means one line or one kilo lines. A Measure must be either targeted by one Artifact or observed by one Measurement.

  • Attributes
    • title: String [0 .. 1]
      • A name of this Measure.
    • value: Decimal [1]
      • A value of this Measure.
  • Links
    • metric: Metric [0 .. 1]
      • A metric of this Measure.
    • unitOfMeasure: UnitOfMeasure [0 .. 1]
      • A unit of this Measure.

4.1.13 Measurement

A measurement links between an artifact and actual measures of it. It also represents the date on which the measures are taken.

  • Attributes
    • date: DateTime [1]
      • A date on which an Artifact is measured.
  • Links
    • observes: Measure [*]
      • Measures measured by this Measurement. One Measurement can measure zero or more Measures.
    • measures: Artifact [1]
      • An Artifact measured by this Measurement.

4.1.14 Project

A software development project is a collaborative activity to be executed in a fixed time period and to produce software systems and/or products.

A Project represents the information of the whole project such as the name of the project, the descriptions of the project, and progress of the whole project. A Project also specifies the Metric and the unit of size of ScopeItems because they should be unique in a project.

  • Attributes
    • identifier: String [1]
      • An identifier of this Project.
    • title: String [0 .. 1]
      • A name of this Project.
    • description: String [0 .. 1]
      • A text which describes of this Project.
    • plannedStartDate: DateTime [0 .. 1]
      • A planned date to start this Project.
    • actualStartDate: DateTime [0 .. 1]
      • An actual date to start this Project.
    • plannedEndDate: DateTime [0 .. 1]
      • A planned date to end this Project.
    • actualEndDate: DateTime [0 .. 1]
      • An actual date to end this Project.
  • Links
    • metricOfScopeItemSize: Metric [0 .. 1]
      • A metric of size of ScopeItems in this Project.
    • unitOfScopeItemSize: UnitOfMeasure [0 .. 1]
      • A unit of size of ScopeItems in this Project.

4.2 Samples of Two Project Models

4.2.1 Applying to Progress Management

Table 1 shows a typical progress management table. The table describes the status of implementing Functions defined in the first column. Each Function is divided into a collection of Sub Functions. Each Sub Function has phases of Analysis, Design, and Coding activities. Note that the real management tables are more complex than shown in in real cases. Function-Sub Function forms a tree structure with several levels. There are more activities required to implement Sub Functions.

Table 1 only shows the essential structure of real management tables.

Table 1 Example of Progress Management Table
Function Sub Function Analysis Design Coding
Start End Start End Start End
A A1 Planned 6/4 6/11 6/12 6/19 6/20 6/27
Actual 6/4 6/10 6/11 6/19 6/20 6/26
A2 Planned 6/4 6/11 6/12 6/19 6/20 6/25
Actual 6/4 6/12 6/13 6/20 6/21 6/26
B B1 Planned 6/4 6/11 6/12 6/19 6/20 6/27
Actual 6/4 6/12 6/13 6/20 6/21 6/28

Fig. 4 Example of Project Model for Progress Management illustrates the corresponding project model. Function and Sub Function are subclasses of ScopeItem, and the Analysis, Design, and Coding activities are subclasses of WorkItem. A Function is decomposed into a collection of Sub Functions which have three kinds of required WorkItems for implementation. This structure indicates that all project management data in Table 1 can be represented as instances of the PROMCODE Domain Model classes of ScopeItem and WorkItem.

Fig. 4 Example of Project Model for Progress Management

4.2.2 Applying Quality Management

Table 2 shows a typical quality management table. Main managed entity is Module which is grouped under Requirement. Each Module is measured using several KPIs including lines of code, number of test cases, and number of defects found.

Table 2 Example of Quality Management Table
Requirement Module Line of Code #Test Case #Defect
Target Actual Target Actual Target Actual
R1 M1-1 2,000 2,130 60 62 5 5
M1-2 1,500 1,450 45 43 3 2
R2 M2-1 2,000 1,980 60 65 5 4
M2-2 1,000 950 30 35 2 2

Fig. 5 Example of Project Model for Quality Management illustrates the corresponding project model. Requirement is a subclass of ScopeItem and Module is a subclass of Artifact. A Requirement is used to group Modules that implement it. The structure indicates that all project management data in Table 2 can be represented as instances of PROMCODE Domain Model classes of ScopeItem, Artifact, and Measure.

Fig. 5 Example of Project Model for Quality Management

5. PROMCODE Service Specification

PROMCODE services are a set of services to exchange project management data defined by the PROMCODE resource definitions described in section 6.

This specification is based on OSLC Core 3.0 [OSLCCore3]. PROMCODE servers and clients MUST be compliant with both the [OSLCCore3] specification and this PROMCODE specification, and SHOULD follow all the guidelines and recommendations in both of these specifications.

The following sections describe further restrictions and guidance on requirements of [OSLCCore3].

5.1 Namespaces

In addition to the namespace URIs and namespace prefixes oslc, rdf, dcterms and foaf defined in the [OSLCCore3], PROMCODE defines the namespace URI of http://open-services.net/ns/promcode# with a preferred namespace prefix oslc_promcode. Prefix promcode is used in this specification.

5.2 Service Discovery

There are two approaches described in the OSLC Core Version 3.0 Discovery specification [[OSLC-Discovery-3.0]]. A PROMCODE server SHOULD support dynamic incremental discovery which is utilizing [LDP], and MAY support static up-front discovery which is compatible with [OSLCCore2].

5.2.1 Root Resource

A PROMCODE server which supports dynamic incremental discovery MUST sprovide a project container resource as a root resource. The project container resource MUST be an LDP basic container for project resources.

A PROMCODE server which supports static up-front discovery MUST provide service provider catalog as a root resource that has its oslc:domain property set as http://open-services.net/ns/promcode#.

The root resource can be retrieved at an implementation dependent URI.

5.2.2 PROMCODE LDP Containers

A PROMCODE server which supports dynamic incremental discovery MUST provide a set of LDP containers. The diagram below illustrates the PROMCODE LDP containers and relationships with PROMCODE resources.

Fig. 6 PROMCODE LDP Containers

Black boxes are PROMCODE resources, orange boxes are PROMCODE LDP containers, and lightblue box is an inline resource.

Chapter 6 gives definitions of all these resources. In addition to these resources, there are two additional definitions: ManagedItem and ManagedItemCollection. These are used only as schemas that abstract common properties of other schemas to define resources. Therefore, Fig. 6 does not contain these "abstract" schemas.

All PROMCODE LDP containers MUST be an LDP Basic Container.

5.2.3 Discovery

This section is non-normative.

Steps with dynamic incremental discovery proceed as follows. A PROMCODE client sends an http request to a PROMCODE server to access the project container, the top-level resource the server manages. After getting a list of project resources from the container, it can select the project resource of interest. Then, the client can determine if there is a link from the project resource to each of container resources as in Figure 6 (explained in Section 5.4). If a link to a container exists, resources created by the container are supported by the server. If not, the resources are not supported. For discovery of measurement container, an artifact resource needs to exist and then, the container is obtained by following a link from the artifact resource. Once the existence of each container is assured, the client can send an http OPTIONS message to the container to get a list of all the services supported for the resource created by the container. In this way, a PROMCODE client communicates with a PROMCODE server to get the information on all the resource types the server supports and all the services supported for each of such resource types.

Discovery for static up-front discovery is done as described in OSLC Core 2.0 [OSLCCore2].

5.3 Resource Operations

This section describes frequently used resource operations.

5.3.1 Create Resources

A PROMCODE client can create a PROMCODE resource through a corresponding PROMCODE LDP container if the server supports the dynamic incremental discovery or through a corresponding creation factory if the server supports the static up-front discovery. For example, Plan resource can be created by sending an HTTP POST request to the plan container resource or to an URL of creation factory for Plan resource advertized in Service resource.

Creation of a measure resource is done as part of creation of an artifact or a measurement as inline resource. Therefore there is no need to use a container for measure resources.

In a PROMCODE server which supports dynamic incremental discovery,

  • all the container resources for PlanContainer, ReportContainer, ScopeItemContainer, WorkItemContainer, ArtifactContainer, RiskContainer, IssueContainer, RiskCollectionContainer, and IssueCollectionContainer are created implicitly when a project resource is created, and
  • a measurement container resource is created implicitly when an artifact resource is created.

5.3.2 Update Resources

A PROMCODE server MAY support HTTP PUT or HTTP PATCH method to update resources. The detailed behavior is described in [LDP].

Because a measure is an inline resource, updating the resource in an artifact resource is done by using HTTP PUT or PATCH method of the artifact resource. Updating a measure resource in a measurement resource is done by using HTTP PUT or PATCH method of the measurement resource.

5.3.3 Delete Resources

A PROMCODE server MAY support HTTP DELETE method to delete resources. The detailed behavior is described in [LDP].

Because a measure is an inline resource, deleting an artifact resource or a measurement resource results in deleting the measure resources implicitly.

Container resources for PlanContainer, ReportContainer, ScopeItemContainer, WorkItemContainer, ArtifactContainer, RiskContainer, IssueContainer, RiskCollectionContainer, and IssueCollectionContainer are deleted implicitly when the project resource which links to the container resources is deleted. A measurement container resource is deleted implicitly when the artifact resource which has the measurement Container resource is deleted.

5.4 Query Capabilities

A PROMCODE LDP container MAY include the target URI in a Link header with "http://open-services.net/ns/core#queryCapability" as rel attribute in an HTTP response for a PROMCODE LDP container resource.

Example 1: OSLC Query
Link: <http://example.com/promcode/query>; rel="http://open-services.net/ns/core#queryCapability"; type="oslcQuery" ,
Example 2: SPARQL Query
Link: <http://example.com/promcode/sparql>; rel="http://open-services.net/ns/core#queryCapability"; type="http://www.w3.org/TR/sparql11-query/" 

6. PROMCODE Resource Definitions

Property value types that are not defined in the following sections, are defined in [OSLCCore3]. Descriptions of resources in this chapter assume LDP. For implementation based on OSLC 2.0, resources needed are the subset of all the resources except containers.

6.1 HTTP Requests on PROMCODE Resources

PROMCODE resources are categorized into three kinds: containers when LDP is used, inline resources and top-level resources.

Containers are LDP container resources. Containers MUST accept GET requests which returns the resource with their contents URI as ldp:contains range. Containers MAY accept POST requests to generate new corresponding resource as their contents.

A Measure is an inline resource which can exist inside of an Artifact or a Measurement resource. Thus it only accepts GET request which returns the contents. To provide support of updating Measure resources, PROMCODE servers MAY support PUT or PATCH (or both) on Artifact or Measurement resources.

Top-level resources are represented as references for the range of properties. PROMCODE servers MAY support POST request on corresponding containers to create, PUT/PATCH request on their URL to update, DELETE on their URL to remove them. PROMCODE servers MUST provide GET request support to provide the contents.

PROMCODE servers support following HTTP requests for PROMCODE resources. PROMCODE servers MUST support GET requests and MAY support PUT, POST, PATCH and DELETE requests.

Table 4: HTTP requests for PROMCODE resources
Category Resource type of Http request URI Request type Operation
Container ProjectContainer, PlanContainer,
ReportContainer, RiskCollectionContainer,
IssueCollectionContainer, MeasurementContainer,
ArtifactContainer,ScopeItemContainer,
WorkItemContainer,RiskContainer,
IssueConatiner
GET(MUST) Returns container resource including its ldp:contains contents' URI.
POST Generates resources. However, generating container resources are not supported.
PUT/PATCH Not supported.
DELETE Not supported.
Inline Resource Measure GET(MUST) GET request for Measure resources returns Measure resources as inline resources of an Artifact or a Measurement.
POST Not supported.
PUT/PATCH Not supported. PUT/PATCH request on Artifact or Measurement resource updates these resources including Measure inline resource.
DELETE Not supported. DELETE request on Artifact or Measurement resource deletes these resources including Measure inline resource.
Top-level Resource Project, Artifact, ScopeItem, WorkItem, RiskCollection, IssueCollection, Risk, Issue, Measurement, Plan, Report GET(MUST) Returns the resource.
POST Not Supported.
PUT/PATCH Updates the resource with the request body.
DELETE Deletes the resource.

In addition to these resources explained, there are two additional resources used in this specification: ManagedItem and ManagedItemCollection. These are used as "abstract class" of some top-level resources. More specifically, ManagedItem is a resource that abstracts common properties of ScopeItem, WorkItem, Artifact, Issue and Risks. ManagedItemCollection abstracts common properties of Plan, Report, RiskCollection and IssueCollection. ManagedItem and ManagedItemCollection do not have containers. These resources exist when server starts its operations. These resources are used to define "subclass resources" by using property extension of resource shape of the "subclass resources".

GET operations of ManagedItemCollection should support a flag generateDocument to return document representation of the collection. This applies to GET operations of Plan, Report, RiskCollection and IssueCollection. When the flag is set to True, GET returns a document that represents the collection regardless of its representation. If the flag is set to false, it returns the representation of the property of the collection defined.

6.2 Resource Shape

6.2.1 Typographical Conventions and Use of RFC Terms

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in [RFC2119].

Conventions

In this section, Resource Shape is represented in RDF+Turtle format. The following common URI prefixes are used throughout this section.

Example 3
    @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
    @prefix dcterms: <http://purl.org/dc/terms/> .
    @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
    @prefix oslc: <http://open-services.net/ns/core#> .
    @prefix ext: <http://ww.w3.org/TODO:extendsShapeNameSpace> .
    @prefix ems: <http://open-services.net/ns/ems#> .
    @prefix ldp: <http://www.w3.org/ns/ldp#> .
    @prefix oslc_promcode: <http://open-services.net/ns/promcode#> .

6.2.2 ProjectContainer

A ProjectContainer resource is a container for Project resources. A Project resource can be created by sending an HTTP POST request to a ProjectContainer resource.

  • Name: promcode#ProjectContainer
  • Type URI: http://open-services.net/ns/promcode#ProjectContainer
  • Summary: Shape resource of a ProjectContainer.
promcode#ProjectContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:Project contains is a relation between a ProjectContainer and a Project.

6.2.3 Project

A Project represents the information of the whole project such as the name of the project, the descriptions of the project, and progress of the whole project.

  • Name: promcode#Project
  • Type URI: http://open-services.net/ns/promcode#Project
  • Summary: Shape resource of a Project
promcode#Project Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:description Zero-or-one unspecified string N/A Unspecified description is a property of Projects to help human to understand the abstract of the Project.
dcterms:identifier Exactly-one unspecified string N/A Unspecified A unique identifier for a Project.
dcterms:title Zero-or-one unspecified string N/A Unspecified A title string for a Project.
oslc_promcode:actualEndDate Zero-or-one unspecified dateTime N/A Unspecified actualEndDate is a property of Project that stands for actual end date of the project. Its value is a date-time.
oslc_promcode:actualStartDate Zero-or-one unspecified dateTime N/A Unspecified actualStartDate is a property of Project. It is the actual start date of the project. Its value is a date-time.
oslc_promcode:artifactContainer Zero-or-one true Resource Reference oslc_promcode:ArtifactContainer artifactContainer is a relation between a Project and ArtifactContainer.
oslc_promcode:issueCollectionContainer Zero-or-one true Resource Reference oslc_promcode:IssueCollectionContainer issueCollectionContainer is a relation between a Project and IssueCollectionContainer.
oslc_promcode:issueContainer Zero-or-one true Resource Reference oslc_promcode:IssueContainer issueContainer is a relation between a Project and IssueContainer.
oslc_promcode:metricOfScopeItemSize Zero-or-one unspecified Resource Either Unspecified metricOfScopeItemSize is a relation between a Project and a Metric. It defines a metric of size which all the ScopeItems in the project refer to.
oslc_promcode:planContainer Zero-or-one true Resource Reference oslc_promcode:PlanContainer planContainer is a relation between a Project and PlanContainer.
oslc_promcode:plannedEndDate Zero-or-one unspecified dateTime N/A Unspecified plannedEndDate is a property of a Project. It is the planned end date of the project. Its value is a date-time.
oslc_promcode:plannedStartDate Zero-or-one unspecified dateTime N/A Unspecified plannedStartDate is a property of Project. It is the planned start date of the project. Its value is a date-time.
oslc_promcode:reportContainer Zero-or-one true Resource Reference oslc_promcode:ReportContainer reportContainer is a relation between a Project and Report.
oslc_promcode:riskCollectionContainer Zero-or-one true Resource Reference oslc_promcode:RiskCollectionContainer riskCollectionContainer is a relation between a Project and RiskCollectionContainer.
oslc_promcode:riskContainer Zero-or-one true Resource Reference oslc_promcode:RiskContainer riskContainer is a relation between a Project and RiskContainer.
oslc_promcode:scopeItemContainer Zero-or-one true Resource Reference oslc_promcode:ScopeItemContainer scopeItemContainer is a relation between a Project and ScopeItemContainer.
oslc_promcode:unitOfScopeItemSize Zero-or-one unspecified Resource Either Unspecified unitOfScopeItemSize is a relation between a Project and a UnitOfMeasure. It is unit of volume. It defines volume of size which all the ScopeItems in the Project refer to.
oslc_promcode:workItemContainer Zero-or-one true Resource Reference oslc_promcode:WorkItemContainer workItemContainer is a relation between a Project and WorkItemContainer.

6.2.4 ManagedItem

ManagedItem is a super class which abstracts five kinds of managed entities, that is, ScopeItem, WorkItem, Artifact, Risk, and Issue.

  • Name: promcode#ManagedItem
  • Type URI: http://open-services.net/ns/promcode#ManagedItem
  • Summary: Shape resource of a ManagedItem.
promcode#ManagedItem Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:description Zero-or-one unspecified string N/A Unspecified description is a property of ManagedItem to help human to understand the abstract of the item.
dcterms:identifier Exactly-one unspecified string N/A Unspecified A unique identifier for a ManagedItem, ManagedItemCollection and Project.
dcterms:title Zero-or-one unspecified string N/A Unspecified A title string for a ManagedItem and ManagedItemCollection.
oslc_promcode:sequenceNumber Zero-or-one unspecified decimal N/A Unspecified A unique number which represents an order of each subclass of this ManagedItem.

6.2.5 ScopeItemContainer

A ScopeItemContainer resource is a container for ScopeItem resources. A ScopeItem resource can be created by sending an HTTP POST request to a ScopeItemContainer resource.

  • Name: promcode#ScopeItemContainer
  • Type URI: http://open-services.net/ns/promcode#ScopeItemContainer
  • Summary: Shape resource of a ScopeItemContainer.
promcode#ScopeItemContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:ScopeItem contains is a relation between a ScopeItemContainer and a ScopeItem.

6.2.6 ScopeItem

A ScopeItem defines the work to be included in the Project. It defines the boundaries of the Project.

  • Name: promcode#ScopeItem
  • Type URI: http://open-services.net/ns/promcode#ScopeItem
  • Summary: Shape resource of a ScopeItem which has ext:extendsShape relation to ManagedItem.
promcode#ScopeItem Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_promcode:actualSize Zero-or-one unspecified decimal N/A Unspecified actualSize is a property stands for actual development scale for a ScopItem.
oslc_promcode:isPartOf Zero-or-one unspecified Resource Reference oslc_promcode:ScopeItem isPartOf is a relation between child ScopeItem and its parent ScopeItem. A ScopeItem may have multiple child ScopeItems.
oslc_promcode:plannedSize Zero-or-one unspecified decimal N/A Unspecified plannedSize is a property stands for estimated development scale for a ScopItem.

6.2.7 WorkItemContainer

A WorkItemContainer resource is a container for WorkItem resources. A WorkItem resource can be created by sending an HTTP POST request to a WorkItemContainer resource.

  • Name: promcode#WorkItemContainer
  • Type URI: http://open-services.net/ns/promcode#WorkItemContainer
  • Summary: Shape resource of a WorkItemContainer.
promcode#WorkItemContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:WorkItem contains is a relation between a WorkItemContainer and a WorkItem.

6.2.8 WorkItem

A WorkItem describes an activity to be performed in a software development contract. It adds details to the description of the work that is described by a ScopeItem. These details typically include cost, schedule, and resource requirements. The set of all WorkItems in a project forms a work breakdown structure.

A WorkItem is a managed unit of activity required to implement a ScopeItem or to produce an Artifact.

A WorkItem can be decomposed into finer grained WorkItems to be used in detailed management. A coarse grained WorkItem is used to aggregate a set of finer grained WorkItems.

  • Name: promcode#WorkItem
  • Type URI: http://open-services.net/ns/promcode#WorkItem
  • Summary: Shape resource of a WorkItem which has ext:extendsShape relation to ManagedItem
promcode#WorkItem Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_promcode:actualEndDate Zero-or-one unspecified dateTime N/A Unspecified actualStartDate is a property of a WorkItem. It is the actual end date of the work item. Its value is a date-time.
oslc_promcode:actualStartDate Zero-or-one unspecified dateTime N/A Unspecified actualStartDate is a property of a WorkItem. It is the actual start date of the work item. Its value is a date-time.
oslc_promcode:isPartOf Zero-or-one unspecified Resource Reference oslc_promcode:WorkItem isPartOf is a relation between a child WorkItem and its parent WorkItem. A WorkItem may have multiple child WorkItems.
oslc_promcode:plannedEndDate Zero-or-one unspecified dateTime N/A Unspecified plannedEndDate plannedStartDate is a property of WorkItem. It is the planned end date of the work item. Its value is a date-time.
oslc_promcode:plannedStartDate Zero-or-one unspecified dateTime N/A Unspecified plannedStartDate is a property of WorkItem. It is the planned start date of the work item. Its value is a date-time.
oslc_promcode:representedBy Zero-or-one unspecified AnyResource Either Unspecified 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.
oslc_promcode:requiredBy Zero-or-many unspecified Resource Reference oslc_promcode:Artifact, oslc_promcode:ScopeItem requiredBy is a relation between work items and managed items. A work item may be required by a scope item or an artifact.

6.2.9 ArtifactContainer

A ArtifactContainer resource is a container for Artifact resources. An Artifact resource can be created by sending an HTTP POST request to a ArtifactContainer resource.

  • Name: promcode#ArtifactContainer
  • Type URI: http://open-services.net/ns/promcode#ArtifactContainer
  • Summary: Shape resource of a ArtifactContainer.
promcode#ArtifactContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:Artifact contains is a relation between a ArtifactContainer and Artifact.

6.2.10 Artifact

An Artifact is a work product that is produced in a project such as design documents, source code, test report, and so on. An Artifact may be physical or digital.

  • Name: promcode#Artifact
  • Type URI: http://open-services.net/ns/promcode#Artifact
  • Summary: Shape resource of an Artifact.
promcode#Artifact Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:isPartOf Zero-or-one unspecified Resource Reference oslc_promcode:Artifact isPartOf is a relation between a child Artifact and its parent Artifact. An Artifact may have multiple child WorkItems.
oslc_promcode:latestMeasurement Zero-or-one unspecified Resource Reference oslc_promcode:Measurement latestMeasurement is a relation between an Artifact and Measurement which is latest.
oslc_promcode:measurementContainer Zero-or-one true Resource Reference oslc_promcode:MeasurementContainer measurementContainer is a relation between an Artifact and MeasurementContainer.
oslc_promcode:producedFor Zeor-or-many unspecified Resource Reference oslc_promcode:WorkItem, oslc_promcode:ScopeItem producedFor is a relation between an Artifact and a ScopeItem or WorkItems. Artifacts are produced in the course of implementing scope or doing work items.
oslc_promcode:targets Zero-or-many unspecified Resource Inline oslc_promcode:Measure targets is a relation between an Artifact and Measure. The Measure is an inline resource of the Artifact.

6.2.11 Measure

A Measure is an observation of some measurable quality aspect of an Artifact.

  • Name: ems#Measure
  • Type URI: http://open-services.net/ns/ems#Measure
  • Summary: Shape resource of a Measure
ems#Measure Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:title Zero-or-one unspecified string N/A Unspecified A name of this Measure.
oslc_promcode:metric Zero-or-one unspecified Resource Either Unspecified metric is a relation between a Measure and a Metric. It defines the type of size of Measure.
oslc_promcode:unitOfMeasure Zero-or-one unspecified Resource Either Unspecified unitOfMeasure is a relation between a Measure and a UnitOfMeasure. It is a unit of volume. If an acquirer sums up the same type of measures in the report, the value should be converted according to the unit.
oslc_promcode:value Exactly-one unspecified decimal N/A Unspecified value is a property of a Measure. It is either the actual value of a Measurement or the criteria value of a target Artifact.

6.2.12 RiskContainer

A RiskContainer resource is a container for Risk resources. A Risk resource can be created by sending an HTTP POST request to a RiskContainer resource.

  • Name: promcode#RiskContainer
  • Type URI: http://open-services.net/ns/promcode#RiskContainer
  • Summary: Shape resource of a RiskContainer.
promcode#RiskContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:Risk contains is a relation between a RiskContainer and a Risk.

6.2.13 Risk

Risk is a potential problem that must be controlled before it occurs in order to meet the objectives of the Project. Failure to control the situation may result in negative consequences for the Project, such as a schedule delay.

After a Risk actually occurs, it typically becomes an Issue.

  • Name: promcode#Risk
  • Type URI: http://open-services.net/ns/promcode#Risk
  • Summary: Shape resource of a Risk which has ext:extendsShape relation to ManagedItem.
promcode#Risk Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_promcode:identifiedBy Zero-or-many unspecified Resource Either oslc_promcode:ManagedItem identifiedBy is a relation between a Risk and ManagedItems. A Risk may be identified by one or more ManagedItems.
oslc_promcode:identifiedDate Zero-or-one unspecified dateTime N/A Unspecified identifiedDate is an optional property of a Risk. It is the identified date of the Risk
oslc_promcode:stateOfRisk exactly-one unspecified AnyResource Either Unspecified stateOfRisk is a relation between a Risk and a State. The State resource defines a set of values which represent the state of Risk.

6.2.14 IssueContainer

A IssueContainer resource is a container for Issue resources. An Issue resource can be created by sending an HTTP POST request to a IssueContainer resource.

  • Name: promcode#IssueContainer
  • Type URI: http://open-services.net/ns/promcode#IssueContainer
  • Summary: Shape resource of a IssueContainer.
promcode#IssueContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:Issue contains is a relation between a IssueContainer and an Issue.

6.2.15 Issue

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.

  • Name: promcode#Issue
  • Type URI: http://open-services.net/ns/promcode#Issue
  • Summary: Shape resource of an Issue which has ext:extendsShape relation to ManagedItem.
promcode#Issue Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_promcode:raisedBy Zero-or-many unspecified Resource Either oslc_promcode:ManagedItem raisedBy is a relation between an Issue and ManagedItems. An Issue may be raised by one or more ManagedItems.
oslc_promcode:raisedDate Zero-or-one unspecified dateTime N/A Unspecified raisedDate is an optional property of an Issue. It is the raised date of the Issue. Its value is a date-time.
oslc_promcode:stateOfIssue Zero-or-one unspecified AnyResource Either Unspecified stateOfIssue is a relation between an Issue and a State. The State resource defines a set of values which represent the state of Issue.

6.2.16 RiskCollectionContainer

A RiskCollectionContainer resource is a container for RiskCollection resources. A RiskCollection resource can be created by sending an HTTP POST request to a RiskCollectionContainer resource.

  • Name: promcode#RiskCollectionContainer
  • Type URI: http://open-services.net/ns/promcode#RiskCollectionContainer
  • Summary: Shape resource of a RiskCollectionContainer.
promcode#RiskCollectionContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:RiskCollection contains is a relation between a RiskCollectionContainer and a RiskCollection.

6.2.17 ManagedItemCollection

ManagedItemCollection is a super class which abstracts four kinds of collections of managed entities, that is, Plan, Report, RiskCollection, and IssueCollection. A ManagedItemCollection must belong to a Project.

  • Name: promcode#ManagedItemCollection
  • Type URI: http://open-services.net/ns/promcode#ManagedItemCollection
  • Summary: Shape resource of a ManagedItemCollection.
promcode#ManagedItemCollection Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
dcterms:date Zero-or-one unspecified dateTime N/A Unspecified A date on which this ManagedItemCollection collects ManagedItems.
dcterms:identifier Exactly-one unspecified string N/A Unspecified An identifier for a ManagedItemCollection.
dcterms:title Zero-or-one unspecified string N/A Unspecified A name of this ManagedItemCollection.
oslc_promcode:belongsTo Exactly-one unspecified Resource Reference oslc_promcode:Project belongsTo is a relation between ManagedItemCollections and a Project. A project has several snapshots until completion. Sometimes a supplier or an acquirer operates several projects in parallel. The supplier or the acquirer identifies which snapshot should belong to a Project.
oslc_promcode:collects Zero-or-many unspecified Resource Either oslc_promcode:Issues, oslc_promcode:Risk, oslc_promcode:Artifact, oslc_promcode:WorkItem, oslc_promcode:ScopeItem ManagedItems included in this ManagedItemCollection. A ManagedItemCollection collects any type of ManagedItems such as ScopeItems, WorkItems, Artifacts, Risks, or Issues.

6.2.18 RiskCollection

A RiskCollection is a collection, or a snapshot, of Risks.

Only Risks can be collected in a RiskCollection. Examples are a collection of all Risks of the Project on a specific date, a collection of Risks of some category, such as status, priority, related ScopeItem, and so on.

  • Name: promcode#RiskCollection
  • Type URI: http://open-services.net/ns/promcode#RiskCollection
  • Summary: Shape resource of a RiskCollection which has ext:extendsShape relation to ManagedItemCollection.
promcode#RiskCollection Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_promcode:collects Zero-or-many unspecified Resource Reference oslc_promcode:Risk collects is a relation between RiskCollection and Risk. RiskCollection collects only Risks.

6.2.19 IssueCollectionContainer

An IssueCollectionContainer resource is a container for an IssueCollection resource. An IssueCollection resource can be created by sending an HTTP POST request to an IssueCollectionContainer resource.

  • Name: promcode#IssueCollection
  • Type URI: http://open-services.net/ns/promcode#IssueCollection
  • Summary: Shape resource of an IssueCollection.
promcode#IssueCollection Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:IssueCollection contains is a relation between an IssueCollectionContainer and an IssueCollection.

6.2.20 IssueCollection

An IssueCollection is a collection, or a snapshot, of issues.

Only Issues can be collected in an IssueCollection. Examples are a collection of all Issues of the Project on a specific date, a collection of Issues of some category, such as status, priority, related ScopeItem, and so on.

  • Name: promcode#IssueCollection
  • Type URI: http://open-services.net/ns/promcode#IssueCollection
  • Summary: Shape resource of an IssueCollection.
promcode#IssueCollection Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_promcode:collects Zero-or-many unspecified Resource Reference oslc_promcode:Issue collects is a relation between IssueCollection and Issue. IssueCollection collects only Issues.

6.2.21 PlanContainer

A PlanContainer resource is a container for Plan resources. A Plan resource can be created by sending an HTTP POST request to a PlanContainer resource.

  • Name: promcode#PlanContainer
  • Type URI: http://open-services.net/ns/promcode#PlanContainer
  • Summary: Shape resource of a PlanContainer.
promcode#PlanContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:Plan contains is a relation between a PlanContainer and a Plan.

6.2.22 Plan

A Plan is a ManagedItemCollection which collects ScopeItems, WorkItems, and Artifacts together with the Measures.

6.2.23 ReportContainer

A ReportContainer resource is a container for Report resources. A Report resource can be created by sending an HTTP POST request to a ReportContainer resource.

  • Name: promcode#ReportContainer
  • Type URI: http://open-services.net/ns/promcode#ReportContainer
  • Summary: Shape resource of a ReportContainer.
promcode#ReportContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:Report contains is a relation between a ReportContainer and a Report.

6.2.24 Report

A Report is a collection, or a snapshot, of managed entities which is submitted by a supplier for project monitoring.

A Report is a ManagedItemCollection which collects ScopeItems, WorkItems, and Artifacts together with associated Measurements and Measures. It represents the situation of the Project on a specific date.

  • Name: promcode#Report
  • Type URI: http://open-services.net/ns/promcode#Report
  • Summary: Shape resource of a Report which has ext:extendsShape relation to ManagedItemCollection.
promcode#Report Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_promcode:correspondsTo Zero-or-one unspecified Resource Reference oslc_promcode:Plan correspondsTo is a relation between a Report and a Plan. A Report has at most one correspondsTo relation to the corresponding Plan. If the Plan is changed, a Report is submitted to the new Plan

6.2.25 MeasurementContainer

A MeasurementContainer resource is a container for Measurement resources. A Measurement resource can be created by sending an HTTP POST request to a MeasurementContainer resource.

  • Name: promcode#MeasurementContainer
  • Type URI: http://open-services.net/ns/promcode#MeasurementContainer
  • Summary: Shape resource of a MeasurementContainer.
promcode#MeasurementContainer Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
ldp:contains Zero-or-many unspecified Resource Reference oslc_promcode:Measurement contains is a relation between a MeasurementContainer and a Measurement.

6.2.26 Measurement

A Measurement links between an Artifact and its actual measures. It also represents the date on which the measures are taken.

  • Name: promcode#Measurement
  • Type URI: http://open-services.net/ns/promcode#Measurement
  • Summary: Shape resource of a Measurement
promcode#Measurement Properties
Prefixed Name Occurs Read-only Value-type Representation Range Description
oslc_promcode:date Exactly-one unspecified dateTime N/A Unspecified date is either a property of Measurements or a property of ManagementItemCollection. It is the date on which the measurement was made when it is used in Measurements. It is the date on which the collection is held when it is used in ManagedItemCollection.
oslc_promcode:measures Exactly-one unspecified Resource Reference oslc_promcode:Artifact measures is a relation between measurements and artifacts. A measurement measures an artifact.
oslc_promcode:observes Zero-or-many unspecified Resource Inline oslc_promcode:Measure observes is a relation bewteen a Measurement and a Measure. One Measurement observes zero or many Measures. These Measures are inline resoures of a Measurement.

6.3 Vocabulary

6.3.1 Vocabulary Details

The namespace URI for this vocabulary is: http://open-services.net/ns/promcode#

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 the work to be performed by a supplier.

See Also:
6.3.1.1 RDFS Classes in this namespace

Artifact, ArtifactContainer, Issue, IssueCollection, IssueCollectionContainer, IssueConatiner, ManagedItem, ManagedItemCollection, Measure, Measurement, MeasurementContainer, Plan, PlanContainer, Project, ProjectContainer, Report, ReportContainer, Risk, RiskCollection, RiskCollectionContainer, RiskContainer, ScopeItem, ScopeItemContainer, WorkItem, WorkItemContainer

6.3.1.2 RDF Properties in this namespace

actualEndDate, actualSize, actualStartDate, artifactContainer, belongsTo, collects, correspondsTo, date, identifiedBy, identifiedDate, issueCollectionContainer, issueContainer, latestMeasurement, measurementContainer, measures, metric, metricOfScopeItemSize, observes, planContainer, plannedEndDate, plannedSize, plannedStartDate, producedFor, raisedBy, raisedDate, reportContainer, representedBy, requiredBy, riskCollectionContainer, riskContainer, scopeItemContainer, sequenceNumber, stateOfIssue, stateOfRisk, targets, unitOfMeasure, unitOfScopeItemSize, value, workItemContainer

6.3.1.3 Artifact

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

Artifact is an RDFS class.

An Artifact resource is a work product that is produced in a Project such as design documents, source code, test report, and so on. An artifact may be physical or digital.

6.3.1.4 ArtifactContainer

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

ArtifactContainer is an RDFS class.

An ArtifactContainer resource is a container for Artifact resources. An Artifact resrouce can be created by sending an HTTP POST request to a ArtifactContainer resource.

6.3.1.5 Issue

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

Issue is an RDFS class.

An Issue resource is a situation that must be resolved in order to meet the objectives of a project. Shared issues between an acquirer and a supplier must be managed. Internal issues which can be resolved only by supplier may not be shared. Failure to resolve the situation may result in negative consequences for the Project, such as a schedule delay.

6.3.1.6 IssueCollection

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

IssueCollection is an RDFS class.

An IssueCollection resource is a collection of shared issues. Shared issues of resolved status continue to be included in the collection. Only issue resources can be hold in an IssueCollection as a snapshot. It may collect all Issues of the Project on a specific date, however, it also may collect Issues of some category, such as status, priority, related ScopeItem, and so on.

6.3.1.7 IssueCollectionContainer

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

IssueCollectionContainer is an RDFS class.

An IssueCollectionContainer resource is a container for an IssueCollection resource. An IssueCollection resource can be created by sending an HTTP POST request to an IssueCollectionContainer resource.

6.3.1.8 IssueConatiner

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

IssueConatiner is an RDFS class.

An IssueConatiner resource is a container for Issue resources. An Issue resource can be created by sending an HTTP POST request to an IssueConatiner resource.

6.3.1.9 ManagedItem

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

ManagedItem is an RDFS class.

A ManageItem resource is a super class which abstracts five kinds of managed entities, that is, ScopeItem, WorkItem, Artifact, Issue, and Risk.

6.3.1.10 ManagedItemCollection

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

ManagedItemCollection is an RDFS class.

A ManagedItemCollection resource is a collection of ManagedItems with a specific concern. Any type of ManagedItems, that is, ScopeItems, WorkItems, Artifacts, Issues, or Risks can be collected in a ManagedItemCollection as a snapshot on a specified date. ManagedItemCollection has four subclasses such as Plan, Report, IssueCollection, and RiskCollection. A ManagedItemCollection must belong to a Project.

6.3.1.11 Measure

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

Measure is an RDFS class.

A Measure resource is an observation of some measurable aspect of an Artifact.

6.3.1.12 Measurement

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

Measurement is an RDFS class.

A Measurement resource links between an Artifact and actual measures of it. It also represents the date on which the measures are taken.

6.3.1.13 MeasurementContainer

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

MeasurementContainer is an RDFS class.

A MeasurementContainer resource is a container for Measurement resources. A Measurement resource can be created by sending an HTTP POST request to a MeasurementContainer resource.

6.3.1.14 Plan

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

Plan is an RDFS class.

A Plan resource is a collection, or a snapshot, of ManagedItems which is agreed between the acquirer and suppliers at project initiation. A Plan is a ManagedItemCollection which collects ScopeItems, WorkItems, and Artifacts together with associated Measures.

6.3.1.15 PlanContainer

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

PlanContainer is an RDFS class.

A PlanContainer resource is a container for Plan resources. A Plan resource can be created by sending an HTTP POST request to a PlanContainer resource.

6.3.1.16 Project

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

Project is an RDFS class.

A Project resource represents the information of the whole project such as the name of the project, the descriptions of the project, and progress of the whole project. A Project also specifies the metric and the unit type of size of ScopeItems because they should be unique in a project.

6.3.1.17 ProjectContainer

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

ProjectContainer is an RDFS class.

A ProjectContainer resource is a container for Project resources. A Project resource can be created by sending an HTTP POST request to a ProjectContainer resource.

6.3.1.18 Report

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

Report is an RDFS class.

A Report resource is a collection, or a snapshot, of ManagedItems which is submitted by a supplier for project monitoring. A Report is a ManagedItemCollection which collects ScopeItems, WorkItems, and Artifacts together with associated Measurements and Measures. It represents the situation of the Project on a specific date.

6.3.1.19 ReportContainer

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

ReportContainer is an RDFS class.

A ReportContainer resource is a container for Report resources. A Report resource can be created by sending an HTTP POST request to a ReportContainer resource.

6.3.1.20 Risk

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

Risk is an RDFS class.

A Risk resource is a potential problem that must be controlled in order to meet the objectives of a Project. Shared risks between an acquirer and a supplier must be managed. Internal risks which can be resolved only by supplier may not be shared. Failure to control the situation may result in negative consequences for the Project, such as a schedule delay.

6.3.1.21 RiskCollection

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

RiskCollection is an RDFS class.

A RiskCollection resource is a collection, or a snapshot of shared risks. Shared risks of resolved status continue to be included in the collection. Only risk resources can be collected in a RiskCollection. Examples are a collection of all Risks of the Project on a specific date, a collection of Risks of some category, such as status, priority, related ScopeItem, and so on.

6.3.1.22 RiskCollectionContainer

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

RiskCollectionContainer is an RDFS class.

A RiskCollectionContainer resource is a container for RiskCollection resources. A RiskCollection resource can be created by sending an HTTP POST request to a RiskCollectionContainer resource.

6.3.1.23 RiskContainer

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

RiskContainer is an RDFS class.

A RiskContainer resource is a container for Risk resources. A Risk resource can be created by sending an HTTP POST request to a RiskContainer resource.

6.3.1.24 ScopeItem

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

ScopeItem is an RDFS class.

A ScopeItem resource defines the work to be included in a project. It defines the boundaries of the project.

6.3.1.25 ScopeItemContainer

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

ScopeItemContainer is an RDFS class.

A ScopeItemContainer resource is a container for ScopeItem resources. A ScopeItem resource can be created by sending an HTTP POST request to a ScopeItemContainer resource.

6.3.1.26 WorkItem

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

WorkItem is an RDFS class.

A WorkItem resource describes an activity to be performed in a software development contract. It adds detail to the description of the work that is described by a ScopeItem. These details typically include cost, schedule, and resource requirements. The set of all WorkItems in a Project form a work breakdown structure.

6.3.1.27 WorkItemContainer

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

WorkItemContainer is an RDFS class.

A WorkItemContainer resource is a container for WorkItem resources. A WorkItem resource can be created by sending an HTTP POST request to a WorkItemContainer resource.

6.3.1.28 actualEndDate

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

actualEndDate is an RDF property.

actualEndDate is either a property of a WorkItem or a Project. It is the actual end date of the work item or the project. Its value is a date-time.

6.3.1.29 actualSize

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

actualSize is an RDF property.

actualSize is a property actual development scale for a ScopItem.

6.3.1.30 actualStartDate

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

actualStartDate is an RDF property.

actualStartDate is either a property of a WorkItem or a Project. It is the actual start date of the work item or the project. Its value is a date-time.

6.3.1.31 artifactContainer

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

artifactContainer is an RDF property.

artifactContainer is a relation between a Project and an ArtifactContainer.

6.3.1.32 belongsTo

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

belongsTo is an RDF property.

belongsTo is a relation between ManagedItemCollections and a Project. A project has several snapshots until completion. Sometimes a supplier or an acquirer operates several projects in parallel. The supplier or the acquirer identifies which snapshot should belong to a Project.

6.3.1.33 collects

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

collects is an RDF property.

collects is a relation between a ManagedItemCollection and ManagedItems. A subclass of ManagedItemCollection such as Plan or Report collects any combination of subclasses such as ScopeItem, WorkItem and Artifact. On the other hand, IssueCollection collects only Issues. RiskCollection collects only Risks.

6.3.1.34 correspondsTo

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

correspondsTo is an RDF property.

correspondsTo is a relation between a Plan and a Report. A Report has at most one correspondsTo relation to the corresponding Plan. If the Plan is changed, a Report is submitted to the new Plan

6.3.1.35 date

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

date is an RDF property.

date is either a property of Measurements or ManagementItemCollection. It is the date on which an Artifact is measured in case of Measurements. It is the date on which ManagedItemCollection collects ManagedItems.

6.3.1.36 identifiedBy

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

identifiedBy is an RDF property.

identifiedBy is a relation between a Risk and ManagedItems. A Risk may be identified by one or more ManagedItems.

6.3.1.37 identifiedDate

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

identifiedDate is an RDF property.

identifiedDate is an optional property of a Risk. It is the identified date of the Risk. Its value is a date-time.

6.3.1.38 issueCollectionContainer

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

issueCollectionContainer is an RDF property.

issueCollectionContainer is a relation between a Project and an IssueCollectionContainer.

6.3.1.39 issueContainer

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

issueContainer is an RDF property.

issueContainer is a relation between a Project and an IssueContainer.

6.3.1.40 latestMeasurement

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

latestMeasurement is an RDF property.

latestMeasurement is a relation between an Artifact and Measurement which is latest.

6.3.1.41 measurementContainer

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

measurementContainer is an RDF property.

measurementContainer is a relation between an Artifact and a MeasurementContainer.

6.3.1.42 measures

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

measures is an RDF property.

measures is a relation between a Measurements and an Artifact. A Measurement measures an Artifact.

6.3.1.43 metric

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

metric is an RDF property.

metric is a relation between a Measure and a Metric. It defines the type of size of Measure.

6.3.1.44 metricOfScopeItemSize

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

metricOfScopeItemSize is an RDF property.

metricOfScopeItemSize is a relation between a Project and a Metric. It defines a metric of a size which all the ScopeItems in the project refer to.

6.3.1.45 observes

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

observes is an RDF property.

observes is a relation between a Measurement and a Measure. One Measurement observes zero or many Measures.

6.3.1.46 planContainer

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

planContainer is an RDF property.

planContainer is a relation between a Project and a PlanContainer.

6.3.1.47 plannedEndDate

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

plannedEndDate is an RDF property.

plannedEndDate is either a property of a WorkItem or a Project. It is the planned end date of the work item or the project. Its value is a date-time.

6.3.1.48 plannedSize

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

plannedSize is an RDF property.

plannedSize is a property stands for estimated development scale for a ScopItem.

6.3.1.49 plannedStartDate

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

plannedStartDate is an RDF property.

plannedStartDate is either a property of WorkItem or Project. It is the planned start date of the work item or the project. Its value is a date-time.

6.3.1.50 producedFor

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

producedFor is an RDF property.

producedFor is a relation between an Artifact and a ScopeItem or WorkItems. Artifacts are produced in the course of implementing scope or doing work items.

6.3.1.51 raisedBy

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

raisedBy is an RDF property.

raisedBy is a relation between an Issue and ManagedItems. An Issue may be raised by one or more ManagedItems.

6.3.1.52 raisedDate

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

raisedDate is an RDF property.

raisedDate is an optional property of an Issue. It is the raised date of the Issue. Its value is a date-time.

6.3.1.53 reportContainer

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

reportContainer is an RDF property.

reportContainer is a relation between a Project and a ReportContainer.

6.3.1.54 representedBy

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

representedBy is an RDF property.

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

6.3.1.55 requiredBy

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

requiredBy is an RDF property.

requiredBy is a relation either between a WorkItem and an Artifact, or between a WorkItem and a ScopeItem. A WorkItem, such as reviewing the design, is required by producing Artifacts such as reviewing records. The WorkItem is required by implementing Scopes.

6.3.1.56 riskCollectionContainer

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

riskCollectionContainer is an RDF property.

riskCollectionContainer is a relation between a Project and a RiskCollectionContainer.

6.3.1.57 riskContainer

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

riskContainer is an RDF property.

riskContainer is a relation between a Project and a RiskContainer.

6.3.1.58 scopeItemContainer

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

scopeItemContainer is an RDF property.

scopeItemContainer is a relation between a Project and a ScopeItemContainer.

6.3.1.59 sequenceNumber

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

sequenceNumber is an RDF property.

sequenceNumber is a unique number which represents an order of each subclass of this ManagedItem.

6.3.1.60 stateOfIssue

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

stateOfIssue is an RDF property.

stateOfIssue is a relation between an Issue and a State. The State resource defines a set of values which represent the state of Issue.

6.3.1.61 stateOfRisk

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

stateOfRisk is an RDF property.

stateOfRisk is a relation between a Risk and a State. The State resource defines a set of values which represent the state of Risk.

6.3.1.62 targets

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

targets is an RDF property.

targets is a relation between an Artifact and a Measure. The Measure is an inline resource of the Artifact.

6.3.1.63 unitOfMeasure

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

unitOfMeasure is an RDF property.

unitOfMeasure is a relation between a Measure and a UnitOfMeasure. It is a unit of volume. If an acquirer sums up the same type of measures in report, the value should be converted according to the unit.

6.3.1.64 unitOfScopeItemSize

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

unitOfScopeItemSize is an RDF property.

unitOfScopeItemSize is a relation between a Project and a UnitOfMeasure. It is a unit of volume. It defines a volume of size which all the ScopeItems in the Project refer to.

6.3.1.65 value

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

value is an RDF property.

value is a property of a Measure. It is either the actual value of a Measurement or the criteria value of an Artifact.

6.3.1.66 workItemContainer

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

workItemContainer is an RDF property.

workItemContainer is a relation between a Project and a WorkItemContainer.

Note: Non-normative note on sequenceNumber

The property sequenceNumber is motivated by the need to visually display a list of some ManagedItems (such as a list of ScopeItems, a list of some WorkItems a list of Issues, and so forth) by a management tool such as spreadsheet during the course of project management. When such a list is displayed, it is natural to require that a list follows some order for consistency and for a better user experience. The property is introduced for that. It is required that sequenceNumber is unique in all the resources of the same resource type of ManagedItem, i.e., ScopItem, WorkItem, Artifact, Issues and Risk. Actual values and how they are assigned are not specified by the standard.

7. Use Cases and Scenarios

This section is non-normative.

This chapter describes use cases and use case scenarios, or scenarios for short, for the OSLC PROMCODE Interface Specification Version 1.0. Appendix A gives systems and data flow of scenarios described in this chapter.

We will use the vocabulary based on commonly used terms in many real project management activities in contracted delivery. It is also consistent with global standards such as PMBOK and ISO 21500:2012.

In this chapter and in Appendix A, we use the term acquirer and supplier to refer to the project manager responsible for each organization to manage the project.

7.1 Scope of Use Cases

There are three use cases as shown in Figure 3: project planning, project execution and control, and project closing. Each use case can contain multiple use case scenarios, each of which represents a single path of sequential activtieis to achieve its goal. Details of each use case scenario depend on things such as relationships between an acquirer and a supplier, how much information is shared between then, and tools used and project management environment of an acquirer and a supplier. In this chapter, we will describe simple cases we often see. The environment we assume here is that there is a PROMOCODE server available that can be accessed by both an acquirer and a supplier. We call this environment shared server environment. Each of an acquirer and a supplier uses its own tool to manage their work, and information sharing between them is done by using common PROMCODE server. For simplicity, we assume that the common PROMOCODE server supports all the resources and resource operations described in the PROMCODE specification. This is called PROMCODE full server, as defined in Chapter 8.

Another common case is an environment where there is no common server available between an acquirer and a supplier, and information sharing is done by sending and receiving messages and documents explicitly. We call this environment non-shared environment. A PROMCODE report server as defined in Chapter 8 can be used in such cases. Depending on the information shared between an acquirer and a supplier, other server such as PROMOCE issue server, also defined in Chapter 8, can be used in a similar fashion.

We assume shared server environment in our description of the use cases as mentioned above. For non-shared environment, similar sequence can be used to guide activities of an acquirer and a suppler, and differences on activities will be described in relevant portions in the sequence.

Fig. 7 Scope of Use Cases

7.2 Project Planning

This use case has a single use case scenario.

Preconditions

Project initiation is already completed. Project plan and target goal are agreed on by all the stakeholders. The plan includes the project definiton, scope items that define the work by a supplier, work items to describe the work by the supplier, artifacts to be produced by the supplier and target quality of the artifacts. An acquirer and a supplier also agree on metric and unit size of scope items.

Scenario

  1. An acquirer creates a project resource and a plan resource.

  2. The acquirer then creates resources that need to be included in the plan such as scope item resources, work item resources, artifact resources and measure resources with target value using acquirer's project management tool.

  3. The acquirer publishes these resources to the PROMCODE server using the project management tool it uses.

  4. The PROMCODE server accepts PROMCODE resources and generates the URL for each resource.

  5. The acquirer obtains URLs of these resource and notifies the supplier of the URLs when needed.

In non-shared environment, steps 3-5 will be different. In typical case, sharing is done using a plan resource and a report resource. Each of an acquirer and a supplier uses its own report server that can be accessed by its partner. Then, the first step is for the acquirer to create a project resource and a plan resources and publish them on its PROMOCODE report server. Then, the suppler reads them from the acquirer’s plan server and creates the same resources in its own report server. Creating a plan and a report resources will require creation of other resources such as scope item resources, work item resources, artifact resources and measure resources that are included in the plan resource. If the supplier's report server does not support explicit handling of these resources, the server ensures that these resources can be included in a plan and a report resources by collaborating with supplier's project management tool.

7.3 Project Execution and Control

In the project execution and control use case, there are seven scenarios, i.e., project start, status reporting, review and actions for schedule problems, review and actions for quality problmes, plan change, risk management and issue management. As in the case of Project Planning section of 7.2, scenario descriptions in the subsequent subsections assume the use of common PROMCODE full server shared by the acquirer and the supplier. For non-shared environment, description will be given on the different portions when relevant.

7.3.1 Project Start

Project start scenario is the first step of the project execution and control use case. Systems and data flow of the scenario are described in Project start.

Preconditions

An acquirer collects project information from a supplier and summarizes it with the acquirer's project management tool. A supplier may use a project management tool different from that of the acquirer.
Each tool needs to convert project information to PROMCODE resources and should be able to enter PROMCODE resources to the PROMCODE server and to retrieve them from the server.

Before the project starts, an acquirer and a supplier need to agree on rules and guidance to run and manage the project. This includes reporting frequency and timing, and criteria used for raising and managing issues and risks.

Scenario

  1. An acquirer fills in actual starting date of the project resource with the acquirer's project management tool and submits it to the PROMCODE server.

  2. The PROMCODE server updates the PROMCODE resource.

  3. A supplier retrieves the resource and imports the information to supplier's project management tool.

  4. The supplier starts execution and control of the project using its own project management tool that understands the information.

In non-shared environment, sharing is done by first the acquirer publishing the information in its PROMODE report server and the supplier reading the information. Then, the supplier enters the information to its own report server that works with the supplier's project management tool.

7.3.2 Status Reporting

Status reporting scenario describes reporting activties that take place periodically at pre-agreed timing during the project execution. Systems and data flow of the scenario are described in Status reporting.

Preconditions

The acquirer and the supplier agree on reporting information and its timing. Each time the supplier reports the information, a new report resource is created in the PROMCODE server. The acquire retrieves it to review the information. As in the previous sections, the acquirer and the supplier may use their own propriety project tools for their own management activities.

Scenario

  1. The supplier creates a report resource at agreed timing based on the agreed plan. A report resource collects exactly the same set of resources as the plan with updated properties of some of these resources. More specifically, actual start date and actual end date properties of work items resources and latest measurement property of artifact resources are the updated information in each report. The supplier enters the report resource into the PROMCODE server with supplier's project management tool.

  2. The acquirer's project management tool retrieves the report resource and the resources included in the report resource from the PROMCODE server.

In non-shared environment, this is done by the supplier creating a new report resource into its own report server, and the acquirer accessing it and storing it into the acquirer's report server.

7.3.3 Review and Actions for Schedule Problems

Review and actions for schedule problems scenario is concerned with activities during the project execution that review and take actions on potential schedule problems. Systems and data flow of the scenario are described in Review and actions for schedule problems.

Preconditions

Status reporting is done from the supplier to the acquirer at pre-agreed timing.

Scenario

  1. The acquirer reviews the difference between the previous report resource and the current one, and raises a concern if the following is observed.

    • Condition 1: Progress is not sufficient.

    • Condition 2: Risk of not meeting a schedule emerges with the current pace of progress. The acquirer may use past project data for risk identification.

  2. The acquirer interacts with the supplier on further update.

    • Reasons for delay

    • Outlook of meeting a schedule

  3. Based on the interaction, the acquirer takes one of the following actions.

    1. No formal action, but continue to monitor the situation.

    2. Take an action to mitigate the problem raised by the supplier without plan change. This may include new risk to be identified that results in creation of a risk resource.

    3. Escalate the situation to stakeholders for possible plan change.

  4. If plan change is necessary, it will trigger the scenario of plan change. See details in the Plan Change scenario.

7.3.4 Review and Actions for Quality Problems

This scenario is concerned with activities during the project execution that review and take actions on potential quality problems. Systems and data flow of the scenario are described in Review and actions for quality problems.

Preconditions

Status reporting is done from suppliers to the acquirer at pre-agreed timing.

Scenario

  1. The acquirer compares the previous report and current report and reviews the difference.

  2. The acquirer raises a concern if the progress is not sufficient and there is a risk of not meeting quality goals.

  3. The acquirer interacts with the supplier on further update.

    1. Reasons of the current problem

    2. Outlook of meeting a goal

    3. Assess the impact to the overall project.

  4. Based on the interaction, the acquirer takes one of the following actions.

    1. Stay with the current plan and monitor the situation.

    2. Take an action to mitigate the problem raised by the supplier without plan change. This may include new risk to be identified that results in creation of a risk resource.

    3. Escalate the situation to stakeholders for possible plan change.

  5. If plan change is necessary, it will trigger the scenario of plan change. See details in the Plan Change scenario.

7.3.5 Plan Change

Plan change scenario occurs when change on some parts of a current plan becomes necessary. Typical cases may be change on scope items, change on work items, change on artifacts, change on the collections of resources to be reported, and so on. Reasons for change could be due to change of requirements, possible schedule delay, possible quality issues, and so on. Systems and data flow of the scenario are described in Plan change.

Preconditions

All stakeholders of the project agree on the change of a current project plan.

Scenario

  1. The acquirer decides to change a current plan. The acquirer notifies the supplier of the plan change and proposes a revised plan.

  2. A supplier reviews a revised plan. The acquirer interacts with the supplier for the change, and updates it if necessary.

  3. The acquirer and the supplier agree.

  4. The acquirer creates a new plan resource to represent a revised plan and enters it to the PROMCODE server.

  5. A supplier retrieves a new plan resource from the PROMCODE server.

7.3.6 Risk Management

Risk is an event that may or may not happen in the future with adverse effect to the project. Risk may typically be concerned with project cost, project schedule, project scope, quality, and so forth. Systems and data flow of the scenario are described in Risk management.

Preconditions

Risks are examined by reviewing the information of scope item resources, work item resources and artifact resourcess with their values of properties. The acquirer identifies a collection of risks to be managed for the project.

Scenario

  1. The acquirer evaluates each risk, such as cost overrun, schedule delay and shortage of skills for the project.

  2. The acquirer asks a supplier to create a risk resource by examining the information contained in the previous and current report resources in the PROMCODE server.

  3. The supplier creates a risk resource for each identified risk and registers it in the PROMCODE server. The risk resource has links to other resources that caused the risk to be raised.

  4. The supplier notifies the registration of risks to the acquirer.

  5. The acquirer obtains the information on each risk registered from the PROMCODE server.

  6. The acquirer reviews each risk and determines what action is needed. An action can be to monitor it, to take a mitigation action, or to close it for now. Risks reviewed includes all risk resources including non-closed risk resources registered at previous risk review activities.

In non-shared environment, identifying, reporting and managing risks are done by using PROMCODE issue server, a server that supports risk and issue resources. The server may be different from a report server, or the same server may support both plan/report and risk/issue resources. Its use is similar to that of report server, i.e., either one of an acquirer or a supplier creating risk and/or issue resources, and publishing them in its own issue server and the other retrieving them.

7.3.7 Issue Management

In contrast to risk, issue is an event that already took place that requires attention and resolution to minimize negative impact to the project. Issue management scenario can take place after status reporting scenario, or it can take place on as needed basis during project execution. Systems and data flow of the scenario are described in Issue management.

Preconditions

Issues are raised by examining the information of scope items reources, work item resources and artifact resources with their values of properties. The acquirer determines a collection of issues to be managed for the project.

Scenario

  1. The acquirer evaluates each issue and determines the issues to be managed for the project. The acquirer interacts with the supplier for the evaluation if necessary.

  2. The acquirer asks a supplier to create an issue resource for each issue to be managed by examining the information contained in the previous and current report resources in the PROMCODE server.

  3. The supplier creates issue resources and registers them to the PROMCODE server. Each issue resource has links to other resources that caused the issue to be raised.

  4. The supplier notifies the acquirer of the registration of the issues resources.

  5. The acquirer obtains the information on each registered issue resource from the PROMCODE server.

  6. The acquirer reviews each issue and decides what action is needed for it. An actions can be to take an action to resolve the situation represented by the issue, simply to monitor the situation, or to close it. Issues to be reviewed include all non-closed issue resources including issue resources registered at previous issue review activities.

  7. An issue is closed if the acquirer decides that no resolution action nor monitoring is needed for it.

Activities in non-shared environment are similar to those in Risk Management.

7.4 Project Closing

Use case for project closing has a single scenario closes the project.

Preconditions

All the target of artifacts has been achieved. All the risks and issues are closed.

Scenario

  1. A supplier registers actual end date and actual size of the project resource to the PROMCODE server.

  2. The supplier notifies the registration of the data to the acquirer.

  3. The acquirer obtains the published actual data from PROMCODE server.

  4. The acquirer preserves the whole project information for future work such as project analysis.

In non-shared environment, steps are done by the supplier publishing information into its own report server and the acquirer retrieving it from the report server.

8. Conformance

8.1 Conformance Targets

The PROMCODE specification defines conformance for PROMCODE server implementations and PROMCOE Client Implementations

8.2 PROMCODE server

Chapters 5 and 6 define resources that represent comprehensive range of activities in project management. In practice, it is common that some subset of resources is used in project management. To address the situation, conformance level is introduced.

A PROMCODE server is a basic server if it satisfies the following.:

A PROMOCODE server is a full server if it is a basic server and implements all the resources and their must level operations defined in Chapters 5 and 6 except all the container resources if the server is not an LDP server. If the server is an LDP server, it must also implement all the container resources and their operations in Chapters 5 and 6.

Three subsets of resources are used often in many project management activities: the set of scope item resources, work item resources and artifact resources, the set of plan resources and report resources, and the set of issue and risk resources. Therefore, the following servers are also defined.

A PROMOCODE server is a standard resource server, or standard server for short, if it is a basic server that implements at least ScopeItem, WorkItem and Artifact. A PROMOCODE server is a plan and report server, or report server for short, if it is a basic server that implements at least Plan and Report. A PROMCODE server is an issue and risk server, or issue server for short, if it is a basic server that implements at least Issue and Risk.

8.3 PROMCODE Client

A PROMCODE client conforms this specification if it satisfies the following:

It implements all of 'MUST' level client side resource operations as defined in Chapter 6 for the resources used by the client. These operations are used for obtaining resources from a PROMCODE server.

Appendix A. Systems and Data Flow for Scenarios

This section is non-normative.

This chapter describes example systems and data flows among tools and users for each use case described in Chapter 7.

A.1 Tools

In this chapter, we use the following tools to illustrate the system flow sequences.

PROMCODE server
A PROMCODE full server which supports OSLC PROMCODE Interface Specification Version 1.0. It provides REST services defined in OSLC PROMCODE Interface Specification Version 1.0. It supports the POST and PUT method to create and update PROMCODE resources. Both acquirer and supplier access a common PROMCODE server.
PROMCODE client
A PROMCODE client which provides the user with interface for the following operations. Acquirer and supplier install the PROMCODE client in each environment:

A.2 Assumption (Precondition)

Example 4: ScopeItemSize
<ems:metric rdf:resource="http://open-services.net/ns/ems/metric#Effort" />
<ems:unitOfMeasure rdf:resource="http://open-services.net/ns/ems/unit#PersonMonth" />
Example 5: Measure for Source Code artifact
<ems:metric rdf:resource="http://open-services.net/ns/ems/metric#Sloc" />
<ems:unitOfMeasure rdf:resource="http://open-services.net/ns/ems/unit#Loc" />
Example 6: Measure Test Case artifact
<ems:metric rdf:resource="http://open-services.net/ns/ems/metric#Defects" />
<ems:unitOfMeasure rdf:resource="http://open-services.net/ns/ems/unit#Defect" />

A.3 Scenarios

A.3.1 Project Planning

This scenario illustrates how OSLC PROMCODE 1.0 may be used in the process of starting a project. The corresponding use case is described in Project Planning.

Project planning is the first phase in the lifecycle of a project.

A.3.1.1 Scenario

The first step of project planning is to create a project resource and a plan resource in the PROMCODE server through the PROMCODE client.

  1. The acquirer executes "Create a project and a plan" operation and inputs the following information in the PROMCDE client.

    • project name : "PJ1"

    • plan name : "PN1"

    • planned start date : "2017/3/1"

    • planned end date: "2017/12/31"

    • metric and unit of size of ScopeItem: "Function Point"

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE Sever and retrieves the project container resource. Project container resource is already created by default in the beginning.

Example 7: Request - retrieving a project container
GET /pm/ HTTP/1.1
Host: example.org
Accept: text/turtle
Example 8: Response - retrieving a project container
HTTP/1.1 200 OK 
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#BasicContainer>; rel="type", <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: OPTIONS,HEAD,GET,POST,PUT,PATCH
Accept-Post: text/turtle, application/ld+json
Content-Length: 250
ETag: W/'123456789'
    
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix ldp: <http://www.w3.org/ns/ldp#>.
    
<http://example.org/pm/> a ldp:Container, ldp:BasicContainer .
  1. The PROMCODE client creates a content of new project resource to be created with title "PJ1" in RDF (e.g. Turtle format) with the information set in step 1.

  2. The PROMCODE client submits an HTTP POST request with the content created in step 3 to the project container resource URL.

Example 9: Request - creating a project resource
POST /pm/ HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:Project ;
  dcterms:identifier "100" ;
  dcterms:title "PJ1" ;
  promcode:plannedStartDate "2017-03-01T00:00:00Z" ;
  promcode:plannedEndDate "2017-12-31T00:00:00Z" ;
  promcode:metrixOfScopeItemSize <http://open-services.net/ns/ems/metric#Effort> ;
  promcode:unitOfScopeItemSize <http://open-services.net/ns/ems/unit#PersonMonth> .
  1. The PROMCODE server creates project PJ1 and returns the URL to the PROMCODE client.
Example 10: Response - creating a project resource
HTTP/1.1 201 Created
Location: http://example.com/pm/projects/100
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The PROMCODE client submits an HTTP GET request to the PROMCODE server, retrieves PJ1, and extracts containers.
Example 11: Request - container retrieval after resource created
GET /pm/projects/100 HTTP/1.1
Host: example.org
Accept: text/turtle
Example 12: Response - container retrieval after resource created
HTTP/1.1 200 OK 
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: OPTIONS,HEAD,GET,PUT,PATCH,DELETE
Accept-Post: text/turtle, application/ld+json
Content-Length: 250
ETag: W/'123456789'

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/projects/100>
  a promcode:Project ;
  dcterms:identifier "100" ;
  dcterms:title "PJ1" ;
  promcode:plannedStartDate "2017-03-01T00:00:00Z" ;
  promcode:plannedEndDate "2017-12-31T00:00:00Z" ;
  promcode:metrixOfScopeItemSize <http://open-services.net/ns/ems/metric#Effort> ;
  promcode:unitOfScopeItemSize <http://open-services.net/ns/ems/unit#PersonMonth> ;
  promcode:planContainer <http://example.com/pm/projects/100/planContainer> ;
  promcode:reportContainer <http://example.com/pm/projects/100/reportContainer> ;
  promcode:scopeItemContainer <http://example.com/pm/projects/100/scopeItemContainer> ;
  promcode:workItemContainer <http://example.com/pm/projects/100/workItemContainer> ;
  promcode:artifactContainer <http://example.com/pm/projects/100/artifactContainer> ;
  promcode:riskContainer <http://example.com/pm/projects/100/riskContainer> ;
  promcode:issueContainer <http://example.com/pm/projects/100/issueContainer> ;
  promcode:riskCollectionContainer <http://example.com/pm/projects/100/riskCollectionContainer> ;
  promcode:issueCollectionContainer <http://example.com/pm/projects/100/issueCollectionContainer> .
  1. The PROMCODE client creates a content of new plan resource with title "PN1" in RDF with the information set in step 1.

  2. The PROMCODE client submits an HTTP POST request with the content created in step 7 to the plan container resource URL.

Example 13: Request - creating a plan resource
POST /pm/projects/100/planContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:Plan ;
  dcterms:title "PN1" ;
  promcode:belongsTo <http://example.com/pm/projects/100> .
  1. The PROMCODE server creates plan PN1, and returns the URL to the acquirer.
Example 14: Response - creating a plan resource
HTTP/1.1 201 Created
Location: http://example.com/pm/plans/200
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 

The next step is to fill scope items, work items, and artifacts for plan PN1.

  1. The acquirer inputs all scope items, work items, and artifacts for plan PN1.
Fig. 8 Data in the PROMCODE client
  1. The PROMCODE client submits an HTTP GET request to the PROMCODE server, retrieves plan PN1 and the associated project PJ1. PROMCODE client then extracts container URLs of project PJ1.
Example 15: Request - retrieving plan PN1
GET /pm/plans/200 HTTP/1.1
Host: example.org
Accept: text/turtle
Example 16: Response - retrieving plan PN1
HTTP/1.1 200 OK 
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: OPTIONS,HEAD,GET,PUT,PATCH,DELETE
Accept-Post: text/turtle, application/ld+json
Content-Length: 250
ETag: W/'123456789'

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/plans/200>
  a promcode:Plan ;
  dcterms:identifier "200" ;
  dcterms:title "PN1" ;
  promcode:belongsTo <http://example.com/pm/projects/100> .
Example 17: Request - retrieving project PJ1
GET /pm/projects/100 HTTP/1.1
Host: example.org
Accept: text/turtle
Example 18: Response - retrieving project PJ1
HTTP/1.1 200 OK 
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: OPTIONS,HEAD,GET,PUT,PATCH,DELETE
Accept-Post: text/turtle, application/ld+json
Content-Length: 250
ETag: W/'123456789'

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/projects/100>
  a promcode:Project ;
  dcterms:identifier "100" ;
  dcterms:title "PJ1" ;
  promcode:plannedStartDate "2017-03-01T00:00:00Z" ;
  promcode:plannedEndDate "2017-12-31T00:00:00Z" ;
  promcode:metrixOfScopeItemSize <http://open-services.net/ns/ems/metric#Effort> ;
  promcode:unitOfScopeItemSize <http://open-services.net/ns/ems/unit#PersonMonth> ;
  promcode:planContainer <http://example.com/pm/projects/100/planContainer> ;
  promcode:reportContainer <http://example.com/pm/projects/100/reportContainer> ;
  promcode:scopeItemContainer <http://example.com/pm/projects/100/scopeItemContainer> ;
  promcode:workItemContainer <http://example.com/pm/projects/100/workItemContainer> ;
  promcode:artifactContainer <http://example.com/pm/projects/100/artifactContainer> ;
  promcode:riskContainer <http://example.com/pm/projects/100/riskContainer> ;
  promcode:issueContainer <http://example.com/pm/projects/100/issueContainer> ;
  promcode:riskCollectionContainer <http://example.com/pm/projects/100/riskCollectionContainer> ;
  promcode:issueCollectionContainer <http://example.com/pm/projects/100/issueCollectionContainer> .
  1. The PROMCODE client converts the contents to scope item, work item, and artifact resources in RDF. The PROMCODE client also creates a content of measure resources as a sub-resource of the artifact resource in RDF.

  2. The PROMCODE client submits a set of HTTP POST requests to containers to create scope item, work item, and artifact resources. The PROMCODE server creates new scope item, work item, and artifact resources, and returns the URLs to the PROMCODE client.

Example 19: Request - creating a scope item resource
POST /pm/projects/100/scopeItemContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:ScopeItem ;
  dcterms:title "UI for making a reservation" ;
  promcode:plannedSize "20" .
Example 20: Response - creating a scope item resource
HTTP/1.1 201 Created
Location: http://example.com/pm/scopeitems/1010
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
Example 21: Request - creating an artifact resource with measure resources
POST /pm/projects/100/artifactContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:Artifact ;
  dcterms:title "UI for making a reservation Source Code" ;
  promcode:producedFor <http://example.com/pm/scopeitem/1010> .
  promcode:targets <#measure_1>, <#measure_2> .
  
<#measure_1>
  a promcode:Measure ;
  dcterms:title "Code size (kloc)" ;
  promcode:value "10" ;
  promcode:metricOfMeasure <http://open-services.net/ns/ems/metric#Sloc> ;
  promcode:unitOfMeasure <http://open-services.net/ns/ems/unit#Loc> .

<#measure_2>
  a promcode:Measure ;
  dcterms:title "Number of defects" ;
  promcode:value "10" ;
  promcode:metricOfMeasure <http://open-services.net/ns/ems/metric#Defects> ;
  promcode:unitOfMeasure <http://open-services.net/ns/ems/unit#Defect> .
  
Example 22: Response - creating an artifact resource with measure resources
HTTP/1.1 201 Created
Location: http://example.com/pm/artifacts/2010
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
Example 23: Request - creating a work item resource
POST /pm/projects/100/workItemContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:WorkItem ;
  dcterms:identifier "3010" ;
  dcterms:title "Implement UI for making a reservation" ;
  promcode:plannedStartDate "2017-03-05T09:00:00Z" ;
  promcode:plannedEndDate "2017-03-31T18:00:00Z" ;
  promcode:requiredBy <http://example.com/pm/artifacts/2010> .
Example 24: Response - creating a work item resource
HTTP/1.1 201 Created
Location: http://example.com/pm/workitems/3010
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The PROMCODE client adds scope item, work item, and artifact resources as collects property of plan PN1 so that supplier can retrieve all related information for PN1.

  2. The PROMCODE client submits an HTTP PUT request to update plan PN1.

Example 25: Request - updating plan PN1
PUT /pm/plans/200 HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/plans/200>
  a promcode:Plan ;
  dcterms:identifier "200" ;
  dcterms:title "PN1" ;
  promcode:belongsTo <http://example.com/pm/projects/100> ;
  promcode:collects <http://example.com/pm/scopeitems/1010>, <http://example.com/pm/scopeitems/1011>, 
                <http://example.com/pm/artifacts/2010>, <http://example.com/pm/artifacts/2011>,
                <http://example.com/pm/workitems/3010>, <http://example.com/pm/scopeitems/3011> .
Example 26: Response - updating plan PN1
HTTP/1.1 204 No Content 
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" 
  1. The acquirer sends an e-mail to the supplier to notify URL of plan PN1 and ask the supplier to review it.
A.3.1.2 Summary Sequence Diagram

The following sequence diagram summarizes Project Planning scenario:

Fig. 9 Project planning with PROMCODE

A.3.2 Project Start

This scenario illustrates how OSLC PROMCODE 1.0 may be used in the process of starting a project. The corresponding use case is described in Project Start.

Project start is the first phase in the lifecycle of a project.

A.3.2.1 Scenario

The first step of project start is to set the actual start date of project PJ1.

  1. The acquirer sets URL of project PJ1 to the PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server and retrieves project PJ1.

  3. The acquirer executes "Update a project" operation and sets the actual start date in the PROMCODE client.

  4. The PROMCODE client submits an HTTP PUT request to the PROMCODE server.

Example 27: Request - updating project PJ1
PUT http://example.com/pm/projects/100 HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/projects/100>
  a promcode:Project ;
  dcterms:identifier "100" ;
  dcterms:title "PJ1" ;
  promcode:plannedStartDate "2017-03-01T00:00:00Z" ;
  promcode:plannedEndDate "2017-12-31T00:00:00Z" ;
  promcode:actualStartDate "2017-03-01T00:00:00Z" ;
  promcode:metrixOfScopeItemSize <http://open-services.net/ns/ems/metric#Effort> ;
  promcode:unitOfScopeItemSize <http://open-services.net/ns/ems/unit#PersonMonth> ;
  promcode:planContainer <http://example.com/pm/projects/100/planContainer> ;
  promcode:reportContainer <http://example.com/pm/projects/100/reportContainer> ;
  promcode:scopeItemContainer <http://example.com/pm/projects/100/scopeItemContainer> ;
  promcode:workItemContainer <http://example.com/pm/projects/100/workItemContainer> ;
  promcode:artifactContainer <http://example.com/pm/projects/100/artifactContainer> ;
  promcode:riskContainer <http://example.com/pm/projects/100/riskContainer> ;
  promcode:issueContainer <http://example.com/pm/projects/100/issueContainer> ;
  promcode:riskCollectionContainer <http://example.com/pm/projects/100/riskCollectionContainer> ;
  promcode:issueCollectionContainer <http://example.com/pm/projects/100/issueCollectionContainer> .
Example 28: Response - updating project PJ1
HTTP/1.1 204 No Content 
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" 
  1. The acquirer sends an e-mail to the supplier.

When the supplier receives the notification from the acquirer, the supplier reviews plan PN1 using PROMCODE client and starts execution.

  1. The supplier sets the URL of plan PN1 to PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server and retrieves plan PN1.

Example 29: Request - retrieving plan PN1
GET /pm/plans/200 HTTP/1.1
Host: example.org
Accept: text/turtle
Example 30: Response - retrieving plan PN1
HTTP/1.1 200 OK 
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: OPTIONS,HEAD,GET,PUT,PATCH,DELETE
Accept-Post: text/turtle, application/ld+json
Content-Length: 250
ETag: W/'123456789'

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/plans/200>
  a promcode:Plan ;
  dcterms:identifier "200" ;
  dcterms:title "PN1" ;
  promcode:belongsTo <http://example.com/pm/projects/100> ;
  promcode:collects <http://example.com/pm/scopeitems/1010>, <http://example.com/pm/scopeitems/1011>,
                <http://example.com/pm/artifacts/2010>, <http://example.com/pm/artifacts/2011>,
                <http://example.com/pm/workitems/3010>, <http://example.com/pm/scopeitems/3011> .
  1. The PROMCODE client submits an HTTP GET request to the PROMCODE server and retrieves scope item resources for plan PN1 and displays them.
Example 31: Request - retrieving a scope item resource
GET /pm/scopeitems/1010 HTTP/1.1
Host: example.org
Accept: text/turtle
Example 32: Response - retrieving a scope item resource
HTTP/1.1 200 OK 
Content-Type: text/turtle; charset=UTF-8
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Allow: OPTIONS,HEAD,GET,PUT,PATCH,DELETE
Accept-Post: text/turtle, application/ld+json
Content-Length: 250
ETag: W/'123456789'

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/scopeitems/1010>
  a promcode:ScopeItem ;
  dcterms:title "UI for making a reservation" ;
  promcode:plannedSize "20" .
  1. The supplier reviews the project plan on the PROMCODE client and starts execution.
A.3.2.2 Summary Sequence Diagram

The following sequence diagram summarizes Project Start scenario:

Fig. 10 Project start with PROMCODE

A.3.3 Status Reporting

This scenario illustrates how OSLC PROMCODE 1.0 can be used in the process of status reporting. The corresponding use case is described in Status reporting.

Status reporting is a middle phase during project execution.

A.3.3.1 Scenario

First, the acquirer gets plan PN1 and scope item, work item and artifact resources that are associated with PN1.

  1. The acquirer inputs the URL of plan PN1 to the PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server and retrieves plan PN1 and associated project PJ1.

  3. The PROMCODE client parses plan PN1 and gets URLs of associated resources, such as scope item, work item and artifact resources.

  4. The PROMCODE client then submits an GET request to the PROMCODE server and retrieves the scope item, work item, artifact and measurement resources.

  5. The PROMCODE client parses the resources and displays them.

Next, the acquirer selects resources, and put them into a report resource.

  1. The acquirer selects resources and executes "Create a report" operation on the PROMCODE client.

  2. The PROMCODE client creates a content of new report resource with title "RP1" in RDF.

  3. The PROMCODE client extracts the URL of report container resource from project PJ1, and submits an HTTP POST request with the content created in step 7 to the container.

Example 33: Request - creating a report resource
POST /pm/projects/100/reportContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:Report ;
  dcterms:title "reportX" ;
  dcterms:date "2017-03-15T18:00:00Z" ;
  promcode:belongsTo <http://example.com/pm/projects/100> ;
  promcode:collects <http://example.com/pm/scopeitems/1010>, <http://example.com/pm/scopeitems/1011>,
                <http://example.com/pm/artifacts/2010>, <http://example.com/pm/artifacts/2011>,
                <http://example.com/pm/workitems/3010>, <http://example.com/pm/scopeitems/3011> .
  
  1. The PROMCODE server returns the URL of report RP1.
Example 34: Response - creating a report resource
HTTP/1.1 201 Created
Location: http://example.com/pm/reports/300
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The acquirer gets the URL of report RP1.

  2. The acquirer notifies the URL of report RP1 to the supplier.

Next, the supplier updates the scope item, work item, and artifact resources, and creates measurement and measure resources, based on the current status of the project.

  1. The acquirer enters the URL of report RP1 to PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server and retrieves report RP1 and associated project PJ1.

  3. The PROMCODE client parses report RP1 and gets the list of associated resources, such as scope item, work item and artifact resources.

  4. The PROMCODE client then submits an HTTP GET request to the PROMCODE server and retrieves the scope item, work item, artifact, and measurement resources.

  5. The PROMCODE client displays the resources.

  6. The supplier updates the resources on the PROMCODE client.

Next, the supplier publishes the updated resources to the PROMCODE server.

  1. The supplier executes "Publish a report" operation on the PROMCODE client.

  2. The PROMCODE client creates a content of new measurement resource in RDF with the updates by the supplier. The PROMCODE client also creates a content of measure resources as inline resource of the measurement resource in RDF.

  3. The PROMCODE client extracts the URL of the measurement container resource for each artifact resource, and submits HTTP POST request with the content created in step 20 to the container.

Example 35: Listing of an artifact resource
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/artifacts/2010>
  a promcode:Artifact ;
  dcterms:title "UI for making a reservation Source Code" ;
  promcode:measurementContainer <http://example.com/pm/artifacts/2010/measurementContainer> ;
  promcode:producedFor <http://example.com/pm/scopeitem/1010> .
  promcode:targets <#measure_1>, <#measure_2> .
  
<#measure_1>
  a promcode:Measure ;
  dcterms:title "Code size (kloc)" ;
  promcode:value "10" ;
  promcode:metricOfMeasure <http://open-services.net/ns/ems/metric#Sloc> ;
  promcode:unitOfMeasure <http://open-services.net/ns/ems/unit#Loc> .

<#measure_2>
  a promcode:Measure ;
  dcterms:title "Number of defects" ;
  promcode:value "10" ;
  promcode:metricOfMeasure <http://open-services.net/ns/ems/metric#Defects> ;
  promcode:unitOfMeasure <http://open-services.net/ns/ems/unit#Defect> .
Example 36: Request - creating a measurement resource with measure resources for an artifact resource
POST /pm/artifacts/2010/measurementContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:Measurement ;
  dcterms:date "2017-03-15T18:00:00Z" ;
  promcode:measures <http://example.com/pm/artifacts/2010> ;
  promcode:observes <#measure_1> .
  
<#measure_1>
  a promcode:Measure ;
  dcterms:title "Code size (kloc)" ;
  promcode:value "15" ;
  promcode:metricOfMeasure <http://open-services.net/ns/ems/metric#Sloc> ;
  promcode:unitOfMeasure <http://open-services.net/ns/ems/unit#Loc> .
Example 37: Response - creating a measurement resource with measure resources for an artifact resource
HTTP/1.1 201 Created
Location: http://example.com/pm/measurements/5010
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The PROMCODE client submits an HTTP PUT request to the PROMCODE server to update resources in report RP1.

Listing of resources

Example 38: scope item resource
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/scopeitems/1010>
  a promcode:ScopeItem ;
  dcterms:identifier "1010" ;
  dcterms:title "Reservation System" ;
  promcode:plannedSize "20" ;
  promcode:actualSize "25" .
Example 39: work item resource
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/workitems/3010>
  a promcode:WorkItem ;
  dcterms:identifier "3010" ;
  dcterms:title "Implement Reservation System" ;
  promcode:plannedStartDate "2017-03-05T09:00:00Z" ;
  promcode:actualStartDate "2017-03-05T09:00:00Z" ;
  promcode:plannedEndDate "2017-03-31T18:00:00Z" ;
  promcode:requiredBy <http://example.com/pm/artifacts/2010> .
  1. The supplier sends an e-mail which contains the URL of report RP1 to the acquirer.

Upon the notification, the acquirer starts review of the status of the project.

  1. The acquirer gets the URL of report RP1, then set it to the PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server and retrieves report RP1.

  3. The PROMCODE client parses report RP1 and gets the list of associated resources, such as scope item, work item and artifact resources.

  4. The PROMCODE client then submits an HTTP GET request to the PROMCODE server and retrieves the scope item, work item, artifact, and measurement resources.

  5. The PROMCODE client displays the resources.

  6. The acquirer reviews the resources.

A.3.3.2 Summary Sequence Diagram

The following sequence diagram summarizes Status reporting scenario:

Fig. 11 Status Reporting

A.3.4 Review and actions for schedule problems

The corresponding use case is described in Review and actions for schedule problems. This use case doesn't have any interaction with systems. The scenario continues to the Risk Management scenario.

A.3.5 Review and actions for quality problems

The corresponding use case is described in Review and actions for quality problems This use case doesn't have any interaction with systems. The scenario continues to the Risk Management scenario.

A.3.6 Risk Management

This scenario illustrates how OSLC PROMCODE 1.0 can be used in the process of risk management. The corresponding use case is described in Risk management

A.3.6.1 Scenario

First the acquirer evaluates report RP1 and finds possible risks.

  1. The acquirer sets the URL of report RP1 to PROMCODE client

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server to retrieve report RP1 and associated project PJ1.

  3. The PROMCODE client parses report RP1 and gets the list of associated resources, such as scope item, work item, artifact, measurement and measure resources.

  4. The PROMCODE client displays the resources.

  5. The acquirer then reviews the resources and finds possible risks.

Next, the acquirer registers a risk collection resource that is a placeholder of risks.

  1. The acquirer starts "Create a risk collection" operation on the PROMCODE client.

  2. The PROMCODE client extracts the risk collection container resource from project PJ1.

  3. The PROMCODE client creates a content of new risk collection resource with title "RC1" in RDF, and submits an HTTP POST request with the content to the container.

Example 40: Request - creating a risk collection resource
POST /pm/projects/100/riskCollectionContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:RiskCollection ;
  dcterms:title "RC1" ;
  promcode:belongsTo <http://example.com/pm/projects/100> .
  1. The PROMCODE server returns the URL of risk collection RC1 to the PROMCODE client.
Example 41: Response - creating a risk collection resource
HTTP/1.1 201 Created
Location:http://example.com/pm/riskcollections/800
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The PROMCODE client displays the URL of risk collection RC1.

The acquirer notifies the URL of risk collection RC1 to the supplier, and ask to register possible risks.

  1. The acquirer sends an e-mail which contains the URL of risk collection RC1.

The supplier identifies possible risks during project execution, then the supplier registers risk resources for risk collection RC1.

  1. The supplier sets the URL of risk collection RC1 to the PROMCODE client.

  2. The supplier executes "Create a risk" operation on the PROMCODE client.

  3. The PROMCODE client creates a content of new risk resource with title "RS1" in RDF.

  4. The PROMCODE client extracts a risk container resource from project PJ1, and submits an HTTP POST request with risk RS1 to the container.

Example 42: Request - creating a risk resource
POST /pm/projects/100/riskContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:Risk ;
  dcterms:title "RS1" ;
  dcterms:description "Work load for UI for making a reservation may exceed estimation" ;
  promcode:raisedDate "2017-03-15T20:00:00Z" ;
  promcode:identifiedFor <http://example.com/pm/scopeitem/1010> ;
  promcode:stateOfRisk <http://example.com/project/status#open> .
  1. The PROMCODE server returns the URL of risk RS1 to the PROMCODE client.
Example 43: Response - creating a risk resource
HTTP/1.1 201 Created
Location:http://example.com/pm/risks/8000
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The PROMCODE client submits an HTTP PUT request to the PROMCODE server to update risk collection RC1 to have risk RS1.
Example 44: Request - updating a risk collection resource
PUT http://example.com/pm/riskcollections/800 HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/riskcollections/800>
  a promcode:RiskCollection ;
  dcterms:identifier "800" ;
  dcterms:title "RC1" ;
  promcode:belongsTo <http://example.com/pm/projects/100> ;
  promcode:collects <http://example.com/pm/risks/8000> .
Example 45: Response - updating a risk collection resource
HTTP/1.1 204 No Content 
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" 
  1. The PROMCODE client displays the URL of risk RS1.

  2. The supplier notifies the acquirer that risk collection RC1 is updated.

The acquirer reviews risks in the risk collection RC1 and creates a new issue for risk RS1.

  1. The acquirer sets the URL of risk collection RC1 to the PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server, and retrieves risk collection RC1.

  3. The PROMCODE server returns risk collection RC1 to the PROMCODE client.

  4. The PROMCODE client displays the risk collection RC1.

  5. The acquirer selects risk RS1 on the PROMCODE client.

  6. The PROMCODE client submits an HTTP GET request to the PROMCODE server, and retrieves risk RS1.

  7. The PROMCODE server returns risk RS1 to the PROMCODE client.

  8. The PROMCODE client displays risk RS1.

  9. The acquire reviews risk RS1.

  10. Go to Issue Management scenario to create a new issue if necessary.

The acquirer then closes risk RS1.

  1. The acquirer executes "Close a risk" operation on the PROMCODE client, if risk RS1 is no longer needed.

  2. The PROMCODE client submits an HTTP PUT request to the PROMCODE server to update the statusOfRisk property of risk RS1.

Example 46: Listing of a risk resource
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/risks/8000>
  a promcode:Risk ;
  dcterms:identifier "8000" ;
  dcterms:title "Work load for Make Reservation may exceed estimation" ;
  promcode:raisedDate "2017-03-15T20:00:00Z" ;
  promcode:identifiedFor <http://example.com/pm/scopeitem/1010> ;
  promcode:stateOfRisk <http://example.com/project/status#closed> .
  1. The PROMCODE server returns the closed risk RS1 to the PROMCODE client.

  2. The PROMCODE client displays the closed risk RS1.

A.3.6.2 Summary Sequence Diagram

The following sequence diagram summarizes Risk Management scenario:

Fig. 12 Risk Management

A.3.7 Issue Management

This scenario illustrates how OSLC PROMCODE 1.0 may be used in the process of issue management. The corresponding use case is described in Issue management

A.3.8 Scenario

First, the acquirer registers an issue collection resource that is a placeholder of issues.

  1. The acquirer executes "Create an issue collection" operation on the PROMCODE client.

  2. The PROMCODE client creates a content of new issue collection resource with title "IC1" in RDF.

  3. The PROMCODE client extracts the issue collection container resource from project PJ1, and submits an HTTP POST request with the content created in step 2 to the container.

Example 47: Request - creating an issue collection resource
POST /pm/projects/100/issueCollectionContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:IssueCollection ;
  dcterms:title "IC1" ;
  promcode:belongsTo <http://example.com/pm/projects/100> .
  1. The PROMCODE server returns the URL of issue collection IC1 to the PROMCODE client.
Example 48: Response - creating an issue collection resource
HTTP/1.1 201 Created
Location:http://example.com/pm/issuecollections/710
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The PROMCODE client displays the URL of issue collection IC1.

The acquirer notifies the URL of issue collection IC1 to the supplier.

  1. The acquirer sends an e-mail which contains the URL of issue collection IC1.

The supplier already identifies possible issues during the project execution, then registers issue resources in issue collection IC1.

  1. The supplier sets the URL of issue collection IC1 to the PROMCODE client.

  2. The supplier executes "Create an issue" operation on the PROMCODE client.

  3. The PROMCODE client creates a content of new issue resource with title "IS1" in RDF.

  4. The PROMCODE client extracts an issue container resource from project PJ1, and submits an HTTP POST request with the content created in step 9 to the container.

Example 49: Request - creating an issue resource
POST /pm/projects/100/issueContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:Issue ;
  dcterms:title "IS1" ;
  dcterms:description "Estimation for UI for making a reservation needs to be updated" ;
  promcode:raisedDate "2017-03-16T17:00:00Z" ;
  promcode:raisedFor <http://example.com/pm/scopeitem/1010> ;
  promcode:stateOfIssue <http://example.com/project/status#open> .
  1. The PROMCODE server returns the URL of issue IS1 to the PROMCODE client.
Example 50: Response - creating an issue resource
HTTP/1.1 201 Created
Location:http://example.com/pm/issues/7010
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The PROMCODE client submits an HTTP PUT request to the PROMCODE server to update issue collection IC1 to have the issue IS1.
Example 51: Request - updating an issue collection resource
PUT http://example.com/pm/issuecollections/710 HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/issuecollections/710>
  a promcode:IssueCollection ;
  dcterms:identifier "710" ;
  dcterms:title "IC1" ;
  promcode:belongsTo <http://example.com/pm/projects/100> ;
  promcode:collects <http://example.com/pm/issues/7010> .
Example 52: Response - updating an issue collection resource
HTTP/1.1 204 No Content 
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" 
  1. The PROMCODE client displays the URL of issue IS1.

  2. The supplier notifies the acquirer that issue collection IC1 is updated.

The acquirer reviews issues in the issue collection IC1 and change plan.

  1. The acquirer sets the URL of issue collection IC1 to get the resource to the PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server, and retrieves issue collection IC1.

  3. The PROMCODE server returns issue collection IC1 to the PROMCODE client.

  4. The PROMCODE client displays issue collection IC1.

  5. The acquirer selects issue IS1 on the PROMCODE client.

  6. The PROMCODE client submits an HTTP GET request to the PROMCODE server, and retrieves issue IS1.

  7. The PROMCODE server returns issue IS1 to the PROMCODE client.

  8. The PROMCODE client displays issue IS1.

  9. The acquire reviews issue IS1.

  10. Go to Plan Change scenario to change the plan if necessary.

The acquirer then closes issue IS1

  1. The acquirer executes "Close an issue" operation on the PROMCODE client.

  2. The PROMCODE client changes the statusOfIssue property of issue IS1 to "Closed", and submits an HTTP PUT request to the PROMCODE server.

Example 53: Listing of the issue resource
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/issues/7010>
  a promcode:Issue ;
  dcterms:identifier "7010" ;
  dcterms:title "Estimation for UI for making a reservation needs to be updated" ;
  promcode:raisedDate "2017-03-16T17:00:00Z" ;
  promcode:raisedFor <http://example.com/pm/scopeitem/1010> ;
  promcode:stateOfIssue <http://example.com/project/status#closed> .
  1. The PROMCODE server returns the closed issue IS1 to the PROMCODE client.

  2. The PROMCODE client displays the closed issue IS1.

A.3.8.1 Summary Sequence Diagram

The following sequence diagram summarizes Issue Management scenario:

Fig. 13 Issue Management

A.3.9 Plan Change

This scenario illustrates how OSLC PROMCODE 1.0 may be used in the process of plan change. The corresponding use case is described in Plan Change.

A.3.9.1 Scenario

First, the acquirer gets plan PN1 and associated scope item, work item and artifact resources.

  1. The acquirer inputs the URL of plan PN1 to PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server and retrieves plan PN1 and associated project PJ1.

  3. The PROMCODE client parses plan PN1 and gets the list of associated resources, such as scope item, work item and artifact resources.

  4. The PROMCODE client then submits an HTTP GET request to the PROMCODE server and retrieve the scope item, work item, artifact and measurement resources.

  5. The PROMCODE client displays the resources.

Next, the acquirer updates the scope item, work item, artifact and measure resources for the changes of plan.

  1. The acquirer updates the resources on PROMCODE client

Next, the acquirer publishes the plan resource to the PROMCODE server.

  1. The acquirer executes "Update a plan" operation on the PROMCODE client.

  2. The PROMCODE client submits an HTTP PUT request to the PROMCODE server and updates scope item resources in plan PN1.

Example 54: Listing of ScopeItem resource
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/scopeitems/1010>
  a promcode:ScopeItem ;
  dcterms:identifier "1010" ;
  dcterms:title "Reservation System" ;
  promcode:plannedSize "25" ;
  promcode:actualSize "25" .
  1. The PROMCODE client creates a content of new measure resource in RDF as a sub-resource of the artifact resource.
  2. The PROMCODE client submit HTTP PUT request to the PROMCODE server to update the artifact resource with new target value of code size.
Example 55: Request - updating a measure resource in the artifact resource
PUT /pm/artifacts/2010 HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<http://example.com/pm/artifacts/2010>
  a promcode:Artifact ;
  dcterms:identifier "2010" ;
  dcterms:title "UI for making a reservation Source Code" ;
  promcode:producedFor <http://example.com/pm/scopeitem/1010> .
  promcode:targets <#measure_1>, <#measure_2> .

<#measure_1>
  a promcode:Measure ;
  dcterms:title "Code size (kloc)" ;
  promcode:value "15" ;
  promcode:metricOfMeasure <http://open-services.net/ns/ems/metric#Sloc> ;
  promcode:unitOfMeasure <http://open-services.net/ns/ems/unit#Loc> .
<#measure_2>
  a promcode:Measure ;
  dcterms:title "Number of defects" ;
  promcode:value "10" ;
  promcode:metricOfMeasure <http://open-services.net/ns/ems/metric#Defects> ;
  promcode:unitOfMeasure <http://open-services.net/ns/ems/unit#Defect> .
Example 56: Response - updating a measure resource in the artifact resource
HTTP/1.1 204 No Content 
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" 
  1. The PROMCODE client creates a content of new plan resource with title "PN2" in RDF.

  2. The PROMCODE client extracts the plan container resource from project PJ1, and submits an HTTP POST request with the content created in step 11 to the container.

Example 57: Request - creating an updated plan resource
POST /pm/projects/100/planContainer HTTP/1.1
Host: example.org
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Type: text/turtle

@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix promcode: <http://open-services.net/ns/promcode#> .

<>
  a promcode:Plan ;
  dcterms:title "PN2" ;
  promcode:belongsTo <http://example.com/pm/projects/100> ;
  promcode:collects <http://example.com/pm/scopeitems/1010>, <http://example.com/pm/scopeitems/1011>, 
                <http://example.com/pm/artifacts/2010>, <http://example.com/pm/artifacts/2011>,
                <http://example.com/pm/workitems/3010>, <http://example.com/pm/scopeitems/3011> .
  1. The PROMCODE server returns the URL of plan PN2.
Example 58: Response - creating an updated plan resource
HTTP/1.1 201 Created
Location: http://example.com/pm/plans/201
Link: <http://www.w3.org/ns/ldp#Resource>; rel="type"
Content-Length: 0 
  1. The PROMCODE client displays the URL of plan PN2 so that the acquirer can get the URL.

Now plan PN2 is created and it’s ready to review by the supplier. The acquirer notifies the URL of plan PN2 to the supplier.

  1. The acquirer sends an e-mail which contains the URL of plan PN2.

Upon the notification, the supplier starts review of the change of the plan.

  1. The supplier gets the URL of plan PN2 from the e-mail, then sets it to the PROMCODE client.

  2. The PROMCODE client submits an HTTP GET request to the PROMCODE server and retrieves plan PN2.

  3. The PROMCODE client parses plan PN2 and gets the list of associated resources, such as scope item, work item and artifact resources.

  4. The PROMCODE client then submits an HTTP GET request to the PROMCODE server and retrieves the scope item, work item and artifact resources.

  5. The PROMCODE client displays the resources.

  6. The supplier reviews the resources.

  7. The supplier notifies the result of review to the acquirer.

If necessary, the acquirer update the plan again by walking through the scenario again.

A.3.9.2 Summary Sequence Diagram

The following sequence diagram summarizes Plan Change scenario:

Fig. 14 Plan Change

Appendix B. Change History

This section is non-normative.

Below is a summary of some of the changes in this draft.

Appendix C. Acknowledgments

This section is non-normative.

The editor and authors would like to thank the members of the PROMCODE Consortium for their constructive discussions during the development of the specification.

Appendix D. References

D.1 Normative references

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

D.2 Informative references

[HTTP11]
R. Fielding, Ed.; J. Reschke, Ed.. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7230
[LDP]
Steve Speicher; John Arwe; Ashok Malhotra. Linked Data Platform 1.0. 26 February 2015. W3C Recommendation. URL: https://www.w3.org/TR/ldp/
[OSLCCore2]
Dave Johnson; Steve Speicher. Open Services for Lifecycle Collaboration Core Specification Version 2.0. URL: http://open-services.net/bin/view/Main/OslcCoreSpecification
[OSLCCore3]
Jim Amsden; Martin Sarabura. OSLC Core 3.0. URL: http://tools.oasis-open.org/version-control/browse/wsvn/oslc-core/trunk/specs/oslc-core.html
[PMBOK5]
A Guide to Project Management Body of Knowledge, 5th ed.. URL: http://www.pmi.org/
[PROMCODE13]
PROMCODE (PROject Management of COntracted Delivery), Interface Specification, Version 1. URL: http://www.promcode.org/
[PROMCODE14]
M. Aoyama; K. Yabuta; T. Kamimura; S. Inomata; T. Chiba; T. Niwa; K Sakata. A Resource-Oriented Services Platform for Managing Software Supply Chains and its Experience. URL: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=6928949&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6928949
[ROA]
Roy T. Fielding; Richard N. Taylor. Principled Design of the Modern Web Architecture.
[SPMC]
G. Ruhe; C. Wohlin (eds.). Software Project Management in a Changing World.
[WEBARCH]
Ian Jacobs; Norman Walsh. Architecture of the World Wide Web, Volume One. 15 December 2004. W3C Recommendation. URL: https://www.w3.org/TR/webarch/