The Next Generation of ALM Tools: Combine RnD With Quality and Regulations

DZone 's Guide to

The Next Generation of ALM Tools: Combine RnD With Quality and Regulations

This example illustrates the stages, as well as the importance, of risk management in ALM tools, to meet regulations and quality standards.

· DevOps Zone ·
Free Resource


Hi there. In this article, I will describe what I see as next generation in the ALM and Quality Management. This article is a result of many years in the ALM market as an ALM vendor (www.orcanos.com), where, as a bootstrap company we were forced to deal with real problems of real customers while building our product. In the last 9 years, we added the quality and regulations aspects, and it allowed us to shape a unique solution to deal with cross departments challenges, that are described in this article.

I am always for as much consolidation and automation as possible, especially when we talk about complex solutions such as ALM systems, and especially when we talk about ALM under quality and regulations constraints, such as medical device development.


There are numerous ALM tools today in the market, from Jira which is an excellent tool for development teams to HP, MKS-PTC and many others that solve the development aspect mostly, one way or another. And they are all good.

On the other hand, there are tools for quality such as Master control, Grand Avenue, and Sparta Systems, that provide a solution for quality management and regulations.

But how do we connect these departments? and what about making the continuous processes flawless and simple?

The ALM and QMS tools serve different stakeholders in the organization, but the communication is crucial, as no matter how good you develop your product - if it doesn't meet your industry-based quality and regulations, the risk of failure is significantly higher, and it doesn't matter if its a medical device, pharma, automotive, or software.

We talk about different people, different needs, different interest. It's a real challenge to connect them all to one repository and still satisfy everyone and make it unified, and simple enough.

Sounds impossible, ha?

As a founder of Orcanos, I have struggled for years to find a way to connect everyone to one repository, without compromising on the quality of the different modules to the different stakeholders.


I wish to illustrate my idea in a short example taken from the real case of one Orcanos customer:

Orcanos ALM and QMS

Orcanos ALM and Quality Management Solution.

Let's say, you develop a medical device, and you have a customer using your device, and unfortunately, he found a problem.

Process #1: Complaint Management

So, he needs to file a complaint, through a regulated complaint form, filling in all the details, and you as an organization must close the complaint ON TIME!

So, part of the quality procedures of a medical device is the investigation, where you need to investigate what went wrong, what do you need to do in order to fix it, in order to avoid such issues in the future, and reassess risks in your product.

Quite a lot, right?

Process #2: CAPA Management

It doesn't end here. Now you have investigated, and you decided to open a CAPA (Corrective & Preventive Actions) in order to describe the root cause, what needs to be done to fix it, and what needs to be done in order to avoid it in the future.

The CAPA is linked to the complaint, so the customer manager needs to be alert when CAPA is completed.


Process#3: Risk Management

On your risk assessment, you have discovered new risk in your product, that is critical as it affects user safety, so you need to add a new risk to your risk management file. Needless to say that the risk should be linked to the complaint so everyone is in sync with every change.

Now, let's talk about risk mitigation:

Process #4: Design Change for Risk Mitigation

Let's assume that we need to make a change in design, in order to mitigate the risk. in order to simplify the process, let's say that we need to change a requirement in our software.

The requirement should also be linked to the risk.

Now we move on to the verification:

Process #5: Test Design

A test case (one or more) should be added and traced to the requirement in order to verify the risk mitigation (software requirement, in our case).

Process 5: Test Execution

Now the testing team needs to execute the test via a test suite and report the results.

Process 6: Defect Management

Let's say that the test has failed, and we now need to report a defect that is sent to the relevant software team for a fix. The defect is fixed and routed back to the testing team for bug verification. The test is executed again and the defect is verified.

Process 7: Document Control

This entire process shall be documented and approved in the SOP, and we wish to control our documents revisions in an electronic document management system.

So, forms need to be signed, people need to be notified, reports should be executed and new documents revisions are added to our design control, new delivery is on the way, other customers with the same problem should be notified...

Well, it's a hassle. It's quite a lot to handle using Word documents and/or multiple systems


Having one solution that brings it all together will save lots of time and money, and more important - will assure better delivery and compliance with the regulations. This is our challenge, and we constantly working on finding creative and simple solutions to very complex problems.

Related Links


ALM Tools

Quality Management System

application lifecycle management ,alm ,quality control ,devops

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}