Gab es jemals ein kontrollierbares "Software-Engineering"? Software-Pionier Harry Marsh Sneed bezweifelt dies in seinem Gastkommentar. [...]
Software Engineering wurde als Begriff auf der NATO Konferenz in Garmisch im Jahre 1968 erstmals geprägt, ein Jahr nach dem Erscheinen des berühmten Leserbriefes von Edsger Djkstra zum Thema „GoTo Statement considered harmful“. Prof. Fritz Bauer von der TU München gab ihm recht und rief nach einer eigenen Engineering Disziplin, um dem Chaos in der Software Entwicklung Herr zu werden. Dieser Anstoß aus der deutschen akademischen Welt wurde von der IT-Industrie – damals noch DV-Industrie – mit Begeisterung aufgenommen. Es entstand eine neue Lehrdisziplin an den Hochschulen und ein neuer Berufszweig in der Industrie.
Die Bezeichnung Software Engineer setzte sich durch, lange bevor es einen international anerkannten Studienweg zu diesem Berufstitel gab. Ich selbst habe Software Engineering propagiert und gelehrt, obwohl ich es nie studiert habe. Ich habe sogar eine Firma mit dem Titel „Software Engineering Services“ in München und Budapest gegründet mit dem Ziel, den ganzen Software-Lebenszyklus von der Systemanalyse bis zur Systemintegration und Abnahme zu unterstützen. Dennoch habe ich mich niemals aus Respekt vor dieser Disziplin als Software Engineer bezeichnet. Ich war eben Programmierer, Analytiker, Designer, Tester und gelegentlich Manager.
Heute gibt es Studiengänge für dieses Fach und man kann einen Titel als Master of Software Engineering erwerben. Was genau zu diesem Fach gehört, wird überall etwas anders ausgelegt, aber im Großen und Ganzen herrscht Einigkeit über das, was ein Software Engineer zu beherrschen hat. Das Software EngineeringProgramm der Carnegie Mellon Universität in Pittsburgh, U.S.A. dient als Vorbild. Dort ist auch das amerikanisches Software Engineering Institut situiert, wo die Normen für Software Engineering Prozesse in der U.S. Industrie entstanden sind.
Es hat schon immer zwei verschiedene Auslegungen dieses Begriffes gegeben, zum einen als Methodenbündel und zum anderen als Prozess. In den 80er Jahren des letzten Jahrhunderts haben ich (und viele andere) versucht, die beiden Auslegungen zu vereinen indem wir die Methoden in einem all umfassenden Prozess zu integrieren versuchten. Es gab eine ingenieurmäßige Anforderungsanalyse = Requirement Engineering, ein strukturiertes Design, eine strukturierte Programmierung und strukturiertes Testen und oben drauf einen Software Engineering Prozess. Aber der Prozess der gedacht war alle Einzelaktivitäten zusammenzubinden hat nie funktioniert. Das viel zitierte Wasserfallmodell war eine Fata Morgana. Es ist nie gelungen alle Anforderungen im Voraus zu erkennen und diese zu beschreiben. Jeder Versuch die Anforderung exakt zu beschreiben endete in einer weiteren Programmiersprache.
Vierzig Jahre nach der Entstehung dieser Disziplin veröffentlichte der weltbekannte IT-Autor und Dozent – Tom DeMarco einen Artikel in der IEEE Software Magazine mit dem provokativen Titel
„Software Engineering – An Idea whose Time has Come and Gone?“
In diesem umstrittenen Beitrag behauptete DeMarco, dass Software Engineering nicht mehr gültig sei, denn Engineering setze Kontrolle voraus – und moderne Software Projekte liessen sich nicht kontrollieren. In Anspielung auf die agile Entwicklung meint er heute, Softwareentwicklungsprojekte sind eigentlich Forschungsprojekte und als solche nicht im Sinne von Engineering beherrschbar. Er setzt damit Software Engineering mit der zweiten Auslegung gleich, nämlich als ein systematischer Managementprozess mit Meilensteinen und Kontrollen. Dazu muss das Projekt kalkulierbar und planbar sein. Das sind aber die wenigsten Softwareprojekte, vorwiegend Wartungs- und Migrationsprojekte. Entwicklungsprojekte sind überhaupt nicht planbar. Wenn es jedoch nicht möglich ist, ein Software Projekt exakt zu planen und zu steuern so wie dies in einem konventionellen industriellen Fertigungsprozess der Fall ist, kann von Engineering keine Rede sein. Also reiten wir mit dem Begriff „Software Engineering“ auf einem toten Pferd.
DeMarco endet seinen Diskurs mit der Feststellung
„I am gradually coming to the conclusion that software engineering is an idea whose time has come and gone. I still believe it makes excellent sense to engineer software. But that is not what software engineering has come to mean. The term encompasses a specific set of disciplines including defined processes, inspections, walkthroughs, requirement engineering, traceability, metrics, precise quality control, rigorous planning and tracking, coding and documentation standards. All of these activities strive for uniformity, conformance, predictability and measurability. (…) This approach has failed”
In der 50 jährigen Geschichte hat es in diesem Sinne Software Engineering nie gegeben. Denn zu keiner Zeit waren die Projekte wirklich „predictable“ und unter Kontrolle. Ich selbst habe alles versucht, mit der Softorg Software Produktionsumgebung die Kontrolle über die Projekte zu gewinnen und bin damit trotz gelegentlicher Erfolge am Ende gescheitert. Sonst wäre ich nicht als alter Softwaresanierer und –Tester in Wien gelandet. Nur mit den Wartungs- und Migrationsprojekten ist es einigermaßen gelungen, die Kontrolle über die Projekte zu gewinnen. In den Entwicklungsprojekten vermochten wir dies nur in Ausnahmefällen.
Das liegt daran, dass in Wartungs- und Migrationsprojekten ein wohldefinierter, messbarer Ausgangszustand gegeben ist – der bestehende Source-Code. Die Erfahrung aus den vielen Projekten im deutschsprachigen Raum hat mich gelehrt, dass Entwicklungsprojekte ohne Vorgänger bzw. Prototyp weder planbar noch kontrollierbar sind. Sie sind Forschungsexperimente. In diesem Sinne stimme ich mit DeMarco überein – außer in einem Punkt: er meinte, dass Software Engineering einmal funktioniert habe. Ich würde behaupten, es hat nie funktioniert. Ab und zu mal, wo die Umstände besonders günstig waren, sind die Projekte an das Ideal nahe herangekommen. Ein Modell aber, das nur für Ausnahmefälle geeignet ist, kann kein gültiges Modell sein. So war der Begriff Software Engineering vom Anfang an unzutreffend. Ein Software Entstehungsprozess ist mit einem industriellen Fertigungsprozess nicht vergleichbar. Software-Entwicklung bleibt ein Geschäft mit hohen Risiken.
*) Harry Marsh Sneed ist einer der Pioniere der Software-Testtechnologie und Dozent für Software Engineering an zahlreichen Universitäten im In- und Ausland. Er hat 23 Bücher seit 1973 veröffentlicht – das bisher letzte Buch über Projekterfahrungen in der deutschsprachigen IT-Welt mit dem Titel „Endstation Wien“ ist bei Books on Demand erhältlich. Derzeit arbeitet er als Softwaresanierer und -Tester für die Ziviltechnik Prentner in Wien-Kagran.
Be the first to comment