… dann wird meist einfach durchgewurstelt bis zum bitteren Ende. Und die Letzten beissen die Hunde. Das sind die Tester, welche die zu prüfende Software regelmässig zu spät erhalten, aber trotzdem termingerecht fertig getestet abliefern müssen – einschliesslich der nötigen Korrekturen der Entwickler, versteht sich. Da aber die Erstellung des Prüflings mehr Zeit in Anspruch genommen hat als ursprünglich geplant war, steigt naturgemäss entsprechend auch der Testaufwand proportional, der sich bei finanztechnischer Individualsoftware üblicherweise in der gleichen Grössenordnung wie der Entwicklungsaufwand bewegt. Wenn gegen Ende der Entwicklungszeit die Liefertermine ohnehin schon überfällig sind, wird alles noch schnell-schnell codiert und dann ohne Vortests zur Sicherstellung der Lauffähigkeit und Grundfunktionalität durch den Entwickler an die Tester weitergereicht. Dadurch stecken dann noch mehr Fehler in der Software als wenn sie unter Einhaltung der Regeln der IT-Kunst erstellt worden wäre.

Die Gründe für den höheren Entwicklungsaufwand sind meist in den vorgelagerten Phasen zu suchen. Ungenaue, unklare und unvollständige Spezifikationen führen zu Fehlern und Mehraufwänden in den nachgelagerten Projektphasen. Entweder hat der Analyst die Sache selber nicht richtig analysiert und verstanden oder er ist nicht in der Lage, die Anforderungen so zu beschreiben, wie sie von den Entwicklern und Testern verstanden werden können und erwartet werden. Der Entwickler setzt die Modelle aus der Analyse in Programmcode um. Das ist Handwerk, das der Kreativität relativ wenig Freiheit lässt. Entsprechend sind die meisten Fehlerursachen auch nicht hier zu suchen.

Es gibt schon seit längerem Standards zur systematischen Beschreibung von Anforderungen und Modellen (z.B. die Unified Modeling Language UML), die aber in der Praxis oft nur pro forma eingehalten werden. Zum Beispiel mag ein Use Case (d.h. die Beschreibung eines Geschäftsanwendungsfalls) auf den ersten Blick aussehen wie einer, inhaltlich ist er aber nicht selten unvollständig und zu ungenau oder beschreibt nicht das, was er eigentlich sollte. Das kennen wir ja aus dem Alltag schon: aussen hui, innen pfui – aussen straffe Haut und volle Brüste, innen Silikon, abgesaugtes Fett und künstlich gelähmte Nervenzellen. Unvermögen mangels Ausbildung oder Unwille zur Kommunikation und Zusammenarbeit zwecks politischer Machtspiele, indem wichtige Informationen bewusst vorenthalten werden? Oder ganz einfach nur Schlamperei? Die Ursachen sind vielfältig. Das Resultat ist aber immer das selbe: Reibungsverluste, Mehraufwände, Terminverschiebungen und eine schlechte Qualität der Software. Und der CIO ist meist viel zu weit von der Materie entfernt, als dass er gezielt den Hebel ansetzen könnte, um die nötigen Veränderungen in der Arbeitskultur und bei den Prozessen zu initiieren und voran zu treiben. Von der Basis her sind solche Veränderungen unmöglich, weil sie einen starken Führer benötigen, der nicht bloss dahinter steht, sondern den Karren selber zieht.

Erst kürzlich las ich in einem Protokoll eines Projektstatus-Meetings (sinngemäss): „Die Situation wurde durch die Parallelisierung von Design und Codierung entschärft“. Das heisst im Klartext: mit der Umsetzung wurde schon begonnen, bevor klar war, was und wie es eigentlich realisiert werden sollte. In der Maschinenindustrie wäre so etwas kaum vorstellbar. Wenn das bloss wieder einmal gut geht …