Software-Architektur (IEC 62304 konform)

Die Software-Architektur ist die Beschreibung des inneren Aufbaus eine Software-Systems. Üblicherweise identifiziert die Software-Architektur die Komponenten und beschreibt deren Zusammenspiel und Abhängigkeit. Finden Sie in diesem Artikel Informationen zu folgenden Themen:

UML-Diagramme zur Beschreibung von Software-Architekturen

Typische Fehler beim Erstellen der Software-Architektur

Fehler 1: Keine up-front Software-Archiektur

Mit Architektur-Refactoring überfordert

Mancher Freund der agilen Software-Entwicklung wird bei dieser Überschrift aufjaulen. Obwohl ich in meinen Firmen selbst agil entwickle, warne ich davor, die Software-Architektur während der Entwicklung bei jeder Iteration anzupassen. Nahezu alle Software-Entwickler bzw. Software-Architekten sind mit einem kontinuierlichen Architektur-Refactoring überfordert — auch wenn das keiner zugegen möchte.

Die meisten Firmen bzw. Software-Architekten sind bereits damit überfordert, eine Upfront-Software-Architektur zu erstellen. Ich sehe wirklich viele Firmen, und fast alle scheitern daran. Also glauben Sie nicht, Sie könnten „im laufenden Betrieb“ Ihre Software-Architektur anpassen. Das wird man Ihrer Software-Architektur nachher ansehen: „Historisch gewachsen“.

Ging auch mir so

Ich habe eine harte Schule durchlaufen: Wie entscheidend die Software-Architektur für den Erfolg eines Produkts ist, musste ich gleich zweimal lernen.

  1. Das erste Mal, als im Lauf der Jahre meine Software immer unwartbarer und undurchschaubarer wurde und jede Änderung im Code zu zumindest überraschenden Ergebnissen geführt hat. Ich glaubte, ohne explizite Architektur auszukommen. Eine teure Lehre!
  2. Das zweite Mal hatte ich einen strengen Lehrmeister: die Software-Architekten von IBM in Rochester, MN. Ihre Botschaft war eindeutig: „Christian solve your problems in the model“. Und wenn ich mich daran nicht halten würde, würden sie die Zusammenarbeit beenden. Klare Botschaft oder?

Die meisten Probleme, die in der Software-Architektur gelöst werden müssen, sind komplex. Das macht man nicht nebenher.

Software Architektur

Aber die IBM-Jungs hatten Recht. Die eigentliche Entwicklung und Wertschöpfung findet beim Entwerfen der Software-Architektur statt – und (hoffentlich) nicht beim Programmieren. Wer das nicht verstehen will, bezahlt gleich mehrfach:

  1. Man benötigt länger, denn Iterationen und Nachbesserungen gelingen in einem Dokument oder auf einem Flipchart um Größenordnungen schneller als im Code.
  2. Man entwickelt potenziell unsichere Produkte, weil durch unzureichend strene Modularisierung die Risiken nicht beherrscht werden können.
  3. Eine saubere, einfach zu verstehende und konsistente Architektur ist eine zwingende Voraussetzung für eine wartbare Software. „Historisch gewachsen“ zähle ich zu den Unworten in diesem Kontext.

Beachten Sie die regulatorischen Anforderungen an die Software-Architektur

Also, machen Sie es gleich richtig, lösen Sie Ihre „Probleme“ (Requirements) in der (Software-)Architektur und nicht während des Kodierens. Genau das verlangt auch die IEC 62304. Lesen Sie hier mehr zu den regulatorischen Anforderungen an die Dokumentation der Software-Architektur.

Prof. Dr. Christian Johner
Wünschen Sie Unterstützung dabei, eine präzise und gesetzeskonforme Software-Architektur zu erstellen? Melden Sie sich bei mir, ich freue mich darauf!

Fehler 2: Keine standardisierte Notation wie  UML

Die Forderung der IEC 62304, die Software-Architektur zu dokumentieren, führt bei manchen Entwicklern zum reflexartigen Öffnen von PowerPoint und dem Malen irgendwelcher Kästchen.

Softwarearchitektur - Komponenten-Diagramm? Eher nicht...

Davon abgesehen, dass diese Kästchen meist die Architektur gar nicht korrekt abbilden, sind solche Diagramme teilweise wertfrei. Denn ein Modell ist nur dann aussagekräftig, wenn die Notationselemente definiert sind. Doch was bedeutet ein Pfeil bei einer „eigenen“ Modellierungssprache?

  • Eine Abhängigkeitsbeziehung?
  • Eine Assoziation? Komposition oder Aggregration?
  • Eine Vererbungsbeziehung?
  • Eine Datenflussrichtung?
  • Eine Richtung der Methodenaufrufe?
  • Eine Implementierung?

Bevor Sie eine eigene Notation erfinden, nutzen Sie doch UML. Über ein Dutzend Diagrammtypen stehen Ihnen zur Verfügung, mit denen Sie so ziemlich alles ausdrücken können, was Sie benötigen, um Software konzeptionell zu entwickeln.

Ganz automatisch (über)erfüllen Sie damit die Forderungen der IEC 62304.

Review / Verifizierung der Software-Architektur

Die IEC 62304 verlangt, dass die Hersteller die Software-Architektur prüfen, die Norm spricht von verifizieren. Die wichtigesten Aspekte bei der Prüfung sollten sein:

  • Sind alle Software-Anforderungen erfüllt? Mit Traceability-Matrix oder mit Werkzeug prüfen
  • Ist die Risikomanagementakte aktualisiert? Sind alle risikominimierenden Maßnahmen in der Architektur umgesetzt? Sind Risiken, die sich aus der Wahl der Software-Architektur ergeben, analysiert und beherrscht?
  • Erfüllt das Software-Architektur-Dokument die Vorgaben aus dem Entwicklungsplan?
  • Ist die Software-Architektur so verständlich, dass die Entwickler sie ohne weitere Rückfragen umsetzen können?

Review der Software-Architektur als Rollenspiel

Dabei ist die Architektur nur dann eine gute, wenn sie die Komponenten (bei einer Schichten-Architektur die Schichten – bestmöglich getrennt hält (also wirklich komponentenorientiert ist) und wenn Sie geeignet ist, die Systemspezifikation zu erfüllen.

Zumindest letzteres können Sie beim Architektur-Review mit einem Rollenspiel wirkungsvoll prüfen:

Rollenspiel als Metode zum Review der Software-Architektur

Eine Person spielt beispielweise die GUI (also Dialog- und/oder Präsentationsschicht), eine andere Person die Geschäftslogik. Dann geht die GUI stückweise ihre Bildschirmmasken durch und schaut, was sie an Nutzungsobjekten hat. Wenn es beispielsweise eine Tabelle gibt, die alle weiblichen Patienten über 65 mit eine Nephropathie und mit einem Hämoglobinwert unter 10mg/dl und mit einer bestimmten EPO-Dosis anzeigt, dann bittet der „GUI-Schauspieler“ seinen Geschäftslogik-Kollegen, genau diese Daten zu besorgen und dazu im UML-Diagramm zu erklären, welche Methodenkaskade genau diese Daten berechnet und zurückliefert.

Sie gehen dieses Spiel nicht nur für alle Nutzungsobjekte, sondern auch für alle Werkzeuge durch. Die GUI-Vertreter bittet z.B. den Geschäftslogik-Vertreter zu beschreiben, wie die Architektur auf das Klicken des Speichern-Buttons reagiert. Bei einem Ultra-Thin-Client müsste es für jedes Nutzungsobjekt und jedes Werkzeug eine Methode im Backend geben.

Das Ziel der Person, die die Rolle der GUI vertritt, besteht darin, der Architektur nachzuweisen, dass sie nicht in der Lage ist, alle notwendigen Daten zu besorgen oder abzuspeichern. Nach einer Weile – das wäre mein Tipp – sollten die beiden „Schauspieler“ die Rolle wechseln. Glauben Sie mir, intensiver lässt sich eine Architektur kaum prüfen. Das bedingt natürlich, dass Sie Ihre Architektur modelliert haben.

Schlechte Software-Architektur: Ein Problem im Audit?

Die Vertreter der meisten benannten Stellen haben mich am Institut besucht, um über die gesetzeskonforme Software-Entwicklung zu sprechen. Das gab mir die Gelegenheit zu fragen, wie sie mit schlechten Software-Architekturen umgehen würden.

Die Antworten waren eindeutig, für mich aber überraschend: Die Auditoren würden bei einer schlechten Software-Architektur kein „Finding“ notieren. Eine schlecht dokumentierte Software-Architektur (unabhängig davon ob die Architektur selbst gut oder schlecht ist) könnte hingegen zu einem Problem in Audit führen.

Diese Denkweise kann ich einerseits nachvollziehen, weil es kein Gesetz und keine Norm gibt (z.B. IEC 62304), das eine gute Software-Architektur vorschreibt. Andererseits kann eine schlechte Software-Architektur zum Problem werden, wenn sie beispielsweise dafür verantwortlich ist, dass Risiken damit nicht beherrscht oder dadurch sogar verursacht werden.

Güte der Dokumentation

Eine gute Dokumentation der Software-Architektur ist eine Voraussetzung dafür, um die Güte dieser Architektur überhaupt beurteilen zu können. Lesen Sie hier mehr zur Software-Architektur Dokumentation.

Für den Auditgarant habe ich mehrere Videotrainings erstellt, in denen ich Schritt für Schritt erkläre, wie man nicht nur eine gute Dokumentation verfasst, sondern auch eine gute Architektur erstellt.

Als Richtschnur, für eine „gute“ Dokmentation von Software-Architekturen können Sie die ISO/IEC 42010 (guter Wikipedia-Artikel) oder das Template von arc42 nutzen.

 Güte der Architektur

Hier stellt sich die Frage nach den Kriterien und dem Bewertungsmaßstab für die Güte der Architektur. Die Architektur wird im Wesentlichen durch die „nicht-funktionalen“ Anforderungen getrieben. D.h. Sie sollten prüfen, ob hinreichend viele  – für die Architektur relevante – Qualitätsanforderungen definiert sind. Da hapert es bei den meisten Software-/System-Anforderungen. Und muss man eine Methode festlegen, mit dem man die „Angemessenheit“ der Architektur für diese Qualitätsanforderungen überprüft. Z.B. ATAM oder SAAM. Da stoßen wir auf das nächste Problem: Das kennst geschweige denn beherrschen nur wenige.

Mit den Videotrainings des Auditgarants, lernen Sie Schritt für Schritt, eine „gute“ und normenkonforme Architektur zu dokumentieren.

Benötigen Sie noch Hilfe beim Modellieren oder Prüfen („Reviewen“) Ihrer Architektur? Dann melden Sie sich doch bei mir, ich helfe gerne.

Lehrmaterialien und Checklisten

Videotrainings zur Software-Architektur

Wenn es um die Dokumentation der Software-Architektur für Medizinprodukte geht, treffe ich auf zwei verschiedene Typen an Menschen:

  • Die Software-Entwickler, die regelmäßig Probleme damit haben, weil sie den Sinn nicht immer einsehen und nicht wissen, was man dokumentieren muss, um den Forderungen der Gesetze (auch FDA) und Normen gerecht zu werden.
  • Die Regulatory-Affairs-Manager, die zwar die Gesetze und Normen kennen, aber nicht genau wissen, wie man die Forderungen in der Praxis ohne großen Overhead erfüllen kann.

Deshalb enthält der Auditgarant mehrere Videotrainings zum normenkonformen Entwickeln und Dokumentieren von Software-Architekturen.

Softwarearchitektur: Einführung

Sie lernen in diesen Trainings:

  • Weshalb Sie eine Architektur erstellen und dokumentieren sollten
  • Was die Merkmale einer guten Architektur sind
  • Welche regulatorische Anforderungen Sie erfüllen müssen
  • Wie Sie Ihre Architektur dokumentieren können
  • Wie man eine Architektur prüft/reviewed/verifiziert

Mit diesem Wissen, sehen Sie im nächsten Audit gut aus!

Checklisten zur Dokumentation von Software-Architekturen

Ergänzend empfehlen wir Ihnen den Auditleitfaden, die komplette Checkliste für alle Entwicklungsphasen, auch für die Dokumentation der Software-Architektur. Diesen Auditleitfaden haben wir für benannte Stellen entwickelt, die damit Software-Audits durchführen. Sie ersparen sich damit tagelanges Studieren der Normen und können Ihre „Auditfähigkeit“ selbst prüfen.

Software-Auditleitfaden

Persönliche Unterstützung

Falls Sie Ihre Software-Architektur bereits dokumentiert haben, helfen wir Ihnen gerne mit einem Review. Wir können Ihnen ebenso schnell wie preisgünstig wertvolles Feedback geben.

Nehmen Sie gleich Kontakt mit uns auf!
Die Bauarchitektur und die Softwarearchitektur haben viele Gemeinsamkeiten, aber auch einige fundamentale Unterschiede. Dieser Beitrag zeigt Ihnen, wo Sie als Medizinproduktehersteller die Metapher der Bauarchitektur nicht über Gebühr strapazieren sollten.

Software-Architektur versus Bauarchitektur

Das normale Vorgehen

Stellen Sie sich vor, Sie wollen ein Haus bauen – Ihr neues Haus. Wie würden Sie vorgehen?

Wahrscheinlich würden Sie sich überlegen, was Sie in und mit dem Haus machen wollen. Beispielsweise darin die Schwiegermutter beherbergen. Oder das vielleicht gerade nicht. Oder Sie benötigen einen Raum, in dem Sie Ihre Modellflugzeuge bauen und aufbewahren.

Anschließend werden Sie mit Ihren Wünschen zum Bauarchitekten gehen und sich einen Plan entwerfen lassen. Einen Plan, den Sie wahrscheinlich noch ein oder zweimal revidieren. Erst dann bestellt der Bauunternehmer die Maurer, die das Haus gemäß dieses Plans, der Bauarchitektur, hochziehen.

Sie stimmen mir sicher zu, dass dies das absolut normale Vorgehen beim Hausbau ist.

Bauarchitektur: Ein Vorbild für die Softwarearchitektur? (istockphoto)

Bauarchitektur á la Software

Wie würden Sie folgende Variante einschätzen? Zuerst bestellt man die Maurer. Denn die haben ja gerade Zeit und wollen beschäftigt sein. Während diese mit dem Mauern beginnen, überlegt sich der Architekt noch schnell den Bauplan, die Bauarchitektur. Was Sie vom Haus wünschen, wird er schon richtig erahnen.

Das halten Sie für schwachsinnig? Zugegeben, ich auch. Aber genauso wird Software oft entwickelt:

Die teuren Programmierer müssen beschäftigt sein. Man kann sie ja nicht sinnlos ohne Arbeit rumsitzen lassen, bis man endlich weiß, was man will, und dann die Softwarearchitektur entworfen hat.

Und so wird programmiert. Die Änderungen, die sich dann im Lauf der Zeit zwangsläufig ergeben, werden während der Programmierung (des Mauerns) umgesetzt. Das nennt man dann vornehm Refactoring.

Und wenn man, wie das fast immer der Fall ist, feststellt, dass der Kunde doch etwas anderes wünscht (die wissen ja nie, was sie wollen), dann ändert man eben die Anforderungen, danach die Architektur (so man überhaupt eine erstellt) und danach die bereits entwickelte Software. Meistens muss man diesen Zyklus mehrfach durchlaufen, bis die Anforderungen des Kunden erfüllt sind (oder dieser entnervt aufgibt). Das nennt man dann agile Entwicklung.

Bin ich jetzt zu zynisch? Vielleicht ein wenig. Aber von den Jungs am Bau können wir noch verdammt viel lernen.

Unterschied von Bauarchitektur und Softwarearchitektur

Zumindest einen Unterschied zwischen Bauarchitektur und Softwarearchitektur sollten Sie aber bedenken: Die Bauarchitekten ermitteln die Anforderungen und erstellen den Bauplan. Die Softwarearchitekten sollten nur den Bauplan (die Softwarearchitektur) erstellen. Die Anforderungen zu erheben, ist Aufgabe des Requirements Engineers.

Bauarchitektur versus Software-Architektur


Mittwoch 6. September 2017 von Prof. Dr. Christian Johner

Die MedConf ist die jährlich (meist im Oktober) in München stattfindende Konferenz zur normenkonformen Entwicklung von medizinischer Software, sei es als standalone Software oder als embedded Software. Seit 2017 gibt es auch eine MedConf Nord.

Zu den Teilnehmern zählen Mitarbeiter von Medizinprodukteherstellern (Entwicklung, Regulatory Affairs, Qualitätssicherung, Produktmanagement) ebenso wie Beratungsunternehmen, Entwicklungsdienstleister und benannte Stellen. Das Johner Institut ist auf der MedConf als Themensponsor vertreten und gibt praxisnahe Tipps zur normenkonformen Entwicklung.

Johner auf Medconf 2016

MedConf 2017

Downloads (befristet bis 22.10.!)

Leser des Instituts-Journals können sich die Keynote und Mindmaps herunterladen. Registrieren Sie sich hier.

Bereits zum 10. Mal..

Die „klassische“ MedConf in München feiert im Oktober den 10. Geburtstag. Es ist bereits die 10. MedConf, an der das Johner Institut teilnimmt – wie immer als Aussteller und mit Christian Johner als Keynote-Sprecher.

Sofort Rabatt sichern

Eine weitere Tradition haben wir für Sie, die Leser dieses Blogs, beibehalten: Sie profitieren von einem 15%-igen Rabatt! Bitte geben Sie dazu bei der Anmeldung den Code MC17_JI_15% ein. Sie herhalten dann 15% Rabatt auf die Konferenz- und Workshop-Tickets. Ist das ein Angebot? Wir finden schon und hoffen und freuen uns auf ein Treffen in München.

Eigentlich hat die „Rabattphase“ am 31.08.2017 geendet. Weil der Blog aber erst im September wieder startet, wollte das Konferenzteam großzügig sein. Aber zögern Sie nicht zu lange und melden Sie sich gleich hier zur MedConf an!

Die Konferenz findet vom 16. bis zum 20. Oktober 2017 statt.

 

Den ganzen Beitrag lesen »


Dienstag 26. Juli 2016 von Prof. Dr. Christian Johner

Ein „detailliertes Design“ fordern sowohl die IEC 62304 als auch die FDA, jedoch ohne diesen Begriff präzise zu definieren. Lesen Sie hier, wie Sie die regulatorischen Anforderungen schnell und „auditsicher“ erfüllen können.

Inhaltsübersicht

Den ganzen Beitrag lesen »


Mittwoch 23. März 2016 von Prof. Dr. Christian Johner

Der TIR45 („Guidance on the use of AGILE practices in the development of medical device software“) ist ein Technical Information Report (daher TIR) der AAMI, der Association for the Advancement of Medical Instrumentation.

Der 2012 veröffentlichte TIR45 hat sich vor allem ein Ziel gesetzt: Medizinprodukte-Herstellern eine Anleitung zu geben, wie sie Software agil und konform mit den FDA-Forderungen, speziell denen in den Guidance Documents, entwickeln können. Auch die IEC 62304 hat der Technical Report im Fokus.

Lesen Sie hier eine kompakte Zusammenfassung.

Den ganzen Beitrag lesen »


Montag 7. März 2016 von Prof. Dr. Christian Johner

„Findet ein Software-Audit statt?“ lautet eine Frage, die mich über unser Micro-Consulting erreicht. „Und kann ich durch eine geeignete Wahl der Software-Sicherheitsklasse so ein Software-Audit vermeiden?“

Erst ist mir weder klar, was genau mit „Software-Audit“ gemeint, noch was die genaue Befürchtung ist. Doch dann verstehe ich und finde die Frage sehr bedeutsam für alle Medizinprodukte-Hersteller.

Den ganzen Beitrag lesen »


Montag 8. Februar 2016 von Prof. Dr. Christian Johner

Eine Schichtenarchitektur ist ein Architekturstil, der häufig bei Software-Systemen Anwendung findet. Vielen Herstellern sind die Nachteile eine mehrschichtigen Architektur und eines Denkens in Layern nicht bewusst.
Den ganzen Beitrag lesen »


Mittwoch 19. August 2015 von Prof. Dr. Christian Johner

Software-Systeme sollten aus Komponenten bestehen, die über Software-Schnittstellen miteinander kommunizieren. Dieser Artikel beschreibt, wie Sie Software-Schnittstellen IEC 62304 konform dokumentieren können. Dabei zeigt er Konzepte, die sich nicht nur auf interne und externe Software-Schnittstellen, sondern auch auf Hardware-Schnittstellen übertragen lassen.

Update: Internet als interne Schnittstelle?

Den ganzen Beitrag lesen »


Freitag 10. Juli 2015 von Prof. Dr. Christian Johner

Die Software-Architektur Dokumentation dient vor allem diesen Zielen:

  • Eine schnelle und effektive Entwicklung ermöglichen
  • Das Entwicklungsprojekt —Zeiten, Ressourcenpräzise planen
  • Die regulatorischen Anforderungen an die Software-Architektur erfüllen
  • Die Weiterentwicklung des Systems und die Einarbeitung neuer Mitarbeiter erleichtern

Den ganzen Beitrag lesen »


Dienstag 7. Juli 2015 von Prof. Dr. Christian Johner

Die UML, die Unified Modeling Language, ist eine standardisierte Sprache, mit der sich Software, aber auch ganze Systeme beschreiben lassen. Durch die wenigen aber genau definierten Notationselemente der UML sind Hersteller befähigt, Sachverhalten eindeutig und präzise zu beschreiben und so Anforderungen z.B. der IEC 60601-1 und IEC 62304 zu erfüllen.

Den ganzen Beitrag lesen »


Freitag 5. Juni 2015 von Prof. Dr. Christian Johner

Auf die Frage, was ein Design Review sei, bekommt man häufig unterschiedliche Antworten — abhängig davon, ob man einen Entwickler oder einen Qualitätsmanager fragt. Genau diese unterschiedlichen Sichten können im Audit zum Problem werden.

Den ganzen Beitrag lesen »


Freitag 15. Mai 2015 von Prof. Dr. Christian Johner

Scrum ist eher ein Rahmen (Framework) für das agile Projektmanagement als ein Vorgehensmodell im Sinne eines Prozessmodells. Bereits deshalb kann ein Vorgehen nach Scrum durchaus konform mit den regulatorischen Anforderungen an die Entwicklung von Medizinprodukten (insbesondere Software) und der IEC 62304 sein.

Dieser Beitrag hat nicht zum Ziel, Scrum zu beschreiben (das ist an anderer Stelle z.B. Wikipedia bereits erfolgt). Vielmehr möchte er diskutieren, welche Voraussetzungen erfüllt sein müssen und typische Gefahren vermieden werden sollten.

Den ganzen Beitrag lesen »