20070506d dmc Wohldefinierte Entwicklungsprozesse Softwarestandards

s war einmal ein Industriekönig, der wollte bei der Entwicklung seiner Software alles richtig machen. Er holte sich viele gelehrte Berater aus fernen Ländern in sein Schloss, die ihm in langen Jahren halfen, seine Software-Entwicklungsprozesse wohl zu definieren und zu beschreiben. Und es gab auch große Abteilungen in seinem Schloss, deren einzige Aufgabe es war, Strategien zu finden, wie Software richtig, mit guten Antwortzeiten und pflegeleicht zu entwickeln sei, und weitere Abteilungen, die nichts anderes zu tun hatten, als dafür zu sorgen, dass alle Werkzeuge und Entwicklungsschritte im Unternehmen korrekt und in der richtigen Reihenfolge angewendet würden, oder aber sich um die Kosten und die Effizienz der eingesetzten Partner zu kümmern und ihre Zertifizierung durchzusetzen, auf dass jeder, der im Unternehmen mit tun wollte, auch ein Zertifikat haben möge.

Doch die Projektleiter mussten alsbald erkennen, dass sie wie in den Zeiten vor der Einführung der Entwicklungsstandards um Qualität und Termine kämpfen mussten, ja dass sich die Situation sogar verschlechtert hatte, da nun viele formale Fehler zu den technischen und inhaltlichen hinzukamen. Und so begab es sich, dass niemand im Schloss des Industriekönigs die Entwicklungsstandards und die Abteilungen, die sie forderten und überwachten, wirklich liebte oder auf sie hören wollte.

Als nun der Industriekönig eines Tages ein großes Projekt startete, um die nächste Generation einer im Hause vorhandene Software, die nämlich in den Zeiten vor der Einführung von Standards entwickelt worden war, zu realisieren, verzichtete man, um schneller zum Ziel zu gelangen, auf die Rücksichtnahme auf Antwortzeiten, Stabilität, Korrektheit oder gar Funktionalitäten, wie die Endanwender sie immer so gerne fordern, und setzte zudem Entwickler ein, die es nicht gewohnt waren, Qualitätssicherung als Teil ihrer Arbeit zu sehen. Und man verzichtete darauf, Testdaten für die Entwicklung in ausreichendem Umfang bereitzustellen oder gar zu fordern, dass diese zur Modulabnahme auch verwendet würden. Und auch von den Tests, die sonst immer sicherstellten, dass ein Programm ohne Fehl und Tadel sei, wollte man nichts wissen.

Und so kam es, dass das neue Anwendungssystem, von Programmierern aus aller Herren Länder geschrieben, vor Fehlern und Mängeln strotzte und vielfältigste Abstürze und Fehlermeldungen den Pfad derjenigen Tester und Anwender markierten, die das neue System zu nutzen wagten und dabei nach links oder rechts blickten. Die Monate gingen ins Land und die Software lief von Tag zu Tag, von Woche zu Woche schlechter und den Programmierern gelang es trotz unendlicher Bemühungen nicht, Mängel und Fehler zu beseitigen. In wöchentlichen Präsentationen wurde den Fachabteilungen vorgeführt, welchen Entwicklungsstand man habe, und arbeitete am Ende fast nur noch für diese Termine und für die Statistik der behobenen Fehler.

Doch jeder Fehler der behoben wurde, führte zu zwei neuen. Und es schien bisweilen, als würden die Beteiligten nicht nach »Lines of Code«, sondern nach der Anzahl der Fehler im System vergütet, denn letztere stieg ins schier Unermessliche... Und so kam es, dass trotz aller Mühe eines schönen Tages das Projekt gestoppt wurde und alle, die daran gearbeitet hatten, auch diejenigen, die keine oder wenige Fehler gemacht hatten, in den verlängerten Urlaub geschickt wurden.

Und die Moral von der Geschichte? Sie lautet: Egal welche Entwicklungsprozesse genutzt werden, die Wege der Tugend werden fast immer mit dem Argument verlassen, das funktioniere ohnehin nicht – was allzu oft auch stimmt. Und die Entwicklungsabteilungen sind oft die ersten, die sich noch vor der Fachabteilung auf die Suche nach Abkürzungen begeben, die noch weniger funktionieren. Die Sackgasse füllt sich, bis sie voll ist, und dann herrschen Panik und Chaos.

So warten die Unternehmensleitungen von Großunternehmen und Behörden bis heute vergeblich auf die göttliche Eingebung für den universellen Prozess, den Stein der Weisen und den stets korrekten Algorithmus der Softwareerstellung, den man mit Modellen zu beschwören sucht. Und die Erkenntnis, dass es Rezepte gibt wie Sand am Meer, aber jenes Verfahren, das immer von selbst funktionieren will, einfach nicht kommen will, die kommt fast immer, freilich stets zu spät und manchmal auch gar nicht.

So bleibt uns an dieser Stelle nur die Empfehlung, mit kleinen und einfachen Projekten zu beginnen, mit bewährten Entwicklungspartnern, die bereits erfolgreich gearbeitet haben, und mit einem Projektziel, das in wenigen Wochen oder Monaten erreichbar ist. Und Angebote auf Ausschreibungen nicht nur mit dem Auge des Einkaufs zu betrachten. Denn dann erkennt man zumindestens rechtzeitig, wenn etwas nicht stimmt, und läuft nicht kilometerweit ins systematische Nirwana des zu groß geratenen Software-Entwicklungsprojekts, das mit heutiger Managementtechnik schwer bis nicht beherrschbar ist.

Ein kleiner Schritt auf festem Boden in Richtung Ziel ist nämlich stets besser als ein großer, der ins Leere führt. Und viele kleine Schritte, gut getan, sind so gut wie ein großer.

Der Autor Michael Mittermüller ist Gruppenleiter Softwareentwicklung bei der DMC Datenverarbeitungs- und Management-Consulting GmbH mit Hauptsitz in München.

Unternehmensprofil

Der Münchner IT-Dienstleister DMC Datenverarbeitungs- und Management-Consulting GmbH entwickelt seit seiner Gründung im Jahre 1984 kundenspezifische Softwarelösungen auf Basis von Individualentwicklung und Standardsoftware. DMC berät, realisiert und betreut wettbewerbsdifferenzierende IT-Lösungen für große Unternehmen vor allem der Automotive-, Finanzdienstleistungs- und der ITK-Branche.

Das Märchen vom wohldefinierten Entwicklungsprozess und den Softwarestandards

Copyright © 2003-2012 ap Verlag GmbH