Skip to main content

Wir können davon ausgehen, die Komplexität in unserer Gesellschaft wächst, und das sogar mit zunehmender Geschwindigkeit.

Was ist eigentlich Komplexität? Folgende Aussage findet man unter Anderem auf Wikipedia:

Der Ökonom Peter Ulrich bezeichnet die Komplexität einer Situation mit der Vielfalt der einwirkenden Faktoren und dem Ausmaß ihrer gegenseitigen Interdependenzen und charakterisiert diese als Merkmal schlecht strukturierbarer Entscheidungssituationen. Komplexität ist eine mögliche Form eines Gegenteils von Einfachheit, Determinierbarkeit und der Überschaubarkeit.

Dabei gibt es kein absolutes Maß. Komplexität ist immer relativ zu unserer Verstehbarkeit zu sehen. Bekommen wir Hilfestellungen in Bezug zur Verstehbarkeit verschiebt sich die Komplexitätsgrenze.

Wie konkret zeigt sich Komplexität im Software- und Systems-Engineering, und welche Hilfestellungen (Techniken) haben wir, um ihr zu begegnen?

Dieser Frage geht diese Ausgabe des Software Engineering Reports nach.

Wie wirkt sich Komplexität in unserem Umfeld aus?

Es ist unglaublich, als was ich mein iPhone in Kombination mit verschiedensten Apps alles nutzen kann. Angefangen von einer Wasserwaage bis hin zu einem komplexen Audio Signal Analyser, der auf Basis einer FFT die genauen Frequenzanteile analysiert. Der Kreativität scheint keine Grenzen gesetzt zu sein.

Aber wenn ich eine Telefonnummer anrufen möchte, die ich z.B. in einer Mail zugeschickt bekommen habe und die wie folgt aufgeschrieben wurde: +49 (0) 5722 9678 60, treibt mich das iPhone dicht an den Wahnsinn. Das iPhone erkennt sofort, dass es sich um eine Telefonnummer handelt, wählt aber die (0) mit und lässt mir in der Telefon-App keine Möglichkeit die Nummer zu editieren. Der Workaround Kopieren der Nummer in eine andere App und dortiges Editieren, hört sich simpel an, ist aber in Kombination der Touchscreen-Bedienung und der Motorik meiner Finger immer wieder eine echte Herausforderung und Geduldsprobe für mich.

Wie kann es angehen, dass ein Produkt, was im ureigensten Sinn ja immer noch ein Telefon sein sollte, inzwischen Millionen von erweiterten Diensten bereitstellt, aber das Telefonieren in manchen Situationen komplizierter macht, als je zuvor?

Es liegt nicht an der technischen Machbarkeit, es ist die Komplexität, die immer häufiger dazu führt, dass Systeme verschlimmbessert werden.

Immer häufiger kommen Systeme in Situationen, in der die Kombination von Zusammenhängen und deren Auswirkungen bei der Entwicklung nicht mehr überblickt werden. Die Systeme reagieren dann undefiniert bis fehlerhaft.

Müssen wir zukünftig damit leben, dass wir unsere Mobile Devices zwar für nahezu alles Erdenkliche nutzen können, diese aber nur noch gelegentlich funktionieren?

Ich denke nein. Es gibt bereits betriebsbewährte Techniken, auf deren Basis wir der wachsenden Komplexität begegnen können. Bevor wir uns diesen widmen, möchte ich die Komplexität noch einmal etwas durchleuchten.

Was ist Komplexität

Starten wir mit einer häufigen Verwechslung. Was ist der Unterschied zwischen Kompliziertheit und Komplexität?

Ich habe viel recherchiert und hatte selber lange Zeit Schwierigkeiten den genauen Unterschied zwischen Kompliziertheit und Komplexität zu verstehen, zumal einige Aussagen auch immer wieder widersprüchlich erscheinen.

Hier nun ein Versuch es es mit eigenen Worten kurz beschreiben, in der Hoffnung, dass Sie es schneller verstehen, als ich (falls Sie es nicht sowieso schon wissen).

Ein kompliziertes System lässt sich ohne weiteres Wissen verstehen. Es dauert nur länger und bedarf höherer Konzentration im Vergleich zu einem einfachen System. Unser Gehirn kann es nicht auf den ersten Blick vollständig durchdringen. Aber mit Zeit und Konzentration kann ein kompliziertes System vorhersagbar gesteuert werden, es gibt keine Nebenwirkungen.

Ein komplexes System lässt sich ohne weitere Informationen oder Hilfsmittel nicht vollständig verstehen. In einem komplexen System entstehen durch Dynamik Zustände, die sich bei rein statischer Betrachtung nicht erkennen lassen. Die meisten unserer Embedded Systeme sind inzwischen komplexe Systeme. Wir sollten uns also darüber klar sein, dass Änderungen in/an diesen Systemen nicht mehr durchführbar sind, ohne ungewünschte Nebenwirkungen (Fehlverhalten) ausschließen zu können, weil nicht mehr alle dynamischen Aktionen und deren Reaktionen umfassend berücksichtigt werden können.

Eines ist wichtig, und dass werden wir im nächsten Kapitel betrachten. Die Vorgehen und Praktiken, die geholfen haben den Umgang mit Kompliziertheit zu verbessern helfen nur eingeschränkt bei Komplexität.

Wie zeigt sich uns Komplexität?

Wird ein System kompliziert, dann ist einer der meist eingesetzten Instrumente, um das Verstehen weiterhin zu gewährleisten, die Zerteilung (Teile und Herrsche). Dieses Instrument wird bis heute erfolgreich eingesetzt, auch bei komplexen Systemen, dort jedoch mit zunehmend weniger Erfolg. Warum ist das so? Das werden wir uns nun etwas genauer ansehen.

Teile und Herrsche wird so lange durchgeführt, bis die einzelnen Teilsysteme in ihrer Kompliziertheit beherrschbar erscheinen. Was langläufig unberücksichtigt bleibt, ist die Tatsache, dass dem Teilen (Dekomposition) das Zusammenfügen (Aggregation) folgen muss. Alle Teilsysteme müssen am Ende wieder harmonisch zusammen funktionieren und die Funktion des Gesamtsystems abbilden. Hier beginnt heute die Problematik.

Um das zu verstehen, lassen Sie uns einen Blick auf die Abbildung Nr. 1 werfen. Hier ist der Teilungsprozess dargestellt. Behalten wir im Kopf, dass nur auf Basis der Aggregation das Gesamtsystem funktionieren kann, dann bilden sich Schnittstellen (Interfaces). Die Anzahl der potentiellen Interfaces wächst polynom mit der Anzahl der Elemente. Wir verschieben die Kompliziertheit von der Elemente-Ebene auf die Interface-Ebene.

Wir könnten das Spiel Teile und Herrsche immer weiter fortführen, dann würde irgendwann die Kompliziertheit in den Elementen infinitesimal klein sein. Sie wäre dann vollständig auf die Interface-Ebene verschoben. Diese übertriebene Situation würde uns nicht weiter helfen.

Irgendwo dazwischen kann unser Gehirn am besten mit der Kompliziertheit umgehen.

Nun stellt dieses Beziehungsgeflecht nur eine Ebene dar. In realen Software-Projekten haben wir jedoch mehrere Ebenen und hier beginnt das System komplex zu werden. Der Grad der Vernetzung über mehrere Ebenen macht es nahezu unmöglich die dynamische Ausprägung einer Änderung in einer statischen eindimensionalen Betrachtung vorhersagbar zu machen.

In der Praxis: Die Änderung einer Zeile C-Code mag in Bezug auf die Logik des Basis-Betriebsmodus überschaubar sein. Aber da gibt es noch den Modus für Service und Diagnose. Der wird noch einmal überlagert von Versionen (Im Feld laufen Systeme mit neuen und alten Komponenten und der Service-Stecker ist dort jeweils anders ausgeprägt) und dann kommt noch die Luxusvariante dazu ... Verstehen Sie was ich meine? Die Codeänderung muss in jeder Hinsicht kongruent sein. Das zu gewährleisten ist heute die Problematik.

In der Praxis haben heutige Systeme auf etwa 7-12 Ebenen Beziehungen. Folgend sind exemplarisch einige Ebenen aufgeführt, auf denen sich im Software-Engineering Beziehungen potentiell ausprägen.

Entwicklung der Software-Schnittstellen in den letzten Jahrzehnten

Komplexität zeigt sich uns heute also in Form der Schnittstellen in Kombination mit multiplen Ebenen in denen sie wirken.

Nun lässt sich Komplexität in der Software schwierig darstellen. Im Grunde sind auch die bekannten Software Komplexitäts-Maße nicht mehr wirklich aussagekräftig, wenn es um Software für Systeme geht.

Zum Beispiel die (wohl bekannteste) McCabe-Metrik zur Metrisierung von Software-Komplexität versagt heute kläglich, wenn es um Systeme geht. Bereits die Auswirkungen von bedingter Compilation, mit der evtl. die Ausprägung von Varianten dargestellt wird, ist in der Basis-Metrik nicht berücksichtigt.

Im Grunde könnte man sagen, die McCabe-Metrik ist eher ein Maß für Kompliziertheit, als ein Maß für Komplexität. (Vorausgesetzt, das Software-Modul wurde auf Basis von Teile & Herrsche ausreichend übersichtlich gestaltet.)

Wie also lässt sich der aktuelle Stand der Komplexität bildhaft darstellen?

∨ mehr Text anzeigen

Ich werde es mit Beispielen aus dem Automotive-Umfeld versuchen. Stellvertretend für die Komplexität beziehe ich mich auf die Schnittstellen der elektronischen Komponenten.

In den Abbildungen von Nr. 2 sehen Sie die Entwicklung der Bordnetze von 1950 bis 2014 an drei Beispielen. 1950 mit dem VW Käfer. 30 Jahre später, 1980 beim Opel Kadett-D, haben sich die Anzahl der elektronischen Bauteile und das Bordnetz verzehnfacht. 24 Jahre später, 2004 mit dem VW Phaeton gibt es noch einmal eine Verzehnfachung der elektronischen Komponenten und des Bordnetzes.

Was ist bei der Entwicklung des Bordnetzes gegenüber der Anzahl der Komponenten auffällig? Die Anzahl der elektronischen Komponenten hat sich von 1950 bis 1980 verzehnfacht, und Gewicht und Länge des Kabelbaums sind linear mit gewachsen.

Von 1980 bis 2004 hat sich wiederum die Anzahl der elektronischen Komponenten verzehnfacht, jedoch haben sich Gewicht und Länge des Kabelbaums nur knapp verdoppelt. Die für die Kommunikation der Komponenten notwendigen Signale haben sich mit Sicherheit ebenso verzehnfacht. Wie werden sie übertragen?

Des Rätsels Lösung finden wir in den 1990er Jahren. Zu diesem Zeitpunkt haben die Bussysteme in die Bordnetze Einzug gehalten, allen voran der CAN Bus.

Bis dahin konnte über ein Kabel immer nur ein Signal übertragen werden. Mit den Bus-Technologien können nun bis zu 2.500 Signale (zumindest theoretisch und heute sogar noch mehr) über zwei Kabel übertragen werden.

In der Abbildung Nr. 3 ist noch einmal in einem Diagramm dargestellt, wie die Anzahl der Interfaces weiterhin rasant ansteigt, jedoch der Kabelbaum in den 90er Jahren ein vorläufiges Maximum erlebt, ja sogar leicht rückläufig ist, um dann erst wieder leicht anzusteigen.

Bordnetz Stand 1950 - VW Käfer

Bordnetz Stand 1980 - Opel Kadett-D

Bordnetz Stand 2004 - VW Phaeton

Das Wachstum der Signale ist also ungebremst, aber ab den 90er Jahren werden sie über Bussysteme übertragen.

Jetzt kommt die spannende Frage, wie werden denn die Busse angesteuert? Ja richtig, von der Software. Wir können also davon ausgehen, dass seit den 90er Jahren 80% des Wachstums der Komplexität in die Software mündet. Wir können auch getrost davon ausgehen, dass sich von 2004 bis heute die Komplexität in unseren Systemen noch einmal verzehnfacht hat.

Bitte betrachten Sie noch einmal die Abbildungen auf Seite 5. Ich hoffe, Sie bekommen eine Vorstellung von der Komplexität der Software, die derartige Systeme steuert. Die Entwicklung dieser Software auf Basis von Hochsprachen, und das auch noch in verteilten Teams, erreicht zunehmend die Grenze der Leistungsfähigkeit der Gehirne der Ingenieure. Denken Sie bitte auch immer an die multifachen Ebenen, auf denen sich das Beziehungsgeflecht auswirkt (In dieser Betrachtung erst einmal vernachlässigt).

In den letzten Jahrzehnten ist der Großteil der Komplexität in die Software geflossen. Auch dort ist Teile & Herrsche der meist eingesetzte Mechanismus, um ihr zu begegnen, mit demselben Effekt, die Komplexität wirkt sich am stärksten in Bezug auf die Interfaces aus.

Ich möchte das Bild noch etwas präzisieren. Dazu werfen wir einen Blick auf die Schnittstellen an sich.

Interfaces im Software-Engineering

Auch hier möchte ich mit einer analogen Betrachtung starten. Stellen Sie sich folgende Situation vor. Das System soll um eine weitere Funktion (Komponente) erweitert werden. Natürlich existieren bereits viele Funktionen (Komponenten), die zum Teil recht alt sind. Nun haben wir ein Interface, in der Hardware könnte das etwa so aussehen, wie in Abbildung Nr. 4 oben zu sehen ist.

Unser Problem ist, dass das alte System eine alte Stecker-Norm nutzt. In Abbildung Nr. 4 unten sehen Sie symbolisch dargestellt ein häufig angewandtes Vorgehen im Software Engineering, das Interface zu bilden. Und ob Sie es glauben oder nicht, aus Software Design-Sicht funktioniert dieses Vorgehen sogar hervorragend, und es gibt nichts einzuwenden. Warum? Software kennt keine Physik. Der Software-Entwickler hat gelernt: Die einzige Voraussetzung dafür, dass die Verbindung funktioniert ist, dass sich das Metall von Stecker und Kupplung an irgend einer Stelle berühren muss. Und dafür ist gesorgt.

Es gibt keine Korrosion, niemals wird der Stecker mechanisch belastet, es wird nicht wirklich Strom fließen ...

Aus diesem Grund hält diese Art der Verbindung aus Software Design-Sicht für die Ewigkeit und es wäre gar nichts dagegen einzuwenden, wenn es nicht auch noch die Software-Architektur-Sicht gäbe. Das entsprechende ANSI-C Konstrukt für diese Art Interface, das ich im Kopf habe, ist ,Casting‘.

In Abbildung Nr. 5 sehen Sie einen Auszug aus einem ANSI-C-Lehrbuch zum Thema Casting. Dort wird sogar auf die Problematik hingewiesen, aber es fehlt ein Gesichtspunkt. Der Cast ist nur in dem Modul zu sehen, in dem er angewandt wird. Auf der anderen Seite ist er nicht zu sehen, und eine Änderung der Schnittstelle dementsprechend risikoreich. Aus Architektur-Sicht verbessert Casting nicht gerade Änderbarkeit, Wartbarkeit, Robustheit ....

Nun gibt es im Software Engineering auch Muster (Ich komme später noch einmal auf Muster zurück), die aus Architektur-Sicht eher einem heute üblichen Stecker gleichen, wie er in Abbildung Nr. 6 zu sehen ist. Zum Beispiel UML Ports.

Und ... Ja es ist erst einmal mehr Aufwand das ganze Interface mit einem Stecker zu versehen anstelle des Isolierbands.

Aber aus Sicht der Architektur kommen Sie langfristig nicht darum herum, wenn Sie bei steigender Komplexität die Qualitätsattribute Wartbarkeit, Änderbarkeit, Robustheit ... stabil halten wollen. (Siehe auch ESER Ausgabe Nr. 31: Architektur Design)

Wir müssen uns den Interfaces und deren Ausprägung widmen. Dort spüren wir die Auswirkungen der Komplexität am signifikantesten, und dort gibt es Verbesserungspotential.

Nun endlich, nähern wir uns dem Kernthema., wie wir der Entwicklung von Komplexität im Software Engineering konkret begegnen können.

Wie können wir der Komplexität begegnen?

Grundsätzlich möchte ich 3 Basis-Mechanismen darstellen. Es gibt weitere, aber diese halte ich für essentiell. Teile & Herrsche, Musterbildung und Abstraktion.

Noch einmal Teile & Herrsche?

Ja, Sie lesen richtig, Teile und Herrsche gehört nach wie vor zu den Hilfsmitteln komplexe Systeme besser zu verstehen, trotz obiger Aussagen. Teile & Herrsche kann auf verschiedene Art angewandt werden. Die gebräuchlichsten sind folgende:

  • Hierarchische Dekomposition: Aufteilen des Gesamtsystems in kleinere Teile, die überschaubarer sind, hilft überwiegend bei Kompliziertheit.
  • Betrachtung des Systems unter verschiedenen Gesichtspunkten bzw. Ebenen (Datenfluss, Zeitverhalten, statische Aufteilung ...). Hilft auch bei Komplexität.

Erstere wird in der Regel bereits angewandt und hilft, wie wir gesehen haben, eher bei komplizierten Systemen. Bei komplexen Systemen kommt sie an ihre Grenzen. Nun greift jedoch die zweite Art Teile & Herrsche anzuwenden. In diesem Fall wird dasselbe System jeweils mit dem Fokus auf eine Ebene betrachtet. So können nacheinander die verschiedenen Gesichtspunkte (z.B. Zeitverhalten, Kommunikation, Varianten ...) betrachtet werden. Das schafft unser Gehirn sehr gut und es erhöht das Verständnis des Gesamtsystems.

Die Anwendung der UML macht genau dieses auf Basis der verschiedenen Diagramm-Typen. SequenceDiagramme legen den Fokus auf die Kommunikation, Zustands-Diagramme eher auf das logische Verhalten, Timing-Diagramme auf die Zeit, Klassen-Diagramme auf das statische Design ...

Natürlich gibt es eine grundlegende Voraussetzung, damit dieses Prinzip funktioniert. Alle Sichtweisen müssen kongruent den selben Status des Systems darstellen. Das ist einfacher gesagt als getan. Die Aufteilung der Sichtweisen auf verschiedene Ebenen erhöht die Redundanz und diese will bei Änderungen gepflegt werden. Der Aufwand dafür wird häufig unterschätzt. Hier kommen die Werkzeuge ins Spiel. Ein gutes UML Werkzeug bezieht die redundanten Informationen immer auf Basis eines Repositorys. Zusätzlich prüft es das Modell auf Konsistenz.

Die meisten Werkzeuge geraten beim Letzteren schnell an die Grenzen. Letztendlich hat sich die ModelSimulation oder noch besser Codegenerierung und Ausführung mit Backannotation als die beste Art des Konsistenz-Checks der Modelle herausgestellt. Und nur wenn das Modell in allen Aspekten in sich konsistent ist führt die Betrachtung aus verschiedenen Gesichtspunkten zum Ziel.

Musterbildung

Ich glaube es ist müßig zu fragen, auf Basis welcher der beiden Darbietungen in Abbildung Nr. 7 Sie schneller, und vor allem mit geringerer Fehlerrate, sagen können um wie viel Streichhölzer es sich handelt. Hier sehen Sie die Anwendung von Mustern. Musterbildung ist nach aktuellem Kenntnisstand der mächtigste Mechanismus der Komplexität zu begegnen.

Auch das ist nichts Neues, wird im Software Engineering seit Jahrzehnten erfolgreich angewandt und ist noch lange nicht ausgereizt. Zum Beispiel eine for() Anweisung in ANSI C, die als Muster für eine ganz bestimmte Formation an Assembler-Befehlen steht. in diesem Fall kommt ein weiterer Vorteil hinzu, je nach Microcontroller ist die Ausprägung in Assembler immer wieder unterschiedlich. Die oberste Ebene der Anwendung des Musters bleibt davon unberührt, solange das Muster exakt abgebildet werden kann.

Und es gibt noch einen Turbolader in Bezug auf die Wirkung von Mustern. Das sind Standards. ANSI C hat sich nicht durchgesetzt, weil es die bessere Hochsprache im Vergleich zu PASCAL oder PL/M war. Der Grund war die Standardisierung durch Kernighan und Richie bzw. ANSI, weil damit die Dialektbildung unterbunden wurde und das den Grad der möglichen Wiederverwendung vervielfacht hat.

Ein sehr bekanntes Muster ist Schraube und Mutter auf Basis von Gewinde. Zuerst wurde dieses Muster ohne Norm (Standardisierung) angewandt. Der Nutzen war bereits hier groß, aber erst mit der Standardisierung der metrischen Gewinde verbunden mit Schlüsselweiten hat dessen Anwendung im Maschinenbau zu einem Quantensprung geführt.

Stellen Sie sich einmal vor, jeder Automotive OEM würde noch eigene Gewindesteigungen und Schlüsselweiten nutzen. Wie stände es mit der Effizienz in Produktion und Service?

Normen haben einen größeren Nutzen in Bezug zur Komplexität, als allgemein angenommen. Unser Gehirn kann Muster nur dann nutzen, wenn sie gleichförmig sind. Es muss das Muster in und auswendig kennen, mit all seinen möglichen Aspekten. Nur dann kann es in einer Kombination von Mustern schnell deren zusammenwirken assoziieren. Ist die Ausprägung der Muster immer leicht unterschiedlich, steigt die Gefahr von Fehlern exponentiell, bzw. müssen die Muster immer neu antrainiert werden.

Das ist der eigentlich aufwändige Schritt. Das Muster in all seinen Aspekten so verinnerlicht zu haben, dass unser Unterbewusstsein die Ausprägungen korrekt beurteilen kann. Wir nennen das Ergebnis auch Intuition. Unser Unterbewusstsein hilft uns Entscheidungen zu treffen. Wenn Sie mehr dazu erfahren möchten nehmen Sie sich 6 Minuten Zeit für folgendes Video auf Youtube: ,05 Wie reagieren Menschen auf wachsende Komplexität ?‘ von Peter Kruse‘

Und wieder führt uns der Weg zur UML. Die UML ist nüchtern betrachtet nichts weiter als die Standardisierung im Software Engineering von betriebsbewährten Mustern, kombiniert mit Symbolik. (UML der OMG, ISO/IEC 19505)

Klassen, Events, Tasks, Timer, Zustände, Signale ... alles Muster, die bereits vor dem Existieren der UML bekannt und erfolgreich eingesetzt wurden. Bis zu diesem Zeitpunkt jedoch immer in unterschiedlichen Ausprägungen. das U in UML steht für Unified (vereinheitlicht, konsolidiert). Eine der Hauptziele der UML war die Vereinheitlichung der Definition und Anwendung von 4GL Notationen (Room, SDL, SART ..). In der Praxis bedeutet das die Vereinheitlichung von bereits vielfach erfolgreich angewandten Mustern mit ihrer Symbolik und Ausprägung.

Übrigens ist die UML exakter spezifiziert, als viele Anwender annehmen, bzw. deren Kenntnisstand in der Anwendung ist. Was ich damit sagen will, in der Praxis wird sie meistens sehr unexakt angewandt. Dabei geht ihr Nutzen zu 80% verloren.

Abstraktion

Im Grunde ist Abstraktion lediglich die Kombination von Teile & Herrsche, bezogen auf Ebenen mit Musterbildung. Ein Schaltplan ist ein sehr gutes Beispiel für Abstraktion. Dort gibt es z.B. ein Symbol für einen integrierten Schaltkreis. Dieser integrierte Schaltkreis ist an sich bereits ein kompliziertes Muster. Eingebunden in ein System entsteht Komplexität. Diese ist genau in dem Maße von unserem Gehirn beherrschbar, wie das Gehirn den integrierten Schaltkreis (IC) verinnerlicht hat. Kennt Ihr Gehirn das IC nicht, werden Sie Probleme haben die Schaltung zu verstehen und umgekehrt.

Nichts anderes sind die UML Notationselemente. Sie sind Muster mit spezifizierten Artefakten. Je genauer Sie die Artefakte eines Musters kennen, und je häufiger Ihr Gehirn dieses Muster angewandt hat, desto besser beherrschen Sie Komplexität.

Ist das Muster leicht abgewandelt passieren Fehler. Sie können sich nicht mehr auf Ihre Intuition verlassen. (Siehe Youtube Video)

Sie sehen also, Normen spielen eine ebenso große Rolle, wie die Muster an sich.

Aber wir sind noch nicht am Ende der Abstraktion.

Es fehlt noch das bewusste Weglassen von Gesichtspunkten. Erinnern Sie sich? Ein Aspekt der Komplexität waren die multidimensionalen Auswirkungen der Schnittstellen. Die Konzentration auf einen oder wenige Gesichtspunkte des Systems, erhöht die Möglichkeit, dass unser Gehirn diesen Gesichtspunkt vollständig durchdringen kann. (Ist das nicht sinnreich, die Konzentration hilft unserem Gehirn sich zu konzentrieren.)

Natürlich steigt der Arbeitsaufwand. Nun müssen wir Dimension für Dimension betrachten, vorher reichte ein Blick auf den C-Code.

Wenn der Arbeitsaufwand steigt, warum lohnt sich dieses Vorgehen trotzdem? Das erschließt sich durch den so genanten Front Loading Effekt. Er basiert auf der Tatsache, dass Fehler, je später sie gefunden werden, ein vielfaches an Aufwand und Kosten verursachen.

Es lohnt sich also in frühen Phasen mehr Aufwand zu treiben, wenn auf diese Weise Fehler früher gefunden werden. Also lieber früher gründlicher Arbeiten und damit Rückrufaktionen zu vermeiden.

Resümee

Das Wachstum der Komplexität geschieht schleichend. Kennen Sie den Versuch, bei dem Biologen einen Frosch in 50 Grad heißes Wasser setzen. Der Frosch hüpft sofort wieder heraus und überlebt. Dann setzen sie einen Frosch in kaltes Wasser, was dann langsam erhitzt wird. Wenn es dem Frosch zu warm wird und er herausspringen möchte, ist seine Muskulatur bereits überhitzt und er kann die Kraft nicht mehr aufbringen. Die meisten Frösche können dann nicht mehr springen und sterben.

Es ist wissenschaftlich bewiesen. Schleichende Prozesse führen häufiger zum Exodus, als abrupte Veränderungen. Nehmen Sie die Entwicklung der Komplexität im Software Engineering ernst. In den meisten Firmen, in denen ich Einblick in die Entwicklung habe, besteht die Neigung das Wachstum der Komplexität zu unterschätzen und zu spät darauf zu reagieren. Ich hoffe es geht am Ende nicht wie mit den Fröschen aus.

In diesem Zusammenhang ist im Software Engineering ein Paradigmenwechsel von der Programmierung zur Modellierung notwendig, um der steigenden Komplexität nachhaltig zu begegnen. Solch ein Schritt ist kein Klacks. Ein Paradigmenwechsel ermöglich nicht nur einen Quantensprung in der Bewältigung von Komplexität, er bedeutet auch einen Quantensprung an Kosten und Einarbeitung. Das ist wahrscheinlich der Hauptgrund, warum er so lange vor sich hergeschoben wird.

Wer im Unternehmen kann die Entscheidung für einen Paradigmenwechsel treffen? Oder anders gefragt, wer im Unternehmen trifft die Entscheidung SAP einzuführen? Buchhalter und kaufmännische Angestellte? Oder das gehobene Management.

Das gleiche gilt für außerordentliche Investitionen im Software Engineering. Die Ingenieure können das Management lediglich darauf hinweisen, dass die gegebenen Arbeitsmittel der Komplexität nicht mehr gewachsen sind und Empfehlungen für notwendige Schritte aussprechen (und das sollten sie auch tun).

Die Entscheidung über die Freistellung der notwendigen Mittel muss das gehobene Management treffen. Es liegt in der Regel auch nicht im Verantwortungsbereich eines Projektleiters, weil sich die Investitionen nicht innerhalb eines Projektes amortisieren und damit im ROI des Projektes und dessen Budget nicht abbildbar sind.

Und: Es macht keinen Sinn Quantensprünge in Häppchen aufzuteilen. Hier gilt das Ganze ist mehr, als die Summe der Einzelteile. Ich würde es noch drastischer formulieren. Halbherzige Schritte bringen wenig Nutzen, verglichen zum Aufwand. Noch schlimmer, die Resultate von halbherzig durchgeführten Paradigmenwechsel verfälschen den Blick auf den Nutzen, und der vollständige Wechsel wird dann in Frage gestellt.

Abschließend noch ein Punkt, der mir sehr wichtig ist: Die Kosten. Immer wieder höre ich ,das ist aber teuer‘, wenn es um solide Lösungen geht. Was in Deutschland teuer ist, das sind die Personalkosten. Die Kosten für die Einführung eines neuen Vorgehen inclusive Werkzeugen, Schulung und Coaching, liege bei solider Durchführung in etwa bei den Kosten von zwei Mann-Monaten. Bei nur 20% Effizienzgewinn haben sie sich also nach einem Jahr amortisiert. Dieser Schritt sollte aber für mindestens 5 Jahre Vorteile mit sich bringen. (Ach Entschuldigung, ... ich vergaß ... meine Rechnung ist falsch, die Personalkosten werden ja vom Universum bezahlt.)

Die Entscheidung, ob etwas teuer ist oder nicht sollte von den Mitarbeitern im Unternehmen beurteilt werden, die für die Rentabilität des Gesamtunternehmens verantwortlich sind. Und diese sollten, wenn sie klug sind die Personalkosten mit einbeziehen.

In diesem Sinn wünsch ich Ihnen viel Erfolg in Ihren Projekten, und Mut. Mut von Seiten der Ingenieure das Management zum richtigen Zeitpunkt auf notwendige Maßnahmen hinzuweisen und Mut auf Seiten des Managements die Ressourcen für die erforderlichen Maßnahmen bereitzustellen. Und Klugheit, die Kosten richtig zu beurteilen. Vor allem aber wünsche ich Ihnen Spaß, Erfolg und Zufriedenheit bei Ihrer Arbeit.
 

Autor:

Andreas Willert
Haben Sie noch Fragen oder Anregungen zum Thema? Dann freue ich mich über eine E-Mail: awillert@willert.de

Herausgeber:

WILLERT SOFTWARE TOOLS GMBH
Hannoversche Straße 21
31675 Bückeburg
E-Mail: info@willert.de
Tel.: +49 5722 9678 - 60

Alle ESE-Reports im Überblick

Aktuelles Know-how und neueste Entwicklungen und Trends rund um das Thema Emedded Software Engineering

> zu den ESE-Reports

Hinweis: Unsere Webseite nutzt Cookies. Wenn Sie fortfahren, nehmen wir an, dass wir Ihre Erlaubnis haben Cookies zu setzen. Informationen zum Einsatz von Cookies sowie unsere Datenschutzbestimmungen finden Sie in unserer Datenschutzerklärung und über unser Impressum.