TDDC74: Projekttitel

Transkript

1 TDDC74: Projekttitel Projektmedlemmar: Namn Efternamn Namn Efternamn Handledare: Handledarnamn eller 15 maj

2 Innehåll 1 Projektbeskrivning och användarguide Kort projektbeskrivning Användarmanual Teknisk beskrivning Översiktlig skiss Filer Datatyper eller klasser Algoritmer Avstämning av krav Kravlista Uppföljning kravlista Betygsambitioner Utvärdering av arbetet Utvecklingsmetodik Testning Grov tidplan Tidsåtgång och arbetsfördelning Tips till framtida studenter

3 OBS! Detta dokument innehåller bara beskrivningstexter. Mycket av er rapport kommer att kunna klipp-klistras eller uppdateras direkt från projektspecen. Se till att det ni lämnar in faktiskt svarar mot koden som lämnas in, och inte något tidigare utvecklingsskede. Notera att detta inte så mycket är en teknisk rapport som en projektrapport. När det finns en risk för att sväva ut i de tekniska beskrivningarna, håll tillbaka det. Detta ska inte vara en 20s-rapport, utan ska ge en korrekt och tillräcklig översikt! Läs igenom det hela i förväg. 1 Projektbeskrivning och användarguide Ge en kort inledning till projektet (vad är det för spel, vad går det ut på,...). Det ska vara kort och koncist men ge en tillräcklig förklaring till vad spelet går ut på. 1.1 Kort projektbeskrivning Här beskriver ni vad det är ni har skrivit, i korthet. Det här kan nästan tas direkt från projektspecen, men se till att det är en riktig rapportbeskrivning. Om ni skrivit ett spel, ge en lite mer genomgående förklaring av spelet och hur det spelas. Om ni gör ett äventyrsspel, inkludera en kort historia till spelet. Eventuella regler för spelet är även bra att förklara kortfattat, och praktiska informationslänkar bifogas. 1.2 Användarmanual Hur använder man ert program? Hur startar man det? Om ni gör ett spel, beskriv hur man startar det och spelar. Bifoga gärna kortfattade spelregler. En person som får denna text, samt er kod (och eventuella kringfiler modell bilder) ska kunna köra spelet, skriva ert egenutvecklade programspråk, använda ert medicinska beslutsstödssystem, eller vad som nu är aktuellt. 3

4 Lägg gärna in faktiska skärmbilder, om det är relevant. 2 Teknisk beskrivning Det här kapitlet använder ni för att beskriva hur spelet är strukturerat och implementerat rent kodmässigt. Tanken är att en läsare som inte sett projektet förut ska kunna sätta sig in i koden. Tänk er att ni ger koden och rapporten till en annan projekthandledare, som inte har möjlighet att ställa frågor till er. Då ska hen förstå strukturen. Det är viktigt att beskrivningen här är korrekt och uppdaterad (det är delar där man kan utgå från projektspecen, men se till att det faktiskt stämmer med den inlämnade koden). 2.1 Översiktlig skiss Vilka viktigare delar finns det i programmet? Hur kommunicerar de med varandra? Var finns relevant data (till exempel speltillstånd). Detta ska vara översiktligt! Man ska - för att ta ett exempel från labb 5 - snabbt kunna få reda på saker modell att användaren skriver kommandon i ett adventure-ui%-objekt, kommandon tas ur en tabell, att merparten av beteende och data ligger hos separata objekt. Som i projektspecen, notera att ni inte behöver ha exakt dessa rubriker. Om ni inte gör ett objektorienterat spel, är det dåligt att försöka göra en objektmodellering. Om det inte är relevant att ha med ett algoritmavsnitt - ha inte det! 2.2 Filer Om det finns någon riktig stuktur på detta, är det värt att kunna spalta upp vad de olika filerna innehåller ( {item, character, place}.rkt innehåller klassdefinitioner, player_commands.rkt kommandon..., eller dylikt). Gör förslagsvis en överskådlig tabell eller en punktlista. Ni behöver inte ha en 4

5 uttömmande uppräkning av allt som finns i filen. Läsaren ska mest förstå var den ska börja leta. 2.3 Datatyper eller klasser Om ni skulle beskriva labb 5 här, skulle ni lämpligen först beskriva det på nivån vilka sorters klasser det fanns ( character%...), vad för data de innehöll (karaktärer vet saker som sin plats, vilka saker de bär på, och viss information modell sitt namn) och vad för ansvar de har (ansvar för att sköta allt kring flyttande exempelvis). Ge en kort beskrivning för varje klass. Beskriv gränssnittet för varje klass (tänk tabellerna i labb 5-beskrivningen, med kommando, argument och vad de gör). En snabb koll efter (define/public...) bör underlätta här - det är ju metoderna definierade så som exponeras utåt. 2.4 Algoritmer Här beskriver ni ev algoritmiska problem som ni behövt lösa, och beskriver lösningen översiktligt. Detta kan handla om öppnande av rutor i Minröjspel, vägfinnande i kartor i ett äventyrsspel, eller i princip hela projektet om man gjort logiska resolvers eller AI. Har du gjort ett algoritmtungt projekt, beskriv algoritmerna i egna ord. Alla kan hitta pseudokod för t ex Dijkstras algoritm eller Minmax på webben (eller hitta färdig Racket-kod...). Sammanfatta åtminstone grundtanken i det ni använt med egna ord! 3 Avstämning av krav 3.1 Kravlista Detta kopierar ni från godkänd projektspecifikation. Det ska vara exakt samma. 5

6 3.2 Uppföljning kravlista Skriv eventuella kommentarer kring kravuppfyllelsen som kan vara relevanta (fokuserade ni på något särskilt?). Uppfylldes alla SKA-krav? BÖR-krav? Skriv väldigt kortfattat. 3.3 Betygsambitioner Vad hade ni för betygsambitioner? Om ni har ett projekt som kan göras mer eller mindre omfattande, vad är det som motiverar det betyget? 4 Utvärdering av arbetet Här skriver ni kortfattade utvärderingspunkter i relation till projektspecifikationen och tankar ni haft inför arbetet. Ta fram er projektspec. Det kan vara värt att snegla på den. Er text ska dock gå att läsa utan att ha specifikationen bredvid. Vissa av frågorna nedan kan man skriva väldigt långt om. Det väntas och krävs inga långa essäsvar här! Skriv kort och koncist. Det kan vara vissa rubriker som innehåller en-två meningar text. Många är av karaktären hur tänkte vi inför specifikationen - eller tidigt i arbetet, även om det inte skrevs ned - hur blev det, varför. 4.1 Utvecklingsmetodik Hur tänkte ni lägga upp arbetet? Vad fungerade bättre respektive sämre? Vad skulle ni kunna göra för att få det att fungera bättre till senare projekt? 6

7 4.2 Testning Vad för problem har ni stött på som kunnat lösas genom bättre teststrategi? Omvänt, vad för saker gjordes helt i onödan bara för att? 4.3 Grov tidplan Hur såg er tidplan ut inledningsvis? Hur föll det ut? Varför? 4.4 Tidsåtgång och arbetsfördelning Hur såg tidsåtgången åt, och arbetsfördelningen mellan gruppmedlemmarna? Hur lång tid på ett ungefär har det tagit? Vilka veckor gjorde ni vad? 4.5 Tips till framtida studenter Vad för råd, utifrån saker som fungerat bättre respektive sämre, skulle ni vilja ge framtida studenter som väljer samma projekt? (Modell X kommer att ta längre tid än du tror, fråga om Y tidigt, vi körde fast i Z, W var lättare än man trodde, kunde man gjort mer av, det var bra att börja med V, det var kul, vi hade hjälp av att kolla på U eller något helt annat). Tänk på att detta är en rapport som ska lämnas in. Formulera er hjälpsamt, men korrekt. Detta skrivs såklart med baktanken att kunna förbättra projekten och påminna framtida handledare om hinder (inte nödvändigtvis ta bort dem), men också som ett verktyg för att fundera på hur arbetet har gått. En retroaktiv utvärderingsvariant av rubber duck debugging om man så vill. Detta kan ni med fördel göra som en punktlista. 7