Del 1: Produktudvikling

SP1

Hvad er det primære formål med opportunity identification processen og hvad er de vigtigste output? Beskriv/eksemplificer hvordan man kan udføre processen.

En del af frontend, der er forkel på vores ide og en opportunity, Ide er en impulse, opportunity er markeds tilpasset.
En god opportunity skal overkomme en kvalitets barrier.
Disse opportunities kan komme internt eller eksternt fra.
Opprtunity horizons. Hensyn til Computeren
Horizont 1 = Små forbedringer
Horizont 2 = nye løsninger / teknologier, eller ramme et andet marked, som til børn.
Horizont 3 = Innovative løsninger, Iphone, Homeassistant, Computeren.

Step by step
Tragt formet, tournament
Step 1: Innovation Charter, / catagori
Balance mellem katagori størrelse og begænsning og overskuelighed.
Step 2: Idea Generation
Undersøge konkurrenter, nye teknologier, snakker med kunder, studerer markedet, find ulemper med nuværende product.
Step 3: Screen Ideas Fjern urimelige ideer, er dette faktisk muligt.
Step 4: Uddyb gode ideer Undersøge similare produkter, estimere markedet, hvordan kan dette egentligt udføres, små prototyber.
Step 5: Select Candidates
Sammenlign mellem criterier, og kan vi faktisk lave dette.
Output
Key product features, business goals.

Hvad ved jeg at jeg ikke ved, og hvad ved jeg

Er det radikalt nye produkter altid det bedste mål? Hvad er fordelen og ulempen ved radikalt nye produkter?

Ikke udnyttet marked, dyrer løsning / mere udvikling / Høj risiko, ikke bevidst marked.

SP2

Hvad kan vanskeliggøre indhentningen af customer needs? Hvorfor er indhentningen af disse et særligt vigtigt step i produktudviklingsprocessen?

Det er vigtigt at vide hvad kunderne har brug for, da i sidste ende er det kunderne der bestemmer om produktet skal have success.
Men det kan være svært da kunder ikke altid ved hvad de vil have, og hvem er dine kunder egentligt
Sætter udgangspunkt for kravspecifikationen.
4 steps Step 1 Gather Raw data
Intervies, focus grupper, observering a customers(Xbox kinect), Surveys
Der er forskel på kunder, den gennemsnitlige og elite kunder. Jeg er elite bruger af min laptop. Pas på elite brugerne. Brand loyalty. Interview guide, hvad er miljøet, go with the flow, hver objektiv, probs. Man får customer statements
Step 2 Interpret Data
Det vi gjorde efter at have snakket med christoffer. Omskrive og fortolke kunde statements til hvad produktet kan. Undgå løsnings mode. Undgå must and should. Ikke filtrer endnu.
Step 3 Organise Needs
Grupper statements, og sorter data. Ikke fjern modsigende statements endnu.
Step4 Prioritise Needs
Prioriter på baggrund af hvor mange gange det er blevet sagt.

Hvilke andre interessenter kunne være relevante at indhente krav til produktet fra? Hvordan vil du gøre det?

Konkurrenter(Hvad kan konkurrenterne), desk study, Lego, kunden er forældre, barn er bruger. Butikker og resellers, Hvad mener vi selv mangler intern

SP3

Hvilke typer af modularitet findes der for en modulær produktarkitektur? Giv et par eksempler fra konkrete produkter.

Platform modularitet. Noget produkter deler kan udvikles for sig selv. F.eks VW elbil platform, så batterierne er ens. AMD’s Chiplets, som bruges i alle produkter, fra bærbar til server. Fuldt modulær. Semi modulær (smartphones er godt eksempel) Integral. Helt integreret.
Slot-Modular (Smarphone) Ting kan connect 1 sted på det samlede produkt.
Bus-Modular (server/desktop er lidt begge) Alt forbindes til et samlet punkt / ens interface.
Sectional-Modular (Google tingen) Alle moduler er independent, Lego, ting kan stables.

Er en modulær produktarkitektur altid en fordel? Er det tilfælde hvor en integreret arkitektur er en fordel? Giv gerne eksempler.

integreret architecture kan give et “bedre” ende produkt, men kan komme med udviklings udfordringer. Men samtidigt kan modulær arkitektur gøre alle delene extra specialle da alle ikke behøver et overblik over hele løsningen. Mindre produkter. Modulær giver et formt for overhead, ligesom Object orienteret også kan gøre. eksempel (Ram slots er modulære, men har højere latens og laver clock speeds). Fordel er at man kan nemt customize til bestemt cusomer.

SP4

I kurset har vi anvendt en ”screening & scoring” matrix til at udvælge et endeligt koncept. Hvad er styrken ved denne metode? Hvad kunne alternative metoder være til at vælge et koncept?

Et godt koncept men dårligt udført kan være sucess, men dårligt koncept er altid dårligt.
Del produktet op i funktioner / behov(Bilen interrior behøves ikke at hænge sammen med motoren).
Blackbox, Input & output, og hvad sker der så i denne kasse?.
Hvordan bliver dette i kassen så gjort, teknisk specifikt. Undersøg eksiterende løsninger, snak med experter, undersøg specifikke technologier.
Undersøg internt, technologisk, og brug de egenskaber gruppe medlemmerne har.
Disse koncepter kan så blive valgt ved screening & scoring.
steps = Prepare matrix - Rate - Rank - Combine(Merge nogle gode ting man opdager undervejs) - Select:
Tag udgangpunkt i 1 koncept, sæt til lig 0, og sammenlign anre koncepter i forhold til dette.
Nu kan vi vægte værdierne, og derfor prioritere.
Scoring og vægtning kan hurtigt vægte ting mod preferrencer.
Det er vigtigt at have tænkt over vægtende, og ikke ændre vægtende for at prioritere andet produkt.
Kræver en god analyse af features, og krav.
På dette tidpunkt kan det være svært at vurdere hvad man bør scorer de forskellige koncepter.
Alternativ, Vi begyndte at arbejde på forskellige ting samtidigt, og løbende estimere løsninger.

Hvad kunne du gøre for at øge troværdigheden af de enkelte scorer i matrixen?

Understøtte dem med kilder og argumentationer, eller basere dem på customer needs undersøgelser.
Få kunder til at score koncepterne, og give deres mening på det.

SP5

Hvad er fordelene ved at følge en struktureret metode til produktudvikling? Hvad risikerer man ved ikke at gøre det?

Man risikerer at man ender ud med et produkt der ikke lever op til kravene, eller ikke har nogle kunder.
mere… SP5 – Struktur i produktudvikling Hvad er fordelene ved at følge en struktureret metode til produktudvikling? Hvad risikerer man ved ikke at gøre det?

Fordele:

Målrettethed og fokus – En struktureret metode sikrer, at man arbejder mod klart definerede mål, såsom kundebehov, tekniske krav og forretningsmål.

Tids- og ressourceeffektivitet – Ved at følge faser som behovsanalyse, konceptudvikling, prototype og test undgår man spildarbejde.

Bedre kommunikation i teamet – Struktur giver et fælles sprog og forventningsafstemning i tværfaglige teams.

Dokumentation og læring – Man skaber sporbarhed og mulighed for evaluering og forbedring til fremtidige projekter.

Kundecentrering – En god metode (f.eks. Stage-Gate, V-model eller Ulrich & Eppinger) inkluderer kundebehov i processen, hvilket øger chancen for succes på markedet.

Risici ved ikke at følge en struktureret metode:

Udvikling af et produkt uden marked (ingen efterspørgsel).

Fejl og omarbejdning pga. manglende kravspecifikationer.

Manglende integration mellem delsystemer.

Uklare roller og ansvar → dårlig teamkoordinering.

Projektet løber løbsk i tid og budget. ### Hvad er nogle af de største faldgrupper som produktudviklingsteam i forbindelse med processen? Tech-demoer i stedet for rigtige produkter
– Fokus på teknologi frem for brugerbehov. Det kan føre til, at man laver noget "smart", som ingen har brug for.

Springe behovsanalysen over
– Mange teams går direkte til løsning, uden at forstå kundens egentlige problemer. Det fører ofte til forkerte løsninger.

Dårlig kravspecifikation
– Uklare eller ikke-prioriterede krav giver konflikt senere i projektet, især ved test og implementering.

Ingen iterativ test og feedback
– Man udvikler hele produktet uden at teste det løbende. Så opdager man fejlene for sent og må redesigne.

Manglende involvering af relevante interessenter
– Hvis marketing, produktion eller kunder ikke inddrages, kan man ende med et produkt der er svært at sælge eller producere.

For lidt dokumentation
– Uden tilstrækkelig dokumentation kan man ikke overlevere viden, og fremtidig vedligehold bliver svær.

Scope creep
– Projektets mål udvides hele tiden uden kontrol, så man mister fokus og overskrider budget og tid.

Del 2: Kravsspecifikation og system design.

SP6

Hvad er et use case diagram? Hvilke elementer består det af? Hvad bruger man det til? Hvornår anvender man use case diagrammer? Tegn eller vis eksempel/eksempler.

Hvad er et use case diagram?

Et use case-diagram viser aktører (brugere eller andre systemer) og deres interaktioner (use cases) med systemet. Det beskriver funktionerne (use cases), som systemet skal levere, og hvordan brugerne interagerer med dem.
Hvilke elementer består det af?

System (grænse) – Angivet som en rektangulær boks, der indeholder use cases. Det er dét system, man beskriver.

Use case (brugssituation) – En oval der beskriver en funktion (f.eks. "Log ind", "Bestil produkt").

Aktør (actor) – En stick-figur, der repræsenterer en bruger eller andet system, der interagerer med systemet.

Relationer:

Association (linje): Forbindelse mellem aktør og use case.

Include: Angiver at en use case altid inkluderer en anden.

Extend: Angiver at en use case nogle gange udvides med en anden, fx afhængigt af betingelser.

Hvad bruger man det til?

Få overblik over funktionelle krav til et system.

Kommunikere med interessenter (brugere, kunder, udviklere).

Dokumentere brugerbehov og systemets forventede opførsel.

Analyse og design af software og interaktionsflow.

Hvornår anvender man use case-diagrammer?

Tidligt i kravspecifikationsfasen i systemudvikling.

Under analyse og design.

Når man vil visualisere brugerinteraktioner og sikre, at alle funktioner er dækket.

Som supplement til user stories og funktionelle krav ### Hvad er en use case beskrivelse? Hvad er vigtigt i en sådan beskrivelse? Hvordan relaterer disse sig til krav specifikationerne? Hvornår udarbejder man beskrivelserne? Hvem udarbejder dem? Giv eksempler. **Hvad er en use case-beskrivelse?**

En use case-beskrivelse er en tekstuel (detaljeret) beskrivelse af, hvordan en aktør interagerer med systemet for at opnå et bestemt mål. Hvor use case-diagrammer viser overblik, går beskrivelsen i dybden med trin-for-trin scenarier. Hvad er vigtigt i en use case-beskrivelse?

En god use case-beskrivelse indeholder typisk følgende elementer:  
Felt	Beskrivelse  
Navn	Kort og præcis titel (f.eks. "Log ind")  
Mål	Hvad aktøren ønsker at opnå  
Primær aktør	Den bruger eller system der initierer use casen  
Interessenter og behov	Hvem har interesse i funktionen og hvorfor  
Forudsætninger	Hvad skal være opfyldt før handlingen starter  
Efterfølgende tilstand	Hvad er opnået, hvis use casen lykkes  
Hovedforløb (normal flow)	De vigtigste trin i interaktionen  
Alternative forløb / Undtagelser	Hvad sker der, hvis noget går galt eller afviger  
Frekvens (valgfrit)	Hvor ofte use casen typisk forekommer   **Hvordan relaterer use case-beskrivelser sig til kravspecifikationer?**

Use case-beskrivelser konkretiserer funktionelle krav fra kravspecifikationen.

De fungerer som en slags bro mellem overordnede krav og teknisk design.

Gør det nemt at teste og verificere, om krav er opfyldt (basis for test cases).

Hjælper med at prioritere funktionalitet baseret på brugerens behov.

Hvornår og af hvem udarbejdes de?

Spørgsmål	Svar
Hvornår?	I krav- og analysefasen – gerne før design og kodning starter.
Hvem?	Typisk systemanalytikere, UX-designere, eller produktudviklere – ofte i samarbejde med kunden eller slutbrugere.
✏️ Eksempel på use case-beskrivelse

Use case: Bestil produkt

Mål: Kunden ønsker at bestille et produkt online.

Primær aktør: Kunde

Interessenter: Kunden (hurtig levering), webshop (salg), lager (ordrebehandling)

Forudsætning: Kunden er logget ind og har fundet et produkt.

Efterfølgende tilstand: Ordren er registreret og bekræftet.

Hovedforløb:

Kunden klikker på "Køb" på produktet.

Systemet viser kurven og totalbeløb.

Kunden klikker på "Gå til betaling".

Kunden indtaster leverings- og betalingsoplysninger.

Kunden klikker "Bekræft".

Systemet validerer oplysningerne og opretter ordren.

Kunden får bekræftelse på ordren.

Alternative forløb:

4a. Kunden vælger at betale med MobilePay.

6a. Hvis betaling mislykkes → system viser fejl og beder om ny metode. ## SP7 ### Hvad karakteriserer gode krav? Giv eksempler på gode og dårlige krav. Hvor i V-modellen finder vi hvilke typer af krav? Med hvem udarbejder vi krav og på hvilke måde sikrer vi at vi får samtlige vigtige krav med i kravspecifikationen? **Hvad karakteriserer gode krav?**

Gode krav skal være:

Kvalitet	Forklaring
Entydige	Kravet skal kun kunne forstås på én måde (ingen tvetydighed).
Testbare / Verificerbare	Det skal være muligt at afprøve, om kravet er opfyldt.
Nødvendige	Kun krav, der har reel værdi for systemet eller brugeren.
Tydelige og præcise	Ikke vage begreber som "hurtig", "let" eller "bedre".
Sporbare	Man skal kunne se, hvor kravet stammer fra (f.eks. en kundeanmodning).
Konsistente	Krav må ikke modsige hinanden.

Eksempler på gode og dårlige krav

Dårligt krav	Hvorfor dårligt	Godt krav (forbedret)
"Systemet skal være hurtigt."	Uklart, subjektivt	"Systemet skal svare inden for 1 sekund i 95 % af alle tilfælde."
"Brugeren skal nemt kunne oprette en profil."	Ikke målbart	"Brugeren skal kunne oprette en profil via en formular med maks. 5 felter."
"Appen skal være moderne."	For vag og upræcis	"Appen skal følge Android Material Design 3 retningslinjer."

Hvor i V-modellen findes kravene?

V-modellen beskriver systemudvikling som en proces, hvor hver fase på venstresiden har en tilsvarende testfase på højresiden. Krav findes på venstresiden i starten af udviklingen: Fase i V-modellen Type krav Brugerbehov (toppen) Overordnede forretnings- og brugerkrav Systemkrav Funktionelle og ikke-funktionelle krav Designkrav Tekniske specifikationer for hvordan kravene opfyldes

På højresiden verificeres kravene gennem test: systemtest, integrationstest, enhedstest – baseret direkte på kravene. Med hvem udarbejder vi krav?

Krav udarbejdes i samarbejde med:

Slutbrugere / kunder – deres behov og ønsker er fundamentale.

Forretningsanalytikere / produktledere – oversætter behov til krav.

Udviklere / arkitekter – vurderer realiserbarhed.

Testere – sikrer at krav kan testes.

UX-designere – bidrager til brugervenlighedskrav.

Hvordan sikrer vi, at vi får alle vigtige krav med?

Workshops & interviews med interessenter.

Observationer & kontekstuel analyse – se hvordan nuværende systemer bruges.

Brainstorming og kravindsamlingsteknikker (f.eks. MoSCoW, Kano).

Use cases og user stories – hjælper med at identificere funktionelle krav.

Prototyper og mockups – skaber feedback og afdækker oversete krav.

Sporbarhedsmatrix – kobler krav til test, design og forretningsmål. ### Hvilke krav har vi til vores kravspecifikation? Hvordan sikrer vi at krav til krav er opfyldt? Hvordan bruger vi krav i efterfølgende udviklingsproces? Hvordan forholder vi os til at skulle lave ændringer i krav i de efterfølgende tidsperioder i en udviklingsproces f.eks. hen mod slutningen af projektet? Giv eksempler. Hvilke krav har vi til vores kravspecifikation?

En kravspecifikation skal være:

Krav til kravspecifikationen	Beskrivelse
Komplet	Alle relevante funktionelle og ikke-funktionelle krav skal være med.
Entydig	Hvert krav skal kun kunne forstås på én måde.
Testbar	Det skal være muligt at verificere hvert krav.
Sporbar	Hvert krav skal kunne spores til kilder (behov, interessenter) og til test, design og kode.
Struktureret og prioriteret	Kravene skal være velorganiserede og eventuelt prioriteret (f.eks. MoSCoW: Must, Should, Could, Won’t).
Versionsstyret	Man skal kunne følge ændringer over tid (hvem ændrede hvad og hvornår). **Hvordan sikrer vi, at “krav til krav” er opfyldt?**

Review og godkendelse
– Gennemgå kravene med interessenter og få dem godkendt. Brug evt. checklister (f.eks. IEEE-830).

Sporbarhedsmatrix
– Kortlæg alle krav til relaterede designbeslutninger og testcases.

Brug af skabeloner og værktøjer
– Kravspecificeringsværktøjer (f.eks. Jira, IBM DOORS) hjælper med konsistens, dokumentation og versionsstyring.

Testbarhedsanalyse
– Involvér testere tidligt: “Kan dette krav testes?” Hvis ikke, skal det omskrives.

Roller og ansvar
– Tydelige ejere af kravene sikrer ansvar for indhold og ændringer.

Hvordan bruger vi krav i den efterfølgende udviklingsproces?

Kravene er fundamentet for hele udviklingsprocessen:
Procesfase	Brug af krav
Design	Udviklere og arkitekter bruger krav til at beslutte systemets struktur og komponenter.
Implementering	Kode baseres på funktionelle krav.
Test	Testcases laves ud fra krav (accepttest, systemtest).
Verifikation og validering	Bruges til at afgøre, om det udviklede system matcher krav og behov.
Dokumentation og overlevering	Krav dokumenterer, hvad systemet skal kunne – bruges til support og videreudvikling. **Hvordan håndterer vi ændringer i krav sent i udviklingsforløbet?**

Ændringer sker ofte – men sent i processen er de dyrere og risikofyldte. Sådan håndteres det:

Change Request-proces
– Formaliseret måde at foreslå, evaluere og godkende ændringer.

Impact analysis
– Hvad påvirker ændringen? Tid, test, funktionalitet, afhængigheder? Dette vurderes før godkendelse.

Sporbarhed
– Man kan hurtigt identificere, hvilke komponenter og testcases der berøres.

Kommunikation
– Informér hele teamet om ændringer (dev, test, design, kunde).

Agile eller iterativ udvikling
– Hvis muligt: arbejd i iterationer, så krav kan justeres løbende med mindre risiko.

Eksempler på ændringer i krav og deres konsekvenser
Ændring i krav Konsekvens Håndtering “Brugeren skal kunne betale med MobilePay” tilføjes sent Integration med ny betalingsgateway → ekstra udvikling og test Change request, teknisk vurdering, planjustering
Ændring af svartid fra 2 sek til 0.5 sek Kræver optimering af backend og database Reprioritering af performancefokus, evt. delvis opfyldelse
Krav om at systemet skal virke offline Ændrer hele arkitekturen Overvej version 2, lav business case for værdi/kost

SP8

Hvordan deler man effektivt krav op i funktionelle moduler? Hvad definerer et modul? Hvad kan vi bruge modulariseringen til? Giv eksempler, gerne på tavle.

Hvordan deler man krav op i funktionelle moduler?
Grundidé:

Du opdeler systemet i mindre funktionelle enheder (moduler), som hver især dækker ét specifikt område af funktionaliteten. Metode:

Identificér hovedfunktioner / use cases
– Hvad skal systemet kunne?

Gruppér relaterede krav
– Krav, der hører sammen funktionelt, samles.

Opdel efter ansvar og grænseflader
– Hvert modul skal have et klart ansvar og minimalt overlap.

Overvej brugerroller og systemaktører
– Hvad har forskellige brugere brug for at gøre? Dette guider opdelingen.

Hvad definerer et modul?

Et modul er:
Egenskab	Forklaring
Afgrænset funktionelt område	Løser én tydelig opgave (f.eks. "Brugerhåndtering")
Indeholder relaterede krav og funktioner	F.eks. "Login", "Opret bruger", "Nulstil adgangskode"
Har en veldefineret grænseflade (API eller UI)	Moduler kommunikerer gennem veldefinerede kald eller skærme
Kan udvikles og testes uafhængigt	Gør teams mere effektive og reducerer kompleksitet

Hvad kan vi bruge modularisering til? Fordel Beskrivelse
✅ Overblik Krav bliver lettere at forstå og styre
✅ Genbrug Moduler kan genbruges i andre projekter
✅ Parallelt arbejde Teams kan arbejde på forskellige moduler samtidigt
✅ Fejlisolering Fejl lokaliseres hurtigere
✅ Ændringer bliver lettere Ændringer i ét modul påvirker ikke hele systemet
✅ Skalerbarhed Systemet kan lettere vokse med nye funktioner

Hvad er en grænseflade? Hvordan bliver man enig om en grænseflade? Hvem er involveret i at definere grænseflader? Hvilke fordele/ulemper er der ved at definere grænseflader tidligt/sent i et projektforløb? Giv eksempler

Typer af grænseflader:

Type	Eksempel
Teknisk grænseflade	API mellem backend og frontend
Fysisk grænseflade	Stikforbindelse, skærm, knap
Brugergrænseflade (UI)	App-skærmbilleder, menuer, formularer
Procesgrænseflade	Overlevering mellem to teams eller systemer i et workflow **Hvordan bliver man enig om en grænseflade?**

Identificér behov og afhængigheder
– Hvad har de to parter brug for fra hinanden?

Samarbejde og kommunikation
– Design, software, hardware, test og brugerrepræsentanter skal involveres.

Brug specifikationer og diagrammer
– Brug f.eks.:

    Interface-specifikationer (API-dokumenter, wireframes)

    Sekvensdiagrammer, I/O-skemaer

Prototyper og mockups
– Visualisering af interaktion hjælper parterne med at forstå grænsefladen.

Hvem er involveret i at definere grænseflader?

Rolle	Bidrag
Systemarkitekt	Fastlægger overordnede tekniske grænseflader
Softwareudviklere	Definerer f.eks. API’er mellem komponenter
Hardwareudviklere	Ved fysiske grænseflader (sensorer, knapper, porte)
UX-designere	Ved brugergrænseflader (UI)
Testere	Sikrer at grænsefladen kan testes og valideres
Kunder/brugere	Ved brugerinteraktion eller systemintegration
⏱️ Fordele og ulemper ved tidlig/sen definition
Timing	Fordele	Ulemper
Tidlig	- Gør parallel udvikling muligt
- Giver klar struktur
- Giver testmuligheder tidligere	- Risiko for ændringer senere
- Kan låse fast i et forkert design
Sen	- Mere viden og erfaring
- Bedre tilpasning til reelle behov	- Forsinker udvikling
- Skaber afhængigheder og flaskehalse
- Øget risiko for misforståelser **Eksempler** **Teknisk eksempel (software):**

Et API mellem en webshop-frontend og backend:

    Grænsefladen definerer kald som: GET /products, POST /checkout

    Frontend- og backendteams arbejder parallelt, fordi grænsefladen er defineret tidligt

Fysisk eksempel (produktdesign):

En elektrisk motor med en standardiseret stikforbindelse til styring:

    Grænsefladen er stiktypen + datasignaler

    Motor og styringsmodul kan udvikles hver for sig

Brugergrænseflade:

En app har et loginmodul, som leverer brugerinfo til resten af systemet

    UI og backend skal blive enige om: Hvilke felter vises? Hvad sendes?

Del 3: Implementering og test

SP9

Hvad er kodestil og kodestruktur? For hvem er dette vigtigt? Hvad har I gjort i jeres projekt? Hvordan bliver man enige om f.eks. brug af white space eller tab’s? Giv eksempler på forskellige kodestilarter der kan øge læsevenligheden, og eksempler på det modsatte (der mindsker læsevenligheden).

Hvad er kodestil og kodestruktur? Kodestil

Kodestil handler om hvordan koden ser ud – det visuelle og sproglige udtryk. Det dækker fx:

Brug af indrykning (tabs vs. spaces)

Navngivning af variabler og funktioner (camelCase, snake_case)

Brug af mellemrum og linjeskift

Kommentarstil og placering

Placering af {} i funktioner og kontrolstrukturer

Eksempel på to forskellige kodestile i JavaScript:

// Kodestil 1 (kompakt, men lidt sværere at læse)
function add(a,b){return a+b;}

// Kodestil 2 (mere læsbar)
function add(a, b) {
  return a + b;
}

Kodestruktur

Kodestruktur handler om hvordan koden er organiseret logisk:

Filstruktur (mappestruktur)

Moduler og komponenter

Funktionsopdeling (små, genanvendelige funktioner)

Separation of concerns (logik adskilt fra præsentation og data)

Eksempel:

projekt/
├── controllers/
│   └── userController.js
├── models/
│   └── userModel.js
├── routes/
│   └── userRoutes.js
└── app.js

For hvem er dette vigtigt?

For hele teamet: Giver fælles sprog og færre misforståelser.

For fremtidige udviklere: Koden bliver nemmere at vedligeholde.

For review og samarbejde: Gør kodegennemgang hurtigere og mere effektiv.

For test og debugging: En ensartet stil gør det nemmere at finde fejl.

💬 Hvordan bliver man enige om stil (fx tabs vs. spaces)?

Læg fælles retningslinjer fra starten:

    Brug fx Google Style Guide, Airbnb JS Guide, PEP8 (Python) osv.

Automatisér med linters og formateringsværktøjer:

    Eksempler: ESLint, Prettier, Black (Python), clang-format

Lav en README.md eller CONTRIBUTING.md med stilregler

Brug Git pre-commit hooks til at tjekke stil før kode pushes

✅ Eksempler på god kodestil (læsevenlig)

def calculate_total(price, tax_rate):
    """Calculate total price including tax."""
    return price * (1 + tax_rate)

Klar funktion

Gode navne

Kommentar (docstring)

Lige mellemrum

❌ Eksempler på dårlig kodestil (ulæselig)

def ct(p,t):return p*(1+t)

Dårlige navne

Ingen mellemrum

Ingen kommentar

Alt på én linje kamelCase, navngivning, function størrelse, nasa's krav. Vi havde både python og C++, python blev tjekket via github action, c++ var mere skrevet så det man skrev lignede det der allerede stod. Manglede generelt måske lidt konsistens. ### Hvad er objekt orienteret programmering? Hvad er en klasse i forhold til et objekt? Hvad er et klassediagram? Tegn gerne et simpelt et på tavlen og diskuter ud fra det tegnede diagram. **Hvad er objektorienteret programmering (OOP)?**

Objektorienteret programmering er en programmeringsparadigme, hvor man strukturerer kode omkring objekter, som repræsenterer ting, begreber eller enheder i virkeligheden. Nøgleprincipper i OOP:

Princip	Forklaring
Indkapsling	Data og funktioner gemmes sammen i objekter
Arv	En klasse kan arve egenskaber fra en anden
Polymorfi	Objekter kan opføre sig forskelligt, selvom de deler samme interface
Abstraktion	Skjuler kompleksitet og viser kun nødvendig information **Hvad er en klasse og et objekt?**
Begreb	Forklaring
Klasse	En skabelon eller blueprint for at lave objekter
Objekt	En konkret instans af en klasse med sine egne data

Eksempel i Python:

class Dog:               # Klasse
    def __init__(self, name):
        self.name = name

    def bark(self):
        print(f"{self.name} says woof!")

my_dog = Dog("Fido")     # Objekt (instans af klassen)
my_dog.bark()            # Output: Fido says woof!

Hvad er et klassediagram?

Et klassediagram er en grafisk måde at vise klasser og deres relationer på. Det er en del af UML (Unified Modeling Language) og bruges i designfasen. Klassediagrammet viser:

Klasser

Attributter (datafelter)

Metoder (funktioner)

Relationer mellem klasser (arv, association, komposition osv.)

Tegn et simpelt klassediagram på tavlen Eksempel: Et system med Person og Student

+————–+ | Person | +————–+ | - name | | - age | +————–+ | + greet() | +————–+ ▲ | inherits | +————–+ | Student | +————–+ | - studentID | +————–+ | + study() | +————–+

Forklaring:

Person er en superklasse

Student arver fra Person

Student har en ekstra attribut og metode

greet() findes i Person og kan bruges af Student ## SP10 ### Hvad er white boks test? Hvornår anvender vi white boks test og i hvilke sammenhæng. Hvad er en path test og hvorfor er en 100% path testing stort set altid umulig at gennemføre? Tegn et flowgraph diagram på tavlen og forklar hvad en branch test er **Hvad er white-box test?**

White-box test (eller strukturtest) er en testmetode, hvor man tester et programs interne struktur og logik. Man kigger ”ind i koden” og bruger sin viden om, hvordan programmet er bygget. Formålet:

Teste alle logiske grene og kontrolstrukturer

Sikre at alle veje i koden fungerer som forventet

Afsløre fx:

    Ubrugte kodelinjer

    Fejl i loops og betingelser

    Forkert håndtering af kanttilfælde

Hvornår bruger man white-box testing – og i hvilke sammenhænge? Bruges typisk ved Eksempler
Unit testing Test af enkeltfunktioner
Integration testing Når moduler integreres og man vil teste flow mellem dem
Ved kritisk kode F.eks. sikkerhed, beregning, pengeoverførsel
Automatiseret test Fx med værktøjer som JUnit, Pytest, osv.

White-box testing bruges tidligt i udviklingen af udviklere og QA, og supplerer black-box tests (som kun ser på input/output uden at kende koden).

Hvad er path testing?

Path testing handler om at teste forskellige stier igennem et program – altså de mulige kørselsforløb gennem kontrolstrukturen.
Eksempel:

Hvis en funktion har en if-else og et while-loop, kan der være mange forskellige måder, koden kan køres på afhængigt af input.
Hvorfor er 100% path testing næsten umuligt?

Antallet af mulige stier vokser eksponentielt med antal beslutninger

Nogle stier kan være umulige at nå pga. logik

Loops med forskellige antal gentagelser giver uendelige kombinationer

Det ville kræve enormt mange testcases og være for tidskrævende

Hvad er en branch test?

Branch testing er en simplere form for path testing:

Her tester man, at alle grene (branches) i programmet bliver kørt mindst én gang

Dvs. hver if, else, case, while, osv. bliver aktiveret i en test

Branch testing sikrer, at alle beslutningspunkter i programmet testes.
Tegn et simpelt flowgraph diagram (til tavle):
Kodeeksempel:

def check(value):
    if value > 0:
        print("Positive")
    else:
        print("Non-positive")

Flowgraph diagram:

[Start] | (1) | [value > 0] /
(2) (3) | | [print P] [print NP] \ / (4) [Slut]

Forklaring:

(1): Start af funktion

(2): Gren for value > 0

(3): Gren for else

(4): Samlet slutpunkt

For branch test skal du have mindst:

    Ét test input hvor value > 0

    Ét test input hvor value <= 0 ### Hvad er debugning? Hvordan bruger man en debugger (princippet)? Hvornår bruger man en debugger? Forklar ud fra et af de tre kodestumper givet på moodle, hvordan du vil white boks teste koden. Vis gerne på laptop hvis du har den med. **Hvad er debugging?**

Debugging er processen, hvor man finder og retter fejl (bugs) i sin kode. Det kan både være syntaksfejl, logiske fejl, runtime-fejl eller uventet adfærd. Målet:

Forstå hvor og hvorfor noget går galt

Identificere årsagen og ikke kun symptomet

Lave rettelser, så koden opfører sig korrekt

Hvordan bruger man en debugger? (princip)

En debugger er et værktøj, der gør det muligt at køre koden trin for trin, observere værdier og indsætte breakpoints.
Typiske funktioner i en debugger:
Funktion	Beskrivelse
Breakpoint	Pause i koden – her stopper eksekveringen
Step over	Kører næste linje kode, men hopper over funktionkald
Step into	Går ind i en funktion og viser dens kode
Step out	Hopper ud af en funktion igen
Watch/Inspect	Se værdien af variabler live
Call stack	Viser hvilke funktioner, der er kaldt, og i hvilken rækkefølge
Debuggere findes i fx:

VS Code, PyCharm, Eclipse, Xcode

Indbygget i browserens devtools (til JS)

CLI (fx pdb i Python, gdb i C)

Hvornår bruger man en debugger?

Situation	Eksempel
Når programmet crasher uden tydelig årsag	Segfault, NoneType error
Når noget opfører sig forkert	En funktion returnerer et forkert resultat
Når man vil forstå andres eller egen kompleks kode	Trinvis analyse
Ved white-box testing	Når man systematisk tester kontrolstrukturer ## SP11 ### Hvad er en black box test? Forklar princippet bag black box tests. Er det realistisk at risikere at en komplet test skal gennemføre 10^100 kombinationsmuligheder af input værdier – hvorfor/hvorfor ikke? Antag det er, hvordan sikrer du så at testen kan gennemføres på realistisk kort tid? Argumenter for hvorfor din metode vil være bullet-proof. Ved sidste spørgsmål, tag gerne udgangspunkt i en løsning fra opgave 1. **Hvad er en Black Box Test?**

Black box test (også kaldet funktionsbaseret test) er en testmetode, hvor du tester systemets funktionalitet udefra – altså uden at kende den interne kode eller struktur.
Princippet bag black box testing

Fokus er på input og output: Giver systemet det rigtige output for det givne input?

Tester typisk:

    Funktionalitetskrav

    Brugerinteraktion

    Grænseværdier

    Fejlhåndtering **Du skriver testcases baseret på kravspecifikationen og tester, om programmet opfører sig som forventet.**     **Er 10^100 kombinationsmuligheder – realistisk?**

Nej, det er komplet urealistisk.

Et eksempel:

Forestil dig et system der tager 100 inputfelter, og hvert felt kan have 10 værdier → 1010010100 kombinationer = mere end antallet af atomer i universet.

Så:

Det er umuligt at teste alle kombinationer

Det vil tage uendelig lang tid og regnekraft

✅ Hvordan tester vi alligevel på realistisk tid?

Ved at bruge strategiske metoder:

  1. Ækvivalensklasser

    Del input i grupper, hvor du forventer samme adfærd

    Test kun én værdi pr. gruppe

🔧 Eksempel: Hvis alder skal være 18–100, så test:

Undergrænse: 17 (ulovlig)

Gyldig: 25

Overgrænse: 101 (ulovlig)

  1. Grænseværditest (Boundary Value Analysis)

    Fejl sker oftest ved grænser, fx 0, 1, max

    Test fx værdier: min-1, min, min+1, max-1, max, max+1

  2. Fejlspekulation / Edge cases

    Brug erfaring og viden om typiske fejl

    Eksempler: tom input, null, ekstremt store/små tal

  3. Risiko-baseret test

    Prioritér test på funktioner der er forretningskritiske eller fejl-udsatte

🛡️ Argument: Hvorfor er dette “bulletproof”?

Det er ikke muligt at sikre 100% korrekthed i alle situationer, men:

✅ Disse metoder minimerer risikoen for kritiske fejl ✅ De fokuserer indsatsen på de vigtigste og mest fejl-udsatte områder ✅ De gør det muligt at teste hurtigt og effektivt med høj dækning ✅ Kombineret med white-box tests, får du både intern og ekstern testdækning 🧪 Eksempel: BubbleSort fra opgave 1

Krav:

BubbleSort skal sortere listen i stigende orden

Black box test cases: Test Case Input Forventet Output Tom liste [] [] Én værdi [5] [5] Allerede sorteret [1, 2, 3] [1, 2, 3] Omvendt sorteret [3, 2, 1] [1, 2, 3] Dobbeltværdier [2, 2, 1] [1, 2, 2]

⚠️ Bemærk: Her kender vi ikke hvordan koden er lavet (black box), men vi ved hvordan den skal opføre sig.

Hvis noget kode ser ud til at virke, er du så helt sikker? Hvordan sikrer du dig, at du også vil have den kode til at være ansvarlig for næste flytur du selv skal på? Beskriv hvordan du fandt fejlen i det kode der blev givet i opgave 2. Er du sikker på du fandt ALLE fejl? Argumenter hvorfor du er sikke

Hvis noget kode ser ud til at virke – er man så helt sikker?

Nej – aldrig.

At koden ser ud til at virke, betyder kun, at den virker i de tilfælde, du har testet den.

Men hvad med alle de utestede situationer, inputkombinationer, kanttilfælde eller fejlscenarier?

Når det handler om kritiske systemer, som fx en flyver, så er “det virker på min maskine” ikke godt nok. ✅ Hvordan sikrer man sig kvalitet og sikkerhed?

Grundig test:

    Brug både black box og white box tests

    Test grænsetilfælde, fejlscenarier, store input, tomme input, uventede input

Code review:

    Flere øjne opdager flere fejl

    Du får feedback på både logik og struktur

Statisk analyse:

    Brug værktøjer der automatisk analyserer koden for potentielle fejl (f.eks. pylint, mypy, flake8)

Formal verification (i kritiske systemer):

    Matematiske beviser for at koden opfører sig korrekt

Test coverage:

    Hvor meget af koden bliver faktisk ramt af tests? (Fx med coverage.py)

🐛 Hvordan fandt vi fejlene i opgave 2?

Vi gennemgik koden linje for linje, og:

Brugte white-box teknik til at se på intern logik

Spottede:

    Forkert abs(...) brugt i sammenligning

    Forkert initialisering og opdatering af swapped i bubble sort

    Logiske fejl i rekursiv tilgang → risiko for uendelig løkke

    Misforståelse af sorteringsretning

    Manglende input() validering

❓Er vi sikre på, at vi har fundet ALLE fejl?

Nej – men vi har reduceret risikoen betydeligt.

Vi kan ikke 100% garantere, at der aldrig er fejl. Der kan stadig være:

Edge cases vi ikke har testet

Performance-problemer på store inputs

Fejl ved flydende tal, NaN, inf, etc.

Men:

Vi har anvendt systematiske metoder

Vi har lavet grundige test og kontrol

Og vi har lavet logiske forbedringer i strukturen

Det gør os trygge ved funktionaliteten, men vi ville stadig ikke bruge det i en flyver uden meget mere test og certificering. 🧠 Konklusion

At være professionel udvikler betyder ikke at “tro” koden virker – det betyder at dokumentere og teste, indtil man ved, at den virker — i hvert fald under de definerede krav og forudsætninger.