|
Die Softwarekrise
Der Begriff Softwarekrise entstand Mitte der 1960er Jahre. Der Begriff Softwarekrise wird auch heute noch häufig verwendet. Sie wird in der Regel als Grund für die Notwendigkeit neuer Ansätze im Software-Engineering oder in der Software-Engineering-Ausbildung genannt. Das wirft die Fragen auf:
Kann eine Krise drei Jahrzehnte dauern?
Ist die Softwarekrise mehr als nur ein triviales Verkaufsargument für neue Methoden, Techniken und Werkzeuge der Softwareentwicklung?
Ist Softwarekrise (Softwarekrise ist ein Begriff aus der Frühzeit der Informatik für die Schwierigkeit, nützliche und effiziente Computerprogramme in der erforderlichen Zeit zu schreiben) ein Begriff für einen bereits weit verbreiteten Zustand, mit dem sich die Softwareindustrie abgefunden hat?
Viele Softwareprodukte zeigen dem Anwender und dem Entwickler immer wieder Probleme. Beispielsweise müssen Sie in einem Programm zweimal auf die Schaltfläche Speichern drücken, um sicherzustellen, dass Sie es wirklich gespeichert haben. Der Entwickler des Programms beweist in einer Standarddemonstration, dass es auch mit einer Memory-Aktion funktioniert. Und doch, nach einer langen Zeit der Arbeit mit dem Programm, findet der Anwender seine Beobachtung bestätigt. Ein unkontrolliertes Leben von Software kann leicht zu einem lebensbedrohlichen Sicherheitsrisiko werden. Von Juni 1985 bi
s Januar 1987 ereigneten sich in verschiedenen kanadischen und US-amerikanischen Kliniken insgesamt sieben bekannte Bestrahlungsunfälle, bei denen Patienten erhöhten Strahlendosen ausgesetzt waren. Mindestens vier der Unfälle führten nachweislich zum Tod des Patienten. Lange Zeit hat der Hersteller das Fehlverhalten des Bestrahlungsgerätes bestritten. Es wurde angenommen, dass der massive Schaden für den Patienten durch Bedienungs- und Behandlungsfehler des Krankenhauspersonals oder durch unsachgemäße Behandlung der betroffenen Patienten an anderer Stelle verursacht wurde. Erst nach hartnäckigen Recherchen verschiedener Krankenhausphysiker führten unter anderem Fehler in der Dosierungssoftware zu der tödlichen Überdosierung. Interessanterweise war auch hier eine Abweichung vom normalen Betriebsablauf in einer speziellen Konstellation, d.h. die unkontrollierte Lebensdauer der Software, eine Ursache für das Auftreten fataler Fehler. Die Software eines Therac 25 (Der Therac-25 war ein Strahlentherapiegerät der Firma Atomic Energy of Canada Limited aus dem Jahr 1982 nach den Geräten Therac-6 und Therac-20) das Bestrahlungsgerät ist weit weniger komplex als die in Flugzeugen, Zugbeeinflussungsanlagen, Kernkraftwerken oder in weltweit operierenden Daten- und Kommunikationsnetzen verwendeten Softwaresysteme. Wie viel mehr müssen wir befürchten, dass diese weitaus komplexeren Softwaresysteme, die weitaus mehr Menschen betreffen, zu Katastrophen führen könnten? In einem modernen und hochtechnisierten Industrieland spielt der von Ingenieuren organisierte Entwicklungs- und Produktionsprozess eine entscheidende Rolle im Gegensatz zur manuellen oder künstlerischen Produktion. Eine gleichbleibend hohe Qualität industrieller (Massen-)Produkte kann nur mit einem ausgereiften Entwicklungs- und Produktionsprozess erreicht werden.
Wir betrachten die Planung eines Bauvorhabens als erstes Beispiel für einen etablierten Entwicklungsprozess.
Baunormen regeln die einheitliche Auslegung, Berechnung, Ausführung und Instandhaltung von Bauwerken. Baunormen basieren auf der Verallgemeinerung der mathematischen und wissenschaftlichen Grundlagen der Bauphysik für eine vereinfachte und rationelle Nutzung in der Praxis. Das Baurecht ist eine Regelung und Ordnung des Bauprozesses zum Schutz der Interessen der Allgemeinheit und zur Gefahrenabwehr. Die Bauaufsichtsbehörde (Landesbaupolizei) prüft und überwacht die Bauausführung nach den Vorschriften der Bauordnung und des Baurechts auf Lage, Festigkeit, Brandschutz und Gesundheit.
Ein weiteres Beispiel für einen technischen Entwicklungs- und Fertigungsprozess findet sich in der Automobilindustrie. An der Produktion eines Fahrzeugs sind auch eine Vielzahl unterschiedlicher Berufsgruppen beteiligt:
Zum Beispiel Maschinenbauingenieur, Elektroingenieur (Elektrotechnik ist ein Fachgebiet, das sich in der Regel mit dem Studium und der Anwendung von Elektrizität, Elektronik und Elektromagnetismus beschäftigt), Produktionstechniker, ldots. Ingenieure verschiedener Disziplinen bringen ihr Wissen in den Entwicklungs- und Produktionsprozess ein und nutzen wissenschaftliche Erkenntnisse und Prinzipien zur Lösung anstehender Aufgaben.
Die vielen an der Entwicklung Beteiligten arbeiten durch direkte Kommunikation und weitgehend standardisierte Dokumentation zusammen. Der Produktionsprozess wird detailliert geplant. Produktions- und Wartbarkeitseinschränkungen werden bereits in der Produktentwicklung berücksichtigt.
Aus Kostengründen wird bei der Entwicklung und Produktion darauf geachtet, möglichst auf vorhandene Standardkomponenten zurückzugreifen.
Dabei spielt es keine Rolle, ob ein bestimmtes Normteil selbst gefertigt wird oder ob es von Zulieferern bezogen wird, wodurch die Fertigungstiefe in der eigenen Produktion reduziert wird. Bevor das erste Fahrzeug ausgeliefert werden kann, muss eine Typgenehmigung den sicheren Betrieb und die Einhaltung der Sicherheitsnormen bestätigen.
Die klassischen Ingenieurdisziplinen haben eine Struktur, die in der Softwarebranche bis heute nicht erkennbar ist. Es gibt weder verbindliche Standards in der Softwareindustrie, die die Anwendung geeigneter Verfahren und Methoden vorschreiben, noch gibt es so etwas wie eine Aufsichtsbehörde, die die Entwicklung von Softwareprodukten überwacht.
Der Stand der Softwareentwicklung wird oft an der Qualität des Softwareprodukts gemessen. Softwareprodukte werden direkt oder indirekt von Menschen”hergestellt”. Dies bedeutet, dass Qualitätsmängel von Softwareprodukten auf “Qualitätsmängel” der an der Softwareentwicklung beteiligten Personen zurückzuführen sind!
Er ist in diesen Herstellungsprozess von Anfang bis Ende eingebunden. Dabei sind die Softwareentwickler wesentlich für die Qualität des Endproduktes verantwortlich.
Im Folgenden werden einige Eigenschaften von Softwareentwicklern beschrieben, die für die Entwicklung von Engineering-Software gefährlich oder unerträglich sind.
Software wird grundsätzlich selbst geschrieben, weil der Kauf von Standardkomponenten verpönt ist. Dies bedeutet zusätzlichen Aufwand und unbeabsichtigte Redundanz, da viele Komponenten mehrfach entwickelt werden; die Komplexität der Aufgabe wird unterschätzt; die eigene Problemlösungskompetenz für die Entwicklung dieser Softwarekomponente wird überschätzt und der Aufwand für die Entwicklung einer neuen Komponente wird unterschätzt. Softwareentwickler lehnen neue Konzepte und Verfahren ab und verweisen auf ihre langjährige Berufserfahrung. In dieser Situation hofft er auf Hilfe durch viel gepriesene innovative Methoden, Techniken und CASE-Tools im Gegensatz zur sonst vorherrschenden Reserve.
Viele Softwareentwickler sind nicht sehr motiviert, Dokumentation zu erstellen. Die Architekten geben die Pläne an ihre Maurer weiter, die daraus ein Haus bauen. Der Softwareentwickler verzichtet auf den Plan, er ist Architekt und Maurer in einer Person; die Motivation, seine Arbeit zu planen und zu dokumentieren, ist daher nicht besonders hoch. Dokumentation wird nicht als Teil des Softwareprodukts oder als wichtiger Teil des Softwareentwicklungsprozesses betrachtet.
Dementsprechend verzichten viele Entwickler natürlich auf Dokumentation und bevorzugen einen Service, der ihren Ruf im Unternehmen stärkt, d.h. sie schreiben nur Quelltext und keine Dokumentation. Entwickler, die es für sinnvoll halten, dies zu dokumentieren, können dies oft nicht tun, da der Projektplan seit langem keine Dokumentation mehr vorsieht. Für Software, die für Ihre eigene Entwicklungs- oder Produktionsumgebung entwickelt wurde, existiert in der Regel nur das Tastaturlayout. Technische Erklärungen und Gründe für Optimierungen werden nicht ausreichend berücksichtigt. Strukturelle Zusammenhänge zu verdeutlichen, Entscheidungen über das WARUM und nicht nur über das WIE der Funktionen zu treffen, wird oft ausgelassen. Die Entwicklungsdokumentation enthält selten aussagekräftige Grafiken. Formale oder standardisierte grafische Anzeigesprachen wie ER (1) oder SDL (2) Diagramme sind in der Dokumentation kaum enthalten. Die Entwicklungsdokumentation ist oft irreführend oder ungenau formuliert und weist in einigen Fällen sogar sprachliche Defizite auf.
Die Folgen dieser Aktion werden erst viel später sichtbar. Ein Großteil der heute eingesetzten Software ist entweder gar nicht oder nur unzureichend in Bezug auf Struktur und Funktionalität dokumentiert. In vielen Fällen sind die Entwickler der Software nicht mehr verfügbar. Fehlersuche, notwendige Anpassungen oder Funktionserweiterungen führen zu einer Wartungsfalle. Das bedeutet, dass die Einarbeitungszeit für die Softwaresysteme sehr zeitaufwendig und fehleranfällig ist.
Der Softwareentwickler verkürzt den Herstellungsprozess (die Softwareentwicklung) und beginnt seine Entwicklungsarbeit mit der Produktrealisierung, d.h. mit der Implementierungsphase. Im Beispiel des Automobilingenieurs würde dies bedeuten, ein Auto ohne Bezeichnungen herstellen zu wollen.
Anhand dieser Beschreibung wird verständlich, dass Software ein Eigenleben hat. Änderungen führen oft zu unerwarteten und unkontrollierten Reaktionen des Softwaresystems; die möglichen Gefahren durch fehlerhafte Software lassen sich kaum abschätzen.
Der Leiter der Softwareentwicklung wird vom Softwareentwickler besprochen (Softwareentwicklung ist der Prozess der Computerprogrammierung, Dokumentation, Test und Fehlerbehebung bei der Erstellung und Wartung von Anwendungen und Frameworks, die zu einem Softwareprodukt führen) weil seine Beteiligung an der Softwareentwicklung eher in der Steuerung des Entwicklungsprozesses als in der konkreten Entwicklungsarbeit zum Ausdruck kommt.
Seine Entscheidungen haben jedoch einen entscheidenden Einfluss auf den Entwicklungsprozess.
Aufgrund des enormen Zeit- und Kostendrucks hinkt das Entwicklungsteam bei vielen Projekten fast immer hinterher. Die Angst vor noch größeren Verzögerungen im Zeitplan führt zur Ablehnung neuer Methoden und Werkzeuge.
Um die Produktivität zu steigern, vertrauen die Menschen hingegen auf die Versprechen, die den Einsatz neuer CASE-Tools begünstigen. In den meisten Fällen wird nicht berücksichtigt, dass die Methoden, auf denen die CASE-Tools basieren, erst von den Entwicklern erlernt werden müssen.
Seine Beteiligung ist eigentlich sehr prominent. Ohne einen Kunden gäbe es kein Softwareentwicklungsprojekt. Ohne die Wünsche des Kunden gäbe es keine Entwicklungsvorgaben. Doch gerade diese Kundenorientierung beeinflusst die Softwareentwicklung oft viel stärker als der Kunde oder die anderen am Softwareentwicklungsprozess Beteiligten wissen. Er ist daher auch mitverantwortlich für die Ergebnisse des Softwareentwicklungsprozesses. Die Ermittlung der tatsächlichen Kundenbedürfnisse ist ein wesentlicher Aspekt einer erfolgreichen Softwareentwicklung. Allerdings ist es für den Kunden oft schwierig, seine Wünsche mit ausreichender Präzision zu übermitteln. Im weiteren Projektverlauf lernt der Kunde durch Gespräche mit dem Softwarehersteller mehr und mehr von den Möglichkeiten des Tools. Alte Anforderungen werden korrigiert und neue Anforderungen an die Werkzeugfunktionalität hinzugefügt. Dieser an sich sehr positive Effekt kehrt sich dann ins Gegenteil um, wenn der Kunde bis zur Fertigstellung des Werkzeugs ungeprüft neue Anforderungen einbringt.
Der Kunde will verständlicherweise das Beste für sein Geld . Natürlich sollte sein Werkzeug auch mit den neuesten Methoden und Werkzeugen entwickelt werden. Hier besteht eine große Gefahr. Der Kunde nimmt die von Methodenexperten initiierten Modetrends auf und fordert diese neuen Techniken vom Softwarehersteller, unabhängig davon, ob das Entwicklungsteam beispielsweise im Umgang mit diesen Techniken und Methoden erfahren ist, unabhängig davon, ob durch den Einsatz dieser Methoden eine Qualitätssteigerung nachgewiesen werden kann.
Man hört oft den Satz”Ich habe einen ausgezeichneten Mann zur Hand, der mir meine Werkzeuge schreibt”. PC-Freaks aller Art kommen zu solchen Aufträgen. Im Nebenerwerb: Studenten, Lehrer, Betriebswirte,…. Softwareprodukte, die dann von Lehrern zur Verwaltung von Prüfungsaufgaben, von Versicherungsvertretern zur Verwaltung von Verträgen oder zur Berechnung von Retouren oder von Ärzten zur Unterstützung der Abrechnung eingesetzt werden.
Andererseits werden die Kunden von akademischen Titeln geblendet. Die Software-Engineering-Kompetenz wird automatisch dem Diplom-Ingenieur oder Informatiker zugeordnet.
Jede Veränderung führt den Kunden zurück zum PC-Freak. Ist der freundliche Helfer nicht mehr verfügbar, wird ein Ersatz gesucht, der notwendige Erweiterungen in das Tool einbringt, Fehler beseitigt, Anpassungen an neue Hardware oder ein neues Betriebssystem vornimmt (Ein Betriebssystem ist eine Systemsoftware, die Computerhardware und Software-Ressourcen verwaltet und gemeinsame Dienste für Computerprogramme bereitstellt). Natürlich werden ähnliche Preise wie bei der Erstprogrammierung erwartet.
Der Wert von Softwareprodukten wird stark über- oder unterschätzt. Solange dieser Bedarf besteht, wird ein Softwareentwicklungsprozess mit entsprechend niedrigem Engineeringaufwand auch zu verkaufsfähigen und, gemessen am Wert, teuren Produkten führen. Solange die Beratung beim Softwarekauf und die anschließende Betreuung und Wartung nicht berücksichtigt werden, werden hochwertige Produkte mit Update- und Hotline-Service den Preisvergleich nicht bestehen. Solange ein Kunde – und hier sind nicht nur Privatkunden, sondern auch Unternehmen gemeint – mit Raubkopien arbeitet, weil er Angst vor dem Preis für den Kauf des’selten’ verwendeten Tools hat, oder man die’Usability’ vor der Einführung eines Tools testen will, wird die professionelle Softwareentwicklung weiter ihrer wirtschaftlichen Basis beraubt.
In jüngster Zeit wurde jedoch eine Vielzahl von technischen und methodischen Innovationen von Beratern in den Entwicklungsprozess eingebracht. Diese neuen Methoden und Techniken werden oft in Form von Büchern oder in Seminaren, die ein großes Publikum ansprechen, bekannt gemacht. Die Berater finden oft über ihre Methoden den Weg in den Softwareentwicklungsprozess. Dabei beeinflussen externe Berater einerseits den internen Entwicklungsprozess des Unternehmens und andererseits potenzielle Kunden.
Die Software-Engineering-Beratung hat sich mittlerweile zu einem eigenständigen und lukrativen Geschäftsfeld entwickelt.
International tätige Veranstalter bieten mehrmals im Jahr unter der Leitung von Beratern mit internationalem Ruf” Tag für Tag Seminare zu verschiedenen Themen an verschiedenen Standorten an.
Darüber hinaus versuchen Marktberichte Klarheit in das Labyrinth (Into the Labyrinth ist eine britische Kinderfernsehserie) von Methoden und CASE-Tools im Bereich der Softwaretechnologien zu bringen. Objektorientierte, schnelle Anwendungsentwicklung – Integriert – CASE’: OO-RAD (Rapid Application Development ist sowohl ein Oberbegriff für Alternativen zum herkömmlichen Wasserfallmodell der Softwareentwicklung als auch der Name für James Martins Ansatz zur schnellen Entwicklung) -I-CASE’) dienen dazu, innovative, neue Methoden und Werkzeuge von etwas weniger neuen Vorgängern zu unterscheiden (‘Objektorientierte Programmierung (Objektorientierte Programmierung ist ein Programmierparadigma, das auf dem Konzept der “Objekte” basiert, die Daten in Form von Feldern, oft als Attribute bezeichnet, enthalten können; und Code in Form von Verfahren, oft als Methoden bezeichnet) OOP’). Es entsteht der Eindruck, dass neue Methoden schneller entwickelt werden, als sie angewendet und getestet werden können.
Im Methodenwettbewerb bleibt der Adressat, der lernbegierige Softwareentwickler, das auf methodische Innovation des Softwareentwicklungsprozesses fokussierte Softwareunternehmen auf der Strecke.
Mit dem teuren CASE-Tool und der unkontrollierten Methode allein gelassen, kehren viele Verantwortliche zu dem verpönten und sicherlich oft unangemessenen, aber bewährten”Vorgehensmodell” zurück. Die funktionalen und qualitativen Anforderungen an Softwareprodukte wachsen, die enttäuschten und unsicheren Entwickler werden sich selbst überlassen und der Reifegrad des Softwareentwicklungsprozesses stagniert.
Hochschullehrer sind akademische Lehrer und Ausbilder von Studenten, die für die Kenntnisse, Fähigkeiten und Fertigkeiten ihrer Absolventen verantwortlich sind. Mit einer Verzögerung von mehreren Jahren wird die Universität auch den Softwareentwicklungsprozess beeinflussen.
Informatik (Informatik beschäftigt sich mit den theoretischen Grundlagen der Information und Berechnung, zusammen mit praktischen Techniken zur Umsetzung und Anwendung dieser Grundlagen) und Datentechnik-Ausbildung konzentriert sich oft auf die Beherrschung von Programmiersprachen. Wir halten es für sehr gefährlich, das Programmiersprachen-Training auf eine Sprache (meist C) zu beschränken. Im Gegenteil, die Programmiersprachenausbildung soll neben der Beherrschung der Sprache selbst dazu dienen, die Sprachprinzipien zu erarbeiten, Sprachkonzepte zu vergleichen und damit die Grundlage für das Erlernen weiterer Programmiersprachen auch im Selbststudium zu schaffen. Dabei beeinflussen didaktische und methodische Aspekte sowohl die Wahl der Trainingssprache als auch die Bedürfnisse der Wirtschaft. Viel zu viele Entwickler oder Programmierer fühlen sich dazu berufen, Software-Ingenieure ohne Berechtigung zu sein. Ausbildungsdefizite sind sicherlich viel größer als in der Programmiersprache (Eine Programmiersprache ist eine formale Computersprache, die dazu bestimmt ist, Anweisungen an eine Maschine, insbesondere einen Computer, zu übermitteln) Ausbildung in der Softwaretechnik. Es kommt nicht auf die Programmiersprache an, sondern auf die Verbesserung des Softwareentwicklungsprozesses. Die entscheidende Frage ist, ob wir fortgeschrittene Programmierer oder Software-Ingenieure ausbilden! Die Programmierung ist nur ein kleiner Teil der Softwareentwicklung. Die Analyse von Problemen, Kundenanforderungen oder der Funktionalität bestehender Softwarepakete, die Erfassung und Darstellung von Funktions- oder Informationsstrukturen, die Modellierung von Systemen wird in der Ausbildung oft vernachlässigt. In der Softwareausbildung sollte man sich nicht nur auf Modetrends stürzen, sondern akzeptieren, dass es eine Vielzahl von brauchbaren und anwendungsspezifischen sinnvollen Methoden und Techniken gibt. Insbesondere sollte eine realistische Einstellung zu CASE (Computer Aidded Software Engineering) durch die universitäre Ausbildung vermittelt werden. Ein CASE-Tool ersetzt nicht einen Software-Ingenieur oder eine fundierte Software-Engineering-Ausbildung. Ein CASE-Tool (Computer Aided Software Engineering ist die Domäne von Software-Tools, mit denen Anwendungen entworfen und implementiert werden) kann jedoch einen Software-Ingenieur entlasten (Software Engineering ist die Anwendung von Engineering auf die Entwicklung von Software in einer systematischen Methode) der die dem Tool zugrunde liegende Methode der Verwaltungs- und Dokumentationsarbeit beherrscht und somit eine wertvolle Hilfe wird. Der beste Weg, Methoden und Techniken zu erlernen, ist die geführte Anwendung. Die in einem Vortrag angebotenen Informationen müssen in praktischen Übungen und in der Diskussion erarbeitet werden. Auch die Identifikation von Problemen oder die Vermittlung von Lösungsstrategien erfordert Kommunikationsfähigkeiten. Kommunikation ist daher von besonderer Bedeutung. Aber auch die Kommunikationsfähigkeit muss erlernt werden. Die Universität hat hier eine zusätzliche Aufgabe. Über den Wissenstransfer hinaus kann untersucht werden, inwieweit der Universität strategische Misserfolge vorgeworfen werden können:
Mangelndes Krisenbewusstsein der Hochschullehrer – Mangelnde Kommunikation zwischen Hochschulen und Industrie Für Hochschullehrer endet der Einflussbereich oft mit dem Ausscheiden der Absolventen. Unsere Absolventen sind zwischen 4 und 5 Jahren in unserer Obhut, aber zwischen 30 und 40 Jahren im Berufsleben. Unsere Innovationszyklen werden immer kürzer. Das gilt nicht nur für die Produkte, sondern auch für die IT-Kompetenz. Es ist nur natürlich anzunehmen, dass Wirtschaft und Industrie nach einigen Jahren mehr brauchen werden. Nicht alle Unternehmen können ein Trainingsprogramm organisieren. Oft besteht auch das Interesse, Ausbildungsangebote unabhängig vom eigenen Unternehmen in Anspruch zu nehmen. In der Regel treten hier externe Trainer in den Vordergrund. Die Universitäten sollten diesen Markt jedoch für sich selbst öffnen. Durch die Teilnehmer an solchen Aus- und Weiterbildungsprogrammen hätten die Universitäten, die einzelnen Hochschullehrer, direkte Kontrolle über die Qualität und Praxisrelevanz ihrer Ausbildung. Während die bisher diskutierte Evaluation der Lehre hauptsächlich von Studierenden durchgeführt wird, kann hier die Frage gestellt werden, wie vorteilhaft das im Studium erworbene Wissen in der beruflichen Praxis eingesetzt werden kann.
Die bedarfsorientierte Gestaltung solcher Ausbildungsprogramme führt zwangsläufig zu einem Dialog zwischen Hochschule und Wirtschaft.
Das macht das Nachfrageprofil der Branche viel schneller und direkter sichtbar. Die an den Hochschulen vorhandene Ausbildungskompetenz und die gewonnenen anwendungsbezogenen Forschungsergebnisse stehen der Industrie ihrerseits schneller zur Verfügung.
In einer Publikation vom Oktober 1994 zieht Leveson (3) eine historische Parallele zwischen der Entwicklung der Dampfmaschinen im 18. und 19. Jahrhundert und der heutigen Softwareentwicklung. Die Entwicklung der Dampfmaschine war auch mit der Ausbildung einer neuen Ingenieurwissenschaft verbunden, dem Maschinenbau (Maschinenbau ist die Disziplin, die die Prinzipien der Ingenieur-, Physik- und Materialwissenschaften für die Konstruktion, Analyse , Herstellung und Wartung mechanischer Systeme anwendet). Der Sachschaden betrug mehr als 3 Millionen Dollar. Andere Dampflokkatastrophen in der Marine forderten Hunderte von Menschenleben.
Unter öffentlichem Druck werden sowohl in den USA als auch in Großbritannien Qualitätsstandards für die Konstruktion, Herstellung und den Betrieb von Dampfmaschinen gesetzlich durchgesetzt. Der Erfolg war durchschlagend. Die Explosionsrate von Dampfmaschinen ist drastisch gesunken.
Die Analyse des historischen Dampfmaschinenentwicklungsprozesses liefert die folgenden sechs Aussagen, die auf die Hauptmängel im technischen Entwicklungsprozess hinweisen:
Die Entwicklung einer neuen Technologie braucht Zeit. Entwickler und Nutznießer dieser Technologie müssen zunächst lernen, sie verantwortungsvoll und kompetent einzusetzen. Die Frage stellt sich: Wollen wir eine 200-jährige Entwicklungsgeschichte der Ingenieurwissenschaften in der Informatik in allen Phasen wiederholen, oder sind wir bereit und in der Lage, Lehren zu ziehen? Die Grundlage für den Wohlstand und die Lebensqualität einer Gesellschaft ist ihre führende Rolle im Ingenieurwesen. Soweit
wir schneller als unsere Wettbewerber Lehren aus der Wissenschaftsgeschichte ziehen und eine führende Rolle bei der Weiterentwicklung der Informatik zu einer neuen Qualität der Industrialisierung spielen, sichern wir unsere Zukunft.