CarAPP. Ronni Hansen, Jesper Jensen, Jonas Kristensen og Mads Nielsen

CarAPP Ronni Hansen, Jesper Jensen, Jonas Kristensen og Mads Nielsen

Titelblad Overskrift: Udarbejdet af: CarAPP Ronni Hansen, Jesper Jensen, Jonas Kristensen, Mads Nielsen Projektperiode: 23-11-2012 til 7-1-2013 Vejleder: Uddannelse: Hold: Normalsider: Mogens Iversen University College Nordjylland, Datamatikeruddannelsen DM 75-4 Semester 40 (2200 anslag/side inkl. figurer) Bilag: 2 Underskrifter: Ronni Hansen Jesper Jensen Jonas Kristensen Mads Nielsen Resumé I dette projekt har emnet været meget frit, da det var op til hver gruppe selv at finde på en idé, som de ville udvikle videre på. Vores vejleder har deltaget som rollen kunde/product owner, da vi ikke har haft en reel kunde til vores software. Rapporten omhandler arbejdet med at få en idé til at få den udviklet så meget, at det kan lade sig gøre, at realisere den. Idéen omhandler en app til smartphones som skal integreres med brugerens bil vha. Bluetooth samt kommunikation med en webservice over 3g/Wifi. Der har været frit valg mellem brug af systemudviklingsmetoder. Gruppen har valgt Scrum, da gruppemedlemmerne bl.a. ønskede sig mere erfaring med Scrum og dets artefakter. Side 1 af 55

Indholdsfortegnelse Titelblad... 1 Indledning... 4 Rapportens udformning samt begrundelse, og udformning af sprint 0... 5 Sprint 0... 6 Idegenerering & idegenereringsmetoder... 6 Brugsscenarier... 7 Krav... 9 Funktionelle krav... 9 Ikke funktionelle krav... 10 Afgrænsning af features... 10 Prototyping... 11 Prototyper... 11 Prototype 1... 11 Prototype 2... 12 Prototype Web... 12 Overvejelser omkring prototyper... 13 Udviklingsmetodikker samt valg af metode... 14 Vandfaldsmodellen versus Scrum... 15 extreme Programming(XP)... 16 Scrum... 18 Unified Process... 22 Projektkortet... 25 Konklusion, udviklingsmetode... 26 Projekttrekanten... 27 Produktvision... 28 Business Canvas... 29 Risikoanalyse... 29 Tidshorisont og budget... 31 Kvalitetssikring... 31 Test(kode/brugstest)... 31 Unit Test... 32 Sikkerhed... 33 Side 2 af 55

Krav til teknologi... 34 Valg af teknologi... 35 Webservices... 36 Product backlog... 37 Prioriterings tabel... 38 Sprint 1... 39 Design... 39 Domænemodel... 39 Relationel model af databasen... 40 Design klassediagram... 41 Opsummering... 41 Beskrivelse af sprint... 42 Sprint 1 retrospective... 42 Sprint 2... 44 Beskrivelse af sprint... 44 Sprint 2 retrospective... 45 Sprint 3... 47 Beskrivelse af sprint... 47 Retrospective... 47 Konklusion... 50 Evaluering... 51 Litteraturliste... 52 Bilag... 53 Ansvarlige for afsnit... 53 Business Canvas... 55 Side 3 af 55

Indledning Denne rapport tager udgangspunkt i en systemudviklingsproces der er afledt af en idégenerering, hvor den teori der er brugt i undervisningen vil blive brugt i praksis. Mere konkret handler denne rapport om udviklingen af en ny og smart applikation der kan være med til at afhjælpe forskellige problemstillinger der kan opstå ved brug af biler. Hovedfokus i denne rapport vil, på grund af fagets opbygning, være på systemudviklingsmetoden og selve systemudviklingsprocessen fremfor udviklingen af det egentlige produkt. Der vil dog blive udviklet et produkt i det omfang, der vil være tid til. Det er vigtigt at pointere at resultatet(produktet) er blevet nedprioriteret i forhold til at dokumentere processen, da dette var vores hovedfokus. I rapporten er der en del antagelser omkring Personas, målgrupper og lignende. Grunden hertil er at der ikke er indsamlet informationer omkring evt. brugere. Det vil sige, at vi selv har forestillet os forskellige personer som kunne tænktes at benytte vores produkt. Dette har vi gjort, fordi vi mente, at der i dette forløb ikke har været grundlag for at foretage en målgruppe eller markedsanalyse, da vi som tidligere nævnt fokuserer på processen. Side 4 af 55

Rapportens udformning samt begrundelse, og udformning af sprint 0 Rapporten er kronologisk opbygget, da den er struktureret i forhold til SCRUM metodens sprints. Sprint 0 indeholder primært forarbejdet for systemudviklingsperioden, og er derfor det største afsnit. Der foreligger i modsætning til de andre sprints, ikke en beskrivelse af sprint 0 samt retrospective. Grunden til dette er, at en del af afsnittene i sprint 0 i forvejen er beskrivelser af processer, der har været nødvendige i forbindelse med fastlæggelse af idéen samt et valg af en relevant systemudviklingsmetode. Der tages i øvrigt også forbehold for mulige risici ved projektet, prototyper samt kvalitetssikring. De resterende 3 sprints beskrives, og bliver alle evalueret i forbindelse med et sprint retrospective. Når alle 4 sprints er gennemførte, diskuteres der på projektets gennemførsel, og der vurderes hvilke ting der fungerede godt, samt ting der måske burde have været inddraget i softwareudviklingsprocessen. Slutteligt konkluderes der på projektet. Sprint 0 Ideudvikling Kravsspecifikation Gennemgang af sprint Sprint 1 Prototyper Sprint retrospective Valg af udviklingsmetode Gennemgang af sprint Sprint 2 Produktvision Sprint retrospective Risikoanalyse Gennemgang af sprint Sprint 3 Kvalitetssikring Sprint retrospective Product backlog & Stories Diskussion Konklusion Figur 1 - Rapportens udformning Side 5 af 55

Sprint 0 Idegenerering & idegenereringsmetoder For at nå frem til en overordnet idé og videre til et produkt, benyttedes der flere teknikker for at fremme kreativiteten. Som det første blev der benyttet brainstorm teknikken, for at fremskaffe så mange idéer som muligt. Denne individuelle brainstorm tog udgangspunkt i et specifikt emne der var bragt på banen, f.eks. mobiltelefoner eller computere. Denne teknik blev brugt ved 4 forskellige emner, og endte ud i godt 20 forskellige idéer. Disse idéer blev så prioriteret efter, hvad gruppen mente, var de bedste. Herefter blev de vurderet i samråd med vores klasse. Den idé som fik flest stemmer fra vores klassekammerater blev så udvalgt, som den der skulle videreudvikles. Den idé der blev udvalgt var en smartphone applikation der kunne styre og kontrollere visse funktioner på en bil. For videreudvikle på idéen, brainstormede vi over mulige features. Undervejs i dette forløb blev der lavet elevatorpitches 1, for at undersøge hvad en fremmed ville synes om idéen. Udover dette, blev der udarbejdet scenarier for, hvordan produktet kunne benyttes samt Personas og de såkaldte happy-daysscenarier. Disse beskrives i det efterfølgende afsnit. Ifølge figuren til højre har ideudviklingsfasen fungeret tilnærmelsesvist som en iterativ proces, hvor de ikke accepterede idéer(problems with design) bliver bortkastet og man derfor fortsætter med at genere nye idéer. Figur 2 Udviklingscirkel for idéer. 1 30 sekunders præsentation af idé. Side 6 af 55

Brugsscenarier Som en videreudvikling af idéen, blev der udviklet brugsscenarier hvis formål var at anskueliggøre hvilke ting applikationen skulle indeholde. Reparationer & Informationer om bilen En bruger står i en salgssituation omhandlende sit køretøj. For at anskueliggøre hvorledes køretøjets reparationshistorie ser ud, samt hvornår bilen er indregistreret, slår han hurtigt og nemt op på bilens online opslagsværk, og viser en mulig kunde relevant information om køretøjet. En bruger er ved mekanikeren for at få skiftet hans tandrem, mekanikeren noterer herefter denne reparation i et online system, og giver herved brugeren nem adgang til dette, og samtidigt dokumentation for reparationen. Type Olie/Brændstof Brugeren skal skifte olie på sin bil eller fylde brændstof på, men har glemt eller er ikke bekendt med hvilken type olie/brændstof han/hun skal bruge. Brugeren åbner appen og finder informationer om hvilken type brændstof og/eller motorolie der benyttes. Hvordan serviceres bilen? Eks. Kølevæske hvor hældes det i Der skal hældes kølervæske på bilen, da det er tid til et tjek. I appen gives først en instruktion til at åbne klappen til motorrummet. Her efter vises der et billede af motorrummet for brugerens bil. På dette billede er der vist hvilken beholder der skal påfyldes, samt hvor meget der skal fyldes på. Hvor langt kan der køres på reservetanken? Brugeren har i en længere periode undret sig over hvor meget brændstof han egentligt har tilbage samt hvor mange kilometer han kan køre, når reservelampen lyser. Gudskelov har han adgang til appen, der hurtigt fortæller dette. Dæktype Brugeren vil selv skifte dæk på sin bil for at spare penge, men er ikke sikker på hvilke dæk han/hun skal købe. Brugeren finder information om hvilken type dæk brugeren skal kigge efter. Brugeren kan indtaste tallene på et dæk, for at se om de passer til brugerens bil. Side 7 af 55

Lufttryk i dæk Der skal fyldes luft på de forreste dæk på bilen. Brugeren af bilen er i tvivl om, hvad trykket skal være på disse dæk. Brugeren tager sin smartphone og åbner appen. Brugeren vælger at se information omkring bilen og kan her aflæse standard dæktryk for bilen. Er lyset slukket? Tænd/sluk (advar hvis bilen er slukket i x minutter) Brugeren har efter en hård arbejdsdag plantet sig solidt i sofaen, men kommer pludseligt i tvivl om han/hun har husket at slukke lyset på bilen. I samme øjeblik alarmerer appen via brugerens smartphone om, at han har glemt at slukke lyset. Brugeren slukker herefter lyset på bilen med appen. Er dørene låst? Åbne/låse (advar hvis bilen er slukket i x minutter) Brugeren skal låse sine bildøre for at sikre den mod tyveri. Brugeren benytter sin smartphone til at låse sin bil med. Hvis brugeren forlader bilen uden at låse den, advarer applikationen brugeren som får mulighed for at låse dørene. Hvordan er olie/benzin/kølervæske niveauet? Reager(Automatisk advarsel). Niveauet af en af væskerne nærmer sig den laveste værdi som er fastsat automatisk. Appen på smartphonen giver en besked på skærmen om, at niveauet er lavt og der skal fyldes noget på og om der burde tjekkes for lækager i systemet. Tænd/sluk oliefyr En kold vinterdag står brugeren op og gør sig klar til at køre arbejde. For bekvemmelighedens skyld har brugeren dog anskaffet sig appen, og tænder derfor bilens oliefyr inde fra sit hus. Brugeren slipper dermed for at fryse når han/hun sætter sig ind. GPS System til at finde parkeringsmuligheder Det er altid et problem at finde parkeringspladser i større byer. Appen skal derfor kunne hjælpe med at finde parkeringsmuligheder i de større byer. Dette skal vises på et kort. Side 8 af 55

Krav Ud fra de foregående brugsscenarier blev der udledt hvilke krav der ville være til applikationen. Disse krav blev opdelt i funktionelle og ikke funktionelle krav. Funktionelle krav Aflæsning Kunne se om bilen mangler motorolie (web og app) Kunne se hvor meget reservebenzin der er tilbage (web og app) Kunne se antal kørte kilometer (web og app) Kunne se hvor langt man kan køre på den resterende brændstofmængde (web og app) Brændstof (web og app) o Historik over benzinforbrug (statistik) o Kunne udregne hvor meget en tur har kostet(ud fra km kørt/benzin brugt) Generel info (web og app) o Benzin, olie type og mængder o Dæktryk og dækdimension o Producent, Model og Årgang o Tid til Service Kunne se om lyset er tændt/slukket (web og app) o Kunne advare hvis lyset på bilen ikke er slukket (app) Kunne se om bildøre er åbne/låst (web og app) o Kunne advare hvis dørene ikke er låst(app) Kunne finde en parkeringsplads og vise en ledig via GPS. Fjernbetjening (app) Kunne åbne/låse bildøre Kunne tænde/slukke lys på bilen Vejledning(app) Montering af dæk Påfyldning af luft i dæk Skift af lys Påfyldning af olie og kølervæske Påfyldning af sprinkler væske Sikringsskifte Side 9 af 55

Elektronisk servicebog Andet Brugeren skal have mulighed for at læse servicebogen, og vise den, f.eks. i en salgssituation (web og app) Oprette en bruger(web og app) Tilføjet bil til ens profil(web og app) Tilføje billeder(web og app) Mekanikeren skal kunne logge service og reparationer (web) Ikke funktionelle krav Nemt at benytte Lav responstid(hurtig respons på input fra brugeren) Skal have lavt dataforbrug Skal have ansvarligt batteriforbrug Skal behandle alt data på en ansvarlig måde Høj oppetid på database/website Afgrænsning af features Betjening af oliefyr i bilen Antallet af biler der har et oliefyr installeret er ikke særlig højt. Et oliefyr koster ca. 10.000Kr og opefter. På dette grundlag kan man konkludere, at et oliefyr ikke lige frem er hvermandseje. Desuden er der en højere sandsynlighed for, at det befinder sig i nyere og dyrere biler. På grund af dette er der valgt, ikke at inkludere oliefyrskontrol i appen, men det afvises ikke, at det kunne være en mulighed i fremtiden. GPS Parkeringssystem Ydermere har vi valgt ikke at inkludere GPS parkeringssystemet, da det efter vores mening ikke er realistisk at implementere denne funktionalitet i appen pga. tiden som skulle bruges på dette. Bl.a. kan det være meget besværligt at lokalisere ledige parkeringspladser. Denne rapport fokuserer som bekendt primært på proces. Derfor er gruppens tid primært brugt her på. Side 10 af 55

Prototyping I forbindelse med udarbejdelse af både krav og design er der gjort brug af udforskende og eksperimentelle prototyper 2, for at klarlægge hvilken funktionalitet løsningen skulle indeholde, samt hvordan dette kunne implementeres. Der blevet brugt mockups, som er simple konceptuelle skitseringer, for at blive klogere på hvordan det grafiske interface til smartphone applikationen og websitet kunne se ud. Den efterfølgende diskussion omkring disse mockups har bidraget til at gøre nogle af de abstrakte krav mere håndgribelige og konkrete. Da ingen i gruppen har arbejdet med Bluetooth før, blev der lavet en eksperimentel prototype af den sorte boks for at kunne afprøve om de enkelte stykker funktionalitet kunne lade sig gøre i praksis. Prototypen af den sorte boks 3 er skrevet som en smid-væk løsning, som gruppen har benyttet sig af for at kunne komme helt til bunds med udviklingen af de enkelte opgaver til smartphone applikationen. Prototyper Prototype 1 Til højre ses en af de prototyper der blev lavet i starten af projektet. I denne prototype er der lagt vægt på et simpelt design. Dette er forsøgt at opnå ved, at hvert menupunkt er forståeligt, uden at brugeren behøver at skulle trykke ind i menuen for at se, hvad den indeholder. Til hvert menupunkt er der en lille uddybende tekst som forklarer menupunktets indhold. Desuden er der lagt vægt på at hastigheden skal være i Figur 4 - Hovedmenu Figur 3 1.menupunkt fra hovedmenuen. top. Dette sker ved at undgå at bruge grafiske komponenter såsom ikoner og animationer. Dette betyder at selv gamle smartphones vil kunne køre appen med fornuftig hastighed. 2 Floyd, A Systematic Look at Prototyping 3 Den sorte boks: Noget hardware som gruppen forestiller sig er implementeret i bilen. Dette hardware giver adgang til visse funktioner i bilen via Bluetooth. Side 11 af 55

Prototype 2 Prototypen er lavet for at afklare hvordan navigation i appen kan foregå på fornuftig vis. Hovedmenuen (figur 5) viser den side brugeren ser når applikationen startes. De enkelte ikoner repræsenterer dele af applikationen som kan tilgås ved at trykke på ikonerne. Manualen (figur 6) viser hvordan brugeren kan søge i manualen, enten ved at skrive i søgefeltet eller gennem den alfabetiske inddeling i venstre side. Navigation tilbage til hovedmenuen fra f.eks. Manualen, foregår ved at trykke på hus-ikonet i øverste venstre hjørne. Figur 6 Hovedmenu. Figur 5 - Visning af manual. Prototype Web Prototypen er konstrueret for at få et overblik over navigationen på vores website, og for at få en fornemmelse af hvad kunden vil have. Der er ydermere lagt vægt på, at brugeren får en så nem og simpel navigation som det nu er muligt. Figur 7 Indeks og navigation på websitet. Figur 8 Profilside for min bil med faner til yderligere navigation. Side 12 af 55

Overvejelser omkring prototyper Ud fra de udarbejdede prototyper, er der blevet diskuteret positive og negative aspekter af disse, med henblik på at komme frem til den mest hensigtsmæssige udformning af applikationen og websitet. Måden hvorpå dette er udført, var via en diskussion ud fra vores balsamique mockups, der var projekteret op så alle gruppemedlemmer kunne følge med. App Vedrørende appen var der flere aspekter, som vi mente kunne fungere på en mere optimal måde. Først og fremmest nåede vi til enighed om, at det ville give det bedste indtryk og brugervenlighed hvis vi benyttede den intuitive GUI der fungerede via intuitive ikoner, frem for en almindelig listevisning. Sidestillet med dette, valgte vi dog at bibeholde denne listevisning når man klikkede sig dybere ind i systemet. Grunden til dette var, at vi mente, at behovet for hjælpetekst og beskrivelser af menuernes funktionalitet var til stede her. Dette giver i øvrigt også et større overblik over funktionaliteten herunder. Da vi kiggede nærmere på servicecheck-delen af applikationen fandt vi frem til en måde at visualisere den data der ligger i systemet. Vi mente her, at det ville være mest optimalt, at vise det næste servicecheck som det øverste punkt på listen, og derefter liste historikken over tidligere servicechecks. Brugeren er derfor hele tiden obs. på hvornår det næste servicecheck er, og har samtidigt en kronologisk liste over tidligere servicechecks. Under vejledninger valgte vi at slette muligheden for at søge i vejledninger. Grunden til dette er at den mængde vejledninger, der sandsynligvis kommer til at eksistere i applikationen, ikke er højt nok til at retfærdiggøre en søgefunktionalitet herunder. Det blev også hurtigt klart, at der var nogle mangler på hovedskærmen. Disse var reparationer, vejledninger og generel information. I forbindelse med det, mente vi i øvrigt at manual ikonet skulle fjernes, da det er misvisende at fortælle at appen indeholder en manual, da den blot indeholder specifikke vejledninger. Målinger omdøbes ligeledes til statistikker, da den information der vises i denne del af appen er af statistisk natur. Som en sidenote har det også været en mangel, at få fastslået at førstegangsåbningen af applikationen vil kræve et login, hvorimod man senere under indstillinger vil have mulighed for at skifte bruger osv. Side 13 af 55

Web I vores web-mockups stod det hurtigt klart at vi manglede at kunne registrere en bruger på websitet. Dette må siges at være en essentiel del af forretningskonceptet. Herunder skal man desuden kunne registrere sin bil under sin bruger. Som en hurtig indskudt ide, mente vi, at det ville være en super god ide at give mulighed for at præsentere brugeren for et eksternt link til sin profil, som brugeren kan bruge til at promovere/præsentere sit køretøj på nettet, eller i en salgssituation. Udviklingsmetodikker samt valg af metode Agil systemudvikling er en betegnelse for en række softwareudviklingsmetoder. Ved agil systemudvikling er der lagt vægt på, at der igennem hele projektet bliver leveret værdi til kunden igennem iterativ udvikling. Med det menes der, at det skal være muligt hurtigt at kunne levere en ny version af softwaren, når der kommer ændringsønsker fra slutbrugerne. Agile metoder, er især oplagte til udvikling af software som ikke kræver særlig meget dokumentation og som ikke har alle krav fastlagte fra projektets start. Det modsatte til agil udvikling, er vandfaldsmodellen og dermed også Unified Process(UP), hvor i der er en lang række krav til dokumentation mv. Værdier i agiludvikling: - Individer og interaktioner frem for processer og værktøjer - Fungerende software frem for omfattende dokumentation - Kundesamarbejde frem for kontraktforhandling - Reaktion på ændringer frem for at følge en plan Side 14 af 55

Vandfaldsmodellen versus Scrum Vandfaldsmodellen er en proces der er opdelt i 5 trin, i den originale version var der 7 trin man har i gennem tiden set forskellige udtryk for de enkelte trin og forskellige modeller af denne type proces, dog med samme princip. Processen er plandrevet, man ser på figuren hvordan man springer fra det enkelte trin til det næste. Dette gør, at det, at gå tilbage er svært, og da man ikke har stor kunde kontakt, så kan evt. krav ændringer have stor indflydelse på tidsplanen, for så skal man gå tilbage til trin1 og starte forfra, med den/de enkelte ændringer der måtte være. Test og debugging er der ikke noget af før i trin 4(Verification). Dette vil sige, at større fejl, som har stor indvirkning på projektet først findes til sidst i processen. Man ser heller ikke noget af værdi før sidst i processen. Det vil sige, at man ser ikke et stykke færdigt software som er brugbart før efter trin 4, hvor du også installere det. Der er en projekt manager, det vil sige the power of one altså det er ham der bestemmer, og det er ham der har kontakt til kunden. Forskellen på Scrum og vandfaldsmodellen er først og fremmest: Scrum er ikke plandrevet. Scrum er agilt det er nemmere at tage evt. problemstillinger op eller nye kravspecifikationer. Scrum siger intet om test eller design. Scrum, der har vi kunden med i form af Product owner. Som man ser på figuren, så står man efter hvert sprint med et potientelt produkt ud fra hvad man har planlagt, der skulle laves i det enkelte sprint. Der er ingen overordnet tidsplan som med vandfaldsmodellen, men tilgengæld er der Daily Scrum Figur 10 - Oversigt over Scrum. Figur 9 - Vandfaldsmodellen. Meeting som er med til at skabe et overblik, over hvor vi er, hvad vi mangler og om vi har problemer med den task vi er i gang med. Side 15 af 55

Konklusion Når man kigger på de 2 systemudviklingsmetoder, som hver bruger sin form for struktuering af de forskellige processer, og så på et projekt kort, så kan man som virksomhed konkludere hvilken type systemudviklingsmetode virksomheden skal arbejde efter. Der er ingen tvivl om at der er fordele og ulemper ved begge systemudviklingsmetoder. Man har gennem tiden som softwareudvikler lært, at test og debugging er uundværligt. Det er både tiden og pengene værd i sidste ende, i scrum tales der ikke om hverken test eller debuggging modsat i vandfaldsmodellen, hvor der i de sidste faser er test og debugging. Det at have kunden inde over gør, at man hele tiden kan holde fokus på de fælles mål. Man sørger for, at kunden for det, som kunden ønsker. Desuden er det nemmere at sørge for at eventuelle krav bliver overholdt og opdateret når kunden er tæt på projektet. Størrelsen på projektet har ikke rigtig nogen indvirkning på, om man skal tage den ene eller den anden systemudviklingsmetode, der i mod kan størrelsen på antallet af medarbejder have noget at skulle sige, man kan sige at med mange medarbejder er det for mange nemmest hvis man kender målet og vejen der hen på forhånd som vandfaldsmodellen, modsat scrum som er denne agile metode, der gør det muligt at tage nye tasks ind. Valget mellem de 2 afhænger kort og godt af den ene virksomhed, man kan ud fra vores projektkort udlede at vi skulle have valgt vandfaldsmodellen, i form af mere plandreven tilgang til projektet. Man kan man læse mere om projektkortet i et senere afsnit. extreme Programming(XP) XP er en agil udviklingsmetode og målet er at producere software af høj kvalitet ved hjælp af 4 aktiviteter. Disse 4 aktiviteter er programmering, testning, kundekontakt, og design. I XP er der 4 grundlæggende principper: - Kommunikation Kunden og/eller brugere skal hele tiden kommunikere med udviklere omkring funktionaliteten i softwaren. - Simpelhed Man skriver kun den kode, som lige er nok til at kunne løse et givent problem. - Feedback Test er en stor del af XP. Det giver udviklerne svar på om de har lavet det, som kunden og/eller brugeren har efterspurgt. Side 16 af 55

- Mod Man skal kunne bryde med traditionelle ting i systemudviklingsmetoder. F.eks. grundig kravspecifikation. Ting der fokuseres på ved XP: Par-programmering, simpelt design, kodestandarder, refaktoring, små udgivelser med korte mellemrum, tests mm. 4 Planlægning i XP kan deles op i 3 faser: Exploration phase Her laves der user stories, hvilket er små historier, som kunden af det kommende system, skal være med til at lave. Disse historier skal omhandle de funktioner, som kunden ønsker, at det kommende system skal indeholde. Herefter estimeres de forskellige stories af udviklerne. Ved ukendte områder, foretages et gæt på estimeringstiden ved hjælp af spikes. Typisk bruges der planning poker til estimering af de forskellige stories. Commitment phase I denne fase vælger kunden så hvilke stories der er de vigtigste. Disse deles op i 3 bunker. Udviklerne sorterer bunkerne i prioriteret orden efter, hvor præcist der kan estimeres, og ved hver story angives der så et mere præcist estimat. Kunden vælger her efter hvilke stories som skal med i første release. Der vælges også en dato for hvornår første udgivelse skal finde sted. Denne fase kaldes også Release Planning Game. Steering phase Kunden vælger stories for næste iteration og der fastsættes datoer for resten af udgivelserne(fastsættelse af datoer sker kun første gang, man kører denne fase). Udviklerne opdeler derefter stories til tasks for den igangværende iteration. 5 Denne fase kaldes også Iteration Planning Game. Den fase gentages i starten af hver iteration, da indholdet af fremtidens iterationer, er mere usikre, jo længere ude i fremtiden man kigger. 4 http://da.wikipedia.org/wiki/extreme_programming 5 XpPlanlægning.pptx Side 17 af 55

Figur 11 - Overblik over udviklingsforløbet for et XP projekt. Scrum Scrum skeleton Iterativ Inkrementel proces 6 skelet ses på figur 11. Denne cyklus som ses, gentager sig selv indtil projektet er afsluttet. Hjertet af Scrum Der tages kollektive beslutninger om hvordan forskellige elementer har indvirkning på projektet, om hvordan de skal nå frem til målet og om hvordan de skal gøre det. Figur 12 Scrum skeleton. Scrum Roller Der er 3 roller i et Scrum team. Herunder vil de disse roller og deres funktioner i projektet blive beskrevet: Product Owner(PO) PO har ansvaret for slutresultatet. PO sørger for kapital sådan at der er nogle ressourcer man kan trække på i løbet af processen. PO har også ansvaret for vedligeholdelse af product Backlog(PB) han kan dog få teamet til at gøre det, men PO er den ansvarlige. PO sætter en prioritet på de enkelte features i PB. Disse er fundet med hjælp fra kunden. 6 Inkrementel, betyder gradvist voksende en iterativ Inkrementel proces, betyder at det er delt op iterativt(gentagelser) og de gentagelser kan der være et vist antal af. Side 18 af 55

Scrum Master Det er Scrum masteren der sørger for at Scrum metoden bliver overholdt det vil sige, at han følger op på, om de elementer der er i Scrum, nu også bliver brugt hensigtsmæssigt og korrekt. The Development Team Ansvarlige for udviklingen, selvstyrende, selvorganiserende og tværfunktionel. Det er dem der bryder PB op i mindre opgaver(tasks), og så planlægger de ud fra prioriteringerne, hvilke der skal laves i det kommende sprint. Disse 3 roller er direkte involveret i projektet og disse har rettigheder til at lave ændringer i løbet af projektet dog skal det siges at det kun er teamet der kan tilføje ekstra opgaver til de enkelte sprints. Scrum Artefakter Product Backlog, en ordnet liste af alt det der med kunden er aftalt, som produktet skal indeholde, det er den eneste kilde til ændringer af selve produktet. PO er den ansvarlige for at opdatere og vedligeholde product backlog. Med det menes der, at hvis der forekommer der ændringer, så skal det skrives i product backlog af PO. De enkelte stories i product backloggen er beskrevet, et estimat på hvor lang tid den enkelte story tager og evt. delt i mindre tasks for et bedre overblik.indeholder en beskrivelse af Selve product backloggen lister alle de funktioner, krav, udvidelser og fejlrettelser der skal implementeres i de fremtidige releases. Der med sagt at kommer der en udvidelse fra kunden, ses den første gang på product backloggen. Det betyder også at product backlog hele tiden vil være under revidering. Man kan sige: Først når produktet holder op med at eksistere, holder product backlog op med at eksistere. Sprint Backlog Her er udtaget stories fra product backlog, som så formodentlig bliver delt op i mindre tasks, ikke en nødvendighed. Der udover bliver der sat et estimat på hver enkel task. Sprint backloggen, viser hvad der skal være færdig i det enkelte sprint, hvor imod product backlog viser hvad der ønskes af kunden. Figur 13 - Eksempel på en Burndown Chart. Side 19 af 55

Burndown chart En grafik der viser hvor langt, man er i det enkelte sprint. Det er en god måde at vise grafisk hvor langt man er, hvor langt der er igen, og ikke mindst om man er foran eller bagud. Man kan også lave en der viser flere iterationer af gangen, således at man hurtigt kan få et overblik over hele projektet. Scrum Møder Sprint Planning Meeting Det er her, at det arbejde som skal udføres i et sprint bliver planlagt. Denne plan er lagt af hele Scrum teamet. Disse møder er time-boxed det vil sige at de har en fast varighed. Denne varighed afhænger af sprintets størrelse og firmaet. Mødet er delt op i to dele, hvor man skal have svar på følgende spørgsmål: Hvad vil der blive leveret af det kommende sprint? Hvordan vil vi klare denne leverance? Daily Scrum Et møde der bliver afholdt hver morgen når man møder ind. Det vil være development teamet, der under dette møde, synkroniserer og planlægger de næste 24 timer dette møde har også en fastvarighed. Typisk 15-25 min. Under selve mødet svarer hvert medlem på 3 spørgsmål: Hvad har jeg lavet siden sidst møde? Hvad skal jeg lave indtil det næste møde? Er der nogen hindringer der står i vejen? Scrum master sørger for at teamet holder disse møder, men det er teamet selv der er ansvarlige for gennemførelsen af mødet. Det kan tolkes som et status møde, et møde der er forbeholdt for de personer der omdanner product backlog til leveringsdygtige produkter. Sprint Review Disse møder afholdes i slutningen af hvert sprint, for at inspicere iterationen og tilpasse product backlog hvis der er nødvendigt. Under mødet vil Scrum teamet og interessenterne vurdere hvad der er afsluttet i det enkelte sprint. Disse møder er, som nogle af de andre artefakter, også tidsbestemte. Igen afhænger varigheden af af sprintets størrelse. Ting der bliver drøftet under mødet er følgende: Side 20 af 55

PO identificere det der er færdig jf. definitionen af done 7. Development teamet drøfter ups and downs 8 I forhold til produktet, under sprintet. Devolopment teamet demonstrerer funktionaliteten og svarer på evt. spørgsmål. Ud fra den nuværende product backlog forudsiger PO en sandsynlig slut dato. Alle drøfter hvad der skal ske fremadrettet, så det enkelte review giver et godt input til fremtidige sprint planning meetings. Resultatet af dette møde vil være en revideret product backlog der viser de sandsynlige tasks for næste sprint product backlog kan også revideres for at tage højde for nye forretningsmuligheder nye kunder. Sprint Retrospective Dette møde er en måde hvorpå Scrum teamet kan inspicerer sig selv og det kan udarbejde en plan med forbedringer. Disse forbedringer er beregnet på fremtidige sprints. Retrospective ligger mellem Sprint review og sprint planning meeting. Retrospective er tidsbestemt på baggrund af projektets størrelse. Scrum master opfordrer til at forbedre udviklingsprocessen og praktikker hvis dette er en nødvendighed. Afslutningsvis på disse møder, burde teamet have identificeret de forbedringer de vil bruge for fremtiden. Der skal dertil siges, at forbedringer kan ske i løbet af et sprint. Med dette møde har man det formelle grundlag til at gøre det. Formålene for mødet er: Inspicerer hvordan sprintet er gået. Identificerer og ordne større ting der er gået godt samt mulige forbedringer. Arbejder på ups and downs i forhold til teamet. Udarbejdelse af en plan for implementeringen af forbedringerne. 7 Definitionen af done, det er nødvendigt at alle i teamet har en klar definition af ordet done sådan at man ved, at man er færdig, når disse kriterier er opfyldt. 8 Hvilke problemer er opstået og hvordan er disse problemer blevet løst. Side 21 af 55

Unified Process Unified Process, eller UP, er en objektorienteret systemudviklingsmetode, der foregår via inkrementielle iterationer. Softwarearkitekturen designes i UP ved hjælp af Unified Modelling Language, eller UML, der er en standard for visualisering af softwarearkitektur. UML kan beskrives som en form for blueprint der kan arbejdes ud fra. I UP er softwareudviklingsprocessen opdelt i 4 overordnede faser: Inception, Elaboration, Construction og Transition faserne. Disse er også kaldt projektets livscyklus. UP beskrives ikke som sådan som en fasttømret proces der følges slavisk, men et framework der kan tilpasses til et specifikt projekt. Et af hovedpunkterne i UP er, at hele processen er fokuseret på arkitekturen af softwaren, og at det er umuligt at beskrive et stykke software med en enkelt model. Derfor benyttes der også i UP et utal af UMLdiagrammer, der i høj grad giver et overblik over softwarens arkitektur. UP er use-case-drevet, og disse bruges til at identificere de funktionelle krav på projektet, samt indholdet af de forskellige iterationer. Et tidsdrevet diagram over et projekts fire faser inddelt i iterationer, kan ses på ovenstående figur til højre, og fortæller lidt om den mængde arbejde der er forbundet med de forskellige faser/iterationer. Iterationerne kan beskrives som en slags mini-vandfald, som man kender fra vandfaldsmodellen. UP er desuden også fokuseret på risikovurdering, dette er en ting der især er i fokus under elaborationsfasen, der er forgængeren for det egentlige startskud til at konstruere softwaren. Der foretages derfor ved slutningen af elaborationsfasen en vurdering af, om det er fornuftigt at afslutte projektet, eller om det skal revurderes/skrottes. Nærmere om faserne: Inception Inceptionfasen går i bund og grund ud på at fastlægge hvad det egentligt er man skal lave. I denne fase identificeres nøglefunktionerne i systemet, og disse beskrives vha. use-cases. Det er også i denne fase der identificeres risikoer og omkostninger vedrørende projektet. I denne fase findes der også eksempler på mulige arkitekturer, og der udfærdiges en tidsplan og omkostningsstruktur. Aktivitetsdiagrammer kan i denne fase være en stor hjælp til at afdække use-cases. Figur 14 - Unified Process. Side 22 af 55

Elaboration I Elaborationsfasen skal størstedelen af systemets funktionelle krav fastlægges. Dette op følges af en konstruering af systemets arkitektur, og en vurdering af denne. Ud over dette, er det en primær faktor, at der handles i forhold til de risikofaktorer der er identificeret. Arkitekturen vurderes desuden ud fra om det er sandsynligt at den understøtter performance, skalerbarhed og omkostninger. I denne fase udvikles størstedelen af artefakterne i UP. Disse er bl.a. Use-case diagrammer, domænemodel og design klassediagram. Ved afslutning af denne fase kan der tages en beslutning om at risikofaktorer er blevet bearbejdet og om arkitekturen er hensigtsmæssig. Det skulle efter denne fase være klarlagt om det vil være fornuftigt at udføre resten af projektet. Construction Constructionfasen går, som navnet antyder, ud på at konstruere selve systemet. Features implementeres i tidsbestemte iterationer, hvor hver iteration udmunder i et stykke funktionelt software. Transition Under Transitionfasen afleveres systemet til kunden/brugere og feedback bearbejdes. Denne fase kan også indeholder instruktion og undervisning i softwaren. Transitionfasen foregår som regel over flere iterationer. Nærmere om artefakter: UP benytter sig som tidligere nævnt af UML til at beskrive et systems funktionalitet, dette afsnit opridser kort nogle eksempler på, hvilke diagrammer der ofte benyttes i forhold til arbejde med UP som udviklingsmetode. Aktivitetsdiagram Aktivitetsdiagrammet benyttes til at visualisere hvordan flowet af informationer bevæger sig i et system. Dette kunne f.eks. være at identificere et forløb fra start til slut, hvor en kunde går ind i en forretning for at købe en sodavand. Use-case diagram En use-case viser et brugsmønster der kan hjælpe med at afdække kravene der kan være til et system. Use-casen skal i bedste tilfælde være udarbejdet så teknisk viden ikke er nødvendig. Selve use-casen viser en interaktion fra en aktør i forhold til beskrevne aktiviteter, altså fra brugerens synsvinkel. Side 23 af 55

Domænemodel Når en domænemodel udfærdiges tages der udgangspunkt i virkelig-verden-objekter og use-cases. Det er altså tænkte klasser, der ikke er komplet beskrevet i modsætning til design klassediagrammet. Der laves ud over dette også associationer mellem klasserne, for at beskrive deres samspil. Attributter tilføjes desuden også til modellen, men ingen typer angives. Design klassediagram Design klassediagrammet viser en fuldstændig version af systemets arkitektur, herunder klasser, metoder, attributter og sammenhænge mellem klasserne. Interaktionsdiagrammer Sekvensdiagrammer viser kald mellem objekter i systemet. Disse giver derfor et overblik over, hvordan delene af softwaren snakker sammen. Ydermere kan de også benyttes til at beskrive brugerens interaktion med systemet. Side 24 af 55

Projektkortet Projektkortet bruges til afklaring ved valg af udviklingsmetode. Der findes forskellige kriterier for, hvilken udviklingsmetode man skal vælge. De 5 vigtigste er: size, criticality, dynamism, personnel og culture. Size: Størrelsen på development teamet som arbejder på produktet. Criticality: Tab på grund af fejl i produktet. Dynamism: Hvor mange procent af kravene der ændrer sig pr. måned. Personnel: Fordeling af medarbejdere på development teamet i procent alt efter kompetencer og erfaring. Figur 15 - Projektkort for vores gruppe. Culture: Hvordan medarbejderne trives med hensyn til kaos vs. orden vedrørende opgaver i projektet. Angives i procent. Ud fra det development team man har, skal man nu i gang med at undersøge de forskellige kriterier og derefter tegne streger ind på projektkortet. Ud fra projektkortet kan man nu se, om ens projekt passer bedst til en agil eller plan-driven udviklingsmetode. Jo længere ud fra centrum man kommer, jo mere peger i retning af, at man skal vælge en plan-driven udviklingsmetode. Side 25 af 55

Konklusion, udviklingsmetode Efter en diskussion i gruppen omkring de forskellige systemudviklingsmetoder, blev vi enige om at bruge Scrum. Dette gør vi af flere grunde. Det er først og fremmest valgt, da vi mangler en praktisk viden omkring brugen af Scrum, og at rapporten naturligvis er udformet i et uddannelsesmæssigt perspektiv. Det skal dog nævnes, at vi tidligere har forsøgt, at bruge metoden til et projekt, og derfor mener vi, at der er et godt grundlag for at gøre brug af Scrum. Man kan på basis af vores projektkort konkludere, at der er størst vægt på det plandrevne. Man kan se at 3 ud af de 5 forgreninger er vægtet imod plandrevet styring. Grunden til at vi på trods af dette vælger Scrum er, at vi af erfaring har lært, at de agile metoder fungerer bedst i en arbejdsgruppe som vores, og at vi i øvrigt kan tilpasse Scrum metoden til de behov der kræves af projektet. Der er yderligere valgt nogle ekstra elementer fra både UP og XP. Grunden til dette er, at vi mener at disse elementer vil hjælpe med at give en bedre forståelse for hele processen. De elementer der er valgt er Parprogrammering og relevante UML-diagrammer. Par-programmering, skulle gerne være med til at gøre programmeringsfasen nemmere, ment på den måde at vi vil sidde 2 og 2 og skrive koden, hvilket vil føre til færre fejl og pænere kode. Udover dette menes der, at det giver et godt grundlag for at hjælpe og støtte en niveau 1B programmør, som vi jf. projektkortet har vurderet at projektgruppen indeholder. Ydermere har vi af personlig erfaring opdaget, at parprogrammering er yderst effektivt, hvis programmøren er træt eller stresset. UML-diagrammer, er med til at afholde programmører fra at lave fejl. Diagrammerne danner et overblik over, hvordan vores program skal se ud. På den måde undgå vi forhåbentlig de store fejl. De giver i øvrigt et rigtigt godt overblik over softwarens arkitektur. Disse elementer menes at skulle være med til at give et bedre overblik og i sidste ende et bedre projekt og produkt. Side 26 af 55

Projekttrekanten Projekttrekanten er i alt sin simpelhed en model, hvorpå man gør det klart, at man ikke kan ændre på nogle af faktorerne(tid,penge,features), uden de får indflydelse på hinanden. Summen af disse faktorer kan siges at være projektets/produktets kvalitet i sidste ende. Eksempelvis vil en ændring af projektets deadline gøre, at der enten skal investeres flere penge til mere Figur 16 - Projekttrekanten. arbejdskraft, eller at der må skæres ned i de features produktet ender ud med. Dette projekt har, lige som alle andre projekter, visse begrænsninger der skal tages forbehold for. Da projektet er gennemarbejdes som et studieprojekt, er de mest begrænsende faktorer penge og tid. Der er en meget fasttømret deadline på projektet, og der er ingen kære mor hvis denne overskrides. Ydermere er budgettet på projektet nul, og der skal derfor arbejdes ud fra, at der ikke kan investeres nogen midler i projektet. Alt dette betyder, at den faktor der har højst sandsynlighed for at skride, er antallet features som produktet vil indeholde. Dette vil i sidste ende vise sig på det færdige produkt, der med høj sandsynlighed ikke vil blive færdigt, pga. produktets omfang, og de begrænsede handlemuligheder omkring projekttrekantens fokuspunkter. Side 27 af 55

Produktvision Produktets målgruppe Produktets primære målgruppe er alle folk der har en bil og en smartphone. Ydermere er produktet også henvendt til forbrugere der er økonomisk bevidste, da man i appen kan få information om hvordan man kører, og derved optimerer sit brændstofforbrug. Vi antager i øvrigt, at mulige købere primært er folk med nyere biler. Kundebehov Produktet skal gøre det nemmere at vedligeholde informationer som står i servicebog ved at overføre dem til en elektronisk servicebog og dermed decentraliserer bogen som derved gør den mere tilgængelig. Produktet skal også øge komforten når det kommer til kontrol af låsning af døre, samt lys på bilen. Påmindelserne gør derfor, at brugeren får en vis sikkerhed i, at bilen ikke står ulåst, eller tærer på batteriet pga. bilens lygter. Kunden kan i højere grad holde øje med brændstofforbrug og kørte kilometer. Denne data decentraliseres også, og det er muligt at føre statistikker over dette data. Informationen kan bruges til at optimere brændstoføkonomien. Det giver i øvrigt også en vis tryghed for brugeren hele tiden at have adgang til bilens manual, samt nøgletal hvis disse informationer skal bruges. dette kunne f.eks. være ved skift af kølervæske, når man har begrænset viden om biler. Vigtige produktattributter Sikkerhed omkring servicebogen, da det er en kritisk faktor at denne ikke går tabt. Generelt set er dataens integritet vigtig, da statistikker også er en stor del af applikationen. I forbindelse med at appen skal virke som en fjernkontrol, er det i øvrigt også essentielt at applikationen sikres, da dette er en sikkerhedsrisiko. Responstid i denne forbindelse er også vigtigt, da man ikke skal vente på at bilen låses op. Det skal ske med det samme. Applikationen skal sikres således, at der ikke sker uhensigtsmæssige handlinger som f.eks. i worst case, at lyset slukker under kørsel. Side 28 af 55

Unikhed Produktet er en all-in-one applikation til bilejere, der i forvejen ikke eksisterer på markedet. Produktet er en samlet løsning for nogle af de trivielle problemstillinger man oplever som bilejer, f.eks. glemme at låse dørene i bilen, slukke sine lygter, eller at holde styr på sit brændstofforbrug. Ydermere giver produktet også en vis tryghed, da der i produktet også findes en elektronisk vejledning, der kan instruere brugeren i, at servicere bilen selv. Business Canvas For at blive klogere på vores idé, trådte vi et skridt tilbage og brugte et businesscanvas for bedre at kunne konkludere, om der var nogen reel værdi i vores idé. I business canvasset, som findes i bilag, findes der nogle forskellige felter. Disse felter består af forskellige kategorier som så udfyldes med relevant information. Ud fra disse informationer burde det nu være nemmere at træffe en beslutning omkring videreudvikling af idéen. Med udgangspunkt i vores businesscanvas fandt vi nogle forskellige problemer ved vores idé. Vi har haft svært ved at finde ud af, hvordan vi skal tjene penge på produktet samt at vores sorte boks, som skal sælges ved bilforhandlere osv., måske hurtig kan blive meget dyr at udvikle, da den skal tilpasses mange forskellige slags biler. Det er nok begrænset hvor mange kunder der vil give mere end 1000Kr for at få den funktionalitet som vores sorte boks udbyder. Dette kunne man måske blive klogere på ved at tage direkte kontakt til potentielle kunder og spørge om de funktioner, som den sorte boks udbyder, vil være interessante for dem. Derudover kunne man undersøge hvilket prisleje kunderne vil se som realistisk, for at de ville betale for at få den funktionalitet, som den sorte boks giver. Desuden skal der være nogle midler som gør det muligt, at kunne drive webservicen, websitet og databasen. Risikoanalyse En risikoanalyse bruges til at vurdere, hvilke risici der er de alvorligste i forhold til gennemførelse af projektet. Ved at man finder ud af hvilke risici der er, kan man mindske følgerne af dem, hvis de skulle opstå. En risiko består af sandsynligheden for, at et eller andet sker samt hvad konsekvensen af den pågældende hændelse er. Reducering af en risiko kan foretages på to måder. Man kan forebygge, dvs. at man reducerer sandsynligheden for, at det pågældende problem opstår. Den anden måde består i, at man reducerer konsekvenserne af den forventede hændelse. Side 29 af 55

De tal, der er skrevet i kolonnerne Probability og Impact, er fra 1-5, hvor 5 er det højeste. Disse er multipliceret for at prioritere de forskellige risici. Der er i mitigationskolonnen givet en kort beskrivelse af de handlemuligheder, der er til rådighed for at minimere effekten af en risiko, hvis den opstår. Risikoanalyse Risiko Probability Impact Total Mitigation Kunde ændrer krav til ITsystemet 3 3 9 - Løbende brugertests igennem hele projektet. - Løbende dialog med kunden igennem hele projektet. - Agil udviklingsmetode. Internet - nedbrud 2 3 6 - Smartphones bruges som access points. - Tage hjem til et gruppemedlem. Sygdom 2 2 4 - Skype (til kommunikation mellem parter). - Aftale om hvad den sygdomsramte skal lave hjemme, hvis det er muligt. Fravær 1 3 3 - Klare retningslinjer (gruppekontrakt). - Morgenmøde om hvem der evt. laver den fraværendes arbejde. Gruppemedlem forlader gruppen Dårligt samarbejde i gruppen Nedbrud på database server 1 4 4 - Snak med personen. 2 3 6 - Snak om de problemer der opstår. - Gå på kompromis og kom videre med arbejdet. - Snak pænt til andre gruppemedlemmer. 1 3 3 - Gemme scripts der bruges til at oprette databasen. - Skift til lokal database hvor de gemte scripts køres. Fravær af underviser 3 3 9 - Planlægge møder med den pågældende underviser. - Kontrollere underviserens skema. PC nedbrud 1 4 4 - Låne pc. - Evt. brug stationær (hjemme). - Sørg for at commit og update SVN jævnligt. Problemer med SVN 3 3 9 - Commit ofte. - Undlad at committe ikke kompilerbar kode. Optimistisk tidsplan 2 2 4 - Mere kritiske over valg af tasks. - Brug af flere forskellige estimeringsmetoder. Side 30 af 55

Tidshorisont og budget Deadline for udvikling og aflevering af projektet er d. 7. januar 2013, denne dato er givet af MHI i forbindelse med projektstart. Budgettet på projektet er 0Kr, da produktet udvikles i et studieprojekt. Kvalitetssikring Test(kode/brugstest) Det var fra først dag gjort klart at, der i sidste ende ikke ville blive lagt vægt på projektets produkt, dog med et krav om en demo i de enkelte sprints, men eftersom vægten har lagt på udviklingsprocessen, så er det der fokus er lagt. I Scrum nævnes ikke noget om test, og derfor vil der heller ikke blive lagt vægt på det, som en del af udviklingsprocessen. Der har altså ikke været planlagt tests i løbet af de enkelte sprints. Der er i løbet af projektet, blevet snakket om test og hvorfor man gør det og hvis man ikke gør det, hvorfor man så burde gør det. Ydermere er der lavet integrationstest for nogle af elementerne. Bl.a. for at se om der var adgang til databasen fra app en og samtidig om der var adgang fra websitet til databasen. Der er i løbet af projektet gjort brug af black box testing 9. White box 10 er modsat black box, hvor det er den indre struktur der bliver testet i den enkelte applikation. Vi er alle i gruppen enige om at, det at gøre brug af tests er en god ide til at kvalitetssikre et produkt. Man er således sikker på, at det virker og ikke mindst, at også kunden er tilfreds, når der er produkt release. 9 Test af funktionalitet i en applikation, med ikke en nødvendigvis viden omkring koden bag. 10 Viden omkring applikationen og koden bag, til at skrive de enkelte test cases. Side 31 af 55

Unit Test Unit test er hvor man tester isolerede dele af kildekoden. Man tester at kildekoden virker efter hensigten. En unit test er den mindste testbare form for test, som man kan have, når man udvikler software. En Ideel unit test er ikke afhængige af andre unit tests og skal derfor altid kunne afvikles selvstændigt. En unit test er hvor man skriver en lille stump kode, som tester den del af kildekoden, man nu skal teste. Der findes 2 former for brug unit tests. Den ene er, hvor man benytter unit tests som drivkraft i ens udvikling af software. Her skriver man først unit testen, og derefter skriver man så den kode, der skal til, for at testen bliver en succes. Den anden metode er, hvor man først har skrevet koden og derefter ønsker at teste koden, for at se om koden agerer, som den skal. Når man først har skrevet unit tests, er det nemt at foretage ændringer i kildekoden og derefter teste, at kildekoden stadig virker efter hensigten. Dog kræver dette, at de unit tests, som er lavet, er fyldestgørende i forhold til den funktionalitet, som de skal teste. Et sæt af unit tests er fyldestgørende når alle tilstande i en funktion eller metode bliver aktiveret. Tilstande kan f.eks. være alle cases i et switch-statement. Figur 17 - Et switch-statement. Alle cases skal aktiveres i metoden for, at testen (som typisk består af flere unit tests) er fyldestgørende. Side 32 af 55

Sikkerhed I projektet valgte vi, at vi ikke ville lægge ret meget vægt på sikkerhed, da vi fokuserede på at få tingene til at virke først og fremmest. Ved et ethvert udviklingsprojekt er det selvfølgelig vigtigt nøje at overveje, hvilke ting der kan udgøre en sikkerhedsrisiko. I det følgende vil der blive nævnt konkrete emner som er blevet diskuteret i gruppen. Bluetooth I Bluetooth standarden er der defineret 3 forskellige sikkerhedsservices. Den første er Authentication, som godkender enhedernes identitet ved hjælp af deres Bluetooth adresse. Den anden er Confidentiality som forhindrer at information kan opsnappes af uvedkommende enheder ved at sikre, at det kun er autoriserede enheder, der kan opnå adgang og se sendte data. Den sidste er Authorization, hvilket tillader kontrol af ressourcer ved at sikre, at en enhed er godkendt til at benytte en service, før den får tilladelse til det. Authentication og Authorization foregår automatisk i Bluetooth og det opnås ved at man parrer de enheder som skal snakke sammen. Det skal dog siges, at det kommer an på hvilken sikkerhedsmåde der vælges. Der findes 4 sikkerhedsmåder. En parring foregår på den måde, at enhed 1 sender en kode til enhed 2. Enhed 2 skal så bekræfte, at den har modtaget den samme kode, som vises på enhed 1. Confidentiality(kryptering) er noget man skal implementere ved siden af parringen. 11 Webservice Vi har i vores webservice brugt et framework til kommunikation med vores database. Dette skulle nok undersøges nærmere for at sikre, at der ikke er nogle alvorlige bugs i dette framework. Vi skal f.eks. sikre os at der bruges prepared statements og paramatisereret sql queries, da disse forhindrer, at en hacker kan udføre sql injections. I og med at databasen ikke kommunikerer direkte med appen eller websitet, har vi et ekstra lag af sikkerhed i form af vores webservice, da al kommunikation foregår igennem den. Dette giver os mulighed for at foretage forskellige former for validering m.v. inden vi sender en forespørgsel videre til databasen. 11 http://csrc.nist.gov/publications/nistpubs/800-121-rev1/sp800-121_rev1.pdf Side 33 af 55

I webservicen er det muligt at kalde alle funktioner selvom man ikke er logget ind. Dette skal der selvfølgelig sikres imod, og trafikken til og fra webservicen skal krypteres. Der burde også bruges certifikater for at forhindre Man-in-the-middle attacks. Ved webservicen skal vi sikre os imod spam oprettelser af flere brugere. Dette kunne vi gøre ved f.eks. at sende en email ud til den nye kunde. I denne email er der et aktiveringslink, som kunden skal trykke på, før hans/hendes konto oprettes i systemet. Alt dette skal der testes for. I og med, at vi ikke har gjort så meget ud af tests i dette projekt, så ved vi heller ikke, hvilke reelle sikkerhedsproblemer der findes i lige netop vores software. Krav til teknologi Kommunikationen mellem smartphone appen og bilen skal foregå trådløst indenfor et område på nogle få meter. Forbindelsen skal i øvrigt være sikret mod uønsket adgang udefra og være tilgængelig på de fleste smartphones. Til opbevaring af data, skal der bruges en database som indeholder alle de statiske oplysninger omkring bilen. Dette er sådan noget som de vigtigste kernepunkter i manualen f.eks. brændstoftype, dæktype mv. Databasen vil dog også indeholde data omkring service/reparationer på bilen. Smartphonen, som får de dynamiske oplysninger fra bilen, skal så overføre disse data til databasen. Dynamiske oplysninger er f.eks. antal kilometer kørt, brændstof niveau, status på lys samt status på lås af døre. Til sidst skal der være et website, hvor på det skal muligt at logge ind og se oplysningerne omkring bilen, samt beregne forskellige statistikker på f.eks. brændstofforbrug. Side 34 af 55

Valg af teknologi Som kommunikationsteknologi imellem smartphone og kommunikationsboksen, som sidder i bilen, er der valgt Bluetooth som teknologi. Denne teknologi er valgt pga. dens rækkevidde samt beskedne strømforbrug især ved version 4.0. Rækkevidden på bluetooth svinger meget alt efter hvilken hardware der benyttes. Bluetooth radioen der findes i smartphones rækker op mod 10 meter, hvilket gruppen anslår, burde være rigeligt projektet. Overførslen fra smartphonen til databasen vil foregå gennem de forbindelser som smartphonen har til internettet, hvilket primært vil være 3g og wifi. I denne forbindelse skal der overvejes hvilke data der skal sendes for de enkelte stykker data under implementationen. Hvis appen skal fungere på alle smartphones (Android, Iphone, & Windows Phone), vil en smart løsning være Phonegap. Herved vil appen kunne udvikles til de mest væsentlige smartphone platforme ud fra den samme kildekode. I dette projekt vil der udelukkende blive fokuseret på at udvikle specifikt til Android smartphones, da vi i gruppen allerede har en vis viden inden for Androidudvikling. Gruppen har valgt at opbygge websitet i PHP, da gruppen har noget erfaring med opbygning af websites i PHP. Da MySQL er den mest Figur 18 - Idéen skitseret. populære database at bruge sammen med PHP, har gruppen valgt at bruge denne. Til den visuelle præsentation af websitet på en almindelig computer, bruges HTML5 og CSS3 da dette er standarden for visning af indhold på nettet. For at holde smartphone appen adskilt fra databasens implementering, har gruppen valgt at benytte en webservice som mellemled. Dette vil gøre det muligt at indføre adgangskontrol og abstraktion fra implementationen af databasen, hvilket medfører at ændringer i databasen ikke påvirker smartphone appen. Da den sorte boks i dag ikke findes på markedet og det er udenfor gruppens ekspertise at lave denne slags hardware, har Gruppen har valgt at lave en simpel java løsning med et interface, der skal agere som en virtuel sort boks der kan testes op imod. Side 35 af 55

Webservices I projektet er der udviklet en webservice til opbevaring af de informationer som websitet og android applikationen sender og forespørger. Fordelene ved at benytte en webservice over en direkte forbindelse mellem klienten og databasen, er at den bagvedliggende infrastruktur lettere kan skalere og undgå ændringer i implementation, uden at dette påvirker klienterne, såfremt den aftalte kontrakt mellem klienterne og servicen overholdes. I projektet er webservicen bygget op som en REST 12 webservice der benytter HTTP protokollen til overførsel af data. Fordelen ved at benytte HTTP protokollen til kommunikation, er at protokollen er tilstandsløs og derved behandler hver forespørgsel uafhængigt af hinanden, samt at protokollen er tekst-baseret, hvilket gør det lettere at implementere klienterne frem for f.eks. at benytte en binær protokol. I forbindelse med projektet er der ikke på forhånd lavet en specifikation for hvilke URLer klienterne skal benytte for at hente de enkelte sæt af data. Specifikationen er opstået i form af implementering efterhånden som arbejdet er skredet frem og der har været behov for ny funktionalitet. Grunden til at denne fremgangsmåde er valgt, er for at gå i hånd med den agile udviklingsmetode og holde fokus på de arbejdsopgaver der er i gang i øjeblikket. Fordi at denne fremgangsmåde let kan præsentere den udfordring at den nuværende specifikation af URLer skal ændres under udviklingen, er der i webservicen indtænkt at URLerne kobles op mod den enkelte funktionalitet. Dette er i praksis realiseret ved at bruge et front controller pattern 13 og ved at gemme koblingen mellem URLer og controllerne i en konfigurations-fil. 12 http://www.ibm.com/developerworks/webservices/library/ws-restful/ 13 http://martinfowler.com/eaacatalog/frontcontroller.html Side 36 af 55

Product backlog Prioritering: 1 er vigtigst. 5 er mindre vigtigt. Prioritering skal foretages for både app og web. Ved de sorte felter skal der ikke prioriteres. Estimater er angivet i mandetimer. ID Stories Pri.App Pri.Web Est. App Est.Web 1 Afgiver advarsel om bilen mangler motorolie 1 1 2 2 2 Kunne se hvor mange liter benzin og antal km der 1 1 2 2 kan køres når reserve lampen lyser i instrumentbrættet 3 Kunne se antal kørte kilometer 2 2 2 2 4 Kunne se hvor langt man kan køre på den resterende 2 2 3 3 brændstofmængde 5 Historik over benzinforbrug (statistik) 2 2 9 5 6 Kunne udregne hvor meget en tur har kostet(ud fra 2 2 3 2 km kørt/benzin brugt) 7 Det skal være muligt at se benzin-, olie type og 2 2 2 2 mængder 8 Det skal være muligt at se dæktryk og 3 3 2 2 dækdimensioner som passer til bilen 9 Det skal være muligt at se producent, model og 2 2 2 2 årgang 10 Tid til Service - angivet i km og tid. 3 3 3 2 11 Kunne se om lyset er tændt/slukket 1 1 2 1 12 Kunne advare hvis lyset på bilen ikke er slukket 1 3 13 Kunne se om bildøre er åbne/låste 1 1 2 1 14 Kunne advare hvis dørene ikke er låst 1 3 15 Kunne åbne/låse bildøre 3 4 16 Kunne tænde/slukke lys på bilen 3 4 17 Montering af dæk 3 1 18 Påfyldning af luft i dæk 2 1 19 Vejledning til skift af pære i for- og baglygter 2 1 20 Påfyldning af olie og kølervæske 2 1 21 Påfyldning af sprinklervæske 2 1 22 Vejledning til skift af sikringer 3 1 Side 37 af 55

ID Stories Pri.App Pri.Web Est. App Est.Web 23 Brugeren skal have mulighed for at læse 2 2 3 2 servicebogen, og vise den, f.eks. i en salgssituation 24 Oprette en brugerprofil 1 1 3 3 25 Tilføje bil til ens brugerprofil 1 1 3 3 26 Tilføje billeder af ens bil 4 4 4 2 27 Man får udleveret et stykke papir hvorpå der står skrevet fra værkstedets side, hvad der er forgået under servicen eller reparationen. Tager et billede og uploader det under service eller reparation. 2 2 7 4 Prioriterings tabel Efter udarbejdelsen af vores product backlog, prioriterede vi vores stories i forhold til de ønsker Product owner fremlagde. Det eneste krav vi som projektgruppe fremsatte, var at de blev prioriteret i intervallet 1(højest) til 4(lavest). Stories er i vores prioriteringstabel afbilledet i forhold til den prioritet Product owner gav fra 1 til 4. Tallene der er vist i kolonnerne for prioritering 1-4, er det unikke ID, som vi har givet de forskellige stories, ordnet i forhold til den vigtighed Product owner havde angivet. Prioriteringstabellen danner grundlag for udarbejdelsen af vores sprint backlogs. 1 2 3 4 Gående fra øverste til nederste, højeste til laveste. 24 25 1 2 13 14 11 12 18 20 21 27 23 19 9 7 3 6 5 4 8 17 16 15 10 22 26 Side 38 af 55

Sprint 1 Design Vi har valgt at lave nogle artefakter for at få et overblik over den grundlæggende arkitektur i vores software. Scrum har ikke noget krav om artefakter eller en designfase, men vi følte, at en domænemodel, en relationel model samt et design klassediagram ville give os et overblik over systemet. Derudover sikrer de, at alle i gruppen er enige om, hvordan strukturen i softwaren ser ud. Domænemodel Figur 19 - Domænemodel. Domænemodellen skal bruges til at lave en relationelmodel. Den relationelle model bruges til opbyggelse af databasen, som skal bruges til at opbevare vores data. Side 39 af 55

Relationel model af databasen AppCars vin licenseplate model VARCHAR(50) VARCHAR(20) VARCHAR(50) AppUsers email fname lname address zipcode phoneno password vin VARCHAR(100) VARCHAR(100) VARCHAR(100) VARCHAR(100) CHAR(4) VARCHAR(20) VARCHAR(30) VARCHAR(50) AppMaintenances type date image vin TINYINT(1) DATE VARCHAR(255) VARCHAR(50) (sti til billede) AppCarModels model manufacturer year fueltype oiltype motorsize tanksize reservetanksize reservetankkm defaultkmprltr VARCHAR(50) VARCHAR(50) DATE VARCHAR(20) VARCHAR(20) DOUBLE(2,1) INT() INT() DOUBLE(4,1) DOUBLE(4,1) AppInstructions name description image model VARCHAR(100) TEXT VARCHAR(255) VARCHAR(50) (sti til billede) AppCarDetails vin noofkm dateservice kmtoservice kmprltr oilstatus fuelstatus lightstatus doorsstatus fuelusedtrip VARCHAR(50) DOUBLE(8,1) DATE INT() DOUBLE(4,1) DOUBLE(3,1) DOUBLE(4,1) TINYINT(1) TINYINT(1) DOUBLE(7,1) AppZipcodeCity zipcode city CHAR(4) VARCHAR(50) Herover ses den relationelle model. Denne er mappet således, at den kan bruges til en mysql database. TINYINT(1) kunne have været skiftet ud med en bit, da denne skulle fungere som en boolean, men vi valgte at fortsætte med det design, som vi oprindeligt havde lavet. Pilene illustrerer fremmednøgler der peger på primærnøgler. De attributter der er understeget, er primærnøgler. Side 40 af 55

Design klassediagram Det sidste artefakt vi har valgt at tage med, er et designklassediagram, eller rettere sagt, en del af det. Dette har vi valgt at lave for at blive enige om, hvilke datatyper der skal bruges, samt hvilke klasser der kan se andre klasser. Figur 20 - Udsnit af designklassediagram. Opsummering I gruppen besluttede vi at lave en idé til et design, ikke et færdigt design. Det vil sige, at vores domænemodel, relationelmodel og design klassediagram muligvis ikke stemmer overens med den faktiske implementation. Brug af tid på design er blevet nedprioriteret, da det er vigtigere at fokusere på noget kørende software. I og med at vi har brugt lidt tid på de ovenstående modeller, mener vi, at vi har haft et grundlag for en fornuftig arkitektur i vores software, samt at modellerne mindsker chancen for uoverensstemmelser ved implementering af kode. Side 41 af 55