3.5 Användarapplikation och GUI
3.5.2 Metod
Detta stycke beskriver de metoder som använts för att ta fram en kravlista för RSI GUI och efterföljande designförslag eller ”mockups”.
Framtagning av kravlista för RSI GUI
För att komma fram till en lista av funktionalitet som bör finnas för presentationsmiljön för RSI under projektet har ett antal aktiviteter genomförts. Fyra huvudsakliga faktorer har påverkat kravlistan. Den första är intervjuer med användargrupper, den andra är VViS-enkäten som genomförts av Trafikverket och den tredje är viktiga erfarenheter från tidigare projekt såsom SRIS, MobiRoma och nu senaste BiFi. Den fjärde faktorn är projektgruppens egna tankar och idéer kring möjligheterna med RSI. Figur 85 visar en schematisk bild över arbetsgången att ta fram kravlistan för presentationsmiljön för RSI.
Figur 85: Arbetsgång vid framtagning av kravlista för RSI GUI.
Från de tilltänkta användargrupperna har samlats in synpunkter om vad som kan underlätta dennes arbete, främst med utgångspunkt från vad som upplevs saknas i VViS idag.
Kontroller har gjorts för att säkerställa att den planerade informationen från RSI är av intresse, men eftersom RSI är ett nytt koncept och användargrupperna inte har fått möjlighet att helt se potentialen i RSI så har projektgruppen valt att tillåta en viss höjd mellan vad som användargrupperna efterfrågar och vad som planeras för RSI.
VViS-enkäten har erbjudit information om hur de användargrupperna ser på den nuvarande versionen av VViS. Vissa av förbättringsförslagen som framkom i enkäten och som ligger nära området för RSI har i stor utsträckning fått påverka tankarna kring kravlistan för RSI. Som tre exempel på konkreta önskemål i VViS-enkäten som kommer finnas med i RSI kan nämnas:
• Väglagsredovisning för sträckor mellan mätstationerna • Vägledning för åtgärdsplanering (saltmallen)
• Redovisning av utförda åtgärder (saltning och plogning)
Störst påverkan på formuleringen av kravlistan för RSI GUI och presentation har dock projektdeltagarnas egna idéer om de nya möjligheterna med RSI varit. Anledningen är att konceptet är nytt och tankarna är endast i begränsad omfattning spridd utanför
projektgruppen. De som har störst möjlighet att känna till möjligheterna och begränsningarna och formulera kraven på RSI är därför projektdeltagarna själva.
Med utgångspunkt från dessa tre källor av information hölls en workshop där idéer kring vad som skall presenteras i RSI diskuterades. Diskussionen på denna workshop kretsade kring frågor som:
• I en perfekt värld, vad skulle vi vilja ha för funktionalitet i RSI? • Vilken typ av data går det få från bilarna?
• Vad finns det för möjligheter? • Vad är begränsningarna?
• Hur ska vi bäst kompromissa för att fylla användarnas behov givet begränsningarna? De tankar och resultat som kom från denna workshop arbetades sedan genom och
formaliserades i en kravlista för vad projektgruppen anser viktigt och realistiskt att ha med i en första version av presentationsmiljön för RSI.
Framtagning av designförslag(mockup) för RSI GUI
Utifrån den kravlista som formulerats för RSI GUI så hölls sedan en andra workshop där ett antal relaterade hemsidor och system för visning och presentation av bl.a. väderprognoser studerades. Funktionskraven från kravlistan och presentationsidéer från andra system sammanfogades med egna idéer om design för RSI GUI och utifrån detta skapades ett antal bilder eller s.k. ”mockups” där en tilltänkt presentationsmiljö för RSI presenterades. Detta underlag och dessa mockups utgör sedan en grund för programmeringsarbetet.
Figur 86: Arbetsgång vid framtagning av mockup för RSI GUI.
Utveckling och applikationsprogrammering av RSI utifrån designförslag
Designförslagen och de mock-ups som tagits fram under ovanstående workshops har hittills enbart utgått från funktionalitetsönskemål och under denna fas har inte
programmeringstekniska begräsningar och möjligheter vägts in. För att fånga precis alla detaljer som RSIs designförslag består av, görs en detaljerad nedbrytning av den tekniska funktionalitet som krävs för att skapa ett RSI som motsvarar designönskemålen. Detta arbete skedde genom att en ”user story” skapades och delades upp sina minsta
beståndsdelar. Till en början skedde detta med fördel på post-it-lappar för enkel och tydlig överblick för att i nästa skede digitaliseras. I nästa stycke beskrivs denna user story och vidare planeringsarbete i mera detalj.
Figur 87: "Planeringsvägg för RSI". Varje Post-It-lapp beskriver en liten del funktionalitet som behövs för att förverkliga RSI
”User story RSI” - detaljerad kartläggning av teknisk funktionalitet som krävs för RSI
För att maximera nyttan med RSI behövs en tilltalande och användarvänlig applikation. För att funktionaliteten hos applikationen ska bli bästa möjliga inom uppsatta tids- och
budgetramar så måste användarsituationerna specificeras i detalj, detta för att utveckla rätt saker på rätt sätt. Under första delen av projektet RSI, som beskrivs ovan, genomfördes arbetet med att skapa koncept och mockup av RSI-applikationen för att kunna ta in synpunkter från användargrupperna. Under innevarande moment har en sammanvägning av alla synpunkter gjorts och översatts i detaljerade tekniska funktionsbeskrivningar. Resultatet från detta arbete bildar en så kallad ”user story” som beskriver hur en användare kommer använda RSI och vilken funktionalitet som krävs för att kunna använda RSI på det tilltänkta sättet.
En ”user story” bildar en översikt över användningssituationerna och ger på samma gång en detaljerad ”ToDo-lista” med funktioner som kan prioriteras i förhållande till varandra. Arbetet med den faktiska utvecklingen av applikationerna handlar sedan om att prioritera mellan alla ToDo-punkter och beta av dem en efter en. Figur 87 ovan beskriver den första analoga versionen av denna ”ToDo-lista” och Figur 88 visar den digitaliserade versionen.
Figur 88: User story for applikationen för RSI
Iterationer av GUI-utveckling
Programmeringsarbetet med att skapa webapplikationen RSI har genomförts i en iterativ process för mjukvaruutveckling, likt metoden SCRUM18. Utifrån den övergripande user story som skapats och den funktionalitet som behövs så adderas funktionalitet stegvis in i applikationen under en-veckas iterationer, s.k. ”spintar”. Varje veckas iteration börjar med ett avstämningsmöte där föregående veckas arbete diskuteras och godkänns eller ej godkänns. Därefter prioriteras den kvarvarande funktionaliteten och en ny sprint backlog och todo-lista skapas för kommande vecka. Ett exempel på översiktsplanen för en vecka visas i Figur 89.
Figur 89: Exempel på en veckas iteration / ToDo-list
Med ett iterativt arbetssätt som används i detta projekt skedde hela tiden små förbättringar till applikationen och användargränssnittet. Några steg i iterationsprocessen kan ses i nedanstående bilder.
Figur 91: Exempel på tidig iteration 2: Addering av aggregerad väglagsinformation i diagramform
Serverteknologi och ”back-end” för RSI
För att driva RSI och hantera trafik till och från användare genom webbserver och
kartservrar har en omfattande server-infrastruktur skapats. Den fysiska server som RSI kör på hanteras av AcuGIS som är en tjänsteleverantör inom webbhosting specialiserade på applikationer med olika kartlösningar.
På AcuGIS finns programvara som hämtar data från Klimators servrar där data från klimatmodeller och tolkmodeller sparats. När denna data når AcuGIS läggs den in i en PostGre-databas och bearbetas så att den är förberedd att hämtas när en användare anropar RSIs hemsida. När detta sker och en användare öppnar applikationen på
roadstatus.info/app så anropas en GeoServer som ligger hos AcuGIS och denna geoserver genererar kartor utifrån data i PostGRE-databasen. Dessa kartor skickas sedan till användares webbläsare där de ritas ut.
Programuppdateringar för version 2 av applikationen.
Baserat på generella användarkommentarer och feedback från riktade utfrågningar bland användare till RSI skapades i februari 2015 en kravlista med uppdateringar till RSIs webbapplikation. Arbetet med att införa dessa uppdateringar till RSI genomfördes enligt samma metod som finns beskriven i avsnitt 0 ovan. Utifrån kravlistan så uppdaterades alla ”user storys” och bröts sedan ner till funktionalitetslistor som sedan stegvis
implementerades med hjälp av samma iterativa arbetssätt som tidigare utvecklingsarbete inom RSI.