Nedenstående er et forslag til en disposition for selve rapporten. I er naturligvis ikke forpligtede til at følge den, MEN den kan i hvert fald tjene som en rettesnor for hvad vi lærere mener der skal med i en god rapport
Forside, Titelblad og Indholdsfortegnelse
Hører til i kategorien “Formalia”, men er ikke desto mindre vigtige for rapportens fremtoning, og dermed også for hvordan læseren (= lærer og censor) opfatter og vurderer arbejdet.
Forsiden skal indeholde projektets titel (helst ikke bare “Eksamensprojekt” – giv jeres produkt et navn), samt deltagernes navne, skolens navn, fagets navn, afleveringsdatoen samt evt. også lærerens navn. Den må meget gerne også have en velvalgt og relevant illustration som “blikfang”.
Titelbladet sidder lige efter forsiden og rummer titel, forfattere (deltagerne) samt et Abstract/Resumé, som gerne må være på dansk
Indholdsfortegnelsen angiver hvilke kapitler og afsnit, rapporten består af, således at læseren kan danne sig et overblik og om nødvendigt finde frem til bestemte steder i teksten på en nem måde. Bilag (kode, datablade, interview-udskrifter) bør også medtages i indholdsfortegnelsen. NB! Husk nu, at en indholdsfortegnelse ikke er noget værd, hvis ikke siderne i rapporten har sidetal! Og det betyder noget, at siderne er sat pænt og overskueligt op, fx at en eventuel toptekst nemt kan adskilles fra brødteksten.
Husk, rapporten er et kommunikationsprodukt: Hjælp din læser!
Forord og indledning
Den oprindelige projektbeskrivelse er et godt sted at starte – men det er sjældent den kan sættes ind i den endelige rapport uforandret. Den rummer blandt andet det, som man ofte vil skrive i et forord, en indledning og – ja, en projektbeskrivelse – når man skriver en rapport over et færdiggjort projektforløb. Men selve projektet har som regel ændret sig en del siden de første tanker blev skrevet ned.
Forord er ikke altid med – her kan man fx skrive om de ydre rammer for projektet, hvis der er særlige forhold: Hvis projektet startede et helt andet sted, hvis deltagergruppen har ændret sig i forhold til starten og det har haft væsentlig betydning for projektet, hvis skolen lukkede ned eller op, uden at man havde forudset det.
Indledningen opridser de overordnede tanker om projeket – valg af eksamenstema, inspiration og visioner, koncept, tematik, tanken med produktets navn eller titel. Det skal give læseren et overblik over tankerne og den overordnede plan bag projektet. Meget af dette er formentlig skrevet i den oprindelige projektbeskrivelse.
Projektbeskrivelse
Den endelige projektbeskrivelse kan vise sig at afvige en del fra den oprindelige. Man er sandsynligvis blevet klogere. Form og struktur vil variere meget, afhængig af projektets emne og produktets art, men der vil sandsynligvis indgå afsnit om
- Brugsscenarier og formål
- Brugere og målgrupper
- Problemidentifikation og -analyse – hvilke specifikke tekniske problemer er projektet fokuseret på,
- Kravspecifikation – konkrete og testbare/målbare krav til funktionalitet og platform. I rappporten er der ikke længere brug for tre forskellige niveauer som i den indledende fase, kun de krav, I faktisk har fokuseret på at prøve at opfylde. Jeres oprindelige tanker kan I diskutere til sidst, i konklusion, diskussion og evaluering.
- Teoretisk baggrund – det kan fx være om spildesign, om kognitiv udvikling hos børn, om farverum, om interaktionsdesign i VR, om neurale netværk eller hvad der nu er relevant for produktudviklingen. Husk kildehenvisninger!
- Værktøjer, teknologier
Projektbeskrivelsen understøttes af illustrationer, skitser og modeller, for eksempel flow-diagrammer, screenshots, wireframes, eller andre former for visualiseringer. I kan lave dem selv eller hente dem udefra (husk da igen kildehenvisninger!), men sørg for at de er klare og forståelige, og relevante i den kontekst de placeres i, så de virkelig hjælper læseren.
Produktudvikling og projektforløb
Et stort kapitel – her dokumenteres den faktiske produktudvikling og det faktiske projektforløb. Det kan for eksempel handle om (men listen er ikke nødvendigvis fuldstændig eller i rækkefølge) at beskrive
- Idegenerering
- Eksterne inputs: interviews, undersøgelser og ekskursioner til kvalificering af ideer til og viden om brugere og brugssituationer
- Udviklingsspor: Interaktionsdesign, funktionalitet, datamodeller (hint: trelags-arkitektur), protokoller, hardware og hvordan I har organiseret arbejdet og samarbejdet omkring disse
- Projektstyring og udviklingsforløb, herunder eventuelle blindgyder og snubletråde, I ramte undervejs samt de værktøjer, I har brugt (hint: Trello, Logbog)
- Produkttest – metodik og udførelse, samt resultater og konsekvenser heraf
- Iterationer af produktet i udviklingsprocessen
Også her er illustrationer et nyttigt værktøj, herunder fotos/screenshots af produktet på forskellige stadier.
Diskussion, Konklusion og Perspektivering
Her gøres status og evalueres resultaterne af projektarbejdet, sat op mod den oprindelige projektplan og de oprindelige krav til og tanker om produktet: Nåede vi i mål, i hvilken grad er kravene blevet opfyldt, hvad siger brugerne, som produktet var tænkt til, hvad blev anderledes end planlagt, var det samlet set en god ide eller hvad mere skal der til? Kort sagt: Hvad har vi lært.
Kilder og Litteratur
Meget vigtigt. Samme regler som for SOP: Så vidt muligt forfatter/rettighedshavers navn, dato for hentning (websider etc.) eller for udgivelse (trykte kilder, samt web hvis muligt), titel osv. Det gælder også kilder til kodestumper, man har brugt, illustrationer og datasæt.
Bilag
Rapporten skal kunne læses uden at læseren bruger bilagene, men de medtages som uddybende dokumentation.
- Den oprindeligt godkendte projektbeskrivelse skal sættes her, som det første. Obligatorisk.
- Egen kode sættes ind, formatteret som kode (IKKE ind i en brødtekst, så higlighting og indentering forsvinder)
- Baggrundsundersøgelser, fx spørgeskemaer og -resultater, interviews eller ekskursioner kan placeres her
- Fotoserier og wireframes fra udviklingsarbejdet, hvis der er mere end man fandt relevant inde i rapporten
- Datablade eller lignende fra komponenter og API’er man benytter i produktet
Links til andre beskrivelser af en teknikfagsrapport
På Systime findes en lærebog til faget, i den er der også et afsnit om rapporten (man skal være logget ind på Systime for at kunne læse det).
Mikkel (mkm) har et repo på GitHub, hvor der ligger en mere udførlig vejledning til rapporter i Digitalt Design.