25 Nachwort: Die Schule der Software-Ingenieure

Dieses Buch ist vor allem für die geschrieben, die etwas über Software Engineering lernen wollen. Seine Verfasser haben aber in den vergangenen Jahrzehnten begriffen, dass zwischen dem Inhalt des Fachs, der Art, wie man auf diesem Gebiet arbeitet und wie man es vermittelt, keine scharfen Grenzen gezogen werden können. Wir schließen das Buch darum mit einigen Bemerkungen über den Stand und die Probleme, die das Fach Software Engineering als akademische Disziplin hat.

Es liegt auf der Hand, dass wir hier unsere Sicht präsentieren; dass andere Leute eine andere Sicht der Dinge haben, ist uns bewusst. Sie mögen diesen Teil als Diskussionsbeitrag betrachten. Eine intensivere Diskussion täte dem Software Engineering gut.

25.1 Software Engineering in der Praxis

Die Anforderungen wurden unzureichend dokumentiert, es gab auch keine vollständige Entwurfsdokumentation, nur Diagramme der Software-Architektur, und die Prüfungen des Quellcodes beschränkten sich auf ein Walkthrough. Die meisten Tests waren ad hoc, nur wenige konnten systematisch vorbereitet und durchgeführt werden.

Im Unternehmen ist durchaus bekannt, wie man arbeiten müsste, aber die Entwicklerkapazitäten reichen nicht für ein gutes Software Engineering aus. Das ohnehin große Arbeitsvolumen wäre dadurch erheblich gewachsen und der Abgabetermin nicht eingehalten worden.

Aus einem Praktikantenbericht, Universität Stuttgart, 2006

Die Praxis gibt es nicht. Jede Aussage, dass es in der Praxis so oder so sei, stößt auf begründeten Widerspruch, denn die Verhältnisse sind alles andere als homogen. Trotzdem entsteht durch Beratungen und Schulungen, durch Kooperationsprojekte und Prüfung der Praktikantenberichte, die die Studierenden der Softwaretechnik in Stuttgart abliefern müssen, ein Bild der Praxis.

Dieses Bild schmeichelt der Praxis nicht. Zwar kennen wir einige Software-Biotope, in denen gut, selten auch sehr gut gearbeitet wird. In vielen Unternehmen ist die Software-Entwicklung jedoch geprägt von Spezifikationen, die unzulänglich sind oder fehlen, mangelhafter Dokumentation, unsystematischem Test, unter Zeitdruck abgesagten Reviews und mangelnder Kommunikation und Abstimmung in den Projekten. Für eine grundlegende Verbesserung ist die Belastung zu groß und das Vertrauen ins Software Engineering zu gering.

Wenn in Industrieseminaren am zweiten Tag eine gewisse Vertrautheit entstanden ist, hört man ähnliche Aussagen, oft mit einem bitteren Unterton, und es folgt die Frage: »Ist es eigentlich bei uns viel schlimmer als anderswo?« Die ehrliche Antwort ist: »Nein. Im Großen und Ganzen ist es fast überall so.« Und während man das sagt, erinnert man sich an die beruhigende Auskunft des Arztes: »Nein, nein, keine Sorge, das ist keine seltene Krankheit. Letztes Jahr stand sie auf jedem zweiten Totenschein.«

25.2 Stand der Technik und Stand der Praxis

In allen technischen Disziplinen gibt es eine Forschung, die nicht an die harten Randbedingungen der Praxis gebunden ist. Hohe Kosten, hohe Anforderungen an die Qualifikation der Beteiligten, niedrige Produktivität, fehlende Rentabilität dürfen die Forscher nicht daran hindern, einer Frage auf den Grund zu gehen.

Darum kann der Stand der Technik nicht der Stand der Forschung sein; die Praxis muss sich daran orientieren, was mit den verfügbaren Mitarbeitern und unter den Randbedingungen, die die Kunden definieren, möglich und profitabel ist. Das wäre der Stand der Technik. Leider bleibt die Praxis auch hinter diesem Stand weit zurück; vermutlich ist das Software Engineering die einzige Ingenieurdisziplin, in der es notwendig ist, zwischen dem Stand der Technik und dem Stand der Praxis zu unterscheiden. Umgekehrt kann man nicht behaupten, dass alle Vorschläge, die aus der Forschung kommen, viel mit den Problemen zu tun haben, die es in der Praxis so reichlich gibt.

Ganz allgemein ist eine viel engere Kooperation zwischen Forschung und Praxis notwendig. Sie setzt aber voraus, dass auf beiden Seiten einige Illusionen begraben werden: Die Praktiker müssen bekennen, dass sie bislang die Mühe gescheut haben, ihre Erfahrungen zu sammeln und auszuwerten, neue Verfahren, Notationen und Werkzeuge zu erproben und zu verbessern, kurz: auf den aktuellen Stand der Technik zu kommen. Und die Forscher können nicht ihren Anspruch aufrechterhalten, die Lösungen aller Probleme zu kennen, weil viele »Lösungen« nur unter Laborbedingungen funktionieren und versagen, wenn damit keine Lehrbuchbeispiele, sondern echte Aufgaben bearbeitet werden (siehe Abschnitt 3.2.2). Oft hat auch niemand ernsthaft darüber nachgedacht, wie komplizierte Verfahren und Notationen in eine Praxis transferiert werden können, in der Menschen, nicht geklonte Doktoranden arbeiten.

Unter Kooperation verstehen wir, dass beide Seiten einander zuhören, sich selbst wie die andere Seite ernst nehmen und selbstverständlich erwarten, zu geben und zu nehmen. Die Praxis bietet die echten Probleme und den Härtetest für alle Lösungsvorschläge; die Forschung hat das aktuelle Wissen und die Freiheit, Fragen und Unklarheiten auf den Grund gehen zu können. Natürlich gewinnt auch die Lehre durch die Kooperation; die Dozenten können ihre Vorlesungen durch echte Erfahrungen bereichern, und Praktika, Projekte und Studien werden ganz oder teilweise in die Praxis verlagert (vgl. Bleek, Lilienthal, Schmolitzky, 2005; Lichter et al., 2003).

Wer ein anspruchsvolles (d. h. normales) Software-Projekt beginnt, also eines, bei dem Termine, Budget, Anforderungen und Rahmenbedingungen kaum vereinbar sind, hat eine Reihe von Problemen, und er verdient Respekt, wenn er diese Probleme befriedigend lösen kann. Die Forschung kann dabei helfen – und eine Menge lernen.

Die Praxis kann für sich in Anspruch nehmen, dass sie, wie auch immer die Projekte verlaufen, am Ende in der Regel erfolgreich ist; sonst gäbe es längst keine Informatik mehr. Die Horrormeldungen aus den Standish-Reports (siehe Abschnitt 8.7.2) sind unseriös und taugen nicht zur ernsthaften Diskussion. Die Verantwortlichen sollten sich aber nicht darauf verlassen, dass die Software-Mängel, die man heute als normal, als unvermeidbar betrachtet, auch morgen noch toleriert werden. Wenn die Menschen eines Tages an eine Software die gleichen Stabilitätsforderungen stellen wie an eine Straßenbrücke, werden Hersteller mit chaotischen Prozessen und einer nur kosmetischen Qualitätssicherung keine Chance mehr haben. Das ist keine Bedrohung, sondern eine Hoffnung.

25.3 Der Studiengang Softwaretechnik¹

1996 wurde an der Universität Stuttgart ein Versuch begonnen, die Ausbildung der Software-Ingenieure von Grund auf neu zu konzipieren. Die ersten Erfahrungen waren außerordentlich erfreulich, sodass aus dem Versuch ein regulärer Diplomstudiengang wurde (Ludewig, 2000).

Da man bei der Gestaltung eines neuen Studienplans unter den Randbedingungen, die durch die Gesetze, das Ministerium, die Universität und die Fakultät vorgegeben sind, nur wenige Freiheiten hat, muss man diese wenigstens nutzen. Was war (und ist) neu an der Stuttgarter Softwaretechnik? Natürlich ist der Studienplan inhaltlich auf die Ziele abgestimmt. Wirklich neu sind aber die folgenden Punkte:

Die Vorstellung, Software Engineering könne als Zusatz, als Spezialisierung an ein Informatikstudium geklebt werden, wurde zu Gunsten eines eigenständigen Studiengangs Softwaretechnik aufgegeben. Kein Mensch käme auf die Idee, aus Physikstudenten durch eine Spezialvorlesung Elektroingenieure zu machen. Ingenieur ist man nicht dadurch, dass man zwei oder drei einschlägige Bücher gelesen hat, sondern durch eine bestimmte Denkhaltung. Die muss früh vermittelt werden. Parnas ist mit seinem etwa zur selben Zeit entstandenen Studiengang an der McMaster University in Hamilton, Ontario, noch deutlich weiter von der Informatik abgerückt (Parnas, 1999).

Schon im ersten Semester bekommen die Softwaretechniker einen speziellen Programmierkurs; massiv wird das Software Engineering vom dritten Semester an als Programmieren im Großen und Programmieren im Kleinen vermittelt und geübt. (Es wäre klar besser, damit im ersten Semester zu beginnen, das hat sich aber bislang nicht realisieren lassen.) Nach dem dritten Semester führen die Studenten das erste Software-Projekt an einem Simulator durch (Drappa, Ludewig, 2000).

Die Projektarbeit in Gruppen aus zunächst drei, dann bis zu zehn Studenten zieht sich als roter Faden durch das Studium (Ludewig, 2006). Nach einem Programmierprojekt, das gegen Ende des dritten Semesters beginnt, stehen im fünften und sechsten Semester die sogenannten Studienprojekte auf dem Programm, die jeweils ein Jahr lang laufen und pro Teilnehmer etwa 400 Stunden Aufwand erfordern. Diese Projekte beginnen in der Regel mit der Erstellung eines Angebots und enden mit der Übergabe an den Kunden; bei einigen Studienprojekten waren das externe Partner, sonst sind es Mitarbeiter der Lehrstühle, die nicht gleichzeitig als Betreuer agieren dürfen; alle Projekte sind seriös konzipiert und zielen darauf ab, etwas Brauchbares zu schaffen. Projekte vom Typ »Wir implementieren die Siedler von Catan« sind damit definitiv ausgeschlossen.

Schließlich fertigen die zukünftigen Software-Ingenieure noch in einer Dreiergruppe eine Expertise an. Diese sogenannte »Fachstudie« findet meist in der Industrie statt, und unsere Partner dort sind regelmäßig überrascht, wie fundiert die Empfehlungen sind, die sie auf diese Weise bekommen.

Ein mindestens dreimonatiges Industriepraktikum ist obligatorisch; dabei ist durch die Richtlinien sichergestellt, dass die Studenten Einblick in die Praxis gewinnen und in einem Praktikantenbericht über ihre Erfahrungen berichten. Die Praktika können bei beliebigen Firmen stattfinden, vorausgesetzt, dass sich dort mindestens zehn Leute mit Software-Entwicklung befassen. Die Studenten arbeiten in kleinen mittelständischen Betrieben und in Weltkonzernen, in Software-Häusern und in Firmen, die man nicht mit Software in Verbindung brächte. Natürlich dominieren Unternehmen im Raum Stuttgart, aber eine beträchtliche Zahl der Praktika findet in anderen Teilen Deutschlands oder im Ausland statt.

Die Einführung dieses Studienganges hatte vorhersehbare, aber auch überraschende Effekte; wie erwartet haben sich vor allem Studienanfänger mit Neigung zur Praxis für die Softwaretechnik eingeschrieben, und wir sehen Absolventen, die ihre Lektion gelernt haben und ohne Hemmungen Praktikern erklären, wie man Software-Projekte durchführt. Überraschend ist, dass schon nach wenigen Jahren in der Softwaretechnik eine Kultur gewachsen war, die sich deutlich von der älteren Kultur in der Informatik unterscheidet. Die Studenten denken in Teams, und sie argumentieren nicht mit dem theoretisch Möglichen, sondern mit dem Machbaren. Die Prüfungsleistungen der Softwaretechniker liegen im Vergleich mit den Informatikern enger beieinander, die Zahl der besonders guten und der besonders schlechten ist deutlich geringer. In den Firmen des Großraums Stuttgart sind Bewerber mit einem Abschluss in Softwaretechnik besonders gern gesehen.

2009 wurde die Ausbildung der Softwaretechniker vom Diplomstudiengang auf ein Bachelor-Curriculum umgestellt (Ludewig, 2009); ein Master-Studiengang dazu läuft seit 2012. Dabei mussten unter den sachfremden Zwängen dieser »Reform« einige Stärken geopfert werden, vor allem das Anwendungsfach und das Studienprojekt im Anwendungsfach sowie das Industriepraktikum. An der grundsätzlichen Ausrichtung wurde nicht gerüttelt. Es ist nun ganz anders als früher unser Anliegen, die Studenten darauf hinzuweisen, dass man zwar in sechs Semestern Bachelor werden kann, aber nicht muss. Wer dafür aber wohlüberlegt acht Semester einsetzt, indem er eines für ein Industriepraktikum, eines für einen Studienaufenthalt im Ausland verwendet, hat nicht ein Jahr verloren, sondern ein sinnvolles Studium gewonnen.

25.4 Nachfrage und Angebot auf dem Ausbildungsmarkt

In Zukunft wird die Weiterbildung der Software-Ingenieure einen eigenen Schwerpunkt der Lehre darstellen. Noch lange wird die Mehrheit derer, die als Informatiker arbeiten, keine einschlägige Ausbildung haben. Die von der Politik erzwungene Verkürzung des ersten (und für viele letzten) Studiums wird unvermeidbar dazu führen, dass die Absolventen im Mittel weniger gut auf ihren Beruf vorbereitet sind als die Diplom-Informatiker. Auch das wird den Bedarf an Weiterbildung erhöhen.

Leider steht dem Bedarf kein entsprechendes Angebot gegenüber, denn es gibt viel zu wenige Dozenten, die bereit und in der Lage sind, Software Engineering als Ingenieurdisziplin zu lehren und vorzuleben. Die Elektrotechnik hat sich zu Beginn des 20. Jahrhunderts von der Physik und vom Maschinenbau gelöst und zu einem eigenen starken Fach entwickelt. Solange das Software Engineering diesen großen Schritt nicht wagt, ist nicht zu erwarten, dass es in den Hochschulen personell das Gewicht erhält, das es nach seiner wirtschaftlichen Bedeutung längst haben müsste.