Folge 2

- Ausbildungs- und Laufbahnplanung (Stichwort: Personalfluktuation)

- Einbeziehung der Fachabteilungen durch laufende Mitarbeit

- Berücksichtigung der Bedürfnisse der DV-Anwender bei der Konzeption von DV-Systemen (Stichwort: Benutzerfreundlichkeit)

Woran es liegt, daß auch heute noch zahlreiche Projekte daran scheitern, daß grundlegende Voraussetzungen der Personen- und Teamführung nicht erfüllt sind und daß bisher dazu aus der Software-Engineering-Literatur kaum Anregungen, schon gar nicht Lösungsansätze kommen, ist eigentlich unerklärlich.

2. Definition und Bewertung der Ziele des Software-Erstellungs-Prozesses

Angesprochen ist hier die Managemententscheidung über die Gestaltung von Informationssystemen, deren Qualität und Aussagefähigkeit, den Grad ihrer Automatisierung etc.

In diesen Entscheidungsprozeß einbezogen ist auch die Frage der Gestaltung des Software-Erstellungs-Prozesses selbst. In beiden Bereichen, Informationssystem im Unternehmen wie Software-Erstellung, gibt letztendlich die Bewertung einer Kosten-/Nutzen-Relation der erstellten Produkte oder des Erstellungs-Prozesses selbst den Ausschlag für Planungs- und Investitionsentscheidungen. Allerdings ist die Bewertung von Wirtschaftlichkeitskritenen dadurch erschwert, daß viele Kriterien nicht quantifizierbar sind und dennoch bewertet werden müssen (so etwa die Benutzerfreundlichkeit von Systemen oder die Aktualität der Entwicklungsdokumentation, um willkürlich zwei Punkte herauszugreifen); sie ist durch den überaus schnellen Wandel der letzten Jahre (Stichwort: Dialogisierung, dezentrale Verarbeitung von Daten) zusätzlich behindert worden.

Es ist bemerkenswert, daß vom Software-Engineering kaum praktikable Entscheidungsunterlagen für das Management in Form von Wirtschaftlichkeitsanalysen, Checklisten etc. für kurz-, mittel- oder gar langfristige DV-Planung angeboten werden.

3. Definition der Aufgaben zur Software-Erstellung und Schaffung einer verbindlichen Terminologie.

Die Abstinenz der großen Software-Engineering-Familie auf diesem Gebiet hat besonders unangenehme Folgen. Da die verwendete Terminologie (weder was den DV-Bereich noch gar, was den fachlichen, betriebswirtschaftlichen Teil der Software-Erstellung betrifft) nicht nur uneinheitlich ist, sondern sich sogar unkontrolliert ausbreitet, werden viele Software-Engineering-Kontroversen um des Kaisers Bart geführt.

Was not täte, wären grundlegende Arbeiten zu den Themen:

- Strukturierung von DV-Entwicklungen in Projektphasen (mit definierter Phasenabgrenzung)

- Definition von Phasenzielen (quantitativ und qualitativ)

- Definition von Aktivitäten zur Zielerreichung

- Definition von Phasenergebnissen und Beschreibung der Dokumentationserfordernisse

- Definition von Prüfungs- und Kontrollmechanismen für Phasenaktivitäten und -ergebnisse

- Festlegung einer einheitlichen Terminologie für Phasen, Ziele, Ergebnisse, Aktivitäten, Dokumente etc.

Der Grundsatz, daß bei der Software-Erstellung das Was vor dem Wie kommt, gilt bis heute anscheinend für das Projekt "Software-Engineering" nicht.

4. Festlegung der Formen, In denen der Software-Erstellungs-Prozeß abläuft.

Vor der eigentlichen Erstellung ist das Wie festzulegen, an dem sich die folgende Arbeit orientiert. Hierunter fallen Konventionen für Systementwurf und Implementierung ebenso wie die Festlegung einer Kommunikationsgrundlage für alle Projektbeteiligten einschließlich Fachabteilung und DV-Anwender.

In diesem Bereich schafft das Software-Engineering unmittelbare Handlungsanweisungen für Software-Ersteller.

Der Bereich läßt sich grob, nicht ohne Überschneidungen, in drei Teilbereiche gliedern:

a) Entwurf und Dokumentation von DV-Systemen.

Beim Systementwurf sind folgende Fragen durch Konventionen zu regeln:

- Regeln für die Strukturierung von Systemen und für die Gestaltung von Abläufen Regeln für die Festlegung von Gliederungsebenen und Gliederungstiefe zur Funktionsstrukturierung

- Fragen der Gestaltung von Funktionsmodifikationen oder -alternativen unter Einbeziehung der Möglichkeiten der Dialogsteuerung

- Regeln für die Gestaltung der "Benutzeroberfläche" insbesondere bei

Dialogsystemen

- Spezifikation, Dokumentation und Implementierung von Schnittstellen

- Bereitstellen von Entscheidungskriterien für die Vorgehensweise der Entwickler (daten-, funktions-, ablauf-, phasenorientiert etc.)

Damit sind nur einige der wichtigsten Fragen aufgezählt. Wer sich mit diesen Fragen sowie mit Fragen der Entwicklungsdokumentation bereits einmal befaßt hat, wird festgestellt haben, daß er dazu vom Software-Engineering kaum praktische Hilfen zu erwarten hat.

Fehlender Praxisbezug

Für einzelne der oben aufgezählten Punkte, etwa was die Strukturierung von Funktionen betrifft, gibt es zwar eine Reihe von formalen Lösungen (Stichwort: Top-Down-Ansatz/Hierarchische Strukturierung), aber weder eindeutige Begriffsdefinitionen (für Funktionen, Abläufe etc.), noch klare Kriterien zur Gliederung von Systemen sowie für die Abgrenzung der einzelnen Gliederungsebenen. (Wo beispielsweise endet die Strukturierungsebene des Grobkonzepts, wo beginnt das Feinkonzept, wenn wir einmal davon ausgehen, es wäre klar definiert, was nun ein Grob- beziehungsweise Feinkonzept seit)

Es gibt zahlreiche Einzeluntersuchungen zu anderen Fragen der Systemgestaltung wie

- Erfahrungen bei der Einführung neuer DV-Systeme (meist werden ohnehin nur die positiven Erfahrungen veröffentlicht),

- ergonomische Untersuchungen zur Gestaltung von Dialogsystemen (insbesondere die Systembedienung und die optische Gestaltung betreffend, weniger zu allgemeinen Akzeptanzfragen oder zur Steuerung und Kontrolle von Dialogabläufen), aber kaum Informationen, die für den Systemgestaltungsprozeß praktisch verwertbar wären.

Zum Thema Entwicklungsdokumentation wäre zu sagen, daß sie entgegen anderslautenden Bekundungen im Software-Engineering nach wie vor ein bescheidenes Dasein führt.

Bitteres Brot

Einige Stichworte zu diesem Thema, die das tägliche - oft bittere - Brot des Software-Entwicklers darstellen, mögen dies verdeutlichen:

- Festlegen von Inhalt, Form, Umfang, Genauigkeit von Dokumentation

- Festlegen des Zeitpunktes der Dokumenterstellung

- Festlegen der Gültigkeitsdauer von Dokumentation sowie ihrer Versionsführung

- Regeln für phasenübergreifende Umsetzung von Entwicklungsdokumenten

- Darstellungsschwerpunkte im Dokumentationsprozeß (insbesondere Abgrenzungsregeln für betriebswirtschaftliche und DV-technische Darstellungen)

- Regeln für die Umsetzung von Entwicklungsdokumentation in Anwendungs- oder Rechenzentrumsdokumentation

- Regeln für die Benennung der Objekte des Entwicklungsprozesses

- Festlegungen, die die Form der Kontrolle und Verifikation der Ergebnisse der Software-Erstellung betreffen

- Aussagen zum Management von Dokumentation

Der Anspruch einer projektbegleitenden Dokumentation, wie er allgemein erhoben wird, ist hier durch Grundlagenarbeit noch nicht eingelöst.

b) Regeln, die die Organisation und Darstellung von Daten betreffen.

Das Software-Engineering hat die zunehmend stärkere Datenorientierung bei der Gestaltung von Informationssystemen noch nicht voll berücksichtigt, wenngleich in den letzten Jahren bemerkenswerte Ansätze in dieser Richtung zu registrieren sind (Stichworte: datenorientierte Entwurfsmethode, relationale Datenbanken, Data Dictionaries).

Die in letzter Zeit verstärkt eingesetzten Data Dictionaries beschränken sich bisher stark auf formale Aspekte der Datendarstellung, die freilich nicht geringzuschätzen sind: Durch maschinelle Verwaltung der Datendokumentation, insbesondere durch automatisierte

Verwaltung der Referenzen der Daten innerhalb des Informationssystems schaffen sie die Voraussetzungen für eindeutige, weitgehend redundanz- und überschneidungsfreie Datenbestände.

Es ist davon auszugehen, daß künftig datenbezogene Etwurfsentscheidungen, die sich auch auf die Qualität von Daten beziehen, von solchen Systemen unterstützt werden:

- Richtlinien für die Namensvergabe (eine bestimmt wichtige, in ihrer ständigen Wiederholung jedoch ebenso überflüssige wie periphere Prozedur der Software-Erstellung)

- Richtlinien für die Datenverschlüsselung (Matchcodes, Kunden-, Artikelnummern etc.)

- Richtlinien für die Bildung und Verwaltung von Zustandsinformationen (etwa die zahlreichen Ausprägungen der Datenlöschung betreffend)

- Festlegen von Prüfregeln für Daten

- Regeln für eine optimale Datenorganisation im Sinne des Software-Engineerig (Stichworte: Flexibilität, Erweiterbarkeit, gezielter Einbau von Redundanzen, Entkopplung der Wertebelegungen)

- Regeln für die Organisation von Tabellen etc.

Wird fortgesetzt