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