Die Einführung einer Software-Produktionsumgebung (SPU) kann - nicht über Nacht erfolgen. Um den enormen Aufwand an organisatorischer Anpassung und Schulung in den Griff zu bekommen, ist eine strategische Vorausplanung unbedingt erforderlich. Helmut Gomolzig* durchleuchtet den SW-Entwicklungsprozeß mit Blickrichtung auf die SPU.
"Software umfaßt alle für die betreffende DV-Anlage zur Verfügung gestellten Programme mit der zugehörigen Dokumentation." Diese Definition der International Organization for Standardization (ISO) macht deutlich, daß Software nicht nur aus Programmen besteht, sondern auch aus der für die Entwicklung, die Pflege und die Bedienung der Programme so überaus wichtigen Dokumentation. Software, also Programme und Dokumentation, entsteht heutzutage in der Regel nach standardisierten Verfahren (Software-Engineering) als ingenieurmäßig entwickeltes und gewartetes Produkt nach wirtschaftlichen Gesichtspunkten in einer industriellen Umgebung.
Im Rahmen der Systementwicklung wird jedoch nicht nur die Dokumentation der Software erstellt. Es entsteht auch die Dokumentation. darüber, zu welchem betrieblichen Zweck die Software produziert wird, also welche betriebswirtschaftliche Funktion damit erfüllt wird (Systemdokumentation) und wie, das heißt in welchen Schritten, das neue System erstellt wurde (Projektdokumentation). Daraus läßt sich erkennen, daß im Bereich der Dokumentation wiederum zwischen produktspezifischer und projektspezifischer Dokumentation zu unterscheiden ist.
Diese Trennung wird auch dadurch unterstrichen, daß ein Produkt seinen Erstellungsprozeß gewöhnlich längere Zeit überlebt, jedoch in bestimmter Weise gepflegt werden muß. Diese Pflege oder Wartung bezieht sich meist auf einen bestimmten Einzelteil des gesamten Produktes und es ist daher wichtig, alle Einzelteile des Endproduktes zu kennen, das heißt entsprechende Dokumentation zu haben.
Das Ziel eines Systementwicklungsprozesses oder eines Wartungsprozesses ist im allgemeinen die definierte Überführung eines konsistenten Zustandes des Unternehmens in einen neuen konsistenten Zustand. Das Produkt ist also ein neuer organisatorischer und technischer beziehungsweise softwaretechnischer Zustand. Software ist damit ein Teilprodukt eines derartigen Vorganges:
Projektprodukt
Teilprodukt Organisation
- organisatorische Dokumentation - Betriebswirtschaft
Teilprodukt Software
- technische Dokumentation
- Bedienungsdokumentation
- Programme
Teilprodukt Projektdokumentation
Die Qualität eines Softwareproduktes ist abhängig von der Güte des Erstellungsprozesses beziehungsweise von der Güte der erforderlichen Zwischenprodukte (Zwischenergebnisse) des Erstellungsprozesses. Qualität läßt sich messen. Dies gilt auch für alle Zwischenergebnisse des Erstellungsprozesses. Vorausgesetzt wird jedoch eine gleichartige und damit meßbare Erstellung der Zwischen- und Endprodukte sowohl was den Erstellungsvorgang betrifft als auch was das Ergebnis selbst betrifft.
Die Vergleichbarkeit von Ergebnissen der Systementwicklung hat darüber hinaus den Vorteil, daß man bereits beschriebene Zwischenprodukte erkennt - möglicherweise aus anderen Projekten - und daß man bei vorhandener Definition der Standards und deren Automatisierung in der Prüfung echte Qualitätssteigerung bei gleichzeitiger Erhöhung der Produktivität erreichen kann.
Um derartige Vorteile zu erreichen, benutzt man zunehmend maschinell abgebildete Vorgehensmodelle, Phasenkonzepte oder ähnliches. In ihnen ist der Systementwicklungsvorgang als Standardnetzplan enthalten, wobei möglicherweise mehrere unterschiedliche Varianten vorhanden sind (Projektmuster). Neben der Beschreibung der Verrichtungen (Aktivitäten) ist die Beschreibung der zu produzierenden Ergebnisse (Ergebnistypen) enthalten und es werden jene Ergebnisse genannt, die als Voraussetzung (Zwischenprodukte) zur Durchführung der Verrichtung erforderlich sind.
Zur verläßlichen Einhaltung der Standards wird bei jeder Verrichtung ein Hinweis auf die relevanten Regelungen, Normen, Standards, Konventionen gegeben, aber auch darauf hingewiesen, welche Methode oder Technik beziehungsweise welches Werkzeug zu verwenden ist. Dies ermöglicht die konsequente Nutzung selbst größter Regelwerke. Im DV-Bereich sind dies die Org./DV-Handbücher. Die Größenordnung, die fehlende Aktualität und die mangelnde Transparenz derartiger Werke verhindern erfolgreich den breiten Einsatz. Auch dafür ist eine maschinelle Abbildung erforderlich. Dies erhöht in Verbindung mit dem Vorgehensmodell die Transparenz und Akzeptanz; auch werden Pflege und Erweiterung erleichtert.
Vorgehensmodell und Richtlinien sind sowohl für den Bereich der Entwicklung und Wartung, als auch für den Bereich des Projektmanagements von gleich hoher Bedeutung. Darüber hinaus spielen die jeweiligen Zwischenprodukte und Endprodukte des Erstellungsvorganges für das Projektmanagement eine entscheidende Rolle.
Vorgehensmodelle (Phasenkonzepte) sind primär für die Ersterstellung eines Produktes konzipiert. Bei der Ersterstellung stehen vor allem die Verrichtungen ("Was ist zu tun?") im Vordergrund. Das Produkt selbst ist vorläufig noch unbekannt und wird erst im Laufe des Erstellungsprozesses geformt.
Bei der Wartung hingegen steht plötzlich das Produkt beziehungsweise dessen Teile im Vordergrund. Die Fragen, die sich stellen, lauten: "Was ist betroffen?", "Woran ist zu arbeiten?", "Was ist davon abhängig?". Sind die einzelnen betroffenen Produktteile dann ermittelt, müssen die Verrichtungen festgelegt werden, die an den Produktteilen (Änderungsobjekten) vorzunehmen sind.
Prinzipiell sind die Verrichtungen der Wartung (Phase Wartung) die gleichen wie die Verrichtungen der Entwicklung, wenn man spezielle Aktivitäten wie Schadensanalyse, -umgehung und -begrenzung nicht in Betracht zieht. Sie sind nur unterschiedlich relevant. Die Bedeutung hängt von der Art der Wartung beziehungsweise des Fehlers ab.
Liegt eine funktionale Störung vor, so ist auch ein Teil des Entwurfsprozesses zu wiederholen oder durchzuführen. Die Auswirkungen, die sich unter Umständen daraus ergeben, sind abhängig von der Komplexität oder Integriertheit des Verfahrens. Diese Folgeerscheinungen können sich auf die funktionale Seite erstrecken, aber auch die DV-Technik - die Software - nachhaltig beeinflussen.
Vorgehensmodell muß breites Spektrum abdecken
Liegt eine softwaretechnische Störung vor, so kann zum Beispiel im Falle einer Änderung eines Datenelementes eine Unmenge von Softwareteilen betroffen sein. Daraus resultiert in Extremfällen wiederum eine funktionale Auswirkung. Es ist daher erforderlich, schon bei der Ersterstellung jene Produktteile, die später der Pflege unterliegen, zu identifizieren, zu beschreiben und ihre Abhängigkeiten darzustellen (Dictionary). Bei der Abbildung des Vorgehensmodells ist dabei zu berücksichtigen, daß man bei jeder Verrichtung beziehungsweise bei jedem Ergebnistyp eine Aussage macht, welches Produkt, Zwischenprodukt oder Produktteil man erzeugt oder dokumentiert. Dies bedeutet, daß ständig der Kontext zwischen den Verrichtungen, die durchzuführen sind, und dem Produkt, das erstellt werden soll, gewährleistet sein muß.
Ersterstellung vermittelt klares Bild des Produktes
Diese Kontextwahrung während der gesamten Lebenszeit des Produktes erleichtert das Management von Softwareentwicklungsprojekten entscheidend. Bei der Ersterstellung ergibt sich ein klares Bild des künftigen Produktes aus den Verrichtungen. Im Rahmen der Wartung gilt es, eine klare Projektion der erforderlichen Pflegeverrichtungen an einem bestehenden Produkt zu erstellen.
Werkzeuge zur Software-Entwicklung werden schon lange verwendet und sind vor allem im Bereich der eigentlichen Realisierung nicht mehr wegzudenken. Ein Werkzeug unterstützt die Lösung eines klar abgegrenzten DV-Problems in Form eines Software-Hilfsmittels. Ein Beispiel für diese Kategorie von Hilfsmitteln sind Generatoren.
Eine höhere Form von Werkzeugen sind sogenannte Werkzeugkästen, die aus einer Anzahl von aufeinander abgestimmten Tools bestehen. Die Ergebnisse der einzelnen Werkzeuge können von anderen weiterverarbeitet werden. Eine Steigerung stellen Entwicklungssysteme dar. Sie sind im Prinzip Werkzeugkästen, die unter einem einheitlichen Prinzip entworfen wurden und mehrere Entwicklungsphasen abdecken.
Eine Software-Produktionsumgebung geht in ihrem Anspruch viel weiter: Der Begriff der Software-Produktionsumgebung (SPU) wird einerseits als Oberbegriff für Systeme verwendet, die bei der Systementwicklung Unterstützung geben, andererseits wird er in etwa so definiert: "Computergestützte Einrichtungen für die ingenieurmäßige Entwicklung von Software, mit denen Entwickler mit unterschiedlichen Aufgaben in einem durchgängig organisierten Arbeitsprozeß zusammenarbeiten." Dabei werden Hilfsmittel (Methoden, Techniken, Werkzeuge) verwendet, die auf die Bearbeitung einzelner Arbeitsschritte abgestimmt sind.
Rückgriff auf vorhandene Komponenten ist ratsam
Eine SPU umfaßt das organisatorische Umfeld, die erforderlichen Softwarewerkzeuge inklusive der Trägersoftware der SPU selbst sowie die erforderliche beziehungsweise vorhandene Hardware. Um die Kosten einer Neuentwicklung zu reduzieren, sollte man bei der Schaffung einer SPU auf vorhandene Komponenten möglichst zurückgreifen. Dies setzt eine technisch offene Grundkonzeption voraus (Meta-SPU), die unternehmensspezifisch konfiguriert und weiterentwickelt werden kann. Nur so kann den Entwicklungen auf dem Markt oder im eigenen Unternehmen Rechnung getragen werden.
Die Rationalisierung der Anwendungsentwicklung fordert den Einsatz moderner Hilfsmittel. Die Verwendung unterschiedlicher Hilfsmittel von unterschiedlichen Herstellern führt ohne ein einigendes Gesamtkonzept in eine Sackgasse. Um eine solche negative Entwicklung zu vermeiden, empfiehlt sich die Erstellung einer integrierten Datenbasis zur Verbindung der Hilfsmittel.
Die Einführung einer Software-Produktionsumgebung beziehungsweise die Realisierung eines geschlossenen Systems kann nicht über Nacht geschehen. Es ist enormer Aufwand an organisatorischer Anpassung, Schulung der Methode und der Technik erforderlich. Die Einführung verteilt sich über einen Zeitraum von zwei bis fünf Jahren.
Angesichts der hohen Kosten für Entwicklung, Anschaffung oder Anpassung einer Software-Produktionsumgebung in das Unternehmen ist eine strategische Vorausplanung von großer Bedeutung. Diese Vorausplanung legt fest, nach welcher Vorgehensweise die Umgebung entwickelt beziehungsweise eingeführt wird. Darüber hinaus wird umrissen, welche Methoden, Techniken und Werkzeuge zur Anwendung gelangen sollen.
Prinzipiell lassen sich Entwicklungsstrategien und Einführungsstrategien unterscheiden.
Für beide Gruppen können folgende Ansätze festgestellt werden:
Trial and Error ist in der Entwicklung eher zu empfehlen als in der Einführung. Das Verfahren liefert brauchbare Insellösungen, integrierte Gesamtlösungen sind hingegen schwer erreichbar.
Bottom-up sollte bei der Entwicklung verwendet werden. Von der Fertigung oder Anschaffung einzelner Werkzeuge aus kommt man zu einem integrierten Werkzeugkonzept, dem dann ein Methodenkonzept unterlegt wird. Dieses wiederum läßt sich in ein Phasenkonzept einbetten (Checklisten zur Werkzeugeinführung). Die Einführung läuft ebenfalls in diesen Schritten ab.
Top-down eignet sich für die Entwicklung und Einführung. Von der Vorgabe eines Phasenkonzeptes aus wird unter Einbettung der gewünschten Methoden ein Werkzeugkonzept abgeleitet. Die einzelnen Werkzeugkomponenten lassen sich nach und nach entwickeln (Methodengesamtplanung).
Alle diese Ansätze haben ihre Vor- und Nachteile. Im Normalfall kommt es zu einer Mischung der Verfahren. Ergebnis ist ein Software-Projekt der gehobenen Mittelklasse, das auch so geplant und durchgeführt werden sollte.