Ett utvecklarperspektiv Design och konstruktion av användargränssnitt distanskurs 1MD113 Användbarhet vs. utveckling Varför har så många system låg användbarhet? Konflikter bråk om vad som ska utvecklas Tidsbrist användbarhet hinns ej med Upphandling kan ge formella hinder Okunskap inte veta vad göra Oförmåga inte klara av att möta mål Informationsteknologi 2005-05-28 #2 Konflikter Har vi egentligen konflikter mellan beställare och utvecklare? Nja, men olika faktorer styr när man blir nöjd det är svårt att skilja systemutveckling från verksamhetsutveckling (= turbulens) svag förståelse för varann: mycket är en språk- och intressebarriär, ej nödvändigtvis en konflikt i sig dålig medverkan i de andras aktiviteter leder ofta till osämja Informationsteknologi 2005-05-28 #3 1
Tidsrelaterade problem Produktivitet Avtar med antalet personer. Kompensera med gruppuppdelning; ger ännu fler parter att hantera Att öka takten är snudd på omöjligt Människor är inte plug & play-kompatibla Informationsteknologi 2005-05-28 #4 Formella hinder Dåliga odds från första början på grund av upphandling Fast pris + låsta krav = betong Upphandling är ofta lek i en låtsasvärld Beställaren låtsas veta alla framtida krav Leverantören låtsas tro på det, och låtsas vidare att det går räkna ut fix kostnad för att konstruera systemet Utvecklarna låtsas att utveckling är statiskt och använder metoder som tar fyrkanter som indata och som producerar nya fyrkanter Alla blir förvånade/upprörda när systemet sedan inte håller måttet Informationsteknologi 2005-05-28 #5 Upphandling KUNDEN LEVERANTÖREN Krav Analys: behov Analys: tid & pengar Offert Informationsteknologi 2005-05-28 #6 2
Förändringar Mjukvara är just mjuk; det bör gå att göra förändringar För att nå användbarhet så måste man kunna korrigera fel Lösningen är att inte låsa krav, speciellt inte tidigt Vad utvecklingskostnaden blir beror nästan enbart på krav (som vi ju inte vet i förväg) Informationsteknologi 2005-05-28 #7 Offertvarianter Risk Fast pris med böter Fast pris Blandformer Löpande räkning Chans att få kontrakt Informationsteknologi 2005-05-28 #8 Okunskap Design för användbarhet Inget som skiljer sig från andra krav Dock, det finns sällan konkreta användbarhetsmål om man frågar beställare/användare/experter! Alltså ligger svaret troligen i hur man utvecklar, inte vad Informationsteknologi 2005-05-28 #9 3
Oförmåga Projektmedlemmar Något av ett tabu: vi är olika bra (och dåliga) Vi är dessutom individuellt olika bra/dåliga på olika saker Ofta saknas kompetens för nya moment och situationer Mycket hade kunnat förbättras med lite framförhållning Informationsteknologi 2005-05-28 #10 Lösningen? Problemen är många så enkla lösningar finns ej tyvärr! Dock, det går lösa flera problem genom en lämplig utvecklingsmetodik Användbarhetsprocess! Svaret ligger i metoden! Om utvecklarna varit med i framtagandet av krav och prototyp så ökar chanserna att nå bra resultat Informationsteknologi 2005-05-28 #11 Svaghet Stor brist ligger i my baby -syndromet; att man aldrig vill ändra på en egen (=vacker) lösning Leder till 1 enda utvecklingsspår mot målet; det är ej tillräckligt Denna naturlag fungerar åt båda håll, men oftast är det utvecklarna som får skäll Finns en mängd olika strategier för att undvika just den fällan Här är 7 stycken: Informationsteknologi 2005-05-28 #12 4
1. Perfektionism Hela tiden leta efter den ultimata lösningen; nuvarande lösning endast temporär Bygger på att det existerar en killer app som löser alla våra problem Inte riktigt sant Eller Informationsteknologi 2005-05-28 #13 Verkligheten Worse is Better gäller tyvärr Richard P. Gabriel vs. Nickieben Bourbaki Good News, Bad News, How to Win Big http://www.dreamsongs.com/worseisbetter.html I korthet: Enkelhet i kod > enkelhet i design Enkel > korrekt Enkel att bygga > enkel att använda Informationsteknologi 2005-05-28 #14 2. Projektledning Arbetssätt är en fråga om inställning Jämför hur coachning sker av målvakter i hockey och handboll Kompetens och självförtroende Duktiga utvecklargrupper tvekar inte att slänga bort saker som inte passar eller är bra nog. Det gäller nå denna nivå/attityd! Coachning Ledargestalt Utbildning, anställa den bästa i världen Prestigelös miljö Informationsteknologi 2005-05-28 #15 5
3. Metodik Arbeta på ett sätt som omöjliggör revirbevakande och rigida strukturer Prototypdriven verksamhet är sådan, med stora vinster: I en datorvärld kommer prototyper sanningen mycket nära Prototyper kan dock bara ge svar på frågor; ingen generell räddningsplanka Informationsteknologi 2005-05-28 #16 Metodik, hur bäst förstöra Skapa moment som går emot allt mänskligt Förutsätt konsekvent beteende av de som ska använda metoden Om vi bara folk kunde vara konsekventa (och vara snälla, motionera mera, röka mindre ) så skulle det inte vara ett problem Förutsätt att folk ska ändra beteende ifall någon vill det Ingen byter personlighet pga metod Informationsteknologi 2005-05-28 #17 4. extreme Programming (XP) Förändringarna har förändrats Verksamhet förändras hela tiden, alltså bör även systemen göra det Ett nytt sätt att utveckla system Kontinuerliga förändringar! Testdriven process 2 x personer = 1 dator Inga dokument sparas Gemensamma ståmöten Långsiktig planering är osäker, alltså låter man bli sånt Informationsteknologi 2005-05-28 #18 6
XP, del 2 Gör upp med gamla sanningar Att tänka efter ger bättre kvalité än att göra nu Fel: kvalité har med riktig användning att göra, inte planerad användning. T.ex. snabbast ta första tunnelbaneuppgången än den rätta Att göra rätt sak från början är billigare än att rätta i efterhand Fel: troligtvis behövs saken inte alls, om den sedan behövs gör man det då. Dokumentation är viktig att spara Fel: den är så dålig att den inte är värd något Informationsteknologi 2005-05-28 #19 XP, del 3 Planera noga för viktiga saker Fel: om framtiden är oklar, och du kan fixa saker i efterhand, varför införa något som man misstänker kan vara bra? Välj bästa lösningen Fel: välj enklaste lösningen, för den är ändå bra nog (och enklare att ändra) Se framåt Fel: gör endast vad du vet, inget mer Informationsteknologi 2005-05-28 #20 XP, del 4 Koda, testa sedan att det blev rätt Fel: gör test först, koda sedan Många rader kod/dag, och många funna fel i ett test är bra Fel: få rader går snabbare att skriva, noll antal fel vore bättre Informationsteknologi 2005-05-28 #21 7
5. Designkriteria Jobba mot förbestämda mål Överenskomna Gemensamma Styrande Målen riskerar bli förtäckta krav (Exempel kommer i del 2) Informationsteknologi 2005-05-28 #22 6. Rationale Att arbeta enligt Design Rationale kan hjälpa utvecklingsgruppen att ompröva alla lösningar Motiverar lösningar även för andra, externa personer Ger bättre kvalité på varje del-lösning, men hjälper det i det stora hela? Informationsteknologi 2005-05-28 #23 7. Verktyg Genom att noggrant välja verktyg kan man uppnå många positiva effekter Inga låsningar Visionära Nästan samma vinst som via prototyper Papperslappar, skisser, Informationsteknologi 2005-05-28 #24 8
Verktyg, hur bäst förstöra Verktyg för kommunikation Börja med 2 personer vid svarta tavlan Ta bort närhet mellan personer (video) Ta bort alla förklarande gester (telefon) Se till att intonation inte kan användas till att förmedla vad som är viktigt (epost) Se till att man inte kan ställa frågor (dokument) Detta är vad de flesta metoder rekommenderar Informationsteknologi 2005-05-28 #25 Verktyg, välj rätt Kommunikation Svarta tavlan Telefon Epost Formell notation Dokument Strukturerat dokument Verktyg Informationsteknologi 2005-05-28 #26 Verktyg, välj rätt byggnad "Make sure there are whiteboards and coffee corners all over the building. (IBM) Informationsteknologi 2005-05-28 #27 9
5 vanligaste verktygen För hand (ovanligt) Färdigt bibliotek (toolkit) Färdigt gränssnittsverktyg (builder) Modell-baserade gränssnitt (kommer starkt) Informationsteknologi 2005-05-28 #28 Handgjort Ligger direkt ovanpå hårdvara Högsta möjliga kontroll Högsta möjliga prestanda Svår och arbetskrävande utveckling, oflexibelt, hög kunskapströskel Ger ganska ofta låg kvalité Tänk videobandspelare Informationsteknologi 2005-05-28 #29 Bibliotek Hög tröskel; man måste kunna alla delar i biblioteket Kräver mycket kod/arbete Utmärkta prestanda Bra kontroll Informationsteknologi 2005-05-28 #30 10
Hello, exempel i Java import javax.swing.*; class HelloWorldSwing { public static void main(string args[]) { JFrame mainwin = new JFrame("MainWindow"); JButton button = new JButton("Hello World"); mainwin.getcontentpane().add(button); mainwin.pack(); mainwin.show(); } } Informationsteknologi 2005-05-28 #31 Bibliotek, byggklossar Informationsteknologi 2005-05-28 #32 Builder/RAD Vanligaste lösningen idag Visual Basic, Visual C++, Forte, etc Kräver fortfarande att man kan hela biblioteket Flexibel utveckling, stor frihet Billigt Hjälpsystem, underhåll, distribution, felhantering, Ger initialt en snabb utveckling (falsk känsla dock) Informationsteknologi 2005-05-28 #33 11
Informationsteknologi 2005-05-28 #34 Informationsteknologi 2005-05-28 #35 Modellbaserat gränssnitt rubrik: textfält(ej inmatning), bakgrund=vit. varningsrubrik: rubrik, bakgrund=röd. Informationsteknologi 2005-05-28 #36 12
Modellbaserat gränssnitt Bokabiljett: rubrik( Boka biljett ), dag, namn( Ditt namn ), knapp( Skicka beställning ). dag: rubrik( När vill du resa), datum. Informationsteknologi 2005-05-28 #37 13
Exempel: Medicus Informationsteknologi 2005-05-28 #1 Medicus Deutsche Telekom beställare. Ville skapa produkter som använder ISDN, för att kunna sälja som mervärden till den tjänsten. Specifikation: Telekonferens. Utbyte av bilder. Informationsteknologi 2005-05-28 #2 Tidiga krav Beställaren om systemet: Ska nyttja ISDN Konferens Säljande Medicinsk personal: Vara som förr, fast bättre Katastofhjälp Se motpart Bild + ljud Dela pekare Informationsteknologi 2005-05-28 #3 1
Informationsteknologi 2005-05-28 #4 Informationsteknologi 2005-05-28 #5 Medicus, design Bag Panel Folder Panel Session Panel Task Panel Status Panel Quit Panel Work Area Informationsteknologi 2005-05-28 #6 2
Medicus, look&feel Informationsteknologi 2005-05-28 #7 Informationsteknologi 2005-05-28 #8 Jättestor bild Stor bild Funktionalitet Användbar Prisvärd Senare krav Informationsteknologi 2005-05-28 #9 3
Informationsteknologi 2005-05-28 #10 Användning Krankenhaus Salem Onkologische Diagnostik Deutsches Krebsforschungszentrum Informationsteknologi 2005-05-28 #11 Start av applikation 120 100 80 60 40 20 0 01:00 03:00 05:00 07:00 09:00 11:00 13:00 15:00 17:00 19:00 21:00 23:00 Informationsteknologi 2005-05-28 #12 4
Konferenslängd 250 200 150 100 50 0 < 1min 1-2 min 2-3 mins 3-4 min 4-5 min 5-10 10-15 15-20 20-25 > 25 min min min min min Informationsteknologi 2005-05-28 #13 Start av konferens 1 000 900 800 700 600 500 400 300 200 100 0 01:00 04:00 07:00 10:00 13:00 16:00 19:00 22:00 Informationsteknologi 2005-05-28 #14 Nya idéer Informationsteknologi 2005-05-28 #15 5
CHILI PDA, senaste Informationsteknologi 2005-05-28 #16 6