Fehlerhafte Anwendungen 5 Gründe, warum Software-Releases fehlschlagen

Entwickler oder Vertreiber von Software können schnell in eine Falle treten, wenn ihr Produkt unfertig oder schadhaft auf dem Markt erscheint. Aber welche Ursachen führen zu scheiternden Releases?

Anbieter zum Thema

PresseBox - unn | UNITED NEWS NETWORK GmbH

Windhoff Group

Windhoff Group

Parasoft® Deutschland GmbH

Man erlebt immer wieder, dass Organisationen, Vertriebe oder Hersteller ihre Software auf eine Weise veröffentlichen, die ungefähr so sicher ist, wie russisches Roulette zu spielen. Sie setzen dabei sowohl die Sicherheit (im Sinne von sowohl Safety als auch Security) als auch die privaten Daten ihrer Kunden aufs Spiel – ganz zu schweigen von der Zuverlässigkeit; dazu kommt der eigene Ruf und das eigene Geschäftsergebnis.

Der Vergleich mit russischem Roulette mag beängstigend sein, aber ... wie oft heißt es, dass es die Software schon so lange gebe, ohne dass es zu Problemen gekommen sei, oder dass man schon immer so gearbeitet habe und es immer funktionierte … was natürlich eine schlechte Planung ist.

Ein Unternehmen mit Schwerpunkt Softwareentwicklung sucht nach Möglichkeiten zur Entwicklung und Einführung besserer Software, die weniger versagt. Dies bedingt eine proaktive, erfolgsorientierte Planung, indem man das Richtige tut, auch wenn das falsche Tun bisher folgenlos blieb.

Laut einer von Forschern der Harvard-Universität durchgeführten Studie schlägt ungefähr die Hälfte aller IT-Softwareprojekte fehl. Es gibt darüber hinaus noch jede Menge weiterer Zahlen aus anderen Quellen, und die genannte Schätzung ist keineswegs die höchste. Eine Fifty-Fifty-Chance heißt effektiv nichts anderes als russisches Roulette mit drei Kugeln im Revolver. Unter keinen Umständen würde ich bei dieser Wahrscheinlichkeit die Zukunft meines Unternehmens aufs Spiel setzen wollen.

Hier folgt ein genauerer Blick auf die Risiken, die jeden Tag bei der Einführung von Software in Kauf genommen werden:

„Technical Debt“: Vererbte, altbekannte Fehler

Es ist eine bekannte Tatsache, dass fehlerbehaftete Software auf den Markt gebracht wird, denn die Entwicklung absolut fehlerfreier Software würde unendlich lange dauern. Dies darf allerdings keine Entschuldigung dafür sein, die bekannten Fehler nicht zu beseitigen.

Über das Thema ‚Technische Schuld‘ (Technical Debt) wurde in sehr abstrakter Form bereits sehr viel geschrieben. Aber hier haben wir es mit einem sehr realen Maß für die Schuld in Ihrer Software zu tun. Wenn man von einem Fehler weiß und ihn nicht behebt, dann sollte es schon sehr triftige Gründe geben, wenn dieser Fehler als bedeutungslos eingestuft wird. Man sollte Sie für jedes Release Zeit dafür einplanen, nicht nur neue Features hinzuzufügen, sondern alles insgesamt zu verbessern. Sich also die Zeit zu nehmen, um die Software aufzupolieren.

Verschlimmbesserung: Neue Bugs in altem Code

Alter Code hat seine Tücken. Bei manchen Unternehmen heißt die Devise: „Bessert die Software gleich mit auf, wenn ihr sie ohnehin schon repariert.“ Anderswo lautet die Anweisung dagegen, nur das unbedingt Nötige anzufassen und dies auch nur dann, wenn es um einen im Feld aufgetretenen Fehler geht.

Beides sind interessante Herangehensweisen. Am wichtigsten ist es allerdings, zu verstehen, was mit dem alten Code passiert und welche Risiken sich aus diesem Code für Ihr Unternehmen ergeben. Denn wenn der Code kritisch ist, spielt das Alter möglicherweise keine so große Rolle, wie man vielleicht glaubt. Wird der Code aber ausgesondert, verschwendet man unter Umständen Zeit mit dem Testen von etwas, das man ohnehin nicht reparieren wird.

Security als Teil des Testens anstatt der Entwicklung

Es macht einen betroffen zu erleben, wie häufig Organisationen das Thema Security außer Acht lassen. In einigen Fällen glauben sie, sie könnten ihre Applikationen durch Testen sicher machen (was ein Irrglaube ist), und in anderen Fällen wird die Auffassung vertreten, Security-Probleme seien für ihren Code kein Thema (was falsch ist).

Um aus dieser Misere mit fortlaufenden Security-Problemen herauszukommen, müssen Organisationen ihren Code mit soliden AppSee-Methoden absichern, kodifiziert mit einem statischen Analysetool, das sich nicht auf eine simple Ablaufanalyse beschränkt. Wenn man nicht weiß, wo man ansetzen soll, würde es ehrlich gesagt auch nicht schaden, die MISRA-Regeln zugrunde zu legen und sie bei jedem Code, der neu geschrieben wird, zu befolgen.

Die Aussagefähigkeit von Test Suites

Eine äußerst weit verbreitete und gefährliche Praxis, besteht darin, eine umfangreiche Test Suite zu verwenden und sich schlicht auf die Zahl der bestandenen Tests zu verlassen. Werden beispielsweise in der Regel 80% der Tests bestanden, geht man davon aus, dass dies so in Ordnung ist. Allerdings weiß man nicht, ob die 80% bestandenen Tests heute dieselben sind wie die gestrigen. So könnte die Zahl von 80% etwa einen neuen gravierenden Fehler verbergen, weil ein anderer Fehler behoben wurde, sodass die Gesamtzahl gleichbleibt.

Man sollte die Test Suite sauber halten, sonst sind ihre Ergebnisse von keiner großen Aussagekraft. Ich möchte den Nutzen eines nicht bestandenen Tests, den man ruhigen Gewissens ignoriert, ernsthaft in Zweifel ziehen. Warum übergeht man diesen Test dann nicht ganz? Das wäre zumindest ehrlicher und sinnvoller.

Der Launch-Zeitpunkt: Einführung nach Kalender

Das vielleicht kritischste, weit verbreitete Release-Kriterium ist der Kalender. Ein festes Datum ist definiert, und jetzt erfolgt die Einführung, weil dieser Tag gekommen ist. Man sollte sich darauf verlassen, dass es externe Faktoren gibt, die Ihren Release-Zeitplan beeinflussen. Nur das Erreichen eines bestimmten Tages darf deshalb nicht der Anlass sein, den arglosen, baldigen Ex-Kunden eine zweifelhafte Software zuzumuten. Software sollte nur dann herausgegeben werden, wenn sie fertig, sicher, stabil und gut ist. Sollte der Kalender dennoch eine feste Vorgabe sein, muss man den pünktlichen Projektablauf sicherstellen.

Wie oft können Unternehmen Software auf diese Weise einführen, bevor sie die Quittung dafür bekommen? Es kann sechsmal klappen oder schon beim ersten Mal schiefgehen – ganz wie im Beispiel mit dem russischen Roulette. Geben wir stattdessen doch einfach unser Bestes, um mit der höchsten Erfolgsquote die beste Software abzuliefern.

Dieser Beitrag stammt ursprünglich von unserem SchwesterportalElektronikpraxis.de.

* Arthur Hicken ist Software-Evangelist bei Parasoft Corp.

(ID:44991710)