Fehlerquellen auf der Spur

Bereits Ende letzten Jahres veröffentlichte die auf Softwaretests spezialisierte SQS AG eine Liste mit den spektakulärsten Softwarefehlern des Jahres 2011. Für einige Unternehmen kamen diese richtig teuer. So verhängte die US-Finanzaufsichtsbehörde Securities and Exchange Commission (SEC) einem internationalen Finanzdienstleister ein Strafe von 25 Mio. Dollar. Dieser hatte zuvor einen Fehler in einer Software-Anwendung eines Investmentfonds vertuscht. Gleichzeitig musste das Unternehmen den geprellten Anlegern den entstandenen Schaden zurückerstatten: schlappe 217 Mio. Dollar.

Und auch im Automobilbereich ging es 2011 nicht ohne Softwarefehler. Hier musste ein japanischer Autohersteller weltweit knapp eine Million Autos zurückrufen. Ursachen dafür waren u.a. elektrische Fensterheber, die zu einem Brand führen konnten. Doch damit nicht genug: So rollten 26.000 Fahrzeuge durch einen Programmierfehler im Motormanagement wie von Geisterhand selbsttätig vor und zurück, sobald der Fahrer den Motor abwürgte. Laut SQS waren allein in Deutschland knapp 2.400 Autos von diesem Fehler betroffen. In Folge brach an der Börse in Tokio die Aktie des Herstellers um fast fünf Prozent ein. Dass solche Vorfälle keine Seltenheit sind, beweisen die Erfahrungen von Michael Speer, Mitglied des Vorstandes bei Generic.de: „Der schlimmste mir bekannte Fehler, der auf fehlerhafte Programmierung zurückzuführen ist, gipfelte in einer dreistündigen Ausfallzeit der produktiven Anwendung. Der schlimmste Fehler, der aufgrund eines mangelhaften Prozesses beim Kunden zustande kam, resultierte in der völligen Neuentwicklung der Anwendung im Umfang mehrerer Mannjahre.“

Entwicklungsfehler gefährden Menschenleben

Lässt sich solch wirtschaftlicher Schaden vielleicht noch verschmerzen, hört der Spaß spätestens dann auf, wenn Menschenleben gefährdet werden. „Besonders schlimm sind Fälle, in denen Menschen durch Entwicklungsfehler zu Schaden kommen oder gar sterben, wie im Fall falsch programmierter Bestrahlungsgeräte, bei denen Patienten eine tödliche Strahlendosis erhielten“, führt Wolfgang Neuhaus, Vorstand bei der Itemis AG, als Negativbeispiel an. Neben solchen Horrorszenarien lassen sich aber auch Kuriositäten finden: „Im Programmcode eines der ersten computergesteuerten Jagdflugzeuge, der F-16 der USA, befand sich im Algorithmus ein Vorzeichenfehler. Beim Überfliegen des Äquators stellte sich das Flugzeug auf den Kopf“, berichtet Neuhaus. Nicht zuletzt bemerkt Chris Adlard, Senior Manager Customer Advocacy bei Coverity, dass die IT-Geschichte zwar immer wieder Beispiele für spektakuläre Softwarepannen liefert – die Dunkelziffer aber nochmals um einiges größer sein dürfte.

Fehlerquelle Nummer eins

Die Ursachen für fehlerhafte Software können vielfältig sein. Als Fehlerquelle Nummer eins gelten für David Intersimone, Chief Evangelist bei Embarcadero, mangelnde Absprachen und schlechtes Anforderungsmanagement. Ähnlich argumentiert Matthias Grund, Vorstand der Andrena Objects AG. Seiner Ansicht nach liegen die Ursachen häufig in einer schlechten Planung, die unnötigen Druck auf die Entwicklungsteams erzeugt. Ein mangelndes Verständnis von modernen Software-Engineering-Methoden wie der testgetriebenen Entwicklung sei der Qualität ebenfalls abträglich. Ergänzend hierzu können laut David Intersimone eine unzureichende Einbindung der User sowie ein hoffnungslos unterschätzter Aufwand eine große Rolle spielen. Um Fehler in der Software-Entwicklung so früh wie möglich aufzuspüren bzw. zu eliminieren, können Programmierer verschiedene Methoden und Tools einsetzen. Hier hat sich laut Chris Adlard inzwischen Agilität zum De-facto-Entwicklungsmodell für die meisten großen Unternehmen herauskristallisiert. Damit einher gehe ein größeres Engagement der Entwickler in Initiativen zur Qualitätssicherung, was wiederum dazu beiträgt, weitere Verbesserungen in der Softwarequalität sicher zu stellen.

Einen Qualitätsstandard für Software entwickelten die Partner des Forschungsprojektes Quamoco (Softwarequalität: flexible Modellierung und integriertes Controlling; www.quamoco.de) innerhalb der letzten drei Jahre. Das Konsortium mit den Partnern Fraunhofer IESE, Itestra, SAP, Siemens, TU München und Capgemini stellte im Mai die erarbeiteten Modelle und Werkzeuge zur Messung und Bewertung von Softwarequalität frei zur Verfügung. Sie sollen die Lücke zwischen den existierenden abstrakten Qualitätsnormen wie ISO 25010 und den konkreten Maßen und Kennzahlen schließen, die die heute üblichen Werkzeuge zur automatisierten Software-Analyse ermitteln.

Dieser Brückenschlag erlaube es Software-Ingenieuren nun, Software mittels einheitlicher und nachvollziehbarer Qualitätsmodelle zu vergleichen. „Daneben haben wir auch mit den dazugehörigen Werkzeugen – etwa einem Modelleditor, einem Wizard für die Modell­anpassung und einer One-Click-Anbindung an ConQAT – Maßstäbe für die Qualitätsanalyse gesetzt“, fasst Marion Kremer, Head of CSD Research bei Capgemini, die Ergebnisse des Forschungsprojekts zusammen.

Test ist nicht gleich Test

An sich besitzt die Qualitätssicherung viele Facetten. Neben dem Einsatz klassischer Testtools sei es in kritischen Anwendungsbereichen zielführend, „die Codequalität ebenso wie die Architekturkonformität und die Schnittstellenkompatibilität zu prüfen“, meint Marion Kremer. Sinnvollerweise kommen hier Werkzeuge zum Zuge, die sich in eine integrierte Entwicklungsumgebung einbinden bzw. im Nightly Build einsetzen lassen, so dass der Entwickler möglichst eine direkte Rückmeldung erhält. „Die genaue Ausgestaltung der Qualitätssicherungsmaßnahmen sollte jedoch genau geplant und auf die Fähigkeiten der Beteiligten abgestimmt werden“, rät Kremer weiter.
In der Praxis können Entwickler auf verschiedene Tools setzen, um die Qualität der Software zu gewährleisten. So ermöglicht Static Analysis, ein Bestandteil der Coverity-Plattform, das automatische Testen während der Entwicklung. „Das Tool lässt Programmierer versteckte, aber gleichzeitig potentiell schwerwiegende Fehler bereits in einem frühen Stadium der Entwicklung aufspüren“, erklärt Chris Adlard. Damit würden die Kosten, der notwendige Mehraufwand und das Risiko verringert, welches die Softwarefehler verursachen. Das Analyseverfahren findet kritische Fehler in C/C++-, Java- und C#-Code.

Desweiteren bietet der Hersteller mit Integrity Control eine Lösung zur Kontrolle des Quelltextes. Software-Entwickler können mit ihrer Hilfe Richtlinien zur Quelltextqualität, Sicherheit und Entwicklerproduktivität erstellen. „Der Test des Codes kann dann mit Hilfe von Richtlinien verwaltet, überwacht und protokolliert werden. Auf diese Weise erhalten die Firmen Einblicke in die Risiken, die mit der Entwicklung verbunden sind“, ergänzt Chris Adlard.

Dabei sind Tests jedoch nicht gleich Tests. Metin Savignano, Geschäftsführer bei Savignano Software Solution, zufolge können fachliche Funktionstests oder Zweigüberdeckungstests, besonders in Form von Regressionstests, die funktionalen Anforderungen der Software testen. Ergänzend dazu messen Performance- und Lasttests nicht-funktionale Qualitätsmerkmale wie Skalierbarkeit. „Für wichtig halte ich risikobasiertes Testen, also die Festlegung des Detaillierungsgrades von Tests anhand einer Risikoanalyse“, betont Metin Savignano weiter.

Grundsätzlich spricht er sich für wiederholbare Tests aus, die dann auch eine Aussage über die Qualität und den Qualitätsverlauf erlauben. „Um möglichst früh solche Aussagen treffen zu können, halte ich Unit-Tests für unerlässlich“, so Savignano weiter. Hierbei behelfen sich Entwickler damit, dass sie ihren Code in überschaubare Stücke bzw. Komponenten aufteilen und diese separat testen. Frühe Unit-Tests tragen dazu bei, dass die Testbarkeit schon im Entwurf berücksichtigt wird. Das bringt den positiven Effekt mit sich, glaubt Savignano, dass dies zu einem besseren Design von Komponenten und Schnittstellen führe.

Trends schaffen neue Anforderungen

Wie in der Vergangenheit stellen technologische Trends die Software-Entwickler aktuell vor neue Herausforderungen. Heißt: Auch sie bleiben von Hypes wie Cloud Computing und Mobility nicht verschont. So glaubt Sven Euteneuer von SQS (siehe Interviewkasten), dass diese Trends neue Anforderungen an Software schaffen, die in herkömmlichen Projekten keine oder nur eine geringfügige Rolle gespielt haben. Insbesondere Cloud Computing verändere die Software-Entwicklung aber nur in geringem Ausmaß, so Michael Speer, da service-orientierte und verteilte Applikationen zunächst einmal nichts Neues sind. Von größerem Interesse sind vielmehr mobile Anwendungen. „In diesem Bereich gibt es viele neue Plattformen (iOS, An­droid) und die Anwendungen müssen an unterschiedliche Bildschirmgrößen (Smartphone, Tablet) angepasst werden. Das kann unter Umständen jedoch aufwendig sein“, so Speer. Zudem sorgt die zunehmende Verbreitung mobiler Endgeräte für neue Herausforderungen in der Bedienbarkeit. „Hier ist die Erwartungshaltung der Nutzer deutlich größer geworden. Auch Gesten oder Sprache dienen zunehmend als Interaktionsmittel und müssen in der Entwicklung verstanden und sinnvoll eingesetzt werden“, berichtet Wolfgang Neuhaus von Itemis.

Einen weitaus geringeren Einfluss misst Matthias Grund von Andrena Objects den beiden Hypethemen bei. Denn es seien weniger neue Technologien, die gegenwärtig die Software-Entwicklung verändern, als vielmehr das Thema Agilität. „Denn Agilität verlangt neuartige Engineer­ing-Skills wie die testgetriebene Entwicklung, Refactoring und Continuous Integration sowie soziale Fähigkeiten“, so Grund. Von daher würden vor allem die Software-Entwicklung in Iterationen und Inkrementen sowie der Erhalt der Planungshoheit für Entwicklungsteams aktuell die Prozesse grundlegend verändern.

Wandel der Programmiersprachen

Parallel zum Methodikwandel in der Software-Entwicklung, verändert sich der Stellenwert der Programmiersprachen. Während man aus Tradition, aber auch aufgrund der Mächtigkeit und Flexibilität der Programmiersprache, vor allem im industriellen Umfeld weiterhin auf C/C++ baut, rücken bei der Programmierung für mobile Geräte neue Sprachen in den Vordergrund: „Für Apple-Modelle ist dies beispielsweise Objective C“, erklärt David Intersimone von Embarcadero.

Desweiteren sind laut Chris Adlard vor allem bei Online-Applikationen im Finanzsektor und im Handel Java und C# weit verbreitet. Auf diesen beiden Sprachen basierende Anwendungen lassen sich zum einen schneller entwickeln und bieten dem Entwickler zum anderen vielfältigere Möglichkeiten. Allerdings binden sie auch mehr Ressourcen, räumt Adlard ein. Befragt nach den beliebtesten Programmiersprachen, erklärt Marion Kremer: „Neben der .Net-Welt zählt vor allem Java dazu, da diese Sprache – zumindest in Deutschland – an den Hochschulen gelehrt wird und trotz aller damit verbundenen Herausforderungen von vielen Unternehmen zur Vorgabe gemacht wird.“ Zählt man zu den Software-Entwicklern auch Hobbyprogrammierer hinzu, wird sicherlich PHP sehr häufig verwendet, so Metin Savignano abschließend.

Kriterien für die ­Bewertung von Softwarequalität

• Zufriedenheit der Benutzer: Ist die Software funktional und sind die Features leicht zugänglich?
  
• Wiederverwendbarkeit: Können Teile modular in weiteren Anwendungen benutzt und wiederverwendet werden. Wie sieht es mit der Wartbarkeit aus?
  
• Monetär: Wie gut verkauft sich eine Anwendung? Aber auch, wie schnell und zu welchen Kosten wurde die Software entwickelt?
  
• Quellcode-Ebene: Hier kann man die Qualität automatisiert durch Metriken überprüfen. Auch funktionale Tests bis hin zu Sicherheitstests lassen sich heutzutage schon automatisieren.

Quelle: David Intersimone, Chief Evangelist bei Embarcadero

Häufige Fehlerquellen bei der Entwicklung von Individualsoftware

•   Parallelitätsfehler wie Deadlocks, Gleichzeitigkeitsbedingungen und Blocking Call Misuse
•   Leistungsabfall durch Verluste bei Speicherkapazitäten, Dateien, benutzerdefinierten Speichern und Netzwerkressourcen, Datenbankverbindungen
•   Ausfallverursachende Fehler wie Null-Zeiger-Dereferenzierung, Use-after-free, Double free, unsachgemäße Speicherzuordnungen und nicht übereinstimmende Array New/Delete
•   Programmfehlverhalten durch toten Code, nicht initialisierte Variablen, ungültige Anwendung negativer Variablen
•   Fehlerhafte Anwendung von APIs mit Standard-Template-Library–Nutzungsfehlern (STL)
•   Sicherheitsverletzungen durch Überläufe im Zwischenspeicher, unzureichende Überprüfungen etc.

Quelle: Chris Adlard, Senior Manager bei Coverity

Bildquelle: iStockphoto.com/Ecocandle