Pragmatische Überlegungen zur Softwarequalität

Pragmatische Überlegungen zur Softwarequalität

Softwarequalität wird oft als schwer fassbares und mysteriöses Ziel behandelt. Jeder wünscht es sich und die Strategien zur Erreichung von Qualität sind so vielfältig wie die Unternehmen, die es beanspruchen. Interessanterweise sind nur sehr wenige Menschen in der Lage, eine klare Aussage darüber zu treffen, was Softwarequalität ist. Meiner bescheidenen Meinung nach ist das der Kern des Problems, wie kann ein Ziel erreicht werden, das nicht klar definiert ist?

Es gibt tatsächlich eine Vielzahl von Software-Qualitätsdefinitionen, die gefunden werden können. Wie so oft bietet Wikipedia einen interessanten Ausgangspunkt für das Studium. Die pragmatische Schwierigkeit bei vielen Qualitätsdefinitionen besteht darin, dass es sich um qualitative Beschreibungen handelt, die stark vom Standpunkt des Betrachters abhängig sind. Eine pragmatisch sinnvolle Definition der Softwarequalität muss objektiv und reproduzierbar sein und quantitative Ergebnisse liefern.

Die Definition von Qualität allein ist jedoch nicht ausreichend. Eine Strategie, die beschreibt, wie Qualitätsziele erreicht werden sollen, ist unerlässlich. Wann und wie sollen Qualitätskennzahlen erhoben werden? Wie sollen diese Qualitätskennzahlen verwendet und dargestellt werden, um das Qualitätsniveau sichtbar und kommunizierbar zu machen? Für diese Kennzahlen müssen Qualitätsziele in Form von Zielwerten definiert werden. Sowohl langfristige als auch kurzfristige Ziele sind notwendig, um den Entwicklern erreichbare Ziele zu geben, mit denen sie Fortschritte erzielen können. Schließlich muss ein Plan aufgestellt werden, der zu diesen Zielen führt.

Eine Möglichkeit zur Bestimmung der strukturellen Codequalität ist die statischen Codeanalyse. Auf dem Markt befinden sich zahlreiche konkurrierende Tools (z.B. PcLint, QaC, Polyspace, etc.) für die statische Codeanalyse. Tatsächlich wird das Konzept der „statischen“ Codeanalyse durch die Fähigkeiten, die einige Tools bei der Vorhersage des Laufzeitverhaltens des analysierten Codes einbringen, stark ausgeweitet.

Allerdings kann auch der Compiler ein beträchtliches Maß an Unterstützung bieten, wenn man sich entscheidet, ihn voll auszunutzen. Der gcc-Compiler stellt die Flags „-Wall -Werr“ zur Verfügung, die meines Erachtens immer zwingend sein sollten. Das erste Flag ermöglicht eine große Liste von statischen Prüfungen, die sonst übersprungen würden. Das zweite Flag stellt sicher, dass Warnungen als Fehler behandelt werden, was die Entwickler zwingt, Warnungen ernst zu nehmen und zu beseitigen. Jeder Compiler, mit dem ich vertraut bin, hat ähnliche Fähigkeiten. Ich war oft schockiert über die ungezwungene Art und Weise, in der viele Organisationen Compiler-Warnungen als „sinnlos“ abweisen.

Zusätzliche Ideen für strukturelle Qualitätskennzahlen können aus MISRA oder aus den Quellcode-Metriken von HIS gewonnen werden. MISRA spielt eine wichtige Rolle bei der embedded C-Programmierung und wird oft in sicherheits- und/oder sicherheitsrelevanten Anwendungen eingesetzt. Die HIS-Kennzahlen sind ein Produkt der Automobilindustrie und leisten überraschend gute Arbeit bei der Quantifizierung von strukturellen Qualitätsmerkmalen, die oft als schwer zu quantifizieren gelten.

Einen Ausgangspunkt für die Bestimmung der funktionalen Qualität des Codes bilden Automotive SPICE® (ASPICE), CMMI® und andere Entwicklungsreifemodelle. Ein wiederkehrendes Thema dieser Modelle ist die Forderung nach vollständig definierten Funktionsanforderungen. Diese wiederum müssen auf Qualifikationstests zurückführbar sein, die am Endsystem durchgeführt werden. Im Wesentlichen kann mit bestandener Prüfung der Nachweis erbracht werden, dass die damit verbundenen funktionalen Anforderungen erfüllt sind. Der Grad, in dem funktionale Anforderungen auf Qualifikationstests rückführbar sind, kann daher eine Metrik für die funktionale Qualität des Endsystems liefern. Das funktioniert natürlich am besten, wenn die Anforderungen vollständig und korrekt sind.

Das erste Mal, wenn Werkzeuge zur Generierung von Qualitätskennzahlen eingesetzt werden, werden die Ergebnisse wahrscheinlich entmutigend sein. Es ist nicht ungewöhnlich, dass bei mittelgroßen Projekten viele tausend Fehler nur bei den statischen Codeanalysetools auftreten. Dies einfach vor das Entwicklerteam zu werfen mit der Forderung, dass die Probleme „behoben“ werden, wird die Moral ruinieren und nicht produktiv sein. Es werden zwei verschiedene Werkzeugkonfigurationen benötigt. Die schwache Konfiguration wird diejenige sein, die derzeit verwendet wird. Die starke Konfiguration stellt das langfristige Qualitätsziel der Organisation dar.

In der schwachen Konfiguration werden genügend Fehler- und Warnmeldungen unterdrückt, so dass die Gesamtzahl der zu korrigierenden Probleme innerhalb kurzer Zeit erreichbar ist. Die zweite Konfiguration spiegelt das Qualitätsniveau wider, das das Unternehmen erreichen möchte. Dies erfordert, dass ein Ingenieur die Fähigkeiten des Analysetools und die Bedeutung der verschiedenen Tests, die durchgeführt werden können, untersucht. Dieser Experte muss dann eine fundierte Entscheidung über die zu ermöglichenden Tests treffen.

Bei der Festlegung kurzfristiger Ziele ist ein Zeitrahmen von 2 bis 4 Monaten zwischen den Meilensteinen in der Regel sinnvoll. Ziele können festgelegt werden, indem jeder Entwickler aufgefordert wird, jede Woche 50 Warn- oder Fehlermeldungen zu beseitigen (z.B.). Es kann und sollte akzeptiert werden, dass die Kennzahlen manchmal für eine Weile stagnieren können. Es sollte niemals akzeptiert werden, dass sich die Metriken verschlechtern.

Ich halte es für wesentlich, dass die Entwickler selbst in der Lage sind, die Qualitätskennzahlen für den Code, für den sie verantwortlich sind, zu generieren. Dies fördert das Bewusstsein für die persönliche Verantwortung für die Qualität des Codes, den jeder Entwickler liefert.

Regelmäßige informelle Ergebnisse können im Rahmen des täglichen (oder kontinuierlichen) Aufbaus erzielt werden. Formale Ergebnisse, die für die Planung und Trendanalyse erfasst und verwendet werden, können im Rahmen des Integrationsschritts, wöchentlich oder auf andere Weise generiert werden, die sich problemlos in den Entwicklungsprozess integrieren lassen.

Am Ende eines jeden Verbesserungszyklus von 2 bis 4 Monaten ist eine Überprüfung erforderlich. Sollte die gewählte Definition von Qualität, wie sie in der Wahl der Metriken, Werkzeuge und Konfigurationen enthalten ist, angepasst werden? Die schwache Konfiguration muss überprüft und verstärkt werden, um zusätzliche Warnungen und Fehler für den nächsten Verbesserungszyklus zu ermöglichen. Die kurzfristigen Verbesserungsziele für die Entwickler müssen überprüft und angepasst werden, um realistische und erreichbare Erwartungen für den nächsten Zyklus zu gewährleisten.

Qualitätskennzahlen ermöglichen eine klare Kommunikation sowohl mit dem Management innerhalb des Unternehmens als auch mit den Kunden. Die regelmäßige Sammlung von Kennzahlen unter Verwendung der starken Konfiguration zeigt den Fortschritt bei der Erreichung der gewählten langfristigen Qualitätsziele. Der allgemeine Trend zu weniger Warnungen ist eine Botschaft an sich. Ein Vergleich der beiden Konfigurationen (schwach und stark) kann jedoch leicht genutzt werden, um eine „prozentuale Erreichung“ der allgemeinen Qualitätsziele zu erreichen. Dies geschieht durch Einstellen der Anzahl der aktivierten Tests in der schwachen Konfiguration im Verhältnis zur Anzahl der aktivierten Tests in der starken Konfiguration.

Zusammenfassend lässt sich sagen, dass die Softwarequalität nicht mysteriös sein muss. Exzellente Konzepte und leistungsstarke Tools stehen zur Verfügung. Die Herausforderung besteht darin, die Konzepte und Tools auszuwählen, die in Ihrer Organisation am besten funktionieren. Daraus kann dann eine messbare, quantitative Definition der Qualität abgeleitet werden. Sobald dies geschehen ist, wird die Umsetzung zu einer Frage der Strategie und des Managements. Setzen Sie die Ziele, definieren Sie die Strategie, erstellen Sie einen Plan und erledigen Sie die Arbeit, Meilenstein für Meilenstein.

Was hier nicht diskutiert wurde (es verdient einen eigenen Artikel), ist, wie man dies in den gesamten Entwicklungsprozess integrieren kann, ohne zusätzliche Arbeit für die Entwickler zu verursachen. Es genügt zu sagen, dass auch dies ein lösbares Problem ist.

‍