Systemudvikling

Når du udvikler et IT/medieprodukt, har du sammen med dit udviklerhold - og andre, der har med projektet at gøre - brug for et overblik  over de aktiviteter og faser, udviklingsarbejdet består af.

Der findes forskellige metodeplatforme, der på hver sin måde gør op, hvad et udviklingsprojekt gennemgår, og hvordan det gribes an. Man kan her f.eks. nævne SCRUM eller Extreme Programming som er anerkendte modeller for fremgangsmåde og teknikker til samarbejde og systematik i forbindelse med design af udvikling af IT-produkter ...som f.eks. computerspil.

Ude til højre er en forenklet model inspireret af de de mere komplekse og professionelle. Det gør projektet op i 5 grundlæggende faser, der hver indeholder en række aktiviteter. Du kan måske genkende overskrifterne fra rapportskabelonen (pkt. 6 "Arbejde med løsning") , den skal du planlægge og strukturere dit arbejde ud fra sammen med din makker/gruppe.

Implementering

Når man mener, at der er styr på målgruppe og spilkoncept - d.v.s. man har specificeret kravene til spillet, forstår, hvem der skal spille det og har arbejdet sig frem til et design - sætter man gang i implementeringen. 

"At implementere" betyder ca. "at få det til at fungere". Her skal man vælge det værktøj (de værktøjer), man finder bedst egnet til opgaven.  Her har vi jo afprøvet Snap!/Scratch, men hvis man er hjemme i et alternativt værktøj, må man gerne vælge det.

Man kan ofte finde "worked examples" d.v.s. færdigudviklede udgaver af noget, der minder om det, man gerne selv vil lave. Det kan være en god hjælp. 

Det kan dog være overvældende at møde den til tider ret komplekse kodning, det viser sig skal til. Her kan det være en god idé at bryde sit spil ned til mindre grundfunktioner og bygge det trinvist op. Metoden kaldes "stepwise improvement" og ude til højre kan I se hvordan Bartek trin for trin bygger funktioner på sit tennisspil. Se om ikke det kan give jer et par hints om, hvordan I kan gribe udviklingsarbejdet metodisk an.

Sørg for undervejs at få dokumenteret, hvad I gør i form af screensshots, noter og evt. kodestumper.

Test

Måske kan du huske tilbage til, da vi arbejdede med brugervenlighed/usability. Her gennemgik vi tænke-højt-testen og øvede os i at gennemføre den på en prototype til et website, I havde designet.

Ude til højre ser du vejledningen til en simpel tænke-højt-test  svarende til den, vi brugte i grundforløbet

Overvej sammen med din projektgruppe hvordan og hvornår I kan teste forskellige krav til jeres spil. 

Sørg for at det kan blive en del af udviklingsarbejdet d.v.s. få dokumenteret aktiviteten og følg op i jeres design og implementering på baggrund af det, testen(e) viser

Tænke-højt-test

1. Hav en prototype klar

Udgangspunktet for testen er, at der er en udgave af produktet, det er muligt for en testbruger at afprøve. Det behøver ikke være pænt eller fuldkomment. Det kan ofte give gode input til udviklingsarbejdet at teste tidlige og kun delvist implementerede varianter af jeres produkt (I har f.eks. erfaret, at man kan bruge papirprototyper i en afprøvning) 

2. Gennemfør en tænke-højt-test (principperne vil blive gennemgået):

• Forberedelse 

  • Læg en plan (hvem leder og hvem registrerer?) 

  • Definer opgaver, som testpersonen skal udføre

  • Find en eller flere egnede testpersoner

• Gennemførelse 

  • Lad testpersonen udføre de planlagte opgaver på prototypen

  • Få testpersonen i tale om det, han/hun foretager sig og forventer 

  • Registrer hvad testpersonen gør (ikke så meget hvad han/hun mener)

• Kommunikation af resultat 

  • Diskuter resultaterne af testen – hvor var der problemer og hvad virkede? 

  • Skriv det ned 

  • Følg op i designet. 

• http://www.dialogdesign.dk/index.html

  • Molich says: Usability testing

• SIGCHI.dk: Regler for standardtest af brugervenlighed (word-fil)

• Steve Krug: "Don't make me think", kap. 9