Polarion ALM Reviews

We mainly use Polarion ALM for requirements engineering as well as task planning and task execution, but we mainly use it as a documentation and traceability tool.

I work in the medical device development field. Even though Polarion is quite expensive, it's quite a good solution for medical device development in general, especially for software development.

Within our previous company, not that many people used Polarion as it was only used within our department relating to medical device development. I'd say around 20 to 30 people were using it. It's hard to say as we had around six licenses with some floating licenses.

I like that there is, more or less, a single solution for everything. In regards to Polarion, if you're not experienced, it can be quite complicated, so you may need weeks or even months to familiarize yourself with the tools and how it operates. Once you understand how it works it becomes a very useful tool; we mainly use it for requirements engineering, so for us, the traceability is a really important feature. I also like all of the possibilities for different reports and the option to have a "what you see is what you get" editor for all documents and especially, for the release of documents. 

The amount of document control, combined with review and release probabilities and signatures is really useful. For example, Confluence does not have these capabilities. You would have to install Comala, with its plug-in that is used for document control, and even then, it would not be comparable. Polarion's document control is one of the best that I have used. In terms of development itself, having the work items and requirements altogether in one place and being able to control them by Staples, is really helpful.

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.

My current company has been using Polarion ALM for quite a long time, since approximately 2012. I personally started working with Polarion ALM four years ago.

I don't remember any real bugs. We always had some (more or less) minor questions relating to different issues. I don't completely remember, but we had direct contact to our vendor here in Austria, so in most cases, problems could be solved in a more or less direct way. So no really big problems. 

We had a nice experience with technical support. Contacting them was like gaining secret knowledge because so much information is not published, like macros and snippets of code and so on. If you just ask, they will give you different pieces of code for different purposes — for reports for example. You couldn't find that hidden code on your own but if you ask, Siemens will, more or less, give it to you for free. As it's clear that they don't want to publish everything on their website, just ask if they have a solution that is yet to be published, and maybe they can help you out.

I was not involved in the initial setup. Still, when you're working with Microsoft, creating your own code within the system, you have to be the admin. Also, when updating to a newer version, problems can occur leading to the loss of older, developed pieces of code. It's a small issue but you need to be aware of it in order to handle it properly. Other than that, the setup is quite straightforward. 

Maintenance was distributed between several people. We had one main administrator. We were quite a large company with 1,300 people in total, but there were only around 60 of us working in the medical device domain. We had one central IP infrastructure, but they only provided us with computers to the hardware. We managed the tool within the departments on our own. We had one administrator, who was the master administrator, who did the updates, and so on. We also had several tool administrators. In other words, we were two units within the department and for each unit, we had one administrator.

The license model is okay for large companies but would be quite expensive for smaller enterprises.

If you're a beginner to Life Cycle Requirements Engineering in general, I'd recommend that you familiarize yourself with the basics of requirement engineering in order to gain independence of the tool itself. Eventually, when you start using Polarion, start from the very beginning. Even though the tutorials are out-of-date, they are still helpful. 

We also used our vendors as our trainers and teachers. We booked them for three or four days to get a proper introduction to Polarion. Starting off with an expert is a really good idea, it will cost you, but it will save you so much time. One expert instructor can teach more than 20 workers at once, saving you hours or even weeks.

I would rate Polarion really quite high. We were happy with it, and nowadays, without this type of tool, it's not possible to develop medical devices independently of software or hardware. I would give Polarion a rating of nine out of 10.

I use the on-prem deployment model. Our primary use case is for application life cycle management, DevOps, and all the application requirements.

You can see the work ticket and you can circulate that within the teams. You can define your flows, customize according to your needs, and you can create dashboards and create the reports according to your needs. The version is not a distributed version of those systems. I think after requiring the kit by Microsoft most of the parties who are already using different ALM tools, they are moving towards Azure DevOps. Microsoft should be dedicated to moving the teams, creating new features, and making the Azure DevOps most straight-form independent. I have been using Siemens Polarion for three years but I haven't found out a way that you can use it in your own methodology for content management systems. If you were to say that everything is integrated and it's a complete solution, I would say it's not.

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. 

It has worked well. Communication, dashboarding, reporting, content management, workflows, and you are creating user stories and you'll communicate within teams creating different divisions, mapping, queuing; for these kinds of things, that is good.

Scalability is good. It's easy to expand it. 

The initial setup was straightforward as far as the installation and management. It's easy to establish, setup, and deploy. 

The deployment took two to three hours. 

I would rate it a five out of ten. I would like to see better integration and better extensivity of tasks. The costs are not proportionate to the features it offers. 

We primarily use this solution for requirement engineering. 

Our deployment is on a private cloud from Siemens. 

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.

The stability of this solution is not bad, but it could be better. If there are too many work items in one LiveDoc then usage is limited, which requires a workaround.

You have to take care not to use more than 1000 workitems in one livedoc, in other case the loading times will be so long, that you get timeouts for them. Baseline comparisons and other oprations will be timeouted also.

I don't think that this solution scales well. The problem is that they don't have the memory being used entirely. I think that it has something to do with the architecture.

I think that we have plans to increase usage, although I do not have the details as to how. I've got some information from the Siemens colleagues and I see that we cannot improve too much, or in too many ways, due to limitations in the architecture. It means that we have to split our project and use something with fewer objects in it.

There are approximately ten people using this solution.

Technical support for this solution is ok. 

The initial setup of this solution was straightforward, and there were not too many problems with it. The process took a few hours.

I know of some other solutions, but they are different. For example, I think that IBM Rational DOORS is much better for requirements engineering, but it lacks other capabilities from Polarion. Merck may be better. It seems nice and seems to have the same capabilities, but I only have limited experience with it.

My advice to anybody who is implementing this solution is to use less than one thousand work items in one LiveDoc. Otherwise, their experience may be poor. 

I would rate this solution a five out of ten.