Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

05.06.1981

Vorschläge für ein pragmatischeres Software Engineering

Das Projekt "Software-Engineering" läuft nunmehr seit rund zwölf Jahren. Ein erfolgreiches Projektende ist aber noch lange nicht in Sicht. Im Gegenteil bereits eine oberflächliche Projektrevision zeigt, daß die Requirements unvollständig sind, Milestones nicht definiert sind, ein Entwurfskonzept nicht vorliegt.

Vielmehr wird seit Jahren (fast) ausschließlich an der "Implementierung" des Software-Engineering gearbeitet.

Immer wieder werden neue Darstellungsformen, Strukturierungsmethoden, Sprachkonzepte etc. entwickelt, ohne daß über Voraussetzungen und Möglichkeiten ihres Einsatzes Klarheit besteht.

Um die Gründe für diese Phasenverschiebung einigermaßen vollständig zu erörtern, wäre eine eigene Artikelreihe erforderlich. Zu registrieren ist auf jeden Fall, daß zwischen den großen Entwürfen für die nächsten Jahrzehnte und den formalen Details die Erarbeitung von empirisch fundierten Grundlagen für Software-Engineering zu kurz kommt.

Dies mag wesentlich an einer Wissenschaftsauffassung der Software-lngenieure liegen, die sich um die Bedürfnisse der Software-Basis nicht kümmern, sondern die Formalisierungen als Selbstzweck betreiben und ihre Theoriebildung nur an ihren eigenen formalen Voraussetzungen verifizieren.

Keine gesicherten Grundlagen

Wenn man den hohen Anspruch, mit dem Software-Engineering seit Jahren publiziert und verkündet wird, am bisher Erreichten mißt, ist ein kritischer Kommentar sicher nicht überspitzt.

Um nicht mißverstanden zu werden: Es geht nicht darum, Software-Engineering an sich oder die bisherigen Produkte, die unter diesem Stichwort entstanden sind (wie etwa Entwurfsmethoden oder Data Dictionaries), in Frage zu stellen oder zu kritisieren. Ich meine allerdings, daß entgegen der bisherigen Vorgehensweise Vorrang für die Aufgabe besteht, erst die Grundlagen für das Software-Engineering zu schaffen.

Das Fehlen dieser Grundlagen macht es dem DV-Anwender bisher unmöglich, ein geschlossenes Software-Engineering-Konzept im eigenen Betrieb einzuführen, welches auch nur die wichtigsten Bereiche im Rahmen der Softwareerstellung abdeckt. Infolge des Fehlens von gesicherten Grundlagen kann er sich in der Fülle der für verschiedenste Bereiche wie Entwurf, Dokumentation Projektmanegement, Programmierung etc. isoliert angebotenen Methoden, Tools und Formalismen nicht zurechtfinden.

Die Ziele des Software-Engineering, Software in hoher Qualität wirtschaftlich zu erstellen, können, so behaupte ich, mit dem heutigen Instrumentarium nur unzureichend erfüllt werden. Welches sind nun die Grundlagen, mit denen sich Software-Engineering zu befassen hat? In wertender Reihenfolge können sie den folgenden fünf Bereichen zugeordnet werden:

1. Der menschliche Faktor ist der mit Abstand wichtigste in der Software-Erstellung. Vom Software-Engineering wird er eher stiefmütterlich behandelt. Dies zeigt die Praxis der täglichen Arbeitssituation ebenso wie die Verfassung des Arbeitsmarktes für DV-Fachkräfte.

Aufgabe des Software-Engineerings und seiner Proponenten wäre es, systematisch - auf empirischer Basis - die Voraussetzungen für erfolgreiche Projekt- und Teamarbeit zu schaffen. Über einen groben Taylorismus der "lines of code per ...." ist man noch kaum hinausgekommen.

Einmaleins der Personalführung

Es sollen nur die wichtigsten Fragen aufgezählt werden, deren Behandlung über Erfolg/Mißerfolg eines Projektes entscheiden:

- Organisation von Projektteams

- Führungs- und Kommunikationsstrukturen

- Motivation von Projektmitarbeitern und (fast noch wichtiger) von Mitarbeitern der Fachabteilung

- Versorgung der Projektbeteiligten mit dem richtigen Maß von Informationen

- Transparenz von Projektsteuerungs- und Entscheidungsvorgängen

Wird fortgesetzt