Synopsis i Programmering

OBS !! : Der er ikke én fast facitliste, men baseret på struktur, som angivet i Programmering B-vejledning:

Synopsen skal:

• Give et overblik over projektets problemstilling og løsning
• Dokumentere programmets struktur, funktionalitet og faglige overvejelser
• Understøtte den mundtlige fremlæggelse
• Vise, at eleven kan reflektere over, hvad de har lavet og lært

Det er vigtigt, at synopsen ikke kun er kode, men at den forklarer tankerne bag programmet og viser, hvordan du arbejder med fagets mål — fx krav, design, test og refleksion.

• Omfang: 5-8 normalsider (kun tekst og pseudokode tæller med) resten, kode, billeder, data-tabeller og andre illustrationer tæller ikke med)

• Titel på projektet
• Elevnavn(e), Hold, fag og niveau
• Dato
• Antal normalsider
• Evt. et relevant billede af dit produkt.

• Kort beskrivelse (2-5 linjer) af, hvad projektet går ud på — hvad programmet er, og hvad det gør.
• (Abstrakt placeres på sin egen side, før indholsfortegnelse)

Det vigtigste i hele synopsen.

• Skal være et spørgsmål
• Skal være programmeringsfagligt
• Må gerne have underspørgsmål

• Hvad er formålet med projektet?
• Hvilke spørgsmål eller problemer vil du løse med programmet?
  • Fx: Hvordan kan jeg udvikle et spil, der…? eller Hvordan kan jeg automatisere X-opgaven med et program?
• Problemformuleringen skal være konkret og afgrænset, så det er klart, hvad du vil arbejde med.

Kravspecifikationen beskriver, hvad programmet skal kunne for at løse problemformuleringen. Kravene er formuleret i naturligt sprog og uden tekniske detaljer, så de kan forstås uden kendskab til koden.

• Kravspecifikationen omsætter problemformuleringen til konkrete testbare krav
• Her kan du spørge: Hvad skal programmet konkret kunne, hvis problemformuleringen skal besvares?

Kravene er opdelt i forskellige typer for at skabe overblik og tydelighed.

• Funktionelle krav beskriver, hvad programmet gør.
• Brugerkrav beskriver, hvordan brugeren interagerer med programmet.
• Output/feedback‑krav beskriver, hvilken feedback eller output programmet giver.
• Afgrænsningskrav beskriver, hvad programmet bevidst ikke indeholder.

Der skelnes desuden mellem krav, som programmet skal opfylde, og krav som er valgfrie. Bemærk her sprogbrug ift. 'skal', 'burde', 'kan'

Metoden opdeler krav i fire kategorier, efter MoSCoW metoden:

• Must have (Skal)
  • Krav der er helt nødvendige.
  • Uden dem kan projektet ikke gennemføres eller giver ingen værdi.
• Should have (Bør)
  • Vigtige krav, men ikke kritiske.
  • Projektet kan fungere uden dem, men med visse kompromiser.
  • Det er her der kan „skæres“ hvis situationen kræver det.
• Could have (Kunne have)
  • Nice-to-have funktioner.
  • De implementeres kun, hvis der er tid og ressourcer. (hvis M & S er implementeret)
• Won’t have (Vil ikke/skal ikke have)
  • Krav der bevidst udelades i denne omgang.
  • Kan evt. gemmes til fremtidige versioner.

Funktionsbeskrivelsen forklarer, hvad programmet gør set udefra. Den beskriver programmets funktionalitet, ikke dets kode eller tekniske opbygning. Man kan tænke den som en ”brugsforklaring” eller en systembeskrivelse i naturligt sprog.

• Programmets grundlæggende formål
• Bruger roller (bruger, moderator, admin, andre?)
• Use cases - formuler use‑cases på baggrund af kravspecifikationen for at få overblik over brugerens handlinger.
• Skærmlayout ved wireframes. (brug evt. draw.io Mockup-forms)

• I denne del kan der fx. indgå skærmbilleder, brugerhistorier, use cases.

I den tekniske dokumentation forklarer du, hvordan programmet er bygget. Du kan med fordel anvende et udvalg af nedestående metoder og diagram-former.

• Objekt Orienteret Analyse (OOA)
• UML-klassediagrammer
• Programstruktur (moduler, klasser, funktioner)
• Flowcharts, pseudokode
• Udvalgt relevant programkode med forklaring
• Angiv de metoder og teknikker du bruger
• ER-diagrammer for database struktur

• OBS!
  • Husk dine diagrammer/illustrationer må ikke stå alene, og forklares fyldestgørende med tekst.
  • Husk at forklare dine valg — fx hvorfor du valgte netop denne struktur eller algoritme.

Beskriv hvordan du har testet dit program:

• Testcases (hvad tester du?)
• Resultater af test
• Hvad virker/ikke virker — og hvorfor?

Dette viser, at du kan arbejde systematisk med kvalitetssikring.

• Kort opsummering af, hvad du har opnået i projektet i forhold til problemformuleringen.
• I hvilket omfang bekræfter dine tests din kravspecifikation.

Her kan du fx lægge:

• Projektbeskrivelse (oprindelig) - incl. tidsplan
• Hele koden (Hvis du har mere end 30 siders kode, så angiv et link til git repository istedet)
• Yderligere diagrammer
• Evt. ekstra tests
• Evt. revideret tidsplan

• Anvend lstlistings i LaTeX til kode blokke.
• Hvis du anvender Word brug da: Easy Code Formatter