Software ändert sich, aber unkontrollierte Änderungen bringen die Software-Entwicklung oft an den Rand des Chaos. Nur mit einem professionellen Software-Management lässt sich ein hoher Qualitätsstandard sichern. Dabei erstreckt sich die Steuerung und Kontrolle des Entwicklungsprozesses über alle Phasen des Software-Life-Cycle und reicht vom Versions- bis zum Prozess-Management. Wenn das Chaos auf Ordnung trifft, gewinnt das Chaos, weil es besser organisiert ist – und eine der wichtigsten Frontlinien im Ringen des Menschen mit dem Chaos verläuft mitten durch die IT-Welt, wo die Software-Entwickler mittlerweile seit Jahrzehnten heroisch gegen das Chaos ankämpfen. Oft vergeblich, denn manchmal scheint es, als habe Software, obwohl selbst eine hochgradig strukturierte und festen Regeln gehorchende Angelegenheit, eine immanente Tendenz „sich“ im Handumdrehen unkontrolliert neu zu organisieren.

Ein Phänomen, das jeder Entwickler kennt: Hier wird schnell mal ein Code-Teil angefügt, dort muss eine Ad-hoc-Änderung vorgenommen werden, woanders ein Objekt verbessert oder ein Modul durch ein besseres, funktionelleres, schnelleres, schöneres ersetzt werden. Tausend Veränderungen, die alle ganz schnell, ganz einfach, ohne viel Drumherum gemacht werden müssen – die berühmten „zwei Zeilen Code“, die man doch leicht mal nebenbei in zehn Minuten schreiben und in zwei Minuten einfügen kann. Das Ergebnis eines derartigen Vorgehens ist eine Organisationsform von Software, die auch jeder Entwickler kennt: undokumentierter Code, Programmteile, deren Funktionen keiner mehr so richtig kennt, Module, deren Zweck unbekannt ist, die man aber trotzdem nicht zu entfernen wagt, Anwendungen, die außer ihrem Schöpfer niemand mehr versteht, nicht definierte Schnittstellen, undurchsichtige Ablaufstrukturen, seltsame Calls, eigenartige Parameter, merkwürdige Verzweigungen, rätselhafte Objekte – mit anderen Worten: Chaos.

Das Chaos mag mitunter kreativ sein, aber seine Ergebnisse sind nicht vorhersagbar, und das ist keine gute Basis für Software. Die SW-Entwicklung hat sich daher neben ihrer eigentlichen Aufgabe, Software zu entwickeln, auf einer Meta-Ebene mittlerweile ein umfangreiches Instrumentarium zugelegt, mit dem sie das eigene Tun und Lassen zu steuern und zu kontrollieren versucht. Sie will damit die eigenen Prozesse in eine Organisationsform bringen, die den eigenen Ansprüchen an Qualität – und den Forderungen der Auftraggeber – gerecht wird.

Für das Management der Software-Entwicklung ist eine entsprechend qualitativ angepasste Organisation heute unerlässlich. Wobei die Qualitätsstandards nicht nach eigenem Gutdünken definiert werden dürfen, sondern sich zweckmäßigerweise an anerkannten Verfahren wie ISO, CMM oder CMII orientieren. Grundlegende Anforderung ist dabei immer, dass jede Aktion bei der Erstellung von Software nachvollziehbar und reproduzierbar sein muss, weil nur dann Aussagen über die Qualität des Prozesses möglich sind. Das führt direkt zu dem, was von vielen Entwicklern in der täglichen Praxis noch mehr gefürchtet wird als das Chaos: die zusätzliche Arbeit der Dokumentation.

Software-Entwicklung im Life-Cycle

Ein derartiges „dokumentierendes“ Management der Software-Entwicklung sollte freilich nicht nur punktuell bestimmte Aspekte des Entstehungsprozesses herausgreifen, beispielsweise die Codierung, sondern den gesamten Prozess, also den Software-Life-Cycle möglichst umfassend abdecken. Und in jeder Phase spielen die entsprechenden Dokumente eine zentrale Rolle.

Der Lebenszyklus einer Software beginnt normalerweise mit einem Wunsch des Anwenders, der in einer ersten Phase sachgerecht formuliert wird, so dass aus ihm eine Anforderung dargestellt werden kann. Diese Anforderung stellt das erste Dokument dar, das technisch relevant verwaltet wird. Als Nächstes werden daraus die entsprechenden Aktivitätsbeschreibungen abgeleitet, die aus dem reinen Wunsch langsam eine reale Software entstehen lassen.

Je nachdem wie umfangreich oder neu die Anforderung ist, beginnt der Bearbeitungsbereich mit einer entsprechenden Analyse der Problemstellung. An die Analysephase schließt sich das Design an, das entsprechend die Ergebnisse der Analyse in logische Strukturen umwandelt. Auf das Design folgt das Coding, sofern nicht der Code schon automatisch aus dem Designwerkzeug erzeugt wurde. Damit ist die Software entstanden und durchläuft nun den Testbereich, in dem geprüft wird, ob die entsprechenden Anforderungen erfüllt werden. Je nach der Unternehmensorganisation kann noch eine spezielle Phase der Qualitätssicherung folgen, während die nochmals qualitativen Ansprüche überprüft werden.

Schließlich wird die Software als fertig oder released gekennzeichnet; sie verlässt den Entwicklungsbereich und geht in den produktiven Einsatz. Dabei begleitet sie mitunter ein Software-Verteilungswerkzeug, vor allem wenn bei der Verteilung zu viele Wege zu gehen sind und das Umfeld entsprechend komplex ist.

Im produktiven Einsatz angekommen und in Dienst gestellt gilt es nun, den ursprünglichen Wunsch des Anwenders zu erfüllen. Ist dies der Fall, endet der Zyklus – vorerst, weil neue Wünsche neue Änderungen notwendig machen. Sind schon die ursprünglichen Anforderungen nicht erfüllt, müssen weitere Phasen eingeschaltet werden. Dies ist die Stunde der Änderungsanträge: Zeigt die Software beispielsweise fehlerhafte Informationen an, wird vom Anwender eine Fehlermeldung erzeugt und an den Hersteller/Entwickler geschickt, der die Behebung des Fehlers in Angriff nimmt. Mitunter erfüllt sie zwar die Anforderungen, der Anwender hat jedoch seinen Wunsch nicht richtig formuliert oder hat sich eigentlich eine etwas andere Funktionalität vorgestellt. In diesem Fall kommt es zu einem Änderungsantrag. Es können sich auch während der Entwicklung Umgebungsparameter geändert haben, die Änderungen in der Funktionalität notwendig machen. Es gibt viele Ursprünge für Änderungsanträge, aber alle haben gemeinsam, dass ein Eingriff in die fertige Software erforderlich wird.

Für ein einzelnes Objekt sieht dieser Lebenszyklus noch einigermaßen übersichtlich aus. Da moderne Programme einige tausend bis zehntausend Objekte umfassen, lässt sich leicht abschätzen, wie groß die Aufgabe ist, alle diese Objekte über alle Phasen zu steuern – wobei die Objekte ihre jeweiligen Phasen natürlich zu unterschiedlichen Zeiten durchlaufen. Die entsprechenden Dokumente, die unterschiedlichen Fehlermeldungen und Änderungsanträge müssen so organisiert und verwaltet werden, dass keines der Objekte übersehen oder sonstige Unstimmigkeiten in der Software erzeugt werden. Das Chaos ist hier nur ein paar Mausklicks und einige wenige Code-Zeilen entfernt.

Die Wartung der Software erfolgt in der modernen SW-Herstellung parallel zur normalen Weiterentwicklung, womit sich die Komplexität des Gesamtprozesses weiter erhöht. Wenn auch im Bereich der Anforderungen und der Produktion immer wieder Änderungen durchgereicht werden, so ist doch im zentralen Entwicklungsbereich die Anzahl der Änderungsanträge am höchsten. Vor allem in diesem Bereich wird deshalb die Organisation heute meist mittels entsprechender Werkzeuge wie Merants PVCS Dimension unterstützt, die dann dem Konfigurations-Management zuzuordnen sind (SCM steht für Software Configuration Management oder Software Change Management, nicht zu verwechseln mit Supply Chain Management).

Life-Cycle-Management und SCM

Für das Management des Software-Life-Cycle werden die verschiedenen SCM-Werkzeuge ihrerseits in einem eigenen Zyklus eingesetzt, denn ihre jeweiligen Funktionen bauen aufeinander auf und werden sukzessive absolviert. Die wichtigste Aufgabe bei der Steuerung des Software-Life-Cycle ist das Versionsmanagement, das die Archivierung der einzelnen Software-Objekte vornimmt. Diese ermöglicht, dass die Objekte zu jedem Zeitpunkt wiederherstellbar sind und dass auch auf ältere Versionen der Objekte zurückgegriffen werden kann. Das Versions-Management bildet den Grundstock für alle weiteren Funktionalitäten.

Im nächsten Schritt geht es darum, die Zusammenhänge innerhalb der Software zu dokumentieren und zu verwalten. Dies geschieht zum einen im Build-Management, das die notwendigen Objekte adressiert, wenn es um die Bildung ausführbarer Programme geht, zum anderen im Konfigurations-Management, das seinerseits auch alle sonstigen Objekte einbezieht, die zur einer Software gehören. Dies können beispielsweise Dokumente sein, die über die Funktionen der Software Auskunft geben, Bibliotheken, die entsprechende Standardkomponenten mitbringen, oder auch Bilder, Videos für Tutorials usw. Dabei können dann für verschiedene Bereiche unterschiedliche Konfigurationen notwendig sein. So wird vielleicht ein Entwickler nicht unbedingt die Tutorials in seiner Arbeitsumgebung haben wollen, dafür aber alle Sourcen und Bibliotheken. Im Gegenzug wird der Tester wiederum kein Interesse an den Sourcen haben, dafür aber die Übereinstimmung zwischen Tutorial und Software prüfen wollen.

Das Prozess-Management sorgt dafür, dass die Ergebnisse der Entwicklung zum Test und zu den anderen Bearbeitungsstufen weitergeführt werden. Diese Prozesse können natürlich je nach Unternehmen sehr unterschiedlich sein, teilweise sogar in den verschiedenen Projekten eines einzelnen Unternehmens. Die unterstützenden Werkzeuge müssen daher sehr flexibel reagieren können und auch für Notfallszenarien entsprechende Durchlaufmodelle vorsehen, wie die SCM-Werkzeuge von Merant, die den Anwender in die Lage versetzen, durch ein wohldurchdachtes System die komplexen Veränderungen in seinen Produkten in den Griff zu bekommen. Sind die eingesetzten Werkzeuge nicht flexibel, sondern versuchen den Änderungsprozess mit einem vordefinierten Modell festzuzurren, so ist die Wahrscheinlichkeit sehr groß, dass früher oder später das Werkzeug unterlaufen wird und dann nicht mehr als zuverlässige Referenz gelten kann. An dieser Stelle scheitern oftmals Projekte, die mit hohen Zielen angefangen haben, dann aber aufgrund dringender, kurzfristiger Eingriffe in den definierten Ablauf soviel Chaos verursachen, dass eine sinnvolle Weiterführung irgendwann nicht mehr möglich ist.

MERANT GmbH

D–85737 Ismaning

Telefon: (+49) 089/96271-0

www.merant.com