Brukervennlighet i smidig systemutvikling - Brukerinvolvering i ...

KAPITTEL 2. FORSTUDIE 23
av systemet. Man skal i smidige metoder utvikle de ulike delene av systemet gjennom
iterasjonene, mens man i mer tradisjonelle metoder gjør designet helt ferdig
før man begynner p˚a den videre prosessen.
For ˚a tilpasse brukervennlighetsmetoder til smidige metoder, er det foresl˚att at
man skal benytte s˚akalt ”discount usability” [39]. Dette begrepet ble utviklet av
Jakob Nielsen allerede i 1994 [40] og har vist seg ˚a være hensiktsmessig i smidige
metoder. Han mener at litt brukertesting er bedre enn ingen brukertesting.
Typiske metoder man benytter i ”discount usability” er heuristikk evaluering og
papirprototyping (se tabell 2.1 for en beskrivelse av disse) siden disse krever lite
ressurser og gir gode tilbakemeldinger.
En annen metoden som er populær ˚a benytte i smidige metoder er automatisk
testing av brukergrensesnittet [29]. Dette er en effektiv metode for ˚a sikre et stabilt
og p˚alitelig brukergrensesnitt, og kan samtidig kjøres mer regelmessig enn en
manuell brukertest. Men det er ogs˚a ulemper knyttet til automatiske tester. En
automatisk test vil ikke kunne erstatte en bruker. Man vil alts˚a ikke se hvordan
interaksjonen mellom systemet og en faktisk bruker vil foreg˚a. Dette er et viktig
aspekt, da forskjellige brukere resonerer p˚a forskjellige m˚ater, noe som er vanskelig
˚a gjenspeile i en automatisk test. I tillegg kan det ogs˚a bli knyttet store kostnader
til reparasjon av et testskript. I artikkelen Maintaining and evolving GUI-directed
test scripts [23] viser man til at den ˚arlige kostnaden hos et enkelt selskap er p˚a
mellom 50 og 120 millioner dollar for ˚a vedlikeholde de automatiske testskriptene.
Videre har Hellann sett nærmere p˚a hvordan om man kan benytte testdrevet utvikling
(Test Driven Development (TDD)) for testing av brukergrensesnittet til et
system. Dette vil være en mulig tilnærming, da TDD er blitt en viktig kjerneprosess
i smidig utvikling. TDD g˚ar helt overordnet ut p˚a˚a lage tester for kravene man
skal implementere, og deretter gjøre selve implementasjonen slik at den passerer
testen som er laget [4]. Men en ulempe med bruk av TDD i testing av brukergrensesnitt
er at det m˚a eksistere et brukergrensesnitt før man kan registrere resultatet
fra testen. Man har forsøkt ˚a lage flere ulike metoder for ˚a løse dette problemet,
men det er enn˚a ingen utbredt bruk av dette.
Som det kommer frem fra artikkelen til Hellmann [25] er det fortsatt utfordringer
knyttet til arbeid med brukervennlighet i smidige metoder.
Undersøkelser gjort i industrien
Det har blitt gjort noen studier som ser nærmere p˚a forholdet mellom smidig
utvikling og designet av brukergrensesnittet. Vi vil i dette avsnittet presentere
resultater fra noen utvalgte artikler.