Unterhalt von Java-Software teurer als von Cobol-Programmen

Eine Untersuchung von Unternehmenssoftware zeigt einerseits eine Dominanz von J2EE. Andererseits verursacht Java-Software jedoch deutlich höhere "technische Schulden" als in Cobol geschriebene.

In Pocket speichern vorlesen Druckansicht 342 Kommentare lesen
Lesezeit: 2 Min.
Von
  • Christian Kirsch

Zum zweiten Mal hat die US-Firma CAST Software Unternehmenssoftware unter anderem in Hinblick auf Sicherheit, Leistung und Wartbarkeit untersucht. Dabei kamen 745 Anwendungen mit 365 Millionen Zeilen Code aus 160 Organisationen auf den Prüfstand.

J2EE-Anwendungen machen mit knapp 46 Prozent den Löwenanteil der untersuchten Programme aus, gefolgt von 16 Prozent, die verschiedene Techniken mischen. Auf den dritten Platz kommt Cobol-Software mit 11 Prozent. Vertreten sind außerdem die Kategorien .NET, ABAP, C, C++, Oracle Forms, Oracle CRM/ERP und Visual Basic.

Der Bericht (PDF) bewertet die Aspekte Robustheit, Leistung, Sicherheit, Einarbeitungsaufwand (Transferability) und Flexibilität. Transferability beschreibt den Aufwand einer neuen Entwicklergruppe für das Einarbeiten in die Anwendung, sodass sie produktiv an ihr arbeiten kann.

Bei der statischen Code-Analyse mit dem hauseigenen Werkzeug "Application Intelligence Platform" ermittelte CAST eine als "technische Schuld" (technical debt) bezeichnete Größe zum Messen der Code-Qualität. Sie beschreibe "die Kosten für die Behebung jener Probleme in einer Anwendung, die das Unternehmen einem ernsthaften Risiko aussetzen."

Am höchsten liegen, so CAST, die durchschnittlichen Schulden bei J2EE-Anwendungen, während Cobol- und ABAP-Anwendungen sehr niedrige Werte haben. Dazu dürfte auch beitragen, dass Cobol-Programme im Durchschnitt wesentlich älter sind als etwa in .NET oder Java geschriebene, sodass viele Bugs bereits entdeckt und beseitigt sind.

Ungewöhnlicher ist der behauptete Zusammenhang zwischen Software-Releases einerseits und den Faktoren Wartbarkeit und Sicherheit andererseits: CAST zufolge ist häufig aktualisierte Software schlechter zu warten und hat mehr Sicherheitsprobleme. Das scheint zumindest dem Credo "release early, release often" der Open-Source-Bewegung zu widersprechen. (ck)