# Examensarbete *Denna beskrivning är preliminär tills vi har gått igenom den tillsammans på första kurstillfället och gjort eventuella ändringar/tillägg utifrån era frågor och kommentarer.* ## Översikt Målet med denna kurs är att självständigt genomföra ett praktiskt projektarbete och formellt dokumentera det (projektrapport och presentation) samt kritiskt granska någon annans arbete (opponering och opponeringsrapport). Ni förväntas i regel utföra ert arbete på och i samarbete med er LIA-plats, och sådana arbeten är också oftast de som bäst uppfyller kursens kriterier. ## Viktiga datum - **31:a augusti:** Introföreläsning (ingen inspelning, se till att närvara) - **Senast 18:e september:** [Lämna in **projektidé** och **projektplan**](https://yh.pingpong.se/courseId/13393/content.do?id=6920060) (ju tidigare desto bättre) - **Löpande:** Lägg 20% av LIA-tiden på examensarbetet - **Senast 25:e september:** [Lämna in frågor/utkast till **handledning 1**](https://yh.pingpong.se/courseId/13393/content.do?id=6920064) - **26:e - 30:e september:** Handledning 1 - **Senast 23:e oktober:** [Lämna in frågor/utkast till **handledning 2**](https://yh.pingpong.se/courseId/13393/content.do?id=6920071) - **24:e - 28:e oktober:** Handledning 2 - **November - December:** Föreläsning om opponering (datum ej satt) - **Senast 1:a januari:** [Lämna in **projektrapport**](https://yh.pingpong.se/courseId/13393/content.do?id=6920081) - **Senast 8:e januari:** [Lämna in **opponeringsrapport**](https://yh.pingpong.se/courseId/13393/content.do?id=6920091) - **9:e - 13:e januari:** Genomför **presentation** och **opponering** ## Projektidé Beskriv följande: 1. **Problemet** som arbetet ska lösa. - Detta är ofta en funktion som saknas i ett existerande system eller en brist som behöver åtgärdas. 2. **Lösningen** som ska implementeras. - Detta innebär ofta att utveckla en ny applikation eller göra förändringar i en existerande. 3. **Kriterier för utvärdering** av lösningen. - Målet är att inte bara säga "jag har implementerat detta" utan också kunna bedöma om arbetet var lyckat. Kriterierna kan vara objektiva/specifika (exempelvis hur snabbt programmet är) eller subjektiva/vaga (exempelvis huruvida utvecklarna anser att ett nytt verktyg underlättar deras arbete). Även avvägningar är relevanta (exempelvis att ett nytt verktyg underlättar utvecklarnas arbete men tar mer tid att använda än tidigare verktyg). Denna utvärdering kan göras av dig själv eller i samarbete med andra på din LIA-plats. ## Projektplan Ta fram ett diagram av lämplig typ (exempelvis Gantt) som visar vilka delar som ingår i ditt projektarbete och när du planerar att utföra dem (vilka veckor). - Projektplanen är preliminär och det är fritt fram att ändra på den när som helst, men ett genomtänkt första utkast är nödvändigt. - Om det passar dig kan du planera flera aktiviteter parallellt, exempelvis rapportskrivande parallellt med implementation. ## Handledning 1 och 2 Handledningen är till för din skull, så se till att förbereda de frågor som är viktigast för dig att få svar på. Några tips på saker att fråga om: - Problem som hindrar dig från att komma vidare med arbetet. - Sätt att avgränsa eller utöka arbetet om det behövs. - Om du har kommit långt nog i arbetet eller rapportskrivningen hittills. - Hur du bör dokumentera ditt arbete i projektrapporten. - Hur du kan utvärdera arbetets resultat. Lämna också in ett utkast till din projektrapport (oavsett hur lite du har hunnit göra). *Vi är en större klass än vanligt, så det kan hända att den tid vi har avsatt för handledning inte räcker. Om detta händer så kommer skolan att avsätta mer tid vid behov, så det här problemet går alltså att lösa om det skulle uppstå.* ## Projektrapport Beskriv följande: 1. **Vad du gjorde**, på teknisk nivå med relevanta detaljer. Detta bör också innefatta en beskrivning på lämplig teknisk nivå av hur nuvarande system/applikation/organisation fungerade innan arbetet på projektet inleddes. 2. **Hur det gick**, inklusive utmaningar och förändringar under arbetets gång. 3. **Hur resultatet blev**, utifrån kriterierna för utvärdering (antingen de i projektidén eller andra som har tagits fram under arbetets gång). En helhetsbedömning bör också finnas med, samt en rekommendation eller slutsats kring hur projektets resultat bör användas, vidareutvecklas och/eller tolkas. 4. **Sammanfattning** av hela arbetet på högst en sida (*abstract*), skrivet på engelska. Det finns ingen strikt gräns för rapportens längd, men i de flesta fall bör du hålla dig inom 10-30 sidor. ### Struktur Det finns ingen fördefinierad struktur som din rapport måste följa utan det är upp till dig att välja exakta rubriker förutsatt att du täcker in de 4 punkter som beskrivs ovan. Det finns dock flera vanliga avsnitt som är lämpliga att välja från: - **Sammanfattning (*abstract*)**, som ska vara först i rapporten. - **Inledning**, **syfte** och/eller **problemformulering**, som beskriver problemet på generell nivå innan lösningen beskrivs. - **Bakgrund**, **teori** och/eller **forskningsöversikt**, som beskriver relevant information som behövs för att förstå resten av rapporten. - **Metod** och/eller **genomförande**, som beskriver hur arbetet genomfördes. - **Analys**, **diskussion**, **resultat** och/eller **analys**, som beskriver resultatet och utvärderingen av det. Välj de rubriker som är mest lämpliga för just din rapport (eller ta fram egna rubriker om de ovanstående inte passar). Det viktigaste är att din rapport som fristående dokument beskriver projektarbetet så bra som möjligt, inte att en viss mall efterföljs. ## Opponeringsrapport *Terminologi: **Respondenten** är den ursprungliga rapportens författare. **Opponenten** är den som opponerar och skriver opponeringsrapporten.* Beskriv följande: - **Brister** i rapporten. Detta kan innefatta både arbetet som utfördes och hur rapporten beskriver detta arbete. - **Styrkor** i rapporten. Detta är i princip motsatsen till föregående punkt och visar ytterligare att du kan bedöma kvaliteten på ett arbete. - **Hypotetiska frågor** kring rapporten, exempelvis hur arbetet skulle ha förändrats utifrån andra förutsättningar eller hur det skulle kunna vidareutvecklas i framtiden. Detta visar att både du och rapportens författare kan resonera kring nya och obekanta situationer relaterade till ditt arbete. Vid inlämning ska opponeringsrapporten lämnas in både till mig och till respondenten, så att de vet ungefär vad som kommer att tas upp. *Viktigt: Opponeringsrapporten är främst till för att jag ska kunna bedöma **opponenten**. Det är ovanligt att **respondentens** insats har en nämnvärd påverkan på respondentens betyg, förutsatt att respondenten på grundläggande nivå kan besvara frågor kring sitt arbete. Med andra ord kan du som opponent kritiskt granska respondentens arbete utan att oroa dig för att respondenten kommer att bli underkänd på grund av dig.* ## Diverse ### Lämpliga projekt - Projektet bör utgå från ett verkligt problem som din LIA-plats vill lösa. (Dessa är nästan automatiskt lämpliga, förutsatt att storleken också är lämplig.) Rent teoretiska eller hypotetiska arbeten rekommenderas inte. - Det behöver finnas kriterier för att utvärdera om projektet är lyckat eller inte. Se tidigare beskrivning kring detta. - Välj ett projekt med lämplig storlek eller åtminstone ett som vid behov går att utöka/avgränsa under arbetets gång. - Det är tillåtet att välja projekt inom andra miljöer än .NET eller med andra programmeringsspråk än C#/JavaScript/SQL, med följande villkor: - Kontakta mig först (via Teams) för att kort beskriva konceptet, så att jag kan bedöma om det är lämpligt. - I din rapport, se till att lägga extra stor vikt vid att beskriva relevant bakgrund som inte ingår i utbildningen (exempelvis obekanta programmeringsspråk, miljöer, bibliotek osv.) så att både jag och din opponent har nog med information för att bedöma ditt arbete. ### Referenser - Ange referenser med ett etablerat system (exempelvis Harvard eller Oxford) och använd de inbyggda funktionerna i ditt ordbehandlingsprogram till detta. - Inom programmering är det vanligt att ange hemsidor som referenser (istället för böcker). Se till att i dessa fall också ange åtminstone titel och publiceringsdatum på källan. Referenser som *enbart* anger URL är inte tillåtna. - Det är tillåtet och lämpligt att i rapporten utgå från åsikter, observationer, påståenden etc. från personer på din LIA-plats, trots att detta normalt sett inte kan anges som referenser (då referenser måste syfta på publicerat material). Försök i dessa fall också att hitta publicerade källor som gör liknande påståenden och använd dessa källor som referens. - Ha en lagom mängd referenser i rapporten. Målet är inte att varje påstående ska styrkas med en källa utan att visa att du förstår hur man använder sig av och refererar till publicerat material i en sån här rapport. ### Samarbete Det är tillåtet för två personer att arbeta på samma projekt, men ni ska då också skriva en individuell rapport var. Samma regler som mina tidigare kurser gäller här: diskutera gärna tillsammans vad ni ska ta upp i era rapporter, men utför allt skrivande på egen hand. Ni behöver dock bara skriva en enda projektidé och projektplan, men båda behöver lämna in denna individuellt via PingPong (för att betygsättningen ska bli tydlig och enkel). ### Resultat En av de allra viktigaste kommentarerna är att det inte spelar någon roll för betyget huruvida ert projekt var lyckat eller inte; det viktiga är att ni dokumenterar det på ett bra sätt, inklusive era kriterier för att bedöma om arbetet var lyckat. Förutsatt att ni själva har lagt den tid och den ansträngning som behövs, samt dokumenterat arbetet på ett bra sätt, så kan ni vara nöjda oavsett resultatet i övrigt. ## Exempel ### Projektidé - **Problem:** Att förbättra och förenkla kodstrukturen på en existerande applikation byggd med renodlad JavaScript som har blivit svår och långsam att underhålla och vidareutveckla. Här bör också beskrivas vad applikationen gör och översiktligt hur den är uppbyggd på teknisk nivå. - **Lösning:** Att skriva om den existerande applikationen från renodlad JavaScript till React. Här bör också beskrivas om detta ska göras för hela applikationen eller enbart delar av den och/eller om vissa delar ska ha högre prioritet. - **Kriterier för utvärdering:** - Antal rader kod: om React innebär mindre kod är det positivt. (Objektiv) - Kodstruktur: om React är mer flexibelt och enklare att förändra eller vidareutveckla är det positivt. (Subjektiv) - Inlärningströskel: om React innebär längre inlärningstid för nya utvecklare är det negativt. (Subjektiv) - Prestanda: om React är långsammare är det negativt. (Objektiv/subjektiv) - Testbarhet: om React är enklare att testa är det positivt. (Subjektiv) ### Projektplan Projektplanen bör ta upp åtminstone följande: - Tid till att bekanta sig med den existerande applikationen. - Tid till att skriva om applikationen från renodlad JavaScript till React. - Tid till säkerställa att den nya applikationen fungerar korrekt. - Tid till att utvärdera för- och nackdelar med den nya applikationen jämfört med den gamla. - Tid till att skriva rapporten. ### Projektrapport - **Vad du gjorde:** Rapporten bör beskriva på lämplig teknisk nivå hur de olika filerna/klasserna/modulerna i den existerande applikationen skrevs om till React. Den bör innehålla kortfattade men illustrativa före-och-efter-kodexempel (antingen riktiga eller påhittade) som visar hur detta kunde gå till. - **Hur det gick:** Rapporten bör beskriva utmaningar i att hitta React-motsvarigheter till den existerande applikationens renodlade JavaScript samt hur dessa löstes. Den bör också beskriva utmaningar på högre nivå i att skriva om en existerande applikation, exempelvis beroenden mellan olika delar av applikationen som gör det svårt att skriva om en del i taget. - **Hur resultatet blev:** Rapporten bör exempelvis konstatera att kodstrukturen ansågs förbättrad och prestandan ansågs oförändrad, men på grund av en hög inlärningströskel och försämrad testbarhet bedöms att övergången till React inte bör fortsättas i detta fall.