Kursplan och betyg

Kursplan

Kursplanen i sin helhet hittar du här:

Kursplan 1DV613

Nedan lyfts delar ur kursplanen ut och diskuteras.

Förkunskapskrav och antagning

Enligt kursplanen krävs:

Minst 30 hp inom datavetenskap inkluderat kursen Webbprogrammering på klientsidan, 15 hp (1DV025) eller motsvarande.

Kursomgången VT2023 kan vi ge dispans enligt:

Minst 30 hp inom datavetenskap kan inkludera 1ME321

eller

Webbprogrammering på klientsidan, 1dv025, provmoment 2005 (B2) är avklarat samt
Webbprogrammering på serversidan, 1dv026, provmoment 2003 (B1) är avklarat.

eller

1DV502 avklarad.

Provmoment i kursen

Provkod	Benämning	Betyg	Poäng
2101	Muntlig examination	U/G	4 hp
2102	Projekt	U/G/VG	11 hp

För slutbetyget VG krävs G på 2101 samt VG på 2102.

Provmoment 2101 - Muntlig examination

Den muntliga examinationen examinerar följande kursmål:

A.1 förstå och redogöra för olika utvecklingsprocesser och begrepp såsom krav, implementation, testning, leverans och planering.
A.2 förstå och redogöra för betydelsen av automatisering i mjukvaruutveckling inklusive arbetsflöden, versionshantering, kontinuerlig leverans och automatiserad testning.
C.1 reflektera över rådande lagstiftning samt etiska frågeställningar generellt i mjukvaruutveckling och i förhållande till valt projekt.

Vad krävs för betyget G?

På det muntliga förhöret behöver du visa på tillräcklig förståelse för följande nedanstående delar i kursen. Detta är med andra ord kursens teoridelar.

Att arbeta i projekt
Versionshantering
Kravhantering
Testning
CI/CD

Provmoment 2102 - Projekt

Det praktiska projektet examinerar följande kursmål:

B.1 planera och genomföra ett individuellt utvecklingsprojekt som följer en strukturerad utvecklingsprocess.
B.2 arbeta enligt ett arbetsflöde för versionshantering samt följa kodstandard och vedertagna konventioner kopplat till specifikt projekt.
B.3 kontinuerligt redovisa och kommunicera projektets resultat och status både skriftligt och muntligt.
B.4 kontinuerligt utvärdera och redovisa projektets implementation genom strukturerad testning.
C.1 reflektera över rådande lagstiftning samt etiska frågeställningar generellt i mjukvaruutveckling och i förhållande till valt projekt.

Vad krävs för betyget G?

För att uppnå betyg G måste alla uppgifter i projektet genomföras och bli godkända . Den utvecklade applikationen måste ha en viss svårighetsgrad/storlek. Att t.ex. göra en enkel blogg är inte tillräckligt svårt/stort. Att implementera en blogg med möjligheter till kommentarer, bildgalleri, kategorier, taggar, formatering av inlägg, spamhantering kan däremot vara tillräckligt. Det kan också vara som så att delar som inte bara rör projektet som helhet kan vägas in i svårighetsgraden. Sätta upp en pipeline för kontinuerlig leverans? Är du osäker så lyft frågan vid ett standup-möte.

Att kopiera implementation och presentera denna som sin egen betraktas som försök till vilseledande vid examination. Detta kommer att anmälas till skolans disciplinnämnd. Om du använder någon annans implementation så måste detta tydligt anges och de delar som du själv ha bidragit med markeras. Du måste även följa de licenser som den kod du använder är släppt under. Ditt projekt måste också innehålla en betydande mängd extra funktionalitet som du själv har implementerat för att uppnå betyg G.

Aktivt deltagande vid standup-möten kommer att göra att projektets omfattning styrs och prioriteras på sådant sätt att du får en klar bild över vad som krävs för betygsnivån G.

Nedan listas de delar som särskilt kommer att bedömas vid examination.

Kravhantering och planering

Det går tydligt att se vad som planerats för varje iteration, samt uppföljning av vad som är gjort.
Uppgifter har brutits ned till lämplig storlek för planering.
Det finns funktionella krav som beskriver produktents funktionalitet på lämplig nivå.
Det finns ickefunktionella krav som beskriver produktens kvaliteter på lämplig nivå.
Det finns etiska överväganden kring applikationen, och projektet.

Testning

Studenten har validerat sina krav genom att ha minst ett testfall per implementerat krav. Inte alla testfall behöver vara lyckade.
Studenten har regressionstestat krav som implementerats i tidigare implementationer och redovisat i veckomöten
Studenten har en metod i sin applikation som är testad automatiskt med hjälp utav enhetstester ex. JUnit, Jest, Mocha. De olika automatiska enhetstesterna skall vara användbara det vill säga: det skall kunna finnas en bugg för varje test som just det testet fångar. Exempelvis kan man skapa ett testfall för varje ekvivalens-partion som metoden har. Metoden skall ha minst en kontrollsats (if/for/while/try-catch eller liknande).

Implementation

Koden håller en acceptabel kvalitetsnivå. Tänk särskilt på:
- Undvik duplicering av kod.
- Filer, variabler, klasser och funktioner etc. är namngivna så att det underlättar förståelse.
- Koden är uppdelad i flera filer.
En dokumenterad kodstandard finns och följs.
En enklare schematisk bild över applikationens arkitektur finns tillgänglig.
Applikationen är driftsatt.
Projektets hela kodbas versionshanteras kontinuerligt.
Koden är dokumenterad på sådant sätt att den underlättare för andra utvecklare att sätta sig in i koden.

Slutresultat

Vad krävs för betyget VG?

Nedan listas kriterier för betyget Väl godkänd. För VG krävs att samtliga krav enligt ovan för G är uppfyllda. (I de fall de finns motsägande krav kan du ignorera kravet för G.)

Kravhantering och planering

En majoritet av iterationsplanerna har ett resonemang kring utvärdering av föregående iterations resultat och arbetssätt, lämpliga processförbättringar har kontinuerligt genomförts och utvärderats.
Uppgifter och krav har kontinuerligt prioriterats på ett lämpligt och genomtänkt sätt. Prioriteringsförfarande är beskrivet och motiverat.
Det finns tydliga beroenden och spårbarhet mellan olika artefakter. T.ex. mellan uppgifter och krav, krav och krav, krav och testfall etc.
Kraven är väl beskrivna och kategoriserade på lämpligt sätt. Kategoriseringen är definierad.
Kvalitetskrav är väl definierade och testbara.
Organisationskrav är väl definierade och testbara.

Testning

Studenten har skapat en överblick över Release-testningen så att det blir tydligt vilka krav som är implementerade och testade.
Projektet är vältestat, krav som har scenarion täcks in av minst ett test per scenario. Testerna kan vara manuella eller automatiserade. Skapa överblick över testfallen.
Studenten har skrivit automatiska enhetstester för minst 10 olika metoder. Varje test skall vara användbart (enligt G-nivån)
De automatiska enhetstesterna ska testas i projektets CI/CD-flöde.
Studenten har låtit en annan student testa sin applikation och dokumenterat feedbacken.

Implementation

Koden håller överlag en hög kvalitet. Tänk särskilt på:
- Låg nivå av kodduplicering.
- Undvik hårdkodade konstanter som upprepas. sk. dolda beroenden.
- Jämn storleks- och komplexitetsnivå. Ingen del (funktion, klass, model etc.) är överdrivet stor eller komplicerad jämfört med andra delar.
- Koden är uppdelad och organiserad i logiska delar som är tydligt avgränsade och följer best practice för valda tekniker och arkitekturer.
- Undivk "globala variabler", arbeta istället med inkapsling.
Den dokumenterade kodstandarden veriferas automatiskt då koden förändras på Gitlab.
Centrala flöden i applikationen finns dokumenterade i form av sekvensdiagram.
Utvalda delar finns representerade som klassdiagram (eller motsvarande).
Applikationen kan driftsättas via CI/CD-flöden i Gitlab.
Semantisk versionshantering följs.
Studenten väljer, följer samt dokumenterar ett arbetsflöde för versionshantering ("branch strategy").
Koden är dokumenterad på sådant sätt att utvecklingsverktyg kan dra nytta av den samt att det går att automatiskt skapa en samlad dokumentation. (Jmfr. JSDOC, JavaDoc).