Afstemningsapps – forløb til informatik B

Afstemningsapps er et godt og afgrænset tema, hvor det er muligt på relativt kort tid at komme rundt om en række faglige mål helt fra design, database, programmering til datasikkerhed og påvirkning af brugere. I forløbet udvikler eleverne et logon- og afstemningssystem, som de kan tage med videre i eksamensprojektet

Forløbet følger vandfaldsmodellen tæt, så eleverne får førstehåndskendskab til modellen og får arbejdet fokuseret med interaktionsdesign, arkitektur og database og først senere skal tage højde for de begrænsninger, der findes i det udviklingsmiljø, de skal implementere det i.

Der er vedhæftet et udfoldet forløb til App Lab  på code.org, men afstemningsapp’en kan også udvikles i eksempelvis MIT - appinventor eller  Swift.

Forløbet kommer særligt i dybden med følgende kernestof:

• It-sikkerhed, netværk og arkitektur
• Repræsentation og manipulation af data
• Interaktionsdesign

Eleverne skal have basal kendskab til programmering samt kende til AIDA, gestaltlove og retningslinjer for visuelt design.

Forløbet er bygget op omkring fælles trinvis forbedring af et worked example, som grupperne kan bygge videre på. Det er opdelt i faser, der følger vandfaldsmodellen tæt, hvor hver fase kommer omkring forskellige faglige begreber og metoder:

• Forundersøgelse: afgrænsning af interessenter; målgruppeanalyse; analyse af eksisterende websider og applikationer; interview, kravsspecifikation.
• Design og arkitektur: mock-ups; navigationsdiagrammer; tre-lagsarkitektur; use-case-diagrammer og E/R-diagrammer.
• Udvikling: brugergrænseflade; logonsystem; afstemningssystem; visualisering af data.
• It-sikkerhed: passwords, risikoanalyse, sikkerhedsmodel

Før forløbet

Vælg et miljø, App Lab på code.org eller ét eleverne kender fra C-niveau, så der ikke skal bruges tid på at introducere et nyt.

Vælg også ét redskab til tegning af diagrammer. Det kan være Power Point eller sitet diagrams.net, som eleverne kan bruge helt ude logon.

Inddel på forhånd eleverne i grupper og lav en række cases, de kan vælge eller trække. Find gerne cases i nærområdet, så eleverne har en vis forhåndsviden: afstemningssystem til elevråd, festudvalg, kantine, restaurant, diskotek, klub…

Forløb

Introduktion til forløbet (1 time)

Vis eleverne flere eksempler på afstemningssystemer – gerne systemer, der senere kan inddrages til fx at snakke om godt/dårlig interaktionsdesign og sikkerhed. Inddel eleverne i grupper, der skal arbejde sammen om at udvikle et afstemningssystem, og lad dem vælge/trække en case.

Gennemgå vandfaldsmodellen for eleverne med fokus på, hvordan modellen er særligt velegnet ved en lav grad af innovation, hvor en eksisterende proces kan understøttes digitalt.

Forundersøgelse (3 timer)

Introducer eleverne til interessentanalyse, målgruppeanalyse, dokumentanalyse, samt evt. interview af domæneeksperter og tegning af rige billeder (cloud.cct.au.dk). Lad dem bruge redskaberne på deres selvvalgte case og bruge det til at lave en kravspecifikation, der afgrænser:

• Afsender samt primære og sekundære målgrupper
• System: skal alle brugere logge på? Skal man kunne se og/eller rette i tidligere afstemninger? Skal man kunne se, hvad andre brugere har stemt?
• Data, der er behov for at indsamle, samt krav til spørgsmål og svarmuligheder: antal svarmuligheder, behov for illustrationer, lav/normal/høj stil, lixtal… 

Design og arkitektur (4 timer)

I denne fase introduceres eleverne til at modellere systemer i forskellige diagrammer, så eleverne bliver fortrolige med det valgte værktøj og diagrammerne. 

Introducer ét diagram ad gangen med de tilhørende regler og guidelines.
Afslut hver gennemgang med at lade grupperne udarbejde et diagram til deres case og gemme den i portfolio.

Mock-Up's: Repetér AIDA, gestaltlove og designguidelines, som eleverne kender fra C-niveau.
Vis og diskuter forskellige eksempler på gode og dårlige/vildledende afstemninger.
Afslut med, at grupperne laver mock-ups i fx Power Point for forside, resultatside samt mindst 2 afstemningssider.

Navigationsdiagram: Gennemgå forskellige navigationsstrukturer, og bed grupperne tegne et diagram over navigationsstrukturen i deres app. Introducer designretningslinjer med fokus på god mapping - eksempelvis Jakob Nielsens 10 usability-heuristikker (nngroup.com) eller Donald Normans Designprincipper (medium.com). Bed eleverne opdatere deres mock-ups med særligt fokus på:

• Systemets status: Er det synligt for brugeren, hvor hun er i afstemningen?
• Kontrol og frihed: Kan brugeren gå tilbage og rette svar?
• Konsistens: Har ”ens” knapper samme placering og udformning?

Use-Case-Diagram: Opsummer trelagsmodellen og tegn i fællesskab et use-case-diagram, hvor logiklag og datalag tegnes som adskilte systemer, så kald fra program til database fremstår tydeligt.

E/R-diagram: Introducer modellering af database med entitetsklasser, attributter, relationer og nøgler.
Lad eleverne se og arbejde med diagrammer til forskellige systemer, så de får en forståelse af problemer ved redundant data – evt. kan man introducere til normalformer.
Afslut med, at grupperne laver et diagram over deres database med minimum tre entitetsklasser: brugere, administratorer og afstemninger.

Udvikling af brugergrænseflade (2 timer)

Introducer kort udviklingsmiljøet, og repeter de programmeringsstrukturer eleverne kender fra c-niveauet. Udvikl en standardgrænseflade trin for trin i klassen, hvor alle byder ind med løsninger og programmerer med. Den kan fx indeholde en fungerende menu, afstemningsside samt logonside, der i første omgang begge blot fungerer med et eller flere logons, der er oprettet direkte i koden).

Efterfølgende tilpasser grupperne grænsefladen til det design og den opbygning, de har skitseret i deres mock-ups og navigationsdiagram.

Udvikling af logonsystem (4 timer)

Start op i klassen med at afgrænse delmål i en trinvis forbedring (informatik-gym.dk) af et logonsystem.
Introducer databasesystemet og gå sammen i gang med at udvikle logonsystemet trin for trin.
Fortsæt i fællesskab indtil, at der er et fungerende system, hvor brugere kan logge på via et inputfelt. 

Herefter videreudvikler grupperne selv systemet så:

• Design og opbygning matcher mock-ups og use-casediagram
• Brugere kan opdatere password
• Administrator kan oprette og evt. slette brugere

Udvikling af afstemningssystem (6 timer)

Opstil i fællesskab de delmål, der er i udviklingen af et afstemningssystem. Gå sammen gennem de første trin til alle har et fungerende multiple-choice-system, hvor resultatet vises som tal.

Introducer herefter til forskellige måder, det valgte miljø kan visualisere resultater på - det kan eksempelvis være scatterplot, søjlediagram og lagkagediagram.
Vis og diskuter eksempler på brug af de forskellige diagramtyper, og implementer sammen en visualisering af afstemningen.

Grupperne arbejder videre på systemet og tilpasser det, så det matcher deres case:

• Systemet skal skifte ved afgivning af stemme, så bruger ikke klikker flere gange.
•  Flere afstemninger og mulighed for at bruger kan skifte mellem afstemninger.
• Afstemninger og udseende matcher kravspecifikation og mock-ups.
• Administratorer kan oprette, nulstille og slette afstemninger.
• Systemet synkroniserer, hvis flere brugere stemmer på samme tid.

It-sikkerhed (2 timer)

Introducer en model for risikostyring som Cybersecurity Framework af National Institute of Standards and Technology med faserne: Predict, Prevent, Detect, Respond, Recover. 

Giv eksempler på sikkerhedsbrud og hvordan de kan håndteres i de forskellige faser. Lav herefter i fællesskab et risikomatrix, hvor generelle trusler for afstemningssystemer udpeges og vurderes. Gennemgå herefter truslerne én for én startende med de, der har en høj konsekvens og en høj risiko. Overvej i fællesskab, hvordan truslerne kan undgås, opdages og håndteres.

Afslut med, at grupperne implementerer enkelte løsninger - feks.: 

• Brugere skal kun kunne stemme én gang.
• Sørg for at kode ikke vises, når den indtastes, men erstattes af stjerner.
•  Kræv og tjek, at passwords har en vis længde.

Udvid evt. med at udvikle en simpel hash-algoritme, så brugernes adgangskoder ikke ligger gemt i klartekst i databasen. Det giver anledning til at tale om god brug af password, fordele i at opdele systemer i tre eller flere lag og et lille indblik i algoritmer. En simpelt hash-algoritme baseret på modulo kan eleverne godt forstå og implementere – evt. også med tilføjelse af salt og peber. Tag fx afsæt i videoen Passwords & hash functions på youtubekanalen Simply Explained.

Evaluering

Forløbet afsluttes med, at grupperne dokumenterer udviklingsprocessen i en rapport. De skal særligt inddrage de modeller og diagrammer samt skemaer for trinvis forbedring - og reflektere over i hvilken grad de i processen har afveget fra dem.

Udvælg iagttagelser, som er relevante i en eksamenssammenhæng, og præsenter dem for holdet. Bed eleverne parvist diskutere hvorfor iagttagelserne fagligt set er særligt interessante.

Kreditering

Jacob Stenløkke Bendtsen, Hvidovre Gymnasium