Eksamens Journal

Til eksamen i programmering skal der afleveres et program der kan afvikles og programmets kildekode.

Dette program skal dokumenteres i en Eksamens Journal.

Struktur

Der er ikke en fast opskrift for hvordan en journal skal opbygges, men alligevel er der visse formelle krav som det er en god ide at opfylde.

Forside

Skal indeholde følgende: Titel, navn, klasse, Fag, Skole, dato, vejleder og evt. samarbejdspartner(e).

Indholdsfortegnelse

Kan godt udelades, når det kun er 10 sider, men vil give et godt overblik over projektets indhold.

Indledning

Dette afsnit kan indeholde forskelligt, alt efter hvilket program man arbejder med - er det fx et spil, så kan det bare være en kort indledning der siger at dette projekt går ud på at lave et kendt spil som fx Memory.

Hvis det er et mere specielt program som fx et program der anvendes i en helt speciel faggren som fx bioteknologi, hvor man kigger på arvelige egenskaber eller noget helt andet, så kan indledningen være et godt sted at beskrive hvorfor man interesserer sig for netop denne problemstilling.

Indledningen kan normalt være en god ide at have med, så censor kan herved orientere sig om opgavens indhold (skriv det til sidst, så du selv har overblikket).

Projektbeskrivelse

Dette kan begrænses til en Problemformulering, men man kan også udvide det:

• En problemanalyse hvor du begrunder og beskriver problemstillingen.
• Eventuelt en beskrivelse af hvem brugergruppen antages at være.
• Den egentlige problemformulering, som er ret begrænset - typisk 20-30 ord.
• En kravspecifikation, der opstiller de konkrete krav til hvad programmet skal kunne.
• Eventuelt en problemafgrænsning.

Hovedindhold / dokumentation

Her er der mange muligheder, som tit er bestemt af hvilket program man har lavet og hvor omfattende det er.

Man kan starte med en funktionsbeskrivelse, hvor man f.x. angiver skærmlayout, indtastningsmuligheder, funktionalitet – alt efter hvad det er for et program.

Så er der selve dokumentation af programmet, der gerne skal være hovedparten af rapporten, hvor man gerne skal overveje:

• overordnet beskrivelse af programmet
• datastrukturer / dataabstraktion
• detaljeret dokumentation af dele af programmet (flowchart, pseudokode),
• variabler, objekter, events
• databasestruktur, tabeller osv.
• centrale kode dele

Inspiration

Journalen kan indeholde nogle af følgende elementer, men ikke nødvendigvis i denne rækkefølge eller adskilt i disse afsnit, så dette kan blot tjene til inspiration, hvis man har svært ved at finde vinkler på hvad der kan dokumenteres.

Krav til løsningen Hvilke overordnede krav er der til løsningen. Tager i høj grad udgangspunkt i problemstilling og valg af brugergruppe.

Beskrivelse af løsningen Her er dine overvejelser og analyse af hvordan programmet kan laves og dine begrundelser for de valg, du har foretaget.

Her er også typisk en beskrivelse af processen. Det er fint hvis dine fejltagelser og blindgyder er med i beskrivelsen. Denne beskrivelse vil afspejle, om du har brugt top-down metoden.

Skærmbilledet Her står dine begrundelser for designet af formene. Her skal der være kopi af samtlige forme og en liste over samtlige væsentlige objekter på formene med navn, type, caption/tekst og eventuelle tilknyttede handlinger. Husk også at vise sammenhængen mellem formene.

Detaljer i løsningen Her beskriver du de mere komplicerede dele af din kode, typisk i form af pseudokode. Du skal beskrive samtlige selvlavede typer og alle sammensatte variable (f.eks. lister og poster).

Begrænsninger De begrænsninger du har valgt eller er blevet tvunget til at lægge på din løsning. Kendte fejl og uhensigtsmæssigheder.

Story-board Her er et typisk eksempel på hvordan du tænker dig at programmet vil blive betjent. Brugervejledning Hvis du mener det vil hjælpe læseren eller brugeren så kan du lave en egentlig brugervejledning.

Test

Endelig vil det være en god ide at beskrive en test af programmet. Her beskriver du hvordan du har testet programmet, hvilke situationer du har testet for og hvordan det gik.

En god ting i testen er at kigge på sin kravspecifikation - opfylder programmet de stillede krav?

Mange programmer kan være svære at teste, da de i princippet har uendeligt mange inputdata, så det er en god ide at overveje, om man tester sit program med det rigtige input, og i denne sammenhæng kan det godt være at forkerte eller underlige input er det rigtige at teste med, for at se om programmet har en fornuftig opførsel på underlige input.

Konklusion

Løser dit program problemformuleringen?

Dette afsnit skal kunne læses i forlængelse af problemformuleringen.

Hvad er lykkedes at lave, og hvilke dele er det ikke lykkedes at få til at virke.

evt. Perspektivering

Hvis man stadig har en del ideer om hvad der kunne laves, hvordan man kunne gøre det osv. så kan det være en god ide at have en perspektivering med, men det er ikke nødvendigt.

Kildeliste

Det er meget sjældent man programmerer helt fra bunden, uden at have søgt inspiration nogen steder.

Har man lånt kode-dele eller moduler fra nogle steder, så skal det naturligvis anføres i koden, men det skal også angives i kildelisten.

Desuden er det en god ide at angive hvilke sider man primært har brugt til hjælp / opslag.

Bilag

Det er godt at få koden placeret i bilag, da den muligvis ikke ville kunne indeholdes indenfor journalens 10 sider.

Når man kopierer koden ind, så sørg for at få syntaksfarvningen med over, så er koden langt mere læselig.

Eksempler

Dette er ikke nødvendigvis journaler, da der er dokumentationer fra forskellige faser i programmeringsfaget, men det kan give nogle ideer til hvordan man kunne dokumentere koden.

Rapport/Journal om et program i javascript, der kan lave en menu til hjemmesider, baseret på javascript og simple tekst-menu-punkter.

Rapport/Journal om et program i PHP er et program der implementerer nogenlunde den samme menu, blot med oplysningerne liggende i en database

Rapport om et spil i Pascal er en lidt ældre rapport, som har et lidt større omfang, og er skrevet til et DOS-baseret programmeringsmiljø.

Rapport om et spil i Processing er en lidt nyere rapport, som har et lidt større omfang, og er skrevet i Processings programmeringsmiljø.

Rapport om et Ur med TV-timer bygget omkring Arduino Rapporten har fokus på flere fags dokumentationstraditioner, Teknologi B, Programmering C og Teknikfag A