Über 10 Jahre Medizintechnik. Was habe ich hier alles gelernt, welche Empfehlungen kann ich geben? Mit dieser Frage kam Goran Madzar auf mich zu und hat mich gefragt, ob ich nicht Lust hätte einen Gastblog zu schreiben. Gerne war die Antwort, es hat zwar etwas gedauert, aber nun ist der Beitrag da.
Mein Name ist Heiko Schmidt und ich habe über 10 Jahre im Bereich der Medizintechnik gearbeitet. Ich habe als Software-Entwickler begonnen und nach 4 Jahren die Leitung der Software-Entwicklung übernommen. Später kam auch die Leitung der Systemverifizierung hinzu.
Einen kleinen Ausschnitt aus meinen Erfahrungen möchte Ich Ihnen heute hier geben. Gerne bin ich auch bereit diese Punkte oder auch weitere Punkte mit Ihnen zu diskutieren. Melden Sie sich einfach!
Alles ist perfekt
Ich bin in die Medizinbranche gewechselt weil ich dachte hier läuft alles strukturierter und besser. Das erste Fragezeichen hatte ich, als ich mit der Q-Abteilung besprechen wollte was für eine moderne Software-Entwicklung alles zu machen ist und wie man es machen könnte. Auf verschiedene Fragen zu normativen Anforderungen, bekam ich die Antwort: „Und das alles wollen Sie machen? Na dann viel Spaß !“
Von wollen kann nicht immer die Rede sein. Es gibt doch einige Normen und Guidances, welche von einer Software-Entwicklung gewisse Dinge fordern. Und mein Verständnis war, die meisten Dinge, die dort stehen sind sinnvoll und einzuhalten.
Was ich aus solchen Erfahrungen recht schnell gelernt habe ist, dass man meistens keine konkrete Antwort bekommt, wie man etwas machen soll. Daher meine Empfehlung an Sie:
Die Antwort müssen Sie sich selber erarbeiten und praktikabel in die Praxis umsetzen. Schauen Sie sich die relevanten Normen und Guidances an und leiten Sie für sich die Anforderungen und Vorgehensweisen daraus ab.
Erstellen Sie ein einfaches Konzept zur Erfüllung dieser Anforderungen inklusive einem Mapping und stellen Sie dieses Vorgehen Ihrer Q-Abteilung vor. Somit haben Sie eine gute Vorlage geschaffen und Widerspruch ist eher selten, denn Sie sind der Experte und wissen wie Software-Entwicklung funktioniert und was praktikabel ist.
Experten
Ich habe viele Experten in den 10 Jahren kennengelernt. Es gibt viele Experten die können einem erzählen, was in jedem Lehrbuch steht, alles sehr theoretisch und abstrakt. Dieses Wissen habe ich auch und es hilft mir nicht weiter. Wenn die Fragen dann konkreter werden, dann wird es oft dunkel und viele Experten sind weg.
Auch werden häufig Lösungen vorgeschlagen die richtig, aber in der Praxis nicht praktikabel sind. Zur Umsetzung würden Sie hierfür die doppelte Mannschaft an Mitarbeitern benötigen, welche Sie aber nicht erhalten.
Wenn Sie 3 Experten fragen, bekommen Sie mindestens 4 Meinungen. Hieraus sieht man auch, dass Normen und Guidances einen gewissen Abstraktionslevel haben und einem die Freiheit geben Dinge auf unterschiedliche Art und Weise zu interpretieren und zu implementieren.
Es gibt nicht nur den einen richtigen Weg!
Daher meine Empfehlung: Hören Sie sich Experten an, es erweitert sicher den Horizont und oft hört man auch sehr gute Dinge. Genauso stark sollten Sie aber auch Ihre Kompetenz berücksichtigen und auf Ihre Erfahrung vertrauen! Vertrauen Sie Ihrem Können und Ihrem Wissen, was die Best Practices in einer Software-Entwicklung sind.
Legen Sie eine Vorgehensweise fest, von der Sie überzeugt sind, die zu Ihrem Unternehmen passt und praktikabel ist, zeigen Sie Rückgrat und verteidigen Sie Ihre Vorgehensweise gegenüber Auditoren und Kritikern.
Stehen Sie dazu, Sie sind schließlich auch ein Experte auf Ihrem Gebiet.
Architektur / Komponenten / Units / Schnittstellen
Die Zeit ist knapp, die Anforderungen sind noch nicht klar, wir fangen schon mal an zu programmieren. Wer kennt das nicht? Auch ich kenne das und habe es praktiziert! Ich bin voll dabei, es kann nicht alles rein sequenziell laufen. Zu warten, bis die Anforderungen perfekt und unterschrieben vorliegen ist auch nicht realistisch und funktioniert nur in der Theorie. Aber ohne eine Grobarchitektur zu starten, den Systemkontext nicht definiert zu haben und das System in Komponenten zerlegt zu haben, ist es doch extrem schwierig.
Im Nachhinein die Komponenten und Units zu definieren mit künstlichen Abgrenzungen, das geht überhaupt nicht. Sie werden es spätestens dann merken, wenn Sie Ihre Komponenten- und Unittests aufsetzen wollen und feststellen, wie viele Schnittstellen und Abhängigkeiten dort existieren.
Meine Empfehlung daher: Erstellen Sie eine Architektur mit klaren Benennungen, mit klaren Schnittstellen, mit klaren Aussagen wer was entwickelt und was SOUP ist. Investieren Sie genügend Zeit in die Architektur, der Invest lohnt sich! Fangen Sie frühzeitig damit an, identifizieren Sie Ihre Software-Systeme und die darunter liegenden Komponenten und stellen Sie diese grafisch dar. Sie werden merken, nun hat man etwas konkretes, ein Bild, welches als Grundlage für fachliche Diskussionen dient. Sie und Ihre Kollegen reden nun vom Gleichen, Sie diskutieren fachlich und haben nun die Chance die Architektur immer feiner zu detaillieren, da wo es notwendig ist und Widersprüche aufzudecken. Gleichzeitig teilen Sie das Wissen im Team.
Diese Architektur muss kein Buch mit 100 Seiten werden, schon wenige Entwürfe mit kurzen Beschreibungen des Zwecks, der Benennung, der Schnittstellen,… helfen extrem! Fangen Sie an, die Architektur, die Abgrenzung und die eindeutige Benennung ist aus meiner Sicht mit das Wichtigste für alle Beteiligten, nicht nur für neue Kollegen! In diesem Stadium wird festgelegt, ob Sie das Spiel gewinnen werden!
Vergessen Sie nicht, wichtige Entscheidungen zu dokumentieren. Es dauert kein halbes Jahr und Sie werden gefragt warum Sie sich so und nicht anders entschieden haben. Nehmen Sie die Entscheidungen in Ihrer Architekturdokumentation auf. Schauen Sie auf www.arc42.de vorbei, dort gibt es sehr gute Vorlagen, welche sie für sich anpassen können. Beschaffen Sie sich auch das passende Buch dazu (z.B. arc42 in Aktion).
Ein wenig Werbung am Rande: Holen Sie sich auch einen moderierenden Experten dazu, der eine Sicht von außen auf Ihr Projekt hat und deutlich besser die richtigen Fragen stellen kann, z.B. Herrn Madzar!
Units und deren Anzahl bzw. Definition
Das Thema Units hat mich lange verfolgt und viele Diskussionen verursacht. Was ist eine Unit, ist eine Unit ein Modul, wie werden Units spezifiziert, ist eine Funktion eine Unit, ist eine C-Datei eine Unit, usw….
Dieses Thema können Sie endlos diskutieren und recherchieren und Sie werden nirgends die eine richtige Antwort finden. Die 62304 sagt dazu: Eine Software Einheit ist eine Software Komponente, die nicht in weitere Komponenten unterteilt ist (nicht kann)!
Sie legen also fest, was für Sie eine Software-Einheit ist, sonst niemand!
Was habe ich daraus gelernt und was sind meine Empfehlungen: Legen Sie zu Beginn Ihres Projektes klar fest, was für Sie Units sind. Machen Sie die Units in Ihrer SW-Architektur eindeutig sichtbar, so haben Sie einen schnellen Überblick wieviel Units Sie haben und Sie können leicht prüfen, ob alle Units spezifiziert, implementiert und verifiziert wurden. Werden Sie nicht zu feingranular. Definieren Sie jede C-Datei als Unit haben Sie sehr schnell mehrere Hundert bis Tausend Software-Units. Wollen Sie für diese Anzahl von Units anschließend Unit Tests implementieren, werden Sie es vermutlich aus Aufwandsgründen nicht schaffen.
Haben Sie Ihre Units identifiziert so machen Sie für jede Unit das Folgende:
- Benennen Sie Ihre Units eindeutig und sinnvoll
- Legen Sie den Zweck der Unit fest,
- Spezifizieren Sie Ihre Units, was sind die Eingänge, was sind die Ausgänge und wie ist das Verhalten der Ausgänge zu den Eingängen.
Die Schnittstellen der Units sollten klare Namen, Einheiten und Gültigkeitsbereiche haben. Vergessen Sie nicht, das Verhalten im Fehlerfall zu definieren! Habe Sie das alles gemacht, so sind sehr gute Voraussetzungen gegeben um einen passenden Unittest zu schreiben.
Namensgebung und Ablage
Was ich bisher in meiner gesamten beruflichen Praxis immer wieder gesehen habe ist das Thema, wie Dinge benannt und abgelegt werden. Jeder Mensch tickt ein wenig anders, was gut und richtig ist. Jeder benennt Dinge anders und hat eine andere Struktur im Kopf. Hier beginnt das Problem. Man redet aneinander vorbei und man sucht im Laufe der Zeit Dinge und verliert den Überblick. Es fängt damit an, wie ein Projekt heißt und was der konkrete Inhalt des Projektes ist und was nicht dazugehört. Legen Sie es schriftlich fest und akzeptieren Sie nichts anderes!
Sollte sich der Fokus oder der Inhalt ändern, kein Problem, dann passen Sie es eben an, aber schriftlich! Wie heißen Ihre Software-Systeme, wie heißen die Software-Komponenten und die Software-Units? Legen Sie in der Architektur Namen fest, für jedes Software-System, für jede Software-Komponente, für jede Software-Unit.
Vergessen Sie nicht die Schnittstellen, benennen Sie sie ebenfalls eindeutig! Nachdem alles einen Namen bekommen hat, ist der nächste Schritt: Nutzen Sie die Namen und nutzen Sie nur die festgelegten Namen, nichts anderes!
Es ist eine Katastrophe wenn Sie im Audit sitzen und erklären müssen, warum die Komponente mit dem Namen A der Komponente mit dem Namen B entspricht, oder der Testreport mit dem Namen X die Verifizierung der Unit Y darstellt.
Benennen Sie Ihre Spezifikationen, Testspezifikationen, Ergebnisse, Unit Tests, Code Reviews usw. mit dem Namen des entsprechenden Software-Systems, der entsprechenden Komponente oder Unit.
Das folgende Bild zeigt ein Beispiel: Über die Architektur wurde eine Unit LedController identifiziert. Alle notwendige Dokumentation hat in der Namensgebung diese Identifikation. Sie haben somit eine schnelle Zuordnung und können eventuelle Lücken sehr schnell erkennen.
Definieren Sie eine Verzeichnisstruktur, wo was abgelegt wird. Es gibt auch hier nicht den goldenen Weg, wichtig ist, dass Sie eine eindeutige Definition haben, diese Definition von allen eingehalten wird und wenn Sie mehrere Projekte haben, es in allen Projekten gleich gemacht wird.
Sie werden sehr schnell merken, wie Sie Sachen selber wiederfinden und nicht immer die Kollegen fragen müssen. Auch neue Kollegen werden hoch erfreut sein, Sie müssen einmal das System erklärt bekommen und können dann recht schnell selbstständig laufen! Seien Sie bei diesem Thema konsequent und drängen Sie die Kollegen dazu, dies einzuhalten!
Wichtig ist, definieren Sie es zu Beginn eines Projektes. Nachträglich haben Sie keine Chance mehr, das Durcheinander der Benennung und der Ablage zu korrigieren!!!
Tracking und Traceability
Dieses Thema ist nicht zu unterschätzen und ohne entsprechendes Tooling fast nicht effizient möglich. Vergessen Sie Excel Listen und andere ungeeignete Werkzeuge für diese Aufgabe. Beschaffen Sie sich ein System, welches Sie dabei unterstützt. Glauben Sie aber nicht, dass das Werkzeug Ihnen alles abnimmt und alle Ihre Probleme für Sie löst!
Ich wurde oft mit Fragen konfrontiert, die eigentlich sehr einfach klingen, aber nicht immer einfach zu beantworten sind. Hier einige Beispiele:
- Wurden alle Anforderungen verifiziert und wo sind die Testergebnisse?
- Wo findet sich die Anforderung in der Architektur wieder?
- In welcher Unit wurde die Anforderung umgesetzt?
- Wo im Quellcode ist die Anforderung implementiert?
- Es gibt ein Fehlerticket mit Nummer 1234, wurde es behoben, in welchem Release, wo im Quellcode?
- ….
Alles aus meiner Sicht einfache, berechtigte Fragen. Können Sie Sie beantworten?
Machen Sie sich zu Beginn des Projektes Gedanken über die notwendigen Werkzeuge und wie diese zusammenarbeiten, um die manuellen Tätigkeiten und damit die Fehlerquellen gering zu halten.
Tooling
In der Medizinbranche ist es zum Teil sehr schwierig und aufwendig moderne Werkzeuge an den Start zu bringen und konsequent einzusetzen. Es werden immer wieder Argumente angeführt, dass die Tools nicht zuverlässig sind, Sie erst validiert werden müssen usw…. Also bleibt man oft bei Word und Excel.
Word und Excel haben natürlich Ihre Berechtigung, keine Frage. Wenn Ihr System sehr einfach ist und es nur 20 Anforderungen hat, ja, dann belassen Sie es bei diesen Werkzeugen. Ansonsten kann ich nur empfehlen, nutzen Sie die passenden Werkzeuge und missbrauchen Sie Excel nicht als Datenbank!
Ja, die Tools müssen zuverlässig funktionieren. Ja man muss sich vorher Gedanken machen, was man mit den Tools eigentlich erreichen möchte. Die meisten Tools sind deutlich zuverlässiger und effizienter als jedes Word und Excel.
Daher meine Empfehlung: Denken Sie rechtzeitig über Ihre Toolchain nach, was Sie benötigen, nicht zu viel und nicht zu wenig. Dokumentieren Sie Ihre Toolchain und zeigen Sie auf, in welcher Phase der Entwicklung was genutzt wird. Wenn Sie wissen was Sie benötigen, dann beschaffen Sie sich die Werkzeuge. Validieren Sie die Werkzeuge mit dem richtigen Augenmaß und setzen Sie sie ein.
Passen Sie den Aufwand der Validierung an den Einsatz des Werkzeuges an. Meistens sind Werkzeuge die zu Beginn einer Entwicklung eingesetzt werden unkritischer als Werkzeuge die am Ende der Entwicklung (z.B. bei der Verifizierung) eingesetzt werden. Nur so werden sie effizient und reproduzierbar arbeiten.
Projektmanagement
Wissen Sie wo Sie im Projekt stehen? Können Sie auf einer Folie sagen wo Sie stehen, was die Themen sind und was als Nächstes folgt?
Ich habe oft die Erfahrung gemacht, dass unser Management berechtigterweise wissen wollte, wie der Stand ist, welche Projektrisiken vorhanden sind und was die Top Themen sind. In diesem Moment ging dann die große Suche los, man musste viele Kollegen Fragen wie der Status ist und schnell eine Folie zusammenbauen, die jedes Mal anders aussah. Es kamen oft weiche Aussagen heraus die zu einem sehr verschwommenen Bild bezüglich dem Status geführt haben. Unser Management hat daraus den passenden Eindruck bekommen!
Seit wir das Projekt in Arbeitspakete zerlegt haben wurde auf einmal deutlich besser sichtbar wo wir stehen. Es konnte klar gesagt werden dass z.B. 40% der Arbeitspakete erledigt sind. Es gab für jedes Arbeitspaket eine Person die verantwortlich war und das erwartete Ergebnis des Arbeitspaketes (Definition of done) war auch definiert.
Aus diesen Arbeitspaketen kann man sehr gute BurnDown Charts generieren, die für eine Managementfolie ideal sind und einen schnellen Eindruck geben, ob wir im Zeitplan und bei den Aktivitäten liegen.
Daher meine klaren Empfehlungen:
- Strukturieren Sie Ihr Projekt in klare Arbeitspakete mit klaren Aufgaben, legen Sie Verantwortliche dafür fest und definieren Sie was das Ergebnis sein soll.
- Erstellen Sie sich ein einfaches Cockpit, welches mit wenig Aufwand aktualisiert werden kann.
Die nächste Anfrage des Managements können Sie dann entspannt entgegenschauen! Sie werden glänzen und Kompetenz ausstrahlen, dass Sie das Projekt im Griff haben und nicht das Projekt Sie!
Meine Lieblingswerkzeuge
Hier nun einige Werkzeuge, die ich in meinen 10 Jahren kennen und lieben gelernt habe.
Bugzilla
Das war unser erstes Werkzeug, neben Excel! Es war damals die beste Entscheidung so etwas aufzusetzen!!! Ich habe viel über Namen, Eindeutigkeit und Traceability geredet und wie wichtig das ist. Das Gleiche gilt für gefundene Fehler oder gewünschte Änderungen, jeder benennt ein Problem, oder eine Änderung anders.
Das Werkzeug Bugzilla vergibt für jeden Eintrag eine eindeutige Nummer. Das hat den riesen Vorteil, dass es keine Diskussionen mehr gibt, von was man eigentlich redet. Alle reden von einer Bugnummer und die ist eindeutig, Sie können einfach den Status tracken und Abfragen generieren. Für mich war und ist es ein super Werkzeug!
Bei uns wurden alle Codeänderungen nur mit Bugnummer eingecheckt, was eine sehr gute Traceability geliefert hat. Selbst nach Jahren kamen Kollegen aus anderen Abteilungen zu mir und haben gefragt, ob und wann ein Bug behoben oder eine Änderung implementiert wurde. Nichts einfacher als das. Ich suche im Bugzilla nach der Bugnummer oder der Beschreibung und konnte somit sehr schnell, über die Versionsverwaltung, bis auf die Zeile Code runter sagen, was wann gemacht wurde und in welches Release die Änderung eingegangen ist.
Unsere Devise war immer: Keine Codeänderung ohne Bugeintrag!
Übrigens: Bugzilla ist nur ein Beispiel. Mit Jira oder ähnlichen Werkzeugen (nicht Excel!), bekommen Sie den gleichen Effekt!
Doxygen
Die Dokumentation muss zum Quellcode passen, den Satz kennen vermutlich sehr viele. Wie schnell die Dokumentation und der Quellcode nicht mehr zusammenpassen, ist uns allen bekannt. Schnell mal eine Änderung machen, dokumentiert wird dies später! Und schon ist es passiert!
Sehr hilfreich ist es hier ein Werkzeug wie Doxygen einzusetzen und im Quellcode entsprechend zu dokumentieren. Mit diesem Werkzeug können Sie Ihre Schnittstellen klar spezifizieren, die Eingangsbereiche festlegen und die Rückgabewerte definieren. So schnell haben Sie Ihre Units dokumentiert!
Damit dies auch konsequent gemacht wird, helfen File-Templates, welche für alle Projekte einzusetzen sind. Hier wird bereits die Struktur jeder Datei vorgegeben, was wieder zu einer einheitlichen Dokumentation über mehrere Projekte führt. Verankern Sie das Ganze noch in Ihren Kodierrichtlinien und Sie werden sehen, der Aufwand wird beherrschbar.
Jenkins
Was bringt Ihnen die Dokumentation mit Hilfe von Doxygen, wenn Sie nicht aktuell ist?
Alles was man regelmäßig machen muss, aber manuell gestartet wird, hat die Chance, dass es irgendwann vergessen wird. Setzen Sie sich einen Jenkins Build Server auf. Dieses System kann automatisch in regelmäßigen Abständen Dinge für Sie erledigen. Fangen Sie klein an! Lassen Sie Jenkins jeden Tag den aktuellen Quellcode auschecken. Lassen Sie sich die Doxygen Dokumentation generieren und Übersetzen Sie Ihr Projekt. Somit erkennen Sie sehr schnell, ob ein Übersetzung fähiger Stand Ihrer Software in der Versionsverwaltung ist und ob die Dokumentation vollständig ist.
Das Ganze kann man dann beliebig weiter ausbauen. Erweitern Sie im nächsten Schritt das System um eine statische Codeanalyse. Anschließend führen Sie dynamische Smoke Tests durch, angestoßen von Jenkins, jeden Tag!
Sie sehen schon die Vorteile: Sie sehen jeden Tag, sofort, ob Sie ein stabiles System haben, oder ob etwas geändert wurde, was unbewusst zu negativen Seiteneffekten geführt hat. Haben Sie so ein System erst einmal aufgesetzt, so profitieren Sie jeden Tag davon und das ganz automatisch! Daher meine klare Empfehlung: Nutzen Sie solche automatisierten Systeme für immer wiederkehrende Aufgaben, starten sie klein und erweitern Sie iterativ nach Bedarf! Melden Sie sich, wenn Sie über die Optimierung Ihrer Testumgebung mehr wissen wollen!
Fazit
Alle genannten Punkte sind aus meinen persönlichen Erfahrungen entstanden. Viele Punkte haben auch nichts mit der Medizintechnik zu tun, sondern sind einfach Best Practices!
Ich hoffe ich konnte Ihnen einige Eindrücke geben und Sie auch dazu inspirieren über manche Dinge nachzudenken. Falls Sie konkrete Fragen zu einzelnen Themen haben oder meine Meinung hören wollen, dann lassen Sie es mich wissen.
Ihr Heiko Schmidt
