by Andy Lapping
In this series of articles, we’ll be exploring how to build views in IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) that allow you to visualize and analyze your engineering data in a powerful, dynamic way. We’ll see just how quickly and easily these views can be built, starting with some very basic concepts before progressing to more advanced topics. In this first article, we’ll explore what ENI (formerly called Rational Engineering Lifecycle Manager or RELM) is and what it can do for you.
What is Engineering Insights?
The Engineering Environment
In any large organization, the engineering environment can be highly fragmented. Many tools are in use, each with its own user interface, database or file system repository and workflow. And yet for a robust engineering environment, the data in these tools must be connected.
The Importance of Traceability
Traceability between artifacts is critical in complex engineering projects, especially those which have to consider compliance to standards such as DO178B/C, ISO 26262, Automotive SPICE and so on. Traceability is one of the cornerstones of change impact analysis (and if you can be sure of one thing – it is that change is inevitable in a project). This kind of traceability has historically been done using point-to-point, bespoke tool integrations, which are brittle and prone to breaking when one of the tools changes versions. Alternatively, the traceability may have been maintained separately in other documents such as spreadsheets – a cumbersome, time-and-labor-intensive and potentially error-prone process. Yet another way traceability has been maintained is by taking an ‘import all the data into a single tool’ approach (which simply doesn’t scale).
The advent of Open Services for Lifecycle Collaboration (OSLC) solved this problem by allowing the data to stay where it belongs; in the tools that best know how to author and manage it, whilst allowing that data to be linked to related data in other tools using standard HTTP-based protocols. So requirements, for example, stay in the requirements management tool but can be connected to design elements in any design tool that supports the standard.
So what has all of this got to do with ENI?
Whilst OSLC allows the creation of these links, it does not address how to view and analyze them, at least not in any holistic way. When a requirement changes, how quickly can you assess the impact of that change? The designs, the test cases, the physical parts that all might be modified or replaced? These kinds of analyses can take days, even weeks to perform and are costly and error-prone. Engineering Insights allows searching, visualization and dynamic analysis of the linked lifecycle data, allowing tasks like impact analysis to be performed in minutes.
Whilst ENI has other capabilities such as global searching and auto-generation of impact analysis graphs, this series of articles will focus on how to build views that allow dynamic analysis and visualization of our engineering data. Obviously, impact-analysis/traceability style views are particularly useful (and if you’ve seen ENI before it’s likely that you saw an impact analysis view) but don’t fall into the trap of thinking that ENI is only useful for impact analysis. In fact, I’ve heard several misconceptions around ENI, such as:
- “ENI is only useful for Impact Analysis”
- ENI has a far wider scope than this – in a moment we’ll see a few examples
- “ENI is only useful if you have the entire suite of Jazz tools”
- Not true at all, ENI is equally useful for analyzing a single data source. For example, it can provide a view of the status of work items across all EWM projects or provide gap analysis on requirements that goes way beyond the ERM traceability tree.
- “ENI is only useful for Engineering”
- Despite the name, Engineering Insights is equally applicable to finance, IT and so on. It analyses data, and as long as that data is visible to ENI (more on that later)it doesn’t matter at all what the nature of that data is.
To highlight the previous points, here are some sample views that have been built with ENI:
Yes, this one is an impact analysis view – starting from a single artifact, in this case, a Story work item in IBM Engineering Workflow Management (EWM). This is actually the first view we’ll build in this series of articles, and we’ll be using the out of the box data set so you can deploy a sandbox on Jazz.net and try this for yourself. Note that the test results are color-coded by their pass/fail status. Note also that the view is live – you can invoke rich hover on any of these artifacts, and even use ENI to navigate to any of these artifacts in the correct tool, and in the correct configuration context (ENI is GC-aware)
Traceability View – The Big Picture
An alternative to showing impact analysis for a single artifact – show it for all of them. We can go from the first traceability view to this one and back again with a couple of clicks of the mouse. No other single tool can give you this kind of view.
Budget / Cost Analysis
This view is analyzing a single data source – IBM Engineering Workflow Management (EWM). By traversing the internal links between different work items, it performs calculations and highlights where a parent task is over or under budget, based on its child tasks, the resources allocated to those tasks, the time estimation of the tasks and the cost of the allocated resources. The view is also dynamic – clicking on a parent task will display another view that drills down into the detail:
Requirements Quality Analysis
IBM Engineering Requirements Management can leverage the power of Watson to analyze requirements and score them for quality. The above view(s) present an average of those quality scores, by module and by project, helping to identify project risk or identify those projects that need extra training in how to write better requirements.
ENI for Compliance
This ‘requirements readiness’ view we built for ASPICE compliance. Only when all of the requirements in a module have a linked test case with a passed result (and thus turn green) does the module turn green. This view is also dynamic, clicking a module on the left populates the details of the requirements on the right.
Traceability Beyond the Jazz Platform
This view shows artifacts that are not maintained inside the Jazz platform. At the top of the view is a device type coming from the Watson Internet of Things Platform. At the bottom, we can see artifacts from a PLM tool which is not even a product from IBM.
And Now for the Science Bit … The Lifecycle Query Engine
So how does ENI work? One of the core technologies of the Jazz platform is the Lifecycle Query Engine (LQE). LQE builds an index of all of the linked lifecycle data, and it keeps that index up to date by periodically polling any connected tool for updates. Any tool that conforms to the OSLC Tracked Resource Set (TRS) specification can expose its data for LQE to consume, so this capability is not limited solely to the tools on the ELM platform but can also include (for example) PLM data.
LQE then makes this indexed data available to other tools such as Jazz Reporting Services (JRS) Report Builder for self-serve dynamic reporting, and IBM Engineering Lifecycle Optimization – Publishing (formerly called Rational Publishing Engine) for document generation. It also has a REST interface so you can interrogate it yourself.
The other key tool that consumes this data is, of course, Engineering Insights. Note that the data is protected by access permissions so if your user doesn’t have access to it in the native tool, then you won’t see that data in ENI either.
I hope that’s given you an overview of Engineering Insights and in particular the kinds of views that we can create. In the next article, we’ll get our feet wet and start actually building them!
Building Views with IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) Part Two – Building a Traceability View
In this article, we’ll build our first view. Later we’ll make it look visually appealing and introduce some dynamic visualization but we’ll start by simply reporting the data we are interested in and see just how quickly and easily views can be designed. We’ll be building this view using the out-of-the-box sample data that ships with ELM – JKE Banking (or whatever you choose to call it when you deploy it). That sample just happens to be a finance sample, but it has the same kinds of an artifact that IT and Engineering projects have, it has requirements, it has test cases and it has work items.
ENI has three conceptual roles (these are not tool-based roles that appear in the UI)
- Consumers: Project managers, engineers and so on that simply want to view the graphical analyses, typically on dashboards. Consumers need very little knowledge of ENI (only perhaps how to modify the parameters a view designer has included to allow dynamic customization of the returned data)
- View Designers: As the name implies, designers build the views that the consumers use. Designers need to know (a) how to use the tool to build views and (b) the information model. How is the data being created? What link types are being used? How many levels of traceability have been implemented? What kinds of analyses are required?
- Custom Artifact Element Designers: This is the deepest level of customization and requires all the knowledge of a View Designer but also the concepts of RDF and the SPARQL query language.
For most of this series, we will flip back and forth between Consumers and View Designers. A later series of articles will focus on the concepts around Custom Artifact Elements, how they are used and how they are designed.
Building a View
Creating the Project
One of the major differences between an ENI project and any other Jazz-based project is that it does not scope the visible data. As we discussed in the previous article, ENI sits on top of LQE and LQE sees all. The visible data is only scoped by (a) the users’ permissions to see the data and (b) the scoping that the View Designer decides to apply and this is done in the View – not at a project level.
Creating a View
Creating a new View is an exercise in simplicity; there are multiple menu items and indicated buttons to do so.
Your new View can be created in the Shared section and thus instantly available to anyone else who is a member of this ENI project; or it can be in the My Views section, visible only to you (until you choose to move it).
When you create the view, you can if you wish to limit its scope immediately to only specific projects. You don’t have to do that; you can add project-level filtering later, in containers or links (you’ll see that later). My recommendation is this: don’t limit it until you have to / want to, so we can skip this page (selecting nothing means we don’t want to apply any project filtering)
Populating a View
Views are populated by dragging elements from the palette onto the canvas:
Artifacts and Custom Artifact Elements
It’s worth at this point acknowledging that the palette has three sections:
- Custom Artifact Elements
Leaving Containers aside for a moment, the two major sections are Artifacts and Custom Artifact Elements. Both represent “stuff” in your database. For example, work items, test cases, requirements and so on. However, they have some key differences:
- Are populated automatically by ENI by asking the data source ‘hey – what do you have ?’
- Custom work item types, requirement attributes and so on all appear automatically with no effort at all on your part
- They are limited to what the data source returns (more on this later)
- Custom Artifact Elements
- Do not appear automatically. They have to be hand-crafted using a query language called SPARQL (although a sample set can be deployed)
- Are more flexible than Artifact Elements; you can write a query to interrogate the data source in any way you like.
For this first set of articles, we’ll use the automatically-generated Artifacts. Since the sample data has a work item type called Story, we can drag that Artifact onto our canvas:
Refining Container Content
When an Artifact is dragged onto the canvas, it turns into a container. That container will be populated with graphical nodes that represent the data source, in this case, Stories. Before that happens, we can choose to filter that population in several ways; by the project (Edit scope tab); by the presence of outgoing links (Link types tab); or by any attribute of the data source (Edit conditions tab).
This is optional and we can invoke the same dialog later so, for now, we can click OK to see All Stories:
Showing a Count
Using the right-click menu for a container we can toggle it between showing the artifacts or a count of those artifacts:
Adding Connected Artifacts
If the container is showing artifacts (not a count) then we can add a new container that populates with connected artifacts by right-clicking the existing container (in this case Story) and selecting the menu Show Links To:
This starts a wizard with several pages where we can:
- Create a new container or add connections to an existing one (in this case we are creating a new container)
- Filter by the project (useful if our Stories connected to artifacts in multiple projects – they don’t so we can skip this page)
- Select the type of artifact and the type of link we want to use to populate the new container:
We can continue adding more containers to show whatever traceability we want. This is where the information model becomes important!
Filtering a Container
Remember when we first dragged the Story artifact onto the view and we had a chance to apply to filter? Let’s invoke that again. We can right-click any container (in this case we’ll right-click the Story container) and select Refine Container Content > Edit conditions.
It doesn’t matter which of that four sub-menus we choose since they all invoke the same dialog that has those menu entries as tabs.
On the Edit conditions tab, we can filter the container based on any of the data source attributes. For example, we could filter based on the Priority of the Story:
We can also decide if the Consumer of the view can change the condition to see different data (the default is yes, they can – but they don’t have to)
We can apply filters to any of the containers, not just the first one:
Consuming the View
By clicking Save and Close we can switch from designing the View to consuming it (of course the View appears on the menus and can also be added directly to dashboards in other parts of the platform). To change the filter values, we click the ‘ruler’ symbol in the tools bar:
Creating an Impact Analysis Style View
These types of views typically start with a single artifact. We can implement that easily by applying a filter to our starting container that only returns a single artifact. ID or URL are both good choices:
That’s all for now; later we’ll see how to make this view dynamic so that the Consumer of the view can easily select a Story with a single click and instantly see the traceability view change. We’ll also see how we can make the view more visually appealing by changing the colors, line shapes and so on.
Building Views with IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) Part Three – Customizing the Look and Feel of Views (The Basics)
In the previous article we built out a simple traceability view – as a reminder here is where we ended up:
While functional it isn’t particularly appealing visually. In this article, we will apply some formatting to improve its consumability.
It’s probably worth mentioning straight away that formatting for Artifacts differs slightly from formatting for Custom Artifact Elements. In this article, we’ll focus solely on Artifacts (which we used to create the traceability view in the previous article).
The formatting of resources displayed on the view is done primarily through Nodes. We can open the Node definition for any type of Artifact by right-clicking (any) resource displayed inside an Artifact Container and then selecting Edit Node:
Note that editing the Node for a particular Artifact (e.g. Story) affects all containers of that type on this view.
Nodes are based on UI Types that define the basic display characteristics of an element such as its shape (for example it’s a rectangle that is 160 wide and 30 high), its content (for example it has one line of text), its colors and so on.
These characteristics (parameters) have default values which may then be overridden by the Node that uses them. In the screenshot above you can see that the Story Node is based on the simpleResourceNode UI Type – which is a rectangle with a single line of text. By default, the rectangle is 160 wide and 30 high, and the single line of text is populated by the title property of the underlying resource when it appears on the view.
If we select a different UI Type – for example the baseResourceNode UI Type; this one is slightly different in that it has two lines of text, populated by the shortTitle and title properties respectively:
Note that the preview at the top-right displays the current value setting of the parameter, not the name. Rather confusingly, for example, the UI Type has a parameter called title, which by default uses the shortTitle property of the resource. It also has a parameter called summary, which uses the title property of the underlying resource. Don’t worry too much about this – just change the values in the table and then look at the preview for the effect. For example, if we modify the title row to use the id property instead of the shortTitle:
Then the view updates so that Stories display their ID as well as their title:
Another simple change we can make to improve the look and feel is to change the fill color of a Node:
Fill colors may be solid, gradients, or patterns and it doesn’t take very long to create a more pleasant looking view. Don’t overdo this of course and you will find that lighter colors work better than darker ones.
Any value defined in a Node may be set statically (for example width=30 and fill color=yellow) or conditionally. This is particularly useful for applying properties like coloring, for example, the Test Result container could color its display based on the verdict (passed, failed and so on) of the underlying test result:
Want to change the width of the displayed artifacts on a diagram so you can read them? Change the width property in the Node definition. Resizing a container will do just that (resize the container) not the displayed elements inside it.
Note that UI Types may be customized and new ones added – but this is beyond the scope of this article.
Aside from the elements in the containers, the other thing we may want to customize on our view is the connections. Note that in edit mode, there is a dashed line between containers. This line only appears in edit mode and is there to allow you to customize the display of the actual OSLC connections between the resources:
Right-clicking the dashed line will give the following options:
- Show Connections: This is a toggle to show/hide the actual OSLC links (between the resources in these containers) on the view. It is sometimes useful to hide these links – for example, if you have a DOORS Next module, with a linked container showing the requirements used by that module, the links are not only superfluous but make the view unnecessarily busy, so we can simply hide them.
- Show Linked Nodes Only: When we create a container using Show Links To, we are doing two things: (a) Adding a container of elements (for example Requirements) and then (b) filtering that container by only showing ones that have incoming links from elements in the previous container. Show Linked Nodes Only is the second part of this equation. Disabling it will remove the filter and instead show ‘all’ elements (of course any other filters on the container would still be applied)
- Edit Connection: This is where we can edit the look and feel of the OSLC links between these containers, and the dialog is similar to the one for Nodes:
The most useful setting is the UI Type combo box:
- baseConnection = rectilinear
- roundConnection = spline
- lineConnection = straight line
Also very useful are the startDir and endDir properties (although these are set to ‘auto’ – this is unfortunately far from automatic and it is much better to select either “Left or Right” or “Top or Bottom”:
There is no capability (at least at the time of writing) to annotate a connection (perhaps with the type of relationship it represents). Although one can imagine if there are many OSLC links such annotations would quickly cause the view to become unreadable, still the option would be nice. Here is what our sample view looks like after applying a few of the properties described above.
That’s all for now; in the next article, we’ll see how to make this view dynamic so that consumers of the view can easily select a Story with a single click and instantly see the traceability view change.
Building Views with IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) Part Four – Building Dynamic Views
In this article, we’ll introduce Actions that allow us to make the views more interactive and dynamic. We will start by creating a new View that we can use as a launchpad, opening the traceability view we created earlier for any selected Story. Then we will add a Story selector to the traceability view itself so that the user can click a Story in that same view and see its traceability. (Typically we would only use one of these options)
As a reminder here is the traceability view we’ve built in the previous articles:
Adding a Launchpad
Let’s now add a second View which will serve as our launchpad. We can add a Story container to it and set the number of columns to (for example) 5 to create a dashboard:
In the previous article, we used Nodes to customize the look and feel of resources in our view. Nodes also allow us to define Actions (as well as customize the rich hover).
There are two types of Action:
Command: Internal ENI commands such as opening another ENI View (see below)
URL Link: When invoked simply navigates to a web page – either in this web browser tab or in a new one
There are three Commands:
openView: Opens another ENI View, optionally passing in parameters
reloadContainer: Reloads a container on this view – again optionally passing in parameters
reloadConnections: Reloads any custom connections defined by queries in this view
We will use the openView action to open our Story Traceability view. When a view is selected, any available parameters are presented along with their default values (if you recall when we built the traceability view we filtered the initial Story container on a specific ID)
By changing the parameter value to Id (and this is a selector that presents attributes of the underlying resource for the Node) we are saying “When this action is invoked, open this other view and use the ID of the resource we clicked on to invoke it as the new parameter value”
The options at the bottom of the dialog are:
Target: Open the new view in this web browser tab or a new one
Default Action: If selected then the user can left-click a resource to invoke the action (whether selected or not the action always appears on the right-click context menu, using the label specified in the Action Label field)
After applying that we can open a traceability view for any Story simply by clicking it (in View mode) or right-clicking and select Explore Traceability (in either Edit or View mode)
Creating a Dynamic View
Let’s now make the traceability view dynamic – starting by adding a second Story container to it. Note that it is automatically formatted based on the Node we modified for Stories in the previous article:
Next, we can add an Action to the Story, this time using the reloadContainer command. Other than that it is almost identical to how we configured the previous action – instead of selecting a view, we select a container in this view (you can always use the properties of a container to view/change its ID)
Now our user can change the traceability pictures displayed simply by clicking any Story in the same view:
That’s all for now; in the next article we’ll explore a very useful layout feature – grids.
Technical Enablement Specialist
Watson IoT & Engineering Lifecycle Management