In der Praxis stößt man immer wieder auf das gleiche Konzepte Schwierigkeiten bei der Softwareproduktion sollen durch neue Werkzeuge aus der Welt Geschafft werden. Technikverliebte Systementwickler basteln an allumfassenden Softwareproduktions-Umgebungen (SPU), aber dem Anwendungsentwickler ist damit kaum geholfen. Eine SPU jedoch läßt sich auch evolutionär implementieren.
Je mächtiger das Tool, desto höher der Problemlösungsbeitrag - nach dieser Logik muß oft eine komplette Softwareproduktions-Umgebung die Lösung schlechthin liefern. Daß dem nicht so ist, erfahren viele Unternehmen, wenn sie immense Investitionen in den Sand gesetzt und sich damit nur noch größere Probleme eingehandelt haben. Dabei geht es durchaus auch anders. Aber was läßt sich nun tatsächlich evolutionär implementieren?
Eine Softwareproduktions-Umgebung besteht, wie bereits beschrieben, aus sieben wesentlichen Bausteinen: der grafischen Benutzeroberfläche, dem Monitor, dem Vorgehensmodell mit seinen Methoden, den phasenorientierten sowie den phasenübergreifenden Werkzeugen, der Infrastruktur und last, but not least dem Repository. Fast jede dieser Komponenten läßt sich sinnvoll auch schrittweise implementieren.
Grafische Benutzeroberflächen sind nicht nur ein wesentlicher Bestandteil von Softwareproduktions-Umgebungen. Sie werden sich zur Schnittstelle zum Anwender entwickeln sei es nun der Anwendungsentwickler, der Sachbearbeiter, der sich primär mit Bürokommunikation auseinandersetzt, oder der Nutzer jedweder produktiv eingesetzter Anwendungssoftware. Sie alle werden via grafischer Oberflächen mit dem Computer kommunizieren.
Dies bedeutet aber, daß schon heute, unabhängig von einer SPU, jedes Unternehmen eine grafische Standardoberfläche definieren sollte. Ein Konzept für grafische Benutzeroberflächen kann nicht nur, sondern muß geradezu unabhängig von der Entscheidung für den Einsatz der SPU getroffen werden. Denn nur eine unternehmensweit einheitliche grafische Benutzeroberfläche erlaubt es, die Produktivitätssteigerungen zu realisieren, die sich durch verminderten Einarbeitungsaufwand ergeben. Etablieren sich mehrere Oberflächen mit unterschiedlichem "Look and Feel", so wird ein Rationalisierungspotential verschenkt.
Erhebliche Fortschritte in Produktivität und Qualität
Auch ein Vorgehensmodell mit zeitgemäßen Software-Engineering-Methoden läßt sich ohne Einsatz einer kompletten SPU bereits frühzeitig implementieren. Der Großteil aller Probleme in der Anwendungsentwicklung der meisten Unternehmen ist weiterhin im mangelnden Projekt-Management und im unvollständigen Produkt-Management zu suchen. Ein Vorgehensmodell, das Ergebnisse, Meilensteine, Konfigurations-Management, Statuskonzepte und Qualitätssicherungsmaßnahmen bindend vorschreibt und tatsächlich benutzt wird, kann erhebliche Produktivitäts- und Qualitätsfortschritte realisieren.
Der Einkauf eines Vorgehensmodells im Rahmen einer SPU hat darüber hinaus beträchtliche Anpassungskosten zur Folge, denn jedes Unternehmen hat eine Historie, die nicht einfach beiseite geschoben werden kann, weshalb so manche Unternehmensspezifika in ein neues Vorgehensmodell eingearbeitet werden müssen. Die Einführung neuer Software-Engineering-Methoden ist allerdings nur im Zusammenhang mit Werkzeugen möglich, die diese Methoden auch unterstützen.
Bei den Werkzeugen muß zwischen den phasenorientierten und den phasenübergreifenden Tools unterschieden werden. Phasenorientierte Werkzeuge lassen sich einfacher nutzen als phasenübergreifende, auch ohne SPU. So können Tools, die zum Beispiel die "Strukturierte Analyse" oder "Entity Relationship Modeling" unterstützen, auch ohne SPU verwendet werden natürlich nur mit funktionalen Einschränkungen.
Beim Einsatz von Werkzeugen über alle Phasen der Software-Erstellung sollen möglichst alle Ergebnisse, die in frühen Phasen erzielt wurden, an die Werkzeuge der späteren Phasen weitergereicht werden. Dies ist mit einer homogenen Softwareproduktions-Umgebung über den ganzen Lifecycle natürlich weit eher gewährleistet als mit Stand-alone-Werkzeugen. Die evolutionäre Implementierung nimmt hier bewußt Medienbrüche, Inkonsistenzen und nicht realisierte Produktivitätsfortschritte in Kauf.
Einige Hersteller bieten allerdings Schnittstellen zu anderen Werkzeugen an (zum Beispiel IEW/CSP mit dem ESF-Format). Die Erfahrungen in der Praxis zeigen aber, daß diese Schnittstellen oft Probleme ausweisen; so sind sie beispielsweise zum Teil nur unidirektional.
Der Einsatz von phasenübergreifenden Werkzeugen ist ohne eine SPU mit noch größeren funktionalen Einschränkungen verbunden. Zum Beispiel kann ein Tool für das Konfigurations-Management eigentlich nicht ohne eine gemeinsame Datenbasis, wie sie jede SPU anbietet, eingesetzt werden
Andere phasenübergreifende Werkzeuge sind jedoch auch stand alone nutzbar. Beispielsweise kann ein Projekt-Management-Werkzeug auch ohne SPU eingesetzt werden - mit der funktionalen Einschränkung, daß dem Werkzeug alle Informationen manuell mitgegeben und diese dann redundant in dem Werkzeug gehalten werden müssen. Dies kann bei größeren Projekten zu einem erheblichen Aufwand führen.
Das Infrastruktur-Konzept (Rechner- und Netzarchitekturen) eines Unternehmens muß analog einem Konzept für grafische Benutzeroberflächen definiert werden. Auch die Infrastruktur sollte im Unternehmen möglichst homogen über die unterschiedlichen Einsatzgebiete der DV konzipiert sein. Entwicklungsrechner, Produktionsrechner, Bürokommunikations-Systeme und Arbeitsplatz-Rechner inklusive deren Vernetzung lassen sich nur als Ganzes betrachten.
Unternehmen haben heute große Kompatibilitätsprobleme, weil dieser Punkt in der Vergangenheit nicht ausreichend beachtet wurde. Gerade eine integrierte Verarbeitung verlangt zunehmend einen intensiven Informationsaustausch. Aus diesem Grund ist auch das Infrastrukturkonzept einer SPU nur im Zusammenhang mit der strategischen Infrastrukturplanung des Unternehmens zu sehen. Im Rahmen dieser Planungen können auch ohne SPU zum Beispiel Workstations sinnvoll als Arbeitsplatz-Rechner eingesetzt werden.
Einiges läßt sich evolutionär nicht machen
Auch wenn hier eine Reihe von Dingen Thema waren, die sich schrittweise in die Anwendungsentwicklung implementieren lassen, können einige wesentliche Bausteine einer SPU nicht evolutionär eingesetzt werden. So kann der Monitor seine Aufgabe, eine Kommunikation zwischen Werkzeugen, Vorgehensmodell und Repository herzustellen, natürlich nur erfüllen, wenn alle diese Bausteine verfügbar sind. Die durch den Monitor gewährleistete teilautomatisierte Konsistenz geht beim evolutionären Einsatz einer SPU zunächst einmal verloren.
Das Herzstück einer SPU, das Repository, ist theoretisch auch nur dann sinnvoll einzusetzen, wenn alle Werkzeuge mit dieser Komponente kommunizieren können. Hier muß allerdings hinzugefügt werden, daß dies eine sehr theoretische Forderung ist; denn die Kommunikationsmöglichkeit der Werkzeuge mit dem Repository ist eine notwendige, aber lange keine hinreichende Bedingung für ein konsistentes Konfigurations-Management.
Unternehmen sind in der Regel mit dem kompletten Einsatz einer SPU überfordert, da Ziel eines Repository nicht nur die reine Sammlung der Ergebnisse ist, sondern darüber hinausgehend auch die administrative Behandlung dieser Ergebnisse. Denn eins muß man sich vergegenwärtigen: Ein Repository ist nur so gut, wie die Ergebnisse, die in ihm abgelegt sind. In der Praxis bleiben damit Problemkreise wie zum Beispiel Homonyme und Synonyme bestehen. Diese sind nur über administrative Verfahren zu lösen, die die Unternehmen sowohl - aufbauwie ablauforganisatorisch implementiert haben müssen. Allein die Zusammenführung der Ergebnisse zweier Projekte in einem gemeinsamen Datenmodell erfordert einen immensen Abstimm- und Verwaltungsaufwand.
Ein Repository kann diese Aufgaben technisch unterstützen - mehr nicht. Aus diesem Grund ist der Einsatz eines Repositories sehr konservativ zu Beurteilen. Unternehmen sind gut beraten, wenn sie zunächst in kleinen, lokalen Dictionaries erste Erfahrungen mit Dingen wie beispielsweise Datenmodellen machen. Erst wenn sich im Unternehmen ausreichend Know-how und Verständnis für diese Thematik gebildet haben, lassen sich langsam umfassendere Dictionaries einsetzen. Schließlich wird man auch in der Lage sein, ein Repository zu managen - aber dies ist ein Prozeß, der viele Jahre in Anspruch nehmen dürfte.
Natürlich reicht ein solcher Betrag nicht aus, um daraus eine Handlungsmaxime abzuleiten. Jedes Unternehmen hat eine spezielle Ausgangsposition, die genau analysiert werden muß. Trotzdem lassen sich aus den hier angeführten Überlegungen einige Schlüsse ziehen:
- Eine Softwareproduktions-Umgebung kann in großen Teilen evolutionär eingesetzt werden.
- Einige Bausteine der SPU müssen unabhängig von der Fragestellung der Softwareproduktion geklärt werden.
- Unternehmenspezifische Anpassungen haben nicht zu unterschätzende Investitionen zur Folge.
- Ablauf- und Aufbauorganisation zur Nutzung einer SPU können nur langsam implementiert werden.
Abschließend soll hier noch ein Aspekt hervorgehoben werden, der bei der technischen Diskussion über eine SPU vernachlässigt wurde: Auch das beste Werkzeug läßt sich nicht sinnvoll einsetzen, wenn diejenigen, die es bedienen sollen, nicht ausreichend geschult und motiviert sind. Auch müssen sie eine adäquate Unterstützung erfahren.
Dies bedeutet, daß alle Verfahrensänderungen in der Systemerstellung von ausreichenden Support-Maßnahmen begleitet werden müssen