Softwareprojekt: "Agile Softwareentwicklung in einem Open-Source-Projekt"
Modulbeschreibung
| Typ: | Projektseminar (ECTS: 10) |
| Dozenten: | Franz Zieris Lutz Prechelt |
| Sprache: | Deutsch |
| Zeitraum: | 15.08.2016 bis 23.09.2016 |
| Vorbesprechung: | Mi 27.04.2016 16:00 bis 18:00 Uhr, SR 005, Takustr. 9 |
| maximale Teilnehmerzahl: | 16 |
| Terminhinweis: | Blockveranstaltung in der vorlesungsfreien Zeit: 15.08.2016 bis 23.09.2016 |
| Inhalt: |
Dieses Softwareprojekt findet im Kontext eines Open-Source-Projektes statt. Die Teilnehmer/innen arbeiten sich – nah an der Berufsrealität – in ein bestehendes Softwaresystem innerhalb eines komplexen Ökosystems ein. Sie folgen dabei einem agilen, iterativen Entwicklungsprozess und durchlaufen mehrfach die typischen Phasen eines Softwareprojekts. Die aus der Vorlesung "Softwaretechnik" bekannten Methoden und Vorgehensweisen werden hierbei vertieft. Im Einzelnen:
|
| Zielgruppe: | Studierende im Bachelor- oder Masterstudium Informatik |
| Voraussetzungen: |
|
| Literatur: |
|
Organisatorisches
Anmeldung
Die Anmeldung erfolgt im KVV. Hinweis zur Anmeldung im Campus-Management: Bachelor-Studierende der neuen Ordnung (gültig seit WiSe 2014/15) haben die Wahl zwischen den Modulen "Softwareprojekt A" (undifferenziert benotet, d.h. bestehen oder nicht) und "Softwareprojekt B" (differenziert benotet, d.h. volles Notenspektrum). Wann sollte man welche Variante wählen:- Man hat im Nebenfach mehr als 6 unbenotete Leistungspunkte erworben --> man muss Variante B buchen, weil man sonst mehr unbenotete Leistungspunkte hat als erlaubt ist (nämlich mehr als 45). Andernfalls müsste am Ende aus einem Projekt A ein Projekt B gemacht werden, und aus dem "bestanden" wird eine "4.0".
- Man hat nicht zu viele unbenotete Leistungspunkte aus dem Nebenfach, bzw. weiß das noch nicht --> man sollte Variante B wählen, weil man das im Zweifelsfall als A-Projekt anrechen lassen kann.
Termine
Die erste Präsentation und reichlich Möglichkeiten zum Fragenstellen gab es am 2016-04-27. -- die Folien stehen zum Download bereit. Einführungswoche- Montag, 2016-08-15, um 10 Uhr (c.t.) in Raum K48: Folien
- Dienstag, 2016-08-16, um 10 Uhr (c.t.) in Raum K48: Folien
- Mittwoch, 2016-08-17, um 12 Uhr (c.t.) in Raum K48: Folien
| Woche 1 | Woche 2 | Woche 3 | Woche 4 | Woche 5 | Woche 6 |
|---|---|---|---|---|---|
| K48 | K44 | ||||
FAQ
Sind die Voraussetzungen obligatorisch?Die Vorlesung Softwaretechnik muss bestanden sein; die aufmerksame und (soweit möglich) aktive Lektüre der angegebenen Web-Literatur sollte zur Aneignung der Grundkenntnisse in Git und Scrum ausreichen. Die Anschaffung des Git-Buches ist ausdrücklich nicht erforderlich. Wie nötig sind eigene Notebooks?
Die PC-Pool-Rechner können genutzt werden, aber nur in begrenztem Umfang an persönliche Vorlieben im Entwicklungsprozess angepasst werden. Die größte Flexibilität hat man mit eigener Hardware. Wie wird die Anwesenheit geregelt?
Es wird von 40-Stunden-Wochen ausgegangen, was einem Tagespensum von 8 Stunden entspricht. In der Kernarbeitszeit von 10 - 15 Uhr müssen alle Teammitglieder anwesend sein (exkl. Mittagspause). Meine Frage wurde nicht beantwortet!
Hier hilft eine Kontaktaufnahme mit Franz Zieris, z.B. per Mail: zieris@inf.fu-berlin.de.
Scrum
Product Backlog
Zum Product Backlog.Allgemeine Festlegungen
- Das Daily Scrum findet Di-Fr um 10:15 Uhr statt.
- Montags findet zwischen
10:15 und 12:15 Uhr13:30 und 15:30 Uhr das Sprint Planning statt; ein Daily Scrum ist hier unnötig. - Der Sprint Review und die Sprint Retrospektive werden am Freitag von 12:30 bis 13:30 bzw. 13:30 bis 14:30 Uhr stattfinden.
Spezielle Festlegungen
- (aus Retro 2:) In der Zeit vor dem Sprint Planning analyisiert das Entwicklungsteam gemeinsam die risikoreichsten Einträge aus dem Product Backlog, um beim Planning kein falsches Commitment abzugeben.
Definition of Ready-to-Review
Ein Item ist "ready-to-review", wenn:- Alle im Backlog formulierten Anforderungen erfüllt sind.
- Test-Fälle formuliert und -- falls möglich -- automatisiert sind.
- Test-Fälle erfolgreich durchgelaufen sind.
- Das Inkrement sich aus den Quellen heraus demonstrieren lässt.
Definition of Done
Ein Item ist "done", wenn:- Das Item "ready-to-review" ist.
- Die zum Inkrement gehörigen Patches erfolgreich begutachtet und in den master-Branch integriert wurden.
- Die Test-Fälle laufen auf der Version von der Nightly Build-Update-Seite erfolgreich durch.
- Das Inkrement lässt sich von der Nightly Build-Update Site her demonstrieren.
Sprint Goals und Backlogs
Sprint 1
Spring Goal -- am Ende der KW 34:- haben wir das Feature HighlightMirror implementiert,
- den IntOverview erstellt, und
- die restlichen Product Backlog Items abgeschätzt,
- sowie die restlichen Aufgaben aus der Einführungswoche bearbeitet.
- Einführungaufgaben abschließen:
- Wann: Benötigt Reviews, daher zu Beginn des Sprints.
- HighlightMirror: Die lokale Hervorhebung von Bezeichnerverwendungen nach einem Anklicken (nicht Selektion) des Bezeichners soll auch für die anderen Sitzungsteilnehmer sichtbar sein.
- Wann: Benötigt Reviews, daher zu Beginn des Sprints.
- IntOverview: Für die Planung der weiteren Entwicklung brauchen wir eine Übersicht über die Mängel und Funktionslücken in der aktuellen Implementierung von Saros für IntelliJ.
- Ziel: Eine Liste von Mängeln und Funktionslücken in Saros/I, die die Unterschiede zu Saros/E dokumentiert.
- Wann: Weil hier auf Reaktionen gewartet werden muss, nach den oberen beiden Aufgaben, bzw. wenn bei obigen Aufgaben Wartezeiten entstehen
- Restliche Product Backlog Items abschätzen:
- Ziel: Eine Liste mit den aktuell bekannten Product Backlog Einträgen mit einer Aufwandsschätzung auf halbe Entwicklertage genau, inkl. einer Liste beteiligter Klassen.
- Wann: Nach den oberen drei Aufgaben
- Allgemein: Es war noch keine Änderung integriert (weder im Saros-Hauptprojekt, noch in der Projekt-Kopie), demonstriert wurden nur Entwicklungsstände auf Arbeitsplatzrechnern.
- HighlightMirror:
- Es werden keine Hervorhebungen übertragen, sondern es wird der Text-Cursor aktiv versetzt. Dadurch werden etwaige Tippaktivitäten des Followers gestört.
- Wenn der Followee selbst tippt, dann sieht er/sie das "Nachziehen" der Text-Cursor seiner Follower in seinem Editor. Je nach Netzwerkgeschwindigkeit wird der eigene Cursor also durch eine Reihe fremder Cursor verfolgt, was den Followee irritiert.
- Zusätzlich werden etwaige Selektionen übertragen und ebenfalls aktiv gesetzt.
- Das Feature ist nicht auf Bezeichner beschränkt, sondern überträgt jede Cursor-Position und -Selektion.
- IntOverview:
- Bereich "User Data and Crash Reports"
- Unklar, ob diese Daten nicht erhoben, oder nicht versendet werden.
- Bereich "Sesion Management"
- Unklar, was genau "Problem with reliability" bei "Initiate a Session" bedeutet.
- Der Status von "Partial Sharing" ist unklar.
- Der Status von "Version Control" ist unklar.
- Der Status von "Adding additional contacts to a session" ist unklar.
- Unklar, ob Saros/I sowohl das Anlegen neuer Projekte als auch die Wiederverwendung ermöglicht
- Unklar, ob Sitzungen mit mehreren Nutzern gestartet werden können
- Bereich "Preferences"
- Unklar, welche Vorseinstellungen lediglich eine Einbettung in die Oberfläche von IntelliJ benötigen, welche zusätzlich noch einen Speicher-Mechanismus benötigen, und welche Einstellungen bereits einen Effekt auf das Verhalten von Saros/I haben.
- Bereich "Editor"
- Unklar, ob ViewportAnnotations angezeigt werden.
- Unklar, ob die aktuell offene Datei im Projekt-Explorer und den Karteireitern angezeigt wird.
- Bereich "Miscellaneous"
- Unklar, ob der Status (z.B. "away") von Kontakten angezeigt wird.
- Bereich "User Data and Crash Reports"
- Abschätzung der restlichen Backlog-Items
- Einheit der Abschätzung unklar: Heißt "5 Tage" (a) "5 Personentage" oder (b) "ein kompletter Sprint"?
- Abschätzung von IntComp wirkt mit 30 Personentagen extrem überhöht, denn:
- Es sollte ausreichen zu versuchen, Saros/I mit einer neuen Intellij-Versionzu bauen und Kompilierfehler zu beheben. Die wahrscheinlichsten Änderungen sind (1) deprecated/gelöschte API-Elemente und (2) neue Methoden in implementierten Interfaces (siehe https://sourceforge.net/p/dpp/bugs/862/). Subtile Änderungen an der API (es kompiliert noch, läuft aber nicht mehr) sind nicht zu erwarten und würden als Bug behandelt werden.
- "Build-Server" heißt nur, dass der Saros/I-Quellcode automatisiert gebaut und getestet wird. Diese Infrastruktur steht. Aus Sicht des Build-Tools (hier: ANT) ist IntelliJ nur eine von mehreren Bibliotheken, d.h. eine neue IntelliJ-Installation muss dem Build-Server bereit gestellt werden, wie schon aktuell eine IntelliJ-13-Installation bereit gestellt ist.
Sprint 2
Spring Goal -- am Ende der KW 35:- haben wir das Feature HighlightMirror implementiert (Aufwand in diesem Sprint auf 4 Personentage gedeckelt),
- haben wir folgenden Zustand der Sitzungseinladung in Saros/I hergestellt (IntSession):
- Sitzungseinladungen sind zuverlässig aus der GUI heraus zu starten
- es treten keine Timeouts auf, die nicht auf reine Netzwerkprobleme zurückzuführen sind
- die Projektressourcen werden vollständig übertragen
- der konstante Anteil der Zeit, die eine Saros/I-Einladung dauert darf nicht mehr als 50% größer sein als die vergleichbare Zeitspanne einer Saros/E-Einladung
- es kommt zu keinem "Einfrieren" der Oberfläche
- Montag:
- Einrichten der Arbeitsumgebung nach Raumumzug (Bernd und Michaela)
- Anlegen des Bugtracker-Eintrags für IntSession (Alex)
- Dienstag:
- Nachmittags Mail an Mailingliste falls es keine Reaktionen im Bugtracker gab
- sonst:
- HighlightMirror wird durch Michaela bearbeitet: 3 Tage plus später dann Hilfe von Alex.
HighlightMirror:
- wurde auf einem Entwicklungsrechner präsentiert, es wurden keine Mängel festgestellt
- die Integration in das Saros-Projekt steht noch aus
- GUI-Elemente zum Sitzungsstart:
- "Work together on"-Button wird immer angezeigt, und man kann auch eine Sitzung mit einem Modul starten
- "Share With"-Button wird nicht immer angezeigt; es gibt allerdings ein Setup (=Infrastruktur/Projekt-Kombination) bei dem der "Share With"-Button zuverlässig immer angezeigt wird, d.h. dass die Verfügbarkeit des Buttons ist aktuell sowohl von Infrastruktur- als auch Projekteigenschaften abhängig.
- Störungen der sonstigen IDE:
- Manchmal wird ein mit dem Projekt gleichnamiger Ordner automatisch angelegt. Gibt es diesen Ordner, wird der "Share With"-Button nicht mehr angezeigt. Der Auslöser für das Anlegen dieses Ordners scheint zu sein, dass sich Saros/I in einen dubiosen Verbindungsstatus begibt.
- Manchmal wird beim Rechts-Klick auf einen Ordner/ein Modul (?) kein Kontextmenü angezeigt.
- Fehlerbehandlung beim Sitzungsaufbau:
- Schlägt der Sitzungsaufbau fehl, erscheint auf Empfängerseite ein kaum sichtbares (klein und in der Bildschirm-Ecke) Dialogfenster, das sich nicht endgültig schließen lässt, d.h. der Fenster-Inhalt verschwindet zwar, aber das Fenster selbst bleibt.
- Vollständige Projektdaten:
- Bei erfolgreichem Sitzungsaufbau (d.h. kein Abbruch) werden alle Modul-Inhalte komplett zum Empfänger übertragen; alle Sitzungsteilnehmer inkl. Sender haben den gleichen Stand des Moduls.
- Ein erfolgreich übertragenes Modul ist auf Empfänger-Seite kein "Modul" im IntelliJ-Sinne, sondern nur ein normaler Ordner.
- Abbruch der Einladung:
- Manchmal bricht der Einladungsprozess nach der ersten Seite des Wizard (der fragt, ob man die Einladung annehmen wolle) ab. Dann erscheint auf Empfänger-Seite ein Fehlerdialog (siehe "Fehlerbehandlung") mit dem Inhalt, dass der Host die Einladung abgebrochen haben, weil der Empfänger die Einladung abgelehnt hätte.
Es scheint sowohl Netzwerkkonfigurationen zu geben, bei denen das immer passiert; solche, bei denen das nie passiert; und solche, bei denen es manchmal passiert.
- Manchmal bricht der Einladungsprozess nach der ersten Seite des Wizard (der fragt, ob man die Einladung annehmen wolle) ab. Dann erscheint auf Empfänger-Seite ein Fehlerdialog (siehe "Fehlerbehandlung") mit dem Inhalt, dass der Host die Einladung abgebrochen haben, weil der Empfänger die Einladung abgelehnt hätte.
- Geschwindigkeit der Einladung:
- Der konstante Zeitanteil bei einer erfolgreichen Saros/I-Einladung liegt bei 40 Sekunden (Vergleich: 10 Sekunden bei Saros/E). Evtl. wurde auch ein deutlich kleinerer konstanter Anteil von wenigen Sekunden beobachtet -- das genaue Setup ist unbekannt.
Sprint 3
Spring Goal -- am Ende der KW 36:- IntSession-GUI: Der Sitzungsaufbau in Saros/I kann zuverlässig über den Share With-Button (im IntelliJ Project View) initiiert werden, wenn eine Verbindung zum XMPP-Server hergestellt wurde und mind. ein Kontakt ebenfalls online ist.
- IntSession-GUI: Der Zuverlässigkeit des Work together on-Buttons (in der HTML-View) ist analysiert und ein Lösungsvorschlag ist formuliert (soweit denn ein Problem bei der Analyse festgestellt wurde)
- IntSession-Wrk: Nach erfolgreichem Sitzungsaufbau sollen beide Entwickler so an dem geteilten Modul arbeiten können, wie es der Sender vorher allein konnte. D.h. dass die Modulinhalte gleich sind, und diese in gleicher Weise bearbeitet werden können.
- Das Feature HighlightMirror ist abgeschlossen.
IntSession-GUI:
- Der "Share With"-Button initiiert zuverlässig eine Sitzungseinladung.
- Neues Problem: Nach dem Öffnen eines neuen Projektes ohne IntelliJ dabei zu schließen funktioniert die Sitzungseinladung nicht zuverlässig.
- Aufwandsabschätzung: 3-4 PT
- Es gibt es einen "Start Session"-Button, der einen Wizard öffnet
- Dieser Wizard zeigt zwei Seiten: Zu teilende Ressourcen und einzuladene Kontakte, ersterer ist leer, sodass man keine Module auswählen kann. Eine leere Sitzung kann man aber dennoch starten, und der Eingeladene kann dieser auch beitreten.
- Lösungsvorschlag: Module sollen ausgewählt werden können, Implementierung der Modulliste. Aufwandsabschätzung: 3-5 PT
- Übertragene Module werden als Module statt nur als Ordner angezeigt.
- von der Saros-Community übernommen
Sprint 4
Die Sitzungseinladung in Saros/I soll zuverlässig in einen konsistenten, arbeitsbereiten Zustand führen.Sprint 5
Primäres Ziel:- Die Sitzungseinladung in Saros/I soll zuverlässig in einen konsistenten, arbeitsbereiten Zustand führen.
- Angefangene Arbeiten abschließen
- Erworbene Erkenntnisse (z.B. erkannte und verstandene Probleme) für das Saros-Projekt dokumentieren
Material
Folien der Vorträge
- Vor-Vorstellung des Projekts (2016-04-27)
- Vorstellung des Projekts (2016-08-15)
- Vertiefung SWT und Projekthinweise (2016-08-16)
- ToDos für den Rest der Einführungswoche (2016-08-17)
