Eine schier unübersichtliche Anzahl verschiedener Software-Entwicklungsmethoden,

-konzepte und -werkzeuge kennzeichnet die aktuelle Situation im Bereich des Software-Engineering. Die Systeme verfolgen allerdings alle das gleiche Ziel: Weichware so produktiv und vor allem so realitätsnah wie erforderlich zu entwickeln. Dabei wird allzuleicht vergessen, daß die Konzepte auf einer gemeinsamen Basis beruhen: dem Wechselspiel "Kommunikation".

Computersoftware und Informationstechnologie haben fast unbemerkt den traditionellen Begriff der Maschine außer Kraft gesetzt. Zu Recht wird in der neueren Literatur darauf hingewiesen, daß die Erfindung der mechanischen Uhr die Kultur tiefgründiger revolutionierte als die Erfindung der Dampfmaschine, weil die Uhr eine neue Denkweise geschaffen hat, indem sie die Menschheit "von der Natur entfremdete" durch die quantifizierende "Entqualifizierung" kosmischer Zeitbegriffe. Softwaresysteme entqualifizieren und karikieren in analoger Weise die menschliche Sprache insgesamt.

Die Eindeutigkeit der Sprache von Softwaresystemen entsteht durch die Hardware und den Code, indem sie implementiert wird. An und für sich ist sie jedoch "vieldeutig". Die babylonische Sprachverwirrung existiert auch in der (Hardware-) Maschinenwelt. Kein Mensch hat die Kraft, jedes Wort, das er spricht, zu hinterfragen. In gleicher Weise versteckt sich die Maschinensprache unter Schichten von Abstraktionen. Auch in (höheren) Programmiersprachen stecken Momente "metaphysischer" Unschärfe des Inhalts.

In diesem Sinne sind Softwaresysteme auch Medien, die

menschliche Beziehungen auf neue Art vermitteln. Softwaresysteme vermitteln Anwendern und Entwicklern neuartige Machtgefühle, die durch die wachsende Abhängigkeit von abstrakten Maschinensystemen nur noch gesteigert werden. Diese Neuartigkeit abstrakter Maschinen zwingt zu neuen Fragestellungen, die grundsätzlich auf das allgemeine Verhältnis von Mensch und Maschine eingehen.

In der Entwicklung des Software-Engineering läßt sich die Historie dieses neuen Themas zumindest ansatzweise verfolgen. Zunächst ging es nur um die Entwicklung von Methoden, zur Beherrschung des Chaos. Mit den ersten Erfolgen kam aber auch die erste Krise, die dazu zwang, den Softwareentwicklungsprozeß als Ganzheit zu betrachten, die eng verkoppelt ist mit menschlicher Kommunikation.

Zwei Fragenkomplexe sind gegenwärtig umstritten:

- das Verhältnis von Entwickler und Werkzeug beziehungsweise von Softwareentwicklung und Softwareentwicklungs-Umgebung,

- das Verhältnis von Software und Anwendern beziehungsweise Softwareproduktion und Softwareanwendung. Zusammengefaßt ergibt sich das Bild einer Beziehungskette, in der beide Fragenkomplexe die Pole einer qroßen Relation bilden: Entwickler - Werkzeug, Software - Anwender.

Die Kette schließt sich zum Kreis, wenn der Anwender als

Auftraggeber auftritt: Auftraggeber - Entwickler ( - Werkzeug - Software - ) - Anwender. Sind Auftraggeber, Entwickler und Anwender Mitglieder des gleichen sozialen Systems (eines Unternehmens), so wird das Werkzeug zu den Zwecken eingesetzt werden, die das Unternehmen für wesentlich hält.

Die Relation Werkzeug/Software ist so letztlich nur noch ein Zwischenglied menschlicher Systembeziehungen. Es geht daher um die wohlverstandenen Interessen von Softwareentwicklung und Softwareproduktion, wenn die Eigenarten der menschlichen Kommunikation in das Zentrum der Aufmerksamkeit des modernen Software-Engineering gestellt werden.

Nur in diesem Zusammenhang kann sinnvoll gefragt werden, wie abstrakte Maschinenmedien als Werkzeuge dieser Kommunikation

sinnvoll genutzt werden können.

Es gibt heute zahlreiche Regeln, Verfahren, Methoden, Techniken und Werkzeuge, die verschiedene Phasen der Softwareentwicklung unterstützen. Es entstehen Methodenpakete, die tendenziell den gesamten Lebenszyklus von Softwareprojekten umgreifen. All diese Systeme basieren auf einer Vielzahl mehr oder weniger ähnlicher Phasenkonzepte

Die oft brillanten Instrumente haben Vor- und Nachteile, im wesentlichen aber wohl jeweils spezielle und eingeschränkte Einsatzbereiche. Das Ideal des technisch-praktisch orientierten Software-Engineering ist die Entwicklung eines "Universalsystems", für den gesamten "Software-life-cycle" und für alle Fälle.

Zwei Aufgabenstellungen kennzeichnen diese technisch-praktische Richtung:

- Das Streben nach Formalisierung, Standardisierung und Normierung der Verfahren, Methoden und Techniken als Basis für die Entwicklung von Werkzeugen und als Bedingung für die Kompatibilität, Portabilität und Integrierbarkeit dieser Werkzeuge in Werkzeugketten .

- Das Streben, die Kluft zwischen den Phasen und den auf sie zugeschnittenen Methoden zu schließen, insbesondere den Übergang zwischen dem Entwurfsstadium und Realisierungsstadium, wobei aus dem Entwurf ein lauffähiges Programm generiert werden soll.

Ohne den großen Nutzen dieser Forschungen zu bestreiten, bleibt dennoch die Frage nach der praktischen Relevanz dieser aufwendigen Entwicklungen für den Alltag der Softwareentwickler in den Unternehmen.

Das Vordringen der Software in neue Anwendungsbereiche,

Vernetzung und Innovation von Basismaschinen, kapazitätsfressende Programmpflege und -wartung zwingen die Softwareproduzenten und -anwender, die Effektivität ihrer Arbeit zu erhöhen. Der Produktivitätszuwachs muß durch Rationalisierungen erreicht werden. Ein entscheidendes Element ist hierbei der Einsatz von Methoden und Werkzeugen, also die Entwicklung neuer Verfahren und Techniken.

Trotz aller Fortschritte wird aber die Suche nach "richtigen" Lösungen immer schwerer. Insbesondere die Durchgängigkeit der Rationalisierungsmaßnahmen durch den ganzen Produktionsprozeß und die Integration verwendbarer Werkzeuge ist kaum ohne gewaltigen Aufwand zu verwirklichen. Aus dieser Situation entstehen schlichte Anforderungen an Softwareingenieure. Die Aufgabe der Ingenieure besteht nicht zuletzt darin, die Probleme des Alltags den Softwaretechnolgen plastisch vor Augen zu führen.

"Software-Engineering heute" muß sich also drei Herausforderungen stellen:

- Den technisch-praktischen Problemen der Softwareentwicklung, insbesondere den Problemen der Anforderungsspezifikation und der "Wartung ",

- den theoretisch-technischen Problemen der Konstruktion und Herstellung Software-produzierender Software,

- den empirisch-pragmatischen Problemen der real vorhandenen

Softwareproduzenten selbst, insbesondere den theoretisch-organisatorischen Problemen der Softwareproduktion.

Die Beziehung Mensch/Softwaresystem wird oft als Ergonomieproblem diskutiert. Die Aufgabe, Software-produzierende Software herzustellen, beinhaltet schon das Problem der "Benutzerschnittstelle" zwischen Softwareentwicklungssystem und Softwareentwickler.

Aber nicht nur der individuelle Mensch in einer funktionalen Rolle soll mit dem System kommunizieren. Die komplexe "Schnittstelle" von technisch-organisatorischen Systemen (individuellen Unternehmen) und Software-Entwicklungs-Systemen, läßt sich nicht in die Schemata

der Kommunikation Mensch/Maschine via Auge - Bildschirm und Hand - Keyboard pressen, die bei zu hoher Komplexität durch Druckeroutput "gepuffert" werden kann.

Feste Schemata passen nicht für alle Interfaces

Die geforderte "Schnittstelle" ist immer eingelagert in menschliche Kommunikation. Soweit diese Werkzeuge und Maschinen benötigt, verlangt sie ein vermittelndes Medium. Dabei geht es um die Scheidelinie zwischen zwei Problemkreisen: " Softwareentwicklung " und "Softwareproduzent".

Softwareentwicklung hat die Erstellung eines ganzen Produktes zum

Zweck, das definierte Probleme löst. Der Softwareproduzent ist dagegen ein reales System, das aus empirischen Gründen als "ganzheitliches" System zu betrachten ist. Die Struktur dieses Systems hat im Normalfall "Brüche".

Diese Systeme werden definiert durch den Prozeß, der Zwecke setzt, Probleme definiert und löst. Genauer gesagt, dieses System kann definiert werden durch eine Struktur individueller Prozesse, die im komplexen Ineinander und Durcheinander reale Wirkungen erzielen.

Die Industrie unterscheidet scharf zwischen "Forschung und Entwicklung" einerseits und "Produktion und Fertigung" andererseits. Rationalisierung greift insbesondere ein in den zweiten Bereich. Softwareproduktion ist aber nicht von Softwareentwicklung zu trennen. Folglich stellen sich zwei Grundfragen:

- Welche Routinearbeiten sind automatisierbar?

- Worin bestehen die Unterschiede von Softwareproduktion und industrieller Fertigung?

Mangelnde Reflexion der ersten Frage führt in die Sackgasse der überzogenen "Taylorisierung". Rationalisierung und Rationalität müssen verbunden werden. Rationalität besteht darin, die Vielfalt und

Komplexität von Einflußfaktoren mit einzubeziehen.

Volkswirtschaftler verweisen zunehmend auf gesellschaftliche Kosten und ökologische Rahmenbedingungen. Arbeitswissenschaftler verweisen auf humane Kosten und menschliche Faktoren im Inneren der Produktion. Insgesamt werden Unternehmen zunehmend als offene Systeme betrachtet.

Software-Engineering muß das menschliche System "Unternehmen" als zwecksetzendes Subjekt anerkennen, das in sich selbst auch dann komplex strukturiert und aus konkreten Individuen zusammengesetzt bleibt, wenn es nur "Anwender" eines "Standardsystems" ist.

Die unreflektierte Erzeugung von Arbeitsroutine durch Automatisierung ist im Bereich der Softwareproduktion mit Sicherheit noch schädlicher als im Bereich der industriellen Fertigung.

Softwareprodukte sind keine Massenprodukte, die in Serie gefertigt werden. Softwareproduktion entsteht vor allem in kreativen Prozessen. Kreative Prozesse lassen sich nur dort sinnvoll rationalisieren, wo rationelle Bedingungen für die Entfaltung autonomer Energien innerhalb eines zweckbestimmenden koordinierenden Rahmens geschaffen werden.

Softwareproduzenten (das heißt individuelle Unternehmen) sind immer zunächst kollektive geistige Arbeiter, deren Produktivität und Effizienz wesentlich von den inneren Kommunikationsstrukturen und

-medien abhängt, die den menschlichen Geist unterstützen.

Rationalisierung und Automatisierung mag in der industriellen Produktion dort berechtigt sein, wo sie unmenschliche Arbeit, das heißt Vergewaltigung geistiger Potenzen der Menschen, oder reine "Handarbeit", das heißt "geistlose", mechanische Arbeit, substituiert. Die Substituierung kollektiver geistiger Arbeit bewirkt in der Regel Demotivation der Mitarbeiter.

Anspruchsinflation abbauen

Als Schlußfolgerung aus beiden Problemkreisen ergibt sich: Überhöhte Ansprüche und überzogene Erwartungen an die heutige Leistungsfähigkeit der Softwaretechnologie und des Software-Engineering sollten - zumindest während der Arbeitszeit - zurückgenommen werden.

Die Softwareingenieure als Vermittler zwischen Technologie und

industrieller Praxis sollten sich an den Grundsatz halten: Beginne mit dem Einfachen! Das Einfache besteht in der schwierigen Aufgabe, vorhandene und verwendete Entwicklungsmethoden und -verfahren zu analysieren und ihren Einsatz zu optimieren.

Es geht dabei um das Recht der Unternehmen auf freie Wahl passender Methoden und Werkzeuge. Radikalisiert gilt dieses Recht sogar für jeden einzelnen Entwickler innerhalb eines Unternehmens.

Diese "Rechtsnorm" stellt an die Technologen die schlichte Forderung, die Wahrnehmung dieses Grundrechts durch technische Philosophien und sachlogischen Dogmatismus nicht zu behindern.

Optimierung vorrangig

Die Schnittstelle Mensch/Maschine, die hier zu realisieren ist, vermittelt die komplexe Beziehung zwischen dem Unternehmen als einem Bündel von funktionalen Rollen, Aufgaben, Zielen und Mitteln (Kapazitäten) einerseits und einem integrierten EDV-System, das Funktionen eines Informations-, Projektmanagement- und Software-Entwicklungssystems verbindet. Ein solches System ist weniger auf die abstrakt betrachteten Tätigkeiten der Softwareentwickler abgestimmt. Es hat vielmehr mit den Tätigkeiten von Unternehmen zu tun: mit Projekten.

Es geht mehr um Optimierung von Kommunikationsprozessen als um Rationalisierung und Automation von Produktionsprozessen analog der industriellen Massenproduktion.

Es geht weniger um Normierung von Produktionsstrukturen (zum Beispiel durch universell gültige Phasenpläne) als um Unterstützung der Strukturierung konkreter (das heißt "individueller") Arbeitsprozesse bei der Abwicklung von Projekten.

Die Maschine muß als Hilfsmittel des Menschen konzipiert sein, wobei die Maschine wesentlich als Informationssystem und der Mensch wesentlich als soziales und geistig-kreatives. System aufgefaßt wird. Der "Mensch" als System ist mehr als ein Individuum und mehr als ein Organigramm.

Diese Betrachtungsweise enthält einen reduzierten Anspruch an DV - Systeme zur Unterstützung der Softwareentwicklung und einen erweiterten Begriff vom "Menschen im allgemeinen" . Der Benutzer von Softwareentwicklungs-Systemen (und von Standardsoftware insgesamt) ist ein abstraktes, kollektives "Wesen", konkret wird es immer irgendein Unternehmen sein, das neben individuellen Menschen eine Vielzahl sozialer Faktoren in sich enthält.

Zu diesen "sozialen Faktoren" gehören nicht zuletzt die bisher angewendeten Methoden und Verfahren, die vielleicht nur deshalb schwer zu ersetzen sind, weil "man" gewohnt ist, mit ihnen zu arbeiten, beziehungsweise weil ihre Entwickler gerne mit ihren eigenen Methoden weiterarbeiten.

Soll also Software-Engineering und die Konstruktion von Software-Entwicklungs-Umgebungen von der idealen "abstrakten", universell einsetzbaren Maschine ausgehen, oder sollen die konkreten menschlichen Beziehungen, die realen technisch - organisatorischen Beziehungen in Software-produzierenden Unternehmungen als Ausgangspunkt für die Entwicklung entsprechender EDV-Hilfsmittel genommen werden?

Beide Aspekte sind komplementär. Wer den ersten Aspekt verabsolutiert, bewegt sich in akademischen Gefilden, jenseits der Wirrnisse des Marktes. Wer den zweiten Aspekt verabsolutiert, fällt leicht zurück in das alte Chaos unstrukturierter Arbeitsweisen.

Zum heutigen Zeitpunkt das Primat auf den zweiten Gesichtspunkt zu legen, kann demnach nur heißen, in einer bestimmten Situation einen Schritt zurückzumachen, um langfristig schneller voranzukommen.

Gerade in der jungen Disziplin Software-Engineering ist es möglich, den pragmatisch begründeten Rückschritt positiv zu nutzen, indem man sich das Arsenal empirischer Vielfalt und real vorhandener empirischer Lösungen und Lösungsversuche erschließt.

Die Methode, sich dieses Arsenal positiv zu erschließen, kann durch ein DV-System organisiert werden, das der Entwicklung einer Software-Entwicklungs-Umgebung und den Software-produzierenden Unternehmen dadurch dient, daß es lernfähig ist.

Gefordert ist ein lernfähiges System, dessen "Schnittstelle" dem Anwender erlaubt, im ersten Schritt zumindest die schon verwendeten und bewährten Methoden seiner DV- und Organisationsabteilungen

beziehungsweise seines Unternehmens dem System "bekannt" zu machen. Daraus ergeben sich folgende Thesen: Softwareentwicklung muß aufgefaßt werden als ein ganzheitliches und individueller Prozeß, der ausgeht von den Tätigkeiten des "Subjekts Unternehmen", von Projekten, an deren Ende definierte Produkte (Softwaresysteme) stehen.

Das Ziel ist der Bau eines Rahmensystems für die Abwicklung von Projekten im Kontext unternehmensindividueller Entwicklungsumgebungen, damit dieses Rahmensystem die Unternehmen anregt und zwingt Software-Engineering in der Praxis zu betreiben.

Der Zwang ist dann im Idealfall nicht mehr der äußere Sachzwang,

sondern Folgewirkung der sich entwickelnden Symbiose von problemlösendem Subjekt und lernfähigem System, von der Software-Ingenieure der Zukunft leben werden.

Ziel ist der Bau eines Arbeitsinstrumentes für Softwareingenieure, das evolutionäre Entwicklungen im Einsatz von Softwaretechnologie erst möglich macht.

"Revolutionäre Einschnitte" in Unternehmensstrukturen verändern nur die Formen von Entwicklungsprozessen. Die Notwendigkeit solcher Schnitte ist die "historische" Ausnahme. Oberflächliche Radikalität übersieht in der Regel den revolutionären Umwälzungsprozeß, dessen Ausdruck sie ist. Sie versteht es nie diesen Prozeß evolutionär zu nutzen.

Der eigentliche Zweck des geforderten Software-Engineering-Systems ist durch die Aufgabe beschrieben, als Steuerungsinstrument sinnvoller Evolution in revolutionärer Umgebung seinem Anwender zu dienen. Bliebe die Aufgabe, ein solches System im Grundriß zu skizzieren.

*Wilfried Köhler-Frost ist Geschäftsführer der WKF-Consult, Beratungsgesellschaft für Organisationsentwicklung und Informationsverarbeitung mbH, Berlin. Dietrich von Alemann ist Berater für Informationsverarbeitung im selben Unternehmen.

Hinweise auf verwendete Literatur:

Bazert, Die Entwicklung von Software-Systemen, Mannheim/Wien/Zürich 1982

Daenzer, Systems-Engineering, Zürich 1982

GMD: Untersuchung über Maßnahmen zur Verbesserung der Software-Produktion, Bericht Nr. 130 - 135, München/Wien 1980

Hesse, Luft, Keutgen, Rombach, Begriffssystem für die Software-Technik, Informatik-Spektrum Bd. 7/ Heft 4/84

Heuer, Projektmanagement, Würzburg 1979

Luft, Rationaler Sprachgebrauch und orthosprachliche Standardisierung als Grundlage des Software-Engineering, Informatik-Spektrum Bd. 5, Heft 4/82

Platz, Methoden der Software-Entwicklung München/Wien 1983 Schnupp/Floyd, Software, Berlin/New York 79

Sneed, Software-Entwicklungsmethodik Köln-Braunsfeld 1980

Stettner, Softwaretechnologie, Zürich 1984

Technologische Modelle und Ingenieurverfahren

Die Softwaretechnik findet ihre Grundlage immer in den theoretischen und mathematischen Modellen der Softwaretechnologie. Solche Modelle sind zum Beispiel strukturierte Programmierung, Datenabstraktion, Relationsalgebra und -kalkül.

Die Softwaretechnik findet ihre Anwendung immer in den praktischen Alltagsbedürfnissen entspringenden Ingenieurverfahren. Beispiele dafür sind insbesondere die bisher entwickelten Entwurfs- und Spezifikationssprachen wie HIPO, SADT und Jackson (JSD).

Der Experimentalraum von Ingenieurverfahren ist immer die industrielle Produktion im Alltagsbetrieb. In jedem Falle verdient der eigentliche Gegenstand der Ingenieurarbeit größere Aufmerksamkeit: die Softwareproduktion, das heißt die spezielle Logik industrieller Produktionsverfahren, angewandt auf die Produktion von Softwaresystemen.