Kursplanering, VT13

Kursplanering Planering HI1028, Projektkurs inom programvaruutveckling, VT13.pdf

Notera att

* Kravhantering, funktionella och icke-funktionella krav redovisas via en obligatorisk övning måndag 18/3.
* Projektmetodik redovisas genom en inlämningsuppgift kopplad till boken ”Agil projektledning” den 24/3, samt deltagande i obligatoriska seminarier den 25/3.Inlämningsuppgiften, som skrivs enskilt, ska innehålla en sammanfattning av boken på max 3 sidor samt en reflektion över hur denna metodik kan implementeras i ditt projekt på max 1 sida (totalt 4 sidor). Inlämning senast söndag 24/3, 16:00, via Bilda. På förekommen anledning: Texten ska vara skriven med 11 punkter, enkelt radavstånd.

Gruppens webbsida Följande ska finnas dokumenterat på, eller via länkar från, gruppens webbsida.¶


* Kontaktuppgifter till uppdragsgivaren
* Kravspecifikation från uppdragsgivaren
* Product backlog med mål/funktionalitet i prioriterad ordning. Dokumentet får uppdateras under projektets gång men alla versioner måste finnas tillgängliga
* Gruppens arbetsschema som visar på alla hel- och halvdagar då gruppen arbetar med projektet under perioden. Sprintplaneringar och ”sprint reviews” ska vara schemalagda (med lokal angiven). Varje arbetsdag ska börja med ett stå-upp-möte, ”daily scrum”
* Sprint backlog, uppdelad i tidsuppskattade aktiviteter med ansvarig angiven
* En representation av hur arbetet fortskrider under sprinten i form av aktiviteter grupperade under rubrikerna ”to do”, ”in progress” och ”done”. Denna information ska uppdateras vid början av varje arbetsdag (efter "daily scrum"). Om ni använder en fysisk tavla, fotografera och publicera bilden
* Personliga tidrapporter; varje post ska ha motsvarande aktivitet angiven. Uppdateras varje fredag (scrum master kontrollerar att detta görs)
* Länk till repository på versionshanterare
Rapporten, presentation, film Rapporten Se kurs-PM samt nedanstående dokument.Projekthandbok, KTH STH, 2011-12Om rapportskrivning

En kommentar om kod i rapporten:Det är ok med korta kodavsnitt om de kan anses beskriva någon del av lösningen som är mycket kodspecifik och är svår att beskriva på annat, mer generellt sätt (notera att det oftast finns bättre sätt att beskriva). Notera också att om ni vill ha in mycket kod i rapporten kan det vara ett tecken på att ni försöker beskriva lösningen alltför detaljerat.

Är det fråga om större kodstycken ska ni förmodligen ge en översiktlig beskrivning istället; med hjälp av text, diagram (ex. UML) eller liknande. Är det fråga om att beskriva algoritmer bör ni använda er av pseudo-kod.

Presentationen Se kurs-PM

Film Exempel från liknande projekt (årskurs 3) kommer snart...

Redovisningsdagen, 25/5 Information om redovisningsdagen, tider m.m. (kommer...)Glöm inte att första versionen av rapporten ska lämnas in via Bilda samt till opponerande grupp senast 15/5.