No-code integration platform for rich bi-directional sync
Zero downtime migration to tool of your choice
Keep Historical Data, Without Slowing Down Your Tools
Migrate or restructure Azure DevOps Instances
Real-time, context-rich data lake for AI or analytics
By Role
Accelerate delivery with clear insights
Transform smarter with a connected digital thread
Confident transitions for every enterprise change
By Initiative
Modernize and move to cloud without disruption
Build a compliant digital thread for complex environments
Build the foundation for smarter AI
By Domain
No-code integration across teams & systems
Enable collaboration between IT, support & business teams
Connect PLM & engineering teams for smarter products
Ensure regulatory compliance from start to release
Explore the latest in technology and best practices
Success stories from the field
Actionable insights for your business challenges.
See solutions in action
Learn, plan, and execute with confidence
Official announcements and updates
Join discussions that drive results
Stay ahead with curated insights
The defense industry is entering a pivotal phase with the introduction of DoDI 5000.97, mandating the shift to Digital Engineering (DE). This article examines the challenges, including tool interoperability and data governance, and how suppliers can adapt through Intelligent Federation and integration platforms like OpsHub.
This video explores the powerful IBM Rational DOORS integration with Verisium Manager (formerly Cadence vManager), which connects your requirements, design, and verification data across the entire product lifecycle. This integration creates a robust digital thread, essential for driving digital transformation. With IBM Rational DOORS Next Generation, modules automatically synchronize with Verisium Manager, preserving all attributes and hierarchy within the sections, ensuring seamless data flow.
OpsHub Integration Manager (OIM), an enterprise-grade tool, simplifies the integration of best-in-class requirements management tools like DOORS by automating data synchronization with zero manual intervention. It effortlessly handles large data volumes, ensuring scalability as your projects and teams expand. This integration is a key solution for teams looking to leverage the power of IBM tools for efficient and scalable requirements management.
Schedule a 30-minute live demo with our integration experts
In the DOORS database, we can see a project and some modules. We will use the Verification Requirements module and Verification Tests module in DOORS for this demonstration. Objects under the verification requirements will sync to vManager as sections or subsections, and test cases and metric ports attached in vManager linked with the sections or subsections will synchronize back as objects inside the verification test module.
In the Verification Requirements module, we have predefined requirements. We can see a hierarchy of the requirements here, along with their respective attributes like priority, status, heading, short text, etc. The verification test module is currently empty in vManager. Currently, V Plan is also empty, as requirements from DOORS haven’t synchronized yet as sections or subsections.
Now, we will start with synchronizing the verification requirements. OpsHub will preserve the history of DOORS requirements while syncing them to vManager as sections. The OpsHub admin is activating the requirement synchronization. All the objects from the Verification Requirements module in DOORS will synchronize to vManager as sections and subsections, preserving all the attributes and hierarchy. In vManager, the verification engineer refreshes the page and views the four sections and subsections that have been created.
All attributes for each section and subsection, like the title, description, status, priority (mapped as severity), remote ID of the DOORS object in the custom field, and the remote link to navigate to the DOORS object, have successfully synchronized from DOORS to vManager, maintaining the hierarchy. In DOORS, a field is called an attribute. We can see the linked ID of the section from vManager. In all the objects, the value is set, helping users achieve better traceability when navigating to vManager.
Navigating to vManager, the verification engineer now starts adding test cases. Under the first test case, they add a name, description, test execution status, and severity. Similarly, another test case is added. Here, we can see the section and subsection levels with a red flag, whereas the test cases added do not reflect the red flag. This is because the test cases were last updated on vManager. To clear the flag, follow the steps as shown in the video. The flags are no longer visible, indicating that the value has been read and accepted by the verification team.
The verification engineer now goes ahead and adds metrics to the test cases. In DOORS, the project manager opens the verification test module to view the synchronized test cases from vManager with an out link to the requirement. We can see the test cases have been linked to the Verification Requirements module. Under each verification item, we can see the heading, description as short text, and all synchronized attributes like priority and status.
After reviewing the vManager test cases as verification items in DOORS, the project manager makes changes to the short text and then the status for the first test case, adjusting the specs for the tests to be performed. They then change the short text for the second test case. In both test cases, we can see the object text consisting of links attached to V Plan. Here, we can see the link to the Verification Test module in the Verification Requirements module in vManager. The verification engineer refreshes the page to view the changes made to the test cases in DOORS.
At this point, the verification engineer, as per protocol, goes to the regression center, runs the regression. Once the regression is complete and the coverage output is available in the regression center, it is synced and integrated into the planning center. In this demo, we are using pre-calculated coverage output for the metric port attached. Therefore, we will directly fetch the coverage outputs like grade average, past runs, and fail runs. To do so, the verification engineer clicks on Grade Analysis. This button enables OpsHub to show the pre-calculated coverage output.
Once the values are available at the planning center, the verification engineer fetches them from V Plan or its database to the attribute level. By clicking on Sync, we can see the values have been updated. OpsHub, via a CUDA script, allows the roll-up of results from the test case to a section or subsection level. Therefore, the results are identical at the Gluco Monitoring Machine level, which is the parent requirement. We can see the average result of both the test cases. This result is rolled up to the Health Monitoring Device section.
Navigating to DOORS to see similar outputs, the project manager enters the Verification Test module and clicks on the Low Blood Sugar Verification Test. Here, we can see four failed runs, two past runs, and the average grade is 33%. Based on this, the project manager changes the status of the test case to “Failed”. For the second test case, since the average grade is 100%, with zero failed runs and six past runs, the project manager changes the status to “Completed”.
Let’s take a look at the rolled-up results at the Requirements object level. Under High Blood Sugar Range Verification, we can see a 100% grade average, six past runs, and zero failed runs. Under Low Blood Sugar Range Verification, we can see a 33% grade average, four failed runs, and two past runs. The average rolled-up result at the parent requirement level is 66.66%, with four failed runs and eight pass runs. The same result is rolled up at the Health Monitoring Device 2.0 level. The project manager has now changed the status of the requirement to “Closed”.
Navigating to vManager, while the requirement update is syncing, the verification engineer refreshes the page to view the updates made to the test cases in DOORS. The test for High Blood Sugar Notification Verification is marked as “Passed”, whereas the test for Low Blood Sugar Notification is marked as “Failed”. The verification engineer refreshes the vManager page one last time to view the updated status of the requirement. The status change made to the requirement in DOORS has successfully synchronized and is reflected as “Resolved”.
That completes the demo. Thank you for watching.
Schedule a 30-minute live demo with our integration experts
