Vergleich von klassischer und agiler Entwicklungsmethodik anhand der Entwicklung eines in Statemate simulierbaren Modells eines Türsteuergeräts

Transkript

1 Vergleich von klassischer und agiler Entwicklungsmethodik anhand der Entwicklung eines in Statemate simulierbaren Modells eines Türsteuergeräts Experiment an der Uni Ulm im SS 2003

2 berblick Motivation Idee Zielsetzung Struktur und Ablauf des Experiments Agile Methodik Klassische Methodik Ergebnisse Kritik Folie 2

3 otivation Flexibilität bei der Erstellung von Modellen Verbesserungspotential klassischer Methoden Stärken und Schwächen klassischer Methoden Stärken und Schwächen agiler Methoden Übertragbarkeit des agilen Ansatzes auf das Requirements Engineering Folie 3

4 Status: neu 5 Ph, 2(2) B. Ich gehe gerade die Fragen in der Sitzung durch. Ich sehe alle Felder (lesend), auch die Erläuterung. Die Erläuterung erscheint als Feld oder Sprechblase etc. In einem Feld kann ich einen ca. 5-Zeilen- Kommentar angeben bzw. ändern. Darin wird gesagt, wieso die Bewertung ausgewählt wird. Oder Bemerkungen gemacht. Beim Vor- und Zurückblättern taucht er wieder auf und ich kann noch mal ändern Ebenso, wenn die die DB verlasse und später wieder zurückkomme. dee des Experiments Erstellung von Statemate Modellen mit Hilfe zweier Methodiken: Agil (für dieses Experiment zusammengestellt aus XP, Scrum, klassischen Methoden): Kundennähe, Änderungsfreundlichkeit, Einfachheit, Flexibilität, Qualität, Modultests, Spaß,... FIRMA* Story Card Nr. 10 Kommentarfeld und Erläuterung Klassisch (praktisch erprobte und bewährte, plangetriebene Methode): Änderbarkeit und Änderungsverfolgbarkeit durch Requirements Pyramide, Dokumentation, Plan, Use Cases und daraus abgeleitete Test Cases. Folie 4

5 ielsetzung: Unterschiede zwischen agiler und lassischer Methodik hinsichtlich der Qualität der Testfälle... benötigten Modellierungszeit... Qualität der Modelle... Verständnis des Systems... Größe der Modelle... Änderbarkeit... Wartbarkeit der Modelle Folie 5

6 eilnehmer- und Zeitstruktur des Praktikums Vorbereitungsphase Experiment 7 Teilnehmer im Informatik Hauptstudium, verteilt auf drei Gruppen (eine klassische Gruppe und zwei agile). Des weiteren eine Schülergruppe von 10 Teilnehmern (11. Und 12. Klasse). Struktur: 13 Wochen (4 Wochen Einarbeitung, 9 Wochen Experiment) Einarbeitung in STATEMATE Erarbeiten theoretischer Grundlagen über Nebenläufigkeiten in hierarchischen Zustandsautomaten und über die Funktionsweise von hierarchischen Zustandsautomaten Beispielprojekte: Zweihandpresse, Innenlicht Einarbeitung in Use Cases, Story Cards, Testfallermittlung und Vertiefung der gewonnenen Kenntnisse anhand der Beispielprojekte Eigentliches Experiment: 3 Teams in 3 Phasen Folie 6

7 blauf des Experiments in drei Phasen Agile Gruppe Agile Modellierung des Türsteuergeräts inklusive Change Requests. el Modell TSG Rework (Integration) ge Request Change Requests Agil erstelltes TSG Klassisch erstelltes TSG Einarbeitung der Change Requests in die fremden Modelle Klassische Gruppe Klassische Modellierung des Türsteuergeräts inklusive Change Requests. Modell TSG Rework (Integration) Vergleich und Auswertung Change Requests Einarbeitung der Change Requests in die fremden Modelle. Phase 2 Phase 1 Change Request Phase 3 Folie 7

8 gile Methodik Story Cards Story Cards sind das Hauptplanungsdokument für die inkrementelle Entwicklungsarbeit. Jede Story Card beinhaltet einen in sich abgeschlossenen kleinen Arbeitsauftrag, der vom Kunden zu bewerten (priorisieren) ist. Eine Story Card soll den Umfang einer (Power-Point) Seite nicht überschreiten. Eine Story Card enthält folgende Informationen: ID Nummer, geschätzte Umsetzungsdauer, tatsächliche Umsetzungsdauer und Story Text. Folie 8

9 gile Methodik - Entwicklungsphase ach Kurt Schneider, Agile Under Constraints robe Spezifikation, Features, nderungswünsche unde 8 gibt Rückmeldungen 7 wird betrachtet 1 KOMMUNIKATION Customer Proxy Entwicklungsphase 2 Status: neu 5 Ph, 2(2) B. FIRMA* Story Card Nr. 10 Kommentarfeld und Erläuterung Ich gehe gerade die Fragen in der Sitzung durch. Ich sehe alle Felder (lesend), auch die Erläuterung. Die Erläuterung erscheint als Feld oder Sprechblase etc. In einem Feld kann ich einen ca. 5-Zeilen- Kommentar angeben bzw. ändern. Darin wird gesagt, wieso die Bewertung ausgewählt wird. Oder Bemerkungen gemacht. Beim Vor- und Zurückblättern taucht er wieder auf und ich kann noch mal ändern Ebenso, wenn die die DB verlasse und später wieder zurückkomme. 3 schätzt in Personenstunden 1 4 wählt aus 2 schreibt Testfälle Tester Entwickler Modultes Test Test t 5 modelliert Mod Folie 9 6 wird angewendet

10 lassische Methodik - Anforderungsbeschreibung Anforderungen werden explizit beschrieben: Die Nutzer-Anforderungen unterteilen sich in Featurelisten und Use Cases. Die Systemanforderungen sind die Statecharts und Kommentare in Statemate. Warum? (Ziele) Business- Anforderungen Nutzer-Anforderungen Wie? (Lösungen) System-Anforderungen Folie 10

11 lassische Methodik - Entwicklungsphase ach Kurt Schneider, Agile Under Constraints robe Spezifikation, Features, nderungswünsche 1 Entwicklungsphase Entwickler Tester 2 erstellen Plan Test Test Feature 1 Feature 2... unde 8 fragen 1 mal wöchentlich 3 erstellen Use Test Test Cases 4 modellieren Mod 7 wird betrachtet 1 mal wöchentlich 5 erstellen Use Case Diagramm e Testfäll Test e Folie 11 6 wird angewendet

12 rgebnisse Agile Methodik Vorteile Story Cards und Testfallermittlung leicht erlernbar hohe Qualität der Testfälle ausgeprägtes Systemverständnis leicht änderbar Nachteile vergleichbar hoher Dokumentationsaufwand festgefrorene Story Cards z.t. schwer zu nutzen behäbige automatisierte Tests bei Change Requests technische Fehler Klassische Methodik Planung mit Features und Erstellung von Use Cases unterstützt Systemverständnis unvollständige Testfälle lange Modellierungszeit technische Fehler hoher Dokumentationsaufwand Folie 12

13 ritische Betrachtung des Experiments Nicht alle erwarteten Unterschiede beobachtbar (z. B. Wartbarkeit) Schülergruppe schwer einzubeziehen Hinweise auf sinnvolle Adaption der agilen Methodik im Requirements Engineering Folie 13