Software-Qualität – eine oft böse Überraschung


Wer für Software-Entwicklung bezahlt, hält es für selbstverständlich, qualitätsvolle Software zu bekommen. Welch ein Irrtum das sein kann!

Selbst weltweit anerkannte IT-Dienstleister (s.u. Beispiele) liefern hin und wieder absolut unbrauch­bare Software und bescheren so ihren Kunden Verluste in Millionen-Höhe.

Warum nur fühlen sich Software-Entwickler so wenig für die Qualität ihrer Erzeugnisse verantwortlich?

Warum nur sehen sie Qualität so gar nicht als eines ihrer wichtigsten Ziele?

Liegt es daran, dass ihre Auftraggeber Qualität nur allzu pauschal fordern (und denken, sie nicht extra bezahlen zu müssen)?

Traurige Tatsachen sind:

  • Wartbarkeitsaspekte — für Eigentümer und Betreiber der Software extrem wichtig — adressiert kaum jemand: Wie sich die Total Cost of Ownership niedrig halten lässt, diskutieren Entwickler nicht wirklich (sie müsste vom Auftraggeber schon explizit gefordert sein, …).
     
  • Benutzerfreundlichkeit scheint Entwicklern völlig egal (so ergab eine Studie aus 2012).

 

Eine 2001 im Auftrag des deutschen Forschungsministeriums erstellte Studie kam zum Ergebnis: Für Software-Dienstleister ist Qualität ein Fremdwort, und so ist es heute noch:

  • Im Früjahr 2013 bestätigt ein SAP-Team diese Einschätzung ganz unfreiwillig im wirklich übelsten Sinne des Wortes: durch Auslieferung einer absolut unbrauchbaren Neuimplementierung des Payroll Systems der kalifornischen Behörden auf der SAP Plattform (siehe [1], kürzer [CW]).
     
  • Ähnliches war einige Monate früher IBM passiert (siehe [2]). Diesem Team misslang die Neuimplementierung eines Order Management Systems. Man streitet sich jetzt vor Gericht um einen zweistelligen Millionenbetrag.
     
  • Vorher schon hatte IBM in Australien Software abgeliefert, die unbrauchbar war: "The system, which was delivered 20 months after deadline and 300 per cent over budget, led to 70,000 staff in Queensland’s health system being underpaid, overpaid or not paid for months."
     
  • Leider sind das keineswegs die einzigen Beispiele für in den letzten Jahren komplett schiefgelaufene, wirklich große Software-Entwicklungsprojekte. Siehe auch Zahlen dazu, z.B. von 2010.
     
    Man muss sich ernsthaft fragen, ob gängige Software-Entwicklungsmethodik (insbesondere die neue, sog. agile) nicht ganz grundsätzlich nur für Projekte kleiner oder mittlerer Größenordnung funktioniert.

    Wie sonst nämlich wäre es erklärbar, dass man mit den heute zur Verfügung stehenden wunderbaren, kaum noch verbesserungsfähigen Entwick­lungs­werkzeugen an der Neuimplementierung von Anwendungen scheitert, die man vor 30-40 Jahren schon einmal – und damals doch durchaus erfolgreich – geschaffen hatte (!).

    Oder sind vielleicht die Einkäufer schuld, die davon ausgehen, dass der jeweils billigste Anbieter das Projekt schon stemmen werde? Wollen sie Qualität zum Nulltarif?

 

In 2010 schrieben Wissenschaftler der Carnegie Mellon University, die Software-Entwicklungsprozesse untersucht hatten: The software industry is the only modern high-tech industry that ignores quality until test.

Inzwischen aber zeigt sich noch Schlimmeres:

Selbst wirkungsvoller Test gelingt Software-Entwicklern nicht wirklich (siehe etwa [3], [4] und [5] sowie The Healthcare Go Live Debacle).

Wie wenig effektiv Tester bisher sind, spiegelt sich auch wider in Gartners Erkennt­nis: 40% of problems are found by end users.

Wie lange noch — so frage ich — werden Auftraggeber sich das gefallen lassen?

Und insbesondere: Wann endlich werden Software-Entwickler die Konstruktion von Qualität ebenso ernst nehmen, wie das Konstruieren der Software selbst?

Bisher ist das Streben nach Qualität auf Seiten der Entwickler selten mehr als ein Lippenbekenntnis.

Tatsache ist: Wo Termin und Budget eng werden, wird weniger getestet — mit oft schlimmen Folgen (immer für den Auftraggeber, nicht selten auch für den Auftrag­nehmer). Beide Vertragspartner sollten sich dessen bewusst sein und nicht ver­säumen, dem ganz entschieden zu begegnen: Auf jeden Fall weit effektiver als bisher zu beobachten.

Den oft jungen Entwicklern sei gesagt:

Zu glauben, dass sogenanntes agiles Vorgehen die früher übliche, peinlich genaue Dokumentation aller zu entwickelnden Funktionalität überflüssig macht, ist ein ganz gewaltiger Irrtum: Der Wille, praktisch alles, was man produziert, in jedem noch so unfertigen Zustand gerne dem Anwender zu zeigen (damit der sage, wo er was anders haben möchte), mag ja gut gemeint sein, ist aber einfach nur naiv, denn solches Vorgehen überfordert den Anwender – man schiebt ja so nur eigene Verantwortung auf ihn ab.

Kluge Kunden durchschauen das und akzeptieren es nicht.

Vorzugehen, wie im Agilen Manifest gefordert, kann nur gut sein für prototypische Entwicklung in sehr kleinen Teams. Viele der heutigen Entwickler wollen das nicht einsehen. Methodiker, die ihnen Einhalt gebieten, gibt es nicht mehr wirklich. Es fehlt wohl die Einsicht, dass sie zu bezahlen sehr gut angelegtes Geld wäre …

SCRUM-Verfechter, eine spezifische Subklasse der Agilisten, übersehen, dass sich mit täglichen Stand-up-Meetings nur Mikroprozesse steuern lassen — auf keinen Fall aber Großprojekte.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Gebhard Greiter  On June 26, 2013 at 4:24 pm

     
    Der Gerechtigkeit wegen sollte nicht unerwähnt bleiben, dass heute nicht nur die Qualität von Software absolut miese sein kann, sondern ganz grundsätzlch die Ergebnisse aller Großprojekte unakzeptabel sein werden, wenn die ersehnte Lösung in fahrlässiger Weise vor ihrer endgültigen Implementierung nicht richtig durchdacht wurde.

    Überzeugende Beispiele hierfür — solche, die den Auftraggebern finanzielle Verluste in 3-stelliger Millionenhöhe beschert haben — sind z.B.

    (1) Berlins neuer Flughafen (der der allzu miesen Leistung seiner Architekten wegen jetzt wohl teilweise abgebrochen und neu gebaut werden muss),

    (2) die Polizeisoftware Inpol-Neu, die Mehrkosten von fast 120 Millionen Euro verursachte und damit sechsmal so teuer wurde wie ursprünglich geplant,

    sowie (3) ein eben aufgegebenes Großprojekt der BBC, bei dem es um die Modernísierung einer Umgebung für Produktion und Archivierung von Rundfunk- und Fernsehsendungen ging.

    Die Komplexität unvermeidbarer Entwicklungs- und Migrationsprojekte scheint heute schneller zu zeigen als unsere Fähigkeit, solche Komplexität auch wirklich zu beherrschen bzw. beherrschar zu machen.

    Es wird Zeit, dieses Problem gezielt zu adressieren! — vor allem schon im Zuge der Ausbildung der Ingenieure.

     

  • Gebhard Greiter  On August 19, 2013 at 12:18 pm

    Ein ähnlicher Fall in München:

    Fujitsu sollte die gesamte EDV der städtischen Kliniken in München auf einen modernen Stand bringen. Doch das Projekt endete im Chaos.

    Mit welch dramatischer Lieblosigkeit und Inkompetenz das Fujitsu-Team zwei Jahre lang gearbeitet hat, beweist die Tatsache, dass es dem Kunden nach Rauswurf von Fujitsu gelang, in nur einem Jahr aus eigener Kraft eine heute als vorbildlich geltende, auch wirtschaftlich sehr günstige technische Lösung zu finden.
     

  • Gebhard Greiter  On August 25, 2013 at 10:03 am

     
    Verwunderlich bei den so dramatisch schief gelaufenen Migrationsprojekten in Queensland und California ist insbesondere, dass dort niemand auf die Idee gekommen war, vor Inbetriebnahme der neuen Systeme für wenigstens einen Monat die Gehaltsabrechnungen der Staatsbediensteten von beiden Systemen — dem alten wie dem neuen — parallel errechnen zu lassen und das Ergebnis miteinander zu vergleichen. Wäre das geschehen, müsste doch sofort aufgefallen sein, dass die jeweils neue Version dieser Payroll Systeme absolut unakzeptable Ergebnisse liefert. Im übrigen: Eine noch bessere Möglichkeit, die Korrektheit der Ergebnisse des neuen Systems in allen Details zu prüfen, kann man sich doch gar nicht wünschen.

    Von professionellem Vorgehen der Tester, der Testmanager sowie der für die Migration technisch Verantwortlichen kann hier also auf keinen Fall gesprochen werden (!).
     

  • Gebhard Greiter  On October 23, 2013 at 1:15 pm

     
    Selbst Präsident Obama haben inkompetente Software-Entwickler den Start seiner Gesundheitsreform vermasselt. Nach einem Bericht der Computerwoche vom 23.10.2013 gilt:

    Die Website, über die sich die Millionen Amerikaner seit 1. Okt. in eine Kranken­versicherung einschreiben sollen, “funktioniert nicht, wie sie soll” (so Obama). Andere bezeichnen sie als Fiasko, Desaster, als unglaubliche Peinlich­keit.

    Die große Mehrheit der Besucher der Seite erhält frustrierende Fehlermeldun­gen. Nur wenige konnten sich registrieren, noch weniger letztlich einen Vertrag ab­schlie­ßen. Und am Ende lieferte die Seite falsche Daten an die Versicherungen.

    Das für gut eine halbe Milliarde Dollar (etwa 350 Millionen Euro) von mehr als 50 privaten Firmen über Jahre entwickelte Regierungsportal HealthCare.gov muss nach Obamas Worten erst noch repariert werden.
     

  • Gebhard Greiter  On January 14, 2014 at 3:38 pm

     
    Panorama Consulting vergleicht seit einigen Jahren die Business-Anwendungen der drei großen Softwareanbieter SAP, Oracle und Microsoft.

    Hierbei wurde festgestellt (nach Computerwoche, Jan 2014):

    Unter dem Strich beurteilen die Oracle-Kunden ihre ERP-Implementierungen am ehesten als Erfolg (71%), gefolgt von den MS Dynamics-Anwendern (67%) und den SAP-Kunden (62%).

    Obgleich jedes dritte Vorhaben im Nachhinein eher als Misserfolg eingestuft wurde, äußerten sich die Analysten von Panorama Consulting erstaunt über die hohe Zahl derer, die ihr ERP-Vorhaben grundsätzlich als Erfolg einordneten.

    FRAGE also: Gilt ein 2/3-Erfolg heute schon als Erfolg?
     

  • Gebhard Greiter  On March 2, 2014 at 11:30 am

     
    Selbst in aktuellen Fachbüchern über Software Engineering wird dieser traurige Zustand angesprochen — wenn auch nicht wirklich beklagt. So etwa schreiben Tsui, Karam & Bernal in der erst 2014 erschienen neuesten Ausgabe ihres Standard­werks Essentials of Software Engineering auf Seite 6 wörtlich:

    » Its always a good idea to test a program, both while it is developed, and after it is completed. This may sound like obvious advice, but it is not always followed. «

    Wo also bleibt die Professionalität der Software-Entwickler? Und warum lässt man ihnen so ein Verhalten durchgehen?
     

  • Gebhard Greiter  On July 22, 2014 at 3:32 pm

     
    Man darf darauf gespannt sein, wie sich unter solchen Umständen das Mammut­projekt Magellan der Deutschen Bank — welches Umstellung auf SAP zum Ziel hat — entwickeln wird.

    Erste Schwierigkeiten könnte es im Zusammenhang damit ja schon ge­geben haben (was die Bank allerdings bestreitet – sie schweigt zu den Ursachen eines Fehlverhaltens ihrer Systeme, welches mehreren Kunden zum Quartalsabschluss 1/2014 ein sattes, aber völlig unberechtigtes Minus auf ihrem Konto beschert hatte: siehe FAZ-Bericht IT-Panne bei der Deutschen Bank).

    Nebenbei: Die interne Ampel für das Teilprojekt Projekt “Stride”, so wird berichtet, steht im Mai 2014 auf Orange (d.h. auf » kaum Fortschritt «). Der ursprünglich für 2013 geplante Abschluss des Projekts wird nun erst 2015 erwartet.
     
    Mehr — aber durchaus auch Positives — zu Magellan findet man in [1] und [2].
    Mit einem geplanten Gesamtaufwand von rund 1 Mrd. EUR (über 4 Jahre hinweg) ist dieses Projekt derzeit sicher eines der weltweit größten Migrationsprojekte überhaupt.

    Erfahrungen, die man mit ihm sammelt, dürften wegweisenden Charakter haben. Sie werden zeigen, wie real die in [3] vermutete Gefahr tatsächlich ist.
     

  • Gebhard Greiter  On August 28, 2014 at 2:44 pm

     
    R. Goatham – Calleam Consulting Ltd. – wrote in 2009:

    If the failure rates experienced in the IT sector were replicated in civil engi­neering projects our cities would be littered with abandoned construction projects, the electrical supply to our homes would work intermittently and many of our bridges would have gaping holes that would routinely swallow vehicles brave enough to attempt a crossing.

    Source: The Story Behind the High Failure Rates in the IT Sector

    Aber Goatham beklagt nicht nur die Situation, er erklärt auch, wo die Wurzeln des Problems liegen …
     

  • Gebhard Greiter  On January 14, 2015 at 2:42 pm

     
    Sicher sollte man nicht alles glauben, was Hersteller von Testwerkzeugen an Aussagen über fehlende Software-Qualität so in die Welt setzen.

    Dennoch: Das Problem dürfte gewaltig sein, wenn auch nur die Hälfte von dem zutrifft, was eine 2013 durch Parasoft durchgeführte Studie ergeben haben soll. Leider wird uns nicht mitgeteilt, wie die befragten Unternehmen aus­gewählt wurden und wie repräsentativ die Auswahl denn eigentlich war:

    Siehe Parasofts Aussagen aus 2013.
     

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: