Læs med her, og bliv klar til eksamen i Teknikfag – Digital design og udvikling på A- og B-niveau på EUX.
Mundtlig eksamen i Teknikfag – Digital design og udvikling på A-niveau (EUX)
Eksamen i Teknikfag A, Digital design og udvikling er en projektprøve, hvor du viser, at du kan omsætte idéer til fungerende digitale løsninger og dokumentere dine valg. Guiden giver dig et klart, søgevenligt overblik over prøveform, projektperiode, rapport, mundtlig prøve, bedømmelseskriterier, typiske spørgsmål samt konkrete eksempler på god opbygning af dine svar.
Prøveformen i teknikfaget
Prøven består af et afsluttende projekt med skriftlig rapport og et praktisk produkt eller et dokumenteret procesforløb. På baggrund af dette gennemføres en mundtlig prøve med eksaminator og censor, og der gives én samlet karakter på baggrund af en helhedsvurdering.
Projektoplægget – sådan kommer du i gang
Skolen udarbejder flere projektoplæg, der dækker fagets områder bredt, og du vælger herfra. Valget bliver bindende, når din projektbeskrivelse er godkendt. Emnerne spænder typisk over app- eller spiludvikling, interaktive læringsforløb, IoT og dataloggere, robotik og automatisering, intelligente byrum, dynamiske websystemer med database, AI-assistenter, visualisering i 2D/3D, samt overvågning og styring af energi og ressourcer.
I projektbeskrivelsen skal du kortlægge problemformulering, afgrænsning, kravspecifikation, tids- og handlingsplan, metoder, teknologivalg og plan for inddragelse af andre fag. Beskrivelsen kan justeres undervejs, hvis projektet udvikler sig – begrund ændringerne og dokumentér dem i rapporten.
Projektperioden – plan, fokus og fremdrift
Projektperioden omfatter normalt ca. 90 timers uddannelsestid fordelt over ca. otte uger. Den sidste uge er som udgangspunkt friholdt for anden undervisning, så du kan samle trådene og færdiggøre produkt og rapport.
Du tilknyttes en projektvejleder og forventes at udføre arbejdet selv. Det er en fordel at arbejde iterativt i korte sprint med faste leverancer: kravafklaring, prototype, test, forbedring. Dokumentér beslutninger løbende, så rapportskrivningen bliver hurtigere og skarpere.
Rapport og aflevering
Rapporten er din faglige dokumentation, og den afleveres sammen med produktet ved periodens slutning i henhold til skolens eksamensplan. Omfanget ligger typisk på 15–30 normalsider for en elev med +5–15 normalsider pr. ekstra gruppemedlem.
En stærk rapport er overskuelig og genbrugsklar. Det kan du støtte ved at strukturere den efter problem, metode, design, implementering, test, evaluering, konklusion og perspektiv. Husk klare figurer, skærmbilleder, arkitekturdiagrammer, ER- eller klassediagrammer, sekvensdiagrammer, samt bilag med kodeudsnit og testrapporter.
Den mundtlige prøve
Den mundtlige prøve tager udgangspunkt i rapporten og produktet/procesforløbet, og der er ingen forberedelsestid på selve dagen. Du må medbringe disposition, tegninger, slides, kodeudskrifter og noter.
En individuel eksamen kan disponeres sådan her for at sikre fokus og ro:
5–7 minutter: kort præsentation af problem, løsning og resultater
5 minutter: demonstration eller gennemgang af centrale design- og implementeringsvalg
15 minutter: faglig dialog og uddybende spørgsmål, herunder kernestof og perspektiv
3 minutter: votering (du er ikke til stede)
Ved gruppeprøver forkortes tiden pr. elev lidt, men alle skal kunne redegøre for hele projektet og vise ejerskab.
Typiske spørgsmål til prøven (med eksempler)
Spørgsmålene tester din evne til at analysere brugerbehov, definere krav, designe arkitektur, implementere og teste, samt reflektere over kvalitet, etik og sikkerhed. Nedenfor ser du hyppige spørgetyper og korte eksempler.
Problem, målgruppe og krav
Her forventes en klar rød tråd fra behov til løsning.
“Hvilket brugerproblem løser I, og hvordan har I afgrænset det?”
“Hvad er jeres vigtigste funktionelle og ikke-funktionelle krav?”
Eksempel: “Vi adresserer ustruktureret bogning i værkstedet. Must-have: brugerlogin, book/aflys, notifikation. Ikke-funktionelle: svartid < 300 ms, oppetid > 99 %, WCAG-principper for kontrast.”
Arkitektur og teknologivalg
Vis, at du kan begrunde dit stack- og designvalg.
“Hvorfor valgte I netop denne klient–server-arkitektur?”
“Hvordan håndterer I dataadgang, API’er og skalerbarhed?”
Eksempel: “Vi valgte en REST-baseret arkitektur med JSON, tre lag (UI, service, data). ORM for at reducere boilerplate og inputvalidering i API-gateway. Horisontal skalering via stateless services.”
Data- og domænemodellering
Hold det konkret med diagrammer og begrundelser.
“Hvordan ser jeres datamodel ud, og hvilke nøglerelationer er centrale?”
“Hvordan sikrer I dataintegritet?”
Eksempel: “ER-diagrammet har Bookning–Ressource som 1..* relation. Integritet sikres med constraints, transaktioner ved konflikter og unik indeks på tidsvindue pr. ressource.”
UI/UX og tilgængelighed
Du skal kunne koble designvalg til brugbarhed.
“Hvordan har I sikret høj brugervenlighed og WCAG-tilgængelighed?”
“Hvilke brugerundersøgelser testede I på?”
Eksempel: “Vi brugte ‘mobile-first’, mindst 4,5:1 kontrast, tydelig fokusmarkering og tastaturnavigation. Tre tænke-højt-tests afslørede uklare ikoner → ændret til tekstknapper.”
Test og kvalitetssikring
Knyt testtyper til risici.
“Hvilke testtyper anvendte I, og hvorfor?”
“Hvor fangede I den største fejl, og hvad lærte I?”
Eksempel: “Enhedstest for logik, integrationstest for API, manuel brugertest på prototypen. Største fejl var race condition i booking; løst med transaktioner og låsning.”
Ydelse, sikkerhed og dataetik
Vis risikoforståelse og konkrete tiltag.
“Hvordan håndterer I performance under belastning?”
“Hvilke sikkerhedsforanstaltninger har I valgt, og hvorfor?”
Eksempel: “Caching af læse-heavy endepunkter, lazy loading af lister. Sikkerhed: salted hashing, rate limiting, inputvalidering, logning af 4xx/5xx og privacystatement med dataminimering.”
Tværfaglighed og perspektiv
Her bindes fagene sammen.
“Hvilken viden fra matematik/fysik/teknologi har I brugt?”
“Hvordan kan jeres løsning skaleres eller overføres til andre domæner?”
Eksempel: “Algoritmisk planlægning (matematik) til konfliktfri tider, elektronik (teknologi) i RFID-læsning for check-in. Løsningen kan genbruges til lokaleudlån.”
Eksempler på god opbygning af dine svar
Det hjælper både dig og censor, når svar har en fast, klar struktur. Her er tre skabeloner, du kan læne dig op ad til meget forskellige spørgsmål.
Skabelon 1 – Krav → Løsning → Evidens → Effekt
Krav: “Systemet skal understøtte 200 samtidige brugere.”
Løsning: “Vi valgte reverse proxy og stateless API’er.”
Evidens: “Loadtest (bilag L) viser 230 req/s ved 95. percentil under 300 ms.”
Effekt: “Krav opfyldt med 15 % margin; kan skaleres horisontalt.”
Skabelon 2 – Alternativer → Begrundet valg → Risici → Afbødning
Alternativer: “Firebase, egen SQL-backend, no-code CMS.”
Begrundet valg: “SQL-backend pga. komplekse transaktioner.”
Risici: “DevOps-kompleksitet.”
Afbødning: “Docker-compose, backup-rutiner og logs.”
Skabelon 3 – Observation → Analyse → Beslutning → Dokumentation
Observation: “Brugere overså ‘Gem’-knappen.”
Analyse: “Lav kontrast og placering uden for ‘fold’.”
Beslutning: “Primær CTA øverst, høj kontrast, større hit-area.”
Dokumentation: “A/B-test i bilag U: fejlrate faldt fra 28 % til 6 %.”
Bedømmelseskriterier – det kigger lærer og censor på
Bedømmelsen sker som helhed af rapport, produkt/proces og mundtlig præstation efter 7-trinsskalaen. Det trækker op, når du tydeligt:
Arbejder problemorienteret og målrettet fra behov til løsning
Kombinerer teori og praksis i design, implementering og test
Dokumenterer kvalitet, fx gennem test, målinger og logiske argumenter
Præsenterer klart og viser ejerskab til hele projektet
Besvarer uddybende spørgsmål præcist og reflekteret
Perspektiverer til fagets emner og inddrager relevant viden fra andre fag
Karaktereksempler – 12, 7 og 02
12 (fremragende): Problem og målgruppe er skarpt afgrænset, arkitektur og teknologivalg er velbegrundede, produktet er robust, testet og dokumenteret, og fremlæggelsen er sikker og perspektiverende med få, uvæsentlige mangler.
7 (god): Målene opfyldes, men der er mangler i dokumentation eller dybde. Produktet fungerer overordnet, og fremlæggelsen er sammenhængende, men ikke helt sikker.
02 (tilstrækkelig): Minimumskrav er opfyldt. Rapporten er ujævn, produktet har tydelige mangler, og svarene under eksaminationen er usikre og delvise.
Forberedelse – trin for trin
En fokuseret proces giver ro til eksamen. Start med at sikre, at projektet kan gennemføres inden for tid og rammer, og arbejd i korte iterationer med tydelige mål.
Inden projektperioden:
Afklar problem, interessenter og succeskriterier i et kort notat
Vælg værktøjer og sæt versionsstyring op fra dag ét
Under projektperioden:
Arbejd i sprint: krav → prototype → test → forbedring
Få tidlige brugerreaktioner og ret hurtigt til
Log beslutninger og testresultater – de bliver til rapportens rygsøjle
Op til den mundtlige prøve:
Lav en 5–7 minutters pitch med tre hovedpointer: problem, løsning, effekt
Udvælg to tekniske nøgledetaljer, du kan forklare i dybden
Forbered korte, evidensbaserede svar efter skabelonerne ovenfor
På dagen:
Start med problemet og slut med dokumenteret effekt
Vis ejerskab: “Vi valgte… fordi… dokumenteret i bilag…”
Henvis roligt til figurer, diagrammer og testresultater i rapporten
Kort opsummering
Eksamen i Digital design og udvikling A (EUX) er en projektexamen med rapport, produkt og mundtlig prøve. Du bedømmes på sammenhængen mellem behov, design, implementering, test og refleksion. Med en skarp problemformulering, realistisk plan, gennemtænkt arkitektur og dokumenterede resultater står du stærkt – både i rapporten og til den mundtlige prøve.
Mundtlig eksamen i Teknikfag – Digital design og udvikling på B-niveau (EUX)
Eksamen i Teknikfag B, Digital design og udvikling er en projektprøve, hvor du viser, at du kan omsætte en konkret problemstilling til en fungerende digital løsning og dokumentere dine valg. Her får du et søgevenligt overblik over prøveform, projektperiode, rapport, mundtlig prøve, bedømmelseskriterier, typiske spørgsmål og eksempler på god opbygning af dine svar – alt i elevvenligt sprog.
Prøveformen i teknikfaget
Prøven består af et afsluttende projekt med skriftlig rapport og et praktisk produkt eller et dokumenteret procesforløb. På baggrund af projektet gennemføres en mundtlig prøve med eksaminator og censor. Der gives én samlet karakter ud fra en helhedsvurdering af rapport, produkt/proces og din mundtlige præstation.
Projektoplægget – sådan kommer du i gang
Skolen udarbejder flere projektoplæg, der tilsammen dækker fagets områder bredt, og du vælger herfra. Valget bliver bindende, når din projektbeskrivelse er godkendt. Emner kan fx være app- eller spiludvikling, interaktive undervisningsforløb, dataloggere/IoT, robotstyring og automatisering, digitale tjenester med database, AI-assistenter, 2D/3D-visualisering, overvågning/styring af energi, eller lyd/billedbehandling.
I projektbeskrivelsen bør du redegøre for problemformulering, afgrænsning, kravspecifikation, tids- og handlingsplan, valgte metoder og teknologier samt plan for inddragelse af andre fag. Hvis projektet udvikler sig, kan beskrivelsen justeres – begrund ændringerne og dokumentér dem i rapporten.
Projektperioden – plan, fokus og fremdrift
På B-niveau er projektperioden kortere, så koncentreret fremdrift er afgørende. Perioden rummer ca. 45 timers uddannelsestid fordelt over ca. fem uger, og den sidste uge er normalt friholdt for anden undervisning. Du tilknyttes en projektvejleder og forventes at udføre arbejdet selv.
En effektiv rytme er at arbejde i korte iterationer: krav → prototype → test → forbedring. Dokumentér beslutninger, designskitser, tests og læringspunkter løbende, så rapporten kan bygges op næsten “automatisk” til sidst.
Rapport og aflevering
Rapporten afleveres sammen med produktet ved projektperiodens afslutning iht. skolens eksamensplan. Omfanget er typisk 15–30 normalsider for én elev med +5–15 normalsider pr. ekstra gruppemedlem. Figurer, skærmbilleder, arkitektur- og datadiagrammer samt kodebilag/testrapporter er centrale dele af dokumentationen – henvis til dem i brødteksten.
En stærk rapport er overskuelig og anvendelig for andre. En praktisk struktur er: Problem og målgruppe → Krav → Løsningsdesign/arkitektur → Implementering → Test og kvalitet → Resultater og effekt → Konklusion og perspektiv.
Den mundtlige prøve
Den mundtlige prøve tager udgangspunkt i rapporten og produktet/procesforløbet, og der er ingen forberedelsestid på dagen. Du må medbringe disposition, slides, diagrammer, kodeudskrifter og noter.
En individuel eksamen kan disponeres sådan:
5–7 minutter: kort præsentation af problem, løsning og vigtigste resultater
5 minutter: demonstration eller gennemgang af centrale design-/implementeringsvalg
15 minutter: faglig dialog og uddybende spørgsmål, inkl. kernestof og perspektiv
3 minutter: votering (du er ikke til stede)
Ved gruppeprøve forkortes tiden pr. elev en smule, men alle skal kunne redegøre for hele projektet og vise ejerskab.
Typiske spørgsmål til prøven (med eksempler)
Formålet er at teste din evne til at forbinde brugerbehov, krav, design, implementering, test, etik/sikkerhed og perspektiv. Nedenfor ser du hyppige spørgetyper og korte eksempler.
Problem, målgruppe og krav
Her forventes en klar rød tråd fra behov til løsning.
“Hvilket brugerproblem løser I, og hvordan har I afgrænset det?”
“Hvad er jeres vigtigste funktionelle og ikke-funktionelle krav?”
Eksempel: “Vi løser dobbeltbooking af udstyr i værkstedet. Must-have: login, booking/aflysning, notifikation. Ikke-funktionelle: svartid <300 ms, tilgængelig navigation, enkel mobilvisning.”
Arkitektur og teknologivalg
Begrund stack og design simpelt og præcist.
“Hvorfor valgte I denne klient–server-arkitektur?”
“Hvordan håndterer I dataadgang og fremtidig skalering?”
Eksempel: “Tre-lags arkitektur (UI–service–data) med REST-API og JSON. ORM for færre fejl i databaseadgang og stateless services for let skalering.”
Data- og domænemodellering
Diagram + kort begrundelse er stærkt.
“Hvordan ser jeres datamodel ud, og hvilke regler sikrer dataintegritet?”
Eksempel: “ER-diagram: Bruger–Booking–Ressource. Integritet via fremmednøgler, unik indeks for tidsvindue pr. ressource og transaktioner ved konflikter.”
UI/UX og tilgængelighed
Knyt designvalg til brugbarhed.
“Hvordan har I sikret god brugervenlighed og tilgængelighed?”
Eksempel: “Mobile-first layout, tydelig fokusmarkering, kontrast ≥4,5:1 og tekstlabels i stedet for ikon-only. Tre tænke-højt-tests reducerede fejltrin på bookingflowet.”
Test og kvalitet
Vis at test matcher risici.
“Hvilke testtyper har I anvendt, og hvad viste de?”
Eksempel: “Enhedstest af book-/aflys-logik, integrationstest af API, hurtig brugertest på prototypen. Race condition fundet ved samtidige requests → løst med transaktioner og låsning.”
Ydelse, sikkerhed og dataetik
Omtal konkrete tiltag.
“Hvordan klarer systemet belastning, og hvordan beskytter I data?”
Eksempel: “Caching på læse-endepunkter, pagination og lazy loading. Sikkerhed via hashed passwords, inputvalidering, rate-limiting og dataminimering i logning.”
Tværfaglighed og perspektiv
Bind fagene sammen.
“Hvilken viden fra andre fag har I brugt?”
Eksempel: “Algoritmer og statistik fra matematik til planlægning og vurdering af spidsbelastning; teknologi/elektronik i RFID-check-in; samfundsfaglige overvejelser om dataetik.”
Eksempler på god opbygning af dine svar
Det hjælper både dig og censor, når svar følger en fast, klar struktur. Brug disse skabeloner efter behov.
Skabelon 1 – Krav → Løsning → Evidens → Effekt
Krav: “Appen skal håndtere 200 samtidige brugere.”
Løsning: “Reverse proxy og stateless API’er.”
Evidens: “Loadtest (bilag L) viser 230 req/s, 95%-percentil <300 ms.”
Effekt: “Krav opfyldt med ~15 % margin; skalerer horisontalt.”
Skabelon 2 – Alternativer → Begrundet valg → Risici → Afbødning
Alternativer: “Firebase, SQL-backend, no-code CMS.”
Begrundet valg: “SQL pga. transaktionskrav og konflikthåndtering.”
Risici: “Driftskompleksitet.”
Afbødning: “Containerisering, backup-rutiner, overvågning.”
Skabelon 3 – Observation → Analyse → Beslutning → Dokumentation
Observation: “Brugere overså ‘Gem’-knappen.”
Analyse: “Lav kontrast og dårlig placering.”
Beslutning: “Primær CTA øverst, større hit-area, tydelig label.”
Dokumentation: “A/B-test (bilag U): fejlrate faldt 28 % → 6 %.”
Bedømmelseskriterier – hvad trækker op
Der gives én samlet karakter efter 7-trinsskalaen på baggrund af en helhedsbedømmelse af rapport, produkt/proces og mundtlig præstation. Det trækker særligt op, at du:
Arbejder problemorienteret og kan begrunde valg og fravalg
Kombinerer teori og praksis i design, implementering og test
Dokumenterer kvalitet med målinger, test og klare argumenter
Præsenterer tydeligt og viser ejerskab til hele projektet
Besvarer uddybende spørgsmål præcist og reflekteret
Perspektiverer til fagets emner og inddrager relevant viden fra andre fag
Karaktereksempler – 12, 7 og 02
12 (fremragende): Problem og krav er skarpt defineret, arkitektur og teknologivalg er velbegrundede, produktet er robust, testet og veldokumenteret, og fremlæggelsen er sikker med få uvæsentlige mangler.
7 (god): Målene opfyldes, men der er huller i dokumentation eller dybde. Produktet fungerer overordnet, og fremlæggelsen er sammenhængende, men ikke helt sikker.
02 (tilstrækkelig): Minimumskrav er opfyldt. Rapporten er ujævn, produktet har tydelige mangler, og svarene under eksaminationen er usikre og delvise.
Forberedelse – trin for trin
En skarp proces er nøglen, især når tiden er kort på B-niveau. Tænk i små, leverbare skridt.
Inden projektperioden:
Afklar problem, målgruppe og succeskriterier i et kort notat
Vælg værktøjer og sæt versionsstyring op fra dag ét
Under projektperioden:
Kør korte iterationer: krav → prototype → test → forbedring
Hent tidlige brugerreaktioner og justér hurtigt
Log beslutninger og testresultater – de bliver til rapportens kernestof
Op til den mundtlige prøve:
Forbered en 5–7 min. pitch: problem → løsning → effekt
Udpeg to tekniske detaljer, du kan forklare i dybden
Øv svar efter skabelonerne under “Eksempler på god opbygning af dine svar”
På dagen:
Start med problemet og slut med dokumenteret effekt
Henvis roligt til figurer, diagrammer og bilag
Vis ejerskab: “Vi valgte… fordi… dokumenteret i bilag …”
Kort opsummering
Eksamen i Digital design og udvikling B (EUX) er en projektexamen med rapport, produkt og mundtlig prøve. Du bedømmes på sammenhængen mellem behov, design, implementering, test og refleksion. Med en stram plan, gennemskuelig dokumentation og god opbygning af dine svar står du stærkt til at levere en solid præstation.