Erstklassige Ergebnisse entstehen nicht zufällig, sondern durch professionelles Vorgehen. Deshalb gilt es, den Prozess der Softwareerstellung ähnlich gezielt anzugehen, wie es in der mechanischen Konstruktion schon seit Jahrzehnten der Fall ist.
Damit überhaupt Raum für eine derartige Vorgehensweise in der Softwareentwicklung ist, muss der Kunde zunächst einmal an das Thema herangeführt werden. Dies ist ein essentieller Schritt, da auf Kundenseite sehr häufig die Einstellung zu finden ist: "Ich kaufe eine Maschine, was interessiert mich die Software?". In der Regel fällt dieser Schritt leicht, wenn sich der Maschinenhersteller klarmacht, dass und wie sich der Einsatz innovativer Anwendungen in Mark und Pfennig rechnen lässt.
Unverständnis und verkrustete StrukturenDieser an und für sich trivial erscheinende Ansatz ist in Maschinenbauunternehmen meist gar nicht so einfach umzusetzen. Dazu müssten sich nämlich die Mitarbeiter aus Marketing, Vertrieb und Entwicklung zusammensetzen und darüber klar werden, was der Kunde eigentlich wünscht, wo Einsparpotenziale liegen und was technisch möglich ist. So reden vertriebliche und technische Unternehmensteile häufig aneinander vorbei, und man beklagt sich über die jeweils andere Seite: "Die haben ja gar keine Ahnung, was am Markt abgeht" oder: "Bei dem geringen technischen Verständnis ist es ja klar, dass die dem Kunden nichts anbieten können."
Wie in anderen Bereichen des täglichen Lebens, die durch gegenseitiges Unverständnis und verkrustete Verhaltensstrukturen gekennzeichnet sind, sollte man auch hier neutrale Vermittler einsetzen, um die Kommunikation wieder in Gang zu bringen. Doch muss der Moderator, soll er ernst genommen werden, neben sozialen Fähigkeiten einen soliden technischen Background vorweisen können. Konkret bedeutet dieser Ansatz, dass - am besten abseits vom hektischen Tagesgeschäft - Vertrieb und Technik in einem gemeinsamen Workshop erarbeiten, mit welchen (Software-) Funktionen der Kundennutzen gesteigert werden kann.
Sobald geklärt ist, mit welchen Funktionen eine Maschine ausgestattet werden soll, geht es tiefer in die Technik hinein. Dann steht die Systemspezifikation auf der Tagesordnung. Die Bestimmung und Fixierung der Anforderungen an eine Maschine oder Anlage stellen viele Unternehmen vor eine sehr schwierige, weil ungewohnte Aufgabe.
Deshalb wurde in einem Arbeitskreis des Verbands Deutscher Maschinen- und Anlagenbau (VDMA) innerhalb des Fachverbandes Software daran gearbeitet, geeignete Methoden, Verfahren und Hilfsmittel bereitzustellen. Ergebnis dieser Arbeiten ist ein Leitfaden zur Erstellung einer Systemspezifikation, der vom VDMA-Verlag vertrieben wird. (Zu diesem Thema findet am 26. April 2001 um 10 Uhr auf der Hannovermesse auf Stand H35 in Halle 14/15 ein Vortrag statt.)
Der Leitfaden ist Gerüst und Anleitung zum Verfassen von Spezifikationen kompletter Systeme. Ein System im Sinne des Maschinenbaus umfasst auch die Hardware, legt aber einen besonderen Fokus auf den Softwareanteil. Zweck der Systemspezifikation sind die Klärung und Fixierung derjenigen Anforderungen, die sowohl dem Kunden als auch dem Auftragnehmer Klarheit über den zu realisierenden Umfang geben.
Die Systemspezifikation gliedert sich in die vier Kapitel Einführung, Systembeschreibung, Rahmenbedingungen und externe Schnittstellen. Wie die Erfahrung zeigt, wird in den Unternehmen häufig der Fehler gemacht, speziell die übergeordneten - oftmals als bekannt vorausgesetzten - Informationen über Struktur und Aufbau des Systems nicht zu beschreiben. Auf diese Weise soll Zeit gespart werden. Dabei wird leicht übersehen, dass die Gefahr von Missverständnissen zwischen Kunden und Lieferanten speziell in den frühen Phasen des Projekts besonders groß ist und deren Aufklärung dann besonders teuer kommt.
Innerhalb oder außerhalb der Systemgrenzen?Das Einführungskapitel sollte nur wenige Seiten umfassen. Erfahrungsgemäß ist es hilfreich, das Foto einer bereits existierenden ähnlichen Anlage einzubauen, um dem Leser einen ersten Eindruck davon zu vermitteln, was er erwarten kann. Des Weiteren empfiehlt es sich, eine Prinzipzeichnung (Systembild) zu erstellen, in der die wichtigsten Komponenten schematisch dargestellt sind. Dadurch wird klar, welche Komponenten sich innerhalb oder außerhalb der Systemgrenzen befinden. Diese an sich triviale Information ist sehr hilfreich. Oft ist nämlich zu beobachten, dass sich Kunde und Lieferant insbesondere in großen Projekten uneins sind, was nun noch Bestandteil des Projekts ist.
Zudem zeigt das Systembild, welche Schnittstellen nach außen vorliegen. Diese Anforderungen werden häufig erst sehr spät festgelegt und erzeugen damit - speziell wenn die Anforderungen in einer späten Projektphase geäußert werden - hohe Kosten, da zusätzliche (Software-)Schnittstellen nicht selten Einfluss auf das Systemdesign haben.
Zu beachten ist, dass im Strukturbild nicht nach Software und Hardware unterschieden wird. Als Faustformel kann gelten: In diesem Übersichtsbild sind die wesentlichen Prozessschritte darzustellen, die in einer Maschine ablaufen und meist auch einzelnen Komponenten zugeordnet werden können. Dabei sollten innerhalb der Systemgrenze nicht mehr als ungefähr sieben "Kästchen" enthalten sein - sonst geht der Überblick verloren.
Keine detaillierten Pläne für ProjektverläufeDamit die spezifizierten Anforderungen auch richtig umgesetzt werden, müssen Techniken des Projekt-Managements angewendet werden - ein Thema, das psychologisch außerordentlich sensibel ist. Ähnlich wie beim Thema Autofahren glaubt jeder von sich, ein guter Projekt-Manager zu sein.
Wer jedoch meint, mit diesen Kenntnissen das Projekt durchziehen zu können, der irrt. Denn die Entwicklung von modernen Maschinen erfordert ein hohes Maß an interdisziplinärem Arbeiten. Anders als in den reinen Konstruktionsprojekten früherer Zeiten, überblickt heute in der Praxis keine einzelne Person mehr die Vielfalt der unterschiedlichen technischen Problemstellungen. Deshalb muss der Projektleiter von Anfang an versuchen, die unterschiedlichen Fachdisziplinen zur Kommunikation anzuregen. Nur dann gelingt es, einen tragfähigen Plan zu erstellen.
Meist ist dies aber der Knackpunkt: Ähnlich wie beim Thema Autofahren glaubt jeder von sich, sein Metier zu beherrschen, in diesem Fall also ein guter Projekt-Manager zu sein.
In schätzungsweise der Hälfte aller Fälle wird selbst für große Entwicklungsprojekte kein detaillierter Plan für den Verlauf des Projekts erstellt. Meist stehen nur der Endtermin und das verfügbare Budget fest. Unklar bleibt hingegen, in welche einzelne Phasen sich das Projekt gliedert, welches die einzelnen Phasenergebnisse sein sollen, wie überprüft werden soll, dass diese Phasenergebnisse erreicht wurden, und was getan wird, wenn die Zwischenergebnisse nicht erreicht werden.
Um den zeitlichen Verlauf sinnvoll zu gliedern, helfen folgende Faustformeln: Zur Beschreibung der Anforderungen in Form beispielsweise eines Lastenheftes sollten mindestens 15 Prozent der Zeit eingerechnet werden, zur Beschreibung der Umsetzung, also des Pflichtenhefts, zirka 20 Prozent. Für die eigentliche Erstellung sind rund 40 Prozent zu veranschlagen, und der Test, die Inbetriebnahme und die Abnahme nehmen erfahrungsgemäß 25 Prozent der Gesamtzeit in Anspruch.
Das tägliche Leben zeigt, dass zuerst Denken und dann Handeln erfolgreich ist - in der Regel. Doch keine Regel ohne Ausnahmen: Trotz dieser Binsenweisheit werden oftmals statt der empfohlenen 40 Prozent zur Festlegung von Anforderung und Entwurf nur weniger als zehn Prozent investiert. Dieses Vorgehen lässt sich wie folgt auf den Punkt bringen: "Wir wissen zwar noch nicht genau, was wir tun sollen, aber wir haben wenig Zeit, deshalb lass uns schon mal anfangen." Die Auswirkungen einer derartigen Grundeinstellung schlagen massiv zu Buche: in Form von Verzögerungen, Qualitätsmängeln und Kostenüberschreitungen.
Ordnung und Übersicht unverzichtbarSind die wesentlichen Eckpfeiler - Lasten und Pflichten - niedergelegt, sind das Entwicklungsteam zu verstärken und der Entwurf detaillierter auszuarbeiten. Idealerweiser wird die Zusammensetzung des Entwicklerteams während des Umsetzungszeitraums nicht mehr verändert. Anschließend werden bei Bedarf zusätzliche Kräfte hinzugezogen. In der Test- und Inbetriebnahmephase ist in der Regel die Zahl der Personen, die am Projekt beteiligt sind, am größten. Spätestens zu diesem Zeitpunkt sollte spezielles Personal, das mit den Themen Test und Qualitätssicherung vertraut ist, hinzugezogen werden.
Ein weiterer Faktor kommt hinzu: Niemand sollte Softwareerstellung mit "free climbing", also einer umstrukturierten Vorgehensweise ohne ausreichende Sicherung, verwechseln. Trotzdem kommt es häufig vor, dass Entwickler sowie Verantwortliche nicht bereit sind, so viel Zeit, Geld und Energie zu investieren, wie erforderlich wäre, um Ordnung und Übersicht in den Entwicklungsablauf zu bringen.
Welche sind die Grundlagen, um vom free climbing zu einem strukturierten, nachvollziehbaren Prozess zu kommen? Damit das Klettern sicherer wird, verwendet man üblicherweise ein Seil, teilt die Gesamtroute in einzelne Stücke auf und schlägt an günstigen Stellen Sicherungshaken in die Wand. Im übertragenen Sinne funktioniert das in der Software ähnlich: Das Seil, an dem entlang man sich nach oben hangelt, besteht aus einzelnen Software-"Fasern". Die Festigkeit des Seils wird dabei maßgeblich durch die Struktur und Anordnung bestimmt, in der die einzelnen Fasern miteinander verbunden sind. Werden die Fasern wirr und unstrukturiert angeordnet, sind die Festigkeitswerte wesentlich schlechter, als wenn die Fasern wohl geordnet sind. Abstürze sind damit - im wahrsten Sinne des Wortes - programmiert.
Zur Verwaltung der Strukturen, Anordnungen und Konfigurationen von Software-"Fasern" setzen Profis ein Konfigurations-Management-System ein. Ein derartiges SW-System verwaltet alle Elemente, aus denen sich die Software zusammensetzt. Pro Element wird vermerkt, wann es erstellt wurde, was geändert worden ist und wer dafür verantwortlich ist.
Konfigurations-Management von ProfisDas Software-"Seil" wird in der Regel von mehreren Personen parallel bearbeitet. Es muss verhindert werden, dass die Entwickler sich gegenseitig die Ergebnisse zerstören. Ähnlich wie in einer Bibliothek ist deshalb ein Ausleihwesen zu installieren.
Damit im Softwaredschungel der Überblick nicht verloren geht, ist neben der Verwaltungsfunktion eine Administrierung von Gesamtversionen erforderlich. Mit Hilfe dieser Funktion werden Entwicklungsstände eingefroren. Zusammen mit einem derartigen Stand sollten auch andere Dokumente wie die zugehörigen Spezifikationen, Testunterlagen und Benutzerdokumentationen aufbewahrt werden. Wenn sämtliche zu einer Version gehörenden Informationen eindeutig und nachvollziehbar abgespeichert werden, versinnbildlicht dies, dass Sicherungshaken in die Wand geschlagen werden.
Für den Fall, dass zu einem späteren Zeitpunkt Probleme mit einer dem Kunden gelieferten Version auftreten, kann die Ursachenforschung von diesen stabilen "Sicherungshaken" aus starten. Werden derartige Haken hingegen nicht gesetzt, "fällt" man sehr tief, da hier viel Energie in die Rekonstruktion derjenigen Umstände gesteckt werden muss.
*Dr. Rainer Stetter ist Maschinenbau-Ingenieur und Geschäftsführer der ITQ GmbH und der Software Factory GmbH.
Abb.1: Verteilung der Produktanteile
Anteil des Entwicklungsaufwands im Maschinen- und Anlagenbau. Quelle: VDMA
Abb.2: Hauptlast auf Entwickler
Einsatz der Kapazitäten im Verlauf von Softwareprojekten. Quelle: VDMA