Haben Sie schon mal etwas geerbt? Ein Erbe oder ein Vermächtnis kann durchaus etwas Positives sein. Ein anderes Wort macht da schon nachdenklicher: Hinterlassenschaft! Der Begriff Hinterlassenschaft ist im Gegensatz zu Vermächtnis schon deutlich wertfreier und zeigt an, dass da nicht unbedingt etwas Positives hinterlassen wurde. Und was hat das Ganze mit Software zu tun?
Auch Software kann man erben! In diesem Artikel beschreibe ich, wie man mit Legacy Software konform zur IEC62304 umgeht und gebe Einblicke in unsere Prozesse.
Was ist Legacy Software?
Die IEC62304 definiert Legacy Software als Software, die legal in Verkehr gebracht wurde und sich bis heute im Markt befindet, die jedoch nicht gemäß der aktuellen Version der Norm IEC62304 entwickelt wurde (oder dafür keine ausreichenden objektiven Nachweise hat). Wichtig ist dabei: „legal in Verkehr gebracht“. Eine Software, die einfach nur alt und undokumentiert ist, fällt somit nicht unter diese Definition.
Was sagt die Norm über den Umgang mit Legacy Software aus?
Das Kapitel 4.4 im Amendmend 1 der IEC62304 (2015) beschreibt, wie mit Legacy Software umzugehen ist. Dabei bietet die Norm einen alternativen Pfad, um die Konformität der Legacy Software nachzuweisen.
Der klassische Pfad ist die Entwicklung nach Kapitel 5 bis 9 der IEC62304. Die Alternative für Legacy Software zeigt der rechte Pfad in der Darstellung oben.
Die Norm will den Herstellern die Möglichkeit bieten, alte und bewährte Software weiterzunutzen. Es geht dabei nicht darum, nur Papier zu generieren. Vielmehr geht die Norm davon aus, dass durch die fehlenden Dokumente und Aktivitäten ein größeres Risiko vorliegt. Der Hersteller soll sich überlegen, welches Risiko von der Software ausgeht und Aktivitäten durchführen, die das Risiko verringern.
Anleitung zum Umgang mit Legacy Software
Diese Anleitung fasst übersichtlich zusammen, was zu tun ist, wenn man Legacy Software weiterhin nutzen möchte. Dabei unterteile ich die Aktivitäten in 4 Phasen.
Phase 1) Aktivitäten zum Risikomanagement
Beurteilen Sie alle Software Anomalien und Rückmeldungen zu der Legacy Software aus dem Feld. Dazu ist eine bewertete Liste der Anomalien und Rückmeldungen notwendig. Orientieren Sie sich dazu an ihrem Problem-Lösungs-Prozess. Sofern Sie quantitative Aussagen treffen können, ist das für die Risikobewertung hilfreich. Anderenfalls müssen Sie bei der Risikobewertung immer vom Worst Case ausgehen!
Erstellen oder aktualisieren sie die Software Architektur. Aus der Architektur muss deutlich werden, welche Teile Legacy Code sind! Identifizieren Sie die Legacy Software mit genauer Angabe der Version oder Revision.
Führen Sie die Aktivitäten des Risikomanagements durch. Legen Sie dabei besonderes Augenmerk auf die Legacy Software. Bedenken Sie auch, wie die Software zukünftig eingesetzt werden soll:
- gleiche Nutzung
- ähnliche Nutzung mit leichten Anpassungen
- deutlich andere Nutzung eventuell mit anderer Zweckbestimmung.
Legen Sie die Sicherheitsklassifizierung der Legacy Software fest.
Phase 2) Gap Analyse (⇾ Plan)
Stellen Sie die Liste der geforderten Deliverables und Aktivitäten gemäß ihres Software-Lebenszyklus-Prozesses und gemäß der Sicherheitsklassifizierung auf. Ihr Prozess muss selbstverständlich konform zur IEC62304 sein.
Stellen Sie die vorliegenden Dokumente und durchgeführten Aktivitäten den geforderten gegenüber. Dazu bietet sich eine Tabelle an, mit der Forderung auf der linken Seite und den vorliegenden Dokumenten auf der rechten Seite. Damit bekommen Sie einen guten Überblick und können leicht die fehlenden oder nicht ausreichenden Punkte identifizieren und kenntlich machen.
Prüfen Sie die vorhandenen Dokumente daraufhin, ob diese weiterhin gültig und vollständig sind.
Identifizieren Sie Lücken (fehlende Dokumente und Aktivitäten) und bewerten Sie, wie sehr Sie das Risiko reduzieren können, indem Sie die fehlenden Dokumente und Aktivitäten nachholen. Sie sind nicht gezwungen alles nachzuholen. Es ist wichtig, dass Sie sich Gedanken machen, welche Aktivitäten in Bezug auf die Reduktion des Risikos relevant sind. Die Norm geht z. B. davon aus, dass Detailed Design und Unit Verifizierung sehr wohl bei der Erstellung der Software, Risiko reduzieren, im Nachhinein aber nicht mehr unbedingt viel dazu beitragen, außer Papier zu generieren.
Definieren Sie einen Plan, aus dem hervorgeht, welche Dokumente und Aktivitäten zu erstellen sind, wer für die Aufgabe verantwortlich ist und bis wann die Aufgabe zu erledigen ist. Orientieren Sie sich dabei an ihrem Software-Wartungsplan! Das Mindestmaß der notwendigen Dokumente ist aus meiner Sicht, die Software System Anforderungen zu definieren und dokumentiert zu testen (Testspezifikation + Testbericht). Die Software Architektur ist ebenfalls essenziell, da sie bereits für das Risikomanagement notwendig ist. Verwenden Sie, wenn möglich, bestehende Dokumente oder bauen Sie auf diesen auf. Das reduziert den Aufwand und stellt sicher, dass Sie keine wesentlichen Aspekte vergessen, die Ihnen eventuell nicht mehr bekannt sind. Idealerweise können Sie auf Entwickler zurückgreifen, die Erfahrung mit dieser Legacy Software haben. Dann würde ich dazu raten diese Personen mit einzubeziehen. Externe Personen bieten den Vorteil, dass sie nicht befangen oder betriebsblind sind. Behalten Sie den Fokus bei allen ihren Aktivitäten darauf, die Risiken zu minimieren.
Phase 3) Durchführen der Aktivitäten aus dem Plan, um Lücken zu schließen
Das Team führt die Aktivitäten aus dem Plan der Gap Analyse durch. Halten Sie sich dabei an Ihren Software-Entwicklungs-Prozess und den in der Gap Analyse erstellten Plan. Dokumentieren Sie, was Sie tun und insbesondere was Sie nicht tun und warum!
Phase 4) Begründung für die Nutzung der Legacy Software (Rationale)
In der Begründung dokumentieren Sie, dass die Software für den geplanten Einsatzzweck sicher und zuverlässig ist. Folgende Punkte sollten dabei enthalten sein:
- Der geplante Kontext, in dem die Legacy Software eingesetzt werden soll.
- Eine Aussage über die Sicherheit und Zuverlässigkeit der Software.
- Die Version der Legacy Software.
Einmal Legacy, immer Legacy?
Legacy Software oder Teile davon, mit verbleibenden Lücken (Gaps) in den Deliverables und Aktivitäten, bleibt auch in Zukunft Legacy Software und muss entsprechend Kapitel 4.4 behandelt werden. Werden jedoch alle Lücken geschlossen, dann ist es auch zulässig die Konformität auf klassische Art und Weise zu erklären. Damit ist es möglich Legacy Software wieder auf den Pfad der Tugend zurückzuholen.
Was sind die Herausforderungen im Umgang mit Legacy?
Bei der Bearbeitung von Legacy Software gibt es die ein oder andere Herausforderung. Anbei eine Liste der Punkte, die ich hierbei sehe.
TOP1: Code, Architektur und Werkzeuge sind nicht mehr zeitgemäß
Schaut man sich alten Code oder alte Architektur an, dann sind diese oft nicht mehr State of the Art. Am liebsten würde man alles neu schreiben. Das ist aber aufwendig und zudem hat die alte Software durchaus ihre Berechtigung. Schließlich ist sie seit langem im Markt und funktioniert anscheinend sehr gut. Auch die Mikrocontroller und die Entwicklungswerkzeuge sind oft nicht mehr der neueste Schrei, was zu Ablehnung bei den Entwicklern führt.
TOP2: Ursprüngliche Entwickler nicht mehr vorhanden
Das Wissen über Software nimmt ab, da Entwickler, die die Software ursprünglich geschrieben haben, nicht mehr da sind. Entweder sind die Entwickler mittlerweile befördert worden und schreiben keine Software mehr oder sie haben das Unternehmen bereits verlassen. Das führt dazu, dass Wissen verloren geht und der Aufwand entsprechend steigt.
TOP3: Unkenntnis der Prozesse und Normen
Die Prozesse und die Kenntnisse zum Umgang mit Legacy Software sind im Unternehmen nicht vorhanden. Das führt dazu, dass es viel Aktionismus gibt, aber keiner weiß was zu tun ist. Eventuell droht sogar Ärger mit der benannten Stelle, was das Ganze noch verstärkt. Dann ist externe Hilfe absolut sinnvoll.
|
|
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. |
TOP4: Unklare Zieldefinition im Umgang mit Legacy
Legacy Code ist nichts Schlechtes. Daher ist es wichtig, ein Ziel und eine Strategie zu definieren. Will man von der Legacy Software wegkommen und wieder nach dem klassischen Entwicklungsprozess arbeiten? Oder will man einfach nur mit minimalem Aufwand, die Software weiter benutzen können? Die Definition des Ziels ist sehr wichtig für die Entscheidungen, die in der Gap Analyse folgen.
TOP5: Kein Personal
Wer soll die ganze Arbeit machen? Oft arbeiten die Entwickler an neuen Produkten und es gibt wenig Ressourcen für die alten Produkte. Das führt zu langen Durchlaufzeiten. Auch hier ist externe Unterstützung sinnvoll.
Unsere Vorgehensweise, Sie zu unterstützen
Wenn wir Sie unterstützen, dann gehen wir dabei wie im Zeitplan unten dargestellt vor. Die Aufwände hängen dabei von der Legacy Software und dem damit verbundenen Umfang der Arbeiten ab. Der Umfang kann nach einem ersten Gespräch grob geschätzt werden und nach der Review- und Planungsphase konkretisiert werden. Sobald die Informationen aus dem Risikomanagement und der Gap Analyse vorliegen, steht der Fahrplan zur Abarbeitung der Aufgaben und zur Schließung der Lücken.
Ich hoffe, dass Sie durch diesen Artikel ein bisschen Klarheit im Umgang mit Legacy Software gewonnen haben. Sofern Sie Fragen haben oder Unterstützung benötigen, können Sie mich gerne kontaktieren.
Viele Grüße
Goran Madzar