På försvarets materielverk (FMV) i Karlsborg utförs prover av militära vapensystem. Ofta när prov genomförs samlas också väderdata in för att veta om yttre faktorer kan påverka en träffbild. Insamling av väderdata är en manuell process som FMV önskar att automatisera. Målet är att skapa ett system med hjälp av en befintlig vädersensor som kan visa väderparametrar i realtid på en skärm samt spara dem vid rätt tillfälle på ett flyttbart media. Vid utveckling av system för insamling av väderdata ska det väljas ut lämplig hårdvara där även mjukvaran ska formas. Den teoretiska referensramen och litteraturstudierna utgjorde en bra grund för hela projektet genom att få en förståelse om alla de delar som måste tas hänsyn till. FMV har som krav att hårdvaran ska vara baserad på en integrerad krets. Det innebär kortfattat att det inte finns något operativsystem utan att det består endast av en källkod. Den befintliga vädersensorn som ska användas kommunicerar via seriell kommunikation. Det gjordes också ett val mellan två utvecklingsmodeller där en av dem senare ska användas som ett hjälpmedel för utvecklingsprocessen av hela systemet. Den utvecklingsmodell som var mest lämplig för projektet var V-modellen. Genom att använda V-modellen togs det fram en bra struktur för hur arbetet skulle läggas upp gällande planering, verkställande och testning. Med en detaljerad planering underlättade det verkställandet genom att det fanns en tydlig bild av vad som skulle göras. Den noga planeringen gjorde att fel och brister i systemet vid testerna var få. En nyckelfaktor för utvecklingsprocessen var också att ha ett bra samarbete med FMV:s personal vilket gjorde att utvecklingen följde deras vision om systemet. När utvecklingsprocessen och arbetet med V-modellen var genomfört var också ett system för insamling av väderdata framtaget och godkänt av FMV. Systemet generar en minskad hantering av data eftersom det utför det arbete som tidigare har varit manuellt. Det generar också stabilare mätvärden eftersom tidpunkten för loggningen blir mer exakt än tidigare.

Under de senaste åren har produkterna blivit mer invecklade beträffande anslutningen, prestanda och funktionalitet. Därför är syftet av denna studie att undersöka hur komplexa system utvecklas och leds genom att genomföra fallstudie på olika svenska företag som utvecklar mekatroniska och cyber-fysiska system. Resultatet av denna studie har lett till identifieringen av många utmaningar som de undersökta företagen har och som i sin tur har lett till framställningen av ett analytiskt ramverk som diskuterar hur och vad man bör göra för att utveckla komplexa produkter på ett effektivt sätt, så att onödig komplexitet i produktutvecklingen kan reduceras. / In recent years, products have become more complex in terms of connectivity, performance and functionality. Therefore, this study aims at studying how complex products are developed and managed through conducting multiple case studies at different Swedish companies that develop mechatronic or cyberphysical systems. The results of this study is the identification of many challenges that the investigated companies have, which have led to a presentation of an analytical framework that discusses how complex product development projects can and should be managed in order to be efficient, in order to reduce unnecessary complexity in the way companies develop these complex products.

Test av informationssystem är en viktig del inom systemutvecklingsprocessen för att minimera felaktigheter och förbättra tillförlitligheten av system. Trafikverkets IT enhet hade ett fastställt och strukturerat testarbete för high-level test däremot hade de inte ett fastställt strukturerat testarbete inom low-level test. Vi fick i uppdrag att undersöka metoder och arbetssätt som fanns inom low-level test. Vi skulle också jämföra system som genomgått ett strukturerat testarbete inom low- och high-level test mot system som genomgått ostrukturerat low-level test och strukturerat high-level test. Målet med examensarbetet var att föreslå lämpliga metoder och arbetsätt inom low-level test för Trafikverkets IT enhet. Målet var också att ge en rekommendation ifall ett strukturerat testarbete inom low- och high-level var att rekommendera i jämförelse mot system som genomgått ostrukturerat low-level test och strukturerat high-level test. Genom litterära studier och intervjuer med Trafikverkets resurser genomförde vi vår undersökning och kom fram till vårt resultat.Vår rekommendation för Trafikverket IT var att de ska använda sig utav testdriven utveckling eftersom utvecklarna var osäkra på vad som skulle testas och metoden skulle klargöra detta. Dessutom ville de ha valmöjligheter och riktlinjer som skulle ge dem en mer bestämd arbetsstruktur. Vi rekommenderar också en anpassning av Self-Governance ramverket där aktiviteter väljs ut för varje projekt av en metodansvarig eller projektansvarig (Scrum Master) som bestämmer vilka aktiviteter som ska utföras på individ- och gruppnivå. / Testing of information systems is an essential part of the system development process to minimize errors and improve the reliability of systems. Trafikverket IT unit had a structured testing in the test phase high-level, however, they had not a structured testing in the development phase, low-level tests. We were assigned to examine methods and working methods in low-level test. We also would compare systems that had undergone a structuredtesting in low-and high-level test against systems that had undergone an unstructured low-leveltest and structured high-level test.The goal of the thesis was to propose appropriate method/methods in low-level test for Trafikverket IT unit. The goal was also to make a recommendation if a structured testing in low-and high-level were to be recommended in comparison with systems that had undergone unstructured low-level test and structured high-level test. Through literary studies and interviews with Trafikverket employees we reached our result. Our recommendation for Trafikverket IT is that they should use test-driven development because developers were unsure of what should be tested and the method would make thisclear. The developers also wanted to have options and guidelines that would give them a definite work structure. We also recommend an adaptation of the Self-Governance frameworkfrom where activities can be selected from each project manager (Scrum Master) that determines which activities will be performed in individual- and group level for each project.