Wenn Software auf Qualität (s-Metriken) trifft – Teil 1

Björn Schmitz

01/15/2019

Ein Überblick gängiger Metriken zur Softwareverifikation, aus Sicht eines Entwicklers

Lässt sich Qualität von Software messen?

Vor allem in sicherheitskritischen Bereichen wie der Medizintechnik oder Automotive ist die Qualität von Software entscheidend. Vor allem dann, wenn Fehler in der Software zur Schädigung von Menschen führen kann, werden Entwicklungsprozesse benötigt, um Fehler beim Schreiben von Software zu verhindern und bereits gemachte Fehler aufzudecken. Da versteht sich der Wunsch von selbst, die Qualität von Software messen zu können. Aus diesem Grund werden Softwaremetriken eingesetzt. Nicht nur um Softwareteile mit geringer Qualität zu identifizieren, sondern auch um die Qualität der Software zu dokumentieren. Aber lassen sich die Qualität von komplexen Softwaresystemen wirklich mit wenigen Zahlen ausdrücken? Und bei welchem Wert muss, welche Metrik liegen um wirklich „gut“ zu sein? In diesem Beitrag werden wir uns mit einigen der gängigsten Metriken auseinandersetzen und nicht nur auf deren Funktionsweise, sondern auch auf deren Aussagekraft und Nutzen im Qualitätsmanagementsystem eingehen.

Lines of Code (LOC)

LOC ist sicher eine der trivialsten Metriken. Hierbei handelt es sich – wie der Name schon sagt – um die Zahl der Codezeilen. Dieser Wert kann z. B. auf eine Datei oder eine Funktion bezogen sein. Je nachdem welches Tool man verwendet, um diesen Wert zu berechnen, kann man unterschiedliche Ergebnisse erhalten. Wichtig ist, dass die Berechnungsvorschrift des LOC gleich ist, wenn verschiedene Softwaremodule miteinander verglichen werden sollen. So kann zum Beispiel festgelegt werden, ob und in welchem Umfang Kommentare mitgezählt werden.

Trotz der einfachen Berechnung lohnt es sich LOC für Funktionen und Dateien im Blick zu behalten. Auch wenn Code mit wenigen Zeilen nicht zwangsläufig besser ist, als einer der ein paar Zeilen mehr hat. Quetscht ein Entwickler gerne komplexe Berechnungen in eine Zeile, kann das deutlich unübersichtlicher sein, als wenn er die entsprechende Berechnung in mehreren Zeilen durchführt. Es sollte aber klar sein, dass bei Softwaremodulen ab einer bestimmten Länge, das Codereview deutlich erschwert wird. Es kann also durchaus Sinn ergeben, Richtwerte für LOC in den Kodierrichtlinien festzulegen. Wie hoch diese zu setzen sind, ist von vielen Faktoren abhängig, beispielsweise von der verwendeten Programmiersprache. Außerdem kann dieser Wert nur seinen Zweck erfüllen, wenn er auch tatsächlich überprüft wird. Zum Beispiel im Rahmen eines Code-Reviews oder durch die Wahl geeigneter Tools zur Erfassung von Softwaremetriken.

Beispiele für einen Grenzwert sind:

LOC pro Methode: 100

LOC pro Datei: 1000

Stellt sich nur die Frage, was tun, wenn dieser Wert trotzdem überschritten wurde? Das hängt von der jeweiligen Ursache ab:

  • Softwarearchitektur: Werden Source-Dateien zu groß, kann das unter anderem an der Softwarearchitektur liegen. Werden in einigen Modulen zu viele Funktionen zugeordnet, können sich diese schnell aufblähen. Aus diesem Grund lohnt es sich die Architektur immer wieder, auch während der Entwicklung, zu hinterfragen und ggf. anzupassen.
  • Kodierrichtlinien: Ein weiterer Grund für hohe LOC kann in den Kodierrichtlinien liegen. Entweder schreiben diese nicht klar genug vor wie der Programmierer seinen Code zu schreiben hat oder die Richtlinien werden nicht angewendet. Auch bei den Richtlinien bietet sich an, diese regelmäßig zu hinterfragen und anzupassen. Außerdem sollte bei Code-Reviews auch darauf geachtet werden, dass diese eingehalten werden. Der Entwicklungsprozess sollte an geeigneten Stellen den Status und die Qualität der Design-Outputs prüfen. Über Phasen- oder Meilenstein-Reviews soll sichergestellt werden, dass die Softwaremetriken erfasst und gegenüber ihren Annahmekriterien überprüft wurden.
  • Persönlicher Programmierstil: Ein weiterer Grund ist, dass es sich einfach um den Stil des Programmierers handelt. Jeder kennt diese genialen Programmierer, die in der Lage sind äußerst große Source-Dateien zu beherrschen, zumindest wenn sie den Code selbst verfasst haben. Das Problem zeigt sich oft erst dann, wenn Source-Dateien nach Jahren wieder angefasst werden. Nachdem der Autor entweder nicht mehr bei der Firma arbeitet oder völlig vergessen hat was er damals geschrieben hat. Daher ist es wichtig, dass sich auch die Genies unter den Programmierern an Vorgaben zur Codegröße halten, um es ihren Kollegen in Zukunft nicht unnötig schwerzumachen. Daher ist es wichtig die Mitarbeiter entsprechend zu schulen und die Vorgaben durch regelmäßige Reviews zu kontrollieren.

Ihr Ansprechpartner:

M.Sc. Björn Schmitz, Software Entwickler
E-Mail: schmitz@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

Coverage / Testabdeckung

Die Testabdeckung von Software ist sicherlich eine der am häufigsten verwendeten Metriken zur Softwareverifikation. Gleichzeitig wird jedoch Ihre Aussagekraft immer wieder infrage gestellt. Aus diesem Grund habe ich die Testabdeckung bereits in einem früheren Blogeintrag diskutiert, weswegen ich an dieser Stelle auch nicht zu sehr ins Detail gehen möchte. Zusammengefasst lässt sich sagen, dass die Abdeckung von Sourecode durch Unittests keinerlei Aussage über die Qualität der Tests oder der Software an Sich erlaubt. Von daher ergibt es nur bedingt Sinn hier einen Grenzwert festzulegen. Ein sehr geringer Wert kann allerdings ein Hinweis dafür sein, dass der Code noch einmal kritisch beleuchtet werden sollte. Eventuell hat man tatsächlich etwas Wichtiges beim Testen übersehen. Ist die Abdeckung aber tatsächlich so niedrig, weil der nicht getestete Teil einfach unkritisch ist, sollte man lernen auch mit geringen Zahlen leben zu lernen.

Will man hier aber unbedingt einen Grenzwert festlegen, würde ich diesen auf nicht mehr als 60 % festlegen.

Hier geht es zum Artikel über Testabdeckung

Zyklomatische Komplexität nach McCabe

Generell ist Code hoher Komplexität, schwerer zu beherrschen als solcher mit einer geringen Komplexität. Zum einen bedeutet Code mit hoher Komplexität einen höheren Testaufwand. Zum anderen ist komplexer Code in der Regel schwerer zu lesen, sodass die Wahrscheinlichkeit sinkt, bei Reviews Fehler zu finden. Die McCabe Metrik ist eine Möglichkeit, um die Komplexität von Funktionen zu berechnen. Das klingt soweit ähnlich wie bei der LOC-Metrik. Man könnte also auch hier auf den Gedanken kommen einen Richtwert festzulegen. Das Problem bei McCabe ist allerdings, dass eine hohe Komplexität nicht unbedingt schlecht sein muss. Oft gibt es gute Gründe dafür, warum ein Code komplex geraten ist. Auch muss Code mit hohem McCabe-Wert nicht zwangsläufig schlechter lesbar sein als einer mit niedrigem Wert.

Die Metrik kann allerdings ein Hinweis sein, welche Codeteile bei Reviews besondere Aufmerksamkeit benötigen. Wer allerdings hier einen Maximalwert festlegt, sollte sich nicht wundern, warum dieser Wert regelmäßig, überschritten wird, ohne dass sich hierdurch eine Maßnahme ergibt.

Beispiel für einen gängigen Grenzwert ist eine Komplexität von 15

Verschachtelungstiefe von Verzweigungen

Durch Verschachtelung von Verzweigungen wie if und switch lassen sich mit wenig Codezeilen, viele Funktionen umsetzen. Verschachtelung ist also generell nichts Schlechtes. Alternativen, um Verschachtlungen zu umgehen wären:

  • Viele Funktionen die sich nur in wenigen Zeilen unterscheiden
  • Verzweigungen in Funktionen auszugliedern

So oder so steigt bei geringerer Verschachtelungstiefe die Anzahl an Funktionen und somit die Größe des Codes. Ohne, dass dessen Komplexität steigt. Da auch eine Software mit vielen sehr einfach gehaltenen Funktionen unter Umständen schwer zu testen ist, kann es Sinn ergeben einige Verzweigungen zu verschachteln. Allerdings ist anzunehmen, dass sich ab einer gewissen Tiefe eine Anzahl an möglichen Funktionsdurchläufen ergibt, die für einen Reviewer kaum noch nachvollziehbar ist. Der Trick ist hier einen trade-off zu finden, zwischen Übersichtlichkeit und Codegröße. Eine durchschnittliche Verschachtelungstiefe zu messen ergibt vermutlich keinen Sinn. Sinnvoller ist es in den Kodierrichtlinien einen Maximalwert festzulegen. Wird dieser überschritten, sollte geprüft werden, ob es Sinn ergibt, den Code umzuschreiben.

Als gängiger Richtwert, für die maximale Verschachtelungstiefe, hat sich ein Wert von 4 bewährt.

Fazit

Aus Sicht eines Programmierers finde ich es schwierig sich bei der Bewertung von Qualität einer Software, nur auf Metriken zu verlassen. Die wenigsten Softwaresysteme ähneln sich untereinander genug, als das ein Vergleich über Softwaremetriken wirklich aussagekräftig wäre. Auch sagt das Einhalten von Grenzwerten bei Softwaremetriken, nicht viel darüber aus wie gut eine Software implementiert ist. Trotzdem möchte ich Metriken nicht generell schlecht reden. Das Einbinden von Softwaremetriken in den Entwicklungsprozess kann durchaus Vorteile haben. Das „Vermessen“ der eigenen Software, kann ein Ansporn für Programmierer sein, Ihren Code zu verbessern. Zudem kann es dazu dienen, komplexere Softwaremodule zu identifizieren und festzulegen, welche Teile der Software beim Review von Implementierung und Design, besondere Aufmerksamkeit bekommen. Softwaremetriken bringen also durchaus einen gewissen Nutzen mit sich, den man aber nicht überbewerten sollte.


Geschrieben von Björn Schmitz

Seit Juli 2017 gehöre ich zum MEDtech-Ingenieur Team und bin hier vor allem als Firmwareentwickler tätig. Schon in kürzester Zeit konnte ich an vielen spannenden Projekten aus dem Bereich Medizintechnik, aber auch aus anderen Bereichen mitwirken.


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