Minimumkrav för ett CI-system
|
|
- Britta Öberg
- för 8 år sedan
- Visningar:
Transkript
1 Examensarbete 15 högskolepoäng, grundnivå Minimumkrav för ett CI-system On The Minimum Requirements of a CI-system Petrus Kiendys Shadi Al-Zara Examen: Högskoleingenjörsprogram 180 hp Examinator: Gion Svedberg Data- och telekommunikationsteknik Handledare: Mia Persson 19 januari 2015 Tore Nestenius
2 This page intentionally left blank.
3 Tack till medverkande Vi vill tacka följande personer för deras medverkande och stöd under detta examensarbete: Tore Nestenius (extern handledare från Edument AB) för handledning och kontinuerligt stöd under arbetets gång, i synnerhet för den hjälp vi fick under arbetets tidiga fas då vi inte riktigt visste hur vi skulle komma igång. Tore tillhandahöll oss med resurser som vi fick användning av och tillförde en praktisk aspekt av examensarbetet. Mia Persson (intern handledare) för handledning och stöd vid moment och aspekter av examensarbetet som vi haft begränsad kunskap om. Vi har fått hjälp med bl.a. utformningen av marknadsundersökningen, kategorisering av funktionella och icke-funktionella krav samt vilka vetenskapliga metoder som är mest lämpliga för att angripa vår frågeställning. Joakim Hellberg (IT-support) för tillhandahållandet av en fysisk server som vi kan ansluta oss till via fjärrstyrning för att utföra praktiska moment av examensarbetet. Annabella Loconsole (ämnesexpert inom kravhantering) för tips om metoder som kan användas när man utformar krav för ett IT-system samt en inblick i omfattningen av att utföra en formell kravhantering av ett IT-system. Ulrik Eklund, Kristina Ericson och resten av lärarlaget för konkreta tips under informationssökningen av vetenskapliga artiklar, utformning av referenser enligt IEEEreferensstil och hänvisningar till litteratur för att få en bättre förståelse för den vetenskapliga metoden. iii
4 Sammanfattning När en grupp utvecklare jobbar med samma kodbas kan konflikter uppstå med avseende på implementationen av moduler eller delsystem som varje utvecklare individuellt jobbar på. Dessa konflikter måste snabbt lösas för att projektet ska fortskrida och inte stagnera. Utvecklare som sällan kommunicerar framför ofta okompatibla moduler eller delsystem som kan vara svåra eller omöjliga att integrera i kodbasen, detta leder ofta till s.k. integration hell där det kan ta väldigt lång tid att anpassa ny kod till en befintlig kodbas. En strategi som man kan ta till är continuous integration, ett arbetssätt som erbjuder en rad fördelar när man jobbar i grupp på en gemensam kodbas. Continuous integration är möjligt att tillämpa utan verktyg eftersom detta är ett arbetssätt. Däremot kan processen stödjas av ett s.k. CI-system som är något av en teknisk implementation eller påtagligt införlivande och stöd för arbetsmetoden continuous integration. Denna rapport syftar till att ge en inblick i vad ett CI-system är och vad den principiellt består av. Vi undersöker vad ett CI-system absolut måste bestå av genom en litteraturundersökning och en marknadsundersökning. Vi ställer upp dessa beståndsdelar som funktionella och icke-funktionella krav för ett typiskt CI-system. Vi kan på så vis kvantifiera och kategorisera olika komponenter och funktionaliteter som bör innefattas i ett typiskt CI-system. I denna rapport finns även ett bihang som visar hur man kommer igång med att bygga en egen CI-server mha. CI-systemmjukvaran TeamCity. Slutsatsen av vår rapport är att CI-system är ett viktigt redskap som kan underlätta mjukvaruutveckling. Med hjälp av CI-system kan man stödja utvecklingsprocessen genom att bl.a. förhindra integrationsproblem, automatisera vissa delar av arbetsprocessen (kompilering av källkod, testning av mjukvara, notifikation om stabilitet av kodbas och distribution av färdig mjukvara) samt snabbt hitta och lösa integrationsfel. Nyckelord: continuous integration, CI, CI-system, TeamCity, funktionella krav, ickefunktionella krav iv
5 Abstract When a group of developers work on the same code base, conflicts may arise regarding the implementation of modules or subsystems that developers individually work on. These conflicts have to be resolved quickly in order for the project to advance at a steady pace. Developers who do not communicate changes or other necessary deviations may find themselves in a situation where new or modified modules or subsystems are impossible or very difficult to integrate into the mainline code-base. This often leads to so called integration hell where it could take huge amounts of time to adapt new code into the current state of the code-base. One strategy, which can be deployed to counteract this trend is called continuous integration. This practice offers a wide range of advantages when a group of developers collaborates on writing clean and stable code. Continuous integration can be put into practice without the use of any tools as it is a way to do things rather than an actual tool. With that said, it is possible to support the practice with a tangible tool called a CI-system. This study aims to give insight into the makings of a CI-system and what it fundamentally consists of and has to be able to do. A study of contemporary research reports regarding the subject and a survey was performed in order to substantiate claims and conclusions. Core characteristics of CI-systems are grouped into functional requirements and nonfunctional requirements (quality attributes). By doing this, it is possible to quantify and categorize various core components and functionalities of a typical CI-system. This study also contains an attachment which provides instructions of how to get started with implementing your own CI-server using the CI-system software TeamCity. The conclusion of this study is that a CI-system is an important tool that enables a more efficient software development process. By making use of CI-systems developers can refine the development process by preventing integration problems, automating some parts of the work process (build, test, feedback, deployment) and quickly finding and solving integration issues. Keywords: continuous integration, CI, CI-system, TeamCity, functional requirements, nonfunctional requirements, quality attributes v
6 Innehållsförteckning 1. Inledning Bakgrund Målgrupp för examensarbete Syfte och frågeställning Motivering till ämnesval Uppdragsbeskrivning och avgränsningar Internt uppdrag Externt uppdrag Översikt över området Teoretisk beskrivning Systemutvecklingsmetoder Continuous Integration (CI) Vad är CI? Varför CI-system används CI-system verktyg CI-system grundläggande verktyg CI arbetsflöde För- och nackdelar med CI-system Fördelar med CI-system Nackdelar med CI-system Continuous Integration bästa praxis Metod Litteraturundersökning Utförande av litteraturundersökning Undersökningsmetod Datainsamling och analys Utförande av marknadsundersökning Etiska principer Informationskravet Konfidentialitetskravet Nyttjandekravet Metod för övriga moment Utförande av kursmaterial Uppbyggnaden av CI-systemet Utförandet av användbarhetstest och behandling av svarsdata vi
7 4. Resultat och analys Krav för ett CI-system Funktionella krav Icke-Funktionella krav Hur ställer man upp krav för system? Kravtest och utvärdering Resultat från marknadsundersökningen Resultat från litteraturundersökning Användbarhetstestning Kategorisering av användbarhet via användbarhetsattribut Kategorisering av användbarhet via huvudområden Indelning av beståndsdelar för användbarhetsscenario Uppställning av användbarhetsscenario Uppställning av testformulär och användarenkät Resultat från användbarhetstestning Slutsats Diskussion Diskussion av kraven Förbättringar Fortsatt forskning Referenser Bibliografi Bilagor vii
8 1. Inledning 1.1 Bakgrund Utvecklare är intresserade av att skapa de bästa möjliga applikationer för sina kunder på kortast möjliga tid. Men applikationer kan bestå av många olika delar och moduler, vilket skapar stora och komplexa applikationer. Således blir utvecklingsprocessen av mjukvara svårare även om man använder sig av avancerade verktyg. En lösning till detta är att automatisera vissa delar av utvecklingsprocessen. Continuous integration (CI) är ett av de bästa sätten att göra detta [1]. När många team och utvecklare samarbetar med varandra är continuous integration avgörande för att leda framgång eller misslyckande av projektet [2]. Continuous integration (CI) är en del av Extreme Programming (XP) metoden. XP utvecklades 1997 under Chrysler Comprehensive Compensation System (C3) projektet av Kent Beck och Ron Jeffries [3]. Metoden har blivit populär inom mjukvaruutveckling. Det har visat sig att användning av metoden kan förbättra releasefrekvens av mjukvara och förutsägbarhet, dvs. förmågan för utvecklare att förutsäga när färdig leverans av stabil mjukvara kan ske. Metoden har även visat sig öka utvecklarnas produktivitet och förbättra kommunikationen inom ett utvecklingsteam, bland andra förmåner [4, s. 1]. CI är en process eller en uppsättning rutiner som ett utvecklingsteam kan jobba utefter. CI kräver inga verktyg för att kunna tillämpas, däremot kan processen stödjas på ett mer effektivt sätt mha CI-system. CI-system kan bl.a. automatisera olika processer som är grundläggande för CI och på så sätt förenkla, upprätthålla och förbättra processen [5]. Mer om detta kan läsas i avsnitt 2.5 CI-system bästa praxis. CI-system används alltmer i näringslivet vid mjukvaruutveckling för att effektivisera arbetsprocessen och tillföra ökad produktionsvärde [6]. CI-system ska enligt [7] kunna utföra 3 grundläggande funktioner som utgör cykeln för continuous integration: Versionshantering av resurser (version control system) för att utföra insamling av resurser (källkod, byggskript) Bygge av system som utför kompilering eller annan behandling av källkod, även utförandet av fördefinierade uppgifter som körning av byggskript och dylikt. Deployment management som tar hand om förpackningen och leveransen av stabil mjukvara. Något som sällan diskuteras är om det finns speciella krav som ett CI-system måste uppfylla för att vara tillfredsställande för ett utvecklingsteam och när systemet är användbart. Detta ska tittas närmare på i denna rapport. Läsaren hänvisas till avsnitt för en teoretisk beskrivning kring vad CI-processen är och hur CI-system stödjer denna process. I avsnitt definieras vad som menas med ett CI-system och i avsnitt presenteras ett antal argument för varför CI-system bör användas. I avsnitt går vi igenom olika verktyg som används i samband med CI-system och i avsnitt förklaras arbetsflödet för CI-system. Avsnitt och handlar om funktionella och icke-funktionella krav för CIsystem. Hur de ställs upp, valideras och testas förklaras i avsnitt och Sida 1
9 För att ge läsaren en klar bild över hur och varför CI-system används så anges i avsnitt 2.5 bästa praxis för continuous integration. 1.2 Målgrupp för examensarbete Målgruppen för denna studie är utvecklare och systemadministratörer inom olika organisationer som tänker introducera continuous integration i sin verksamhet. Examensarbetet genomfördes efter en 3-årig högskoleingenjörsutbildning i Data och Telekom vid Malmö Högskola och kan även vara intressant för studenter som genomför en kandidatexamen i liknande områden. Även tekniskt kunniga individer som är intresserade och vill lära sig mer om CI-system kan ha nytta av denna studie. Rapporten är skriven på så sätt att nya termer förklaras då dem påträffas, läsaren förväntas därför läsa från början till slut. Dock har vi angett hänvisningar till relevanta avsnitt när detta krävs för att underlätta för läsaren. 1.3 Syfte och frågeställning Syftet med denna studie är att utforska olika egenskaper hos CI-system och systematiskt kategorisera dessa samt definiera minimumkrav som CI-system måste uppfylla för att vara tillfredsställande för ett utvecklingsteam. Vår frågeställning är följande: Huvudfrågor: 1. Vilka funktionella och icke-funktionella krav måste CI-system uppfylla för att vara till nytta för användning? 2. Kan man enligt fastställda krav testa, värdera och jämföra CI-system? Delfrågor: 3. Vilken mjukvara för CI-system används mest? 4. Vilka för- och nackdelar finns det för ett CI-system? 5. Hur pass utbredd är användningen av CI-system bland utvecklare inom företag som använder sig av dessa system? 6. Leder CI-system till en mer effektiv utvecklingsprocess för mjukvaruutvecklare? Motivering till ämnesval Vi har valt att utforska CI-system eftersom diskussioner med vår externa handledare (Tore Nestenius) har påvisat att det finns ett intresse och behov i industrin att bedriva ytterligare undersökning och forskning kring ämnet. Tore Nestenius jobbar för Edument AB som sysslar med systemutveckling och utbildning inom IT. Företaget jobbar just nu med att utforma en rad olika kurser som kan användas för workshops och 3-dagars seminarier. Några månader innan examensarbetet satte igång hade vi tid att undersöka olika förslag till examensarbetet. Vi fick en del förslag både internt på Malmö Högskola och utifrån. Efter fortsatta diskussioner med Tore stod det mellan 2 förslag: Practical continuous Integration and deployment (with TeamCity) och Application visualization in.net (with Microsoft Azure). Vi kom fram till att det är mer relevant och intressant att undersöka Sida 2
10 continuous integration och valde därför detta förslag. Förslaget presenterades sedan för Malmö Högskola och vår examinator. Tillsammans med våra handledare diskuterade vi fram en infallsvinkel och avgränsning för ämnesområdet, mer om detta beskrivs i nästa avsnitt. 1.4 Uppdragsbeskrivning och avgränsningar Vi hade både ett internt uppdrag som utfördes åt Malmö Högskola och ett externt uppdrag som utfördes åt Edument AB. Uppdragen och avgränsningarna beskrivs utförligt nedan Internt uppdrag I början var det interna uppdraget att utforska CI/CD (continuous integration and deployment) i stort. Därför började vi med att utföra en grundlig förstudie (se bilaga 5) där vi lärde oss mer om CI/CD. Vi tittade även på närliggande koncept så som agila metoder. Efter diskussioner med vår examinator och interna handledare kom vi fram till att uppdraget måste avgränsas och begränsas till något som är genomförbart och verifierbart. Vi valde därför att avgränsa oss från att titta på CI som en process i stort och dess inverkan på utveckling av mjukvara till CI-system som är tekniska system för att stödja denna process och vilka krav dessa system måste uppfylla för att vara tillfredsställande för utvecklingsteam. Uppdraget delades upp i fyra delar: 1. Vi utförde en analys av vilka minimumkrav som behöver uppfyllas för att ha ett välfungerande CI-system. Kraven togs fram via en litteraturundersökning (se bilaga 3) och en marknadsundersökning. Därefter delade vi in kraven i specifika områden dvs. funktionella och icke-funktionella krav för att systematiskt kunna utföra ett kravtest utefter kraven. Således är slutsatsen för vilka krav ett CI-system måste uppfylla förankrat i både vetenskap och industriella erfarenheter. 2. Efter att vi kom fram till vilka krav som var viktigast för CI-system att uppfylla så byggde vi upp en TeamCity-server. Vi avgränsade oss till endast en implementation för att vara säkra på att kravtest och behandling av data kan utföras i tid. 3. När TeamCity-servern var körbar testades denna enligt de krav som vi ställt upp. Man kan med hjälp av testresultaten redogöra TeamCitys lämplighet för användning på ett mer objektivt och systematiskt sätt till skillnad från att endast uttrycka en subjektiv åsikt. 4. Den sista delen av examensarbetet bestod av att behandla data som vi fick fram från testfasen. Under denna del diskuterar och presenterar vi data samt dra slutsatser för TeamCity och CI-system utifrån dessa data Externt uppdrag En artefakt som producerades under examensarbetet är kursmaterial till vår externa handledare. Kursmaterialet består av en teoretisk genomgång av CI och CI-system, samt en praktiskt get started with CI genomgång mha CI-mjukvara TeamCity. Sida 3
11 Vår externa handledare hade specifika krav kring hur kursmaterialet ska vara utformat: Kursmaterialet ska vara skrivet på engelska Kursmaterialet är tänkt att användas för en 3-dagars kurs som består av powerpoint slides eller 10 timmars kursmaterial Moduler består av ca slides i timmen 2 huvuddelar som i sin tur består av moduler CI/CD teoretisk bakgrund och varför det används Praktiskt exempel på hur man kommer igång med TeamCity Vi insåg dock att arbetsbördan för att producera denna mängd material är för stor och att detta realistiskt sett inte kan rymmas inom det här examensarbetet. Därför kom vi överens med vår externa handledare att minska antalet slides men försöka hålla kvaliteten hög för det kursmaterial som vi hinner få ut. Vi fick under examensarbetet fram ca 280 slides sammanlagt för de båda huvuddelarna (se bilaga 1). Processen att utforma kursmaterialet löpte parallellt med tidigare nämnda delproblem. 1.5 Översikt över området Vår förstudie (bilaga 5) innehåller relevanta böcker, vetenskapliga artiklar och yrkeskunskap som vi tagit del av för att genomföra och förankra studien i vetenskap. Under litteraturundersökningen (bilaga 3) har vi även tagit del av tidigare studier kring ämnet CI-system och även den innehåller resurser som kommit till nytta. Nedan följer en sammanfattning av vetenskapliga artiklar, böcker och webbartiklar som kommit till störst nytta för vår studie samt en förklaring till varför vi valt just dessa resurser. Vi har utgått från följande källor för områdena: Beskrivning av olika begrepp inom CI: För att få kunskap om CI och beskriva det som en del av mjukvaruutvecklingsverktyg läste vi den vetenskapliga artikeln [2] som beskriver fördelar med att använda automatiserade mjukvaruutvecklingsverktyg vid mjukvaruutveckling av komplexa system. Ki & Song anger flaskhalsar i mjukvaruutveckling för större projekt och presenterar en open-source lösning som förbättrar utvecklingsmiljön. Det finns många artiklar som definierar CI på nätet. Webbartikeln [5] av Martin Fowler är en av de mest tillförlitliga källorna när det gäller CI. Den har hög relevans för vår studie eftersom man får en genomgång av vad CI är, vilka bästa praxis det finns för CI och varför det bör tillämpas. Med hjälp av artikeln kunde vi bl.a. definiera begreppet CI samt tolka och på svenska sammanfatta bästa praxis för CI i denna studie. Ytterligare en intressant webbartikel är [12], där författaren går in på en processbeskrivning för hur ett CI-system bör fungera samt beskriver grunderna (viktiga komponenter) för ett CI-system. Den hjälpte oss att förstå och beskriva CI-processen i vår studie. Den vetenskapliga artikeln [15] som är skriven i form av case study, visar hur CI-system och automatiserade tester används för att utveckla robusta Sida 4
12 C4ISR system. Artikeln beskriver koncepten build agents och build configuration som används i TeamCity. Författarna beskriver även testning utförligt. Av artikeln fick vi veta hur ett CI-system kan tillämpas i industrin. En bok som kommer till stor användning är [9]. Den beskriver begreppet CI och dess praxis från grunden samt går den igenom andra effektiva processer som utförs av CI-system, såsom databasintegration, testning och återkoppling. I vår studie definierade vi begreppet CI och beskrev olika CIprocesser med hjälp av denna bok. Slutligen vill vi nämna den vetenskapliga artikeln [4] som genom en litteraturstudie visar att det finns skillnader i hur olika utvecklare brukar och tolkar continuous integration. Denna studie är väldigt lik i karaktär till vår studie, inte minst pga. vi i vår studie också utfört en litteraturundersökning. Beskrivning av olika komponenter och verktyg för CI-system: Introduktionsboken [8] var till stor hjälp för att kunna bygga vårt CI- system då den beskriver steg för steg hur man bygger upp en TeamCity-server. En annan bok vi tyckte var intressant att belysa är [1]. Den beskriver hur man implementerar ett CI-system i.net samt ger en beskrivning av olika CIservrar. Boken hjälper utvecklare som vill komma igång med CI men vet inte hur. I vår studie använde vi boken för att beskriva olika komponenter och viktiga verktyg som ingår i ett CI-system. Boken [10] är mycket intressant för vår studie eftersom den innehåller de principer och tekniska metoder som används i CI-system och beskriver olika komponenter och funktioner i systemet. Webbartikeln [14] anger fördelar med att använda sig av CI-system både genom en inledning som beskriver vad ett CI-system är och praktiska exempel på hur man kommer igång med det. I den praktiska beskrivningen förklarar författaren hur man förbereder ett större projekt för automatisering via byggskript. Vi fick stor hjälp av denna artikel då den förklarade hur byggskript kan användas. Den vetenskapliga artikeln [7] beskriver inlärningsprocessen då man inrättar continuous integration för en grupp utvecklare. Författaren tar utförligt och explicit de grundläggande komponenter som ett CI-system består av och han förklarar hur CI-system kan motverka långa integrationsprocesser och göra de mindre och mer hanterbara. Beskrivning av olika krav för CI-system: En intressant webbartikel när det gäller CI-krav är [11]. I denna artikel listas några krav som ett CI-system måste uppfylla för att kunna fungera och erbjuda utvecklare kontinuerliga kvalitetskontroller. Fokus för artikeln sammanfaller med vår frågeställning beträffande CI-krav. Vissa böcker och artiklar som vi använde oss av när vi undersökte krav för CI-system [17, 25-26, 42] nämner inte krav specifikt för CI-system utan det är allmänna beskrivningar om hur krav hanteras i sammanhang där man utvecklar mjukvara. Sida 5
13 2. Teoretisk beskrivning 2.1 Systemutvecklingsmetoder Inom organisationer som arbetar med mjukvaruutveckling är det viktigt att använda någon typ av utvecklingsmetod för att hantera och förbättra utvecklingsprocessen [17]. De mest kända traditionella metoderna inom mjukvaruutveckling är följande: Vattenfallsmetoden är en metod som använts länge och är en av de traditionella sekventiella metoderna i vilket arbetsprocessen övergår från ett stadie till ett annat utan att återgå till föregående stadier [18]. Fig. 1: Vattenfallsprocessen [18] Agila metoder kan sägas vara moderna anpassningar av de traditionella metoderna och innefattar en grupp av mjukvaruutvecklingsmetoder. De utvecklades för att producera mjukvara av hög kvalitet under kortare tid och för att effektivisera utvecklingsprocessen. Metoderna är designade på så sätt det blir lättare för utvecklare att identifiera kravförändringar under utvecklingsprocessen. Utvecklargrupper som använder sig av agila metoder brukar ha en bättre kontakt med kunden och övriga intressenter under utvecklingsprocessen. [19-20] Fig. 2: Agila metoder [20] Sida 6
14 Extreme Programmering (XP) är en del av de agila metoderna och utvecklades 1997 under Chrysler Comprehensive Compensation (C3) projektet av Kent Beck och hans utvecklingsteam. XP syftar till att förbättra kvaliteten på mjukvaran, förkorta leveransplaner och vara en metod som är anpassad till föränderliga kundkrav. [3, 21] Fig. 3: XP practices [21] "Continuous Integration originated with the Extreme Programming development process, as one of its original twelve practices" [5]. 2.2 Continuous Integration (CI) Vad är CI? Martin Fowler påpekar att continuous integration är en metod som ofta används i mjukvaruutveckling där utvecklare i ett team integrerar sitt arbete minst en gång om dagen vilket ofta leder till flera integrationer per dag. Varje integration verifieras, kontrolleras och testas för att så snabbt som möjligt upptäcka fel i integrationen av ny kod [5]. Paul Duvall anger en annan definition där han menar att CI är en taktik som används mest inom mjukvaruutveckling för att det garanterar hälsosamma IT-system och stabila applikationer. Det ökar mjukvaruutvecklares förmågan att göra förändringar i deras kod och garanterar en snabb återkoppling om något fel uppstår i programvaran. Detta möjliggörs genom att köra ett bygge med varje förändring [9]. Sida 7
15 2.2.2 Varför CI-system används K. Marcin och B. Craig anger flera skäl till att använda CI i utvecklingsprocessen som följande [1]: Minskade risker: CI skapar bättre mjukvara pga. tidiga tester och integrationer av ny kod under utvecklingsprocessen. Paketerbar mjukvara: När installationsprocessen automatiseras kommer programvaran att installeras som den ska. Ökad synlighet för projektet: Återkopplingsmekanismen ger en möjlighet för projektmedlemmar att se byggresultaten och visar var problemen uppstår. Snabba inkrementella byggen: Att snabbt bygga och testa innebär att utvecklare snabbare får resultat, vilket bistår utvecklarna att fixa problemen tidigare i utvecklingsprocessen. CI-system kan både användas i små, medelstora och stora IT-verksamheter. CI-system kan även användas vid andra verksamheter, bl.a. uppbyggnad av kunskapsbaser [22], men vi kommer inte titta närmare på dessa användningsområden. 2.3 CI-system verktyg En komplett CI-process använder sig av flera verktyg. Man kan köpa dyra CI-system som är funktionsrika och ofta enkelt att installera och underhålla, eller så kan man använda verktyg som inte är lika funktionsrika och ofta kräver en del arbete för att ställa upp, men är antingen gratis eller till låg kostnad [1] CI-system grundläggande verktyg Grundläggande CI-system verktyg enligt K. Marcin och B. Craig [1] är: 1. Versionshanteringssystem (eng. source code control) När utvecklare lägger upp sin kod i en gemensam kodbas gör de en så kallad incheckning (eng. commit) av källkoden. Varje revision av källkoden lagras i en så kallad centralkatalog (eng. repository). Centralkatalogen tillhandahåller utvecklare med den senaste revisionen av källkoden som lagts in och arkiverar samtidigt tidigare revisioner så att man bl.a. ska kunna återställa källkod till ett tidigare tillstånd om det behövs men även för att spåra förändringar som skett över en viss tid. Centralkatalogen används inte bara för att lagra och arkivera källkod utan används även för att lagra andra artefakter så som kundsanteckningar, designskisser, dokumentation och liknande. 2. Continuous Integration server CI-servern pollar källkodskontroll-systemet med ett jämnt intervall för att upptäcka förändringar (tittar om en ny revision har lagts in). När en förändring upptäckts kan CI-servern hämta hem kodbasen på nytt och t.ex. trigga ett nytt bygge och köra enhetstest. CI-servern samordnar även de övriga stegen i CI-processen. Sida 8
16 3. Bygghanterare (eng. build manager) Verktyget hanterar själva kompileringen och bygge av källkod och övriga projektfiler. Vissa projekt implementeras kanske för olika plattformar eller olika inställningar för kompilatorn. Build managern sköter detta arbetet och ser till att rätt kompilator används för att kompilera källkoden. Efter kompilering kan binärfilerna användas för olika syften t.ex. paketeras och distribueras eller testas dynamiskt, dvs. systemet testas under körtid till skillnad från statiska test där man läser av källkoden för att hitta fel. 4. Enhetstest (eng. unit testing) Detta verktyg kör enhetstester som utvecklarteamet skriver för sin applikation. När testerna genomförts genereras resultatdata som brukar sparas i loggar (t.ex. XMLformat) eller i textfiler. Loggarna kan sedan avläsas av CI-systemet varefter olika åtgärder kan vidtas beroende på huruvida testerna lyckades eller misslyckades. 5. Återkopplingsmekanism (eng. feedback mechanism) Utvecklare vill ofta hålla sig uppdaterade om huruvida deras senaste incheckningar av källkoden gick igenom tester och byggdes korrekt. Detta är speciellt viktigt om utvecklarens incheckning resulterade i ett misslyckat bygge, då måste detta misstag åtgärdas så fort som möjligt för att kodbasen ska återgå till ett stabilt läge. Utvecklare blir ofta meddelade om misslyckade byggen genom en feedbackmekanism, där dem får feedback via en rad olika kommunikationskanaler så som t.ex. , SMS, IM, dashboard CI arbetsflöde Fig. 4: arbetsflöde för CI-system[23] Sida 9
17 CI-processen börjar med att en build server i CI-systemet hämtar den senaste revisionen från ett versionshanteringssystem när den upptäcker att en ny revision lagts in [22, s. 97]. CI-systemet kommer sedan att köra fördefinierade skript som anger hur den hämtade källkoden ska byggas och övriga konfigurationer kring bygget. När applikationen har byggts enligt skriptet körs relevanta automatiserade tester. De flesta CI-systemmjukvaror inkluderar ett webbinterface som visar en lista över byggen som kör och möjliggör en insikt för utvecklare i byggprocessen och avläsning. Här kan utvecklare se om deras revision av källkoden är stabil eller om något gick fel på vägen. Denna process avslutas i produktion och lagring av resulterande artefakterna såsom binärfiler eller installationspaket och distribueras så att testare och kunder enkelt kan hämta den mest uppdaterade och stabila versionen av applikationen. De allra flesta CI-system kan konfigureras med hjälp av ett webbgränssnitt eller via terminalkommandon samt skript. 2.4 För- och nackdelar med CI-system Det finns flera fördelar och nackdelar med CI-system. Vi har genom rapporten främst belyst fördelar med CI-system som möjliggör effektivisering av olika arbetsprocesser för systemutvecklare. I följande avsnitt vill vi sammanfatta dessa fördelar men även gå in på några fördelar med CI-system som inte nämns lika ofta. Även om vi i vår studie vill anföra argument för varför CI-system kan vara gynnsamma för vissa situationer måste vi givetvis även vara objektiva och opartiska i vår bedömning, därför kommer vi även redogöra nackdelar med att använda sig av CI-system, främst de organisatoriska svårigheter som kan uppstå då utvecklare överger vissa rutiner och arbetsmetoder för att tillämpa continuous integration med hjälp av CI-system Fördelar med CI-system CI-system har många fördelar [33, 41, 49-50] och vi har nämnt de flesta i olika avsnitt av rapporten. Nedan anger vi och sammanfattar några fördelar som vi tycker är extra viktiga men även fördelar som inte ofta brukar nämnas i sammanhang där man diskuterar CIsystem: Smidigare integration av ny kod. Utvecklare undviker långa integrationsfaser i utvecklingsprocessen genom att dela upp arbetsuppgiften i små delar som oftare kan integreras in i kodbasen. Automatisering av bygg-, testning- och distributions-processer. Hjälper till att skapa CRISP (Complete, Repeatable, Informative, Schedulable, Portable) byggen av systemet som är under utveckling via CI-systemet. Med CRISP menar vi: o Complete - Bygget av systemet ska kunna ske på en ren maskin och utan att utvecklaren ska behöva utföra en manuell rutin som kan medföra mänskliga fel, med andra ord ska bygget av systemet ske med ett knapptryck och utföras på ett maskinellt och automatiserat sätt. o Repeatable - Bygget av systemet ska vara repeterbart, dvs. det resultat som skapas när kompilatorn och övriga behandlingsverktyg bearbetat källkod ska inte ändras över tiden och inte bero på yttre faktorer och verktyg, CI- Sida 10
18 systemet ska förses med all inmatning inkl. byggskript i centralkatalogen där hela kodbasen ligger. o Informative - Om något går fel i bygget av systemet så ska man snabbt kunna fixa dessa fel. Detta kan man endast göra om man har ett CI-system som utförligt loggar olika händelser och statistik. Med hjälp av dessa loggar kan man snabbt se var fel inträffade. Det är viktigt att man har mekanismer som tidigt kan spåra oväntade förändringar eller beteenden för systemet som utvecklas. o Schedulable -Utvecklare ska kunna schemalägga byggen, det ska inte behövas manuella utlösare för att köra byggen. o Portable - Systemet ska kunna byggas från vilken arbetsstation som helst, oavsett vilken plattform och operativsystem körs. Detta kan ske via CI-system och man bör därför förlita sig på CI-systemet för att byggen istället för att utföra det på enskilda arbetsstationer. Snabbare och enklare att hitta fel och fixa buggar, både semantiska och syntaktiska fel men även kodningskonventioner kan upprätthållas via CI-system. Bättre översikt över projektet och fortskridande. Detta ökar förtroende mellan utvecklarna men även mellan kunden och slutanvändare som kan se fortskridandet av projektet mer kontinuerligt. Generera distributionspaket när som helst, då kodbasen alltid förväntas vara stabil (fixas inom en kort tidsram om så inte är fallet). Distributionspaketet kan även genereras från vilken arbetsstation som helst då det är CI-systemet som sköter detta och inte enskilda arbetsstationer vars miljöer kan skiljas åt. Detta anknyter till föregående punkt då utvecklare kan förse kunden med distributionspaket i utvärderings- eller demonstrationssyfte mer kontinuerligt under projektets gång. Snabb återkoppling och rapportering när fel inträffar. Utvecklaren som har gjort fel är snabbt underrättad om fel som finns och kan åtgärda dessa fel så att medarbetare som ska fortsätta med arbetet inte använder sig av icke-fungerande kod eller artefakter Nackdelar med CI-system Det är givetvis inte bara intressant att titta på vilka fördelar ett CI-system har men även vilka nackdelar som finns och hur mycket tid och resurser som måste läggas ner för att komma igång och tillämpa CI-system på en industriell nivå. Det är rätt svårt att få fram information kring detta eftersom de allra flesta källor som beskriver CI-system argumenterar för användningen av CI-system snarare än emot. Dock har vi hittat information kring nackdelar med CI-system och vilka svårigheter som kan uppstå när man försöker använda sig av CIsystem inom olika verksamheter [33, 49]. Det tar tid att ställa upp och komma igång med CI-system. Detta fenomen inträffar när man omstrukturerar eller ska tillämpa nya rutiner på arbetsplatsen i alla möjliga sammanhang, inte bara när CI-system ska introduceras. Oavsett vilken rutin som ska ändras så finns det alltid en förlust av tid när man introducerar något nytt. Det tar inte bara tid att ställa upp ett CI-system, man måste även ha kompetens och förhoppningsvis tidigare erfarenhet av att ställa upp CI-system för att det ska gå så smidigt som möjligt. Sida 11
19 Det krävs välutvecklade tester (t.ex. enhetstester och integrationstester) för att ta del av fördelarna med automatisering. Liksom föregående punkt kan det ta ett tag innan utvecklare skiftar från att skriva mjukvara som kan kompileras (men som kanske ändå innehåller fel) till ett testdrivet tillvägagångssätt där man först utvecklar en testsvit (eng. test suite) för att sedan påbörja implementationen av systemet. Frekventa förändringar i kodbasen kan skapa ett tillstånd av förvirring för utvecklare. Detta är kanske mer vanligt för utvecklare som tidigare inte arbetat med CI-system. Denna nackdel är dock mer pga. dålig inlärd rutin eller praxis snarare än en direkt nackdel eller motargument för att använda CI-system. Ett sätt att motverka denna nackdel är att utbilda utvecklare (kanske via en snabbkurs i hur man använder CIsystem) och inge förtroende samt förklara hur det nya arbetsflödet kommer att se ut då utvecklare som arbetat med vattenfallsmodellen är mer vana att jobba med större moduler över längre tid istället för att dela upp arbetet i mindre arbetspaket. Ett bra CI-system betyder höga kostnader gällande mjukvara och hårdvara. Detta kan vara ett problem för verksamheter som inte har en budget att investera i ytterligare resurser. Kostnaderna omfattar inte endast köp av mjukvara och hårdvara, det finns ytterligare kostnader som tillkommer när man t.ex. måste reparera servrar eller uppdatera mjukvaran. Problem kan även uppstå om man upptäcker att ett visst mjukvarupaket inte uppfyller de krav som man ställer på sina utvecklingsverktyg och man måste då migrera till och anpassa en annan lösning. Ovan har vi listat en rad olika nackdelar. Att hitta integrationsfel och buggar tidigt i utvecklingsprocessen sparar både tid och pengar över livslängden på ett projekt [49]. Därför vill vi påstå att fördelarna med att använda sig av ett CI-system uppväger nackdelarna som man stöter på när man först börjar använda sig av ett CI-system. 2.5 Continuous Integration bästa praxis För att ge en mer handfast bild av hur CI-processen kan och bör användas och hur CI-system kan upprätthålla CI-processen samt en rad olika fördelar mjukvaruutvecklare kan dra nytta av om de tillämpar CI, kommer de 10 bästa CI tillämpningarna enligt Martin Fowler att presenteras nedan: [5] 1. Utvecklingsteamet bör använda sig av en gemensam centralkatalog 2. Automatisera bygget 3. Se till att bygget innehåller automatiska tester 4. Utvecklare uppmanas att ofta checka in till kodbasen 5. Varje incheckning bör trigga en build som ligger på utvecklarens ansvar 6. Se till att bygget är optimerat och kan göras på under 10 minuter 7. Utför tester i en kopia av produktionsmiljön 8. Tillgängliggör exekverbara filer (prototyper/demo) för intressenter 9. Se till att hela utvecklingsteamet har koll på läget 10. Automatisera paketering och distribution av mjukvara Sida 12
20 3. Metod I detta avsnitt går vi igenom hur vi löste olika delproblem under examensarbetet. För att kunna introducera ett CI-system vetenskapligt krävs det en hel del kunskap om ämnet. Vi började vår studie med att söka och samla in information kring ämnet på nätet. Då hade vi ingen aning om vad CI-system handlar om. Därefter genomförde vi en problemformulering där vi förklarade och avgränsade vår frågeställning. Strukturen på examensarbetet och indelningen av delproblem fick vi fram under förstudien som innehöll bl.a. litteraturstudier och tekniska lösningar till problemet (se bilaga 5). Då fördjupade vi oss i ämnet genom att läsa flera böcker och vetenskapliga artiklar som handlar om problemområdet. För att underbygga den slutsats som vi slutligen kom fram till och för att få svar på vår frågeställning utförde vi både en litteraturundersökning (avsnitt 3.1) och en marknadsundersökning (avsnitt 3.3). Svarsdatan från dessa undersökningar kunde vi senare jämföra och korrelatera. Slutligen, för att kunna verifiera en aspekt av vår slutsats och demonstrera en praktisk artefakt i examensarbetet så ställde vi upp ett CI-system (avsnitt 3.5.2) och övrig infrastruktur för att demonstrera hur CI-system kan användas, men även ett användbarhetstest (avsnitt 3.5.3) för att utöka omfattningen av det praktiska momentet. Under tiden som vi utförde samtliga delar arbetade vi även med kursmaterial (avsnitt 3.5.1) på uppdrag av vår externa handledare. Processen som vi använde följer stegen som Saunders, Lewis & Thornhill beskriver i [24]. Stegen förklaras tydligare enligt bilden nedan. Fig. 5: Research process I följande avsnitt förklarar vi hur vi har utfört de olika stegen. Sida 13
21 3.1 Litteraturundersökning För att kunna beskriva CI och dess minimala krav i produktutvecklingscykeln krävs det erfarenhet och kunskap om den aktuella byggprocessen och olika CI komponenter. Därför valde vi att avgränsa oss och genomföra en litteraturundersökning (se bilaga 3) på CIsystem. Syftet med litteraturundersökningen var att samla information och fakta om CIsystem, förstå hur CI-system fungerar och undersöka om det är möjligt att definiera minimumkrav som CI-system måste uppfyllas för att vara tillfredsställande för ett utvecklingsteam Utförande av litteraturundersökning Vi beslutade oss för att presentera och formellt ställa upp litteraturundersökningen i en matris där kopplingar mellan referenser och funktionella samt icke-funktionella krav listas. Populära CI-servrar mjukvaror listades även här (se bilaga 3). För att fastställa vilka funktionella och icke-funktionella krav som vi letar efter i litteraturen tillgick vi mötesprotokoll och anteckningar från diskussioner med våra handledare. Vi sökte även efter en sammanfattning av vanliga icke-funktionella krav för olika typer av system [25-28]. Den litteratur som vi sedan gick igenom med hjälp av ovan nämnda funktionella och ickefunktionella krav bestod av yrkeskunskap i form av webbartiklar och bloggar, böcker utgivna av författare som är verksamma inom mjukvaruutveckling med CI-system och vetenskapliga artiklar som har en högre nivå av relevans för vår studie [2, 5, 7, 9-16, 29-35]. 3.2 Undersökningsmetod Som undersökningsmetod valde vi SES metoden enligt John W. Creswell [36]. Sequential Exploratory Strategy (SES) är en två-fas metod med prioritet på den första fasen. Under den inledande fasen samlar man in och analyserar kvalitativ data. Därefter övergår man till nästa fas och kategoriserar de kvantitativa data, man använder sig alltså av kvantitativ data för att förstå sig på de kvalitativa data. Slutligen integrerar man slutsatser som man fått fram från båda faserna i en tolkningsfas. Metoden är enkel att tillämpa och använda sig av i olika formuleringar, dess utformning gör den även lämpad för en tydlig beskrivning av hur man behandlat datan. Metoden är väl lämpad för forskning kring ett fenomen, särskilt om man vill utforska de kvalitativa resultaten från den första fasen [36]. Eftersom vi i vår studie kommer att utforska CI-system och dess minimala krav, där vi är särskilt intresserade av kvalitativ data anser vi att SES-metoden är att föredra. Sida 14
22 3.3 Datainsamling och analys Under denna studie genomfördes en marknadsundersökning mha en webbaserad enkät, för att på ett effektivt sätt samla in data från en stor grupp människor om vårt ämne. Via enkäten som utfördes kunde vi få fram data som vi ville komma fram till om CI-system och dess minimala krav. En enkätundersökning är ett flexibelt medium som kan mäta attityder, kunskaper, preferenser, osv [37]. När man gör en enkätundersökning så är det viktigt att man formulerar enkätfrågorna noggrant så att man verkligen får den svarsdata som är relevant för studien. Frågorna ska vara tydliga och kortfattade samt de ska inte vara ledande i sin karaktär [38]. Enkäten innehåller 19 frågor av olika typer och tar cirka 5 minuter att fylla på. Den är riktad till företag och utvecklare som använder sig av CI-system inom olika organisationer av olika storlekar i ett flertal länder. Enkätundersökningsfrågorna presenteras i bilaga 2. Enligt Saunders, Lewis och Thornhill [24] finns det olika tekniker för att samla in och analysera data som man fått ifrån en undersökning. De vanligaste datainsamlingstekniker är kvalitativ och kvantitativ tekniker. Man kan skilja mellan de två teknikerna när man behandlar numeriska eller icke-numeriska uppgifter. Kvalitativ datainsamling används för det mesta vid frågor eller dataanalytiska förfaranden där man bara intresserad av att kategorisera data som ger eller använder sig ut av icke-numerisk data så som text, bilder och även videoklipp. I vår enkätundersökning har vi använt den kvalitativa tekniken för att undersöka och samla in data för funktionella och icke-funktionella krav för CI-system på vissa frågor t.ex. fråga 1, 3, 5-8, (se bilaga 2) Kvantitativ datainsamling används däremot oftast vid frågor eller dataanalytiska förfaranden där man är intresserad av att visualisera data i grafer och statistik som ger eller använder sig utav numerisk data. I enkätundersökning har vi också använt den kvantitativa tekniken för att undersöka och samla in data för funktionella och icke-funktionella krav för CI-system på vissa frågor t.ex. fråga 2, 4, (se bilaga 2) För att klargöra de kvalitativa resultaten som vi fick från enkätfrågorna omvandlade vi kvalitativa data till numerisk data och statistik i form av grafer. Vi kombinerade både kvalitativa och kvantitativa tekniker för att kunna presentera resultaten på ett bättre sätt. Därför ska vi enligt Creswell [36] kunna använda mixed methods i denna typ av studie. Mixed methods är metoder som enligt Saunders, M., Lewis, P. och Thornhill, A. [24] kombinerar både kvantitativa och kvalitativa datainsamlingstekniker och analysförfaranden. Detta innebär att man kan ta kvantitativa uppgifter och omvandla dem till vanlig text som kan analyseras kvalitativt. Eller så kan man omvandla sina kvalitativa data till numerisk data, så att dem kan analyseras kvantitativt precis som vi gjorde i fråga 3, 5-8, när vi tog utdatan från textfrågorna (kvalitativa data) som vi kom fram till via enkäten och presenterade detta via diagram för att tydligare åskådliggöra resultaten. Sida 15
23 3.3.1 Utförande av marknadsundersökning För att genomföra en marknadsundersökning valde vi att utföra en webbaserad enkät. [37] Enkäten genomfördes med hjälp av Google Docs Forms (se bilaga 2). Anledningen till vårt val av Google Docs Forms var att det är lätt och använda, gratis, och att det inte finns någon övre gräns för hur många frågor man kan ställa upp på enkäten som SurveyMonkey har. Enkäten utformades enligt strikta riktlinjer [36], vi kunde därför försäkra oss om att vi fick ut användbara svar från marknadsundersökningen till vår studie. Enkäten innehåller 19 frågor av olika typer och tar cirka 5 minuter att fylla i. Den är riktad till företag och utvecklare som använder sig av CI-system inom olika organisationer av olika storlekar. I början tänkte vi ta kontakt med företag som jobbar med CI-system inom Sverige och skickade då enkäten till flera företag som jobbar med CI-system i hela landet, men de flesta företag som tillfrågades avböjde att delta i vår studie. Därefter vände vi oss till sociala media såsom Facebook, LinkedIn, Twitter och vi kontaktade företagare och utvecklare som sysslar med CI-system. Enkäten innefattade frågor av olika typer [38] bl.a. flersvarsfrågor som kan sägas vara kvantitativa och öppna frågor som kan sägas vara kvalitativa. Meningen med detta var att ge utvecklare möjlighet att uttrycka sig själva i sina egna ord och få en bättre förståelse för hur utvecklare identifierar och definierar minimala krav för CI-system. I slutändan besvarades enkäten av 39 aktörer av de ca 300 aktörer som tillfrågades att delta, vilket innebär att svarsfrekvensen var ca 13%. För att samla in och analysera data med hjälp av enkätundersökning använde vi oss ut av kvalitativ datainsamlingsteknik för följande frågor: 1, 3, 5-8, För återstående frågor använde vi kvantitativ datainsamlingsteknik [24]. Erhållna data ifrån enkätundersökningen behandlades med hjälp av MS Excel och visualiserades i olika typ av diagram (se avsnitt 4.2), för att lättare kunna visa svaren och enklare kunna dra slutsatser av inlämnade svar. 3.4 Etiska principer Ett av de stegen i undersökningsprocessen är att diskutera etiska principer. Enligt Staffan Stukát [39] är det viktigt att man tänker på etiska principer när man utför en undersökning. Därför ansåg vi att det var viktigt att ta hänsyn till etiska principer när vi utförde denna studie. De forskningsetiska principer beskrivs av Vetenskapsrådet [40] som följande: Sida 16
24 3.4.1 Informationskravet Forskaren skall informera de av forskningen berörda om den aktuella forskningsuppgiftens syfte [40]. Vi informerade deltagare om studiens syfte och vilka villkor som gäller när de deltar i studien. Vi var specifika när vi angav att syftet för vår studie var att undersöka krav för CIsystem (se bilaga 2) Konfidentialitetskravet Uppgifter om alla i en undersökning ingående personer skall ges största möjliga konfidentialitet och personuppgifterna skall förvaras på ett sådant sätt att obehöriga inte kan ta del av dem [40]. Vi har under studien angett att deras svar förblir sekretessbelagda och att insamling av uppgifter för denna studie hanteras varsamt för att obehöriga ej ska få tillgång till denna data (se bilaga 2) Nyttjandekravet Uppgifter insamlade om enskilda personer får endast användas för forskningsändamål [40]. I vår studie har vi angett att deltagande i undersökningarna genererar data som endast kommer att användas av för att besvara våra frågeställningar för studien (se bilaga 2). 3.5 Metod för övriga moment Utöver undersökningsprocessen som vi använde oss av har vi även utfört moment i vår studie som inte innefattas av den. Nedan beskriver vi hur vi utfört kursmaterial, uppbyggnad av CI-systemet och genomförandet av tester Utförande av kursmaterial Båda delar av kursmaterialet (teoretisk och praktisk) som vi fick fram presenteras i bilaga 1. Vi började först med den teoretiska delen av kursmaterialet genom att söka lämpliga källor och samla in information som behövs för att beskriva continuous integration. Informationen som erhölls kom dels från böcker och vetenskapliga artiklar som vi gick igenom när vi skrev Sida 17
25 vår studie och dels från olika webbartiklar på nätet. De flesta källor kunde vi komma fram till via Malmö högskolans databaser (bl.a. ACM Digital library, Google Scholar, IEEE Xplore). Information och anteckningar som vi sammanställde under studien utmynnade till bl.a. kursmaterial i form av 2 omfattande powerpoint-dokument, dessa dokument utgör ett utkast till den kurs som kommer att vidareutvecklas och användas i utbildningssyfte av Edument AB där man både är intresserad av att undervisa i continuous integration men även i hur detta praktiskt kan tillämpas med hjälp av CI-server mjukvaran TeamCity. För att utföra den praktiska delen av kursmaterialet behövde vi därför först och främst komma igång med TeamCity och förstå hur man använder sig av det, innan vi kunde börja beskriva det och presentera i ett powerpoint-dokument. Mer om hur själva uppbyggnaden av CI-systemet TeamCity skedde kan läsas om i nästa avsnitt. Vi kan därför fokusera på själva processen av att få fram den praktiska delen av kursmaterialet i detta avsnitt. Detta var i själva verket en väldigt enkel process, dock tog det ett bra tag att få alla bitar på plats och få fram powerpoint-dokumentet. Vi tog helt enkelt skärmdumpar under olika delar av interaktionen med TeamCity (allt från installation av TeamCity till att köra byggen och tester) och kategoriserade dessa i moduler. Sammanlagt fick vi fram 14 moduler som beskriver hur man kommer igång med att använda TeamCity. Vissa bilder behövde även modifieras (t.ex. förstoras eller att viktiga element i bilden markeras med röda rektanglar eller pilar) så detta skedde i nästa steg. När vi väl hade skärmdumparna på plats så infogades dessa i powerpoint-dokumentet och en bildtext skrevs till för att beskriva vad som sker på skärmdumparna. Även en beskrivande text för varje modul skrevs för att åhöraren ska få en uppfattning om vad som kommer att presenteras Uppbyggnaden av CI-systemet För att uppfylla krav som ställs på ingenjörer och ingenjörsverksamhet byggde vi upp ett CIsystem och kravtestade systemet enligt de krav som fåtts fram av tidigare nämnda undersökningar. Vi använde oss under detta moment av CI-mjukvaran TeamCity [8] för att uppfylla vår externa handledares krav. Vi avgränsade oss till uppbyggnad och kravtest av endast ett CI-system pga. omfattningen av examensarbetet. Vi valde TeamCity eftersom just detta CI-system är av intresse för vår externa handledare. Eftersom vi har interna krav på att utföra ett praktiskt moment och ett externt krav att producera kursmaterial som består av en praktisk del där vi går in på hur man kommer igång med en TeamCity-server var detta ett lämpligt val. IT-supporten på Malmö högskola försåg oss med en dator som vi kunde använda som CIsystem server. Serverns systemspecifikationer beskrivs i bilaga 9. Sida 18
26 Till att börja med installerade vi TeamCity (se bilaga 1 för en utförlig beskrivning om hur man kommer igång med TeamCity). TeamCity lagrar loggar och annat i en databas, därför installerade vi även XAMPP för att kunna köra en MySQL databas. Sedan installerade vi IDE:n Eclipse Luna för att skapa ett enkelt Java-projekt som vi kan bygga och testa i TeamCity, detta projekt är alltså skapat i demonstrationssyfte och har ingen annan praktisk tillämpning. Vi installerade även Apache Ant för att skriva ett byggskript som bygger projektet lokalt, detta skript måste sedan skickas med till TeamCity så att CI-systemet vet hur den ska bygga källkoden i projektet. Sedan skrev vi även enhetstester för projektet i JUnit via Eclipse. När Java-projektet var färdigt (se bilaga 8) så satte vi upp ett VCS (version control system) i Google Code och använde oss då av Subversion (se bilaga 1 för en beskrivning i hur detta skedde). Subversion centralkatalogen kan hittas här: Vi använde TortoiseSVN som ett grafiskt gränssnitt för att checka in nya revisioner av kodbasen till Subversion centralkatalogen. Vid detta laget hade vi alla bitarna på plats och då var det bara att få TeamCity att hämta den senaste revisionen av kodbasen som vi lagt upp på Google Code Subversion och kompilera koden samt köra enhetstester (även detta beskrivs mer utförligt i bilaga 1) Utförandet av användbarhetstest och behandling av svarsdata Av både litteraturundersökningen och marknadsundersökningen framgår det att det ickefunktionella kravet användbarhet är ett av de viktigaste kraven som måste uppfyllas i ett CIsystem. Efter diskussioner med vår interna handledare kom vi därför fram till att det vore intressant att ta reda på om TeamCity uppfyller krav gällande användbarhet. Dessutom är detta ett sätt för oss att validera de slutsatser som vi har kommit fram till genom undersökningarna. Vi började med att diskutera vilken målgrupp vi ska rikta oss mot. Likt marknadsundersökningen var vi mest intresserade att titta på huruvida yrkesverksamma individer som haft erfarenhet av CI-system anser att TeamCity är användbart eller ej. När vi fastställt målgruppen så utformade vi textmallar där vi informerar inbjudna individer och företag om hur de kan anmäla sitt intresse och vi skickade ut dessa inbjudningar främst via LinkedIn där vi bjöd in mer än 400 individer och företag. Eftersom användbarhetstestet ej kan utföras obevakat, till skillnad från t.ex. enkäten för marknadsundersökningen, och eftersom den dessutom tar mellan minuter att utföra krävdes en del arbete med bokföring och schemaläggning av intresserade testkandidater. Vi erbjöd även de intresserade att anmäla sitt intresse både via mail och via Doodle.com, vår schemaläggningssida kan hittas här: I olika sammanhang kan man använda sig av ett godtyckligt antal testare för att fastställa om krav för ett system är uppfyllt eller ej. För vårt användbarhetstest bestämde vi oss för att Sida 19
27 ha 5 testsessioner med deltagare som har tidigare erfarenhet av CI-system men ej använt TeamCity. Vi ville även ha 1-5 deltagare som tidigare använt TeamCity, dessa deltagare kan då placeras i en kontrollgrupp där vi kan jämföra resultat mellan testgruppen och kontrollgruppen. Dessutom kan kontrollgruppens resultat användas som måttstock när vi fastställer kriterier och gränsvärden för svarsdatan och bestämmer om dessa påvisar att CIsystemet är användbart eller ej. Efter att ha genomgått testsessioner och inbjudningar under 2 veckors tid hade vi svarsdata från 5 deltagare i testgruppen (som ej använt TeamCity tidigare) och 1 deltagare i kontrollgruppen. Vi hoppades få in lite fler deltagare i kontrollgruppen men just pga. omfattningen och tiden som individer måste lägga ner för att genomföra detta test (30-50 min plus bokning och mail-korrespondens) men även faktumet att vi utförde testerna utan en budget (diskuteras närmare i avsnitt 6.2 förbättringar ) innebar att vi inom denna tidsram inte fick in fler testsession. Trots detta anser vi att momentet är lyckat då vi i första hand ville få in 5 deltagare i testgruppen, vilket vi lyckades med. För att ställa upp en miljö där vi kan utföra användbarhetstest fanns det en del saker att tänka på. För det första bestämde vi oss för att utomstående klienter (deltagaren) skulle koppla upp sig mot vår CI-server som körs på Malmö Högskola. När klienten väl var uppkopplad så försågs hon med användarenkäten och interfacet till TeamCity som båda körs via webbläsaren. Inloggning till TeamCity, förberedelse inför testsession och tillgång till användarenkäten sköttes alltså av oss innan klienten/testaren anslöt sig. Vi använde oss av TeamViewer för att förse en uppkopplingslänk mellan CI-system servern och testaren. Det fanns flera skäl till att vi valde just TeamViewer istället för t.ex. VNC eller andra verktyg. För det första så ville vi ha en säker uppkoppling där vi som värd snabbt kan koppla ifrån eller begränsa interaktion och tillgång till CI-system servern om det under testets gång visar sig att testaren interagerar med servern utanför testets ramar. Då kan testaren snabbt kopplas från och nekas en ny uppkoppling. Sedan har TeamViewer stöd för att spela in testsessioner vilket var önskvärt. Detta innebär att vi inte måste belasta servern med ytterligare program som körs under testsessionen. Mer diskussion kring TeamViewer och dess fördelar och nackdelar i avsnitt 6.2 förbättringar. Det sista delmomentet i utförandet av användbarhetstesterna var efterbehandlingen av svarsdatan från testsessionerna. Som tidigare nämnt så fylldes en del svarsdata in i testformuläret via användarenkäten och en del efter kontroll av inspelade test sessioner. Arbetsflödet för behandling och beräkning av task time förbättrades under delmomentets gång där vi till en början utförde aritmetiska beräkningar manuellt men sedan tillämpade automatiska och mer precisa beräkningar via spreadsheet-mjukvara så som MS Excel, OpenOffice Spreadsheet och Google Docs Spreadsheet. Vi använde oss av bl.a. för att dubbelkolla beräkningar och kunde på så sätt snabbt hitta fel som uppstod pga. manuella beräkningar i det tidiga skedet. Den behandlade svarsdatan redogörs grafiskt i form av diagram i avsnitt Sida 20
28 4. Resultat och analys I detta avsnitt redogör vi resultat som vi fått fram genom våra undersökningar samt analyserar resultatdatan. Vi definierar även olika begrepp och förklarar koncept som vi lärt oss om i samband med detta arbete som är specifikt för vårt sätt att betrakta CI-system utifrån krav. Vi redogör både funktionella och icke-funktionella krav för CI-system i avsnitt 4.1 samt redogör för hur man ställer upp krav för system och hur man sen kan kravtesta och utvärdera system utifrån uppställda krav. I avsnitt 4.2 redovisar vi resultat från marknadsundersökningen som vi utförde och i avsnitt 4.3 redovisar vi resultat från litteraturundersökningen. I avsnitt 4.4 förklarar vi hur man utför användbarhetstestning enligt vedertagna tekniker samt hur vi själva tillämpat den föreslagna tekniken för vårt eget syfte. Slutligen redogör vi resultatet från vår användbarhetstestning. 4.1 Krav för ett CI-system Systemkrav är de krav som ställs på mjukvaran och anger vilka avvägningar man gör t.ex. mellan olika icke-funktionella krav som oftast är ömsesidigt uteslutande, exempelvis kan en applikation skrivas på ett tydligare sätt för att senare kunna underhållas till förlust av prestanda och resurseffektivitet. I systemkrav anges även vilka funktionella krav som ligger i fokus, dvs. vad applikationen ska kunna utföra för tjänst i huvudsak. Kraven som ställs på mjukvara kan kategoriseras enligt funktionella och icke-funktionella krav [17] Funktionella krav Funktionella krav för ett CI-system beskriver vad systemet ska göra. Här kommer några exempel på funktionella krav för ett CI-system [5, 7, 30, 32, 41]: Kodhantering (eng. code management): Hantering av ändringarna i källkod och möjliggörandet av att återvända till äldre versionen och tillstånd av applikationen vid behov. Kompilering/bygge av källkod (eng. compiling/building source code): Kompilering av källkod via CI-systemet. Testning: Olika typer av tester ska kunna utföras via CI-systemet. Det finns olika sätt att kvalitetssäkra källkod, bl.a. via statisk analys, enhetstest, stresstest och integrationstest samt systemtest. Återkoppling (eng. feedback/notification): Utvecklare som checkat in kod måste på något sätt bli underrättade om CI-systemet upptäcker fel i den incheckade koden. Detta kan ske via exempelvis , dashboard/wui (eng. web-based user interface, dvs. webbaserat användargränssnitt), SMS eller IM (eng. instant messaging). Vissa projektgrupper använder sig av andra sätt att notifiera gruppmedlemmar om att kodbasen är i ett brutet tillstånd, därför är det bra om CI-systemet tillåter administratören att konfigurera återkopplingen till en hög grad. Distribution (eng. deployment): Källkod som kompilerats och testats kommer vid en viss tidpunkt under projektets gång att behöva distribueras till slutanvändare och övriga intressenter (eng. stakeholder). Detta kan automatiseras via CI-system som skapar jar-filer, tar-filer eller paketerar körbar mjukvara i en så kallad installer, dessa utdelningsbara (eng. distributable) filer kan sedan delas ut till intressenter. Sida 21
29 Administration: Hantering av användare och användargrupper med en lista över privilegier som kan tilldelas till dessa. Byggserverhantering (eng. build agent management): Hantering av byggservrar som utför centrala funktionaliteter för CI-system. En byggserver är en enhet som utför själva arbetet som ett CI-system delegerar till enheten, t.ex. kompilering av källkod och testning av kod. Byggservrar kan hanteras och ställas in med olika prioriteringsnivåer för byggen och utlösare (eng. triggers). Resurshantering (eng. resource management): Kontroll över diskanvändning, komprimering, lagring, säkerhetskopiering av data och övervakning av resursanvändning och tillståndet av CI-systemet Icke-Funktionella krav Icke-funktionella krav för ett CI-system beskriver hur systemet ska utföra funktioner. Här kommer några exempel på icke-funktionella krav för ett CI-system [17, 25-28, 42]: Prestanda (eng. performance): Prestanda är ett mått på hur snabbt ett CI-system agerar när det utför ett visst arbete. Exempel på olika typer av arbeten är uppstart av CI-systemet eller större moduler, återhämtning från fel, kommunikation med utomstående komponenter, bearbetning av anrop (eng. queries), stabil användning av GUI:t och byggning av källkod för projekt. Användbarhet (eng. usability): Användbarhet för ett CI-system avser huruvida god eller dålig interaktionen mellan användare och systemet är, alltså hur lätt det är att använda sig av systemet som användare. Ett användbart CI-system är ett system som stödjer användarens inlärningsprocess och gör det lätt för användaren att vänja sig vid gränssnittet och använda den på ett effektivt sätt, t.ex. kan detta göras genom att följa en standard för var vissa knappar ska ligga och användas, användaren kan då intuitivt lära sig använda CI-systemet eftersom GUI:t liknar många andra system. Ett användbart system ökar också feltolerans (dvs. det är svårt att begå kritiska fel som påverkar större delar av systemet och inte går att ångra). Utbyggbarhet (eng. extensibility): Ett CI-system ska vara lätt att utvidga och modifiera. Utvecklare av CI-system måste därför se till att tillgodose ett gränssnitt eller API för tredjepartsutvecklare så att CI-systemet kan modifieras men så att denna modifikation ej påverkar CI-systemets robusthet på ett negativt sätt. Tillförlitlighet (eng. reliability): Ett tillförlitligt CI-system har förmågan att kontinuerligt utföra funktioner, uppgifter och vara tillgänglig för att utföra diverse tjänster på begäran av klienter eller användare. Detta ska kunna ske under en längre tid utan avsevärda försämringar eller fel som uppstår pga. att systemet hålls i drift. Dessutom ska systemet vara funktionellt även om delsystem eller beroende komponenter (eng. dependencies) fallerar. Stabilitet (eng. stability): Med stabilitet menar man CI-systemets förmåga att vara robust under en längre tid av användning men även att modifiering av systemets periferi- och kärnkomponenter inte ska påverka systemets prestanda. Tillgänglighet (eng. availability): Ett CI-system som är tillgängligt är ett system som kan interagera med klienter eller användare under en längre tid och har en låg stilleståndstid (eng. downtime). Ett CI-system med hög drifttid (eng. uptime) är tillgängligt och möjliggör användare att få tillgång till information eller resurser på Sida 22
30 begäran. Med tillgänglighet menas även om ett CI-system endast kan nås från en viss plats (inom ett visst nätverk) eller om det kan nås via internet. Skalbarhet (eng. scalability): Skalbarhet är en egenskap hos ett CI-system som beskriver dess förmåga att hantera och prestera under en ökad eller växande arbetsbörda. Exempelvis kan skalbarhet syfta på förmågan hos ett CI-system att öka sin prestanda och bearbeta en viss arbetsbörda snabbare när man utökar resurserna som CI-systemet har att tillvarata. Detta kan antingen göras genom att byta ut gamla eller slitna komponenter mot nya för en centraliserad server (t.ex. lägga till RAMminne eller installera ett bättre CPU), eller att använda sig av decentraliserad bearbetning av arbetsbördan, dvs. en fördelning av arbetsbördan (eng. load balancing). Återhämtning (eng. recoverability): Ett CI-system med en fungerande återhämtningsförmåga kan återställas till ett fungerande tillstånd om ett kritiskt fel skulle inträffa. Systemet måste ha en förmåga att säkerhetskopiera och utföra vissa uppgifter på ett tillförlitligt sätt och utan att orsaka kostnadsförluster. Effektivitet (eng. efficiency): Ett effektivt CI-system använder resurser på ett effektivt sätt, dvs. en överanvändning av resurser sker inte relativt med den arbetsbördan som tilldelats till systemet. Systemet har en förmåga att bl.a. tilldela minne till olika processer, fördela processorkraft mellan olika processer och att förbruka ström på ett effektivt sätt Hur ställer man upp krav för system? Under kravhanteringsprocess eng. requirements engineering process kan olika tekniker användas för att hjälpa utvecklare att ställa upp krav för ett system. Några av de tekniker beskrivs av [17, s ] som följande: 1. Krav upptäckt (eng. requirements discovery): är en process för att samla in information om ett befintligt system, för att sedan kunna avgöra vilken målgrupp av användare som kommer att använda systemet och vilka krav som ställs på systemet enligt denna information. 2. Intervjuer (eng. interviewing): där utvecklare ställer frågor till systemanvändare kring deras system som kommer utvecklas. 3. Scenario (eng. scenarios): är en berättelse som beskriver på vilket sätt systemet kommer användas. 4. Användningsfall (eng. use cases): där systemet beskrivs med hjälp av flera grafiska modeller som UML-sekvens eller statiska diagram. Med andra ord, identifieras alla aktörer som kommer att interagera med systemet och deras roll i interaktionen beskrivs grafiskt. I vår studie har vi följt en undersökningsprocess (avsnitt 3), vi utförde en enkätundersökning (se avsnitt 3.1) där vi ställde några frågor kring CI-system till utvecklare och företagare som använder sig av CI-system för att samla in information kring krav för CI-system och vi skrev ett användbarhetsscenario (se avsnitt 4.4.4). Vi har således använt oss av requirement discovery, interviewing och scenarios teknikerna. Sida 23
31 4.1.4 Kravtest och utvärdering Det finns ett antal kravvalideringstekniker som kan användas för sig eller i kombination med varandra [17, s. 110], några av dessa beskrivs nedan: 1. Kravrecensioner (eng. requirements reviews). 2. Test-case generation. 3. Prototyping: Här demonstreras en körbar modell av systemet till slutanvändare (utvecklare, kunder) så att de kan experimentera med modellen för att se om den uppfyller deras verkliga krav samt identifiera eventuella problem och planera möjliga lösningar. Enligt E. Folmer, J. Gurp och J. Bosch har användbarhet (eng. usability) blivit en viktig faktor vid utveckling av programvara och har även visat sig vara avgörande för framgången av programvarusystem. Många mjukvaruprojekt har påvisat att programvara som har användbarhetsproblem inte kan anpassas utan större förändringar i programvarukonstruktionen. Att lösa användbarhetsproblem under senare faser av utvecklingsprocessen kostar tid, pengar och förhindrar utvecklare från att uppfylla alla användbarhetskraven vilket resulterar i system med mindre än optimal användbarhet. [43] Vår marknadsundersökning har påvisat att det icke-funktionella kravet användbarhet är ett av de viktigaste kraven som måste uppfyllas i ett CI-system och vi har därför valt att utvärdera CI-systemet TeamCity med avseende på användbarhet. Tekniken som vi har valt för att validera kravet användbarhet är prototyping med hjälp avanvändbarhetsscenario som beskrivs i avsnitt Vi har valt prototyping-tekniken för att den ger användare en möjligt att testa hur väl systemet stödjer deras arbete enligt krav som ställs på systemet. Tekniken hjälper även användaren att få fram nya idéer samt ser till så att man hittar starka och svaga sidor i systemet. Detta kan sedan leda till fastställandet av nya systemkrav. En funktion beskrivs ibland i en systemspecifikation som verkar vara användbar och väl definierad. Men när denna funktion kombineras med andra funktioner, så upptäcker användare ofta att deras ursprungliga uppfattning var felaktig eller ofullständig. [17] 4.2 Resultat från marknadsundersökningen Vår marknadsundersökning bestod av en enkät som innehåller 19 frågor varav 15 flersvarsfrågor och 4 fritextfrågor. Syftet med flersvarfrågorna var delvis att få kvantitativ svarsdata för en enklare behandling och delvis för att underlätta för deltagaren att svara på frågorna. Syftet med fritextfrågorna var att få rikare information och en bättre förståelse för hur utvecklarna identifierar och definierar minimala krav för CI-system dvs. kvalitativ svarsdata. Frågorna skickades via social medier som bl.a. LinkedIn, Twitter och Facebook, och var riktade till företagare och utvecklare som använder sig av CI-system. Resultat som vi fick utav marknadsundersökningen presenteras grafiskt och analyseras nedan. Sida 24
32 Analys av fråga 1 Enligt Goodman, Elbaz och [1, 2, 4-6] kom CI-system först till användning inom mjukvaruutveckling men har sen dess även använts i andra typer av verksamheter. För att ta reda på vilka verksamheter som använder sig av CI-system så ställde vi denna fråga. Svarsdatan pekar på att 74% av svarsobjekten anger att de använder sig av CI-system inom en Data/IT verksamhet, 13% Teknologi/Vetenskap, 5% Logistics/Transport och 3% Ekonomi/Finans samt 5% har andra verksamheter. Enligt svarsdatan så används CI-system mest inom Data/IT branschen. Analys av fråga 2 Fig. 6: Type of business För att veta hur stor verksamheten är som mest använder sig av CI-system så ställdes denna fråga. Av svaren som vi fick från svarobjekten i enkätundersökningen så kunde vi enligt EUkommissionens [44] definition benämna 21% som små företag där de har mindre än 50 anställda, 29% som medelstora företag som har anställda och 50% som stora företag med fler än 250 anställda. Enligt svarsdatan är det huvudsakligen stora företag som använder sig av CI-system. Fig. 7: Size of the company Sida 25
33 Analys av fråga 3 För att få fram meningsfull svarsdata så försökte vi nå ut till ett stort antal företagare och utvecklare (ca 300) inom teknikbranschen som faktiskt använder sig av CI-system. För att säkerställa att enkäten besvaras av svarsobjekt som sysslar med CI-system ställde vi denna fråga. Svarsdatan påvisar att 97% av de som deltog i undersökningen använder CI-system Analys av fråga 4 Fig. 8: Companies that utilize CI-systems Vi ville undersöka hur stor andel av utvecklare i en verksamhet som använder sig av CIsystem. På så sätt kan vi få en uppfattning om CI-system påverkar hela eller endast några delar av arbetsprocessen i verksamheten. Vi har valt en 10% inkrementell ökningsskala vilket innebär att t.ex. svarsalternativ 1 = 10%, 5 = 50%, 10 = 100%. Svarsdatan visar att 41% av svarobjekten har svarat att 100% av andel utvecklare använder sig av CI-system i deras verksamhet. Enligt svarsdatan så påverkar CI-system hela arbetsprocessen hos de flesta verksamheter. Fig. 9: Percentage of developers that use or are affected by the CI-system Sida 26
34 Analys av fråga 5 Här undersöker vi vilken CI-systemmjukvara som används mest i näringslivet för att senare kunna använda oss av denna data i vår studie. Av de 39 svar som vi mottagit var det 41% som använder Jenkins, 32% använder TeamCity, 5% använder Cruise Control, 5% använder Bamboo, 5% använder Continua CI - FinalBuilder och resten 16% använder andra CIsystemmjukvaror som inte finns med på listan. Alltså enligt svarsdatan så är det Jenkins som är mest känd CI-system ute på marknaden. Analys av fråga 6 Fig. 10: CI-system software that is used in the company För att kunna kategorisera främsta fördelarna av CI-system och förstå vad utvecklarna gillar och föredrar i deras system ställdes den frågan. Alltså tyckte de flesta enligt svarsdatan att deras CI-system var lätt att använda. Fig. 11: Main advantages with your CI-system Sida 27
35 Analys av fråga 7 Här frågade vi deltagarna att välja vad de ogillar i deras CI-system för att kunna kategorisera främsta nackdelarna av CI-system. De flesta anser att deras CI-system inte har några nackdelar. Analys av fråga 8 Fig. 12: Main disadvantages with your CI-system Av denna fråga försökte vi ta reda på hur ofta ett CI-system används hos olika verksamheter. Svarsdatan påvisar att CI-system används kontinuerligt hos de flesta verksamheterna. Fig. 13: Frequency of performing builds Sida 28
36 Analys av fråga 9 För att kunna veta hur lång tid CI-system brukar ta i olika verksamheter för att genomföra ett bygge ställdes denna fråga. Svarsdatan visar att det tar olika tid för olika CI-system i olika verksamheter att genomföra ett bygge på grund av olika faktorer som påverkar CI-system prestanda så som snabb mjukvara och gammal hårdvara osv. Tiden anges i HH:MM:SS format. Men de flesta som deltog i undersökningen angav att deras CI-system i snitt tar en timme för att genomföra ett bygge. Fig. 14: Time for your CI-system to build a project Analys av fråga 10 För att ta reda på om CI-system leder till bättre prestanda och produktionsvärde i en verksamhet [4-6] ställdes denna fråga. Svarsdatan visar att 97% av svarobjekten tycker att verksamhetens prestanda och produktionsvärde har ökat med hjälp av CI-system. Fig. 15: Company s performance after using CI-system Sida 29
37 Analys av fråga 11 För att ta reda på vilka huvudsakliga funktionella krav som ett CI-system brukar ha hos de flesta verksamheter ställde vi denna fråga. Frågan besvarades i fritext och vi fick därför ut rik kvalitativ information som behövdes tolkas. Efter tolkning grupperades och kvantifierades svaren. Diagrammet visar att de flesta svarsobjekt har angett: compile/build source code test feedback package/deployment Dessa krav kan sägas vara de huvudsakliga funktionella krav som ett CI-system ska uppfylla. Fig. 16: The basic functional requirements of a CI-system (qualitative sample) Sida 30
38 Analys av fråga 12 För att bekräfta fritextsvaret från fråga 11 gav vi svarsobjekt en möjlighet att besvara samma typ av fråga med hjälp av flersvar. Vi tänkte att bästa sätt att få svar på denna fråga var att låta svarsobjekten göra det åt oss genom att ange de funktionella krav de har för deras CI-system. Svarsdatan visar att de flesta som deltog i undersökningen valde: compiling/building source code test (unit test, static analysis) feedback Dessa kan påstås utgöra de minimala funktionella kraven för CI-system i enligt vår marknadsundersökning. Fig. 17: The basic functional requirements of your CI-system (quantitative sample) Sida 31
39 Analys av fråga 13 Vi ville inte bara veta vilka funktionella krav som svarsobjekten hade på CI-system utan även vilka av dessa krav som de ansåg var viktigast, därför ställde vi denna fråga. Ur diagrammet kan vi avläsa att de flesta ansåg att compile/build source code var det viktigaste kravet som måste uppfyllas, med bred marginal. Men även följande krav ansågs viktiga att uppfylla: VCS/SCM management testing provide feedback to developer Fig. 18: Most important functional requirements for this CI-system Sida 32
40 Analys av fråga 14 Samtliga svarsobjekt anser att deras CI-system uppfyller minimala funktionella krav (compiling/building source code, test, feedback). Fig. 19: Does your CI-system meet the minimum functional requirements? Analys av fråga 15 För att ta reda på vilka huvudsakliga icke-funktionella krav som ett CI-system brukar ha hos de flesta verksamheter ställde vi denna fråga. Frågan besvarades i fritext och vi fick därför ut rik kvalitativ information som behövdes tolkas. Efter tolkning grupperades och kvantifierades svaren. Diagrammet visar att de flesta svarsobjekt har angett performance usability och reliability. Dessa krav kan sägas vara de huvudsakliga icke-funktionella krav som ett CI-system ska uppfylla. Fig. 20: The basic non-functional requirements of your CI-system (qualitative sample) Sida 33
41 Analys av fråga 16 För att bekräfta fritextsvaret från fråga 15 gav vi svarsobjekt en möjlighet att besvara samma typ av fråga med hjälp av flersvar. Vi tänkte att bästa sätt att få svar på denna fråga var att låta svarsobjekten göra det åt oss genom att ange de funktionella krav de har för deras CI-system. Svarsdatan visar att de flesta som deltog i undersökningen valde: extensibility stability & reliability maintainability usability Dessa kan påstås utgöra de minimala icke-funktionella kraven för CI-system i enligt vår marknadsundersökning. Fig. 21: The basic non-functional requirements of this CI-system (quantitative sample) Sida 34
42 Analys av fråga 17 Vi ville inte bara veta vilka icke-funktionella krav som svarsobjekten hade på CI-system utan även vilka av dessa krav som de ansåg var viktigast, därför ställde vi denna fråga. Ur diagrammet kan vi avläsa att de flesta ansåg att usability var det viktigaste kravet som måste uppfyllas följt av maintainability. Även följande icke-funktionella krav anses vara viktiga: stability & reliability extensibility performance Fig. 22: Most important non-functional requirements for your CI-system Sida 35
43 Analys av fråga 18 De flesta som deltog i undersökningen tycker att deras CI-system uppfyller minimala ickefunktionella krav (extensibility, stability, reliability, maintainability). Fig. 23: Does your CI-system meet the minimum non-functional requirements? Analys av fråga 19 Den sista frågan var för att veta om de som deltog i undersökningen är intresserade för att ta reda på slutresultatet. Svarsdatan visar att de flesta tackade ja. Fig. 24: Respondent s desire to be notified of the final results Sida 36
44 4.3 Resultat från litteraturundersökning Litteraturundersökningen var en formell sammanställning och uppräkning av hur ofta vissa nyckelord förekommer i litteratur kring CI-system. Vi kategoriserade då nyckelord i funktionella krav, icke-funktionella krav och som ett tillägg avläste vi även omnämnandet av olika CI-server mjukvaror som vi sedan kan jämföra med de mjukvaror som nämndes i marknadsundersökningen. De flesta huvudfrågor och delfrågor från vår frågeställning besvaras av resultat från både litteratur- och marknadsundersökningen, det är därför viktigt att vi ställer liknande frågor och tittar efter liknande signaler från båda undersökningarna. Vi hänvisar läsaren till avsnitt för mer information kring utförandet av litteraturundersökningen. Se bilaga 3 för rådatan och uppställningen av litteraturundersökningen. I litteraturundersökningen har vi formellt avläst 10 webbartiklar, 2 böcker och 7 vetenskapliga artiklar [2, 5, 7, 9-16, 29-35] och spårat kopplingar mellan funktionella- och icke-funktionella krav. De flesta krav listade vi enligt [25-28], dock fanns det krav som kom till vår kännedom när vi läste igenom källorna, även dessa lades till i matrisen. Nedan redogör vi resultat för undersökningen som åskådliggörs grafiskt i diagram. Vi analyserar även resultaten och kan ibland tolka resultaten. Sida 37
45 Funktionella krav som omnämns i litteraturen Vi undersökte vilka funktionella krav som nämns i litteraturen och fick fram nedanstående resultat. Det visar sig att följande funktionella krav omnämns mest: Källkodshantering (eng. source code management) Kompilering av källkod (eng. build source code) Körning av tester (eng. run tests) Notifiering [av status för bygge] (eng. feedback & notifications) Vi kan även se att andra funktionella krav är betydande men nämns inte lika ofta: Möjliggörandet av byggautomatisering (eng. enable automation) Förse infrastruktur som möjliggör upprepbara byggen (eng. provide infrastructure for repeatable builds) Distribution [av mjukvara] (eng. deployment) Ovanstående funktionella krav nämns ofta som betydelsefulla funktioner för CI-system i litteraturen. Fig. 25: Functional requirements Sida 38
46 Icke-funktionella krav som omnämns i litteraturen Vi undersökte även vilka icke-funktionella krav som nämns i litteraturen. Följande icke-funktionella krav omnämns mest: Prestanda (eng. performance) Användbarhet (eng. usability) Flyttbarhet (eng. portability) Interoperabilitet (eng. interoperability) Vi kan på diagrammet se rätt stora gap mellan de icke-funktionella krav som nämns mest och de som nämns mer sällan. En till sak som är viktig att påpeka är att icke-funktionella krav ofta inte nämns explicit utan genom förväntningar, t.ex. att ett CI-system ska bygga källkod snabbt vilket tyder på ett prestandakrav. En indelning av dessa förväntningar är i vissa fall överlappande eller tvetydig. Hur vi gjort kan närmare granskas i matrisen för litteraturundersökningen (se bilaga 3). Fig. 26: Non-functional requirements Sida 39
47 CI-server mjukvara som omnämns i litteraturen Slutligen undersökte vi även vilken CI-server mjukvara som nämns i litteraturen och hur ofta mjukvaran omnämns. Vi kan på nedanstående diagram se att följande CI-server mjukvaror nämns mest i litteraturen: CruiseControl och dess varianter Jenkins Hudson Bamboo TeamCity Buildbot Kanske är det inte så förvånande att CruiseControl är mest omnämnt i litteraturen om tar hänsyn till att den första versionen av CruiseControl släpptes under början av Dock kan man undra varför AnthillPro som även det släpptes 2001 inte är mer omnämnt i litteraturen. Här kan det handla om allt från en diskrepans i marknadsföring mellan de två mjukvarorna till att utvecklare har lättare att ta till sig CruiseControl, denna diskussion är dock utanför ramarna för vår studie. Något annat som är av intresse med denna data är att TeamCity inte nämns lika ofta som t.ex. Jenkins, Hudson eller till och med Bamboo i litteraturen. Detta trots att TeamCity, enligt vår marknadsundersökning, anses användas av ca 32% av tillfrågade utvecklare, där 42% uppges använda Jenkins men endast 5% uppges använda Bamboo. Fig. 27: CI-server software Sida 40
48 4.4 Användbarhetstestning Vi gick tidigare igenom ett antal icke-funktionella krav, däribland det icke-funktionella kravet användbarhet (eng. usability). Under senare delar av examensarbetet ställde vi upp ett användbarhetstest och mätte användbarheten för TeamCity, men innan resultatet för dessa mätningar och slutsats kan dras måste vi gå igenom vad som menas med användbarhet och hur ett användbarhetstest ställs upp Kategorisering av användbarhet via användbarhetsattribut Användbarhet har enligt Folmer, Gulp och Bosch att göra med hur enkelt det är för slutanvändaren att utföra en viss uppgift med hjälp av systemet och på vilket sätt systemet stödjer denna process. I vår studie vill vi ta reda på hur lätt det är för slutanvändaren att utföra en rad olika nyckelfunktioner som stöds av de flesta CI-system (enligt litteraturundersökning och marknadsundersökning). Det finns olika sätt att kategorisera användbarhet. Nedan följer Folmer, Gulp och Bosch kategoriseringen med hjälp av användbarhetsattribut [43, 45]: Lärbarhet (eng. learnability) - Hur snabbt kan en användare komma igång med att använda ett system som hon inte har använt tidigare, samt hur lätt det är för användaren att minnas hur man använder sig av systemet Effektiv användning (eng. efficiency of use) - Antalet uppgifter användaren kan utföra under en viss tid med hjälp av systemet Tillförlitlighet (eng. reliability) - Andelen fel som uppstår när man använder sig av systemet och hur lång tid det tar att återhämta sig från fel Tillfredsställelse (eng. satisfaction) - Användarens subjektiva åsikt kring användandet av systemet Vi kommer dock att kategorisera användbarhet enligt Bass kategorisering av huvudområden för scenarion [46] som beskrivs nedan, men använder oss även av vissa ovanstående användbarhetsattribut för att få ett helhetsperspektiv utifrån testarens synpunkt (detta redogörs i avsnitt 4.4.6) Kategorisering av användbarhet via huvudområden Bass [46] använder sig av ett annat sätt att kategorisera och strukturera användbarhet så att det kan testas. Vi använde oss främst av detta sätt att kategorisera användbarhet när vi ställde upp användbarhetstestet. Huvudområden som betecknar användbarhet [46]: Inlärning av systemets funktioner (eng. Learning system features) - På vilket sätt hjälper systemet användaren att bli bekant med systemets olika funktioner och hur man använder sig av dessa? Har CI-systemet ett tydligt (grafiskt) gränssnitt som gör det lätt för framförallt nya användare att snabbt lära sig använda systemet. Effektiv användning av systemet (eng. Using a system efficiently) - Hur kan systemet hjälpa användaren att utföra uppgifter på ett mer effektivt sätt. Sida 41
49 Här kommer vi att titta på om CI-systemet har effektiva sätt att automatisera och skapa genvägar för processer som ofta används och därför bör vara ytterst effektiviserade. Minimera inverkan av fel (eng. Minimizing the impact of errors) - Vad kan systemet göra för att avvärja användarfel. Vad händer om användaren råkar ta bort eller modifiera kritiska komponenter av utvecklingsinfrastrukturen? Har systemet dialogrutor eller säkringar som kan motverka kritiska fel? Anpassning av systemet för användarens behov (eng. Adapting the system to user needs) - Hur kan systemet anpassas för att bli mer användbart för användaren? Vi kommer att titta på om tidigare utförda operationer och händelser i systemet påverkar användarupplevelsen. Vi tittar även på om gränssnittet kan ändras till användarens fördel. Inge förtroende och tillfredsställelse (eng. Increasing confidence and satisfaction) - Hur bekräftar systemet för användaren att denne utfört önskvärd åtgärd? Vi tittar efter bekräftelsedialoger och andra indikationer som förmedlar förändringar av systemets tillstånd till användaren Indelning av beståndsdelar för användbarhetsscenario När man väl definierat vad som menas med användbarhet kan man övergå till att beskriva hur användbarhet ska mätas. Bass anger ett användbarhetsscenario (eng. usability scenario) som kan delas upp i ett antal beståndsdelar. Dessa beståndsdelar påvisar omständigheterna och avgränsningar för mätningen av användbarhet för ett visst system. Användbarhetsscenariot kan avgränsas och delas upp i följande beståndsdelar: Källa för indata (eng. source of stimulus) - Källan för indata är en självständig entitet och kan vara allt från en individ till ett datorsystem eller annan typ av självständig aktör. I fallet med användbarhetstestning (eng. usability testing) är användaren källan för indata. Indata (eng. stimulus) - Indata är en omständighet, villkor eller önskemål som måste övervägas när denna når mottagaren. I fallet med användbarhetstestning är indatan kategoriserat enligt de huvudområden som beskrevs i avsnitt Användaren vill alltså lära sig systemets funktioner, effektivt kunna använda systemet, minimera inverkan av fel, anpassa systemet för sina behov och känna förtroende och tillfredsställelse med användningen av systemet. Mottagare (eng. artifact) - En mottagare för indatan måste identifieras. Detta kan antingen vara hela systemet eller en del av systemet. I fallet med användbarhetstestning är det hela systemet. Sida 42
50 Miljö (eng. environment) - Utskick av indata och mottagandet av denna sker i en viss miljö och under vissa omständigheter. Exempelvis kan systemet vara i ett tillstånd av överbelastning, normalkörning eller i ett avstängt tillstånd. Andra typer av tillstånd kan även äga rum. I fallet med användbarhetstestning sker relevanta händelser vid körtid eller vid konfiguration av systemet (så som t.ex. installation av systemet). Interaktioner med systemet innan dess räknas till interaktioner mellan utvecklare och systemet och kan därför inte innefattas i detta scenario. Respons (eng. response) - Respons är den händelsen som sker efter att indatan tagits emot och behandlats av mottagaren. I fallet med användbarhetstestning förväntas systemet kunna uppfylla användarens behov genom att förse henne med programfunktioner som möjliggör utförandet av önskvärda uppgifter. Detta återspeglas via responsen som genereras. Mätning av respons (eng. response measure) - När responsen genereras måste denna mätas på något sätt för att systemet ska kunna kravtestas och för att man ska kunna fastställa om systemet besvarat indatan med rätt typ av respons. Responsen i användbarhetstestning kan mätas på ett antal olika sätt: [47-48] Tiden det tog (eng. task time) för användaren att utföra en viss uppgift Antalet fel som uppstod Antalet problem som användaren löst Användarens tillfredsställelse med hur uppgiften löstes mha. systemet Kunskapsökning, känner användaren att hon förstått hur man använder systemet för att utföra specifika uppgifter? Förhållandet mellan antalet lyckade operationer och totala antalet operationer som utförts Hur mycket tid/data gick förlorat när ett fel inträffade (vare sig felet orsakades av systemet eller användaren är ej relevant i detta mätningsfall) I utförandet av användbarhetstestet kommer vi att välja några av dessa mätningar av respons som vi anser är mest relevanta för vår studie. Sida 43
51 4.4.4 Uppställning av användbarhetsscenario Vi utgick från Bass kategorisering av användbarhet och beskrivning av användbarhetsscenario när vi ställde upp vårt scenario [46, s. 106]. CI-systemet TeamCity testades utifrån detta scenario: Beståndsdel av scenario Värden Källa för indata Indata Mottagare Miljö Respons Användare Vill Lära sig systemets funktioner Effektivt kunna använda systemet Minimera inverkan av fel Anpassa systemet för sina behov Känna förtroende och tillfredsställelse med användningen av systemet CI-system (TeamCity) Normalkörning CI-systemet förser användaren med följande responser: 1. För att stödja Inlärning av systemets funktioner : GUI:t är tydligt och lättanvänt GUI:ns design är baserad på progressive disclosure 2. För att stödja Effektiv användning av systemet : Det är enkelt att automatisera funktioner som ofta kommer att användas t.ex. konfiguration av byggskript Återanvändning av data/kommandon som tidigare inmatats 3. För att stödja Minimera inverkan av fel : Dialogrutor och säkringar inför mer omfattande operationer Möjlighet att ångra (eng. undo) ändringar 4. För att stödja Anpassning av systemet för användarens behov : Systemets utseende och funktionalitet kan ändras utifrån användarens behov 5. För att stödja Inge förtroende och tillfredsställelse : Systemets tillstånd åskådliggörs tydligt för användaren Större ändringar bekräftas genom t.ex. bekräftelsedialoger Mätning av respons Tid för att utföra en uppgift (eng. task time) Antalet problem som användaren löst Användarens tillfredsställelse med hur uppgiften löstes Sida 44
52 4.4.5 Uppställning av testformulär och användarenkät Baserat på användbarhetsscenariot ovan har vi utformat ett testformulär (se bilaga 6) som vi fyller i för att sammanställa svarsdata från testaren efter utförandet och inspelning av test. Eftersom vissa svar endast kan besvaras av testaren själv och ej observeras via inspelning av test har vi även utformat en användarenkät (se bilaga 7) som testaren fyller i under testets gång. I testformuläret har vi delat upp uppgifter enligt de responser och huvudområden som anges i användbarhetsscenariot. Uppgifterna är inte specifika för något enskilt CI-system och kan därför tillämpas på såväl TeamCity som andra CI-system. Vi har dessutom sett till att funktionella krav som anses viktiga enligt litteratur- och marknadsundersökningarna innefattas i testformuläret. Vi har exempelvis med uppgifter där testaren ska bygga källkod för Java-projektet som vi skapade eller köra tester för Java-projektet, detta eftersom exempelvis bygge av källkod och testning framgått som viktiga funktionella krav för CIsystem (se avsnitt 5 för slutsatser kring viktiga funktionella och icke-funktionella krav för CIsystem). Med hjälp av inspelningen av testsessioner kan vi fylla i tiden som förflöt när testaren utförde en viss uppgift (eng. task time) samt kontrollera om uppgiften löstes korrekt. I testformuläret fylls även in svarsdata från användarenkäten som endast kan besvaras av testare, t.ex. tillfredsställelse av att lösa en viss uppgift. Den andra större dokumentationsartefakten för användbarhetstestning var som nämnt användarenkäten. Denna fylldes i under testets gång av testaren. Användarenkäten är TeamCity-specifik och kan till skillnad från testformuläret inte användas för andra CI-system, den måste i sådant fall skrivas om. Trots detta anknyter den till testformuläret och användbarhetsscenariot på ett sådant sätt att man kan påstå att den konkretiserar riktlinjer angivna i dessa artefakter så att de kan tillämpas på TeamCity på ett testbart sätt. I denna form fyllde testaren bland annat i hur hon upplevde att lösa specifika uppgifter med hjälp av systemet. Vi var noggranna med att endast inkludera frågor i användarenkäten som inte kan besvaras via observation. Användarenkäten var inte endast till för att fyllas i av testaren under testsessionens gång, utan här fanns även all information beskriven för att testaren ska kunna utföra uppgifterna i TeamCity. En detalj som är värd att nämna är att ordningen på uppgifterna är strukturerad och optimerad för att minimera förvirring under utförandet av uppgifter och minska tiden för att utföra testet för samtliga testare, ordningsföljden beskrivs i testformuläret. För att anknyta till kategorisering av användbarhet enligt Folmer, Gulp och Bosch lade vi även till 4 korta frågor i slutet av användarenkäten som testaren svarar på för att delge sin uppfattning om TeamCity enligt dessa 4 kategorier. Sida 45
53 4.4.6 Resultat från användbarhetstestning I detta avsnitt redovisas de resultat som vi fick fram av användbarhetstestet och analysen av svarsdatan från testerna som utfördes. Användbarhetstestet är också av betydelse för att svara på vår andra huvudfråga, om man kan testa, jämföra och värdera CI-system. I just denna studie kommer vi inte att utföra användbarhetstestet på flera olika CI-system men det är något som kan vara intressant att utföra (se avsnitt 6.3 fortsatt forskning ). Bilaga 6 påvisar hur vi samlat och sammanställt data som kommer att presenteras grafiskt i form av diagram. Bilaga 7 är användarenkäten som användes för att samla in denna data och agerar som ett gränssnitt mellan oss och testare. Läsaren hänvisas till dessa bilagor för att ta del av mer utförlig information kring genomförandet av användbarhetstester. Resultatdatan som kommer att presenteras i detta avsnitt berör olika aspekter av användbarhetstestet som vi tycker är extra intressanta att titta på. Olika statistik kring utförandet av testerna samt testarnas subjektiva intryck av att lösa uppgifter och av TeamCity i sin helhet kommer att åskådliggöras. Samtliga diagram belyser skillnader mellan testgruppen som bestod av 5 testare och kontrollgruppen som bestod av 1 testare. Vi analyserar resultaten som redogörs och kan i vissa fall även tolka resultaten. Varje diagram förses med en förklaring till hur mätningen genomfördes och ibland även en förklaring till varför vi mätte just detta. Därefter följer en saklig redogörelse av hur datan som presenteras i diagrammen ska avläsas, följt av en subjektiv tolkning av datan där detta är möjligt. Sida 46
54 Totalt antal uppgifter som löstes Vi kontrollerade hur många uppgifter av totalt 17 st som löstes av testare efter varje testsession via användarenkäten och inspelningar. En del testare ansåg sig vara klara med vissa uppgifter men det framkom efter granskning av inspelning att detta inte stämde, vi korrigerade svarsdatan utefter vår uppfattning om huruvida uppgiften löstes korrekt eller ej. Vi kan på nedanstående stapeldiagram avläsa att kontrollgruppen löste alla 17 uppgifter medan testgruppen löste nästan alla 17 uppgifter. Testgruppen hade 16.4 uppgifter lösta i snitt vilket innebar att 3 fel uppstod under de 5 testsessionerna. Varför testgruppen inte lyckades lösa alla uppgifter är svårt att avgöra utifrån den data som vi samlade in, det kan antingen bero på att användarenkätens uppgiftbeskrivning för vissa uppgifter var otydlig eller yttre faktorer som att TeamCity i vissa fall är så användarvänlig och layout-mässigt anpassad för att stödja nya användare att utföra vissa operationer. Eftersom felen uppstod bland 3 olika uppgifter (uppgift 3, 4 och 14) är det mer sannolikt att det har att göra med interaktionen mellan testare och TeamCity snarare än ett allmänt fel i utformandet av användarenkäten. Vi menar att ett fel i användarenkäten hade kommit till uttryck om olika testare begick samma fel under utförande av testet (dvs. om felet uppstod på samma uppgift). Uppgifterna i vilka fel uppstod tillhör huvudområdena Anpassning av systemet för användarens behov, Inlärning av systemets funktioner och Inge förtroende och tillfredsställelse. Trots vår diskussion om de 3 felen som uppstod kan vi konstatera att det nästan perfekta resultatet för antal korrekt utförda uppgifter tyder på att TeamCity stödjer lärbarhet för användare som aldrig använt systemet tidigare. Fig. 28: Totalt antal uppgifter som löstes Sida 47
55 Total tid för utförande av samtliga uppgifter Vi tittade inte bara på hur många uppgifter som löstes, vi tittade även på hur lång tid det tog för testarna att utföra alla uppgifter. Vi gjorde detta genom att gå igenom inspelningarna av testsessionerna och kolla hur lång tid det tog för varje testare att gå vidare till nästa uppgift, från att uppgift 1 påbörjades till att uppgift 17 avslutades. Vi ser intressant data i nedanstående stapeldiagram (jämfört med diagrammet för totalt antal uppgifter som löstes ). Kontrollgruppen genomförde samtliga uppgifter på 20 minuter och 19 sekunder, medan testgruppen utförde uppgifterna på 43 minuter och 18 sekunder. Vi ser därför en markant skillnad mellan oerfarna TeamCity användare och erfarna användare med avseende på hur snabbt vissa operationer kan utföras i TeamCity. Att kontrollgruppen utförde samtliga uppgifter betydligt snabbare än testgruppen tyder på att TeamCity stödjer användbarhetsattributet effektiv användning. Fig. 29: Total tid för utförande av samtliga uppgifter Sida 48
56 Användarnas tillfredsställelse av att lösa samtliga uppgifter Efter varje utförd (eller outförd) uppgift angav testaren hur han eller hon upplevde att uppgiften löstes. Detta gjordes utefter en Likert skala där 1 innebär en låg tillfredsställelse med utförandet av en viss uppgift och 5 innebär hög tillfredsställelse. I stapeldiagrammet kan vi avläsa en relativt hög nivå av tillfredsställelse för båda grupperna, dock ser vi att testgruppen var aningen mindre tillfredsställd i genomsnitt. Detta beror förmodligen på att testarna i testgruppen inte alltid visste hur de ska göra för att lösa vissa uppgifter. Vi kan också efter granskning av testformuläret se en korrelation mellan missnöje och misslyckande av utförandet av specifika uppgifter. Om vi tittar på kontrollgruppen kan vi se att testaren angivit nivå 5 av tillfredsställelse på samtliga uppgifter förutom uppgift 1, 6 och 11. Dessa uppgifter tillhör huvudområdet Inlärning av systemets funktioner. Om vi istället tittar på testgruppen kan vi se att testarna angivit en hög nivå av tillfredsställelse med 5,0 i snitt för uppgift 8 och 13. En låg nivå av tillfredsställelse kan vi avläsa för uppgift 4 med 2,8 i snitt. Uppgifterna med ett högt utslag tillhör huvudområdena Inlärning av systemets funktioner och Minimera inverkan av fel. Beträffande uppgiften med lågt utslag tillhör den huvudområdet Anpassning av systemet för användarens behov. Vi kan se att på det stora hela verkar TeamCity stödja användbarhetsattributet tillfredsställelse. Det verkar dock finnas rum för förbättring när det gäller användarens tillfredsställelse och upplevelse av hur pass anpassningsbart systemet är för användarens behov. Fig. 30: Användarnas tillfredsställelse av att lösa samtliga uppgifter Sida 49
57 Total tid för utförandet av enskild uppgift Under efterbehandligsfasen av testsessionerna tittade vi på hur lång tid det tar för varje testare att utföra varje enskild uppgift. Startpunkt och slutpunkt markerades när testaren påbörjade en ny uppgift i användarenkäten genom att gå till nästa sida. På så sätt kunde vi ta tidspunkter på ett objektivt sätt istället för att gissa oss fram till när en viss uppgift påbörjades eller avslutades. Vissa testare kommunicerade även med oss mellan utförandet av uppgifter, detta noterades och räknades bort för att inte driva upp datan till högre nivåer pga. dessa pauser. Vi kan väldigt tydligt se från linjediagrammet att kontrollgruppen låg snäppet under testgruppen vad gäller snabbheten i att utföra uppgifterna. Dock kan vi se att genomsnittstiden för utförandet av enskild uppgift för testgruppen var aningen lägre på 1 minut och 10 sekunder jämfört med 1 minut och 16 sekunder för kontrollgruppen. Vad detta kan bero på är svårt att fastställa, dock kan vi konstatera att det har att göra med uppgiften Kompilera källkod för ett projekt som tillhör responsen Det är enkelt att automatisera funktioner som ofta kommer att användas och huvudområdet Inlärning av systemets funktioner. Fig. 31: Total tid för utförandet av enskild uppgift Sida 50
58 Tidigare erfarenhet av CI-system Till skillnad från tidigare redovisad resultat så presenterar vi via detta stapeldiagram inte mätningar. Vi redogör här hur testarna har svarat när de tillfrågades vilken tidigare erfarenhet de har av CI-system och vilken CI-systemmjukvara de har använt sig av. Som nämnt i utförandet av användbarhetstestet så var målgruppen för testerna användare som både hade erfarenhet av CI-system tidigare men ej av TeamCity och användare som tidigare använt sig av TeamCity. Detta åskådliggörs rätt tydligt i stapeldiagrammet då vi ser att endast testaren från kontrollgruppen angav att han hade erfarenhet av TeamCity. Han angav även erfarenhet av CruiseControl.net. Slutligen vill vi även påpeka att tidigare erfarenhet av CI-system kan ha en betydelse för olika statistik och data som erhålls från denna typ av användbarhetstest. Det kan vara så att Jenkins är likt eller olikt till användning och utseende som TeamCity. Detta innebär att inlärningskurvan för TeamCity kan bero på vilken tidigare erfarenhet av CI-system man har, därför är detta viktigt att belysa och ta hänsyn till både i vår studie och liknande studier, genom att exempelvis ställa motsvarande fråga i andra enkäter. Fig. 32: Tidigare erfarenhet av CI-system (båda grupper) Sida 51
59 Hur pass väl stödjer TeamCity Lärbarhet? Som tidigare nämnt så använder vi oss av 4 användbarhetsattribut för att fastställa vilket intryck testarna har av TeamCity. Vi börjar med att diskutera lärbarhet. Lärbarhet har att göra med hur snabbt användaren lär sig använda systemet och hur lätt det är att minnas hur man använder systemet. Vi kan från diagrammet avläsa att kontrollgruppen angav den högsta nivån för lärbarhet. Kanske beror detta på att denna testare redan är bekant med hur TeamCity används och därför även anser att nya användare kommer att snabbt kommer att lära sig hur man använder TeamCity. Om vi tittar på testgruppen kan vi se att de allra flesta svarat att de anser att TeamCity stödjer lärbarhet. Denna data är aningen mer intressant att titta på, främst pga. dessa testare uppgav att de inte använt TeamCity tidigare. Detta tyder på att nya användare efter utförandet av 17 uppgifter tycker att TeamCity är ganska bra på att lära användaren hur man kommer igång med användningen av CI-systemet. Fig. 33: Hur pass väl stödjer TeamCity Lärbarhet? Sida 52
60 Hur pass väl stödjer TeamCity Effektiv användning? Effektiv användning av ett system innebär att en användare snabbt kan utföra operationer i systemet och kan effektivisera det han eller hon genomför med hjälp av systemet ju mer bekant han eller hon blir med användandet av systemet. Resultatdatan som åskådliggörs via diagrammet påvisar även här att de flesta testare har en uppfattning om att TeamCity stödjer effektiv användning. Till skillnad från föregående diskussion om lärbarhet, är det mer betydelsefullt att belysa kontrollgruppens uppfattning av effektiv användning. Detta eftersom en testare med tidigare erfarenhet av TeamCity förmodligen har använt systemet under en viss tid och kan därför ha en uppfattning om TeamCity håller i längden. Om vi tittar på testgruppen kan vi se att de flesta angett nivå 4 för just detta användbarhetsattribut. Både testare 4 och 5 har angett att TeamCity stödjer effektiv användning trots att deras totala tid för utförandet av uppgifterna hörde till de längre tidtagningarna. Tolkning: Att de markerat nivå 5 kan bero på att de under testets gång ansåg att det gick fortare framåt när de lärde sig använda systemet bättre, men kanske också pga. testsessionen var så pass långt gången att de snabbt ville fylla i den sista sidan i användarenkäten och bli klara med testsessionen. Fig. 34: Hur pass väl stödjer TeamCity Effektiv användning? Sida 53
61 Hur pass väl stödjer TeamCity Tillförlitlighet? Ett system som är tillförlitligt är ett system utformat på så sätt att en användarens interaktion med systemet genererar ett lågt eller obefintligt antal fel vid normalt bruk. Tillförlitlighet innebär även att ett system snabbt kan återhämta sig från fel som kan uppstå. Som vi kan se på diagrammet nedan så har samtliga testare angett högsta nivå för att påvisa att TeamCity stödjer tillförlitlighet. Detta är rätt ointressant data att diskutera eftersom det inte finns någon variation, dock kan vi konstatera att TeamCity är ett tillförlitligt system utifrån denna data. En intressant sak som vi kan påpeka är testare 3 s svar på frågan. Denna testare angav att han inte hade tillräckligt med erfarenhet av TeamCity för att dra denna slutsats och att ytterligare användning av TeamCity krävs för att på ett bestämt sätt kunna fastställa om TeamCity faktiskt är tillförlitligt. Fig. 35: Hur pass väl stödjer TeamCity Tillförlitlighet? Sida 54
62 Hur pass väl stödjer TeamCity Tillfredsställelse? En användares tillfredsställelse med ett system är hur denna individ subjektivt upplever användningen av systemet. Som nämnt har testaren efter varje uppgift svarat på hur tillfredsställd han eller hon är med hur uppgiften löstes. Även på slutet av användarenkäten frågar vi testaren hur tillfredsställd han eller hon är med TeamCity i stort. Vi kan även i detta diagram se en homogenitet mellan svarsdatan där endast små avvikelser förekommer. De allra flesta testare har angett nivå 4 av tillfredsställelse för TeamCity. Ännu en intressant sak som kan påpekas är testare 2 s svar för denna fråga där testaren angett att en längre tid med användandet av CI-systemet krävs för att kunna fastställa om TeamCity är tillfredsställande att användas. Fig. 36: Hur pass väl stödjer TeamCity Tillfredsställelse? Sida 55
63 5. Slutsats Vår frågeställning bestod av 2 huvudfrågor och 4 delfrågor (se avsnitt 1.3). Efter genomförd marknadsundersökning och litteraturundersökning kan vi dra en slutsats kring vad ett CI-system principiellt bör bestå av, vilka funktioner den bör förse användaren med samt vilka kvalitetsattribut som bör eftersträvas. Svaren till vår första huvudfråga Vilka funktionella och icke-funktionella krav måste CIsystem uppfylla för att vara till nytta för användning? är följande: Funktionella krav: Källkodshantering (eng. source code management) Kompilering av källkod (eng. build/compile source code) Exekvering av byggskript (eng. running arbitrary build scripts), med möjlighet till byggautomatisering (eng. enable build automation) Körning av tester (eng. run tests) Notifiering av status för bygge (eng. feedback/notification of build status) Stöd för paketering och distribution av mjukvara (eng. support deployment of stable software) Icke-funktionella krav: Prestanda (eng. performance) Användbarhet (eng. usability) Tillförlitlighet (eng. reliability) Utbyggbarhet (eng. extensibility) Stabilitet (eng. stability) Underhållsmässighet (eng. maintainability) Efter genomförd användbarhetstest kan vi även besvara vår andra huvudfråga och därmed validera en del av den slutsats vi fått fram via första huvudfrågan. Vår andra huvudfråga Kan man enligt fastställda krav testa, värdera och jämföra CIsystem? besvaras positivt via de resultat som vi redogör i avsnitt Genom en utvärdering av användbarhet för CI-systemet TeamCity demonstrerade vi detta praktiskt. Genom att använda sig av testformuläret som vi fick fram under utförandet av användbarhetstestet och genom att modifiera användarenkäten för ett annat CI-system kan man även utföra användbarhetstestet för andra CI-systemmjukvaror. Sida 56
64 Delfråga 1 Vilken mjukvara för CI-system används mest? besvaras av både litteraturundersökningen och marknadsundersökningen. Enligt undersökningarna kom vi fram till följande: Litteraturundersökningen pekar på: CruiseControl och dess varianter Jenkins Hudson Bamboo TeamCity Buildbot Marknadsundersökningen pekar på: Jenkins TeamCity CruiseControl och dess varianter nämns fortfarande i litteratur och är en väletablerad CIserver mjukvara som funnits i över 10 år. Hudson som senare blev Jenkins har en stor marknadsandel och nämns även den i litteraturen. TeamCity nämns inte så ofta i litteratur, däremot visar marknadsundersökningen att även den har en stor marknadsandel. Vi kan dra slutsatsen att Jenkins används mest, tätt följd av TeamCity men att även andra CI-server mjukvaror så som CruiseControl nämns i litteraturen och säkerligen används än idag. Delfråga 2 Vilka för- och nackdelar finns det för ett CI-system? besvaras av marknadsundersökningen och diskuteras även i avsnitt 2.4. Med hjälp av denna fråga vill vi ta reda på vad som utmärker vissa CI-system från andra och vad det är som gör att en grupp utvecklare väljer att använda ett CI-system över ett annat. Vi tittar också på eventuella nackdelar som utvecklare tycker att deras CI-system har. Svarsobjekten för marknadsundersökningen har angivit att de främsta fördelarna med deras CI-system är att det är lättanvänt, stabilt och tillförlitligt. När svarsobjekten tillfrågades om nackdelar med deras CI-system var det en signifikant andel som inte kunde identifiera någon betydlig nackdel. Om vi däremot tittar på de svarsobjekt som identifierade nackdelar med sitt CI-system nämnde de svårigheter med att felsöka, en hög kostnad (av att sätta upp och underhålla systemet) och instabilitet. Andra nackdelar specificerades också men dessa nämns ej här. Delfråga 3 Hur pass utbredd är användningen av CI-system bland utvecklare inom företag som använder sig av dessa system? besvaras av marknadsundersökningen (se analys av fråga 4). 41% av svarsobjekten svarade att 100% av deras utvecklare använder sig av CIsystemet och övriga svarsobjekt anger att ca % av utvecklare på företaget påverkas av CI-systemet. Endast tre svarsobjekt utav 39 svarade att CI-systemet endast påverkar 10%, 30% resp. 50% av deras verksamhet, där de resterande angav en större andel utvecklare Sida 57
65 som påverkas av CI-systemet. Vi kan därför konstatera att nästintill 100% av utvecklare på företagen påverkas av CI-systemet där ett sådant är implementerat. Delfråga 4 Leder CI-system till en mer effektiv utvecklingsprocess för mjukvaruutvecklare? besvaras av marknadsundersökningen (se analys av fråga 10). 97% av svarsobjekten har svarat att deras CI-system leder till att deras verksamhet kan prestera bättre. Att en tillämpning och användning av CI-system har övervägande fördelar jämfört med dess nackdelar nämns även i litteraturen. Därmed kan vi dra slutsatsen att ett CI-system leder till en mer effektiv utvecklingsprocess för mjukvaruutvecklare. Sida 58
66 6. Diskussion I detta avsnitt vill vi diskutera sådant som tidigare nämnts i rapporten. Vi börjar med att diskutera krav som CI-system bör uppfylla enligt våra undersökningar i avsnitt 6.1 och huruvida vår uppfattning om vilka krav som var viktiga stämde under tidiga skeden av examensarbetet. I avsnitt 6.2 redovisar vi smärre fel och misstag som gjordes under examensarbetets gång men även alternativa tillvägagångssätt och förbättringsförslag, med andra ord utföranden av moment som hade kunnat göras på ett annat sätt. Slutligen kommer vi i avsnitt 6.3 att spåna på framtida forskningsförslag och försöka klargöra hur man kan gå vidare med de resultat som vi kommit fram till i vår studie. 6.1 Diskussion av kraven Vi kan från både litteratur- och marknadsundersökningen komma underfund med att CIsystem består av betydligt fler funktionella krav än vad vi hade förväntat oss (grönmarkerade) under tidiga skeden av examensarbetet. Av dessa undersökningar framgår det att följande funktionella krav är betydelsefulla: Källkodshantering (eng. source code management) Kompilering av källkod (eng. build/compile source code) Exekvering av byggskript (eng. running arbitrary build scripts) Körning av tester (eng. run tests) Notifiering av status för bygge (eng. feedback/notification of build status) Stöd för distribution av mjukvara (eng. support deployment of stable software) Möjliggörandet av byggautomatisering (eng. enable build automation) Förse utvecklarna med en infrastruktur som möjliggör upprepbara byggen (eng. provide infrastructure for repeatable builds) Hantering av byggartefakter (eng. internal handling of build artifacts) Vi kan dock se att de funktionella krav som vi utgick från fick högt utslag i undersökningarna. Vi förutsåg inte att övriga funktionella krav som listas ovan (ej grönmarkerade) även är av betydelse. Den största överraskningen för oss var beträffande icke-funktionella krav där vi förväntade oss att performance (grönmarkerat) skulle få högst utslag. Visserligen påvisar båda undersökningarna att performance är ett eftersträvat icke-funktionellt krav för CI-system, däremot visade sig att det fanns andra minst lika betydelsefulla icke-funktionella krav (ej grönmarkerade) som både litteraturen och slutanvändare av CI-system påpekade. Samtliga icke-funktionella krav som är av intresse listas nedan: Prestanda (eng. performance) Användbarhet (eng. usability) Flyttbarhet (eng. portability) Interoperabilitet (eng. interoperability) Utbyggbarhet (eng. extensibility) Stabilitet (eng. stability) Tillförlitlighet (eng. reliability) Underhållsmässighet (eng. maintainability) Sida 59
67 Varför stämde då vår tidigare uppfattning om vilka krav som ett CI-system måste uppfylla inte helt överens med den slutsats som vi kom fram till efter undersökningarna? Troligtvis beror det på ett flertal olika anledningar. Under förstudien hade vi inte all information till vårt förfogande och vi hade därför en väldigt vag idé om hur CI-system används och vad de består av. Dessutom skiljer sig beskrivningar av CI-system och användandet av vissa begrepp mellan olika författare och källor, något som gör det svårt att dra slutsatser från ett stort antal källor [4]. Marknadsundersökningen var till stor hjälp för att ta reda på vilka krav ett CI-system ska uppfylla och en bra vägvisare när vi försökte göra tvetydiga begrepp, som vi stötte på under litteraturundersökningen, entydiga. 6.2 Förbättringar Nedan presenterar vi olika förbättringar och alternativa lösningar samt reflektioner kring hur vissa moment hade kunnat utföras utifrån andra förutsättningar (så som en obegränsad tidsomfattning eller en större budget): Utförande av intervjuer som medel för en marknadsundersökning istället för en enkätundersökning: Det finns en rad olika skäl till varför intervjuer kan användas för att utföra en marknadsundersökning istället för att använda ett opersonligt medium som enkäter. I studier där man använder sig av intervjuer kan man ofta inte nå ut till lika många individer som man kan med hjälp av enkäter, däremot kan man inrikta sig på att träffa nyckelpersoner för ens studie. Exempelvis hade en intervju med Kent Beck eller Martin Fowler gett oss rik information om hur CI-system området ser ut just nu. Intervjuer ger en mer kvalitativ data att arbeta med och kanske mer tankeväckande svar. Intervjuaren kan ändra frågor, klargöra punkter och ställa nya frågor beroende på vilken riktning intervjun tar, detta kan leda till en rikare marknadsundersökning. [24, s. 323] En fråga i marknadsundersökningen ställdes på ett oklart sätt: Fråga 4 i marknadsundersökningen borde ha formulerats på ett mer konsekvent sätt. Frågan som ställdes var What percentage of your developers uses or is affected by the CI-solution?. Ursprungligen ville vi ta reda på hur många anställda på företaget (även de som inte direkt jobbar med mjukvaruutveckling eller annan IT-verksamhet, t.ex. kundservice, försäljningsavdelningen eller PR-avdelningen) som påverkas av företagets CI-system. Ett exempel på ett sådant scenario är: Kundservicen för företag X är överbelastad med klagomål eftersom en uppdatering i ett mjukvarupaket som företaget lanserat skapat problem för deras kunder. Efter att mjukvaruutvecklarna tagit till sig användning av CI-system så är kundservicen inte lika belastad, även under perioder där många uppdateringar lanseras till kunder. Tyvärr ställdes frågan på ett sätt som innebar att vi endast fick ut svarsdata som tyder på hur utvecklarna på företaget berörs. Därför var vi tvungna att i ett senare skede även omformulera delfråga 3, något som inte påverkade integriteten av Sida 60
68 studiens syfte eller mål men gott kunde undvikas och klargöras innan enkäten skickades iväg. Vi hade kunnat ställa upp och jämfört flera olika CI-system: Genom att göra detta kan man utifrån fler referenspunkter utvärdera prestandan och funktionaliteten av ett visst CI-system, TeamCity i vårt fall. Uppställning av ett CI-system med hjälp av exempelvis Jenkins, CruiseControl eller Bamboo hade varit spännande, tyvärr tar detta också tid och innebär en större omfattning av examensarbetet. Vi hade även kunnat utföra flera typer av icke-funktionella tester: I vår studie undersökte vi användbarhet (eng. usability). Det hade även varit intressant att titta på och mäta andra icke-funktionella krav, t.ex. prestanda (eng. performance), utbyggbarhet (eng. extensibility) eller tillförlitlighet (eng. reliability). Dock innebär detta liksom föregående punkt en ökad omfattning av examensarbetet, inte endast eftersom det tar tid att utföra utan även för att ytterligare kunskaper måste införskaffas inom dessa områden. Körning av CI-system via virtuella maskiner (VM): Det finns flera fördelar med att använda sig av virtuella maskiner för att köra CI-system. Nedan kommer vi att ange hur användning av virtuella maskiner både hade kunnat underlätta användbarhetstestningen men också hur det hade skapat fler möjligheter för simuleringar av olika slag: Man kan via en virtuell maskin installera och konfigurera TeamCity på ett säkert sätt, i den mening att om ett fel uppstår så kan man återställa TeamCity till ett tidigare tillstånd eller helt enkelt rensa TeamCity från den virtuella maskinen. Användning av virtuella maskiner medför en positiv egenskap om man tittar på säkerhetsaspekten av att tillåta utomstående enheter att koppla upp sig mot en server (i syfte att utföra tester). Kör man t.ex. TeamCity via en virtuell maskin så kan utomstående användare som har för avsikt att sabotera eller skada maskinen som de fått tillgång till endast navigera inom ramarna för den virtuella maskinen. Detta innebär att förändringar i systemet som görs snabbt kan återställas till ett fungerande tillstånd utan att påverka värdsystemet (dvs. operativsystemet som kör den virtuella maskinen). Under vårt arbete har vi som nämnt använt TeamViewer och har fått vara försiktiga med att uppkopplade testare inte utför ändringar i systemet som kan vara skadliga. Man återställer CI-systemet till ett testbart tillstånd efter varje test, så att nästa testsession kan utföras. Under detta examensarbete var vi tvungna att anteckna vilka ändringar användaren gör i CI-systemet och sedan återställa dessa efter att testet genomförts så att nästa testare utgår från samma situation. Med virtuella maskiner kan detta göras betydligt lättare genom att återställa CI-systemet till tidigare s.k. snapshots. Sida 61
69 Man skulle kunna köra 2 instanser av TeamCity parallellt och utföra olika tester på dessa. På så sätt kan man smidigare upptäcka skillnader mellan instanserna och fastslå vad skillnaden orsakas av. När man kör ett system via en virtuell maskin så har man en väldigt precis kontroll över allokering av hårdvaruresurser för just denna virtuella maskin. Om man då kör TeamCity via en virtuell maskin så kan man utföra olika tester med varierande parametrar och hårdvarubegränsningar för att se skillnader i utslag utifrån dessa parametrar. Användning av TeamCity på en virtuell maskin som agerar centralenhet och build agents på andra virtuella maskiner som utför själva jobbet för att simulera kommunikation mellan olika fysiska enheter i en typisk CI-system miljö där man ofta har skalbar decentralisering av CI-systemet och inte kör både TeamCity och dess build agents på samma server/maskin. Körning av CI-system i Linux: Unixliknande operativsystem är att föredra för att ställa upp CI-system. Exempelvis är körning av CI-system i Linux tillförlitligare i den mening att fel och stabilitet inte påverkas lika mycket när servern är igång under en längre tid. Det är även enklare att konfigurera CI-system via Linux om man är bekant med gränssnittet och de verktyg som finns att tillgå. Vi hade inte stora problem med tillförlitlighet när vi körde TeamCity i Windows 8 men det fanns en del problem med skrivrättigheter och tillgång till konfigurationsfiler för TeamCity. Även uppstart av TeamCity eller då användning återupptogs efter en tid av TeamCity som varit i drift under längre tid var ibland trögt. Vi hade även problem med virtuella nätverksadaptrar när vi försökte ställa upp virtuella maskiner. Ett annat moment som kan lösas på ett smidigare sätt i Linux är SSH uppkopplingar för fjärrstyrning. Detta kan då användas istället för TeamViewer. TeamViewer upplevdes som trögt av många testare i den mening att det fanns en viss latens/fördröjning och möjligtvis paketförlust i anslutningen mellan testarens enhet och servern och att testaren ibland fick klicka ett par extra gånger för att kunna navigera i TeamCity via TeamViewer. Anledningen till varför vi inte använde oss av Linux var för att vi inte hade förkunskap om detta operativsystem, men det är något som är värt att titta på och kanske hade vissa moment kunnat lösas på ett smidigare sätt om vi använt oss av Linux. Förberedandet av användbarhetstester kan automatiseras: De förberedelser som gjordes inför användbarhetstesterna var manuella. Delvis har detta att göra med att vi inte använde virtuella maskiner men en del inställningar gjordes även utanför en tänkt VM-miljö. Exempel på dessa förberedelser är schemaläggning av testare och uppdatering av status (t.ex. om en testare ändrar tid), sätta igång användarenkäten och TeamViewer för användning, skicka ut uppkopplingsinstruktioner till testare, sätta igång inspelning av testsession när testaren väl kopplat upp sig samt efterbehandling av testsessionen som innebar allt från att stänga ner användarenkäten och TeamViewer, till att uppdatera schemaläggning och bokföring Sida 62
70 av testare, skicka ut tack mejl till testare och behandla svarsdatan. Många av ovan nämnda uppgifter kan automatiseras och förenklas, på så sätt minskar man arbetsbördan av att utföra testerna och kan därför fokusera sin tid på annat. Smärre fel i designen av användbarhetstestet: Ett antal smärre fel smög sig in i designen av den dokumentation som skapades för användbarhetstestet. Nedan presenteras dessa fel: Bakgrundsinformation som testkandidater angav när de anmälde sitt intresse för användbarhetstestet och i användarenkäten innan testet utfördes behövde inte ha med fältet task assignment. Detta var till för att ge en rikare bild av testarens bakgrund men var något som de flesta testare inte tog till sig. Det räcker alltså om testaren endast anger occupation. Både testgruppen och kontrollgruppen klarade de flesta uppgifter (eng. tasks) under användbarhetstestet. Båda grupperna gick igenom 17 uppgifter där kontrollgruppen klarade 17 uppgifter och testgruppen klarade 16.4 uppgifter i snitt. Det vore intressant att veta varför vissa inte klarade av alla uppgifter och just därför hade vi ett fritextfält där testaren motiverade varför hon inte klarade just den uppgiften. Dock kunde den beskrivande texten, som angav att testaren ska motivera varför hon misslyckades med uppgiften, vara lite mer detaljrik och kräva att testaren anger om felet låg i TeamCity eller om det var uppgiftsbeskrivningen som var vag. Man skulle även kunnat föra en diskussion med testaren efter en misslyckad uppgift för att få en bättre bild av vad som gick fel, detta är speciellt viktigt när man utför användbarhetstest, att man vet vad som gick fel och varför, så att detta senare kan åtgärdas. Användning av bättre verktyg: Detta examensarbete utfördes utan en budget. Vi använde oss av gratisverktyg och medel som försågs av Malmö Högskola för att kunna utföra samtliga moment. Dock hade vissa moment kunnat utföras både snabbare och kanske med en större grad av kontroll om vi använt oss av verktyg som kostar lite extra. Exempel på vad som hade kunnat göras annorlunda om vi haft en budget att tillgå presenteras nedan: Användning av SurveyMonkey.com eller liknande verktyg för att utföra marknadsundersökning via enkäter men även användarenkäten som användes för användbarhetstestet. Vi använde oss i vårt arbete av Google s gratisverktyg och dessa fungerar utmärkt när man vill få fram mindre och enklare artefakter och dokument, men det var mycket som var omständigt och saknades i t.ex. Google Forms. En teknisk begränsning var att det inte går att manipulera olika element samtidigt och utföra flera operationer åt gången (eng. bulk operations). Detta innebär att en uppställning av t.ex. 20 frågor tar relativt lång tid eftersom man inte enkelt kan behandla och återanvända tidigare inmatningar. En annan teknisk begränsning var att Google Forms stöd för logisk utgrening är bristfällig och därför kräver Sida 63
71 kringgående (eng. workaround) som även dessa har begränsad användning. Exempelvis vill man ofta dölja vissa element och endast visa dessa om användaren svarat på ett visst sätt, detta kan inte göras i Google Forms och innebär därför att svarsobjektet presenteras med lite för mycket information än vad som är nödvändigt. Rekrytering av testare via tjänster som t.ex. UserTesting.com. Med hjälp av denna typ av tjänst kan man snabbt och enkelt skräddarsy ett användbarhetstest och få testare som är avlönade för att utföra testet. Efter utförda test får man en detaljerad rapport och andra artefakter för att bedöma hur pass användbar systemet som man testat är. Tjänsten UserTesting.com kostar $49 för en videoinspelning eller $225/månad. En fördel med att använda sig av denna typ av tjänster är att man snabbt kan få svarsdata som kan bearbetas. Momenten med att skicka ut inbjudningar för marknadsundersökningens enkät och användbarhetstestet var rätt tidskrävande. Marknadsundersökningen nappade individer på rätt snabbt, inbjudningarna för användbarhetstestet tog dock en lite längre tid trots att vi nådde ut till mer än 400 individer för båda delarna. Denna tid kunde ha sparats in genom att använda sig av olika tjänster där man förses med en grupp testare. Slutligen vill vi påpeka att hårdvara även kan användas för användbarhetstest som utförs fysiskt (ej via internet). Exempelvis kan man använda sig av olika instrument som eye tracking för att få in rik data från testare som på ett mer tillförlitligt sätt beskriver hur testaren upplever utförandet av användbarhetstestet. Detta kräver antingen att hårdvaran finns tillgänglig för oss och att testerna då måste utföras lokalt eller att testare som befinner sig på olika platser måste ha tillgång till hårdvaran eller teststudios varifrån testerna kan utföras. Sida 64
72 6.3 Fortsatt forskning En del nya frågeställningar uppkom under genomförandet av denna studie. Det finns nog många olika spår som man kan gå vidare på för att utforska CI-system: Man skulle kunna titta på vad som gör vissa CI-system bättre än andra. Konsensus verkar vara att CI-system i de flesta fall är nyttigt för verksamheter, men om man istället för att titta på vilka krav ett CI-system ska uppfylla tittar på vad det är som gör att vissa utvecklingsteam använder sig av en viss CI-systemmjukvara istället för en annan, kan man nog ta reda på en hel del intressanta saker kring state-of-the-art CI-system. Man kan titta på vilka olika typer [13] av CI-system som finns. Man utgår från en modell [4] och tittar på hur olika delar av ett CI-system hänger ihop samt redogör för varför vissa typer används i vissa sammanhang. Analysera CI-system utifrån en reglerteknisk synvinkel där man tittar på vad som händer när ett överflöde av incheckningar sker. Hur hanterar utvecklare ett oreglerat flöde av arbetsenheter som bearbetas av CI-systemet, motverkar detta själva continuous integration-processen eller kan CI-system anpassas för att hantera dessa typer av svängningar? Skapa CI-systemmjukvara som kan integrera och använda sig av befintliga verktyg och plugins som finns till andra CI-systemmjukvaror. Implementera flera olika CI-system och kravtesta dessa enligt de krav som vi framfört. Vidareutveckla vår modell för att utvärdera CI-system. Sida 65
73 Referenser Bibliografi [1] K. Marcin, B. Craig, Continuous integration in.net, Stamford: Manning Publications, [2] Y. Ki, M. Song, An Open Source-Based Approach to Software Development infrastructures, ASE, 2009, s [3] K. Beck, Extreme Programming Explained: Embrace Change, Upper Saddle River: Addision-Wesly, [4] D. Ståhl, J. Bosch Modeling continuous integration practice differences in industry software development, Journal of Systems and Software, vol. 87, s , Januari [5] M. Fowler, Continuous Integration, maj 1, 2006, [Hämtad: 25 feb 2014]. [6] M. Larsson, N. Lindholm, "Den agila utvecklingen. En studie baserad på den agila metodikens utformning i praktiken," Examensarbete, Malmö högskola, Sverige, 2009, [Hämtad: 12 mars 2014]. [7] Abdul, F.A; Fhang, M.C.S. Implementing Continuous Integration towards Rapid Application Development, ICIMTR, 2012, s [8] Volodymyr Melymuka. TeamCity 7 Continuous Integration Essentials: A step-by-step introductory tutorial and intelligible practical guide to successfully applying Continuous Integration via TeamCity, Birmingham: Packt Pub, [9] P. Duvall, M. Steve, G. Andrew. Continuous integration: improving software quality and reducing risk, Saddle River. NJ: Addison-Wesley, [10] Farley, Dave; Humble, Jez. Continuous Delivery Reliable Software Releases through Build, Test, and Deployment Automation, Boston: Pearson Education, [11] M. Bathie, Continuous Integration- Basic Overview and Best Practices, CollabNet, April 11, 2010, [Hämtad: 7 mar 2014]. [12] L. White, Continuous Integration Strategies, Red Hat, nov 8, 2013, [Hämtad: 6 mar 2014]. [13] C. T. Brown, R. Canino-Koning, Continuous Integration, The Architecture of Open Source Applications, first edition, A. Brown, G. Wilson, Calif. : Creative Commons, 2011, s [14] E. Duvenage, Continuous integration basics, WordPress, nov 14, 2011, [Hämtad: 7 mar 2014]. [15] H.M. Yuksel, Using continuous integration and automated test techniques for a robust C4ISR system, ISCIS 2009, s [16] Eun Ha Kim, Implementing an Effective Test Automation Framework, COMPSAC 2009, s , Sida 66
74 [17] I. Sommerville. Software Engineering: International computer science series, Ninth edition, Boston: Addison-Wesley, [18] Future Publishing Limited. The new design methodologies, Oct 30, 2012, [Hämtad: 15 aug 2014]. [19] Livermore, J.A. Factors that impact implementing an agile software development methodology, SoutheastCon, 2007, s , [20] QAI Global Service. Agile Methodology, [Hämtad: 15 aug, 2014]. [21] Ronald E. Jeffries. What is Extreme Programming?, Xprogramming, March 16, [Hämtad: 15 aug 2014]. [22] J. Baumeister, J. Reutelshoefer. Developing knowledge systems with continuous integration, Proceedings of the 11th International Conference on Knowledge Management and Knowledge Technologies, 2011, vol 33, 4 sidor. [23] PRQA Programming Research. Continuous Integration, [Hämtad: 21 maj 2014]. [24] M. Saunders; P. Lewis; A. Thornhill, Research methods for business students, Fifth edition, Harlow: Pearson Education Limited, [25] G. Borrêga, Functional Requirements and Their Poor Cousins: The Truth About Non-Functional Requirements (NFRs), Platform - OutSystems, mar 25, [Hämtad: 3 aug 2014]. [26] M. Griffiths, Non-Functional Requirements - Minimal Checklist, Leading Answers, march 29, 2009, [Hämtad: 5 aug 2014]. [27] T. Stålhane, Non-functional requirements, NTNU, [Hämtad: 5 aug 2014]. [28] P. B. Hoggett, Making Quality Software: 12 non functional requirements every app should have, WordPress, jan 7, [Hämtad: 6 aug 2014]. [29] Agileheads, Continuous Integration Basics, mar 8, 2012, [Hämtad: 8 mar 2014]. [30] P. M. Duvall, Continuous Integration : Improving Software Quality with Continuous Integration, 2007, Stelligent Inc, [Hämtad: 8 mar2014]. Sida 67
75 [31] Xamarin, Introduction to Continuous Integration with Xamarin : Integrating Xamarin Projects into a Continuous Build Workflow, [Hämtad: 9 mar 2014]. [32] D. Bowler, Ten Best Practices For Continuous Integration, CollabNet, okt 9, 2012, [Hämtad: 10 mar 2014]. [33] E. Crewe, Continuous Integration (C.I), s5sclsht2ck/present. [Hämtad: 11 mar 2014]. [34] W. Billingsley, J. Steel, A comparison of two iterations of a software studio course based on continuous integration, ITiCSE, 2013, s [35] S. Stolberg, Enabling Agile Testing Through Continuous Integration, AGILE 2009, s [36] John W. Creswell. Qualitative, Quantitative, and mixed methods approaches, 4th edition, Lincoln: SAGE Publications, [37] Sarah L. Collie, P. Jesse Rine; Survey Design: Getting the results you need, Office of Process Simplification, May 26, 2009, [Hämtad: 6 maj 2014]. [38] Oppenheim, A. N. Questionnaire design, interviewing and attitude measurement, New edition, Continuum, London and New York, [39] Stukát, S, Att skriva examensarbete i utbildningsvetenskap, upplaga 2, Lund: Studentlitteratur AB, [40] E. Gotab, Forskningsetiska principer: inom humanistisk-samhällsvetenskaplig forskning, Sverige: Vetenskapsrådet, [41] Thought Works. Continuous Integration, [Hämtad: 1 aug 2014]. [42] Quyen L, Nguyen. Non-Functional Requirements Analysis Modeling for Software product Lines, MISE, 2009, s [43] E. Folmer, J. Gurp, J. Bosch. Software Architecture Analysis of Usability, Berlin Heidelberg: Springer-Verlag, [44] G. Verheugen. Den nya definitionen av SMF-företag: Användarhandbok och mall för försäkran, EU: Europeiska kommissionen [45] E. Folmer, J. Gurp, and J. Bosch. Scenario-based assessment of software architecture usability : In Proceedings of Workshop on Bridging the Gaps Between Software Engineering and Human-Computer Interaction (SE-HCI). IFIP, 2003, s [46] Bass, L; Clements, P.; Kazman, R. Software architecture in practice, 3 uppl, Upper Saddle River NJ: Addison-Wesley, [47] J. Sauro, Measuring Errors in the User Experience, Measuring U, Maj 15, 2012, [Hämtad: 5 sept 2014]. [48] J. Sauro, Measuring Usability Average Task Times in Usability Tests: What to Report?, Measuring U, April 21, 2010, [Hämtad: 4 sept 2014]. Sida 68
76 [49] Khushboo. S, Kishore. M. N, Continuous Integration Using Team Foundation Build Microsoft Developer Network, Microsoft Corporation, jan 2006, [Hämtad: 1 aug 2014]. [50] T. Krishnan, Continuous Integration & Hudson, Slideshare, May 03, 2010, [Hämtad: 23 mar 2014]. Sida 69
77 Edument AB. All Rights Reserved Historical background Continuous Integration & Deployment Kent Beck Martin Fowler In 1997, have Kent Beck and a team of developers at Chrysler Comprehensive Compensation (C3) project, invented Extreme Programming (XP). [1] Martin Fowler said: This was my first chance to see Continuous Integration in action with a meaningful amount of unit tests.[2] System Development Methods System Development Methods The most pupular traditional sequential methods in system development: Ian Sommerville Development methods is a must to manage and improve development process in any organization working with system Waterfall method Agile method Extreme programming development.[3] Waterfall Method Waterfall method is an old method of those traditional sequential methods.[3] In which the work process is flowing downwards Agile methodologies Agile is a newer approach of those traditional sequential methods and a generic term for several development methods.. 1
78 Agile Development Methodology Agile changed the way devlopers organize their work. With Agile developers analysis, designs, builds, and tests depends on pruduct s requirements. Extreme Programming (XP) XP is one of Agile software development methods. It was developed to handle the needs of software development. It performed by teams of few developers to be commensurate with the changing requirements. [1] Continuous Integration (CI) What is CI? "Continuous Integration originated with the Extreme Programming development process, as one of its original twelve practices [2]. Definition 1 What is CI? Why CI? Definition 2 A developers goal is to create perfekt applications with less time and work as possible. Reaching this goal is not easy now, because the applications are getting more complex and consists many parts. [5] 2
79 One of the most important keys to improving applications and streamline the work is to automate som parts of the work that are possible to automate. [5] One of the best ways to automate som of the work is to implement Continuous integration (CI) [5] Reasons of using CI Reasons of using CI Reduce risks: Bugs and problems can be detected and solved earlier by implementing a CI-system, because the testing and integration is already done earlier in the developementprocess. [5] Deployable software: To make sure that the developed software will work as expected the installation process has to be automated. [5] Which leeds to bettersoftware. Reasons of using CI Reasons of using CI Increase project visibility: Project members ll get better control over the project because of the feedback mechanism, which allows them to see the final results and place of errors to be fixed. [5] Fast incremental builds: CI provides faster build, test and feedback which helps developers to finde bugs and errors earlier in the development process. [5] 3
80 Frequency of performing builds 0% 0% 21% 79% Continuously Daily Weekly Monthly CI-Tools Essential CI-Tools The quality of a CI-system depends on tools that the system contains. We can either buy an expensive CIsystem that is feature-proof and often easy to use, or we can choose a CI-system that is less future-proof and often require more work before it can be used, but are almost for free or low cost. [5] Source code control Continuous integration server Feedback mechanism Build manager Unit test framework Code analysis tool Testing tools [5] Advantages with CI-system CI-Advantages Other Stable Reliable Low cost Fast Easy to troubleshoot Ease of use None Advantages with CI-system Helps developers to revert the codebase to a bug-free state in case of build fail, unittest fail or bugs detection.[5] Easy to None Ease of use Fast Low cost Reliable Stable Other troubleshoot Responses Fixing integration and problems continuously avoids last-minut stress of releasing data. 4
81 CI-Advantages CI-Advantages Early warning when the code is broken or incompatible Early warning when detecting incompatible changes on the code Makes the current build available all times so that developers can test, demonstrate, or release the build. Provides fast unit testing of all changes Povides fast feedback to developers about code quality and functionallity. Frequent controll on the code helps developers to create better and less complex code. Metrics that developers get from automated testing helps developing good quality and functionality code. CI-Disadvantages survey CI-Disadvantages Other Unstable Unreliable High cost Slow Difficult to troubleshoot Difficult to use None Disadvantages with CI-system Difficult to Difficult to None troublesho Slow High cost Unreliable Unstable Other use ot Responses Some developers complaining that Continuous Integration causes kind of bottleneck at the work because of the hard roles. [5] CI causes a backup because developers cannot check in code that is not completed. CI-Disadvantages Advantages VS Disadvantages Increment of maintenance and hardware costs. [6] Experience for the first-time setup required. It requires speciell software to get best results. Most developers who use CI believe that the advantages of using CI will covers the disadvantages. Because they will save both time when they find and fix integration problems earlier in the development and they will save money when they complete the project earlier. [6] 5
82 CI-Workflow In the CI process, developers check code into the version control repository. The automated CI system polls the repository for changes and then builds and tests the code. Results are posted to a feedback system where the team members can see the results [5]. Manual Build & CI-server Manual Build Here the developer has to check out the head of the mainline in the integration machine where he now can find his last checkin. He then starts the integration build, and wait for results. He ll be done with his commit if the buid succeed. [2] Why manual build? Doing time schedule buildings, like every night or in specific time doesn t means that it s continuous build not either Continuous Integration because the main point with continuous integrations is to detect and fix bugs and problems as soon as possible. [2] A schedule build like every night means that bugs and problems will lie undisconverd in the system for a long time and that will take more time to detect and remove them. And this is contrary to the principle of Continuous Integration. [2] James Shore The code in revision control always builds and passes tests. Period. [7] Why manual build? Why manual build? It s easier and faster to detect and fix the problem by using manual build. The problem will be one of 3 things if something goes wrong. - your own code - Integrations with someone else code - Enviromental changes. [7] We do not need to fix somebody else's mistakes or broken build due to negligence. Manual build leeds to better test and better design because it ll keep your build times down and avoids long integrations. 6
83 CI-Server Why CI- Server? It acts like an observer to the repository because as soon as the repository finishes a commit, the server will send the source automatically onto an integration machine to start the build and then send feedback to developer by , SMS or dashboard. [2] CI-Server is a helpful tool according to developers who are using it. [2] for example CI server s web pages provides: An indication of who is building. What changes made. History of changes. Last activities on the project. Control of what developers have been doing. Get a sense of the project's status. CI-Benefits CI-System Practices No more long integrations [8] Better communication Increase project visibility Detect bugs and problems faster Saving alot of debugging time Enhance confidence and improvement No more worrying about not working codes. Faster software delivery by reducing integration issues Continuous Integration system has many practices. And the best ten practices according to Martin Fowler are: [2] 1. Maintain a Single Source Repository [2] which can be demonstrated in several stages: Make sure to use a source code management system, also make sure everyone uses the repository to checkout and commit their code to. Store everything you need in the repository to fully build your application including source code but also test scripts, properties files, install scripts, third party libraries, IDE configurations. A clean machine should be able to fully build your application without external dependancies. Do not store actual build artifacts such as binaries or executables. Branching is a feature of source code management systems, but make sure you use it to a bare minimum. Make sure everyone works off the mainline and frequently integrates their changes into mainline. 7
84 Automate the Build [2] Going from source code compilation to run time execution can be a complicated process and shouldn't be handled manually by developers as the process is prone to human errors and can be automated. Make sure to include everything in the automated build. Going back back to (1), nothing else should be required from a clean machine to fully build the system. Make sure your build tool can analyze what needs to be built and customize the build according to the changes that have been made, no need to rebuild everything from scratch if a minor change was made. 3. Make Your Build Self-Testing [2] Traditionally, building an application means compiling, linking and executing code, omitting the process of testing the code for bugs. While IDEs can catch obvious bugs through static analysis many slip through the net. A good way to add another level of error detection is to include automated tests in the build process. For self-testing code to be useful you need to write a whole suite (a bunch of) automated tests that cover a large part of the code base (high code coverage). Going back to (2), the whole suite of tests needs to be able to trigger from a simple command. For a build to be self-testing the failure of a test should cause the build to fail. Of course, tests can't find everything and poorly written tests can't detect the presence of bugs. However, having imperfect tests run frequently is preferred over perfect tests that are never written at all. 4. Everyone Commits To the Mainline Every Day [2] Integration is primarily about communication. Frequent integration allows developers to quickly notify their team about changes of the project. Of course, there are prerequisites for the developer before a commit to the mainline should be made. 8
85 The developer needs to update their working copy to match the mainline (other developers may have made changes since the last checkout), resolve any conflicts and make sure that his code builds locally without errors, including passing tests. Only then is he free to commit to the mainline. By being engaged to this practice, developers quickly identify conflicts within the project. Conflicts that stay undetected for weeks can be very hard to resolve. A series of errors can be detected early and resolved, such as compilation conflicts and textual conflicts. Even bugs can be detected that would otherwise occur as a result of lack of integration. It is advized that developers commit to the repository at least a day, preferably several times a day. The more frequently your team commits, the easier it is to identify and resolve errors. Furthermore, breaking down a days of work into small chunks of a few hours helps track and provide a sense of progress. The regularity of commits can help project managers to track progress with KPI. 5. Every Commit Should Build the Mainline on an Integration Machine [2] Every time a developer commits his code, the CIsystem should trigger a build of the mainline. The developer who commits needs to monitor the mainline build so it can be fixed if it breaks. He's not done until the CI system is done building and testing the latest revision of the code. Practically impossible if building takes a lot of time, more about this in (6). 6. Keep the Build Fast [2] The whole point of CI is to provide rapid feedback. This can only be enforced by optimizing the build process, as a long build can become a bottleneck, disrupting the CI process and wasting precious development time. The build time relies on the complexity and scope of the project. The XP guideline of a ten minute build is within reason. 9
86 Concentrated effort should be put in to optimizing the build process as every minute reduced off the build time is aminute saved every time a developer commits,which could add up to a lot of time! For more complex projects, the usual bottleneck lies in the testing phase. More so when tests involve external services such as databases. A solution to this problem is setting up a deployment pipe (aka. build pipeline or staged build) which basically means that the monolithic big bang build will be separated into several stages. The first stage build will be called the commit build. During this stage only the highest priority tests will be run, to ensure a good balance between code coverage and build time. Once the first stage build is successful developers can resume development of the system. Meanwhile further thorough tests can be run in the background which leads us to the second stage build. With the first stage build having compiled and run localized unit tests (where external services are comitted), the secondstage build run tests that involve larger scale interactions. The suite of tests that is run during the second stage buildis more encompassing and involves testing of endto end behavior, thus it might take a couple of hours to run. The second stage build runs whenever higher priority tasks are not run and picks up the latest stable commit build for further testing. Builds performed after the initial commit build are said to contain pure tests as they thoroughly investigate for errors that are not detectable in the commit build. Whenever bugs are detected in stage builds subsequent to the commit build, developers try to adapt or introduce new tests to the commit build, to assure that the bug stays fixed in the commit build if it should reappear at later releases. The example of the two stage pipeline is used for explanatory purposes. In practice, any number of stages can be used in a deployment pipeline. Furthermore, builds subsequent to the commit build can b e parallelized and the workload may be distributed and scaled over a large number of machines. By distributing the workload of later build stages, it is possible to introduce further automated testing without sacrificing the need for a fast building of the commit build. 10
87 Test in a Clone of the Production Environment [2] The whole point of testing is of course to detect and resolve any issue that the system would have in production (the environment where customers use the system). Issues may arise if the production environment is significantly different from the development and tes ting environment. Ideally, the same version of the database software is running under the same version of operating system in the two environments.all libraries that are present in the production environment should also be present in the test environment. The same IP addresses and ports should be used, running on the same hardware and platform, etc. In practice, it may be hard to replicate the production environment. For example if you're writing desktop software it's virtually impossible to test your system in every kind of environment running various third party software. The developer should however be aware that Every difference in the test and production environment poses a risk and may potentially be a source of error. Virtualization is a great way to put together test environments as everything can be saved into the virtualization. Virtualization also allows for running of multiple tests on one machine or even simulation of multiple machines in a network on a single physical machine. 8. Make it Easy for Anyone to Get the Latest Executable [2]. Agile development of software addresses one of the most difficult parts of software development: How do we build the right software for the customer? It's often very hard for the customer to specify what he wants in advance, it's much easier to point out what needs to be fixed or changed. For this purpose, everyone involved with the proj ect including the customer should with ease be able to get hold of the latest stable executable. Make sure there's a place where people involved with the project have access to and can get hold of the latest stable executable. Preferably, also make sure that previous stable executable are available. 11
88 Everyone can see what's happening [2] As mentioned in (4), (Continuous) Integration is Primarily about communication. Make sure everyone can easily see the state of the system and recent changes that have been made. The state of the mainline build is one of the most i mportant things to communicate, it's important that everyone is on the same page. Some CIsystem software offer dashboards that display if there's a build in progress and the state of the most recent mainline build. Furthermore, CIsystem software can provide more details about these events. Often times, team leaders are interested in this kind of information to get a sense of who's being active and to keep an overview over the sta te of the system. Another advantage with dashboards is that Peripheral people that are not co-located with The main team of developers can from a remote location get a sense of the project's status. Yet another advantage is that dashboards can be used to aggregate build information and project status of several different projects, thus providing a centralized place where this information can be viewed. Many teams are not content with a dashboard, instead hooking up various build sensors such as light display sand lava lamps with red and green colours indicating stable or broken states of the mainline build. But CI-systems aren't necessary to enforce this practice. Unique physical tokens such as rubber chickens or toys may be passed around the office to indicate what developer in a team is doing the current build. 10. Automate Deployment [2] In other cases, aural signatures, such as ringing a bell, are used to communicate the status of builds. Regardless of how teams choose to communicate,it' s very important that the state of the mainline build is communicated in a clear way and that this information is readily available to anyone involved in the project! As previously mentioned, usually several environments are used during development of software at enterprise level. Since executable are frequently moved between These environments, it's preferred to automate the deployment process. This is made possible and can be simplified and automated with scripts. 12
89 Of course, this also means that deployment into Production should be automated and possible to do with ease. While it is true that deployment into production is not something that every development team will want to do every day, a routine for doing this should nevertheless be set up to assure that this process is easy to set in motion once it's needed and that deployment to production can be done quickly. Another benefit of automated deployment is as with other forms of automation, the reduced risk of human errors. It's a cheap practice to utilize as it uses the same capabilities as mentioned in (6). Another capability that should be considered is Automated rollback. As well all know, bad things happen and if worst comes to worst, and a critical bugs are found in the production environment it's good to be able to quickly revert to the last known stable state. Automated rollbacks also reduce tension in the team regarding deployment, encouraging developers to deploy more frequently at lower risk ofcritical failure, meaning new features get released quicker! This allows developers to test out new features, fixes and changes in a smaller scale before fully deciding on whether to keep the changes or discard them Automated deployment can even be taken one step further! The practice of deploying a trial build with the lat est features and fixes to a subset of users allows the development team to see the impact of the latest changes before gradually rolling the latest build out to the entire user base. How To Du It? According to (thoughtworks)[8] Developers have to check out their code into their own workspaces. Developers have to commit changes they have made to the repository. The CI server monitors the repository and checks out changes when they occur. The CI server builds the system and runs unit and integration tests. The CI server releases deployable artefacts for testing. The CI server assigns a build label to the version of the code it just built. The CI server informs the team of the successful build. If the build or tests fail, the CI server alerts the team. The team fix the issue at the earliest opportunity. Continue to continually integrate and test throughout the project. 13
90 Team responsibilities Team responsibilities It s important that a team developers have some kind of policies to follow, when working with Continuous Integration. Policies that let teams having better control and manage on themselves, to complete the work successfully. [8] (thoughtworks)[8] have explained some polices that developers have to follow: Check in frequently Don t check in broken code Don t check in untested code Don t check in when the build is broken Don t go home after checking in until the system builds [8] CI- Team Objections And Solutions CI- Team Objections And Solutions When the job increases, developers have to change the style of their work to fet the new situation. This can lead to objections from some team members that working with Continuous integration like the following: [5] Objection: CI brings additional tasks to developers like CIsystem setup and maintainance and this will take them away from the main task. [5] Solution: Developers will save much more time when the systen is fully integrated because they will be able to build code, test code and fix bugs earlier and faster. [5] CI- Team Objections And Solutions CI- Team Objections And Solutions Objection: It s difficult for developers to follow up the continuous and very fast changes. [5] Solution: It ll be easier to follow up if dovelopers start out with a simple build a day, and increase it later on when they feel that they can. Objection: CI requires additional expenses when it comes to hardware and software costs. [5] Solution: You can actuelly start out with old equipments lik an old PC as your CI server and so on. [5] 14
91 CI- Team Objections And Solutions CI- Team Objections And Solutions Objection: Developers have to compile and test their code. Solution: Compiling and testing helps developers to use their brains to solve application problems. But CI automates much of the work process. [5] Objection: It takes along time before a CI-system can be included into the project. [5] Solution: You ll be able to use som of CI-tools no matter how much time your project needs to use CI. But the easier and better way to do that is by creating the new project under CI process. [5] CI and type of business 0% 3% 5% 5% Administration 13% Computer / IT Technology / Science 74% Economy / Finance Logistics / Transport Other Size of the company that using with CIsystem 50% 21% 29% Small (up to 50 employees) Medium ( employees) Large (over 250 employees) Percentage of developers uses or affected by the CI-solution Company's performance after using CI-system 0% 3% Percentage (1=10%, 5=50%, 10=100%) Responses 97% Worse performance No change Better performance
92 Continuous Delivery Continuous Delivery (CD) For many organizations Continuous Delivery isn t just a deployment methodology, it s critical to doing business [10] "Continuous delivery is a series of practices designed to ensure that code can be rapidly and safely deployed to production by delivering every change to a production-like environment. [9] CD- Survey CD- Benefits Som of CD benefits are the following: [12] Delever most important changes and improvements faster. Ability to release in high quality and usability. Ability to increase development team in a continuous process by skipping batch processes. CD- Benefits When to use CD? Save money and time by eleminating batch process. Developers have more time to think and complete the work. Developers work in low stress condition. Improve cooperation between development and operations Continuous Delivery should be used when: [12] Having online service Having longer release time Having a new product to develope Having a big project with many contributors Having to release security patches frequently 16
93 CD- Practices CD- Practices Som of CD practices: [13] 1. Manage and version controll your code and include everything like documents, configuration parameters, databases. 2. Automate everything that make sense to you like unite testing, integration testing, regression testing. 3. Automate your deployments. 4. Fix the problem that you get probably at it s root and follow the process again from the beginning. 5. Allocate some time for frequent maintenance and improvment if you want to reach the benefits. 6. Decide a clear process and let your teams follow it, everyone should cooperate to get CD started, and to keep it going. Continuous Deployment Continuous ( Delivery VS Deployment) 1. Deliver every change of code to an environment continuously to be tested automatically. [15] Jez Humble According to (Jez Humble) who is the author of Continuous Delivery. it is the practice of releasing every good build to users [14] 2. Then every change that passes the automated tests is deployed to production automatically. [15] Continuous Improvement Continuous Improvement A process based on continuous improvement is essential to the rapid delivery of quality software. [14] Continuous improvement is an ongoing effort to improve products, services or processes. These efforts can seek incremental improvement over time or breakthrough improvement all at once. [16] 17
94 Continuous improvement tools What PDCA- cycle means? Four-step quality model or plan-do-check-act (PDCA) cycle is the most used tool for continuous improvement. It s also known as Deming Cycle or Shewhart Cycle: [16] Plan: Identify an opportunity and plan for change. Check: Use data to analyse the results of the change and determine whether it made a difference. Do: Implement the change on a small scale. Act: If the change was successful, implement it on a wider scale and continuously assess your results. If the change did not work, begin the cycle again. [16] Continuous improvement methods (Continuous and Continual) Improvement? There are many methods for continuous improvement. But the widely used methods are Six Sigma, Lean, and Total Quality Management. All of them are found to enhance teamwork, employee involvement, systematize processes and reducing defects, variation and cycle time. [16] The terms continuous improvement and continual improvement are frequently used interchangeably. But some quality practitioners make the following distinction. [16] (Continuous VS Continual) Improvement Continual improvement: a broader term preferred by W. Edwards Deming to refer to general processes of improvement and encompassing discontinuous improvements that is, many different approaches, covering different areas. Continuous improvement: a subset of continual improvement, with a more specific focus on linear, incremental improvement within an existing process. Some practitioners also associate continuous improvement more closely with techniques of statistical process control. [16] David Bolton A Version Control System (VCS) is an application, desktop or web-based that lets developers keep their source code and binary and resource files stored away along with information about different versions [19] 18
95 Version Control Why Version Control? The simplest way to explain Version control is that it's used to keep a repository of your project files together with a history of all your code changes in one place. This allows the developers of the project to track every change made to the code, who made the change and the reasons for the code change. [20] Version control is essential when working with a team of developers. Using version control will allow multiple developers to work on the same file at the same time. If you were using version control you could just revert your code back to before you started developing that feature. [20] Why Version Control? Version Control Options Version control will record who wrote a piece of code. Version control is also a good way to keep your code shared on multiple computers. Tagging is an important feature you need to take advantage of when working with version control. When you have completed a piece of work and ready to deploy the code, you then tag this version of the code. [20] There are many different types of version control, here we are just going to look at the two most popular version control repositories, Git and SVN. [20] SVN GIT SVN or Subversion: Is very popular due to the fact that it's very easy to understand and very straight forward to work with. The WordPress plugin repository uses SVN. It works by having a central server for your repository, this repository is split into 3 key areas...trunk, Branches and Tags. Each one of these areas have an important role to play. [20] At the moment GIT is probably the most popular version control which is aided by the popular websitegithub. Like I said before GIT and SVN are quite similar but the workflow is a bit different. SVN has one central repository, but GIT has multiple repositories, one central repository but each developer has their own repository. [20] 19
96 Software configuration management (SCM) SCM Best Practices Using a SCM System To: Jacky Estublier SCM is the control of the evolution of complex systems,, for the purpose to contribute to satisfying quality and delay constraints. [17] Store and version all source code Utilizing private developer workspaces Third-party libraries Properties files Database schema Test scripts Install scripts [18] Best Practice Utilizing Private Developer Workspaces CI- Servers Comparison Name Platform License Windowsbuilders Javabuilders Other.Builders Notification IDEIntegration Integration Eclipse, Visual Ant, Maven 2/3, Jetbrains MSBuild,NAnt, Studio, IntelliJ IDEA.ipr based, , XMPP, Youtrack, JIRA, Visual Studio, Rake, FxCop, IDEA, RubyMine, TeamCity Servlet Container Proprietary IDEAInspections, RSS, IDE, Bugzilla,FishEye, Duplicates finder Command Line PyCharm, IDEADuplicates SysTray FindBugs, PMD, for.net PhpStorm finder,gradle dotcover,ncover,webstorm Team Custom script, Visual Studio, Foundation Windows,VSTM Proprietary MSBuild Ant, Maven , SOAP Unknown Command line Eclipse Server Work in isolation Revert to known good states when needed Checkpoint their changes Share only mature, well-tested code with other team members [18] Shippable Hosted Proprietary MSBuild, NAnt MSBuild,NAnt, QuickBuild Cross-platform Proprietary Visual Studio Creative Jenkins/Hudson Servlet Container Commonsand MSBuild, NAnt MIT NAnt, Rake, CruiseControl Cross-platform BSD-style and Xcode Ant, Maven, Gradle Ant, Maven 1, Maven 2 Ant, Maven 2, Kundo Apache Ant, Phing, Maven Ruby, Python,Node.js , Campfire No GitHub, Heroku,Java,Scala,C Sharp , XMPP, Eclipse, Rake, Shell script, RSS, GoogleTalk, IntelliJ IDEA, JIRA Command Line Remote API Visual Studio Grails,Phing, Android, , Bugzilla, Eclipse, Rake,Ruby, Cmake, GoogleCalendar, GoogleCode, IntelliJIDEA, Gradle, SCons,Python IRC,XMPP, JIRA,Redmine, NetBeans Shell script, Gant RSS, witter Mantis, Trac catch-all 'exec' , CCTray Eclipse Unknown Bamboo Servlet Container Proprietary MSBuild,NAnt, Visual Studio Ant, Maven 1, Maven 2,Maven 3 custom script, command line, Bash XMPP, Google Talk, ,RSS, Remote API IntelliJIDEA, Eclipse, Visual Studio FishEye,Crowd, JIRA,Clover AnthillPro Cross-platform Proprietary Shell script, Batch script, MSBuild, [1] NAnt, [2 Ant, [4] Cross-platform Maven 1, 2, ] Visual Studio [3] & 3 [5] commandline, Groovy script,make, [6] RTC Jazz, [7] TFS Build [8] , XMPP,RSS, Systray Eclipse, Visual Studio (many)[9] Refrences References: [1] Kent Beck. Extreme Programming Explained : Embrace change, U.S, [2]Martin. Fowler, Continuous Integration, [e- resurce], 2006 [3] Ian Sommerville, software Engineering, Ninth Edition, Addison-Wesley, [4] Duvall, Paul ; Matyas, Steve; Glover, Andrew. Continuous integration : improving software quality and reducing risk, Saddle River, NJ,2007. [5] K.Marcin ; B.Craig, Continuous Integration in.net [e-book], 2011 [6] V.Bakhov, Continuous Integration For Database Development [e-resurce], 2011 [7] James Shor, The Art Of Agile, Integration-on-a-Dollar-a-Day.html e- resurce [8] [9] Yuli Deng, Continuous Delivery Software Developing System On Vlab Platform, Arisona State University, 2013 [10] James, Turnbull, [11] [12] [13] [14] J. Humble; D. Farley. Continuous Delivery : Reliable Software Releases Through Build, Test, And Deployment Automation, Addition Wesley, 2010 [15] [16] [17] Jacky Estublier. Software Configuration Management: A Road Map, Proceedings of the Conference on The Future of Software Engineering, USA [18] [19] [20] Slide 2: Kent Beck: Martin Fowler: Slide 3: Ian Sommerville: Slide 4: Slide 5: Slide 6: Slide 7: Slide 8: Slide 9: Slide 10: Martin Fowler: Slide 11: Paul Duvall: Slide 14: Slide 15: Slide 16: Slide 17: Slide 18: Slide 19: Slide 22: Slide 24: Slide 28: Slide 31: Slide 34: James Shore: Slide 91: James Turnbull, Slide 93: Slide 99: Jez Humble, Slide 100: Slide Slide Slide 108: David Bolton: Slide 115 : J. Estublier: Slide 118: 20
97 Edument AB. All Rights Reserved Introduction CI-server software are used to enforce and support Continuous Integration. Continuous Integration with TeamCity Introduction Installing TeamCity TeamCity is a popular CI-server software developed by JetBrains. In this presentation we explore TeamCity and learn how to use it. Installing TeamCity Installing TeamCity Installing TeamCity Download TeamCity from We will look at TeamCity in this presentation but make sure you download the latest version for your personal or business use. Choose the features that you want installed. 1
98 Installing TeamCity Installing TeamCity Choose the server port that you want TeamCity to use. Configure Build Agent properties. Installing TeamCity Installing TeamCity Specify which user will be running the TeamCity Server service. Specify which user will be running the TeamCity Agent service. Starting up and accessing TeamCity Starting up and accessing TeamCity Starting up and accessing TeamCity Now that you have installed TeamCity, let s start it up and access it through the web browser. 2
99 Starting up and accessing TeamCity Starting up and accessing TeamCity Run the runall.bat batch file with the start switch to start the TeamCity Server service. By default, you can use the following command: C:\TeamCity\bin\runAll.bat start Access the setup instruction page by typing in the IP adress and port of the TeamCity server machine ( localhost in our case). Starting up and accessing TeamCity Setting up TeamCity after installation Setting up TeamCity after installation TeamCity should be up and running constantly, however if you wish to shut TeamCity down then do the following: Run the runall.bat batch file with the stop switch to stop the TeamCity Server service. By default, you can use the following command: C:\TeamCity\bin\runAll.bat stop Setting up TeamCity after installation Setting up TeamCity after installation In order to run TeamCity, we need to connect it to a database. Verify the location of the data directory. 3
100 Setting up TeamCity after installation Setting up TeamCity after installation Setup your connection to your database of choice (we re using MySQL). If the MySQL JDBC driver is not found in your environment, make sure you download it. Setting up TeamCity after installation Setting up TeamCity after installation Once downloaded, move the.jar file containing the driver to the TeamCity /lib/jdbc folder. Click on the Refresh JDBC drivers button and make sure TeamCity loads the driver correctly. Setting up TeamCity after installation Setting up TeamCity after installation Fill in the rest of the fields in the form in order to establish a connection to your database. Make sure a database is set up prior to filling out the form, the following statement may be used on your MySQL control panel to create a TeamCity compliant database. 4
101 Creating a user account for TeamCity Creating a user account for TeamCity Creating a user account for TeamCity In order to log in and interact with TeamCity, you need to set up a user account. Creating a user account for TeamCity Creating a user account for TeamCity Access the Create Administrator Account page by navigating to the localhost/setupadmin.html page. Fill in the username of the administrator and the password. Overview of TeamCity Overview of TeamCity Overview of TeamCity Now that we can log in to TeamCity as an admin user, let s take a look at the different sections of TeamCity and what they do. 5
102 Overview of TeamCity Overview of TeamCity The first page that you re presented with is the Overview page, also known as the Projects page. You have an overview of all projects from this page. This is the Changes page. VCS changes (changes committed to the repository) are displayed on this page. Overview of TeamCity Overview of TeamCity This is the Agents page. This page provides an overview of Build Agents. You can view properties of Build Agents here or set up new Build Agents. This is the Build Queue page. Builds that have been triggered (and scheduled) will queue up and be listed on this page. Overview of TeamCity Overview of TeamCity This is the User Settings page. You can set up your TeamCity profile and user-specific settings on this page. This is the Administration page. Only a user with administrative privileges will be able to access this page. A wide range of global and project-specific settings can be accessed and changed from this page. 6
103 Setting up a sample project Setting up a sample project Setting up a sample project Now that we have taken a look around TeamCity, let s set up a sample project that we can work with. The sample project will be a Java-project, being built with an Ant build script and tested with the JUnit unit testing framework. Setting up a sample project Setting up a sample project Here s an overview of our project. We have 2 Java-classes and a JUnit test class. We also have a custom build script which we will be using. Demo01.java is a demonstration of how what a functional class in a Java project can do. It has 2 methods that concatenate a string and calculate a sum. Setting up a sample project Setting up a sample project Demo02.java is also a demonstration of a functional class. It s included in this project to show that a project may of course consist of more than 1 class. Test01.java is a JUnit test class that consists of a test suite containing 2 test cases. Each test case tests the 2 methods of Demo01.java: demostringconcatenate & democalcsum. 7
104 Setting up a sample project Setting up a sample project build_custom.xml is an Ant build script (the Eclipse-generated build.xml will not be used). This build script consists of various targets, on this slide we can see the init target which initializes file and folder structures pre-compilation. On this slide we can see the build, clean and run targets which compile the project, clean (ie. delete) generated binaries and other artifacts, and run the project. Setting up a sample project Running the project locally Running the project locally On this slide we can see the test target which runs JUnit tests included in the project. Running the project locally Running the project locally Now that we have a project in place, let s run it in the IDE and in the CLI. We are using Eclipse as our IDE and Windows Command Prompt as our interfaces but of course any IDE and CLI can be used. Demo01 is running, also creating an instance of Demo02. hello and world is concatenated into helloworld. 5 and 10 is added up into 15. 8
105 Running the project locally Running the project locally Test01 is running, displaying both console output stream (bottom) and the passing of unit tests (right). Both tests passed successfully. build_custom is building and testing the project. Console output stream of the junit tests can be read. Running the project locally Running the project locally Demo01 can also be run through Ant via the CLI, this command directs Ant to build_custom.xml and runs the target run : ant -f build_custom.xml run Test01 can aswell be run through Ant via the CLI, this command directs Ant to build_custom.xml and runs the target test (which performs unit tests): ant -f build_custom.xml test Setting up and installing Ant & JUnit Setting up and installing Ant & JUnit Setting up and installing Ant & JUnit We ve demonstrated how to use Ant and JUnit both within the IDE and outside (via the CLI). Let s take a step back and go through the installation and integration process of connecting Ant and JUnit to the IDE. 9
106 Setting up and installing Ant & JUnit Setting up and installing Ant & JUnit Navigate to the JUnit homepage ( and read about JUnit or simply proceed to the installation page. Navigate to the Apache Ant Binary Distributions page ( and download the.zip archive. Setting up and installing Ant & JUnit Setting up and installing Ant & JUnit You should know have these 3 archive files in your download folder. Refer to the JUnit FAQ if you have trouble installing JUnit or want to learn more about JUnit in general. Setting up and installing Ant & JUnit Setting up and installing Ant & JUnit Refer to the Apache Ant manual if you have trouble installing Ant or want to learn more about Ant in general. Installing JUnit in short: Place the hamcrest-core library and junit library in the /lib folder of your project. 10
107 Setting up and installing Ant & JUnit Setting up and installing Ant & JUnit For Eclipse, go into the project properties and add the JAR to the libraries in the Java Build Path. If you have a recent version of Eclipse, this isn t necessary as JUnit should already be provided in the bundle. Installing Ant in short: Extract the contents of the apache-ant.zip archive into any folder, I ve placed it in C:\ant. Make sure you correctly configure environment variables (refer to the Apache Ant manual) Setting up and installing Ant & JUnit Setting up a VCS and commit code Setting up a VCS and commit code Try running the command ant -version from any directory in the CLI (Command Prompt). The version of Ant should be displayed. Setting up a VCS and commit code Setting up a VCS and commit code In this section, we will demonstrate how to set up a VCS (version control system) using a SVN (Apache Subversion) repository hosted on Google Code. We will also demonstrate how you can commit your project files to the repository. Navigate to the Google code webpage ( and click on Create a new project. 11
108 Setting up a VCS and commit code Setting up a VCS and commit code Set up the parameters of your VCS. You can use Git, Mercurial or Subversion with Google Code, we re going to use Subversion. Google Code provides a graphical interface to the SVN repository. Here s an overview of the source code. Setting up a VCS and commit code Setting up a VCS and commit code So that s how the interface of Google Code looks like, now let s take a look at how to actually commit the code of the project. We re going to use TortoiseSVN to commit code through a graphical interface. Of course this can also be done through a CLI but we will not cover this approach. Here s an overview of commit messages and revision changes. Setting up a VCS and commit code Setting up a VCS and commit code Navigate to the TortoiseSVN webpage ( and download TortoiseSVN. Make some changes in the source code. 12
109 Setting up a VCS and commit code Setting up a VCS and commit code TortoiseSVN spots the differences in the project folder (workspace). You must however first commit your existing codebase for it to track changes done to your project files. Let s commit the changes. Right-click on the project folder and select SVN Commit Setting up a VCS and commit code Setting up a VCS and commit code Any changes made are displayed here, including addition or removal of files (compared to the most recent revision, the HEAD revision). Click on OK to commit the changes. Let s inspect the changes. Right-click on the changed file and select Compare with base. Setting up a VCS and commit code Setting up a VCS and commit code The changes are displayed and highlighted in the TortoiseMerge editor. We can also inspect committed changes between revisions through the Google Code graphical interface. Clicking on diff displays changes made in a particular file. 13
110 Setting up a VCS and commit code Monitoring VCS changes via TeamCity Monitoring VCS changes via TeamCity Here s an example of changes made between r30 and r31 (revision 30 and 31). A lot of code and comment was removed. Monitoring VCS changes via TeamCity Monitoring VCS changes via TeamCity Not every VCS has a graphical interface. In fact, most VCSes can only be accessed and interacted with via CLIs. Let s take a look at how we can monitor the codebase and differences between revisions in the VCS via TeamCity. The first time you navigate to the Changes page in TeamCity you will be presented with an empty list and a message telling you that your VCS username is not set up. So let s set it up by clicking on the link in the text: your VCS username settings. Monitoring VCS changes via TeamCity Monitoring VCS changes via TeamCity Click on Add new VCS username. Once you ve set up a VCS root (we will go over this later on), type in which VCS roots you want to monitor and for what username. The VCS username is the username by which the VCS identifies you. 14
111 Monitoring VCS changes via TeamCity Monitoring VCS changes via TeamCity A new VCS username has been added. The VCS username is the username by which your VCS (Google Code SVN in our case) identifies you. Look up your VCS username by checking the logs of your VCS or refer to the manual of your VCS of choice. Monitoring VCS changes via TeamCity Monitoring VCS changes via TeamCity We can confirm that Google Code SVN identifies us as ci.research.mah@gmail.com through the changes page which lists revisions and details of those revisions (such as who committed them). If we navigate back to the Changes page of TeamCity, we can now see that the revisions are correctly displayed. Monitoring VCS changes via TeamCity Monitoring VCS changes via TeamCity We can also click on the white arrows next to the revisions to expand the details of that particular revision. We re presented with build information in the Builds tab. If we click on the Files tab, we re presented with information about what files were changed for that particular revision. We can see that Test01.java was changed for this revision. By clicking on the link, we get taken to the difference viewer. 15
112 Monitoring VCS changes via TeamCity Setting up a project in TeamCity Setting up a project in TeamCity In the difference viewer we can inspect the changes between revisions, the same way we did through Google Codes graphical interface. This is particularly useful for those working with a repository that does not provide a graphical interface. Setting up a project in TeamCity Setting up a project in TeamCity Now that we a sample project and a connection to the VCS set up, let s take a look at how projects can be set up in TeamCity. Let s start by navigating to the Administration page and clicking on Create project. Setting up a project in TeamCity Setting up a project in TeamCity We ll call our project my-first-project. The Project ID is generated automatically, but we can assign this manully aswell. The project my-first-project is now created. Let s proceed with setting up a VCS Root. 16
113 Setting up a project in TeamCity Setting up a project in TeamCity A VCS Root is a connection to your repository via TeamCity. Click on VCS Roots at the sidebar on the left-hand side. Let s create a new VCS Root by clicking on Create VCS root. Refer to your VCS manual to get the URL of your repository. For Google Code SVN we navigate to Source/Checkout to get the URL of our repository. Setting up a project in TeamCity Setting up a project in TeamCity Our VCS Root has been successfully created. Fill in the information needed to set up a VCS Root. We ll call this VCS Root my-first-project-svn-google-code- VCS-root and fill in the URL of the repository under SVN Connection Settings. Setting up a project in TeamCity Setting up a project in TeamCity We ll call it my-first-buildconfig. Next, let s head back to the General Settings of our project and select Create build configuration. A Build Configuration is a set of settings which determine how the project is built. It also determines what happens before and after builds. 17
114 Setting up a project in TeamCity Setting up a project in TeamCity Now that we ve created a Build Configuration, let s attach it to the VCS Root that we created moments earlier by selecting it from the drop-down list and clicking on Attach. The VCS Root has been successfully attached to my-firstproject. Setting up a project in TeamCity Setting up a project in TeamCity Now let s add a Build Step by clicking on Build Steps in the sidebar and then clicking on the Add build step button. A Build Step is a process which will be executed when the project is run through a particular build configuration. We ll set up our first Build Step as an Ant runner. Let s name it ant-build-step and point toward build_custom.xml. Also, let s make sure it runs the test target (so that it performs JUnit tests). Setting up a project in TeamCity Setting up a project in TeamCity The Build Step ant-build-step was added. Let s set up another Build Step as a Command Line runner. This one will just consist of an echo message, but as you can see this kind of setup provides a lot of possibilities and control over how the project is built. 18
115 Setting up a project in TeamCity Setting up a project in TeamCity Both Build Steps are now set up. Let s move on and add a Trigger. Triggers are used to control when the build is to be triggered, either by an event or at a defined regular time. Setting up a project in TeamCity Setting up a project in TeamCity We ll start by setting up a VCS Trigger. It will trigger whenever a change is detected in the VCS (so whenever a new commit reaches the VCS and a new revision is generated, this Build Configuration will trigger). Next up, we ll set up a Schedule Trigger. It will trigger at a regular interval, in this case it will trigger daily at 2 AM UTC+2, and only if there are pending changes. Setting up a project in TeamCity Setting up a project in TeamCity Our Triggers have been added. Finally, let s take a look at Failure Conditions. Failure Conditions are conditions or events that will cause the build to break. By applying these to the Build Configuration the development team can strictly control and enforce rules regarding which builds pass successfully and which builds fail. 19
116 Setting up a project in TeamCity Setting up a project in TeamCity The Failure condition was added. We ll add a Failure Condition that states that if the build log contains the text test did not pass then the build will result in a failure. Running a build in TeamCity Running a build in TeamCity Running a build in TeamCity Now that we ve set up our project, let s take a look at how to run it manually. In other words, let s find out how to run a TeamCity build. Running a build in TeamCity Running a build in TeamCity Of course, having it set up with Triggers will make sure it runs unattended whenever it s triggered, but for demonstrational purposes we will trigger the build manually. From the Overview page, we can see that our projects has no builds to display, this is because a build has never been run for this project. So let s start by running a build. Run a build of my-first-buildconfig by pressing on the Run button on the far right-hand side. 20
117 Running a build in TeamCity Running a build in TeamCity The build is now running. The build has completed running and the green checkmark is an indication of a successful build, so we can assume that our codebase is stable. Running a build in TeamCity Running a build in TeamCity By hovering over the green checkmark, we can see that the build was successful and also which Build Agent ran the build. If we expand the Build shortcuts menu by clicking on the arrow to the right, we are presented with a few shortcuts that will take us to pages which display details about the build. We can also click on.zip right of the Build log link to download the Build Log as a textfile within an archive file. Running a build in TeamCity Running a build in TeamCity By clicking on the... button next to the Run button we can customize and control the next build to a greater degree. Let s click on it and see what options we are presented with. The first tab of the Run Custom Build menu is the General tab. Here we can assign a different Build Agent to run the build. We can also prioritize the build by putting it to the queue top or we can clean all files in the checkout directory to make sure that we re running a clean build. 21
118 Running a build in TeamCity Running a build in TeamCity The second tab of the Run Custom Build menu is the Parameters tab. Here we can assign various configuration parameters, system properties or environment variables that may affect the outcome of the build. Finally, the last tab of the Run Custom Build menu is the Comment tab. The developer that is triggering the build may leave a comment here if there s a particular reason for why this build is to be run. Taking a look at the Build Configuration Taking a look at the Build Configuration Taking a look at the Build Configuration Now that we know how to run a build manually (and through Triggers), let s take a look at the information that we are provided with through the Build Configuration. Taking a look at the Build Configuration Taking a look at the Build Configuration We ll take a look at the Build Configuration of ci-research-teamcity-test-project as this project contains more interesting data to look at. We ll be navigating to its Build Configuration named buildconfig3. In order to access the Build Configuration we need to click on it from the Overview page. 22
119 Taking a look at the Build Configuration Taking a look at the Build Configuration The first tab that we are presented with is the Overview tab. This tab contains a summary of the current state of the Build Configuration including pending changes, current status and a list of the recent build history. The second tab is the History tab. This tab contains information about the whole history of builds done via buildconfig3. You can also filter by agent name at the top of the tab page. Taking a look at the Build Configuration Taking a look at the Build Configuration The third tab is the Change Log tab. This is where you will find information about changes that occured between and during builds. If we scroll all the way down to build #13 and #14 we can see that some files were edited (and summarized in the commit messages). We can also see that build #13 failed and that the changes made to Test01.java fixed the codebase so that build #14 resulted in a successful build. Taking a look at the Build Configuration Taking a look at the Build Configuration The fourth tab is the Statistics tab. Different kinds of metrics and statistics is displayed here in the form of charts and graphs. Displayed on the image above is a bar chart for the success rate of builds run during a set period of time, as well as a line graph plotting the time of build duration during a period of time. On this image, we have another two line graphs. One is displaying the time a build spent in queue before running during a specified time frame (during a month, as we can see on the far right side Range: Month ). The other is displaying the number of tests that were run during a particular build, also color coding the nodes to signify the amount of failed and passed tests. 23
120 Taking a look at the Build Configuration Taking a look at the Build Configuration Let s hover the mouse over these charts and see what additional information is displayed. By hovering over this bar we can see that 7 builds were run on September 14th, out of which 86% passed. So 6 builds passed during this day and 1 failed. Build #30 was run on the 3rd of October. This build had one of the highest measured build duration out of all of the builds run for this particular Build Configuration at seconds. Taking a look at the Build Configuration Taking a look at the Build Configuration Build #14 spent a relatively long time in queue compared to other builds. It spent 421 milliseconds in queue. This chart might be a bit tricky to understand at first. Let s take a look at build #13. The green node signifies total amount of tests run, regardless of if they passed or failed, we can see that there were 7 total tests run. The red node signifies total amount of failed tests, 4 failed tests in this case. We can also see that these 4 tests that failed were all new tests added recently to the JUnit test class. Finally, the green node signifies total amount of passed tests, 3 tests passed during this build. Taking a look at the Build Configuration Taking a look at the Build Configuration By clicking on a build when highlighting build details, we are taken to the details of the build results (more about this later). Let s take a look at build #13 that had 4 failed tests and 3 that passed. As we can see the failed tests are: testgenerateerror, testmultiplefailasserts, testindexoutofboundsexceptionnotraised and testgeneratefailure. Let s move on from the Statistics tab to the next tab, Compatible Agents. In this tab, we are presented with a list of Build Agents that are compatible with buildconfig3 and are able to run it. By utilizing this configuration, load balancing and decentralized processing can be put into effect. 24
121 Taking a look at the Build Configuration Taking a look at the Build Configuration Next up we have the Pending Changes tab. This tab will provide us with a list of pending changes that have not yet been applied. Finally we have the Settings tab at the end of the tabs bar. In this tab page we can review and edit the Build Configurations, very much in the same way we did when we were setting up a new project. Taking a look at the Build Results Taking a look at the Build Results Taking a look at the Build Results Now that we ve looked at the information that the Build Configuration can provide, let s dive a bit deeper and take a look at the information that individual Build Results can give us. Taking a look at the Build Results Taking a look at the Build Results Let s start off with finding an interesting build to look at. Navigate to the Overview or History tab of the Build Configuration and click on a build. We ll take a closer look at build #14 by clicking on it. The first tab that we are presented with is the Overview tab. This tab contains a summary of the Build Results. We can see that 2 tests passed and that the test was run on the 19th of September at 22:10:31 and ran for 13 seconds in total. We can also see the Build Agent that ran it and how it was triggered (manually or by a Trigger). 25
122 Taking a look at the Build Results Taking a look at the Build Results Moving on to the second tab, which is the Changes tab. This tab displays changes that were made to the codebase between builds. As we can see, the latest change made is with revision 31 of the repository. We can read the commit log message aswell. Let s click on the arrow next to 1 file and see what happens. We can see that Test01.java was edited in the latest revision of the codebase. Taking a look at the Build Results Taking a look at the Build Results Let s move on to the third tab Tests. On this tab page we can gather information about tests that were run for this build. We can see that there were a total of 2 tests run and that they took less than 1 second to run. The scope of tests can be filtered aswell to customize which test suites are shown. Moving on to the next tab, Build Log. This is a central functionality of TeamCity and very useful in determining what went wrong once a build breaks. Expanding the Log tree reveals detailed information about the processes and Build Steps that were run during the build. There is also a way to filter what messages are shown by selecting a different option in the View drop-down list. Taking a look at the Build Results Taking a look at the Build Results Let s expand the Log tree and view details about the Ant target test. We can see that the test suite has 2 test cases. We can also see that 2 tests were run during seconds. Both testcalcsum and teststringconcatenate passed successfully. The next tab that we will be looking at is the Parameters tab. In this tab we are presented with a list of parameters and properties that were in effect when the build was run. This is great for troubleshooting! 26
123 Taking a look at the Build Results Taking a look at the Build Results Let s take a look at various parameters that may be of interest. We can detect the JVM version of the Build Agent that was performing the build. We can also gather various details about the Build Agent from the Parameters tab. We can localize the checkout directory of the Build Agent, if we navigate to that directory we can find the codebase that was pulled from the repository. We can also determine who triggered this build (it s a VCS trigger in this case). Taking a look at the Build Results Taking a look at the Build Results The OS on which the build was run and the environment variable Path can also be determined by looking through the Parameters tab. Finally, the last tab that we ll be looking at is the Artifacts tab. This tab will display all artifacts that were produced by the build. 27
124 Continuous Integration Survey How do we define the minimum requirements of a Continuous Integration System? We are two students from Malmö university in Sweden doing a research on how to define the basic requirements of a CI-system. The survey takes approximately 5 minutes to fill in. Your participation is vital to our study and our effort to answer our research questions. The responses will remain confidential and data gathered in this survey will be handled with care to make it impossible to trace and identify any specific individual or organization. If you would like to be notified of the final results of this study, please enter your address and check the box at the end of this survey. Thank you for your participation! * Required 1. 1 * What kind of business do you operate? Mark only one oval. Administration Computer / IT Economy / Finance Technology / Science Logistics / Transport Other: 2. 2 * How big is your company? Mark only one oval. Small (up to 50 employees) Medium ( employees) Large (over 250 employees) 3. 3 * Does your company utilize a CI-build solution? Mark only one oval. Yes Skip to question 4. No Skip to question 19.
125 4. 4 * What percentage of your developers uses or is affected by the CI-solution (10%, 20%, 30%, 40%, 50% %)? Mark only one oval % 100% 5. 5 * What CI-server software do you use in your company? Mark only one oval. Hudson Bamboo CruiseControl Jenkins BuildMaster TeamCity Continua CI - FinalBuilder Other: 6. 6 * Why did you choose this CI-system over the others (main advantages with your CI-system)? Check all that apply. Low cost (setup and maintenance fee) None Ease of use Fast (building code, processing queries) Easy to troubleshoot Reliable (trust the build) Stable (no system crashes and high availability...etc) Other:
126 7. 7 * What are the main weaknesses with your current CI-system (main disadvantages with your CIsystem)? Check all that apply. Difficult to use Slow Unstable (causes system crashes, low availability..etc) None Difficult to troubleshoot High cost (setup and maintenance fee) Unreliable (don't trust the build) Other: 8. 8 * How frequently does your company use the CI-system to perform builds? Check all that apply. Continuously (several times a day) Daily Weekly Monthly 9. 9 * How long does your CI-system take to build a project? Example: 4:03:32 (4 hours, 3 minutes, 32 seconds) * Does the CI-system that you have lead to better performance in your company? ("No change" represented by 2) Mark only one oval Worse performance Better performance * How would you describe the basic (functional) requirements of your CI-system (what the system should be able to do at the minimal level of operation, core functionalities/components)?
127 * Which of the following are a part of those basic (functional) requirements? Check all that apply. Feedback (through , SMS, Dashboard) Compiling/Building source code Test (Unit test, static analysis) Build agent management (various build agents, build priorities and triggers) Deployment Resource management (systems usage, storage, backup and health) Source code management Administration (setting up users or groups) Other: * Which of the above (functional) requirements that you selected is most important for your CIsystem? * Does the CI-system that you re using meet the minimum (functional) requirements that your company is looking for? Mark only one oval. Yes No * How would you describe the basic (non-functional) requirements of your CI-system (how well does it do what it s supposed to do in terms of performance, usability, reliability, etc.)?
128 * Which of the following are a part of those basic (non-functional) requirements? Check all that apply. Ease to connect with (accessibility) Response time (usability) Ease of modification (extensibility) Ease to be maintained (maintainability) Stable & no crashes (stability & reliability) Ease of use (look and feel standards) Build time (projects/source code) Easy to debug Uptime/downtime (availability) Other: * Which of the above (non-functional) requirements that you selected is most important for your CIsystem? * Does the CI-system that you re using meet the minimum (non-functional) requirements that your company is looking for? Mark only one oval. Yes No Notification of study results * Would you like to be notified of the final results? Mark only one oval. Yes No 20. Please enter your address if the answer is "Yes"!
129 litteraturundersökning - källor Källor (kategori) Källor webbartiklar & yrkeskunskap böcker vetenskapliga artiklar SUMMERING SUMMERING (NFR gruppering) Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Humble, Jez and Farley, Da Continuous Integration: Improving Software Quality and Reducing Risk (Duvall, Paul M., Matyas, Steve and Glover, Andrew) Using continuous integration of code and content to teach software engineering with limited resources A comparison of two iterations of a software studio course based on continuous integration An Open Source-Based Approach to Software Development Infrastructures Enabling Agile Testing Through Continuous Integration Using continuous integration and automated test techniques for a robust C4ISR system Implementing an Effective Test Automation Framework Implementing Continuous Integration towards rapid application development 1
130 litteraturundersökning - funktionella krav (del 1) Funktionella Krav source code management build source code (though build triggers run arbitrary build scripts (build automation run tests support usage of production-like environment for precise testin assessment of test coverage & code complexity source code formatting & conforming to coding standard generate documentation generate differential artifacts (changelog, change scripts for db, version labeling,.. 1 [6] 1 1 [7] [8] 1 [9] 1 1 [10] 1 [11] 1 [12] 1 [13] [14] [15] [16] 1 1 [17] 1 [18] [19] 1 [20] 1 [21] 1 [22] 1 [23] [24] 1 [25] 1 [26] [27] [28] 1 [29] 1 [30] [31] 1 [32] [33] 1 1 [34] 1 [35] 1 [36] 1 [37] [38] 1 1 [39] litteraturundersökning - funktionella krav (del 2) Funktionella Krav feedback/notifications (build status monitoring, error identification artifact & log storage (product aggregation generate install package build verification (testing) bug/issue tracking software metrics tool (benchmarking/performance measuremen concurrency testing code obfuscation deployment rollback production to stable build multiple architecture builds resource management enable automation & provide infrastructure for repeatable buil scheduling 1 [52] [53] [54] [55] [56] [57] [58] 1 [59] 1 1 [60] 1 [61] 1 [62] 1 [63] 1 [64] 1 1 [65] 1 [66] 1 [67] 1 [68] [69] [70] 1 [71] [72] 1 [73] 1 [74] 1 1 [75] 1 [76] 1 [77] [78] [79] [80] 1 1 [81]
131 litt.undersökning - icke-funktionella krav (del 1) Icke-funktionella Krav performance availability how fast can you build a project response times (sending request, interfacing through GUI, startup of system processing times (importing/exporting data, spinning wait cursor-related ease of communication (ease of implementing protocols for intermodular communicatio resource utilization (usage of appropriate resources in an appropriate tim sharing resources uptime/downtime of CI-system, hours of operation (up all the time or scheduled downtime, incl. for maintenanc accessibility to CI-system from workstations (from internet/intranet? connection requirements 1 [89] 1 [90] 1 [91] 1 [92] 1 [93] 1 1 [94] [95] 1 1 [96] 1 [97] 1 [98] 1 [99] 1 1 [100] 1 [101] 1 [102] litt.undersökning - icke-funktionella krav (del 2) usability scalability & capacity extensibility/flexibility & maintainability is the usage of the CI-system user-friendly (look and feel standards any mention of UI (web based, graphical, command line, shell detailed feedback / reporting growth requirement - can the system be scaled up? (software performance increases proportionally with added hardware resource throughput - possible to handle a large amount of requests storage - any mention of storage usage or constraint configurability - how easy is it to modify and extend (f.e. with plugins) the CI-syste maintainability/changeability - ease of improving or adapting the system to changes in environment and requireme 1 [111] 1 [112] 1 [113] [114] [115] 1 [116] 1 [117] 1 [118] 1 [119] [120] 1 [121] 1 [122] 1 [123] 1 [124] [125]
132 litt.undersökning - icke-funktionella krav (del 3) portability & interoperability testability security multiple programming language suppor can the CI-system be used in various environments (operating systems, hardware platform can the CI-system communicate with other systems through established standards, formats and protocols installability - capability of the system to be installed in a specified environmen co-existence - capability of system to share common resources in a common environment with other independent software/syste components can be isolated and mocked trust policies & authorization 1 1 [132] 1 [133] 1 1 [134] [135] 1 1 [136] 1 [137] 1 [138] 1 [139] 1 1 [140] [141] litteraturundersökning - CI-mjukvaror CI-mjukvara (som nämns) TeamCity Jenkins Hudson Team Foundation Build Travis Wercker CruiseControl (incl. CruiseControl.NET & CruiseControl.r Cruise Buildbot CDash Pony-Build (ThoughtWorks) Go Bamboo (Zutubi) Pulse AnthillPro Electric Commander BuildForge Mike CI Continuum TinderBox Automated Build Studio Draco.NET Gauntlet Luntbuild ParaBuild QuickBuild Sin Bitten BuildBeat CM Crossroads Gump PerfectBuild Pragmatic Automation [142]
133 Continuous Integration and Deployment Petrus Kiendys Shadi Al Zara 1. Bakgrund Continuous Integration (CI) är en metod för att effektivt utveckla stabil mjukvara där en grupp utvecklare är inblandade i ett projekt. Syftet med exjobbet är att utforska metoden, kvantifiera dess för- och nackdelar, sätt upp krav för ett CI-system samt implementera ett CI-system för att undersöka om implementationen uppfyller kraven. Kunskapsinsamlingen kommer att lägga grunden för vidareutveckling av kursmaterial i ämnet för vår externa samarbetspartner. Krav och önskemål som ställs på CI-system är att minska kostnaden för mjukvaruutvecklingsprojekt och samtidigt tillföra ökad funktionalitet i form av detaljrika artefakter som genereras när CI-systemet bygger källkod. En annan fördel är att projektledare får större insikt i hur projektet fortskrider och att utvecklare således snabbt kan åtgärda fel. Eftersom utvecklare enligt CI ska integrera kontinuerligt och dessutom använder sig av en rad olika analytiska verktyg så upptäcks fel i källkod tidigt i projekt och mer komplexa problem kan därför tidigt avvärjas. Ett annat krav som ställs på CI-system är således att mjukvaruutvecklingsgrupper förmodas prestera bättre med ett CI-system som stöd. Vi har valt att utforska metoden CI eftersom diskussioner med Edument AB (externt företag) har påvisat att det finns ett intresse och behov i industrin att bedriva ytterligare undersökning och forskning kring ämnet. Ett antal rapporter som kan vara relevanta är A Comparison of Two Iterations of a Software Studio 1 Course Based on Continuous Integration och Implementing Continuous Integration towards 2 rapid application development. 2. Uppdragsbeskrivning Vi kommer till en början att utföra en grundlig förundersökning där vi lär oss mer om CI/CD-metoden. Informationen som vi samlat på oss kommer att filtreras, delas upp och sammanställas i vad som kan utgöra en grund till en nybörjarkurs i CI. Sedan kommer vi undersöka vilka minimumkrav som ett CI-system måste uppfylla enligt standarder som framkommer från litteratur samt en marknadsundersökning. Marknadsundersökningen som utförs kommer att innefatta ca. 10 olika företag som svarar på olika frågor kring CI. Vi kommer att utforma en korrekt enkätstudie så att vi försäkrar oss om att vi får användbara svar ifrån vår marknadsundersökning till vår studie, eventuellt kommer en pilotstudie att genomföras innan den huvudsakliga marknadsundersökningen genomförs. Vi kommer att ställa upp funktionella krav och kvalitetsattribut (som är en del av icke-funktionella krav). Där kommer vi mest att fokusera på performance, usability and availability av ett CI-system. Vi kommer inte att lägga mycket vikt på testability, security and maintainability
134 Både kvalitativ och kvantitativ metod kommer att användas under exjobbets gång, dvs. Creswells mixed methods. För att uppfylla krav som ställs på ingenjörer och ingenjörsverksamhet kommer vi att bygga upp ett CI-system och kravtesta detta system enligt krav som framkommit från litteraturstudien och marknadsundersökningen. Vi kommer till en början att använda oss av CI-systemet TeamCity för att uppfylla det externa företagets krav. I mån av tid kan vi även kravtesta andra CI-system för att få in ett mer objektivt perspektiv över den praktiska delen men vi väljer till en början att avgränsa oss till ett CI-system. Sammanfattningsvis kommer uppdraget bestå av en sammanställning av kunskap kring CI i allmänhet och en praktisk beskrivning på hur ett CI-system kan byggas upp mha. TeamCity, en av de mer populära CI-mjukvarorna. Därefter kommer en marknadsundersökning att utföras bland svenska företag. Slutligen kommer vi att bygga upp ett CI-system och kravtesta systemet enligt de krav som framkommit av litteraturstudien och marknadsundersökningen. 3. Förutsättningar - System som ska användas: TeamCity,... - Vart ska arbetet genomföras: MAH - Aktörer: MAH, Edument AB - Externt företag: Edument AB Stora Varvsgatan 6a, Malmö Tore Nestenius tore@edument.se Förväntas arbeta hos företag till 0% - Arbetsplats på högskolan: Behövs Speciell utrustning: Litteratur Server/servrar för uppbyggnad av CI-system 4. Grov tidsplanering med uppgiftsuppdelning Se bifogad fil Exjobb-tidsplanering VT14 - CI_CD.xlsx för tidsplanering. 2
135 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE Minimum requirements of a CI-system Petrus Kiendys PK Shadi Al-Zara SA 1. Avgränsning av forskningsfrågan eller huvudproblemet, förtydligande av kravspecifikationer 1.1 Bakgrund CI-system används alltmer i näringslivet vid mjukvaruutveckling för att effektivisera 1 arbetsprocessen och tillföra ökad produktionsvärde. I centrum av feedbackloopen mellan utvecklare och slutanvändare ligger CI-system som bevakar arbetsprocessen, effektiviserar integration av källkod mellan ett antal olika individer i en utvecklingsgrupp och ger feedback till utvecklarna så att de kan förbättra källkoden. I takt med en ökad användning av CI-system så ställs allt högre krav på funktionaliteten som systemen ska tillföra. 1.2 Huvudproblem Syftet med examensarbetet är att utforska olika egenskaper hos CI-system och systematiskt kategorisera dessa samt definiera minimumkrav som CI-system måste uppfylla för att vara tillfredställande för ett utvecklingsteam. Vår frågeställning är således följande: 1. Vilka funktionella och icke-funktionella krav måste CI-system uppfylla för att vara till nytta för användning? 2. Kan man enligt definierade krav testa, värdera och jämföra CI-system? 1 M. Larsson and N. Lindholm, "Den agila utvecklingen. En studie baserad på den agila metodikens utformning i praktiken," Student thesis, Y, 2009 [Online] Available: MAH MUEP, [Accessed: ]. 1
136 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE Beskrivande figurer Fig 1. Workflow för CI-system 2 Följande hierarkiska trädstruktur illustrerar uppdelningen av huvudproblemet i delproblem: Fig 2: Uppdelning av huvudproblemet i delproblem och möjliga lösningsprinciper 2 2
137 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE Uppdelning och utförande av arbetet Examensarbetet kommer att delas upp i fyra olika delar: 1. Vi utför en analys av vilka minimumkrav som behöver uppfyllas för att ha ett välfungerande CI-system. Kraven tas fram via en litteraturstudie (DP1.1) och en marknadsundersökning (DP1.2). Vi kommer därefter att dela in kraven i specifika områden dvs. funktionella (LP1.3.1) och icke-funktionella 4 (LP1.3.2) krav för att systematiskt kunna utföra ett kravtest utefter kraven. Funktionella och icke-funktionella krav kommer att definieras mha. use cases resp. quality attribute scenarios. Således kommer kravspecifikationen för CI-system vara förankrat i både vetenskap (LP1.1.2) och industriella erfarenheter (LP1.2.1). 2. När vi väl utformat en kravspecifikation för CI-system så kommer vi att bygga upp en TeamCity-server (DP2.1). Vi avgränsar oss till just en implementation för att vara säkra på att kravtest och behandling av data kan utföras i tid. I mån av tid kan vi även tänka oss implementera flera system och kravtesta dessa. 3. När TeamCity-servern är körbar kan denna testas enligt de krav som vi ställt upp (LP3.1). Vi kan då på ett mer objektivt och systematiskt sätt redogöra för TeamCitys lämplighet för användning i olika sammanhang annat än en subjektiv åsikt. Vi kommer även efter testerna titta på hur TeamCity beskrivs i dokumentation och jämförelsematriser på nätet samt titta på hur andra system (LP3.2), som vi troligtvis inte hinner mäta, beskrivs. 4. Den sista delen av examensarbetet kommer bestå av att behandla data (DP4) som vi fick fram från testfasen. Vi kommer här att diskutera och presentera data (LP4.1) samt dra slutsatser för TeamCity och CI-system utifrån denna data. En artefakt som kommer att produceras under examensarbetet är kursmaterial (LP4.2) till vår externa handledare, denna process kommer löpa parallellt med tidigare nämnda delproblem. 3 Efter diskussioner med vår interna handledare har vi kommit fram till att mixed methods är att föredra som metod när vi analyserar data från marknadsundersökningen och systemtester, samt 4 att vi ska förhålla oss till Software Architecture in Practice när vi utformar den tekniska specifikationen. Följande lista med kravspecifikationer har fastställts. Typbetäckningarna m/i/ö avser minimumkrav, idealkrav resp. önskemål. I tabellen finns också hänvisningar till delproblem och lösningsprinciper i figur 2 som kravspecifikationer framför allt gäller för: Krav -nr. Typ m/i/ö Kravspecifikation K1 m Få ut en lista på minst 5 krav för att kunna kravtesta CI-system K2 m Ha ett körbart CI-system som kan bygga källkod och köra tester K3 m/i Formulera 15/20 frågor som ska användas till marknadsundersökningen Gäller för DP1 DP2 DP1.2 3 Creswell, J.W. (2003). Research design: qualitative, quantitative, and mixed methods approaches. (2. ed.) Thousand Oaks: Sage. 4 Bass, L., Clements, P. & Kazman, R. (2012). Software architecture in practice. (3. ed.) Upper Saddle River, N.J.: Addison-Wesley. 3
138 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE K4 m/i Få ut 10/15 svar från enkätsundersökningen LP1.2.1 K5 ö Bygga upp flera CI-system som kan jämföras med DP2.1 TeamCity K6 m/i Kunna köra 5/10 build agents samtidigt LP2.1.2 K7 m/i Kunna avläsa resultat från kravtest i mindre/större DP3 detaljnivå K8 ö Jämför data från kravtest mellan olika CI-system LP2.1.1 LP3.1 LP3.2 K9 m Jämför mätdata från test på TeamCity med LP3.2 dokumenterade egenskaper i både TeamCity och andra CI-system K10 m Presentera data enligt 3 olika kvalitetsattribut LP4.1 (performance, usability, availability) K11 m/i Skapa 5/10 kapitel till kursmaterialet LP Informationssökning efter vetenskapliga artiklar och yrkeskunskap Följande översikt visar sambandet mellan delproblem (DP) och lösningsprinciper (LP) från figur 2 och de vetenskapliga artiklar och den yrkeskunskap som resulterade från informationssökningen. En kort beskrivning förklarar relevansen av källorna för examensarbetet. DP, LP Källförteckning Relevans DP2 LP2.1.1 Lp2.1.2 DP4 Kawalerowicz, Marcin; Berntson, Craig. "Continuous integration in.net", Manning Publications 2011, [Elektronisk resurs] Bok där man bl.a. behandlar olika komponenter som ingår i ett CI-system och visar hur man presenterar data. DP2.1 Volodymyr Melymuka. TeamCity 7 Continuous Integration Essentials, A step-by-step introductory tutorial and intelligible practical guide to successfully applying Continuous Integration via TeamCity, Birmingham, 2012 Bok som beskriver hur man bygger upp en TeamCity-server (CI-system). Hög relevans. LP1.1.1 Farley, Dave; Humble, Jez. Continuous Delivery Reliable Software Releases through Build, Test, and Deployment Automation, Wesley Professional, pp.63, 2010 [Elektronisk resurs] Bok där man bl.a. behandlar olika komponenter som ingår i ett CI-system. 4
139 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE LP1.1.1 DP2 DP1.2 LP1.2.1 DP1 DP1 DP1 DP1 LP2.1.1 LP2.1.2 LP1.1.2 Duvall, Paul M; Matyas, Steve; Glover, Andrew. Continuous integration: improving software quality and reducing risk, Saddle River, NJ, 2007 Saunders, M; Lewis, P; Thornhill, A. Research methods for business students, 5th ed., Pearson Education,pp , 2009 Amy Brown; Greg Wilson. Continuous Integration in The architecture of open source applications: Elegance,Evolution,and a Few Fearless Hacks, (volume 1), June Continuous Integration- Basic Overview and Best Practices, ntinuous-integration-overview-best-p ractice#.uw5supldvh4 Continuous Integration, nuousintegration.html Continuous Integration Strategies, 3/11/08/ci-strategies-1of3/ Introduction to Continuous Integration with Xamarin s-platform/ci/intro_to_ci/ Yuhoon Ki; Meongchul Song, "An Open Source-Based Approach to Software Development Infrastructures," Automated Software Engineering, ASE '09. 24th IEEE/ACM International Conference on, vol., no., pp.525,529, Nov Bok där man beskriver CI i stort och även komponenter som används i CI-system. Bok där man förklarar hur man går till väga när man genomför en marknadsundersökning genom att förklara diverse undersökningsmetoder som används i näringslivet. Man förklarar även den praktiska relevansen av undersökningsmetoderna. Utdrag ur bok där komponenter och funktionella krav för ett CI-system beskrivs. Medelhög relevans. Webbartikel där komponenter i ett CI-system beskrivs. Väldigt hög relevans eftersom fokus för artikeln sammanfaller med vår frågeställning. Webbartikel av Martin Fowler (en av grundarna av agile manifesto och nykelperson i ThoughtWorks). Denna artikel omnämns och refereras upprepande gånger i både böcker och vetenskapliga artiklar. En genomgång av vad CI är och varför det bör tillämpas. Medelhög relevans. Webbartikel där man går in på en processbeskrivning för hur ett CI-system bör fungera. Hög relevans. Webbartikel där man beskriver några komponenter i olika delar av ett CI-System. Medelhög relevans. Vetenskaplig artikel där man beskriver fördelar med att använda automatiserade mjukvaruutvecklingsverktyg vid mjukvaruutveckling för mer komplexa system. Anger flaskhalsar i mjukvaruutveckling för större projekt och presenterar en 5
140 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE LP1.1.2 DP2.1 DP3 LP1.1.2 LP2.1.2 LP1.1.2 LP1.1.2 DP1 DP1.1 LP1.1.2 Stolberg, S., "Enabling Agile Testing through Continuous Integration," Agile Conference, AGILE '09., vol., no., pp.369,374, Aug Yuksel, H.M.; Tuzun, E.; Gelirli, E.; Biyikli, E.; Baykal, B., "Using continuous integration and automated test techniques for a robust C4ISR system," Computer and Information Sciences, ISCIS th International Symposium on, vol., no., pp.743,748, Sept Eun Ha Kim; Jong Chae Na; Seok Moon Ryoo, "Implementing an Effective Test Automation Framework," Computer Software and Applications Conference, COMPSAC '09. 33rd Annual IEEE International, vol.2, no., pp.534,538, July 2009 Bo Jiang; Zhenyu Zhang; Tse, T. H.; Chen, T.Y., "How Well Do Test Case Prioritization Techniques Support Statistical Fault Localization," Computer Software and Applications Conference, COMPSAC '09. 33rd Annual IEEE International, vol.1, no., pp.99,106, July 2009 Abdul, F.A.; Fhang, M.C.S., "Implementing Continuous Integration towards rapid application development," Innovation Management and Technology Research (ICIMTR), 2012 International Conference on, vol., no., pp.118,123, May 2012 open-source lösning som förbättrar utvecklingsmiljön. Beskriver CI som en del av mjukvaruutvecklingsverktyg som används vid större projekt. Vetenskaplig artikel i form av en case study av hur ett CI-system implementerades när man gick från traditionell till agil utveckling och testning av mjukvara. Beskriver olika steg/komponenter i ett CI-system. Medelhög relevans. Vetenskaplig artikel i form av en case study som visar hur CI-system och automatiserade tester används för att utveckla robusta C4ISR system (command & control, används för kommunikation mellan militärbefälhavare och styrkor). TeamCity används som CI-system. Beskriver koncepten build agents och build configuration som används i TeamCity. Beskriver även testning utförligt. Vetenskaplig artikel där man beskriver grundläggande steg i bygge av mjukvara som bl.a. involverar en VCS, en CI-server och automatiserad testserver. Medelhög relevans. Vetenskaplig artikel där man beskriver olika steg i bygge av mjukvara mha. CI-system. Vetenskaplig artikel där man beskriver grundläggande CI-system komponenter och arbetsprocessen. 6
141 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE DP2.1 DP1 DP2 ay/tcd8 Staffan Persson. Introducing Continuous Integration in an Enterprise Scale Environment. Uppsala Universitet, 2008 Dokumentation av TeamCity. Hög relevans. Examensarbete där man förklarar hur befintliga mjukvaruutvecklingsmiljöer kan ändras för att innefatta en CI-process. Beskriver komponenter i ett CI-system. Hög relevans. 3. Genomförbarhetsanalys Till en början tänkte vi att vårt examensarbete skulle innefatta både sociala och tekniska aspekter av att tillämpa CI-system i en verksamhet men efter diskussion och feedback från lärarlaget i samband med problemformuleringsredovisningen blev vi tvungna att omvärdera omfattningen av arbetet. Vi har därför bestämt oss att avgränsa oss till att endast innefatta en teknisk aspekt av CI-system i detta examensarbete. Detta innebär att vi kan uppfylla både MAH s och vår externa handledares krav under arbetets gång. Som tidigare nämnt kommer examensarbetet att bestå av 4 delar (se 1.2 Huvudproblem). Genomförbarheten för att ställa upp krav för CI-system DP1 är mellanhög till hög. Vi har lyckats hitta enstaka artiklar som objektivt beskriver grundfunktionalitet och krav som CI-system ska uppfylla. Det är mycket möjligt att vi ger oss in på ett tidigare outforskat forskningsområde och kommer därför stöta på hinder men även möjlighet till att bidra till forskningen på ett unikt sätt. Genomförbarheten av DP1.2 är hög eftersom vår externa handledare kan tillhandahålla kontakter inom näringslivet, undersökningen kan även lägga grund till DP1 eftersom litteraturundersökningen påvisar att det finns väldigt lite relevanta vetenskapliga artiklar kring ämnet, däremot finns det mycket med yrkeskunskap i form av webbartiklar och böcker skrivna om ämnet. Att bygga upp ett CI-system DP2 ska kunna utföras förutsatt att vi får tillgång till hårdvara i tid, vi upskattar att genomförbarheten för DP2 är väldigt hög. Vi har redan börjat diskutera med handledare och IT-support för att få tillgång till hårdvara samt börjat orientera oss kring implementation av TeamCity. Testa CI-system enligt krav DP3, denna del är beroende av utförandet av DP1 och DP2. Förutsatt att DP1 och DP2 utförs med tillfredställande resultat uppskattar vi att genomförbarheten av LP3.1 är hög. CI-system brukar innehålla stöd för mätningar eller extensibility i form av plugins, oavsett om man använder sig av förstaparts eller tredjepartsverktyg för test så uppskattar vi att test kommer att kunna utföras. Angående LP3.2 uppskattar vi genomförbarheten till mellanhög. Vi har hittat funktionalitetsmatriser mellan olika populära CI-system, frågan återstår om dessa datan från dessa matriser sammanfaller med de krav som vi kommer att ställa upp. Behandla och presentera data DP4 & LP4.1 är givetvis beroende av föregående delproblem. Precis som med DP3 så uppskattar vi att genomförbarheten är hög förutsatt att vi har data att arbeta med från DP3. Skapa kursmaterial LP4.2 genomför vi parallellt med tidigare nämnda delproblem och uppskattar att genomförbarheten är hög. 7
142 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE Vi anser att examensarbetet är genomförbart i nuläget, vissa delar kan ta mer tid än vad vi uppskattar men på det stora hela anser vi att genomförbarheten för examensarbetet är hög. 4. Detaljplanering med ansvars- och uppgiftsuppdelning 8
143 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE Disposition av rapporten 1. Sammanfattning (Abstract) 2. Innehållsförteckning 3. Inledning a. Bakgrund i. Inledning till examensarbete ii. Målgrupp för examensarbete b. Syfte och frågeställning i. Varför valde vi detta ämne? c. Uppdragsbeskrivning i. Internt uppdrag ii. Externt uppdrag d. Förutsättningar och avgränsningar e. Tidigare forskning f. Metod - Hur arbetet ska genomföras i. Creswells mixed methods - kvalitativ och kvantitativ dataanalys ii. Funktionella och icke-funktionella krav 4. Teknisk beskrivning (Teori) - Grundlig beskrivning av teoretiska aspekter, även lite breddning åt håll som vi inte tittar närmare på a. Agila metoder - Vad är agila metoder? b. Continuous Integration - Vad är CI och varför används det? c. CI-system - Hur stödjer man arbetsprocessen CI mha. verktyg? Vilka verktyg finns det att välja mellan? d. Hur ställer man upp krav för system? e. Hur ställer man upp tester för system? 5. Utförande - Hur har vi gjort? Varför gjorde vi så? a. Hur utförde vi studien kring kravspecifikation för CI-system? b. Varför valde vi TeamCity och hur byggde vi upp CI-systemet? i. Vilka CI-system finns det, varför valde vi TeamCity? c. Vilka tester valde vi att genomföra och vad vill vi komma fram till genom testerna? 6. Resultat a. Krav för CI-system b. Uppbyggnad av ett CI-system (TeamCity) c. Tester 7. Slutsats 8. Diskussion a. För- och nackdelar med CI-system b. Stämmer resultaten överens med vår hypotes? - Är resultaten och mätdatan tillfredställande för att kunna göra en bra bedömning och komma fram till en tydlig slutsats? c. Förbättringar - Saker som kan ha gjorts bättre, alternativlösningar d. Vidare forskning - Frågeställningar som uppkom i samband med studien 9. Referenser a. appendix A i. bilaga 1: Kursmaterial till extern handledare b. appendix B 9
144 Examensarbete VT2013 inom högskoleingenjörsprogram Data & telekom och Programvaruutveckling Teknik och samhälle Institutionen för datavetenskap FÖRSTUDIE Källförteckning 1. M. Larsson and N. Lindholm, "Den agila utvecklingen. En studie baserad på den agila metodikens utformning i praktiken," Student thesis, Y, 2009 [Online] Available: MAH MUEP, [Accessed: ] Creswell, J.W. (2003). Research design: qualitative, quantitative, and mixed methods approaches. (2. ed.) Thousand Oaks: Sage. 4. Bass, L., Clements, P. & Kazman, R. (2012). Software architecture in practice. (3. ed.) Upper Saddle River, N.J.: Addison-Wesley. 10
145 Mätning av respons Tester 1 (experimental) Huvudområde Respons Uppgift Task time [1] Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför? [4] Task nr. Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1 Testare identifierare systemets funktioner 0: : _1200 Inlärning av GUI:t är tydligt och lättanvänt Navigera till "build" sektion av CI-system [7] Navigera till "inställningar" sektion av CI-system 7: Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [8] 2: Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [9] 1: Öppna en "build log" och granska tester som körts [10] 2: GUI:ns design är baserad på progressive disclosure Fäll ut och fäll ihop detaljer kring incheckningar 1: Det är enkelt att automatisera funktioner som ofta kommer Lägg till en "trigger" i en "build configuration" [11] 2: att använd Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [12] 5: Kompilera källkod för ett projekt [13] 0: Kör enhetstester för ett projekt [14] 1: Återanvändning av data/kommandon Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration" 4: Unable to locate button/interface to create and copy the build configurat Dialogrutor och säkringar Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att 1: Minimera inverkan av fel bekräftelseruta dyker Möjlighet att ångra ändringar Stoppa en pågående "build" 1: Ändra säkerhetsinställningar och ångra ändringen 1: Anpassning av systemet Systemets utseende och funktionalitet Dölj ett projekt från "Projekt" sektionen av CI-systemet 2: för användarens beh kan ändras Inge förtroende och tillfredsställelse Systemets tillstånd åskådliggörs tydligt för användaren Kontrollera om kodbasen för ett visst projekt är stabil (grön) 5: eller bruten (röd) [15] Navigera till "användningsstatistik" sektion av CI-system 6: Incorrect input, mistook "Java version" for "Java runtime version" Övrig information Tester 2 (experimental) Mätning av respons Övrig information Huvudområde Respons Uppgift Task time Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför? Task nr. Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1 Testare identifierare systemets funktioner 1: : _1300 Inlärning av GUI:t är tydligt och lättanvänt Navigera till "build" sektion av CI-system [22] Navigera till "inställningar" sektion av CI-system 3: Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [23] 5: Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [24] 1: Öppna en "build log" och granska tester som körts [25] 5: GUI:ns design är baserad på progressive disclosure Fäll ut och fäll ihop detaljer kring incheckningar 1: Det är enkelt att automatisera funktioner som ofta kommer Lägg till en "trigger" i en "build configuration" [26] 2: att använd Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [27] 6: Kompilera källkod för ett projekt [28] 1: Kör enhetstester för ett projekt [29] 3: Återanvändning av data/kommandon Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration" 2: Minimera inverkan av fel Dialogrutor och säkringar Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker 0: Möjlighet att ångra ändringar Stoppa en pågående "build" 1: Ändra säkerhetsinställningar och ångra ändringen 2: Anpassning av systemet Systemets utseende och funktionalitet Dölj ett projekt från "Projekt" sektionen av CI-systemet 3: för användarens beh kan ändras Inge förtroende och tillfredsställelse Systemets tillstånd åskådliggörs tydligt för användaren Kontrollera om kodbasen för ett visst projekt är stabil (grön) 5: eller bruten (röd) [30] Navigera till "användningsstatistik" sektion av CI-system 0: Tester 3 (experimental) Mätning av respons Övrig information Huvudområde Respons Uppgift Task time Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför? Task nr. Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1 Testare identifierare systemets funktioner 0: : _1800 Inlärning av GUI:t är tydligt och lättanvänt Navigera till "build" sektion av CI-system [37] Navigera till "inställningar" sektion av CI-system 1: Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [38] 1: Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [39] 1: Öppna en "build log" och granska tester som körts [40] 3: GUI:ns design är baserad på progressive disclosure Fäll ut och fäll ihop detaljer kring incheckningar 0: Det är enkelt att automatisera funktioner som ofta kommer Lägg till en "trigger" i en "build configuration" [41] 3: att använd Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [42] 3: Kompilera källkod för ett projekt [43] 1: Kör enhetstester för ett projekt [44] 1: Återanvändning av data/kommandon Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration" 3: Minimera inverkan av fel Dialogrutor och säkringar Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker 2: Möjlighet att ångra ändringar Stoppa en pågående "build" 1: Ändra säkerhetsinställningar och ångra ändringen 1: Anpassning av systemet Systemets utseende och funktionalitet Dölj ett projekt från "Projekt" sektionen av CI-systemet 2: för användarens beh kan ändras Inge förtroende och tillfredsställelse Systemets tillstånd åskådliggörs tydligt för användaren Kontrollera om kodbasen för ett visst projekt är stabil (grön) 2: eller bruten (röd) [45] Navigera till "användningsstatistik" sektion av CI-system 1:
146 Mätning av respons Tester 4 (experimental) Huvudområde Respons Uppgift Task time Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför? Task nr. Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1 Testare identifierare systemets funktioner 1: : _1500 Inlärning av GUI:t är tydligt och lättanvänt Navigera till "build" sektion av CI-system [52] Navigera till "inställningar" sektion av CI-system 1: Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [53] 2: Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [54] 1: Öppna en "build log" och granska tester som körts [55] 3: GUI:ns design är baserad på progressive disclosure Fäll ut och fäll ihop detaljer kring incheckningar 2: Det är enkelt att automatisera funktioner som ofta kommer Lägg till en "trigger" i en "build configuration" [56] 2: att använd Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [57] 5: Kompilera källkod för ett projekt [58] 1: Kör enhetstester för ett projekt [59] 2: Återanvändning av data/kommandon Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration" 3: Minimera inverkan av fel Dialogrutor och säkringar Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker 2: Möjlighet att ångra ändringar Stoppa en pågående "build" 1: Ändra säkerhetsinställningar och ångra ändringen 2: Anpassning av systemet Systemets utseende och funktionalitet Dölj ett projekt från "Projekt" sektionen av CI-systemet 4: för användarens beh kan ändras Inge förtroende och tillfredsställelse Systemets tillstånd åskådliggörs tydligt för användaren Kontrollera om kodbasen för ett visst projekt är stabil (grön) 1: eller bruten (röd) [60] Navigera till "användningsstatistik" sektion av CI-system 1: Tester 5 (experimental) Övrig information Mätning av respons Övrig information Huvudområde Respons Uppgift Task time Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför? [64] Task nr. Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1 Testare identifierare systemets funktioner 1: : _1600 Inlärning av GUI:t är tydligt och lättanvänt Navigera till "build" sektion av CI-system [67] Navigera till "inställningar" sektion av CI-system 2: Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [68] 2: Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [69] 1: Öppna en "build log" och granska tester som körts [70] 2: GUI:ns design är baserad på progressive disclosure Fäll ut och fäll ihop detaljer kring incheckningar 1: Det är enkelt att automatisera funktioner som ofta kommer Lägg till en "trigger" i en "build configuration" [71] 3: att använd Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [72] 4: Kompilera källkod för ett projekt [73] 1: Kör enhetstester för ett projekt [74] 1: Återanvändning av data/kommandon Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration" 3: Minimera inverkan av fel Dialogrutor och säkringar Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker 1: Möjlighet att ångra ändringar Stoppa en pågående "build" 1: Ändra säkerhetsinställningar och ångra ändringen 2: Anpassning av systemet Systemets utseende och funktionalitet Dölj ett projekt från "Projekt" sektionen av CI-systemet 3: för användarens beh kan ändras The tester was unable to locate the element that disables visibility of a pro Inge förtroende och tillfredsställelse Systemets tillstånd åskådliggörs tydligt för användaren Kontrollera om kodbasen för ett visst projekt är stabil (grön) 1: eller bruten (röd) [75] Navigera till "användningsstatistik" sektion av CI-system 1: Tester 6 (control) Mätning av respons Övrig information Huvudområde Respons Uppgift Task time Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför? Task nr. Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1 Testare identifierare systemets funktioner 0: : _1600 Inlärning av GUI:t är tydligt och lättanvänt Navigera till "build" sektion av CI-system [82] Navigera till "inställningar" sektion av CI-system 1: Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [83] 2: Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [84] 0: Öppna en "build log" och granska tester som körts [85] 0: GUI:ns design är baserad på progressive disclosure Fäll ut och fäll ihop detaljer kring incheckningar 0: Det är enkelt att automatisera funktioner som ofta kommer Lägg till en "trigger" i en "build configuration" [86] 1: att använd Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [87] 2: Kompilera källkod för ett projekt [88] 1: Kör enhetstester för ett projekt [89] 1: Återanvändning av data/kommandon Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration" 1: Minimera inverkan av fel Dialogrutor och säkringar Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker 0: Möjlighet att ångra ändringar Stoppa en pågående "build" 0: Ändra säkerhetsinställningar och ångra ändringen 1: Anpassning av systemet Systemets utseende och funktionalitet Dölj ett projekt från "Projekt" sektionen av CI-systemet 1: för användarens beh kan ändras Inge förtroende och tillfredsställelse Systemets tillstånd åskådliggörs tydligt för användaren Kontrollera om kodbasen för ett visst projekt är stabil (grön) 0: eller bruten (röd) [90] Navigera till "användningsstatistik" sektion av CI-system 1: Average (experimental) Mätning av respons Övrig information Huvudområde Respons Uppgift Task time Användarens tillfredställelse Löstes uppgiften? [villkorlig] Om uppgiften inte löstes, varför? Task nr. Genomsnitt för användarens tillfredställels Total tid för utförande av samtliga tasks Totalt antal uppgifter som löstes (max: 1 Testare identifierare systemets funktioner 1: : avg_exp Inlärning av GUI:t är tydligt och lättanvänt Navigera till "build" sektion av CI-system [97] Navigera till "inställningar" sektion av CI-system 3: Läs ett incheckningsmeddelande från centralkatalogen via CI-systemet [98] 2: Öppna en källkodsfil och granska ändringar som lagts till i valfri revision [99] 1: Öppna en "build log" och granska tester som körts [100] 3: GUI:ns design är baserad på progressive disclosure Fäll ut och fäll ihop detaljer kring incheckningar 1: Det är enkelt att automatisera funktioner som ofta kommer Lägg till en "trigger" i en "build configuration" [101] 2: att använd Lägg till en "build step" i en "build configuration" och kör ett valfritt "build script" [102] 5: Kompilera källkod för ett projekt [103] 1: Kör enhetstester för ett projekt [104] 2: Återanvändning av data/kommandon Skapa en ny "build configuration" genom att kopiera en befintlig "build configuration" 3: Minimera inverkan av fel Dialogrutor och säkringar Ta bort "build configuration" som skapades i föregående uppgift(er) och kontrollera att bekräftelseruta dyker 1: Möjlighet att ångra ändringar Stoppa en pågående "build" 1: Ändra säkerhetsinställningar och ångra ändringen 2: Anpassning av systemet Systemets utseende och funktionalitet Dölj ett projekt från "Projekt" sektionen av CI-systemet 3: för användarens beh kan ändras Inge förtroende och tillfredsställelse Systemets tillstånd åskådliggörs tydligt för användaren Kontrollera om kodbasen för ett visst projekt är stabil (grön) 3: eller bruten (röd) [105] Navigera till "användningsstatistik" sektion av CI-system 2:
147 Usability test - user form (TeamCity) Please fill in this form as you're doing the usability test. This form contains all tasks that you need to complete. We will monitor your progress through screen capture software during the test. You may go back to previous tasks to read the task descriptions once again but you may not change previous answers that you have submitted. To provide clarification, the help text of each task is simplified by a set number of steps, denoted by (#), ie. "(1) perform step 1, (2) perform step 2." If you are unable to complete a specific task, please explain why you were unable to complete that task. Please be aware that this is a usability test that is used to measure the usability of TeamCity and is not targeted at measuring your ability as a tester to solve problems and perform tasks, so please do not feel under pressure to perform. Simply read the task instructions and do your best to complete the tasks. The test contains 17 tasks that you will perform, the 17 tasks are structured into 3 main parts: - Interaction with the UI & VCS, changing settings - Compiling and testing code, reading logs - Setting up a custom build configuration After completing all of the tasks a short series of questions may be answered in a 1-5 Likert scale format to convey your overall impression of TeamCity from a usability standpoint. Feel free to get acquainted with the interface of TeamCity and TeamViewer before you start taking the test. An assistant will be offering assistance during the test if needed, please do not hesitate to type any questions or concerns into the TeamViewer chat. If you are unable to complete a task and subsequent tasks depend on the completion of that specific task, the assistant will set up TeamCity so that you can proceed with the test. The assistant will communicate with you through chat and voice when needed. Please answer a few short questions below before proceeding with the test. When you're ready, go to the next page. * Required 1. Your * 2. Occupation * What is your job title? What is your task assignment (what is it that you do at your workplace)? 3. Experience with CI-systems (build servers) * Have you worked with CI-systems (build servers) before? Popular CI-systems include TeamCity, Hudson, Jenkins, Bamboo and CruiseControl. Mark only one oval. Yes No After the last question in this section, stop filling out this form.
148 4. Experience with which CI-systems? If you answered "Yes" to the question above, please list the CI-systems that you have experience with: 5. Experience with TeamCity * Have you worked with TeamCity before? Mark only one oval. Yes No 6. Notification of study results * Would you like to be notified of the results of this study? Mark only one oval. Yes No 7. Task 1: Navigate to the " settings" section of TeamCity You are currently in the "Overview page". (1) Navigate to "Administration". (2) Look at the sidebar to the left. (3) Look at the 3 items nested under "Integrations". Which item is located in-between "Issue Tracker" and "Tools"?: 8. Check all that apply. Unable to complete task 9. User satisfaction * Were you able to perform this task with ease? What is your overall satisfaction of performing this task? Mark only one oval low satisfaction high satisfaction 10. If you were unable to perform the task, please explain why Why were you unable to perform the task? (What was the main obstacle in performing this task, what made it difficult to perform this task?)
149 11. Task 2: Change " Authentication" settings and revert the changes You are currently in the "Administration page". (1) Navigate to "Authentication". (2) Change the guest user username to "guest123" and (3) save the changes. Next, (4) revert the changes and (5) confirm that the default settings were restored. Were you able to successfully make changes and revert the changes? Mark only one oval. Yes No (please explain why below) 12. Check all that apply. Unable to complete task 13. User satisfaction * Were you able to perform this task with ease? What is your overall satisfaction of performing this task? Mark only one oval low satisfaction high satisfaction 14. If you were unable to perform the task, please explain why Why were you unable to perform the task? (What was the main obstacle in performing this task, what made it difficult to perform this task?) 15. Task 3: Navigate to " Usage Statistics" (1) Navigate to "Usage Statistics". What "java runtime version" is the server running? (Hint: feel free to use ctrl+f) 16. Check all that apply. Unable to complete task 17. User satisfaction * Were you able to perform this task with ease? What is your overall satisfaction of performing this task? Mark only one oval low satisfaction high satisfaction
150 18. If you were unable to perform the task, please explain why Why were you unable to perform the task? (What was the main obstacle in performing this task, what made it difficult to perform this task?) 19. Task 4: Hide a visible project (1) Navigate back to the "Overview page" (the first page you were presented with) and (2) hide the project "dt3-robotlego-2012ht-white". Only "ci-research-teamcity-test-project" should be visible. Check all that apply. Done 20. Check all that apply. Unable to complete task 21. User satisfaction * Were you able to perform this task with ease? What is your overall satisfaction of performing this task? Mark only one oval low satisfaction high satisfaction 22. If you were unable to perform the task, please explain why Why were you unable to perform the task? (What was the main obstacle in performing this task, what made it difficult to perform this task?) 23. Task 5: Verify if a project is stable or broken Judging by what you can see on the current page ("Overview page"), (1) is the current build of "ci-research-teamcity-test-project" stable or broken? (You may click on different elements on this page, but do not navigate from the "Overview page") Mark only one oval. Stable Broken
151 24. Check all that apply. Unable to complete task 25. User satisfaction * Were you able to perform this task with ease? What is your overall satisfaction of performing this task? Mark only one oval low satisfaction high satisfaction 26. If you were unable to perform the task, please explain why Why were you unable to perform the task? (What was the main obstacle in performing this task, what made it difficult to perform this task?) 27. Task 6: Read a commit log message (1) Navigate to "Changes" to pull information from the connected VCS. What is the commit log message of revision 29, committed "14 Sep 14 19:11"? (Hint: feel free to copy-paste the message instead of typing it manually, try right-clicking and selecting "copy" if ctrl+c is unresponsive) 28. Check all that apply. Unable to complete task 29. User satisfaction * Were you able to perform this task with ease? What is your overall satisfaction of performing this task? Mark only one oval low satisfaction high satisfaction
152 30. If you were unable to perform the task, please explain why Why were you unable to perform the task? (What was the main obstacle in performing this task, what made it difficult to perform this task?) 31. Task 7: Expand the details of a revision (1) Expand revision 29 and specify the name of the.java file that was edited: test/packdemo/ 32. Check all that apply. Unable to complete task 33. User satisfaction * Were you able to perform this task with ease? What is your overall satisfaction of performing this task? Mark only one oval low satisfaction high satisfaction 34. If you were unable to perform the task, please explain why Why were you unable to perform the task? (What was the main obstacle in performing this task, what made it difficult to perform this task?)
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
Läs merLinkö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,
Läs merKvalitetssäkra ditt projekt med kontinuerlig integration
Kvalitetssäkra ditt projekt med kontinuerlig integration Mathias Olausson http://olausson.net/blog Om oss: QWise Vi hjälper systemutvecklingsteam att bli bättre. Vi är experter på ALM och Team System.
Läs merÖ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
Läs merQC 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
Läs merSänk kostnaderna genom a/ ställa rä/ krav och testa effektivt
Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning
Läs merTestdriven 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
Läs merLinkö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?
Läs merKONSTFACK Institutionen för design, inredningsarkitektur och visuell kommunikation KURSPLAN
KONSTFACK Institutionen för design, inredningsarkitektur och visuell kommunikation KURSPLAN Breddning av industridesign Broadening of Industrial design 27,5 högskolepoäng / 27,5 credits Kurskod: IDK215
Läs merVersionshantering. Problem som uppstår i större (samt även mindre) projekt:
Versionshantering Problem som uppstår i större (samt även mindre) projekt: Samtidiga ändringar. Kålle och Ada öppnar samma fil för redigering vid var sin dator. Om Kålle först sparar sina ändringar och
Läs merFilhanterare 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
Läs merPMM (Process Maturity Metrics) Allmänt. Mätetal för framgångsfaktorer. 1. CM konfigurationsstyrning
PMM (Process Maturity Metrics) PMM är en metod för att mäta processmognad i utvecklingsprojekt. I korthet går metoden ut på att man utvärderar sin utvecklingsprocess med avseende på ett antal framgångsfaktorer
Läs merTMP Consulting - tjänster för företag
TMP Consulting - tjänster för företag Adress: http://tmpc.se Kontakta: info@tmpc.se TMP Consulting är ett bolag som utvecklar tekniska lösningar och arbetar med effektivisering och problemslösning i organisationer.
Läs merRegressionstestning 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
Läs merMönster. Ulf Cederling Växjö University Ulf.Cederling@msi.vxu.se http://www.msi.vxu.se/~ulfce. Slide 1
Mönster Ulf Cederling Växjö University UlfCederling@msivxuse http://wwwmsivxuse/~ulfce Slide 1 Beskrivningsmall Beskrivningsmallen är inspirerad av den som användes på AG Communication Systems (AGCS) Linda
Läs merUndervisningen 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
Läs merTestning som beslutsstöd
Testning som beslutsstöd Vilken typ av information kan testning ge? Vilken typ av testning kan ge rätt information i rätt tid? Hur kan testning hjälpa din organisation med beslutsstöd? Hur kan produktiviteten
Läs merKritisk reflektion av använd teori för införande av digitala teknologier, Tidsläckage Teorin.
Examensarbete Magisterprogrammet Digital Affärsutveckling, kurs uppgift 3 teori-reflektion. Kritisk reflektion av använd teori för införande av digitala teknologier, Tidsläckage Teorin. Författare: Magnus
Läs merKristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson
Rapport grupp 4 Software Engineering Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson 2009-10-29 Processer Sprinter Scrum har varit till stor hjälp för oss för att nå våra mål,
Läs merEnterprise App Store. Sammi Khayer. Igor Stevstedt. Konsultchef mobila lösningar. Teknisk Lead mobila lösningar
Enterprise App Store KC TL Sammi Khayer Konsultchef mobila lösningar Familjen håller mig jordnära. Arbetar med ledarskap, mobila strategier och kreativitet. Fotbollen ger energi och fokus. Apple fanboy
Läs merBION03, Biologi: Examensarbete - masterexamen, 60 högskolepoäng Biology: Master s Degree Project, 60 credits Avancerad nivå / Second Cycle
Naturvetenskapliga fakulteten BION03, Biologi: Examensarbete - masterexamen, 60 högskolepoäng Biology: Master s Degree Project, 60 credits Avancerad nivå / Second Cycle Fastställande Kursplanen är fastställd
Läs mermen borde vi inte också testa kraven?
men borde vi inte också testa kraven? Robert Bornelind Presentation på SAST, 24 februari 2011 SQS Software Quality Systems Sweden AB Innehåll Introduktion Kvalitet, tid och kostnad Process Testning av
Läs merBedömningsmall med riktlinjer för kvalitetskriterier för bedömning av examensarbete master+civilingenjör
Bedömningsmall med riktlinjer för kvalitetskriterier för bedömning av examensarbete master+civilingenjör Examensarbetet bedöms i områdena: Process, Ingenjörsmässigt och vetenskapligt innehåll samt Presentation.
Läs merRUP - Rational Unified Process
IBM Software Group RUP - Rational Unified Process Eva Hådding eva.hadding@se.ibm.com 1 Projektkaos. Chaos-rapporten 28% av projekten avslutades i tid och enligt budget. 49% av projekten drog över de ursprungliga
Läs merProjektplan, 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)
Läs merDr. Gustav Taxén MDI-Gruppen, CSC / VIC-Sthlm gustavt@kth.se
Att utvärdera spel Dr. Gustav Taxén MDI-Gruppen, CSC / VIC-Sthlm gustavt@kth.se Att utvärdera spel Buggar / logikfel: QA Upplevelsen: Playtesting Utvecklingsprocessen: Post Mortem BUGGAR / LOGIKFEL Unit
Läs merPROGRAMMERING. Ämnets syfte. Kurser i ämnet
PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration
Läs merKursplan. FÖ3032 Redovisning och styrning av internationellt verksamma företag. 15 högskolepoäng, Avancerad nivå 1
Kursplan FÖ3032 Redovisning och styrning av internationellt verksamma företag 15 högskolepoäng, Avancerad nivå 1 Accounting and Control in Global Enterprises 15 Higher Education Credits *), Second Cycle
Läs merConfiguration Management Vägen till ordning och reda med rätt stöd! 2010-03-23. Greger.Ohlsson@bita.eu
Configuration Management Vägen till ordning och reda med rätt stöd! 2010-03-23 Greger.Ohlsson@bita.eu BiTA Service Management Tjänsteområden inom utbildning och konsultation: IT-styrning IT-kvalitet IT-effektivitet
Läs merPSYKOLOGISKA INSTITUTIONEN
PSYKOLOGISKA INSTITUTIONEN PX1500 Psykologi: Forskningsmetod och kandidatuppsats, 30 högskolepoäng Psychology: Research Methods and Bachelor Thesis in Psychology, 30 higher education credits Fastställande
Läs merPROGRAMMERING. Ämnets syfte. Kurser i ämnet
PROGRAMMERING Ämnet programmering behandlar hur mjukvaror skapas, anpassas och utvecklas samt programmeringens roll i informationstekniska sammanhang som datorsimulering och praktisk datoriserad problemlösning.
Läs merInformation technology Open Document Format for Office Applications (OpenDocument) v1.0 (ISO/IEC 26300:2006, IDT) SWEDISH STANDARDS INSTITUTE
SVENSK STANDARD SS-ISO/IEC 26300:2008 Fastställd/Approved: 2008-06-17 Publicerad/Published: 2008-08-04 Utgåva/Edition: 1 Språk/Language: engelska/english ICS: 35.240.30 Information technology Open Document
Läs merPSYKOLOGISKA INSTITUTIONEN
PSYKOLOGISKA INSTITUTIONEN PX1500 Psykologi: Forskningsmetod och kandidatuppsats, 30 högskolepoäng Psychology: Research Methods and Bachelor Thesis in Psychology, 30 higher education credits Fastställande
Läs merSäkerställ er tillgänglighet Kommunikationsrapporteringsverktyg
Säkerställ er tillgänglighet Kommunikationsrapporteringsverktyg Vad är Meridix Studio? Meridix Studio är ett verktyg som låter er analysera och följa upp er kommunikation via ett enkelt men kraftfullt
Läs merDATA- OCH INFORMATIONSTEKNIK
DATA- OCH INFORMATIONSTEKNIK DIT560 Examensarbete i datalogi för kandidatexamen, 15 högskolepoäng Bachelor s Thesis, 15 higher Fastställande Kursplanen är fastställd av IT-fakultetsnämnden 2006-11-17 och
Läs merPresentation. Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban
Presentation Fredrik Runnsjö 1996 Utvecklare 2004 Testare ~2006 Scrum/Canban Om AddQ Mission Vi skapar affärsnytta för kunden genom specialisttjänster inom test, kvalitetssäkring och effektivisering Tjänsteområden
Läs merAtt fastställa krav. Annakarin Nyberg
Att fastställa krav Annakarin Nyberg Disposition Del 1 Varför samla in krav? Typer av krav Interaktionsdesign och krav Del 2 Analys, tolkning och presentation Scenarios Use cases Task analysis Avslutning
Läs merProjektkaos. Chaos-rapporten. 34% av projekten avslutades i tid och enligt budget... ... 66% misslyckades!
Projektkaos. Chaos-rapporten 34% av projekten avslutades i tid och enligt budget...... 66% misslyckades! 1 Standish Group, 2003 (www.standishgroup.com) Praxis Hantera krav Använd komponentarkitekturer
Läs merSKOLFS. beslutade den XXX 2017.
1 (11) Föreskrifter om ändring i Skolverkets föreskrifter (SKOLFS 2010:247) om ämnesplan för ämnet programmering i gymnasieskolan, inom kommunal vuxenutbildning på gymnasial nivå och inom vidareutbildning
Läs merSystem arbetssystem informationssystem
System arbetssystem informationssystem Vad är ett system? Exempel - Matsmältningssystemet - Immunförsvaret - Ett hemelektroniksystem -En skola System - definition Ett system är en uppsättning interagerande
Läs merJavautvecklare. Utbildningsfakta. 400 YH-poäng, 2 år
Javautvecklare 400 YH-poäng, 2 år Utbildningsfakta Kurser (12 stycken) Grundläggande programmering och javaverktyg 50 yhp Grafiskt gränssnitt och interaktion 20 yhp Internet, webb och webbramverk 40 yhp
Läs merBedömningsmall med riktlinjer för kvalitetskriterier för bedömning av examensarbete master+civilingenjör
Bedömningsmall med riktlinjer för kvalitetskriterier för bedömning av examensarbete master+civilingenjör Examensarbetet bedöms i områdena: Process, Ingenjörsmässigt och vetenskapligt innehåll samt Presentation.
Läs merLi#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE
Li#eratur och empiriska studier kap 12, Rienecker & Jørgensson kap 8-9, 11-12, Robson STEFAN HRASTINSKI STEFANHR@KTH.SE Innehåll Vad är en bra uppsats? Söka, använda och refera till litteratur Insamling
Läs merUtbildningsplaner för kandidat-, magister och masterprogram. 1. Identifikation. Avancerad nivå
1. Identifikation Programmets namn Omfattning Nivå Programkod Ev. koder på inriktningar Beslutsuppgifter Ändringsuppgifter Masterprogram i kognitionsvetenskap 120 hp Avancerad nivå HAKOG Fastställd av
Läs merPlantPuppy 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
Läs merPROGRAMMERING. Ämnets syfte. Kurser i ämnet
PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration
Läs merSymptom på problemen vid programvaruutveckling
eller Varför är det bättre med halsbränna i början av ett projekt än i slutet? Eva Hådding ehadding@rational.com Symptom på problemen vid programvaruutveckling Användarnas och verksamhetens behov ej uppfyllda
Läs merSwedbank Mobile Loadtesting. LoadRunner 11.04 Mobile App protocol
Swedbank Mobile Loadtesting LoadRunner 11.04 Mobile App protocol Bakgrund Mission: Prestandatesta mobilt backend Typ: RESTful tjänst Underlag: Dokumenterat URI och API (Uniform Resource Identifier, Application
Läs merDag König Developer Tools Specialist Microsoft Corporation
Dag König Developer Tools Specialist Microsoft Corporation Magnus Timner Transcendent Group Olov Mattsson Know IT Krav Testning Microsoft Team System Arkitektur Bygga Kodning Vinn en XBOX 360 Elite Alla
Läs merHi-Fi Prototyping + laborationsgenomgång & verktyg
Hi-Fi Prototyping + laborationsgenomgång & verktyg Karin Fahlquist 2015 Frågor att besvara Vad innebär prototyping? Vad är speciellt med hi-fi prototyping? Hur kan man använda dem? Hur väljer man nivå
Läs merUTBILDNINGSPLAN. Master Programme in Business Process and Supply Chain Management, 60 Higher Education Credits
Dnr: 999/2008-515 Utbildningsnämnden för grundnivå och avancerad nivå inom humaniora och samhällsvetenskap UTBILDNINGSPLAN Master Programme in Business Process and Supply Chain Management, 60 Higher Education
Läs merSLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS
SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS Individuellt Mjukvaruutvecklingsprojekt (Utvecklare av digitala tjänster) Den 1 juni 2011 ABSTRAKT Rapporten tar upp positiva och negativa erfarenheter som jag erhållit
Läs merAnvändningscentrering i agila utvecklingsprojekt. johanna.sarna@valtech.com Valtech
Användningscentrering i agila utvecklingsprojekt johanna.sarna@valtech.com Valtech Vem är jag? Johanna Särnå Jobbar på Valtech sedan 3 år tillbaka Jobbar där med användbarhet och projektledning Certifierad
Läs merVisionen om en Tjänstekatalog
Visionen om en Tjänstekatalog Varför ska vi införa tjänster? Copyright BiTA Service Management/Rolf Norrman 1 IT:s värde för verksamheten tydliggörs i verksamhetens egna termer Organisationens kundfokus
Läs merKursplanen är fastställd av Naturvetenskapliga fakultetens utbildningsnämnd att gälla från och med , höstterminen 2017.
Naturvetenskapliga fakulteten MOBN03, Molekylärbiologi: Examensarbete - masterexamen, 60 högskolepoäng Molecular Biology: Master s Degree Project, 60 credits Avancerad nivå / Second Cycle Fastställande
Läs merProtokoll Föreningsutskottet 2013-10-22
Protokoll Föreningsutskottet 2013-10-22 Närvarande: Oliver Stenbom, Andreas Estmark, Henrik Almén, Ellinor Ugland, Oliver Jonstoij Berg. 1. Mötets öppnande. Ordförande Oliver Stenbom öppnade mötet. 2.
Läs mer1IK430 Brukarorienterad design
1IK430 Brukarorienterad design Projektarbete i 1IK430 Följande text är en förklaring av projektarbetet som ingår i kursen 1IK430 Brukarorienterad design, 15 högskolepoäng Enligt kursplanen, ska studenten,
Läs merMasterprogram i socialt arbete med inriktning mot verksamhetsanalys och utveckling i civilsamhället, 120 hp UTBILDNINGSPLAN
1 (7) Institutionen för socialvetenskap Masterprogram i socialt arbete med inriktning mot verksamhetsanalys och utveckling i civilsamhället, 120 hp UTBILDNINGSPLAN Master Programme in Social Work Research
Läs merProgrammering. Hur, var, när och varför. 22 November. Lars Ohlén Tieto lars.ohlen@tieto.com
Programmering Hur, var, när och varför 22 November Lars Ohlén Tieto lars.ohlen@tieto.com Agenda Om mig Programmering Vad är? Varför kunna? Hur använda kunskapen? Framtiden Sammanfattning Q+A 2 Om mig Arbetat
Läs merAnvisningar till rapporter i psykologi på B-nivå
Anvisningar till rapporter i psykologi på B-nivå En rapport i psykologi är det enklaste formatet för att rapportera en vetenskaplig undersökning inom psykologins forskningsfält. Något som kännetecknar
Läs merVad är molnet?... 2. Vad är NAV i molnet?... 3. Vem passar NAV i molnet för?... 4. Fördelar med NAV i molnet... 5. Kom igång snabbt...
Produktblad för NAV i molnet Innehåll Vad är molnet?... 2 Vad är NAV i molnet?... 3 Vem passar NAV i molnet för?... 4 Fördelar med NAV i molnet... 5 Kom igång snabbt... 5 Bli kostnadseffektiv... 5 Enkelt
Läs merAtt göra examensarbete
Att göra examensarbete För att ta ut en masterexamen måste du ha genomfört ett examensarbete. Under examensarbetet förväntas du bland annat visa fördjupade teoretiska kunskaper inom någon del av det biologiska
Läs merRune Tennesmed. Oskar Norling 1DV430. Individuellt Mjukvaruutvecklingsprojekt 1DV430 Webbprogrammerare H12 Oskar Norling
Rune Tennesmed Oskar Norling Individuellt Mjukvaruutvecklingsprojekt Webbprogrammerare H12 Oskar Norling 2012-05-30 Abstrakt Denna rapport handlar om mitt mjukvaruutecklingsprojekt som jag och en klasskompis
Läs merExercise 1b: Requirements evaluation
Resurser Produktmål Tidplan Projektplan Idé Affärsmål Användarfall Risker Krav Design Gränssnitt hårdvara Återanvänd kod Funktionella krav Kvalitetskrav Granskning Programkod Applikation Validera Kodgranskning
Läs mer2014-2015 Alla rättigheter till materialet reserverade Easec
1 2 Innehåll Introduktion... 4 Standarder... 5 Översikt: Standarder... 6 1058.1-1987 IEEE Standard för Software Project Management Plans... 7 Ingående dokument... 8 Syfte och struktur... 9 ITIL... 10 ITIL
Läs merTitel på examensarbetet. Dittnamn Efternamn. Examensarbete 2013 Programmet
Titel på examensarbetet på två rader Dittnamn Efternamn Examensarbete 2013 Programmet Titel på examensarbetet på två rader English title on one row Dittnamn Efternamn Detta examensarbete är utfört vid
Läs merNya möjligheter med M3 Technology. Björn Svensson, Björn Torold
Nya möjligheter med Technology Björn Svensson, Björn Torold Vem är vi? 2 Copyright 2011 Lawson. All rights reserved. Nya möjligheter med Technology System Foundation Grid Förändrar basen i Installation
Läs merPROGRAMMERING. Ämnets syfte. Kurser i ämnet
PROGRAMMERING Ämnet programmering behandlar programmeringens roll i informationstekniska sammanhang som datorsimulering, animerad grafik, praktisk datoriserad problemlösning och användaranpassad konfiguration
Läs merExamensarbeten hösten 2014
Examensarbeten hösten 2014 2/8 Förslag till examensarbeten på SPV Hos oss kan du ansöka om att skriva uppsats inom flera olika ämnesområden. För oss är uppsatsen ett bra sätt att få delar av vår verksamhet
Läs merKursöversikt Certifierad Mjukvarutestare
Kursöversikt Certifierad Mjukvarutestare Kurs Poäng (5 yh poäng/vecka) Examensarbete 20 Grunderna inom test 20 Kommunikation i arbetslivet 15 Lärande i arbete 1 60 Lärande i arbete 2 60 Projektarbete 15
Läs merTherese Hansson & Magnus Jonsson. Motivationsfaktorer - Test inom Agila utvecklingsprojekt
Motivationsfaktorer - Test inom Agila utvecklingsprojekt Magnus Jonsson & Therese Hansson Flerårig erfarenhet från ett globalt utvecklingsprojekt där vi införde Agile & Scrum metodik i hela organisationen
Läs merSyns 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
Läs merMina listor. En Android-applikation. Rickard Karlsson 2013-06-09. Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.
Mina listor En Android-applikation Rickard Karlsson 2013-06-09 Rickard Karlsson - rk222cu Linnéuniversitet rk222cu@student.lnu.se Innehållsförteckning 2. Innehållsförteckning 3. Abstrakt 4. Inledning/bakgrund
Läs merMolnet som skapats för ditt företag.
Molnet som skapats för ditt företag. Det här är Microsoft Cloud. Alla företag är speciella på sitt sätt. Hälso-/sjukvård, detaljhandel, tillverkning och ekonomi ingen verksamhet fungerar exakt likadant.
Läs merUtbildningsplan. Kommunikation och PR. SGKPR Kommunikation och PR Study Programme in Public Relations. Programkod: Programmets benämning:
Dnr HS 2016/638 Fakulteten för humaniora och samhällsvetenskap Utbildningsplan Programkod: Programmets benämning: SGKPR Study Programme in Public Relations Karlstads universitet 651 88 Karlstad Tfn 054-700
Läs merUniverse Engine Rapport
1 Universe Engine Rapport Alexander Mennborg 2017-05-08 2 Inledning I denna rapport diskuteras utvecklingsprocessen till projektet Universe Engine. Denna diskussion omfattar hela utveckling från starten
Läs merMetoder 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
Läs merConfiguration testing Why? Vad det är tänkt att koden ska göra. Performance testing Kommentarer Skriva om koden som kommentar
Skapa testfall Testing Köra testen Hitta fel Inspections and reviews Verifiera resultatet Formal methods Static analysis Completeness Verifiering Kvalitet Maintainability Validering Traceability Fault
Läs merSlutrapport. APFy.me
Slutrapport APFy.me Innehållsförteckning 1 Inledning... 3 2 Mål och syfte... 3 3 Projektbeskrivning... 3 4 Leverabler... 4 5 Resultat... 4 6 Utvärdering och analys... 4 6.1 Utvärdering av resultat... 4
Läs merDetta dokument innehåller anvisningar för upprättande av en sökplan i kursen TDDD39 Perspektiv på informationsteknologi.
Sökplan TDDD39 Perspektiv på informationsteknologi Detta dokument innehåller anvisningar för upprättande av en sökplan i kursen TDDD39 Perspektiv på informationsteknologi. Anvisningar Sökplanen påbörjas
Läs merVerktyget FindBugs. Djupstudie i kursen EDA 270 Coachning av programvaruteam. Christofer Bach dt05cb6 Daniel Nilsson dt05dn4. Lunds Tekniska Högskola
Verktyget FindBugs Djupstudie i kursen EDA 270 Coachning av programvaruteam Christofer Bach dt05cb6 Daniel Nilsson dt05dn4 Lunds Tekniska Högskola 15 feb 08 1. Sammanfattning Denna djupstudie kommer att
Läs merKurser och seminarier från AddQ Consulting
Kurser och seminarier från AddQ Consulting Med fokus på kvalitet och effektivitet bidrar vi till att underlätta människors vardag. Kompetensutveckling är nyckeln till framgång för dig som jobbar med test,
Läs merMagisterprogram i nationalekonomi med inriktning turism och evenemang 60 högskolepoäng
Sida 1(5) Utbildningsplan Magisterprogram i nationalekonomi med inriktning turism och evenemang 60 högskolepoäng Master Programme in Economics of Tourism and Events 60 Credits* 1. Programmets mål 1.1 Mål
Läs merRiktlinjer för bedömning av examensarbeten
Fastställda av Styrelsen för utbildning 2010-09-10 Dnr: 4603/10-300 Senast reviderade 2012-08-17 Riktlinjer för bedömning av Sedan 1 juli 2007 ska enligt högskoleförordningen samtliga yrkesutbildningar
Läs merTDDD80 Mobila och sociala applikationer. Kursintroduktion
TDDD80 Mobila och sociala applikationer Kursintroduktion Personal Kursansvarig, föreläsare, seminarieledare Rita Kovordanyi Labbansvarig, föreläsare, seminarieledare Anders Fröberg
Läs merStatsvetenskap GR (C), 30 hp
1 (5) Kursplan för: Statsvetenskap GR (C), 30 hp Political Science Ba (C), 30 Credits Allmänna data om kursen Kurskod Ämne/huvudområde Nivå Progression SK026G Statsvetenskap Grundnivå (C) Inriktning (namn)
Läs merUTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng. Master Program in Educational Work 60 credits 1
UTBILDNINGSPLAN Magisterprogram i pedagogiskt arbete 60 högskolepoäng Master Program in Educational Work 60 credits 1 Fastställd i Områdesnämnden 2015-XX-XX Gäller fr.o.m. HT 2015 1. PROGRAMMETS MÅL 1.1.
Läs merExercise 1b: Requirements Evaluation ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15
Exercise 1b: Requirements Evaluation ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15 Lund U niversity Computer Science Jonas W isbrant ETSA01 Ingenjörsp ro cessen metodik V-modellen för programvaruutvecking
Läs merCertifieringswebb. Version 1.0 Mats Persson
Version 1.0 Distributionslista Befattning Bolag/enhet Namn Åtgärd Info. Student KaU Viktor Samuelsson Student KaU Gustaf Åhs Konsult/handledare Sogeti Konsultchef Sogeti Åsa Maspers Projektledare/handledare
Läs merLitteraturstudie. 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
Läs merHenrik Häggbom Examensarbete Nackademin Våren 2015
AV Henrik Häggbom Examensarbete Nackademin Våren 2015 1 INLEDNING Som examensarbete på min utbildning på Nackademin Programutveckling.NET kommer jag skapa ett webbaserat system för statistik, tabeller
Läs merVersionshantering. Jan Erik Moström
Versionshantering Jan Erik Moström Johan Eliasson Versionssystem Gjorda för att användas av en eller flera personer på en eller flera platser, exempelvis: För en ensam användare som jobbar med ett projekt
Läs merKursplan. AB1030 Att arbeta i projekt. 7,5 högskolepoäng, Grundnivå 1. Working in projects
Kursplan AB1030 Att arbeta i projekt 7,5 högskolepoäng, Grundnivå 1 Working in projects 7.5 Higher Education Credits *), First Cycle Level 1 Mål Kursens övergripande mål är att den studerande ska tillägna
Läs mer1 Vad är Versionshantering? 2 Git. 2.1 GitHub
1 Vad är Versionshantering? Versionshantering (eller Version Control) är ett samlingsnamn för program som ger en användare möjlighet att komma åt tidigare versioner av dokument och spåra ändringar som
Läs merKanban är inte din process. (låt mig berätta varför) #DevLin2012 15 Mars 2012
Kanban är inte din process (låt mig berätta varför) #DevLin2012 15 Mars 2012 Torbjörn Tobbe Gyllebring @drunkcod tobbe@cint.com Är du eller känner du en Kanban hipster? Förut körde vi X nu kör vi Kanban
Läs merOpponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg
Datavetenskap Opponenter: Erik Hansen Mats Almgren Respondent: Martin Landälv ioftpd-verktyg Oppositionsrapport, C-nivå 2006:12 1 Sammanfattat omdöme av examensarbetet Examensarbetet är intressant eftersom
Läs merIBSE Ett självreflekterande(självkritiskt) verktyg för lärare. Riktlinjer för lärare
Fibonacci / översättning från engelska IBSE Ett självreflekterande(självkritiskt) verktyg för lärare Riktlinjer för lärare Vad är det? Detta verktyg för självutvärdering sätter upp kriterier som gör det
Läs merWEBBSERVERPROGRAMMERING
WEBBSERVERPROGRAMMERING Ämnet webbserverprogrammering behandlar funktionalitet för webblösningar och samspelet mellan beställare, användare, formgivare och utvecklare. Ämnets syfte Undervisningen i ämnet
Läs merKursen ingår i Kompletterande pedagogisk utbildning (KPU) vid Lunds Universitet. Kursen omfattar andra terminen av sammanlagt tre.
Humanistiska och teologiska fakulteterna ÄKPN02, Ämnesläraren som reflekterande praktiker, 30 högskolepoäng The Subject Teacher as a Reflective Practitioner, 30 credits Avancerad nivå / Second Cycle Fastställande
Läs merInförande av en integrationsplattform med Apache Service Mix på LTU
Införande av en integrationsplattform med Apache Service Mix på LTU Apache Service Mix = Opensource java teknologier + Prenumerationer och Support = Red Hat JBoss Fuse Bakgrund 2012/2013 - Arbetsgruppen
Läs mer