Agil användbarhetsutveckling för handhållna enheter TNM082, VT2014, FÖ1 Idag IntrodukEon Formaliteter Kursinnehåll J Formaliteter Personal (examinator, föreläsningar, projekt) camilla.forsell@liu.se 011-36 34 71 Kopparhammaren, Visualiseringscenter, plan 4 G414 Kåkenhus, Plan 4 K1417 (Tisdag, Torsdag) Henry Fröcklin (laboraeon, projekt) Kopparhammaren, Visualiseringscenter, plan 4 G415 henry.frocklin@liu Felicia Krepper (kursadministraeon) felicia.krepper@liu.se Kåkenhus, Plan 4 K1415 Exjobb (handledare/examinator) David Geijer. 2011. Agero. Utredning av mobila pla^ormar med fokus på användbarhet för akevitetshantering inom mulienaeonella organisaeoners verksamhetsstöd. Fredrik Bergström & Gustav Engvall. Abou AB. 2011. Development of handheld mobile applicaeons for the public sector in Android and ios using agile Kanban process tool. Albin Carnstam & Tobias Ohlsson. 2012. Exsitec AB. A Business Intelligence applicaeon for interaceve budget processes. Madelene Allvin & Björn Götestrand. 2012. User centric development for a sales support system on a mobile touch device. Gustav Jorlöv. 2013. Recorded Future. Visualisering av Edsrelaterade uppdateringar för mobila enheter. Gustav Lysell Smålänning & Daniel Svärd. Yooba. 2013. VisualizaEon of salesmen acevity in business environments based on ipad applicaeon usage data. Formaliteter Formaliteter Kurshemsida Se Ell ai du är registrerad och med på maillistan! hip://www.lith.liu.se/for- studenter/ kurskompleiering?l=sv&sc=true hip://www.itn.liu.se/grundutbildning/kurs/tnm082?l=svitn/ utbildning/grundutbildning/kurser/tnm082 Via ITNs hemsida/grundutbildning/kurser (googla inte!) 1
Mål (Kursplan) Förväntningar på kursen Några farhågor? Årskurs Mål Kursen sypar Ell ai ge dig god förståelse för hur användarcentrerad utveckling bedrivs, specifikt i förändringsbenägna projekt, med fokus mot applikaeoner på handhållna enheter, exempelvis mobiltelefoner. Läst programvaruutvecklingsmetodik HT2013 Mål (Kursplan) Mål: Studenten skall eper genomgången kurs kunna: Designa och programmera enkla grafiska Ellämpningar för handhållna enheter Genomföra en användaranalys och en behovsanalys samt modellera och dokumentera dessa Bedriva fältstudier för kartläggning av ei problemområde inom interakeonsdesign Utveckla system på ei säi så ai användbarheten kan mätas och garanteras Formellt uröra användningstest både med och utan användare Integrera användbarhetsutveckling med övriga delar inom agil systemutveckling Tillämpa formella principer för agila utvecklingsmetoder Tillämpa formella principer för mobil interakeonsdesign Programmera för kommunikaeon mellan handhållna enheter Mål (Kursplan) Mål: Dessutom ska projektarbetet lära studenten ai: Skapa enkla och kreaeva lösningar Ell komplicerade problem Arbeta eper agil utvecklingsmetodik i hög fart med god kvalitét Kommunicera och fungera socialt i ei team Ta och ge återkoppling på ei konstrukevt och givande säi Vara öppen för konenuerliga förändringar Reflektera över urört projektarbete och föreslå förbäiringar runt metod och resultat OrganisaEon (Kursplan) Kursinnehåll: Användbarhetsutveckling: Användarcentrerad systemutveckling, målgruppsanalys, personas Användbarhetsutvärdering: Intervjuteknik, kogniev genomgång, rollspel, prototyping KvanEtaEva och kvalitaeva användningsstest InterakEonsdesignmetodik: Brainstorming, storyboards, kreaevitetsövningar Agil utveckling: Extreme programming med deviser som parprogrammering, testdriven utveckling och omfaktorisering Arbetsstöd: BlåtandskommunikaEon, ljud i gränssnii Formaliteter Kursliieratur Essen;al Scrum: A Prac;cal Guide to The Most Popular Agile Process. Rubin S.K. 2013. (307SEK) Agile Sopware Development With Scrum. Schwaber, K. & Beedle. M. 2008. (474SEK) Agile Project Management With Scrum. Schwaber, K. & Beedle. M. 2004. (235SEK) Föreläsningsmaterial och annat material hemsida 2
OrganisaEon (Kursplan) OrganisaEon: Kursen består av föreläsningar, seminarier (nu workshop), projekrörberedelse och mobilprogrammeringsuppgip i period 1 och projektarbete i period 2. Projektet i period 2 bedrivs under flera heldagar varje vecka i en och samma laboraeonssal. Kursen pågår hela vårterminen. Formaliteter Kursstruktur VT1 V4-11: Föreläsningar Agil systemutveckling, Srum (Camilla) Användbarhet, sem utvärdering sem (Camilla) sem Inför projekt (Camilla) V6: Hur maskiner kommunicerar (Pierangelo DellAqua),,,, Programvaruutvecklingsmetodik (KJ) 1 Workshop (Camilla, Henry) miniprojekt Gäsröreläsning, introdukeon av projekt (Combitech) Redovisning/examinaEon av projekrörberedelse (Camilla, Henry) V8: 1 LE/lab Android, mobilprogrammering (Henry),,,, Kursstruktur VT1 Miniprojekt - projekrörberedelse Gruppindelning (?st) Roller Projekthantering metoder för dokumentaeon, kommunikaeon, testning, versionshantering etc. Gruppkontrakt, behov av kompetensutveckling. ExaminaEon Skripligt och muntligt, ca 15min per grupp Kursstruktur VT2 Förberedelser Projekrörberedelsen Combitech besöker? Mars introdukeon av företaget presentaeon av projekt vilken grupp som får vilket projekt, om olika, avgörs vid första dag på Combitech? Kursstruktur VT2 1 Produktägare/scrumcoach per grupp Schemaförslag v13-16, 18-20 Mån 9-11, Combitech, Lkpg schemalagda 8-12 för resed och undvika schemakrock planering, demonstraeon etc. Es och tors 8-17 heldagar i labsal V 21 redovisning ExaminaEon (Kursplan) ExaminaEon: VT1 En skriplig tentamen för mobil interakeon (22 mars) Hemuppgip i mobilprogrammering (U,G) Miniprojekt (U,G) (redovisning v 10 eller 11) 3 hp 1 hp 2 hp VT2 Projektuppgip (U,G) (görs i samarbete med Combitech AB, 6hp Lkpg, v 13-16, 18-20 (21), 24 mars 24 maj, redovisning v 21) 3
Kursvärdering från VT 2012 Svarsfrekvens 34 % (11/32) Medelvärde 3.3 (av 5.0) Innehåll Struktur OrganisaEon Kursvärdering KURT VT 2012 Svarsfrekvens 34 % (11/32) Medelvärde 3.3 (av 5.0) Innehåll Struktur OrganisaEon Fritextsvar Ge oss relevanta föreläsningar om hur agilt arbete fungerar och om scrum. Användbarhet har vi redan gåi igenom i en annan kurs! Låt Combitech hålla en scrumföreläsning och låt dom även sköta gruppindelning. De två "graespoängen" skulle kunna ges ut i labbar. En labb i Android (som det är nu) en i windows mobile och en i Iphone- utveckling. => 3hp. Däreper får gruppen välja vilken pla^orm de vill utveckla på. Kursstruktur VT2 Utveckla i Android för: Kursvärdering KURT VT 2012 Fritextsvar ExaminaEonen (tentan) handlade inte om kursens innehåll, mer om användbarhet än om Agil utveckling. Finns inga övningstentor, finns inga gränser utskrivna på tentan förutom godkäntgränsen. Enligt tentamen 2013: Inget skripligt material eller andra hjälpmedel är Ellåtet vid tentamen. Vissa föreläsningsanteckningar var på engelska och det går bra ai använda engelska termer istället för ai översäia dem Ell svenska. 24 frågor. Totalt 60p, 34p krävs för godkänt. (3=34p, 56%), (4=42p, 70%), (5=50p, 84%) Kursvärdering KURT VT 2012 Fritextsvar ExaminaEonen (tentan) handlade inte om kursens innehåll, mer om användbarhet än om Agil utveckling. Finns inga övningstentor, finns inga gränser utskrivna på tentan förutom godkäntgränsen. Tentan ska inte vara den enda examinaeonen som ger slutbetyget. Ai betyget baseras enbart på tentan verkar inte ve{gt. Det går ai betygsäia projekt individuellt. Kursvärdering KURT 2013 Svarsfrekvens 36 % (10/28) Medelvärde 4.33 (av 5.0) 4
Kursvärdering KURT 2013 Fritextsvar Om kursen som helhet har jag yrerligare ar säga: Jäiebra genomförd kurs! Tydligt ai examinatorn vill något med kursen! Jag jobbar som summer intern på Netlight ConsulEng i år och är, tack vare kursen, den som har bäst koll på hur man arbetar med agil systemutveckling. Deia även fast de andra sommarjobbarna hunnit längre i deras utbildning. Agila metoder är något som andra universitet verkar ha svårt ai lära ut. SamEdigt är det en mycket epertraktad erfarenhet hos arbetsgivare. Ai en kurs är så bra som denna är ovanligt och den kan bara bli bäire i och med bytet av examinator. Den kommer bli ännu bäire nästa år. Kursvärdering KURT 2013 Om kompetensutvecklingen som kursen bidragit ;ll har jag yrerligare ar säga: Kursen har bidragit enormt mycket Ell min personliga utveckling. Jag har känt mig väldigt säker på mii sommarjobb där vi jobbar med systemutveckling i scrum. Om examina;onen har jag yrerligare ar säga: Tentamen borde vara en U/G- dugga eper halva första perioden. Projektet borde komma igång direkt eper deia. Om kursen som helhet har jag yrerligare ar säga: För lite första perioden och lite mycket andra perioden. Kursvärdering KURT 2013 De vik;gaste förändringar som bör göras i denna kurs är: 20 h i veckan schemalagt endast för denna kursen blir sapigt i andra perioden. Knasigt ai byta dag på de schemalagda dagarna då de var röda dagar på de dagar projektet egentligen var schemalagt... Olika systemutvecklingsprocesser I ei systemutvecklingsprojekt ska man i ei antal steg: ta fram behov och krav på systemet designa konstruera införa- implementera testa utvärdera och följa upp konenuerligt underhålla och utveckla TradiEonell systemutveckling visualiserad Vaienfallsmodeller VaRenfallsmodellen är en sekveneell systemutvecklingsprocess där man ser framstegen som ei flöde (som ei vaienfall) nedåt genom olika faser: förberedelse, etablering, analys, design, konstrukeon, test, produkeonssäining och underhåll. Tanken är ai varje steg ska vara helt klart och bedömas innan man går vidare Ell nästa steg. 5
Vaienfallsmodeller Modellen har sina röier i Ellverknings- och byggindustrin där det är mycket kostsamt ai införa ändringar sent i processen - om inte omöjligt. Ei exempel som opa används på vaienfallsmodellen brukar vara ai bygga ei hus. Först analyseras behoven. En arkitekt anlitas som gör en ritning. Denna ritning används för ai ta fram specifikaeoner i form av olika dokument för ai få söka bygglov. Däreper byggs huset enligt specifikaeonen. Då byggnaeonen påbörjats är arkitekten frikopplad och inga ändringar görs. Eper byggnaeonen sker inflyining och drip och underhåll av fasegheten påbörjas. Vaienfallsmodeller Fördelar: Fungerar bra i projekt som är väldefinierade, förutsägbara och där det är osannolikt ai det blir större förändringar. Kostnadskontroll, beställaren (den som betalar) kan besluta i varje steg huruvida projektet ska startas, fortsäia, avslutas eller läggas på is. Ei projekt ska kunna återupptas med hjälp av de dokument som redan gjorts. Resursplanering eller upphandling kan göras mellan stegen. Om kravspecifikaeonen och designen är Ellräckligt bra så ska vem som helst kunna implementera systemet. Det som levereras är testat och är kvalitetssäkrat. Vaienfallsmodeller Nackdelar: Opast är it- system mycket mer komplexa än vad ei hus är ai bygga så denna modell kan/bör bara användas Ell viss del i projekt för it- system. Vaienfallsmodellen hanterar egentligen inte förändringar. Ei förändringsförslag (Elläggsbeställning) måste gå igenom flera steg för ai genomföras. Vaienfallsmodeller Kri;k Vaienfallsmodellen har fåi mycket kriek och de flesta hävdar idag ai det är bevisat via undersökningar ai det inte fungerar för ai utveckla it- system. Det blir mycket dokumentaeon. Mycket av det är nödvändigt, annan dokumentaeon kanske inte kommer ai läsas. Vad kan gå fel i utvecklingsprojekt? Vad går fel i utvecklingsprojekt? Man kan läi få uppfainingen ai de flesta it- projekt misslyckas. Dessvärre verkar bilden stämma, åtminstone om vi får tro The Standish Group, ei amerikanskt företag som regelbundet granskar projekt från hela världen och ställer samman en rapport med det talande namnet The CHAOS Report. http://cio.idg.se/2.1782/1.326833/darfor-floppade-projektentre-svenska-it-fiaskon-under-lupp http://cio.idg.se/2.1782/1.326833/darfor-floppade-projektentre-svenska-it-fiaskon-under-lupp 6
Vad går fel i utvecklingsprojekt? Därför floppade projekten: Tre svenska it- fiaskon under lupp Av Liv Marcks von Würtemberg (forskning inom industriell informaeon och kontrollsystem på KTH) För dyrt, för sent och för dåligt. Forskarna på KTH har tagit en ;R på tre skandalomsusade it- projekt och rer ut vad som gick sner och vad man kunde ha gjort annorlunda. http://cio.idg.se/2.1782/1.326833/darfor-floppade-projektentre-svenska-it-fiaskon-under-lupp CIO Sweden är ett månadsmagasin för strategiska beslutsfattare inom IT. Tidningens devis är "länken mellan IT och affärer" och syftet är att belysa den mer affärsmässiga sidan av IT och att fungera som stöd och beslutsunderlag för svenska CIO:er (egentligen strategiska IT-chefer). Vad går fel i utvecklingsprojekt? Levereras aldrig eller för sent Dyrare än beräknat Låg kvalitét Inte det man behövde Saknar funkeoner eller har onödiga funkeoner man vet inte vad man ska göra, funkeoner utan prioritet Dålig användbarhet man klarar inte uppgipen Vad beror det på? Vad går fel i utvecklingsprojekt? Förändring (allt förändras) verksamhet önskemål/krav teknik Andra problem konsulter anlitas som kan it men inte verksamheten de skall stödja, bristande kompetens i flera led för stora system/projekt man försöker göra allt på en gång mjukvara är komplex och ogripbar, system blir alltmer komplexa vilket leder Ell ai färre personer i ledningsposieon är beredda ai säia sig in i hur de fungerar trög process och brist på återkoppling Vad går fel i utvecklingsprojekt? Förändring (allt förändras) verksamhet önskemål/krav teknik Andra problem för stora system/projekt man försöker göra allt på en gång trög process och brist på återkoppling mjukvara är komplex och ogripbar, system blir alltmer komplexa vilket leder Ell ai färre personer i ledningsposieon är beredda ai säia sig in i hur de fungerar konsulter anlitas som kan it men inte verksamheten de skall stödja TradiEonell utveckling visualiserad Hur ska vi nå hit? 7
10 framgångsfaktorer I sin genomlysning listar Standish Group Eo framgångsfaktorer för lyckade projekt. Dessa är: 1. DelakEga slutanvändare 2. Ledningsstöd 3. Tydliga affärsmål 4. Känslomässig mognad 5. Gör bara det som eperfrågas 6. Flexibel process 7. Kunniga projektledare 8. Kunniga medarbetare 9. Handlingskrap 10. Adekvata verktyg Vaienfallsmodeller Kri;k Vaienfallsmodellen har fåi mycket kriek och de flesta hävdar idag ai det är bevisat via undersökningar ai det inte fungerar för ai utveckla it- system. Modernare metoder menar ai man istället borde likna systemutveckling vid ei gemensamt lärande, där beställaren och leverantören Ellsammans lär sig om varandras världar och gemensamt bygger en passande lösning i flera steg (iteraeoner). Hur ska vi nå hit? Ta reda på behov, presentera förslag, KOMMUNICERA, visualisera, testa, gör om och gör rätt. Agil systemutveckling Agile är engelska och betyder smidig, vig, läirörlig. Agil systemutveckling är ei samlingsnamn för ei antal programutvecklingsmetodiker som kan användas vid programvaruutveckling, även kallade läirörliga metoder. Metoderna följer i stort sei samma värderingar, principer och synsäi. Jämfört med Edigare metoder/modeller representerar de mer flexibla säi ai arbeta. Delvis misslyckade) 8
Manifest för Agil systemutveckling Fyra nyckelprinciper: Individer och interakeoner framför processer och verktyg. Fungerande programvara framför omfaiande dokumentaeon. Kundsamarbete framför kontraktsförhandling. Anpassning Ell förändring framför ai följa en plan. Agila utvecklingsmetoder Grundtankarna bakom agilt bygger på ai göra kunden/användaren nöjd med det som utvecklas genom ei mycket nära samarbete under hela utvecklingseden med täta och regelbundna möten mellan utvecklare och beställare/moiagare. Det agila synsäiet anser ai det opare är människor och kommunikaeon än verktyg och formella dokument som löser problem under utvecklingsarbetet. http://agilemanifesto.org/iso/sv/ http://www.agilealliance.org/the-alliance/the-agile-manifesto/ Arbetet bedrivs inkrementellt och iteraevt vilket innebär ai regelbundna mindre leveranser sker och ai saker löpande utvärderas och kan ändras för ai möta nya krav och önskemål. Agila utvecklingsmetoder En annan central grundtanke är ai minimera risken för ai en stor del av ei system befinner sig i ei halvfärdigt läge och inte kan leverera nyia. Ei agilt arbetssäi gör det möjligt för beslutsfaiare ai få ei bäire underlag inför beslut om ai Ellföra yierligare resurser Ell ei projekt. Tolv grundprinciper Vår högsta prioritet är ai Ellfredsställa kunden genom Edig och konenuerlig leverans av värdefull mjukvara. Förändrande krav är välkomna, även sent i utvecklingen. Agila processen skördar förändring Ell kundens konkurrenskrapighet. Leverera fungerande programvara opa med Edsskala från ei par veckor Ell ei par månader, med en förkärlek Ell den kortare Edsskalan. Affärsfolk och utvecklare måste arbeta Ellsammans dagligen under hela projektet. Bygg upp projektet runt moeverade individer. Ge dem den miljö och det stöd de behöver, och lita på dem för ai få jobbet gjort. Den mest effekeva metoden för ai förmedla informaeon Ell och inom ei utvecklingsteam är konversaeon på plats mellan individerna (face- to- face). En fungerande programvara är det huvudsakliga måiet på framsteg. Agila processer främjer en hållbar utveckling. Sponsorer, utvecklare och användare ska kunna hålla en jämn utvecklingstakt på obestämd Ed. KonEnuerlig uppmärksamhet på teknisk kvalitet och god design ökar flexibiliteten. Enkelhet - konsten ai maximera mängden arbete som inte görs - är vikegt. De bästa arkitekturer, krav och design framträder ur självorganiserande team. Teamet ser över med jämna mellanrum hur man ska blir mer effekeva, sedan finjusteras det och man anpassar sii beteende däreper. Agila metoder Feature driven development (FDD) Extreme programming (XP) AdapEve sopware development Dynamic Systems Development Method (DSDM) Crystal Lean sopware development Kanban Scrum 9
Användbarhet MDI, MSI etc. Användbarhet? Användbarhet Användbarhet Förstå grunderna inom användbarhet utvärdering metoder, processer Och lära er att använda dem användarcentrerad utveckling/design designa för god användbarhet planera och utföra utvärderingar/tester Ei användbart system Modeller Mycket enkelt urryckt!: Tillåter användaren ai fokusera på sina (arbets)uppgiper Är effekevt i sin dagliga användning Innehåller relevant informaeon och funkeonalitet Är intuievt och naturligt ai lära sig Är airakevt Designers modell Designer Användares modell Användare Kan jag göra det jag behöver / vill? Kan jag göra det på ei bra säi. Utan större ansträngning, felfrii, kosnadseffekevt, etc. Upplevde jag användningen som rolig semulerande och utan obehag? Om JA på samtliga: 100 % användbarhet!!! System Systembild 10
Modeller Norman ser det hela som kommunikaeon/interakeon mellan två parter: Användaren och Designern. KommunikaEonen sker genom systembilden. Man kan säga ai designerns jobb delas upp i två problem enligt denna modell: Ai förstå användarens mentala modell och skapa en bra designmodell uefrån denna kunskap. Ai bygga en systembild som är konsekvent och klart och tydligt förmedlar denna modell Ell användaren. Modeller Vi skapar dessa mentala modeller för hur något ska användas genom Edigare erfarenheter, träning och handledning. Norman (1990). En mental modell för ei objekt skapas i stort sei genom ai utvärdera dess möjliga "handlingar" och dess visuella struktur. Med ai utvärdera dess möjliga "handlingar" menas: Vad kan man göra med objektet? Exempelvis om vi vill öppna en dörr så kan olika dörrhandtag utlysa olika möjliga handlingar, likaså kan olika knappar/kontroller etc. i ei gränssnii. Modeller Hemsidor Användarcentrerad systemdesign Ei säi ai förhålla sig Ell utveckling och Ellse ai resultatet blir användbart. 11
Användarcentrerad systemdesign Användare De som kommer ai interagera med systemet Inte de som beställer systemet Det finns inget subsetut för rikega användare Centrerad Användarna involveras akevt under hela processen Användarna ska inte vara passiva och bara tycka Ell om färdiga lösningar, de ska vara med och ta fram dem Design All design leder fram Ell en produkt Design är främst en process Design kan också vara en representaeon av en produkt under procesen Jan Gulliksen och Bengt Göransson, 2002. Användarcentrerad systemdesign : en process med fokus på användare och användbarhet. Användarcentrerad systemdesign Vad påverkar designen? Det finns fyra vikega användarcentrerade designakeviteter som ska planeras och äga rum för ai införliva användbarhetskrav i utvecklingsprocessen. Dessa är: ai förstå och specificera användningssammanhanget ai specificera användarnas krav ai ta fram designlösningar som möter användarnas krav ai utvärdera designlösningar mot krav Följande faktorer har vikeg påverkan på designen: Kunskap om användningssituationen Kunskap om användarna Gränssnitt Jan Gulliksen och Bengt Göransson, 2002. Användarcentrerad systemdesign : en process med fokus på användare och användbarhet. Kunskap om människa-dator interaktion (MDI) och design Kunskap om de tekniska förutsättningarna Vad minns ni ifrån TNM040? 12
Användbarhet ny (?) Energy capabilities Processing capabilities Context of use Connectivity Data input/output methods Tack vi ses på torsdag nästa vecka! (Esdag har utgåi) Screen size Screen resolution 13