Wie viele Fehler darf ein Softwareprodukt haben, bevor es an den Markt geht?
Dr. Patrick Hedfeld, Senior Project Manager, IT, Deutsche Leasing Gruppe und
Yannick Gael Fokou Fotsing, Student, Deutsche Bahn
An Fehler in Softwareprodukten hat sich der Mensch schon längst gewöhnt, beispielsweise, wenn während des Arbeitens auf einmal Excel, Word oder das Betriebssystem abstürzen und neu gestartet werden müssen. Diese Fehler sind für jeden ärgerlich, gehören aber zum Alltag. Laut des amerikanischen National Institute of Standards and Technology verursachen Softwarefehler in den USA jährlich Kosten von über 60 Mrd. $. Im Rahmen der Untersuchung ist auch festgestellt worden, dass fast 80 % der Kosten für die Softwareentwicklung in die Suche nach Softwarefehlern investiert werden. Obwohl Software vor der Produktionssetzung intensiv getestet wird, treten diese Fehler immer wieder auf. Um die neu entdeckten Sicherheitslücken und Fehler in ihren Betriebssystemen zu schließen, müssen allein Microsoft und Apple jeden Monat einen oder mehrere Patches veröffentlichen.
Einleitung
Die Geschichte hat gezeigt, dass diese Softwarefehler viel schlimmer werden und fatale Folgen für Unternehmen und sogar Menschenleben haben können. Das erinnert an zwei schwerwiegende und berühmte Softwarefehler der Geschichte: Die Explosion von Ariane 5 und das Denver-Koffer-Debakel.
Am 04.06.1996 explodierte die Ariane 5 nur 40 Sekunden nach dem Start. An Bord waren vier Satelliten. Der Verlust betrug ungefähr 500 Mio. Dollar für die Raketen und die Satelliten. Die Entwicklungskosten hatten ca. sieben Mrd. Dollar betragen. Ursache für den Absturz war ein kleiner Softwarefehler: Der Computer stürzte 37,6 Sekunden nach dem Start ab, als er versuchte, den Wert der Horizontgeschwindigkeit von 64 Bit Gleitkommadarstellung in 16 Bit Signed Integer umzuwandeln. Die entsprechende Zahl war größer als 2 mal 10 hoch 15, wodurch ein Stackoverflow entstand.
Messbarkeit
Es besteht die Frage nach der Messbarkeit eines Bugs. Anders gesprochen: Wie viele Bugs darf eine Software haben, damit sie produktiv gehen kann? Das bezeichnet man als die sogenannten Known-Bugs.
Bis zur Fertigstellung eines Softwareprodukts müssen viele Phasen durchlaufen werden. Dabei können zahlreiche Fehler auftreten. Softwarefehler entstehen hauptsächlich während der Anforderungsspezifikation, Integration, Designspezifikation und Implementierung oder Codierung. Viele Mechanismen werden in dieser Phase eingesetzt, um diese Fehler so früh wie möglich zu entdecken. In IT-Projekten gilt die Maxime: Je früher ein Fehler gefunden wird, desto günstiger ist die Behebung. Deshalb wird schon ein Teil der Fehler im Rahmen von verschiedenen Reviews entdeckt: ungefähr 20 % durch Spezifikations- und Code-Reviews, ca. 70 % in den Testphasen und ca. zehn Prozent im Betrieb.
SEMINARTIPPS
Neuerungen im EEG 2018 / 2019 - Auswirkungen auf die Finanzierung von EE-Projekten, 27.11.2018, Frankfurt/M.Gesamtbanksteuerung im Fokus von Aufsicht & Revision, 18.09.2018, Köln.
Prüfung & Beurteilung des Geschäftsmodells durch Aufsicht & Revision, 19.09.2018, Köln.
Identifizierung und Prüfung IDVs & neues IDV-Zentralregister, 14.11.2018, Köln.
Fehlerhafte Definition in den Anforderungsdokumenten
Eine Ursache ist eine fehlerhafte Definition in den Anforderungsdokumenten. Im Rahmen von Projekten werden in der Regel Anforderungen mit den Projektbeteiligten abgestimmt und in Anforderungsdokumenten festgehalten. In diesen Dokumenten sind alle benötigten Komponenten und Funktionalitäten des gewünschten Softwareprodukts beschrieben und werden an den Auftragnehmer übergeben. Diese Dokumente sind die prinzipielle Ursache von Softwarefehlern. In der Regel können sie folgende Mängel enthalten:
- falsch definierte Anforderungen
- fehlende zentrale Anforderungen
- unvollständig beschriebene Anforderungen
- Probleme in der Kunde-Entwickler-Kommunikation
- Missverständnisse bei der Interpretation des Dokuments durch den Auftragnehmer
BUCHTIPP
Tschuschke (Hrsg.), Geschäftsmodellanalyse, 2016.
Klassifierung und Clusterung
Softwarefehler lassen sich klassifizieren. Die Kategorisierung der Fehler nach DIN 55350 Teil 31 orientiert sich an den Fehlerfolgen und gruppiert sich wie folgt: Kritischer Fehler (A), Hauptfehler (B), Nebenfehler (C). Aus Sicht des Managements lässt sich ein IT-Projekt bewerten, indem bestimmte Regularien erfüllt werden. Zu den Regularien gehört beispielsweise die Definition einer Release- Planung, an der sich das Projekt ausrichten muss. Um diese Regularien zu erfüllen, sind IT-Projekte gezwungen, in einem bestimmten Zyklus einen Softwarestand in die Produktionsumgebung zu überführen.
Dabei werden Maßnahmen ergriffen, um ihre Auswirkungen auf das
gesamte System so gering wie möglich zu halten. Diese Maßnahmen bestehen darin,
- die Komponente zwar produktiv zu nutzen, ihre Funktionalität aber nicht für den Benutzer zugänglich zu machen und
- die Komponente zu kapseln, sodass sie nicht von anderen Komponenten angesprochen werden kann und keine Auswirkungen auf andere Komponenten des Systems hat.
In der Regel handelt sich dabei um Fehler der Kategorie B oder C. Es sind aus Sicht des Projekts Fehler, die das gesamte System nicht beeinträchtigen. Ohne Funktionalitäten, die in diesen Komponenten enthalten sind, kann das System trotzdem bedient werden. Anders ausgedrückt: Es handelt sich um Softwarefehler, mit denen der Kunde zeitweise leben kann, Fehler, die keine Notlieferung erzwingen. Aus strategischer und planerischer Sicht des Projekts kann es sinnvoll sein, Known-Bugs in die Produktionsumgebung aufzunehmen. Schließlich besteht die Möglichkeit, dass diese Known-Bugs beim nächsten Release-Zyklus behoben werden können.
Die Frage, was ein bekannter Bug für eine Software bedeuten kann, kann in einer ersten Näherung folgendermaßen beantwortet werden: Die Funktionalität und die damit verbundene Verwendung der Software entscheidet über den Verbleib eines Known-Bugs, wenn dieser nicht zur Kategorie A (Sicherheitslücke, Systemabsturz etc.) gehört. In einem zweiten Schritt (beispielsweise Folge-Release) kann über den Verbleib des Known-Bugs entschieden werden.
PRAXISTIPPS
- Fehler in der Software kosten viel Geld und führen zu hohen Wartungsaufwänden.
- Known-Bugs sind bekannte Softwarefehler, die nicht schwerwiegend sind.
- Durch (kurze) Release-Zyklen kann die Software sogar mit bekannten Fehlern live gesetzt werden.
- Bekannte Fehler dürfen keine schwerwiegenden Fehler sein.
Beitragsnummer: 860