Metod för initial behovsoch kravhantering i agila systemutvecklingsprojekt. LINUS ERICSSON och EMELIE SVARTLING

Storlek: px
Starta visningen från sidan:

Download "Metod för initial behovsoch kravhantering i agila systemutvecklingsprojekt. LINUS ERICSSON och EMELIE SVARTLING"

Transkript

1 Metod för initial behovsoch kravhantering i agila systemutvecklingsprojekt LINUS ERICSSON och EMELIE SVARTLING Examensarbete Stockholm, Sverige 2011

2 Metod för initial behovsoch kravhantering i agila systemutvecklingsprojekt LINUS ERICSSON och EMELIE SVARTLING Examensarbete i människa-datorinteraktion om 30 högskolepoäng vid Programmet för teknisk fysik respektive medieteknik Kungliga Tekniska Högskolan år 2011 Handledare på CSC var Gustav Taxén Examinator var Olle Bälter TRITA-CSC-E 2011:060 ISRN-KTH/CSC/E--11/060--SE ISSN Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC Stockholm URL:

3 Metod för initial behovs- och kravhantering för systemutveckling i agila projekt Sammanfattning Denna studie föreslår en metod för behovs- och kravhantering i början av systemutvecklingsprojekt. Studien har utförts på uppdrag av Försvarets Radioanstalt (FRA) där vi också har utfört arbetet. Vi har även utfört studiebesök på fem företag i stockholmsområdet för att få en översiktlig bild av hur behovs- och kravhantering kan gå till i näringslivet. Initialt utgick vårt arbete från skapandet av en första backlog i scrumutveckling då uppdragsgivaren uppgav sig sakna ett inbyggt stöd för det i utvecklingsmetodiken. Vår undersökning visade att problemet inte bara låg i skapandet av backlogen. Det saknades ett enhetligt sätt att skapa en initial kravbild oavsett vilken utvecklingsmetodik som användes. Vi fann däremot att processer från projektstart till färdigt system var väletablerade i verksamheten. En konsekvens av bristen på process för initial behovs- och kravhantering blir att steget mellan idé och projektstart sker på olika sätt i varje projekt och att projektteamen ibland upplever detta arbete som dubbelarbete. Syftet med vårt arbete blev att ta fram en metod för den initiala behovs- och kravhanteringen som utifrån FRA:s behov ger stöd för detta arbete. Method for Requirements Engineering in Agile Software Development Abstract This study suggests a method for requirements engineering in early phases of software development projects. The study is performed on behalf of the National Defence Radio Establishment (Försvarets Radioanstalt), where the study was also realised. We have also conducted study visits at five companies located in the Stockholm area to get an overview on how requirements engineering is done in industry. Initially our work was based on the issue on creating the initial backlog in the authority!s Scrum based development projects, which our commissioner stated had no methodology for initial backlog creation. It turned out that the problem was more widespread than just creating the backlog. We discovered that there was a lack of methodology in the whole initial requirements engineering process, regardless of development methodology used. On the contrary we found that the process from development to finished system was well established in the organization. The lack of methodology in the initial requirements engineering process results in variation in how the steps between idea and project initialization are carried out. The project members express that this work is often regarded as redundant. Our task was then to develop a methodology to support the initial requirements engineering processes adapted to our commissioner!s needs.

4 Tack Vi vill särskilt tacka vår handledare Fredrik som gett oss många viktiga uppslag och generöst delat med sig av sina erfarenheter. Tack Lennart för att du möjliggjort detta examensarbete och funnits tillhands under resans gång. Tack till övrig personal på Försvarets Radioanstalt (FRA) som med intresse och entusiasm hjälpt oss framåt i vårt arbete. Tack till våra respondenter utanför FRA, som generöst och med stort intresse delat med sig av sin stora erfarenhet inom kravhantering och användbarhet. Utan er hade inte arbetet gått att göra. Ett sista tack vill vi ägna till våra nära och kära som har haft tålamod med oss när vi arbetat med examensarbetet, avskärmade från omvärlden.

5 Innehållsförteckning Bakgrund...1! Bakgrund till studien...1! Problemformulering...1! Syfte och mål...1! Frågeställning...2! Avgränsning...2! Språkbruk...2! Målgrupp...2! Metod...3! Metodteori...3! Induktion och deduktion...3! Grounded Theory...3! Reliabilitet och validitet...3! Datainsamling...4! Intervjuer...4! Observationer...4! Designaktiviteter...4! Prototyper...4! Tillvägagångssätt...5! Val av metodteori och förklaringsmodell...5! Studiens reliabilitet och validitet...5! Val av datainsamling...6! Praktiskt genomförande...7! Beskrivning av vår förförståelse...7! Urval av teori...7! Urval av respondenter...7! Intervjuerna...7! Observationerna...8! Dataanalysen...8! Designprocessen...8! Teoretisk referensram...10! Systemutveckling...10! Projektstyrning...10! Effektstyrning...11! Agil utvecklingsmetodik...12!

6 Scrum...13! Rational Unified Process...13! Krav och kravhantering...14! Användarcentrerad systemutveckling...16! Organisationer och användarcentrerad systemutveckling...16! Empiri...18! Respondenter på företagen...18! Stora Fabriken...18! Systemleverantören...18! Medicinteknikföretaget...19! Kravkonsulten...19! Granskningskonsulten...19! Försvarets Radioanstalt...19! Presentation av respondenter på FRA...20! Organisation...20! Projektstyrning...20! Innan projektstart...21! Krav...22! Utveckling...22! Analys och diskussion...24! Innan projektstart...24! Krav...25! Användbarhet...26! Slutsatser...28! Svar på frågeställningar...28! Hur kan metoden underlätta för FRA gällande initial behovs- och kravhantering?...28! Vad kan en metod för initial behovs- och kravhantering bestå av?...28! Hur ska metoden gestaltas för att motivera till användandet av denna?...28! Slutsatser rörande införande av användarcentrerad systemutveckling på FRA...28! Kravkartan en metod för behovs- och kravhantering...29! Reflektion...31! Fortsatta studier...31! Litteraturlista...32! Bilaga 1: Koncept och dimensioner...35! Bilaga 2: Konceptuell bild för uppgiftsfördelning i utvecklingsprocessen...38! Bilaga 3: Kravkartan...39! Källhänvisningar Kravkartan...40!

7 Bakgrund Bakgrund I detta kapitel presenteras bakgrunden till denna studie. Här presenteras även syftet med studien samt frågeställningarna vi utgått från. Här definieras även målgruppen för rapporten och studiens avgränsning. Bakgrund till studien När ett system utvecklas till kund är det av största vikt att systemet motsvarar beställarens förväntningar och krav men också att beställarens förväntningar är realistiska och att såväl beställare som utvecklare har en klar bild av vilken effekt systemet kommer att ha på verksamheten. Det är därför viktigt att tidigt i projektet undersöka hur systemet ska användas, vad systemet ska användas till och hur detta hjälper organisationen att lösa sina uppgifter. Robertson & Robertson (2007, s. 1) menar att det är först då man har förståelse för de bakomliggande behoven man kan skapa användbara system som utgör nytta för verksamheten. Förståelsen för behoven måste finnas hos beställare såväl som leverantör för att utvecklingsprojektet ska nå framgång. Fenomenet systemutveckling och dess förutsättningar är väl undersökt. En central framgångsfaktor är att ha god förståelse för användarna (Robertson & Robertson 2007, s. 1). Standish Group undersökte ett stort antal amerikanska mjukvaruprojekt vilket resulterade i tre faktorer som uppgavs vara de viktigaste framgångsfaktorerna i systemutvecklingsprojekt. Dessa var användarmedverkan i utvecklingen, stöd från beslutsfattare och ledning samt tydliga krav (Standish group, 1995). Det finns många olika metoder för att utveckla mjukvara. Dessa förutsätter ofta att en mer eller mindre noggrann behovs - och kravinsamling är genomförd när utvecklingen påbörjas. Att identifiera de bakomliggande behoven tidigt i ett systemutvecklingsprojekt är viktigt för att systemet ska kunna utgöra det goda stöd för verksamheten som beställaren förväntar sig vid systemets införande. Denna initiala behovs- och kravhanteringsfas skapar grunden och förutsättningarna för det fortsatta arbetet mot detta mål. Det har visat sig i denna undersökning att såväl beställare som utvecklare behöver stöd i denna relativt komplexa behovs- och kravprocess. Problemformulering På FRA har utvecklingsmetodiken gått från Rational Unified Process (RUP) till delvis agil metodik, främst baserad på metoden Scrum. För det initiala kravarbetet vid agil utveckling saknas fortfarande en dokumenterad metod på myndigheten. Syfte och mål Syftet med denna studie är att undersöka vilka behov FRA har gällande en metod för initialt behovs- och kravhanteringsarbete. Målet är att ta fram en metod för detta vilken är anpassad till FRA:s arbetssätt och organisation. 1

8 Bakgrund Frågeställning Vår huvudsakliga frågeställning är: Hur kan en metod för initial behovs- och kravhantering som motsvarar FRA:s behov i agil utveckling se ut? Denna frågeställning kan delas upp i följande delar: Hur kan en metod underlätta för FRA gällande behovs- och kravhantering? Vad kan en metod för initial behovs- och kravhantering bestå av? Hur ska metoden gestaltas för att motivera till användandet av denna? Avgränsning Vårt fokus ligger främst i de första faserna av systemutvecklingsprocessen där de första linjerna för projektet ritas upp. Detta initiala arbete påverkar i hög grad resten av projektet. Vi anser därför att det är viktigt att tidigt ha rätt fokus i arbetet. Denna rapport berör följaktligen även hur man säkerställer användbarhet i de första faserna i projektet. Detta kräver också att organisationen är mogen för ett användarcentrerat arbetssätt, varför vi berör även detta i rapporten. Metoden som har tagits fram i samband med denna studie är tänkt att stödja arbetet med att gå från idé till ett principiellt lösningsförslag i agila utvecklingsprojekt. Denna studie berör inte hur prioriteringen mellan olika projekt ska gå till men metoden ska stödja i arbetet med att skapa ett underlag för att fatta välgrundade beslut där prioritering mellan projekt ingår. Denna studie fokuserar inte på metoder för teknikfokuserad kravinsamling. Vi har istället valt att fokusera på användbarhetsaspekter i behovs- och kravhanteringsarbetet eftersom vi fann det behovet mer angeläget. Metoden täcker dock in alla typer av krav och ger förutsättningar för att öka kunskaperna även inom andra områden. Språkbruk I de fall där vi översätter engelska ord till svenska har vi valt att sätta det engelska ordet inom parentes. När vi inte stött på någon svensk motsvarighet till ordet har det engelska använts. Målgrupp Rapporten riktar sig i första hand till FRA som en del av vårt arbete på myndigheten. Den är dock skriven för att alla som intresserar sig för krav och användbarhet i agil utveckling ska kunna dra nytta av den. Vi förutsätter att läsaren har en översiktlig kunskap om systemutveckling och vanliga modeller för hur denna kan gå till. 2

9 Metod Metod I det här kapitlet tar vi upp något om vetenskaplig metodik, vetenskapliga förklaringsmodeller samt begreppen validitet och reliabilitet. Begreppet Grounded Theory introduceras. Vidare ges även en översiktlig bild av datainsamlingsmetoder vilka använts i studien, vårt tillvägagångssätt samt det praktiska genomförandet. Metodteori Det finns huvudsakligen två typer av undersökningar, kvalitativa och kvantitativa. De kvantitativa metoderna syftar till att koda observationer till siffervärden som kan användas som underlag för att dra slutsatser. Dessa har fördelen att det går att relativt enkelt göra fler mätningar för att stärka en hypotes. Kvalitativa data låter sig svårligen kodas som värden på ett fruktbart sätt och är mer tidskrävande att sammanställa. Denna typ av data kräver en mer sammansatt förklaringsmodell (Preece, Rogers & Sharp 2007, s. 356). Induktion och deduktion Induktion är att härleda slutsatser från empiriska erfarenheter. Enligt principen om Occams rakkniv, som säger att en enkel teori är mer sannolik än en mer komplicerad, kan man reducera teorierna till de mest sannolika. (Hansson 2003, s. 53). Deduktion innebär att ställa upp en hypotes utifrån ett antal antaganden (axiom eller tidigare hypoteser). Dessa hypoteser behöver inte nödvändigtvis leda till en utsaga som är med verkligheten överensstämmande, men måste kunna verifieras eller falsifieras för att kunna sägas vara sann. (Hansson 2003, s ). Grounded Theory Grounded Theory är främst en induktiv metod för att koda kvalitativa data där man inducerar teori ur en datamängd genom att identifiera olika koncept och relationerna mellan dessa (dimensioner). Grounded Theory förutsätts fortsätta till dess att ny data inte längre tillför nya begrepp och relationer i modellen, utan bara bekräftar tidigare kunskap. (Bell 2006, s ). Reliabilitet och validitet Under en forskningsprocess är det viktigt att kritiskt granska den insamlade informationens giltighet och tillförlitlighet. Ett instrument eller ett tillvägagångssätt för att samla in information kan ge olika resultat vid olika tillfällen trots att omständigheterna är desamma, vilka kan bero på slumpmässiga mätfel i studien. För att uppnå god reliabilitet ska studien innehålla så få mätfel som möjligt och inte påverkas av omständigheterna runt omkring eller av vem mätningen utförs. I exempelvis en intervjusituation kan svaren bero på en rad olika orsaker så som intervjupersonens humör, tidigare händelser, vart intervjun äger rum eller av vem respondenten blir intervjuad (Bell 2006, s. 117). Validitet handlar om informationens giltighet, alltså om det empiriska materialet mäter det forskaren tänkt att det ska mäta. Det betyder alltså att forskningsansatsen ska ge data som med säkerhet kan sägas spegla det förhållande som ska mätas (Bell 2006, s. 118). 3

10 Metod Datainsamling I detta avsnitt ges en översiktlig bild av metoder för att samla in data vilka vi använt under studien. Intervjuer Intervjuer kan utföras mer eller mindre strukturerat där den mest strukturerade formen kan liknas vid en enkät med ett antal förutbestämda svarsalternativ. Den mest ostrukturerade intervjun utgår från ett antal förberedda frågor men bygger på att föra ett samtal kring ett visst tema (Bell 2006, s. 160). Observationer Observationer kan ge data som annars vore omöjliga att ta fram och kan därför fungera som ett bra komplement till intervjuer. Forskaren måste vara medveten om att observatörens egen uppfattning påverkar tolkningen. Observationer sker antingen ostrukturerat eller strukturerande och deltagande eller icke-deltagande (Bell 2006, s ). Ostrukturerade observationer är lämpliga när forskaren är klar över syftet med observationerna, och kan användas för att generera hypoteser exempelvis i Grounded Theory. Den deltagande observationen innebär att forskarna deltar i en social kontext och försöker förstå vad som händer genom att tolka sina intryck och genom att ställa frågor till gruppen. (Bell 2006, s ). Designaktiviteter För att skapa och utvärdera ett designförslag finns det en rad olika metoder. Dessa metoder har till syfte att på olika sätt stödja en process, och ofta att få människor att tänka i nya banor (Häggberg 2002, s. 2-3). Prototyper En prototyp är en representation av en tänkt design vilken kan användas som underlag för en första användbarhetsutvärdering. Det kan också vara ett användbart redskap för att diskutera och testa idéer med användare och projektmedlemmar. Genom att bygga en prototyp tvingas designern reflektera över sina idéer och hur produkten ska realiseras. (Preece, Rogers & Sharp 2007, s 11). Inom interaktionsdesign talar man om två typer av prototyper: Low-fidelity (Lo-Fi) och Highfidelity (Hi-Fi). Lo-Fi-prototyper är mycket enkla, billiga och ska gå snabbt att skapa. De kan vara gjorda av pappkartong eller skissade på papper och används i ett tidigt skede i utvecklingsprocessen. Hi-Fi prototyper är mycket välgjorda och ska ge en trovärdig representation av produktens utformning (Preece, Rogers & Sharp 2007, s. 531). Prototyper kan utvärderas på en rad olika sätt och olika syften. Användbarhetsdesignern kan låta användare prova lösningarna genom att utföra en viss uppgift i en workshop eller att föra in dem i verksamheten och observera hur de tas emot (Preece, Rogers & Sharp 2007, s ). 4

11 Metod Tillvägagångssätt I detta avsnitt redogör vi för hur vi valt att gå tillväga i vårt datainsamlande och analysen av datat. Vi diskuterar även kring studiens reliabilitet och validitet. Val av metodteori och förklaringsmodell Vi har tillämpat Grounded Theory för att bygga upp en förståelse för nuvarande arbetssätt inom organisationen och försöka identifiera styrkor, förbättringsområden och behov. I analysen av våra data har detta delats i koncept (återkommande begrepp) som i sin tur har grupperats i dimensioner. En förteckning av dessa koncept hittas i Bilaga 1, och en övergripande konceptuell bild presenteras i Bilaga 2. För att öka förståelsen för det agila arbetssättet har vi valt att lägga upp det praktiska arbetet utifrån utvecklingsmetoden Scrum. Metoden som helhet presenteras närmare i teoriavsnittet. Viktiga aspekter vid valet av Scrum är att metoden används i organisationen och att den har tydliga inslag av kontinuerlig feedback, vilket gynnar såväl designprocess som studiens reliabilitet. Dessutom ville vi att vårt resultat skulle vara kompatibelt med det agila arbetssättet. Scrum har i vårt arbete fungerat som vår projektmetod, för att stödja vårt praktiska arbete. Vi har anpassat Scrum efter vårt arbete och vårt arbetssätt skulle kunna kallas Scruminspirerat. Vi har dragit nytta av vissa aspekter som time-boxing, stories och scrumtavla. Arbetet har utgått från en backlog med uppgifter, vilka vi prioriterade själva. Vi har även haft sprintredovisningar på myndigheten, vilka utnyttjades för feedback på det arbete vi gjort under sprinten. Vi har inte haft någon uttalad Scrummaster eller produktägare, men vår handledare tog rollen som beställare. Scrum visade sig passa bäst för datainsamlingsarbetet. Under rapportskrivandet beslöt vi oss för att inte ägna oss åt Scrum lika uttalat men använde timeboxing och prioritering av uppgifter, även om detta till stor del bara skedde verbalt. För att skapa vår metod för initial behovs- och kravhantering valde vi att arbeta kreativt enligt en strukturerad designprocess. Eftersom vår förståelse för behovet av en sådan metod successivt ökade ville vi utforska flera olika lösningar under arbetets gång. Dessa utvärderades för att få nödvändig feedback på lösningsförslagen. På grund av begränsat dataunderlag används en induktiv metod och vårt data behandlades som kvalitativt. För att bygga en förklaringsmodell har vi använt Grounded Theory, för att skapa en nulägesbeskrivning där behov och problemområden inom behovs- och kravhanteringsarbetet kan identifieras. Dessa kan adresseras med en strukturerad designprocess. Analysen har skett främst utifrån ett användarcentrerat perspektiv, då vi anser att detta är en förutsättning för ett framgångsrikt systemutvecklingsarbete. Valet av Grounded Theory grundar sig i att vi ville skapa oss en egen uppfattning om FRA:s möjliga problemområden eller behov. Vi kunde därför inte på förhand ställa upp en hypotes om hur nuläget såg ut. Vi ville inte begränsa oss till någon enskild förklaringsmodell utan ville själva skapa oss en bild av nuläget. Vi bedömde att en kvantitativ metod skulle vara av begränsat värde för designprocessen då tillgång till kvantifierbar data var begränsad. Det hade varit svårt att kvantifiera de data vi samlade in för att få de resultat vi förväntade oss för skapandet av vår metod. Antalet respondenter var också för få för att en kvantitativ metod skulle ge tillförlitliga svar. Studiens reliabilitet och validitet För att stärka reliabiliteten har många intervjuer utförts (tjugo stycken). Frågorna var utformade på samma sätt för att utgångspunkten i intervjuerna ska vara densamma. Där intervjupersonen svarat otydligt eller svävande har frågorna omformulerats i samtalen för att få ett mer ingående svar. 5

12 Metod Rummet där intervjuerna på FRA skett har varit detsamma utom i två fall där vi fick anpassa oss till intervjupersonerna. Alla intervjuer, även de på företagen, skedde i någon form av mötesrum, aldrig på respondentens eget kontor. Alla har intervjuats enskilt och har därför inte kunnat påverka varandra under intervjutillfällena. Under intervjuerna har bakgrund och utbildning efterfrågats och hänsyn till detta har också tagits vid analysen av vårt data. Då intervjuerna varit ostrukturerade har det funnit möjligheter att validera påstående från tidigare intervjuer tillsammans med intervjupersonen. Dessa har sedan kunnat provas ytterligare med efterkommande intervjupersoner vilket stärker reliabiliteten i våra resultat. Vi har som examensarbetare och utomstående haft möjlighet att ställa naiva frågor vilket har varit till hjälp vid definition av olika begrepp och sakförhållanden. På grund av den sekretess som råder på myndigheten har det funnits vissa svårigheter i att finna representativa personer som kunnat ge den information som eftersökts. Detta gör det svårt att veta huruvida de personer som intervjuats har gett en representativ bild av hur det ser ut på berörda delar av myndigheten. Intervjuerna har därför kompletterats med dagliga observationer och studier av bland annat skriftlig projektdokumentation. De data som samlats in har i vissa fall kontrollerats med vår handledare eller chef för att verifiera eller falsifiera vissa påståenden. I andra fall har påståenden kontrollerats under lunch- och fikarumsdiskussioner på i stort sett daglig basis. Vi har haft ett visst bortfall bland våra respondenter. Detta kan bero på att de som inte hade tid att ställa upp hade mycket att göra. Detta kan betyda att de har haft stort ansvar och därmed god insikt i organisationen och dess arbetssätt. För att kompensera bortfallet av data från dessa intervjuer har vi kompenserat detta genom att intervjua desto fler personer i deras närhet. Vi anser därför inte att bortfallet påverkat resultatens reliabilitet nämnvärt. Det finns en risk att vårt insamlade data inte ger en fullständig bild av myndighetens arbetssätt. Empirin är dock inte det enda som ligger till grund för våra slutsatser, dessa grundas även i litteratur och jämförelser med de företag vi besökt. Vi gör bedömningen att det empiriska underlaget är mer än tillräckligt för att använda vid syntes av vår metod. Studien uppnår hög validitet genom att vi har tillbringat fyra månader på myndigheten, vilket kan ses som relativt lång tid, och aktivt följt upp våra resultat under arbetets gång. Våra observationer och slutsatser har dock löpandet kontrollerats med andra på myndigheten. De fenomen vi observerat återkommer och beskrivs i litteraturen och vi har även stött på dem under våra studiebesök. Val av datainsamling Vi valde tidigt att genomföra enskilda intervjuer skilt från respondentens arbetssituation då vi ansåg att respondenterna skulle känna sig obekväma i att prata fritt i sin vardagliga miljö. Det var framför allt viktigt att respondenterna själva hade kontroll över hur mycket information de delgav oss, vilket vi bedömde skulle vara lättast i en neutral situation utanför arbetsplatsen utan några kollegor närvarande. Detta gällde både myndighetspersonalen och respondenterna på företagen. Vi valde ostrukturerade intervjuer för att kunna föra ett fritt samtal kring nuläget för att försöka ringa in problemområden och tillsammans fundera på vilka metoder personerna använde idag. Vi ville även diskutera kring roller och hur dessa förhöll sig till varandra, vilket skulle ställa högre krav på frågorna i en strukturerad intervju. Observationer utfördes på ett deltagande och ostrukturerat sätt genom att vi deltog i fikaraster, lunchdiskussioner och gemensamma aktiviteter på avdelningen. Vi har i stort sett dagligen befunnit oss på myndigheten vilket har gjort att vi på ett avslappnat sätt har kunnat prata med medarbetarna. Vi har också satt upp många lappar där vi bett om hjälp med olika saker och även bloggat internt, för att alla på avdelningen ska ha haft möjlighet att lära känna oss. Mycket fokus har lagts på att skapa ett förtroende mellan oss och medarbetarna på avdelningen. 6

13 Metod För att utvärdera de prototyper vi producerat hölls sprintdemos och en workshop. Prototyper delades också ut till olika personer i utvecklingsverksamheten som fick utvärdera och prova dem. Tyvärr fanns det inte möjlighet att testa prototyper i ett skarpt projekt, varför vi var tvungna att simulera en projektstart under den workshop som genomfördes. Praktiskt genomförande I detta avsnitt beskrivs genomförandet av studien, hur vi valt ut relevant teori och respondenter. Här ges även en beskrivning av vår förförståelse. Beskrivning av vår förförståelse Vi har studerat inriktningen Människa-datorinteraktion vid Kungliga Tekniska Högskolan i Stockholm. Vi har inte läst några kurser i kravhantering, men har viss erfarenhet av systemutveckling. Linus Ericsson har tidigare arbetat med viss kravställning av system. Eftersom vi båda har ett intresse för användarcentrerad systemutveckling har detta synsätt präglat studien. Urval av teori Vi har valt att fördjupa oss i den teori som kan förväntas ligga till grund för centrala begrepp i slutsatserna eller metoden. Vi har också fördjupat oss i teori för fenomen vi stött i vår data. I teorin har vi valt att titta närmare på hur organisationer ser på användbarhet och hur ett användarcentrerat synsätt kan införas i en organisation. Vi har haft stort nytta av den litteratursökning vi gjort, men vi har valt att sålla bland de många utvecklingsmetoder vi bara sett förekomma i litteraturen då det är av begränsat värde för rapporten. Vi har redogjort för de utvecklingsmetoder vi stött på i empirin. Vi har noterat att det inte alls finns lika mycket skrivet om kravinsamlingsmetoder som olika metoder för den mer konkreta systemutvecklingen. Urval av respondenter På FRA intervjuades totalt 20 personer och vi genomförde sex intervjuer på totalt fem företag. Vi har försökt få representation både från beställare och leverantör av systemen. Därför har vi inom myndigheten valt att titta på ett begränsat urval av systemen och intervjuat så många olika roller och intressenter som möjligt i vart och ett av systemutvecklingsprojekten. Respondenterna var i första hand utvecklare, projektledare, användarrepresentanter och beställare. Dessa valdes i samråd med vår handledare för examensarbetet och verksamhetschefer. Respondenterna på företagen hittades genom personliga kontakter som kunde tipsa oss vidare. Vi strävade efter att välja företag som antingen i något avseende liknade FRA eller sannolikt hade god kompetens inom kravställning och användbarhet. Då vi tittade på kravprocessen ur ett övergripande perspektiv var företagens verksamhetsområde av underordnad betydelse för studien. Samtliga företag levererade mjukvara i någon form med höga krav på kvalitet. Intervjuerna Som tidigare nämnts valde vi ostrukturerade intervjuer för att skapa en fri dialog och ett öppenhjärtligt samtal om ämnet. Vi var noga med att uppge vår säkerhetsklassning innan intervjun började för att intervjupersonen inte skulle behöva tveka om vad man kunde prata om och inte. Då vi var två som intervjuade ställde en person de flesta frågorna och den andra antecknade. Intervjuerna bokades in via kortfattad mailkorrespondens med respondenten. Personerna fick frågorna på förhand, för att kunna förbereda sig och ta med eventuellt relevant material. Inga 7

14 Metod bild- eller ljudupptagningar gjordes. Alla intervjuer med myndighetspersonal genomfördes i samma rum utom två, som på grund av respondenterna fick äga rum på annan plats, dock fortfarande i mötesrum. Fyra av intervjuerna med respondenterna på företagen skedde på respektive företag, en hölls på ett café i närheten av arbetsplatsen och en intervju utfördes som telefonintervju. Observationerna Vi förde kontinuerligt dagbok i slutet på varje arbetsdag för att samfatta de observationer som gjorts under dagen. Vi deltog även på en förstudiepresentation, ett dagligt Scrummöte och andra interna föreläsningar. Vi satt nära utvecklare som vi hade nästan daglig kontakt med. Dataanalysen Dataanalysen genomfördes manuellt. Anteckningarna renskrevs i ordbehandlare och varje mening skrevs som nytt stycke. De renskrivna anteckningarna skrevs ut i storlek 18, färgmärktes beroende på intervjuperson och klipptes isär. Det resulterade i hundratals lappar, vilka vi sorterade in i ca 90 koncept. Dessa tejpades återigen upp på papper och koncepten var tydligt antecknade och sattes in i en pärm. En innehållsförteckning gjordes. En genomgång av koncepten gjordes och ett fåtal centrala dimensioner identifierades. På en vägg i arbetsrummet fästes fjorton blädderblockspapper i storlek A3, på vilka vi skrev ner de centrala dimensionerna i lämplig disposition, omgivna av de relaterade koncepten. Data tillhörande de olika koncepten dikterades av en av oss medan den andra antecknade datat i form av en tankekarta, där linjer kunde dras till relaterade begrepp i varje utsaga. Vissa utsagor insåg vi här inte var meningsfulla att försöka få med i förklaringsmodellen. Det framgick snart vilka begrepp och koncept och relationer mellan koncepten som var vanligast, det var helt enkelt bara att räkna antalet streck. En genomgång av data också sorterat på koncept, listor på roller, aktivteter och centrala begrepp,som exempelvis förstudie, markerades och skrevs ut som stöd för visualiseringen och klistrades upp på tankekartan. Inte alla begrepp kom med, läsningen och försöken att förklara datat med hjälp av en tankekarta sållade alltså bort perifera begrepp (vilka vi troligtvis inte haft tillräcklig grund för). Vi turades sedan om att läsa tankekartan och skriva ned de slutsatser vi kunde dra utifrån kartan, exempelvis kommer meningen En allmän uppfattning hos utvecklarna att Scrum är bra på att fånga feedback från beställarsidan vilket man får under sina sprintdemos sig av att flera intervjupersoner nämnt Scrum och feedback från beställarsidan och att begreppet sprintdemos varit näraliggande feedback från beställarsidan. Givetvis kunde vi av de erfarenheter vi dragit ut under intervjuerna veta att det inte var någon som hade sagt något direkt negativt om feedback från beställarsidan och Scrum, vilket förstås skulle ha gjort att vi förkastat den förklaringen. Diskussionen om slutsatsernas rimlighet diskuterades löpande under såväl diktering som bearbetning av de nedskrivna resultaten. Värt att notera är att vi inte kunde uppnå teoretisk mättnad i analysen av intervjuerna från de olika företagen. Dessa data särredovisades därför, även om vi redogör för vissa gemensamma dimensioner och ibland relaterar det till data från FRA. Vi har främst utgått från intervjumaterialet i analysen. Processbeskrivningar och andra dokument har inte genomgått samma analys som ovan, men jämfördes med förklaringsmodellen. Ur denna jämförelse framkom flera behov. Designprocessen Vi samlade redan tidigt på oss olika lösningsförslag, dels sådana vi själva kommit på, dels idéer från intervjurespondenter och andra anställda. Dessa nedtecknades och vi diskuterade dem med varandra såväl som med handledare och andra på FRA. Vi utvärderade idéerna genom att på ett 8

15 Metod strukturerat sätt hitta styrkor och svagheter, bland annat med krysschema (Häggberg 2002 s 16). Ur lösningsförslagen kunde vi även ofta identifiera behov. Våra förslag gestaltades även med hjälp av prototyper av Lo-Fi-karaktär. Utvärderingar skedde genom att vi kontinuerligt visade upp våra artefakter för besökare på vårt rum och andra vi tyckte borde se dem. Vi gav även bort prototyper till utvecklare att titta på och reflektera kring. Under vår workshop fick en grupp projektledare ett enkelt case rörande initial kravinsamling. Syftet med workshopen var att testa metoden för initial kravinsamling i användning. 9

16 Teoretisk referensram Teoretisk referensram Här behandlar vi den teori som ligger till grund för vår undersökning. Vi tar upp systemutvecklingsmetodiker, projektstyrning och kravhantering. Vi tar även upp användarcentrerad systemutveckling och hur detta arbetssätt kan föras in i organisationer. Systemutveckling Hökenhammar (2001, s. 273) definierar systemutveckling som en process för att skapa ett system vilken sträcker sig från ide till färdig produkt. Tonnquist delar upp systemutvecklingsprocessen i en förstudiefas, planeringsfas, design- och konstruktionsfas och en avslutande fas (Tonnquist 2008, s. 192). Ett vanligt sätt att inleda systemutvecklingsprojekt är att inleda arbetet med någon form av kravprocess, där användare tillfrågas efter vilken funktionalitet som önskas eller att de på annat sätt formulerar behoven det producerade systemet ska uppfylla (Davis, Yourdon & Zweig 2000 s. 2-3). Tonnquist (2008, s. 192) förespråkar att kraven samlas in under förstudiefasen. Det finns en rad olika metoder för systemutveckling vilka har som primärt syfte att föreskriva ordningen av de olika stadierna som ingår i processen. (Gulliksen & Göransson, 2002 s. 137). Den, enligt Gulliksen & Göransson (2002, s 139), vanligaste modellen för systemutveckling är Vattenfallsmodellen, som kom till 1970, och innebär att faserna behandlas sekventiellt. Innan en fas i systemutvecklingsprocessen påbörjas måste den tidigare ha avslutats. Kritik har dock framförts mot denna metod då arbetet lätt kan fastna i en återvändsgränd om projektgruppen tänkt fel i något av de tidigare stegen. Eftersom problemställningen systemet ska lösa ofta ändras eller kompletteras under projektets gång, har det utvecklats iterativa metoder för att bedriva systemutveckling. I de iterativa metoderna accepterar man att den initiala kravbilden förändras under projektet och löser detta genom att gör om och kompletterar dellösningar i produkten (Gulliksen & Göransson 2002, s 145). Projektstyrning För att göra projektarbete förutsägbart och minimera riskerna för den investering ett projekt innebär har man utvecklat projektstyrningsmetoder. En projektstyrningsmetod består huvudsakligen av processer, roller och olika mallar och dokument. I ett projekt strävar man efter en styrmodell som ger tillräckligt med kontroll, men inte verkar begränsande (Tonnquist 2008, s. 332). Projektstyrningen verkar övergripande i ett utvecklingsprojekt och definierar projektets ramar. På en mer detaljerad och resultatinriktad nivå verkar någon utvecklingsmetodik (Tonnquist 2008, s. 337). Ett exempel på en utvecklingsmetodik är Scrum vilken beskrivs närmare nedan. För att finansiärer ska kunna styra projektet på en övergripande nivå har projektstyrningsmodellerna ett antal beslutspunkter. Detta är beslut som tas vid kritiska faser av projektet och som syftar till att projektets styrgrupp ska kunna ta beslut om projektet ska fortsätta eller inte (Tonnquist 2008, s. 13). Tonnquist (2008, s. 334) nämner metoden PROPS, utvecklad av telekombolaget Ericsson under namnet Projektet för Projektstyrning, som en vanlig projektstyrningsmetod för organisationer med flera parallella projekt. Standardversionen av PROPS föreskriver sex beslutspunkter. Exempel på tidiga beslutspunkter är beslut att inleda projektet, att inleda projektplanering samt att etablera och genomföra projektet. 10

17 Teoretisk referensram Kvalitet i projekt kan upprätthållas med så kallade kvalitetsgrindar. Dessa kan finnas i projektstyrningsmodellen. Utifrån dessa ska den yttersta ledningen bedöma projektet utifrån den föregående fasen, och avgöra om projektet lever upp till förväntad kvalitet och ta beslut om projektet bör fortsätta (Hallberg 2009, s. 69). Dessa kan jämföras med projektets beslutspunkter. Hallberg (2009, s. 14) menar att ett potentiellt problem med kvalitetsgrindar är att de släpper igenom projekt som inte håller tillräckligt hög kvalitet. Vidare menar Hallberg (2009, s. 69) att detta ofta beror på att kriterierna för besluten är oklara för dem vars arbete ska bedömas. Effektstyrning Ottersten & Balic (2010, s ) anför dagens projektstyrningsmetoder som en anledning till att projekt inte strävar mot att uppnå de önskade effekterna med produkten i användning utan att projektgruppen istället strävar mot att producera kod, klara leveranser och att hålla budget. Vidare menar de att för att styra projektet mot förväntade effekter behövs ett strukturerat arbetssätt som bygger på att projektets styrgrupp har som huvudfokus att se till att projektets förväntade effekter infrias, snarare än att hålla tid och budget. Detta strukturerade arbetssätt kan införas i den befintliga projektstyrningsmetoden och kompletteras med beslutspunkter, så kallade effektbeslut, som syftar till uppfyllandet av effektmålen. Ottersten & Balic (2010, s ) förespråkar därför effektstyrning som en lämplig process för att styra projekt mot förväntade effekter. Effektstyrningsprocessen är uppdelad i tre faser som i sin tur innehåller totalt tio effektbeslut. Figur 1 visar hur de tio effektbesluten är sammankopplade med de tre faserna i processen. I första fasen ägnar projektgruppen sig åt insamling av idéer och behov och vill fastställa beställarens förväntningar på den nytta som IT-systemet ska skapa i verksamheten. Denna kartläggning av nyttan kan sedan användas i upphandling. Andra fasen syftar till att styra produktens utformning så att de förväntade effekterna uppnås och den tredje handlar om att testa den färdiga produkten i användning för att värdera och godkänna den (Ottersten & Balic 2010, s. 71). Figur 2 beskriver de fyra första effektbesluten vilka kan sägas höra till förstudiefasen i traditionell systemutveckling. Fastställa förväntningar på nytta Styra produktens utformning Värdera och godkänna produkten 1 Förbättringsområde definierat 2 Produktidén godkänd 3 Krav på kvalitet och införande 4 Principlösning godkänd 5 Detaljdesign godkänd 6 Produktutformning godkänd 7 Användningskvalitet godkänd 8 Teknisk kvalitet godkänd 9 Produkten godkänd 10 Införande godkänt Upprepas, avser delar av produkten Figur 1. De tio effektbesluten och hur dessa förhåller sig till de tre faserna i processen (Ottersten & Balic 2010, s. 72). 11

18 Teoretisk referensram 1. Förbättringsområde definierat Här har någon i ledningsgruppen bedömt att IT kan användas som medel för att tillfredsställa ett behov i verksamheten. Här har en kostnadsbedömning gjorts och det finns en grov beskrivning av vilken nytta IT-satsningen kommer att utgöra för målgruppen. 2. Produktidén godkänd I detta steg är man övertygad om att IT är en lönsam satsning för verksamheten för att uppnå en önskvärd förändring. Här har man större kunskap om målgruppen och vilken nytta som förväntas uppstå vid systemets införande. 3. Krav på kvalitet och införande Här har man en beskrivning av de kvalitetskrav som finns på produkten, teknisk kvalitet såväl som användningskvalitet. Man bör därför undersöka alternativa produktutformningar och välja en lösning. 4. Principlösning godkänd Detta beslut handlar om vad den slutliga produkten ska innehålla. I detta steg ska därför en grov interaktionsdesign där de viktigaste flödena finnas beskrivna. Samtliga funktionella krav också finnas beskrivna. Övriga effektbeslut innebär att godkänna detaljdesign, produktutformning, användningskvalitet, teknisk kvalitet, produkten, införande. Figur 2. De fyra första effektbesluten (Ottersten & Balic 2010, s ) Agil utvecklingsmetodik Grundtanken bakom agil utveckling är att utvecklarna snabbt ska kunna bygga ett utkast till ett system som sedan kan testas. Arbetet sker i korta cykler, så kallade iterationer, och bryter ned utvecklandet av en produkt i mindre delar vilka färdigställs en i taget. Detta gör att utvecklingen enkelt kan ställas om vid förändrade behov (Agile Sweden, 2004). Det huvudsakliga syftet med agil utvecklingsmetodik är att göra kunden nöjd genom att kontinuerligt leverera fungerande mjukvara under hela processen. Detta gör att kraven hela tiden kan ändras då projektgruppen ofta utvärderar leveranserna tillsammans med kunden. Detta ställer krav på kundens engagemang då man kan ha kontakt så ofta som på daglig basis (Agile Manifesto, 2001). Den agila utvecklingsmetodiken sammanfattas i det Agila manifestet som lyder: Vi finner bättre sätt att utveckla programvara genom att utveckla själva och hjälpa andra att utveckla. Genom detta arbete har vi kommit att värdesätta: Individer och interaktioner framför processer och verktyg. Fungerande programvara framför omfattande dokumentation. Kundsamarbete framför kontraktsförhandling. Anpassning till förändring framför att följa en plan. (Agile Manifesto, 2001). 12

19 Teoretisk referensram Scrum Scrum är en agil projektmetodik för mjukvaruutveckling som bygger på att projektarbetet delas upp i iterationer, så kallade sprintar. Varje sprint är en till fyra veckor lång och föregås av ett sprintplaneringsmöte. Projektteamet består av fem till nio personer. Inom teamet är professioner oviktiga och alla i teamet arbetar med det som bäst bidrar till att uppnå de uppsatta målen för sprinten (Mountain Goat Software, 2011). Scrummastern är teamets coach och har till uppgift att se till att teamet ständigt presterar sitt bästa för att uppnå de uppsatta målen. Produktägaren (Product Owner) har till uppgift att se till att teamet arbetar i rätt riktning. Produktägaren tar även emot, hanterar och prioriterar önskemål om tillägg och ändringar rörande produkten (Mountain Goat Software, 2011). Varje dag har teamet ett femton minuter långt möte, så kallat dagligt scrummöte (daily scrum), där projektgruppen, produktägaren och scrummastern deltar (Mountain Goat Software, 2011). Varje deltagare ska svara på tre frågor: Vad gjorde du igår? Vad ska du göra idag? Vilka eventuella hinder finns? Genom att svara på dessa frågor kan projektgruppen tillsammans förstå problem och hjälpa varandra. (Nodder & Nielsen 2008, s. 13) Scrum representerar funktionella krav i form av stories. Dessa beräknas ofta ta högst ett par dagar att implementera och har ofta formen av papperslappar som sätts upp på så kallade scrumtavlor så att alla i projektteamet kan se hur arbetet fortlöper. Alla stories prioriteras och i normalfallet arbetar teamet på den story som har högst prioritet. Alla stories samlas i en product backlog vilken projektarbetet utgår från (Kniberg, 2007, s ). Produktägaren, som har ansvar för backlogen, prioriterar mellan stories för att teamet hela tiden ska arbeta med de viktigaste uppgifterna. Inför varje sprint skapar produktägaren sprint backlog vilken innehåller de stories som är högst prioriterade. Dessa ska ha implementeras för att målet med sprinten ska vara uppnått (Kniberg, 2007, s ). För att veta när en story är färdigställd, behöver projektgruppen ha en definition of done, vilken är en överenskommelse mellan produktägare och teamet om när en story anses vara slutförd (Kniberg, 2007, s. 27). Varje sprint tidsbegränsas (time boxing) till iterationer som inte pågår längre än en månad. Under sprintarna är kraven frysta (Mountain Goat Software, 2011). En vanlig metod är att under en sprint samla in alla krav som är nödvändiga för nästkommande sprint och ordningsställa dem inför sprintplaneringsmötet. Syftet är att ha kraven tillgängliga precis då de behövs, men inte förr. Eventuella brister som upptäcks kan rättas till längre fram (Kniberg, 2007, s ). I slutet av varje sprint demonstrerar teamet den funktionalitet som implementerats för att få feedback från produktägaren och de intressenter som bjudits in till demonstrationen. Ytterligare ett möte hålls där teamet, scrummastern och produktägaren utvärderar föregående sprint för att hitta möjligheter till förbättringar under nästkommande sprint. Alla tillkomna eller förändrade krav som uppkommit under dessa två möten läggs i product backlog. Eftersom kraven i product backlog hela tiden kan ändras och nya krav kan tillkomma blir den aldrig färdigställd (Mountain Goat Software, 2011). Rational Unified Process Rational Unified Process (RUP) är utvecklad av företaget Rational, vilket köptes upp av IBM 2002 (eweek, 2002). RUP är enligt Gulliksen & Göransson (2002, s.187) den mest etablerade och vedertagna systemutvecklingsprocessen och har sitt ursprung i utvecklingsmetoden Objective som kom redan på 1980-talet. Rational Software (2008, s. 2) menar att en av de 13

20 Teoretisk referensram centrala förtjänsterna med RUP är metoden är iterativ och utvecklar systemet i små delar. Gulliksen & Göransson (2002, s ) menar dock att den i RUP föreskrivna metoden att dela upp uppgifterna kan ses som inkrementell, vilket skulle göra att den fortfarande särskiljer sig från de agila metoderna och användarcentrerad systemutveckling. RUP delar in utvecklingen i fyra faser: inception, elaboration, construction och transition, alla med syfte att alltmer begränsa och förfina omfattningen av det system som ska byggas (Rational Software, 2008, s. 3). De inledande faserna fokuserar mycket på systemets arkitektur, och projektgruppen uppmanas i elaborationfasen att göra en prototyp på hög nivå för att tillse att arkitekturen är tillräcklig för det system man ska utveckla (Rational Software, 2008, s. 6). Inom alla utvecklingsfaser finns en stor mängd olika aktiviteter och tanken är att projektgruppen väljer ut aktiviteter specifikt för varje projekt. Företag föreslås ofta ta hjälp av RUP-konsulter för att få hjälp att välja vilka aktiviteter som passar företagets projekt väl (Rational Software, 2008, s. 3). RUP kan därmed sägas vara ett projektramverk eller en process snarare än en specifik metod (Rational Software, 2008, s. 1). En av RUPs uttalade målsättningar är att överbrygga gapet mellan verksamhetsarkitekter och utvecklare, genom att använda symbolspråket UML som ett gemensamt språk. UML är ett antal överenskomna standarder för att beskriva hur mjukvara är uppbyggd (Rational Software, 2008, s. 1). Det finns diagram för användningsfall, hur datastrukturer ser ut och hur programmet modellerar objekt. Användningsfall är en enkel metod att beskriva vilken funktionalitet ett system ska ha, genom att ge bra exempel på sätt systemet ska användas och de förväntade resultaten av detta (Strand, 2001, s. 17). RUP definierar roller på ett tydligt sätt, där varje roll tar ansvar för någon del av utvecklingsprocessen. Exempel på roller är testledare, arkitekt, prestandatestare, projektledare. En person kan ha flera olika roller. Rollernas belastning förändras över tid i projektet, och det finns diagram som schematiskt visar hur mycket rollerna förväntas arbeta under olika delar av projektet (Rational Software, 2008, s. 3). Krav och kravhantering Davis, Yourdon & Zweig (2000, s. 2) beskriver krav som externt observerbara egenskaper, funktioner eller attribut vilka användare, beställare och andra intressenter vill att systemet ska bestå av eller karaktäriseras av. Robertson & Robertson (2007, s. 1) beskriver krav som de syften systemet ska uppfylla för användarna och vilka begränsningar som finns på systemet. I systemutveckling brukar man tala om två typer av krav; funktionella och icke-funktionella. Enligt Robertson & Robertson (2007, s. 9-10) beskrivs de funktionella kraven som produktens funktionalitet och de icke-funktionella kraven som de restriktioner som finns på produkten. Tidigt i utvecklingsprocessen undersöks intressenternas behov. Behoven översätts sedan till funktionella och icke-funktionella krav på systemet. Vilka krav som prioriteras menar Davis, Yourdon & Zweig (2000, s. 2) beror på flera faktorer. Dessa kan bland annat vara att det för projektet finns begränsade resurser eller att projektet har höga krav på riskminimering. Davis, Yourdon & Zweig (2000, s. 2) förespråkar en strukturerad kravprioritering där nödvändiga intressenter deltar. Kraven sammanfattas ofta i en kravspecifikation på lämplig detaljnivå. (Preece, Rogers & Sharp 2007, s 476) menar också att det är viktigt att kraven ska vara tydliga och formulerade på ett sådant sätt att man entydigt kan avgöra när systemet uppfyller ett krav. Kravarbetet måste anpassas till projektets storlek och projektmetod. Robertson & Robertson (2007, s. 7) föreslår tre olika storlekskategorier av utvecklingsprojekt, kanin-, häst och elefantprojekt där skillnaden mellan dessa är projektets storlek och behovet av noggrant kravarbete. Projekten går från att vara mycket agila (kanin) till mer vattenfallslika med en omfattande kravprocess i början av projektet och tydliga krav på dokumentation (elefant). Robertson & Robertson (2007, s. 9) menar att oavsett arbetssätt och projektets omfattning behöver man alltid skapa sig en förståelse för kraven och de bakomliggande behoven. Vidare 14

21 Teoretisk referensram menar de att kostnaden av en god initial kravinsamling är oväsentlig jämfört med kostnaden av en bristfällig kravinsamling. En allt för detaljerad kravbild i början av projektet motsäger ett iterativt arbetssätt då detta bygger på att man inte i förväg känner problemet och hur en lösning borde se ut (Gulliksen & Göransson 2002, s 108). Robertson & Robertson (2007, s. 20) menar att en kravprocess fortsätter under hela systemets livscykel. När en produkt, eller en del av en produkt, brukas av användarna upptäcks nya användningsområden och behov vilket ofta ger upphov till nya krav. Genom att leverera något till användarna i ett tidigt skede med minimal med funktionalitet kan man låta produkten utvecklas tillsammans med användarnas behov. Robertson & Robertson (2007, s. 17) menar att man för att hitta rätt krav behöver systematik i sitt kravarbete. För att stödja kravinsamlingen har Robertson & Robertson utvecklat Volere, vilket är riktlinjer för att säkerställa att alla krav tas om hand i kravprocessen och under senare utvecklingsaktiviteter. Volere innehåller 27 kategorier vilka bland annat motsvarar olika typer av krav (se figur 3). Då dessa 27 kategorier inte nödvändigtvis behöver ses över i början av projektet fungerar Volere även som en checklista. (Robertson & Robertson, 2007 s ). Projektets drivkrafter 1. Syftet med projektet 2. Beställare, kund och andra intressenter 3. Användare av produkten Produktens begränsningar 4. Krav som begränsningar produkten och utvecklingsprojektet 5. Begreppsordlista 6. Relevanta kringförhållanden och antaganden Funktionella krav 7. Arbetets omfattning 8. Produktens omfattning 9. Funktionella krav och krav på data som behandlas Icke-funktionella krav 10. Utseendemässiga krav 11. Krav på användbarhet 12. Krav på prestanda 13. Bruksmiljöns krav på systemet 14. Förvaltning- och supportrelaterade krav på produkten 15. Säkerhetsmässiga krav 16. Kulturella och politiska krav 17. Juridiska krav Frågeställningar rörande projektet 18. Öppna frågeställningar 19. Befintliga lösningar 20. Nya problem 21. Att-göra-lista 22. Migrering till ny produkt 23. Risker med projektet 24. Kostnadsuppskattning 25. Användarmanual 26. Väntrummet (framtida kravställningar) 27. Lösningsförslag Figur 3. Lista över Voleres kategorier (fritt översatt) (Robertson & Robertson, 2007 s ) 15

Agila Metoder. Nils Ehrenberg nils.ehrenberg@mah.se

Agila Metoder. Nils Ehrenberg nils.ehrenberg@mah.se Agila Metoder Nils Ehrenberg nils.ehrenberg@mah.se Agenda Agila Metoder: Scrum och sprints Lean och Design Workshops Kravställning Agil Utveckling Individer och interaktioner istället för processer Fungerande

Läs mer

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete

Projektmetodik II. HF1005, Informationsteknik och ingenjörsmetodik för Datateknik. Projektarbete Projektmetodik II HF1005, Informationsteknik och ingenjörsmetodik för Datateknik Projektarbete Förväntade resultatet är t.ex. en produkt Vi behöver arbeta med Analys Faktainsamling Genomförande Rapportering

Läs mer

Projekt- och kvalitetsstyrning på Frontec

Projekt- och kvalitetsstyrning på Frontec Projekt- och kvalitetsstyrning på Frontec Detta dokument beskriver hur Frontec bedriver utvecklingsprojekt med kvalitetssäkring FSAB_LS020_Projekt och kvalitetsstyrning A.doc Sida 1(6) Frontec kan projekt

Läs mer

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech

Användningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech Användningscentrering i agila utvecklingsprojekt johanna.sarna@valtech.com Valtech Vem är jag? Johanna Särnå Jobbar på Valtech sedan 3 år tillbaka Jobbar där med användbarhet och projektledning Certifierad

Läs mer

Anvisningar till rapporter i psykologi på B-nivå

Anvisningar till rapporter i psykologi på B-nivå Anvisningar till rapporter i psykologi på B-nivå En rapport i psykologi är det enklaste formatet för att rapportera en vetenskaplig undersökning inom psykologins forskningsfält. Något som kännetecknar

Läs mer

Analysen syftar till att ge en god gestalt. Kontinuerlig växling mellan delar och helhet.

Analysen syftar till att ge en god gestalt. Kontinuerlig växling mellan delar och helhet. Beteendevetenskaplig metod Kvalitativ analys Eva-Lotta Sallnäs Ph.D. CSC, Kungliga Tekniska Högskolan evalotta@csc.kth.se Kvalitativ databearbetning Analysen syftar till att ge en god gestalt. Kontinuerlig

Läs mer

SCRUM och mycket mer

SCRUM och mycket mer Typ av dokument Anvisning Skapad Senaste uppdatering 2008-01-27 2008-11-13 1 (5) Sida 1 Det minsta möjliga? SCRUM och mycket mer Om man nu vill vara agile och inte har allt tid i världen, vad skall man

Läs mer

SCRUM. En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte?

SCRUM. En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte? SCRUM En agil projektmetod baserad på empiri - vad fungerar och vad fungerar inte? Grundprinciper Projektgruppen organiserar och planerar sitt eget arbete Fokus på verksamhetsnytta Alla krav prioriteras

Läs mer

BESKRIVNING AV PROCESSMETODEN SCRUM

BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM NORDSCRUM BESKRIVNING AV PROCESSMETODEN SCRUM INNEHÅLLSFÖRTECKNING inledning... 3 SCRUM... 3 Bakgrund... 3 Faser... 3 Ramverket... 3 Nordscrum... 4 StudentProjekt...

Läs mer

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg

Automation Region. Affärsdriven systemutveckling genom agila metoder. Stefan Paulsson Thomas Öberg Automation Region Affärsdriven systemutveckling genom agila metoder Stefan Paulsson Thomas Öberg Frontit Frontit är ett svenskt konsultföretag i gränslandet mellan Management & IT, som stärker sina kunders

Läs mer

Processbeskrivning Systemutveckling

Processbeskrivning Systemutveckling ProcIT-P-015 Processbeskrivning Systemutveckling Lednings- och kvalitetssystem Fastställd av Sven Arvidson 2011-09-12 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Systemutvecklingsprocessen

Läs mer

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell.

2010-12-27 SCRUM. Vattenfallsmodellen. Analys. Design. Kod. Test. Rational Unified Process Agile. Kallas också linjär sekventiell modell. Vattenfallsmodellen SCRUM Analys Kallas också linjär sekventiell modell Introduktion Design Kod Test Rational Unified Process Agile DSDM Adaptive Software Development Crystal Feature-Driven Development

Läs mer

Lyckade projekt - finns det?

Lyckade projekt - finns det? Lyckade projekt - finns det? Maria Lindqvist Björkman Enea Business Software Enea Business Software 2002 Sida 1 Agenda Förväntningar kund & leverantör Statistik om projekt Framgångsfaktorer Exempel på

Läs mer

Metoder för Interaktionsdesign

Metoder för Interaktionsdesign Metoder för Interaktionsdesign Föreläsning 4 Projektmetodik och Scrum Kapitel 9-12 + 14, Scrumbok Det högra spåret Vi lämnar nu det vänstra spåret de mjukare delarna och går in på det högra spåret som

Läs mer

Kvalitativ Analys. Utvärderingsmetoder inom MDI DH2408

Kvalitativ Analys. Utvärderingsmetoder inom MDI DH2408 Kvalitativ Analys Utvärderingsmetoder inom MDI DH2408 Inlämningsuppgift 2 Era gruppinlämningar ligger här framme, leta reda på er egen!!! Jag har godtyckligt gett er ett gruppnummer, referera till det

Läs mer

Kursöversikt Certifierad Mjukvarutestare

Kursöversikt Certifierad Mjukvarutestare Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15

Läs mer

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp

Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp 2008 02 21 Identifiera kundbehov KPP306, Produkt och processutveckling, 15hp PM, Seminarie SEM1, 3hp Kapitel 4 Seminariegrupp 7 Författare: Robin Hellsing Robin Jarl Handledare: Rolf Lövgren Sammanfattning

Läs mer

Kravfångst Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form

Kravfångst Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form Kravfångst? Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form Gästföreläsning Datavetenskap 2011-02-15 Therese Söderlund, Lars Hansson och Jan Bidner (ITS) ITS - Enheten

Läs mer

Perspektiv på kunskap

Perspektiv på kunskap Perspektiv på kunskap Alt. 1. Kunskap är något objektivt, som kan fastställas oberoende av den som söker. Alt. 2. Kunskap är relativ och subjektiv. Vad som betraktas som kunskap är beroende av sammanhanget

Läs mer

Användbarhet i sitt sammanhang

Användbarhet i sitt sammanhang Användbarhet i sitt sammanhang Världsanvändbarhetsdagen 2009-11-12 Anders Hedberg, Guide Konsult Stockholm Innehåll En helikoptertur över ett projekts olika faser med belysning på användbarhet i förhållande

Läs mer

Interaktionsdesign som profession. Föreläsning Del 2

Interaktionsdesign som profession. Föreläsning Del 2 Interaktionsdesign som profession Föreläsning Del 2 Vikten av att göra research Varför behöver vi göra research? En produkt blir aldrig bättre än den data som denna baseras på Men Vi har redan gjort en

Läs mer

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning

PMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer

Läs mer

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation

Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...

Läs mer

UTVÄRDERING - VAD, HUR OCH VARFÖR? MALIN FORSSELL TOVE STENMAN

UTVÄRDERING - VAD, HUR OCH VARFÖR? MALIN FORSSELL TOVE STENMAN UTVÄRDERING - VAD, HUR OCH VARFÖR? MALIN FORSSELL TOVE STENMAN KORT OM RAMBÖLL OCH UTVÄRDERING Ca 60 konsulter i Stockholm, totalt 500 i Europa Ca 80 utvärderingar varje år i Sverige Stora utvärderingar,

Läs mer

Agile-metoder, XP och ACSD

Agile-metoder, XP och ACSD Användarcentrerad systemdesign. Föreläsning 12 Agile-metoder, XP och ACSD Stefan Blomkvist MDI / IT, stefan.blomkvist@it.uu.se & Profdoc AB www.profdoc.se www.it.uu.se/edu/course /homepage/acsd/s04 XP

Läs mer

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development

Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Identifiera kundbehov En sammanfattning och analys av kapitel 4 i boken Product Design and Development Grupp 6 Ali Abid Kjell Nilsson Patrick Larsson Mälardalens högskola KN3060, Produktutveckling med

Läs mer

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1

Scrum Scrum. en beskrivning. a description. V 2012.12.13 2012 Scrum Alliance,Inc 1 " Scrum Scrum en beskrivning a description 1" 1 Scrums principer Värderingar från Agile Manifesto Scrum är mest känt av de agila arbetssätten. Agile Manifesto utgör en gemensam bas för att arbeta agilt

Läs mer

Testbara krav. SAST Syd 2012-02-09. Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt

Testbara krav. SAST Syd 2012-02-09. Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt Testbara krav SAST Syd 2012-02-09 Ställ gärna frågor under presentationen eller efteråt Åhörarkopior distribueras efteråt Ulf Eriksson Produktägare på ReQtest Specialist på kravhantering och test Grundare

Läs mer

SESAM. Agila metoder

SESAM. Agila metoder SESAM Försvarssektorns Användargrupp för Software Engineering Inbjuder till seminariet Agila metoder en förutsättning för att lyckas med komplexa försvarssystem? 11 november 2010 Armémuseum, Stockholm

Läs mer

Du fulländar mig! Om synergierna mellan agila metoder och UX. Joakim Holm Adaptiv AB. Erik Hammarström Antrop AB

Du fulländar mig! Om synergierna mellan agila metoder och UX. Joakim Holm Adaptiv AB. Erik Hammarström Antrop AB Du fulländar mig! Om synergierna mellan agila metoder och UX Joakim Holm Adaptiv AB Erik Hammarström Antrop AB Vetenskapliga metoden 1. Observera verkligheten 4. Genomför experiment 2. Utforma hypotes

Läs mer

Agil programutveckling

Agil programutveckling Agil programutveckling Pontus Evertsson D00, Lunds Tekniska Högskola d00pe@efd.lth.se Anna Jennerheim D00, Lunds Tekniska Högskola d00aj@efd.lth.se 2003-05-15 1 1. Inledning 3 2. Extreme Programming (XP)

Läs mer

Metodologier Forskningsdesign

Metodologier Forskningsdesign Metodologier Forskningsdesign 1 Vetenskapsideal Paradigm Ansats Forskningsperspek6v Metodologi Metodik, även metod används Creswell Worldviews Postposi'vist Construc'vist Transforma've Pragma'c Research

Läs mer

Projektguide Kvalitetsdriven verksamhetsutveckling för kontaktsjuksköterskor 15 HP 2013-2014

Projektguide Kvalitetsdriven verksamhetsutveckling för kontaktsjuksköterskor 15 HP 2013-2014 Projektguide Kvalitetsdriven verksamhetsutveckling för kontaktsjuksköterskor 15 HP 2013-2014 Projektguide - Kvalitetsdriven verksamhetsutveckling 15 hp I utbildningen ingår att genomföra ett förbättringsprojekt.

Läs mer

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se

Agila Avtal. avtalsformer som kan fungera. Carina Meurlinger carina.meurlinger@agero.se Agila Avtal Hur man säljer in agila projekt olika avtalsformer som kan fungera Carina Meurlinger carina.meurlinger@agero.se Min syn på saken och kundens Detta är vad vi alla önskar Lite om mig själv Carina

Läs mer

ALM Live: Scrum + VSTS

ALM Live: Scrum + VSTS ALM Live: Scrum + VSTS Explained and distilled for Everyone! Micael Herkommer micael.herkommer@inexor.se Introduktion Micael Herkommer Developer Coach & Solutions Architect INEXOR EPiServer Professional

Läs mer

IT-projektledning - introduktion 725G62

IT-projektledning - introduktion 725G62 IEI Tommy Wedlund Läsanvisningar, IT-projektledning introduktion, 725G62 IT-projektledning - introduktion 725G62 Läsanvisningar tentamen inför tentamen I tentamen ingår följande kurslitteratur: The IBM

Läs mer

Datainsamling. Daniel Bosk. data.tex 1914 2014-08-26 13:33:45Z danbos

Datainsamling. Daniel Bosk. data.tex 1914 2014-08-26 13:33:45Z danbos 1 Datainsamling Daniel Bosk Avdelningen för informations- och kommunikationssytem (IKS), Mittuniversitetet, Sundsvall. data.tex 1914 2014-08-26 13:33:45Z danbos 2 Litteratur Du ska inför övningen ha läst

Läs mer

Betygskriterier för Examensarbete, 15hp Franska C1/C3, Italienska C, Spanska C/C3

Betygskriterier för Examensarbete, 15hp Franska C1/C3, Italienska C, Spanska C/C3 Uppsala universitet Institutionen för moderna språk VT11 Betygskriterier för Examensarbete, 15hp Franska C1/C3, Italienska C, Spanska C/C3 För betyget G skall samtliga betygskriterier för G uppfyllas.

Läs mer

Modell för agil utveckling och förvaltning av produkter

Modell för agil utveckling och förvaltning av produkter Beslutsdatum: 2014-07-23 MDH 1.1-396/14 1 (4) Beslutande: Förvaltningschefen Ansvarig för tillämpning: Förvaltningschef Dokumentansvarig: Rektors kansli Dokumenttyp: Processbeskrivning Datum för ikraftträdande:

Läs mer

HUR SÄKRAR VI KVALITET, ARBETSMILJÖ OCH BRANDSKYDD I VÅRA KREMATORIER?

HUR SÄKRAR VI KVALITET, ARBETSMILJÖ OCH BRANDSKYDD I VÅRA KREMATORIER? HUR SÄKRAR VI KVALITET, ARBETSMILJÖ OCH BRANDSKYDD I VÅRA KREMATORIER? Ett kartläggnings- och visualiseringsprojekt för att få En helhetsbild över arbetet som utgångspunkt för fortsatta diskussioner om

Läs mer

Projektutvärdering. Produkter och tjänster för ökad projektkultur. Partner

Projektutvärdering. Produkter och tjänster för ökad projektkultur. Partner Projektutvärdering Produkter och tjänster för ökad projektkultur Partner För att kunna erbjuda våra kunder ett heltäckande utbud inom projektområdet arbetar Effektiv Projektkonsult och tillsammans. Detta

Läs mer

Tentamen, delkurs Projektstyrning Webbutvecklare SU13, Malmö

Tentamen, delkurs Projektstyrning Webbutvecklare SU13, Malmö Sida 1/14 Tentamen Projektstyrning, Webbutvecklare, WU13, Malmö Tentamen, delkurs Projektstyrning Webbutvecklare SU13, Malmö Plats: Plushögskolan Malmö Tid: fredag 29 november 2013, kl. 9.00-12.00 Tillåtna

Läs mer

AvI-index. Ett instrument för att mäta IT-systems användbarhet

AvI-index. Ett instrument för att mäta IT-systems användbarhet ANDERS GUNÉR AvI-index Ett instrument för att mäta IT-systems användbarhet Iordanis Kavathatzopoulos Uppsala universitet ISBN 978-91-976643-5-6 Copyright 2008 Iordanis Kavathatzopoulos. Uppsala universitet,

Läs mer

Decentraliserad administration av gästkonton vid Karlstads universitet

Decentraliserad administration av gästkonton vid Karlstads universitet Datavetenskap Opponent(er): Markus Fors Christian Grahn Respondent(er): Christian Ekström Per Rydberg Decentraliserad administration av gästkonton vid Karlstads universitet Oppositionsrapport, C/D-nivå

Läs mer

Kravfångst Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form

Kravfångst Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form Kravfångst? Bra kravarbete handlar om att ställa rätt frågor och att ge rätt svar i rätt form Gästföreläsning Datavetenskap 2012-02-12 Lars Hansson och Jan Bidner (ITS) ITS - IT-stöd och systemutveckling

Läs mer

Agilt arbetssätt i komplexa organisationer. Välkomna! Anna Picetti, IT-HUSET 2011-10-27. www.it-huset.se

Agilt arbetssätt i komplexa organisationer. Välkomna! Anna Picetti, IT-HUSET 2011-10-27. www.it-huset.se Agilt arbetssätt i komplexa organisationer Välkomna! Anna Picetti, IT-HUSET 2011-10-27 Ord från en företagsledare Ett bra genomförande är 90 procent av framgången och strategin 10, varav magkänslan är

Läs mer

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman

Design och krav. Design Definition. enkelt Det ska vara möjligt att. Henrik Artman Design och krav Henrik Artman >>Ett av skälen till att projektet inte höll tidplan och budget var [beställarens] höga ambitionsnivå. Dessutom skulle man gjort en stordel av arbetet självt, men en del av

Läs mer

Den agila utvecklingen

Den agila utvecklingen Den agila utvecklingen En jämförelse mellan teori och praktik Agile Development A Comparison between Theory and Practice JENNIE HÄGGLUND JOHANNA FRE MARIA KARLSSON Examensarbete/Kandidatuppsats i Informatik

Läs mer

Målmedveten satsning på aktionsforskning i Varberg

Målmedveten satsning på aktionsforskning i Varberg Målmedveten satsning på aktionsforskning i Varberg 1 Målmedveten satsning på aktionsforskning i Varberg I Varberg finns sedan länge en ambition att sprida aktionsforskning som en metod för kvalitetsarbete

Läs mer

Ramverk för projekt och uppdrag

Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 1 (9) Ramverk för projekt och uppdrag Peter Yngve IT-centrum 2011-02-10 1.0 2 (9) BAKGRUND/MOTIV... 3 MÅL OCH SYFTE... 3 DEFINITIONER AV PROJEKT... 3 MODELL FÖR PROJEKTSTYRNING...

Läs mer

Bild 1: Översikt över faserna i projektarbetet

Bild 1: Översikt över faserna i projektarbetet Projektarbete kring system X Det här dokumentet beskriver uppgiften samt innehåller mallar för de rapporter som ska lämnas in. Bild 1 visar ordning och ungefärligt förhållande för tidsåtgång mellan de

Läs mer

Projekt intranät Office 365 av Per Ekstedt

Projekt intranät Office 365 av Per Ekstedt Projekt intranät Office 365 av Per Ekstedt 1 BESKRIVNING AV UTFÖRANDE Uppdraget planeras att genomföras med ett agilt arbetssätt samt best practice från Microsoft gällande SharePoint online. Uppdraget

Läs mer

HÖSTTERMINEN. Scrum STF INGENJÖRSUTBILDNING AB. Vi vidareutbildar ingenjörer och tekniker. Din partner för livslångt lärande

HÖSTTERMINEN. Scrum STF INGENJÖRSUTBILDNING AB. Vi vidareutbildar ingenjörer och tekniker. Din partner för livslångt lärande STF INGENJÖRSUTBILDNING Vi vidareutbildar ingenjörer och tekniker Scrum STF KOMPETENSINFO NR 63/2011 HÖSTTERMINEN STF INGENJÖRSUTBILDNING AB Din partner för livslångt lärande WWW.STF.SE Scrum i praktiken

Läs mer

Infomet / Datateknik KursPM

Infomet / Datateknik KursPM Kurs HF1005 Informationsteknik och ingenjörsmetodik 6hp, HT 2013 Infomet / KursPM Utdrag ur kursplanen Fullständig kursplan finns på http://www.kth.se/student/kurser/kurs/hf1005 Mål Kursens övergripande

Läs mer

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!

Projektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades! Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer

Läs mer

Agil utveckling ställer nya krav på upphandling. Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se

Agil utveckling ställer nya krav på upphandling. Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se Agil utveckling ställer nya krav på upphandling Roland Bäcklin, Jaybis Konsult AB roland.backlin@jaybis.se Roland Bäcklin Tidigare: Utvecklare, Systemarkitekt, Projektledare, CTO, CIO, Riksinstruktör,

Läs mer

Konstruera och anskaffa

Konstruera och anskaffa Konstruera och anskaffa www.informationssäkerhet.se 2 Upphovsrätt Tillåtelse ges att kopiera, distribuera, överföra samt skapa egna bearbetningar av detta dokument, även för kommersiellt bruk. Upphovsmannen

Läs mer

KOMMUNIKATIVT LEDARSKAP

KOMMUNIKATIVT LEDARSKAP KOMMUNIKATIVT LEDARSKAP 7, 100, 85, 7 EN ANALYS AV INTERVJUER MED CHEFER OCH MEDARBETARE I FEM FÖRETAG NORRMEJERIER SAAB SANDVIK SPENDRUPS VOLVO Mittuniversitetet Avdelningen för medieoch kommunikationsvetenskap

Läs mer

KOMMUNIKATIVT LEDARSKAP

KOMMUNIKATIVT LEDARSKAP KOMMUNIKATIVT LEDARSKAP 7, 100, 85, 7 EN ANALYS AV INTERVJUER MED CHEFER OCH MEDARBETARE I FEM FÖRETAG NORRMEJERIER SAAB SANDVIK SPENDRUPS VOLVO Mittuniversitetet Avdelningen för medieoch kommunikationsvetenskap

Läs mer

Skriftlig redovisning av gymnasiearbetet

Skriftlig redovisning av gymnasiearbetet Skriftlig redovisning av gymnasiearbetet Gymnasiearbetet ska förbereda eleven för högskolestudier. Det innebär att gymnasiearbetet utförs och redovisas med arbetssätt och redovisningsformer som liknar

Läs mer

Operatörer och användargränssnitt vid processtyrning

Operatörer och användargränssnitt vid processtyrning Operatörer och användargränssnitt vid processtyrning Normativa och beskrivande analyser Uppsala universitet @ 2003 Anders Jansson Sammanfattning kap. 1 Sociotekniska system Många olika grupper av användare

Läs mer

Användbarhet och Webbutveckling för mobila enheter. Behovsanalys

Användbarhet och Webbutveckling för mobila enheter. Behovsanalys Användbarhet och Webbutveckling för mobila enheter Behovsanalys Kurshemsidan Böcker mobilutveckling Dokumentation/Inlämningar Kommer på hemsidan (tills på måndag?) Nästa vecka: Planeringsdokument (Scrum)

Läs mer

En sammanfattning av. - Implementeringsutvärdering av Beslutsstöd i tre kommuner

En sammanfattning av. - Implementeringsutvärdering av Beslutsstöd i tre kommuner En sammanfattning av - Implementeringsutvärdering av Beslutsstöd i tre kommuner Abstrakt Under de senaste åren har flera problem inom hjälpmedelområdet lyfts fram. För att hantera utvecklingen har Beslutsstöd

Läs mer

ETT ARBETSSÄTT FÖR AGIL KRAVHANTERING. Kandidatuppsats i Informatik. Beatrice Eriksson VT 2013:KANI13

ETT ARBETSSÄTT FÖR AGIL KRAVHANTERING. Kandidatuppsats i Informatik. Beatrice Eriksson VT 2013:KANI13 ETT ARBETSSÄTT FÖR AGIL KRAVHANTERING Kandidatuppsats i Informatik Beatrice Eriksson VT 2013:KANI13 Svensk titel: Ett arbetssätt för agil kravhantering Engelsk titel: An approach for agile requirements

Läs mer

Projektplan för utvecklingen av Kryssarklubbens nya webbplats

Projektplan för utvecklingen av Kryssarklubbens nya webbplats Projektplan för utvecklingen av Kryssarklubbens nya webbplats Sammanfattning Detta dokument beskriver hur Kryssarklubbens nya webbplats skall tas fram. Planen är ett resultat av det arbete som gjorts av

Läs mer

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban

Presentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Presentation Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Om AddQ Mission Vi skapar affärsnytta för kunden genom specialisttjänster inom test, kvalitetssäkring och effektivisering Tjänsteområden

Läs mer

Kurser och seminarier från AddQ Consulting

Kurser och seminarier från AddQ Consulting och seminarier från AddQ Consulting Vår vision är att genom fokus på kvalitet och effektivitet inom IT bidra till att underlätta människors vardag. Kompetensutveckling är nyckeln till framgång för dig

Läs mer

PROJEKTSKOLA 1 STARTA ETT PROJEKT

PROJEKTSKOLA 1 STARTA ETT PROJEKT PROJEKTSKOLA I ett projekt har du möjlighet att pröva på det okända och spännande. Du får både lyckas och misslyckas. Det viktiga är att du av utvärdering och uppföljning lär dig av misstagen. Du kan då

Läs mer

KVALITATIV DESIGN C A R I T A H Å K A N S S O N

KVALITATIV DESIGN C A R I T A H Å K A N S S O N KVALITATIV DESIGN C A R I T A H Å K A N S S O N KVALITATIV DESIGN Svarar på frågor som börjar med Hur? Vad? Syftet är att Identifiera Beskriva Karaktärisera Förstå EXEMPEL 1. Beskriva hälsofrämjande faktorer

Läs mer

Utveckling av simulator för ärendehanteringssystem

Utveckling av simulator för ärendehanteringssystem Datavetenskap Opponent(er): Emil Danielsson & Patrik Lundberg Respondent(er): Niclas Hanold & Samiar Saldjoghi Utveckling av simulator för ärendehanteringssystem Oppositionsrapport, C/D-nivå 2005:xx 1

Läs mer

Collaborative Product Development:

Collaborative Product Development: Collaborative Product Development: a Purchasing Strategy for Small Industrialized House-building Companies Opponent: Erik Sandberg, LiU Institutionen för ekonomisk och industriell utveckling Vad är egentligen

Läs mer

Kursplan ENGELSKA. Ämnets syfte. Mål. Innehåll. Insikt med utsikt

Kursplan ENGELSKA. Ämnets syfte. Mål. Innehåll. Insikt med utsikt Kursplan ENGELSKA Ämnets syfte Undervisningen i ämnet engelska ska syfta till att deltagarna utvecklar språk- och omvärldskunskaper så att de kan, vill och vågar använda engelska i olika situationer och

Läs mer

Agil testning i SCRUM

Agil testning i SCRUM Agil testning i SCRUM Petter Salomonsson Petter.salomonsson@addq.se Tel: 0708-398435 Kort presentation AddQ Consulting AB tydlig fokus på test och kvalitetssäkringstjänster erbjuder mycket erfarna konsulter

Läs mer

Exempel på gymnasiearbete inom ekonomiprogrammet juridik

Exempel på gymnasiearbete inom ekonomiprogrammet juridik Exempel på gymnasiearbete september 2012 Exempel på gymnasiearbete inom ekonomiprogrammet juridik Barnets ställning i vårdnadstvister Elevens idé Martin har en idé om att göra sitt gymnasiearbete om barn

Läs mer

Instruktion Stöd för processkartläggning i ett processorienterat arbetssätt för Region Skåne. Syfte

Instruktion Stöd för processkartläggning i ett processorienterat arbetssätt för Region Skåne. Syfte Instruktion Stöd för processkartläggning i ett 1 (7) Instruktion Stöd för processkartläggning i ett processorienterat arbetssätt för Region Skåne. Syfte Denna instruktion syftar till att utgöra ett stöd

Läs mer

Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport

Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport Webbsystems inverkan på innehåll och användbarhet på webbplatser - oppositionsrapport Respondenter: Emma Henriksson och Ola Ekelund Opponenter: Eva Pettersson och Johan Westerdahl Sammanfattande omdöme

Läs mer

Skapa kreativa och innovativa testorganisationer. Staffan Iverstam, QualityMinds

Skapa kreativa och innovativa testorganisationer. Staffan Iverstam, QualityMinds Skapa kreativa och innovativa testorganisationer Staffan Iverstam, QualityMinds Kort om mig Staffan Iverstam, QualityMinds Civilekonom som arbetat med affärsutveckling och e-butiker. IT-konsult sedan 2001

Läs mer

Fakulteten för ekonomi, kommunikation och IT. Jenny Ericsson. Kanban. Går metoden att använda för att styra utvecklingsprojekt? Informatik.

Fakulteten för ekonomi, kommunikation och IT. Jenny Ericsson. Kanban. Går metoden att använda för att styra utvecklingsprojekt? Informatik. Fakulteten för ekonomi, kommunikation och IT Jenny Ericsson Kanban Går metoden att använda för att styra utvecklingsprojekt? Informatik C-uppsats Datum: VT 2011 Handledare: Examinator: Lars-Erik Axelsson

Läs mer

FÖR FÖRETAG/ORGANISATIONER I SAMBAND MED EXAMENSARBETE. Vägledning

FÖR FÖRETAG/ORGANISATIONER I SAMBAND MED EXAMENSARBETE. Vägledning FÖR FÖRETAG/ORGANISATIONER I SAMBAND MED EXAMENSARBETE Vägledning INNEHÅLLSFÖRTECKNING Inledning... 3 Beskriv rätt problem eller utvecklingsidé... 3 Vad är ett examensarbete... 3 Vad är en handledares

Läs mer

Människa- datorinteraktion, MDI, vt 2012, Anvisningar för projekt- /grupparbete

Människa- datorinteraktion, MDI, vt 2012, Anvisningar för projekt- /grupparbete Människa- datorinteraktion, MDI, vt 2012 Anvisningar för projekt- /grupparbete Kursens projektuppgift består av att genomföra ett projektarbete i grupper om 3-4 personer. Uppgiften ska sedan presenteras

Läs mer

Spelplanen ändras. 1. Agila arbetssätt växer sig starkare. 2. Förenkling, transparens och flexibilitet blir ledstjärnor i förändringsarbeten.

Spelplanen ändras. 1. Agila arbetssätt växer sig starkare. 2. Förenkling, transparens och flexibilitet blir ledstjärnor i förändringsarbeten. Spelplanen ändras Allt fler är överens om att vi står inför en förändring i sättet att se på och arbeta i projekt och organisationer. Trender kommer och går men det finns några som kommer att bestå och

Läs mer

En jämförande studie av begreppet Agil utveckling i teori och praktisk användning

En jämförande studie av begreppet Agil utveckling i teori och praktisk användning Teknik och samhälle Datavetenskap Examensarbete 15 högskolepoäng, grundnivå En jämförande studie av begreppet Agil utveckling i teori och praktisk användning A comperative study of the agile concept. Agile

Läs mer

- A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform

- A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform Datavetenskap Opponent(er): Jhonny Carvajal Johan Bjärneryd Respondent(er): Fredrik Häggbom Erik Olsson Haglund Scrumptious - A Scrum Planning Tool Case Study to Evaluate the The Rich AJAX Platform Oppositionsrapport,

Läs mer

Agile - det moderna synsättet på mjukvaruutveckling Ordet Agile kommer från engelskan och kan närmast översättas med flexibel, dynamisk och smidig. Med det menar vi dynamiska projekt som konstruktivt kan

Läs mer

Metodstöd www.informationssäkerhet.se 2

Metodstöd www.informationssäkerhet.se 2 Projektplanering www.informationssäkerhet.se 2 Upphovsrätt Tillåtelse ges att kopiera, distribuera, överföra samt skapa egna bearbetningar av detta dokument, även för kommersiellt bruk. Upphovsmannen måste

Läs mer

HANTERING AV PROBLEM I

HANTERING AV PROBLEM I HANTERING AV PROBLEM I AGIL SYSTEMUTVECKLING EN FALLSTUDIE AV CGI Kandidatuppsats i Informatik Mike Pihel Christian Bartelius 2013KANI:02 Svensk titel: Hantering av problem i agil systemutveckling en fallstudie

Läs mer

Utforma säkerhetsprocesser

Utforma säkerhetsprocesser Utforma säkerhetsprocesser www.informationssäkerhet.se 2 Upphovsrätt Tillåtelse ges att kopiera, distribuera, överföra samt skapa egna bearbetningar av detta dokument, även för kommersiellt bruk. Upphovsmannen

Läs mer

Objektorientering. Grunderna i OO

Objektorientering. Grunderna i OO Objektorientering Grunderna i OO 1 Systemutveckling Tre systemnivåer: Verksamhet Informationssystem Datasystem Huvuduppgifterna i ett systemutvecklingsarbete: Verksamhetsanalys Informationsbehovsanalys

Läs mer

SYSTEMUTVECKLING METODER & MODELLER. Suzana Ramadani

SYSTEMUTVECKLING METODER & MODELLER. Suzana Ramadani SYSTEMUTVECKLING METODER & MODELLER 1 Processlinjen Produktlinjen Livscykelmodellen systemutveckling systemering Analys Design Realisering Implementering Förändringsanalys Verksamhetsanalys Förvaltning

Läs mer

Analys av kvalitativ data Kvalitativ innehållsanalys som ett exempel. Introduktion Bakgrund Syfte Metod Resultat Diskussion Slutsats

Analys av kvalitativ data Kvalitativ innehållsanalys som ett exempel. Introduktion Bakgrund Syfte Metod Resultat Diskussion Slutsats KVALITATIV ANALYS Analys av kvalitativ data Kvalitativ innehållsanalys som ett exempel Övning i att analysera Therese Wirback, adjunkt Introduktion Bakgrund Syfte Metod Resultat Diskussion Slutsats Fånga

Läs mer

Metoder för datainsamling

Metoder för datainsamling Metoder för datainsamling Föreläsning 16/10-2002 Christina von Dorrien Kapitel 9.4, 12-13 Användarcentrerad designmetodik Analysera användare, användningssituation och uppgift Testa och utvärdera designförslag,

Läs mer

Praktikum i programvaruproduktion

Praktikum i programvaruproduktion Praktikum i programvaruproduktion Introduktion Föreläsare/Ansvarig: Pontus Boström Email:pontus.bostrom@abo.fi Rum A5055 Assistent: Petter Sandvik Email: petter.sandvik@abo.fi Rum: A5048 Föreläsningar:

Läs mer

Kursen presenterar olika perspektiv inom beteendevetenskap med fokus på metod. Praktisk övning i datainsamlingstekniker ges.

Kursen presenterar olika perspektiv inom beteendevetenskap med fokus på metod. Praktisk övning i datainsamlingstekniker ges. Beteendevetenskaplig metod Kursen presenterar olika perspektiv inom beteendevetenskap med fokus på metod. Praktisk övning i datainsamlingstekniker ges. Kursens mål är att ge kännedom om beteendevetenskaplig

Läs mer

Kvalitativ intervju en introduktion

Kvalitativ intervju en introduktion Kvalitativ intervju en introduktion Olika typer av intervju Övning 4 att intervjua och transkribera Individuell intervju Djupintervju, semistrukturerad intervju Gruppintervju Fokusgruppintervju Narrativer

Läs mer

Utvärdering några grundbegrepp

Utvärdering några grundbegrepp Utvärdering några grundbegrepp Fredrik Björk, Projektledning, Malmö högskola 2005-11-07 Inledning: varför skall man utvärdera? Varför skall man utvärdera en verksamhet? Svaret på den frågan är inte så

Läs mer

Riktlinjer Projektmodell fo r Kungä lvs kommun

Riktlinjer Projektmodell fo r Kungä lvs kommun Riktlinjer Projektmodell fo r Kungä lvs kommun Riktlinjerna är antagna av förvaltningsledningen 2013-01-28 och gäller tillsvidare. (Dnr KS2012/1542) Ansvarig för dokumentet är chefen för enheten Utveckling,

Läs mer

Riktlinjer för bedömning av examensarbeten

Riktlinjer för bedömning av examensarbeten Fastställda av Styrelsen för utbildning 2010-09-10 Dnr: 4603/10-300 Senast reviderade 2012-08-17 Riktlinjer för bedömning av Sedan 1 juli 2007 ska enligt högskoleförordningen samtliga yrkesutbildningar

Läs mer

Införandemetod Medverkaprojektet

Införandemetod Medverkaprojektet Införandemetod Medverkaprojektet Förbättring och digitalisering av Malmö stads ärendeprocess Detta dokument beskriver översiktligt projektprocessen för de införandeprojekt som bedrivits i varje förvaltning

Läs mer

Projektplan - Hållbarhetsintegrering

Projektplan - Hållbarhetsintegrering Projektplan - Hållbarhetsintegrering Stadskontoret Upprättad Datum: Version: Ansvarig: Förvaltning: Enhet: 2015-01-09 1.0 Susanna Jakobsson, Lotta Heckley, Maria Kronogård, Jenny Theander Stadskontoret

Läs mer