Synchronize-and-Stabilize Software Development Model von Microsoft

Auch das Synchronize-and-Stabilize Modell, wie es u.a. bei Microsoft zum Einsatz kommt, basiert auf einer inkrementellen Vorgehensweise. Ausgehend von einer Vorstellung über das zu entwickelnde Softwaresystem / Produkt werden die Anforderungs-, Entwurfs- und Testphasen solange wiederholt, bis bestimmte Meilensteine erreicht werden. Folgende Meilensteine gilt es zu beachten:

  • MM1 ( = Major Milestone 1)
  • Alpha Release
  • Beta Release
  • CTP (= Community Technical Product)

Ausgehend von einer groben Beschreibung der vom zu entwicklenden Softwaresystem zu leistenden Funktionen wird vom Projektmanager ein formale Spezifikation erstellt, die jedoch immernoch sehr grob ist und über den gesamten Entwicklungsprozess hinweg verfeinert und erweitert wird. Ausgehend von der formalen Spezifikation fängt man mit der Entwicklung des Softwaresystems an, wobei die Phasen der Anforderungsdefinition und –analyse, des Entwurfs und der Implementierung und Tests durchlaufen werden. Über das gesamte Entwicklungsprojekt hinweg sind, wie schon erwähnt, mehrere Meilensteine zu erreichen. Normalerweise gibt es drei Meilensteine. Jeder Meilenstein repräsentiert den Fortschritt nach einem mehrwöchigen Entwicklungs-Subzykluses. Hierbei werden

  • Entwürfe erstellt
  • Quellcode programmiert
  • Die Anwendung gestestet
  • Tägliche Builds erzeugt, von Fehlern behoben, integriert und stabilisiert

Jeder Subzyklus endet mit einem  Meilenstein, wobei entweder ein Alpha oder Beta Release ausgegeben wird. Zwischen den Subzyklen wird schon vor Beginn des Entwicklungsprozesses eine Pufferzeit eingelegt, damit sich das Entwicklerteam an auftretende Wünsche der Endabnehmer anpassen kann – genau dazu sind die Releases ja da! Der abschließende Meilenstein führt dazu, dass keine weiteren Bemerkungen von Endabnehmern empfangen werden und der Code als vollständig angesehen wird. Es wird nun ein abschließender Test durchgeführt und die letzten Fehler werden behoben. Erst dann, wenn das Projekt erfolgreich abgeschloßen wurde, ist die formale Spezifikation, die am Anfang sehr grob war, als vollständig anzusehen. Hier verdeutlicht sich nochmals der Unterschied zum traditionellen Wasserfallmodell, da dieses nach der Planungsphase und Anforderungsdefinition und –analyse von einer vollständigen Spezifikation ausgeht.

Abschließend noch eine Bemerkung zum Unterschied zwischen Alpha- und Beta-Releases. Alpha-Releases finden oft ausschließlich Unternehmensintern statt. Sie richten sich an wenige Test-Experten. Diese führen hauptsächlich White-Box-Tests durch, evtl. aber auch Grey- und Black-Box-Tests. Getests wird das Programm meistens noch in der Entwicklungsumgebung.

Beta-Releases richten sich an ein etwas breiteres Publikum, u.a. auch aus potentiellen Endabnehmern ausserhalb des Unternehmens bestehend. Durchgeführt werden meist Black-Box-Tests in der Realen Ablaufumgebung. Der Beta-Release und die vorgehende Beta-Phase sind natürlich näher an dem eigentlichen ”Shipping Date” als die Alpha-Releases und die zugehörige Alpha-Phase.