Was taugt der Programmcode? Der Crash-Report 2014 – Fehler in Business-Anwendungen

Von Ludger Schmitz

Anbieter zum Thema

Alle zwei Jahre erscheint der Bericht „Cast Research on Application Software Health“. Der Titel ist mit Bedacht gewählt; seine Abkürzung „CRASH“ zeigt an, um was es geht: die Code-Qualität von Business-Software.

Der CRASH-Report von Cast zeigt die Qulität des Programmcodes zahlreiicher Busness-Applikationen auf.
Der CRASH-Report von Cast zeigt die Qulität des Programmcodes zahlreiicher Busness-Applikationen auf.
(Bild: Coloures-pic/ Fotolia.com)

Cast ist ein Unternehmen, das bei IT-Anwendern Software und deren Entwicklung analysiert sowie Verbesserungen vorschlägt. Der soeben erschienene „Crash Report 2014“ - kostenlos zugänglich ist eine Zusammenfassung – fasst die Ergebnisse einer aktuellen Analyse von Programmen zusammen. Er bewertet die technische Qualität von Business-Software, nicht aber ihre Funktionalitäten. Der Bericht zeigt ferner auf, welche Methoden die Applikationsentwicklung verbessern.

Für den neuen Report hat Cast 1.326 Applikationen von 212 Organisation aus verschiedenen Industriesektoren in Europa, Indien und den USA untersucht. Insgesamt waren es mehr als 700 Millionen Zeilen Code.

28 Prozent der Anwendungen hatten weniger als 50.000 Codezeilen (LoC), 33 Prozent 50.000 bis 200.000, 29 Prozent auf der nächsten Stufe bis zu eine Million LoC und elf Prozent noch mehr Codezeilen. Die meisten Programme davon, nämlich 565, waren in Java-EE geschrieben, 280 in Cobol, 127 in .NET, 77 in ABAP, 59 in Oracle Forms, 33 in Oracle ERP, 39 in C, 28 in C++ und 24 in ASP. Bei 84 Anwendungen lag ein Mix von Programmiersprachen vor.

Die Bewertungskriterien

In der diesem Bericht zugrunde liegenden Zusammenfassung geht es ausschließlich um die strukturelle Qualität von Code. Diese bestimmt Cast nach fünf Eigenschaften des analysierten Codes: Robustheit (die Stabilität und Abwehr von Fehlern bei Modifikationen), Performanz (im Sinne von Durchsatz und Ressourcenbeanspruchung), Sicherheit (gegen unbefugte Änderung), Wandelbarkeit (zwecks künftiger Modifizierung) sowie Übertragbarkeit (der Pflege und weiteren Entwicklung auf ein völlig neues Team).

Bildergalerie
Bildergalerie mit 8 Bildern

Jeden dieser Aspekte bewertet Cast mit Scores, also Punkten, die von 1 für hohes Risiko bis 4 für geringes Risiko reichen. Die Einzelergebnisse der fünf Qualitätsfaktoren fließen statistisch bereinigt in einem „Total Quality Index“ zusammen.

Nicht so schlecht

Bei der Untersuchung zeigte sich, dass drei Viertel der Anwendungen für die Faktoren Robustheit, Performanz und Sicherheit auf Scores von höher als 3,0 kommen. Die Aspekte Wandelbarkeit und Übertragbarkeit schneiden deutlich schlechter ab, was Cast darauf zurückführt, dass diese zwei Faktoren in der Software-Entwicklung zusätzliche Kosten verursachen, die gescheut werden. Robustheit, Performanz und Sicherheit haben eben Priorität.

Bildergalerie
Bildergalerie mit 8 Bildern

Zwischen den fünf Faktoren ist ein Zusammenhang auffällig, der eigentlich auch zu erwarten ist: Die Verletzung von Regeln guter Softwarearchitektur und -entwicklung führt mit sehr hoher Wahrscheinlichkeit zu weniger sicheren Anwendungen. Hingegen scheint die Performanz mit allen anderen Faktoren wenig zusammenzuhängen, was der herkömmlichen Auffassung widerspricht, dass die Durchsatz-Optimierung alle anderen Qualitätseigenschaften einer Software negativ beeinflusse.

Im Allgemeinen stehen die Qualitätsmerkmale von Anwendungen nicht in Relation zu ihrer Größe. Der Satz „Je größer, desto schlechter“ gilt also nicht – auch nicht im umgekehrten Sinn oder gar mit dem Zusatzattribut exponentiell. Doch bei Java-EE-Anwendungen gibt es eine Korrelation mit Robustheit und bei Cobol-Programmen mit Sicherheit. Beide Male im Sinne von: Je mehr Code, desto schlechter schaut's aus.

Egal, wer entwickelt

Nur bei den Anwendungen, die mit Java-EE geschrieben sind, war die Basis der vorliegenden Detailinformationen groß genug, um statistisch relevant weitere Zusammenhänge zu analysieren. Hier ergab sich, dass es keinen Unterschied macht, ob die Entwicklung firmenintern oder extern erfolgte.

Auch Offshore-Entwicklung zeitigt keine unterschiedliche Qualitätsbenotung. Allerdings erreichten Anwendungen, die für mehr als 5000 User geschrieben waren, höhere Punktzahlen, als Anwendungen für kleinere Nutzerzahlen. Das ist aber laut Cast auch kaum verwunderlich, weil Applikationen für eine breitere Anwenderbasis oft geschäftskritisch sind, weshalb hier an die Entwicklung rigorosere Maßstäbe angelegt werden.

Unternehmen können ihre Software-Entwicklung bewerten lassen. Dafür gibt es „Capability Maturity Model Integration” (CMMI), eine Gruppe von Referenzmodellen, darunter für die Verbesserung der Software-Entwicklung. Andere Standards wie DIN EN ISO 9001, oder ISO/IEC (diverse Normen) sind ähnlich, entsprechen ihm aber nicht genau. CMMI kennt fünf Level von „Initial“ bis „Optimizing“, hier sind jedoch die Level 2 bis 4 (Managed, Defined und Quantitatively Managed) von Interesse.

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zur IT-Sicherheit

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung.

Aufklappen für Details zu Ihrer Einwilligung

Gute Software muss reifen

Cast hat festgestellt, dass diese Bewertung des Reifegrades der Software-Entwicklung durchaus Folgen für die Qualität der Programme hat. Bei allen fünf Teilaspekten von Softwarequalität – und natürlich im Gesamtergebnis – erzielten Entwicklerumgebungen mit CMMI-Level 2 und 3 deutlich bessere Noten als mit Level 1.

Bildergalerie
Bildergalerie mit 8 Bildern

In Sachen Robustheit, Sicherheit und Wandelbarkeit waren die Scores 20 bis 28 Prozent besser. In puncto Performanz und Übertragbarkeit betrug der Unterschied noch 11 bis 12 Prozent. Allerdings ist kaum ein Unterschied zwischen CMMI-Level 2 und 3 auszumachen, was daran liegt, dass hier der Unterschied vor allem in der Standardisierung der Entwicklungspraxis liegt, während zwischen Level 1 und 2 ein größerer Sprung erfolgt.

Die besten Ergebnisse

Ein Blick auf die Grundmethoden der Entwicklungsarbeit zeigt sich ein weiterer Unterschied. Wo nach dem Wasserfallmodell oder nach agiler Methode gearbeitet wird, sind die Ergebnisse in allen Einzelkategorien signifikant besser als ohne solch eine Herangehensweise. Am besten wird die Software nach Ergebnissen der Analyse offenbar dann, wenn Wasserfall- und agile Methoden miteinander verbunden sind.

Daraus folgert Cast die Empfehlungen, erstens den Reifegrad der Software-Entwicklung normengemäß zu steigern und zweitens Hinderungsgründe für diszipliniertes Software-Engineering zu beseitigen.

* Ludger Schmitz ist freiberuflicher Journalist in Kelheim.

Artikelfiles und Artikellinks

(ID:42989146)