MediaLab: Systemudviklingsmetode

From rtgkomArkiv
Jump to: navigation, search

Den systemudviklingsmetode som vi bruger i MediaLab består af en Indledende aktivitet som vi gennemfører kun i begyndelsen af projektet. Dernæst kommer fem aktiviteter som gentages et antal gange (itereres), indtil resultatet (produktet) er tilstrækkelig færdigt, og så afsluttes forløbet med en Afsluttende aktivitet. Efter den første iteration (gentagelse) har vi selvfølgelig kun den første prototype (det første udkast) til produktet. Denne prototype skal helst afprøves med rigtige brugere fra målgruppen, og således kommer der nye ideer, ønsker og krav til hvordan produktet skal virke. Disse indarbejdes i designet og en ny iteration resulterer i en ny prototype, osv.

Det er et vigtigt aspekt ved vores metode at vi aldrig opfatter produktet som helt perfekt og færdigt. Det er således klart på forhånd at du ofte må stoppe den iterative udvikling af prototyper inden du er helt tilfreds med produktet. Det er nemlig grænser for hvad du og dine samarbejdspartnere kan nå at lave på den afsatte tid og med de afsatte midler/resurser.

De fem iterative aktiviteter, altså de som gentages for hver prototype er:

	Iterationsplanlægning - Kravspecifikation og testspecifikation - Design - Implementering - Test

Og når vi tilføjer Indledende aktivitet og Afsluttende aktivitet så kan metoden inklusive de iterative løkke illustreres med følgende figur:

Indledende aktivitet - Iterationsplanlægning - Kravspecifikation og testspecifikation - Design - Implementering - Test - Afsluttende aktivitet
                       ^                                                                                               |
                       |                                                                                               |
                       |             Gentag så ofte som behov kræver eller resurser tillader                           |
                       |                                                                                               |
                        ------------------------<<<-------------------<<< -------------------<<<-----------------------

Der er et antal begreber knyttet til metoden. Blandt de vigtigste er brugerhistorie (user story), brugstilfælde (use case), krav og test, samt selfølgelig prototype og iteration. Det er et et meget vigtigt aspekt ved vores metode, at alt arbejde skal dokumenteres og så vidt muligt publiseres på Inernettet, altså på elevernes StudieWeb's. I en redegørelse for projektet, som kan antage forskellige former, f.eks. mundtlig fremlæggelse, video, podcast eller en rapport, skal arbejdets gang kunne aflæses. Læseren skal kunne følge udviklingen i arbejdet. Du skal altså ikke bare beskrive slutresultatet, -den sidste prototype. Det er oftest meget mere interessant, og fortæller mere om dig og dine evner som designer og implementør af medieprodukter, at høre hvordan prototyperne udviklede sig i hver enkelt iteration.

Fra XP bruger vi blandt andet brugerhistorier, user stories, til at indsamle og fastholde brugernes ønsker. En User Story er en kort beskrivelse hvor en bruger i sit eget sprog, frit for teknisk jargon, beskriver et konkret ønske om hvad produktet skal kunne gøre, eller bruges til. En user story skal ikke handle om hvordan produktet udfører eller muliggør gennemførelse den pågældende opgave. Det er en opgave for dig, systemudvikleren, at undersøge og afgøre om det er muligt at implementere den pågældende funktionalitet i produktet og hvordan det bedst lader sig gøre. På XP's website er der et eksempel på hvordan fire user stories for en kaffemaskine kan se ud.

Fra OOA&D har vi lånt begrebet brugstilfælde (use case). Det bruger vi til at definere XXX

Vores systemudviklingsmetode er brugercentreret. Det betyder at vi tager brugernes ønsker alvorligt, vi ligefrem inddrager brugerne i udviklingsarbejdet, både ved afdækning af kravene og til test-aktiviteten. Det er brugernes vigtigste ønsker, sådan som de kommer til udtryk i deres user stories, som bestemmer hvilken funktionalitet vi bygger ind i vores næste prototype. Se også her hvordan XP beskriver brugerens/købers aktive deltagelse i udviklingsforløbet.

I en iterativ proces hvor brugerne aktivt inddrages: planlægges, defineres krav og testprocedurer, designes og fremstilles (implementeres) en prototype som afprøves af brugerne. Resultatet af afprøvningen bruges som input til den næste iteration.

I XP beskrives flere såkaldte regler, som beskriver hensigtsmæssige måder at angribe den opgave at udvikle programmer, se her en oversigt over XP-metodens regler http://www.extremeprogramming.org/rules.html.

De enkelte aktiviteter indeholder følgende delaktiviteter. Se også gerne Dokumentation af arbejdet, hvordan? for en anden lignende fremstilling, som dog kun diskuterer delaktiviteter i de fem iterative aktiviteter.

  1. Indledende aktivitet Planlægning af kommunikation og de tekniske aspekter ved projektet. I praksis vil denne aktivitet, på HTX, ofte mere eller mindre indeholde de samme overvejelser som en god projektbeskrivelse, hvor blandt andet: forudsætningerne for projektet analyseres, problemet formuleres, der defineres målgruppe og løsningsforslag, værktøj vælges, resurseplan laves osv. Så egentlig kunne denne aktivitet helt enkelt siges at handle om at skrive en projektbeskrivelse, men for at sætte fokus på to af de vigtigste elementer i projektet, nemlig kommunikation og teknik, og fordi projektbeskrivelser laves på meget forskellige niveauer i de forskellige fag, så siger vi i vores hjemmelavede systemudviklingsmetode at den første aktivitet består af følgende to delaktiviteter.
    1. Kommunikationsplanlægning for projektet Som minimum indebærer dette at du aktivt forholder dig til Laswell's fem spørgsmål, altså Hvem siger Hvad til Hvem i Hvilken kanal og med Hvilken effekt? Du skal altså som minimum definere afsender, budskab, modtager, medie og effekten hos modtageren. En mere udfoldet tilgang til denne delaktivitet kunne være at besvare alle de 25 spørgsmål som Jan Kragh Jacobsen stiller til vores rådighed i sin bog "De 25 spørgsmål".
    2. Resurseplanlægning for projektet Som minimum indebærer dette at der defineres delopgaver for hver aktivitet i systemudviklingsmetoden. Ofte vil det være hensigtsmæssigt at definere underopgaver, subtasks, som de forskellige gruppemedlemmer bliver ansvarlige for. Dernæst tildeles resurser til disse tasks og den tidsmæssige rækkefølge af dem fastlægges. Resultater bliver et Gant-diagram. Det er let at lave sådan en resurseplan vha. programmet GanttProject, som kan downloades her http://www.ganttproject.biz/download eller her http://sourceforge.net/projects/ganttproject/. Her vil man normalt også prøve at vælge værktøjerne som skal bruges i projeket.
  2. Iterationsplanlægning (Se Release Planning i XP)
    1. Revision af kommunikationsplanlægning og den tekniske planlægning for projektet med fokus på den kommende iteration .
    2. Valg af de brugerhistorier, (user stories), som skal implementeres i denne iteration.
  3. Kravspecifikation og Testspecifikation
    1. Skrive kravene som skal opfyldes for at implementere de valgte user stories.
    2. Skrive testprocedure til afprøvning af disse krav.
  4. Design
    1. Design implementering af funktionaliteten som behøves for kravene. (Det kan være meget forskelligt hvad dette egentlig indebærer, men som et eksempel så kan kravet om rød baggrund i et web-produkt kræve at du sætter dig ind i hvordan CSS kan bruges til at gøre en websides baggrund rød. Hvis det handler om et Python program, så kan f.eks. et krav om at brugeren skal kunne læse data fra en tekstfil indebære at du skal sætte dig ind i de kommandoer som behøves til den opgave, f.eks. nytekstfil = open("gammelfilpaadisk.txt", r).
    2. Design af en brugerflade som gør funktionaliteten tilgængelig for brugeren. (Dette kan også indebære forskellige ting, afhængigt af det konkrete projekts karakter. For eksempel hvis projektet handler om et client-server webbaseret produkt til lagerstyring, og hvis kravet/brugerhistorien som vi fokuserer på handler om at det skal være muligt at slette en vare/varenummer, -ja, så skal det designes hvordan den funktionalitet gøres tilgængelig i produktets brugerflade, evt. med en lille knap med et x-symbol på, bagerst i en linie i en eventuel tabel over varer. Dette design-valg, skal både beskrives og argumenteres for, gerne med udgangspunkt i vores to designmodeller, gestaltreglerne, eller andre designmodeller eller overvejelser som finder særlig relevans i det pågældende tilfælde. Det kan også være at det valgte design for implementering af funktionaliteten i brugerfladen medfører særlige nye tekniske problemer, og så skal løsning af disse designes/beskrives her.
  5. Implementering
    1. Realisering af designet, ved hjælp af de udviklingsværktøjer som bruges i projektet.
    2. Dokumentering af realiseringen af designet!!! Dette er mindst lige så vigtigt som selve kodningen eller tegnearbejdet. Hvis du f.eks. er meget dygtig til at tegne, så skal du lave screenshoots (med PrtScr knappen på en PC/Windows) for at alle kan se at du selv har lavet dine skitser, tegninger, knapper, baggrunde osv.
  6. Test
    1. Gennemførelse af testprocedurerne, som defineret under aktiviteten Kravspecifikation og testspecifikation. For hver testprocedrue skal det afgøres om den er bestået eller ikke bestået.
    2. Dokumentation af gennemførelsen af testprocedurerne og opgørelse af resultaterne fra testen.
  7. Afsluttende aktiviteter
    1. Resultatopgørelse
    2. Registrering af erfaringer fra projektet

Analyse af problemstillingen/opgaven, informationssøgning, definition af problemformulering, og valg af løsningsforslag Projektbeskrivelse (Problemanalyse, problemformulering, definition af løsningsforslag, valg af løsning, valg af værktøjer mm)


Externe links[edit]

  1. Extreme Programming: A gentle introduction, http://www.extremeprogramming.org/. Dette er en af de agile (lette og fleksible) systemudviklingsmetoder. Vi har hentet inspiration fra dem til vores egen systemudviklingsmetode.
  2. http://www.agilemanifesto.org/, http://www.agilemanifesto.org/. Dette er "grundloven" for den agile bevægelse.