What needs improvement with Polarion ALM?

Polarion ALM can learn from Atlassian tools a lot, as the usability is not the best, and it is really narrowly focused on requirements management only. For example, if you want to do testing and test result management with it, it is very limited. Jama Connect has similar limitations, and both should really focus on developing the integrations and extendability. For example, Jama Connect does not even have an extension marketplace, whereas Polarion has a small one. However, compared to the Atlassian Marketplace where you can get whatever applications for whatever price, it is a totally different ballgame. I would highly recommend Polarion ALM add more AI features to it. I know they have started to do something, but for example, I have been developing widgets for IBM DOORS Next, AI widgets, so that you can write and analyze requirements with the AI, and I have also done the same for Jira, creating a couple of Jira applications in the marketplace as well.

The backlog management for Agile in Polarion ALM could be improved or enhanced in future releases. What is missing is that if you have a hierarchy in your backlog with epics, features, and user stories, there is no simple way to generate standardized views on all this, which is available out of the box in Jira or in Azure DevOps with just one click. Here it is more complicated. The reporting and analytics capabilities in Polarion ALM could be improved as there are some dashboard functionalities, but they are not fulfilling our requirements.

The user interface of Polarion ALM needs improvement as it can experience changes that disrupt workflows, especially during major updates. Sometimes, database migrations take too long, spanning two to three days, which can be a disruption. Additionally, there is a need for better speed and efficiency when doing bulk updates with large data sizes. This is critical for big updates that could be reduced to shorter durations.

Polarion ALM ( /categories/application-lifecycle-management-alm-suites ) could see improvements in performance and scalability. The system’s technology is not the most current, leading to missing features that are common in web-based applications. Users need to manually save their progress, unlike more modern systems. The collaboration features, such as editing the same document simultaneously, also need enhancement. Additionally, the high price compared to other products and complex installation procedures are issues. Lastly, API integration through REST needs improvements.

I also recently suggested that CMS consider incorporating generative artificial intelligence into the system. This could greatly enhance requirement checking, improve form, content, and clarity, and assist in defining tests and developing models.

Some parts related to the dashboard need improvement. Nowadays, the dashboard is too complex to be created.

Integration requires a lot of effort. You typically need to work with an implementation partner to get it done. Most connectors available for Polarion ALM are paid. Unlike other vendors offering several standard connectors for free, integrating third-party software with Polarion ALM involves discussing and coordinating with the third-party software providers, which requires effort. Most of our customers use multiple third-party software, and integrating them with Polarion ALM can be difficult. Even if we configure it for project use, integrating all this software plays a major role. It’s challenging to convince clients to use Polarion ALM because it requires a lot of effort and manual work to sync data from other third-party software.

At the moment, I haven't looked in-depth into what needs improvement in the product. Based on my understanding, the tool's integration capabilities with multiple tools is an area of concern that Polarion needs to focus on more. Polarion ALM's features should be communicated easily with other tools as well. My company developed and built up some areas in Polarion ALM, because of which we are able to communicate its features with the other tools we use, but in general, everywhere, it is quite difficult to do it, mainly on the side of Azure DevOps. If you just look at Azure DevOps, it is completely on CI/CD pipeline, and the development process for certain things happens in such a tool when revolving around areas, like Sprint, Scrum, and Kanban, that fall under agile methodologies and not there in ALM, making it an area Polarion needs to build. Otherwise, Polarion ALM should be able to integrate with multiple tools and make the overall functioning feel much better.

The tool needs to improve its planning. It also needs to add more integrations.

The weak point of Polarion ALM software is about reporting and time for extraction of the data included in the database to communicate with the regulatory authority. Polarion did not understand that its user just wanted the reports to be submitted in a better way. So about the improvement needed for the entire Polarion software, I spoke several times about the difficulties of the company working with a fixed standard with a document that is 500 pages, and you get this with a PDF. Also, each line of the standard will be connected to risk analysis. So the improvement I proposed is to transfer the PDF document and pages inside the database directly to be able to use each pair with the database tools. So what I saw is that Aligned Elements proposed this but never maintained this correctly, so it was useless since data was changing very often. The database standard will be very useful for doing the safety report and everything. In fact, with what is coming for the regular database, they need to add on the database format. So this is a change that happened now. So, how to integrate these changes inside the software is new. The EDR software will be software that includes thousands of standard insights in a database and maintains them correctly. My customers were complaining about the quality of the report. The quality of reporting needs to improve.

The planning and task management aspects of the solution were not that easy. It is a bit complex to set up.

The solution needs to improve its user experience and graphics.

The solution's editing capabilities need improvement. I would like the traceability and the generation of trace matrices beefed up. Felix ALM had a very flexible and powerful trace matrix capability, that Polarion ALM doesn't have. Currently, we have a person that writes scripting to do trace matrices across requirements tests, and different versions. The solution has a real problem when we have two or more people working on the same document with different WIs. in Polarion ALM, we have no way of knowing if someone else is using the same document until we try to exit because a notification pops up indicating someone else is working on the document. If we exit, we potentially will override their work and will have to go into the history to reconsolidate the document." The solution only indicates that someone else is also accessing the document once we have completed our work and it does not provide any information about who it is which makes things even more complicated when trying to consolidate the document.

The solution can be improved by making it more user-friendly, and a server-based application rather than client based. I find it difficult to update the test cases in the test run and would like a more simplistic process. As an example, If I create version one of the test case. And in a test run, I add that version one of the test cases in the test run and I go to that test case and update it to version two, I can update that fine, but in the test run, it is not automatically updated to version two.

As Polarion ALM is a development-oriented tool, easy support or easy access is provided by default, but if I want to use detailed features, I need to write the script, particularly the VM script, and this is its area for improvement. I want Polarion ALM to have a graphical user interface that doesn't need scripting. In the next release of the tool, I'd like for it to not require scripting and programming because needing to run script language is time-consuming.

We use PTC Windchill, and Polarion ALM doesn't have native integration, so we had to purchase the connector to integrate it with Polarion ALM. We still haven't implemented it.

One of Polarion's shortcomings would be planning. It can handle plans, but the planning feature is very basic. There are third-party solutions that could be easily incorporated or built into the license. They have plugins they developed only after many customers complained about Polarion's integration with third-party repositories. Some of the repositories aren't working all the time. So it works when you set it up, but it stops working after a while, and there is nothing you can do except reset the whole server and try it again. So it's not a convenient way to deal with those issues because the solution should be up 99.9% of the time. Another issue is Polarion's integration with external tools, including repositories for source code, mechanical design, electrical designs, etc. There should be out-of-the-box integration with different tools like Jira or things of that nature. Some of this functionality exists, but it's not so easy to set up. Polarion ALM needs more integration with external repositories, especially for source code. Most of these tools don't recommend using Polarion ALM as a repository, so you have to use Search Party or a different tool for that. And integration is not straightforward or not easy to do.

The solution is not easy to use. The configuration aspect of the solution is not easy. A person needs a lot of programming knowledge in order to successfully handle the job. The cost of the product is quite high. They should work to bring it down a bit so it's not on the higher end of the market.

This is an area that has already been corrected, but the Navigation areas of the document and being able to have subdocuments was an area that needed improvement. Technical support needs some improvement. The pricing could be reduced. If the pricing would come down and it was more affordable then we wouldn't have to switch.

The ease-of-use could be improved a little, but at the same time, it's a complex tool so that has to be expected; such a complex tool cannot be completely straightforward. The license model is okay for large companies but would be quite expensive for smaller enterprises. Also, the beginner's tutorials are quite outdated — working on versions from 2010 or 2012. More up-to-date tutorials with different use cases would be a nice adjustment. It's always possible to improve such tools by adding more features and improving automatization. For example, we never tried the connection to build service. I believe it's possible to do that, to automatically link it to the software build process. We only used it more or less manually. It's possible that, that feature could be improved because I believe there was a reason why we didn't do it, but I can't explain in more detail as I was not really involved in the process. In general, I would like to see improvements on the information and materials.

The most important thing for them to improve should be platform-independent features. They should also provide extensive pipelines and release pipelines that we can define and we can work on. Another area of improvement is integration with external tools and external platforms like Linux, Mac, and other stuff. Most of the teams are basically moving towards faster development. Everything should be flexible. All the tasks you can see in AWS and Azure, you would just need to drag and drop and release into the pipeline. Right now, if you can evaluate the tools, then I think that as for the cost differences and for the usability, and other things concerned, so I will rate AWS at the first, Azure second, and then Atlassian tools and then Siemens would be fourth or fifth.

The interface for this solution needs to be made more user-friendly to provide a better user experience. If we have too many work items in one LiveDoc then usage can be limited because the loading times are very slow. In the next release of this solution, I would like to see the limitations removed. There should be a better facility for importing, such as from an IBM Rational Doors document. The configuration would be much simpler if it had limited functions for synchronizing with JIRA, for example.