fö12 - systemutvecklingwebstaff.itn.liu.se/~marka/TNMK31/Material/systemutveckling.pdf · 8.Användarcentrerad ledning och styrning • Användardata styr inte bara individuella

1

Modernutvecklingsmetodik

TNMK31 – Användbarhet

Martin Karlsson [email protected] K7522 011 – 36 34 63 07-02-22 Martin Karlsson - Användbarhet 2

Teknikdriven design kontra användarcentrerad design

Traditionell filosofi• Teknikdriven• Fokus på komponenter• Individuella bidrag• Fokus på intern

arkitektur• Kvalitetsmått genom

systemets brister• Lösningarna styrs av

funktionella krav

Användarcentrerad filosofi• Användardriven• Fokus på lösningen• Tvärdisciplinärt teamarbete• Fokus på

användbarhetsattribut• Kvalitetsmått genom

systemets fördelar• Lösningarna styrs av

förståelse för användnings-sammanhanget

07-02-22 Martin Karlsson - Användbarhet 3

Användarcentrering i företag

• 8 stadier som visar på medvetenhetenrunt användarcentrering ochanvändbarhetstänkande

1. Fientlighet mot användbarhet• Utvecklare vill inte höra om användares behov

då det ger merjobb för deras del• Den enda bra användaren är en död användare• Dock kostnadseffektivt på kort sikt• Går ej att införa användarcentrering i en sådan

organisation om de inte själva inser behovet



2. Utvecklarcentrering• Företaget inser att användbarhet är bra• Designteamet litar dock på sin egen intuition

om vad bra användbarhet är• Alla utvecklare är ju också människor (?)• Relativt lätt att förespråka mer

användarcentrerade metoder• Företag brukar fastna i ungefär 3 år i det här

stadiet



3. ”Skunkwork usability”• Företaget inser att man inte kan lita på

designteamets föreställning om användbarhet• Mycket beslut tas dock på samma vis• Man kanske tar in några användare i varje

projekt och låter dem testa lite• Man förlitar sig på utvärderingar av resultatet,

och inte så mycket under processens gång• Användbarhetsarbetet anses vara enkelt, och

inte så komplicerat som vi vet att det är



4. Projekt med användbarhetsbudget• Man planerar för användbarhet, liksom man

planerar för annat kvalitetsarbete• Huvudmetoden är användningstest och lagom

många typiska användare rekryteras• Dessa test utförs dock sent i processen• För att få ledningen att inse att man måste göra

mer, så krävs det att man mäter mer noga huranvändbarhetsaspekten påverkarförsäljningssiffror

2



5. Ledningsplanerad användbarhet• Det finns en officiell användbarhetsgrupp som

leds av en användbarhetsspecialist som ”äger”all användbarhetsutveckling i företaget

• Ekonomin är fortfarande inte tillräcklig för fullanvändarcentrering så användbarhets-specialisten får fokusera på vissa projekt

• Fokus är fortfarande på användningstest



6. Systematisk användbarhetsprocess• Företaget har en metod för att spåra förbättringar av

användbarheten i hela processen, ex. Användbarhetsmål• Iterativ design är mer vanlig på den här

nivån, i alla processer på företaget

7. Integrerad användbarhetsprocess• Alla sysslar med användbarhet på företaget• Alla projekt börjar med fältstudier• Istället för att bara spåra förbättringar så mäter man

numera kontinuerligt alla kvalitetsaspekter i processen• För att komma hit har företaget spenderat kanske 6-7 år i

de tidigare nivåerna



8. Användarcentrerad ledning och styrning• Användardata styr inte bara individuella projekt

utan även vilka projekt som ska genomföras• Användbarhetsmetoder påverkar inte bara

projektet utan företagsstrategier och andraaktiviteter långt utanför gränssnittsdesign

• Få företag har nått den här nivån, så troligentar det runt 20 års aktivt användbarhetsarbeteatt nå denna nivå av användarcentrering


Moderna utvecklingsprocesser

• De mest kända• Rational Unified Process (RUP)• Dynamic Systems Development Method (DSDM)• Extreme Programming (XP)

• Andra som ni får läsa om i kursboken• Object, View and Interaction Design (OVID)• Logical User Centered Interaction Design (LUCID)• DELTA-metoden• Usage-centred design• Praktiskt Användarmedverkan vid Systemutveckling

(PAS)


Rational Unified Process

• Knuten till objektorienterad systemutveckling• Fokus på systemarkitekturtänkande• Baseras på 6 stycken ”goda vanor”

inom systemutveckling:1. Utveckla mjukvara iterativt2. Förvalta kraven3. Använd komponentbaserad arkitektur4. Kontrollera mjukvarukvalitet5. Kontrollera förändring

• Det stora vattenfallet är omgjort till en radmindre och väl definierade vattenfall medhjälp av evolutionär prototyping



• De iterationer somutförs är snarareinkrement, då manbygger upp delar avsystemet(komponenter)

• Därmed kan manpåstå att iterativutveckling intenödvändigtvisbedrivs inom ramenför RUP

3



• RUP är uppdelad i fyra faser, som är sekventiella• Faserna är inception (förberedelse), elaboration

(utredning), construction (konstruktion) ochtransition (överlämning)

• Dessa faser består av ett antal iterationer• Arbetet inom varje fas bedrivs inom ramen för ett

antal discipliner• Varje disciplin innehåller ett arbetsflöde med

aktiviteter

• Denna typ av utvecklingsprocess kallas förtungviktsprocess





• Det finns ingen disciplin som handlar omanvändbarhet eller användarcentrering (dockhar författarna av kursboken hittat på en egensom passar in i RUP)

• Användarcentreringen baseras på prototypingav olika slag samt användningsfall (use cases)

• ”A use case specifies a sequence of actions,including alternatives of the sequence, that thesystem can perform, interacting with actors ofthe system”



• Användningsfall kan vara beskrivna i text• Ser då ut som scenarion men har funktionen att

dokumentera redan färdiga funktioner istället för attutvärdera sådana som formas

• ... eller med hjälp av modelleringsspråket UML(Unified Modeling Language)



• Det finns två syften med användningsfall• Att beskriva användarens interaktion med systemet

från en användares perspektiv• Att beskriva systemets uppförande från en

systemdesigners perspektiv• Det är dock en beskrivning baserad på

utvecklarnas villkor, även om den ska beskrivaanvändarnas interaktion

• Den utvecklare som skriver användningsfalletsätter sig säkert in i användarens situation(kanske inte på rätt sätt), men systemet fårhögre användbarhet i slutändan



• Användningsfall blir oftast ett kontrakt mellanutvecklare och användare, och det är svårt attförstå konsekvenserna av dessa

• Hela definitionen av användningsfall är oklar,det finns många tolkningar och detta försvårarju självklart ytterligare för en användare elleren kund att förstå vad de skriver under

• Dock är inte textbaserade kontrakt, exempelviskravspecifikationer av olika slag, det bästaheller, då de ljuger. Text kan formuleras påmycket tvetydiga vis, och enda utvägen äregentligen en ordentlig interaktionsdesign(principdesign)

4



• Man delar upp systemet i mindre delarmed användningsfall• Vilket är mycket bra för utvecklarna, att få

en mindre del att arbeta med, de känner dåatt de utför något bra

• Men det är en fara att man abstraherar förlångt och vissa saker faller mellan stolarna

• Detta leder ofta till vad som kallas förfragmenterade användargränssnitt, det finnsinget flöde genom hela systemet



• RUP med användningsfall är ett steg åträtt håll, men det är fortfarande förtungrott och tvetydigt


DSDM

• Dynamic Systems Development Method är en processmed nio principer som bas

1. Active user involvement is imperative2. DSDM teams must be empowered to make decisions3. The focus is on frequent delivery of products4. Fitness for business purpose is the essential criterion for

acceptance of deliverables5. Iterative and incremental development is necessary to

converge on an accurate business solution6. All changes during development are reversible7. Requirements are baselined at a high level8. Testing is integrated throughout the life-cycle9. A collaborative and co-operative approach between all

stakeholders is essential


DSDM

• DSDM har fem faser• Feasibility study, business study, functional model

iteration, design and build iteration, implementation


DSDM

• DSDM bygger på användarmedverkan• Men man har inte definierat något sätt att

hitta ett representativt urval av användare• Man förespråkar ett urval där man fokuserar

på ett effektivt arbete, framför allt i form avworkshops

• Dessa workshops har dock inget krav påmedverkan av representativa användare


Extreme Programming

• XP är en iterativ lättviktsmetod för små tillmellanstora projektteam som utvecklar mjuk-vara som antingen är vagt specificerad eller därförutsättningarna kan ändras utan förvarning

• XP lovar två saker• Att programmerarna varje dag ska få hålla på med något de

anser vara meningsfullt. Att de ska slippa bemöta otäckasituationer ensamma och att de får ta besluten som de kan tabäst själva

• Att kunden och ledningen får ut mesta möjliga värde ur varjeprogrammeringsvecka. Att kunden och ledningen får se resultatunder utvecklingens gång och att de ska kunna ändraprojektets riktning när det behövs

5


Extreme Programming

• XP består av ett antal sedvanor(practices) som är baserade på femstycken värden (values)

• XP är ingen metod med ett givet ramverkoch givna aktiviteter, därför finnsegentligen ingen tydlig användar-centrering alls inom metoden

• Användare förutsätts deltaga iplaneringsfasen och interaktionsdesignersförutsätts medverka i processen


Extreme Programming

• En interaktionsdesigner inom ett XP-team ska• Välja systemmetafor• Skriva ”stories” tillsammans med kund• Analysera verkliga användare och deras behov• Arbeta iterativt

• Det finns inget i modellen som hindrar eninteraktionsdesigner från att utföra sina”vanliga” aktiviteter. Detta är upp till XP-teametvad de vill fokusera på


Extreme Programming (i bilder)



• Testdriven utveckling

Skriv test

Kompilera testet. Första gången ska det fallera, eftersom du inte har skrivit koden som testet ska anropa och testa

Implementera precis tillräckligt för att testet

ska gå igenom

Kör testet och kolla om det fallerar

FärdigKasta koden





6



Documents

fö12 - systemutvecklingwebstaff.itn.liu.se/~marka/TNMK31/Material/systemutveckling.pdf · 8.Användarcentrerad ledning och styrning • Användardata styr inte bara individuella