Theorie:
- Auf welchen Annahmen basiert sequentielle Softwareentwicklung & Probleme. Wie geht kontinuierliche SE damit um?

Annahme: vollständige unveränderliche Anforderungen.
z.B WasserfallModell, die vorherige aktuelle Phase muss abgeschlossen sein, damit in die nächste Pahase übergangen werden 
kann, zusätzlich basiert jede phase auf den Vorgänger phasen und ein Zurückspringne ist nicht möglich.
Problem: je innovativer eine Lösung ist, desto weniger sind die erforderlichen Eigenschaften zu Beginn bekannt.
dynamische Geschäftszweige ändern sich rasch -> Anforderungen ändern sich,
sequentieller Entwicklungsprozess ist eine system immanente Bruchstelle.

Kontinuierliche SE löst die aufgezeigten Probleme, in dem rasch ein ausliefbares Teilprodukt verfügbar ist, und der Entwicklungsprozess
sich über mehrere Iterationen erstreckt, wobei bei jeder Iteration da Produkt um zusätzliche Features erweiter wird, dadurch können Anforderungsänderungen schnell umgesetzt werden.
z.b SCRUM.



- Was sind funktionale und nicht-funktionale Anforderungen & 3 Bsp jeweils

  Funktionale Anforderungen:
   Was soll das System leisten?
   Welche Dienste soll es bieten ?
   Eingaben, Verarbeitungen, Ausgaben
   Verhalten in definierten Situtationen
   Datenformate
  Nicht funktionale Anforderungen:
   Wartbarkeit 
   Performance
   Sicherheit  
- Aufgaben eines SCM und Konflikt-Ablauf für verteilte SCM Beschreiben
 Source Code Management
  Parallel auf mehreren Zweigen arbeiten
  Mehrere Versionen Verwalten
  Transparente Änderungen
  Nachvollziehbarkeit Historie
  
  Konflikt Ablauf
	Locking,
	Merging,
   Arbeits Ablauf:
	lokal klonen des verteilten SCM 
	lokale änderungen durchführen 
	lokale Commits:
	Merge: Pull/Push
	
  
- Die 2 Teststrategien beschreiben
	Blackbox
		Input/Output
		Unabhängig von der Realisierung der Module
		data-driven
		Anforderungsüberdeckung
		Äquivalenzklassenbildung
		Keine genaue Fehlerortung möglich
	Whitebox
		Software Code als Grundlage
		logic driven
		Fundiertes Verständis des internen Aufbaus
		Datenflussabdeckung
		Äqivalenzklassen für Bedingungen und verschachtelungen 
		Ermöglicht Fehlererkennung- lokalisierung
	
	
Was ist Prozess Tailoring
	generische Entwicklungsprozesse die angepasst werden müssen an die individuelle Projektgegebenheiten
	individuelle Projektplan anpassung
	einzelne Prozessschritte durch Alternativen ersetzen
	Erfordert:
		Erfahrene Projektleiter da ein fundiertes Verständnis des Modellaufbaus erforderlich ist
		Die Berücksichtigung von definierten Tailoring-Kriterien
	
	Process Tailoring wird eingesetzt, da standatisierte Software-Prozesse, aufgrund einer Vielzahl von zu berücksichtigenden Projektattributen, in der Praxis eher schwer einsetzbar sind.
	
Systemintegration und Strategien beschreiben
	Big Bang
		Gleichzeitige Integration aller Komponenten.
		Vorteil: Keine zusätzlichen Aufwände für Test-Stubs
		Nachteile: Fehler schwerer lokalisierbar, Hohes Risiko bei Integration
		Anwendung: Kleine, überschaubare Produkte
	Bottom Up
		Schrittweise Integration ausgehend von der Hardware.
		Vorteile: Stabiles System, schrittweise Integration Richtung Businesscases (Layers)
		Nachteile: Ausführbares Gesamtsystem erst spät verfügbar, zusätzlicher Aufwand für Prototypen & Test-Drivers
	Top Down 
		Schrittweise Integration ausgehend von Business Cases.
		Vorteile: Ausführbares Produkt Framework früh vorhanden, Demo-Prototypen, Framework für Testfälle
		Nachteile: Hoher Aufwand für Test-Stubs, späte Integration von Hardware
	Build
		Schrittweise Integration entsprechend der Business Cases über alle Layer hinweg -> Phasen-orientierte Integration
		Vorteile: Frühe Verfügbarkeit von funktionalen Anforderungen, Prototypen & Demo, Berücksichtigung priorisierter Anforderungen möglich
		Nachteile: Wiederverwendung von Kompontenten möglicherweise schwierig, Regression-Tests erforderlich
		
- Prozess für Testfallbestimmung beschreiben und was dokumentiert wird
	Äquivalenzklassezerlegung:
	Eingabedaten werden in Klassen mit äquivalentem Verhalten eingeteilt und anschließend wird ein Repräsentant jeder Klasse für einen Testfall gewählt.
	Kann durch eine Grenzwertanalyse erweitert werden -> Repräsentanten um Klassen-Grenzen wählen

	Normal Fall / Spezialfall / Fehlerfall
	Vorbedingungen (Eingaben,..)
	evtl. Äquivalenzklasse
	Erwartest Ergebnis
	Tatsächliche Ergebnis
	
2 MC über Design Principles, Testphilosophie, System Control
	
Praxis:

Genau wie alle anderen Prüfungen, wo man nicht modelliert musste:

- Team aufstellen
	4 köpfiges Team:
		Person 1: Projektleiter und. technischer Architekt
		Frontend Dev
		Backend Dev
		Tester
		
- Prozess auswählen
	Agiler SE Prozess: 
		Wenige Entwickler, mittelgroßes Projekt mit einigen unklaren Anforderungen
		z.b Kunden sperren , muss noch abgeklärt werden 
		Vermutlich Erweiterung in Zukunft möglich deswegen Scrum 
		Scrum:
			kleine hocheffiziente Teams, Sprint im Vordergrund, Anforderungsänderungen schnell umsetzbar, hocheffizient 
- Meilensteine aufstellen
	Kick Off Meeting
	Projektfreigabe
	Anforderungsreview
	Entwurf-Design Review
	Sprint 1- n Design Review
	Produktabnahme
- Nicht funktionale Anforderungen bestimmen
- Burndown Chart analysieren (agile Verstoße nennen)
	idk.