Ett automatiskt verifieringssystem vid utvecklingen av inbyggda system
|
|
- Georg Danielsson
- för 6 år sedan
- Visningar:
Transkript
1 Ett automatiskt verifieringssystem vid utvecklingen av inbyggda system En länk mellan byggserver och testmiljö. HUVUDOMRÅDE: Datateknik FÖRFATTARE: Emanuelsson, Alexander & Karlsson, Filip HANDLEDARE: Tarasov, Vladimir JÖNKÖPING 2018 juni
2 Detta examensarbete är utfört vid Tekniska Högskolan i Jönköping inom datateknik, inbyggda system. Författarna svarar själva för framförda åsikter, slutsatser och resultat. Examinator: Håkan Sundell Handledare: Vladimir Tarasov Omfattning: 15 hp (grundnivå) Datum: Postadress: Besöksadress: Telefon: Box 1026 Gjuterigatan (vx) Jönköping
3 Abstract Automotive companies are increasingly investing in fast development processes and new advanced technology, resulting in less time being allocated to development that is more time consuming. The purpose of this thesis was to develop and evaluate an automatic verification system adapted for companies within the automotive industry with VT System as test environment and Jenkins as build server. Based on this purpose, three research questions were defined and then answered by first investigating which components an automatic verification system could contain. This was followed by the development of an automatic verification system and a corresponding architecture. Finally, the automatic verification system was evaluated through an experiment, with the purpose of investigating it s time efficiency. To achieve the purpose of this thesis the method Design Science Research was used. The results from the experiment shows that there is no significant difference in time efficiency between the automatic verification system and a manual approach of the same task. The thesis highlights other aspects of the automatic verification system in which it can contribute. The result of the work contributes to different knowledge areas such as automated testing and fully automated systems, it does this by presenting an architecture for an automatic verification system and by presenting the result from the above-mentioned experiment. Keywords: Automatic verification system, ECU, Testing, Components, Artefact i
4 Sammanfattning Företag inom fordonsindustrin sätter mer och mer press på snabba utvecklingsprocesser och ny avancerad teknik, vilket resulterar i att mindre tid allokeras åt utveckling som kräver mer och mer tid. Syftet med detta examensarbete var att ta fram, utveckla och utvärdera ett automatiskt verifieringssystem lämpat för ett företag inom fordonsindustrin med VT System som testmiljö och Jenkins som byggserver. Utifrån syftet definierades tre frågeställningar som besvarades genom att först undersöka vilka komponenter ett automatiskt verifieringssystem kan innehålla, för att sedan utveckla ett automatiskt verifieringssystem samt en tillhörande arkitektur. Slutligen utvärderades det automatiska verifieringssystemet genom ett experiment för att undersöka dess tidseffektivitet. För att uppnå detta syfte samt besvara examensarbetets frågeställningar valdes Design Science Research som metod för arbetet. Resultatet från experimentet visar på att det inte finns någon signifikant tidseffektivitetsskillnad mellan ett automatiskt verifieringssystem och ett manuellt utförande av samma uppgift. Examensarbetet belyser andra aspekter som det automatiska verifieringssystemet istället kan bidra med till verksamheten. Resultaten från arbetet bidrar till kunskapsområdena automatiska tester och helt autonoma system, detta genom att dels presentera en arkitektur för ett automatiskt verifieringssystem och dels genom resultat från tidigare nämnt experiment. Nyckelord: Automatiskt verifieringssystem, ECU, tester, komponenter, artefakt ii
5 Förkortningar SBW CAN LIN ECU DSR SUT AI ROI DSA Shift By Wire Controller Area Network Local Interconnect Network Electronic Control Unit Design Science Research System Under Test Artificial intelligence Return On Investment Diagnostic and Software Download Application iii
6 Innehållsförteckning Abstract... i Sammanfattning... ii Förkortningar... iii Innehållsförteckning... iv 1 Introduktion BAKGRUND PROBLEMBESKRIVNING SYFTE OCH FRÅGESTÄLLNINGAR OMFÅNG OCH AVGRÄNSNINGAR DISPOSITION Metod och genomförande KOPPLING MELLAN FRÅGESTÄLLNINGAR OCH METOD ARBETSPROCESSEN ANSATS DESIGN MJUKVARUUTVECKLINGSPROCESS DATAINSAMLING Förstudie Experiment DATAANALYS TROVÄRDIGHET Teoretiskt ramverk KOPPLING MELLAN FRÅGESTÄLLNINGAR OCH TEORI AUTOMATISKA TESTER AUTOMATISERINGSPROCESSEN AV MJUKVARUTESTER Testfall Testskripts Testdata Testutförande Testutvärdering Testresultatsrapportering... 8 iv
7 3.3.7 Testhantering och övriga testaktiviteter FÖRUTSÄTTNINGAR FÖR VIDARE AUTOMATISERING V-MODELLEN AGILA UTVECKLINGSMETODER EFFEKTIVITET KOPPLAT TILL AUTOMATISK TESTNING Maintainability Empiri FRÅGESTÄLLNING FRÅGESTÄLLNING FRÅGESTÄLLNING Analys FRÅGESTÄLLNING FRÅGESTÄLLNING FRÅGESTÄLLNING Diskussion och slutsatser RESULTAT IMPLIKATIONER BEGRÄNSNINGAR SLUTSATSER OCH REKOMMENDATIONER VIDARE FORSKNING Referenser v
8 1 Introduktion 1.1 Bakgrund Fordonsindustrin är en av de branscher som under de senare åren haft en explosionsartad utveckling. Företag sätter mer och mer press på snabba utvecklingsprocesser lik såväl att produkterna skall innehålla ny och avancerad teknik, med andra ord ges mindre tid åt utveckling som kräver mer och mer tid. Detta leder till ett kritiskt behov av verktyg och metoder som effektiviserar arbetet. Att automatisera delar av verksamheten har länge varit aktuellt inom de flesta branscher. Mer och mer fokus sätts på att byta ut människans arbetsuppgifter mot mer effektiva lösningar som i praktiken kan utföra arbetsuppgifter dygnet runt. Inom många organisationer som arbetar med mjukvaruutveckling har stort fokus hamnat på automatisering av testprocesser [1]. Att låta avancerad mjukvara testa och verifiera den kod som produceras i en verksamhet är ett effektivt sätt att få bort den mänskliga faktorn ur processen och att minska antalet fel i slutprodukten [2], [3]. Detta arbete är utfört på företaget Kongsberg Automotive AB i Mullsjö. Här bedrivs bland annat utvecklingen av växelspakar med Shift By Wire (SBW) teknologi. SBW växelspakar har ingen mekanisk konstruktion mellan växelspak och växellåda utan kommunicerar med hjälp av elektroniska signaler genom kablage. Kommunikationen mellan växelspak, växellåda och övriga delar av bilen sker genom något av kommunikationsprotokollen CAN eller LIN. Dessa växelspakar tillsammans med en mängd andra komponenter i dagens kommersiella fordon och personbilar innehåller en Electronic Control Unit (ECU). En ECU består av en mikroprocessor med tillhörande elektroniska komponenter, exempelvis sensorer av olika slag. Mjukvaran i dessa ECU:er är under hårda krav från såväl ISO-standarder samt kunder vilket leder till en stor mängd av tester och verifieringar. Utvecklingen av en ECU sker i stor utsträckning iterativt vilket kräver regelbunden testning av ny och befintlig funktionalitet genom varje iteration av utvecklingsprocessen. Detta för att verifiera att ny funktionalitet fungerar samt att försäkra sig om att äldre funktionalitet fortsätter fungera på senare versioner av mjukvaran. Att testa äldre funktionalitet manuellt är tidskrävande och ett återkommande steg i utvecklingsprocessen. Detta leder till det ovan nämnda behovet av ett verktyg som kan effektivisera denna del av utvecklingsprocessen, ett automatiskt verifieringssystem. 1.2 Problembeskrivning På Kongsberg Automotive AB finns en testmiljö, VT System, som är en produkt av företaget Vector AB. Systemet används bland annat för att kunna utföra automatiska tester på inbyggda system. Företaget använder sig även av en byggserver, Jenkins, som används för att bygga deras mjukvaruprojekt periodiskt eller på kommando. För att testa ny mjukvara som finns tillgänglig på Jenkins måste den i nuläget först laddas ner manuellt, för att sedan manuellt laddas in i aktuell ECU lokaliserad i testmiljön. En studie visar att automatisering av testprocesser inte bara leder till en högre effektivitet utan kan även leda till en högre kvalitet på mjukvaran [2]. Denna process vill företaget automatisera för att även kunna utföra tester nattetid helt utan mänsklig interaktion. Detta för att komplettera den dagliga verksamheten och för att kunna verifiera genom tester att redan implementerad funktionalitet inte har påverkats av nya funktioner i den senaste mjukvaran. Att även automatisera denna process under dagtid kan vara relevant för företaget om det visar sig vara mer effektivt. Med andra ord behöver ett automatiskt verifieringssystem skapas. Med ett automatiskt verifieringssystem menas 1
9 i detta examensarbete en länk mellan byggserver och testmiljö för att kunna bygga och testa mjukvara helt automatiskt. 1.3 Syfte och frågeställningar Följande arbete syftar till att ta fram, utveckla och utvärdera ett automatiskt verifieringssystem lämpat för ett företag inom fordonsindustrin med VT System som testmiljö och Jenkins som byggserver. För att kunna uppnå detta syfte har följande frågeställningar formulerats: Vilka mjukvaru- respektive hårdvarukomponenter kan ett automatiskt verifieringssystem lämpat för företag inom fordonsindustrin med aktuell testmiljö och byggserver innehålla? Hur kan arkitekturen samt uppbyggnaden för ett automatiskt verifieringssystem se ut, där valda hårdvaru- respektive mjukvarukomponenter kan appliceras? Vilka för- och nackdelar kan ett sådant automatiskt verifieringssystem föra med sig i termer av tidseffektivitet? 1.4 Omfång och avgränsningar Då examensarbetet utförs på och utgår ifrån ett specifikt företag med ett antal grundförutsättningar, som exempelvis byggserver och testmiljö, kommer inte alla olika möjliga lösningar att undersökas. Den lösning som lämpar sig bäst för det aktuella fallet kommer att användas. Detta betyder att resultatet nödvändigtvis inte återspeglar hela fordonsindustrin. 1.5 Disposition Resterande rapport utgörs av följande: Ett kapitel som beskriver den metod som används för att utföra examensarbetet. Detta kapitel följs upp av rapportens teoretiska ramverk. Vidare redovisas den empiri som samlats in under arbetets gång i empirikapitlet, för att sedan analyseras i analyskapitlet. Rapporten avslutas med slutsatser kring studien i diskussions- och slutsatskapitlet. 2
10 2 Metod och genomförande 2.1 Koppling mellan frågeställningar och metod För att uppnå examensarbetets syfte och besvara dess frågeställningar valdes Design Science Research (DSR) som metod. DSR metoden går ut på att skapa en artefakt för att sedan utvärdera dess effektivitet, vilket stämmer in på detta arbete. Den första frågeställningen besvaras genom en undersökning av vilka mjukvaru- respektive hårdvarukomponenter som det automatiska verifieringssystemet kan innehålla, samt vilka av dessa komponenter som lämpar sig bäst för den färdiga artefakten. Vidare besvaras den andra frågeställningen genom skapandet av artefakten, där de valda mjukvaru- respektive hårdvarukomponenterna kan appliceras. Avslutningsvis besvaras den sista frågeställningen genom ett experiment för att utvärdera artefaktens tidseffektivitet. 2.2 Arbetsprocessen De första stegen i arbetsprocessen, undersökning och litteraturöversikt, bygger på att skapa en förståelse för området, samla material för teorin och att identifiera artefaktens olika komponenter. Arbetet går sedan vidare genom utvecklingen av artefakten och en kontinuerlig uppbyggnad av teori. Sedan utvärderas artefakten och empiri samlas in. Det sista steget utgörs av en analys av insamlad empiri och slutsatser dragna från arbetet. Fig. 1. Studiens arbetsprocess. 2.3 Ansats I detta examensarbete har en kvantitativ ansats använts för att besvara dess frågeställningar och syfte. En kvantitativ ansats bygger på att kunna dra slutsatser från hårda fakta som exempelvis siffror, strukturerade empiriinsamlingar eller generaliseringar [4, s. 56]. En kvantitativ ansats innefattas av exempelvis enkätstudier, experiment eller statistiska metoder [4, s. 56]. Detta examensarbete använder sig av DSR för att skapa och utvärdera en artefakt. Utvärderingen görs genom ett experiment för att kunna dra slutsatser kring artefaktens tidseffektivitet. 2.4 Design DSR-metoden förhåller sig till ett antal riktlinjer [5]. Dessa riktlinjer kan sammanfattas på följande sätt: - DSR måste producera fram en artefakt i form av en konstruktion, metod, modell eller exemplifiering [5]. - Artefakten skall utvecklas för att lösa ett specifikt problem, detta problem måste vara relevant för aktuell bransch [5]. - Artefaktens effektivitet och kvalitet måste utvärderas genom strikta metoder, detta gäller även utvecklingen av artefakten [5]. - Bra DSR-forskning skall bidra med tydliga och verifierbara fakta inom relevant kunskapsområde [5]. 3
11 - Resultaten måste hålla en god kommunikationsnivå för att nå en bred publik [5]. Artefakten, eller det automatiska verifieringssystemet, utvecklades under examensarbetet med målet att kunna användas som en färdig produkt och tillämpas inom olika skarpa projekt på företaget. Artefakten designades med hänsyn till byggserver och testmiljö men även utifrån det praktiska behovet och insamlad teori. Länken mellan dessa komponenter byggdes upp med hjälp av flera kommunicerande skript. Artefakten utvärderas som tidigare nämnt genom ett experiment. Detta för att kunna dra slutsatser om ett eventuellt samband mellan användandet av artefakten och minskad tidskonsumtion. 2.5 Mjukvaruutvecklingsprocess Vid utvecklingen av artefakten användes en iterativ utvecklingsprocess. Varje arbetsdag började med att välja ut uppgifter för dagen och avslutades med en återkoppling över hur dagen hade gått. Under återkopplingen diskuterades även möjliga uppgifter inför nästkommande arbetsdag. Ett antal element från Scrum, en vanligt förekommande Agil utvecklingsmetod, applicerades på utvecklingsprocessen. Detta genom att arbetsdagarna började med ett snabbt möte för att stämma av vad som åstadkommits förra gången, vad planen var för dagen samt om några problem uppstått. Den webbaserade projekt-hanteringsapplikationen Trello användes för att definiera upp alla uppgifter inom projektet. Trello gör det möjligt att enkelt förflytta olika uppgifter, eller kort, till olika listor som exempelvis: Att göra, håller på att göra eller uppgifter som är klara. I samband med återkopplingen efter varje avslutad arbetsdag granskades Trello för att se hur dagen gått och för att även potentiellt förflytta uppgifter till nästkommande lista. Utöver detta utfördes kontinuerliga möten varannan vecka med handledare på företaget. Detta för att stämma av och få feedback på arbetet för att behålla önskad kvalitet på artefakten. 2.6 Datainsamling Förstudie Arbetet startades genom en förstudie som bestod dels av en litteraturöversikt för att hitta relevant teori för arbetet och dels en undersökning av vilka mjukvaru- respektive hårdvarukomponenter som lämpades för artefaktens uppbyggnad. Litteraturöversikten utfördes genom en identifiering av relevanta artiklar med fokus på testautomatisering på högskolans sökmotor för databaser, Primo. Relevansen bestämdes primärt av en översikt i rapportens abstract och vidare i rapportens resultat. Undersökningen av lämpliga mjukvaru- respektive hårdvarukomponenter baserades på estimerad implementeringstid för komponenten samt dess kompatibilitet till artefaktens helhet. Slutgiltiga val av mjukvaru- respektive hårdvarukomponenter för det automatiska verifieringssystemet baserades sedan på de erhållna fakta från beskriven undersökning, författarnas förkunskaper inom ämnet samt tillgänglighet på företaget Experiment Empiriska data som besvarar studiens kvarstående syfte erhålls genom ett experiment. Experiment är en vanligt förekommande metod för att svara på ett syfte som baseras på en hypotes (ett deduktivt upplägg) [4, s. 67]. I experimentet skapas en situation, typisk för aktuellt fenomen, där händelser studeras i samband med manipulation av situationen [4, s. 67]. I detta examensarbete syftade experimentet till att mäta 4
12 eventuella tidsskillnader mellan det automatiska verifieringssystemet och ett manuellt utförande av samma process. Processen utgörs av att ladda ner de genererade mjukvarufilerna från byggservern, ladda in mjukvaran på aktuell ECU, starta igång testmiljön och att utföra automatiska tester. Efter detta skall den mjukvara som befann sig på ECU innan testningen laddas in på nytt. Tiden det tog för fyra mjukvarutestare på företaget att utföra processen mätes upp med tidtagarur och jämfördes mot den tid som det automatiska verifieringssystemet behöver för att utföra samma process. Denna tid erhålls istället genom två tidsstämplar, start och stop, på den PC skripten befinner sig på. Starttidsstämpeln erhålls när hela processen startar och sluttidsstämpeln erhålls när hela processen är slut. Alltså användes en oberoende variabel, testningsmetod, som antingen är en testare eller det automatiska verifieringssystemet, för att dra slutsatser om den beroende variabeln, tid. 2.7 Dataanalys Insamlade empiriska data från experimentet analyseras genom ett T-test av typen Tvåsidigt prövning [6]. Data består av uppmätta tider för det manuella utförandet respektive det automatiska verifieringssystemet att utföra hela processen. Då själva testningen av ECU kan ta allt ifrån 5 sekunder till 5 timmar, beroende på antalet tester som ska utföras, elimineras denna tid ifrån sluttiden. T-testet används för att undersöka om det finns en signifikant tidsskillnad mellan ett automatiskt verifieringssystem och ett manuellt arbetsutförande. Detta genom att förkasta nollhypotesen H 0 : Ett manuellt utförande är lika snabbt som ett automatiskt verifieringssystem. s d = (d d)2 n 1 t df = d μ D S d n (1) (2) S d är stickprovets standardavvikelse [6] för tidsskillnaden mellan en testare och det automatiska verifieringssystemet. µ D antar värdet noll när en nollhypotesförkastning prövas. Det standardiserade t-värdet (t df) jämförs mot ett tabellvärde (kritiskt tabellvärde) för aktuellt T-test, baserat på antalet mätningar, för att ta reda på om nollhypotesen kan förkastas [6]. Nollhypotesen förkastas om det standardiserade t- värdet är större än det kritiska tabell-värdet, alternativt lägre än ett negativt kritiskt tabell-värde. För att kunna undersöka en eventuell tidsskillnad mellan de två olika utförandena, med hjälp av ett T-test, krävs i detta fall minst två stycken mjukvarutestare. Om istället fyra stycken används, som i detta arbete, blir det kritiska tabell-värdet nästan tre gånger mindre. Detta resulterar i att en eventuell tidsskillnad baseras på konsekventa skillnader istället för enstaka större skillnader. Fler än fyra mjukvarutestare hade givetvis sänkt det kritiska tabell-värdet ytterligare, men flera mjukvarutestare fanns inte tillgängliga och hade vidare inte sänkt det kritiska tabellvärdet avsevärt. 2.8 Trovärdighet Arbetets trovärdighet kan baseras på två begrepp: validitet och reliabilitet [7]. Validitet hanterar frågan om mätningar som utförs är relevanta för studien, mäts det som är avsett mätas? Reliabilitet beskriver studiens tillförlitlighet, om mätningar går till på ett tillförlitligt sätt och om resultatet är reproducerbart. Studien avser att med hjälp av DSR ta fram en artefakt, det automatiska verifieringssystemet, och att utvärdera dess effektivitet med hjälp av experimentet som beskrivs i avsnitt Experimentets resultat avser att på ett tydligt sätt redovisa eventuella tidsskillnader av att utföra ett antal väldefinierade uppgifter för artefakten, samt för en person, vilket stärker studiens validitet. 5
13 För att öka arbetets reliabilitet erhålls i avsnitt 4.2 en definition av artefaktens uppbyggnad och i avsnitt 2.4 beskrivs den vetenskapliga metod, DSR, som användes för att ta fram artefakten. En ytterligare faktor som stärker studiens reliabilitet är den väldefinierade beskrivningen av experimentet som utfördes för att undersöka artefaktens tidseffektivitet. Genom att använda fyra istället för två stycken mjukvarutestare till experimentet ökar studiens validitet. Studiens validitet hade ytterligare kunnat höjas med ett större antal mjukvarutestare, men fyra stycken ansågs tillräckligt för ett godtyckligt resultat. I rapporten används till stor del "peer-reviewed" artiklar, rapporter och dokument som referenser till teorikapitlet. Genom att använda expertgranskad litteratur ökar rapportens trovärdighet. 6
14 3 Teoretiskt ramverk 3.1 Koppling mellan frågeställningar och teori Då arbetet syftar till att ta fram, utveckla och utvärdera ett automatiskt verifieringssystem har teorier om framförallt testning lyfts fram i detta kapitel. Hur automatisering av testprocesser kan höja verksamhetens effektivitet och gynna utvecklingsmetoden är exempel på detta. Vidare behandlas teorier om effektivitet och tillhörande beräkningar. 3.2 Automatiska tester I dagens samhälle är det vanligt att projektledare och utvecklare av mjukvarusystem placeras under hård press. Att lansera en produkt tidigast möjliga tid på marknaden är av yttersta vikt för dess överlevnad, och därmed också för företaget [1]. Företag kräver att mer och mer arbete skall utföras på mindre tid samtidigt som företagen pressas till att reducera kostnaderna för processen [1]. Parallellt med att arbete skall utföras på mindre tid vill även företagen testa sin mjukvara mer frekvent. Av denna anledning väljer företag att vända sig mot automatiska tester [1]. Automatiska tester kan definieras enligt följande, The management and performance of test activities, to include the development and execution of test scripts so as to verify test requirements, using an automated test tool. [1]. Alltså att hantera testaktiviteter genom att utveckla och exekvera testskripts som körs i ett automatiskt testverktyg för att verifiera krav. 3.3 Automatiseringsprocessen av mjukvarutester Ett automatiskt testsystem kan byggas upp på flera olika sätt. Men det finns ett antal komponenter som är nödvändiga för ett automatiskt testsystem. [8] nämner bland annat testfall, testskripts och testdata som nödvändiga delar Testfall Enligt [9] definieras ett testfall på följande sätt: A set of test inputs, execution conditions, and expected results developed for a particular objective, such as to exercise a particular program path or to verify compliance with a specific requirement. Alltså innehåller ett testfall olika typer av för- och efterhands villkor, tillvägagångssätt för utförandet och ett förväntat resultat utifrån de krav som verifieras Testskripts Testskripts används för att automatisera de olika steg som behöver utföras i ett testfall. Skripten skrivs med hjälp av något skript- eller programmeringsspråk och kan användas tillsammans med ett testverktyg [8], [10]. Det finns ett flertal olika verktyg för att automatisera tester där XUnit, som är ett.net ramverk, är det vanligaste [10]. I dessa ramverk är det vanligt att använda skripts för att utföra testerna automatiskt [10] Testdata Testdata kan användas som parametrar till en funktion för att verifiera ett förväntat resultat, men kan även användas för att se hur systemet hanterar ogiltiga eller korrupta data. Testdata kan vara data från en testare, men det kan även vara data ifrån en funktion eller ett program som hjälper testaren [8]. Automatiseringsprocessen av mjukvarutester kan definieras upp i ett antal olika steg. Även [11] menar på att de första stegen i processen är att designa testfall samt att skapa testskript utifrån dessa. Men till skillnad från [8] nämner [11] att processen av att automatisera mjukvarutester innehåller ytterligare några steg som beskrivs i avsnitt till och med
15 3.3.4 Testutförande Testutförandet utgörs av att de testfall som skapats exekveras och resultatet eller beteendet noteras från System Under Test (SUT). Utförandet kan se olika ut beroende på tillvägagångsättet i tidigare steg. Om testfallen valdes att skapas som automatiska kommer utförandeprocessen vara helt automatisk [11] Testutvärdering Det finns olika sätt att utvärdera resultatet från utförandet. Enligt [11] finns det vanligtvis tre olika tillvägagångssätt. En mer manuell inställning till utvärderingen är att låta en person tolka resultatet. Men för en mer automatiserad process av utvärderingen kan hårdkodad testbedömning genom verifieringspunkter i koden tillämpas. Det tredje alternativet av testutvärdering är att utvecklarna skapar intelligenta test Oracles för att utföra och validera SUT, detta genom att använda maskininlärning och AI Testresultatsrapportering Testresultat skickas till utvecklarna där alla potentiella fel punkteras upp. Denna aktivitet kan antingen vara manuell eller automatisk. Exempelvis är NBug.NET library ett program som automatiskt genererar och skickar buggrapporter, kraschrapporter samt felbedömningsrapporter [11] Testhantering och övriga testaktiviteter Övriga aktiviteter som förknippas med automatiska tester kan exempelvis vara underhållet av tester. Om tester blir oanvändbara i samband med att SUT ändras, behöver de aktuella automatiska testerna uppdateras [11]. 3.4 Förutsättningar för vidare automatisering När ett automatiskt testsystem skall vidare automatiseras och utvecklas, som exempelvis ett automatiskt verifieringssystem, menar [12] att befintliga verktyg bör, om möjligt, användas. Genom att återanvända redan befintliga delar av systemet minskar insatsen som krävs för att utföra arbetet [12]. 3.5 V-modellen Inom mjukvaruutveckling finns flertalet olika metoder för att underlätta utvecklingsprocessen. V-modellen, eller Verification and Validation model, är en väletablerad och använd metod inom mjukvaruutveckling. V-modellen delar upp utvecklingsprocessen i olika steg, se Fig. 2, där de första stegen syftar till att definiera och designa mjukvaran utifrån krav och koncept. Efter detta påbörjas implementationen av mjukvaran. Sedan utförs integrering, verifiering och testning av mjukvaran utifrån de krav som ställts på produkten [10]. Fig. 2. V-Modellen [13]. 8
16 Mjukvaran testas iterativt genom varje utvecklingsnivå, där dess funktionalitet testas på följande sätt: - Enhetstestning, där små separata delar av mjukvaran testas. - Integrationstestning, där integrationen av enheter testas. - Systemtestning, där den färdigintegrerade produktens funktionalitet testas. Systemtestning utförs även tillsammans med de två resterande testnivåerna, användaracceptans och releasetestning, där systemet testas utifrån slutkundens acceptans [10]. 3.6 Agila Utvecklingsmetoder Att använda en agil utvecklingsmetod är något som [14] anser vara en fördel när det kommer till att minska utvecklingstiden för ett projekt. Konceptet att bryta ner allt arbete är ett välkänt begrepp inom agil mjukvaruutveckling. Genom att dels bryta ner arbetet och att dels använda en anpassningsbar planering, erhålls en iterativ utvecklingsprocess som gör det möjligt att leverera lösningar tidigt och kontinuerligt till kund [14]. Det finns ett antal olika agila utvecklingsmetoder som exempelvis Scrum, Extreme Programming (XP) och Feature-Driven Development (FDD) [15]. Även fast dessa agila utvecklingsmetoder har mycket gemensamt, fokuserar metoderna på olika saker. Scrum är främst en projektledningsmetod till skillnad från XP som framförallt fokuserar på mjukvaruutvecklingen [15]. På grund av metodernas olika grundkoncept används ibland motsägelsefulla agila tekniker. Till exempel använder sig XP av ett gemensamt ägarskap av koden, medan FDD istället föreskriver att varje kodkomponent har en definierad ensamägare [15]. Ett agilt utvecklingsteam baseras på att individer har olika kompetenser inom bland annat programmering, design, databasarkitektur samt administration, analys, systemingenjörskap och projekthantering [15]. Detta skiljer sig från till exempel den äldre utvecklingsmetoden, vattenfallsmodellen, där utvecklingsteam ofta specialiserar sig inom ett specifikt område som exempelvis analys, design, utveckling eller testning, beroende på funktion [16]. Mjukvarutestning är en viktig del, om inte den viktigaste, inom agil mjukvaruutveckling [17]. Agil utveckling kräver att tester utförs mycket tidigt i projektet och att även automatiserade tester skapas [17]. Tanken med att utföra tester i ett tidigt stadie och kontinuerligt genom projektet är för att få en iterativ återkoppling. [14] menar på att automatiska tester bidrar till en direkt återkoppling till utvecklarna i form av resultat från testerna, godkända eller icke-godkända. Denna återkoppling är väldigt viktig när det kommer till den fortsatta utvecklingen av produkten. 3.7 Effektivitet kopplat till automatisk testning Att effektivisera verksamheten är en ständig kamp som alla företag driver. Inom mjukvaruutveckling är testautomatisering en stor del av denna process. Att testa mjukvara är en stor del av utvecklingsprocessen och kan stå för upp till mer än 50% av projektets tids- och kostnadskonsumtion vilket tas upp i [10], [18], [19], [17], [20], [21]. Detta innebär att kostnaden för att testa en mjukvara kan bli dyrare än att utvecklad den. Stora summor av pengar spenderas alltså på testningsdelen av utvecklingsprocessen. När bristfällig testning sker går företagen med stora förluster. Enligt [19] finns det rapporter som pekar på att företag som jobbar inom mjukvaruutveckling enbart i USA förlorar sammanlagt 22.2 miljarder dollar per år. 9
17 Detta på grund av bristfällig testning som även [19] menar hade kunnat förhindras genom satsningar på exempelvis testautomation. När företag går från ett manuellt testande till ett automatiskt försvinner bland annat den mänskliga faktorn ur testerna som enligt [2] och [3] leder till minskade testluckor och felbedömningar. Resultaten från [18] pekar även på att defekter hittas i större utsträckning och att utvecklingstiden blir kortare med hjälp av automatiska tester. Enligt [2] där automatiska tester implementerades vid utvecklingen av 3 olika mjukvaror blev utfallen positiva mätt i tids- och kostnadsaspekter för samtliga fall. Även Return On Investment (ROI), att investeringen lönat sig, uppnåddes för alla mjukvaror. Vidare uppnådde även majoriteten av fallen en högre kvalitet på sin mjukvara, där bland annat ett minskat Maintainability-värde kunde uppnås Maintainability Maintainability, eller underhållsmässighet är den tid och insats som krävs för att i en operativ mjukvara analysera och identifiera ett fel, fixa detta fel och sedan testa mjukvaran igen [2]. Underhållsmässighet mäts genom: Maintainability = time spent on testing total development time (3) Genom att implementera automatiska tester kunde företagen i [2] sänka sitt Maintainability-värde. Detta genom effektivare testning som resulterade i en mindre tidskonsumtion. Även om forskning pekar på att automatiska tester har positiva effekter för verksamheten kvarstår faktumet att manuella tester fortfarande används i större utsträckning än automatiska. Enligt [19] använder bara 26 % av företagen i studien automatiska tester. [19] menar att detta beror på att implementeringen av automatiska testsystem är mycket krävande, både design- och underhållsmässigt, vilket skapar stora trösklar för företagen att ta sig förbi. 10
18 4 Empiri 4.1 Frågeställning 1 För att besvara på examensarbetets första frågeställning undersöktes olika komponenter som kunde användas i det automatiska verifieringssystemet. I Tabell 1 visas alla de olika komponenter som undersöktes som eventuella komponenter till det automatiska verifieringssystemet. Vidare visas i Tabell 2 de komponenter som lämpades bäst utifrån estimerad implementeringstid, kompatibilitet, erfarenhet och tillgänglighet på företaget och som även användes till den färdiga artefakten. Tabell 1. Komponenter undersökta till det automatiska verifieringssystemet. Hårdvarukomponenter PC VN1630A VT System Microcontroller RaspberryPi Arduino Information om nyintroducerade komponenter: Mjukvarukomponenter CANoe DSA Python Jenkins vflash C/C++ - DSA och vflash är program som bland annat används för att programmera ner mjukvara på en ECU. - VN1630A är ett CAN-nätverksinterface som bland annat används för att möjliggöra kommunikation mellan DSA och ECU via CAN. - CANoe är ett program som bland annat används för att simulera, analysera och testa en ECU. CANoe används också för att styra VT System. - Arduino och Microcontroller är två olika sorters mikroprocessorer. - Raspberry Pi är en enkel PC med tillhörande Linuxoperativsystem. Tabell 2. Komponenterna i det färdiga automatiska verifieringssystemet. Hårdvarukomponenter PC VN1630A VT System Mjukvarukomponenter CANoe DSA Python Jenkins 4.2 Frågeställning 2 För att besvara på examensarbetets andra frågeställning designades och utvecklades ett automatiskt verifieringssystem samt en tillhörande arkitektur. Fig. 3 visar en översiktlig bild av det automatiska verifieringssystemets lagerarkitektur. Fig. 3. lagerarkitekturen för det automatiska verifieringssystemet. 11
19 Det understa lagret, grundlagret, utgörs av de två kritiska byggstenar som examensarbetet är uppbyggt av, byggserver och testmiljö. Detta följs upp av kommunikationslagret, där CAN och skript är de fundamentala delarna för att kunna kommunicera mellan artefaktens olika delar. Användare av artefakten kan även få feedback och ändra inställningar i artefaktens funktionalitet i detta lager. Detta genom en konfigurationsfil, testrapport samt logg. Det sista lagret, funktionalitetslagret, utgörs av de väsentliga funktioner artefakten behöver, som att hämta mjukvara, ladda ECU med mjukvara och att testa mjukvara. Fig. 4 visar hur hårdvarukomponenterna är sammankopplade i det färdiga systemet och Fig. 5 visar det automatiska verifieringssystemets flödesschema. Det automatiska verifieringssystemets funktionalitet är uppbyggt av flertalet kommunicerande Pythonskript. Fig. 4. Hårdvarukoppling för det automatiska verifieringssystemet Fig. 5. Flödesschema för det automatiska verifieringssystemet. 12
20 Artefaktens funktionalitet beskrivs nedan och kan även visualiseras genom Fig. 5. Vid ett definierat periodiskt klockslag börjar Jenkins bygga mjukvarufiler baserade på aktuellt mjukvaruprojekt. Detta periodiska klockslag är även definierat på en labbdator där ett antal Pythonskript befinner sig. På denna dator startas istället en socketserver vars uppgift är att lyssna efter de mjukvarufiler som genererats på Jenkins. Detta görs möjligt genom ett Pythonskript som befinner sig på Jenkinsservern som har i uppgift att ansluta sig till socketservern och skicka över mjukvarufilerna efter färdigt bygge. När filerna har överförts till labbdatorn startar nästa skript. Detta skript öppnar programmet CANoe som startar VT systemet i ett passivt läge. VT Systemets passiva läge används för att programmera aktuell ECU och det aktiva läget används för att testa ECU. När detta steg är färdigt öppnar skriptet DSA, programmet som används för att programmera ner mjukvarufilerna på ECU. Här konfigurerar skriptet DSA för att göra programmeringen möjlig. Skriptet importerar till DSA de filer som laddats ner från Jenkins för att sedan programmera ner mjukvarufilerna till ECU. ECU programmeras med hjälp av VN1630A som möjliggör kommunikation via CAN, se Fig. 4, på detta sätt skickas mjukvarufilerna över till ECU. Efter detta steg går skriptet tillbaka till CANoe för att istället sätta VT systemet i det aktiva läget. När detta är gjort startas de tester som skall utföras. Testerna är skrivna i ett plugin-program, vteststudio. Dessa tester är utvecklade sen tidigare och användare kan välja och ändra vilka tester som det automatiska verifieringssystemet skall utföra under natten. Detta genom att välja tester i en lista och sedan spara konfigurationen av CANoe som det automatiska verifieringssystemet använder. När testerna är klara öppnas DSA på nytt och samma programmeringsprocedur upprepas med skillnaden att mjukvarufilerna som programmeras ner på ECU istället utgörs av officiell mjukvara för aktuell sprint på företaget. När detta steg är klart stänger skriptet ner alla program och två Pythonskript genererar en logg respektive en testrapport. 4.3 Frågeställning 3 För att besvara på examensarbetets sista frågeställning utvärderades det automatiska verifieringssystemet genom tidigare beskrivet experiment. Empiri från detta experiment redovisas nedanför. I Tabell 3 redovisas de tider som mättes upp för det automatiska verifieringssystemet respektive tiderna för fyra olika mjukvarutestare att utföra testproceduren mellan Jenkins och VT System. Tabell 3. Uppmätta tider i sekunder för de två olika testutförandena. Manuellt utförande, unika testare Automatiskt verifieringssystem (x 2) (x 1) 363 s 316 s 278 s 314 s 400 s 313 s 282 s 314 s 13
21 5 Analys 5.1 Frågeställning 1 För att besvara på den första frågeställningen gjordes som nämnt tidigare en undersökning av vilka hårdvaru- respektive mjukvarukomponenter det automatiska verifieringssystemet kunde innehålla. Tabell 1 visar alla undersöka komponenter och Tabell 2 visar de slutgiltiga komponenterna i det automatiska verifieringssystemet. Nedanför kommer en motivering till varför de slutgiltiga komponenterna valdes till artefakten: DSA och vflash är program som används för att programmera ner mjukvarufiler på en ECU. Dessa program var båda möjliga komponenter till den slutgiltiga artefakten. Fördelen med DSA var att stor kunskap om programmet fanns hos både anställda på företaget respektive författarna vilket även [12] menar skall utnyttjas om möjligt. En stor nackdel med DSA är att programmet inte är helt kompatibelt med VT System vilket leder till att en VN1630A behöver användas för att kunna uppnå programmering av ECU. Fördelen med vflash är att programmet, precis som VT System, är en produkt av företaget Vector. Detta leder till att vflash är mer kompatibelt med VT System än DSA och att en VN1630A inte är nödvändig för att uppnå programmering av ECU. Nackdelen med vflash var istället att väldigt lite kunskap fanns tillgänglig på företaget om programmet och att även otillräcklig information fanns att hitta på internet om programmet. Vidare hade även kontakt med företaget Vector krävts för att kunna utforma en mall för mjukvaruprogrammeringen för aktuell ECU. DSA valdes över vflash även om vflash antagligen hade varit en mer optimal komponent till artefakten från ett färdigt produktperspektiv. Men vägen till en fungerande artefakt skulle blivit längre än de tidsramar exjobbet innefattade, vilket gjorde DSA till det bättre valet. Att använda Pythonskript för att automatisera artefakten kan antas vara till en stor fördel då mängder av bibliotek finns tillgängliga för skriptspråket. I och med dessa bibliotek möjliggjordes många olika lösningar till examensarbetets problematik, vilket gjorde Python till ett bra val. Uppbyggnaden av Pythonskripten resulterade även i en fördel i avseendet att vidare generalisera det automatiska verifieringssystemet. Detta då artefaktens grundfunktioner ej är bundna till specifika komponenter, vilket gör det enklare att underhålla och vidareutveckla systemet om företaget vill använda andra program och verktyg. Detta är inte bara till en fördel för det aktuella företaget utan även för andra organisationer som vill vidare automatisera sin verksamhet på ett likartat sätt. Vidare övervägdes även tidigt i examensarbetet en Raspberry Pi som komplement till PC i form av hämtning av mjukvarufiler och programmering av ECU. Detta skulle eventuellt kunna leda till en mer effektiv artefakt då PC och Raspberry Pi i vissa stadier av processen kunnat arbeta parallellt. Men artefakten hade blivit beroende av fler komponenter och därför inte fått en lika kompakt arkitektur. Vidare hade även ett ytterligare sätt att programmera ECU behövt undersökas för denna lösning, då varken DSA eller vflash fungerar med Raspberry Pi. Detta ledde till att denna lösning valdes bort och resulterade även i en mer effektiv utveckling av artefakten. Att använda en Arduino eller Microcontroller med tillhörande C/C++-kod för att testa ECU i VT Systemet undersöktes också. Detta för att inte störa skarpa pågående projekt i testmiljön. Denna lösning hade varit mer aktuell om ändamålet var att få fram en prototyp av artefakten. Tillgången till en Arduino eller Microcontroller hade varit obegränsad under examensarbetets gång. VT Systemet använder företaget däremot i ett antal olika skarpa projekt och var därför bara tillgängligt för examensarbetet ett antal timmar per vecka. Detta ansågs i slutändan ändå vara tillräckligt för att få fram en fungerande artefakt och lösningen valdes bort. Lösningen hade bland annat blivit 14
22 mer primitiv då ändringar av de tester som utförs på ECU hade behövt justeras direkt i C/C++-koden. 5.2 Frågeställning 2 För att besvara på den andra frågeställningen analyseras i detta avsnitt det automatiska verifieringssystemets arkitektur: Alla beståndsdelar i lagerarkitekturen, som visas i Fig. 3, ansågs vara nödvändiga för en välfungerande artefakt av författarna. Funktionalitetsmässigt hade artefakten fungerat utan konfigurationsfil, testrapport samt logg, men dessa möjligheter ansågs viktiga av såväl företaget som av författarna. Båda parter menade på att dessa funktionaliteter kan underlätta både användning och uppehåll av artefakten. Även [11] menar på att testrapporter är en väsentlig del av automatisk testning. Att vidare använda Python som skriptspråk ansågs fördelaktigt av författarna för att bygga upp det automatiska verifieringssystemets funktionalitet, men utesluter inte andra lösningar. Funktionaliteten kan sannolikt byggas upp med exempelvis Java, Ruby, C++ eller Unix Shell scripts istället, för att passa den enskilda verksamheten bäst. Att även använda Pythonskript på byggservern har i detta examensarbete möjliggjort vidare generalisering av det automatiska verifieringssystemet. Eftersom Pythonskriptet inte är hårdkopplat till Jenkins blir det möjligt att använda skriptet på en annan byggserver med endast små modifikationer. Genom denna generalisering antas andra byggservrar kunna användas som exempelvis Travis CI, GitLab eller Microsoft Azure. Att även de funktioner som byggts upp av Pythonskripten är skapade med hänsyn till eventuella förändringar av komponenter, som exempelvis testmiljö eller byggserver, blir ersättningar enkla och artefakten blir mer generaliserbar. Testfall och testdata är viktiga delar av automatisk testning, vilket även [8] och [11] belyser, [11] tar även upp vikten av själva testutförandet. I det automatiska verifieringssystemet styrs alla dessa delar av testmiljön. Detta bidrar till att artefakten dels blir mer anpassningsbar till förändring och dels enklare att använda, då ändringar inte behöver implementeras direkt i Pythonskripten. Istället implementeras ändringar i testmiljöns konfiguration, vilket inte påverkar resterande delar av artefakten. 5.3 Frågeställning 3 För att besvara på den sista frågeställningen analyseras i detta avsnitt den empiri som erhållits genom experimentet. Då experimentet syftade till att undersöka en eventuell tidseffektivitetsskillnad mellan det automatiska verifieringssystemet och ett manuellt utförande formulerades nollhypotesen H 0 : Ett manuellt utförande är lika snabbt som ett automatiskt verifieringssystem. Genom att förkasta eller inte förkasta nollhypotesen kan en slutsats gällande tidseffektiviteten hos det automatiska verifieringssystemet dras. Tabell 4. Uppmätta tider i sekunder, minus testningen av ECU, för de två olika testutförandena samt differensen mellan dessa. Manuellt utförande, unika testare (x 1 ) Automatiskt verifieringssystem (x 2 ) d = x 1 x s 277 s 47 s 239 s 275 s -36 s 361 s 274 s 87 s 243 s 275 s -32 s 15
23 Att testa ECU mättes upp till 39 sekunder och eliminerades från den totala tiden, detta för att få en korrekt bild av utförandets tidseffektivitet. Exempelvis hade en testtid på en timme gjort skillnaderna mellan de två olika utförandena obefintliga. Medelvärdet av differensen, differensens standardavvikelse samt standardisering av t- värde: d = d = 16,5 s (4) n s d = (d d)2 n 1 t df = d μ D s d n 60,6 s (5), där df = n 1 t 3 0,54 (6) Det kritiska t-värdet för df = 3 och ett p-värde på 5 % är 0,05t 3 = 2,353. Nollhypotesförkastning om: t 3 > 0,05t 3 eller t 3 < 0,05t 3. t 3 > 0,05t 3 : Det automatiska verifieringssystemet är signifikant mer tidseffektivt. t 3 < 0,05t 3 : Det automatiska verifieringssystemet är signifikant mindre tidseffektivt. För att kunna förkasta nollhypotesen och dra slutsatsen att det automatiska verifieringssystemet är signifikant mer tidseffektivt än ett manuellt utförande, med ett p-värde på 5%, behöver det standardiserade t-värdet (t 3 ) överstiga det kritiska t-värdet ( 0.05t 3). Det standardiserade t-värdet hade ett positivt men klart mindre värde än det kritiska t-värdet. Detta betyder att nollhypotesen ej kan förkastas och att det automatiska verifieringssystemet inte är signifikant mer tidseffektivt. De insamlade tiderna pekar eventuellt på att det automatiska verifieringssystemet kan vara till en viss del mer tidseffektivt, då medeldifferensen är +16,5 sekunder och att även det standardiserade t-värdet är positivt. Det automatiska verifieringssystemet håller även en mer jämn tidskonsumtion till skillnad från de olika mjukvarutestarna på företaget, vilket tyder på mer stabilitet. Att även mjukvarutestarna eventuellt utförde testproceduren snabbare än vanligt kan ge en viss felmarginal till experimentet. Detta då personer kan tendera till att utföra en uppgift mer effektivt under uppsyn och tidtagning. En annan felmarginalsfaktor kan vara att de olika mjukvarutestarna har olika erfarenheter gällande testproceduren, vilken kan påverka resultatet i båda riktningar. Även om det automatiska verifieringssystemet inte är signifikant mer tidseffektivt kan artefakten positivt bidra till verksamheten genom andra aspekter. Genom att med hjälp av artefakten komplettera verksamhetens dagliga testarbete med testning under kvällstid möjliggörs konsekvent iterativ och mer utförlig testning, vilket är en viktig del av agil utveckling [14]. Artefakten kan även leda till kostnadsbesparingar för verksamheten. Detta genom att möjliggöra konsekvent testning av äldre funktionalitet på ny mjukvara för att säkerställa att inte nya implementeringar skadar äldre, samt att defekter hittas snabbare och i större utsträckning [18]. Eventuellt kan även artefakten bidra till att verksamheten sänker sitt maintainability-värde genom en större andel automatiska tester [2]. Att även artefakten inte behöver någon lön för att utföra testprocessen möjliggör besparingar för verksamheten. Det automatiska verifieringssystemet tar även bort den mänskliga faktorn ur testprocessen, vilket enligt [2], [3] kan minska antalet testluckor och felbedömningar, vilket i sin tur leder till en mer säkerställd produkt. 16
24 6 Diskussion och slutsatser 6.1 Resultat Genom detta examensarbete har dels lämpliga komponenter sammanfogats till ett enat system och dels har en arkitektur skapats för ett automatiskt verifieringssystem, lämpat för fordonsindustrin. Vidare har data samlats in och analyserats med slutsatsen att det automatiska verifieringssystemet inte är signifikant mer tidseffektivt än ett manuellt utförande av samma process. Genom detta anser författarna att de tre frågeställningarna besvarats och att även examensarbetets syfte uppnåtts. Vidare kan det automatiska verifieringssystemet istället tillföra andra positiva aspekter till verksamheten som exempelvis en större testtäckning, eliminera den mänskliga faktorn, kostnadsreduceringar och att underlätta iterativ testning. Det automatiska verifieringssystemet kan även antas vara mer optimerat för en agil utvecklingsmetod som exempelvis Scrum, XP eller FDD. Detta genom att enkelt möjliggöra iterativ testning, som är en kritisk del av dessa metoder. Att även testning påbörjas mycket tidigt i agila projekt möjliggör att även tidigt använda det automatiska verifieringssystemet, vilket anses fördelaktigt. Det automatiska verifieringssystemet kan även användas tillsammans med en utvecklingsmetod som exempelvis V-modellen på ett likartat sätt. Artefakten och dess arkitektur kan även antas fungera för andra verksamheter inom fordonsindustrin och kanske även inom andra branscher, med ett fåtal modifikationer. Detta genom att en generell arkitektur tagits fram och att även komponenter som exempelvis byggserver och testmiljö teoretiskt sett kan bytas ut. 6.2 Implikationer Detta examensarbete bidrar till att utöka kunskapsområdet som berör automatiska tester och helt autonoma system. Detta genom att presentera en arkitektur för ett automatiskt verifieringssystem och att även belysa att inga signifikanta tidseffektivitetsskillnader kan förväntas i samband med implementationen av ett sådant system. Examensarbetet påpekar utöver detta att verksamheter istället kan erhålla andra positiva konsekvenser av ett automatiskt verifieringssystem. 6.3 Begränsningar Examensarbetet har utförts under en begränsad tid vilket ledde till att inte alla olika lösningar på artefaktens uppbyggnad undersöktes. Detta ledde även till att komponenter med låg implementeringstid värderades högst, då det annars hade varit svårt att få fram en fungerande artefakt inom examensarbetets tidsramar. Även att inte alla undersökta komponenter testades till artefakten blir en begränsning, då andra komponenter hade kunnat resultera i en eventuell tidseffektivitetsskillnad. Vidare har inte lönsamheten av ett automatiskt verifieringssystem undersökts, vilket hade gett viktig information gällande om det är lönsamt för ett företag att investera i ett automatiskt verifieringssystem eller inte. Även detta berodde på examensarbetets tidsramar. 6.4 Slutsatser och rekommendationer I detta examensarbete undersöktes först vilka hårdvaru- respektive mjukvarukomponenter ett automatiskt verifieringssystem, lämpat för fordonsindustrin, kan innehålla. Efter detta utvecklades ett automatiskt verifieringssystem utifrån ett antal av de undersökta komponenterna samt en tillhörande arkitektur för det automatiska verifieringssystemet. Det färdiga automatiska verifieringssystemet utvärderades sedan genom ett experiment för att undersöka om det fanns en signifikant tidsskillnad mellan det automatiska verifieringssystemet och ett manuellt utförande av samma testprocess. Resultaten från experimentet tyder på att det inte finns någon signifikant tidsskillnad mellan 17
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
Testplanering, test-first, testverktyg
Testplanering, test-first, testverktyg Mats Skoglund Department of Computer and Systems Sciences Stockholm University/Royal Institute of Technology Stockholm, Sweden 12 mars 2007 Mats Skoglund Page 1(33)
Linköpings universitet 1 TDP029. Systemutveckling. Systemutveckling. Vanliga faser. Fler faser. Systemutvecklingsmetod
Systemutveckling TDP029 Systemutveckling Annika Silvervarg COIN/HCCS/IDA Systemutveckling kallas processen att ta emot en beställning på ett datorsystem, skriva en strukturerad kravspecifikation på systemet,
V!cto. Att tjäna pengar genom bättre testning med
Att tjäna pengar genom testning med Att tjäna pengar genom testning med 1 (50) Det finns tre vägar till test: 1: Testautomati- Att bygga sering Att bygga Att bygga Att bygga Att bygga Att bygga Att bygga
Automatiserade testsystem
Automatiserade testsystem Fredrik Edling, Tekn. Dr. Enea Services Stockholm fredrik.edling@enea.com Min bakgrund 2000: Civilingenjör teknisk fysik, inriktning mot tillämpad fysik 2004: Teknisk doktor,
Visuell GUI Testning
Visuell GUI Testning Vad är ett Graphical User Interface (GUI)? Icke-animerat GUI Animerat GUI Nuläget System- och acceptanstestning är dyrt! Manuellt Långsamt Enformigt Svårt att replikera exakt Nödvändigt
Några grundläggande begrepp
Några grundläggande begrepp Validering bygger vi rätt system? Uppfyller kravspecifikationen de verkliga behoven? Verifiering bygger vi systemet rätt? Uppfyller det färdiga systemet kravspecifikationen?
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
Testdriven utveckling. Magnus Jonsson Siemens Medical Solutions
Testdriven utveckling Magnus Jonsson Siemens Medical Solutions 2 Soarian Stort projekt, ca 400 personer i projektet Distribuerad utveckling i USA, Indien och Sverige Web baserat lösning med admin client
CREATING VALUE BY SHARING KNOWLEDGE
CREATING VALUE BY SHARING KNOWLEDGE PROJEKTLEDNING 101 Nidzara Dellien, Lund September 2017 PROJEKT En formell definition på projekt är följande (enligt Wikipedia): En temporär satsning för att framställa
Användarcentrerad systemdesign
Användarcentrerad systemdesign Föreläsning 11: Agile-processer och ACSD Stefan Blomkvist Avdelningen för MDI/IT, Uppsala Universitet, Stefan.Blomkvist@hci.uu.se www.it.uu.se/edu/course /homepage/acsd/
Syns du, finns du? Examensarbete 15 hp kandidatnivå Medie- och kommunikationsvetenskap
Examensarbete 15 hp kandidatnivå Medie- och kommunikationsvetenskap Syns du, finns du? - En studie över användningen av SEO, PPC och sociala medier som strategiska kommunikationsverktyg i svenska företag
Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1
Algoritmer Lars Larsson VT 2007 Lars Larsson Algoritmer 1 1 2 3 4 5 Lars Larsson Algoritmer 2 Ni som går denna kurs är framtidens projektledare inom mjukvaruutveckling. Som ledare måste ni göra svåra beslut
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
Ökat personligt engagemang En studie om coachande förhållningssätt
Lärarutbildningen Fakulteten för lärande och samhälle Individ och samhälle Uppsats 7,5 högskolepoäng Ökat personligt engagemang En studie om coachande förhållningssätt Increased personal involvement A
Regressionstestning teori och praktik
Regressionstestning teori och praktik Lic. Emelie Engström emelie.engstrom@cs.lth.se Software Engineering Research Group LUND UNIVERSITY Sweden SWELL the Swedish Research School in Software Verification
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
Oppositionsprotokoll-DD143x
Oppositionsprotokoll-DD143x Datum: 2011-04-26 Rapportförfattare Sara Sjödin Rapportens titel En jämförelse av två webbsidor ur ett MDI perspektiv Opponent Sebastian Remnerud Var det lätt att förstå vad
Testplan Cykelgarage
Testplan Cykelgarage Stefan Johansson D08 (dt08sj7@student.lth.se) Johan Anderholm D08 (dt08ja5@student.lth.se) Angelica Gabasio D08 (dt08ag8@student.lth.se) Marcus Carlberg D08 (dt08mc4@student.lth.se)
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
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
Continuous Integration med Jenkins. Linus Tolke Enea Experts
Continuous Integration med Jenkins Linus Tolke Enea Experts Föredraget Grunderna i mjukvaru-cm Trender inom mjukvaruutveckling Continuous Integration Vad är Jenkins Demo Jenkins i ArgoUML-projektet Problem
Agil programutveckling
Agil programutveckling Pontus Evertsson D00, Lunds Tekniska Högskola d00pe@efd.lth.se Anna Jennerheim D00, Lunds Tekniska Högskola d00aj@efd.lth.se 2003-05-15 1 1. Inledning 3 2. Extreme Programming (XP)
Linköpings universitet 1
Vanliga faser TDP029 Systemutveckling Annika Silvervarg COIN/HCCS/IDA Analys Vad är problemet? Uppgift Vad är det för arbetsuppgifter och hur utförs de? Användarbehov Vad behöver användaren/användarna?
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
Version 1.0. 2013-02-13 Testteam 4 Testledare: Patrik Bäck
Version 1.0-2013-02-13 Testteam 4 Testledare: Patrik Bäck 0 Sammanfattning Testplanen är utarbetad som ett svar på Konsumentverkets förfrågningsunderlag avseende upphandling av ett nytt budget- och skuldsaneringssystem,
Datavetenskapligt program, 180 högskolepoäng
GÖTEBORGS UNIVERSITET UTBILDNINGSPLAN IT-fakultetsstyrelsen 2013-02-14 Datavetenskapligt program, 180 högskolepoäng (Computer Science, Bachelor s Programme, 180 credits) Grundnivå/First level 1. Fastställande
Carl-Fredrik Lindberg, ABB Corporate Research. Automation Scandinavia, Trådlös kommunikation i industrin - ett PiiA-projekt
Carl-Fredrik Lindberg, ABB Corporate Research. Automation Scandinavia, 2016-04-12 Trådlös kommunikation i industrin - ett PiiA-projekt Trådlös reglering Tidigare och nuvarande PiiA-projekt Control & Communications
Enhetstester på.netplattformen
Enhetstester på.netplattformen Praktikfall ur verkligheten Copyright Prolore 2007. All Rights Reserved. Viktor Laszlo Vem är jag 11 år inom test Prolore: specialiserat på Testautomatisering, Prestandatest
Webbserverprogrammering
Webbserverprogrammering WES Webbserverprogrammering Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets
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
WEBBSERVERPROGRAMMERING
WEBBSERVERPROGRAMMERING Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets syfte Undervisningen i ämnet
PlantPuppy Räddaren för den som inte kan hålla växterna vid liv
Lunds Tekniska Högskola Elektro- och informationsteknik Digitala Projekt PlantPuppy Räddaren för den som inte kan hålla växterna vid liv Gerda Sidwall Thygesen Sofia Sundbom Zoë Wyon ine14gth@student.lu.se
SCRUM. Marcus Bendtsen Institutionen för datavetenskap
SCRUM Marcus Bendtsen Institutionen för datavetenskap 2 Metodik Systematiskt tillvägagångssätt för att garantera utfallet Metodiken behöver passa kontexten och tillgängliga resurser Verifiering av metodiken
Agil testning i SCRUM
Agil testning i SCRUM Petter Salomonsson Petter.salomonsson@addq.se Tel: 0708-398435 Kort presentation AddQ Consulting AB tydlig fokus på test och kvalitetssäkringstjänster erbjuder mycket erfarna konsulter
Decentraliserad administration av gästkonton vid Karlstads universitet
Datavetenskap Opponent(er): Markus Fors Christian Grahn Respondent(er): Christian Ekström Per Rydberg Decentraliserad administration av gästkonton vid Karlstads universitet Oppositionsrapport, C/D-nivå
SAST Q1. Som att börja arbeta på ett nytt jobb. Testautomatisera med Modell-baserad testning
SAST Q1 Som att börja arbeta på ett nytt jobb Testautomatisera med Modell-baserad testning Christina Nordström Kristian Karl Christina Nordström Test sedan 1996 Aldrig testautomatiserat Enhetschef Testenheten
DETALJNIVÅNS PÅVERKAN PÅ EN SIMULERING HOW THE LEVEL OF DETAIL AFFECTS A SIMULATION
DETALJNIVÅNS PÅVERKAN PÅ EN SIMULERING HOW THE LEVEL OF DETAIL AFFECTS A SIMULATION Hampus Wallin Emil Wåhlin EXAMENSARBETE 2015 Datateknik Postadress: Besöksadress: Telefon: Box 1026 Gjuterigatan 5 036-10
Projektmodell med kunskapshantering anpassad för Svenska Mässan Koncernen
Examensarbete Projektmodell med kunskapshantering anpassad för Svenska Mässan Koncernen Malin Carlström, Sandra Mårtensson 2010-05-21 Ämne: Informationslogistik Nivå: Kandidat Kurskod: 2IL00E Projektmodell
Konsultbolag1. Testplan för Europa version 2. Testplan Projekt Europa Sid 1 (av 9) 2009-05-14. Europa-projektet. Dokumenthistorik
Testplan Projekt Europa Sid 1 (av 9) Europa-projektet Testplan för Europa version 2 Dokumenthistorik Utgåva Datum Författare Kommentar 1 2008-12-16 Ulf Eriksson Ursprunglig version, utkast 2 2008-12-18
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
The Intelligent Timer
The Intelligent Timer Linnea Karell och Oscar Bagge, I10 Handledare: Bertil Lindvall 2013-05-20 Abstract The objective of this project was to build a prototype of a digital timer. The product design specification
Testautomatisering. Intro
Testautomatisering FM: Presentation Genomgång av Kursplan / Kursupplägg Varför testautomatisering? Video + diskussion Idag David Gullmarsvik david.g@jetas.se Software Developer Tidigare Lärare KYH, TI
Mälardalens högskola
Teknisk rapportskrivning - en kortfattad handledning (Version 1.2) Mälardalens högskola Institutionen för datateknik (IDt) Thomas Larsson 10 september 1998 Västerås Sammanfattning En mycket viktig del
Kursintroduktion. B-uppsats i hållbar utveckling vårterminen 2017
Kursintroduktion B-uppsats i hållbar utveckling vårterminen 2017 People build up a thick layer of fact but cannot apply it to the real world. They forget that science is about huge, burning questions crying
Tentamen vetenskaplig teori och metod, Namn/Kod Vetenskaplig teori och metod Provmoment: Tentamen 1
Namn/Kod Vetenskaplig teori och metod Provmoment: Tentamen 1 Ladokkod: 61ST01 Tentamen ges för: SSK GSJUK13v Tentamenskod: Tentamensdatum: 2015 10 02 Tid: 09:00 12:00 Hjälpmedel: Inga hjälpmedel Totalt
Metoder och verktyg för funktionssäkerhet
Metoder och verktyg för funktionssäkerhet Projektstart 1. Hantera kraven En bra process är grunden för att hantera kraven i ett säkerhetsprojekt. Det krävs att du har en tydlig spårbarhet mellan krav och
Using SharePoint Workflow
Datavetenskap Opponent(er): Anders Olsson Marcus Karlsson Respondent(er): Harald Quist Creating a Help Desk Using SharePoint Workflow Oppositionsrapport, C-nivå 2009:xx 1 Sammanfattat omdöme av examensarbetet
Microsoft Dynamics 365 Business Application vs. ERP. Företagen måsta sätta sig själva i förarsätet
Microsoft Dynamics 365 Business Application vs. ERP Slutsats från mina 5 artiklar om ämnet: Tema Dynamics 365 Business Application 2017-05-10 Created by: Mikael Petersén: Vi är inne i ett stort teknikskifte
Idag. EDAA35: Utvärdering av programvarusystem. Mål. Innehåll. Kursmoment. Lärare
EDAA35: Utvärdering av programvarusystem MARTIN HÖST Idag Intro till kursen Forskningsmetodik Att sätta mål i studier Mål Innehåll Kursens syfte är att ge förståelse om hur vetenskapliga studier genomförs,
Filhanterare med AngularJS
Filhanterare med AngularJS Författare: Filip Johansson Peter Emilsson Oskar Georgsson Christian Nilsson Datum: 2014-03-26 1 Sammanfattning Filhanterare med AngularJS är en filhanterare skapad för Sigma
Automatiserad testning av användargränssnitt i SharePoint
Automatiserad testning av användargränssnitt i SharePoint Automated UI Testing in SharePoint Daniel Borg Anders Elfström Examensarbete inom information- och programvarusystem, grundnivå Högskoleingenjör
Thomas Pettersson. Sammanfattning. Född: 1969. Telefon: +46760446260. Kristinagatan 23B 602 26 Norrköping. thomas.pettersson@debadata.
Thomas Pettersson Född: 1969 Telefon: +46760446260 Adress: E-post: Kristinagatan 23B 602 26 Norrköping thomas.pettersson@debadata.se Sammanfattning Thomas är född 1969 och är bosatt i Norrköping. Han har
Testning. 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer
Testning 1DV404, HT14 Jesper Andersson Kap 21 + Testing Primer UP Faser Elaboration ü Syfte: Fastställa och validera en basarkitektur för systemet vilket ger en stabil grund för den största delen av utvecklingsarbetet
Sirius II Installation och Bruksanvisning
Sirius II Installation och Bruksanvisning Innehåll 1. Introduktion... 2. Installation av Sirius II programvara... 3. Anslutning Data Linker interface.... 4. Sirius II funktioner.... 5. Bruksanvisning....
Användarcentrerad systemdesign
Användarcentrerad systemdesign Föreläsning 9: Agile-metoder, XP och ACSD Stefan Blomkvist MDI / IT, Uppsala Universitet, stefan.blomkvist@it.uu.se XP www.it.uu.se/edu/course /homepage/acsd/s04 Dagens föreläsning
Sara Skärhem Martin Jansson Dalarna Science Park
Sara Skärhem Martin Jansson Dalarna Science Park Sara Skärhem Martin Jansson Vad är innovation? På Wikipedia hittar man: En innovation är en ny idé, till exempel i form av en produkt, lösning, affärsidé,
Utbildningsplan. Systemvetenskapliga programmet. 180 högskolepoäng. System Science Program. 180 Higher Education Credits *)
Utbildningsplan Systemvetenskapliga programmet 180 högskolepoäng System Science Program 180 Higher Education Credits *) Fastställd i Utbildnings- och Forskningsnämnden 2012-11-14 Gäller fr.o.m. 2013-07-01
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...
Litteraturstudie. Utarbetat av Johan Korhonen, Kajsa Lindström, Tanja Östman och Anna Widlund
Litteraturstudie Utarbetat av Johan Korhonen, Kajsa Lindström, Tanja Östman och Anna Widlund Vad är en litteraturstudie? Till skillnad från empiriska studier söker man i litteraturstudier svar på syftet
Studenters erfarenheter av våld en studie om sambandet mellan erfarenheter av våld under uppväxten och i den vuxna relationen
Studenters erfarenheter av våld en studie om sambandet mellan erfarenheter av våld under uppväxten och i den vuxna relationen Silva Bolu, Roxana Espinoza, Sandra Lindqvist Handledare Christian Kullberg
På jakt efter examensarbete?
På jakt efter examensarbete? BorgWarner i Landskrona utvecklar ett system för 4-hjulsdrift som idag serietillverkas till ett flertal bilmodeller från bl.a. Volkswagen, Volvo och Land Rover. BorgWarner
Vetenskapsmetod och teori. Kursintroduktion
Vetenskapsmetod och teori Kursintroduktion Creswell Exempel Vetenskapsideal Worldview Positivism Konstruktivism/Tolkningslära Kritiskt (Samhällskritiskt/ Deltagande) Pragmatism (problemorienterat) Ansats
Projekt EITA15. Väckarklocka. LTH Ingenjörshögskolan vid Campus Helsingborg Datateknik
Projekt Väckarklocka LTH Ingenjörshögskolan vid Campus Helsingborg Datateknik Grupp:, och Handledare: Bertil Lindvall och Lars Göran Larsson Kurs: EITA 15 Lunds Tekniska Högskola Datum: 2019-05-21 Sammanfattning
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ärande, kommunikation och informationsteknologi, Magisterprogram, 60 högskolepoäng
Utbildningsplan Dnr G 2018/203 IT-FAKULTETEN Lärande, kommunikation och informationsteknologi, Magisterprogram, 60 högskolepoäng Learning, Communication and Information Technology, Master's Programme,
Projektplan, Cykelgarage
Projektplan, Cykelgarage Johan Anderholm, (dt08ja5@student.lth.se) Jon Andersen (dt08ja8@student.lth.se) Marcus Carlberg (dt08mc4@student.lth.se) Simon Ekvy (dt08se2@student.lth.se) Stefan Johansson (dt08sj7@student.lth.se)
Projektdirektiv Oskar Ljungqvist Sida 1. Kund/Examinator: Daniel Axehill, Reglerteknik/LiU
2018-08-30 Sida 1 Projektnamn Beställare Projektledare Projektbeslut Projekttid Rapportering, ISY Student, ISY Läsperiod 1-2, HT 2018. Projektet klart senast vid projektkonferensen. Löpande rapportering:
Metodguiden en webbaserad tjänst med information om olika insatser och bedömningsinstrument.
Metodguiden en webbaserad tjänst med information om olika insatser och bedömningsinstrument. Vilka metoder granskas? Hur granskas de? Finns det effektiva och evidensbaserade metoder? Jenny Rehnman jenny.rehnman@socialstyrelsen.se
Pragmatisk programmering. Cyberrymden 2001-10-03. Marcus Rejås <marcus@rejas.se> Pragmatisk programmering,19 september 2002 1(26)
Pragmatisk programmering,19 september 2002 1(26) Pragmatisk programmering Cyberrymden 2001-10-03 Marcus Rejås $Id: slides.tex,v 1.8 2002/09/16 19:43:40 rejas Exp $ Metainformation Denna
Varje rätt svar ger 0.5 poäng. (max 3p)
Fråga 1) Följande fråga beaktar skillnaden mellan marknadsdriven och kontraktsdriven produktutveckling. Para ihop varje scenario med det alternativ som passar bäst. A Kontraktsdriven produktutveckling
Goals for third cycle studies according to the Higher Education Ordinance of Sweden (Sw. "Högskoleförordningen")
Goals for third cycle studies according to the Higher Education Ordinance of Sweden (Sw. "Högskoleförordningen") 1 1. Mål för doktorsexamen 1. Goals for doctoral exam Kunskap och förståelse visa brett
Teknisk testning för otekniska testare
Teknisk testning för otekniska testare SAST, 16-feb-2017 Rikard Edgren Nordic Medtest rikard.edgren@nordicmedtest.se Nordic Medtest utför testning och kvalitetssäkring och bidrar till mer användbar och
Förslag på examensarbete
Förslag på examensarbete 2011 Allmän information - exjobb på Aros utvecklar och producerar kundanpassad industriell elektronik. Motorstyrningar, sensorer och fältbussteknologi är våra specialområden. Inom
QC i en organisation SAST 2008-09-16
QC i en organisation SAST 2008-09-16 1 Agenda Hur är vi organiserade inom test på SEB? Hur är QC uppsatt på SEB? Hur arbetar vi med QC i en stor organisation? Uppfyllde QC våra förväntningar och hur har
Hur skriver man statistikavsnittet i en ansökan?
Hur skriver man statistikavsnittet i en ansökan? Val av metod och stickprovsdimensionering Registercentrum Norr http://www.registercentrumnorr.vll.se/ statistik.rcnorr@vll.se 11 Oktober, 2018 1 / 52 Det
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
Praktikanter i lyckat testuppdrag för LearningWell
Praktikanter i lyckat testuppdrag för LearningWell 2013-03-12 Tre praktikanter - Patrik Johansson, Anton Danielsson och Patrik Eriksson (bilden) - har på uppdrag av LearningWell utvecklat en automatiserad
Cacheminne Intel Core i7
EDT621 Datorarkitekturer med operativsystem 7,5 hp 2015-12-07 Cacheminne i Intel Core i7 Författare: Adnan Karahmetovic Handledare: Erik Larsson Innehåll 1. Inledning... 1 1.1 Syfte... 1 1.2 Frågeställning...
Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation
Kurs: Designm etodik, 3 p Delm om ent: Datum : 2 0 0 3-1 2-1 8 Utvecklingsm odell och utvecklingsm etod för att skapa god kom m unikation Nils Järgenstedt [ it3 jani@ituniv.se] Innehållsförteckning INLEDNING...
Programmera Avant 5 med PC mjukvara
Programmera Avant 5 med PC mjukvara Installera mjukvaran på din PC Sätt i CD-skivan i PC:n. Kör filen setup.exe på CDskivan så startar installationen. Följ instruktionerna tills installationen är klar.
Datalagringsmetodik och arkitektur i Java. Projektdefinition. Projektdefinition. Björn Brenander. 7 maj 2001
Datalagringsmetodik och arkitektur i Java Projektdefinition Dokumenttitel Projektdefinition Dokumentansvarig Dokumentförfattare Björn Brenander Dokumentnamn Projektdefinition.doc Version 16 Ref. nr. Skapades
Undervisningen i ämnet webbutveckling ska ge eleverna förutsättningar att utveckla följande:
WEBBUTVECKLING Ämnet webbutveckling behandlar de tekniker som används för att presentera och bearbeta information i webbläsaren samt utifrån dessa tekniker skapa och vidareutveckla statiska och dynamiska
Två innebörder av begreppet statistik. Grundläggande tankegångar i statistik. Vad är ett stickprov? Stickprov och urval
Två innebörder av begreppet statistik Grundläggande tankegångar i statistik Matematik och statistik för biologer, 10 hp Informationshantering. Insamling, ordningsskapande, presentation och grundläggande
TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 1. Kursinformation Vad är Software Engineering? Hur går ett projekt till?
TDDI02 Programmeringsprojekt, Föreläsning 1 Anton Sundblad Filip Strömbäck Med utgångspunkt i tidigare slides av Jonas Lindgren På denna föreläsning: Kursinformation Vad är Software Engineering? Hur går
Unit testing methodology
Department of Computer Science Per Hurtig Stefan Lindberg & Fredrik Strandberg Unit testing methodology Opposition Report, C/D-level 2005:xx 1 Övergripande utvärdering Helhetsintrycket av uppsatsen är
Rapportmall för Skogsmästarskolan 2018
SKOGSMÄSTARPROGRAMMET Examensarbete 2018:xx Rapportmall för Skogsmästarskolan 2018 Report template School of Forest Management 2018 Back Tomas Ersson Johan Törnblom Examensarbete i skogshushållning, 15
sida 1 Grupp 6 co-browsing 1DV411 - Webbprojekt I Markus Axelsson Stavros Gemitzoglou Axel Hernborg Joakim Jonsson Rickard Karlsson Peter Magnusson
sida 1 Grupp 6 co-browsing 1DV411 - Webbprojekt I Författare: Markus Axelsson Stavros Gemitzoglou Axel Hernborg Joakim Jonsson Rickard Karlsson Peter Magnusson Termin: VT2014 sida 2 Sammanfattning Denna
12 principer of agile practice (rörlig)
X-treme programming 12 principer of agile practice (rörlig) Ge nöjd kund genom tidig och kontinuerliga leveranser Den viktigaste punkten som betyder att min vill ha kontinuerlig feedback Välkomna sena
TETRIS. LTH, Campus Helsingborg EITA15 Digitala System
TETRIS LTH, Campus Helsingborg EITA15 Digitala System Handledare: Bertil Lindvall Författare: Isak Shamun, Viktor Kulle, Mark Slipac och Dennis Järnåsen Datum: 2019-05-09 Abstract This report concerns
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
ISO STATUS. Prof. dr Vidosav D. MAJSTOROVIĆ 1/14. Mašinski fakultet u Beogradu - PM. Tuesday, December 09,
ISO 9000 - STATUS Prof. dr Vidosav D. MAJSTOROVIĆ 1/14 1 ISO 9000:2000, Quality management systems - Fundamentals and vocabulary Establishes a starting point for understanding the standards and defines
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
Microsoft ALM Agenda. Processer metoder Kundcase Paus Under huven på Visual Studio Team Test Frågor och Svar + en liten tävling
Agenda Processer metoder Kundcase Paus Under huven på Visual Studio Team Test Frågor och Svar + en liten tävling 2009-05-19 1 Intro Lights In Line Bo & Christian 2009-05-19 2 Varför Prestandatester *Tillgänglighet
Distribuerade affärssystem
Distribuerade affärssystem Kursens mål Bygga upp, strukturera och programmera distribuerade system med en flerskiktsarkitektur Beskriva och förklara teorier och uttryck som används inom affärskritiska
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;
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
CUSTOMER VALUE PROPOSITION ð
CUSTOMER VALUE PROPOSITION ð IN BUSINESS MARKETS JAMES C. ANDERSSON, JAMES A. NARUS, & WOUTER VAN ROSSUMIN PERNILLA KLIPPBERG, REBECCA HELANDER, ELINA ANDERSSON, JASMINE EL-NAWAJHAH Inledning Företag påstår
TDIU14. Föreläsning 3 - metoder Ola Leifler
TDIU14 Föreläsning 3 - metoder Ola Leifler Så, vad är ett BRA examensarbete? Examensarbete = projektresultat + skriftlig rapport En fungerande, intressant, välbeskriven tillämpning av teknik med tydligt