Dies ist die ResourceMap!

Jeder Pixel (100*100) dieser png Datei entspricht einem möglichem Produktionsfeld auf der original Map!

Die Farbwerte beschreiben welche Gebäude wo gebaut werden können!

Blau = Unbebaubar

Grün = Holzfällerplätze

Rot = Steinmetzplätze

Dunkelrot/Braun = Fischerhüttenplätze

Schwarz = Normale Gebäudeplätze

Screen Cast SE1_K06_QS1.html

SE1_K05_QS1.ppt

Da das erste Release ansteht, eine kurze Info zu den Terminen:

• In der letzten Woche des Releases trifft sich der Product Owner der ersten Releases mit den Kunden, aktualisiert das Product Backlog und erstellt mit dem Kunden das neue Release Backlog.
• In der ersten Woche des neuen Releases präsentieren der alte Product Owner und der alte Scrum Master den Kunden das fertig gestellte Release.
  • Präsentation mit Installation auf einem Kundenrechner.
  • Alle Teammitglieder sollten anwesend sein.
  • Betreuer und Kunden werden anwesend sein und sich Notizen zur Bewertung des Vortrags machen.

Bitte nehmt Kontakt mit euren Kunden auf und vereinbart entsprechende Termine.

Des weiteren gilt die Releasepräsentation als Offizielle Übergabe der Product Owner und Scrum Master Rollen.

Die Vorlesung Softwaretechnik ist jetzt in der OKA freigeschaltet. Bitte meldet euch rechtzeitig an, da wir das Prüfungsdatum auf den 06.12.2009 gelegt haben um den Teams mehr Sicherheit bezüglich ihrer Mitglieder zu geben.

Die heute in der Vorlesung vorgestellte Code Coverage sollte regelmäßig vom Scrum Master durchgeführt werden und

1. bei Anzeichen von Unterdeckung auch während der Daily Scrums angesprochen werden und
2. die Code coverage fließt als eigenes Kapitel in die Technische Dokumentation zum Release mit ein.

Eine Vorabversion sollte mit den Betreuern durchgesprochen werden.

Die Beispielgrafiken wurden mit GIMP erstellt und sind auf die unterschiedlichen Ebenen der .xcf Datei Verteilt:

Karte: LSS Grafikpaket.xcf.zip (32,8 MB, entpackt 53,1 MB)

Objekte: Grafikpaket Objekte.zip (2,9 MB, entpackt 3,9 MB)

Wir haben den Server aktualisiert. Ein login mit Passwörtern ohne Sonderzeichen sollte jetzt funktionieren und auch mit einem SUCCESS quittiert werden.

Wir werden hier bekannt geben sobald der Server auch mit Sonderzeichen umgehen kann.

In der Regel ist jedes Feature mit mindestens einem JUnit Test zu testen. Für jedes Szenario wird eine Testmethode geschrieben, die die textuelle Szenariobeschreibung im JavaDoc enthält. Außerdem soll aus dem JavaDoc für die Klasse ersichtlich sein zu welcher Anforderung aus dem Anforderungsdokument sie gehören (Referenz auf das Kapitel).

Die Kommentare im Quellcode sollen wie heute in der Vorlesung gezeigt die einzelnen Schritte kurz erklären.

In jedem Release werden die Kunden die ausführliche Dokumentation eines bestimmten Features wünschen. Die Ausführlichen Features sollen in einem technischen Handbuch Dokumentiert werden und enthalten neben Anforderungsbeschreibung und textuellen Szenarien auch Objektdiagramme mit Start- und Endsituation zu den Szenarien, aus den Objektdiagrammen abgeleitete Klassendiagramme sowie ein einleitendes Kapitel zur Architektur mit einem Komponentendiagramm. Außerdem muss ein Hinweis / Link auf die relevanten JUnit tests vorhanden sein, sowie die Ergebnisse der Code Coverage und JavaDoc angesprochen werden. Die Kapitelstruktur sollte sich an folgenden Vorschlag halten:

0. Startseite mit Kontaktinformationen wie beim Anforderungsdokument
1. Einleitung
2. Architektur
3. Schlüsselanforderungen
3.1 Login
3.2 KI Architektur
3.3 <To be announced>
3.4 <To be announced>
4. Glossar

Im ersten Release ist die ausführliche Dokumentation des Login gefordert. Im zweiten Release ist die ausführliche Dokumentation der KI Architektur gefordert. Die ausführlich zu Dokumentatierenden Features der nächsten Releases werden noch bekanntgegeben.

Ab Montag, den 23.11. erwarten wir von jedem Scrum Master die Erstellung eines täglich aktualisierten Burn Down Charts.  Um das Vorankommen des Teams zu visualisieren soll täglich bis 24h ein PDF erstellt werden, das auf der ersten Seite das Diagramm für den aktuellen Sprint zeigt und auf den nachfolgenden Seiten die Tabelle die dem Diagramm zugrunde liegt. Falls der Scrum Master ein Teammitglied nicht erreichen konnte trägt er die Kontaktversuche mit Uhrzeit ein: Mail / IM / Phone …

Die Diagramme könnte ihr mit Google Text & Tabellen, OpenOffice, Excel, Latex oder sonst irgendwie erstellen, als Abgabe ist aber ein PDF gefordert.

Das PDF ist im CVS unter “pfad/zur/doku/BurnDownChart.pdf” einzuchecken. Die Teammitglieder und Betreuer können so täglich erkennen wie weit die Gruppe ist.