|
Die meisten Bücher und heutigen SW eingineering models sind auf dem "Wasserfallmodel" für die Lieferung aufgebaut. Das kann verschiedene Formen annehmen, aber charakteristisch dafür ist:
. das die Planung des ganzen Projekts auf einen Liefertermin ausgelegt ist. Wenn die Lieferung in einzelne Phasen aufgeteilt ist, dann sind sie sehr umfangreich. Es gibt kein Konzept um unzufrieden abgeschlossene Phasen noch einmal aufzuarbeiten. (Macht es so gut es geht fertig, und aus)
. alle Analysen und das ganze Design werden bis ins Detail vorbereitet, bevor mit der Programmierung und dem Testen angefangen wird
Die Methode der evolutinären Lieferung basiert auf den folgenden einfachen Prinzipien:
. Liefere etwas an einen wirklichen End-user
.
. richte das Design nach den Erfahrungen aus, die du beobachtet hast
Das einfachste SW-Model von evo Lieferung, ist ein Personal Computer Benutzer, der sich seine eigene Applikation zusammenstellt. Der Programmierer wird zu einem Anwender, dem Zielsetzer, Analytiker, Designer und Tester. Es ist eine ständige Verbesserung von der ersten Phase an, während das System entsteht. Das System das entsteht entwickelt sich ständig weiter. Der Benutzer kann das Design ändern, Programmdetails was den Code betrifft ändern und auch die Ziele. Evolutionäre Lieferung besteht aus einer Sammlung von vielen Konzepten. Die grundlegendsten lauten wie folgt:
. Multi-objectives
. frühe, ständige Verbesserung
. komplette Analysen, Design, Entwicklung und Test bei jeder Phase
. User orientiert
. System orientiert, nicht hauptsächlich auf Algorithmen konzentrieren
. open-ended basic systems architecture
6.1 Planen für multiple objectives
Die übliche Sw-Planung ist überwiegend "Funktions" orientiert. Die Planung geschieht auf Grund von funktionellen Ansprüchen (Was die SW können wird) statt sich vielmehr um das Wie gut und zu welchem Preis wird es das können zu kümmern. Heutiges SW-engineering beschäftigt sich viel zu wenig mit der Kontrolle der kritischen Qualitäts- und Resource Eigenschaften eines Systems, und deswegen verliert es die Kontrolle über diese Eigenschaften. Ein einfaches Beispiel ist das Fehlen von Wissen unter Software engineers, wie man kritische Eigenschaften wie "Benutzerfreundlichkeit" oder "Wartbarkeit" definiert. Diese Dinge sind aber so wichtig für den Erfolg eines heutigen SW-Projects, das die Ignoranz davon einem Projekt großen Schaden anrichten kann.
Evolutionäre Lieferung ist auf der Weiterentwicklung entlang von klar und meßbaren Objectives aufgebaut. Das Set von Objectives muß alle funktionellen, qualitativen und resource objectives beinhalten, die für das langzeitige und kurzzeitige Überleben des Systems unter Entwicklung notwendig sind. Projekte die nicht so aufgebaut sind, sind auch nicht nach den Anforderungen des Anwenders aufgebaut.
6.2 Frühe und ständige Verbesserung
In den meisten SW-engineering Projekten, ist der Zeitplan so festgelegt, das frühestens nach einem Jahr ein erstes praktisches und brauchbares Ergebnis vorhanden ist. Es gibt zwar einige Gründe für das Fehlen einer frühen Konfrontation mit dem echten Anwender, aber die Ausreden davor sind unzureichend. Das Management eines solchen Projekts würde natürlich gerne die ersten Ergebnisse so früh wie möglich haben. Aber das selbe Management akzeptiert auch die allgemeine Einstellung, das es einem langen Kreislauf bedarf, bevor etwas nützliches geliefert werden kann.
Das Prinzip der evolutionären Lieferung basiert aber darauf, das das Entstehen des Systems in viele kleine Phasen zerlegt wird, deren Ergebnis von einem Anwender getestet wird, und dessen Urteil in die Weiterentwicklung mit einbezogen wird. Die Auswahl der Reihenfolge der Phasen kann so getroffen werden. "Welche Phase benötigt den wenigsten Aufwand, bewirkt aber trotzdem etwas in Richtung unserer Ziele."
6.3 Komplette Analysen, Design, Entwicklung und Test nach jeder Phase
Eine der großen Zeitverschwendungen in SW-Projekten sind detaillierte Bedürfnisanalysen, gefolgt von detailliertem Design. Wie können solche Aufgaben nur für sehr kleine Projekte bestimmen. Es sind so viele Unbekannte, zu viele dynamische Veränderungen, und ein zu komplexes Set von Weiterentwicklungen in den Systemen die wir entwickeln. Wir müssen etwas bescheidener sein.
Wir müssen meßbare Objekte festlegen, soweit wird eine begründete Meinung über die Zukunft haben. Wir müssen bereit sein, die Objekte zu verändern, sobald wir aus den Erfahrungen durch die Lieferung der einzelnen Phasen dazu gedrängt werden. Wir müssen meßbare Objectives für jede kleine Lieferungsphase definieren. Ist einfach nicht möglich ein Set von multiple quality, ressource und functional objectives zu definieren, und sicher zu sein, das alle wie geplant erreicht werden. Man muß darauf vorbereitet sein, Kompromisse einzugehen.. Wir müssen die technische Lösung designen, entwickeln, testen, liefern und Feedback bekommen. Dieses Feedback muß dafür verwendet werden, um das vorhandene Design, falls notwendig, zu verändern, und um sowohl Kurz- als auch Langzeitziele zu ändern. Es ist sinnlos so viel Geld auszugeben, oder vielmehr zu vergeuden, um über Bedürfnisse und technischen Eigenschaften zu spekulieren, die viel leichter bestimmt werden können, wenn es während der Implementierung eines funktionierenden Systems geschieht.
Evolutionäre Lieferung soll uns frühe Warnsignale liefern. Die sind zwar unangenehm, verhindern aber, das Unzulänglichkeiten in unserem Produkt nicht zu groß werden
6.4 User-Orientiertheit
SW Projekte werden nicht so sehr wegen der erfolgreichen Einstellung auf den Markt oder den Benutzer für gut befunden. Die Orientierung liegt viel mehr Richtung der Maschine, den Algorithmen, oder den Deadlines - aber viel zu selten Richtung User. Viele SW-Entwickler sehen ihr Produkt nicht einmal im Einsatz mit richtigen Anwendern, genausowenig wie Anwender die Gesichter von Designern oder Programmierern sehen. Selbst wenn der Entwickler es gewollt hätte, ein Produkt zu entwickeln das jeden Benutzer glücklich macht, ist es meistens schon zu spät oder zu unpraktisch es zu tun, nachdem zuviel Zeit vergangen ist, um es herauszufinden.
Mit evolutionärer Lieferung hat sich die Situation verändert. Der Entwickler ist mit dem anhören der Benutzerreaktionen beauftragt, sehr früh und oft. Der Benutzer kann also eine wichtige Rolle im Entwicklungsprozeß übernehmen. Wertvolle Benutzerideen können die Planern auf eine Reihe von neuen Ideen bringen, die ursprünglich nicht geplant waren. Wenn also bessere Ideen vorhanden sind, müssen wir sie so früh wie möglich einbauen. Jeder Systementwickler sollte begreifen, das er Feedback braucht
6.5 Systemorientiert, nicht hauptsächlich auf Algorithmen konzentriert
Viele SW-engineering Methoden haben eine gemeinsame Schwäche. Sie orientieren sich rein auf aktuelle Programmiersprachen. Sie kümmern sich herzlich wenig um den Aufbau der Daten, und noch viel weniger um offensichtliche Anliegen wie Dokumentation, Training, Marketing oder Motivation.
Evolutionäre Lieferung ist eine Methode die nicht nur auf SW limitiert ist. Sie ist für jeden kreativen Prozeß geeignet. Man darf nicht vergessen, dem ganzen Aufbau der Systemarchitektur zu betrachten, in dem die Software nur ein Teil ist.
6.6 Open-ended basic systems architecture
Unter den prinzipiellen Attributes eines jeden Systems sind die, die das Überleben und erreichen der Ziele unter Konditionen erlauben, die sich mit der Zeit ändern. Ein guter SW-engineer sollte fortwährend und detailliert die vorhandenen Design Technologien studieren, die zu Systemen führen die anpassungsfähiger sind als andere. Es gibt eine Reihe von meßbaren, technischen Eigenschaften, wie zum Beispiel Wartbarkeit, Transportierbarkeit und Erweiterbarkeit.
Was die evolutinäre Lieferungsmethode betrifft, sind offene Architekturen absolut notwendig. Eine offene Architektur muß es erlauben, auf Änderungen reagieren zu können..
6.7 Die Gemeinsamkeiten mit Auto fahren und Schach
auf plötzliche Veränderungen eingehen - Wenn du ein Auto fährst, mußt du vorausdenken und planen. Du kannst aber nie absolut sicher sein, das du den gewählten Weg auch fahren kannst, weil sich etwas Unvorhergesehenes ergibt.
Trip von London nach Rom - Vergeudetet Zeit - minimum an Planung - Route festlegen - Straßenkarte einstecken und Extrazeit einplanen für event. Zwischenfälle.
Schachspielen - hat das Ziel zu Gewinnen - bestimmte Strategie und Taktiken - aber bei jedem Zug des Gegners mußt du sie neu überdenken
|
