Zu irgendeinem Zeitpunkt des Lebenszyklus-Prozesses kommt ein Änderungswunsch. Das führt dazu, dass die bisherigen Aktivitäten überdacht werden müssen. Wie geht man am besten damit um, wenn es Änderungswünsche an eine Software oder ein System gibt? Denn das Ziel ist es, Änderungen systematisch durchzuführen.
Die IEC 61508 beschreibt, was in so einem Fall zu tun ist:
7.1.2.9- If at any phase of the software safety lifecycle, a modification is required pertaining to an earlier lifecycle phase, then an impact analysis shall determine (1) which software modules are impacted, and (2) which earlier safety lifecycle activities shall be repeated.
7.5.2.6- During the integration testing of the safety-related programmable electronics (hardware and software), any change to the integrated system shall be subject to an impact analysis. The impact analysis shall determine all software modules impacted, and the necessary re-verification activities.
Um Ihnen eine Hilfe an die Hand zu geben, wie so eine Impact-Analyse gestaltet werden kann, teile ich heute Auszüge aus unserem Formblatt zur Impact-Analyse. Dieses Formblatt nutzen wir in unserem Software-Entwicklungsprozess.
Zunächst einmal starten wir mit der Identifikation der Software und der Beschreibung der Änderung. Jede Impact-Analyse bekommt bei uns eine eindeutige ID (z.B. #2019-004). Damit kann man die Impact-Analysen besser verwalten.
| Software Name | |
| Software Version | |
| Software Hersteller | |
| Beschreibung | |
| Impact Analyse ID |
#2019-004 |
Der erste Teil des Dokumentes stellt den Impact Analysen Plan dar. Hier bewerten wir die Änderungen und planen die zu ändernden Dokumente und weitere Aktivitäten. Wir listen zunächst die Änderungen auf. Jede Änderung ist in unserem Bug-Tracking Tool hinterlegt und hat eine ID und eine Beschreibung. Diese Inhalte kommen in die Impact-Analyse. Dann wird bewertet, ob die Änderung sicherheitskritisch ist. Sicherheitskritisch sind Änderungen dann, wenn sie Einfluss auf wesentliche Leistungsmerkmale, grundlegende Anforderungen oder Risikokontrollmaßnahmen haben. Für sicherheitskritische Änderungen, ist entsprechend ein höherer Aufwand einzuplanen.
|
|
| Dipl.-Ing. Goran Madzar, Gesellschafter, Senior Systems Engineer E-Mail: madzar@medtech-ingenieur.de Tel.: +49 9131 691 240 |
|
Benötigen Sie Unterstützung bei der Entwicklung Ihres Medizingeräts? Wir helfen gerne! Die MEDtech Ingenieur GmbH bietet Hardware-Entwicklung, Software-Entwicklung, Systems Engineering, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf. |
|
Um den Impact zu bewerten, werden die durch die Änderung betroffenen Komponenten, Anforderungen und Tests identifiziert. Änderungen an Software oder Systemen können immer zu Wechselwirkungen im System führen, über die man sich Gedanken machen muss. Ändert man z. B. die Farbe in einer graphischen Benutzeroberfläche, kann das dazu führen, dass der Nachtmodus nicht mehr richtig dargestellt wird. Es ist somit zu überlegen, welche negativen Effekte durch die Änderung hervorgerufen werden können und welche Regressionstests durchgeführt werden sollen. Regressionstests dienen dazu, Fehler durch unabsichtlichen Wechselwirkungen zu finden. Unsere Tabelle hat den folgenden Aufbau:
| Änderung | Sicherheitskritisch | Betroffene | Notwendige | |||
| ID | Beschreibung | (ja / nein) | Komponenten | Anforderungen | Tests | Regressionstests |
Änderungen an Software oder an dem System führt zwangsläufig zu Änderungen an der Dokumentation. Auch dies ist sorgsam zu dokumentieren. Dazu bietet sich die folgende Darstellung an:
| Dokumentenbezeichnung | Aktuelle Version | Änderungsbeschreibung | Zielversion |
Damit zeigt man an, welche Dokumente, in welcher Version vor der Änderung gültig waren. In der Änderungsbeschreibung definiert man, was an dem Dokument zu ändern ist und gibt eine Zielversion an, wenn die Änderung abgeschlossen ist. Relevant sind nur die für die Änderung relevanten Dokumente.
Neben den Dokumenten kann es notwendig sein, weitere Aktivitäten durchzuführen. Z.B. könnten Code Reviews notwendig werden. Diese Aufgaben, nehmen wir im Kapitel „Weitere Aktivitäten“ mit auf.
| Titel | Beschreibung | Verantwortlich |
Der zweite Teil des Dokumentes ist der Impact Analysen Bericht. Der Abschnitt Bericht wird ausgefüllt, wenn die Änderung durchgeführt wurde. Damit soll sichergestellt werden, dass die identifizierten Aufgaben aus dem Plan erfolgreich umgesetzt wurden. Bei der Planung bleibt der Abschnitt leer. Das realisieren wir in unserem Formblatt durch eine Checkbox, die entweder bei Plan oder bei Bericht zu setzen ist. Am Ende gibt es zur Impact-Analyse zwei unterschriebene Dokumente, eines für den Plan und eines für den Bericht.
Im Bericht ist zu bestätigen, dass die Aufgaben aus dem Plan umgesetzt wurden. Das geschieht durch eine Liste mit Checkboxen und eine Tabelle für ggf. vorliegende Abweichungen. Abweichungen sind in jedem Fall zu begründen. Das Ganze wird somit wie folgt dargestellt:
Alle Aufgaben aus dem Plan der Impact Analyse wurden umgesetzt.
[x] ja
[ ] nein
[ ] mit Abweichung
| Abweichung | Begründung |
Am Ende stellt sich noch die Frage, ob die Änderung freigegeben werden kann oder nicht. Auch das wird mit Checkboxen realisiert:
Änderung ist freigegeben.
[x] ja
[ ] nein
Das Dokument endet mit einer Dokumentenfreigabe.
| Name / Rolle | Firma / Abteilung | Ort / Datum | Unterschrift |
Die Impact-Analyse ist aus meiner Sicht ein sehr nützliches Mittel, um strukturiert mit Änderungen umzugehen und diese auch im Nachhinein nachvollziehbar zu dokumentieren. Änderungen führen oft zu Wechselwirkungen, die nicht bedacht werden und werden zudem oft schlecht dokumentiert. Daher empfehle ich, den Impact systematisch, wie in dem Blogbeitrag beschrieben zu analysieren und zu dokumentieren.
Haben Sie Fragen zur Impact-Analyse oder zu Entwicklungsprozessen? Dann sprechen Sie mich gerne an.
Viele Grüße
Goran Madzar
