Bildandet av grupper (5-6 personer) överlåts åt kursdeltagarna själva och varje medlem i en grupp behöver anmäla sig i WebReg. Gruppen ska meddelat sin assistent via mail (se "Kontakt med assistent") att gruppen bildats och vilka som ingår i gruppen. Projektgrupper kan bildas över de tidigare labgruppsgränserna. Försök bilda grupper där ni i så stor utsträckning som möjligt har samma ambition och ungefär lika starka kunskaper i C++. Det underlättar era diskussioner och ert samarbete.

För de som söker grupp finns det en grupp i WebReg att anmäla sig till. Du behöver inte känna oro om du inte har en grupp. Kontakta kursassistenten så löser vi det tillsammans.

Vi rekommendera att ni tänker igenom hur ni vill samarbeta och kommer överens om vad som gäller. Gruppkontrakt är ett verktyg för det. Vi ger er här en mall vi försökt hålla kort och samtidigt få med det viktigaste att tänka på.

• Instruktion (pdf)
• Instruktion (Latex) och tillhörande Latex-mall
• Exempelsamling (pdf)

En kravspecifikation ska tas fram. Av denna ska det blivande systemets funktioner klart framgå och användargränssnitt och andra externa egenskaper ska beskrivas. Detta ska vara användarens syn och krav på systemet, dvs vad systemet ska klara, ej hur. Uppdelning kan göras i absoluta krav på det levererade systemet samt tilläggsfunktionalitet, vilken utlovas endast i mån av att det kan utföras inom projektets tidsram.

Kravspecifikationens innehåll

• En försättssida med projektets namn som huvudrubrik, en underrubrik som anger att det är en kravspecifikation (ev. versionsnummer som underrubrik till denna), vidare namnen på projektgruppens medlemmar, datum och år.
• En kort sammanfattning som beskriver dokumentets syfte, det sammanhang som projektet utförs i (kursen), samt dokumentets viktiga beståndsdelar. Bör bestå av ett eller två stycken, omfattande sammanlagt 8-10 rader text.
• Innehållsförteckning
• Dokumentkonventioner. Vad olika teckenutformningar, symboler, etc., som används i dokumentet innebär.
• Beskrivning av spelet:
  • Spelidé: Vad går spelet ut på? Vad gör spelet underhållande att spela? Vad driver spelet framåt?
  • Vilka regler styr spelet?
  • Hur ska spelet se ut? (Ha gärna med en skiss)
• Användargränssnitt. Beskrivning av hur en användare kan kommunicera med systemet (kommandostyrt, grafiskt gränssnitt, etc.)
• Kravformulering:

  Beskriv de uppgifter systemet ska utföra och de problem systemet ska lösa genom krav. Tillsammans ska kraven ge en heltäckande beskrivning av vad spelet är och ska kunna göra.

  Dela upp kraven på funktionalitet i följande tre nivåer:

  Absolut krav

  Något som måste uppfyllas.

  Bör-krav

  Borde finnas med i slutprodukten, men systemet kan fungera utan denna funktionalitet.

  Kanske-krav

  Tillägsfunktionalitet som kan läggas till i mån av tid och intresse.

  Kraven ska numreras enligt något system. Tänk dock på att alla krav ska ha unika nummer (det ska exempelvis inte finnas fler än ett krav med nummer 3). Om ni under projektets gång vill ändra i kraven eller flytta dem är det viktigt att kraven behåller sin tidigare numrering. Annars kommer alla andra dokument som refererar till kraven via nummer att referera till fel krav.

• Lagring av permanenta data.

  Använder systemet lagring på fil för vissa data och/eller sparar systemet data på fil mellan körningar av programmet. Beskriv hur data (ska) lagras på fil.

• Beskrivning av begränsningar som systemet har, t.ex. fall som ej hanteras och andra undantag.

Kravspecifikationens utformning

• Komplett - all funktionalitet beskrivs.
• Klar och koncis.
• Läsbar och välstrukturerad.
• Angivna krav måste vara testbara.
• I princip fri från diskussion om implementering av systemet

OOA genomförs med utgångspunkt från kravspecifikationen. Analysen dokumenteras med objekt- och klassdiagram.

En mer djupgående läsning om stegen i att ta fram en OOA kan göras i dokumentet Objektorienterad programutveckling i ett nötskal under rubriken "Objektorienterad analys".

(Värt att notera: En väl genomförd OOA framhålls genomgående i tidigare års studenters erfarenhetsredovisningar som synnerligen viktigt för att projektet kunnat genomföras framgångsrikt och i tid.)

Följande ska finnas med i det mycket förenklade analysdokument som varje projektgrupp ska lämna in:

• Försättssida

  Projektets namn används som huvudrubrik. En underrubrik som anger att det är ett analysdokument (ev. versionsnummer som underrubrik till denna). Vidare namnen på projektgruppens medlemmar, datum och år.

• Innehållsförteckning

• Klassdiagram

  Ett eller flera klassdiagram som ger en övergripande bild av de klasser som ingår i systemet och hur de är relaterade.

• Klassbeskrivningar

  För varje klass ska en kort beskrivning finnas och som redogör för syftet med klassen. En beskrivning kan vara CRC-kortsinformation och lite textuell beskrivning tillagd.

• Användningsfall/scenarion

  Lista de användningsfall som har hittats. (Ett användningsfall är en interaktion som kan inträffa under systemets exekvering)

Git ska användas av alla medlemmar i gruppen och genom hela arbetet med projektet. Detta är ett krav då det är vår enda möjlighet att bedöma om du har varit delaktig i utförandet av projektet. Att var aktiv innebär att ha genomfört commits som bidrar till implementationen av projektet. Ett krav för att bli godkänt är att commit-meddelanden inte är tomma, opassande eller bara en ansamling av osammanhängande bokstäver, exempelvis "askjad".

OBS! Ett repository för projektet kommer att skapas på Gitlab av kurspersonal och alla blir därefter inbjudna till projektet. Detta är för att säkerställa att projekten har rätt inställningar.

Vid inlämning skickas ett mail till er assistent med en länk till ert git-projekt på Gitlab. En mer detaljerat beskrivning finns under det obligatoriska momentet Kodinlämning.

Allt som ligger i ert repository (projektet på Gitlab) vid inlämning kommer att bedömas. Se därför till att ha tagit bort allt som inte är en del av det färdiga spelet. (Undantag för dokument som kravspec. och OOA ifall de laddats upp)

Syftet med avstämningsmötet är att fånga upp om projektet är på rätt spår för att bli godkänt. Projektgruppen har själva ansvar att kontakta assistenten för att boka in mötet. Tänk på att vara ute i god tid, för att garantera att ni kan träffas i v47-49, och skicka gärna med förslag på flera tider i mailet.

På mötet kommer följande att diskuteras:

• Vilka krav som är uppfyllda.
• Vem i gruppen som gjort vad.
• Vilka problem gruppen stött på och vad gruppen gjort för att lösa dem.
• Vad gruppen ska arbeta med under varje av de resterande veckorna, prioriteringar som kan behöva göras och vem som ska göra vad.
• Vilka möjliga problem som kan uppstå under resterande veckorna och vad gruppen kan göra för att undvika dem.

OBS! Halvtidsavtämningen är ett ypperligt tillfälle att genomföra bonusuppgiften "Leda ett projektmöte med assistent".

Ett redovisningspass är schemalagt i timeedit. På passet kommer alla grupper ta fram sina spel och det finns en möjlighet att gå runt och se vad andra har gjort under projektet - och förhoppningsvis spela lite! Detta är en höjdpunkt i slutet av terminen.

Er assistent kommer att testa ert spel och gå igenom er kravspecifikation för att se att den är uppfylld. Assistenten kommer också komma att ställa frågor kring hur du implementerat just din del av ert spel. Efter detta ger assistenten grönt ljus att genomföra en kodinlämning.

Det är möjligt att redovisa innan det schemalagda passet. För att de ska vara möjligt behöver assistenten kontaktas i god tid innan för att ett datum som passar både assistent och gruppen.

När redovisning genomförts ska gruppen lämna in sin kod genom att skicka ett mail till assistenten med en länk till ert projekt på Gitlab. Mailet ska vara utformat enligt följande:

    To: 
      CC: LiU-ID@student.liu.se för samtliga projektmedlemmar
      Subject: TDDC76-Grupp-XX: Kodinlämning
      Content:
      [Ska som minst innehålla en länk till ert projekt på Gitlab.]
  

Var noga med att ert spel går att starta genom att (1) klona ert projekt (2) gå in i projektmappen och skriva "make" (3) starta spelet genom att skriva "./play" (testa sekvensen i ny tom mapp!)

Det är i projektet okej att använda sig av CMake för att generera en Makefile, fast går självklart precis lika bra att skapa en egen Makefile för hand.

Rapportens syfte och innehåll

Detta dokument ska ni skriva för att få anledning att begrunda den process ni gått igenom, samla ihop de tankar den givit upphov till, och summera erfarenheter som kan ligga till grund för framtida projekt/verksamhet. Rapporten i sin helhet ska vara ett par A4-sidor.

Relatera till den tidsplan ni satt upp, eller de förväntningar ni med all säkerhet haft. Reflektera annars om hur en bättre planering kunde undvikit några problem ni haft eller hjälpt er på annat sätt.

Gå igenom projektets olika faser (krav, analys, implementation, resultat), en i taget. Skriv ner hur er plan sett ut, och huruvida ni lyckats hålla er till den eller ej. Analysera orsakerna till att ni eventuellt blev sena, och beskriv hur ni löste de problem ni stötte på. Eller tvärtom; av vilket skäl gick det bättre än ni förväntat er? Blev slutprodukten från denna fas bra nog för att ligga till underlag för nästa fas, eller inte? Vad bestod dess brister i? Vad kunde gjorts bättre, sett ur det perspektivet?

Blev slutprodukten vad ni från början hade hoppats? Vilka faktorer bidrog till att det gick som det gick?

Slutligen ska varje gruppmedlem för sig (ange vem!) beskriva den allra viktigaste personliga erfarenheten/kunskapen som projektarbetet bidragit till, och som säkerligen kommer till nytta i kommande programmeringsprojekt (eller vidare yrkesliv).

Sammanlagt ska detta bli minst 8 erfarenheter, individuella och gemensamma sammanräknade.

OBS! Dokumentet är INTE en kursutvärdering, utan en samling arbetserfarenheter som är värda att komma ihåg till nästa projekt ni är med i. En form av självutvärdering. Vi värderar studenternas åsikter om kursen högt och en kursutvärdering kommer att genomföras. Har ni synpunkter på kursen kan ni dessutom lämna dem separat till examinator.

Vad räknas som en dokumenterad erfarenhet?

Att skriva ned sina erfarenheter kräver lite eftertanke. Det gäller att skriva ned tillräckligt för att en oinsatt läsare skall kunna dra nytta av erfarenheten i ett eget projekt. Det bör för varje erfarenhet framgå:

• Hur ni gick tillväga, vad ni gjorde, hur ni gjorde, och varför ni valde den metoden?
• Vad resultatet blev, om tillvägagångssättet ledde till något positivt eller negativt?
• Varför ni är nöjda eller missnöjda med resultatet och varför det blev som det blev?
• Hur det kommer påverka hur ni närmar er en liknande situation i framtiden? Det vill säga, vad blir det långsiktiga lärdommen från detta?

Exempel på en intetsägande "erfarenhet": "Versionshantering via Git har fungerat mycket bra och hjälpt alla utvecklare i projektet."

Exempel på en bättre formulerad erfarenhet: "Vi använde versionshantering via Git. Detta hjälpte alla utvecklare hålla reda på senaste versionen och underlättade distributionen av färdiga moduler mellan utvecklarna. Vid två tillfällen kunde vi snabbt hitta fel som uppstod tack vare historiken. Ett problem var att kod som inte fungerade checkades in vid flera tillfällen och det slarvades även med att kommentera vad som checkades in. Detta gjorde att utvecklare spenderde onödig tid på felsökning. Vi borde kommit överens om att bara checka in testad och fungerande kod, men ändå ofta, en modul i taget. I framtida projekt kommer vi försöka använda versionshantering, med ett gruppkontrakt där vi kommer överens om att bara checka in fungerande kod för att underlätta samarbetet."

Döm själv vad som saknas i de två exemplen enligt punkterna ovan. Döm själva vilken ni helst skulle vilja läsa i förberedelsefasen för ett projekt.