Eksamensprojekt i Informatik B

Projektbeskrivelsen skal afleveres på Lectio 25.2. 2019 kl. 23. Der er afsat 2 elevtimer
Rapporten skal afleveres på Lectio senest 26.04.2018 kl. 23.59. Der er afsat 12 elevtimer.

Projektbeskrivelsen

Projektbeskrivelsen skal omfatte tre ting:

  • Beskriv ideen med det planlagte IT-produkt
  • Skitser hvilke værktøjer/teknologier, der forventes anvendt
  • Giv et udkast til kravspecifikation for produktet, gerne på tre forskellige niveauer: minimum, forventet og håbet på

Rapporten

Rapporten skal dokumentere såvel udviklingsprocessen, som det produkt I udvikler. Den ligner med andre ord en teknologirapport temmelig meget, omend der er mindre vægt på problemanalysen, på miljøvurdering og lignende.

Derfor vil det være hensigtsmæssigt i rapporten at have nogle afsnit som nedenstående:

Abstract (I kan lige så godt vænne jer til det) 

Et resumé af opgaven, på engelsk. Skrives som det allersidste!

Indledning og problembeskrivelse

Opridser de overordnede rammer for opgaven, fx at det er et eksamensprojekt i IT B samt hvad det helt overordnet er for en slags applikation I vil skrive om, og hvem den er rettet mod.

Med andre ord, en beskrivelse af den samfundsmæssige og brugsmæssige kontekst, som applikationen skal indgå i, samt de fordele, den vil give for målgruppen og øvrige interessenter. Herunder eksempelvis resume af brugerundersøgelser etc.

Kravspecifikationen skal ligeledes indgå i præsentationen af produktet.

Beskrivelse produktudviklingen

Produktudviklingen beskrives bl.a. ved overvejelser om systemets funktion og anvendelse, herunder

Valg af de teknologier, I bruger (platforme, arkitektur, interaktionsdesign, typer af applikationer)

Produktudvikling dokumenteres med use cases, mockups, diagrammer, modeller.

Valg I har truffet med hensyn til hvilke dele af systemet I har prioriteret at udvikle, herunder også, om I primært laver front-end eller back-end komponenter i systemet.

Udvalgte kodestumper eller funktionalitet udvælges og beskrives nøjere

Arkitektur: Hvilke sider indgår i løsningen, hvad er deres funktion og indbyrdes relation?

Dokumentation af selve produktet

Selve produktet dokumenteres med et link samt fotos, screenshots, diagrammer osv. Inddrag også eventuelle brugertests, datakørsler, screencasts eller lignende. Eventuel kildekode (kommenteret!) anbringes som bilag.

Evaluering / test

Hvis i kan nå det, bør i forsøge at teste hvorvidt produktet lever op til forventningerne i kravspecifikationen. Nogle dele kan testes empirisk – fx hastighed og funktionalitet – mens andre dele må testes kvalitativt.

Hvis det er muligt, kan i lave en lille test af produktet – for eksempel en tænke højt test.

Selvom i ikke når at teste produktet, er det stadig en fordel at beskrive hvordan det kunne have været testet/evalueret. Resultaterne af eventuelle tests indgår kortfattet i rapporten eller i bilag.

Diskussion, refleksion, perspektivering

Hvor godt er det lykkedes, hvilke problemer og nye muligheder er I blevet opmærksomme på undervejs etc.

Arbejdsprocessen

En kort redegørelse for hvordan I har struktureret gruppens arbejde vil også være en god ide. Her kan i også komme ind på metoder i har brugt, for eksempel den SCRUM inspirerede brug af issues/afstemning vi har benyttet os af i timerne.

Konklusion

Kort i forhold til intentioner og problembeskrivelse: Hvor langt er I kommet med jeres løsningsforslag i forhold til de tanker, I startede med.


Afsnit 3 og især 4 er de vigtigste. Husk desuden en forside med navne, fag, klasse, skole, titel etc. og ikke mindst med et tydeligt link til applikationen (som i øvrigt skal afleveres på en måde, så det kan verificeres at den ikke er blevet ændret efter afleveringen). Husk også kilder, herunder kilder til kode I ikke selv har skrevet.

Læs (genlæs) også læreplanens beskrivelse af fagets mål og formål. Selve rapporten bør være 8-20 sider lang ekskl. bilag – afhængig af, hvor mange I er om at skrive den, hvor meget plads I bruger på illustrationer og diagrammer etc. Der er ingen formelle grænser eller krav – det er kvaliteten, der tæller.

Formalia omkring opgaven

Bekendtgørelsens tekst om eksamensprojektet

I den afsluttende periode af undervisningen afsættes 20 timers undervisningstid til at eleverne med vejledning fra læreren, udarbejder et eksamensprojekt i grupper på to til tre. Hvor dette ikke er muligt eller ønskeligt, kan man lade eleverne arbejde individuelt.

Projektet skal være inden for rammerne af et projektoplæg stillet af skolen, og projektbeskrivelsen skal godkendes af skolen. Gruppen udarbejder eksamensprojektet bestående af et it-system og en skriftlig rapport som dokumentation af udviklingsprocessen.

Omfanget af dokumentationen er maksimalt fem normalsider per elev. Eksamensprojektet indgår i grundlaget for den afsluttende standpunktskarakter, hvis der gives en sådan, og udgør grundlaget for prøven. Afleveringstidspunktet skal normalt være senest en uge før eksamensperiodens begyndelse. Det afsluttende eksamensprojekt er forinden prøven ikke rettet og kommenteret af eksaminator.

Og fra vejledningen…

Projektet kan tage udgangspunkt i en virksomhed og problemstillinger, der relaterer sig til virksomheden eller et samfundsproblem, som eleverne skal udvikle et it-system som løsning til. Eleverne udarbejder eksamensprojektet bestående af et it-system og en skriftlig rapport som dokumentation af udviklingsprocessen. Dokumentationen skal derfor ikke blot omhandle det færdige produkt, men hvordan eleverne kom frem til løsningen ved hjælp af en systemudviklingsmodel

Ved udarbejdelse af et it-system er projektarbejdsformen oplagt. Som regel har eleverne gavn af at kunne gå sammen i grupper, da det kan være svært at overskue alle aspekter af it-udvikling alene. Ofte vil der både være grafiske elementer, lyd, programmering, interaktionsdesign, projektstyring, dokumentationskrav m.m., der vil skulle tages højde for. Ofte vil eleverne have gavn af at kunne sparre med hinanden om disse aspekter. Og de vil som oftest også have forskellige kompetencer, som de kan supplere hinanden med.

Det bør sikres, at alle elever arbejder med centrale faglige mål, eksempelvis programmering. Her er det hensigtsmæssigt med undervisning, som sikrer, at alle eleverne bliver trænet heri, før de slippes løs i projektarbejdet.

På B-niveau er det oplagt ved større projekter at få eleverne til at tilrettelægge arbejdet ved hjælp af agile arbejdsmetoder som Scrum eller Kanban. Hermed kan de få en forståelse for, hvad det vil sige at arbejde iterativt, og hvad fordelene og ulemperne er herved.

Bekendtgørelsens tekst om eksamen

Der afholdes en mundtlig prøve på grundlag af eksaminandens eksamensprojekt […] og en opgave med tilhørende bilag, tildelt ved lodtrækning

Eksaminationstiden er ca. 30 minutter. Der gives ca. 60 minutters forberedelsestid. Opgaverne, der indgår som grundlag for prøven, skal tilsammen dække de faglige mål. Den enkelte opgave må højst anvendes to gange på samme hold. Eksaminationen er individuel. Eksaminationen tager udgangspunkt i eksaminandens præsentation af eksamensprojektet. Eksaminationen former sig derefter som en samtale mellem eksaminand og eksaminator med udgangspunkt i opgaven.

Opgaverne med bilag, samt en fortegnelse over eksamensprojekt- beskrivelserne, sendes til censor forud for prøvens afholdelse.

4.3. Bedømmelseskriterier

Bedømmelsen er en vurdering af, i hvilken grad eksaminandens præstation opfylder de faglige mål, som de er angivet i pkt. 2.1.

Ved prøve, hvor faget indgår i fagligt samspil med andre fag, lægges der vægt på, at eksaminanden kan
̶ demonstrere viden om fagets identitet og metoder
̶ behandle problemstillinger i samspil med andre fag

Der gives én karakter ud fra en helhedsvurdering af eksaminandens mundtlige præstation.

Læs hele bekendtgørelsen her