Impact Analyse – Änderungen systematisch durchführen

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.

Ihr Ansprechpartner:

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 und Beratung aus einer Hand. Nehmen Sie Kontakt auf.

Kontakt aufnehmen

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:

ÄnderungSicherheitskritischBetroffeneNotwendige
IDBeschreibung(ja / nein)KomponentenAnforderungenTestsRegressionstests

Ä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:

DokumentenbezeichnungAktuelle VersionÄnderungsbeschreibungZielversion

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.

TitelBeschreibungVerantwortlich

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

AbweichungBegrü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 / RolleFirma / AbteilungOrt / DatumUnterschrift

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

Auch interessant:

Koexistenz zwischen Anforderungs- und Modellierungswerkzeug

Auf dem Requirementsengineering Barcamp 2016 in Köln hatte ich eine Session zu genau diesem Thema. Auf der einen Seite die Anforderungen, auf…

Goran Madzar

Seit Mai 2007 bin ich zusammen mit meinem Kollegen Martin Bosch selbständig. Unser Standort ist im Innovations- und Gründerzentrum in Erlangen. Hier entwickeln wir für Kunden in der Medizintechnik mit unseren Mitarbeitern Lösungen für die Produkte von Morgen.

Getagged mit: ,

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.