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

Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE

Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE Innehåll Vad är en bra uppsats? Söka, använda och refera till litteratur Insamling

Läs mer

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

Användarcentrerad Systemutveckling

Användarcentrerad Systemutveckling Användarcentrerad Systemutveckling Människadatorinteraktion (MDI) Inst. för informationsteknologi http://www.it.uu.se/edu/ course/homepage/hci/ ht10 Användarcentrerad systemutveckling, gränssnitt och prototyper.

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

Business research methods, Bryman & Bell 2007

Business research methods, Bryman & Bell 2007 Business research methods, Bryman & Bell 2007 Introduktion Kapitlet behandlar analys av kvalitativ data och analysen beskrivs som komplex då kvalitativ data ofta består av en stor mängd ostrukturerad data

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

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

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

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

för att komma fram till resultat och slutsatser

för att komma fram till resultat och slutsatser för att komma fram till resultat och slutsatser Bearbetning & kvalitetssäkring 6:1 E. Bearbetning av materialet Analys och tolkning inleds med sortering och kodning av materialet 1) Kvalitativ hermeneutisk

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

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

Kvalitativa metoder I

Kvalitativa metoder I Kvalitativa metoder I PeD Gunilla Eklund Rum F 625, tel. 3247354 E-post: geklund@abo.fi http://www.vasa.abo.fi/users/geklund/default.htm Forskningsmetodik - kandidatnivå Forskningsmetodik I Informationssökning

Läs mer

Chaos om IT-projekt..

Chaos om IT-projekt.. Användarcentrerad systemutveckling, gränssnitt och prototyper. Lämplig extraläsning Gulliksen, Göransson: Användarcentrerad systemdesign, Studentlitteratur, kapitel: 4, 5, 6, 7, 8, 9 (Bredvidläsning) Syfte

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

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

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

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

Titel på examensarbetet. Dittnamn Efternamn. Examensarbete 2013 Programmet

Titel på examensarbetet. Dittnamn Efternamn. Examensarbete 2013 Programmet Titel på examensarbetet på två rader Dittnamn Efternamn Examensarbete 2013 Programmet Titel på examensarbetet på två rader English title on one row Dittnamn Efternamn Detta examensarbete är utfört vid

Läs mer

Rutiner för opposition

Rutiner för opposition Rutiner för opposition Utdrag ur Rutiner för utförande av examensarbete vid Avdelningen för kvalitetsteknik och statistik, Luleå tekniska universitet Fjärde upplagan, gäller examensarbeten påbörjade efter

Läs mer

Kvalitativ metodik. Varför. Vad är det? Vad är det? Varför och när använda? Hur gör man? För- och nackdelar?

Kvalitativ metodik. Varför. Vad är det? Vad är det? Varför och när använda? Hur gör man? För- och nackdelar? Kvalitativ metodik Vad är det? Varför och när använda? Hur gör man? För- och nackdelar? Mats Foldevi 2009 Varför Komplement ej konkurrent Överbrygga klyftan mellan vetenskaplig upptäckt och realiserande

Läs mer

Föreläsning 11, Planera utvärdering. Att planera utvärdering. Vetenskapliga experiment. Kapitel i kursboken

Föreläsning 11, Planera utvärdering. Att planera utvärdering. Vetenskapliga experiment. Kapitel i kursboken Föreläsning 11 Planera utvärdering Kapitel 22-24 i kursboken Att planera utvärdering Vem, vilka? Att välja användare, antal Vad? Hur sätter man ihop lämpliga uppgifter? När? Hur lång tid ska man avsätta?

Läs mer

Föreläsning 4: Designprocessen

Föreläsning 4: Designprocessen Föreläsning 4: Designprocessen FSR: 2, 3, (6), 7 Att läsa: Kapitel 9 och 12 i Rogers et al.: Interaction design 4/e 150911 Designprocessen 2 Designprocessenöversikt Introduktion Att involvera användare

Läs mer

Kurser och seminarier från AddQ Consulting

Kurser och seminarier från AddQ Consulting Kurser och seminarier från AddQ Consulting Med fokus på kvalitet och effektivitet bidrar vi till att underlätta människors vardag. Kompetensutveckling är nyckeln till framgång för dig som jobbar med test,

Läs mer

Föreläsning 6: Analys och tolkning från insamling till insikt

Föreläsning 6: Analys och tolkning från insamling till insikt Föreläsning 6: Analys och tolkning från insamling till insikt FSR: 1, 5, 6, 7 Rogers et al. Kapitel 8 Översikt Kvalitativ och kvantitativ analys Enkel kvantitativ analys Enkel kvalitativ analys Presentera

Läs mer

Hållbar utveckling A, Ht. 2014

Hållbar utveckling A, Ht. 2014 Hållbar utveckling A, Ht. 2014 Kommunikation och projektledning för hållbar utveckling Projektplan Bakgrund Som ett stöd i ert projekt kommer ni att arbeta utifrån en projektplan i tre delar, varje ny

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

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

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

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

Kriterier för bedömning av examensarbete vid den farmaceutiska fakulteten

Kriterier för bedömning av examensarbete vid den farmaceutiska fakulteten Kriterier för bedömning av examensarbete vid den farmaceutiska fakulteten 1 Inledning Vid den farmaceutiska fakulteten har det sedan 2005 funnits kriterier för bedömning av examensarbete (medfarm 2005/913).

Läs mer

Föreläsning 5: Analys och tolkning från insamling till insikt. Rogers et al. Kapitel 8

Föreläsning 5: Analys och tolkning från insamling till insikt. Rogers et al. Kapitel 8 Föreläsning 5: Analys och tolkning från insamling till insikt Rogers et al. Kapitel 8 Översikt Kvalitativ och kvantitativ analys Enkel kvantitativ analys Enkel kvalitativ analys Presentera resultat: noggrann

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

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

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

Här ges en överblick över de delar som ingår i projektarbetet och beskriver kraven och bedömningskriterierna.

Här ges en överblick över de delar som ingår i projektarbetet och beskriver kraven och bedömningskriterierna. ACPU 2006 Experter Årets tema handlar om tekniska stöd åt experter. Vi vill att ni ska koncenterar er på människor som har en konkret och specifik kompetens inom ett avgränsat område. Denna kunskap kan

Läs mer

Bedömningsmall med riktlinjer för kvalitetskriterier för bedömning av examensarbete master+civilingenjör

Bedömningsmall med riktlinjer för kvalitetskriterier för bedömning av examensarbete master+civilingenjör Bedömningsmall med riktlinjer för kvalitetskriterier för bedömning av examensarbete master+civilingenjör Examensarbetet bedöms i områdena: Process, Ingenjörsmässigt och vetenskapligt innehåll samt Presentation.

Läs mer

TDDC72 Kvalitativ Medod Seminarie 2

TDDC72 Kvalitativ Medod Seminarie 2 1 2 Vad händer idag? TDDC72 Kvalitativ Medod Seminarie 2 Lärare: Jonatan Wentzel jonwe@ida.liu.se Presentation av grundläggande begrepp och datainsamlingsmetoder Observation Att selektera och hantera data

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

Användbarhet. Datorbaserade verktyg används till att. Aspekter på användbarhet. uppfylla behov eller lösa problem! Användbarhet.

Användbarhet. Datorbaserade verktyg används till att. Aspekter på användbarhet. uppfylla behov eller lösa problem! Användbarhet. Innehåll Användbarhet Användbarhet När, hur och vem? Specificering av krav Utvärdering Stefan Berglund Användbarhet Den grad i vilken användare i ett givet sammanhang kan bruka en produkt för att uppnå

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

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

RUP - Rational Unified Process

RUP - Rational Unified Process IBM Software Group RUP - Rational Unified Process Eva Hådding eva.hadding@se.ibm.com 1 Projektkaos. Chaos-rapporten 28% av projekten avslutades i tid och enligt budget. 49% av projekten drog över de ursprungliga

Läs mer

Kursens syfte. En introduktion till uppsatsskrivande och forskningsmetodik. Metodkurs. Egen uppsats. Seminariebehandling

Kursens syfte. En introduktion till uppsatsskrivande och forskningsmetodik. Metodkurs. Egen uppsats. Seminariebehandling Kursens syfte En introduktion till uppsatsskrivande och forskningsmetodik Metodkurs kurslitteratur, granska tidigare uppsatser Egen uppsats samla in, bearbeta och analysera litteratur och eget empiriskt

Läs mer

Agil Projektledning. En introduktion

Agil Projektledning. En introduktion Agil Projektledning En introduktion Agil Projektledning Förändringar sker alltid i projekt Agil projektledning handlar om att hantera dessa Kunden har dålig insyn i ett traditionellt projekt De ska vara

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

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel.

Deluppgift 2 Kravhantering a) (2p) När man diskuterar krav brukar man ange två olika typer av krav. Beskriv dessa och ge exempel. Page 1 (5) Hemuppgift 1DV404 150115-150118 Deluppgift 1 Processmodeller a) (4p) Alla mjukvaruutvecklare följer någon form av utvecklingsprocess i sitt arbete. Diskutera vad organisationer brukar ange som

Läs mer

Fastställa mål. Daniel Bosk. goals.tex :33:45Z danbos

Fastställa mål. Daniel Bosk. goals.tex :33:45Z danbos 1 Fastställa mål Daniel Bosk Avdelningen för informations- och kommunikationssytem (IKS), Mittuniversitetet, Sundsvall. goals.tex 1914 2014-08-26 13:33:45Z danbos 2 Litteratur Du ska inför denna övning

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

Provmoment: Tentamen 3 Ladokkod: 61ST01 Tentamen ges för: SSK06 VHB. TentamensKod: Tentamensdatum: 2012-12-14 Tid: 09.00-12.00

Provmoment: Tentamen 3 Ladokkod: 61ST01 Tentamen ges för: SSK06 VHB. TentamensKod: Tentamensdatum: 2012-12-14 Tid: 09.00-12.00 Vetenskaplig teori och metod Provmoment: Tentamen 3 Ladokkod: 61ST01 Tentamen ges för: SSK06 VHB 7,5 högskolepoäng TentamensKod: Tentamensdatum: 2012-12-14 Tid: 09.00-12.00 Hjälpmedel: Inga hjälpmedel

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

Fungerar Agila principer i alla typer av projekt?

Fungerar Agila principer i alla typer av projekt? Fungerar Agila principer i alla typer av projekt? Wenell Management AB Vad är Agile? Agile kan sägas vara ett paraplybegrepp. Det är inte en systemutvecklingsmetodik i sig utan snarare en uppsättning värderingar,

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

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

Att designa en vetenskaplig studie

Att designa en vetenskaplig studie Att designa en vetenskaplig studie B-uppsats i hållbar utveckling Jakob Grandin våren 2015 @ CEMUS www.cemusstudent.se Vetenskap (lågtyska wetenskap, egentligen kännedom, kunskap ), organiserad kunskap;

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

Metoduppgift 4 - PM. Barnfattigdom i Linköpings kommun. 2013-03-01 Pernilla Asp, 910119-3184 Statsvetenskapliga metoder: 733G02 Linköpings universitet

Metoduppgift 4 - PM. Barnfattigdom i Linköpings kommun. 2013-03-01 Pernilla Asp, 910119-3184 Statsvetenskapliga metoder: 733G02 Linköpings universitet Metoduppgift 4 - PM Barnfattigdom i Linköpings kommun 2013-03-01 Pernilla Asp, 910119-3184 Statsvetenskapliga metoder: 733G02 Linköpings universitet Problem Barnfattigdom är ett allvarligt socialt problem

Läs mer

Kravplan Projekt Datum Version. Författare KRAVPLAN. KravXperts i samarbete med Kunskapsresan Sida 1 av (7)

Kravplan Projekt Datum Version. Författare KRAVPLAN. KravXperts i samarbete med Kunskapsresan Sida 1 av (7) KRAVPLAN Sida 1 av (7) Revisionshistorik Datum Version Beskrivning Sida 2 av (7) Innehållsförteckning 1 INLEDNING... 4 1.1 BAKGRUND... 4 1.2 MÅL OCH SYFTE... 4 1.3 OMFATTNING OCH AVGRÄNSNING... 4 1.4 BEROENDEN

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

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

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

Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16

Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16 Kurs-PM fo r HI1028, Projektkurs inom programvaruutveckling, VT16 Mål Kursen skall ge studenten träning i att utveckla en större programvara. Arbetet utförs i projektform. Projektet skall ge grundläggande

Läs mer

KOMMUNIKATIVT LEDARSKAP

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

Läs mer

Forskningsprocessens olika faser

Forskningsprocessens olika faser Forskningsprocessens olika faser JOSEFINE NYBY JOSEFINE.NYBY@ABO.FI Steg i en undersökning 1. Problemformulering 2. Planering 3. Datainsamling 4. Analys 5. Rapportering 1. Problemformulering: intresseområde

Läs mer

Kursbeskrivning och schema: Statsvetenskapliga metoder, statsvetenskap 2, 5 poäng (VT 2007)

Kursbeskrivning och schema: Statsvetenskapliga metoder, statsvetenskap 2, 5 poäng (VT 2007) LINKÖPINGS UNIVERSITET 2007-01-19 Institutionen för ekonomisk och industriell utveckling Avdelningen för statsvetenskap Marie Jansson marie.jansson@ihs.liu.se Kursbeskrivning och schema: Statsvetenskapliga

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

UTBILDNING I SYSTEMATISK UPPFÖLJNING

UTBILDNING I SYSTEMATISK UPPFÖLJNING 2015 UTBILDNING I SYSTEMATISK UPPFÖLJNING Utbildningen syftar till att bredda och fördjupa kunskapen om hur systematisk uppföljning på olika nivåer kan planeras, genomföras, användas och komma till nytta

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

Prototyping. Planera och genomföra webbproduktionsprojekt. Innehåll. Fördelarna med Pappersprototyper. Lofi-prototyp. Prototyping

Prototyping. Planera och genomföra webbproduktionsprojekt. Innehåll. Fördelarna med Pappersprototyper. Lofi-prototyp. Prototyping Innehåll Planera och genomföra webbproduktionsprojekt Stefan Berglund Prototyping Prototyping LoFi-prototyp HiFi-prototyp Användarcentrerad utveckling Användbarhet Specificering av krav Prototyping Kartläggning

Läs mer

Kursbeskrivning och schema: Statsvetenskapliga metoder, statsvetenskap 2, 7,5 poäng (HT 2007)

Kursbeskrivning och schema: Statsvetenskapliga metoder, statsvetenskap 2, 7,5 poäng (HT 2007) LINKÖPINGS UNIVERSITET 2007-09-03 Institutionen för ekonomisk och industriell utveckling Avdelningen för statsvetenskap Marie Jansson marie.jansson@ihs.liu.se Kursbeskrivning och schema: Statsvetenskapliga

Läs mer

Process- och metodreflektion. Grupp 3; Ida Gustafsson, Mikael Karlsson, Jonas Lind, Hanne Sundin, Maria Törnkvist

Process- och metodreflektion. Grupp 3; Ida Gustafsson, Mikael Karlsson, Jonas Lind, Hanne Sundin, Maria Törnkvist Process- och metodreflektion Grupp 3; Ida Gustafsson, Mikael Karlsson, Jonas Lind, Hanne Sundin, Maria Törnkvist Planeringen Redan från början av projektet bestämde vi oss i gruppen för att planera utförande

Läs mer

UTVECKLINGSSAMTAL. Chefens förberedelser inför utvecklingssamtal

UTVECKLINGSSAMTAL. Chefens förberedelser inför utvecklingssamtal UTVECKLINGSSAMTAL Chefens förberedelser inför utvecklingssamtal Detta är ett stödmaterial för planering och förberedelser av utvecklingssamtal och innehåller tre delar: 1. Syfte med utvecklingssamtal 2.

Läs mer

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

Människa- datorinteraktion, MDI, ht 2012, Anvisningar för projekt- /grupparbete Människa- datorinteraktion, MDI, ht 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

Prototyping. Susanna Olsson, TietoEnator Funda Denizhan, TietoEnator Ann Lantz, CID

Prototyping. Susanna Olsson, TietoEnator Funda Denizhan, TietoEnator Ann Lantz, CID Prototyping Susanna Olsson, TietoEnator Funda Denizhan, TietoEnator Ann Lantz, CID TRITA-NA-D0105 CID-139, KTH, Stockholm, Sweden 2001 Susanna Olsson, TietoEnator, Funda Denizhan, TietoEnator, Ann Lantz,

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

Användarcentrerad systemdesign introduktion till begrepp, processer och arbetssätt

Användarcentrerad systemdesign introduktion till begrepp, processer och arbetssätt Användarcentrerad systemdesign introduktion till begrepp, processer och arbetssätt Bengt Göransson bengt.goransson@it.uu.se Människa-datorinteraktion 1MD016, hösten 2012 Avdelningen för Visuell information

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

Kursbeskrivning och schema: Statsvetenskapliga metoder, statsvetenskap 2, (7,5 poäng) VT 2008

Kursbeskrivning och schema: Statsvetenskapliga metoder, statsvetenskap 2, (7,5 poäng) VT 2008 LINKÖPINGS UNIVERSITET 20080116 Institutionen för ekonomisk och industriell utveckling Avdelningen för statsvetenskap Marie Jansson marie.jansson@ihs.liu.se Kursbeskrivning och schema: Statsvetenskapliga

Läs mer

ATT MÄTA FRAMGÅNG I MATEMATIKPROJEKT MARTIN GRANDER MALMÖ HÖGSKOLA

ATT MÄTA FRAMGÅNG I MATEMATIKPROJEKT MARTIN GRANDER MALMÖ HÖGSKOLA ATT MÄTA FRAMGÅNG I MATEMATIKPROJEKT MARTIN GRANDER 2012-05-08 martin.grander@mah.se HUR VET DU ATT DU HAR LYCKATS MED DITT PROJEKT? Hur kan du kontinuerligt arbeta för att mäta framgång när det gäller

Läs mer

Kvalitativa metoder. Amy Rankin amy.rankin@liu.se

Kvalitativa metoder. Amy Rankin amy.rankin@liu.se Kvalitativa metoder Amy Rankin amy.rankin@liu.se Vad händer i dag? Validitet och reliabilitet Metodfördjupning: observation, intervju Diskussion av artikel Exploring the Openness of Cognitive Artifacts

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

DH2622 MDI-fk Introduktion till kursen & ämnet. MDI på KTH. Kursen i sitt sammanhang

DH2622 MDI-fk Introduktion till kursen & ämnet. MDI på KTH. Kursen i sitt sammanhang DH2622 MDI-fk Introduktion till kursen & ämnet Tisdagen den 27 oktober 13-15 i svg alz@kth.se http://www.csc.kth.se/utbildni ng/kth/kurser/dh2622/ MDI på KTH Kursen i sitt sammanhang Forskningsmiljö Utbildning

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

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

Utvärdering. Övergripande (1) Med/utan användare. Övergripande (2) Fredag 1 oktober F1. Ann Lantz - Anna Swartling -

Utvärdering. Övergripande (1) Med/utan användare. Övergripande (2) Fredag 1 oktober F1. Ann Lantz - Anna Swartling - Utvärdering Fredag 1 oktober 13-15 F1 Ann Lantz - alz@nada.kth.se Anna Swartling - ast@kth.se Övergripande (1) Av den verkliga världen: Hur agerar man, vad händer? Hur används teknik? Beteendevetenskapliga

Läs mer

Projektarbete. Anvisningar, tips och mallar. Sammanställt lå 05/06 av lärgruppen - Projektarbete

Projektarbete. Anvisningar, tips och mallar. Sammanställt lå 05/06 av lärgruppen - Projektarbete Projektarbete Anvisningar, tips och mallar Sammanställt lå 05/06 av lärgruppen - Projektarbete Henrik Andersson, Martina Johansson, Göran Johannesson, Björn Bergfeldt, Per-Erik Eriksson, Franz Kreutzkopf,

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

A-Ö Ämnet i pdf Ämne - Fysik Fysik är ett naturvetenskapligt ämne som har sitt ursprung i människans behov av att förstå och förklara sin omvärld. Fysik behandlar allt från växelverkan mellan materiens

Läs mer

Agil Projektledning. En introduktion

Agil Projektledning. En introduktion Agil Projektledning En introduktion Agil Projektledning Förändringar sker alltid i projekt Agil projektledning handlar om att hantera dessa Kunden har dålig insyn i ett traditionellt projekt De ska vara

Läs mer

Framsida Titelsida ii Trycksida iii Abstract iv Sammanfattning v Förord vi Tom vii Innehållsförteckning 1 Introduktion... 1 1.1 Bakgrund... 1 1.2 Inledning... 1 1.2.1 Kaprifolen... 2 1.3 Syfte... 2 1.4

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

Examensarbete, Högskoleingenjör energiteknik, 15 hp Grundnivå

Examensarbete, Högskoleingenjör energiteknik, 15 hp Grundnivå Examensarbete, Högskoleingenjör energiteknik, 15 hp Grundnivå Studenten ska tillämpa kunskaper och färdigheter förvärvade inom utbildningsprogrammet genom att på ett självständigt och vetenskapligt sätt

Läs mer

Holmen Skogs anvisningar för examensarbeten 15 högskolepoäng

Holmen Skogs anvisningar för examensarbeten 15 högskolepoäng Holmen Skogs anvisningar för examensarbeten 15 högskolepoäng 1. Allmänt Inom Holmen Skog fyller examensarbeten tre syften: - ett sätt att knyta kontakter med studenter i slutfasen av deras utbildningar

Läs mer

Beställa och ställa krav på ett användarcentrerat sätt. Nätverksträff för 24-timmarswebben Norra Latin 12 december 2007

Beställa och ställa krav på ett användarcentrerat sätt. Nätverksträff för 24-timmarswebben Norra Latin 12 december 2007 Beställa och ställa krav på ett användarcentrerat sätt Nätverksträff för 24-timmarswebben Norra Latin 12 december 2007 Fredrik Andersson fredrik.andersson@kronofogden.se Idag en del av Skatteverket, fr

Läs mer

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare

IBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare Fibonacci / översättning från engelska IBSE Ett självreflekterande(självkritiskt) verktyg för lärare Riktlinjer för lärare Vad är det? Detta verktyg för självutvärdering sätter upp kriterier som gör det

Läs mer

"Distributed Watchdog System"

Distributed Watchdog System Datavetenskap Emma Henriksson Ola Ekelund Oppositionsrapport på uppsatsen "Distributed Watchdog System" Oppositionsrapport, C-nivå 2005 1 Sammanfattande omdöme på exjobbet Projektet tycks ha varit av

Läs mer

Vetenskapsteori och vetenskaplig forskningsmetod II SQ1361 (termin 6) Studiehandledning

Vetenskapsteori och vetenskaplig forskningsmetod II SQ1361 (termin 6) Studiehandledning Institutionen för socialt arbete Vetenskapsteori och vetenskaplig forskningsmetod II SQ1361 (termin 6) Studiehandledning Vårterminen 2011 Kursansvarig: Jörgen Lundälv December 2010 JL 1 Välkommen! Du hälsas

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