Code-Reviews in der Medizintechnik

Goran Madzar

12/04/2015

Code-Review oder kein Code-Review? Das ist hier die Frage. Um Software-Qualität sicherzustellen, gibt es verschiedene Ansatzpunkte. Statische Codeanalyse, automatisierte Unittests, Integrationstests, Smoke Tests und viele viele mehr. Die aufgezählten Punkte sind in der heutigen Software-Entwicklung Stand der Technik und nicht aus der täglichen Arbeit wegzudenken. Beim Code-Review ist die Medizintechnik-Szene jedoch gespalten. Kaum eine andere Testmethode ist so umstritten.  Dabei wird der Methode Code-Review oft unrecht getan.

“Talk is cheap, show me the code.”

Linus Torvalds

Was sagt die IEC62304 dazu?

Die IEC62304 (Medizingeräte-Software – Software-Lebenszyklus-Prozesse) fordert kein Code-Review. Vielmehr muss für die Software eine Sicherheitsklassifizierung erfolgen. Auf Basis der Sicherheitsklassifizierung kann man dann festlegen, welche Testmethoden angewendet werden sollen. Dabei ist es zulässig, durch Architektur-Entscheidungen Software-Komponenten zu segregieren und damit sicherheitskritische von nicht sicherheitskritischen Teilen zu trennen. Das führt zur Reduktion von Aufwand und ist durchaus berechtigt. Es führt häufig dazu, dass man Code-Review als absolute „Topmethode“ auf Software der Sicherheitsklasse C beschränkt und andere Module der Klassen A und B unberücksichtigt lässt. Schließlich muss man ja bei A und B weniger machen als bei C. Hier ist die Frage, ob diese Entscheidung sinnvoll ist. Denn auch wenn Software nicht imstande ist jemanden zu töten oder zu verletzen, so kann ein Fehlverhalten trotzdem unangenehme Folgen haben.

Was bringen Code-Reviews?

  • Fehler werden frühzeitig in der Entwicklung gefunden (in der Programmierphase).
  • Nicht verstandene Anforderungen an das Produkt werden erkannt.
  • Entwickler räumen Code auf, der zum Review soll.
  • Externe Experten sehen Dinge, die der Entwickler nicht mehr sieht.
  • Fehler im Systemtest führen zu einem sehr hohen Aufwand. Fehler finden, Fehler lokalisieren, Änderung durchführen, erneute Tests durch Änderung (z.B. Systemtests müssen wiederholt werden).
  • Systemtests sind nicht vollständig. Es ist nicht möglich alle Fälle zu testen. Daher ist es besser, die Fehlerfälle durch ein Code-Review zu finden.
  • Ein dokumentiertes Code-Review gibt dem Entwickler ein gutes Gefühl und sorgt dafür, dass Fortschritt sichtbar ist (Spezifikation, Implementierung, Review, Test, Fertig, nächstes Modul)
  • Das Wissen im Unternehmen wird größer. Die Entwickler werden besser und lernen voneinander.
  • Die Wartbarkeit von Code ist besser, wenn mehr als eine Person den Code verstanden hat. Es ist auch leichter möglich für andere sich einzuarbeiten.
  • Es entsteht ein firmenweiter Standard auf hohem Niveau.

Was spricht gegen ein Review?

  • Es gibt keine Zeit mehr im Projekt. Reviews werden zu spät im Projekt eingeplant. Die Software soll eigentlich schon fertig sein und jetzt soll es noch Reviews mit 100-200 Stunden Aufwand geben. Das will keiner mehr ausgeben.
  • Manche Module oder Komponenten (z.B. Linux) sind viel zu groß und es wäre unwirtschaftlich diese zu reviewen. Das ist in der Tat ein gutes Argument gegen das Review. Im Gegenzug muss klar sein, dass sich dadurch Aufwand an anderer Stelle ergibt. Es müssen also Tests durchgeführt werden. Bei SOUP/OTS (source of unknown provenance / off the shelf software) ist auch das Risikomanagement gefragt.
  • Es handelt sich nur um Klasse A oder B Software. Von diesem Argument rate ich dringend ab! Es ist sehr schwierig auszuschließen, dass Klasse A Software nicht ebenfalls zu einem Fehlverhalten führen kann. Und es geht ja nicht nur darum niemanden zu verletzen. Das Ziel ist es, effizient ein gutes Produkt entwickeln.

Was sind meine Erfahrungen?

  • Bei mehr als 30 % der Code-Reviews werden kritische Fehler erkannt, die zu einem Fehlverhalten im Feld  führen können.
  • Richtig geplant und eingesetzt entsteht ein Aufwand von ca. 5-8 % der Software-Entwicklung (Erfahrungswerte aus meinen Projekten) für ein vollständiges Code-Review einer Klasse C Software.
  • Gerade junge Entwickler profitieren enorm durch Reviews.
  • Es entsteht eine sehr große Dynamik und damit Spaß an der Arbeit mit Kollegen Arbeitsergebnisse zu diskutieren und zu zeigen, was man drauf hat.
  • Viele sehr gute und erfahrene Entwickler sprechen sich für Reviews aus.
  • Durch Weglassen des Reviews wird kein Aufwand vermieden, sondern nur an anderer Stelle bezahlt. Unter Umständen zu einem höheren Preis.

Was ist sonst noch wichtig?

Entwickler, die noch nicht durch das Fieber Review angesteckt sind, lehnen diese eher ab. Sie sehen es als Prüfungssituation, wodurch Stress produziert wird. „Das soll sich lieber keiner anschauen, ich mache das schon…“ Diese Einstellung ist nicht sinnvoll. Es geht nicht darum jemanden schlecht zu machen oder seine Kompetenzen abzusprechen. Es geht darum ein gutes Produkt zu entwickeln und technologisch sehr gute Arbeit zu leisten. Sobald das klar ist, entsteht ein Flow, der zum Anspruch führt Software auf hohem Niveau zu entwickeln.

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, Mechanik-Entwicklung und Beratung aus einer Hand. Nehmen Sie Kontakt mit uns auf.

Kontakt aufnehmen


Templates für Reviews müssen leicht handhabbar sein. Es ist natürlich nicht klug ein Template zu verwenden, das nicht schlank und einfach zu benutzen ist. Wir wollen nicht Word Experten sein, sondern super Software entwickeln. Am besten verwendet man Tools, um Code Reviews durchzuführen (z.B. Remine, reviewboard). Hiermit können die Reviews in der Versionsverwaltung der Software integriert werden.

Es muss die Freiheit geben, das Vorgehen beim Review anzupassen. Manche brauchen den Source Code vor dem Review als Ausdruck, um sich Notizen zu machen. Andere brauchen unbedingt ihren Editor, weil dieser Begriffe über das ganze Dokument markieren kann. Manche brauchen ihre Ruhe zum Denken. Andere wollen darüber sprechen. Es ist daher nicht sinnvoll eine Vorgehensweise für alle Fälle vorzuschreiben.

Was ist das absolute Minimalziel?

Code-Reviews sollten in den folgenden Fällen auf jeden Fall durchgeführt werden:

  • Klasse C Module
  • Komplexe Module
  • Code von unerfahrenen Entwicklern (<3Jahre Berufserfahrung oder an weniger als 20 Code Reviews teilgenommen) als eine Art Mentoring
  • Code von externen Mitarbeitern
  • Code bei dem die Entwickler ein schlechtes Gefühl haben

Überlegen Sie sich welche Module wie getestet werden. Eventuell sind Module durch Unit-Tests besser testbar als durch Review. Die Teststrategie und die Verifikationsplanung muss frühzeitig festgelegt werden. Die Methoden müssen zielführend sein!

Planung der Code-Reviews

Ich plane die Code-Reviews auf Basis der Software Architektur und der Liste der Software Module. In Tabellenform werden die Software-Module mit Risikoklassifizierung aufgelistet und die Testmethode festgelegt. Die Festlegung wird dabei mit dem Software-Entwickler diskutiert. Die Tabelle unten zeigt den prinzipiellen Aufbau.

Module Risk Class Test Method
Code Review Unit Test Software System Test
FreeRTOS B yes yes
HAL: CMSIS B yes yes
Audio Manager A no yes
Error Manager B yes yes yes
Language Manager A yes no yes
Menu Control B yes yes yes
Parameter Base B yes yes
Module xyz B yes yes yes

Um die Aufwände für die Code-Reviews abzuschätzen, werden zwei Ansätze verwendet. Zum einen schätzt der Entwickler den Aufwand für jedes Modul in der Liste. Bei einem jungen oder unerfahrenen Kollegen sollten erfahrene Kollegen unterstützen. Das ergibt die Bottom-Up Schätzung. Um die Plausibilität und Richtigkeit überprüfen zu können, werden Aufwände eines ähnlichen Projektes gegenübergestellt. Das ist die Top-Down Schätzung. Mit diesen beiden Werten hat man eine gute Basis für eine fundierte Aufwandsabschätzung.

Vorgehensweise bei Code-Reviews

Der Source Code muss vorher aufgeräumt werden, sodass Offensichtliches beseitigt ist. Es ist nicht das Ziel sich auf Kommentare (z.B. Doxygen) oder auf Rechtschreibfehler zu konzentrieren, sondern auf den Code. Es ist auch empfehlenswert die statische Codeanalyse vorher durchzuführen und den Code daraufhin zu prüfen, dass es den Programmierrichtlinien ihrer Organisation entspricht.

Das Ablaufdiagramm zeigt eine mögliche Vorgehensweise.

Vorgehen Code-Review
Vorgehen Code-Review

Fazit

Die Codereviews sind eine gut planbare und frühzeitig mögliche Methode, um Fehler und damit verbundene Aufwände in einer späten Projektphase zu vermeiden. Es wird empfohlen, bei der Abschätzung sowohl Top-Down als auch Bottom-Up vorzugehen. Es ist daher sinnvoll, Aufwände von vergangenen Projekten zur Abschätzung zu benutzen. Es ist auch sinnvoll, die geeignete Testmethode für die Qualifizierung festzulegen. Manchmal ist ein Code-Review günstiger als eine andere Methode, weil man einfach nur lesen muss.

Das Vorgehen funktioniert und bringt eine bessere Codequalität. Nicht nur für die Module, die man sich anschaut, sondern auch in den anderen, weil ein Lerneffekt eintritt und die Fehler nicht in anderen Modulen wiederholt werden. Die Qualität verbessert sich sogar über das Projekt hinaus. Die Code-Reviews sorgen für einheitlichen Code.

Ich freue mich über Feedback und wenn Sie mit mir in Kontakt treten. Sie können gerne auch einen Kommentar zu dem Artikel abgeben. Falls Sie jemanden kennen, für den der Blog ebenfalls interessant sein könnte, freue ich mich auch sehr über eine Weiterempfehlung.

Viele Grüße

Goran Madzar


Geschrieben von Goran Madzar

MEDtech Ingenieur aus Leidenschaft! Mein Team und ich helfen Medizintechnik-Herstellern mit Engineering-Dienstleistungen dabei, Produkte zu entwickeln und in Verkehr zu bringen! Sprechen sie mich gerne an, ob bei LinkedIn oder per Mail. Ich freue mich Sie kennenzulernen.


Weitere Beiträge

  • 12/11/2024
  • Allgemein, Software, Testen, Tools

In sicherheitskritischen Softwareprojekten steht die Qualität der Software an erster Stelle. Besonders bei Klasse-C-Software, die nach strengen Normen wie IEC 62304 (Medizintechnik) zertifiziert werden muss, ist es essenziell, dass ...

Weiterlesen
  • 08/08/2024
  • Allgemein, Elektrostimulation, Software, Testen

Heutzutage sind Apps im Gesundheitsbereich sehr wichtig. Besonders Apps, die Daten von medizinischen Sensoren lesen und verarbeiten können, sind nützlich. Flutter ist ein Open-Source-Framework von Google, das sich hervorragend ...

Weiterlesen
  • 30/06/2024
  • Allgemein, Hardware, Software, Technik, Tools, Usability

KI – Was ist das denn überhaupt? Künstliche Intelligenz ist zurzeit in aller Munde, doch die wenigsten Menschen beschäftigen sich mit der Funktionsweise von künstlicher Intelligenz oder damit, was ...

Weiterlesen
Cookie-Übersicht

Die Internetseiten der MEDtech Ingenieur GmbH verwenden Cookies. Cookies sind Textdateien, welche über einen Internetbrowser auf einem Computersystem abgelegt und gespeichert werden.

Zahlreiche Internetseiten und Server verwenden Cookies. Viele Cookies enthalten eine sogenannte Cookie-ID. Eine Cookie-ID ist eine eindeutige Kennung des Cookies. Sie besteht aus einer Zeichenfolge, durch welche Internetseiten und Server dem konkreten Internetbrowser zugeordnet werden können, in dem das Cookie gespeichert wurde. Dies ermöglicht es den besuchten Internetseiten und Servern, den individuellen Browser der betroffenen Person von anderen Internetbrowsern, die andere Cookies enthalten, zu unterscheiden. Ein bestimmter Internetbrowser kann über die eindeutige Cookie-ID wiedererkannt und identifiziert werden.

Durch den Einsatz von Cookies kann die MEDtech Ingenieur GmbH den Nutzern dieser Internetseite nutzerfreundlichere Services bereitstellen, die ohne die Cookie-Setzung nicht möglich wären.

Mittels eines Cookies können die Informationen und Angebote auf unserer Internetseite im Sinne des Benutzers optimiert werden. Cookies ermöglichen uns, wie bereits erwähnt, die Benutzer unserer Internetseite wiederzuerkennen. Zweck dieser Wiedererkennung ist es, den Nutzern die Verwendung unserer Internetseite zu erleichtern. Der Benutzer einer Internetseite, die Cookies verwendet, muss beispielsweise nicht bei jedem Besuch der Internetseite erneut seine Zugangsdaten eingeben, weil dies von der Internetseite und dem auf dem Computersystem des Benutzers abgelegten Cookie übernommen wird.

Die betroffene Person kann die Setzung von Cookies durch unsere Internetseite jederzeit mittels einer entsprechenden Einstellung des genutzten Internetbrowsers verhindern und damit der Setzung von Cookies dauerhaft widersprechen. Ferner können bereits gesetzte Cookies jederzeit über einen Internetbrowser oder andere Softwareprogramme gelöscht werden. Dies ist in allen gängigen Internetbrowsern möglich. Deaktiviert die betroffene Person die Setzung von Cookies in dem genutzten Internetbrowser, sind unter Umständen nicht alle Funktionen unserer Internetseite vollumfänglich nutzbar.

Weitere Informationen erhalten Sie in unserer Datenschutzerklärung.

Unbedingt notwendige Cookies

Dieses Cookie wird benötigt, um Ihre Cookie-Einstellungen zu merken und weitere Hauptfunktionen zur Verfügung zu stellen

Um Ihnen eine Auskunft über Ihre gespeicherten personenbezogenen Daten hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) geben zu können, benötigen wir einen Cookie, um Sie bei der Datenabfrage identifizieren zu können. Dieser Cookie muss aus Sicherheitsgründen deshalb aktiviert sein. Ein weiterer Cookie wird gesetzt, um diesen Banner nicht erneut anzeigen zu müssen.

Cookie-Name Beschreibung
PHPSESSID Name: PHP session
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wir benötigt, um Sie bei der Anfrage von personenbezogenen Daten identifizieren zu können. Das Cookie wird nur gesetzt, wenn Sie eine Anfrage hier (https://medtech-ingenieur.de/gespeicherte-daten-2/) stellen.
Laufzeit: Sitzungsende
Kategorie: Unbedingt notwendige Cookies
moove_gdpr_popup Name: Cookie-Box Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Wird benötigt, um Ihre Cookie-Einstellungen zu speichern, um den Cookie-Banner nicht erneut anzeigen zu müssen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
comment_author_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_email_9c90e388e3e1be4a6c594fa6ac8a3eec
comment_author_url_9c90e388e3e1be4a6c594fa6ac8a3eec
Name: Kommentar Einstellungen
Anbieter:
Eigentümer der Webseite (MEDtech Ingenieur)
Zweck:
Cookie wird angelegt, wenn Sie ein Kommentar auf MEDtech Ingenieur veröffentlichen wollen, um Sie als Autor identifizieren und den aktuellen Status Ihres Kommentars anzeigen zu können. Das Cookie enthält den angegebenen Namen. Das Cookie wird erst gesetzt, wenn Sie der Speicherung Ihrer personenbezogenen Daten zustimmen.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
rmp-rate Name: RMP Rate
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie eine Bewertung eines Blogbeitrags mithilfe des Sternebewertungssystems abgeben. Ihnen wird eine anonymisierte ID zugewiesen, um zu erkennen, ob Sie einen Artikel bereits bewertet haben oder nicht. Das Cookie wird nur verwendet, um zu verhindern, dass mehrfache Bewertung abgegeben werden und erst gesetzt, wenn Sie auf einen Stern klicken.
Laufzeit: 1 Jahr
Kategorie: Unbedingt notwendige Cookies
medtech-download-page Name: Download Page
Anbieter: Eigentümer der Webseite (MEDtech Ingenieur)
Zweck: Cookie wird angelegt, wenn Sie den Landing-Page Prozess erfolgreich durchlaufen haben. Dies geschieht nur, wenn Sie einen Content-Download von unserer Website anstreben.
Laufzeit: 1/2 Jahr
Kategorie: Unbedingt notwendige Cookies