Göm menyn

Projektuppgift

Att göra: Anmälan i Webreg

I projektet delar vi upp oss i nya "storgrupper":

  • D1P1, D1P2, D1P3 för D1a/b/c och kognitionsvetare
  • U1P1, U1P2 för U1a/b

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 WebReg för D1Px respektive U1Px. Om det är fullt, vänta lite eller 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: Val av projekt

Innan ni börjar behöver ni själva välja vilket projekt ni vill utföra. Läs informationen om vad som kan vara ett lämpligt projekt. Fundera och bestäm vad du/ni vill göra, inklusive om ni vill använda ett inspirationprojekt eller hitta på något helt eget.

Steg 2: Beskrivning av projekt

Innan ni börjar behöver ni skriva en projektbeskrivning, oavsett om ni valde ett inspirationsprojekt eller ett helt eget. Projektbeskrivningen ska skrivas på svenska, oavsett handledare. 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 ni ska tänka genom hur ni ska arbeta, om ni arbetar i par. Det är viktigt att komma överens om när/hur man arbetar och vad ambitionen är!

  3. 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.)

Att göra: Beskriv projektet

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

Att göra: Skicka till handledaren

Om du går TDDD78 (VT1) skickar du in projektbeskrivningen så snart du är färdig, enligt instruktion nedan. Handledaren går genom den så snabbt som möjligt.

Om du går TDDE30/729A85 (VT1 + VT2) finns mer kalendertid och vi kan därför sätta en specifik deadline (ett datum för att få feedback innan projektstart, ett annat datum för att få lämna in projektet under våren).

  1. 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. Ditt eller era LiU-ID måste alltså finnas med.

    liuid123-liuid456-beskrivning.pdf

  2. Skicka till er egen handledare för en kort genomgång. Brevets ämne ska som alltid inledas med kurskoden (TDDD78, TDDE30 eller 729A85) så det kan sorteras rätt.

Om granskningen

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-2018-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 8–12 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 lite tid närmast 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. Labbomslag bör finnas i kartonger i skrivarrummen och kan också skrivas ut från en PDF.

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 180 deltagare, så om vi behöver lägga ner 10 minuter extra per student "i onödan" tar det 30 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. Gå genom de specifika tipsen.

  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, sök efter varningen i de specifika tipsen , 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-2018-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. Om ni använder externa klassbibliotek ska även dessa finnas med – vi använder inte verktyg som Maven etc. för att hämta dem. 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. 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. Lämna in via vårt centrala gitlab-repo!

Sidansvarig: Jonas Kvarnström
Senast uppdaterad: 2018-10-16