Göm menyn

TDDI02 Programmeringsprojekt

Instruktioner: Projekt


Gruppregistrering och projektval

Ni registrerar er grupp i webreg. Det är tillåtet att bilda grupper med medlemmar ur olika klasser. För att undvika strul rekommenderas att ni bildar gruppen först och sedan fyller i alla fyra namn på en gång. De som inte riktigt får ihop till fyra medlemmar registrerar sig på den grupp med färst (motsats till flest, se SAOL) antal medlemmar. Grupper om fem eller fler accepteras aldrig. Grupper om färre än fyra delas upp och sprids ut på andra grupper med för få medlemmar. Uppstår därvid en ensam grupp med färre än fyra medlemmar förs medlemmar över från 4-grupper tills alla grupper har 3 eller 4 medlemmar.

Krav på kod och programspråk

Kraven som ställs på kod och programspråk är:

  • Att du använder ett tredje generationens programspråk, d.v.s. C++, Java, Ada etc. är i stort sett "samma sak" i dessa dagar. Förmodligen kommer ni välja att använda C++.
  • Att koden är mycket välstrukturerad, förslagsvis objektorienterad.
  • Att en bra kodstil används. En konsekvent stil ska följas av samtliga gruppmedlemmar.
  • Att koden är självdokumenterande, alltså att kommentarer och namngivning räcker för att förstå kodens funktion och hur den passar in i projektet.
  • Att ni använder åtminstone ett externt bibliotek, exempelvis SFML, SDL, Qt, MySQL, SQLite, ENet, Box2D.

Handledarmöten

Ni ska ha ett kort möte med er handledare i veckan. I samband med detta möte ska ni:
  • Förmedla status via Kernel Alphas
  • Rapportera individuella workitems i ett e-mail från gruppen till handledaren. Ungefärligt format: Vad som gjordes - av vem - tidsuppskattning. Använd gärna ett verktyg för detta, exempelvis Toggl eller annat som kan exportera hela gruppens tider till en pdf-fil.
Om ni av någon anledning inte kan boka ett möte med er handledare en vecka ska ni kontakta handledaren i god tid och försöka komma överens om en lösning. Att utan varning utebli från möten eller låta bli att boka möten jämställs med att ha missat en deadline.

Genomförande

Här presenteras ett lämpligt sätt att gå tillväga med projektet, indelat i några punkter. Dessa är inte helt tidsordnade, notera det! Några av punkterna innebär obligatoriska moment (som examineras), och där anges i grova drag de krav som examinationen ställer.

Alla de dokument ni ska redovisa ska ha ett genomgående enhetligt utseende och format, med lätt identifierbara försättsblad. Detta ska bl.a. ange gruppens nummer och deltagarnas namn.

  • Ni måste starta med att sätta er in i problemet/uppgiften ganska noga - vad vill ni att systemet ska kunna uträtta åt er (eller nån annan). Ni måste förstå sammanhanget där det ska användas och dess totala funktionalitet. Tänk er t ex in i olika situationer, och spela upp användningsfall. Utan denna tämligen djupa förståelse kan man inte göra en kravspecifikation.

  • Projektplan - obligatorisk veckovis redovisning under handledarmöte

    Gör en projektplan innehållande en tidsplan för projektet. Denna plan ska ni sen relatera till i er erfarenhetsrapport. Tidsplanen bör struktureras så att ni har ungefär en milstolpe per deadline i kursen (ej inräknat hemtentornas deadlines). Den uppdateras löpande, ni behöver alltså inte planera hela projektet dag ett. Detta är till för att ni ska få en bättre uppfattning kring hur ni ligger till sett till var ni borde ligga till under projektets gång.

  • Kravspecifikation - obligatorisk redovisning

    Det krävs inte att ni gör en fullständig kravspecifikation, men några väsentliga delar av en sådan ska ni framställa. Det krävs att ni dels beskriver systemets funktionella krav, dels de övergripande kraven på användargränssnittet och dels om systemet kräver något annat stödsystem. Observera att en kravspec på många punkter uttrycker sig i tvingande ordalag.

    De funktionella kraven är en lista på alla de händelser som användaren kan trigga. I var och en beskriver man uppgiften i stora drag, vilken påverkan på systemet/dess data den medför, vilken form av respons som ska ges och särskilt vilka eventuella felkontroller som genomförs och vad som då ska meddelas. Denna lista skulle kunna struktureras upp i händelser av olika kategorier, för att göra det hela mer överskådligt. De funktionella kraven ska dock på den yttersta nivån delas upp i skall-krav (som man inte kan strunta i) och bör-krav (som man kan ignorera om tiden inte räcker), och kanske ytterligare en nivå. Observera att funktionella krav bara ger uttryck för vad användaren upplever .

    När det gäller gränssnittet ska ni här specificera dess allmänna karaktär och layout (fråga- svar, textbaserat, ...). Det är också möjligt att i detalj-speca utseendet av varje konversation, men ni kan skjuta upp det till designspecifikationen om ni vill.

    Om ert system måste ta hjälp av nåt annat system, ett databassystem t ex, ska ni också specificera vilket detta skall vara.

    Kravspecen ska dessutom ha en aldrig så liten inledning, som presenterar den miljö och den användarkategori systemet är avsett för.

  • Designspecifikation - obligatorisk redovisning

    Ni ska också redovisa en designspecifikation, dvs den ritning som man sen kodar systemet efter. Denna specifikation kan behöva ha fyra delar, kanske flera, men minst två. Det man främst ägnar sig åt under konstruerandet är att av kravspecen förstå vilka datamängder/- strukturer man behöver och hur systemet ska delas upp i komponenter, lämpliga till storlek, antal och funktion.

    Den första delen är vad man kan kalla systemets arkitektur. Den visar på ett övergripande sätt de större beståndsdelar man delar in systemet i, och hur dessa samverkar. Beståndsdelarna - modulerna - kan t ex vara klasser av olika slag, eller i språk som saknar det begreppet, databärande eller rent funktionella moduler. Arkitekturen saknar detaljer, men modulerna namnges, deras övergripande syfte beskrivs, och också på vilket sätt moduler använder varandra.

    Den andra delen utgör en mer detaljerad specifikation av varje modul för sig; man kallar den för (lågnivå) moduldesign eller modulkontrakt. Den ska ge all den information som behövs för att andra delar av systemet ska kunna använda modulen, så att - i princip - andra modulers kod skulle kunna skrivas innan den som specas faktiskt finns! För varje modul behöver t ex följande specificeras: dess uppgift i allmänna drag, vad den (eventuellt) gömmer för data i abstrakt mening, hur dess ingångar (t ex metoder) används/anropas och vilken funktionalitet detta innebär, vad för effekter eller åtgärder utanför systemet (bl a I/O) som åstadkoms. De slutliga namnen på (synliga) beståndsdelar (metoder, parametrar, ...) brukar också fastslås här.

    Användargränssnittet, i alla dess detaljer, skall också specas i designen, om det inte skett i kravspecen. Det gäller då både användarens input och systemets output, för alla tänkbara fall.

    När ert system utnyttjar andra system som stöd kan vissa designbeslut också behöva tas. Kanske det kan gälla gränssnittet eller uppbyggnaden av en databasstruktur ni önskar. Detta blir i så fall särskilda kapitel i designdokumentet.

  • Designpresentation med opposition - obligatoriskt

    Innan ni gjort er design klar ska ni - får ni möjlighet att - presentera och ventilera er idé i ett seminarium. Detta ska ge er en övning i muntlig presentation inom ert fackområde. Men det är också en chans att få respons från åhörarna, era kursare, innan ni slutligen bestämmer er. Det är också meningen att en annan grupp i förväg studerat er design och nu kommer med synpunkter på den, positiva som negativa. Förhoppningen är att en liten diskussion ska utbryta.

    Designen använder ni sen som underlag för att koda, och efterhand testar ni mot kravspecen att koden uppfyller dess krav! Mer behöver väl inte sägas här - ni vet ju hur man kodar snyggt, och vad rigorös testning innebär.

  • Användarhandledning - obligatorisk redovisning

    Det krävs också en liten användarhandledning, och en sådan är det tredje dokument ni ska redovisa. Det är kanske inte så klokt att vänta till efter implementationen med att skriva handledningen; all information som krävs finns ju redan i och med krav-/designspecifikation! Men en manual måste skrivas på ett lite annorlunda sätt än övriga dokument. Dessa vänder sig ju till dataspecialisterna och tillåts innehålla mycket fackspråk. Manualen har en helt annan publik, vilket kräver ett helt annat språk, och måste dessutom vara pedagogiskt och systematiskt upplagd. Det är inte så lätt...

  • Systemdemonstration - obligatoriskt

    Systemet ska till sist levereras och överlämnandet sker genom att ni genomför en demonstration. Ni ska då föreställa er att det är de tänkta användarna som är åhörare, och detta ställer också krav på er pedagogiska ådra, ert ordval och strukturen på sessionen. Demonstrationen ska visa att kravspecifikationen uppfyllts!

  • Reflektionsdokument/efterstudie - obligatorisk

    Varje projekt ger lärdomar inför framtiden, vare sig det var lyckat eller inte. Ni ska efter avslutat projekt skriva och redovisa en liten erfarenhetsrapport. Berätta i den vad som gick bra, vad som gick dåligt, vad som var lättare/svårare än väntat, hur tidsplaneringen höll och vilken orsak det ena resp det andra kan tänkas ha. Relatera dels till den tidsplan ni gjort upp inledningsvis, dels till vad ni fakiskt förväntade er. Ge några anvisningar till er själva om hur ni bör gå tillväga i liknande situationer i framtiden.


Sidansvarig: Filip Strömbäck
Senast uppdaterad: 2017-06-26