Team-Projekt © Helmke Hon. Prof. Dr.-Ing. Hartmut Helmke in Deutsches Zentrum für Luft- und Raumfahrt e.V. (DLR) Institut für Flugführung Abteilung Lotsenassistenzsysteme Lilienthalplatz 7 38108 Braunschweig Tel. 0531 295-2599 E-Mail: [email protected] SS 2015 V 1.05; © Prof. Helmke 1 Team-Projekt © Helmke Hartmut Helmke Diploma degree in Computer Science from the University Karlsruhe (Germany) Since 1989 with DLR’s Institute of Flight Guidance Since 1999 with department of Controller Assistance, deputy department leader since 2005 Coordinates the development of AMAN 4DCARMA. Prof. Helmke is an assistant professor for Computer Science at Ostfalia University (Wolfenbüttel) since 2001. 25 courses at Ostfalia, 23 at DLR. [email protected] +49 531 295-2599 Project Lead of AcListant® since Feb. 2013. SS 2015 www.DLR.de/fl • Chart 2 V 1.05; © Prof. Helmke Team-Projekt © Helmke Wann machen wir? Vorschlag: 8:15 bis 11:30 Sie suchen sich die Pause. SS 2015 V 1.05; © Prof. Helmke 3 Team-Projekt © Helmke Lothar Christoffels Malte Jauer Gerald Siol SS 2015 Christian Weiß V 1.05; © Prof. Helmke 4 Team-Projekt © Helmke Flugzeuge über Europa SS 2015 V 1.05; © Prof. Helmke 5 Team-Projekt © Helmke Ihre Aufgabe: Wegpunkte und Path-Stretching anklicken Trajektorie, die Zielzeit einhält berechnen SS 2015 V 1.05; © Prof. Helmke 6 Team-Projekt © Helmke zeitlicher Verlauf von Höhe und Geschwindigkeit SS 2015 V 1.05; © Prof. Helmke 7 Team-Projekt © Helmke Was fehlt Die Software zur Berechnung der Trajektorien ist schon als Executable für Windows vorhanden Es fehlt eine GUI, per „Clicky-Bunti“ den Auftrag einzugeben. Das ganze soll als Client-Server-Anwendung per Web-Interface nutzbar sein. SS 2015 V 1.05; © Prof. Helmke 8 Team-Projekt © Helmke Webbasierte Client-Server-Anwendung SS 2015 V 1.05; © Prof. Helmke 9 Team-Projekt © Helmke Kompetenzziele des Team-Projektes Studierende sammeln Erfahrung in der Software-Entwicklung im Team. Sehr generisch Es geht um Softentwicklung, aber vor allem um das „Leben“ im Team. Softskills SS 2015 V 1.05; © Prof. Helmke 10 Team-Projekt © Helmke Lehrinhalte des Team-Projektes Praktische Umsetzung der vermittelten Lehrinhalte in Programmieren und ggfs. Softwaretechnik. 5 Credits, also 150 Stunden Aufwand. SS 2015 V 1.05; © Prof. Helmke 11 Team-Projekt © Helmke Rahmenbedingungen • • • Keine Klausur 5 Credtis, d.h. 150 Stunden bis Semesterende pro Teilnehmer Für eine 10er-Gruppe stehen 1.500h zur Verfügung • Jeder Dozent möchte 150 h bis Semesterende, bei 30 Credits sind das pro Nase 900 h, bei 15 Wochen ca. 60 Stunden pro Woche. Sie wollen aber auch die 5 Credits. • SS 2015 V 1.05; © Prof. Helmke 12 Team-Projekt SS 2015 Termine des Sommersemesters 2015 V 1.05; © Prof. Helmke © Helmke 13 Team-Projekt SS 2015 Termine des Sommersemesters 2015 V 1.05; © Prof. Helmke © Helmke 14 Team-Projekt © Helmke Spezielle Termine 6.3. 13.3. 27.3 Gruppeneinteilung, Aufgabe verstehen Vorstellung der Gruppe Requirements-Dokument vorstellen bzw. Demo der ersten Implementierung 3.4 Karfreitag, fällt aus 10.4 Gruppe A, B, C: ggf. Zwischendemo 17.4 Gruppe D, E, F: ggf. Zwischendemo 24.4 Enddemo: 1. Teil; Ideen für zweite Aufgabe vorbesprechen 1. Mai Fällt aus 8.5. Requirements-Dokument vorstellen bzw. ein Teil gibt Demo des Standes (Gruppe A, B, C) 15. Mai Himmelfahrt fällt aus 22.5 Restliche Gruppen: Zwischen-Demo (Gruppe D, E, F) 29.5 ggf. Zwischendemo (Gruppe A, B, C) 4.6 ggf. Zwischen-Demo (Gruppe D, E, F) 11.6 Enddemo SS 2015 V 1.05; © Prof. Helmke 15 Team-Projekt © Helmke Gruppeneinteilung • • • X Teilnehmer pro Gruppe streben wir heute an Wir losen Bilden Sie Zweier-Teams. Wir gruppieren zu Teams Wir behalten uns eine Umstrukturierung der Gruppen bis Semesterende vor • Die Gruppen tragen nächste Woche ihre ersten Ergebnisse des Teamfindungsprozesses vor • Alle Gruppen dürfen bei den anderen Gruppen zuhören, müssen es aber nicht, seien Sie aber pünktlich für Ihren Slot anwesend. SS 2015 V 1.05; © Prof. Helmke 16 Team-Projekt © Helmke Gruppeneinteilung SS 2015 V 1.05; © Prof. Helmke 17 Team-Projekt © Helmke Wollen Sie Arrival Interval Calculator oder Trajektorien Generator? SS 2015 V 1.05; © Prof. Helmke 18 Team-Projekt © Helmke Literatur Jochen Ludewig, Horst Lichter: Software Engineering, dpunkt Verlag, 2013 (3. korrigierte Auflage) Bernd Müller: Software-Technik, Vorlesungsskript, Fakultät für Informatik, Ostfalia, Hochschule Braunschweig/Wolfenbüttel, Ian Sommerville: Software Engineering, 9. Auflage. Addison-Wesley Verlag, 2012 Ian Sommerville: Software Engineering, 9. Auflage in Englisch. Addison-Wesley Verlag, 2010 SS 2015 V 1.05; © Prof. Helmke 19 Team-Projekt © Helmke Literatur Chris Rupp & die SOPHISTen: Requirements-Engineering und –Management — Professionelle, iterative, Anforderungsanalyse für die Praxis, Hanser Verlag, 2014 6. Aktualisierte Auflage Hans-Peter Mössenböck. Sprechen Sie Java? Eine Einführung in das systematische Programmieren 5. Auflage, dpunkt-Verlag, 2014 SS 2015 V 1.05; © Prof. Helmke 20 Team-Projekt © Helmke Sonstige Literatur Scott Ambler: Introduction to User Stories. Initial User Stories. Artikel in Englisch, http://www.agilemodeling.com/artifacts/userStory.htm; Kent Beck, Erich Gamma: JUnit Cookbook. Artikel in Englisch, http://junit.sourceforge.net/doc/cookbook/cookbook.htm; SS 2015 V 1.05; © Prof. Helmke 21 Team-Projekt © Helmke Carl Rogers: Du kannst Menschen nichts lehren, Du kannst Ihnen nur helfen, es in sich zu entdecken. Team-Projekt © Helmke Erwartungen an Vortrag nächste Woche Siehe pdf-Folien plus Bewertungskriterien SS 2015 V 1.05; © Prof. Helmke 23 Team-Projekt © Helmke Feedback SS 14: Empfehlungen an Nachfolger (1) 1. Nicht allzu viele andere Fächer belegen 2. IT-Manager sollten ein paar Informatiker dabei haben 3. Code von Betreuern hätte zusammen mit Betreuern stärker zu Beginn analysiert werden müssen. 4. Viele Bonuspunkte erreichen 5. Nichts auf letzten Drücker terminieren 6. Fristen setzen und auf Einhaltung dringen 7. Häufige Teammeetings abhalten 8. Von Beginn an dran bleiben (so wir es gemacht haben) 9. Frühzeitig den Sprint beginnen 10. Aufgaben sinnvoll an die Teammitglieder zu verteilen (sonst machen 2 alles) 11. Vor allem am Anfang viel Zeit in Planung stecken, das vermeidet Fehler im späteren Verlauf V 3.11; © Prof. Helmke 24 Team-Projekt © Helmke Feedback SS 14: Empfehlungen an Nachfolger (2) 1. „printToConsole“ in eine Klasse auslagern, die nicht mit eingecheckt wird 2. Viel fragen 3. Um Hilfe bitten (auch die Betreuer), sich nicht alleine zu lange festbeißen 4. Fach nicht unterschätzen 5. Betreuer/ Dozenten mit Fragen nerven V 3.11; © Prof. Helmke 25 Team-Projekt © Helmke Feedback SS 14: Vorträge der anderen Gruppen sinnvoll? (1) 1. 2. 3. 4. 5. 6. 7. Nein, es wurde kein Codegezeigt Nein, Projektfortschritt der anderen nicht so interessant Nein, man schaut eher auf seine eigenen Probleme Nein: I Nein, aber dennoch interessant die Stände und Ergebnisse der anderen Gruppe zu erfahren Nein, weil im Grunde das gleiche wie beim eigenen Team erzählt wurde, Konkrete Codelösungen fehlten dagegen Nein, weil selbst schon anders implementiert wurde, trotzdem interessant V 3.11; © Prof. Helmke 26 Team-Projekt © Helmke Feedback SS 14: Vorträge der anderen Gruppen sinnvoll? (1) 1. 2. 3. 4. 5. Ja, Vereinzelt Inspiration für eigene Arbeit und Feedback um eigene Qualität einzuschätzen Ja, die persönliche Verunsicherung wurde beseitigt, weil im Vortrag auch gezeigt wird, dass die andere Gruppe die gleichen Probleme hat Ja, man sieht wie weit die anderen sind und wird aufgebaut, wenn dort ähnliche Fehler passieren Ja, etwas erfahren, wie sich Teams organisieren Ja, aber nur in den ersten Sprints sinnvoll V 3.11; © Prof. Helmke 27 Team-Projekt © Helmke Feedback SS 14: Wie könnte man Vorträge verbessern? (1) 1. In den ersten Sprints mehr Code zeigen V 3.11; © Prof. Helmke 28 Team-Projekt © Helmke Feedback SS 14: Transparenz der Bewertung (1) 1. 2. 3. 4. 5. 6. 7. 8. 9. Manchmal war erst nach Bewertung klar, was gemacht werden sollte Teilweise erst nach Bewertung klar, was genau bewertet wird Nicht immer ohne Rückfragen zu verstehen, manchmal hätte ein Satz mehr geholfen Manchmal war erst nach der Bewertung ersichtlich, welche Aufgaben wirklich übernommen werden sollten Ja, sehr ausführlich Ja: I Transparenz war gut und man konnte sich vorbereiten, bevor bewertet wurde Teilweise ja, aber auch mal auf die individuellen Stärken des Teams eingehen (HHe ???, unterschiedlich bewerten?) Teilweise nicht nachvollziehbar, zu wenig erklärt V 3.11; © Prof. Helmke 29 Team-Projekt © Helmke Feedback SS 14: Jeder aus Team gleiche Punktzahl 1. 2. 3. 4. War O.K. Ja, weil jeder im Rahmen seiner Kenntnisse zum Gesamterfolg beigetragen hat Ja: I I I I I I I | I Ja, aber gilt nicht immer V 3.11; © Prof. Helmke 30 Team-Projekt © Helmke Feedback SS 14: Losverfahren in Ordnung 1. 2. 3. 4. 5. Ja: I I I I I I Nein I Jein: I Ja, aber wir hatten Glück, weil unsere Teammitglieder ähnliche Stundenpläne hatten Ja, aber besser erst selbst in Gruppen aufteilen und den Rest bei Losverfahren V 3.11; © Prof. Helmke 31 Team-Projekt © Helmke Feedback SS 14: Wettbewerb am Ende 1. 2. 3. 4. 5. 6. Ja, fördert Motivation: I I Ja, etwas Spaß zum Semesterende Ja: I I I I I Ja, es motiviert und zeigt nochmals die Ergebnisse jeder Gruppe Nein, da es selbst mit Wettbewerb keine Chance mehr 1,0 gab, auch wenn man noch viel Zeit investiert hätte (Hhe: Das war nicht korrekt, in jedem Team gab es mindestens drei Leute mit besser als gut als Bewertung, Praktisch gilt es vielleicht schon, wenn der eigene Code bereits so „kaputt“ ist, dass man damit einfach nicht mehr gewinnen kann) Ja, aber Punktevergabe unfair (Hhe: Warum?) V 3.11; © Prof. Helmke 32 Team-Projekt © Helmke Feedback SS 14: Jedes Mal ein anderer Scrum-Master sinnvoll? (7) 1. 2. 3. 4. 5. 6. 7. 8. Ja, jeder sollte mal machen Ja, so konnte jeder Scrum kennenlernen, auch wenn es gute und andere Scrummaster gab Nein: I I Vielleicht: I I Ja: I I I Sinnvoll, wenn er/sie gut ist Vielleicht, sollte das Team selbst entscheiden Ja, denn praktische Erfahrung ist Gold wert V 3.11; © Prof. Helmke 33 Team-Projekt © Helmke Feedback SS 14: Test-first (8) 1. 2. 3. 4. 5. 6. 7. Gut und akzeptiert Macht schon Sinn Muss sein Anstrengend, zeitaufwändig, viel Vorarbeit nötig, ABER sinnvoll Zum ersten mal praktiziert, besser als ohne Oft unrealistisch, weil man oft erst mal nur ausprobieren will Sehr sinnvoll, anfangs schwierig, da man erst mal lernen muss, wie man richtig testet 8. Schwierig, vor allem am Anfang, Hieraus müsste in Software-Technik mehr drauf eingegangen werden 9. Ist O.K. 10. Gut, allerdings zu wenig Erfahrung, wie man es richtig macht V 3.11; © Prof. Helmke 34 Team-Projekt © Helmke Feedback SS 14: Sonstiges (1) 1. War trotz allem die sinnvollste und lehrreichste Veranstaltung 2. Einsatz von Scrum in den Ostfalia-Lehrveranstaltungen schwierig 3. Von Anfang an sollte feststehen, wer Entwickler, Scrummaster ist (nicht den Scrummaster wechseln). 4. IT-Manager sind keine Programmierer 5. Teilweise unklare Aufgabenstellungen 6. Bewertung gerechter als eine „Müller“-Bewertung 7. Durch Feedback der Betreuer oft Arbeit am Sa/So erforderlich, ggf. Abgabetermin auf Samstag vorverlegen, bzw. Bonuspunkte, wenn nicht am Sonntag fertig gestellt wird. (Hhe Es gab Bonuspunkte für frühere Abgabe, Feedback am Freitag war als Hilfe gedacht, um noch Korrekturen vor Bewertung durchführen zu können, ist nur vorher möglich, wenn vorher etwas (>75%) vorliegt.) V 3.11; © Prof. Helmke 35
© Copyright 2024 ExpyDoc