Das QS-Modell
Das QS-Modell ist das erste vollständig entwickelte Modell, das für die SESAM-Simulation eingesetzt wurde. Das Modell ist auf die Entwicklung von Software im Rahmen eines kleinen bis mittleren Auftragsprojekts ausgerichtet, wobei es sich dabei besonders auf Qualitätssicherungsmaßnahmen konzentriert. Daher wird dieses Modell auch als Qualitätssicherungs-Modell (QS-Modell) bezeichnet.
Das QS-Modell erfordert von den Spielern (Studenten) ein richtiges Vorgehen bei der Besetzung von Stellen sowie der Fortschritts- und Qualitätskontrolle. Es müssen die Analyse, die Spezifikation, der Grob- und Feinentwurf, der Code und das Handbuch erstellt, sowie die Integration und die Auslieferung des Systems durchgeführt werden. Zusätzlich sollten alle Dokumente einem Review unterzogen, als auch Modul-, Integrations-, System- und Abnahmentests durchgeführt werden. Der Spieler ist außerdem dafür verantwortlich, Mitarbeiter anzustellen, ihnen Aufgaben zuzuweisen und zu entlassen.
| All dies ist unter modellabhängigen Zeit- und Budgetrestriktionen durchzuführen! |
Wasserfallmodell
Als Prozessmodell wurde das Wasserfallmodell gewählt, wobei dieses um zusätzliche konstruktive und analytische Maßnahmen erweitert wurde. Das Modell überlässt dem Spieler die Entscheidung, in welcher Reihenfolge er die verschiedenen Tätigkeit durchführt. Die möglichen Abläufe innerhalb des QS-Modells, werden in der folgenden Abbildung dargestellt:
Die gestrichelt gezeichneten Pfeile zwischen den Aktivitäten weisen darauf hin, dass der Spieler nicht streng nach dem Wasserfallmodell vorgehen muss. Es gibt zwar eine vorgegebene Sequenz zwischen den Phasen. Der Spieler muss diese aber nicht einhalten.
Code-and-Fix Ansatz
Er wird allerdings zumindest dazu gezwungen ein Analysedokument zu erstellen und die Implementierung durchzuführen. Alle anderen Phasen zwischen Analyse und Implementierung darf können übersprungen werden. Somit kann der Spieler nicht davon abgehalten werden, den Code-and-Fix Ansatz auszuprobieren.
Weiters sind Rücksprünge zu früheren Phasen möglich, solange das Dokument, zu dem gesprungen werden soll, noch Fehler enthält.
| Fehlerhafte Dokumente können beliebig oft geprüft und korrigiert werden! |
Wichtig ist jedoch, dass die Korrektur eines Reviews erfolgreich abgeschlossen werden muss, bevor eine neue Prüfung desselben Dokuments durchgeführt werden kann. Nach der Korrektur können beliebige Aktivitäten ausgeführt werden.
