Soziale Strukturen in Software Projekten

Woher wissen wir über die implizite Kritik am Alten? Ohne diese sind bestimmte Phänomene neuer Projekte (s.u. Beobachtungen, Neues Projekt) einfach nicht zu verstehen.

Was wird explizit bemängelt?

In den seltensten Fällen erfolgt jedoch eine genaue Analyse der Stellen im System, die diese Probleme verursachen. Damit bleiben grundsätzliche, strukturelle Probleme verborgen und den Verfechtern des alten Systems bleibt immer der Ausweg, dass man dieses oder jenes Merkmal ja noch nachrüsten könne. Diese Auslassung kann fatal sein: Lässt sie doch das alte Konzept bzw. System als mögliches Paradigma weiter bestehen und stellt gleichzeitig die Notwendigkeit des neuen Systems bzw. des neuen Denkens in Frage.

Bei genauerem Hinsehen (sprich eigener Erfahrung mit dem alten System) zeigen sich jedoch schnell auch organisatorische und soziale Kritikpunkte, die jedoch im allgemeinen höchstens hinter vorgehaltener Hand ausgesprochen werden.

Der letzte Kritikpunkt richtet sich meist auf die starren Konzepte und Denkkategorien der bisherigen Entwickler, die öfters in direktem Widerspruch zu Business-Strategien geraten.

Genau wie die sozialen und organisatorischen Kritikpunkte werden auch die alten Denkmuster kaum offen angegriffen. Im Umgang mit ihnen offenbart sich die grösste Hilflosigkeit. Meist bleiben im Umgang mit alten und neuen Denkmustern nur Wege der Trennung.

Im folgenden wollen wir zeigen, welche soziale Strukturen ein neues Softwareprojekt entwickelt, bzw. von welchen es getrieben wird. Unsere Behauptung ist, dass diese Strukturen letztlich dazu führen, dass aus dem Neuen wieder ein Altes wird, das wieder nur durch eine Revolution abgelöst werden kann. Die Replikation der sozialen Strukturen als Ursache dafür, dass es in der Softwareentwicklung scheinbar immer nur Revolutionen und kaum Evolution gibt.

Nachdem wir diese Erfahrungen aus einer relativ kleinen Firma niedergeschrieben und an Kollegen in Grossprojekten und Grossfirmen verteilt hatten, war die für uns erstaunlichste Rückmeldung, dass dies genau die Vorgänge bei Grossprojekten mit Milliarden DM Budget widerspiegeln würde.

Ist das Leiden am Alten und der Weg zum Neuen wirklich unabhängig von der Grösse der Firmen?

Oft stellt eine Firma für ein Softwareprojekt mit neuer Technologie neue Leute ein. Wieso soll/kann es nicht mit den alten Mitarbeitern angegangen werden? Vermutung: Es hat mit einer „hidden agenda", der oben angesprochenen Unzufriedenheit nicht nur mit technischer Leistung der alten Produkte, sondern auch mit der sozialen Organisation der Leistung und alten Denkbildern, zu tun.

Neue Leute bedeuten eine – noch – offene soziale Struktur. Es lässt sich noch etwas bewegen, da die Rollen noch nicht fest verteilt sind.

Neue Leute werden so ausgesucht, dass sie die „neuen" Denkmuster und Konzepte bereits mitbringen. Ein stilles Eingestehen der Tatsache, dass die alten Mitarbeiter dazu nicht mehr zu bewegen sind.

Immer häufiger werden neue Projekte jedoch auch durch „outsourcing" gestaltet, bzw. die neuen Leute werden nicht als Mitarbeiter angestellt, sondern stehen in einem Selbständigen-Verhältnis. Wieso entscheiden sich Firmen dazu, ehemalige Kerngebiete ganz in die Verantwortung von Firmenfremden zu geben? Unsere Vermutung ist, dass dahinter ein stilles Eingeständnis des Managements liegt, dass sich das neue Projekt im eigenen Haus wieder zum gleichen Problemfall wie das alte entwickeln würde. Teilweise stehen wohl auch grundsätzliche Erkenntnisse über den Konflikt zwischen eigenem Business und Eigenentwicklung von Software dahinter (siehe Architekturen und soziale Gliederung weiter unten).

Symbolik des Raumes – ein in der Literatur oft genutztes Mittel. Tatsache ist, dass viele Leiter neuester Technologieprojekte sich dazu entscheiden, aus dem bestehenden Standort wegzugehen. Der Verlust bestehender Infrastruktur wird ausgeglichen durch mehr Flexibilität und dem leichteren Aufbau einer neuen Gruppenkultur in Abgrenzung zum Bestehenden. Neuer Raum vermittelt das Gefühl von mehr Dynamik. Sonderrechte sind leichter zu geben, was unter den Mitarbeitern zur Mehrarbeit führt – oft viel mehr als unter den Mitarbeitern die unter dem standardisierten und kontrollierten Regime des Hauptsitzes arbeiten.

Eine soziale Struktur die schnell sichtbar wird, genauso wie das Spannungsfeld, das sie ergibt.

Was zeichnet die alten Mitarbeiter aus?

Das Wissen um ein bestehendes Produkt, oft in Form eines geheimnisumwitterten Spezialwissens um obskure Details der Implementation. (Wieso ist dieses Wissen etwas besonderes? Liegt es nicht offen zu Tage? Ist EDV immer noch hauptsächlich blosses Wissen von Sachverhalten?)

Erfolge – das alte Produkt existiert und wird verkauft.

Eine bestehende Gruppe, die sich seit längerem kennt, eine Gruppenkultur entwickelt hat. Offene Frage: Wieso braucht es die Neuen? Wieso haben die Alten das neue Projekt nicht bekommen? Ist dies eine indirekte Kritik der Geschäftsleitung an ihnen? Ist das alte Produkt, das so erfolgreich war, plötzlich nicht mehr gut genug? Man könnte doch das alte genauso weiterentwickeln! (Siehe Thomas Kuhn zur Struktur wissenschaftlicher Revolutionen).

Sollen die Neuen mal sehen, wie sie mit den Problemen der Anwendungsdomäne klarkommen.

Fragen: Warum hat man die neuen Kenntnisse nicht erworben? Weil man zu beschäftigt war, die Firma aufzubauen, das momentane Produkt zu entwickeln. Jetzt wo man es geschafft hat, kommen neue Leute und ernten die Früchte.

Was zeichnet die Neuen aus?

Fehlendes Detailwissen des bestehenden Systems. Oft neuere technische Kenntnisse. Oft viel geringere Kenntnisse der Applikation-Domain.

Ergebnis: Verweigerung der Zusammenarbeit. Information-Hiding (im Sinne der Vorenthaltung von Informationen). Heimliches Weiterentwickeln des alten Systems. Grabenkämpfe, Koalitionen. Die neuen Leute stehen vor zwei Alternativen: Versuch der Kooperation oder Alleingang unter Duplizierung vorhandenen Wissens. Wenn gleichzeitig ein Ortswechsel vollzogen wurde, hat die Leitung des neuen Projektes entschieden, den Problemen aus dem Weg zu gehen.

Hauptmerkmal neuer Entwicklungen ist fast immer eine neue Sprache, ein neues Kategorisierungssystem.

Aus einem Architekturdokument einer Grossbank:

Die Informationsstruktur [..] versteht sich als Kommunikationshilfsmittel und vermeidet daher möglichst Begriffe, die heute schon zu Missverständnissnen führen. Insbesondere werden bewusst neue Begriffe gewählt, wenn durch die Weiterverwendung eines etablierten Begriffs der Umfang eines Themas eingeschränkt würde.

Die Informationsstruktur bildet letztich das Gliederungskriterium für die Bildung von Service-orientierten Kompetenzzentren.

An dieser Aussage sind mehrere Dinge bedeutsam:

Der Kampf um die Worte nimmt manchmal fast lächerliche Dimensionen an, wenn z.B. in einem Meeting die Alten beharrlich von „Beleg" sprechen, die Neuen jedoch von „Dokument". Es wäre zu überlegen, ob eine Sprachanalyse den Grad der Integration neuer Technologie in einer Firma anzeigen könnte. Wenn z.B. nach längerer Entwicklung die alten Mitarbeiter immer noch von „Beleg" sprechen, dann darf die Integration der neuen Technologie angezweifelt werden, und es liegt ein enormes Problem für die Firma vor.

Wieso entsteht die neue Sprache? Eine Technologie bringt meist eine neue Sichtweise des Gegenstandsbereichs mit sich. Diese Sichtweise kann die Begriffe des alten Systems nicht verwenden, da diese eben an das alte System gebunden sind. Es würden Doppeldeutigkeiten entstehen und die Möglichkeit von neuer Abstraktion und Verallgemeinerung genommen.

Das Ausmass der unterschiedlichen Sprachwelten lässt sich z.B. daran erkennen, dass die Architekturdokumente zur Softwarearchitektur von SBC und UBS sich jeweils pro Technologie gleichen, d.h. die Unterschiede zwischen den Firmen sind weitaus geringer als zwischen den Technologien.

Selbstbilder:

Das Bild vom (meist männlichen) Einzelkämpfer, der im stillen Kämmerlein grossartige Software entwickelt. Träume von Macht und Kontrolle. Ungeduld ist das zentrale Kennzeichen vieler in der EDV Tätigen – alles ist so mühsam und dauert ohnehin so lange. Kommunikation und Wissenweitergabe sind mühsam, halten von der Arbeit ab. Abstimmen und auf andere angewiesen zu sein ist unangenehm.

Gruppenkultur: Schweigeorden und die Dominanz einzelner.

Immer wieder stösst man auf das Phänomen der Gruppenkultur in Entwicklungsprojekten. Einzelne Personen dominieren so stark, dass sie ein bestimmtes Gruppenverhalten erzwingen. Im Extremfall entsteht ein Schweigeorden.

Fragen:

Wieso kommt die Dokumentation immer am Ende?

Welchen Einfluss hat die Ausbildung (Mathematiker, Physiker, Ingenieure)?

Bei den Ersten eines neuen Softwareprojektes zu sein, ist ein grosser Vorteil: Arbeitsteilung ist noch nicht so ausgeprägt. Man ist gezwungen, in vielen verschiedenen Gebieten zu arbeiten, Grundlagen zu schaffen, Überblick zu verschaffen. Die Organisationsstrukturen sind unscharf, offen, flexibel.

Man erwirbt schlichtes Faktwissen (die DLL xyz.dll arbeitet intern mit 2-byte-alignment, weil die verwendete externe Library es ursprünglich mal so benötigte).

Später Eingestellte treffen in mehrfacher Hinsicht auf starrere Strukturen: Die Software ist bereits entstanden, vorstrukturiert. Und die Organisationsstruktur hat nur noch spezifische Leerstellen („Wir brauchen noch eine zweite Person für die Datenbank") mit genau definierter Funktionalität. Und es gilt das „Closed shop"-Prinzip: Projekte schweissen zusammen, es entsteht eine Gruppenkultur die es dem Neuen u.U. extrem schwer macht einzusteigen. Verhaltensregeln, oft unausgesprochen, sind in Kraft.

Ergebnis: Die Trennung in Alte (altes Projekt) und Neue (neues Projekt) fängt nach kurzer Zeit an, sich auch im neuen Projekt zu replizieren.

Der Erfolg eines Projektes hängt entscheidend von der Auswahl der Mitarbeiter/Beteiligten ab. Bestimmte „Typen" von Entwicklern sind recht häufig anzutreffen und müssen daher bereits am Anfang eines Projektes identifiziert werden.

Wieso gelingt es in der Softwareentwicklung Leuten, sich als „Reichsbedenkenträger" durchs Leben zu schlagen? Es gelingt ihnen, sich ohne jede Abstraktionsfähigkeit durch komplexe Projekte zu schlängeln indem sie:

Gibt es in der Softwareentwicklung kein prüfbares Wissen? Wie schützt man sich vor solchen „Pragmatikern"? Z.B. indem man in Bewerbungsgesprächen auf Wissen über Design-Patterns abprüft und versucht den „Performance"-Bewussten zu identifizieren.

Ein weiterer häufig anzutreffender Typ ist der „Praktiker", der der Performance alle anderen Kriterien der Softwareentwicklung (wie z.B. Wartbarkeit und Erweiterbarkeit) unterordnet. Kennzeichnend für diesen Typ ist, dass er die Entwicklung der Hardware-Technologie hin zu weit schnelleren Systemen keinesfalls als Grund ansieht, seine Denkweise anzupassen.

Der Augen-zu-und-durch-Typ: Kennzeichnend für ihn ist dass er grundsätzlich keine Lebenszyklus- oder Systembetrachtung anstellt. Identifizieren lässt er sich dadurch, dass er sich als „Minimalist" bezeichnet, d.h. es genügt die Kenntniss einer Programmiersprache um Softwareentwickler zu sein. Man kann alles damit machen.

In my life as an architect, I find that the single thing which inhibits young professionals, new students most severely, is the acceptance of standards that are too low. If I ask a student whether her design is as good as Chartres, she often smiles tolerantly at me as if to say, `Of course not, that istn‘t what I am trying to do... I could never do that.‘

Then, I express my disagreement and tell her:`That standard must be our standard. If you are going to be a builder, no other standard is worthwhile. That is what I expect of myself in my own buildings, and is what I expect of my students.‘ [..] Once that level of standard is their minds, they will be able to figure out, for themselves, how to do better, how to make something that is as profound as that. (Christopher Alexander, Vorword to Patterns of Software by R.G.Gabriel)

Die Annahme, dass eine bestimmte Technologie entweder richtig oder falsch ist, ist für die Praxis der Softwareentwicklung ziemlich bedeutungslos. Entscheidend ist, ob eine Technologie eingesetzt wird. Und dies wiederum ist sozial determiniert.

Beispiel:

Jeder Entwickler merkt ziemlich schnell, dass er oder sie immer wieder vor derselben grundlegenden Entscheidung steht:

Es gibt ein Problem. Für dieses Problem gibt es eine Menge von Lösungen mit jeweils unterschiedlichen Kosten, Benefits und Entwicklungszeiten. Das „inventors paradox" behauptet nun, dass die allgemeingültige Lösung sich als die einfachere Lösung herausstellen wird. Dies beruht auf dem Effekt der Abstraktion, der Gemeinsamkeiten von Problemen und Lösungen sichtbar macht..

Anscheinend sollte es möglich sein, durch Schätzung den Aufwand zu ermitteln, die eigenen Requirements aufzustellen und danach zu einer rationalen Entscheidung zu kommen. Eine Folge davon müsste sein, dass recht häufig die generische Lösung genommen wird, weil sie eben einfacher und flexibler ist als Investition.

Tatsächlich fällt die Entscheidung nur sehr selten für die allgemeine Lösung. Warum?

Indikatoren:

Ausgezeichnete Entwickler erzeugen ausgezeichnete Entwickler.

Learning-on-the-job: noch immer die Art und Weise, wie das Wissen der Softwareentwicklung weitergegeben wird. Design-Patterns und Framework-Architekturen deuten hier eine Besserung an.

Was bedeutet das in der Projektpraxis? Es sind soziale Strukturen nötig, um die Wissensweitergabe zu ermöglichen.

Beispiel für Ausbildungsrichtlinien: Ausbildung neuer Mitarbeiter im CC-Inet (Internet Competence Center der Systor AG) in Java. Wollen wir einen „Java-Programmierer", einen Java-GUI Spezialisten oder einen Softwareentwickler mit breitem Horizont?

Nichts wird so oft gefordert und so selten erreicht wie die Wiederverwendbarkeit von Software. Ist der Mangel an Reuse ein technisches oder soziales Phänomen? Welche Rolle spielen Abstraktionen dabei? Wie sorgt die soziale Gliederung der Software-Entwicklung dafür, dass Software nicht wiederverwendet werden kann? Wie ist die Selbstsicht der Applikationsprogrammierer? Wie ihre Aufgabenstellung?

(Thanks to Roald Dahl, The Big Friendly Giant.)

Nichts ist so alt in der Software-Entwicklung wie der Traum vom Modul. Das Software-Modul steht für Wiederverwendbarkeit, Parallelisierung der Arbeit, Unabhängigkeit gegenüber Änderungen anderswo. Anhand von Modularer Dekomposition werden Systeme verständlich gemacht und Gruppen gegründet und Aufgaben verteilt.

Aber worauf gründet sich der Glaube an Module?

Die Wirklichkeit zeigt, dass beide Annahmen im Allgemeinen nicht zutreffen. Jeder Kategorisierung nach einem Prinzip lassen sich beliebige andere gegenüberstellen, die zu ihr im Widerspruch stehen, aber dennoch wichtige Aspekte des Systems erfassen. Und funktionale Dekomposition bis hin zu kleinesten „atomaren" Einheiten vergisst immer, dass z.B. der Wert von Information nicht nur atomar bestimmbar ist, sondern aus den Verbindungen der Informationen untereinander mitbestimmt wird.

In diesem Sinne kann sogar die sog. objektorientierte Herangehensweise als auf wackligen Füssen stehend angesehen werden.

Was die Zusammenarbeit betrifft (Parallelisierung, Vereinfachung), so entstehen gerade durch die Module und die damit verbundenen Kategorisierungen die Barrieren, die eine Gesamtsicht des Systems erschweren und oft zu endlosem Streit führen: „Warum unterstützt euer Modul dies und jenes nicht?"

Durch die soziale Gruppenbildung an den Grenzen von Modulen wird aus einem Mangel an Funktionalität ein politisches und soziales Problem.

Wieso stimmen die technischen mit den sozialen Gliederungen so auffällig überein? (Sogar die neuesten Komponentenmodelle wie Enterprise-Java-Beans definieren wieder verschiedene Rollen und Gruppen).

Was am Frameworkmodell war für die Applikationsleute unannehmbar? (Sie mussten während der Arbeit den Hut wechseln; je nachdem an was sie arbeiteteten, waren sie Systemgruppe oder Applikationsgruppe: Trennung von Rollen und Gruppen wurde abgelehnt.

Wieso brauchen wir in der EDV immer Bilder für Architekturen? Z.B: werden die oben genannten Strukturen der Softwarearchitektur als Kästchen gemalt – verdinglicht. Natürlich sind es keine „Kästchen", haben keine scharfen Ränder – sind letztlich überhaupt nichts „Wirkliches".

Der „Verdinglichungseffekt" hat – ähnlich wie die sprachliche Kategorienbildung – jedoch meist unmittelbare Auswirkungen: Aus den verdinglichten Kategorien werden durch unterschiedliche Aufteilung von Aufgaben sofort soziale Gliederungen in Form von Gruppen und Abteilungen abgeleitet. Der ursprüngliche gemeinsame Gegenstand – das System in seinem Lebenszyklus – verschwindet.

In letzter Zeit sind die sog. „Ilities" als Problemfelder der Softwareentwicklung besonders hervorgehoben worden:

„Ilities are architectural properties that often can cut across different levels or components of a system‘s architecture to be properties of the whole" [OMA-NG]

(Interoperability, composability, evolvability, extensibility, tailorability, security, reliability, adaptability, survivability, afforadability, maintainability, understandability...)

Von welcher Art sind Kategorien wie Sicherheit, Zuverlässigkeit, Qualität, Performance, Wiederverwendbarkeit?

Sie haben gemeinsam, dass sie die gesamte Softwarearchitektur durchdringen. Sie können also nicht durch Interfaces einfach isoliert werden. Dadurch, dass sie nicht isoliert werden können, ist es auch schwierig, sie physisch auf „Module" abzubilden. Daraus folgt wiederum, dass die soziale Abbildung auf eine Rolle bzw. Gruppe schwierig ist.

Wie kann man folgendes Phänomen erklären? Akademiker, teils mit Doktortitel gehen nach dem Studien in die Industrie und werden Softwareentwickler. Nach einigen Jahren praktischer Programmierung erscheinen sie

Es sieht so aus, als als sei ihnen die softwaretechnische Realität, die sie bei Beginn ihrer praktische Tätigkeit kennengelernt haben, geradezu zur absoluten Wirklichkeit geworden, die gar keine Alternative mehr zulässt: Die Welt ist 8 Bit breit und 64 KB gross geworden.

Eine Erscheinung, die nur in Analogie zum Begriff des „Verkafferns" erklärt werden kann. Jemand ist von einer neuen Lebenswelt so gefangengenommen, dass er vorherige Sichtweisen und Fähigkeiten verliert und diese neue Lebenswelt als ausschliessliche, faktische und richtige ansieht.

Weitere mögliche Einflussfaktoren sind:

Das wirklich Schlimme daran ist, dass das Verkaffern keinesfalls nur Nicht-Informatiker betrifft. Selbst diejenigen mit Informatikausbildung zeigen dieses Verhalten.

Wie kann man folgendes Phänomen erklären? Bei vielen Spezialisten bekommt man das Gefühl, dass für sie ein bestimmtes Produkt, mit dem sie arbeiten, gleichbedeutend mit der Thematik geworden ist. Z.B. sieht ein Novell-Spezialist Networking als alles was Novell definiert, hat und kann. Der Spezialist verfügt nicht mehr über eine abstrakte Vorstellung von Networking. Teilweise bekommt man das Gefühl, dass die intime Kenntnis des Produktes einen guten Teil der Identität ausmachen.

Erklärungsversuche:

Das Fatale an dieser Form des „Verkafferns" ist, dass es zunächst für die Firmen produktiv erscheint, wenn jemand nur durch „Knöpfchen drücken" Dinge wieder in Gang bringt. Auf die Dauer stellt sich jedoch heraus, dass eine kritische Sicht des Produktes nicht mehr möglich ist. Bei Wechsel des Produktes (natürlich gegen extremen Widerstand des Spezialisten) erlischt das Wissen der Mitarbeiter.

Wieso gilt heute das Wasserfallmodell für die Softwareentwicklung als gescheitert? Es scheint in seiner Trennung von Analyse, Design und Implementation doch die wesentlichen Schritte des Entwicklungsprozesses zu beinhalten. Es scheitert meiner Ansicht (W. K.) nach auch nicht nur technisch – d.h. es ist ihm technisch nichts immanent, was zu einem Scheitern der Entwicklung führen müsste – es scheitert vielmehr, weil es eine technische Strukturen mit sozialen Strukturen in sehr problematischer Weise verknüpft.

Begründung:

Die Basis für den Cocktail sozialtechischer Probleme wird mit der Arbeitsteilung geschaffen, fein unterteilt nach Analytikern, Designern und Implementatoren (gemeinhin „Kodierschweine" genannt. Dass dies keine nur horizontale Arbeitsteilung ist, zeigt sich darin, dass die Gehalts- und Prestigeverteilung rein vertikal ist: Analytiker bekommen am meisten Gehalt und Prestige. Bekommen Designer noch Visitenkarten?

Den einzelnen Arbeiten wird der Inhalt der auszuführenden Rolle genau festgeschrieben. Es entstehen Identitäten, die sich genau mit diesen Rollen identifizieren. An der Spitze ein Gefühl der Überlegenheit, verbunden mit einer Abscheu vor konkreten, „design- oder implementationspezifischen" Dingen, den Niederungen des Alltags. Am Ende das Gefühl derjenige zu sein, der den ganzen Unsinn der Analytiker und Designer letztlich ausbaden muss, bzw. durch eigene Vorstellungen so hinbiegen muss, dass das Produkt letztlich fertig wird. (Es sind Fälle bekannt, wo Implementationsgruppen am Ende ihr eigenes Design entwarfen, da das offizielle angeblich nicht zu gebrauchen war).

Für jede der drei Rollen werden eigene Wertsysteme, Rituale und Rechtfertigungen entwickelt. Irgenwie muss ja der soziale Unterschied gerechtfertigt werden. Für „die ganz unten" verstehen „die ganz oben" einfach nicht, dass die eigentliche Arbeit ganz unten geleistet wird und umgekehrt.

Und letztlich unterliegt dem Ganzen noch eine zeitliche Struktur der Form, dass Analyse vor Design und Design vor Implementation zu geschehen hat. Daraus ergibt sich die Notwendigkeit kompletten Wissens für das Wasserfallmodell. Wenn dieses komplette Wissen nicht auf allen Ebenen gegeben ist, dann sorgen die sozialen Schranken dafür, dass jede Korrektur den Anstrich von Fehler, Versagen hat. Rückmeldungen von unten nach oben sind schwierig und immer gleich ein Politikum. Wissen über den Zusammenhang von Analyse, Design und Implementation entsteht nirgends.

Häufig werden die Arbeitsschritte auch noch an verschiedene Firmen vergeben. Damit wird eine klare Strukturierung der Verantwortlichkeiten angestrebt, im Regelfall entsteht jedoch an den Übergängen enorme politische Spannung. Wasserfallmodelle enden meist in Form des Fingerzeigens. Die wichtigste Tätigkeit in Wasserfallmodellen besteht darin alle Gespräche, Vereinbarungen etc. genau zu dokumentieren, um bei Bedarf Munition für die politische Auseinandersetzung zu haben.

Obwohl das Modell heute nicht mehr so oft angewandt wird, spielen sich ähnliche Szenen doch immer wieder zwischen Gruppen ab, die an einer gemeinsamen Entwicklung beteiligt sind. Opfer sind meist genau die technischen Probleme, die eine übergreifende Sichtweise gebraucht hätten. Nur ist die Strukturierung hier eine horizontale statt wie im Wasserfallmodell eine vertikale.

Wie kann vermieden werden, dass die vertikale Struktur des Vorgehens nach Analyse, Design und Implementation in eine ebenso vertikale soziale Struktur einmündet? Die Regel lautet dazu ganz einfach, dass wer eine Analyse erstellt, auch am Design und in der Implementation mitarbeitet. In der Praxis sind dies erfahrene Softwarearchitekten an deren Seite jüngere Kollegen und Kolleginnen an allen Phasen mitarbeiten. Die praktische Erfahrung aus der Implementation sorgt wiederum für den notwendigen Feedback, den auch der Architekt braucht.

Wieso gibt es kaum Frauen in der Systementwicklung?

Wieso findet man mehr Frauen in der Modellierung (z.B. OOA, Datenmodellierung, SGML) oder in den analytischen Bereichen (Data-Mining, Data-Warehouse)?

Lassen sich die Ergebnisse der IIG Studie zum Studienanteil von Frauen in der Informatik auch damit in Zusammenhang bringen?

Am Anfang beruht die Kommunikation fast ausschliesslich auf informellen Beziehungen. Jeder kennt jeden. Allmählich entstehen neue Gruppen. Einzelne Mitarbeiter werden jetzt Vorgesetzte. Noch verlassen Mitarbeiter kaum das neue Projekt. Aussenkontakte entstehen (andere verwenden die Produkte des neuen Projektes). Mehr und mehr treten formelle Beziehungen auf, oft gegen den Widerstand der Entwickler eingeführt. Z.B. zieht das Projekt zurück an den Standord der Firma. Vorbei mit dem Sonderweg.

Viele „altgediente" Mitarbeiter des neuen Projektes empfinden dies als schlecht und verlassen die Firma. Kritikpunkte sind mangelnde Flexibilität, keine Dynamik mehr, Bürokratie etc. Man kann sagen, dass ein Gefühl grosser Enttäuschung entsteht, und die Kritikpunkte sind nicht weit weg von denen am alten Projekt.

Soziale Strukturen: Grösse von Gruppen, Abteilungen. Grad der Organisation. Grad der Arbeitsteilung. Die Rolle von Privilegien.

In der Praxis wenig beachtet wird die zeitliche Dimension eines Softwareprojekts. Dies wird begünstigt durch die Arbeitsteilung, die das Kategoriensystem aller Beteiligten formt. Dies führt dazu, dass die Aspekte nachgeordneter Gruppen in der Entwicklung wenig Beachtung finden – z.B. im Design überhaupt nicht auftauchen.

Beispiel: Was ist ein Softwareprodukt?

Problem: Der Entwickler kennt die Files, der Service nicht. Die Software muss über sich selbst Auskunft geben können, damit der Service seine Aufgabe erfüllen kann.