Projektuppgift ACSD HT 2005, grupp 3. Datum:

Projektuppgift ACSD HT 2005, grupp 3 Projekt e-el enligt Deborah J.Mayhew Usability engineering lifecycle Datum: 2005-12-11 Jan Olofsson Mattias Simonsson Sassan Ashkan Kristoffer Eriksson Författare: Jan.Olofsson.4891@student.uu.se Mattias.Simonsson.5851@student.uu.se Sassan.Ashkan_Far.1085@student.uu.se eriksson.kristoffer@gmail.com

INNEHÅLLSFÖRTECKNING 1 INLEDNING...3 1.1 Bakgrund...3 1.2 Syfte med projektplanen...3 2 PROJEKTÖVERSIKT...3 2.1 Mål...3 3 METODVAL...3 3.1 Användarmedverkan...3 3.2 Usability engineering lifecycle...4 4 GENOMFÖRANDE AV PROJEKTET...5 4.1 Kravanalys(Requierement analysis)...5 4.1.1 Användarprofiler...5 4.1.2 Kontextuell uppgiftsanalys...6 4.1.3 Generella Design Principer...7 4.1.4 Plattformsmöjligheter och Begränsningar...8 4.1.5 Användbarhetskrav...8 4.2 Design/test/utveckling....8 4.2.1 Nivå1...9 4.2.2 Nivå2...10 4.2.3 Nivå3...11 4.3 Installation...11 4.3.1 Feedback från användarna...11 4.3.2 Utvärderingstekniker...11 4.4 Projektavslut...12 5 TIDPLAN...13 6 PROJEKTORGANISATION & ROLLER...13 7 ANALYS...15 7.1 Vad var bra...15 7.2 Vad var mindre bra...15 8 KÄLL- OCH LITTERATURFÖRTECKNING....16 8.1 Böcker...16 8.2 Internet...16-2 -

1 INLEDNING 1.1 Bakgrund Konkurrensen mellan elbolagen ökar allt mer och som elkonsument finns det en uppsjö av elbolag och distributionsformer och avtalstyper att välja mellan. Problemet är bara att det inte är helt enkelt att jämföra dessa utifrån de förhållanden som man själv har eftersom det är en mix av tariffer, skatter, abonnemangsavgifter, installationsavgifter o engångskostnader att ta med i beräkningarna. För att göra det ytterligare komplicerat kan man ta med i beaktande att många bolag också erbjuder paket som kombinerar telefon, bredband och el/värmedistribution och till och med ibland försäkringar. 1.2 Syfte med projektplanen Syftet med projektplanen är att visa hur projektupplägget ser ut för arbetet med utveckling och driftsättning av en plattform som möjliggör att kunderna får största möjliga användbarhet i valet av e-el. 2 PROJEKTÖVERSIKT 2.1 Mål Effektmål Tillse att kunderna får största möjliga användbarhet i valet av e-el. Tillse att de tjänster som systemet tillhandahåller är användbara, enkla, nyttiga, tillförlitliga och oberoende. Projektmål Projektmålet är projektets åtagande och ansvar. Projektmålet beskrives av tre mål mot vilka projektet skall styras Produktmål = Förväntat resultat = den produkt som projektet skall leverera Tidsmål = Tidsramar, färdigtidpunkter Kostnadsmål = Ekonomiska ramar, finansiering Produktmål Projektorganisationen skall leverera följande: Att utifrån att användarcentrerat arbetssätt ta fram och driftsätta en verifierad och dokumenterad plattform för e-el. 3 METODVAL 3.1 Användarmedverkan. I förstudierapporten har man identifierat externa och interna användare. En viktig förutsättning för en lyckad implementation är att de verkliga slutanvändarna får vara delaktiga i framförallt utformningen av användargränssnittet i systemet och att samtliga projektdeltagare har ett användarcentrerat synsätt. För att projektet skall kunna leverera i tid avser vi att driva det med korta ledtider och med förhållandevis få användare. Det är därför viktigt att rätt användare identifieras och att projektet har tillgång till dessa användare under utvecklingens olika faser. Vår ambition är att hitta rätt användare och vi ser att följande riktlinjer hjälper oss i detta arbete: - 3 -

Riktlinjer för urval av användare: Baserat på frivilligt deltagande, ingen projektdeltagare skall tvingas vara med. Flexibla användare med stark social kompetens. Fler representiva användare än domänexperter. Urvalsfaktorer: Maximerad skillnad mellan olika användarkategorier i avseende på: Könsfördelning. Rätt åldersfördelning som representerar slutanvändarna. Mångkulturellt. Datorvana. Olika Yrkeskategorier 3.2 Usability engineering lifecycle. Vi avser att använda utvecklingsprocessen Usability engineering lifecycle som kort kan beskrivas enligt följande. Bild1 Visar en schematisk bild över processerna i The usability engineering lifecycle. 1 Processen består av tre huvudprocesser Kravanalys, Design/test/utveckling och Installation. Se bild 1 ovan Där man i Kravanalysen Identifierar vilka användare (profiler) som kommer att använda systemet. Tar farm underlag som beskriver användarnas miljö samt hur de arbetar. Krav på den tekniska miljön som kommer att användas. 1 Källa: http://drdeb.vineyard.net - 4 -

Där man i Design/Test/Utveckling i tre nivåer Analyserar hur användarna utför sin arbetsuppgift, Beskriver användargränssnittet och användarnas interaktion på konceptuell nivå. Tar fram skisser/prototyper för utvärdering. Tar fram standarder av skärmlayouter. Tar vid behov fram speciella Input/Output enheter. Utvärderar och förbättrar genom återkoppling från användarna. Där man i Installation. Utvärderar det driftsatta systemets användbarhet genom dialog med användarna i syfte att kontinuerligt förbättra systemet. 4 GENOMFÖRANDE AV PROJEKTET Projektet som helhet är uppdelat i fyra Faser där Fas1 är Kravanalys, Fas2 är Design test och Utveckling, Fas3 är Installation och Fas4 Projektavslut. 4.1 Kravanalys(Requierement analysis). 4.1.1 Användarprofiler Till att börja med måste vi avgöra vilka som är de verkliga slutanvändarna. Enligt vår uppfattning är det i första hand konsumenter som köper el, men vi har också de användare som ska sköta de administrativa uppgifterna kring systemet. Därför får man dela upp grupperna i interna och externa användare. 4.1.1.1 Externa användare De externa användarna är alltså konsumenterna. Det är naturligt att tänka att majoriteten är av vuxen befolkning, men för att få djupare insikt i profilerna behöver man utföra vissa ytterligare steg. 1. För att få fram tydligare kategorier kommer vi att kontakta el-bolagen och be dom om information. Bolagen har troligtvis redan bra insikt i vilka som köper el. 2. När vi har kategorierna så behöver vi avgöra de relevanta karaktärsdragen som har inflytande på hur systemet ska byggas upp. Här får vi samlas tillsammans och diskutera vilka frågor som passar i ett frågeformulär för att få fram den informationen vi behöver. Till hjälp kan vi ta in ett par representativa och kunniga användare. Viktiga karaktärsdrag: Psykologiska karaktärsdrag t.ex. attityd och motivation Kunskap och erfarenhet t.ex. datorvana Arbets- och uppgifts karaktärsdrag t.ex. frekvens i användandet Fysiska karaktärsdrag t.ex. färgblindhet 3. Efter detta granskar vi frågeformuläret och expanderar det för att passa projektet så bra som möjligt. Till det skriver vi en introduktion för formuläret där vi förklarar syftet och fördelarna med det. 4. Vi skaffar feedback på formuläret från beställaren. 5. Eventuell revidering beroende på feedback. - 5 -

6. Vi bjuder in en liten grupp potentiella användare och går igenom frågorna med dom för att upptäcka eventuella oklarheter i frågorna, diffusa ord, om formuläret är komplett och om någon av frågorna är olämplig. Två till tre användare ur varje kategori ska räcka för detta. 7. Frågeformuläret går igenom ännu en revidering för att infoga feedback från intervjun med den lilla gruppen användare. 8. Nu bestämmer vi ett urval av användare ur varje kategori som vi skall skicka frågeformuläret till. Eftersom detta kan bli väldigt många så kan vi inte förvänta oss mer än 10 % svarsfrekvens, dock måste vi sikta mot att få svar från åtminstone 100 personer från varje kategori. Jämn fördelning av svar mellan kategorierna är viktig, så skulle någon ha färre får vi göra ett nytt urval för denna. 9. Val av distribueringsmetod för formulären har stor inverkan på svarsfrekvensen. Elektroniskt via email är en metod, men eftersom antalet personer som regelbundet kollar sin email är lågt är denna metod kanske inte att föredra. Ett bättre alternativ vore ordinarie post, där man inkluderar ett frankerat kuvert med färdig adress för att underlätta svarandet. Deadlinen ska vara tydlig, men man ska även uppmuntra de som missar den att skicka in sina svar ändå. 10. I detta steg designar vi en analysteknik och dataposter för svaren, antingen med något datorprogram eller med papper, penna och räknare. 11. Allt eftersom svaren kommer in så fyller vi i posterna. 12. När alla svar är inne, eller vid deadline, så summerar vi och analyserar vi svaren vi har fått in. 13. Vi tolkar våra data och skriver en kort sammanfattning av de viktigaste karaktärsdragen hos våra användarkategorier. Vi samlar även ihop de generella behoven för kategorierna utan att notera någon speciell prioritering än. 14. Sist presenterar vi resultatet för de inblandade parterna och lägger till våran rapport till produktens s.k. Style Guide. 4.1.1.2 Interna användare De användare som skall sköta systemet och utföra administrativa uppgifter är de interna, alltså de anställda. I och med att systemet är nytt så har man inga redan anställda att utgå ifrån, men beställaren bör ha en hygglig bild av vilket folk han/hon vill anställa. Stegen för att ta fram profiler över användarna och deras behov är likadant som för de externa förutom att man väljer andra kategorier av användare. 4.1.2 Kontextuell uppgiftsanalys Metoden fokuserar på projekt där produkten redan är definierad. Syftet är att hitta en användarcentrerad modell av det nuvarande arbetet som utförs. Dvs. man vill förstå hur användare tänker, talar och tar sig till när de utför en uppgift i sin naturliga arbetsmiljö. - 6 -

Vi utför tre grundläggande steg: 1. Samlar bakgrundsinformation om arbetsuppgiften. Håller möte med alla projektmedlemmarna och intervjuar dessa för att få deras perspektiv på vad produkten ska erbjuda. Träffar representanter för användarna och spenderar tid med dem för att få en förståelse över vilka artefakter som har inverkan på deras arbete. Fokus ska ligga i att förstå hela arbetssammanhanget. Baserat på de tidigare stegen och de användarprofiler vi har satt upp så identifierar vi och dokumenterar ett par nyckelanvändare och användningsfall. 2. Samlar och analyserar data från kontextuella observationer och/eller intervjuer där riktiga användare får utföra arbetsuppgifter i sin naturliga arbetsmiljö. Dessa understeg utförs iterativt och man dokumenterar och analyserar ett par observationer i taget. Dokumenten kan man uppdatera och förbättra mellan iterationerna. När vi genomför de kontextuella observationerna/intervjuerna fokuserar vi på följande frågor: o Huvudartefakterna och objekten i arbetet. o Användarscenarios / användningsfall. o Insikt i de riktiga användar- och affärsmålen. o Insikt i användarnas arbetsmodeller. o Användarnas terminologi och jargong. o Statistik över användningsfallen, t.ex. antalet fel. o Insikt i problem, fel och annat som kan förbättras. o Arbetsmiljön. Vi observerar och intervjuar tre till sex användare ur varje nyckelkategori för ett flertal timmar. Vi dokumenterar arbetsmiljöanalysen. Vi konstruerar uppgiftsscenarios. Vi dokumenterar uppgiftsanalysen. 3. Konstruerar en organisationsmodell av de nuvarande användaruppgifterna. Tillsammans med de uppgiftsscenarios vi skapat i föregående steg så lägger den grunden till Work Reengineering. Denna dokumenteras i uppgiftsanalysen tillsammans med våra uppgiftsscenarier. Först identifierar vi användarnas huvudsakliga uppgifter utifrån det tidigare insamlade materialet från observationerna. Vi skapar oss en första modell där vi ordnar in objekten i hierarki och grupperar saker som ser ut att höra ihop logiskt sett och i termer av arbetsflöde. Sedan skapar vi en slutgiltig modell empiriskt, d.v.s. utifrån erfarenheterna med den första modellen. För att sortera in aktiviteterna och artefakterna i hierarkin så tar vi hjälp av användarna. Vi jämför de modeller som vi får från användarna och försöker få fram en generell hierarki som fångar alla gemensamheter. 4.1.3 Generella Design Principer Till skillnad från de andra momenten i denna fas så dokumenteras denna ej i Style Guide. - 7 -

4.1.4 Plattformsmöjligheter och Begränsningar Vi väljer att hoppa över detta moment i Usability Engineering Lifecycle eftersom vi tänker oss en web-baserad lösning där användarnas val av plattform inte har någon inverkan. 4.1.5 Användbarhetskrav Som input till Användbarhetskraven använder vi användarprofilerna och uppgiftsanalysen. Den är även baserad på generella affärsmässiga mål. Man ska helst ha användare involverade i framtagningen av kraven så mycket som det går. 4.1.5.1 Funktionella krav: Kvalitativa krav för användbarhet. Vad ska den göra? De funktionella kraven är väldigt användbara i styrandet av de första designförslagen. 4.1.5.2 Icke-funktionella: Kvantitativa krav för användbarhet. Hur ska den göra det? Eftersom de funktionella kraven är väldigt svåra att mäta så behöver man något för att avgöra om systemet uppnår sina mål. Där kommer de icke-funktionella kraven in i bilden. För att få fram kraven tar vi hjälp av användarna och alla andra i projektet i dessa steg: Vi hämtar krav ur användarprofilerna. Vi hämtar krav från den kontextuella analysen. De affärsmässiga målen undersöks och vi försöker översätta dessa till krav. Ur dessa tre steg identifierar vi och gör utkast över kvalitativa krav. Dessa dokumenteras mer noggrant i ett senare steg. Prioriteringar av kraven sätts efter dem som är nödvändigast för projektet, dem som är mindre viktiga och dem som det vore trevligt att uppfylla men som inte är kritiska. Nu formulerar vi kvantitativa krav utifrån de utkasten av kvalitativa krav vi gjorde tidigare. Vi väljer sådana med hög prioritering som verkar lätta att kvantifiera. Vi dokumenterar alla de krav, både kvalitativa och kvantitativa, som fått prioriteringar. De dokumenterade kraven ska nu granskas av projektledningen. Det sista steget är att etablera måttstocksdata för relativa kvantitativa krav, d.v.s. att man undersöker andra system eller produkter som den aktuella ska jämföras med. Om vi väljer att utföra detta steg visar sig först efter vi har satt upp kraven. Allt dokumenteras slutligen i våran Style Guide. 4.2 Design/test/utveckling. Detta är fas två och indata till design, testning och utvecklingsfasen är användbarhetsmål resp. generella användargränssnittsprinciper och riktlinjer från kravanalysen i den första fasen. I denna fas så nämner vi att vi ska ha ett samarbete med användare. Med detta menar vi både de externa och interna användarna. De delar som vi involverar användarna i är de delar där input från användarna är relevant. I vissa delar så finns det ingen mening med att ta med användarna eftersom det kommer att handla om en reflekterande, förberedande och analyserade del som endast systemutvecklarna är delaktiga i. - 8 -

4.2.1 Nivå1 Anledningen till att både involvera interna och externa användare i denna fas är att de båda användargrupperna kommer att samarbeta i det slutgiltiga systemet. Genom att även låta de samarbeta under utvecklingsprocessen tror vi att vi kan uppnå bättre resultat. Fas två är indelad i tre olika nivåer. Den första nivån behandlar högnivådesign i fyra steg. 4.2.1.1 Work Reengineering Work reengineering, av arbete är den första delen i fas två där indata från fas ett omarbetas vad gäller organisation och arbetsflöde. Detta är för att rationalisera arbetet och anpassa det för den fortsatta designen, utvecklingen och testningen. Ingen gränssnittsdesign involveras här. Vi utgår från dokumentationen i projektets Style Guide som har utarbetats i kravanalysen och omarbetar informationen på en abstrakt nivå med avseende på organisation och arbetsflöde. Gränssnittsdesign lämnas till senare designavsnitt i fasen. Vi försöker identifiera delar i problematiken som vi kan automatisera och förbättra för användarna. 4.2.1.2 Konceptuell modelldesign Här skapas en högnivådesign av informationsflödena i systemet. På den här nivån blir det lite mer konkret än i den första, men det är långt ifrån någon färdig modell. Detta är mer ett underlag till nästa del där man skapar en konkret modell så att användaren kan sätta sig in i systemutvecklarnas tankebanor. Utan att involvera användarna skapar vi underlag i form av en abstrakt design av systemet. Detta underlag består av idéer utifrån diskussioner som i kommande steg behandlas tillsammans med användarna. 4.2.1.3 Konceptuella Modellprototyper Här skapas prototyper och pappersskisser som åskådliggör den högnivådesign som har skapats i tidigare steg, så att användarna kan sätta sig in i det systemutvecklarna ser som problem. Man vill uppnå ett stadium där båda parterna pratar om samma problem och mål. Här väljer vi att involvera användarna i arbetet. Tillsammans skapar systemutvecklarna och användarna pappersskisser som fungerar prototyper på en fortfarande mycket abstrakt nivå. I detta skede är det viktigt att modellen inte framstår som för perfekt. Då kan det hända att användarna tror att modellen är färdig och inte går att påverka. Den aktuella prototypen är och ska endast vara ett exempel som användarna i alla högsta grad kan påverka. Det är prototypens hela mening, en modell som sedan ska utvecklas till det färdiga systemet. 4.2.1.4 Iterativ Konceptuell Modellutvärdering Modellerna och prototyperna ifrån föregående två steg utvärderas och utvecklas i iterativa steg genom t.ex. formell användbarhetstestning. Här får användarna testa systemet med minimal träning och ingripande med hjälp av skisser och prototyper från den konceptuella modelldesignen som om detta vore systemets verkliga användargränssnitt. Här utför vi iterativ testning av det som beskrivs i de två föregående steget. Denna process utförs med användarna i fokus tills alla större användbarhetsbuggar är identifierade och bearbetade. När vi testar systemet använder vi skisserna och prototyperna från den konceptuella - 9 -

4.2.2 Nivå2 modelldesignen som om de vore riktiga användargränssnitt. När denna del är avklarad och den konceptuella modellen känns någorlunda stabil, kan vi påbörja design av systemarkitekturen. I nivå två identifieras skärmdesignstandarder i fyra steg. 4.2.2.1 Skärmdesignstandarder Skärmdesignstandarder är en mängd produktspecifika konventioner som specificeras och utvecklas baserat på företagsspecifika standarder som t.ex. Microsoft Windows, Apple Macintosh. Dessa utvecklas baserat på resultat från kravanalysfasen och den konceptuella designmodellen, så att sammanhang och konsekvens uppnås i användargränssnittet. Vi utgår från fas ett och föregående nivå för att utveckla och specificera standarder och konventioner för erhålla sammanhang och konsekvens i systemet. Detta för att få lika struktur på t.ex. fönster och menyer etc. på skärmen. Valet baseras bl.a. på datorvana som är ett delresultat från identifieringen av användargrupper. 4.2.2.2 Prototyp av skärmdesignstandarder Här skapas en aktiv prototyp baserat på de tidigare resultaten i processen, såsom den konceptuella modelldesignen och den valda skärmdesignstandarden. Denna prototyp tillämpas på gränssnittet från nivå ett i fasen. Vi skapar en aktiv prototyp för att presentera de skärmdesignstandarder vi valt för användaren. Även här är användaren en aktiv del i utvecklingsprocessen. 4.2.2.3 Iterativ Skärmdesignstandardutvärdering En iterativ utvärdering i likhet med den för den konceptuella modelldesignen utförs här för den konstruerade prototypen Under detta utförande omdesignas successivt de valda skärmdesignstandarderna. Detta för att eliminera buggar och i möjligaste mån nå användbarhetsmålen. Därefter kan detta tilläggas till projektets Style Guide. Här utför vi, i samarbete med användarna, en iterativ utvärdering av de valda skärmdesignstandarderna. Vår avsikt är att få bort så många buggar som möjligt inom denna utvecklingsdel och sedan anpassa standarderna för att tilläggas i Style Guide-dokumentationen. 4.2.2.4 Utveckling av Style Guide Efter utvärderingsiterationerna i de två första nivåerna har man en validerad och stabiliserad konceptuell modelldesign samt skärmdesignstandarder. Dessa är samlas i projektets Style Guide-dokumentation, som redan innan innehåller resultaten från kravanalysfasen. I kommande nivå följer man denna dokumentation för att säkra kvalitet, sammanhang och konsekvens. Resultaten från projektets tidigare Style Guide (kravanalysdata från fas ett) tillsammans med resultaten från nivå ett och två i fas 2 (den konceptuella modelldesignen och skärmdesignstandarderna) placeras nu tillsammans i en ny Style Guide för att förbereda utveckling av ett mer konkret användargränssnitt i fas tre. - 10 -

4.2.3 Nivå3 Här slutförs designen baserat på nivå ett och två. 4.2.3.1 Detaljerad Användargränssnittsdesign Utifrån den förfinade och validerade dokumentationen i projektets Style Guide utförs här detaljerad design av den kompletta produktens användargränssnitt. Denna design styr sedan produktutvecklingen. Tillsammans med användarna diskuteras och utformas detaljerad design av systemets användargränssnitt. Detta arbete grundar sig på den Style Guide som utvecklades i föregående avsnitt. Samarbetet ska leda till en design så pass färdigställd att den ligger till grund för hela den konkreta produktutvecklingen. 4.2.3.2 Iterativ Detaljerad Användargränssnittsdesign I likhet med tidigare iterativa tester utförs i detta steg användbarhetstestning, men denna testning kommer att fortlöpa genom hela produktutvecklingen. Detta är för att kunna eliminera det totala systemets möjliga buggar från denna nivå, tidigare nivåer och föregående fas. På så vis förfinas användargränssnittet och det kan valideras mot användbarhetsmålen. Vi utför iterativ utvärdering likt de för föregående nivåers utvärderingar fortlöpande under kommande utveckling. Det är nu viktigt att både användarna och systemutvecklarna genomgår denna testprocess för att här testa även föregående nivåer ytterligare och man vill eliminera så många av systemets tänkbara buggar, inte bara just de senaste användargränssnittsbuggarna. Användargränssnittet vidareutvecklas under iterationerna för att förfinas och matchas mot användbarhetsmålen. När funktionaliteten i produktens Style Guide-dokumentation känns tilltalande och komplett använder vi denna Style Guide som utdata ur denna fas. 4.3 Installation. 4.3.1 Feedback från användarna Det sista steget i processen inleds efter installation av plattformen och den har varit i drift en tid. Nu kommer det att finnas ett antal verkliga expertanvändare. Dessa användare kan ge bra och korrekt feedback på ex användbarhet i systemet eller delar av systemet som kanske inte utvärderats tidigare. Beroende på vad vi vill utvärdera ex användbarhet så finns olika tekniker som kommer användas. Syftet med utvärderingen är att: Ge input till underhåll förvaltning av plattformen. Ge input till nya framtida releaser. Ge input till design och utveckling av likartade projekt eller produkter som kan komma att använda samma användarprofiler. Lära oss mer om användbarhet som kan vara tillämpbar i framtida utvecklingsprojekt inom vår organisation. 4.3.2 Utvärderingstekniker Följande tekniker kan vid behov, användas vid utvärdering: - 11 -

Utvärdering av användbarhet (Usability testing): I en driftsatt miljö, så kan man använda ex video inspelning för att inte störa användaren i sitt arbete. Intervjuer: Genom intervjuer ex (Contextual Inquiry) kan man få subjektiv feedback från användarna som baseras på deras verkliga erfarenheter av systemet. Fokusgrupper: Här kan man få användarna att prata med varandra om vad de tycker om systemet. Den dynamik som en gruppdiskussion ger, kan ge feedback av annorlunda typ. Formulär(questionnarie): Genom att använda ett strukturerat frågeformulär, kan man få svar på explicita frågor från många användare. Användnings studie: Genom denna studie kan man identifiera exakt hur systemet används. 4.4 Projektavslut Projektet avslutas och en projektrapport skrivs, där vi tar upp vad som har fungerat bra och vad som fungerat mindre bra. Samtliga projektdeltagare ges möjlighet att ge feedback på såväl det nya systemet som arbetet i projektet. - 12 -

5 TIDPLAN Vår uppskattning är att detta projekt kommer att omfatta ca 5700 timmar totalt inklusive medverkan av externa användare. I kalandertid bör projektet kunna genomföras på 4-6 månader. 6 PROJEKTORGANISATION & ROLLER Projektets organisation ser ut enligt följande: - 13 -

Beställaren Anger effektmålen, fastställer budget och tilldelar ekonomiska resurser till projektet. Fastställer projektdirektiven och ev. ändringar i detta Utser projektägare Utser styrgruppen Utser projektledaren Godkänner projektets resultat Projektägaren Är ordförande i styrgruppen Är ytterst ansvarig för projektets planering och genomförande. Fastställer mål, direktiv och planer som utarbetas utifrån uppdragsgivarens projektdirektiv. Fastställer tids- och kostnadsramar. Tilldelar resurser Beslutar om framlagda förslag Avvecklar projektet. Styrgruppen Stöder projektägaren i hans arbete. Projektledare Ansvarsområde är att: Planera projektet Föreslå medarbetare Förhandla och skriva avtal med linjeorganisationen om lån av medarbetare Organisera arbetet Leda och fatta beslut i projektet i enlighet med projektdirektivet, projektplanen och tilldelad budget Kontinuerligt följa upp planer och kostnader Vid behov delegera uppgifter vidare till medarbetare inom projektet Löpande informera intressenterna Vara föredragande vid möten med styrgruppen Avsluta projektet Aktivitetsansvarig Genomför aktiviteter enligt direktiv från projektledaren. Projektgrupp Har till uppgift att samordna arbetet men även i mindre projekt vara den grupp som genomför aktiviteterna. Sammansättningen kan således vara av olika roller beroende på typ av projekt men ska som regel bestå av det kompetenser projektledaren har behov av för att lösa uppgiften. Projektgruppen är vanligtvis sammansatt av projektledaren, delprojektledarna och projektadministratören. Referensgruppen Referensgruppen är ett rådgivande organ som är sammansatt av intressenter till projektets resultat. Referensgruppen är projektets bollplank. I detta projekt behövs referensgrupp både för externa användare, interna användare och förvaltare. - 14 -

7 ANALYS. 7.1 Vad var bra Vi tror att denna modell kan var relativt enkel att koppla till en redan etablerade systemutvecklingsmetoder som exempelvis den mest kända kommersiella versionen av UP, RUP. Det känns lite som att den är designat för det eftersom det är iterativa processer som även RUP har. Ingen i gruppen har praktisk erfarenhet av detta men förmodligen så blir det inte ett helt nytt och fristående extrasteg i utvecklingen, utan mer som en integrerad del i den redan befintliga systemutvecklingen. Om det nu inte är så, blir det nog mycket svårt att praktiskt jobba med någon form av ACSD överhuvudtaget. I denna(mdi) bransch är tid pengar i en högre grad än andra IT-projekt. Det är alltför vanligt med alldeles för lite resurser och tid att utföra dess uppgift. Även om det vetenskapligt är väl bevisat att det i MDI och speciellt att kunden är involverad i utvecklingen är enormt viktigt för ett projekt ska gå i lås, så resonerar tyvärr inte beställarna riktigt så än. Varför ska jag som beställare lägga ned dyrbar tid och resurser på lullull som att det ska vara snyggt design för användaren. Fortfarande ser nog de flesta beställare MDI som något lite flummigt. Får man däremot in MDI i form av ACSD i den befintliga processen, integrerar den med tex. RUP så blir det nog ett annan respons. På så sätt får man ut krav som stämmer med verkligheten och spårbarhet som leder till att när systemet är klart kunna verifiera om systemet uppnår dess ställda krav/ behov/mål. Till dess att attityden hos beställaren har ändrats så tror vi att det är de enda sättet att få in ACSD i praktiken. 7.2 Vad var mindre bra UEL börjar bra. Det verkar vara mycket fokus på att användarna ska vara med i kravframtagningen, d.v.s. fas 1. Dock är det mycket luddigt över hur man skall välja de representativa användarna som används i de olika stegen. Om man har en stor population användare så kan processen att hitta ett bra urval ur denna bli ganska svår. Ett första steg vore att först hitta de som är frivilliga att ställa upp i projektet. Boken beskriver detta dåligt. I detta fallet när det gällde e-el, så kändes det som att skärmdesigndelarna inte var så viktiga och tar upp en alldeles för stor del av resurser. Här skulle vi enkelt kunna välja en skärmdesignstandard som passar användarna utan att behöva genomgå någon längre iterativ utvärderingsprocess. Antagligen är majoriteten av både externa och interna användare väl bekanta med operativsystemet Microsoft Windows vilken skulle innebär att detta vore ett bra val. Dvs, Microsoft Windows skärmdesignstandarder skulle då användas rakt av för att undvika främmande miljöer. I vårt fall och även generellt sett kanske man skulle kunna tänka sig några fler steg inom gränssnittsdesignen i den sista nivån. Bokens modell verkar lägga större fokus på skärmdesignstandarder än på gränssnittsdesignen. Vi tycker att mer arbete och behandling av gränssnittet är en större problematik vid systemutveckling än just val av skärmdesignstandarder. Alla metoder har för- och nackdelar, vilka beror på projektet ifråga. Att använda frågeformulär när det gäller ett sånt stort antal användare tvingar oss till att begränsa oss till en mindre del av populationen. Det i sin tur ger ju mindre noggranna svar. Även med begränsat antal användare som intervjuas kan tiden det tar för att analysera svaren man får vara mycket stor. Ökar tiden man arbetar så ökar kostnaderna. Eftersom vårat projekt inte behandlar någon redan definierad produkt så är det svårt att utföra observationer. Man skulle kunna använda sig utav ett redan befintligt system som har ungefär samma användningsområde. - 15 -

Som input får man då ta användargrupperna från föregående steg och genom dom bestämma system som man vill observera användarna i: Interna användare något administrativt system. Externa användare något köp-system med många alternativ 8 KÄLL- OCH LITTERATURFÖRTECKNING. 8.1 Böcker 8.2 Internet Användarcentrerad systemdesign, Jan Gulliksen, Bengt Göransson, Lund, Studentlitteratur, 2002. The Usability engineering lifecycle, Deborah J.Mayhew, Academic Press, 1999. http://drdeb.vineyard.net http://www.it.uu.se/research/hci/acsd/principer.pdf - 16 -