Software Engineering

1968

„What we need, is software engineering“, sagte F.L. Bauer 1968 und organisierte die Konferenz in Garmisch, die unser Fach begründete. Nachzulesen in seinem Bericht über diese Konferenz im Informatik-Spektrum 25 Jahre danach:

Verärgert darüber, daß am Ende nicht mehr als ein weiteres rein wissenschaftliches Projekt herauskommen könnte, bemerkte ich eines Tages: „The whole trouble comes from the fact that there is so much tinkering with software. It is not made in a clean fabrication process, which it should be.“ Als ich feststellte, daß dies einige meiner Kollegen schockierte, setzte ich mit dem Ausspruch nach: „What we need, is software engineering.“ Das schlug ein. (Zitiert nach [1])

Im Konferenz-Band [2] heißt es so:

The phrase “software engineering” was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.

Softwareentwicklung sollte also eine Ingenieursdisziplin werden mit systematischer Arbeitsweise, etwa dem Schema folgend

Planen – Konstruieren – Fertigen – Prüfen – Installieren – Warten.

Wie es einen Bauplan für ein Haus und eine Konstruktionszeichnung für eine Maschine braucht, bedarf ein Softwaresystem einer Architektur.

Softwarearchitektur

Softwarearchitektur ist die Königsdisziplin des Software Engineering. Sie befasst sich mit der Gestaltung von Softwaresystemen im Ganzen, mit ihrer fachlichen Funktionalität und den Schnittstellen zur Außenwelt sowie der inneren Struktur im Großen wie im Kleinen. Bei der Gestaltung im Großen geht es um den Aufbau eines Systems aus Modulen, deren Interaktion in ausführbaren Prozessen und um die Verteilung des Systems auf Hardwarekomponenten. Im Kleinen geht es um die Gestaltung einzelner Module: um ihre Außensicht einerseits, d. h. um ihre Schnittstelle zu anderen Modulen, und um ihre innere Struktur andererseits, also darum, mit welchen Funktionen sie auf welchen Daten operieren.

Das Wort Architektur hat sich in der IT als „gehobene“ Bezeichnung für Strukturen verschiedener Art eingebürgert, so auch bei Software. Softwarearchitektur ist ein viel strapaziertes Schlagwort mit vielerlei Interpretationen, manchmal auch mit dem Verständnis, Architektur an sich sei etwas Gutes. Das stimmt nicht, es gibt auch schlechte Architektur. Manchmal heißt es: „Unsere Software hat keine Architektur“. Auch das stimmt nicht, jedes System hat eine. Meist ist gemeint, dass seine Struktur schlecht oder uneinheitlich ist, undokumentiert nur in den Köpfen einiger Programmierer steckt oder gänzlich unbekannt ist. Sie existiert dennoch.

Solche Strukturen werden häufig grafisch mit Kästchen und Strichen dazwischen dargestellt, meist ohne präzise festzulegen, was sie bedeuten. Die Kästchen stehen für Komponenten, Module, Funktionen, Dateien, Prozesse, die Striche und Pfeile für Beziehungen aller Art, Verweise, Datenflüsse, Aufrufe und manches mehr. Oft herrscht darüber keine Einigkeit, nicht einmal innerhalb eines Projekts, einer Abteilung, schon gar nicht innerhalb von ganzen Unternehmen der Wirtschaft, ebenso wenig in wissenschaftlichen Instituten.

Als Softwarearchitektur bezeichne ich die statischen und dynamischen Strukturen, die ein Softwaresystem prägen, betrachtet aus 3 Perspektiven, Sichten genannt: Anwendungs‑, Konstruktions- und Programmsicht. In jeder wird anders über das System gedacht. Denken braucht Sprache. Alle Menschen denken in ihrer Muttersprache, Musiker in Noten, Architekten in Zeichnungen, Mediziner in lateinischen Fachbegriffen, Mathematiker in Formeln. Und Informatiker denken in Programmiersprachen. Das genügt aber nicht, um Softwarearchitektur zu gestalten, jede Sicht hat ihre eigenen Begriffe, Konzepte und Darstellungsformen:

1. 1.

   Anwendungssicht

   Dafür muss man die Sprache der Anwender verstehen und in Konzepten und Begriffen der Anwendung denken, welcher Art sie auch sein mag, betriebswirtschaftlich, technisch, wissenschaftlich, medial etc. Bei betrieblichen Systemen geht es um Daten, fachliche Funktionalität und Geschäftsvorgänge sowie Interaktion mit Benutzern (Dialoge) und Nachbarsystemen, bei technischen Systemen um die physische Maschinerie und Regelungsverfahren. Fachliche Sachverhalte werden mit natürlicher Sprache und mehr oder weniger formalen Darstellungen beschrieben.

2. 2.

   Konstruktionssicht

   Hier geht es um die modulare Gestaltung eines Softwaresystems, d. h. seinen Aufbau aus Bausteinen mit ihren statischen und dynamischen Beziehungen. Grafische Darstellungen spielen eine große Rolle, informelle ebenso wie solche mit formaler Syntax und Semantik, etwa UML. Zudem wird auch hier natürliche Sprache verwendet. Einerseits prägen die fachlichen Konzepte der Anwendungssicht die Konstruktion, sie sollen darin deutlich erkennbar sein. Und zum anderen wird in der Konstruktion die Systemplattform festgelegt, auf der die Software läuft.

3. 3.

   Programmsicht

   Hier dominieren formale Sprachen: Programmiersprachen, Schnittstellen von Frameworks und Bibliotheken (APIs), Kommunikationsprotokolle. Entwicklungsumgebung und -werkzeuge sowie Programmierregeln prägen die Arbeitsweise. Die Programmstrukturen im Großen sind durch die Konstruktion vorgegeben, insbesondere die Verzeichnisstruktur des Quellcodes durch die Modularisierung.

Auf den ersten Blick erscheinen die Architektursichten wie Entwicklungsphasen. Man kann sie auch so sehen, ich jedoch betrachte die Architektur eines Softwaresystems in erster Linie vom Ergebnis her – also wie sie ist oder sein soll(te) –, weniger in ihrer Entstehung. Man stelle sich vor, ein betriebsbereites Softwaresystem müsse vor seinem Einsatz abgenommen und zugelassen werden, wie etwa Züge, neue Automodelle oder medizinische Geräte. In der dazu nötigen Prüfung wird seine tatsächliche Architektur untersucht, gestützt auf ihre Dokumentation und vor allem wie sie sich im Code manifestiert, und nicht wie sie entstanden ist. Bei dieser ergebnisorientierten Betrachtung spielen Entwicklungsprozesse und Vorgehensmodelle keine Rolle, gleichgültig ob phasenorientiert oder agil.

Immer wieder begegnet man der Unterscheidung zwischen „grob“ und „fein“, etwa als Grob- und Feinspezifikation. Das ist sinnvoll, wenn die grobe Form eine präzise Abstraktion der feinen ist, nicht jedoch, wenn grob nur bedeutet „so ungefähr“. Eine Grobdarstellung ist auch gut, wenn sie einen guten Überblick gibt über einen komplexen Sachverhalt mit vielen Details. Keinesfalls jedoch darf man Anwendungssicht als grob verstehen, die Konstruktionssicht als ihre Verfeinerung. Präzision auch im Detail ist in allen Sichten wichtig.

Softwareentwicklung

Ingenieurgemäße Softwareentwicklung basiert natürlich auf einem Architekturplan, allerdings gibt es in der Praxis auch heute noch viel „tinkering“ (F.L. Bauer), nur wird es nicht mehr basteln genannt, sondern agil.

Über die Jahrzehnte sind viele Konzepte für das Vorgehen in Softwareprojekten publiziert und praktiziert worden. Für das strukturierte Vorgehen in Phasen wurden diverse Bezeichnungen anhand grafischer Darstellungen geprägt: Wasserfall‑, Spiral‑, V‑Modell. Diese Metaphern sind sachlich wenig erhellend, aber Gegenstand weltanschaulicher Auseinandersetzungen.

In großen Organisationen, insbesondere auch in staatlichen, gibt es eine Tendenz zu formal-bürokratischer Ausformung von Phasen- und Reifegradmodellen. Die bekanntesten Beispiele sind das Capability Maturity Model (CMMI) des SEI in den USA und das deutsche V‑Modell. Auf der anderen Seite und als Gegenbewegung sind vor gut 20 Jahren die agilen Methoden entstanden, beginnend mit Extreme Programming (XP), heute überwiegend Scrum.

Den Agilen ist es fremd, einen Plan zu machen; Anforderungen und einen Architekturentwurf aufzuschreiben, gilt als vertane Zeit und Mühe. Stattdessen wird in einer Folge von Schritten, meist Sprints genannt, gleich etwas programmiert, das dem Anwender taugen könnte. Wenn dabei verkorkste Programmstrukturen entstehen, wird Refactoring gemacht. Das ist doch seltsam: Man macht sich erst mal keine Gedanken über die Softwarestruktur, aber wenn sie dann nach mehreren Programmiersprints verdorben ist, fängt man an zu reparieren. Das ist kein strukturiertes Arbeiten. Den agilen Methoden mangelt es an ingenieurgemäßer Methodik; konsequenterweise sagt der Scrum-Guide nichts zu Software Engineering.

Bertrand Meyer bietet in seinem Buch „Agile!“ eine profunde, sachliche Darstellung, Analyse und Beurteilung der agilen Methoden. Dem habe ich nur eines hinzuzufügen: Das Beste an den agilen Methoden ist ihre Bezeichnung: agil – ein grandioser Marketing-Gag. Wer traut sich denn zu sagen: Wir arbeiten nicht agil, sondern strukturiert?

Auf den Punkt gebracht: Egal wie ein Team arbeitet, mit Ingenieurmethode, agil oder sonst wie – die Softwarearchitektur muss bedacht werden. Man kann sie vor dem Programmieren entwerfen und auch aufschreiben oder genialisch in den Code hacken – man muss die Softwarearchitektur bedacht haben. Am Ende ist auf jeden Fall etwas niedergeschrieben – im Code. Hoffentlich taugt der. In code veritas.

Teamarbeit

Softwaresysteme sind komplex und groß, sie können aus Hunderttausenden, gar Millionen Zeilen Code bestehen. Ein Einzelner kann sie nicht entwickeln, Teamarbeit ist nötig. Diese setzt Struktur voraus: in der Software eine Architektur und im Team eine Aufgabenteilung; nicht jeder kann alles jederzeit machen.

In jüngerer Zeit wird Teamarbeit verklärt: Bunt gemischte Gruppen, ohne Chef, in flachen Hierarchien, eigenverantwortlich und selbstorganisiert, kriegen alles locker hin in täglichen Stand-up-Meetings, von Sprint zu Sprint. Tiefes und gründliches Nachdenken Einzelner, beispielsweise über Architekturaspekte wie die Modularität einer Software, ist nicht gefragt. Im Wikipedia-Artikel über Scrum steht: „Das Entwicklungsteam ist für die Lieferung … verantwortlich … organisiert sich selbst“.

Verantwortung kann man nicht einem Team zuschreiben, sondern nur einzelnen Personen. Und ein professionelles Projektteam bildet sich nicht wie eine Gruppe von Freunden zur Organisation einer Party, es wird erst einmal zusammengestellt von jemandem mit Personalverantwortung. Wenn dann nichts weiter festgelegt wird, bildet sich zwar eine informelle Organisation und auch eine Führung, aber es mangelt an klaren, verbindlichen Zuständigkeiten. Ein Freund karikiert das mit dem Spruch: „Team = Toll, ein anderer macht’s“.

Eine meiner fundamentalen (Berufs‑)Lebenserfahrungen lautet dagegen: Menschen wollen und müssen geführt werden. Selbstverständlich kommt die militärische Art der Führung mit Befehl und Gehorsam für Softwareentwickler nicht infrage, eher schon die des Fußballtrainers einer Profimannschaft oder des Dirigenten eines Sinfonieorchesters. Ein Projektleiter muss fachlich kompetent und überzeugend sein, zugleich kommunikativ und motivierend, die Mitarbeiter anleiten und dafür sorgen, dass sie gute Arbeitsergebnisse erzielen (können). Anlässlich des 25. Jahrestages der Garmischer Software-Engineering-Konferenz habe ich in einem Artikel im Informatik-Spektrum etwas geschrieben, das auch heute noch gilt:

Ein guter Geist im Team ist für den Erfolg eines Softwareprojekts wichtiger als alle Technik. Deshalb muss sich das Management ständig um die Bedingungen für ein gutes Klima bemühen – ein Manager muss Berufslebensqualität schaffen. Entstehen kann das Klima natürlich nur im Team selbst, alle tragen dazu bei; je besser Verständigung und Verständnis, desto besser das Klima. [3]

Zum Schluss ein Wunsch

Ein Rückblick auf ein Vierteljahrhundert Software-Engineering-Preis zeigt mir, dass sich ein Großteil der Arbeiten mit analytischen Verfahren befasst, etwa Analyse von Code und Modellen, konstruktive Methoden kommen dagegen kaum vor. Bedauerlich, denn Software Engineering ist die Lehre vom Gestalten, Konstruieren, Bauen und Entwickeln von Softwaresystemen. Warum gibt es nicht an einigen Universitäten eine Software-Engineering-Schule, die normativ sagt: So macht man es? Es dürfen gerne zwei oder drei miteinander wetteifern, eventuell mit unterschiedlicher Ausrichtung hinsichtlich der Systemarten, etwa technische, betriebliche, mediale Systeme.

Liegt es an der Praxisferne oder am kurzatmigen Wissenschaftsbetrieb, in dem vor allem sechs seitige Artikel publiziert werden mit dem Ziel, den Zitierungsindex zu verbessern? Leider werden kaum noch Lehrbücher geschrieben. Ich wünsche mir eine konstruktive Software-Engineering-Lehre, als Buch, gerne auf Papier und natürlich digital, ergänzt durch eine Website mit Code-Beispielen und weiteren Materialien.

Die meisten Informatik-Absolventen, die in die Praxis der Wirtschaft gehen, arbeiten an der Entwicklung von Software, für neue Systeme ebenso wie für bereits laufende. Ihnen auf den Weg mitzugeben, wie man das konkret macht, dem sollte eine solche Lehre dienen. Vielleicht heißt es im Unternehmen dann mal: Wir folgen der X‑Schule – das wär’ doch was.

Und es könnte Software-Engineering, unserem praktisch sehr relevanten Fach, wieder zu Ansehen in der Öffentlichkeit verhelfen, aus der es, ebenso wie die Informatik, verschwunden ist, überwuchert von den allgegenwärtigen Schlagwörtern.

Literatur

1. 1.

   Bauer FL (1993) Software Engineering – wie es begann. Informatik Spektrum 16(5):259

   Google Scholar 

2. 2.

   SOFTWARE ENGINEERING, Report on a conference sponsored by the NATO SCIENCE COMMITTEE, Garmisch, Germany, 7.–11. Okt. 1968, Kap. 1, S. 13.

3. 3.

   Denert E (1993) Software-Engineering in Wissenschaft und Wirtschaft: Wie breit ist die Kluft? Informatik Spektrum 16(5):299

Autor und Copyright

Ernst Denert
ernst.denert@web.de

© Springer-Verlag Berlin Heidelberg 2019
Open Access Dieser Artikel wird unter der Creative Commons Namensnennung 4.0 International Lizenz veröffentlicht.