The development of medical device products places high demands on documentation and traceability. Especially when developing complex devices, documentation using Word and Excel is no longer effective. This is where ALM (Application Lifecycle Management) tools come in. These tools can make development efficient, transparent, and process-reliable. This blog post illustrates the development process for medical devices using Polarion.
What is Polarion?
Polarion is a web-based tool that runs on an internal company server. Users can simply log in and use the tool via their web browser. Data is stored on an SVN server. This ensures that data can be restored at any time and that all changes are traceable (audit trail). Polarion is a widely used tool, particularly in the medical technology sector, and is currently outstanding due to its unique usability and performance.
Work items are a central aspect of Polarion. A work item is a data container with attributes and a workflow. An example of a work item is a "software requirement." The software requirement is linked to a system requirement via the "traces to" relationship and is covered by a software system test. The "covered by" relationship serves this purpose. The link relationships therefore result in concrete added value for the work item. The requirement can easily be compared with the test cases or the source of a requirement can be found. Another advantage of work items is that workflows can be defined for the individual work items. This ensures that a software requirement can only be approved by a "reviewer," just as a test can only be carried out by a "tester." Furthermore, it is checked that required attributes are filled. In other words, that an expected result is defined for a software test before the test is released for execution. Workflows enable process-safe work and make it easy to capture the precise project status. Wiki pages in Polarion offer the ability to visualize the status and identify errors.
How does product development work?
Different roles within a company are involved in the development of a product. There is the product manager, who knows the market and what they can sell. There are the quality assurance officers who ensure compliance with approval-relevant aspects and legal regulations. There is the project manager, who wants to complete a product by a certain date and within a budget. Then there are the experts in the areas of systems, hardware, software and mechanics. And finally, there are the test engineers who put the product through its paces. To avoid losing track in such a complex organizational structure, there is a process that specifies how the organization should proceed to achieve the goal. In medical technology, the V-model is primarily used as a process model. This results in documents and requirements at the product, system, sub-systems and design levels, as well as the associated tests.
How do we represent this in Polarion?
The product development process can be mapped in Polarion. This enables the tool to support the described approach. Polarion first divides projects. A project contains the information for developing a product. A project has subfolders, called "spaces," that contain the wiki pages and Polarion documents. The spaces cannot be arranged hierarchically. Therefore, a meaningful and streamlined folder structure is important.
|
|
| Dipl.-Ing. Goran Madzar, Partner, Senior Systems Engineer E-mail: madzar@medtech-ingenieur.de Phone: +49 9131 691 240 |
|
Do you need support with the development of your medical device? We're happy to help! MEDtech Ingenieur GmbH offers hardware development, software development, systems engineering, mechanical development, and consulting services from a single source. Contact us. |
|
The work items have specific input fields (attributes) that are tailored to the work item. In addition, there is a defined workflow for each work item. As an example, a software requirement and a software system test are represented here. There are two active roles in the software requirement: the developer and the reviewer. The developer specifies the requirements and assigns them to the reviewer. The reviewer is responsible for reviewing and approving the requirement, or returning it to the developer if the requirement is not satisfactory.

There are three active roles in software testing. The developer specifies the test, the reviewer verifies and approves it, and the tester executes the test. Finally, the reviewer must evaluate whether the test passes or fails. The roles and workflows can be customized in Polarion as required and should meet your company's processes.

What else can you do in Polarion?
Polarion offers the option of integrating bug tracking. The "Problem Report" work item can be used for this purpose. Integrating bug tracking into Polarion avoids errors that can arise from switching between Polarion and other bug tracking tools (e.g., Bugzilla, Mantis, etc.). Bugs can also be easily linked to the test cases that lead to the error. It's even possible to automatically generate bug reports when a test run finds an error.
Polarion features the "Task" work item. This allows you to manage and coordinate tasks. Tasks within a team can be recorded as tasks and assigned to the responsible person. Anyone with appropriate access can comment on a task. It's also possible to attach files. This makes Polarion a very practical collaboration tool for managing tasks within teams.
Polarion offers the "Word Round Trip" feature. This allows Polarion users to import and export documents from Word into Polarion. This makes it possible to collaborate with people who don't use Polarion. These can be external partners (e.g., clients, contractors) or even people within the company who don't use Polarion.
What should be considered when implementing Polarion?
When introducing tools, there's always the risk of overshooting the mark. The new possibilities and ways of thinking lead to essentially integrating everything into one tool. This requires prudent and cautious approach. A tool as powerful as Polarion can't be implemented overnight, and the tool must be adapted to the company's needs. Therefore, it's a good idea to introduce the tool step by step and allow time for it. It's also very important to involve employees, as otherwise, rejection and frustration can arise.
My conclusion
If you're considering an ALM tool, in my experience, Polarion is a very good and convenient tool for this purpose. However, integrating a tool into a company initially involves work and effort. And ultimately, the tool can't do your work for you.
A fool with a tool is still a fool, but the tool makes the disaster faster.
I welcome feedback and would love for you to contact me. Feel free to leave a comment on the article. If you know someone who might also be interested in the blog, I'd be very happy if you would recommend it.
Best regards
Goran Madzar


