Library > Articles >

Lessons learned when adopting the IBM Systems and Software Engineering Solution

Carlos Ferreira, IBM
Last updated: October 17, 2012
Rational Engineering Lifecycle Manager 1.0

I recently had the opportunity to work on site with customers from all around the world on the Systems and Software Engineering (SSE) Solution Beta. I lead the SSE Jumpstart team, whose responsibility is to understand Systems customers business needs and help them adopt IBM’s new offerings. By working closely with early program customers, we identify where our solution does and does not meet their needs. This allows us to respond more quickly to improve the solution and capture lessons learned before the solution is generally available. Our mission is to make customers and partners successful using the SSE solution and iteratively improve the solution. The SSE Solution helps teams specify, design, implement and validate complex products and the software that powers them. It offers an integrated set of capabilities to enable you to predictably deliver competitive, high-quality products while meeting regulatory and compliance requirements. The Systems and Software Engineering (SSE) Solution includes:

  • IBM Rational DOORS for requirements management
  • IBM Rational Rhapsody and Rhapsody Design Manager for system and software modeling
  • IBM Rational Team Concert(RTC) for project, change, build and source management
  • IBM Rational Quality Manager (RQM) for quality and test management
  • IBM Rational Engineering Lifecycle Manager (RELM) to visualize, analyze and organize engineering data and their relationships
  • IBM Rational Solution Process Assets
The focus of the most recent beta was on IBM Rational Engineering Lifecycle Manager (RELM). This new offering was announced and blogged about by Meg Selfe, Vice President of Complex and Embedded Systems. The purpose of this technical article is to share some of the lessons learned while working with beta customers as they adopted the SSE Solution. The article answers some of the most common business and technical questions asked by the SSE beta customers. This information will hopefully be useful for solution architects and deployment specialists. The SSE solution adoption lessons learned are categorized into four areas:
  1. Business Needs and Capabilities
  2. Solution Architecture
  3. Planning the Deployment and Installation
  4. Using RELM

Business Needs and Capabilities

Here are three key recurring business needs and corresponding capabilities raised by customers who participated in the SSE beta program.

Search and Reuse

Many of the Systems customers are adopting a platforms based approach to drive down costs of developing new products by eliminating the need to custom design and build new components for new products. Car companies are applying these approaches to all aspects of their product designs. Mechanical, electrical and software systems are now being reused across multiple car models. Mobile device companies reuse chips and software across new phones. This platforms based approach to reduce costs has also found its way into defense programs. Government defense agencies are requiring their suppliers to reduce their costs by utilizing more commercial off the shelf (COTS) components and reusing subsystems across different programs. These market trends result in very few projects starting from scratch. New projects or products instead often reference or reuse existing artifacts in their designs. Understanding what artifacts exist or are used in specific products versions or solutions is often difficult. This increases development and maintenance costs. These artifacts can be stored in different repositories scattered throughout the organization. Many of these repositories are not indexed. Often they are not simple web pages that can be crawled by a search engine. Search and reuse involves a time consuming manual process of logging on to each repository to find what you need. RELM working with the SSE Solution allows you quickly find lifecycle artifacts throughout the enterprise, across tools and repositories. It uses Open Services Lifecycle Collaboration and Linked Data recently blogged about by Ben Williams the product manager for RELM.

Managing the Impact of Change

Customer requirements are evolving rapidly. Changing requirements often impact products, systems and software domains. An integrated requirements change management approach requires that you clearly understand what will be changed, who will make and approve the change and how much will it cost. For each domain, teams need to quickly understand how a changed requirement impacts their specific project or product version artifacts. Each team member role must be able to describe and quantify their specific costs and changed artifacts. RELM allows you to more quickly visualize, understand and communicate the impact of changing lifecycle artifacts, systems, and products.

Compliance and Program Status Reporting

Customers often have regulatory compliance reports they must prepare. Data warehouse or manual reporting solutions are not timely. Decision makers and project team members need real time insight into a program or project status. Traditional solutions are often costly to setup or create. RELM provides up to date reporting and direct navigation access to these artifacts so that they can be updated quickly. RELM helps answer questions such as:

  • What shipped in each product version?
  • What were the specific test cases, requirements and design models used to develop that product version?

This allows you to more quickly meet compliance and governance reviews needs.

Solution Architecture

How to Get Started

Start by defining the business needs and how they map to the capabilities provided by the SSE Solution or other tools. Figure 1 shows the core products and corresponding capabilities offered in the Systems Platform.

Figure 1. IBM Rational Systems PlatformIBM Rational Systems Platform

RELM provides product configuration, search, impact analysis and reporting capabilities. The underlying RELM components that provide these capabilities are called Versions Variant and Configuration Services, Lifecycle Query Engine (LQE) and SPARQL Gateway.

First understand how RELM can address your search business needs by identifying which artifacts to search for and what tools and repositories those artifacts are in. These repositories are referred to as “Tracked Resource Set” (TRS) providers. The Tracked Resource Set protocol is not yet public, so for more information contact your IBM representative. RELM’s LQE component allows you to create data sources and index artifacts from repositories that are TRS Providers. These index resources are represented as Resource Description Framework (RDF) triples in the RELM repository. You can learn more about RDF at w3.org. RDF captures how these artifacts are semantically related to each other.

For addressing your impact analysis, reporting and compliance needs, identify the artifacts, products and attributes that you want to report on. Perform a similar analysis of the artifact relationships referenced in the reports. Additionally identify how you want to organize or group your lifecycle artifacts together. These entities can be organized by project, system, sub-system or product. Document how you uniquely identify these entities. This can be a simple attribute, naming convention or version label scheme. RELM provides a SPARQL Gateway component that allows you to create reportable XML data sources from these artifacts and their relationships that are stored as RDF triples in RELM repository. Additionally RELMs product definition tool allows you to create these entities as folders to organize and group artifacts.

SSE Solution Components

RELM v1 provides the greatest value when it is used with the other products in the SSE Solution. The latest product versions of the SSE Solution are TRS Providers:

Other products that support TRS include:

Other products that are being considered or may soon support TRS are included below. Reach out to the respective product managers to learn more about the product roadmap.

Lifecycle Query Engine and Tracked Resources Set

Many of the SSE beta customers were interested in making other software tools and internal system artifacts available in RELM as TRS providers. Other tools are being considered on a case by case basis. A product does not have to be an OSLC Provider or Consumer to be a TRS provider but it does make it easier to implement a TRS provider. A pre-defined OSLC vocabulary makes it easier to define TRS provider artifacts by providing an initial set of industry agreed semantics. These include what are the required or optional attributes and relationship link types. The OSLC Lyo software development kit (SDK) makes it easier to implement an OSLC provider. An example Bugzilla OSLC CM v2 implementation using the Eclipse Lyo SDK is available on Eclipse.org. As mentioned earlier the LQE TRS Protocol is not yet publicly available, but a tutorial on how to implement a LQE TRS Provider Protocol is planned and will available upon approved request to IBM.

  • Note: A product is not automatically a Tracked Resource Provider just because it is an OLSC Provider or Consumer.
Table 1. Tracked Resource Set Vocabularies and OSLC Specifications by Product
Product
Vocabulary
OSLC Specification

Engineering Lifecycle Manager

Draft OSLC Core 2.0 Extensions for PLM

Quality Manager

OSLC-QM v2 Specifications

Team Concert

OSLC-CM v2 Specifications

Requirements Composer

OSLC-RM v2 Specifications

DOORS Next

OSLC-RM v2 Specifications

DOORS

OSLC-RM v2 Specifications

Asset Manager

Same as OSLC Asset v2 Specification

OSLC_Asset v2 Specificatons

Rhapsody Design Manager

DM Core vocabulary

RSA vocabulary:

Rhapsody vocabulary:

OSLC-RM v2 Specifications

OSLC-AM v2 Specifications

Focal Point

Is an OSLC Core provider and doesn’t implement any domain. In practice, you can treat it like an RM provider.

Rational SPARQL Gateway

SPARQL is a querying language for RDF databases analogous to SQL for relational databases. Its power lies in being able to query across RDF artifacts and their relationships that span multiple repositories. RELM supports SPARQL v1.1. Many of the SSE beta customers were interested in reporting on or exporting cross domain artifact reports in PDF, Excel or CSV format. One of RELM’s core capabilities is to provide near real-time reporting across tools and repositories. The SPARQL Gateway component included with RELM allows you to create reportable XML data sources the from the RDF results returned by the RELM SPARQL queries. Additionally RELM allows you to deploy Rational Publishing Engine (RPE) templates that format these XML data sources into reports that can be easily printed or exported to CSV, Excel or PDF formats.

  • Tip:  For historical or trending reports consider Rational Insight. Also consider existing reporting technologies within each SSE product

A tutorial on how to create a RELM report by deploying RPE templates and setting up a SPARQL Gateway reportable data source will be available shortly. Consider reaching out to IBM Software Services Rational (ISSR) and SSE Jumpstart for help on how to SPARQL Gateway data sources and deploy RPE report templates.

Define the SSE Solution Information Model

For each artifact type you want to search, view, analyze or report on in RELM, clearly identify which attributes and relationships are required. Verify that these are available in the TRS Vocabulary for each TRS Provider using the vocabularies provided in Table 1.

  • Tip:   Not all SSE Product artifact types and data can be published to LQE. Here are a couple of notable artifacts and attributes that are not yet available in RELM v1.
    • Rational Team Concert V4.0 does not yet expose source code and Plan items in the LQE index
    • Rhapsody Design Manager V4.0 does not yet expose element stereotypes in the LQE index

If some TRS Provider attributes are not available consider other ways you might be able to achieve the same result. For example, adding a comment or tag to the artifact. If the required relationships do not exist between resources, create the linkages between the two resources using RELM product definition tool. A relationship can be created by adding the related resources to a common product definition container.  This allows you to perform impact analysis in RELM or create need reports. If some artifacts are not available consider other ways you might be able to get the artifacts into an LQE. Evaluate each SSE product’s ability to import artifacts and make their data available within LQE. For example:

  • Microsoft Word, Excel, PDF and other artifacts can be added to an asset that is then published in Rational Asset Manager to be indexed. These assets and artifacts then become searchable and available in LQE
  • Mathworks Simulink models can be imported into Rhapsody Design Manager and then become searchable within RELM

When identifying cross artifact tool RELM queries, map terminology differences across tool artifacts. For example a state in one tool may be equivalent to a state in another tool that has a different name. Understanding these mappings are important as you begin to define the SPARQL query syntax that you will implement for your reports and views.

Consider Deployment Needs and Constraints

Consider your deployment needs and constraints when defining your solution architecture. You likely already have a Deployment topology model. If you do you can map the artifacts in your SSE Solution information model to project areas, tools, repositories and physical servers in your Deployment Topology model. Creating this visual representation allows you to better communicate, plan and deliver your RELM and SSE deployment.

Figure 2.  Example Information Model to Deployment Topology Mapping Information Model to Deployment Topology Mapping

Planning for SSE Environment and Installation

Taking time to plan the SSE deployment environment and installation will save you time later by helping you avoid delays. For each of the solution architecture layers ensure you have completed the required preparation steps. It is often helpful to have both a production and test environment setup to be able to verify you RELM and SSE installation and configuration. Involve your Information Technology (IT) and Security organization early in your planning efforts. Identify the work break-down tasks associated with each level of the SSE Solution architecture by domain role. The sections that follow use the information model in Figure 2 to provide example preparation steps.

Topology Considerations

Settle on which type of RELM/SSE topology you will use. The three IBM Rational SSE Solution topologies available are evaluation/project level, departmental level and enterprise deployment topology. The topologies for SSEA 2012 are in the final stages of being validated and published in the IBM Information Center. The box in Figure 2 showing the artifacts being reported and searched for will become the data that is stored in the RELM LQE application. For evaluation purposes you can install RELM LQE into your existing Jazz Team Server (JTS). For larger deployments you will want to have RELM and LQE have its own dedicated server as shown in the SSEA enterprise topologies.

Hardware

See the RELM and SSE solution hardware requirements for each product. A quick way to get this is to use the software product compatibility reports

Network

Take care in ensuring that required network ports aren’t already in use or blocked by the firewall. On Windows do a netstat-a and review the installation documents for which ports are required by product and how to change them. Anticipate additional network load during the initial TRS provider indexing and updates to RELM. RELM polls each of the repositories checking for change log events since the last time the TRS provider was checked.

Jazz Team Server

Establish OAuth friend relationships between the RELM JTS server and other servers. These friend relationships allow JTS servers to authenticate and communicate with each other. This enables RELM to make the needed authenticated requests to index and poll these other repositories for artifact changes and provide the OSLC artifact preview capabilities. Clearly document the required JTS friend relationships and in what direction the requests will be made. For the JTS being administrated, what requests for information being received are “inbound” from other servers, versus requests for information being made “outbound” to other servers. For example for the OSLC artifact previews to work on the RELM product definition tool page, the tool that owns the linked object has to be registered as an Outbound friend of RELM on the JTS server RELM is installed on. If you get an error message “Unknown Provider” with the OSLC previews, this means the artifact’s JTS is not registered as a friend. If you get a permission errors check also that you have assigned Client Access Licenses to each user for the each of the products being accessed by the user.

  • Tip:   Expiring or changing database user id credentials will require you to rerun JTS Setup.

In Figure 2, the box representing the reports and artifact types will be a separately installed JTS with LQE and RELM installed as Jazz Applications.

Jazz Applications

Create the necessary user ids and authorization access privileges to allow RELM LQE to poll and retrieve change artifact sets from the Data Source project areas. For each tool on a separate JTS you must create the appropriate link type for each project areas and artifact type to enable OSLC preview. Using the SSE information model in the above example, create a table of the relationships like the one below.

Table 2. JTS Friends Associations, Ports and Keys:

App

JTS Server & Port

Key

Project Area

Link Type

Artifact Type

Key

App

JTS Server & Port

Project Area

RTC1

JTS1:

9090

xyz

RTC Problem Reporting Project Area 1

Provides

Problem Requests

xyz

RTC2

JTS2:9080

BU A Defect Project Area 1

RELM

LQE

JTS3:

9070

xyz

RELM Project

Uses

Problem Requests

xyz

RTC1

JTS1:9090

RTC Problem Reporting Project Area 1

 

xyz

RELM Project

Uses

Problem Escalations

xyz

RTC2

JTS2:9080

BU A Defect Project Area 1

 

xyz

RELM Project

Uses

Defects

xyz

DOORS

JTS2:9080

BU A Defect Project Area 1

 

xyz

RELM Project

Uses

Requirements

xyz

DWA1

DWA1

Module BU A

Software

See the RELM and SSE solution software requirements for each product. A quick way to get this is to use the software product compatibility reports. RELM supports the latest versions of the SSE Solution. In order for RELM to index Rhapsody models, Rhapsody Design Manager must be installed. In order for RELM to index DOORS requirements, DOORS Web Access must be installed. See LQE Guidance. Do not forget to include other software that maybe required to complete your installation:

  • Rational Installation Manager v1.5
  • Rational License Manager

Sizing and Capacity Planning

This section provides some observations made regarding Sizing and Capacity Planning during the RELM SSE beta. At the time this paper was written no SSE Solution Sizing article or paper is available. However there are product specific resources available in the table below.

  • Tip:  Use existing individual SSE product hardware sizing and tuning guides. Carefully consider the additional HTTP load imposed by RELM on already deployed SSE products.
Table 3.  Sizing References Available

Scaling DOORS Web Access

http://www.ibm.com/developerworks/rational/library/scale-load-balancing/index.html

Sizing Collaborative lifecyle Management (CLM) 2011

https://jazz.net/library/article/641

Sizing CLM 2012

https://jazz.net/library/article/814

Sizing RELM

Under Development

Sizing LQE

https://jazz.net/wiki/bin/view/Main/LQEDocumentation

Sizing RDM

https://jazz.net/wiki/bin/view/Main/LQEDocumentation

Sizing Rhapsody Design Manager

Under Development

Carefully consider the additional performance implications of RELM. How many artifacts will be indexed? How frequently will the TRS providers be polled for change log events? Have you validated your transaction response times with similar loads in a test environment? Also consider the additional HTTP load that will be imposed by RELM LQE polling each of the tool repositories. There is a trade off between ensuring data is up to date in RELM by increasing the frequency of polling the TRS providers and resultant increased network and HTTP request loads on the SSE Web servers.

Licenses Required

There are several types of license keys required to utilize the RELM and SSE solution. There are product license keys that give an individual user access to the software for customers who have purchased or are evaluating the product. Jazz products are licensed enforced by Jazz licensing included with the Jazz Team Server installation. DOORS and other Rational products are license enforced using a FlexLM licensing server. It is separately installed using Rational License Key Administrator v8.1.3. Use this support reference to figure out if you have all the right license keys and License Servers required. RELM is licensed as floating and authorized user (AU) and uses Jazz Licensing. Evaluation license keys are included with RELM and many of the other SSE products. For RELM they expire 60 days from the time you install and accept the product license agreement. Request additional evaluation keys from your IBM representatives. Quantifying the number of floating licenses required by RELM is customer specific based on the amount of RELM usage. Customers should monitor usage over time to see when concurrent usage begins to approach the number of floating keys available.

RELM also supports token license keys. Tokens allow you access to use multiple products defined in the token product set. Each Rational product consumes a predetermined amount tokens for each concurrent usage. This requires setting up the Rational Common Licensing token service keys

There are internal client access license keys that allow the SSE Solution products to access RELM LQE. This license key referred to as TRS Consumer Internal key is used by internal system generated LQE_user and JTS_user to access RELM LQE. When you install RELM LQE these license keys need to be assigned to these users. A simple way to remember when a license is consumed is to keep track of when a user logs in to a tool. Here are several scenarios

Table 4.  Activities and Licenses Used

Step

Activity

License Used

1

User logs into RELM

Searches for product artifacts

Runs a SPARQL query

RELM (Floating or AU)

2

User Authorizes their credentials

Reviews SSE artifact and RELM product data from the RELM LQE index

RELM (Floating or AU)

3.

User invokes RELM View to see program status

User hovers over artifact in view uses OSLC preview of artifact data or navigates to artifact requiring a login (Work Item in RTC, Design Element in RDM, Test case in RQM etct)

RELM, Each tool the person navigates too or does an OSLC preview on

4

User updates the RTC Work item they navigated to

RTC

5

LQE_User internal user monitors RTC for change log events detects updated work item and updates the index

TRS Consumer Internal key

(RTC license is not used)

6

User refreshes their RELM view and sees the updated program status.

RELM (Floating or AU)

7

User does other activities and his session times out after 30 mins

RELM (Floating or AU) is no longer used.

NA

User logs out of RELM

RELM (Floating or AU) is no longer used.

NA

User programmatically calls RELM Rest interfaces via SPARQL Query required to login with a user id

RELM (Floating or AU)

NA

User programmatically logs out of RELM REST interfaces

RELM (Floating or AU) is no longer used

Installation Instructions

Carefully follow the installation instructions for each of the SSE products. The RELM Information Center provides a useful summary of each of the installation steps with links to each products installation instructions. Augment these installation instructions with the step by step screen shot instructions provided for the SSE Solution on the IBM Developer works site.

Using RELM

This section provides some observations made during the RELM SSE beta regarding views, queries and product configurations. RELM is accessed primarily through a web client. Users must reauthorize LQE to query on their behalf for all the applications being queried by LQE. Users must reauthorize for each web browser session.

View

RELM views provide a way for you to create your own user interface for visualizing RELM Product information and LQE artifacts. To effectively use this powerful flexibility, consider establishing user interface standards for views like standard fonts, font sizes, icons and colors, line colors and thicknesses etc. This will ensure you have a consistent and easy user experience across project teams and tools.

Figure 3.  Custom Created RELM View Widest possible image

Recognize that views provide a visual representation of your systems and become less usable when the number of items grows beyond 100. Consider other approaches like adding category filters similar to those shown in the Figure 2. Filters were added for products, commitment status and priority and technology domain for features. Another option is to setup views to be recursive where you can “dive in” by calling the same view or other views with a passed parameter. From the resource menu you can create custom actions that allow you to call other views and pass in a child ID of the currently selected resource in the current view. When result sets become too large for views, consider providing the information in other formats. Utilize the output from a RELM query or setting up a SPARQL Gateway data source to represent the data in a tabular format.

Views do not have to be limited to showing predefined relationships like is in the case with RELM Impact Analysis. By introspecting TRS artifact attributes, RELM allows you to create other visual linkages between artifacts and view containers in a view. Views provide a way to see artifacts using OSLC and browse and navigate to artifacts.

Queries

RELM queries provide the data that is displayed in RELM views and reports. Similar to SQL, care should be used to optimize your performance of your queries.

  • Tip:  To improve performance, have LQE only index the JTS Application repositories, DOORS modules, RDM streams etc that you require.

Do the initial index of large repositories off hours or during the weekend when network and server capacity is not as demanding. Initial indexes will take some time. Subsequent indexing of data sources is incremental. Only the resources that have changed will be indexed and this will likely be faster. RELM queries default to returning no more than 1000 results. You must increase this setting in LQE if you want to return more results. Consider increasing Feed Query Maximum Entries in JTS Server, Advanced Properties

  • Note:  RELM V1 does not include a SPARQL Query Builder user interface.

Writing SPARQL queries requires some technical skills. These queries however can be extremely powerful and worth the time invested learning how to create them. Here is an example SPARQL query provided by Nick Crossley, that queries across multiple artifact types, relationships and repositories to find all the artifacts impacted by a change to a change request.

    # Description: Find resources impacted by a change to a Change Request  # Follows links such as CR->tracks->REQ->[elaboratedBy->REQ | specifiedBy->REQ]->[verifiedBy->TC | elaboratedBy->ME]  # Prefixes omitted for brevity …    SELECT ?cr ?type ?title ?owner  WHERE  {  	?cr a oslc_cm:ChangeRequest ;  		dcterms:identifier ?id ;  		(oslc_cm:tracksRequirement|oslc_rm:trackedBy|oslc_rm:elaboratedBy|oslc_rm:specifiedBy|oslc_rm:validatedBy)* ?uri .  	?uri dcterms:title ?title  	OPTIONAL  	{  		?uri rdf:type/rdfs:label ?type ;  	}  	OPTIONAL  	{  		{ ?uri dcterms:contributor/foaf:name ?owner }  		UNION  		{ ?uri dcterms:contributor ?owner FILTER NOT EXISTS { ?owner foaf:name ?x } }  	}  }    # Either provide one or more work item ID numbers here,  # or remove or comment out the entire section to look at all work items  VALUES ?id  {  	"626"^^xsd:string  	"627"^^xsd:string  }

License terms that govern use of this SPARQL Query can be found here.

Product Definitions

The RELM product definition tool allows you to organize versions and variants of your artifacts. Carefully consider how these entities can vary and be organized. These variations can be a temporal context representing model or product year or project schedule time intervals like an iteration name. Temporal context can be represented as RELM entity variants and branches which allow you to create multiple streams of these entities. This organization allows you to more easily maintain and reuse entities by understanding which lifecycle artifacts are used in each entity variation. This also makes it easier to filter artifacts down to only those that apply to a particular variant, branch or version. RELM product definition entities do not have to be just products. They could be systems, subsystems, project or other units of organization. The level of granularity for creating product definition folders will likely be higher level product structures driven by reuse or reporting needs. Several customers in the beta created RELM product definition entities to represent project teams. Others created logical subsystem entity grouping that crossed both product hardware and software boundaries. Documenting these items is a way to capture your SSE Solution Information model. With this information, it will be easier and faster to configure RELM and the other SSE products.

  • Tip:  Not all SSE Product artifacts can be version specific. RDM elements and RELM Products can be versioned in RELM v1.

Product definitions allow you to create a relationship between artifacts. This maybe helpful for creating impact analysis in cases where these artifacts do not have predefined OSLC artifact relationships in their TRS vocabularies. By selecting the product you can see the impact of any of these two artifacts changing.

One option for sharing RELM product definitions with others in the organization is to create a SPARQL Gateway end point as a REST data source. Some RELM Beta customers were interested in importing product definitions into RELM. For RELM v1 you must enter product definitions using the RELM web client.

  • Note:  is not possible to import product definitions into RELM v1.

Impact Analysis

RELM impact analysis is not limited to any predefined set of relationships. It explores every link in the RDF graph. The key to providing meaningful impact analysis is context. Everything is related to everything and if you simply create an impact analysis without providing some context it won’t be useful. RELM provides several ways to enable meaningful impact analysis. This includes different graph types and direction of analysis from the selected product or artifact (upstream, downstream and both). RELM allows you to create predefined filters to exclude or include certain artifacts and relationships

  • Tip:  Consider creating predefined Impact Analysis templates that you share across your team for a role or project.

Creating Packages

Views, impact analysis and queries can be shared in RELM using shared folders in the web client. Report templates, views and queries can also be packaged and shared in an unsupported way with other RELM installations. This is useful for jump-starting others to ensure consistent lifecycle methodologies and process and accelerate SSE solution adoption. In the RELM beta customers utilized separately installed packaged views for ISO26262. Content packages are deployed into the RELM installation directory. Consider reaching out to ISSR and SSE Jumpstart for help on how to create packages

  • Note:  It is not possible to package product definitions and impact analysis in RELM v1. You can share queries and impact analysis on the same RELM server by emailing the impact analysis URL.

Data Migration

Setting up SSE development environments involves establishing servers with sample production data and configuration to validate your views and queries before you make them available in production. There are limited options for migrating data from CLM tools: it requires copying the entire repository into your development environment. There are some utilities available within ISSR for being able to do project copy rather than copying the entire repository. Another option is to export artifacts from the product environment and import them into the test environment. For example exporting work items from RTC, requirements from DOORS, or models from Rhapsody Design Manager. This approach will require manually reestablishing linkages between the artifacts, since they would have artifact URIs pointing to the production environment.

Learn More

RELM

SPARQL

Linked Data

RDF

Blogs

About the Author

Carlos Ferreira is the program lead for the Systems Jumpstart Program He works in the IBM Software Group Lab in Massachusetts. He can be contacted at carlos.ferreira@us.ibm.com.

Copyright © 2012 IBM Corporation

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Feedback
Was this information helpful? Yes No 4 people rated this as helpful.