Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

18.01.1991 - 

Häufig geht es bei der Software-Entwicklung gar nicht so sehr um die Sache

Oft siegt die "Politik" über den technischen Sachverstand

Software-Entwicklungsprojekte, vor allem solche, durch die eine historisch entstandene DV-Landschaft in einem Unternehmen durch ein neues, integriertes System abgelöst werden soll, haben sich häufig mit sehr unterschiedlichen Interessen auseinanderzusetzen. Oft entwickelt die Wechselbeziehung zwischen technischer und "politischer" Entwicklung eine Eigendynamik, die sich als schwer steuerbar erweist.

Im Rahmen des Projektes IPAS (Interdisziplinäres Projekt zur Arbeitssituation in der Software-Entwicklung) haben wir Ablauf und Struktur von bislang etwa 15 Software-Entwicklungsprojekten untersucht. Bei den ausgewählten Projekten handelt es sich zwar um keine repräsentative Stichprobe, es wurden jedoch sehr unterschiedliche Projekttypen in die Untersuchung einbezogen. Ein Projekttyp ist in unserer Auswahl verhältnismäßig häufig vertreten: Vorhaben, durch die eine historisch über einen längeren Zeitraum in einem Unternehmen entstandene DV-Landschaft durch ein neues, integriertes System abgelöst werden soll. Die folgenden Ausführungen sind stark, wenn auch nicht ausschließlich von den Erfahrungen in diesen Projekten geprägt.

Eine erste Analyse des vorliegenden Materials zeigt eine beträchtliche Vielfalt in der Gestaltung der Projekte, etwa in der formalen Projektorganisation, der projektinternen Arbeitsteilung, der Regelung der Kontakte zum Anwenderbereich, der Projektsteuerung und

-kontrolle. Hinter dieser Vielfalt war aber auch eine Reihe von Gemeinsamkeiten zu erkennen.

Im Rückblick der Projektverantwortlichen auf den Verlauf nahm durchweg der Abschnitt bis zur eigentlichen Realisierung den weitaus größten Raum ein. Besonders in großen, "anspruchsvollen" Projekten hatte dieser Abschnitt wesentlich länger gedauert als man es erwartet und geplant hatte, erwies sich als schwerer steuerbar und vor allem recht konfliktträchtig. Ein Schlüsselproblem, auf das sich die Schilderungen vor allem bezogen, war die Erarbeitung der Anforderungsspezifikationen, aus denen die Vorgaben für die Gestaltung der Software abgeleitet werden. Verbindliche, das heißt allgemein akzeptierte Anforderungsspezifikationen stellten sich in den meisten Projekten als der archimedische Punkt dar, von dem aus die Lösung der anschließend auftretenden Probleme entscheidend abhing.

Der Weg zum Konsens über die Anforderungen ist lang

Zwar trafen wir Projekte, in denen der Prozeß der Anforderungsspezifizierung offensichtlich reibungslos verlaufen war - wo beispielsweise der Auftraggeber dem Software-Entwickler mehr oder minder spezifische Vorgaben übermittelt hatte, die dieser dann abarbeitete, mit nur gelegentlicher Abstimmung im weiteren Verlauf (wobei im Augenblick offen bleiben muß, wie lange die Erarbeitung der Anforderungsspezifikationen beim Auftraggeber gedauert hatte und wie zulänglich sich diese dann später erwiesen).

Anders allerdings verliefen Projekte, in denen eine Auseinandersetzung über die Definition der Anforderungen zwischen Auftraggebern, späteren Anwendern und Software-Entwicklern durch die Entstehung, die Organisation und institutionelle Stellung des Projektes im Unternehmen faktisch vorgegeben und damit unvermeidlich war. In diesen Projekten erwies sich die Erarbeitung der Anforderungsspezifikation fast durchweg als sehr aufwendig und kontrovers. Es wird von zahlreichen Sitzungen, Besprechungen, Entwürfen und Gegenentwürfen berichtet, die erforderlich waren, bis man sich auf eine Vorlage geeinigt hatte, mit der alle beteiligten Stellen einverstanden waren. Die Zeit, die diese Sitzungen, ihre Organisation, Vorbereitung und Nachbereitung erforderte, addierte sich zu einem Volumen, das schließlich einen ins Gewicht fallenden Anteil am Gesamtaufwand ausmachte, allerdings nur zu einem Teil in der offiziellen Aufwandsberechnung auftauchte.

Der Weg zu dieser Einigung ähnelte meist einer "Echternacher Springprozession": Eine Vorlage wurde erarbeitet, in Frage gestellt, führte zu einer Überarbeitung, wenn nicht gar zu einer weitgehend neuen Vorlage, diese wurde wiederum diskutiert, mit erneuten Änderungsauflagen versehen usw. Nicht selten wurde auch die "endgültige" Vorlage dann im weiteren Projektverlauf noch mehrmals in Frage gestellt, modifiziert und erweitert. In den meisten Projekten wurden die Verzögerungen, die schließlich zur Überschreitung der ursprünglich veranschlagten Projektlaufzeit geführt hatten, nicht zuletzt auf den langwierigen Prozeß der Definition der Anforderungen zurückgeführt.

Die Erarbeitung eines verbindlichen Satzes von Anforderungsspezifikationen gestaltete sich in diesen Projekten so aufwendig, nicht allein weil hier technische und fachliche Aspekte von hoher Komplexität berücksichtigt werden mußten, sondern weil sich im Laufe des Entwicklungsprozesses die Rahmenbedingungen und Vorgaben ständig änderten: durch die technische Entwicklung (neue Hard- und Softwareangebote, Veränderungen im Preisgefüge etc.), durch inner- oder außerbetriebliche Gegebenheiten (Organisationsstruktur, Geschäftspolitik, Marktanforderungen etc.) und schließlich durch die Eigendynamik des Entwicklungsprozesses selbst. Mit der zunehmenden analytischen Durchdringung des Gestaltungsproblems und der Konkretisierung einzelner Gestaltungsansätze ergaben sich häufig neue Ansatzpunkte und Anforderungen. Bei einem dreijährigen Entwicklungsprojekt führte allein die erste Präsentation des Systementwurfes zu 600 Anforderungsveränderungen.

Divergenzen zwischen einzelnen Gruppierungen

Aufwendig gestaltete sich die Formulierung der Anforderungsspezifikationen aber vor allem deshalb, weil zahlreiche und häufig sehr unterschiedliche betriebliche (teilweise auch außerbetriebliche) Stellen einzubeziehen waren, und weil auch die Notwendigkeit bestand, einen Konsens zwischen diesen Stellen zu bewerkstelligen. So wurden in einem anderen Projekt, in dem ein integriertes administratives DV-System von der DV-Abteilung eines Großunternehmens entwickelt wurde, insgesamt 26 Ausschüsse, Projektgruppen, Fachberatungsteams etc. gebildet, in denen etwa 30 verschiedene Stellen vertreten waren.

Zur Überraschung aller Beteiligten erwies sich dies in den meisten Projekten als ausgesprochen schwierig. Es fing bei dem Problem an, kompetenten Input von allen involvierten Stellen zu erhalten und endete mit dem Problem, eine gemeinsame Basis für die häufig recht divergierenden Standpunkte und Interessen zu finden.

Die Notwendigkeit zum Interessenausgleich ergab sich aus den unterschiedlichen Wünschen, Zielvorstellungen und Erfahrungen, die Software-Entwickler einerseits sowie Auftraggeber beziehungsweise Nutzer andererseits in den Entwicklungsprozeß einbrachten. Bei den Software-Entwicklern standen tendenziell technik-immanente Aspekte im Vordergrund (etwa geringer Speicherbedarf, Kompatibilität, "professionelle" Qualitätskriterien wie "Eleganz" der Programme), bei den Nutzern dagegeben aufgaben- und arbeitsbezogene Aspekte (etwa Arbeitserleichterung und Reduzierung der Belastungen).

Divergenzen zeichneten sich auch zwischen einzelnen Gruppierungen von Nutzern ab. Die meisten Entwicklungsprojekte berührten - zumindest potentiell - bestehende Arbeits- und Einflußstrukturen in den Unternehmen, vor allem dort, wo der Einsatz von Software zu Veränderungen in den Aufgaben- und Arbeitstrukturen führte beziehungsweise führen konnte. Allein die Möglichkeit solcher Veränderungen verlieh Softwareprodukten eine betriebspolitische Qualität, das heißt sie wurden auf Interessensposition bezogen.

"Technische" Entscheidung beeinflußt die Karriere

Abweichende Interessen waren schließlich innerhalb der Software-Entwicklung zu erkennen: etwa zwischen hierarchisch übergeordneten und ausführenden Positionen, oder zwischen den in den einzelnen Phasen des Entwicklungsprozesses Beschäftigten, und nicht zuletzt zwischen den Vertretern verschiedener Programmiersprachen, Betriebs- und/oder Datenbanksystemen.

Viele "technische" Entscheidungen waren für die davon Betroffenen - in den DV-Abteilungen selbst wie in den Fachbereichen - zumindest potentiell mit Vor- und Nachteilen verbunden: Karriereaussichten, Qualifikationschancen, Handlungs- und Einflußspielräume wurden eröffnet oder eingeschränkt. Die Wahl etwa zwischen IBM oder DEC war keineswegs nur eine Entscheidung über eine technische Anlage, sondern auch über persönliche Zukunftsperspektiven. Die Wahl einer Programmiersprache konnte sich auf die Einflußverteilung zwischen DV und Fachbereichen auswirken.

Konsequenzen schwer einschätzbar

Entscheidungen über DV-Lösungen betrafen also zweierlei: die technische Lösung und deren nichttechnische Konsequenzen. Häufig waren diese Konsequenzen für die Betroffenen zunächst schwer einschätzbar und wurden oft erst im Verlauf des Entwicklungsprozesses, im Zuge der zunehmenden Konkretisierung des Softwareproduktes beziehungsweise bei seinem Einsatz im "Normalbetrieb" erkannt. Die Entwicklung aufgaben- und nutzungsgerechter Software setzt Wissen über den jeweils anderen Bereich voraus:

- bei den Software-Entwicklern vor allem über die Aufgaben, die Bedingungen und Anforderungen der Arbeitssituation, die durch das Softwareprodukt zu unterstützen sind;

- bei den Auftraggebern beziehungsweise Nutzern über das Leistungspotential und die Leistungsbeschränkungen der Software und die sich daraus ergebenden Möglichkeiten und Konsequenzen für die Gestaltung ihrer Aufgaben.

Dieses fachübergreifende Wissen war im Regelfalle nur recht lückenhaft vorhanden, Lernprozesse waren erforderlich, Lernprozesse, die die Grenzen zumindest einer engen Auffassung der eigenen Disziplin überschreiten mußten und für den Informationsaustausch zwischen Anwendungsbereich und Entwicklungsbereich sowie im Entwicklungsbereich selbst - eine große Rolle spielten.

Dieser Informationsaustausch stieß in den meisten Projekten auf Schwierigkeiten: den Fachjargon auf beiden Seiten, Zeitmangel, Unterschätzung der Wissenserfordernisse. Spürbar war auch hier die Wirksamkeit der Interessensdimension. Meist spielten in diesen Lernprozessen die jeweiligen "Kontrahenten" eine zentrale Rolle. Für die Software-Entwickler waren die Auftraggeber beziehungsweise Nutzer die wesentliche Informationsquelle, wie umgekehrt sie für diese. Entsprechend blieb es nicht aus, daß Informationen interessengesteuert erfolgten beziehungsweise auch vorenthalten wurden.

Diesen Behinderungen gegenüber erwiesen sich die formalisierten Instrumente der Wissensvermittlung (Ist-Analysen) meist als inadäquat. Als wesentlich tragfähiger erwiesen sich offensichtlich eingespielte persönliche Kontakte. Immer wieder wurde die enorme Bedeutung guter persönlicher Beziehungen zwischen den Akteuren in den verschiedenen Bereichen für den Erfolg eines Software-Entwicklungsprojektes betont, nicht zuletzt wohl weil diese eine informelle, nicht "explizite" Verarbeitung von Interessenaspekten erleichterten.

All diese Schwierigkeiten waren um so erkennbarer, je "ehrgeiziger", das heißt umfassender, integrativer die Zielstellung des Projektes war. Diese Projekte waren häufig von einer beeindruckenden Komplexität: durch ihren Umfang, durch die Zahl der zu berücksichtigenden Variablen, durch die Integration von Teilsystemen, durch die Bedeutung der Kompatibilität mit bereits eingesetzter Hard- und Software. Zu dieser Komplexität trug auch der Bezug zur Anwendungssituation bei. In dem Maße, wie die EDV-Verfahren zugleich umfassender und flexibler nutzbar werden, gewinnt die Anwendungssituation als Gestaltungsdimension an Bedeutung und muß im Prozeß der Software-Entwicklung mit berücksichtigt werden.

Retrospektive Korrekturen sind mitunter notwendig

Man könnte von einer strukturellen Komplexität sprechen: Software-immanente Gegebenheiten, das technische Umfeld, die qualifikatorischen und motivationalen Voraussetzungen bei den Nutzern, die Struktur des Anwendungsfeldes und der Aufgaben müssen gleichermaßen berücksichtigt und aufeinander bezogen werden.

Die Anforderungen, die sich aus diesen heterogenen Gestaltungsanforderungen ergeben, werden verstärkt durch die prozessuale Komplexität des Software-Entwicklungsprozesses. Diese ergibt sich vor allem aus der Notwendigkeit zu ständigen Feedbackprozessen und Korrekturschleifen. Es gilt, die im fortschreitenden Entwicklungsprozeß gemachten Erfahrungen auf die vorangegangenen Entwicklungsschritte rückzubeziehen, was möglicherweise zu "retrospektiven" Korrekturen, etwa in der Definition der Zielvorgaben, führt.

Sowohl die mehrdimensionale wie auch die prozessuale Komplexität ist natürlich allen Entwicklungsprozessen gemeinsam. Diese doppelte Komplexitätsproblematik stellt sich jedoch bei Software-Entwicklungsprojekten in besonderer Schärfe und in spezifischer Ausprägung. Daraus ergeben sich spezielle Anforderungen an die Gestaltung des Software-Entwicklungsprozesses: an die Regelung der Arbeitsteilung und der Kooperationsbezüge wie auch ihres Ablaufes. Dies gilt sowohl innerhalb des Entwicklungsbereiches wie auch für die Beziehung zum Anwendungsfeld.

Der Ablauf als Doppelprozeß

Dabei zeichnete sich ein Spannungsverhältnis ab zwischen der Notwendigkeit einer zunehmenden Arbeitsteiligkeit in der Organisation der Entwicklungsprozesse und der Notwendigkeit zur Integration. Fragen der Verteilung und Abgrenzung der Zuständigkeiten und Aufgaben sowohl innerhalb des Entwicklungsbereichs wie auch zwischen Entwicklungs- und Anwendungsbereich bekamen dadurch beträchtliche Brisanz.

Ein Spannungsverhältnis zeigte sich auch in der prozessualen Dimension zwischen der Notwendigkeit zu verbindlichen Zielsetzungen und Vorgaben und der Notwendigkeit zu ständigen Korrekturen im Laufe des Entwicklungsprozesses. Die zu Beginn eines Projekts definierten Zielvorgaben können nur vorläufigen Charakter haben. Ihre Korrektur wird allerdings meist erschwert durch die "politische" Funktion dieser Zielvorgaben: Sie sind ja gewissermaßen die Vertragsgrundlage zwischen Auftraggeber und Entwickler wie auch Bezugspunkt der Aufgabenzuweisung und Zeitvorgabe für die einzelnen Software-Entwickler.

Fazit: Der Ablauf vieler Projekte stellt sich dar als ein Doppelprozeß von technischer Entwicklung und "politischer" Verarbeitung (Interessenaushandlung). Beide Prozesse sind auf vielfältige und meist schwer durchschaubare Weise miteinander verwoben: Aus der technischen Entwicklung ergeben sich Impulse für die politische Dimension, die ihrerseits immer wieder in diese hineinwirkt. Diese Wechselwirkung der beiden Dimensionen entwickelt eine Eigendynamik, die den Projektablauf wesentlich bestimmt.

Ein Symptom des Doppelcharakters der Software-Entwicklungsprozesse, das die Auseinandersetzungen über die Systemgestaltung zweifellos erschwert, ist der Umstand, daß häufig auf der technischen Ebene argumentiert wird, selbst wo es auch oder primär um "politische" Aspekte geht.

Damit wird vermieden, daß diese ausdrücklich und offen auf den Tisch kommen. Es wäre wohl falsch, in diesen technischen Diskussionen nur Scheinargumentationen zu sehen, durch die die letztlich allein ausschlaggebenden "politischen" Aspekte nur verdeckt werden. Natürlich haben die technischen Aspekte Gewicht, können Argumentationen auf technischer Ebene die Entscheidungen mit beeinflussen, nur war in den Auseinandersetzungen meist schwer auszumachen (und vor allem nicht nachzuweisen), welche Ebene nun letztlich gerade den Ausschlag gegeben hatte. Mit dieser Doppelbödigkeit umzugehen fällt offensichtlich nicht leicht; und ohne Zweifel trägt sie zu der beträchtlichen Emotionalität bei, mit der diese Auseinandersetzungen häufig ausgetragen werden.

Bleibt noch die Frage, wie sich die Wirksamkeit der "politischen" Dimension auf die Qualität der Softwareprodukte auswirkt. Eine Beantwortung dieser Frage war im Rahmen unserer Untersuchungen bislang nicht möglich. Wir müssen uns hier auf Vermutungen beschränken, die sich auf eher unsystematische Eindrücke stützen.

Führt die "politische" Verarbeitung zu einer Verwässerung der konzeptionellen Entwürfe, zu Kompromissen, die schließlich die Qualität des Produkts beeinträchtigen, oder wird durch sie eine Anpassung an die realen Anforderungen der Einsatzsituation geleistet, also eine stärkere Durchsetzung des Aufgabenbezugs? Vermutlich geht es hier nicht um ein Entweder-Oder. Bislang spricht alles dafür, daß die Qualität des Softwareproduktes nicht zuletzt von der Qualität der "politischen" Verarbeitung abhängt.

Mit anderen Worten: Die "politische" Verarbeitung ist ein notwendiger Teil des Software-Entwicklungsprozesses - zumindest bei jenen betrieblichen, integrativen Projekten, auf die sich unsere Ausführungen primär beziehen. Bei solchen Projekten setzt die Beherrschung der software- und ablauftechnischen Komplexität die Beherrschung der politischen Komplexität voraus. Mit Sicherheit ist ein Ausblenden des Konfliktpotentials - wie in jenem Projekt, in dem ein "fertiger" Auftrag an die Software-Entwickler als Vorgabe übermittelt wurde - nicht die Lösung. Es mag zwar zu einer rascheren Abwicklung der ersten Phasen des Projektes führen, allerdings auf Kosten der späteren Aufgabenangemessenheit des Produkts und damit auch seiner Akzeptanz im Anwendungsbereich.

In den meisten Projekten waren Bemühungen zu erkennen, sich den Problemen und Anforderungen dieses Doppelprozesses von technischer und politischer Entwicklung zu stellen. Insgesamt jedoch vermittelten nur wenige Projekte den Eindruck, daß es gelungen ist, die "politische Eigendynamik" wirklich in den Griff zu bekommen. Vor allem erweisen sich gegenüber dieser Problematik die verfügbaren Instrumente als kaum wirksam - im Gegenteil: eine einseitige Orientierung an diesen "Tools" verstärkt die Gefahr einer untergründigen und damit unkontrollierten Wirkung der politischen Eigendynamik.

Abschließend eine Erfahrung, die wir in fast allen Projekten machten: Zwar bezogen sich die Gesprächspartner in ihren Berichten über den Projektablauf offen, ausführlich und sehr reflektiert auf die ihn bestimmenden Kontroversen und "politischen" Interessen, zugleich waren ihre eigenen Analysen wesentlich von dieser Dimension geprägt. "Das war eben politisch" war in vielen Gesprächen ein häufig wiederkehrendes Leitmotiv.

Diese Betrachtungsweisen fanden offenbar kaum einen zumindest keinen für uns erkennbaren - Niederschlag in den Lehren und Konsequenzen, die man aus den Erfahrungen abgeschlossener Projekte zog. Diese konzentrierten sich im wesentlichen dann doch wieder auf Fragen der Beherrschbarkeit der software- und ablauftechnischen Komplexität. Zunächst erschien uns das inkonsequent, eher enttäuschend. Im Kontext der betrieblichen Praxis sind diese Reaktionen jedoch verständlich und durchaus realitätsgerecht. "Politik" wird ja in den Unternehmen nicht als eigene Dimension gehandelt, sondern ist integrale Qualität allen Geschehens; ihre Wirksamkeit wird nicht zuletzt gerade dadurch bestimmt, daß sie sich verdeckt vollzieht. Die Forderung nach der Entwicklung von Instrumenten und Verfahren, die explizit der politischen Verarbeitung von Entwicklungsprozessen gelten, wäre entsprechend eher naiv.

Trotzdem meinen wir, daß eine ausdrückliche Auseinandersetzung mit der Frage, wie der Eigendynamik des Doppelprozesses bei Software-Entwicklungsprojekten entgegengewirkt werden kann, sowohl in der Praxis, in den Unternehmen und den Softwarehäusern, wie auch in der wissenschaftlichen Diskussion, notwendig ist. Notwendig erscheint auf allgemeiner Ebene eine Entmythologisierung der Softwareentwicklung, durch die ihr Doppelcharakter als Prozeß technischer Entwicklung und "politischer" Auseinandersetzung deutlich gemacht wird.

Notwendig erscheinen schließlich organisatorische Modelle, die eine tragfähige Grundlage für die Verarbeitung von Interessensgegensätzen und Konfliktpotential liefern und damit die Thematisierung der "politischen" Diskussion erleichtern.