Bar: /* Inspiration */

2024-11-19T20:21:36Z

Inspiration

← Ældre version		Versionen fra 19. nov. 2024, 22:21
Linje 42:		Linje 42:

	===Inspiration===		===Inspiration===
	Journalen kan indeholde nogle af følgende elementer, men ikke nødvendigvis i denne rækkefølge eller ~~ad-skilt~~ i disse afsnit, så dette kan blot tjene til inspiration, hvis man har svært ved at finde vinkler på hvad der kan dokumenteres.		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'''		'''Krav til løsningen'''
Linje 48:		Linje 48:

	'''Beskrivelse af løsningen'''		'''Beskrivelse af løsningen'''
	Her er dine overvejelser og analyse af hvordan programmet kan laves og dine ~~begrun-delser~~ for de valg, du har foretaget.		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.		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.
Linje 65:		Linje 65:
	Brugervejledning		Brugervejledning
	Hvis du mener det vil hjælpe læseren eller brugeren så kan du lave en egentlig brugervejledning.		Hvis du mener det vil hjælpe læseren eller brugeren så kan du lave en egentlig brugervejledning.


	===Test===		===Test===

Bar: /* Projektbeskrivelse */

2024-11-19T20:01:56Z

Projektbeskrivelse

← Ældre version		Versionen fra 19. nov. 2024, 22:01
Linje 25:		Linje 25:
	*Eventuelt en beskrivelse af hvem brugergruppen antages at være.		*Eventuelt en beskrivelse af hvem brugergruppen antages at være.
	*Den egentlige problemformulering, som er ret begrænset - typisk 20-30 ord.		*Den egentlige problemformulering, som er ret begrænset - typisk 20-30 ord.
	*En kravspecifikation, der opstiller de konkrete krav til ~~kvad~~ programmet skal kunne.		*En kravspecifikation, der opstiller de konkrete krav til hvad programmet skal kunne.
	*Eventuelt en problemafgrænsning.		*Eventuelt en problemafgrænsning.

Bar: /* Hovedindhold / dokumentation */

2022-10-13T20:14:09Z

Hovedindhold / dokumentation

← Ældre version		Versionen fra 13. okt. 2022, 22:14
Linje 34:		Linje 34:

	Så er der selve dokumentation af programmet, der gerne skal være hovedparten af rapporten, hvor man gerne skal overveje:		Så er der selve dokumentation af programmet, der gerne skal være hovedparten af rapporten, hvor man gerne skal overveje:
	*overordnet beskrivelse af programmet		*overordnet beskrivelse af programmet
	*[[datastruktur]]er / [[dataabstraktion]]		*[[datastruktur]]er / [[dataabstraktion]]
	*detaljeret dokumentation af dele af programmet ([[flowchart]], [[pseudokode]]),		*detaljeret dokumentation af dele af programmet ([[flowchart]], [[pseudokode]]),

Bar: Oprettede siden med "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..."

2022-10-12T07:23:23Z

Oprettede siden med "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..."

Ny side

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 kvad 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
*[[datastruktur]]er / [[dataabstraktion]]
*detaljeret dokumentation af dele af programmet ([[flowchart]], [[pseudokode]]),
*[[variabler]], [[objekt]]er, [[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 ad-skilt 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 begrun-delser 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å [[syntaksfarvning]]en 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.

[[media:javascript-rapport.pdf|Rapport/Journal om et program i javascript]], der kan lave en menu til hjemmesider, baseret på javascript og simple tekst-menu-punkter.

[[media:php-rapport.pdf|Rapport/Journal om et program i PHP]] er et program der implementerer nogenlunde den samme menu, blot med oplysningerne liggende i en database

[[media:spil-pascal.pdf|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ø.

[[media:eksempel-dokumentation.pdf|Rapport om et spil i Processing]] er en lidt nyere rapport, som har et lidt større omfang, og er skrevet i Processings programmeringsmiljø.

[[Media:Ur-dokumentation.pdf|Rapport om et Ur med TV-timer bygget omkring Arduino]] Rapporten har fokus på flere fags dokumentationstraditioner, Teknologi B, Programmering C og Teknikfag A

[[Kategori:Program Dokumentation]]

Eksamens Journal - Versionshistorie

Bar: /* Inspiration */

Bar: /* Projektbeskrivelse */

Bar: /* Hovedindhold / dokumentation */