====== Synopsis i Programmering ====== OBS !! : Der er __ikke__ én fast facitliste, men baseret på struktur, som angivet i Programmering B-vejledning: ===== Hvad er formålet med synopsen? ===== 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)// ---- ===== Indhold / Struktur ===== ===== Forside ===== * Titel på projektet * Elevnavn(e), Hold, fag og niveau * Dato * Antal normalsider * Evt. et relevant billede af dit produkt. ---- ===== Abstract / Kort resume ===== * 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) ---- ===== Problemformulering ===== 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. Problemformuleringen vil i høj grad ligne det du har i projektbeskrivelsen. Dine krav kan du med fordel udbygge og lave en dedikeret sektion/afsnit til disse, se kravspecifikation. ---- ===== Kravspecifikation (ikke angivet i vejledning) ===== 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. === Kravtyper === * **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' === Prioritering (MoSCoW) === Metoden opdeler krav i fire kategorier, efter MoSCoW metoden: * **M**ust have (**Skal**) * Krav der er helt nødvendige. * Uden dem kan projektet ikke gennemføres eller giver ingen værdi. * **S**hould 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. * **C**ould have (**Kunne** have) * __Nice-to-have__ funktioner. * De implementeres kun, hvis der er tid og ressourcer. (hvis **M** & **S** er implementeret) * **W**on’t have (Vil ikke/**skal ikke** have) * Krav der bevidst udelades i denne omgang. * Kan evt. gemmes til fremtidige versioner. ==== Oversigt over krav ===== ^ Id. ^ Kravtype ^ Prioritet ^ Krav ^ | K1 | Funktionelt | M | Programmet skal kunne modtage input fra brugeren | | K2 | Funktionelt | M | Programmet skal reagere på brugerens handlinger | | K3 | Output/feedback | M | Programmet skal give feedback i form af point | | K4 | Brugerkrav | M | Programmet skal kunne betjenes med mus | | K5 | Output/feedback | C | Programmet kan vise en highscore | | K6 | Afgrænsning | W | Programmet skal ikke gemme data permanent | ---- ===== Funktionsbeskrivelse ===== 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. Du kan med fordel starte din funktionsbeskrivelse ved at lave use case diagrammer over de interaktions muligheder brugeren har ift. jeres system. I kan lave arbejdesnoter som:\\ UC1: Bruger opretter udfylder bestilling, op klikker ok.\\ UC2: Bruger sletter bestillling.\\ UC3: Bruger Login\\ UC4: Bruger Logoff\\ etc.. ---- ===== Teknisk dokumentation ===== 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. Her kan det være en god ide at starte med en Objekt Orienteret Analyse (OOA) for at identificere de klasser, metoder og variable jeres system kan bestå af. ---- ===== Test og validering ===== 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. ---- ===== Konklusion ===== * Kort opsummering af, hvad du har opnået i projektet i forhold til problemformuleringen. * I hvilket omfang bekræfter dine tests din kravspecifikation. ---- ===== Bilag ===== 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 ==== Andet ==== * Anvend lstlistings i LaTeX til kode blokke. * Hvis du anvender Word brug da: [[https://marketplace.microsoft.com/en-us/product/office/wa104382008|Easy Code Formatter]]