Programmieren durch Probieren

Auch Code und fix oder trial and error

Vorgehen

· Vorläufiges Programm erstellen

· Anforderung, Entwurf, Testen, Wartung überlegen

· Programm entsprechend „verbessern“

Eigenschaften

· Schnell (?), Code ohne „nutzlosen“ Zusatzaufwand

· Erzeugt schlecht strukturierten Code wegen unsystematischer Verbesserungen und fehlender Entwurfsphase

Probleme

· Mangelhafte Aufgabenerfüllung wegen Fehlens der Anforderungsanalyse

· Wartung/Pflege kostspielig, da Programm nicht darauf vorbereitet

· Dokumentation nicht vorhanden

· Für Teamarbeit vollständig ungeeignet, da keine Aufgabenaufteilung vorgesehen

Wasserfallmodell („Phasenmodell“)

Vorgehen

· Jede Aktivität

· In der angegebenen Reihenfolge

· Vollständig durchführen

· D.h. streng sequentielles Vorgehen

Eigenschaften

· Am Ende jeder Aktivität steht ein fertiges Dokument – dokumentgetriebenes Modell

· Einfach, verständlich

· Benutzerbeteiligung nur in der Definitionsphase vorgesehen

Probleme

· Keine phasenübergreifende Rückkopplung vorgesehen – Fehlersuche und Korrektur problematisch

· Parallelisierungspotential möglicherweise nicht richtig ausgeschöpft – Markteinführung verzögert sich unnötig

· Zwingt zur genauen Spezifikation auch schlecht verstandener Benutzerschnittstellen und Funktionen – Entwurf, Implementierung und Testen von später nutzlosem Code

Daher: Wasserfallmodell ist eher ein pädagogisches Modell, bei dem die einzelnen Aktivitäten klar getrennt sind und daher in reihenform studiert und erlernt werden können. Insbesondere zeigt es auf, dass SW-Entwicklung wesentlich mehr ist, als nur Coden.

Viele Praktiker benutzen leider noch Code und Fix

V-Modell 97 – das „hadelsübliche“

V wie Vorgehensmodell

Jede Aktivität hat einen eigenen Prüfungsschritt

V-Modell XT (Vorgehensmodell)

· Entwicklungsstandard für IT-Systeme der öffentlichen Hand in Deutschland

· Aktivitäten, Produkte und Verantwortlichkeiten werden festgelegt, jedoch keine Reihenfolge/Phasengrenzen

o Aktivität – Tätigkeit, die in Bezug auf ihr Ergebnis und ihre Durchführung genau beschrieben werden kann

o Produkt – Ergebnis einer Aktivität

· Projekt wird aus vielen möglichen Perspektiven betrachtet

· Weiterentwicklung des V-Modells 97

· Definierte Rollen 30 Stück: Anwender, Architekt usw.

· Jede Rolle hat eine Erklärung für:

o Beschreibung

o Aufgaben

o Fähigkeitsprofil

o Verantwortlichkeiten

o Mitwirkungen

· Im „alten“ V-Modell 97 existierten 4 Submodelle, die so zugeschnitten waren, dass es hinsichtlich der dort auftretenden Rollen keine Überschneidungen gab

o Submodell Projektmanagement (PM)

o Submodell Qualitätssicherung (QS)

o Submodell Konfigurationsmanagement(KM)

o Submodell Systemerstellung (SE)

· Das aktuelle V-Modell XT gliedert diese Submodelle in sog. „Vorgehensbausteine“

V-Modell XT: Produktzustände

· Jedes definierte Produkt durchläuft 4 Zustände

o In Planung

o In Bearbeitung

o Vorgelegt

o Fertig gestellt

Prototypmodell

· Geeignet für Systeme, für die keine vollständige Spezifikation ohne explorative Entwicklung oder Experimentation erstellt werden kann

· Der Prototyp kann Arbeitsmoral und Vertrauern zwischen Anbieter und Kunden stärken

· Wichtig: PROTOTYP WEGWERFEN

______________________________________________________________________________________________________________

 

Iteratives Modell

· Auch successive versions – Erweiterung der Prototypen Idee

· Idee: Zumindest Teile der Funktionalität lassen sich klar definieren und realisieren

· Daher: Funktionalität wird Schritt für Schritt erstellt und dem Produkt hinzugefügt

· Gleiche Vorteile und einsatzgebiete wie Prototypmodell

· Versuch, mehr weiter zu verwenden als beim Prototypmodell

Zwei Ansätze

· Evolutionär: Plane und analysiere nur den teil, der als nächstes hinzugefügt wird (x-faches Wasserfallmodell)

o Risiko, dass sich der nächste Teil aufgrund struktureller Schwierigkeiten nicht integrieren lässt und deshalb Teile noch mal gemacht werden müssen

· Inkrementell: Plane und analysiere alles und iteriere dann n-mal über Entwurfs-, Implementierungs- und Testphase

o Erfordert vollständige Planung und Analyse, was ja eigentlich mit diesem Modell umgangen werden soll

→ Mischformen und Flexibilität angebracht

Synchronisiere und stabilisiere (auch „Microsoft-Modell“)

Ansatz

· Organisiere die 200 Programmierer eines Projektes in kleinen Hacker-Teams – das ergibt Freiheit für eigene Idee/Entwürfe

· Aber: Synchronisiere regelmäßig (nächtlich)

· Und Stabilisiere regelmäßig (Milesteine, 3 Monate)

Drei Phasen

· Planungsphase

· Entwicklungsphase

· Stabilisierungsphase

Planungsphase

· Wunschbild (vision statement): Manager identifizieren und prioritisieren Produkteigenschaften aufgrund umfangreicher Sammlungen von Kundenwünschen

· Spezifikation: Manager und entwickler definieren Funktionen, Architektur und Komponenten-Abhängigkeiten anhand des Wunschbildes

· Zeitplan und Teamstruktur: Aufteilung der Aufgaben auf Produktfunktionsgruppen mit je

o 1 Manager

o 3-8 Entwickler

o Genauso viele Tester (arbeiten 1:1 parallel zu Entwicklern)

· Dauer: 3-12 Monate

Entwicklungsphase

· Aufgaben

o Manager koordinieren Weiterentwicklung der Spezifikation

o Entwickler entwerfen, codieren und entfernen Fehler

o Tester arbeiten parallel zu ihren Entwickler

· Drei Teilprojekte – Drei Milesteine

o Erstes Drittel der geplanten Funktionalität, wichtigste Funktionen

o Zweites Drittel

o Letztes Drittel: unwichtigste Funktionen

· Ausbuchen, Bearbeiten, Übersetzen und Testen

· Einbuchen (bei Bedarf, i.d.R. 2x pro Woche)

· Nächtliches, vollständiges Übersetzen aller Quellen

· Automatische Regressionstests

· Sanktionen für das Verursachen von Fehlern bei der Integration. Diese Fehler müssen sofort behoben werden, da sie andere Entwickler aufhalten!

· Zum Ende jedes Subprojektes werden alle entdeckten Fehler beseitigt (Subprojekt-Stabilisierung)

Stabilisierungsphase

· Aufgaben

o Manager koordinieren Beta-Tester und sammeln Rückmeldungen

o Entwickler stabilisieren Code

o Tester isolieren Fehler

· Tests

o Interne Tests (innerhalb von Microsoft)

o Externe Tests (Beta-Tester)

· Vorbereitung der Auslieferung

o Fertiges Produkt auf den „Master“-Rohling brennen

o Dokumentation für den Druck aufbreiten

· Dauer: 3-8 Monate

Zeitplan

· Planung: 3-12 Monate

· Jedes der 3 Teilprojekte: 2-4 Monate, wobei

o 6-10 Wochen Codieren, Optimieren, Testen, Fehlersuche und Stabilisieren der Funktionalität

o 2-5 Wochen Integration, Test und Fehlersuche

o 2-5 Wochen Pufferzeit

· Stabilisierung: 3-8 Monate

12-32 Monate Insgesamt

 

 

Vorteile

· Effektiv durch kurze Produktzyklen

· Priorisierung nach Funktionen

· Natürliche Modularisierung nach Funktionen

· Fortschritt auch ohne vollständige Spezifikation möglich

· Viele Entwickler arbeiten in kleinen Teams und damit genau so effektiv wie wenige

· Rückmeldungen könne frühzeitig einfließen

Nachteile

· Ungeeignet für manche Art von Software – Architekturprobleme, mangelhafte Fehlertoleranz, Echtzeitfähigkeit

· Mündliche Arbeitsweise: ad-hoc-Prozesse in jedem Team, kein Lernen über Teamgrenzen

· Alle 18 Monate sind 50% des Codes überarbeitet worden (Code-Instabilität)

Agile Prozesse