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

SW-Metriken aus Sicht des QMS

Warum sollen Software Qualitätsmetriken im Produktlebenszyklus eingesetzt werden?

Eine Softwaremetrik bildet eine Software-Einheit in einen Zahlenwert ab. Der Zahlenwert steht für ein Maß für die innere Qualität von Software. Software Code Metriken werden eingesetzt, um in möglichst kurzer Zeit Eigenschaften von Software quantifizieren zu können. Zum einen, um ein Qualitätsmaß über den Produktlebenszyklus zu verfolgen und um Programme bei gleicher oder ähnlicher Programmiersprache miteinander vergleichen zu können.

Für die Entwicklung und Wartung von medizinischer Software stellen die ISO 13485 und die IEC 62304 den Grundstein der normativen Anforderungen dar. In Abhängigkeit der Software Sicherheitsklasse verschärfen sich die Anforderungen an die Entwicklung und Dokumentation von sicherheitskritischer Software. Im Automotive findet die ISO 26262-6 Anwendung und stellt konkrete Anforderungen an die Verifikation von Software. Hier werden u. a. in Tabelle 14 und 17 Metriken auf Software Unit und Architektur-Ebene gelistet. Die IEC 62304 ist hier weniger konkret. Dennoch bieten sich Metriken zur Erfüllung von zusätzlichen Akzeptanzkriterien für Software Einheiten (Kapitel 5.5.4 IEC 62304 : 2006) an oder als Basisvorgabe für Regressiontests und der Release-Fähigkeit der Software. Des Weiteren werden die ISO 13485 und die 21 CFR 820.250 sehr konkret im Hinblick auf den Einsatz von statistischen Methoden zur Beurteilung von Produktmerkmalen. Hier bieten Softwaremetriken eine schöne Möglichkeit quantitative Aussagen zu liefern und auch negativen Trends im Bereich Softwarequalität schnell und effektiv entgegenzuwirken.

Schwächen von Software Qualitätsmetriken

Softwaremetriken sind nur sinnvoll mit dem Einsatz von entsprechenden Tools zu ermitteln. Dabei muss der Bedienungsaufwand in den Projektplan mit einkalkuliert werden sowie etwaige Lizenzkosten. Alle eingesetzten Tools müssen für ihren Einsatzzweck validiert sein. Auch dieser Aufwand muss sinnvoll eingeplant werden.

Eine Metrik alleine kann nie eine vollständige Aussage über die Qualität der Software treffen. Metriken sollten immer in Kombination bewertet werden. Die Güte und Reife von Software kann nur in Kombination mit statischer Code Analyse, Code Reviews und funktionalen Tests final beurteilt werden. Softwaremetriken sollten nicht am Ende der Entwicklung erstellt werden, um den Auditor zufriedenzustellen, sondern sollten vielmehr kontinuierlich im gesamten Produktlebenszyklus eingesetzt werden, um die Lesbarkeit und Wartbarkeit von Source Code nachhaltig zu verbessern.

Nutzen

Sind die Tools validiert und einsatzfähig vorhanden, lassen sich Softwaremetriken sehr einfach in den Entwicklungs- und Wartungsprozess einbauen. Dies dient u. a. dazu früh potenzielle Bugs zu entdecken und nicht erst mühsam sehr viel später durch aufwendige Debugging-Sessions auf Systemebene. Der Einsatz für Lizenzkosten kann sich also sehr schnell wieder amortisieren.

Kennzahlen sind dort sinnvoll einzusetzen, wo eine quantitative Analyse von Softwareeigenschaften sinnvoll ist. Dies ist bei Softwaremerkmalen gemäß ISO 25010 im Bereich der Wartbarkeit, Effizienz, Sicherheit und Zuverlässigkeit gegeben. Andere Eigenschaften wie die der Funktionalität, Gebrauchstauglichkeit, Kompatibilität und Portabilität lassen sich nur durch geeignete Testmethoden verifizieren.

Softwaremetriken können als Instrument im Bereich der Datenanalyse (Kapitel 8.4 ISO 13485:2016) zur Ermittlung von Produktmerkmalen und deren Trends eingesetzt werden. Dabei ergibt sich zum einen die Möglichkeit negativen Trends entgegenzuwirken und zum anderen generell einen Mechanismus zur Möglichkeit der Verbesserung zu implementieren. Regulativ geforderte Kennzahlen sind mit dem Einsatz von Softwaremetriken einfach, objektiv und effizient in den Prozess zu integrieren.

Der Einsatz und die Weiterverfolgung der Softwaremetriken auch nach dem Produkt-Release kann dazu dienen den Code robuster werden zu lassen, die Wartbarkeit zu erhöhen und insgesamt einen Beitrag zu Kundenzufriedenheit und sicherer Software zu leisten.

Literatur, Links und Schulungen

• Basiswissen Softwaretest – Andreas Spillner und Tilo Linz
• Softwaretest für Embedded Systems – Stephan Grünfelder
• Basiswissen medizinische Software – Christian Johner, Matthias Hölzer-Klüpfel und Sven Wittorf
• Zertifizierung: ISTQB Certified Tester
• Zertifizierung: Certified Professionel for medical software
• Embarc, Architektur Spicker – quantitative Analyse: (https://www.embarc.de/architektur-spicker/)

Kontaktieren Sie uns!