Kurskrav

Bemöda er om språket!

Vi vill att ni skall vara väldigt noga med de dokument ni producerar; kontrollera inte bara stavning, utan även språkbruk. Eliminera onödiga eller märkliga anglicismer. Skilj på skriftlig och talad svenska! Lägg också vikt vid att inte särskiva. Skriv "klassdiagram" och inte "klass diagram", "projektdokumentationsansvariguppgift" och inte "projekt dokumentations ansvarig uppgift".

Vi kommer att kritisera upplägg, meningsuppbyggnad och annat i mån av tid och humör i all dokumentation. Dåligt skriven dokumentation blir underkänd. Rest på svenskan handlar inte om att rätta stavfel utan att göra en kompletterande uppgift. På hemtentan underkänner vi svar som inte uppfyller våra språkkrav. På hemtentan tar vi naturligtvis speciell hänsyn till nysvenskar som inte skall behöva lida för SFI-utbildningens sönderfall. På hemtentan accepterar vi också engelska som språk.

En lista över svenska datatermer finns på http://www.nada.kth.se/dataterm/ .

Spårbarhet

På varje dokument som lämnas in skall det klart och tydligt framgå vem som gjort vad (och vid behov även procentuell fördelning). Ange klart och tydligt i dokumentet vem som skrivit vilka delar. Detta skall anges i en egen bilaga sist i dokumentet. Det är naturligtvis tillåtet att samarbeta om en och samma del. För Javakod gäller att @author-taggen skall vara definierad för varje klass och innehålla namn och epostadress för samtliga gruppmedlemmar som varit inblandade i programmeringen av den aktuella klassen. Om arbetsfördelningen mellan programmerarna av klassen har varit någolunda jämn behöver ni inte ytterligare precisera vem som gjort vad.

Underkänd på kursen (d.v.s. man måste gå om kursen) kan man bli p.g.a stor frånvaro eller liten arbetsinsats. Är man sjuk i några dagar och inte hinner ta igen detta under kursen innebär detta i regel en individuell restuppgift (se ovan). Om man inte aktivt deltar i grupparbetet t.ex. p.g.a. långvarig sjukdom blir man i regel underkänd på grupparbetesdelen eftersom en viktig aspekt är just samarbetet med gruppen och de problem som uppstår under ett programutveckligsprojekt i grupp. Närvaro på seminarierna är obligatorisk.

Frågor om timredovisning och kurskrav ställs till kursansvarig.

Granskning och testning

För att säkerställa kvaliteten hos er produkt är det nödvändigt att genomföra en eller flera validerings- och verifieringsprocedurer. Att både granska och testa alla delar av systmet på olika nivåer vore naturligtvis det bästa men är i praktiken omöjligt.

Ett absolut minimum när det gäller validering och verifiering är att ni testar:

• 1. De gruppgemensamma delarna (d.v.s. tjattstandarden) och dessas gränssnitt mot resten av applikationen.
• 2. Meddelandesändning och -mottagning på låg nivå, d.v.s., att interaktionen med servern är korrekt, att inga otillåtna meddelanden tas emot eller skickas, att inga meddelanden slarvas bort, etc.

Observera att ovanstående formuleringar är ganska vaga och att ni verkligen klart och tydligt måste specificera exakt vad som skall testas -- annars vet ni inte när ni är klara!

Junit
JUnit är ett ramverk för enhetstestning av javakod. Vill ni automatisera era tester (vilket ni bör vilja...) är det det verktyg vi rekomenderar. Det finns gott om tutorials på nätet, men tyvärr relativt lite om JUnit 4, den aktuella versionen som nästan helt skiljer sig från de tidigare. För att ni ska få en översikt över JUnit 4 så har vi därför satt samman en kort presentation av verktyget här.
Om ni vill är det självklart ok att använda JUnit 3, det spelar ingen som helst roll vad kursen anbelangar. Användning av JUnit är inte obligatorisk, bara starkt rekomenderad.

Uppgiftskrav

Projektplanering

Varje grupp skall använda sig av Redmine (alla studenter kommer få inloggningsuppgifter via mail) för att hålla gruppen och kursansvariga uppdaterade om hur arbetet fortskrider. All tid ska loggas i verktyget och det bör framgå precis vad gruppen jobbar med just nu och vad som planeras längre fram.

Observera att det inte bara är projektledarens uppgift att hålla uppgifterna uppdaterade, utan alla gruppmedlemmar måste själva se till att deras tid loggas och att uppgifterna stämmer.

Här kan du läsa mer om Redmine.

Daily builds

Varje dag skall systemet kompileras till en körbar version (som inte nödvändigtvis måste fungera felfritt). Den senaste versionen skall alltid finnas tillgänglig på gruppens hemsida liksom en kort sammanfattning av vad som skiljer den från gårdagens version. Det skall alltså vara möjligt för utomstående intresserade att följa arbetets fortskridande.

Användning av bandbredd

Ett krav från kund är att inte slösa på bandbredd! Eftersom många klienten kan tänkas vara uppkopplade samtidigt är det viktigt att programmen hushålla(/e)r med bandbredd. Om ni har en loop som frågar efter ny post på servern är det viktigt att den pausar mellan varje förfrågan etc. Använd ert sunda förnuft. Ett system som konstant utbyter meddelanden med servern kommer att underkännas. Jämför med hur man i en vanlig epostklient kan ställa in t.ex. "Hämta nya brev varje minut, var 5:e minut, etc."

Samarbete mellan grupperna

Tjattstandardisering

Det tjattprotokoll som används skall vara samma för alla klienter, d.v.s., alla gruppers klienter skall kunna tjatta med alla andra gruppers klienter. Det finns naturligtvis inget på förväg fastslaget protokoll för hur tjatterna skall gå till, utan alla grupper får istället komma överens om detta. Vi kommer att tillhandahålla en inledande mötesplats för ett första "tjattstandardiseringsmöte", och därefter får standardgruppen själv begära mer resurser i form av möteslokaler etc. Det meddelande som skickas mellan klienterna för tjatt har en tom "slot" där ett Object kan skickas med -- alltså kan man skicka med ett godtyckligt objekt. Det finns en fallgrop här som har med klasserna i serverns CLASSPATH att göra.