Polarion in der Medizintechnik

Die Entwicklung von Produkten in der Medizintechnik stellt hohe Anforderungen an die Dokumentation und Rückverfolgbarkeit. Insbesondere bei der Entwicklung von komplexen Geräten ist eine Dokumentation mit Word und Excel nicht mehr zielführend. An dieser Stelle unterstützen sogenannte ALM-Tools (Application Lifecycle Management). Mit diesen Tools kann die Entwicklung effizient, transparent und prozesssicher gestaltet werden. In diesem Blog-Artikel soll der Entwicklungsprozess für Medizingeräte mittels Polarion veranschaulicht werden.

Was ist Polarion?

Polarion ist ein webbasiertes Tool, welches auf einem firmeninternen Server läuft. Die Benutzer können sich einfach über ihren Webbrowser anmelden und das Tool verwenden. Die Daten werden auf einem SVN Server gespeichert. Damit ist jederzeit sichergestellt, dass die Daten wiederhergestellt werden können und alle Änderungen nachvollziehbar sind (Audit Trail). Insbesondere im Medizintechnik Umfeld ist Polarion ein verbreitetes Tool, welches durch seine einzigartige Bedienung und Leistungsfähigkeit im Moment herausragend ist.

Ein zentraler Aspekt von Polarion sind Workitems. Ein Workitem ist ein Daten-Container mit Attributen und einem Workflow. Als Beispiel für ein Workitem sei mal ein „Software Requirement“ genannt. Das Software Requirement ist über die Beziehung „traces to“ verlinkt mit einem System Requirement und wird durch ein Softwaresystem Test abgedeckt. Dazu dient die Beziehung „covered by“. Durch die Link-Beziehungen ergibt sich daher ein konkreter Mehrwert des Workitems. Leicht können die Anforderung den Testfällen gegenübergestellt oder aber die Quelle einer Anforderung gefunden werden. Ein weiterer Vorteil der Workitems ist, dass Workflows für die einzelnen Workitems festgelegt werden können. In diesem Fall wird sichergestellt, dass die Freigabe eines Software Requirements nur von einem „Reviewer“ erfolgen kann, ebenso wie ein Test nur durch einen „Tester“ möglich ist. Außerdem wird überprüft, dass geforderte Attribute ausgefüllt werden. Also, dass bei einem Softwaretest ein erwartetes Ergebnis definiert ist, bevor der Test zur Durchführung freigegeben wird. Durch die Workflows ist damit ein prozesssicheres Arbeiten möglich und es ist einfach den genauen Projektstatus zu erfassen. Wiki-Seiten in Polarion bieten die Möglichkeit den Status sichtbar zu machen und Fehler zu erkennen.

Wie läuft eine Produktentwicklung ab?

Bei der Entwicklung eines Produktes sind unterschiedliche Rollen innerhalb eines Unternehmens beteiligt. So gibt es den Produktmanager, der den Markt kennt und weiß, was er verkaufen kann. Es gibt die Qualitätsbeauftragen, die die Einhaltung der zulassungsrelevanten Aspekte und gesetzlichen Vorschriften sicherstellen. Es gibt den Projektleiter, der ein Produkt zu einem gewissen Termin und im Rahmen eines Budgets fertigstellen möchte. Dann gibt es die Experten in den Bereichen System, Hardware, Software und Mechanik. Und schließlich gibt es Testingenieure, die das Produkt auf Herz und Nieren prüfen. Um bei einer solch komplexen Organisationsstruktur nicht den Überblick zu verlieren, gibt es einen Prozess, der vorgibt wie innerhalb der Organisation vorzugehen ist, um zum Ziel  zu kommen. In der Medizintechnik wird hauptsächlich das V-Modell als Prozessmodell verwendet. Es ergeben sich Dokumente und Anforderungen auf den Ebenen Produkt, System, Sub-Systeme und Design sowie die zugehörigen Tests.

Wie bilden wir das in Polarion ab?

Der Ablauf einer Produktentwicklung kann in Polarion abgebildet werden. Damit wird das Tool in die Lage versetzt das beschriebene Vorgehen toolseitig zu unterstützen. Polarion unterteilt zunächst einmal Projekte. Ein Projekt beinhaltet die Informationen für die Entwicklung eines Produktes. Ein Projekt hat Unterordner, sogenannte „Spaces“, die die Wiki-Seiten und Polarion Dokumente enthalten. Die Spaces können nicht hierarchisch angeordnet werden. Daher ist eine sinnvolle und schlanke Ordnerstruktur wichtig.

Die Workitems haben spezifische Eingabefelder (Attribute), die für das Workitem zugeschnitten sind. Zudem gibt es einen definierten Workflow für jedes Workitem. Beispielhaft soll hier ein Software Requirement und ein Softwaresystem Test abgebildet werden. Beim Software Requirement gibt es zwei aktive Rollen. Das ist der Entwickler und der Reviewer. Der Entwickler spezifiziert die Anforderungen und weist sie dem Reviewer zu. Dieser hat die Aufgabe die Anforderung zu prüfen und freizugeben bzw. wieder an den Entwickler zurückzuweisen, falls die Anforderung nicht in Ordnung ist.

Beim  Software Test gibt es drei aktive Rollen. Der Entwickler spezifiziert den Test, der Reviewer verifiziert und gibt ihn frei. Der Tester führt den Test durch. Am Ende muss der Reviewer evaluieren, ob der Test bestanden ist oder nicht. Die Rollen und Workflows können in Polarion beliebig angepasst werden und sollten den Prozessen in Ihrem Unternehmen genügen.

Was sonst kann man in Polarion machen?

Polarion bietet die Möglichkeit das Bug-Tracking mit zu übernehmen. Dazu kann das  Workitem „Problem  Report“ verwendet werden. Durch die Integration des Bug-Trackings in Polarion werden Fehler vermieden, die durch den Wechsel zwischen Polarion und anderen Bug-Tracking-Tools (z.B. Bugzilla, Mantis, …) entstehen können. Die Bugs können zudem leicht mit den Testfällen verlinkt werden, die zu dem Fehler führen. Es ist sogar möglich automatisch Bug Reports zu generieren, wenn ein Test Run einen Fehler findet.
In Polarion gibt es den Workitem „Task“. Damit lassen sich Aufgaben verwalten und koordinieren. Aufgaben innerhalb des Teams können als Task aufgenommen und der zuständigen Person zugeordnet werden. Alle mit entsprechendem Zugriff können Kommentare zu einem Task abgeben. Es ist auch möglich Dateien anzuhängen. Damit ist Polarion ein sehr praktisches Collaboration Tool, mit dem Aufgaben innerhalb von Teams verwaltet werden können.

Polarion bietet das Feature “Word-Round-Trip” an. Damit kann der Polarion Nutzer Dokumente aus Word in Polarion importieren und auch wieder exportieren. Dadurch ist es möglich mit anderen Leuten zusammenzuarbeiten, die nicht Polarion benutzen. Das können externe Partner (z.B. Kunden, Auftragnehmer) oder aber auch Personen im Unternehmen sein, die nicht mit Polarion arbeiten.

Was ist bei der Einführung von Polarion zu berücksichtigen?

Bei der Einführung von Tools besteht immer die Gefahr weit über das Ziel hinauszuschießen. Die neuen Möglichkeiten und Denkweisen führen dazu, dass man im Prinzip alles in ein Tool integriert. Hier ist besonnen und mit Vorsicht zu handeln. Ein so mächtiges Tool wie Polarion kann nicht über Nacht eingeführt werden und das Tool ist auf die Bedürfnisse des Unternehmens anzupassen. Daher ist es sinnvoll das Tool Schritt für Schritt einzuführen und Zeit einzuplanen. Es ist auch sehr wichtig die Mitarbeiter mitzunehmen, da es sonst zu Ablehnung und Frust kommen kann.

Mein Fazit

Falls Sie über ein ALM-Tool nachdenken, so ist aus meiner Erfahrung Polarion ein sehr gutes und komfortables Werkzeug für diesen Zweck. Die Integration eines Tools in einem Unternehmen ist aber zunächst mit Arbeit und Anstrengung verbunden. Und letzten Endes kann ihnen das Tool nicht Ihre Arbeit abnehmen.

A fool with a tool is still a fool, but the tool makes the disaster faster.

Ich freue mich über Feedback und wenn Sie mit mir in Kontakt treten. Sie können gerne auch einen Kommentar zu dem Artikel abgeben. Falls Sie jemanden kennen, für den der Blog ebenfalls interessant sein könnte, freue ich mich auch sehr über eine Weiterempfehlung.

Viele Grüße

Goran Madzar

Kontaktieren Sie uns!