Polarion Projekt-Vorlage für System- und Geräteentwicklungen

Übersicht

Polarion ist ein ALM-Werkzeug und bietet viele Möglichkeiten Entwicklungsprojekte zu begleiten. Die Konfiguration und Anpassung von Polarion auf eigene Zwecke ist sehr flexibel.

Dieses Vorlagenprojekt eignet sich dafür Entwicklungsvorhaben für kleine moderate Systeme oder Produkte strukturiert aufzusetzen. Es sorgt von Anfang an für eine einheitliche Struktur an Ordnern, Verlinkungen und Reports.

Die Anlehnung an das V-Modell sorgt für eine bekannte Darstellung und großes Verständnis bei vielen Projektbeteiligten.

oberer linker und rechter Teil des V-Modells

Das Vorlagenprojekt beinhaltet Artefakte, die benötigt werden, um ein Entwicklungsprojekt auf Systemeebene abbilden und durchführen zu können. Dies umfasst neben den Systemanforderungen und den dazugehörigen Systemtestfällen auch die vorgelagerten Anwendungsfälle – auch Use-Cases genannt – und die Artefakte des Änderungswesens (Fehlereinträge und Change-Requests).

Abbildung 1 – Systemebene im V-Modell

Abbildung 2 – erste Ordnerstrukturen in Polarion

Ordnerstrukturen zur Verwaltung von Live-Docs und Reports

Da in Polarion alle Daten in einer großen Datenbank liegen, ist es sinnvoll, verschiedenen Sichten anzulegen, um gezielt die unterschiedlichen Aspekte der System- und Produktentwicklung betrachten zu können. Dazu sind erste Ordnerstrukturen in diesem Template vorhanden, die dabei helfen, diese Ordnung zu erreichen.

Diese Ordnerstrukturen sind Teil einer größeren Struktur von Ordnern, die neben denen in Polarion auch auf einem Netzlaufwerk etabliert werden können. Wie diese Strukturen aussehen können ist in Abbildung 2 zu erkennen.

Abbildung 3 – vollständige Liste der Ordnerstruktur

Anwendungsfälle, Systemanforderungen und Systemtestfälle

In diesem Vorlagenprojekt sind Use-Cases, Systemanforderungen und Testfälle (auf Systemebene) enthalten.

Use-Cases dienen dazu, die Situationen zu beschreiben, in denen das System / das Produkt zum Einsatz kommt. Aus den Use-Cases können die Systemanforderungen abgeleitet werden. Diese beschreiben wiederum die Eigenschaften des Systems, die notwendig sind, um die Anwendungsfälle erfüllen zu können. Die Testfälle wiederum weisen nach, dass die jeweiligen Anforderungen realisiert wurden und wie gewünscht funktionieren.

Eine entsprechende Arbeitsweise vorausgesetzt, ist eine Traceability sofort hergestellt und führt zu keiner Mehrarbeit vor Audits.

Abbildung 4 – Zusammenhänge der Artefakte

Abbildung 5 – Beispiel einer aufgebauten Traceability

Abbildung 6 – Baumstruktur inkl Fehlereintrag

Änderungs- und Fehlerwesen

Auch die Behandlung von Fehlern und das Einstreuen von Änderungen in den Entwicklungsprozess ist durch entsprechende Workitems schon vorkonfiguriert. So können Fehler entstehen, wenn Testfälle durchgeführt wurden und dabei fehlschlagen. Genauso können Fehler, wie auch Änderungswünsche vom Kunden gemeldet werden.

Releaseplanung und Iterationen

Zur Planung der Anforderungen, Änderungswünsche und Fehlerbehebungen dient die Releaseplanung. Dort können die genannten Artefakte zu Releases zusammengefasst werden. Der Fortschritt bzgl. der Realisierung der einzelenen Features des Releases kann sofort in der Übersicht erkannt werden.

Abbildung 7 – Releaseplanung