Unglaublich aber wahr, in der Schule dürfen wir einen Warenautomaten programmieren 🙂
Bevor aber etwas programmiert wird, geht es zuerst einmal in die Analyse. Wie schon in einem früheren Artikel erwähnt, ist es wichtig zuerst die Anforderungen des Kunden zu verstehen und diese in einem Model abzubilden. Wie sich manch einer denken kann, ist dies gar nicht so einfach.
Im folgenden Artikel möchte ich beschreiben, wie die Vorgänge in der Gruppe waren und was zu Schwierigkeiten geführt hat.
Phase 1 – Die ersten Schritte
Unsere Gruppe bestand aus 3 Personen und als erstes machten wir uns daran die Kundenspezifikation zu studieren. Wir konzentrierten uns zuerst auf das Klassendiagramm. Wir erarbeiteten das Diagramm mit folgenden Schritten:
- Suchen nach Klassen
- Suchen nach Beziehungen zwischen Klassen
- Suchen nach Attributen und Operationen
Schon nach kurzer Zeit hatten wir Diskussionen über irgendwelche Implementationsdetails, welche für die Analysephase überhaupt nicht wichtig sind. Auch gab es Meinungsverschiedenheiten, weil bei einem Entwicklerego stets seine Meinung die beste ist.
Nach dem ersten gemeinsamen Abend, machten wir uns also daran jeweils alleine das Klassendiagramm fertig zu stellen. Aus diesen 3 Erzeugnissen sollte dann später wieder ein Klassendiagramm gemacht werden, einfach mit den jeweils besten Varianten.
Phase 2 – Die Überarbeitung alleine
Ich arbeitete also alleine am Klassendiagramm für den Warenautomaten weiter. Die grössten Schwierigkeiten waren folgende:
- Verstehen der Anforderung des Kunden
- Wo platziere ich Attribute für die Datenhaltung
- Wie detailliert soll die Analyse sein?
Phase 3 – Das Zusammenführen
In Phase 3 des Miniprojekts galt es, die 3 Klassendiagramme zu einem zusammenzuführen. Es war doch überraschend, wie unterschiedlich sich die 3 Diagramme entwickelt habe, obwohl wir die gleiche Ausgangslage hatten.
Fazit
Was überraschte war, dass die grössten Schwierigkeiten in der Zusammenarbeit lagen. Dies hat wohl damit zu tun, dass man häufig denkt, man selber sei am schläusten, die eigene Meinung sei am wichtigsten usw. Hier noch einmal die wichtigsten Schwierigkeiten aufgelistet:
- Alle 3 Meinungen, Ansichten vereinigen (Aus 3 Varianten muss 1 gemeinsame Lösung erarbeitet werden)
- Sich nicht auf Design/Implementationsebene begeben (Das Modell muss nur logisch korrekt sein und sowohl für den Entwickler als auch für den Kunden verständlich sein) -> Designfragen klären verschwendet Zeit
- Anforderungen verstehen und in einem Model logisch korrekt abbilden
Hätte auch gedacht, dass das Mergen von 3 verschiedenen Varianten am aufwendigsten ist. Sehr interessant zu sehen wie aus einer Kundenspezifikation so unterschiedliche Klassendiagramme erstellt worden sind. Ich weiß noch nicht ob ich die Vorgehensweise gut finden soll oder ob es zeitsparender gewesen wäre, gemeinsam ein Klassendiagramm zu erarbeiten. Jedenfalls ein spannender Ansatz!
Es ging dabei auch nie um Effizienz. Wir müssen ja alle das modellieren lernen und daher haben wir uns entschieden, dass wir den 2. Teil alleine machen um die Unterschiede dann zu besprechen.
Wenn man etwas zusammen macht, besteht jeweils die Gefahr, dass die Person mit der meisten Erfahrung oder dem grössten Durchsetzungsvermögen die Stossrichtung vorgibt und dadurch die anderen beim Lernprozess zu kurz kommen.
Sehr geehrter Herr Meier
Ich finde Ihre Einträge und Aussagen sehr treffend und sie sind auch im 2018 noch aktuell.
Ich arbeite seit 2005 als Requirements Engineer. Habe sowohl in OO-Entwicklungsprojekten mit XP oder Scrum als Member gewirkt und auch als PO. Die Analyse ist eben das A. Ohne A keine Alphabet, kein aufbauendes Forwärtskommen. Im agilen Umfeld ist es mehr denn je wichtig eine Analyse zu einem Thema wirklich durchzuführen und die Frage des WAS nicht einfach zu interpretieren und dann dem Kunden bei der Retrospektive ein Teil zu zeigen, das er nicht einmal mehr erkennt. Zudem braucht auch der Kunde eine gewisse Zeit zum Überlegen, was er will. Diese Zeit schenkt ihm der Analytiker!