While agile development is becoming ever more popular, studies have shown that few organisations successfully transition from traditional to agile practices. One such study showed that large organisations can benefit greatly from agile methods, but evaluating agile maturity and tailoring the method to the organisation’s needs is crucial. An agile maturity model is a tool with which an organisation’s practices and their conformance to agile development is evaluated. The purpose of this study is to discover the best suited agile maturity model for large organisations and to minimise costs, resources and the subjectivity of the model’s evaluation. In this study we take a closer look at four agile maturity models, the Scaled Agile Framework Maturity Model (SAFeMM) by Turetken, Stojanov and Trienekens (2017), the Scaled Agile Maturity Model (SAMM) by Chandrasekaran (2016), the Agile Adoption Framework (AAF) by Sidky, Arthur and Bohner (2007) and the Scaled Agile Framework Business Agility Assessment (SAFeBAA) by the Scaled Agile Incorporation. By evaluating each model on their scalability, completeness, generality, precision, simplicity, usability and meaningfulness, consistency, minimum overlapping, balance and proportion of automatable measurements, the best model is chosen. Based on the evaluation criteria for the maturity models, the SAFeMM is deemed the most suitable model. It proves to be a comprehensive, well-rounded tool with persistent high scores in all criteria. In order to improve the model’s objectivity and resource needs, it is also applied in a case study at the Swedish Tax Agency, where the possibilities to automate the model are investigated. The results show that the SAFeMM can be automated to roughly 50%, with the use of process mining and software system querying. Process mining uses event logs to extract and analyse information, while software querying extracts information directly from the software systems used in an organisation. The study suggests primary sources for querying and process mining techniques and perspectives to enable and encourage future research in the area of process mining within agile development. / Agil utveckling är en mycket populär utvecklingsmetod, samtidigt visar studier att få stora organisationer lyckas med övergången från traditionella metoder direkt. Som hjälpmedel kan dessa organisationer använda så kallade agila mognadsmodeller. En agil mognadsmodell är ett verktyg som mäter hur väl en organisation och dess processer överensstämmer med agila principer. Syftet med denna studie är att undersöka vilken agil mognadsmodell som är bäst lämpad för stora organisationer och kan samtidigt minimera kostnader, resurser och subjektiviteten i mätningarna. Därför tittar denna studie på fyra agila mognadsmodeller, Scaled Agile Framework Maturity Model (SAFeMM) av Turetken, Stojanov och Trienekens (2017), Scaled Agile Maturity Model (SAMM) av Chandrasekaran (2016), Agile Adoption Framework (AAF) av Sidky, Arthur och Bohner (2007) och Scaled Agile Framework Business Agility Assessment (SAFeBAA) av Scaled Agile Incorporation. Genom att utvärdera varje modell baserat på dess skalbarhet, helhetsbild, generaliserbarhet, precision, enkelhet, användbar-het och meningfullhet, kontinuitet, minimal överlappning, balans och andel automatiserbara mätvärden, bestäms vilken modell som är bäst. Resultaten visar, att baserat på de ovannämnda kriterierna, är SAFeMM modellen den bäst lämpade för stora organisationer. Den visade sig vara särsilkt helhetstäckande, enkel att förstå och använda, med höga poäng på de flesta kriterierna. För att förbättra modellens objektivitet och resurskrav, gjordes även en fallstudie där modellen applicerades på Skatteverkets IT avdelning. Där undersöktes möjligheterna för att automatisera modellen. Resultaten visar att knappt 50% av modellen är automatiserbar genom metoder såsom process mining och software querying. Process mining, använder event loggar från mjukvarusystem för att analysera och utvinna information, medan software querying utvinnar information direkt från mjukvarusystemen. Studien presenterar förslag på utvinningskällor och process mining tekniker och metoder för sammanhanget.

Digitala spel har blivit ett allt vanligare sätt för underhållning, där industrin har sett en stor ökning av användare, vilket har stor sannolikhet att fortsätta även i framtiden. Dessa spel har ökat i komplexitet i takt med den teknologiska utvecklingen från 90-talet tills idag, där Internet har haft stor påverkan och introducerat nya möjligheter. En utav dessa möjligheter är insamlingen av olika datatyper med olika syften och olika användningsområden inom ett spelutvecklingsföretag. Industrin har lockat mycket forskning angående processer och metoder som berör skapandet av dessa komplexa produkter, där förarbetet och själva skapandet av digitala spel tar upp majoriteten av forskning i jämförelse med vidareutvecklingen av dessa digitala spel efter lansering. Syftet med denna rapport är därmed att bidra med kunskap till det mindre utforskade området kring utvecklingsprocessen efter lansering av online multiplayerspel, samt undersökning och insamling av data och dess integrering i vidareutvecklingsprocessen. Första viktiga delen av rapporten är ett teoriavsnitt, skapad genom en litteraturstudie där denna bestod av att identifiera och hitta vetenskapliga artiklar med kunskap kring ämnet, där dessa var viktiga för att skapa en teoretisk grund för denna studie. Detta gjordes huvudsakligen genom vetenskapliga databaser och söktjänster, med hjälp av nyckelord relaterade till viktiga teorier. Den andra viktiga delen är empiriska studier i form av semistrukturerade intervjuer utifrån en intervjuguide med respondenter från olika spelutvecklingsföretag. Företagen som respondenterna jobbade för var Ghost Ship Games, Jagex, samt Bohemia Interactive. Dessa intervjuer har sedan analyserats och viktiga teman har identifierats utifrån respondenternas svar. Respondenterna har nämnt olika datatyper som kan täcka olika delar av företaget, men när det gäller vidareutveckling av spel har tre typer nämnts att ha störst påverkan. Dessa typer var datapunkter över hur spelet används av individer, kvalitetsdata av spelets prestanda samt feedback från användare. Metoderna för att samla in de förenämnda datatyperna består framförallt av enkäter som alla respondenter har nämnt att respektive företag använder för att samla in feedback, rapportering av bugs eller förslag på förbättringsområden. Utöver detta samlas även mer övergripande information genom digitala verktyg eller spelklienten för respektive spel. Där dessa verktyg är skapade inom företaget eller hanteras genom ett separat företag. Ghost Ship Games har nämnt en egen idealbild över hur spelet ska vara balanserat som företaget strävar efter, vilket tas i åtanke vid beslut som tas av utvecklarna som täcker respektive problem. Inom Jagex är det hela team som bestämmer tillsammans angående förändringar eller tillägg i spelet. En intressant aspekt var att för Jagex så är användarna en del av beslutsfattandet genom opinionsundersökningar. Beslutsfattandet inom Bohemia Interactive nämndes att ske huvudsakligen genom avdelningen för kvalitetssäkring, där dessa filtrerar insamlad information och sedan delegerar identifierade problem till rätt utvecklare inom företaget. Vidareutvecklingen inom företagen gjordes framförallt genom balansering med hjälp av spelmotorn för respektive spel. Ghost Ship Games fokuserar även på vidareutveckling av befintliga funktioner, system och verktyg, genom att omarbeta några av föregående delar. Inom Bohemia Interactive angående Arma 3 användes till exempel hotfixes eller helt nytt spelinnehåll genom DLC, liknande sker även inom Jagex i form av hotpatches. Övergripande så är vidareutvecklingsprocessen lik mellan företagen, genom de olika steg som har identifierats i denna rapport. Dessa kan beskrivas som en iterativ process där företag identifierar problem eller förslag för vidareutveckling, samlar in eller undersöker befintlig data för att bekräfta problem eller stödja förslag, implementerar lösning eller förslag, samt samlar in feedback och agerar utifrån feedback. / Digital games have become an increasingly common means of entertainment where the industry has seen a huge increase in users, something that is likely to continue in the future. These games have increased in complexity in line with technological developments from the 1990s to the present day, where the Internet has had a major impact and introduced new possibilities. One of these opportunities is the collection of different types of data with different purposes and different uses within a game development company. The industry has thus attracted a lot of research regarding processes and methods involved in the creation of these complex products, where the pre-processing and actual creation of digital games is in the vast majority of studies compared to the further development of these digital games after launch. The aim of this paper is therefore to contribute knowledge to the less explored area of the post-launch development process of online multiplayer games, as well as the investigation of data collection and its integration into the further development process. The first important part of the report is a theory section, created through literature review where this consisted of identifying and finding scientific articles with knowledge on the topic, where these were important to create a theoretical basis for this study. This was mainly done through scientific databases and search services, using keywords related to important theories. The second important part is empirical studies in the form of semi-structured interviews based on an interview guide with respondents from different game development companies. The companies the respondents worked for were Ghost Ship Games, Jagex, and Bohemia Interactive. These interviews were then analysed and important themes were identified based on the respondents’ answers. Respondents mentioned different types of data that could cover different parts of the company, but when it comes to further game development, three types were mentioned to have the most impact. These types were data points on how the game is used by individuals, quality data of the game's performance, and feedback from users. The methods for collecting the aforementioned data types consist mainly of surveys, which all respondents mentioned that the respective companies use to collect feedback, report bugs or suggest areas for improvement. In addition, more general information is also collected through digital tools or the game client for the respective game. Where these tools are created within the company or managed by a separate company. Ghost Ship Games has an ideal image of how the game should be balanced that the company strives for, which is taken into account when decisions are made by the developers themselves that cover the respective issues. Within Jagex, the whole team decides together on changes or additions to the game. An interesting aspect is that within Jagex, users are a part of the decision making process through opinion polls. Decision-making within Bohemia Interactive is mainly done through the Quality Assurance department, where they filter collected information and then delegate identified problems to the appropriate developers within the company. Further development within the companies is mainly done through balancing using the game engine for each game. Ghost Ship Games may also focus on further development of existing features, systems and tools, by reworking some of the previously mentioned elements. In Bohemia Interactive regarding Arma 3, are hotfixes or completely new game content through DLC used for example. Similar is also done in Jagex in the form of hotpatches. Overall, the further development process is similar between the companies, through the different steps identified in this report. These can be described as an iterative process in which companies identify problems or proposals for further development, collect data or investigate existing data, implement the solution or proposal, collect feedback and act on the feedback.

Most Agile Software Development methodologies are aimed towards large companies and large-scale projects. The purpose of this report was to identify, and potentially modify, Agile Development methodologies and strategies suitable for small-scale projects. Initially a comprehensive study was conducted on a few selected agile methodologies in order to find the most suitable one to be used for a loosely defined small-scale project. The result of the study led to the methodology Kanban being used experimentally on that project. The report goes through how Kanban was utilized and modified to better suit the project as well as bring forward interesting details regarding the outcome of the actual project. The produced methodology, with Kanban at its core, can especially be of use for small IT companies looking for an agile methodology fitting their project(s). It could also be used to further develop alternative variants of the agile methodology Kanban with focus on small-scale projects. / De flesta agila utvecklingsmetodiker riktar sig mot storskaliga projekt och företag. Syftet med denna rapport var att identifiera lämpliga agila utvecklingsmetodiker och strategier för småskaliga projekt. Inledningsvis genomfördes en omfattande studie av ett fåtal agila metodiker med målet att hitta den mest lämpliga för ett löst definierat småskaligt projekt. Resultat av studien ledde till att metodiken Kanban experimenterades med och användes för projektet. Rapporten går igenom hur Kanban nyttjades och modifierades för att bättre passa projektet i fråga. Den framtagna metodiken, med Kanban som grund, kan vara speciellt användbar för mindre IT-företag som letar efter en agil metodik som passar deras projekt. Den skulle även kunna användas för att vidareutveckla alternativa agila Kanban-metodiker för småskaliga projekt.

I början av år 2020 blev världen medveten om viruset covid-19 som orsakade en pandemi. Människor och företag har behövt anpassa sig till följd av den rådande situationen för att minska smittspridningen vilket har gjort att anställda tvingats till att arbeta på distans. Tidigare forskning har visat att det finns utmaningar att arbeta med agila metoder på distans där team eller delar av team arbetar distribuerat. Dock berör dessa forskningar till största del agila utvecklingsprojekt där IT-företag är verksamma globalt. Denna studie har undersökt hur arbetet bedrivs på distans där alla teammedlemmar arbetar distribuerat till följd av andra orsaker än att mjukvaruutvecklingen sker globalt. Syftet med denna studie har varit att undersöka hur anställda som ingår i teams upplever arbetet med agila utvecklingsprojekt som bedrivs på distans till följd av rådande pandemi. Därför har följande två frågeställningar formulerats “På vilka sätt upplever anställda som ingår i teams att interaktionen gentemot kollegor fungerar under den rådande pandemin?” och “Hur upplever anställda att arbetet på distans fungerar när de arbetar distribuerat till följd av covid-19?”. För att undersöka detta genomfördes åtta semistrukturerade intervjuer med mjukvaruutvecklare som arbetar med Scrum inom ett medelstort IT-företag beläget i västra Sverige. Majoriteten av respondenterna har ingått i samma teams under flera år och har därför en bra relation till sina kollegor. Resultatet visade att arbetet med agila utvecklingsprojekt som bedrivs på distans till följd av pandemin har fungerat bra. Respondenterna har inte upplevt några svårigheter med att överföra Scrum till distans vilket kan bero på att de arbetat inom samma teams en längre tid. För att kunna utföra arbetet krävs det interaktion och kommunikation, något som respondenterna upplever som väl fungerande även på distans. Dock har den informella kommunikationen inte kunnat ersättas fullt ut av digitala verktyg, något som tidigare forskning lyft fram som en begränsning när team arbetar distribuerat. / At the beginning of 2020, the world became aware of the covid-19 virus that caused a pandemic. People and companies have had to adapt as a result of the current situation in order to reduce the spread of the virus, which has forced employees to work remotely. Previous research has shown that there are challenges in working with agile methods remotely where teams or parts of teams work distributed. However, these researches largely concern agile software development projects in which IT companies operate globally. This study has examined how the work is conducted remotely where all team members work distributed as a result of other reasons than the global software development. The purpose of this study has been to investigate how employees who are part of teams experience the work with agile development projects that are conducted remotely as a result of the current pandemic. Therefore, the following two research questions have been formulated as “In what ways do employees who are part of teams feel that the interaction with colleagues works during the current pandemic?” and “How do employees feel that remote work functions when they work distributed as a result of covid-19?”. To investigate this, eight semi-structured interviews were conducted with software developers working with Scrum within a medium-sized IT company located in western Sweden. The majority of the respondents have been part of the same team for several years and therefore have a good relationship with their colleagues. The results showed that the work with agile development projects conducted remotely as a result of the pandemic has functioned well. The respondents have not experienced any difficulties intransferring Scrum in regards to distance work, which could depend on the fact that they have worked within the same team for a long period of time. In order to be able to perform the job, both interaction and communication are required, something that the respondents experienceas working well even remotely. However, informal communication has not been able to be fully replaced by digital tools, something that previous research highlights as a limitation when teams work distributed.

Product development has become essential in today’s technology driven marketplace. Currently, pointbased models such as the stage-gate model are applied in practice of several incumbent firms in the automotive industry. However, stage-gate models have been criticized for being too linear and plan focused as external pressures and internal complexity demand for faster and more flexible development, such as agile development. Although product development has a central role in the success of a firm, suppliers play a central role in helping firms achieve their product development goals. As a result, firms may undertake suppler development and integration initiatives to ensure quality and efficiency at the supplier. Utilizing supplier integration has shown positive effects on several performance outcomes. However, limited research on the effects of suppliers being integrated to deficient development practices has been published. Firms that integrate suppliers into point-based, documentation heavy processes could therefore potentially hinder internal development of flexible practices. Therefore, the aim of this study is to investigate how supplier integration challenges suppliers in adopting agile methods in product development and how these challenges can be addressed.  This study is based a qualitative, exploratory case study approach, including 13 interviews with various stakeholders within the case company together with extensive data from observations. The empirical data in combination with theories on agile development, traditional development, and supplier integration resulted in a proposition for adopting agile development approaches for integrated suppliers being locked-in to traditional development models. The findings indicate that integrated suppliers may face challenges in adopting agile methods due to requirements from the integrating firm on using traditional development methods. However, a possibility to utilize agile practices on the microperspective while retaining traditional development methods on the macro-perspective through a hybrid model enables adoption of agile methods for integrated suppliers. Although the possibility to adopt agile methods exist, the methods yield little benefits unless an agile leadership and vision is established. Therefore, a transition towards agile development also requires a transition in organizational culture to promote collaboration, distributed responsibility and collective intelligence. / Produktutveckling har blivit väsentlig på dagens teknikdrivna marknadsplats. För närvarande är traditionella modeller som stage-gate vanligt förekommande i flera etablerade företag inom bilindustrin, även om dessa modeller har kritiserats för att vara för linjära och planfokuserade när omgivningen och intern komplexitet kräver snabbare och mer flexibel utveckling. Även om produktutveckling har en fundamental roll i framgången hos ett företag så är leverantörer centrala i att hjälpa företag att uppnå sina produktutvecklingsmål. Som ett resultat av ökad outsourcing kan företag vidta mer utvecklings och integrationsinitiativ för att säkerställa kvalitet och effektivitet hos leverantören. Att använda leverantörsintegration har visat positiva effekter på flera nyckeltal. Emellertid har begränsad forskning om effekterna av att integrera leverantörer i ineffektiva produktutvecklingsmetoder publicerats. Företag som integrerar leverantörer i linjära, dokumentationstunga processer kan därför potentiellt hindra den interna utvecklingen av flexibla tillvägagångssätt. Därmed är syftet med denna studie att undersöka hur leverantörsintegration kan försvåra tillämpning av agila metoder i produktutveckling för leverantörer och hur dessa utmaningar kan adresseras. Denna studie bygger på en kvalitativ, explorativ fallstudie som inkluderar 13 intervjuer med anställda inom det observerade företaget tillsammans med omfattande data från observationer. Empiriska data i kombination med teorier om agil utveckling, traditionell utveckling och leverantörsintegration resulterade i ett förslag till integrerade leverantörer, som är bundna till traditionella utvecklingsmodeller, att adoptera agila utvecklingsmetoder. Resultaten tyder på att integrerade leverantörer kan möta utmaningar när det gäller att använda agila metoder på grund av krav att använda traditionella utvecklingsmetoder från det integrerande företaget. Där emot finns möjlighet att tillämpa agila metoder i mikroperspektivet samtidigt som traditionella utvecklingsmetoder bibehålls i makroperspektivet genom en hybridmodell. Även om möjligheten att adoptera agila metoder finns ger metoderna små fördelar utan adekvat agilt ledarskap och tankesätt. Därmed kräver en övergång till agil produktutveckling också en förändring i organisationskultur för att främja samarbete, distribuerat ansvar och kollektiv intelligens.

Public procurement is described as trade in goods andservices by government agencies. Carrying out aprocurement of information systems according to atraditional purchasing process is challenging if the intendedsystem is extensive or complex, as many requirements andother documentation are needed for a supplier to be able tocarry out the assignment. This makes it challenging forsuppliers to deliver a product that meets the customer'sexpectations and is one of the reasons why many public ITprojects fail today.System development has been conducted as standardaccording to an agile development process for many years.To be able to apply the agile way of working in systemdevelopment work in the public sector, a new way ofprocuring is required. This is done by describing whichimpact goals the business wants the system to satisfy andthen sets requirements for the development team that willcarry out the work, instead of setting requirements for thesystem.The knowledge gap identified and which the study aimed toinvestigate was how agile development teams should beevaluated, so that it is ensured that the supplier who winsthe procurement is also the development team that candeliver the most cost-effective solution for the contractingauthority.A qualitative study has been carried out, which was basedon a literature review to map the current state of knowledgein the field and to create a theoretical basis to start from. Theempirical material has been collected by conducting eightsemi-structured interviews with respondents from thecustomer and supplier side in public procurement of agiledevelopment teams. The collected material has beenanalysed to map success factors in evaluating agiledevelopment teams in public procurement.The study resulted in five success factors that were identifiedas important to consider when evaluating agile developmentteams, these are clear impact goals, mature organization,competence in the agile working methods, evaluation of softfactors and a clear project plan. By identifying and ensuringthese factors during the evaluation phase in publicprocurement, the contracting authority can procure thesupplier that best meets their expectations. / Offentlig upphandling beskrivs som handel av varor ochtjänster av statliga verksamheter. Att genomföra enupphandling av informationssystem enligt en traditionellinköpsprocess är utmanande om det påtänkta systemet äromfattande eller komplext eftersom det behövs en stormängd krav och annan dokumentation för att en leverantörska kunna genomföra uppdraget. Detta gör det utmanandeför leverantörer att leverera en produkt som motsvararbeställarens förväntningar och är en av anledningarna till attmånga offentliga IT-projekt misslyckas idag.Systemutveckling bedrivs som standard enligt en agilutvecklingsprocess sedan många år tillbaka. För att kunnatillämpa det agila arbetssättet vid systemutvecklingsarbeteninom offentliga sektorn så krävs ett nytt sätt att upphandla.Detta görs genom att beskriva vilka effektmål verksamhetenvill att systemet ska tillfredsställa och sedan kravställskompetenser på det utvecklingsteam som ska genomföraarbetet, i stället för att ställa krav på systemet.Den kunskapslucka som identifierats och som studien syftatatt undersöka var hur agila utvecklingsteam bör utvärderas,så att det säkerställs att den leverantör som vinnerupphandlingen också är det utvecklingsteam som harförmågan att leverera den mest kostnadseffektiva lösningenför den upphandlande myndigheten.En kvalitativ studie har genomförts, som utgått från enlitteraturgranskning för att kartlägga det aktuellakunskapsläget inom området och för att skapa en teoretiskgrund att utgå från. Det empiriska materialet har samlats ingenom att genomföra åtta semistrukturerade intervjuer medrespondenter från beställar- och leverantörssidan vidoffentlig upphandling av agila utvecklingsteam. Detinsamlade materialet har analyserats för att kartläggaframgångsfaktorer vid utvärdering av agila utvecklingsteamvid offentlig upphandling.Studien resulterade i fem framgångsfaktorer somidentifierats som viktiga att beakta vid utvärdering av agilautvecklingsteam, dessa är tydliga effektmål, mogenorganisation, kompetens inom de agila arbetssättet,utvärdering av mjuka faktorer och tydlig projektplan.Genom att kartlägga och säkerställa dessa faktorer underutvärderingsfasen inom offentlig upphandling, kan denupphandlande myndigheten upphandla den leverantör sommotsvarar deras förväntningar på bäst sätt.

Brist på information, och otydligt kommunicerade krav är vanligt i IT-projekt, särskilt vid handover-processen, där designen överlämnas till utvecklare för implementation. User Experience (UX), eller användarupplevelse, syftar till att skapa en positiv interaktion och känsla av en produkt för användaren. Enligt företaget CGI infinner sig problem och om-arbete när UX-kompetens utesluts eller brister, vilket är vanligare när designen kommer från extern aktör kontra internt (in-house). I studien identifieras effekten på utvecklingsprocessen när handover och kommunikation får ta plats, samt effekten av sena ändringar. Detta i syfte att påvisa värdet av robusta underlag och tidig UX-involvering in-house. Problem och förbättringsförslag identifieras i syfte att stärka framtida projekt. Insamling av data sker genom metodisk triangulering. Genom två implementeringar av CGI:s interna verktyg och webblösning CGIMoving – En med ett lågdetaljerat designunderlag, och en med handover och kommunikation med UX-designer. Data från implementeringens mätpunkter, dagboksanteckningar och kommunikationslogg samlas in. För att bredda perspektivet, genomfördes en fristående fokusgruppsdiskussion med praktiker med olika erfarenhet. Resultatet analyserades genom tematisk analys, och den kvalitativa och kvantitativa data analyserades och jämfördes mot tidigare litteratur. Studien visar att problem och konsekvenser i överföringen av design till kod, berör både in-house och extern aktör, men försvåras när leverantören är extern, då olika grad av kommunikation, UX- och webbkompetens förekommer. En robust handover och kommunikation mellan UX-designer och utvecklare effektiviserar utvecklingsprocessen genom att mildra identifierade problem, minskar resursåtgång och ökar slutproduktens kvalitet. Sena designändringar på befintlig lösning får negativa effekter och ökar resursåtgången med avseende på utvecklingstid och externa förtydliganden, samt påverkar den övergripande kodstrukturen, och orsakar frustration och ökade kostnader. Att prioritera UX in-house kan ha en hög initial kostnad, men effektiviserar utvecklingsprocessen och lämnar högre kvalité av slutprodukten, eftersom kommunikation och nära samarbete naturligt infinner sig. För optimering föreslås tidig involvering av mångsidiga roller och kompetens, diskussioner om tekniken, och skriftliga beskrivningar av komponenter. Främst föreslås en produktutvecklande kommunikation, där lösningen och design kan anpassas direkt – i likhet med co-creation. Viss kod- och webbkunskap hos UX-designern kan underlätta exporteringen av design-komponenter till kod, och förslag om att tidigt specificera variabler redan i designunderlaget anges. Framställning av ett ramverk rekommenderas, för att säkerställa ett gemensamt tillvägagångssätt för skapandet och användandet av designunderlag och designsystem.

<p>I maj 2009 släpptes den första betaversionen av Visual Studio Team System 2010. Den innehåller en rad intressanta nyheter och funktioner som kan underlätta utvecklingsarbetet och höja den interna kvaliteten.</p><p>Kvalitetsbegreppet inom mjukvaruutveckling kan delas upp i två delar: extern och intern kvalitet. Med extern kvalitet menas det som kunden ser, till exempel att rätt funktionalitet utvecklas och att den levereras i tid. Intern kvalitet handlar om processer inom företaget och det som kunden ofta inte ser eller är medveten om.</p><p>Nyheter i Visual Studio 2010 har utvärderats i fokusgrupper tillsammans med rutinerade utvecklare på Medius. Den agila arbetsprocessen har utvärderats utifrån observationer, informella intervjuer samt den teoretiska referensram som ställts upp.</p><p>Utvärderingarna har resulterat i ett antal riktlinjer för hur Medius kan förbättra sin interna kvalitetsprocess. Dessa rekommenderar bland annat mindre förändringar i den agila arbetsprocessen, till exempel tydligare utvärderingar och uppföljning samt introduktion av distribuerad Scrum. Riktlinjerna föreslår också införandet av verktygen kodkontrakt, incheckningsregler och gränssnittstestning i Visual Studio 2010.</p>

I maj 2009 släpptes den första betaversionen av Visual Studio Team System 2010. Den innehåller en rad intressanta nyheter och funktioner som kan underlätta utvecklingsarbetet och höja den interna kvaliteten. Kvalitetsbegreppet inom mjukvaruutveckling kan delas upp i två delar: extern och intern kvalitet. Med extern kvalitet menas det som kunden ser, till exempel att rätt funktionalitet utvecklas och att den levereras i tid. Intern kvalitet handlar om processer inom företaget och det som kunden ofta inte ser eller är medveten om. Nyheter i Visual Studio 2010 har utvärderats i fokusgrupper tillsammans med rutinerade utvecklare på Medius. Den agila arbetsprocessen har utvärderats utifrån observationer, informella intervjuer samt den teoretiska referensram som ställts upp. Utvärderingarna har resulterat i ett antal riktlinjer för hur Medius kan förbättra sin interna kvalitetsprocess. Dessa rekommenderar bland annat mindre förändringar i den agila arbetsprocessen, till exempel tydligare utvärderingar och uppföljning samt introduktion av distribuerad Scrum. Riktlinjerna föreslår också införandet av verktygen kodkontrakt, incheckningsregler och gränssnittstestning i Visual Studio 2010.