----------------------------
- Scrum beschreiben -
----------------------------
Der Name Scrum kommt aus dem Rugby, dort steht es für eine selbstorganisierende, adaptive Strategie. Die Wurzeln des Prozessmodells liegen in der empirischen Prozesssteuerung (die im Gegensatz zur definierten Prozesssteuerung steht). Scrum wird bei einer Teamgröße von 7+/- 2 verwendet.
Bei Scrum wird die Software in "Sprints" (Dauer: ca. 30 Tage) inkrementell erstellt. Dies geschieht lt. den Vorgaben der Funktionalität in dem Product Backlog, dieses ist jedoch äußerst dynamisch angelegt. Ein wichtiger Teil der Entwicklungsphilosophie ist das "Daily Scrum Meeting", in dem über Fortschritte/Hindernisse gesprochen wird.

Wichtige Elemente: 
	- Sprint
		Ziel eines Sprints - potentiell auslieferbares Software System. Sprint Goal so schnell als möglich .
		keine Vorgaben bzgl. Dokumenten/Methoden
		Abbruch möglich
		gelieferte Funktionalität am wichtigsten
	- Daily Scrum
		täglich selbe Zeit/Ort (ca. 15 Minuten)
		Scrum Master stellt 3 Fragen an jedes Teammitglied
			- Was hast du seit dem letztem Meeting getan bzw. erreicht?
			- Was wirst du bist zum nächsten Meeting tun?
			- Was hindert dich daran deine Arbeit zu tun bzw. deine Ziele zu erreichen?
	- Product Backlog
		von allen einsehbar
		äußerst dynamisch
		wichtig: nur Production Owner darf ändern
	- Inkrement
		System entsteht in Inkrementen
		Spätestens zweiter Sprint -> lauffähige Version
	- Burndown-Chart
		tagesaktuelle Aufwandsschätzungen für akt. Sprint
		Aufgabe des Scrum Masters
		soll Probleme/Hindernisse schnell erkennen helfen

Wichtige Rollen
	- Product Owner
		verantwortlich für Product Backlog
		ausschließlich für Kommunikation Team/Auftraggeber
	- Scrum Master
		achtet auf Einhaltung der Ordnung/Regeln
		Abschottung des Teams von externen Einflüssen
	- Scrum Team
		Erreichung des Sprint Goals / Umsetzung Production Backlog

Vorteile
	Späte Änderungen kein großes Problem
	Schnelle Reaktion auf sich ändernde Anforderungen möglich
Nachteile
	Wenige/Keine terminlichen Anpassungsmöglichkeiten vorgesehen (tägliche Meetings, Sprint-Länge)
	keine Vorgaben bzgl Artefakten und Methoden (kann auch Vorteil sein!?)
Wesentliche Eigenschaften
	Fokus auf durchzuführende Aktivitäten
	verdankt Relevanz Erfindern und Benutzern
	Erweiterungen durch Kombination mit anderen SWEPs bei der eigentlichen SW-Entwicklung (Sprints) sinnvoll

--------------------------------------------------------------------------------------------------------------------------
- Refactoring, Beschreibung, Vor- und Nachteile, ein beliebiges Refactoring Pattern beschreiben -
-------------------------------------------------------------------------------------------------------------------------- - Foliensatz 8: Realisierung/Integration
Refaktorisierung
	Eine Änderung an der internen Struktur einer Software, um sie leichter verständlich zu machen und einfacher zu verändern,
	ohne ihr beobachtbares Verhalten zu ändern.

Refaktorisieren
	Eine Software umstrukturieren, ohne ihr beobachtbares Verhalten zu ändern, indem man eine Reihe von
	Refaktorisierungen anwendet.

Vorteile
	Erhöhung der Wartbarkeit
	Erhöhung der direkten und indirekten Wiederverwendbarkeit
	Erhöhung der Verständlichkeit
	Indirekte Code Inspektion
	oft durch IDEs automatisiert

Nachteile
	Nutzen oft nicht direkt messbar
	Veränderung kann unerwünschte Seiteneffekte beinhalten
	Refaktorisierung nicht immer anwendbar
	Verschiedene Refaktorisierungsstrategien anwendbar

Refactoring Pattern: Extract Method
	Code der in mehreren Methoden/Unterprogrammen gleich ist, wird in neue Methoden/Unterprogramme extrahiert
	diese neuen Methoden werden in den bestehenden Methoden/Unterprogrammen verwendet

---------------------------------------------
- V-modell XT: Arten des Tailorings -
--------------------------------------------- - Foliensatz 5: Prozesse 2
Statisches Tailoring
	zu Projektbeginn
	Charakterisierung eines Projekts anhand vorgegebener Projektmerkmale (-> Profil)
	Profil legt verpflichtend bzw. optional die zu verwendenden Vorgehensbausteine/Durchführungsstrategien fest
	durch Hinzunahme; nicht durch Streichung (nur relevante VB/DS wichtig)

Dynamisches Tailoring
	Während des Projekts
	Durch Hinzufügen/Entfernung von VB (Ausnahmen, Regeln)	

Detaillierte Anpassung erst bei Projektplanung
	Produkte (Abhängigkeiten), Aktivitäten

Erweiterungen/Anpassungen
	z.B.: von Vorgehensbausteinen, Entscheidungspunkten

---------------------------
- Arten der Wartung -
--------------------------- - Foliensatz 7: Qualitätssicherung, Wartung
Präventive Wartung
	Jene Maßnahmen, die ergriffen werden, um Fehler und damit weiteren Wartungsaufwand zu vermeiden,
	bevor sie auftreten.

Korrektive Wartung
	Alle jene Änderungstätigkeiten, die aufgrund eines Fehlers im System unmittelbar notwendig sind.

Adaptive Wartung
	Jene Anpassungen welche sich aufgrund der sich ändernden Systemlandschaft rund um das Softwareprodukt
	ergeben.

Perfektionierende Wartung
	Jegliche Veränderung  am Softwareprodukt, welche die Qualität des Produkts erhöhen soll.

Anteil: 50% Perfektionierend, 25% Adaptiv, 20% Korrektiv, 5% Präventiv

--------------------------------------------------------------------------------
- Wartung im RUP: welche Rollen, welche Dokumente, warum   -
- wird zwischen Fehler und Erweiterungswunsch unterschieden -
--------------------------------------------------------------------------------
finde nichts entsprechendes in den Folien WS07