Software Entwicklung
(Autor: Oliver Dorsch)
Die Notwendigkeit, Software- Entwicklung auf eine solidere Basis zu stellen, ist wohl nicht zu bestreiten. Noch viel zu sehr sind Qualität, funktionaler Umfang und Bedienbarkeit eines komplexeren Softwaresystems Ergebnisse eines mehr oder weniger zufälligen Prozesses.
Professionelle Software- Entwicklung?
graphic
So wie in dem Bild werden wohl viele Softwareprojekte "entwickelt" oder besser: durchlitten. Eine Mischung von Mode- Methoden, Querschüssen, kreativem und gewöhnlichem Chaos wird mit viel Aufwand und Motivation in Szene gesetzt, als Ergebnis soll eine wohlgeordnete, stabile und sichere Software entstehen. Ein Paradies vielleicht für Marketing- Künstler, die aus jedem Nichts ein einmaliges Etwas kreieren können und sich nicht festlegen müssen. Kein Paradies dagegen für die tapferen Frauen und Männer an den Tastaturen, die mit dem Ergebnis ein Unternehmen am Laufen halten sollen.
Es muß auch anders gehen.
Dieser Artikel verfolgt deshalb ganz einfach und bescheiden das Ziel, einen neuen Denkansatz zur professionellen, ingenieursmäßigen Erstellung von Softwareprodukten aufzuzeigen und zu verbreiten. Diesen Ansatz nennen wir 3RPC, das "3 requirements planning and controlling". Die Absicht dieser Methode ist es, bereits mit Beginn eines Projektes einen methodischen und systematischen Entwicklungsplan zu erstellen, der permanent überprüft und mit dem Projektverlauf abgeglichen wird.
Letzendliches Ziel ist die industrielle Revolution in der Software-Entwicklung!
Solche Ansätze kennen Sie bereits im Dutzend? Wir auch. Lassen Sie sich überraschen!
graphic
Zu viel Technik statt Verstand
Die hektische Entwicklung, Einführung und Ablösung der verschiedenen Paradigmen wie CASE, Prototyping, Objektorientierung, Komponententechnik samt den zugehörigen Tools zeigt eher das Problem als eine Lösung:
graphic Technische Mittel und Konzepte zur Unterstützung der menschlichen Denkarbeit und Entwicklungstätigkeit mutieren zu Selbstläufern. Anstelle, daß über das Ziel der Entwicklung nachgedacht wird, steht die Art und Weise des Entwicklungsprozesses als Nabelschau im Mittelpunkt. Die intellektuelle Leistung bezieht sich nicht mehr auf die Erstellung eines durchgängigen Ergebniskonzeptes, sondern auf den durchgängigen Einsatz eines Konzeptes. Somit wird der Weg zum Ziel, und das "wohin" ist irgendwie aus dem Blickwinkel gerückt.
Es liegt auf der Hand, daß ein solcher Denkansatz zu dem führt, was wir alle kennen: Überzogene Termine, überzogene Kosten, mangelnde oder fehlerhafte Funktionalität, schlechte Bedienbarkeit, schlechte Wartbarkeit.
graphic
Die Auswirkungen
Die großen Beratungshäuser mögen darüber streiten, wieviele Projekte ihre ursprünglichen Vorgaben bezüglich Zeit, Kosten, Funktionalität und Qualität verfehlen - sofern überhaupt vor Projektbeginn irgendwelche realistischen Vorgaben gemacht wurden.
Typischerweise sollen 30% bis 70% der Projekte mindestens eine ihrer Vorgaben nicht erfüllen - und vergessen wir dabei nicht, daß diese Branche Projekte häufig schon "erfolgreich" nennt, wenn sie nur überhaupt zum Laufen kommen und nicht völlig "gegen die Wand fahren"!
Natürlich entsprechen viele Projekte den Zielvorgaben nur deshalb nicht, weil eben keine konkreten Ziele gesetzt wurden. Im Nachhinein wollte dann der Anwender eigentlich alles anders. So kann man natürlich eine hohe Quote mangehafter Projekte künstlich generieren. Nur - warum wurde dieses Projekt eigentlich genehmigt?
Betrachten wir die notwendigen Investionen an Geld und Mannjahren, dann sind die Gründe für einen Projektversager und die genaue Quote eigentlich schon wieder egal, alleine schon die Größenordnung ist bereits erschreckend. Welche Summen werden hier zum Fenster hinausgeworfen, die doch an anderer Stelle sinnvoller und produktiver eingesetzt werden könnten!
graphic
Was geht schief?
Technische Hilfsmittel werden das Problem grundsätzlich nicht lösen, da sie nur steuern können, wie, aber nicht was entwickelt wird. Dieses "Was" verbleibt nach wie vor beim Menschen. Hier müssen wir folglich neue Denkansätze einführen, damit wir unsere Probleme an der Wurzel fassen und nicht dort, wo wir einfach nur leicht eingreifen können. Denn noch wird Software zu sehr als Handwerksarbeit betrieben, nicht aber als geplanter und gesteuerter Konstruktionsprozeß.
     Denk mal!
          ...vorher über das Ziel nach.
Wir benötigen also "etwas", anhand dessen der Entwickler, besser: die Entwicklergruppe, eine konzeptionell vollständige Projekt"spezifikation" erstellen kann. Dieses "etwas" muß zwingend dafür sorgen, daß die Entwicklergruppe bereits frühzeitig alle für das Projekt notwendigen Aspekte erkennt, bewertet und die entsprechenden Lösungen definiert. Und es muß dafür sorgen, daß die Anwenderanforderungen verbindlich und konkret ermittelt und festgeschrieben werden.
Ist dies geschehen, dann kann und muß die Realisierung dieser Spezifikationen wieder mit den bekannten und hoffentlich beherrschten Techniken wie CASE, ERM, Prozeß- oder OO- Modellierung erfolgen.
Ein solches "etwas" kann nur ein Denkmodell sein, untermauert mit klaren Verhaltensweisen und auch Checklisten. Der Einsatz dieses Denkmodells ist - wie kanns auch anders sein - vom Menschen abhängig.
Wir werden das Denkmodell im folgenden in mehreren Schritten entwickeln, mit denen wir bisherige Denkweisen analysieren und die resultierenden Fehler aufzeigen wollen. Daraus leiten wir ein neues Anforderungsprofil ab, aus dem sich das 3RPC-Konzept ergeben wird..
Wir wünschen Ihnen nachfolgend viel Vergnügen und viel Erfolg mit Ihrem nächsten Projekt!
Folgende Unterpunkte sind noch in Planung:
  • Anhänge
  • Checklisten
  •