Dieser Abschnitt stellt die erreichten Ergebnisse dem ursprünglich definierten Soll gegenüber. Bewertet werden einerseits die fünf in der Projektplanung definierten Ziele, andererseits der funktionale Lieferumfang sowie der tatsächliche Aufwand. Ziel ist eine ehrliche, nachvollziehbare Erfolgsmessung – ohne Schönfärberei.

Zielerreichung (Soll/Ist)

Die folgende Tabelle fasst den Erreichungsgrad der fünf Projektziele zusammen. Ziel 1 wurde konkret gemessen, die übrigen Ziele werden qualitativ anhand der umgesetzten Funktionalität und der Stakeholder-Rückmeldungen bewertet.

Ziel	Soll	Ist	Status
Ziel 1: Bereitstellungszeit pro Instanz	von ca. 20 Min auf unter 5 Min	gemessen: Standard-Umgebungen (Prod/Int/Dev) unter 2 Min, Custom ca. 4 Min	✅ erfüllt
Ziel 2: Konsistente, nachvollziehbare Konfiguration	keine manuellen Abweichungen mehr	Werte je Umgebung zentral aus /.admin/Standards_AbyssInc.md, Configuration Drift eliminiert	✅ erfüllt
Ziel 3: Reduktion Support-/Troubleshooting-Aufwand	mind. −20 %	qualitativ plausibel durch Standardisierung, Dry-Run und Betriebsdoku/Runbooks; nicht über Produktivlaufzeit messbar	🟡 teilweise belegbar
Ziel 4: Verbesserung Wartbarkeit & Nachvollziehbarkeit	nachvollziehbare Infrastruktur	versionierte Konfiguration, funktional gegliederter Monolith, AWS-Tags (Name, Environment)	✅ erfüllt
Ziel 5: Standardisierte Deployments durch weniger erfahrene Mitarbeitende	kein ID-Wissen nötig	Human-Readable Umgebungsauswahl, Defaults, Auswahlmenüs statt Freitext	✅ erfüllt

Ziel 1 – Bereitstellungszeit (gemessen)

Das einzige rein quantitativ messbare Ziel wurde im Rahmen mehrerer manueller Testläufe gegen die AWS-API überprüft. Gemessen wurde die Zeit ab dem Start von main.sh bis zur laufenden Instanz inklusive ausgegebener Public-IP – die reine Bedenkzeit des Nutzers bei der Eingabe ist dabei nicht eingerechnet, da sie nicht dem Werkzeug zuzuschreiben ist. Für die Standard-Umgebungen (Prod/Int/Dev) lag die Bereitstellung dabei konstant bei unter 2 Minuten, da hier alle Werte über die Standard-Defaults vorbelegt sind und nur bestätigt werden müssen. Ein Custom-Deployment, bei dem sämtliche AWS-IDs manuell einzugeben sind, dauert mit rund 4 Minuten erwartungsgemäss länger – liegt aber selbst dann noch klar unter der Zielmarke von fünf Minuten. Der Grossteil der Zeit entfällt auf das Warten auf die AWS-API (Provisionierung und Vergabe der Public-IP), nicht auf das Skript selbst.

Ziel 2 bis 5 (qualitativ)

Die Ziele 2, 4 und 5 sind durch die im Sprint 2 umgesetzten Funktionen direkt belegbar: Die zentral in den Standards hinterlegten Umgebungswerte verhindern abweichende Konfigurationen (Ziel 2), die versionierte und funktional gegliederte Codebasis verbessert die Wartbarkeit (Ziel 4), und die Human-Readable Auswahl macht das Werkzeug auch für den 2nd Level Support ohne ID-Kenntnis bedienbar (Ziel 5).

Ziel 3 (Reduktion des Support-Aufwands um mindestens 20 %) lässt sich im Rahmen einer Semesterarbeit nicht seriös in Prozent messen, da hierfür ein Vorher-/Nachher-Vergleich über einen längeren Produktivbetrieb nötig wäre. Die Voraussetzungen für eine Reduktion sind jedoch geschaffen: standardisierte Eingaben, der Dry-Run-Modus zur Vorab-Validierung sowie die Betriebsdokumentation mit Runbooks senken die Fehlerquote und die Einarbeitungszeit nachweisbar. Dieses Ziel wird daher bewusst als teilweise belegbar statt als vollständig erfüllt ausgewiesen.

Funktionale Ergebnisse (Release-Sicht)

Über die drei Sprints wurde der geplante Funktionsumfang vollständig erreicht. Jeder Sprint mündete in das vorgesehene Release:

Release	Sprint	Lieferumfang	User Stories
MVP	1	Lauffähiges Deployment: interaktive Eingabe, Userdata-Template, aws ec2 run-instances	US.0–US.3
MMP	2	Robustheit & Usability: Fehlerbehandlung, Dry-Run, Defaults, Auswahlmenüs, Tagging, Output-Zusammenfassung	US.5–US.8, US.10
MLP	3	Polishing & Übergabe: Spinner/Statusmeldungen, vollständige Betriebsdokumentation	US.9, US.11

Die ursprünglich für Sprint 2 geplante US.4 (Abfrage von SSH-Keys & Security Groups) wurde bewusst als Won’t Do verworfen und im Review von Sprint 2 begründet dokumentiert. Damit sind alle werthaltigen User Stories umgesetzt; das Produkt entspricht dem geplanten MLP-Stand.

Aufwand (Soll/Ist)

Für die Arbeit war ein Budget von rund 60 Stunden vorgesehen. Der laufend erfasste Ist-Aufwand liegt darunter:

Phase	Aufwand
Sprint 0 (Setup & Planung)	~8.1 h
Sprint 1 (MVP)	~9.5 h
Sprint 2 (MMP)	~11.5 h
Sprint 3 (MLP)	~6.7 h
Total (ohne Finalisierung)	~35.8 h

Der Verbrauch liegt klar innerhalb des Budgets. Auffällig ist der überdurchschnittliche Anteil von Sprint 0: Wie in der Zeiterfassung dokumentiert, entfiel hier viel Aufwand auf das erstmalige Einarbeiten in das agile Vorgehen (SCRUM), der sich nicht auf einen Kunden verrechnen liesse. Über die Sprints hinweg sank der Projektmanagement-Overhead spürbar, während die Implementierung effizienter wurde – ein direkter Effekt des Lernfortschritts.

Grenzen der Messung

Die hier dokumentierten Ergebnisse stammen aus einem Ein-Personen-Projekt mit manuellen Testläufen gegen einen AWS-Free-Tier-Account. Die Zeitmessung (Ziel 1) ist damit indikativ, nicht unter Laborbedingungen reproduziert. Für eine produktive Bewertung der Effizienzgewinne (insbesondere Ziel 3) wäre eine Erhebung über mehrere Wochen Produktivbetrieb mit mehreren Anwendern erforderlich. Diese Einschränkung wird bewusst offengelegt, um die Aussagekraft der Ergebnisse korrekt einzuordnen.