Freitag, 25. Oktober 2013

Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?

Prozessübersicht Softwareentwicklung

Artikelübersicht
1. Teil Missing Links im Modell.
2. Teil Gibt es einen eklatanten Wissensbruch in der Softwareentwicklung?
3. Teil Entwurf und Bauen von Software – eine falsche Vorstellung.
4. Teil Softwareentwurf ist ein organisierter Kreislauf.
5. Teil In Softwareprojekten gibt es viel zu entdecken!
6. Teil Die Interaktion mit dem Kontext ist ein wesentlicher Grund für den Erfolg eines Softwareprojektes.
7. Teil Das unentdeckte Land oder wo noch nie ein Mensch gewesen.
8. Teil Mit schlanken Methoden zu gewollter Software.
9. Teil Die Flexibilität des Vorgehens schenkt laufende Verbesserungen.
10. Teil Vom Problem seiner Rolle gerecht zu werden.
11. Teil Wir gründen eine virtuelle Firma.
12. Teil Warum ist unsere virtuelle Firma nur ein Torso?
13. Teil Eine Arbeitsvorlage, ein strategisches Team und ein tolles Geschäft.
14. Teil Ein fortgesetztes tolles Geschäft.


Mein Beispiel mit dem Architekten im Post Missing Links im Modell sorgte anscheinend für einige Verwirrung. Es wurde angemerkt, dass ein Architekt das spätere Bauwerk nicht benutzen muss und daher Bauwerke entstehen, die nicht besonders nutzerfreundlich sind. Die Schlussfolgerung daraus war, in der Softwareentwicklung treten keine schlimmeren Wissensbrüche auf als in anderen Produktionsbereichen. Kurz gesagt zwischen dem Nutzer des Hauses und dem Architekten besteht derselbe Wissensbruch, wie zwischen dem Bankfachmann und dem Requirements Engineer.

Im Post Wissensformen habe ich zwischen drei Wissensformen unterschieden: das fachliche Wissen, das analytische Wissen und das technische Wissen. Der Fachmann weiß um die Inhalte des zu bearbeitenden Themas. Der Analytiker übersetzt sie in eine geeignete Modellform und bereitet sie so auf, dass der Techniker das Ganze erschaffen kann.

Übersetzt in den Hausbau stellen sich die Fragen nach den Besitzern dieser Wissensformen. Wer verfügt über das fachliche Wissen zum Hausbau? Gewöhnlich ist es nicht der Benutzer des Hauses. Dieser wohnt nur im Haus und kann sich furchtbar echauffieren, wie die Bude zusammengebastelt wurde. Es sind Architekten und Bauingenieure, die über das fachliche Wissen verfügen. Sie können Häuser konstruieren, in denen wir wohnen können. Kann ein Requirements Engineer in der Softwarebranche eine Bankensoftware konstruieren, ohne die fachliche Hilfe einer Fachfrau aus der Branche? Er müsste selber dieser Fachmann sein, aber das kommt in den seltensten Fällen vor. Der Bauingenieur und der Architekt können ihr Wissen jedoch ganz alleine in eine übliche Modellsprache übersetzen. Er ist also auch der Inhaber des analytischen Wissens, fertigt Konstruktionszeichnungen und -pläne an. In der Softwarebranche ist der Requirements Engineer der Analytiker. Er versucht, das Wissen über die Fachfrau aus der Bankenbranche zu ermitteln. Dann übersetzt er es in eine Modellsprache, die eine aus der Informatik ist. Genau diese Trennung von fachlichen und analytischen Wissen bezeichne ich als eklatanten Wissensbruch. Übrigens muss die Bankfachfrau auch nicht in die Verlegenheit kommen, mit der angefertigten Software arbeiten zu müssen. Das können Angestellte sein, die gar nicht über das fundamentale Fachwissen der Fachfrau verfügen.

Inwiefern der zweite Übergang, der vom Analytiker zum Techniker, nicht so eklatant ist, könnte eine weitere Streitfrage sein. In der Baubranche bekommt der Baufachmann sein Modell und baut das Haus. In der Softwarebranche wird dem Entwickler das Modell übergeben und er codiert das Gewollte. Wahrscheinlich hat die Softwarebranche auch in diesem Bereich eine längere Strecke zurückzulegen, um die selbe Eindeutigkeit des Modells zu erreichen wie in anderen Ingenieurskünsten. Wahrscheinlich ist es aber so, dass das Bauen in der IT nur das Kompilieren und Linken ist und somit das Programmieren immer noch zur Entwurfsarbeit gehört. Damit ist die Entwurfsarbeit schon in drei Teilbereiche getrennt, das Requirements Engineering, die Softwarearchitektur und die Programmierung, in denen es bei jedem Übergang zu einem Wissensverlust kommen kann.

Die benötigte Information gelang also vom Fachwissenden zum Analytiker zum Techniker. Die übermittelte Information unterliegt einem Prozess der Transformation. Dabei unterscheidet man Wahrnehmungs- und Darstellungstransformationen.

Eine Person erfasst mit ihren Sinnen die Realität und bildet sie dann jedoch in ihrer persönlichen Wirklichkeit ab. Diese Transformation nennt man Wahrnehmungstransformation. Die Darstellungstransformation vollzieht sich bei der Erstellung des Konzeptes, des Modells, der Präsentation der wahrgenommenen Realität.

"Die Darstellung der Wirklichkeit ist auch immer eine Modellbildung. Eine Person nimmt die Realität wahr und konstruiert daraus ein gedankliches Bild. Dieses gedankliche Bild, die Konzeption, wird als Repräsentation dargestellt. Die erzeugte Repräsentation wird durch eine weitere Person wahrgenommen. Durch die Interpretation des Wahrgenommenen wird wiederum ein gedankliches Bild, eine Konzeption erzeugt. Diese sollte mit der ursprünglichen Realität korrespondieren." [S.25, BAU09]

Das folgende Bild verdeutlicht diese Prozesse. Es stellt die Transformationseffekte bei der Modellbildung und Modellinterpretation dar und wurde aus [S.294, POHL08] entnommen.

Deutlich zu sehen ist die Unterscheidung von Wahrnehmung und Darstellung. In der Softwarebranche wird dieser Transformationsprozess im Allgemeinen einmal mehr durchlaufen als in anderen Ingenieurskünsten. Dadurch kommt es zu einem größeren Informationsverlust. Die Verluste durch die Wahrnehmungstransformationen sind nur durch das Begutachten durch mehrere Personen zu minimieren. "Darstellungstransformationen lassen sich laut [RUPP07] sehr gut auflösen. Dazu muss man die verschiedenen Transformationsarten genau kennen. Benannt werden die Tilgung, die Generalisierung und die Verzerrung." [S.26, BAU09] Dieses Wissen ist jedoch oft nicht vorhanden oder die Wichtigkeit dieses Wissens wird geleugnet.

Patrick Koglin hat diese Grafik zum Inhalt dieses Artikels angefertigt. Dafür möchte ich mich an dieser Stelle noch einmal ausdrücklich bedanken und hoffe auf weitere grafische Unterstützung. :-)


"Tilgung reduziert die Welt auf Ausmaße, mit denen wir umgehen können." [S.143, RUPP07] Wir nehmen die Welt also selektiv wahr und lassen Dinge weg, die wir nicht für wichtig halten. Die Meinung über wichtig oder nicht ist jedoch eine subjektive Entscheidung.

"In der Generalisierung fassen wir einzelne Teile oder Ereignisse zu Kategorien zusammen, mit denen wir auf einer abstrakteren Stufe umgehen können. Man überträgt ein Einzelerlebnis auf eine allgemeinere Form des Erlebens." [S.26, BAU09]

"Jede Wahrnehmung der Wirklichkeit ist auch immer die Verzerrung derselben. Die Wirklichkeit wird immer aus dem eigenen Erfahrungshorizont beurteilt. Das entstehende Bild ist immer ein Zerrbild, das einem anderen Betrachter als falsch erscheinen kann." [S26, BAU09]

Durch die subjektive Wahrnehmung kommt es also zu einer erheblichen Transformationsreibung. Diese gilt es zu minimieren. Dabei kann die Minimierung der Informationsüberträger helfen oder die Eineindeutigkeit von Modellen. Für diese Bereiche gilt es Lösungen zu finden.

  • [BAU09] Ralf Baumann: "Entwicklung eines Arbeitsablaufes für die Entwicklung von Anforderungen an eine Software durch den Auftraggeber.", Diplomarbeit an der FH Trier, 2009
  • [POHL08] Klaus Pohl: "Requirements Engineering", 2. korrigierte Auflage, dpunkt.verlag GmbH, Heidelberg, 2008
  • [RUPP07] Chris Rupp & SOPHISTen: "Requirements Engineering und – Management", 4. aktualisierte und erweiterte Auflage, Carl Hanser Verlag, München, Wien, 2007


Vielen Dank an Markus Flückiger für seinen Kommentar in der Xing-Gruppe Requirements Engineering und seine Erlaubnis diesen, in meinem Blog, zu veröffentlichen:

Es gibt sogar viele Wissensbrüche im Software Engineering. Immer dann, wenn jemand was aufschreibt und das Dokument jemand anderem weitergibt, ist der Wissensbruch besonders ausgeprägt.

Wer schon mal die folgende Kette in einer Firma, in der das Erstellen von Dokumenten die Hauptarbeit ist, als PL durchgemacht hat, müsste das eigentlich nachvollziehen können:

Business Analyst --> Requirements Engineer --> Systemarchitekt --> UI Entwickler --> Server Entwickler --> Tester.

Vom Wissensbruch, der am Ende entsteht, sobald das Entwicklungsteam abzieht und den Dokumentenberg dem Maintenance Team hitnerlässt, wollen wir schon gar nicht erst sprechen.

Ebenfalls lassen wir die Projekte aussen vor, bei welchen ein Manager ein 100 Personen Team hinstellt und die jetzt losrennen lässt.

Beim Entwickeln des Buches "Softare entwickeln mit Verstand" haben wir Autoren uns intensiv mit Wissensbrüchen auseinandergesetzt. Im Buch haben wir Wissen übrigens recht eng definiert, nämlich so ungefähr das was in den Köpfen der Personen ist.

Denkt man diesen Ansatz etwas detaillierter durch, schaut ein bisschen Problemlösen, Kommunikation und Teamarbeit an (und das haben wir für das Buch gemacht), liegt die Erkenntnis auf der Hand: Wissensbrüche sind das Problem überhaupt bei dokumenten-zentrierten Vorgehen. Wie beim Ins-Ohr-Flüstern-Spiel ergeben sich die abstrusesten Resultate.


vorheriger Post dieses Themas     folgender Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Kommentare:

  1. Der Vergleich mit dem Bau hinkt. Ein Architekt mag fachlich wissen wie ein Haus gebaut werden muss, aber schon die Tatsache, dass es Innenarchitekten, Küchenplaner, Lichtdesigner usw. gibt, zeigt, dass er in der Regel nicht der Generalist ist, als der er hier gesehen wird.

    Die Vorstellung, dass der Maurer, usw. den Bauplan lesen können ist eine Wunschvorstellung, die sich in meinem privaten Bauprojekt mir nicht gezeigt hat! Ich bin in der IT und wie in der IT ging es auch mit dem Bau. Die IT-Erfahrung hat dazu geführt, dass ich als Bauherr wesentlich besser mit meinem Architekt zusammengearbeitet habe, als das bei anderen der Fall war. Aber am Ende konnte ich definitiv den Bauplan besser lesen als die Vorarbeiter vom Elektriker und dem Installateur.

    Das Bauprojekt wäre nur dann vom Architekten allein zu stemmen, wenn jeder der einzieht ein Null-Acht-Fuchzehn Haus akzeptiert und sich mit allen unpraktischen Planungen abfindet.

    Wenn also der Bankmitarbeiter zufrieden ist, dass er eine Null-Acht-Fuchzehn Kassensoftware und Bankensoftware benutzt und seine speziellen Produkte dann eben händisch rechnet und einträgt oder was auch immer an missratener Ergonomie in Bezug auf seine Betriebsabläufe akzeptiert. Dann könnte man so Software planen.

    Wenn der Bauherr nicht weiß was er will und dauernd nach Fertigstellung von Teilleistungen feststellt, dass er es doch anders benötigt, dann entstehen Kostenexplosionen und Baumängel und nicht umgesetzte Eigenschaften. Sehen Sie da Ähnlichkeiten zur Software-Entwicklung => eben.

    Wenn der Bauherr einen quadratischen Keller haben will und dann ein rundes Erdgeschoss draufsteht und im Keller die Anschlüsse so haben will, dass sie nicht zu den Anschlüssen im Erdgeschoss passen, dann bekommt er Probleme z.B. mit der Entwässerung und dem Gefälle in den Kanalleitungen. So ähnlich lässt sich das auf die Performance-Probleme so mancher Software auch übertragen …

    Ich sehe nach meinem Bauprojekt keinen großen Unterschied zwischen beiden Disziplinen mit dem Unterschied, dass man auf dem Bau einen Bauherrenwunsch als Claim nicht als etwas Negatives auffasst. Der Bauherr wird professionell auf die Mehrkosten aufmerksam gemacht und entscheidet dann, dass es ihm das Wert ist oder auch nicht und lebt dann mit den Kostensteigerungen. In der IT führt man sich dann als Fachbereich auf. Da das Objekt auf dem Bau greifbar ist, man sich andere ähnliche Objekte anschauen kann, kommt es eben seltener vor, dass der Bauherr stur auf Wünsche besteht, die einfach nicht funktionieren. Ein Architekt hat es in der Regel da einfacher als das IT-Pendant, aber die prominenten Beispiele u.a. Flughafen Berlin, Hamburger Elbphilharmonie etc. zeigen, dass das nicht immer stimmt, weil es auch auf dem Bau beratungsresistente Fachbereiche gibt.

    AntwortenLöschen
  2. Vielen Dank für Ihren Kommentar! Die wesentliche Schnittstelle, auf die ich aufmerksam machen wollte, ist die zwischen dem, der das Fachgebiet beherrscht und dem, der den Entwurf macht. Ich wollte darauf aufmerksam machen, dass
    diese beiden Gebiete leider nicht durch ein Fachgebiet abgedeckt werden, sondern durch zwei Fachgebiete, die weder über dieselbe Fachsprache, noch über dieselben Modelle verfügen. Ich würde denken, dass ist etwas besonderes in der Softwareentwicklung, da hier Fachgebiet und Entwurf oft getrennt sind, außer ich erstelle einen Compiler. Auf keinen Fall möchte ich ignorieren, dass in allen Branchen Murks gemacht werden kann. Auch ist es möglich, dass die Mitarbeiter der entsprechenden Branche ihr Handwerk nicht verstehen. Sind die Fehlschläge in der Baubranche wirklich genauso hoch wie in der Softwarebranche? Wenn ja, würde ich daraus ableiten, dass der eklatante Wissensbruch auch in der Baubranche behoben werden muss.

    AntwortenLöschen
  3. Hallo zusammen.

    Der Wissensbruch erscheint mir universell, unvermeidbar und sogar nützlich.

    1) Der Wissensbruch ist universell.
    Bauprojekte liefern prominente Beispiele für Fehlschläge, weil sie in der breiten Öffentlichkeit aufgrund ihrer Sichtbarkeit und Kosten besonders gut wahrgenommen werden: Flughafen Berlin, Stuttgart 21, Limburger Bischofsresidenz (alle ganz in der Analogie von rolandInterFace).

    In der Softwarebranche finden eher nur IT-Experten zahlreiche und gute Beispiele. Das liegt an unserer selektiven Wahrnehmung unserer IT-Welt.

    Prinzipiell hat jede Branche so ihre Wissensbrüche - z.B. wenn der Manager einer Logistik-Firma verlangt, dass der Einkauf 4-achsige LKW beschaffen soll. Dumm nur, dass die benötigten zusätzlichen Aufbauten so schwer sind, dass die Firma damit keine größeren Lasten transportieren kann als vorher mit 3-achsigen. Da ist wohl zwischen Fachabteilung, Anforderungsanalyst und Umsetzung einiges schiefgelaufen....


    2) Der "Wissensbruch" ist unvermeidbar
    Grund für den Wissensbruch ist nicht die Trennung von Fachabteilung und Entwurf - der Grund ist die Arbeits- und Verantwortungsteilung an sich. Der "Wissensbruch" kann überall dort entstehen, wo mehr als ein Mensch an einem komplexen Problem arbeitet - also in der Teamarbeit.

    Teamarbeit erfordert Kommunikation. Und diese schlägt häufig fehl - selbst wenn man sich Fachsprachen und Modellen bedient. Die Ursache sind die bereits erwähnten Tilgungen, Verzerrungen und Generalisierungen.

    Hinzukommen noch weitere Faktoren, die eine "echt" objektive Zusammenarbeit zwischen Individuen unmöglich machen:
    - psychologische Fehlschlüsse ("in 95% der Fälle gehen wir von uns selbst aus")
    - Befindlichkeiten ("ich will das nicht, weil es unbequem ist")
    - Beziehungsaltlasten der Vergangenheit ("Der hat es schon früher nie verstanden")
    - Ängste ("wenn ich das so mache, dann wird ein Mitarbeiter überflüssig")
    - Das Hammer-Nagel-Problem ("Für einen Hammer sieht jedes Problem wie ein Nagel aus")
    - etc......

    3) Der Wissensbruch ist nützlich
    Meiner Erfahrung nach sollten Konzepte und Modelle in immer größer werdenden Kreisen aus Fachabteilung und IT "zirkulieren". Ich mache das in meinen Projekten, weil ich überzeugt bin, dass niemand ein komplexes Problem vollständig verstehen kann.

    Die Fachabteilung kocht ja in Wahrheit schon immer im eigenen Saft und ist per se unfähig zur Innovation. Der Fachexperte kann dem Requirements Engineer eigentlich selten mehr sagen als: "Ich will das machen, was ich bisher immer gemacht habe - nur bequemer und schneller." --> Das sind die Projekte zum Optimieren der Wachskerze.

    Echte Durchbrüche kommen nur durch Friktionen zustande, z.B. durch
    - Austausch im Rahmen von Kongressen, Tagungen, etc.
    - Fachliche Beratung
    - Prozessverbesserung, Organisationsveränderung oder Process Reengineering
    - Analyse von Kundenbedürfnissen
    - etc.

    Um ein möglichst optimales Ergebnis zu erzeugen, sollte also um ein Softwareprojekt herum ein Kommunikationsprozess entwickelt werden. Dieser Kommunakationsprozess sorgt dafür, dass
    - Jeder "Wissensbruch" transparent / augenscheinlich wird
    - Bewusst kognitive Dissonanzen gefördert werden
    - Lücken, Redundanzen und Fehler erkannt und behoben werden
    - Echte Innovation entsteht
    - Eine aus verschiedenen Blickpunkten aussagekräftige und verständliche Dokumentation entsteht (nicht als alleiniges Produkt, sondern sozusagen als Verschriftlichung der wichtigsten Erkenntnisse aller Teilnehmer und "Marker" ihres impliziten Wissens)

    These: Bewusst mit dem Wissensbruch arbeiten, denn beheben kann man ihn nicht.

    AntwortenLöschen