Abgabe 10

Aufgabe 1.md

Aufgabe 1

Vorüberlegungen:

Die Datenstruktur "Array" bietet für Blackboxtests immer sinnvollerweise schon mal die Äquivalenzklassen "leer", "ein Element", "ein paar Elemente" und "sehr langes Array". Die Pre-Condition ist nicht zu testen, sie muss nur zur Erstellung valider Testfälle eingehalten werden und schränkt die für die Integer-Arrayelemente üblichen Fälle "negativ", "null", "positiv" auf die letzten beiden ein. Die Post-Conditions "gleiche Elemente" und "sortiert" legen ein Unterscheiden von Arrays, die Elemente mehrfach enthalten, und solchen, die es nicht tun, nahe, sowie Arrays, die bereits vorsortiert sind, und welche, die es nicht sind. Außerdem ist zum Testen von Sortierung sinnvoll, etwas längere, gut durchmischte Arrays zu testen, da ein Sortierverfahren evtl. recht komplex ist und man möglichst viele verschiedene Arten von "Unordnung" durch längere Arrays gut abdeckt.

Da wir nur 4 Klassen angeben, wählen wir die, die am sinnvollsten / wichtigsten erscheinen.

Array

Äquivalenzklasse	inputArray	outputArray
leer	[]	[]
einelementig	[42]	[42]
ein paar Elemente, sortiert	[0,23,23,40]	[0,23,23,40]
lang, unsortiert, mit mehreren Duplikaten	[5,5,21,0,1,4,666,1,6,7,8,3,2]	[0,1,1,2,3,4,5,5,6,7,8,21,666]

Aufgabe 2.md

Aufgabe 2

Kontrollflussgraph	Kantenüberdeckung der Testfälle

Testfalltabelle

Weniger als 3 Testfälle ist nicht möglich, denn es gibt 2 return-Punkte und der eine ist nicht auf einem Pfad zu erreichen, der durch beide Zeilen 10 und 11 verläuft (und Pfade zum anderen führen durch keine der beiden Zeilen).

Nr	Klasse	Beschreibung des Testfalls	Erwartetes Ergebnis (a,b)	Beispielhafte Eingabedaten
T1 (grün)	a=0	Parameter a ist null	b	(0,7)
T2 (blau)	a "gerader"	Parameter a gerade, b ungerade, a ist Zweierpotenz mal b	b	(2,1)
T3 (rot)	b "gerader"	a, b gerade, a/2 ungerade, b/2 gerade, b ist Zweierpotenz mal a	a	(2,4)

T1 verläuft durch Kanten Nr.: 1, 2
T2 verläuft durch Kanten Nr.: 1, 3, 4, 7, 9, 11, 12, 13, 14, 15, 16, 17, 19, 21
T3 verläuft durch Kanten Nr.: 1, 3, 4, 5, 6, 7, 8, 10, 12, 13, 14, 15, 16, 18, 20, 21

Aufgabe 3.md

Aufgabe 3

Da das Programm "kein Semikolon" enthält, findet die Sequenzregel hier keine Anwendung.

Um die Verzweigungen (if (.. < ..)) zu behandeln, wird die Auswahlregel angewandt, hierzu muss in jedem Block innerhalb einer if-Konstrukts jeweils unter Annahme der Bedingung (bzw. beim else der negierten Bed.) die jeweils in beiden Fällen (then/else) gleiche Nachbedingung folgen.
Zum Beispiel bei if ( b < c ) x := c else x := b im then-Fall, gilt unter Vorbedingung a < b and b < c klar die Nachbedingung a < b and b < x. Mithilfe der Konsequenzregel kann man jeweils zur Nachbedingung x = max{a,b,c} übergehen, da diese logisch aus der anderen folgt.

Aufgabe 4.md

Aufgabe 4

Aufgabe 5.md

Aufgabe 5

Das Modell des Extreme Programmings (XP) ist deutlich simpler aufgebaut als z.B. das Wasserfallmodell (WM). Beim WM kommt es auf Planung an, man teilt Zeit und Inhalte vorher ein und auf, nach Kategorien wie Anforderungsanalyse, Design, Entwicklung und Test. XP, macht dagegen "alles gleichzeitig", aber dennoch auf eine strukturierte Art und Weise.

-	Wasserfall-Modell	Iteratives Modell
Anwendbarkeit	Projektanforderungen dürfen sich nicht ändern	Vielseitig anwendbar, gerade bei variablen Anforderungen
Strukturierung des Systems	Projektstruktur wird geplant	Struktur wird muss nebenbei aufrechterhalten und angepasst werden
Reihenfolge der Aktivitäten	Sequentielles Vorgehen mit verschiedenen Entwicklungsphasen	"gleichzeitig" (bzw. in schnellem Wechsel) Planen, Entwickeln und Ausliefern
Breite einer Aktivität	Aktivitäten sind jeweils volle Entwicklungsphasen (sehr breit)	Aktivitäten Featureabhängig und fokussiert (schmal)
Nutzerbeteiligung / Festlegung der Anforderungen	Nutzer werden im Planungsprozess beteiligt oder sind bei Entwicklung gar nicht vorhanden, Anforderungen statisch festzulegen	Nutzer als "gleichgestellte" Mitglieder im Entwicklungsprozess, Anforderungen permanent änderbar
Manegementaufwand	Zeitplanung	Kommunikation und Organisation aller Beteiligten
Entwicklungszeit	Lange "nur" Entwicklung, aber ein abgeschlossener Prozess	sehr schnell ein "benutzbares" Produkt, aber langwieriger und zeitlich nicht überschaubare Entwicklungsprozess
Risiko "Fehlentwicklung"	Bei hinfälligen Anforderungen hohes Verlustrisiko	keine wirkliche "Fehlentwicklung" möglich
Verfügbarkeit des Systems / Fertigstellung	Es gibt eine fest geplante "Fertigstellung", danach aber erst Verfügbarkeit	"Fertigstellung" kaum plan- oder absehbar, dafür schon frühe Verfügbarkeit eines Systems