Göm menyn

Projektuppgift

Att göra: Anmälan i Webreg

I projektet delar vi upp oss i 4 nya "storgrupper", där D1/kogvet samlas i tre av grupperna och U1 har en egen grupp. Man får givetvis även samarbeta över klassgränserna, men eftersom detta har varit väldigt ovanligt har vi nu gjort en uppdelning som ger bättre schemaläggning och färre sena kvällstider (kan lägga en Java-labb för U1 parallellt med en annan aktivitet för D1).

Att arbeta i par kan ha många fördelar, så vi och många tidigare studenter rekommenderar det. Man kan även arbeta enskilt om man föredrar eller inte hittar en partner. Vi tar självklart hänsyn till detta i bedömningen, men tänk på att pararbete inte innebär att två personer gör varsin halva utan kommunikation. Alltså kan den som arbetar enskilt inte nöja sig med att nå hälften så långt.

Större grupper än två är inte tillåtna.

Anmäl er i WebReg3. Om det är fullt, kontakta examinatorn.

Regler: Grupparbete sker i grupp!

Även när man arbetar i grupp måste man utvecklas individuellt. Den ena personen i gruppen får inte skriva det mesta av koden "för att det skall gå fortare". Ni ska båda göra ungefär lika stor del av både design och kodning, och båda ska vara fullt insatta i hur saker fungerar.

Om ni arbetar separat på vissa delar av koden måste ni därför regelbundet (gärna varje dag) gå genom den kod som skrivits och diskutera hur den fungerar. Denna informella code review är inte tidsslöseri utan ett utmärkt sätt att både lära sig av andra och hitta problem i programkoden innan det är "för sent"!

I verkligheten krävs i många projekt att all ny kod verifieras på detta sätt innan den överhuvudtaget får integreras i kodbasen.

Steg 1: Förstå krav och kriterier

Det första steget i projektet är att förstå vilka krav som gäller för samtliga projekt och vilka kriterier som ni måste uppfylla för vissa betyg. Detta kan påverka hur ni ska bygga upp ert projekt. Läs därför bedömningssidan.

Missa inte detta, annars kan ni få mycket extrajobb på slutet!

Kontrollera vad som ska ingå i dokumentationen, och fyll på den kontinuerligt – senare kan det t.ex. vara svårt att minnas designbeslut man gjorde. Många studenter har rapporterat exakt detta!

Steg 2: Val och beskrivning av projekt

Syfte

Innan ni börjar behöver ni själva välja vilket projekt ni vill utföra. En projektbeskrivning måste sedan skrivas och lämnas in till labbhandledaren, helst innan projektstart (det går bra att skriva på svenska). Syftet är:

  1. Att ni ska tänka genom implementationen i förväg. Många studenter anser att man har tjänat mycket på detta steg.

  2. Att er handledare ska kunna ge feedback om det är större problem med den valda inriktningen. (Mindre detaljer är svåra att kommentera eftersom mycket beror på era förkunskaper och exakt hur ni går tillväga.)

Vid slutinlämningen ska även en uppdaterad version av projektbeskrivningen lämnas in, med ytterligare information adderad.

Att göra: Välj och beskriv projekt

  1. Läs informationen om vad som kan vara ett lämpligt projekt.

  2. Kom överens om ett projekt att utföra.

  3. Fyll tillsammans i första delen av projektbeskrivningen enligt projektbeskrivningsmallen. Mer instruktioner finns i denna.

  4. Exportera till PDF-format, t.ex. med File | Export to PDF i OpenOffice Writer. Döp filen enligt följande mönster, utan mellanslag i filnamnet. ID måste alltså finnas med.

    liuid123-liuid456-beskrivning.pdf

  5. Skicka till er egen handledare för en kort genomgång. Brevets ämne ska som alltid inledas med kurskoden TDDD78 så det kan sorteras rätt. Lämna in enligt deadline (ett datum för att få snabbast feedback, ett annat datum för att få lämna in projektet under våren)!

    Det är omöjligt för handledarna att helt och hållet avgöra hur genomförbart ett projekt är. Därför är genomgången är en kortare "sanity check" där vi tittar efter uppenbara problem, som att projektet är alldeles för litet eller för stort eller att ni saknar tillräcklig information om milstolpar. Vi ger inte "godkänt" eller "ej godkänt" på detta i webreg, utan ger "inlämnat" som betyg om vi inte ser något uppenbart att diskutera. Ansvaret för projektets innehåll ligger fortfarande på er som kursdeltagare, och ni får gärna fortsätta diskutera detta med era handledare under labbarna medan ni utför projektet.

Steg 3: Programutveckling

Att göra: Uppstart

Under projektstarten skapar vi regelbundet nya Git-repon för projektgrupperna, allteftersom deltagarna anmäler sig. Titta om ditt/ert repo finns tillgängligt – annars bör det komma inom kort.

Gör en klon av det nya repot, på samma sätt som för labbarna – se de tidigare instruktionerna!

Skapa också ett nytt IDEA-projekt i den resulterande arbetskopian. Detta måste i vilket fall som helst göras före inlämning, även om ni huvudsakligen använder ett annat verktyg vid utvecklingen.

Se till att More Settings / Project format är ".ipr (file based)"!

Att göra: Programutveckling

Under hela programutvecklingsfasen ska ni:

  • Följa milstolparna i projektbeskrivningen. Upptäcker ni problem eller vill göra ändringar uppdaterar ni projektbeskrivningen – den är inte en kravspecifikation, utan projektet kan vid behov ändras under tiden.

  • Testa regelbundet, så att ni hittar problem tidigt.

  • Putsa och förbättra koden regelbundet, så att ni inte har allt detta kvar till slutet. Nya features är roliga, men hög kvalitet är viktigt.

  • Dokumentera regelbundet. Många tidigare studenter skriver att de önskar de hade dokumenterat under kursens gång – efter ett tag glömmer man t.ex. vilka designbeslut man gjorde!

  • Välja objektorienterade lösningar så att ni kan lära er, och visa att ni har lärt er, både Java och objektorientering.

  • Gå genom IDEAs kodinspektioner minst en gång i veckan (Analyze | Inspect Code, välj profil TDDD78-2017-v1), och håll koll på färgläggningen som visas direkt i koden. Detta är ofta ett utmärkt sätt att starta reflektioner över den egna koden och att lära sig något nytt. Ibland kan det så klart ge "falska varningar", och dessa ska då kommenteras så att handledaren får er motivering till varför varningen finns kvar.

  • Diskutera projektet med labbhandledaren då och då. Be om feedback på lösningar ni har gjort och ta chansen att fixa eventuella problem så tidigt som möjligt, även om vi så klart inte kan garantera att allt upptäcks. Att använda handledaren är inte en svaghet utan en styrka!

  • Ge oss omedelbar feedback om det uppstår tekniska eller andra problem.

Steg 4: Feature Freeze

Syfte

Det är bättre, både ur betygssynpunkt och för inlärningen, att ha ett projekt med något mindre omfattning men högre kvalitet än att ha ett större antal features som tyvärr inte riktigt fungerar.

Så är det även i "verkligheten", och i många projekt sker därför en feature freeze en tid innan en ny version faktiskt görs tillgänglig. Man slutar alltså lägga till nya finesser och spenderar tid enbart på att fixa problem och "städa upp".

Detta är extremt viktigt och ska göras även i detta projekt!

Att göra: Feature Freeze

Någon vecka innan inlämning är det dags att sluta lägga till nya finesser. Då sätter ni istället av tid till att:

  • Återigen gå genom alla IDEAs kodinspektioner och fixa eventuella problem som hittas.

  • Se över den övergripande strukturen på hela projektet och se om den kan förbättras.

  • Gå tillbaka till koden ni skrev i början, och uppdatera den nu när ni kan mer och vet bättre!

  • Leta efter ineffektiv och duplicerad kod. Hitta sätt att reducera detta. Finns det till exempel ställen där kod från många liknande klasser egentligen borde ligga i en gemensam superklass? Detta kan ge komplettering!

  • Uppdatera dokumentationen och kommentarerna, så att en utomstående lättare kan förstå.

  • Uppdatera projektbeskrivningen.

  • Finputsa programkoden på "detaljnivå".

  • Och så vidare...

Steg 5: Demonstration

Syfte: Demonstration

Beroende på antal projektgrupper kommer ni att ha cirka 10 minuter på er att demonstrera ert projekt för labbhandledaren. Två specifika labbtillfällen är reserverade för detta. Det går även bra att demonstrera tidigare om handledaren har tid, men vi bedömer ändå alla projekt tillsammans efter deadline.

Förberedelser för demonstration

Använd veckan innan demonstrationen till att "polera" projektet enligt ovan.

Fyll i ett labbomslag där ni skriver under att ni har följt alla labbregler på IDA.

Var förberedda på själva demonstrationen! Allt ska gå att starta smidigt när labbhandledaren kommer till er. Testa att demonstrera för varandra i god tid, så att ni inte hittar uppenbara buggar under demonstrationen för handledaren.

Info: Demonstrationen

Demonstrationen går till så här.

  • Hos de grupper som vill demonstrera ska alla gruppmedlemmar vara närvarande för att svara på frågor (som på en tenta). Kan någon medlem inte komma hänvisar vi till tidigare labbtider eller nästa omredovisningstillfälle.

  • Demonstrationen inleds med att ni själva demonstrerar funktionaliteten i projektet under några minuter. Var beredda på att visa hur det används och att visa upp de finesser ni själva tycker är viktigast givet tidsbegränsningen (cirka 10 minuter).

  • Därefter fortsätter handledaren med egna tester och frågor. Bland annat kan vi testa er kunskap om koden och att kontrollera att ni vet varför ni har gjort som ni har gjort. Frågorna kan ställas till en specifik person. Se därför till att alla känner till alla aspekter av koden.

    Detta garanterar inte att alla problem upptäcks – inte ens de som kan verka "uppenbara". Den riktiga genomgången av programkoden sker efter inlämning, när handledaren får tid att sätta sig en timme eller två med enbart ert projekt!

  • Labbhandledaren kan också välja att ställa några (individuella!) frågor runt objektorienterad programmering: Vad menas med polymorfism? Varför vill man gömma information? Vad är skillnaden på ärvning mellan klasser och när man implementerar ett gränssnitt? Varför kan designmönster vara bra? Vad finns det för relation mellan meddelanden och metoder? Och så vidare. Var beredda på att svara.

  • Om projektet är buggigt kan handledaren välja att gå vidare till en annan grupp så att ni får försöka igen senare. Är programmet för buggigt när demotillfället närmar sig sitt slut kan ni bli hänvisade till omredovisning under nästa planerade demotid.

  • När allt är klart lämnar ni in det ifyllda labbomslaget som ni förberedde.

Projektbeskrivningen lämnas in tillsammans med koden, inte vid demonstrationen.

Steg 6: Inlämning av kod och dokumentation

Allmänna regler

Vi har strikta instruktioner för inlämning. Vi har runt 150 deltagare, så om vi behöver lägga ner 10 minuter extra per student "i onödan" tar det 25 timmar som vi kunde ha lagt på handledning och kursutveckling! Därför måste vi returnera labbar som inte följer instruktionerna för komplettering.

Inlämningsprocedur

  1. Se till att projektet är i IDEA-format med en .IPR-fil så att vi snabbt kan öppna det och navigera genom koden.

    Har du använt en annan miljö: Skapa ett nytt projekt enligt instruktionerna. Kom ihåg att kolla att More Settings / Project format är ".ipr (file based)"!

  2. Läs genom betygskriterierna en gång till och se till att koden uppfyller grundkraven, inklusive krav på felhantering, resurshantering med mera.

  3. Kör IDEAs kodinspektioner en sista gång. Det här är till stor del ett sätt att lära sig skriva kod som inte bara gör vad den ska utan även är välskriven och strukturerad.

    Förstår du inte en varning? Utmärkt! Då har du en chans att lära dig något nytt, redan innan du lämnar in koden! Läs IDEAs inbyggda beskrivningar, läs våra utökade beskrivningar, och om det inte hjälper, fråga gärna assistenten eller examinatorn.

    1. Välj Analyze | Inspect Code i menyn.
    2. Välj inspektionsprofil "TDDD78-2017-v1" och tryck OK.

    Inget automatiskt inspektionsverktyg är 100% korrekt. Det kan alltså finnas varningar som är "felaktiga". Alla sådana måste kommenteras på plats på plats i koden, med god motivering. Övriga varningar ska korrigeras. Annars får ni tillbaka projektet!

    Är du osäker? Fråga handledaren, helst i god tid!

  4. Dubbelkolla att projektrapporten är uppdaterad. Den ska använda mallen och ska innehålla all den information vi efterfrågar med korrekt numrering av avsnitt. Se den som en tenta – en viktig del av betyget!

    Se till att rapporten är exporterad till PDF-format Använd t.ex. File | Export to PDF i OpenOffice Writer. Döp beskrivningen enligt följande mönster, utan mellanslag i filnamnet. ID måste alltså finnas med.

    • liuid123-liuid456-rapport.pdf

    Se till att rapporten och PDF-filen är adderade till Git och incheckade.

  5. Är detta en komplettering? Beskriv i så fall i filen "kompletteringar.txt" hur varje enskild kommentar från handledaren har hanterats: Vad som ändrats och var i koden (klass/metod), hur ni har löst problemet, och annan information som är relevant för att handledaren lätt ska se vad som gjorts.

    Gör ni flera kompletteringar ska gamla kommentarer vara kvar och tydligt skilda från nya kommentarer (markera med kompletteringsdatum). Detta underlättar för oss och är en del av examinationen där ni visar att ni förstår varför kompletteringen behövdes.

    Se till att filen är adderad till Git och incheckad.

  6. Checka in all kod och dokumentation, och pusha till GitLab. Kontrollera noga att allt verkligen är incheckat, inklusive .ipr-fil och eventuell kompletteringsfil. Alla incheckade och pushade filer kan ses direkt i Gitlab.

  7. Skapa en tagg (etikett) i Gitlab. Detta visar oss vilken version av koden som lämnades in vid inlämningsdatumet.

    1. Logga in på gitlab.

    2. Gå till ditt projekt och välj "tags".

    3. Välj "New tag".

    4. Sätt taggnamnet till "t1" om detta är första gången du lämnar in Tetris. Om du får komplettering får du nästa gång sätta en ny tagg "t2", och så vidare.

    5. Låt "Create from" vara kvar på "master".

    6. Meddelanden och "release notes" behövs inte.

    7. "Create Tag"!

  8. Dubbelkolla och trippelkolla att allt är korrekt. Inlämningar som har okommenterade varningar, saknar nödvändiga filer eller uppenbart bryter mot viktiga regler kommer att returneras utan bedömning.

  9. Skicka ett brev till din handledare. Ange en URL till ditt projekt i gitlab och den tagg du skapade ovan (alltså t1 första gången).

    Brevets ämne ska inledas med kurskoden TDDD78 så det kan sorteras rätt. Annars kan det dröja innan brevet blir läst.


Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2017-02-27