OSLC and Reporting

OSLC stands for Open Services for Lifecycle Collaboration .

Open Services for Lifecycle Collaboration (also known as OSLC or Open Services) is a community and set of specifications for Linked Lifecycle Data. The community’s goal is to help product and software delivery teams by making it easier to use lifecycle tools in combination.

If you browse the content of the OSLC wiki you will discover efforts made to define “common specifications for lifecycle resources and the services to access them”. In other words the folks at OLSC try to agree on ways to represent the core aspects of domain artifacts, core aspects that are the same regardless of implementation or vendor.

How does this affect reporting?

Let’s take a simple example: generate a report listing the titles of all requirements in the repository. Sounds simple and it should be simple but it’s not. As soon as we start doing the report we hit the first problem: how do various RM tools represent a requirement and what is the property storing the requirement’s title?

Until now all vendors  invented names for common properties and that made it difficult for human consumers but especially automated consumers ( such as reporting tools) to identify the bits of data you needed. I don’t discuss about API or representation differences, this is handled in the second part of this discussion. Now I will only refer to the process of identifying the property you need, the title of the requirement. You got the title of a requirement in one way from RequisitePro,  in different from RRC and in a 3rd way if it was DOORS.  With OSLC and the common specs and vocabularies the title is always exposed through the dcterms:title property ( read more on Dublin Core). I don’t have to know nor do I have to care what was the original repository.

And that is one of the main points of OSLC: a requirement has a title regardless if it is a ReqPro/DOORS/RRC requirement. In the same way it has a description, a creation date and a bunch of other common properties. What OSLC does is that it defines a vocabulary that all OSLC compliant vendors have to use when exposing their resources regardless if we talk about RM, CM, QM, Modeling etc.

See bellow links for some of the domains that are of interest for reporting with RPE. 

Reporting spec

Not only OSLC works to define common vocabularies and specifications for the various domains but it also works on defining a common Reportable API that can be used to access those resources.

The OSLC Reporting Specification should help solve the questions I chose to defer in the first part of the discussion: the many different APIs exposed by vendors for reporting and the equally large number of ways to represent that data. Not only the APIs and data representation differ wildly between domains (RRC vs RQM) but they also differ between tools from the same domain ( ReqPro vs RRC).  Unicity is good but in this case it does not help consumers and it does not help the tool itself as it prevents integrating it into a larger system.

We are not there yet but that is the direction we are all headed, providers and consumers of Lifecycle data.


Author: Dragos Cojocari

Architect for Rational Publishing Engine

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s