next up previous contents index
Nächste Seite: 8.3 Gestaltung von Emergenz Aufwärts: 8 Emergenz in der Vorherige Seite: 8.1 Einleitung   Inhalt   Index

8.2 Bewältigung von Emergenz in der Softwareentwicklung

Unter Bewältigung von Emergenz versteht diese Arbeit den Umgang mit einer Welt geprägt durch Nicht-Linearität und Nicht-Determinismus. Bevor mit einer Bewältigung begonnen werden kann, muss allerdings zunächst die Einsicht in die Notwendigkeit existieren. Dies bedeutet eine Abkehr von der These, wonach Softwareentwicklung eine reine Ingenieurdisziplin ist - eine Abkehr vom mechanischen Weltbild. Diese Abkehr vom mechanischen Weltbild hin zum neuen Weltbild mündet in der Kritik an der Baumetapher der klassischen Softwareentwicklung:

Mit Sicherheit ließen sich noch weitere Kritikpunkte finden, aber schon diese wenigen Punkte sind ausreichend um zu erkennen, dass eine Baumetapher für die Softwareentwicklung nicht ausreichend ist. Zentraler Kritikpunkt an der Baumetapher ist, dass Software im Vergleich zu einem Ingenieurprodukt wie einer Brücke oder einem Haus jederzeit änderbar ist. Ein Haus kann nur unter hohem Kostenaufwand geändert werden, wenn es sich bereits im Rohbau oder sogar im Innenausbau befindet. Daraus leitet sich die Forderung ab, dass vor Baubeginn alle zukünftigen Anforderungen ermittelt und berücksichtigt sein müssen. Software hingegen kann jederzeit geändert werden. Der dafür notwendige Kostenaufwand kann durch die vorgestellten Techniken wie automatisierte Tests, Refaktorisierung und häufige Integration wesentlich reduziert werden. Es gibt somit keinen Grund, warum man das Mittel der Softwareänderung nicht einsetzen sollte. Tatsächlich ist es das Mittel, um in einer dynamischen Welt erfolgreich Software zu entwickeln. Denn Anforderungen ändern sich. Es ist unmöglich alle Anforderungen in einem komplexen Projekt am Projektanfang in einer Analysephase vollständig zu bestimmen. Bereits kleinste Änderungen der Anforderungen können große Auswirkungen auf die zu entwickelnde Software haben.

Der typische Einsatz von Software erfordert eine häufige Überarbeitung und Weiterentwicklung. Im Gegensatz zu dem Produkt eines Ingenieurprozesses wird Software oft erweitert oder Kernfunktionen müssen an neue Rahmenbedingungen angepasst werden. All dies erfordert eine Änderung der Software nach deren ursprünglicher Fertigstellung.

Es ist bekannt, dass Anforderungen nur schwer ermittelt werden können. Software ist letztendlich der abstrakte Teil einer komplexen Problemlösung. Dem Nutzer fällt es dementsprechend schwer, die Anforderungen an diese abstrakte Komponente genau zu spezifizieren. Dem wurde in der Vergangenheit durch die Entwicklung von Prototypen und neuen Analysetechniken entgegengewirkt. Die beste Möglichkeit die während der Analyse gewonnenen Anforderungen zu überprüfen, ist der Einsatz des Produktes in der späteren Produktionsumgebung. Dies bedeutet eine häufige Auslieferung von Softwareversionen, die der Nutzer prüft, damit er seine Anforderungen überarbeiten und präzisieren kann. Es handelt sich hierbei um eine iterativ inkrementelle Entwicklung mit stark verkürzten Zyklen von wenigen Monaten. Dabei ergeben sich mehrere Vorteile. So bringt jede neue Version lediglich eine geringe Anzahl von Neuerungen. Damit wird der Nutzer zum stetigen Lernen aufgefordert, aber es findet keine Überforderung der Lernfähigkeit statt. Eine Überforderung kann dann eintreten, wenn zu einem Zeitpunkt z. B. eine komplette Software eingeführt werden soll und wesentliche Teile der Arbeitsprozesse davon betroffen sind und neu erlernt werden müssen. Weiterhin ist es zum Vorteil des Kunden, wenn er während des Projektes seine Anforderungen überarbeiten kann. Dadurch erhält er eine Software, die seinen tatsächlichen aktuellen Anforderungen, und nicht den Anforderungen zu Projektbeginn, entspricht. Der Kunde ist somit an der Gestaltung der zu entwickelnden Software direkt beteiligt.

Im Gegensatz zum Produkt eines Ingenieurprozesses, wie ein Automobil oder ein Haus, ist Software meist Bestandteil einer umfassenden Problemlösung. Diese Problemlösung umfasst neben dem Softwareprodukt weiterhin Hardware, Beratung, Schulung und sogar eine Überarbeitung der Geschäftsprozesse des Kunden (Business Reengineering).

Durch den Wandel der Anforderungen und eingesetzten Technologien wird eine langfristige Projektplanung erschwert. Sinnvoller ist deshalb eine zuverlässige Planung in kurzen Zeiträumen.

Verzichtet man in der Softwareentwicklung auf einen starren Ablauf der einzelnen Phasen, kann man die Entwicklung durch Parallelisierung der Phasen wesentlich beschleunigen. Während bereits Funktionen als Code implementiert werden, findet die Analyse später benötigter Funktionalität statt. Dies führt zu einer gleichmäßigeren Auslastung der einzelnen Mitglieder des Projektteams. Weiterhin können wichtige Programmfunktionen bereits sehr frühzeitig durch den Kunden eingesetzt werden.

Man erkennt, dass die Softwareentwicklung, verstanden als reine Ingenieurdisziplin, nicht alle Fragen beantworten kann. Tatsächlich versucht die klassische Softwareentwicklung Probleme wie sich ändernde Anforderungen zum Beispiel mit dem Change Management zu behandeln. Es muss dabei allerdings gefragt werden, ob mit solchen Verfahren letztendlich nicht nur die Symptome bekämpft werden, ohne die eigentliche Ursache zu erkennen. Denn die Ursache ist eine Welt geprägt von Nicht-Linearität und Nicht-Determinismus. Einige Gründe für Nicht-Linearität in der Softwareentwicklung sind:

Software wird von Menschen entwickelt. Menschen handeln nicht vollständig rational, sondern sind geprägt durch eine Vielzahl von Konflikten. Das Verhalten eines Menschen ist situationsabhängig. Der Mensch denkt assoziativ und nicht rein logisch wie ein Digitalrechner. Dies führt zu einer gewissen Sprunghaftigkeit, die einzig durch den zentralen Charakter des Individuums geglättet wird. Tatsächlich ist eine vollständige Unterdrückung der Sprunghaftigkeit nicht erwünscht, da die Sprunghaftigkeit im Verhalten die Voraussetzung für Kreativität ist. Weiterhin steht der Mitarbeiter in ständiger Interaktion mit den Mitarbeitern, dem Kunden und dem Management. Diese Gruppen haben oft widersprechende Anforderungen. Die Vernetzung der Individuen führt zu einer nicht-linearen Gruppendynamik.

Jeder Codebereich, wie eine Klasse oder Methode, steht mit einer Vielzahl anderer Codebereiche in Verbindung. Eine gute Softwarearchitektur kann dieses Problem einschränken, dennoch kann sie die entstehenden Rückkoppelungseffekte durch die Vernetzung des Codes nicht vollständig verhindern, da der Code zur Erfüllung der Softwarefunktionalität zu einem Mindestmaß vernetzt sein muss. Deshalb können bereits kleinste Änderungen Auswirkungen auf das Gesamtverhalten des Systems haben.

Software wird bei der Auslieferung in eine komplexe Umgebung über eine Vielzahl von Schnittstellen integriert. Durch diese enge Koppelung der Software an die Umwelt wird die Software ein Bestandteil eines größeren Systems und verliert dadurch ihre Autonomie. Die Software ist danach abhängig von einer Vielzahl von Elementen, die nicht kontrolliert werden können. Sie ist Bestandteil eines Netzwerkes.

Weiterhin ist die Softwareentwicklung bestimmt von Nicht-Determinismus. Dies äußert sich z. B. in folgenden Punkten:

Die Gestaltungsmöglichkeiten von Software sind vielfältig. Dies belegt allein die unüberschaubare Anzahl von Programmiersprachen. Weiterhin existiert eine Vielzahl von Entwicklungsparadigmen52. Aus dem verwendeten Paradigma leitet sich die Architektur ab. Diese Architektur kann im Konkreten ebenfalls vielfältig erfolgen. Wird z. B. eine Software in Hinblick auf Erweiterungsfähigkeit entwickelt, dann kann dies über mehrere Wege erfolgen. Denkbar ist beispielsweise eine Plugin-Architektur mit öffentlichen Schnittstellen, die das dynamische Nachladen von Funktionalität erlaubt. Eine andere Lösung ist die Integration einer Skriptsprache mit einer entsprechenden Laufzeitumgebung, damit Erweiterung direkt die internen Daten manipulieren können.

In der Softwareentwicklung sind zukünftige Anforderungen und Umweltbedingungen nicht absehbar. So können sich die Anforderung des Kunden z. B. durch Marktverschiebungen drastisch ändern. Einen ähnlich starken Einfluss haben Änderungen der verwendeten Technologie. In beiden Fällen ist der Einfluss und die Steuerungsmöglichkeit durch das Projektteam relativ gering. Durch diese Unfähigkeit die Zukunft vorherzusagen oder sogar vorherzubestimmen, ist jede Planung lediglich eine Hypothese über die Zukunft. Pläne können nicht realisiert werden, sondern es kann lediglich überprüft werden, ob die Planung der tatsächlichen Entwicklung entsprach. Es muss dabei daran erinnert werden, dass Schätzungen immer nur mit einer bestimmten Wahrscheinlichkeit richtig sind. Umso kürzer und zeitlich nah der von einer Schätzung abgedeckte Zeitraum ist, umso höher ist die Wahrscheinlichkeit einer richtigen Schätzung.

Der Vergleich mit anderen Projekten ist oft wenig hilfreich. Schon kleine Änderungen der Bedingungen, z. B. in der Zusammensetzung des Projektteams, können durch die Vernetzung und Rückkoppelung riesige Auswirkungen auf den Projektverlauf haben, was einen Vergleich unmöglich macht.

Letztendlich sind Organisationen immer einzigartig. Formal gesehen können Organisationen die selbe Struktur aufweisen, dennoch besteht eine Organisation nicht nur aus Struktur, sondern auch aus einzigartigen Individuen. Dadurch bildet jede Organisation eine eigene Kultur, die es zu berücksichtigen gilt.

Das primäre Ziel der Softwareentwicklung ist es, unter den oben genannten Bedingungen Software mit entsprechender Qualität, im gegebenen Zeitrahmen und unter Einhaltung des Projektbudgets zu entwickeln. Das sekundäre Ziel lautet, zukünftige Entwicklungen vorzubereiten (vgl. Coc03, S. 51ff). Dies kann z. B. durch Wiederverwendung bereits entwickelter Komponenten, wartungsfreundliche Gestaltung der Software usw. geschehen. Trotzdem ist eine gut wartbare Software nutzlos, wenn sie vom Kunden als nicht ausreichend betrachtet wird und somit das primäre Ziel eine die Anforderungen erfüllenden Software verfehlt wurde.

Die meisten heute bekannten Mittel zur Erreichung der beiden Ziele in einer emergenten Welt wurden bereits im letzten Kapitel und im Kapitel 5 auf Seite [*] aufgezeigt. Deshalb seien sie lediglich auszugsweise an dieser Stelle kurz genannt:

Es existieren Berichte von Unternehmen wie Microsoft (vgl. CS96), die entsprechende Verfahren in der Softwareentwicklung bereits seit Jahren erfolgreich einsetzen. Ein weiteres praktisches Beispiel für erfolgreiche Bewältigung von Emergenz ist die ,,OpenSource`` Bewegung, die Software vollständig selbstorganisiert entwickelt.

Im Hinblick auf die Fragestellung dieser Arbeit kann davon ausgegangen werden, dass bereits heute eine bewusste Bewältigung von Emergenz stattfindet. Ob dies allerdings mit der Kenntnis des neuen Weltbildes stattfindet, erscheint fraglich. Eine Verbesserung und Erweiterung der verwendeten Mittel in Zukunft ist sehr wahrscheinlich. Gerade im Wirtschaftsbereich wurden bereits einige Mittel langfristig erprobt und kommen erst jetzt in der Softwareentwicklung zum Einsatz. Interessant ist z. B. die Fragestellung, wie das Projektwissen möglichst ohne aufwendige Dokumentationserstellung gesichert werden kann.


next up previous contents index
Nächste Seite: 8.3 Gestaltung von Emergenz Aufwärts: 8 Emergenz in der Vorherige Seite: 8.1 Einleitung   Inhalt   Index
Sebastian Stein 2004-08-30