In der Praxis verwendet jede DV-Abteilung ihr eigenes Phasenmodell und trennt sich nur ungern davon. Die Devise darf deshalb nicht lauten: modernes Software-Engineering nur über einen neuen Ansatz. Ziel sollte es vielmehr sein, Ordnung und Systematik in das bestehende Konzept zu bringen.

Zunehmend komplexer werdende DV-Verfahren und ein immer stärker anwachsender Anteil von Dialogsystemen zwingen zu einer Schwerpunktverlagerung bei den Entwicklungsaktivitäten hin zu den konzeptionellen Arbeiten in Fach- und DV-Konzept. Dies bedeutet jedoch nicht allein eine Aufwandsverlagerung nach vorne, sondern vor allem ein Umdenken im methodischen Ansatz. Software-Engineering als Antwort auf diese Forderung heißt ingenieurmäßiges Betreiben der Softwareentwicklung im Sinne von planerischem, methodengestütztem und werkzeugunterstütztem Konzipieren, Realisieren und Dokumentieren von DV-Verfahren. Diese Disziplin befaßt sich dabei aber nicht ausschließlich mit Software, sondern ebenso stark mit der rein fachlichen Analyse und dem von der DV-technischen Lösung abweichenden Entwurf.

Vielfältige Hindernisse sind zu überwinden

Ist die Notwendigkeit eines Umdenkens auch erkannt, so stößt das Nachvollziehen dieser Entwicklung auf vielfältige Hindernisse, wie zum Beispiel die Skepsis gegenüber modernen Methoden, das Fehlen entsprechend ausgebildeter Mitarbeiter oder die Beanspruchung durch das Alltagsgeschäft. So finden heute noch unterschiedlichste, aufeinander aufbauende Vorgehensweisen Anwendung.

Am weitesten verbreitet ist die allein phasenorientierte Vorgehensweise, bei der zwar Aktivitäten definiert und in ein Phasenmodell eingebettet sind, jedoch kaum Regeln oder Vorschriften dafür existieren, wie die am Ende eines Entwicklungsabschnitts erwarteten Ergebnisse erarbeitet werden und aufgebaut sein sollen. Der Entwurf basiert auf intuitiven, wenig abgestimmten Ideen, die Dokumentation ist überwiegend verbal und schlecht strukturiert, die Vorgaben für die Realisierung sind aufgrund fehlender Methodik und Qualitätssicherung unvollständig und lassen ungewollten Auslegungsspielraum. Verfahren, die auf diese Weise konzipiert und realisiert werden, führen neben erheblichen Qualitätseinbußen und geringer Akzeptanz oft zu Kostenüberschreitungen und Terminverzügen.

Mit der Ergänzung des Phasenmodells um Methoden steigt die Qualität der Verfahrensentwicklung, es bleibt jedoch der hohe manuelle Dokumentationsaufwand und die fehlende Möglichkeit wirksamer Qualitätssicherung. Merkmale der methodengestützten Variante sind verbesserte Qualität der Entwurfsergebnisse aufgrund eines systematischen, schrittweisen Vorgehens bei allerdings nahezu gleichbleibendem Dokumentationsaufwand und weiterhin fehlenden QS-Möglichkeiten. Der hohe Dokumentationsaufwand schmälert die Akzeptanz der Methode, fehlende Qualitätssicherung wirkt sich nach wie vor auf Kosten und Termine aus.

Tooleinsatz verbessert Entwurfsergebnisse

Tool-Unterstützung beim Software-Engineering ist als Unterstützung des Methodeneinsatzes bei konzeptionellen Arbeiten der Verfahrensentwicklung und nicht allein als Hilfe bei Editieren, Dokumentation und Generierung zu verstehen. Tool-unterstütztes Software-Engineering führt zu besseren, qualitätsgesicherten Entwurfsergebnissen bei reduziertem Dokumentationsaufwand. Der Unterschied zum nicht Tool-unterstützten Vorgehen besteht darin, daß

- Einzelergebnisse der Entwicklung (zum Beispiel die Definition eines Informationsobjektes, die Zuordnung eines Datenelementes zu einer Datei) strukturiert und redundanzfrei erfaßt,

- Enddokumente (zum Betspiel eine Informationsstruktur, ein Funktionsbaum) erst aus unterschiedlichsten Verdichtungen der Einzelergebnisse gewonnen und

- qualitätssichernde Maßnahmen durch Auswertung der Abhängigkeiten zwischen Einzelergebnissen gefördert werden.

Von einem modernen Konzept für das Software-Engineering werden verbindliche Aussagen zum "Was", "Wie" und "Womit" der Verfahrensentwicklung erwartet. Ein modernes Konzept muß vorschreiben,

- welche Aktivitäten/Bearbeitungsschritte in welcher Abfolge mit welchen Ergebnissen und Schnittstellen zueinander durchgeführt werden,

- auf welche Weise beziehungsweise mit welchen Methoden die Entwicklungsaktivitäten durchzuführen sind, in welcher Form Dokumentation und Qualitätssicherung betrieben werden und

- mit welchen technischen Hilfsmitteln die Entwicklungsaktivitäten beziehungsweise der Methodeneinsatz hierfür unterstützt werden können.

Phasenmodelle gibt es wie Sand am Meer. Es existiert wohl keine Variante, die nicht schon irgendwo einmal formuliert wurde. Zum Teil unterscheiden sich die Modelle voneinander nur im Detaillierungsgrad einzelner Phasen (grob/fein) oder in Phasenbezeichnungen; zum Teil sind auch nur die Schwerpunkte einzelner Phasen unterschiedlich gelagert. Von einigen wenigen Exoten abgesehen lassen sich alle Phasenmodelle auf die grundlegenden Phasen Voruntersuchung, Fachkonzept, DV-Konzept, DV-Realisierung und Einführung zurückführen.

System-Schwachstellen werden aufgedeckt

Die Voruntersuchung deckt Schwachstellen des bestehenden Systems auf, leitet hieraus Ziele für eine Neuentwicklung ab und zeigt generelle Lösungsvarianten auf.

Das Fachkonzept erstellt einen rein fachlichen Entwurf für das zu realisierende Verfahren. Es beschreibt fachliche Strukturen und Abläufe einschließlich ihrer Darstellung an der Benutzeroberfläche, beispielsweise in Form von Dialogen und Masken.

Im DV-Konzept wird die fachliche Lösung in eine DV-technische Lösung überführt. Erst hier spielen einzusetzende Hardware und Software (inklusive DB-/DC-Systeme) eine Rolle. In dieser Phase wird die vollständige Programmvorgabe für die Realisierung zusammengestellt.

Zur DV-Realisierung gehören Codierung und Test der Einzelmodule sowie des Gesamtsystems. Die Phase Einführung beinhaltet unter anderem Schulung, Durchführung des Überleitverfahrens und Einführungsunterstützung.

Bestehendes Modell dient als Ausgangsbasis

Gerade weil jede DV-Abteilung ihr eigenes Phasenmodell im Einsatz hat und sich nur ungern von ihm trennt, darf die Devise nicht lauten: neues Software-Engineering nur über ein neues Phasenmodell. Es sollte vielmehr versucht werden, Ordnung und Systematik in das bestehende Modell zu bringen. Das kann dadurch geschehen, daß die den einzelnen Phasen zugeordneten Aktivitäten(-gruppen)

- inhaltlich überarbeitet und dabei ergebnisorientiert und methodisch ausgerichtet,

- an ihren jeweiligen Schnittstellen hinsichtlich schnittstellenübergreifender Bearbeitungsfolgen und Dokumentationsanforderungen optimiert und gegebenenfalls

- in sich neu gruppiert oder neu zugeordnet werden.

Entwicklungsaktivitäten lassen sich nach ihren Ergebnissen (Funktionen, Informationen, Module) sowie nach Tätigkeiten (Entwurf, Dokumentation) klassifizieren.

Als eine mögliche, in der Praxis anerkannte Klassifizierung von Aktivitäten(-gruppen) kann die folgende Unterteilung genannt werden:

- Erarbeiten der Informationsstruktur (mit Definition ihrer Informationsobjekte),

- Erarbeiten der Funktionsstruktur (mit Beschreibung der Funktionsinhalte und -abläufe),

- Erarbeiten der Dialogstruktur (mit Darstellung der Einzeldialoge, Maskeninhalte und

-layouts),

- Erarbeiten der Datenbank-/Dateistruktur (inklusive Satzaufbau),

- Erarbeiten der Programmstruktur (inklusive Programmbeschreibung),

- Erarbeiten der Modulstruktur (mit Festlegung von Aufbau und Ablauf der Einzelmodule) und

- DV-technische Realisierung (Programmierung, Test, Integration, Einführung).

Für jede der Aktivitäten sind Entwurfs-, Dokumentations- und Qualitätssicherungsarbeiten erforderlich, die durch den Einsatz von Methoden unterstützt werden. Methoden liefern hierbei die Vorschriften und Regeln für die Vorgehensweise bei bestimmten Entwicklungsaktivitäten. Dem jeweiligen Regelwerk liegen Vereinbarungen begrifflicher und sachlicher Art zugrunde.

Tools für die Softwareentwicklung existieren heute vor allem in Form von Editoren und Generatoren. Darüber hinaus gewinnen in zunehmendem Maße Dictionaries an Bedeutung. Editoren und Textaufbereiter bieten Unterstützung bei der Erstellung und weiteren Bearbeitung unstrukturierter (Text-)Dokumente. Solche Dokumente können Funktionsbeschreibungen oder Pseudocodes sein. Der Schwerpunkt von Editoren/Textaufbereitern liegt in der Dokumentation.

Generatoren unterstützen Entwurf und Erstellung von Bildschirmmasken und Programmen/Modulen. Mit Formatgeneratoren werden Bildschirmmasken interaktiv entworfen und für die Realisierung generiert. Programmgeneratoren erstellen Programmskelette, in die die spezifische Verarbeitungslogik eingebettet wird, und unterstützen beispielsweise die Erstellung von Programmen hinsichtlich Strukturierter/Normierter Programmierung oder Entscheidungstabellentechnik. Programmgeneratoren bieten somit neben der Entwurfsunterstützung auch eine Qualitätssicherungskomponente.

Dictionaries schließlich können für Entwurf, Dokumentation und Qualitätssicherung strukturierter Entwicklungsergebnisse herangezogen werden. Die Abbildung der Entwicklungsergebnisse in weitgehend redundanzfreien Strukturen reduziert den Aufwand für Erfassung und Verwaltung und erhöht die Möglichkeiten qualitätssichernder Maßnahmen.

Tool-Unterstützung des Software-Engineering bedeutet Hilfestellung bei Entwurf, Dokumentation und Qualitätssicherung sämtlicher Aktivitäten der Phasen Fachkonzept, DV-Konzept und Realisierung. Die Auswahl geeigneter Tool-Bausteine ergibt sich dabei aus der Art der zu erstellenden Entwurfsdokumente. Zunächst ist generell zwischen strukturierten und nicht strukturierten Entwurfsergebnissen zu unterscheiden.

Einsatzspektrum für Data-Dictionaries wächst

Strukturierte Entwurfsergebnisse liegen vor, wenn Entwurf, Dokumentation und Qualitätssicherung an definierten Ausprägungen und Inhalten von Entwurfsobjekten und an eindeutig beschriebenen Beziehungen und Abhängigkeiten zwischen diesen ansetzen. Unter einem Entwurfsobjekt ist hierbei ein typisierter Entwurfsbestandteil der Verfahrensentwicklung zu verstehen, wie zum Beispiel eine Information/ein Datenelement, ein Dialog oder eine Datei. Ausprägungen/Inhalte von Entwurfsobjekten sind demnach die Länge einer Information/eines Datenelementes, die Bezeichnung eines Dialogs oder die Organisationsform einer Datei.

Entwurfsobjektbeziehungen als strukturelle Abhängigkeiten zwischen Entwurfsobjekten werden zum Beispiel ausgedrückt durch das Vorkommen eines Datenelementes in einer Maske, die Aufrufbarkeit einer Maske in einem Dialog oder die Verwendung einer Datei in einem Modul. Mit der Definition von Entwurfsobjekten und deren Einbringung in eine Gesamtstruktur werden Art und Umfang der Verfahrensentwicklung bestimmt.

Unstrukturierte Entwurfsergebnisse lassen sich nicht über Ausprägungen definierter Merkmale darstellen, sondern bedürfen der ausführlichen verbalen Beschreibung oder grafischen Abbildung, die jeweils in sich zwar strukturiert sein können, jedoch untereinander keine maschinell auswertbaren Beziehungen unterhalten. Beispiele für im obigen Sinne nicht strukturierte Entwurfsergebnisse sind eine verbale Funktionsbeschreibung oder ein grafisches Maskenlayout.

Bei der Suche nach geeigneten Tools ist darauf zu achten, daß jedes einzelne Tool die ihm übertragenen Aufgaben optimal erfüllt und die Gesamtheit der eingesetzten Tools aufeinander abgestimmte Aufgabenerfüllung gewährleistet.

Die Erfassung und Verwaltung strukturierter Entwurfsergebnisse ist der ureigenste Einsatzzweck von Data-Dictionaries, wobei die Entwurfsobjekte ursprünglich allein aus den Bereichen DV-Konzept und Realisierung stammten und in standardisierten Metastrukturen vorformatiert waren. Heute werden Dictionaries in zunehmendem Maße für Entwurf und Realisierungsvorgabe anstatt nur für die begleitende Realisierungsdokumentation benutzt. Über Benutzerdefinitionen kann hierfür jede gewünschte Metastruktur generiert werden.

Data-Dictionaries sind in der Regel sehr mächtige Systeme, die komplexe Strukturen abbilden können. Für die Erfassung und laufende Verwaltung werden Eingabeskelette generiert, in denen gewünschten Plausiprüfungen und strukturelle Abhängigkeiten definiert werden. Für Auswertungen stehen Listgeneratoren zur Verfügung, die Dialogauskünfte um schriftliche Reports ergänzen.

Eine Alternative zu dedizierten Data-Dictionaries sind Datenbanksysteme, die voll vernetzte Strukturen abbilden können, egal ob Codasyl- oder relationale Systeme. Einsatzentscheidend ist die Verfügbarkeit einer vorgenerierten oder mit geringem Aufwand generierbaren Benutzeroberfläche für Dialog und Report. Wünschenswert ist zudem eine Sprachoberfläche, die sich allgemeinen Standards weitgehend anpaßt.

Nicht oder schlecht strukturierte Entwurfsergebnisse lassen sich den bisher ebenfalls mehr in der Realisierung eingesetzten Editoren und Generatoren zuordnen.

Editoren dienen der Entwurfsdokumentation durch Unterstützung der bloßen Texterfassung, während Generatoren darüber hinaus Entwurf und Qualitätssicherung unterstützen. Mit Programmgeneratoren lassen sich Funktions- und Modulabläufe in strukturierter, syntaxgeprüfter Form darstellen; Maskengeneratoren leisten Hilfestellung bei Entwurf und Definition von Maskenlayouts.

Die gegenseitige Zuordnung strukturierter und unstrukturierter Entwurfsdokumente erfolgt über identische Benennungen von zum Beispiel

- dem Entwurfsobjekt "Funktion" und der verbalen Funktionsbeschreibung,

- dem Entwurfsobjekt "Modul" und der Darstellung des Modulablaufes im Pseudocode oder

- dem Entwurfsobjekt "Maske" und dem über einen Generator erstellten Maskendesign.

Die Frage "Host- oder PC-Lösung" stellt sich nicht nur, wenn es um den Standort fertiger DV-Verfahren geht, sondern wird auch für die Entwicklung von DV-Verfahren zunehmend aktueller. Gab es früher ausschließlich Entwicklungen auf dem Großrechner für den Großrechner, so ist heute ein breites Spektrum des Rechnereinsatzes vom Großrechner über die mittlere Datentechnik und spezielle Entwicklungsrechner bis hin zum PC zu erkennen. Dabei kann auf dem Großrechner ein PC-Verfahren konzipiert und entwickelt werden und umgekehrt.

Welche Möglichkeiten bestehen für die Entwicklung auf dem Host einerseits und dem PC andererseits und worin besteht das für und Wider der Ansätze?

Sowohl Data-Dictionaries für die strukturierte Entwurfsdokumentation als auch Programmgeneratoren für die Strukturierte Programmierung als wichtigste Tools für das Software-Engineering waren über Jahre hinweg ausschließlich auf Großrechnern verfügbar.

PC-Lösung erweist sich als kostengünstiger

Systementwicklung auf Großrechnern kann bezüglich Funktionsspektrum und Komfort als hundertprozentige Lösung angesehen werden, die aber auch ihren Preis kostet. Aufgrund des hohen Aufwands für die Generierung und Betreibung eines Data-Dictionary gibt es in der Regel nur eine Dictionary-Version für alle DV-Projekte einer DV-Abteilung. Dies kann keine projektspezifische, maßgeschneiderte Version sein, sondern allenfalls ein guter Kompromiß. Zudem ist - wiederum bedingt durch die Mächtigkeit und Komplexität des Dictionary - eine einmal generierte Struktur und Oberfläche nur schwer änderbar.

Eine PC-Lösung bietet sich als kostengünstigere, maßgeschneiderte, ausreichend komfortable und äußerst flexible 80-Prozent-Alternative zur Host-Lösung an.

Die von einer PC-Lösung zu erwartende Kostenreduzierung resultiert aus den verringerten Hardware-/Softwarekosten, dem geringen Entwicklungs- und Schulungsaufwand und der weniger aufwendigen Pflege des Systems. Der Entwicklungsaufwand beispielsweise liegt nach Vorliegen einer konzeptionellen Lösung, die auch bei der Host-Variante erst erarbeitet werden muß, im Manntage- beziehungsweise Mannwochenbereich.

Hardware- beziehungsweise softwaretechnische Voraussetzungen für eine PC-Lösung als Ersatz eines zentralen Data-Dictionary sind ein mehrplatzfähiger PC, ein relationales Datenbanksystem, ein integrierter, parametergesteuerter Dialogbaustein sowie ein integrierter, parametergesteuerter Listgenerator.

Die einfache Hantierbarkeit und Flexibilität relationaler Datenstrukturen und die parametergesteuerte statt programmierte Dialogführung und Listenerstellung erlauben eine auf das einzelne Projekt und die jeweiligen Entwicklungsmodalitäten zugeschnittene Metastruktur und Benutzeroberfläche. Neben der von Team zu Team unterschiedlichen Begriffswelt lassen sich auch unterschiedliche Strukturbeziehungen und Entwicklungsschwerpunkte berücksichtigen.

Eine PC-Lösung zeigt ihre Flexibilität nicht nur in der Anpaßbarkeit an die von Projekt zu Projekt variierenden Belange, sondern ebenso in der Anpaßbarkeit an geänderte Anforderungen innerhalb eines Einsatzes. Die Gründe sind auch hier die Änderungsfreundlichkeit relationaler Datenstrukturen und die parametergesteuerte Benutzeroberfläche.

Dr. Christoph Meller ist Berater bei FWU Systema, Geschäftsstelle Nürnberg.