Göm menyn

TDDI02 Programmeringsprojekt

Instruktioner: Projekt


Gruppregistrering och projektval

Ni registrerar Er grupp i LUPP. Klass och grupp som ska väljas är i denna kursen samma sak. Det finns 13 "klasser" och varje har en "grupp" om fyra personer. För att undvika strul rekommenderas att ni bildar gruppen först och sedan fyller ni 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. I stort sett "skit samma" i dessa dagar. Förmodligen kommer ni välja använda C++.
  • Att koden mycket är välstrukturerad, förslagsvis objektorienterat.
  • Att en bra kodstil används. Enkel stilguide för C++ finns att tillgå.
  • 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 hela projektet kan kompileras upp med ett enkelt kommando på våra SUN-system.

Missade deadlines

Det går bra att missa en deadline. Det går bra att missa en andra deadline. Missar gruppen dock en tredje deadline får den gruppen en tråkig extrauppgift: Att i slutet av projektet skriva en rapport hur den färdiga programvaran testats, och över resultatet av testningen. Det ingår då att göra tillräcklig testning för att ha underlag för rapporten.

Den som inte tycker om straff kan vända resonemanget till en belöning: Testning och testrapport ingår att göra för alla, med de som håller alla deadlines slipper.

Genomförande

Här följer en sammanfattning av projektets genomförande (från tidigare år). Tanken är att denna när tid gives skall struktureras upp under lämplig rubrik på 2012 års kurshemsida, och en del saker möjligen få lite fylligare informationen eller exempel.

TDDI02 - Idé till genomförande av kursens projekt

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örsta 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 kravspec.

  • Gör, för internt bruk, en tidsplan (för projektet). Det är inte särskilt enkelt, men gör i alla fall ett försök. Denna plan ska ni sen relatera till i er erfarenhetsrapport . Tidsplanen ska struktureras efter deadlines (ung: tidpunkten när en extern leverans ska ske) och milstolpar (ung: tidpunkten när andra, lite omfattande moment, ska vara klara, dvs har godkänts på ett eller annat sätt). Planen innehåller, i tidsordning, en följd av distinkta arbetsinsatser, och för var och en anger man under vilken tidsperiod den ska äga rum, vilka som deltar och hur många mantimmar som förväntas gå åt. Det är rimligt att man också anger hur olika insatser beror av varandra, och/eller löper parallellt. För detta finns diverse diagramformer att använda om man vill (Bar Charts, Gantt, ...). Tidsplanen ska inte redovisas.

  • 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. Obs 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. Var 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å. Obs 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 designspecen om ni vill.

    Om ert system måste ta hjälp av nåt annat system, ett databassystem t ex, ska ni också speca vilket detta skall vara. Vi kräver att ni använder åtminstone något litet programbibliotek.

    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 spec 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örsta 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 moduler eller rent funktionella. Arkitekturen saknar detaljer, men anger vad moduler heter , vad deras övergripande syfte är och 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

    Men innan ni gjort er design klar ska ni - får ni möjlighet att - presentera och ventilera er ide i ett seminarium. Detta ska ge er liten övning i muntlig presentation inom ert fackområde. Men det är också en chans att få impulser 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 efter hand 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!

  • Evaluering/efterstudie - obligatorisk redovisning

    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: Klas Arvidsson
Senast uppdaterad: 2012-09-07