IBM® Engineering Lifecycle Optimization – Engineering Insights (ENI) provides the following two ways to trace the links and visualize the impact of change between the related artifacts.
Dependency analysis (DA)
Impact analysis diagram (IAD)
In this blog, we will compare the characteristics of Dependency Analysis and Impact analysis diagram to know when to use one over the other.
Assume sample data (Money that matters) is installed in ENI and the user has the required license
Dependency Analysis
Views help you to visualize artifacts (requirements, work items, change requests, and so on) from various applications and explore the relationships among them. For example, Work Item from IBM Engineering Workflow Management can be linked to artifacts from other applications such as Requirement or Test case as shown below:
To create a dependency analysis report of an artifact, complete the following steps:
In a view, hover over the artifact that you want to analyze
Select the checkbox that appears
After you select the artifact, the Dependency Analysis icon is enabled.
Click Dependency analysis> Display current selections to keep only the selected artifacts in the view
The following four types of Dependency Analysis options are available:
Upstream – Helps to explore the child artifacts of the selected artifact
Downstream – Helps to explore the parent artifacts of the selected artifact
Upstream & Downstream – Helps to explore the parent & child artifacts of the selected artifact
Full Traceability – Helps to explore the parent and the child artifacts of the selected artifact and resulted in artifacts parent & child
All possible combinations of artifacts are confined to the containers that are available within the view. Hence this limits tracing of links to the available container (and links which connect them) in a view.
For example, when you run dependency analysis of the Allocate Dividends by an artifact from the Requirement container, its Full Traceability is shown as below:
In the above Full Traceability diagram, the links and the corresponding dependent artifacts are displayed. This helps the user to identify that if the user changes the selected requirement then how many test cases need to be updated. This way the user can find the linked records to know the impact of change.
Advantage: The dependency analysis diagram does not display unwanted data and keeps focus on the selected artifact.
Disadvantage: Users must know the domain to create correct views. User may miss adding some containers which may contain dependent artifacts. In such a case, those artifacts will not be traced.
Impact Analysis Diagram
Impact analysis Diagram helps teams trace the relationships among artifacts that are from different project areas. You can explore what artifacts are associated with a specific artifact.
For example, let us explore the requirement “Allocate Dividend by” by using the impact analysis diagram:
The Impact Analysis diagram is created as shown here: When you click Start Analysis, the Impact Analysis diagram is created as shown below:
The default diagram is created with depth level 1 and Upstream traversal. You can change the depth of the analysis (Using Profiles), add artifacts, remove artifacts, and apply filters (IAD Filters) until you obtain the right information set.
After applying filters and selecting the depth level to 2, the following Impact analysis diagram is created:
As you can see, unlike dependency analysis within views, additional links (for example, Validate Requirement) and artifacts are pulled and displayed in the Impact Analysis Diagram. This helps to identify unknown dependent artifacts that are impacted.
Dependency analysis represents data in flat tree format while impact analysis can represent data in hierarchical, tree, circular and radial tree.
Tip:
The new Impact analysis diagram uses the default filter which does not contain any criteria to filter. Therefore, all the linked data is shown in the diagram. You must create and use filters based on your needs to see the relevant data in the IAD. This helps to improve the performance of the impact analysis.
Make use of the depth property from the Traversal tab to deep dive.
Summary
To summarize, you must have the domain knowledge (creating links, artifacts, etc.) to create the correct ENI views and then run dependency analysis on the ENI views. However, to run an impact analysis you do not require any domain knowledge. You need to just search the artifact, and then start impact analysis.
Table: Comparison of Dependency analysis and Impact analysis diagram
Dependency analysis
Impact analysis diagram
When you run dependency analysis, you trace the dependent artifacts that exist within the context of the view.
When we do traceability using the Impact Analysis diagram you start with a single focused artifact. ENI explores all possible links across projects and then plots the dependencies for you.
To generate the dependency analysis of an artifact, the user must know links between the artifacts to create the view on which dependency analysis is performed.
Impact analysis does not require any domain knowledge. You must search for the artifact and then run the impact analysis.
Dependency analysis represents data in a flat tree format.
Impact analysis can represent data in hierarchical, tree, circular and radial tree.
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).
OSLC
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.
Engineering Insights
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 dynamicanalysis of the linked lifecycle data, allowing tasks like impact analysis to be performed in minutes.
Misconceptions
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.
Sample Views
To highlight the previous points, here are some sample views that have been built with ENI:
Traceability View
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.
Performing Calculations
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.
Conceptual Roles
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)
ViewDesigners: 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:
Containers
Artifacts
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:
Artifacts
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:
Building Views with IBM Engineering Lifecycle Optimization – Engineering Insights (ENI) Part Three – Customizing the Look and Feel of Views (The Basics)
While functional it isn’t particularly appealing visually. In this article, we will apply some formatting to improve its consumability.
Formatting Resources
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).
Nodes
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.
UI Types
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.
Conditional Properties
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.
Line Styles
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:
Command: Internal ENI commands such as opening another ENI View (see below)
URLLink: 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.
This new release of IBM Engineering Workflow Management (EWM) brings additional capabilities in all the product areas: agile planning, source control, build, Git integration as well as enterprise extensions. Similarly, in this new release of IBM Engineering Test Management (ETM) version 7.0.1, you will find many improvements in several functions including test planning, test execution or the ETM Excel importer. I am delighted to have the opportunity to share a couple of the key enhancements for each of these products.
IBM Engineering Workflow Management (EWM)
Agile Planning
In version 6.0.6.1, a new Program Board graphical view was added to provide enhanced support for iteration planning at the program or team level. The Program Board shows dependencies in a specific scope, such as across programs or teams. With v7.0.1, users can now create multiple Program Boards in a project area and share them with project members, team members or individual users.
Multiple Program Boards
This release adds two predefined process templates that support Scaled Agile Framework® (SAFe) version 5.0:
Essential SAFe 5.0: Use this template to establish a Program/Team tooling environment.
Full SAFe 5.0: Use this template to establish a Portfolio tooling environment with the Large Solution layer for the Full SAFe 5.0 configuration. This environment is associated with one or more Essential SAFe Program/Team tooling environments.
Source Control
In the code review capability, issue types and resolutions can now be defined to more easily track and report on code review status and outcome. A new preference is available to allow modification of resolved issues after the code review is closed including changing their type or resolution and adding comments. However, resolved issues cannot be reopened. Developers can add a comment when submitting change sets for code review and when resubmitting after modifications. Reviewers can also add a comment when submitting review assessments and they can adjust the automatically calculated time spent on the review. Code review approvals can be set as conditions for the deliver operation in the “Require Work Item Approval” advisor.
Code Review Issue Types
Build
The new option named “optimized incremental load” will speed up the loading process part of a Jazz or EWM Jenkins build. When enabled, only modified files are fetched from the workspace, local changes are not reverted and untracked files are not deleted.
Git Integration
When submitting Pull Requests in GitHub or Merge Requests in GitLab, links to EWM work items can be created by specifying the work item number in the pull or merge request description. The status of the pull requests and merge requests linked to a work item is now shown on that work item Pull Requests tab.
Enterprise Extensions
A new REST API allows the promotion of z/OS work item packages. If the option to generate a UrbanCode Deploy packages has been configured, the source change set metadata generated on the packages can be used as an input parameter for this Package Promotion API. The deployment system can run customized deployment processes that issue calls to this API to synchronously (or asynchronously) deliver the change sets while their version is being deployed. To validate whether the change sets are not in conflict with the production’s source state before deployment, Package Promotion might be called in the preview mode.
IBM Engineering Test Management (ETM)
Test Planning
A new Suspect Result status for Test Case Execution Records automatically flags tests that may need to be executed again. It is automatically set on the test case execution records when the corresponding test case or the test script has been modified after the last run. Users can get notified by email when execution records are marked suspect.
Suspect Result
Users can link multiple test cases to the same set of lifecycle artifacts, such as requirements, in one single action. They can also associate one Test Script with multiple Test Cases in one gesture.
Test Execution
Two new preconditions – Disallow execution of Test Case/Suite Execution Record without current iteration association – can now be associated to the Execute Test Case/Suite operation in the project area administration page. When one of these preconditions is enabled for a user role, users with that role cannot run the test case/suite execution records which are not associated with the current iteration. The objective is to prevent users from selecting the wrong records by mistake and running tests planned for a past or a future iteration.
ETM Excel importer
The ETM Excel importer has received a large set of enhancements including the ability to link test cases to existing requirements in specific modules, the option to save authentication credentials and more detailed messages displayed in the progress UI when the import operation fails.
Building on the themes of ELM 7.0, our next release is just around the corner. Since 7.0.1 has come so soon after 7.0, we recommend that anyone planning to upgrade should go straight to 7.0.1. This blog covers releases of all Requirements Management tools including:
IBM Engineering Requirements Management DOORS Next 7.0.1
IBM Engineering Requirements Management DOORS 9.7.2
IBM Engineering Requirements Management Requirements Quality Assistant
DOORS Next 7.0.1
One of the themes of DOORS Next V is to extend the overall scale of data that can be managed using a DOORS Next RM server. Testing has continued in V7.0.1 and we can now support up to 1,000 concurrent users working on a single RM server using an Oracle database.
It is often the case that when using changesets to modify requirements, dependencies between changesets are created when multiple people change the same requirements or are making changes in the same module when there are changes to the structure of the module. DOORS Next V7.0.1 allows for dependencies to be overruled when selecting changesets for delivery.
Trace column information can be tailored to be more succinct in the information that is displayed, including the use of traversable Link Indicators rather than displaying more verbose URLs.
ReqIF has been improved in the way attachments and graphical elements are used as part of Requirements information. Where possible, DOORS Next will now import OLE elements from applications like DOORS directly into attachments in DOORS Next. DOORS Next will export graphical elements such as Diagrams in a format that can be seen, but not edited in other requirement tools, including DOORS.
DOORS 9.7.2
DOORS V9.7 was introduced to enhance usability while focusing on integrating DOORS more closely with the IBM Engineering (ELM) portfolio as a whole.
Extending support for collaboration with ELM and Global Configurations, enabling the DOORS user to see and create trace links to ELM (OSLC) data placed under configuration management
We have made a number of improvements for reporting; most significantly is the ability to report on requirements volatility using the Jazz Reporting System Report Builder.
ReqIF interaction with IBM Engineering DOORS Next has been improved to allow OLE data from DOORS to be directly sent to DOORS Next as attachments without the need for wrapping elements. It is also possible to see DOORS Next diagrams for review in DOORS.
The DOORS database explorer shows modules and their baselines to make it easier to open the correct version. Optionally, the module explorer can limit the display to active objects covered by an active filter.
Requirements Quality Assistant
Requirements Quality Assistant is a hosted solution with updates typically released monthly.
RQA can be added to existing deployments or can now be purchased as part of a dedicated DOORS Next SaaS environment, with the power of AI
through Requirements Quality Assistant
Requirement Managers get the full capability of DOORS Next Analyst. to optimize communication & collaboration across teams
Requirement Authors receive coaching from RQA to improve the quality of a requirement as it is being written
RQA scores requirements against criteria consistent with the INCOSE Guidelines for Writing Good Requirements. The tool is pre-trained to detect 11 quality issues and can be extended with more through the support of IBM services.
After analyzing requirements, see the issues found by RQA in the list of attributes in DOORS Next & DOORS. Use the issue guidance to modify requirements and reduce ambiguity. For more information, see Checking DOORS Next requirements with RQA
In recent releases, we have refined the accuracy and scoring and you can now measure the quality of your project or module and use Dashboard views to provide insights on problem projects.
These are only a few of the improvements introduced with DOORS Next, DOORS and RQA. A full list can be found in the product documentation: DOORS Next, DOORS, RQA
Thank you for your continued support and stay safe.
The rising complexity of the products and systems being developed globally is driving engineering teams to seek effective model-based engineering practices, including model-based systems engineering (MBSE). Rising compliance demands such as ISO-26262/ASPICE in automotive and DO-178C and ARP4754 for aerospace and defense are driving the need for rigorous change management and lifecycle traceability. At the same time, engineering teams must maintain or improve their quality and engineering productivity. This approach for digital engineering is further endorsed by INCOSE’s 2025 Vision along with the US Department of Defense’s Digital Engineering Strategy, which places MBSE as an enabling technology for the best systems and software engineering practice.
To achieve these goals, the engineers who create these models must be full participants in the development lifecycle by partaking in activities that span engineering disciplines, such as:
Planning
Workflow and progress tracking
Requirements elaboration and validation
Change management
Reporting
The enhancements in this release of Engineering Systems Design Rhapsody Model Manager (ESD RMM) 7.0.1 and ESD Rhapsody 9.0.1 extends and productizes some of the features of the previous release and allows practitioners to work efficiently at scale, with large models and large sets of requirements.
For those of you using Rhapsody Design Manager, make sure you see my comments at the end of this post.
Introducing ESD Rhapsody Model Manager V7.0.1
The biggest new feature of Rhapsody Model Manager in V7.0 was enabling Rhapsody Model Manager to be an extension to Engineering Workflow Manager(EWM) so that engineers can (optionally) configuration manage models in the same components as source code and other files. As a result of this change in architecture it was necessary to modify the behavior of the EWM Developer and the RMM System and Software Engineer licences so that they matched the license usage patterns that were available with Rhapsody Design Manager, this work is now complete in V7.0.1.
When you install RMM as an extension to an EWM server you have an option to either manage “models” or “models and code”. If the server is set to manage models only when using Rhapsody with RMM to create and check-in models to the EWM server the user only needs the RMM System and Software Engineer license for RMM. If the server is set up to manage models and code, then the user requires an RMM System and Software Engineer license and an EWM Developer license. If the user wishes to create links between model artifacts and requirements in DOORS or DOORS Next or other artifacts such as tests or work items using the RMM web client, then they only need an RMM or Contributor license. If a developer is creating code and delivering it through the EWM Eclipse client, then they need only the EWM Developer license. This behavior matches the license usage patterns that were available with Rhapsody Design Manager- with the added benefit that now the Jazz work item system can be on the model server.
The other major change in Rhapsody Model Manager V7.0.1 is further improvements in the Rhapsody direct integration with EWM. You can now see the configuration management state of a set of artifacts propagated down the model hierarchy. This makes it possible to do Configuration Management operations on an element and its descendants. Another improvement to the EWM direct integration is the ability to accept incoming change sets directly from the Rhapsody browser when being used as part of RMM (see Figure 1). To enable this, changes have been made to the Rhapsody Diff-Merge tool to ignore changes to the metadata in the model files; this prevents users from being overwhelmed with unnecessary information. However, to make this effective you must save and republish your models in the V7.0.1 format.
Figure 1. Accept Incoming Change Sets
There have also been some under-the-hood modifications and improvements in RMM for efficiency and robustness when working with larger models.
Introducing Rhapsody 9.0.1
Considering this was short release cycle, there has been a lot of work going on in the Rhapsody product team. We have been looking at various options for modernising the Rhapsody GUI now that we completed the work on porting Rhapsody Visual Studio 2017. We look forward to sharing news related to the outcomes of this exploration at future IBM ELM events.
We have made further improvements in the HTML document generation. This includes simplified reporting for user defined terminology, so it can now work with user defined profiles and show the “New Elements” in the browser and model. We have also added support for navigable table and matrix views in the document gneration (See Figure 2).
Figure 2. Navigable Table and Matrix views in HTML report generation
Another enhancement in this release is to the populate diagrams feature, this used to only be applicable to an element that was selected from the internal browser in the populate diagram feature box. Now it is possible to select an element on a diagram, open up the “Populate Diagram” application and by selecting “Relations from/to selected” see all the related elements. This becomes very powerful when applied successively to different parts of the model as you can start to discover relationships that you may not have been aware of (see Figure 3 below).
Figure 3. Enhanced Populate Diagrams showing the progression of application on a simple model.
There are improvements to diagram navigation so that you can set the default navigation from a block in a Block Definition Diagram to the Internal Block Diagram it owns, enabling you to drill down through a model hierarchy. It also now possible to shrink the size of a class/block, object/part so that it fits the length of the text used to capture the elements name.
Finally some of the smaller enhancements that have been completed in Rhapsody in this release include;-
Updated support for AUTOSAR and Adaptive AUTOSAR concepts, workflows and tables
Additional properties to control
Custom naming patterns for links and connectors
Integration of properties descriptions in feature dialogs
Control the format of compartments
Open Rhapsody in Read Only mode.
Increase the total number of supported plugins and helpers to 500 and 1000 respectively
Adaptor for MinGW Compiler (MinGW-w64 v.6.3 and 8.1.0 ) 64 and 32 bit versions
This also supports Simulink cosimulation but the MInGW version must match the installed MatLab version
Rhapsody Design Manager: Time to migrate to Rhapsody Model Manager
As many of you are aware, Rhapsody Model Manager was developed to replace Rhapsody Design Manager and that day is now close to hand. The last version of Rhapsody Design Manager is V6.0.6.1. This final version of Design Manager will work with Rhapsody 8.3.1 and with ELM 7.0.0 and 7.0.1 (see Optional Programs Section). Customers with entitlement to Design Manager will also have entitlement to Rhapsody Model Manager going forward.
As an update to my last what’s new blog post: support for Design Manager is planned to end in September 2021. Between now and the end of support only Severity 1 and migration issues will be responded to by IBM Support. Any RFEs raised will be triaged and if applicable moved to RMM.
If you haven’t started already, it’s time to start planning and migrating from Rhapsody Design Manager to Rhapsody Model Manager. Please contact your account manager and/or technical sales representative to discuss how this process can be managed.
Any teams that are starting new modeling projects should use Rhapsody Model Manager. We’ve received a lot of good feedback on the stability, enterprise scale, and tight integration of Rhapsody Model Manager in the ELM solution. I hope you will soon experience the benefits yourself.
