Samlet Projekt

Document Sample
Samlet Projekt Powered By Docstoc
					Malte Mortensen,                        Hovedopgave                                   18-01-2012
Niklas Nøhr                               JCD A/S
DM70

Uddannelse: Datamatiker

Uddannelsesinstitution: University College Nordjylland (UCN)

Klasse: DM70
                                                Resumé
Rapportens titel: Timeregistrering
                                                Denne opgave omhandler planlægning og
                                                udvikling af timeregistreringssystem til browser
Opgavestiller:
                                                og mobil applikation, som arbejder sammen
JCD A/S                                         med Dynamics Nav der fungerer som backend

Systemvej 12                                    system.

9200 Aalborg SV                                 Projektet har resulteret i et system, som JCD

Tlf.: 70 12 00 03                               A/S er tilfredse med og vil benytte i fremtiden.



Kontaktpersoner hos JCD A/S:

Thomas Søndergaard        tks@jcd.dk

Bjarke Dam Nielsen        bdn@jcd.dk



Projektperiode: 8. November 2011 - 18. Januar 2012

Afleveringsdato: 18. Januar 2012



Projektdeltagere:

Malte Mortensen           __________________________

Niklas Nøhr               __________________________



Vejleder: Gunhild Marie Andersen




                                         Side 1 af 79
Malte Mortensen,                              Hovedopgave                                   18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

Forord
Som afsluttende opgave på 5. semester, skal man finde en virksomhed, som har et problem der kan
arbejdes med. Vi har opsøgt JCD A/S, som har stillet os en opgave vedr. en mere mobil
timeregistrering af deres arbejdstimer og kørsel, end deres nuværende system. Vi har gennem
projektet fulgt en planlægningsmetode, som gør projektet mere overskueligt og i sidste ende giver et
bedre   produkt    til   kunden.   Formålet    med   denne   opgave    er,   at   udvikle   et   mobilt
timeregistreringssystem til JCD, som de kan benytte i samspil med deres Dynamics Nav løsning -
på længere sigt vil systemet være et muligt salgsprodukt.

I grove træk beskriver rapporten, teamets arbejde med planlægningen af projektet, samt udvikling af
systemerne for virksomheden. Der vil løbende blive gjort overvejelser ved de forskellige områder.




Tak til Gunhild Marie Andersen, som har været vores vejleder under projektet.

Derudover skal der også lyde en stor tak til vores kontaktpersoner hos JCD A/S, Thomas
Søndergaard og Bjarke Dam Nielsen, som har fungeret som opgavestiller. Vi vil samtidig takke
resten af medarbejderne hos JCD, for at afsætte tid til os, når der har været spørgsmål.




                                              Side 2 af 79
Malte Mortensen,                                                    Hovedopgave                                                            18-01-2012
Niklas Nøhr                                                           JCD A/S
DM70

Indholdsfortegnelse
Forord ................................................................................................................................................... 2
Indledning ............................................................................................................................................ 6
Problemformulering ............................................................................................................................. 7
Afgrænsning ......................................................................................................................................... 7
Tidsplan ................................................................................................................................................ 8
IT Forundersøgelse .............................................................................................................................. 9
   Virksomhedsbeskrivelse ................................................................................................................... 9
   Virksomhedsstruktur ...................................................................................................................... 10
   Idé og mission ................................................................................................................................ 11
   Vision ............................................................................................................................................. 11
   Produkt vision................................................................................................................................. 12
   Dynamics Nav ................................................................................................................................ 14
   Delkonklusion ................................................................................................................................ 15
Metodevalg......................................................................................................................................... 16
   Boehm and Turner - Radar chart .................................................................................................... 16
   Scrum.............................................................................................................................................. 18
   Unified Process (UP) ...................................................................................................................... 20
   Kvalitetssikring .............................................................................................................................. 22
Planlægning af projektet .................................................................................................................... 24
       Product Backlog.......................................................................................................................... 24
       Release plan ................................................................................................................................ 25
       Risikoanalyse .............................................................................................................................. 26
       Arkitekturovervejelser ................................................................................................................ 27
       Kommunikation med Dynamics Nav Web Service .................................................................... 29
       Sikkerhed .................................................................................................................................... 31
       Udviklingsmiljø .......................................................................................................................... 33
   Tidsplan - Revurderet ..................................................................................................................... 35
   Planlægning af 1. sprint .................................................................................................................. 38
       Velocity....................................................................................................................................... 38
       Spike ........................................................................................................................................... 38
       Sprint backlog ............................................................................................................................. 40



                                                                     Side 3 af 79
Malte Mortensen,                                                   Hovedopgave                                                            18-01-2012
Niklas Nøhr                                                          JCD A/S
DM70

      Work Breakdown Structure (WBS) ............................................................................................ 41
      Burndown Chart.......................................................................................................................... 42
Udvikling af 1. sprint ......................................................................................................................... 44
   Prototype - Mockups ...................................................................................................................... 44
   Domænemodel................................................................................................................................ 46
   Interaktionsdiagram ........................................................................................................................ 47
   Kodedokumentation ....................................................................................................................... 48
   Unit Tests ....................................................................................................................................... 51
   Ekstra user story i 1. sprint ............................................................................................................. 52
1. Sprint review .................................................................................................................................. 53
   Sprint review .................................................................................................................................. 53
   Sprint retrospective......................................................................................................................... 53
   Deployment .................................................................................................................................... 55
   Opfølgning på risikoanalyse ........................................................................................................... 55
Planlægning af 2. sprint ..................................................................................................................... 56
   Opfølgning af product backlog....................................................................................................... 56
   Velocity .......................................................................................................................................... 56
   Spike ............................................................................................................................................... 56
   Releaseplan ..................................................................................................................................... 57
   Sprint Backlog (+ WBS og Estimering) ......................................................................................... 58
   Burndown Chart ............................................................................................................................. 60
Udvikling af 2. sprint ......................................................................................................................... 61
   Prototypes - Mockups ..................................................................................................................... 61
   Planlægning af 2. sprint (Ekstra story) ........................................................................................... 63
   2.Sprint (Ekstra story) .................................................................................................................... 65
      Prototype - Mockup .................................................................................................................... 65
   Kodedokumentation ....................................................................................................................... 65
2. Sprint review .................................................................................................................................. 68
   Sprint review .................................................................................................................................. 68
   Sprint retrospective......................................................................................................................... 69
   Deployment .................................................................................................................................... 70
   Opfølgning på risikoanalyse ........................................................................................................... 70


                                                                    Side 4 af 79
Malte Mortensen,                                                   Hovedopgave                                                           18-01-2012
Niklas Nøhr                                                          JCD A/S
DM70

Konklusion ......................................................................................................................................... 72
Læring ................................................................................................................................................ 75
Udtalelse fra JCD A/S ........................................................................................................................ 77
Litteraturliste ...................................................................................................................................... 78
System & CD ..................................................................................................................................... 79


Vedlagt - Quick Guide til mobil timeregistrering

Vedlagt - CD med solution




Installation af Silverlight i Visual Studio 2010

For at kunne køre Silverlight web applikationen fra Visual Studio 2010, kræves der forskellige
installationer. Først og fremmest skal man have Service Pack 1 til Visual Studio installeret, denne
service pack kan hentes på http://www.microsoft.com/download/en/details.aspx?id=23691.
Derudover skal man have installeret Silverlight toolkit, således man kan bruge de forskellige
funktioner i Visual Studio - dette toolkit kan hentes på
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=18149. Derefter er Visual
Studio klar til at køre Silverlight projekter.


Installationsguide til Windows Phone 7, er beskrevet i vedlagte Quick Guide.




                                                                    Side 5 af 79
Malte Mortensen,                            Hovedopgave                                    18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

Indledning
Denne rapport omhandler løsningen af et problem, opstillet af virksomheden JCD A/S. Rapporten
indeholder en IT forundersøgelse af virksomheden, planlægning af selve projektet, samt udvikling
af projektet. Produktet der udarbejdes er et timeregistreringssystem, og dette udarbejdes til to
forskellige klientapplikationer - Browser og Windows Phone applikation - som skal tilgå Dynamics
Nav. Den nye løsning tilbyder, at virksomheden bliver mere mobile ved deres timeregistrering, da
man kan tilgå det fra alle steder vha. netværksforbindelse. Dette resulterer i mere præcise
registreringer, da medarbejderne altid kan lave en timeregistrering, når de er færdige med en
opgave, og påbegynder en ny - også hvis de er ude ved kunder. På nuværende tidspunkt kan der kun
udføres timeregistreringer gennem Dynamics Nav.

Rapporten vil blive udarbejdet ud fra en problemformulering, som danner grundlag for projektet.
Først og fremmest vil vi starte med, at fortælle om virksomheden, således man får et indblik i,
hvilken virksomhed denne rapport drejer sig om. Derefter vil vi starte planlægningen af projektet,
hvor vi vil gøre os forskellige overvejelser om, hvorledes dette projekt skal udarbejdes, og hvilke
arbejdsmetoder vi vil benytte. Under planlægningen af projektet vil vi fortælle om, hvilke
arkitektoniske overvejelser vi har gjort os i forhold til projektet, derudover vil vi også komme ind
på andre aspekter, som vedrører planlægningen til projektet. Vi vil herefter gennemføre udviklingen
af projektet, hvorunder der vil blive overvejet, hvorledes der kan arbejdes bedst muligt.
Afslutningsvis vil vi følge op på hele projektet, samt vurdere hvorledes det er forløbet. Vi vil kigge
på, hvad der er gået godt og skidt, samt vurdere hvad vi kan gøre bedre i forhold til et nyt projekt.
Vi vil under udviklingen af projektet have stor fokus på sikkerhed, da kunden vægter dette højt.
Samtidig er det vigtigt for kunden, at produktet skal være så enkelt så muligt, hvilket vi også vil
have fokus på.

Der vil som sagt blive vedlagt en Quick Guide til Windows Phone applikationen.




                                             Side 6 af 79
Malte Mortensen,                            Hovedopgave                                   18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

Problemformulering
I virksomheden JCD A/S ønskes der et nyt timeregistreringssystem. I forbindelse med opgradering
af Dynamics NAV løsningen ønskes der en timeregistrerings funktionalitet, som er tilgængelig fra
forskellige platforme. Formålet med dette er, at gøre systemet mere mobilt, og der ønskes en løs
kobling imellem brugergrænseflade og forretningslogik, så der senere nemt kan tilføjes nye klient
typer. Virksomhedens nuværende timeregistrering (Dynamics Nav) foregår kun via computer, hvor
et nyt mobilt system kan gøre timeregistreringen lettere for medarbejdere, som er på kundebesøg.

Opgaven er at udvikle et system der skal kunne:

   Håndtere medarbejdernes arbejdsopgaver og timeantal. Derudover skal systemet også håndtere
    medarbejdernes kørsel, hvilket evt. kan gøres vha. telefonens GPS funktion.
   Bruge Dynamics Nav som backend system.
   Have løs kobling imellem brugergrænseflade og forretningslogik.
   Håndtere sikkerhed i forhold til brugernes login oplysninger.

I forbindelse med projektet, vil vi arbejde indenfor områderne Silverlight, Windows Phone og
Dynamics Nav web service. De 3 områder er nye for os, og vi ser derfor opgaven som udfordrende,
da vi skal sætte os ind i nye områder.




Afgrænsning
Under dette projekt har vi besluttet, at begrænse vores arbejde til nogle bestemte teknologier. Vi
kommer derved til, at arbejde yderst motiveret på de valgte områder. De områder vi har valgt, at
arbejde med, er programmering i Silverlight og Silverlight til Windows Phone, samt arbejde med
forbindelse til Dynamics Nav web service. De nye områder giver os en bredere viden indenfor
programmerings faget. Løbende formoder vi, at de nye områder vil give os en del udfordringer, da
det ikke er helt samme måde der programmeres på, som det vi er vant til fra skolen. Vi vil løse disse
udfordringer ved brug af forskellige kilder, samt snakke sammen om, hvordan vi formoder de
forskellige udfordringer kan løses. Et område som forbindelse til Dynamics Nav web service,
formoder vi vil give en del udfordringer, og vi vil derfor gennemgå relevant teori, som kan give os
et indblik i, hvordan dette område skal varetages og estimeres. Der er samtidig også nogle områder,
som vi ikke rører ved, dette drejer sig bl.a. om databasen, som på forhånd er udarbejdet af JCD.
Dynamics Nav web servicen benyttes til kommunikation med databasen, og web servicen


                                             Side 7 af 79
Malte Mortensen,                            Hovedopgave                                   18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

indeholder derved nogle forskellige metoder, som vi kan benytte til vores projekt. Vi skal derfor
ikke tænke på, at skulle lave noget på denne web service selv, men blot hente metoderne ind fra
Dynamics Nav web servicen. Vi sætter os samtidig ikke ind i Dynamics Nav kode, da vi ikke skal
ind og bruge Dynamics Nav systemet, og derfor ikke skal bruge det til noget.


Tidsplan
Til dette projekt har vi udarbejdet en foreløbig tidsplan for, at gøre os overvejelser om hvad
rapporten skal indeholde, samt at skabe et overblik over hvor meget tid vi skal bruge på hvert enkelt
område. Derved er det også let, at se hvor man befinder sig i udviklingen, samt hvor langt tid man
har igen. Den foreløbige tidsplan er indsat nedenfor. Efter vi har fundet frem til, hvilken
planlægningsmetode eller udviklingsmetode vi vil benytte i projektet, vil vi igen tage tidsplanen
frem og ændre denne ud fra hvordan vi vil planlægge hele projektet. Ud fra denne tidsplan kunne
det godt se ud som om, at vi vil bruge vandfaldsmodellen til at udvikle efter, men det er ikke
tilfældet, da vi endnu ikke har valgt en metode. Det kunne også sagtens blive en iterativ metode,
selvom implementeringen ikke er vist i iterationer på tidsplanen.




                                             Side 8 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

IT Forundersøgelse
Under dette afsnit vil vi undersøge virksomheden på forskellige områder, således der kan gives en
overordnet beskrivelse af virksomheden. Vi vil bl.a. kigge på regnskabet, virksomhedsstrukturen,
fremtidige mål, samt lave en beskrivelse af, hvorfor virksomheden ønsker et nyt og mobilt
timeregistreringssystem.

Virksomhedsbeskrivelse
Virksomheden JCD A/S blev etableret i 1991 i Aalborg, og har for nylig fejret deres 20 års
jubilæum. JCD A/S beskæftiger sig med leverance af totalløsninger til det danske erhvervsliv, hvor
de har omkring 1600 kunder, hvoraf 800 af dem er de såkaldte ”sjove” kunder, hvor de løbende
sælger til. Virksomhedens kernekompetence er Dynamics Nav/Navision løsninger, som de både
udvikler og vejleder i – konsulenterne i virksomheden holdes altid opdateret med Microsoft
Certifikater, således de kan løse kundernes problemstillinger bedst muligt. Derudover har
virksomheden også mange andre afdelinger – bl.a. teknisk, grafisk og sikkerhed -, hvilket gør det
muligt, at tilbyde kunderne totalløsninger indenfor IT. Virksomheden har tidligere været Microsoft
Gold Certified Partner, men grundet nye krav fra Microsoft, er de røget ned som Microsoft Silver
Certified Partner – indenfor kort tid forventer virksomheden, at være tilbage som Microsoft Gold
Certified Partner. JCD A/S har siden etableringen oplevet en eksplosiv udvikling på
beskæftigelsesområdet, samt det økonomiske område – det seneste år er antallet af ansatte steget fra
35 til 43. Nedenfor har vi opstillet de økonomiske nøgletal fra 2008-2010, samt en vurdering af
tallene:

                            (Beløb i 1.000 kr.)   2010      2009   2008
                            Omsætning                       31.375 33.872
                            Netto resultat        1.893 1.021      1.835
                            Antal ansatte         35        32     25



Som det ses på ovenstående resultater, er det en virksomhed i udvikling. Bemærkelsesværdigt er det
dog, at der i år 2009 var et noget lavere resultat end 2008 og 2010. Dette er der dog en god grund
til, da virksomheden i regnskabsåret 2009 flyttede til nye lokaler, hvor en del blev renoveret,
samtidig med, at der var 7 nye ansættelser. Hvad vi ikke viser på ovenstående skema, er resultatet
for regnskabsåret 2011, dette skyldes, at det først lige er blevet færdiggjort og vi har derfor ikke de
præcise tal. Vi vil dog lige kommentere på hvordan det er gået i 2011, hvor virksomheden er


                                             Side 9 af 79
Malte Mortensen,                                                          Hovedopgave                                                                         18-01-2012
Niklas Nøhr                                                                 JCD A/S
DM70

kommet ud med et lille underskud på bundlinjen, hvilket bl.a. skyldes opkøb af en Dynamics C5
virksomhed og en virksomhed med overvågning. Derudover har der været 8 nye ansættelser, hvilket
har resulteret i en del flere udgifter til lønninger, feriepenge, uddannelse osv.. Samlet set skal det
ses, som en investering på længere sigt.




Virksomhedsstruktur


                                                                                                 Jørgen Bønsdorff
                                                                                                     Direktør




                                                                                Administration                        Service
                                                                                Bettina Berndt                    Jonas Rosenbeck
                                                                                  Julie Kuhn                       Bent Engstrøm




    Udvikling         Dynamics Nav /                                                                Sikring &                Teknik
                                                                  Salg                                                                         Dynamics C5       Web & Grafik
     Thomas              Navision                                                                 Overvågning            Allan Hansen
                                                             Thomas Ertmann                                                                  Rene Wiebenson
   Søndergaard         Peter Linnet                                                              Sten Rude Torp         Per Kristoffersen


                        Michael Voigt        Marketing                             Indkøber
Bjarke Dam Nielsen                                                                                                          Lars Hald         Jan Sørensen
                        Anette Nyborg     Louise Bønsdorff                      Finn Henriksen
                                                                                                                          Lars Pedersen                        Anders Jørgensen
                     Jesper H. Svensson                                                                                Sune Christoffersen                        Tanja Sloth
                      Sam Hatzigiannis                        Thomas Ebert                                               Thais Beerman                          Kasper Jensen
                       Morten Solberg                          Rasmus Jelle                                                Palle Struwe                       Bo Lenskjold Jepsen
                         Per Koldkær                           Lasse Elbæk                                              Michael K. Nielsen                       Eva Dyrmose
                      Steffen Andersen                       Carsten Pedersen                                          Mads Skov Hansen
                          Per Riishøj                                                                                  Simon Kjær Nielsen
                      Ronny Andersen
                       Jesper Justesen




Virksomheden JCD A/S har 43 medarbejdere, som er fordelt over syv afdelinger, samt fire
stabsfunktioner, og en direktør. JCD har en horisontal arbejdsfordeling, hvor løsningen af opgaver
er fordelt ud på forskellige afdelinger. Virksomheden består af to niveauer, hvilket er en flad
organisationsstruktur. I en flad organisationsstruktur er kommunikationslinjerne mellem toppen og
bunden af organisationen korte, hvilket medfører bedre kommunikation, og mindre misforståelser i
forhold til en dyb organisation. Der kan dog være risiko for, at lederen mister overblikket i en flad
organisation, fordi lederen har koordineringsansvaret for alle de underliggende niveauer.
Arbejdsmiljøet ved JCD er uformelt, og der er ikke stor forskel mellem medarbejdere og ledere.
Medarbejderne har meget frihed, hvilket er positivt, fordi dette er med til at motivere
medarbejderne, og det giver dem mulighed for, at være kreative og tage initiativ, som resulterer i en
god løsning af arbejdsopgaver.




                                                                          Side 10 af 79
Malte Mortensen,                               Hovedopgave                                18-01-2012
Niklas Nøhr                                      JCD A/S
DM70

JCD er opbygget i forhold til Linie- og stabsprincippet, som giver en klar ansvarsfordeling.
Virksomheden har som sagt syv linieafdelinger, der hver har en afdelingsleder. Stabsfunktioner er
hjælpefunktioner, som har til formål at støtte de forskellige linieafdelinger. Der er fire af disse
stabsfunktioner i virksomheden. Linie- og stabsprincippet har nogle fordele i forhold til Linie
princippet, fordi stabsfunktionerne er med til at aflaste linieafdelingerne i deres opgaveløsning, da
stabsfunktioner er specialiseret indenfor et bestemt område, hvilket medarbejderne fra
linieafdelingerne derved kan benytte sig af.

I forbindelse med vores projektforløb, har vi primært tilknytning til virksomhedens
udviklingsafdeling. Det er denne afdeling vi skal lave et system for, og det er normalt denne
afdeling, som beskæftiger sig med det område, vi skal omkring i vores projekt.
Udviklingsafdelingen interagerer med flere af de andre afdelinger i virksomheden, heriblandt den
grafiske afdeling som de arbejder sammen med i forbindelse med udvikling af hjemmesider.

Virksomhedens Dynamics C5 afdeling er forholdsvis ny, den er kommet til inden for det sidste år.
JCD opkøbte en anden virksomhed, som arbejdede med Dynamics C5, og ansatte ejeren som
Dynamics C5 konsulent. Efterfølgende er der blevet ansat én mere Dynamics C5 konsulent.



Idé og mission
JCD A/S er en leverandør af IT-løsninger, primært i Microsoft Dynamics Nav og Dynamics C5,
samt hardware. JCD lægger meget vægt på et godt samarbejde med deres kunder, og er meget
bevidste om, at begge parter skal være tilfredse med dette samarbejde. Et godt samarbejde er vigtigt
for, at holde på nuværende kunder, og have succes på længere sigt. Det er vigtigt for JCD, at give
kunderne den rigtige løsning, til den rigtige pris, som kan hjælpe kunderne mest muligt. JCD ser
deres medarbejdere som virksomhedens vigtigste ressource, og mener derfor det er meget vigtigt, at
passe på dem, ved at give dem gode arbejdsforhold, samt frihed mht. løsning af arbejdsopgaver.
Dette er med til, at motivere medarbejderne til at arbejde mere effektivt, og i sidste ende give
kunderne en bedre løsning.




Vision
JCD A/S har visioner om, at vokse sig større i løbet af de næste par år. Virksomheden vil forsøge,
at opfylde denne vision ved opsøgning af nye kunder og derved få et bredere kundesortiment. Dette


                                               Side 11 af 79
Malte Mortensen,                            Hovedopgave                                   18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

vil samtidig resultere i, at de opfylder deres vision om, at vokse til omkring 60 medarbejdere
indenfor de næste par år, hvor de på nuværende tidspunkt er 43 ansatte. Som tidligere omtalt har
man i 2011 forsøgt sig med opkøb af virksomheder, således JCD kan håndtere flere forskellige
opgaver for kunden - opkøbene formodes at give gevinst indenfor den nærmeste fremtid. Opkøbene
hænger sammen med, at JCD har visioner om, at udvide sig til flere områder, for bedre at kunne
møde kundernes behov, i forhold til at tilbyde kunderne totalløsninger til deres virksomhed. Dette
giver også en god synergi effekt, når virksomheden kan dække så mange forskellige områder, fordi
kunderne ofte har brug for løsninger på flere af disse områder. På det økonomiske område har JCD
visioner om, at omsætte for 1 million kr. pr. medarbejder om året, og have et overskud på 100.000
kr. pr. medarbejder pr. år. Der forventes derfor en kraftig stigning i omsætningen indenfor de næste
år, hvis man forventer 60 ansatte, hvilket vil resultere i en omsætning på 60 millioner kroner om
året. Dette er en stigning på 15-20 millioner kroner i forhold til netop fremlagte regnskab. Som sagt
vil denne omsætning kunne komme i hus ved hjælp af nye kunder.



Produkt vision
JCD A/S har på nuværende tidspunkt et timeregistreringssystem i Dynamics Nav, som de benytter i
virksomheden. Det er ikke planen, at de vil afskaffe dette system, men de ønsker et system som kan
tilgås via browser og mobil applikation, således de ikke er nødt til at benytte Dynamics Nav for, at
lave timeregistrering. Det nuværende system tilgås som sagt gennem Dynamics Nav, og kan kun
tilgås via en computer med Dynamics Nav installeret. Nedenfor har vi indsat et skærmbillede af det
nuværende timeregistrerings system, for at vise hvad det indeholder, og beskrive hvordan det
fungerer.




                                            Side 12 af 79
Malte Mortensen,                            Hovedopgave                                   18-01-2012
Niklas Nøhr                                   JCD A/S
DM70




Ovenstående skærmbillede viser et eksempel på en medarbejders arbejdsdag. Hver gang
medarbejderen skifter opgave skrives det ind. Man vælger først datoen for arbejdet og derefter en
sag eller undersag for kunden, derefter skrives kundens navn automatisk i feltet ”Debitornavn”.
Herefter vælger man, om man har arbejdet hjemme eller ude, og indskriver tidsintervallet for,
hvornår man har startet og afsluttet opgaven. I det efterfølgende felt skrives arbejdstypen ind, det
kan være antal kørte kilometer (KM) eller arbejdstid f.eks.. Efter dette laver man en beskrivelse af
opgaven, hvilket er synligt for kunden og hvis der er en reference til en bestemt person hos kunden,
skrives dette under ”Kontaktperson”. Under ”Fakturerbar” skal man kunne vælge om arbejdet skal
faktureres til kunden eller om det ikke skal. De sidste to felter er ”Antal” og ”Dagbogstekst”, ved
antal finder den automatisk ud af, hvor lang tid man har arbejdet, og hvis man har arbejdstypen
”KM” skriver man antallet af kilometer man har kørt. Ved feltet ”Dagbogstekst” kan man skrive
eventuelle noter som kunden ikke skal se.

Derudover er der også andre funktioner, som f.eks. at kunne se hvor mange timer man har haft i
denne måned, og hvor mange man havde på samme tidspunkt for 1 år siden. Dette er dog ikke
funktioner, som vores system umiddelbart skal kunne håndtere, og vi vil derfor ikke forklare i
dybden om dette.

Overordnet set skal det kommende browser system og mobil applikation, have de mest basale
funktioner fra Dynamics Nav timeregistreringen. Det vigtige er blot, at man kan tilgå
timeregistreringen hvor som helst, blot man har netværksforbindelse. Det skal derudover være en
smartere løsning, således man f.eks. blot trykker ”Start” og ”Stop” når man starter og slutter tiden.
Dette nye system vil give virksomhedens medarbejdere mulighed for at lave præcise



                                            Side 13 af 79
Malte Mortensen,                             Hovedopgave                                   18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

timeregistreringer, fordi de altid vil have mulighed for at lave registreringer. Dermed opnås der
bedre kvalitet, da timeregistreringer bliver mere præcise, da de kan laves lige når en opgave
påbegyndes og afsluttes. Med det nuværende system, sker det at nogle medarbejdere først
registrerer deres timer sidst på dagen, eller på den efterfølgende dag, hvilket kan resultere i
upræcise registreringer, da det kan være svært at huske, hvilke opgaver der er blevet udført, og hvor
lang tid det har taget. Ved at forbedre kvaliteten på timeregistreringer kommer det både virksomhed
og kunder til gode. Virksomheden får faktureret den rigtige tid til kunderne, mens kunderne ikke
kommer til, at betale for meget, da de bliver faktureret for den arbejdstid virksomheden har lagt i
opgaven. Mobil applikationen skal udvikles til en Windows Phone til at starte med, og senere er det
planen, at der skal udvides med en klient til android. Dette vil vi gøre lettere, ved at opbygge
systemet med lav kobling, så brugergrænsefladen nemt kan udskiftes.

De fremtidige brugere af systemet er konsulenterne hos JCD A/S. Vi vil benytte forskellige
konsulenter fra JCD til tests, for at få en fremtidig brugers syn på produktet.



Dynamics Nav
Under dette punkt har vi valgt, at lave en kort beskrivelse af Dynamics Nav, samt forklare hvad
sager og undersager er, som vi kommer til at benytte under timeregistrering. Dynamics Nav, som
tidligere blev kaldt Navision, er et ERP-system. Dynamics Nav kan tilpasses efter hvilke behov man
har i bracher og virksomheder, således kunden får bedst muligt udbytte af deres system. Systemet
indeholder forskellige forretningsaspekter, heriblandt økonomi, produktion, salg og marketing,
projektstyring osv., som gemmes på en central database, hvor brugere hurtigt og enkelt kan hente
informationer fra. I Dynamics Nav er brugervenlighed vigtigt, således programmet er let at bruge,
samt let at tilpasse, hvis kunden får brug for nye funktioner i systemet. Dynamics Nav kan
derudover benyttes til at interagere med andre programmer, hvilket bl.a. vil vises i denne rapport.

Som der blev fortalt under produkt visionen, benytter vi sager og undersager til oprettelse af
timeregistrering. En sag er selve kunden, dvs. at man vælger kunden først, hvorefter man vælger
hvad det er man vil lave for kunden, som er undersagen. En undersag kan f.eks. være opsætning af
kasseapperat, møde med kunden, osv.. Overordnet set er det kunden og kundeopgaven man får styr
på.




                                             Side 14 af 79
Malte Mortensen,                            Hovedopgave                                   18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

Delkonklusion
JCD A/S er en IT-virksomhed i vækst, i løbet af 2011 er der blevet ansat 8 nye medarbejdere, samt
opstartet to nye afdelinger. De to nye afdelinger er Dynamics C5 og Sikring & overvågning, som er
startet op efter, at JCD har opkøbt to mindre virksomheder, der beskæftigede sig med disse to
områder. JCD har visioner om, at fortsætte denne udvikling i fremtiden, og vil gerne vokse til
omkring 60 medarbejdere inden for nogle få år. På det økonomiske område er målet, at omsætte for
1 million kr. pr. medarbejder om året, og få et overskud på 100.000 kr. pr. medarbejder om året. Det
er meget vigtigt for JCD, at have et godt samarbejde med deres kunder, og at begge parter er
tilfredse, da dette er medvirken til, at holde på kunderne i fremtiden. Arbejdsforholdene for
medarbejderne vægtes også højt, da disse er virksomhedens vigtigste ressource. JCD går ind for, at
medarbejderne skal have frie arbejdsforhold, da dette er med til, at motivere dem til at arbejde mere
effektivt og kreativt med løsning af arbejdsopgaver, hvilket i sidste ende resulterer i et bedre
produkt til kunden.

Som afgangsprojekt har vi fået til opgave, at lave et nyt timeregistreringssystem til JCD A/S.
Systemet skal være mere mobilt end det nuværende. Det skal kunne tilgås fra en browser, og en app
til mobiltelefon. Systemet skal laves i Silverlight i form af en browser applikation, og en app til
Windows Phone 7. Det skal opbygges, således det let kan udvides til andre platforme, f.eks. med en
app til Android eller lignende - dette betyder, at der skal gøres nogle arkitektoniske overvejelser.
Det nuværende timeregistreringssystem er i Dynamics Navision, som kun kan benyttes fra
virksomhedens computere. Fordelen ved det nye system vil være, at medarbejderne er i stand til, at
registrere deres timer fra en anden computer, end den der er placeret i virksomheden, eller fra en
mobiltelefon, hvis de er på besøg hos kunder. Dette skal ikke ses som en erstatning af det
nuværende system, men i stedet en udbygning af dette.




                                            Side 15 af 79
Malte Mortensen,                                    Hovedopgave                                 18-01-2012
Niklas Nøhr                                           JCD A/S
DM70

Metodevalg

Boehm and Turner - Radar chart
For at finde frem til hvilken metode vi vil benytte i projektet, har vi benyttet Radar chart af Boehm
and Turner1. Ud fra modellen nedenfor vil vi finde frem til, om vores metodevalg skal være agilt
eller traditionelt. Metodevalget bestemmes ud fra forskellige parametre man skal tage stilling til.




Ovenfor har vi som sagt udarbejdet modellen og vi har her taget stilling til forskellige parametre,
hvilke vi vil beskrive. "Dynamism" har vi valgt skal være ca. 3%, da vi ikke forventer, at der vil
være særlig mange ændringer på kravene løbende i projektet. Dette afspejles også i, at vi har deres
nuværende Dynamics Nav timeregistreringssystem, at gå ud fra mht. hvad systemet skal kunne.
Derudover befinder vi os i teamet bedst med, at arbejde i en kultur (Culture) blandet af kaos og
orden. Vi ønsker nødvendigvis ikke, at projektet skal være fuldkommen planlagt, da projektet ikke
er større end det er - ved større projekter havde det været relevant, at arbejde mere under orden.
Størrelsen (Size) af teamet vil være på 2 personer, da vi er 2 udviklere på projektet. Hvis der er fejl
(Criticality) i systemet efter release, har vi vurderet hvad dette vil have af betydning for
virksomheden. Da det er er timeregistreringer på forskellige opgaver for kunder, kan det være
kritisk, da man ikke får faktureret sine kunder for det man har lavet, hvis timeregistreringen ikke
bliver registreret. Samtidig mener vi ikke, at det vil have voldsomme økonomiske tab, da man ofte
vil opdage, at registreringen ikke er blevet udført og det vil derfor sjældent ske, at en
timeregistrering ikke bliver udført - alternativt kan de benytte Dynamics Nav til timeregistrering,

1
    Balancing Agility and Discipline: A Guide for the Perplexed, Barry Boehm & Richard Turner



                                                    Side 16 af 79
Malte Mortensen,                                 Hovedopgave                               18-01-2012
Niklas Nøhr                                        JCD A/S
DM70

hvis der er problemer. Sidste parameter man skal tage stilling til, er det "personlige" (Personnel) i
projektet. Alt efter, hvilket udviklingsniveau man befinder sig på, placeres man på Level 1, 2 eller
3. Level 1 er begyndere, level 2 er øvede og level 3 er eksperter. Vi vurderer teamet til, at være en
blanding mellem begyndere og øvede - vi har derfor placeret punktet på 20% begynder og 25%
øvede.

Overordnet set, ligger vores metodevalg på en blanding mellem agilt og traditionelt - med
hovedvægt på det agile. Specielt "Size" og "Criticality" er punkter der peger på, at vi skal arbejde
agilt. Derimod læner vi os meget op af et traditionelt metodevalg ved, at vi ikke forventer mange
rettelser i kravene løbende i projektet. Vi har besluttet os for, at vælge en agil metode, da
størstedelen af parametrene peger på en agil metode. Som sagt peger modellen på et traditionelt
metodevalg ved "Dynamism" og "Culture", vi kunne derfor også have valgt en traditionel metode.
Grunden til, at disse to punkter ikke har overbevist os om et traditionelt metodevalg skyldes, at vi i
dette mindre projekt ikke nødvendigvis skal arbejde i et dybt organiseret projekt, men i stedet kan
trives i en blanding mellem orden og kaos. Derudover forventes der som sagt ikke mange rettelser i
projektet, men vi mener ikke, at dette alene kan overbevise os om, at benytte en traditionel metode,
da mange andre parametre peger på et agilt metodevalg.

Til dette projekt har vi valgt, at benytte den agile planlægningsmetode Scrum2, hvor vi vil inddrage
discipliner fra udviklingsmetoden UP. Da Scrum er en planlægningsmetode, fortæller den ikke
noget om, hvordan man skal udvikle. Her vil vi benytte os af elementer fra udviklingsmetoden UP. I
begyndelsen af hvert sprint vælger vi, at vurdere om vi har brug for nogle diagrammer fra UP til det
givende sprint, og udarbejder disse hvis vi mener, det er nødvendigt.




2
    Scrum and XP from Trenches – How we do scrum, Henrik Kniberg


                                                 Side 17 af 79
Malte Mortensen,                             Hovedopgave                                     18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

Scrum




Vi vil ikke følge Scrum ”by the book”, men i stedet tilpasse metoden efter hvad vi har brug for. Vi
vælger bl.a. ikke, at benytte ScrumMaster, da vi kun er 2 personer til dette lille projekt, og vi ser det
derfor ikke som nødvendigt – det havde været mere relevant ved større projekter, og hvor der var
flere personer indblandet i udviklingen. En ScrumMaster fungerer som en koordinator, og assisterer
Scrum teamet, så de kan arbejde så effektivt som muligt. Dette indeholder både kommunikation ud
af til, og løsning af problemer, som forhindrer Scrum teamet i at arbejde effektivt. Først og
fremmest vil vi under planlægningen starte med, at lave en risikoanalyse for at finde ud af, hvilke
forskellige områder der kan skabe problemer i projektet.

Derefter starter vi på selve planlægningsprojektet – det første vi vil gøre er, at udarbejde en product
backlog, som er en prioriteret list over kravene til det system der skal udvikles. Normalt er det
product owner, som har ansvaret for at holde product backloggen opdateret, hvis der kommer
ændringer, men i vores tilfælde er det hele teamet, der vil varetage dette. Herefter vil vi i samråd
med kunden prioritere de forskellige user stories i product backloggen. For de forskellige user
stories i product backloggen, vil vi herefter estimere disse. Til dette er der forskellige værdier, at
estimere i – f.eks. timer, dage, uger, måneder eller story points. Vi har valgt, at vi vil benytte dage
som estimat af user stories. Efter udarbejdelse af product backloggen vil vi udarbejde en release
backlog, således vi kan informere kunden om, hvornår vi forventer forskellige dele af systemet
færdige til release - på dette tidspunkt kan vi bruge estimaterne fra de forskellige user stories til


                                              Side 18 af 79
Malte Mortensen,                              Hovedopgave                                      18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

vurderingen. Efterfølgende skal der ses på, om der er nogle user stories, hvor vi er usikre på det
forventede tidsforbrug pga. ukendt teknologi. Hvis vi vurderer, at der er sådanne user stories, vil vi
lave et spike for disse user stories, for at indsamle yderligere informationer, så vi kan lave en mere
kvalificeret estimering. Efter vurdering af spikes, vil vi se på, om estimaterne på de forskellige
spikes i product backloggen er realistiske, eller om vi har fundet et andet estimat, efter at have
gennemgået det givende spike. Hvis et nyt estimat er besluttet, rettes dette i product backloggen og
release backloggen. Release backloggen vil derudover løbende blive rettet i forbindelse med
retrospectives i forbindelse med afslutning af sprints.

Planlægningen af de forskellige sprints, som skal indgå i projektet, planlægges på et sprint planning
meeting. Under planlægningen af de forskellige sprints startes der med, at fastlægge hvor lang tid ét
sprint skal vare. Derefter tager vi de højest prioriterede user stories fra product backloggen, og
sætter ind i det første sprint, i forhold til den tid der er til rådighed – vi overfører ikke flere user
stories end der tid til i sprintet, da vi ikke vil binde os til at lave mere arbejde, end vi er sikre på at
kunne fuldføre i løbet af sprintet .Vi vil planlægge sprints i samråd med product owner, for at sikre
kundens interesser bliver varetaget. Efter dette vil vi bryde de forskellige user stories ned til tasks,
dette gøres vha. WBS(Work Breakdown Structure). De tasks vi får ud, skal herefter estimeres –
disse vil blive estimeret i timer i modsætning til user stories, som bliver estimeret i dage. Når vi ved
hvor langt et sprint er, og hvor meget der skal laves derpå, udarbejdes et burndown chart. Burndown
chartet viser hvordan det går i sprintet, om vi overholder vores tidsplan eller om vi er bagud – det er
derfor en nem måde, at få overblik over sprintets forløb.

Som sagt er et sprint en del af Scrum – det er oftest mellem en uge og 1 måned. Under et sprint
bliver user stories implementeret, som i slutningen af hvert sprint evt. kan munde ud i et release af
produktet. Som sagt vil der ved Scrum normalt være en ScrumMaster, denne person skal bl.a.
koordinere opgaver til Scrum teamet, samt undgå forstyrrelser fra omverdenen. I dette projekt
vælger vi ikke, at benytte en ScrumMaster grundet teamets størrelse på 2 personer. Daglige Scrum
møder er en vigtig del af et sprint, da vi under disse møder får et overblik over, hvordan det går.
Hvis en udvikler har nogle spørgsmål eller problemer har personen mulighed for, at komme ud med
det under mødet - dette vil dog først varetages under et nyt møde. Ved at komme med problemerne
eller spørgsmålene på disse møder, holder vi samtidig ro mens der udvikles. Vi har valgt, at afholde
disse møder under dette projekt, da vi mener det er en god måde, at koordinere arbejdet på, samt vi
får et indblik i, hvad den anden er i gang med – derudover kan man hurtigt nå, at rette noget, hvis



                                               Side 19 af 79
Malte Mortensen,                              Hovedopgave                                   18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

man har misforstået noget i opgaven. Møderne vil vi holde så korte som muligt, således vi hurtigt
kan komme i gang med at arbejde – hvis der er mange problemer eller problematiske spørgsmål,
vælger vi som sagt, at arrangere et nyt møde, hvorpå disse ting kan drøftes. Herefter begynder
implementeringen af de forskellige user stories i det valgte sprint. Vi starter først med den user
story, som kunden har prioriteret højest, og går derefter videre til den med næsthøjest prioriterede.
Efter implementeringen vil vi teste på de mest komplekse metoder, vi vælger derfor, at udarbejde
Unit-test for disse metoder, således vi har noget, at teste op mod. Udover unit-test vil vi også udføre
andre tests, hvilket bliver kort beskrevet under punktet "Kvalitetssikring". Efter at have
implementeret og testet afholdes et sprint review, hvor vi vil vise product owner, hvad der er blevet
lavet, hvorpå product owner vurderer om det udarbejdede kan accepteres. Hvis product owner ikke
accepterer en user story ved acceptance test, vil denne have højest prioritet i det efterfølgende
sprint. Derefter afholdes retrospective, hvor vi vil evaluere, hvordan det er gået i sprintet, her
samles Scrum teamet, som har arbejdet på det givende sprint. Vi vil her kigge på sprint backloggen,
og der vil blive drøftet, hvad der har været godt, hvad der kunne gøres bedre, og hvad der skal gøres
anderledes til efterfølgende sprint. Derudover kigger vi på, om estimeringen af de forskellige tasks
har været korrekte eller om det er noget vi skal have fokus på ved estimering af de efterfølgende
tasks. Vi mener det er en god måde, at afslutte et sprint på, da man får synspunkterne fra personerne
omkring projektet, og vi opnår et bedre produkt ved, hele tiden at forbedre udviklingsprocessen.
Afslutningsvis ved hvert sprint i forbindelse med retrospective, vil vi se på den forventede velocity
og den faktiske velocity. Dette betyder, at vi sammenligner teamets forventede mængde arbejde,
med den mængde der i virkeligheden blev udført. Hvis der er stor forskel, er det noget vi skal
vurdere og evt. ændre vores velocity til næste sprint.

I det efterfølgende afsnit om UP, vil vi beskrive, hvordan vi har tænkt os at benytte discipliner fra
UP i projektet.

Unified Process (UP)
Som omtalt ovenfor, vil vi benytte Scrum som planlægningsmetode, mens vi vil benytte dele fra
udviklingsmetoden UP3. Herunder følger en beskrivelse af UP, samt hvordan vi vil benytte UP i
dette projekt. Unified Process (UP) er en iterativ og inkrementel proces, hvori man løbende udvikler
programmet hen mod det endelige resultat. Processen er use-case drevet, hvilket betyder, at man
laver use-cases, som bruges til analyse, test, udvikling og design. Kendetegnet ved UP er, at man

3
    Applying UML and Patterns, Craig Larman



                                              Side 20 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

ikke laver alt sin dokumentation først og derefter kode, i stedet gør man begge dele løbende. Tidligt
i forløbet benytter man risici for, at finde frem til hvilke use-cases, der er vigtigst at få styr på.
Overordnet set består UP af 4 faser, dette drejer sig om Inception, Elaboration, Construction, og
Transition, hvilke vi vil gå mere i dybden med senere under dette punkt.

Nedenfor ses et billede af hvordan fordelingen er under de forskellige faser. Det ses ud fra billedet i
hvor stor grad de forskellige områder berører de forskellige iterationer. Som det ses, indgår de fleste
områder under hele processen, hvilket også afspejles ved, at man løbende laver refactoring på
diagrammer og kode.




Under dette projekt vil vi som sagt benytte dele fra UP. Måden hvorpå vores projekt ligner UP, er
bl.a. inception fasen. I denne fase skaber man overblik over projektet, samt planlægger den
grundlæggende arkitektur. I sammenhængen med dette projekt, kan man sige, at "risikoanalyse" og
"arkitekturovervejelser" svarer til inception fasen i UP, her får man skabt overblik over projektet.
Derefter findes elaboration fasen hvor man går mere i dybden med systemets krav og arkitektur,
samt begynder udviklingen af centrale dele af systemet. I forhold til vores projekt, kan man sige, at
elaboration fasen vil svare til vores 1. sprint hvor vi vil benytte de diagrammer vi får brug for fra
UP og derved får mere styr på arkitekturen. Derudover vil vi under 1. sprint begynde udviklingen af
de højest prioriterede user stories, hvilket svarer til at udvikle de centrale dele af systemet under
elaboration fasen i UP. Den efterfølgende fase er construction, hvor man udvikler de resterende dele
af systemet. I sammenhængen med vores projekt vil dette svare til de resterende sprints som bliver
udviklet - disse sprints indeholder de resterende dele af systemet.




                                             Side 21 af 79
Malte Mortensen,                             Hovedopgave                                     18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

Overordnet set vil vi i projektet benytte forskellige discipliner fra UP. Dette gør vi kun hvor dette er
nødvendigt og holder derfor vores metodevalg så agilt som muligt. Grunden til, at vi benytter
discipliner fra UP skyldes, at vi har brug for dokumentation for at lette arbejdet.




Kvalitetssikring
I projektet benyttes der kvalitetssikring, for at sikre et bedre resultat af systemet. Der er nogle
bestemte kvalitetskrav vi vil have fokus på, under udviklingen af systemet, da dette er et ønske fra
kundens side. Et af disse kvalitetskrav er sikkerhed, hvor der skal implementeres et login system,
hvilket også kommer til at fremgå i product backloggen. Derudover skal der være sikker
kommunikation imellem klienten og backend systemet. Kunden ligger også vægt på, at systemet
skal sikres mod tab af data, hvilket specielt er rettet mod løsningen til en mobiltelefon, ved
manglende netværksforbindelse. Her vil der være en user story i product backloggen omkring dette.
Brugervenlighed er også vigtigt for kunden, derfor vil vi lave en brugervenlighedstest, i forbindelse
med design af brugergrænsefladen. Her vil vi benytte en "tænke-højt test", for at sikre at
brugergrænsefladen er let at benytte. Scrum vil som sagt blive brugt som planlægningsmetode,
hvilket indeholder et sprint review, som bliver brugt som kvalitetssikring. Ved et sprint review
bliver product owner, og andre stakeholders præsenteret for det, der er blevet implementeret af
funktioner i løbet af sprintet. Dette giver mulighed for, at product owner kan give Scrum teamet
feedback, i forhold til det der er blevet lavet, hvilket resulterer i et bedre produkt. I forbindelse med
sprint review vil vi lave en acceptance test, som skal godkendes af product owner. Derudover vil vi
ugentligt holde et møde med product owner, for at få feedback på de user stories, som er blevet
implementeret, og sørge for at projektet forløber som det skal, i forhold til kundens ønsker. Vi
mener, at dette vil hjælpe til med at udvikle et system, som opfylder kundens ønsker og behov.

I løbet af sprints laves der unit tests, når user stories implementeres. Dette gør vi for at sikre, at
størstedelen af fejlene, som opstår ved implementeringen, bliver opdaget og rettet, inden systemet
sendes ud til kunden. Derudover vil vi benytte acceptance tests i slutningen af hvert sprint, hvor vi
vil gennemgå de opstillede krav med product owner, for at se om de er blevet opfyldt. Vi fastsætter
delene af systemet som "done", når product owner har accepteret, at kravene er opfyldt og når
produktet er released til kunden. Dermed har man en del færdigt, som kunden kan benytte og det
betegnes derfor som "done". Vi bruger versionsstyring til, at styre og dele vores kode, så vi kan
arbejde flere på det samme projekt. Dette giver også mulighed for, at lave rollback til en tidligere


                                              Side 22 af 79
Malte Mortensen,                             Hovedopgave                                     18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

version, hvis der opstår problemer med koden, efter der er lavet nogle tilføjelser. Alternativt kunne
vi benytte en anden form for versionsstyring, hvor vi skulle flytte koden rundt efter, at have lavet
noget, men vi fandt den anden form for versionsstyring bedre - valg af versionsstyring kan læses
under afsnittet "Versionsstyring". Vi sørger for at teste lokalt, inden noget kode deles via vores
versionsstyring, og vi tester også efter det er delt, så vi er sikre på, at det ikke skaber problemer med
den eksisterende kode.




                                              Side 23 af 79
Malte Mortensen,                               Hovedopgave                                  18-01-2012
Niklas Nøhr                                      JCD A/S
DM70

Planlægning af projektet
Product Backlog
ID   User story                           Importance Estimat Acceptance test
                                          (0-100)    (dage)
1    Der skal udarbejdes                  90         7       Controlleren skal være i stand til, at
     funktionalitet til registrering af                      oprette en ny timeregistrering ved brug
     tid på controller logikken.                             af en Dynamics Nav web service
2    Der skal laves en Web service,       80         1       Web servicen der fungere som interface
     som Interface for Controller                            til controlleren, skal kunne kalde
     logikken.                                               metoderne på controlleren, og returnere
                                                             resultatet.
3    Der skal være Login funktion         70         5       Man skal kunne logge ind med
     med sikkerhed                                           username og password. Systemet skal
                                                             registrere hvilken bruger der er logget
                                                             ind vha. en token.
4    Der skal udarbejdes                  60         4       Det skal være muligt, at oprette en
     brugergrænseflade til Browser                           timeregistrering ved brug af en browser.
     applikationen.
5    Visning af tidligere                 50            2        Skal kunne vise tidligere
     timeregistreringer.                                         timeregistreringer fra Dynamics Nav
                                                                 for et bestemt tidsinterval, samt udregne
                                                                 det samlede antal timer for en periode.
6    Der skal udarbejdes                  40            4        Det skal være muligt at lave en
     brugergrænseflade til Windows                               timeregistrering via en applikation til
     Phone.                                                      Windows Phone.
7    Beregning af kørsel fra start- til   20            7        Skal kunne udregne antal kørte km ud
     slutdestination, samt finde                                 fra en start og slut destination, samt
     kunde ud fra destination                                    finde ud af hvilken kunde man er hos,
                                                                 ud fra destination. Dette skal benyttes
                                                                 vha. GPS funktionen i Windows Phone.
8    Sikring mod tab af data ved          30            5        Ved manglende netværksforbindelse,
     manglende netværksforbindelse                               skal data gemmes lokalt på telefonen,
     på Windows Phone                                            således det kan sendes når der igen er
                                                                 netværksforbindelse på telefonen.
9    Der skal laves et WCF interface 10                 1        Der skal laves en WCF service, der
     til systemet.                                               virker som interface for Controller
                                                                 logikken.


Product backloggen er en prioriteret liste over kravene til systemet, der skal udvikles. Kravene er
opstillet i form af user stories, som senere brydes ned i tasks på et sprint planning meeting. I product
backloggen får hver user story et ID, en beskrivelse, og en prioritering, i form af "importance", hvor
vigtigheden er beskrevet af, hvor høj værdien er. Hver user story får også et estimat i dage, som
beskriver, hvor lang tid den pågældende user story forventes at tage at implementere. Dette estimat



                                               Side 24 af 79
Malte Mortensen,                              Hovedopgave                                        18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

laves mere detaljeret i sprint backloggen, hvor hver user story brydes ned i mindre tasks, som også
estimeres. Til sidst er kolonnen "Acceptance test", som beskriver hvilke krav, den givne user story
skal opfylde, for at gennemføre acceptance testen, og derved blive godkendt af product owner - de
opstillede krav er bestemt af product owner. Product backloggen er prioriteret efter kundens ønsker
i forhold til forretningsværdi, så de funktioner der er vigtigst, kan komme med i den første release.

Hvis det er nødvendigt, vil man udarbejde en detaljeret beskrivelse af kravene til systemet, hvilket
man i f.eks. UP udarbejder ved en fully dressed beskrivelse. Derved skulle vi have benyttet use
cases i stedet for user stories i product backloggen. Vi har valgt, at holde os til user stories, da vi let
kan komme i kontakt med kunden under projektet, da vi sidder hos virksomheden. Derved kan vi
kontakte kunden når det er nødvendigt og har derfor ikke brug for en dokumenteret fully dressed
beskrivelse.




Release plan

                                             ID     Navn                                    Impor.    Est
                                             1      Der skal udarbejdes funktionalitet      90        7
                                                    til registrering af tid på controller
                                                    logikken.
                         1. Sprint           2      Der skal laves en Web service,          80        1
                                                    som Interface for Controller
                                                    logikken.
                                             3      Der skal være Login funktion med        70        5
1. Release                                          sikkerhed
                                             4      Der skal udarbejdes                     60        4
                                                    brugergrænseflade til Browser
                                                    applikationen.
                         2. Sprint           5      Visning af tidligere                    50        2
                                                    timeregistreringer.
                                             6      Der skal udarbejdes                     40        4
                                                    brugergrænseflade til Windows
                                                    Phone.
                                             8      Sikring mod tab af data ved             30        5
                                                    manglende netværksforbindelse
                                                    på Windows Phone
                                             7      Beregning af kørsel fra start- til      20        7
2. Release               3. Sprint
                                                    slutdestination, samt finde kunde
                                                    ud fra destination
                                             9      Der skal laves et WCF interface         10        1
                                                    til systemet.



                                               Side 25 af 79
Malte Mortensen,                              Hovedopgave                                      18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

Vi har lavet en release plan for, at give kunden en idé om, hvornår den første release af systemet er
klar. Vi har lavet denne release plan, ud fra en forventet velocity på 16 dage pr. sprint. Der forklares
hvordan vi er kommet frem til dette tal i afsnittet "velocity" senere i rapporten. Normalt vil man i
Scrum kigge på ROI (Return Of Investment) når man skal planlægge, hvornår de forskellige stories
skal implementeres. Dette ville betyde, at ID 2 skulle udvikles først, da man kigger på "importance"
og "estimat" og ser, at den har en høj vigtighed og samtidig er hurtig at implementere, grundet dens
lave estimat. I dette projekt vil der ikke blive benyttet ROI, da kunden ønsker systemet
implementeret ud fra den vigtighed de har opsat de forskellige user stories efter. Derudover ville det
heller ikke have været muligt, at lave web servicen, før vi har lavet funktionaliteten på controller
logikken, da web servicen fungerer som interface for controller logikken.

Vi regner med, at være i stand til, at udgive den første release af systemet efter 2. sprint er afsluttet,
da vi på dette tidspunkt har nok funktionalitet til, at systemet kan benyttes af kunden. Efter 3. sprint
vil vi lave 2. release, hvor der bliver tilføjet nogle ekstra features til systemet, som gør det lettere og
mere sikkert at benytte - disse er ikke essentielle for, at systemet kan benyttes af kunden. I
planlægningen af hvert sprint vil vi revurdere release planen, da det kan være nødvendigt med
ændringer deri, fordi vi ikke er helt sikre på vores velocity. Hvis vi i vores første sprint fuldfører
mere arbejde end forventet, og når op på 17 dages arbejde, kan vi blive færdige med de 4 første user
stories fra product backloggen. Dette gør det muligt, at lave en release efter første sprint, da vi her
ville have nok færdige user stories til, at systemet kan benyttes af kunden. Ingen af vores sprints er
fyldt helt op med de 16 dages arbejde, som vi forventer at kunne lave, derfor har vi en buffer, som
vil hjælpe os med at overholde release planen, hvis vores velocity er upræcis, og vi ikke kan nå, at
færdiggøre 16 dages arbejde pr. sprint som forventet. Hvis vores velocity er meget ved siden af, er
det muligt at undlade, at implementere den lavest prioriterede user story i den første release, og
skubbe denne til 2. release. Skulle denne situation opstå, vil vi informere kunden om, at hele den
forventede funktionalitet ikke vil være i den første release, men at de vil få første release af
systemet til den aftalte dato.




Risikoanalyse
Herunder har vi udarbejdet en risikoanalyse over de risikoer der er ved projektet. Vi har kigget på
sandsynligheden for, at problemerne opstår og hvor stor konsekvensen vil være. Derudfra har vi
udregnet effekten af de forskellige risikoer ved, at gange sandsynligheden med konsekvensen - vi



                                               Side 26 af 79
Malte Mortensen,                             Hovedopgave                                  18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

finder derved frem til, hvor den største risiko befinder sig. Konsekvensen ved, at risikoen eventuelt
opstår, er at tidsplanen skrider, og man derved ikke kan levere systemet til den aftalte tid. Under
modellen har vi valgt, at vurdere de forskellige risikoer.

                                     Sandsynlighed Konsekvens Effekt        Håndtering
ID    Beskrivelse
                                     (1-10)        (1-10)     (S*K)
1     Estimater kan være             7             6          42            Efter 1. sprint forventer
      upræcise.                                                             vi mere præcise
                                                                            estimater.
2     Forbindelse til Dynamics       3                10           30       Udarbejde spike,
      Nav web service, da det er                                            således vi ved mere om
      ukendt teknologi for os.                                              området.
3     GPS Funktion, da det er        5                1            5        Udarbejde spike,
      ukendt teknologi for os.                                              således vi ved mere om
                                                                            området.
4     Velocity kan være upræcis i 7                   4            28       I retrospective vil vi
      første sprint                                                         evaluere på teamets
                                                                            velocity og justere
                                                                            denne. Vi har en buffer
                                                                            at tage fra, hvis velocity
                                                                            ikke holder.

Ovenfor har vi som sagt angivet de forskellige risikoer, som kan forekomme ved dette projekt. Som
det ses, er der størst risiko ved, at estimaterne kan være upræcise. Derudover er der også fastsat
sandsynlighed og konsekvens for de andre risikoer. I den 5. kolonne "Håndtering", beskriver vi
hvordan vi vil mindske risikoen for de forskellige områder. Vi vil bl.a. ved ID 2 og 3 udarbejde
spikes i starten af sprints, således vi får undersøgt områderne nærmere, og derved får et klarere
indblik i, hvordan det fungerer. Spikes vil hjælpe til, at vi får mere præcise estimater, samt vi får
bedre styr på, hvordan forbindelsen til Dynamics Nav web servicen skal håndteres, og hvordan GPS
funktionen skal gribes an. Grundet udarbejdelsen af spike, forventer vi derfor ikke, at nogle af
risikoerne vil blive problemer for os, men vi har samtidig i baghovedet, hvor stor risiko der er ved,
at enkelte ting muligvis kan give problemer.

Arkitekturovervejelser
Systemet som skal udarbejdes, laves med en 3-lags arkitektur. Denne består af en
brugergrænseflade (GUI), et controller lag (CTR) og et data lag, som består af en Dynamics Nav
web service, der henter data fra en database. Logikken er placeret på en webserver, og der er derfor
tale om en tynd klient, da logikken ikke ligger på klienten. Grunden til, at vi har placeret logikken
på webserveren skyldes, at det gør systemet lettere udskifteligt til andre platforme. I denne



                                             Side 27 af 79
Malte Mortensen,                            Hovedopgave                                    18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

sammenhængen har vi valgt, at benytte lav kobling, hvilket gør det let, at udskifte og tilføje
interfaces. Der er samtidig en lav afhængighed mellem klasserne, hvilket betyder at klasserne ikke
er afhængige af hinanden. Med dette mener vi, at man kan kalde en metode ned gennem alle lagene
i systemet, hvor lagene ikke kender ret meget til hinanden. Derved er det let, at ændre ét lag i
systemet uden, at skulle ændre en masse. Derudover benytter vi høj binding i systemet, hvilket
betyder at der er en klar ansvarsfordeling i systemets klasser, således det er nemmere, at
vedligeholde for andre personer - vi har derfor også hovedsageligt valgt, at benytte engelske navne,
som giver alle mulighed for at forstå koden. Det har dog ikke været muligt, at lave alle navne på
engelsk, da Dynamics Nav web servicen både indeholder danske og engelske navne, som vi ikke
kan ændre i. Ved at lave præcise navngivninger er det samtidig lettere, at ændre i koden på et senere
tidspunkt, da det er lettere at få overblik over, hvad der hænger sammen. Overordnet set har vi gjort
en del overvejelser omkring, hvordan vi skulle gribe arkitekturen an. Vi mener, at vi har fundet den
bedst mulige løsning, som på længere sigt gør systemet let, at vedligeholde for os selv og eventuelt
andre, samt let udskifteligt til andre brugergrænseflader. Nedenfor har vi illustreret hvilken del der
bliver genbrugt, og hvor meget der skal ændres ved at skifte brugergrænseflade fra f.eks. browser
applikationen til Windows Phone applikationen.




Som det ses ud fra illustrationen, er arkitekturen delt op efter brugergrænseflade, forretningslogik
og backend delen af systemet. Forretningslogikken bliver genbrugt, således det er let, at udskifte
brugergrænsefladen. Forretningslogikken bliver lagt op på en webserver, således det kan tilgås via
web servicen fra forskellige brugergrænseflader når man har netværksforbindelse. Det er derfor
nemt hvis der skal udføres rettelser på systemet efterfølgende, da man ikke skal rette koden hele



                                            Side 28 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

vejen ned igennem lagene for hver brugergrænseflade, men blot skal rette i brugergrænsefladen,
samt én gang i de filer, som kan genbruges. Overordnet set gør vores arkitekturvalg, at det i
fremtiden vil være nemt at udføre rettelser på systemet, samt tilføje nye brugergrænseflader - JCD
har allerede nu i tankerne, at de på et senere tidspunkt ønsker, at udvikle en Android klient.
Alternativt til arkitekturen vi har valgt, kunne vi have kodet som vi ville i de forskellige lag og
derved ikke arbejdet efter en tynd klient og lav afhængighed mellem klasserne. Dette ville på nogle
områder under udarbejdelsen af projektet have gjort arbejdet lettere for os, da vi ikke skulle tage
stilling til, hvordan arkitekturen bedst muligt skulle bygges op. Vi vurderede dog, at måden vi vil
gøre det på, er den bedst mulige måde for at sikre, at koden er let genbrugelig, samt let at udskifte
til andre platforme.



Kommunikation med Dynamics Nav Web Service
I udviklingen af timeregistreringssystemet, som skal bruge en Dynamics Nav løsning som backend
system, har vi benyttet os af Dynamics Nav web services. Med Dynamics Nav kan man publicere
pages, som web services, hvilket giver mulighed for at benytte standard operationer via web
servicen som, "Create", "Read", "Update" og "Delete". Bagved disse pages, er der underliggende
virtuelle tabeller. Man publicerer en page, for hver tabel, som man vil gøre brug af. I vores tilfælde
har vi gjort brug af 7 forskellige pages.

Vi har udviklet to klienter, den ene er en applikation til Windows Phone 7, og den anden er en
Silverlight browser klient. Begge disse er tynde klient, hvor så meget som muligt af controller
logikken er flyttet til en web service. Dette giver mulighed for let, at kunne udvikle klienter til
andre platforme, hvilket virksomheden, som tidligere omtalt, har planer om i form af en klient til
Android. Klienterne laver metodekald til web servicen, hvor controller logikken ligger på. Fra
denne web service, kaldes metoder på Dynamics Nav web servicen, som enten henter data fra, eller
skriver i de underliggende tabeller. Hvis der hentes data, returneres denne igennem begge web
services, og tilbage til klienten. Nedenfor har vi illustreret, hvordan systemet er opbygget.




                                             Side 29 af 79
Malte Mortensen,                           Hovedopgave                                18-01-2012
Niklas Nøhr                                  JCD A/S
DM70




På web servicen med controller logikken, ligger alle metoderne, som bruges til at kalde Dynamics
Nav web servicens metoder. For at bruge metoderne på Dynamics Nav web servicen, skal der til at
starte med, konfigureres nogle bindings, som passer til Dynamics Nav web servicen. Dette gøres
ved følgende:




Når binding klassen er lavet, kan man derefter lave en Service Client, hvor binding, og endpoint
angives i konstruktøren.




Herefter skal der gives tilladelse til, at endpointet må gøre brug af delegation, som gøres ved
følgende:




Som det sidste før der kan laves metodekald til Dynamics Nav web servicen, skal ClientCredentials
for Service Client angives. I vores tilfælde er det username, password og domæne.




                                           Side 30 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

Derefter kan metoderne på servicen bruges, som vist nedenfor, hvor data for en kunde hentes, ud fra
et kundenummer.




Sikkerhed
Sikkerhed er meget vigtigt for JCD A/S, da deres login oplysninger ikke må kunne opspores. Vi vil
derfor have fokus på dette område under udviklingen af systemet. Nedenfor har vi opstillet hvordan
sikkerheden skal fungere i vores udarbejdede system - vi vil efter illustrationen beskrive hvordan
det skal foregå.




På ovenstående illustration har vi opstillet hændelserne, ud fra hvilken rækkefølge de vil
forekomme i. Det første der sker er, at brugeren indtaster username og password, som sendes til
web servicen med controller logikken, herefter sendes det videre til Dynamics Nav web servicen,
som tjekker om login godkendes. Herefter sendes det retur til "Web service - Controller logic", om
det godkendes. Hvis det ikke godkendes skrives dette til klienten. Er username og password gyldigt,
tildeles brugeren en token, som registreres i en database, sammen med username, password og
udløbstid. Vi har valgt, at en token er en tilfældig kombination af 20 bogstaver, som systemet selv
genererer. Efter at være blevet tildelt en token, sendes denne token retur til klienten. Den givende
token ligger nu placeret lokalt på den givende bruger og lever i 30 min., eller indtil der logges ud af



                                             Side 31 af 79
Malte Mortensen,                            Hovedopgave                                    18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

systemet - herefter vil den givende token blive slettet fra databasen. Mens brugeren har sin token,
sendes denne med, hver gang der kaldes metoder på Dynamics Nav web servicen. Ud fra den token
der modtages, findes der ud af, hvilket username og password der skal bruges, ved at slå det op i
databasen. Disse oplysninger benyttes derefter til, at få forbindelse til Dynamics Nav web servicen.
Brugernes password er krypteret i databasen, for at give en ekstra sikkerhed, så det ikke er muligt at
læse dette fra databasen, uden en krypterings nøgle til at dekryptere oplysningerne. Ved at benytte
en token til, at sende fra klienten til "Web service - Controller logic", kan username og password
ikke spores. Det er først når man kommer igennem "Web service - Controller logic", at username og
password bliver synligt, hvilket ikke er noget problem, da man på dette tidspunkt opererer internt på
virksomhedens netværk. Nedenfor er et udsnit af databasen, som indeholder tokens, og de
tilhørende informationer. Her kan man se at brugerne, som er logget ind i systemet har en token, et
username, et krypteret password, og til sidst er der en udløbs tid for hver token. Passwordet har vi
krypteret ved at lave et certifikat i Microsoft SQL, samt en symmetrisk krypterings key, der bruger
algoritmen AES 256. Derudover er kolonnen "password" af typen varbinary, som indeholder binær
data. Her krypterer vi brugerens password inden det skrives ind i databasen, og dekrypterer
passwordet, når det læses fra databasen. Krypteringen og dekrypteringen sker begge ved brug af den
symmetriske krypterings key, som vi tidligere lavede i Microsoft SQL.




Udover benyttelse af token, vil vi ligge browser applikationen op på en https:// webserver. Dette
gør, at vi sikrer, at data der sendes mellem klienten og "Web service - Controller logic" ikke kan ses
af uvedkommende. HTTPS er en krypteret udgave af HTTP og denne bruges som sagt, når der skal
sendes noget, hvor afsender og modtager er de eneste der må se det sendte. HTTPS benytter port
443, mens HTTP benytter port 80.




                                            Side 32 af 79
Malte Mortensen,                            Hovedopgave                                   18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

Udviklingsmiljø

Udviklingsplatforme
Under dette projekt har vi arbejdet med udviklingsplatformene Silverlight og Silverlight til
Windows Phone. Vi vil under dette punkt beskrive udviklingsplatformene. Ved begge
udviklingsplatforme benyttes .Net programmeringssprogene C# og VB.

Silverlight4

Silverlight er et programmerings framework, som udvikles i programmeringssprogene C# og VB.
Silverlight kan køres både out-of-browser og som browser applikation - det bruges primært som
browser applikation. Til out-of-browser benyttes Microsofts Windows Presentation Foundation
(WPF) oftest. I de første versioner af Silverlight og WPF var der stor forskel mellem dem, men
eftersom der er blevet lavet nye versioner, er de løbende kommet til, at ligne hinanden mere og
mere. For at kunne køre Silverlight applikationer i browseren, kræves det, at brugeren installerer et
browser-plugin. Silverlight kan køre på forskellige operativsystemer, heriblandt Windows, Mac OS
X og Linux. Derudover kan Silverlight køre i browsers, som IE 8+, Safari, Google Chrome osv..

Der er indtil dags dato udkommet 5 versioner af Silverlight. Vi har under projektet benyttet
Silverlight 4, selvom Silverlight 5 er udkommet, men da det kun er en BETA version i skrivende
stund, har vi valgt, at benytte Silverlight 4. Som tidligere omtalt tilbyder Silverlight grafiske
muligheder i browseren, hvilket andre frameworks ikke gør, derfor er Silverlight det ideelle
framework, at benytte, hvis man ønsker browser applikationer med grafiske egenskaber, som er
kompatible på mange operativsystemer og i mange browsers. I Silverlight udarbejdes User Interface
i Extensible Application Markup Language (XAML), derudover udarbejdes codebehind i .cs filer
tilhørende XAML filerne - i .cs filerne kodes der C#.

Udviklingen af Silverlight applikationer sker i Visual Studio og Microsoft Expression Blend, som
begge er programmer vi vil benytte under dette projekt. Vi vil generelt benytte Visual Studio til, at
skrive kode i, mens vi vil benytte Microsoft Expression Blend til, at designe applikationen, da dette
program indeholder grafiske funktioner. Derudover kan et program, som Microsoft Expression
Design bruges til, at designe yderligere i. Ved arbejde i Microsoft Expression Blend, arbejdes der
stadig i Silverlight, det er blot et program som Visual Studio, som har lagt vægt på det grafiske.
Silverlight benyttes samtidig også, som udviklingsplatform til Windows Phone 7 og Symbian (S60).


4
    http://www.silverlight.net/learn


                                            Side 33 af 79
Malte Mortensen,                               Hovedopgave                               18-01-2012
Niklas Nøhr                                      JCD A/S
DM70

Vi vil nedenfor beskrive udviklingsplatformen "Silverlight til Windows Phone", som vi også vil
arbejde med under projektet. Alternativt til Silverlight, kunne vi også benytte f.eks. ASP.net til
udarbejdelse af browser applikationen, men grundet ønske fra JCD om, at vi udarbejder
programmet i Silverlight har vi derfor valgt at gøre dette.



Silverlight til Windows Phone5

Silverlight til Windows Phone fungerer på mange områder på samme måde, som Silverlight. Til
Windows Phone arbejdes der også i programmeringssproget C#, mens der benyttes XAML, .cs filer
osv., som ved Silverlight. Den generelle forskel på Silverlight og Silverlight til Windows Phone er,
at man ved Silverlight til Windows Phone udarbejder en telefon applikation, som udelukkende kan
fungere på Windows Phones. Vi vil benytte de samme programmer, som ovenfor beskrevet, til
udvikling af applikationen. Som tidligere omtalt under punktet "arkitekturovervejelser" vil vi
forsøge, at samle logikken på CTR laget, således vi ved Windows Phone applikationen, blot skal
genbruge koden derfra. Vi forventer derved ikke, at der skal laves mange rettelser i forbindelse med
udskiftningen af brugegrænsefladen, men forbereder os alligevel på, at der er nogle funktioner der
muligvis ikke fungerer på Windows Phone, som fungerer i browser applikationen. Vi vil benytte
www.msdn.com til, at finde ud af hvad Windows Phone understøtter, hvilket kan ses på de
forskellige klasser.




Kodestandard
Vi har valgt at fastlægge en kodestandard i forbindelse med vores projekt, fordi vi er to, som skal
arbejde på det, og derfor er det en fordel at være enige om, hvordan koden skal laves. Dette gør det
lettere at læse hinandens kode, og lave tilføjelser eller rettelser.

Vi har valgt at navngive fields med "_" foran, som er standard i C#. Et eksempel på dette kan være
"_name". Metodenavne skal starte med et stort bogstav, og have et komplet og beskrivende navn, fx
"GetAllCustomers()". Vi vil bruge engelske navngivninger mest muligt, men som tidligere omtalt
kan vi ikke undgå danske navne pga. Dynamics Nav. Hovedvægten af engelske navngivninger gør
systemet lettere at vedligeholde, for personer som ikke kan dansk. Der skal skrives kommentarer til
komplekse metoder, så de lettere kan forstås af personer, som ikke har lavet dem. Koden skal

5
    http://www.silverlight.net/learn


                                               Side 34 af 79
Malte Mortensen,                              Hovedopgave                                     18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

opstilles pænt, med passende indryk, så den er let at læse. Textboxes, Buttons og lignende
navngives med samme betegnelser, fx "button_FirstName". Objekter navngives med et lille bogstav
først. Når der benyttes "Sqlconnection", "Datareader" eller lignende bruger vi usings, så vi er sikre
på at alle forbindelser bliver lukket, når de ikke bliver brugt mere. Vi kunne i dette tilfælde også
have brugt try/finally, som fungerer nogenlunde på samme måde som ved usings. Usings er faktisk
en try/finally blok, hvor finally blokken indeholder en IDisposable.Dispose() metode. I denne
metode bliver connections osv., som er startet i den givne using, forkastet og derved lukket. I
forhold til en almindelig try/finally, er dette smart, da man i den almindelige "finally", selv skal
sørge for at lukke de forskellige connections osv., som man har startet under "try". Dette er den
store forskel på usings og try/finally og samtidig grunden til, at vi har valgt, at benytte usings.




Versionsstyring
Versionsstyring er et smart koncept, specielt hvis man arbejder i grupper, hvor flere personer har
mulighed for, at rette i et dokument. Overordnet set er det en server der gemmer alle gamle
versioner af filer. Derudover er det muligt, at arbejde i samme kode, hvorefter man kan committe og
koden derefter bliver sat sammen. Vi har valgt, at benytte TortioseSVN6 som versionsstyring, da vi
kan tilgå dette program over nettet. Samtidig letter det vores arbejde, da vi ikke skal bruge en masse
tid på at flytte koden rundt. Derudover er det en sikkerhed for os, at det vi laver bliver gemt på en
server, således vi altid kan tilgå det.



Tidsplan - Revurderet
Efter at have besluttet, at vi vil benytte Scrum som planlægningsmetode, har vi planlagt projektet ud
fra denne metode. Derved er vi nu klar til, at revurdere vores tidsplan, samt specificere den, således
den kommer til, at passe ud fra hvordan vi forventer projektet nu vil forløbe. Den revurderede
tidsplan kan ses under dette punkt. Som det ses i tidsplanen, har vi specificeret den, således den nu
indeholder alt hvad vi forventer projektet skal indeholde. Dermed kan vi specifikt sætte estimater på
hvert enkelt punkt, og derved finde frem til, hvornår vi forventer projektet færdigt. Som det ses på
tidsplanen har vi indsat 3 sprints, som vi ud fra product backloggen forventer, at koden vil tage at
implementere. Under hvert sprint har vi afsat tid til, at udarbejde designdiagrammer, dette har vi



6
    http://tortoisesvn.net/


                                              Side 35 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

gjort, fordi vi endnu ikke ved, om vi får brug for nogle designdiagrammer fra UP, og derved har
muligheden for at tage dem ind, hvis vi får brug for dem.

Som det ses til sidst i tidsplanen forventes projektet færdigt d. 23/01-2011, hvilket er nogle dage
senere end det i realiteten skal afleveres, nemlig d. 18/01-2011. Grunden til den sene slutdato
skyldes, at vi under tidsplanen har taget alt hvad der skal programmeres med, selvom vi ikke
forventer, at nå det hele. Samtidig er 3. sprint ikke fyldt helt ud, da det indeholder 13 dage, hvor et
sprint varer 20 dage. Vi forventer, at implementere 1. og 2. sprint, mens vi ikke forventer, at nå 3.
sprint, derfor vil tidsplanen også komme til at passe i sidste ende.

Overordnet set forventer vi, at være færdige til tiden, mens vi ikke forventer, at få implementeret 3.
sprint. Indholdet i tidsplanen er nødvendigvis ikke alt hvad projektet kommer til at indeholde, men
et udkast til hvad vi forventer det kommer til at indeholde.




                                             Side 36 af 79
Malte Mortensen,   Hovedopgave     18-01-2012
Niklas Nøhr          JCD A/S
DM70




                   Side 37 af 79
Malte Mortensen,                              Hovedopgave                                   18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

Planlægning af 1. sprint
Velocity
Velocity er et udtryk for, hvor meget arbejde Scrum teamet kan nå at lave på et sprint. Velocity har
vi valgt, at udregne i antal effektive arbejdsdage. Det kan være svært for et Scrum team, at
fastlægge deres velocity for det første sprint, da de ikke har erfaring fra tidligere sprints. Hvis
Scrum teamet allerede har udført nogle sprints, kan man ud fra disse, udregne Scrum teamets
velocity mere præcist. Ved at se på de tidligere sprints, kan man se hvor mange user stories Scrum
teamet har fuldført, og herved udregne teamets velocity.

Vi har valgt at længden på vores sprints skal være to uger, altså 10 arbejdsdage. Vi er to personer til
at udvikle systemet, hvilket betyder at vi har 20 dage på et sprint. Under et sprint kan man ikke
arbejde 100 % effektivt med user stories hele tiden, fordi der vil opstå situationer, hvor man mister
fokus på opgaven. For at tage hensyn til dette, har vi valgt at sætte vores "fokus faktor" til 80 %,
dvs. vores faktiske effektive arbejdsdage under et sprint er 20*0,8 = 16 effektive arbejdsdage.
Derfor kan vi maksimalt tage user stories, som svarer til 16 dages effektivt arbejde, ind i det første
sprint. Efter det første sprint er udført, vil vi i sprint retrospective lave en revurdering af vores
velocity, ud fra hvor meget arbejde vi kunne fuldføre, så vores velocity for det næste sprint bliver
mere præcis.




Spike
Et spike7 bruges normalt i XP (eXtreme Programming), hvis man er usikre på teknologien for
løsningen af en bestemt opgave. Vi har valgt at drage spike ind i dette projekt og benytte det hvis
Scrum teamet er usikre på en user story mht. teknologien, der skal bruges for at implementere
denne. Spiket har vi valgt at lave som et teknisk memo8, da dette er en god måde, at dokumentere et
teknisk eksperiment på. Ved et spike laves der research omkring et bestemt emne, hvor yderligere
information er nødvendigt. Et spike giver os bedre forudsætninger for, at estimere meget komplekse
user storys mere præcist. Et spike bruges også til at undersøge, hvordan en ukendt teknologi
fungerer, og om det er muligt at benytte denne, til løsning af en bestemt opgave. Der bruges ofte et
fastlagt tidsinterval til udførslen af et spike, og det udføres før et sprint begynder.



7
    http://www.extremeprogramming.org
8
    Applying UML and Patterns, Craig Larman


                                               Side 38 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

Herunder har vi udarbejdet et spike for en risiko fra risikoanalysen. Spiket har en længde på to
dage, hvor vi laver research omkring en Dynamics Nav web service, som skal bruges til
implementering af flere user stories. Vi har aldrig arbejdet med en Dynamics Nav web service,
derfor var det nødvendigt med et spike.



Emne: Forbindelse til Dynamics Nav web service

Løsning opsummering: Benytte credentials og binding indstillinger til, at få forbindelse.

Faktorer:

      Forbindelse til Dynamics Nav web service

Løsning: Vi lavede et projekt i Visual Studio, hvor vi lavede forbindelse til Dynamics Nav web
servicen. Dette gjorde vi vha. client credentials, hvor vi brugte et username og password der svarede
til et i Dynamics Nav. Vi konfigurerede nogle binding indstillinger, således de passede til Dynamics
Nav. Herefter kunne man opsætte søgefiltre og derefter kalde metoder fra Dynamics Nav web
servicen.

Motivation: For at skrive og hente data til/fra et eksternt program, er det nødvendigt, at få
forbindelse til Dynamics Nav web servicen.




                                             Side 39 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

Sprint backlog




På et sprint planning meeting laves sprint backlog for det kommende sprint. Sprint backlog laves ud
fra product backlog, hvor de højest prioriterede user stories overføres til sprint backloggen. Antallet
af user stories, som overføres, afgøres ud fra teamets velocity, og estimaterne på product
backloggens user stories. Her overfører man ikke flere user stories, end teamets velocity tillader. I
vores tilfælde har vi en velocity på 16 dage for det kommende sprint, derfor har vi overført de 3
højest prioriterede user stories, til det kommende sprint's backlog. Disse 3 user stories udgør i alt 13
dage, hvilket ikke er helt nok til at udfylde det kommende sprint, med en velocity på 16. Hvis der
var blevet tilføjet endnu én user story, ville teamets velocity blive overskredet, hvilket vi derfor
undlader. Det er muligt at inddrage ekstra user stories i løbet af sprintet, hvis alle user stories for
det pågældende sprint er blevet færdiggjorte, og der stadigvæk er tid tilbage i sprintet. Hvis dette er
tilfældet, vælger man den højest prioriterede user story fra product backloggen, som endnu ikke er
overført til sprint backloggen. Efter der er overført user stories til sprint backloggen, nedbrydes
disse til tasks af Scrum teamet, og alle tasks estimeres i timer. Når teamet ikke at implementere alle



                                             Side 40 af 79
Malte Mortensen,                             Hovedopgave                                      18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

de planlagte user stories for et sprint, vil de user stories som ikke er blevet færdiggjorte, få højest
prioritet i det efterfølgende sprint. Hvis denne situation skulle opstå ville vi informere kunden om
dette.



Work Breakdown Structure (WBS)
Work Breakdown Structure eller WBS, gør det muligt, at nedbryde komplekse user stories til
mindre tasks, således det er lettere, at estimere. Man fortsætter med, at nedbryde de forskellige
tasks, indtil taskene er så små, at de let kan estimeres. WBS benyttes til, at gøre projekter mere
overskuelige, således der kan gives et mere præcis estimat. Under nedbrydningen af de forskellige
user stories, skal de indblandede i udviklingen være samlet, således de kan drøfte tingene og
fastsætte estimaterne ud fra hvad de forskellige personer vurderer estimaterne til at være.

Vi vil tage udgangspunkt i billedet fra afsnittet ”Sprint Backlog”, når vi forklarer omkring
nedbrydning af de forskellige user stories. Billedet illustrerer de forskellige user stories, som hører
til under første sprint, samt de tasks vi har lavet og estimeret. Hvis vi tager udgangspunkt i første
user story ”Registrering af tid (Controller logik)”, har vi i teamet drøftet hvilke forskellige opgaver
der var til denne story og givet hver opgave en task – dette er derved blevet til 4 forskellige tasks.
Efter fastsættelse af de forskellige tasks, har vi drøftet hvordan de skulle estimeres og har derved
fundet frem til forskellige estimater, som passer på hvert task. Dette har vi herefter også gjort ved
de andre user stories i første sprint, således vi har fundet frem til, hvad der skal laves af forskellige
opgaver på hvert task. Overordnet set giver arbejdet med WBS et godt overblik over, hvad man skal
lave i en bestemt user story, samt hvor længe en specifik user story vil tage at implementere – det
giver samtidig mulighed for, at flere udviklere kan arbejde på samme user story ved, at vælge
forskellige tasks.

Estimering
Ovenfor har vi været omkring estimering af de forskellige tasks, men under dette punkt vil vi
fortælle lidt mere omkring estimering. Estimering bruges på flere forskellige måder i et projekt. Det
bruges til, at vurdere hvornår specifikke opgaver er færdige, men også for at kunne fortælle kunden
hvornår man forventer, at produktet er færdigt. Der findes forskellige måder, at estimere på, men
den mest benyttede er gruppe estimering. Ved gruppe estimering benyttes Planning-poker i Scrum,
her har hver person i teamet nogle kort med forskellige estimater. Når de forskellige tasks skal
vurderes, lægger hver person deres forventede estimat på bordet, og der diskuteres herefter i forhold



                                              Side 41 af 79
Malte Mortensen,                                          Hovedopgave                          18-01-2012
Niklas Nøhr                                                 JCD A/S
DM70

til hvad der er blevet lagt på bordet. Vi vælger ikke at gøre det på denne måde i dette projekt, da det
oftest benyttes når der er flere personer i teamet. Vi vælger vores egen metode for gruppe
estimering, hvor vi sidder og snakker om de forskellige tasks, og finder frem til hvilket estimat de
forskellige tasks skal have – det minder meget om planning-poker, bortset fra, at vi ikke benytter
kortene.



Burndown Chart
Under dette punkt vil vi beskrive, hvordan et burndown chart fungerer, og hvorfor vi benytter det.
Vi vil under dette punkt ikke benytte det i praksis, da vi endnu ikke har udført et sprint – vi vil
derfor vende tilbage under sprint retrospective, hvor vi vil kigge nærmere på hvorledes vi har ramt
vores velocity, eller om denne skal rettes til næste sprint. Nedenfor har vi opstillet burndown chartet
for første sprint, hvor vi på x-aksen har placeret antal dage i sprintet og på y-aksen har placeret
estimeret arbejde tilbage (Dage).


                                            Burndown Chart - 1. Sprint
                               16

                               14
   Estimeret arbejde tilbage




                               12

                               10
            (Dage)




                                8

                                6

                                4

                                2

                                0
                                    0   1     2   3   4        5          6   7   8   9   10
                                                          Dage i sprint


Ud fra de to akser har vi en linje, som viser hvorledes sprintet gerne skulle forløbe. Dette er det
optimale i forhold til, hvordan man har estimeret og fastsat sin velocity. Under sprintet vil vi hver
dag sætte et punkt for, hvor meget arbejde der er tilbage efter hver dag, således det i slutningen af
sprintet kan vurderes, hvordan det er forløbet. Det kan derfor forekomme, at man nogle gange er
over den reelle streg eller under den reelle streg. Det vil være positivt, at være under stregen, da
man på denne måde har nået mere end man havde forventet, mens man vil være bagud i forhold til


                                                          Side 42 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

sit estimat, hvis man er placeret over stregen på nogle tidspunkter i løbet af sprintet. Vi vil som sagt
tage burndown chartet frem igen ved slutningen af hvert sprint, hvor vi vil vurdere hvordan det er
gået.




                                             Side 43 af 79
Malte Mortensen,                              Hovedopgave                                18-01-2012
Niklas Nøhr                                     JCD A/S
DM70


Udvikling af 1. sprint
Under dette punkt vil vi fortælle om forløbet under vores første sprint. Første sprint forventes, at
omhandle de 3 første user stories fra product backloggen, men hvis vi når mere end forventet og har
plads til den 4. user story, vil vi også inddrage denne under første sprint.

Prototype - Mockups
Under dette punkt har vi opstillet mockups for de forskellige skærmbilleder ved timeregistrering via
browser. På de forskellige mockups vil vi foretage en tænke højt test på en ansat i virksomheden,
således vi allerede på nuværende tidspunkt kan forme systemet efter hvordan virksomheden ønsker.
Dette vil mindske rettelser i brugergrænsefladen og koden på sigt.




Figur 1




Figur 2



Ovenstående mockup (Figur 1) illustrerer en timeregistrering. Vi har forsøgt, at få
brugergrænsefladen til, at ligne deres egen Dynamics Nav timeregistreringsløsning, således det er
lettest muligt, at bruge browser applikationen. Ved udarbejdelse af mockups har vi gjort mange
overvejelser omkring brugervenlighed, da virksomheden ønsker systemet så enkelt som muligt. Vi
har benyttet gestaltlovene9 med henblik på, at udarbejde et brugervenligt system. Loven om nærhed
benyttes mange steder på ovenstående billede, vi har bl.a. sat tidsangivelse (start- og slut tid) og

9
    Brugervenligt webdesign, Rolf Molich


                                              Side 44 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

dato ved siden af hinanden, således man ved, at de ting hører sammen. Derudover kan "Sag" og
"Undersag" nævnes, som også er placeret ved siden af hinanden, da man får nogle undersager efter,
at have trykket på en sag og det er derved let, at se de hører sammen. Derudover har vi også
benyttet loven om lukkethed, ved at lave timeregistreringen i sin egen "tab" og ikke blande det
sammen med den anden "tab", som hedder "Arbejds/Time Log". Derved forstår brugeren også, at
alt under "Timeregistrering" hører sammen. Loven om lighed har vi benyttet ved vores visning af
sager og visning af undersager. Visningen sker i "bokse/liste" som er ens, hvilket er brugervenligt,
da det ikke forstyrrer brugerens syn. Figur 2 vil vi skifte ud med "Starttid", "Sluttid" og "Dato", når
manuel indtastning ændres til nej.

Som sagt har vi udført en tænke højt test 10 og på dette skærmbillede var vores testperson Bjarke
Nielsen (Udvikler hos JCD), overordnet set, tilfreds med denne mockup - Bjarke Nielsen er en
kommende bruger af systemet, og han er derfor en relevant testperson. Han havde nogle få rettelser
i brugergrænsefladen og nogle ønsker til, hvordan forskellige ting i brugergrænsefladen skulle
fungere, således det blev let at arbejde i. Fra Dynamics Nav er de vant til, at kunne udføre hele
timeregistreringen uden mus og han foreslog derfor, at vi skulle vælge rækkefølgen på "tab-
funktionen" nøje, således det er let at navigere rundt uden mus.

Ud fra vores tænke højt test har vi derved fundet ud af, at de udarbejdede mockups er ramt godt, i
forhold til hvad kunden ønsker. Der var nogle få rettelser og ønsker til systemet, som vi vil rette op
på under udviklingen af systemet.

Testen foregik ved, at testpersonen sad med mockup'en, og fortalte hvad han forestillede sig, at
skærmbilledet ville gøre ved at trykke forskellige steder. Under hele testen fungerede vi som
observatører, mens testpersonen skulle tale højt, således vi kunne notere, hvordan de forskellige ting
skulle laves.




10
     Brugervenligt webdesign, Rolf Molich


                                             Side 45 af 79
Malte Mortensen,                              Hovedopgave                                     18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

Domænemodel




Vi har i opstarten af dette sprint, overvejet om vi får brug for nogle modeller fra UP. Vi har som
tidligere omtalt valgt Scrum som planlægningsmetode og vi har dertil fri mulighed for at vælge
forskellige aspekter fra udviklingsmetoderne UP og XP. Vi har valgt, at udarbejde en
domænemodel fra UP, da den kan give et godt overblik over sammenhængen mellem de forskellige
klasser i projektet. Vi får samtidig et overblik over, hvilke attributter vi får brug for, samt relationen
mellem de forskellige klasser. Som sagt har vi ikke selv udarbejdet databasen, og vi har derfor
modtaget vejledningen om de forskellige klasser og attributter fra JCD. Bemærkelsesværdigt i den
udarbejdede domænemodel er, at nogle navne er på dansk og andre på engelsk. Dette er ikke i
hensigt med vores kodestandard, men det er deres navne fra Dynamics Nav, og vi har derfor ikke
mulighed for, at ændre navnene til ét bestemt sprog.

Klassen "WindowsLogin" indeholder login oplysninger, som bruges når en bruger skal logge ind på
systemet. Derefter findes klassen "Job_Journal_Lines", som er selve timeregistreringen og derfor
den primære klasse i projektet. Klassen "Arbejdstyper" indeholder de forskellige arbejdstyper, som
kan angives ved en timeregistrering, dette kan bl.a. være "KM" eller "ARBEJDSTIMER".
"SagsOversigt" klassen indeholder de forskellige sager man kan arbejde på - en sag vil være en
kunde. Disse sager kan have undersager, som f.eks. "Udvikling" og "Telefonsupport" -
undersagerne findes på klassen "Job_task". Til en sag er der tilknyttet en kunde, som der refereres
til i klassen "Customer". Til klassen "Job_Journal_Lines" er der også tilknyttet klassen
"Ressourcekort", hvorpå man finder personen, som skal udføre timeregistreringen - denne hentes ud


                                              Side 46 af 79
Malte Mortensen,                              Hovedopgave                                   18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

fra brugeren, som er logget ind. Mellem de forskellige klasser har vi angivet relationer. Hvis man
tager udgangspunkt i relationen mellem "Job_Journal_Lines" og "SagsOversigt", kan en
"SagsOversigt" have 0 til mange "JobJournalLines", mens en "JobJournalLines" kun kan have 1
"SagsOversigt".

I forhold til dette projekt, har vi valgt at vise domænemodellen forsimplet, da det skal passe til
projektets størrelse. Vi har derfor kun valgt, at indsætte de attributter vi får brug for, og ikke alle
attributter som er tilgængelige i de forskellige klasser.



Interaktionsdiagram
Vi har valgt, at lave et interaktionsdiagram for oprettelse af en timeregistrering, hvilket er vores
mest komplekse user story. Dette gør vi for at skabe et bedre overblik over, hvilke web services,
klasser og metoder, der er nødvendige, for at gennemføre en timeregistrering. På
interaktionsdiagrammet nedenfor kan man se, at der skal bruges 5 forskellige Nav web services, og
6 metoder for at oprette en timeregistrering. Metoderne bliver kaldt fra MainPage, som kalder
metoder på et interface i form af en web service, der kalder metoder på klassen CTRLogic. Det er
klassen CTRLogic, der står for at lave kald til Nav web services, hvor nogle af dataene, som skal
bruges til timeregistreringen, hentes fra. For at skabe højere binding i systemet, kunne man have
lavet flere controller klasser, en for hver web service, men vi mente ikke dette var nødvendigt, da
det primært er "Get metoder", som kaldes fra controlleren. Dette ville resultere i 5 controller
klasser, hvor 4 af dem kun ville indeholde én "Get metode". Fra start laver CTRLogic metodekaldet
GetRessourcekort(), hvor den henter navnet på brugeren, som er logget ind. Ved oprettelse af
timeregistreringen har vi lavet metoden GetMaxLineNo(), som henter det højeste linjenummer.
Dette metodekald kører umiddelbart før metoden CreateJobJournalLine(), da der kræves et
linjenummer før timeregistreringen kan udføres.




                                              Side 47 af 79
Malte Mortensen,                               Hovedopgave                                     18-01-2012
Niklas Nøhr                                      JCD A/S
DM70




Kodedokumentation
I løbet af første sprint, implementerede vi metoden, som bruges til at oprette en timeregistrering.
Dette er den mest komplekse metode, som blev implementeret i første sprint, derfor har vi valgt at
gennemgå denne. Vi starter med at beskrive metoden i brugergrænsefladen, og bevæger os derefter
igennem systemets forskellige lag.




Her kan man se, at der laves en instans af objektet "Job_Journal_Lines", som bruges til at lave en
timeregistrering.   Derefter   sættes   alle   objektets   properties,   til   de   valgte   værdier   fra
brugergrænsefladen.



                                               Side 48 af 79
Malte Mortensen,                              Hovedopgave                                     18-01-2012
Niklas Nøhr                                     JCD A/S
DM70




Derefter sættes objektets property for antal, ud fra om arbejdstypen er kørsel eller arbejdstid, hvilket
betyder at antallet skal registreres i enten km eller timer.




Herefter skal "Specified" for properties sættes til true, for at angive, at der er blevet sat en værdi, og
denne bliver gemt på objektet.




Ovenfor bliver der lavet en ny SoapClient af web servicen, der fungerer som interface for controller
logikken. Denne klient bruges til at kalde metoden "CreateJobJournalLine", hvor Job_Journal_Line
objektet "newJobLine" sendes med som parameter, samt en token der bruges i forbindelse med
sikkerhed.

Metodekaldet ovenfor sendes videre til web servicen, som er interface for controller logikken.
Koden for web servicen er vist nedenfor.




Her kan ses at metoden "CreateJobJournalLines" kaldes på klassen "CTRLogic", med parametrene
newJobline, som er et objekt af Job_Journal_Lines, samt en token.

I controller klassen, som ses nedenfor, starter vi med at kontrollere den token, der er blevet sendt
med.



                                              Side 49 af 79
Malte Mortensen,                           Hovedopgave                                   18-01-2012
Niklas Nøhr                                  JCD A/S
DM70




Der søges efter denne token i en database, hvor der er et username, password og en udløbstid, til
eksisterende tokens. Herefter kontrolleres der om udløbsdatoen er overskredet, hvis dette ikke er
tilfældet, fortsætter metoden .




Ovenfor angives indstillinger, som skal bruges til at få forbindelse til en Dynamics Nav web
service, som er forklaret mere detaljeret i afsnittet "Kommunikation med Dynamics Nav web
service". Her benyttes username og password til at logge ind med, hvilket ligger på et "Credentials"
objekt, som vi har hentet fra en database, som nævnt tidligere. Derefter              laves en ny
"Job_Journal_Lines_PortClient", som bruges til at kalde metoden Create, på Dynamics Nav web
servicen, hvor et "Job_Journal_Line" objekt sendes med som parameter.




                                           Side 50 af 79
Malte Mortensen,                             Hovedopgave                                     18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

Unit Tests
I 1. sprint har vi implementeret funktionaliteten for systemets controller logik, hvilket vi har valgt at
lave unit tests af, da det hjælper os med at sikre, at koden fungerer som den skal. Med unit tests kan
man let teste koden undervejs i udviklingen, når man udbygger systemet, hvilket er meget effektivt,
da man på denne måde, kontrollerer at koden bliver ved med at virke, når der laves ændringer, eller
kommer nye tilføjelser.

Her vil vi vise nogle eksempler af unit tests fra vores kode. Det første eksempel er test for login
metoden.




Metoden TestLogin() returnerer en string på 20 tilfældige tegn, der fungerer som en token for den
bruger som er logget ind. Denne string genereres af metoden GetRandomString(). I testmetoden
kaldes disse to metoder, som begge returnerer en string, hvor vi tester på længden af disse to strings.
Hvis TestLogin() metoden fejler, returneres der en empty string, og testmetoden vil derfor også
fejle.

Derefter har vi lavet en testmetode for "GetCustomer()", der returnerer et customer objekt. Her
starter vi med at kalde login metoden, som vi allerede har testet, for at få en token, der skal bruges,
når alle andre metoder på controller logikken skal kaldes. Denne token sendes som parameter,
sammen med et customer nummer, hvilket resulterer i, at man får et bestemt customer objekt
tilbage. Vi kender navnet på den customer der har dette customer nummer, og bruger derfor
instansvariablen "Name" til at teste op imod.




                                              Side 51 af 79
Malte Mortensen,                                Hovedopgave                                   18-01-2012
Niklas Nøhr                                       JCD A/S
DM70

Ekstra user story i 1. sprint
I 1. sprint blev vi i løbet af de 8 første dage, færdige med de 3 user stories, der var planlagt til dette
sprint. Derfor valgte vi at overføre endnu én user story, til sprint backloggen. Det blev den højest
prioriterede user story, fra product backloggen, som endnu ikke var implementeret, hvilken har ID 4
som vist nedenfor. Denne user story indeholder implementering af interface til browseren, og er
estimeret til 4 dage (omregnet til 2 arbejdsdage når vi er 2 udviklere), hvor vi har medregnet
prototyper og test af disse, i form af en brugervenlighedstest.




Vi blev færdige med denne user story på de 2 sidste dage i sprintet, og havde derfor nok
funktionalitet i systemet, til at lave en release efter 1. sprint.




                                                Side 52 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

1. Sprint review

Sprint review
I løbet af vores første sprint nåede vi, at implementere de første 4 user stories, hvilket er én user
story mere end vi havde forventet, og havde overført til vores sprint backlog. Som afslutning på
sprintet, holdte vi et sprint review meeting, hvor kunden deltog. Her præsenterede vi de
implementerede user stories' funktionalitet for kunden, for at sikre de var lavet, som kunden ønsker
det. Herefter gennemgik vi acceptance test kriterierne i product backloggen sammen med product
owner, da vi efter hvert sprint har en acceptance test, hvor product owner skal afgøre om det, der er
blevet udviklet under sprintet kan godkendes, i forhold til de krav der blev opstillet i product
backloggen. Product owner prøvede selv programmet, således vi kunne opfange eventuelt tvivl fra
brugerens side, under oprettelsen af en timeregistrering. Product owner var tilfreds med resultatet af
sprintet, fordi alle user stories opfyldte acceptance test kriterierne fra product backloggen. Derfor
godkendte product owner det første sprint, og acceptance testen er derved gennemført. Product
owner gav noget feedback i form af et par mindre rettelser. I forbindelse med oprettelsen af en
timeregistrering, skal start- og sluttiden registreres med intervaller af et kvarter. Derudover har vi
lavet "Start" og "Stop" knapper til timeregistreringen, hvilket product owner ønskede skulle skjules
fra browser applikationen. Product owner ville dog gerne beholde funktionaliteten dertil, således
kunden på et senere tidspunkt har mulighed for, at benytte det. Disse rettelser har vi planer om, at
lave i det kommende sprint, så det kan indgå i den næste release.



Sprint retrospective
I vores første sprint planlagde vi som sagt, at udføre de første 3 user stories fra vores product
backlog, som vi har estimeret til 13 dages effektivt arbejde. Det gik hurtigere med udviklingen af
disse user stories end vi havde forventet, og vi nåede derfor at fuldføre de 3 første user stories på 8
dage, som kan ses på Burndown chartet for sprintet nedenfor. Derfor tilføjede vi én user story mere
fra product backloggen til sprintet. Dette var den højest prioriterede user story, som var tilbage i
product backloggen, hvilken har ID 4. Denne user story er estimeret til 4 dages effektivt arbejde.
Som det ses i burndown chartet, har vi sat denne user story ind efter 8 dage og "estimeret arbejde i
dage" bliver derfor sat til 4. Derved ser det ud til, at man er bagude i forhold til den ideelle linje,
men da det totale estimerede arbejde stiger til 17 dage, bliver den ideelle linje rykket, således man
ikke er bagude i forhold til den ideelle linje - dette ses ikke på figuren nedenfor. Vi blev færdige



                                             Side 53 af 79
Malte Mortensen,                                          Hovedopgave                          18-01-2012
Niklas Nøhr                                                 JCD A/S
DM70

med denne på 10. dag i sprintet, og nåede derfor i alt 4 user stroies, der til sammen var estimeret til
17 dages effektivt arbejde. Vi havde sat vores velocity til 16 dages effektivt arbejde på et sprint,
hvilket vi for næste sprint vælger at justere op til 17 dages effektivt arbejde. Dette giver en fokus
faktor på 0,85 i stedet for 0,80. Vi var usikre på, hvor præcise estimeringerne af de forskellige user
stories i første sprint var, hvilket vi også har noteret som en risikofaktor, men de viste sig at passe
forholdsvist godt, da vi nåede at udføre 4 stories, som var estimeret til 17 dages effektivt arbejde i
løbet af sprintet, hvor der var 16 dages effektivt arbejde til rådighed.


                                            Burndown Chart - 1. Sprint
                               16

                               14
   Estimeret arbejde tilbage




                               12

                               10
            (Dage)




                                8

                                6

                                4

                                2

                                0
                                    0   1     2   3   4        5          6   7   8   9   10
                                                          Dage i sprint



Eftersom vi nåede at udvikle de første 4 user stories fra product backloggen, vil vi lave den første
release af systemet, efter dette sprint, fordi systemet nu indeholder nok funktionalitet til, at det kan
benyttes af kunden.

Udviklingen af projektet er forløbet godt, vi er ikke stødt på de store problemer og har hurtigt fået
løst problemerne når de er opstået. Unit testing voldte i starten en del problemer, men efter hurtig
research fik vi det til at virke og det er derfor ikke noget der har rykket vores tidsplan. Omkring de
forskellige valg af indhold i 1. sprint har vi drøftet vores beslutninger nøje, således vi er nået frem
til den bedst mulige løsning. Derudover har vi også drøftet opståede problemer nøje, således vi har
fundet de bedste løsninger.

Under 1. sprint har vi haft brug for aspekter fra udviklingsmetoderne UP og XP. Fra XP har vi
benyttet spike, hvilket har givet os et godt indblik i ukendt teknologi. Spike har gjort, således vi har


                                                          Side 54 af 79
Malte Mortensen,                             Hovedopgave                                     18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

kunne estimere projektet mere præcist, samt haft styr på området inden vi igangsatte arbejdet med
den givne user story. Fra UP har vi valgt at udarbejde en domænemodel, samt et
interaktionsdiagram. Domænemodellen har givet os et overblik over de forskellige klasser og
attributter, samt sammenhængen mellem de forskellige klasser. Interaktionsdiagrammet har gjort
det nemmere for os, at udvikle metoderne omkring oprettelse af en timeregistrering. Diagrammet
viser hvilke metoder man får brug for, samt hvilke klasser og web services man skal have fat i for at
fuldføre de forskellige opgaver. Overordnet set har brugen af aspekter fra UP og XP gjort arbejdet
lettere for os på længere sigt, og hvor det er nødvendigt vil vi igen benytte aspekter fra disse
udviklingsmetoder.




Deployment
I slutningen af dette sprint har vi udført en release af de udarbejdede features, til JCD. JCD vil nu
kunne benytte produktet, og vi vil i næste sprint lave de små rettelser, som JCD ønsker. Produktet
vil blive benyttet på en test server i første omgang og bliver derved ikke integreret med deres
nuværende timeregistrering. Integration med deres nuværende timeregistreringssystem vil hurtigt
kunne udføres. Produktet vil ikke blive benyttet til salg, før rettelserne er udført og før JCD har
benyttet det i deres nuværende timeregistreringssystem.



Opfølgning på risikoanalyse
Under planlægningen af projektet, udarbejdede vi en risikoanalyse, hvor vi havde nogle områder
der var risiko ved. Vi har under dette sprint formindsket risikoen ved tre af områderne, efter at have
arbejdet med det. Den ene risiko var, at vores estimater kunne være upræcise. Dette har de ikke
været, men i stedet har vores fokus faktor været bedre end forventet. Denne fokus faktor har vi som
sagt ændret til 0,85 i stedet for 0,80. Til næste sprint vil vi være mere sikre på vores estimater, da vi
har arbejdet med forskellige områder i Silverlight og omkring Dynamics Nav forbindelse. Netop
forbindelse til Dynamics Nav web servicen var en anden risiko i dette sprint. Vi frygtede, at der
ville opstå problemer med, at få forbindelse til web servicen, men grundet et gennemarbejdet spike i
planlægningen af sprintet, gjorde dette arbejdet en del lettere, da vi kom til opgaven. Vores velocity
var en anden risiko. Som tidligere beskrevet var vores velocity for sidste sprint på 16 dages effektivt
arbejde, mens den nu har ændret sig til 17 dages effektivt arbejde til næste sprint. Vi kan derved
konkludere, at vi har mindsket risikoen ved, at estimater kan være upræcise, samt velocity kan være


                                              Side 55 af 79
Malte Mortensen,                                 Hovedopgave                                  18-01-2012
Niklas Nøhr                                        JCD A/S
DM70

upræcis, derudover har vi fjernet risikoen ved, om vi kunne få forbindelse til Dynamics Nav web
servicen. Vi vil derfor udarbejde spikes til fremtidige risikoer, hvis vi mener dette er nødvendigt.


Planlægning af 2. sprint
Opfølgning af product backlog
Afslutningsvis i 1. sprint ved acceptance test, kom JCD med nogle rettelser til systemet. Disse
rettelser har vi derfor sat på product backloggen. Vi har givet denne user story 55 i prioritet, hvilket
gør, at denne user story er den første der skal implementeres i dette sprint.

ID       User story                          Importance Estimat Acceptance test
                                             (0-100)    (dage)
10       Start- og sluttiden skal kunne      55         0,25    Der skal laves således, at starttiden
         registreres med intervaller af et                      runder ned til det nærmeste kvarter,
         kvarter (Rettelse fra 1. sprint)                       mens sluttiden runder op til det
                                                                nærmeste kvarter, ved en
                                                                timeregistrering.


Velocity
I vores 2. sprint bliver længden på sprintet igen 10 arbejdsdage, dvs. at vi igen har 20 arbejdsdage
til rådighed i sprintet, fordi vi er 2 udviklere, som arbejder på projektet. I det forrige sprint erfarede
vi, at vores velocity kunne justeres lidt op i dette sprint, fordi vi fuldførte mere arbejde end
forventet. Vi nåede i alt, at fuldføre user stories, som var estimeret til 17 dages effektivt arbejde.
Derfor har vi som sagt ændret vores fokus faktor til 85%, hvilket giver os 0,85 * 20 dage = 17 dages
effektivt arbejde i sprintet. Som afslutning på sprintet vil vi igen, under retrospective evaluere på
teamets velocity, og evt. lave justeringer, hvis dette er nødvendigt.




Spike
Emne: Beregning af distance vha. telefonens GPS funktion

Løsning opsummering: Kørselsberegning vha. bing maps

Faktorer:

          Hurtig og præcis beregning af distance mellem start- og slutpunkt.




                                                 Side 56 af 79
Malte Mortensen,                           Hovedopgave                                       18-01-2012
Niklas Nøhr                                  JCD A/S
DM70

Løsning: Vi lavede en lille applikation med hardcodede koordinater og vha. bing maps, kunne vi
udregne GPS koordinaterne for start- og slutpunkt. Herefter kunne vi vha. en rute service
(RouteService), som bing maps tilbyder, finde distancen mellem de to punkter.

Motivation: For at brugerne let kan holde styr på deres kørsel, skulle der laves en funktion der let
kunne udregne distance mellem start- og slutpunkt.




Releaseplan


                                          ID    User story                              Impor.    Est
                                          1     Der skal udarbejdes funktionalitet      90        7
                                                til registrering af tid på controller
                                                logikken.
                                          2     Der skal laves en Web service,          80        1
1. Release               1. Sprint              som Interface for Controller
                                                logikken.
                                          3     Der skal være Login funktion med        70        5
                                                sikkerhed
                                          4     Der skal udarbejdes                     60        4
                                                brugergrænseflade til Browser
                                                applikationen.
                                          10    Start- og sluttiden skal kunne          55        0,25
                                                registreres med intervaller af et
                                                kvarter (Rettelse fra 1. sprint)
                                          5     Visning af tidligere                    50        2
                                                timeregistreringer.
2. Release               2. Sprint        6     Der skal udarbejdes                     40        4
                                                brugergrænseflade til Windows
                                                Phone.
                                          8     Sikring mod tab af data ved             30        5
                                                manglende netværksforbindelse
                                                på Windows Phone
                                          7     Beregning af kørsel fra start- til      20        7
                                                slutdestination, samt finde kunde
3. Release               3. Sprint              ud fra destination
                                          9     Der skal laves et WCF interface         10        1
                                                til systemet.




                                           Side 57 af 79
Malte Mortensen,                              Hovedopgave                                     18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

Efter endt udarbejdelse af 1. sprint, har releaseplanen forskudt sig. Ovenfor ses den nuværende
releaseplan efter rettelser deri. Som det ses på releaseplanen, har vi i 1. sprint nået en user story
mere end forventet, hvilket har resulteret i, at vi allerede efter 1. sprint har lavet 1. release. Grunden
til, at vi nåede mere end forventet, var fordi vores arbejdseffektivitet har været bedre end forventet.
Vi har derfor - som fortalt i ovenstående afsnit "Velocity" - rettet vores fokusfaktor. Derudover har
den gode arbejdseffektivitet resulteret i, at der bliver 3 releases i stedet for 2, da der kan laves en
release efter 2. sprint. 2. sprint indeholder kun 11,25 estimerede dage, hvor vi efter rettelse i vores
velocity har 17 dage til rådighed i dette sprint. Den efterfølgende user story er dog estimeret til 7
dage, hvilket vil resultere i 18,25 dage i 2. sprint, som er for meget. Hvis vi når mere end forventet
og har mulighed for, at tage denne user story ind i 2. sprint vil vi gøre dette. Grundet de 11
estimerede dage i sprintet, mod de 17 dage vi har til rådighed, vil vi have en stor buffer, hvis der
skulle opstå problemer under udviklingen - vi forventer derfor, at have features fra 2. sprint klar til
release til tiden.



Sprint Backlog (+ WBS og Estimering)




                                              Side 58 af 79
Malte Mortensen,                             Hovedopgave                                    18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

Ovenfor kan sprint backloggen for vores 2. sprint ses. Her har vi overført de højest prioriterede user
stories fra product backloggen, som endnu ikke er blevet implementeret. Der var plads til 4 user
stories, hvilket som sagt udgør 11,25 dages effektivt arbejde i alt, hvor vi har 17 dages effektivt
arbejde til rådighed. Vi tager ikke en user story mere ind, selvom der er 5,75 dages effektivt
arbejde, som ikke er udfyldt, fordi den næste user story fra product backloggen, er estimeret til 7
dages effektivt arbejde, hvilket ville give os 18,25 dages effektivt arbejde, som skal udføres i
sprintet, hvor velocity kun er sat til 17 dages effektivt arbejde. Vi vælger ikke at tage den ind, for
ikke at forpligte os til mere end vi kan nå, overfor kunden. Hvis vi bliver færdige med alle 4 user
stories inden sprintet er afsluttet, kan vi vælge at dele den højest prioriterede user story fra product
backloggen, op i to mindre user stories, og overføre den højest prioriterede af disse to til sprint
backloggen. Dette vil vi gøre i samarbejde med product owner, fordi prioriteterne vil blive bestemt
af kunden.

I sprint backloggen har vi brudt user stories ned i mindre tasks, hvor det har været muligt. I dette
tilfælde er det kun ved ID 5, det har været relevant at bryde ned til flere tasks. Efter der er lavet
tasks, for alle user stories, estimerer teamet disse tasks i timer. Ved ID 6, hvor der skal
implementeres en brugergrænsefalde til Windows Phone 7, har vi taget højde for, at der skal laves
prototyper, som også skal testes, hvilket er medregnet i de 4 dage denne user story er estimeret til.




                                             Side 59 af 79
Malte Mortensen,                                          Hovedopgave                          18-01-2012
Niklas Nøhr                                                 JCD A/S
DM70

Burndown Chart

                                            Burndown Chart - 2. Sprint
                               16
                               14
   Estimeret arbejde tilbage




                               12
                               10
            (Dage)




                                8
                                6
                                4
                                2
                                0
                                    0   1     2   3   4        5          6   7   8   9   10
                                                          Dage i sprint



Ovenfor har vi udarbejdet burndown chart for 2. sprint. Som det ses har vi 17 dage til rådighed i
sprintet, men vi har kun taget 11,25 dage ind, da det passer med de forskellige user stories. Den
ideelle tid for udviklingen er den blå streg. Vi formoder, at vi vil ligge under denne streg hele vejen
igennem, samt blive færdige nogle dage før sprintets afslutning, da sprintet ikke er fyldt ud med
user stories. Hvis vi fortsætter arbejdseffektiviteten fra 1. sprint vil vi dog tage næste user story ind
hvis det er muligt. I slutningen af 2. sprint vil vi gennemgå burndownchartet for 2. sprint igen, hvor
vi vil se på hvordan det faktisk er gået i løbet af sprintet og derved finde frem til, om vi skal rette
vores velocity til 3. sprint.




                                                          Side 60 af 79
Malte Mortensen,                           Hovedopgave                                18-01-2012
Niklas Nøhr                                  JCD A/S
DM70

Udvikling af 2. sprint

Prototypes - Mockups




Figur 3

På ovenstående mockup (Figur 3), har vi opstillet hvordan vi forventer "Arbejds/Time Log" skal se
ud. Denne side er som den anden holdt meget enkelt og vi har overholdt gestaltlovene med henblik
på brugervenlighed. Siden vil indeholde visning af timeregistreringer indenfor en bestemt
tidsperiode, som man selv angiver. Til denne mockup havde vores testperson ingen bemærkninger,
da han synes den var meget enkel og virkede let at bruge.




                                           Side 61 af 79
Malte Mortensen,                            Hovedopgave                                   18-01-2012
Niklas Nøhr                                   JCD A/S
DM70




Udover figur 3, har vi også udarbejdet ovenstående mockups, som illustrerer hvordan vi vurderer, at
timeregistrering på Windows Phone 7 vil se ud. Som i browser applikationen har vi været
opmærksomme på, at opfylde gestaltlovene med henblik på, at udarbejde et brugervenligt system.
Loven om nærhed har vi opfyldt ved, at placere ting der hører sammen tæt på hinanden, dette ses
bl.a. på siden hvor man søger på en sag og sagerne derefter skal vises i boksen nedenunder. Loven
om lukkethed har vi benyttet ved, at opdele timeregistreringen på flere sider, således at det man har
på hver enkel side hører sammen. Sidst har vi også benyttet loven om lighed, som bl.a. ses på siden
med sager og undersager. På denne side søger man som tidligere omtalt på en sag, hvorefter sagerne
kommer ud i boksen nedenunder søgeboksen. Det samme foregår når man skal søge i en undersag,
som derved skaber lighed på siden, hvilket ikke forstyrrer brugerens syn.




                                            Side 62 af 79
Malte Mortensen,                                Hovedopgave                                       18-01-2012
Niklas Nøhr                                       JCD A/S
DM70

Som ved 1. sprint har vi også i dette sprint valgt, at lave en tænke højt test. Denne tænke højt test
har vi udarbejdet i samarbejde med Dynamics Nav konsulent, Steffen Andersen fra JCD A/S, som
repræsenterer målgruppen. Overordnet set synes Steffen, at de udarbejdede mockups ser fornuftige
ud, men han havde samtidig nogle områder vi skulle have fokus på ved udvikling af
brugergrænsefladen. Dette drejer sig om, at han ønsker, at kunne se hvis der er et hul i
timeregistreringen i løbet af dagen (hvis man har glemt at skrive noget ind) - dette er ikke noget
JCDs timeregistrering i Dynamics Nav kan, men det er noget han mener kunne være brugbart.
Derudover ønskede han, at det skulle være nemt, at finde de timeregistreringer som var startet, men
endnu ikke afsluttet. Der var også andre mindre områder, som han fremhævede som vigtige i
udarbejdelsen af brugergrænsefladen - det er derfor også områder vi vil have fokus på i
udarbejdelsen. Normalt ville vi lave en ny user story med disse rettelser, men da vi allerede inden
udviklingen får ønskerne fra testpersonen, kan vi vurdere om det vil have påvirkning på vores
estimater. Vi forventer ikke, at ovenstående ønsker fra testpersonen vil have påvirkning på vores
estimater og vælger derfor ikke, at lave en ekstra user story.

Ud fra tænke højt testen har vi fundet ud af, at de udarbejdede mockups tilfredsstiller en person fra
målgruppen. Derudover har vi fundet ud af, hvilke områder vi skal have fokus på under
udarbejdelsen af brugergrænsefladen - det er vigtigt for JCD, at systemet er så enkelt som muligt,
samt at det kun indeholder de mest nødvendige elementer fra timeregistreringen i Dynamics Nav.



Planlægning af 2. sprint (Ekstra story)
Efter udarbejdelse af de forskellige user stories i 2. sprint, har vi stadig 5,75 dages arbejde tilbage i
sprintet, hvilket er 1,25 dage for lidt i forhold til, at tage den sidste user story ind i 2. sprint. Vi har i
samarbejde med kunden vurderet, om vi skulle dele den næste user story op i 2 dele, således vi kan
implementere noget fra denne user story. Vi er nået frem til, at dele den op, således vi får en ekstra
user story ind i 2. sprint - denne user story går ud på, at vi skal kunne beregne afstand fra startpunkt
til slutpunkt, når man skal på kundebesøg. Nedenfor ses sprint backloggen, hvor vi har taget den
ekstra user story ind i 2. sprint - dette har medvirket, at vi nu har 14,75 dages arbejde i burndown
chartet.




                                                Side 63 af 79
Malte Mortensen,                             Hovedopgave                                     18-01-2012
Niklas Nøhr                                    JCD A/S
DM70




Vores velocity er uændret, da vores effektivitet har været som forventet. Vi arbejder derfor stadig
med en fokusfaktor på 85%. Under retrospective vil vi evaluere på teamets velocity og evt. lave
justeringer, hvis dette er nødvendigt.

I forbindelse med, at vi har taget en ekstra story ind i 2. sprint, har dette også ændret releaseplanen.
Planen for 2. sprint var, at lave 2. release efter ID 8 i releaseplanen, men dette er der midlertidig
blevet lavet om på, da vi har taget den ekstra user story ind i sprintet. Som det ses nedenfor laver vi
derfor release efter ID 7.




                                            ID    User story                            Impor.    Est
                                            1     Registrering af tid (Controller       90        7
                                                  logik)
1. Release                   1. Sprint      2     Web service (Interface til            80        1
                                                  Controller logik)
                                            3     Login funktion – sikkerhed            70        5
                                            4     Interface (Browser)                   60        4
                                            10    Start- og sluttiden skal kunne        55        0,25
                                                  registreres med intervaller af et
                                                  kvarter (Rettelse fra 1. sprint)
                                            5     Vis tidligere tidsregistreringer      50        2
2. Release                   2. Sprint      6     Interface (Windows Phone)             40        4
                                            8     Manglende netværksforbindelse         30        5
                                                  ved Windows Phone
                                            7     Beregning af kørsel fra start- til    20        3,5
                                                  slutdestination
                                            11    Finde kunde ud fra destination        15        3,5
3. Release                   3. Sprint
                                            9     WCF                                   10        1



                                             Side 64 af 79
Malte Mortensen,                                       Hovedopgave                                        18-01-2012
Niklas Nøhr                                              JCD A/S
DM70

2.Sprint (Ekstra story)
Prototype - Mockup
Nedenfor har vi udarbejdet mockup for denne user story omkring afstandsmåling fra startpunkt til
slutpunkt ved kørsel. Under udarbejdelsen af brugergrænsefladen har vi igen gjort os overvejelser i
forhold til gestaltlovene, for at gøre det så brugervenligt som muligt.




Til denne mockup har vi udarbejdet en tænke højt test i samarbejde med Thomas Søndergaard -
Udviklingschef hos JCD A/S. Thomas var tilfreds med mockup'en og fandt den enkel og
brugervenlig. Han tilføjede et ønske til hvordan det skulle fungere ved brug. Antallet af kilometer
den findes ud fra ruten skal afrundes til hele tal, således der ikke står 78,65 km. f.eks., men i stedet
79 km.. Derudover havde han ingen bemærkninger.



Kodedokumentation
Under dette punkt har vi opstillet kodedokumentation for, hvordan vi udregner afstanden mellem
startpunkt og slutpunkt vha. telefonens GPS funktion. Vi har benyttet en rute Web Service11 fra
"Bing Maps", som ligger tilgængelig på Internettet, derpå ligger der en metode til at udregne
afstanden mellem 2 punkter. Vi kunne også have valgt en web service fra Google eller lignende,
men vi har valgt "Bing Maps", fordi det er Microsoft, som tilbyder denne, og derfor er der god
dokumentation til denne på MSDN, hvilket hjælper meget under implementeringen. Nedenfor har vi
opstillet metoden der sætter startpunktet, vi vil herunder beskrive hvad der sker i metoden.


11
     Link til web service: http://dev.virtualearth.net/webservices/v1/routeservice/routeservice.svc/mex


                                                        Side 65 af 79
Malte Mortensen,                            Hovedopgave                                   18-01-2012
Niklas Nøhr                                   JCD A/S
DM70

Det første der sker er, at vi benytter en GeoCoordinateWatcher klasse. Denne såkaldte watcher
starter vi, hvorefter vi finder ud af hvor man befinder sig. Derefter sætter man "Pushpin", som er et
punkt man kan sætte på skærmbilledet, lig med lokationen man befinder sig på. Herefter stoppes
den såkaldte watcher igen. Man sætter bagefter nogle indstillinger for skærmbilledet, hvor man
starter med at sætte et punkt, hvor pin/startpunktet er parameteret. Derudover bestemmes det, at
lokationen skal centreres på skærmbilledet, hvorefter man zoomer ind på lokationen. Da man først
skal bruge startpunktet igen når man angiver slutpunktet vælger vi, at gemme startpunktet lokalt på
telefonen indtil da. Dette gør vi vha. en XmlWriter, hvor vi laver en IsolatedStorageFile, som sættes
lig med en Xml fil som bliver oprettet (GeoCoStart.xml). Derefter serialiserer vi indholdet vha.
XmlSerializer og skriver det ind i Xml filen vha. XmlWriter. Indholdet man serialiserer er
XmlWriter og startpunktet.




Nedenfor har vi opstillet metoden til, at udregne ruten vha. et slutpunkt. De første 10 linjer er som
ved foregående metode, hvor punktet man er placeret på angives. Herefter pakker man den tidligere
gemte Xml fil ud igen - denne indeholder startpunktet. I forhold til foregående metode henter denne
metode i stedet Xml filen ind og deserialiserer filen, således den får startpunktet ud. Efterfølgende
sættes en bingKey, som er en udvikler kode hos bing maps. Man laver et request for, at angive


                                            Side 66 af 79
Malte Mortensen,                          Hovedopgave                                  18-01-2012
Niklas Nøhr                                 JCD A/S
DM70

bingKey. Derefter oprettes en ObservableCollection, som skal indeholde Waypoints - disse
waypoints er det valgte startpunkt og slutpunkt, hvorfra man henter latitude og longitude. Man
tilføjer wp1 (startpunkt) og wp2 (slutpunkt) til den collection man har oprettet med waypoints.
Waypoints collection sættes derefter lig med waypoints på klassen RouteRequest. Derefter benyttes
metoden CalculateRoute på klassen RouteServiceClient - på denne metode laves der en
eventhandler. Denne eventhandler opretter en ny metode hvori man udregner distancen, man laver
samtidig et asynkron kald på Web Servicen, hvor request tages med som parameter.




Nedenstående metode, er metoden der oprettes ved, at lave en eventhandler. I metoden benytter
man e.Result til, at finde distancen på ruten. e.Result hentes ud fra det asynkrone kald man laver
med request som parameter. Afslutningsvis skrives kørslen i en MessageBox og distancen i
interface sættes til distancen.




                                           Side 67 af 79
Malte Mortensen,                              Hovedopgave                                      18-01-2012
Niklas Nøhr                                     JCD A/S
DM70




2. Sprint review

Sprint review
Under 2. sprint har vi implementeret de 4 user stories, som vi planlagde på vores sprint planning
meeting, samt én ekstra user story, som vi tilføjede sprintet løbende, fordi vi var færdige med de
første 4 user stories, nogle dage inden sprintet var planlagt til at blive afsluttet. Herefter holdte vi et
sprint review meeting, hvor vi fremviste de user stories, der var blevet implementeret i løbet af
sprintet, for product owner. Vi holdte denne fremvisning på et forretningsmæssigt niveau, uden at
gå for meget ned i tekniske detaljer. Her lavede vi også en acceptance test i samarbejde med product
owner, hvor vi gennemgik acceptance test kriterierne fra product backloggen, for de
implementerede user stories. Product owner testede selv produktet og var meget tilfreds med den
funktionalitet, der var blevet implementeret under sprintet, og godkendte derfor resultatet af
sprintet. Product owner havde nogle få kommentarer, og feedback til Windows Phone 7 interfacen,
hvilket vil medføre nogle mindre ændringer i denne brugergrænseflade. Product owner ønskede at
der skulle være mulighed for, at brugeren kan gemme sit username, på login siden. Derudover var
der også ønsker om, at hvis man søger på en sag, hvor der kun er ét resultat, skal denne sag vælges
automatisk.

Da vi ikke når det 3. sprint under dette projektforløb, vil vi i slutningen af dette sprint implementere
de ønskede ændringer. Dette er mod Scrums regler, som siger, at der ikke må tilføjes noget når man
er i gang med et sprint. Kunden ønsker dog, at have den færdige version færdig hurtigst muligt, og
vi har derfor valgt, at implementere det i slutningen af dette sprint. Normalt ville vi have tilføjet
rettelserne som en ny user story i product backloggen og implementeret rettelserne, som det første i
efterfølgende sprint.




                                               Side 68 af 79
Malte Mortensen,                                          Hovedopgave                            18-01-2012
Niklas Nøhr                                                 JCD A/S
DM70

Sprint retrospective
I 2. sprint planlagde vi, at implementere de 4 højest prioriterede user stroies, som var tilbage i vores
product backlog. Disse 4 user stories havde vi estimeret til 11,25 dages effektivt arbejde, hvor
sprintet maksimalt kunne indeholde 17 dages effektivt arbejde. Vi valgte ikke, at tilføje flere user
stories til sprintet, fordi den næste user story fra product backloggen, var estimeret til 7 dages
effektivt arbejde, hvilket ville overskride antallet af dage vi havde til rådighed i sprintet.

I løbet af sprintets første 6 dage, blev vi færdige med at implementere de 4 user stroies, vi havde
planlagt at udføre i dette sprint. Vi valgte derfor at inddrage én ekstra user story i dette sprint, fordi
der stadigvæk var 4 dage til rådighed. Den højest prioriterede user story fra product backloggen,
som endnu ikke var implementeret, havde vi estimeret til 7 dages effektivt arbejde, hvilket var for
meget, da vi kun havde 8 * 0,85 = 6,8 dages effektivt arbejde til rådighed, og vi vil være sikre på at
kunne levere det, vi aftaler med kunden. Derfor valgte vi i samarbejde med kunden, at dele denne
user story op i to, hvor vi estimerede begge til 3,5 dages effektivt arbejde, mens kunden derefter
prioriterede dem. Vi tog den højest prioriterede af disse to user stories, og overførte denne til
sprintet. Som det ses på burndown chartet nedenfor, har vi indsat den ekstra user story efter 6 dage,
hvilket giver 3,5 dages arbejde tilbage. Dette arbejde blev færdiggjort på 8. dagen og vi brugte
derfor kun 2 dage på at implementere den ekstra story.


                                            Burndown Chart - 2. Sprint
                               16
                               14
   Estimeret arbejde tilbage




                               12
                               10
            (Dage)




                                8
                                6
                                4
                                2
                                0
                                    0   1     2   3   4        5          6   7   8   9    10
                                                          Dage i sprint




                                                          Side 69 af 79
Malte Mortensen,                              Hovedopgave                                     18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

I dette sprint nåede vi i alt, at implementere 5 user stories, som var estimeret til 14,75 dages
effektivt arbejde. Dette gjorde vi på 8 dage, hvilket giver os en fokus faktor på 14,75 / 16 = 0,9. Vi
synes sprintet er forløbet godt, og vi har arbejdet meget effektivt, da vores forventede fokus faktor,
var på 0,85. For et kommende sprint kunne vi overveje at justere fokus faktoren til 0,9, hvilket ville
give os en velocity på 18 dages effektivt arbejde i sprintet.

På mange områder har vi haft den samme arbejdsgang, som ved 1. sprint. Udviklingen har igen
under dette sprint forløbet godt, da vi ikke er stødt på de store problemer og har fået løst dem hurtigt
når de er opstået. Vi har overvejet de forskellige beslutninger i sprintet nøje, således vi har fundet
frem til den bedst mulige løsning.

Vi har under dette sprint ikke benyttet os af aspekter fra UP, da vi ikke har arbejdet med meget
komplekse metoder og derfor ikke har haft brug for dokumentation som ved 1. sprint. I stedet har vi
igen benyttet spike fra XP, som vi også benyttede i 1. sprint. Spiket har igen hjulpet os til, at få
overblik over en user story, hvilket gav os et godt udgangspunkt inden vi begyndte på den givne
user story.



Deployment
Som ved 1. sprint bliver der efter dette sprint også lavet en release af features for dette sprint, til
JCD. Vi har samtidig lavet de sidste rettelser fra 1. sprint, hvilket gør produktet fra 1. sprint færdigt.
Som ved 1. sprint har JCD også nogle få rettelser til 2. sprint, hvilket gør, at features fra 2. sprint
ikke er fuldkommen færdigt endnu, men alligevel kan benyttes. Produktet vil kunne benyttes på
intern test server af JCD. Vi har på nuværende tidspunkt udført 2 releases til JCD, som de vil kunne
benytte.



Opfølgning på risikoanalyse
Under dette sprint havde vi, som ved det foregående sprint, også et område der var risiko ved. Dette
område var GPS Funktionen, som vi ikke havde arbejdet med før og derfor ikke vidste hvordan vi
skulle håndtere. Under planlægningen til dette sprint udarbejdede vi derfor et spike, for at
undersøge, hvordan vi skulle håndtere opgaven med, at benytte GPS funktionen. Efter endt arbejde
med sprintet kan vi konkludere, at vi har fjernet risikoen ved GPS funktionen. Dette skyldes i store
træk, at vi udarbejdede et spike, som gav os viden om, hvordan det skulle håndteres, inden vi



                                              Side 70 af 79
Malte Mortensen,                           Hovedopgave                      18-01-2012
Niklas Nøhr                                  JCD A/S
DM70

begyndte programmeringen. Derudover kan det nævnes, at de andre risikoområder, som vi
mindskede i 1. sprint, endnu ikke har voldt os problemer.




                                           Side 71 af 79
Malte Mortensen,                              Hovedopgave                                     18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

Konklusion
Virksomheden JCD A/S havde et ønske om en timeregistrerings funktionalitet til deres nuværende
Dynamics Nav løsning, som skulle være tilgængelig fra flere forskellige platforme, hvilket vi fik til
opgave at udvikle. I denne forbindelse ønskes der et system med løs kobling imellem
brugergrænsefladen og forretningslogikken, så brugergrænsefladen nemt kan udskiftes senere. Dette
har haft en stor indflydelse på, hvordan systemets arkitektur er blevet udformet. Med henblik på
brugergrænseflade til dette system, har vores opgave været, at udvikle brugergrænseflade til en
Windows Phone 7, og en Silverlight browser applikation - i begge tilfælde for, at gøre
timeregistreringssystemet mere mobilt.

Vi valgte, at benytte projektplanlægningsmetoden Scrum, til at løse denne opgave. Vi kom frem til,
at denne metode var passende til udførslen af projektet, ved brug af Boehm and Turner's Rader
chart. Dette chart bruges til, at vurdere projektet ud fra nogle forskellige parametre, hvor man
derefter kan konkludere, om det er mest passende, at arbejde efter en agil eller traditionel metode.
Vi besluttede ikke at benytte en ScrumMaster, da vi ikke mener det er nødvendigt, når vi kun er 2
personer, som udvikler på projektet. I sammenhængen med Scrum har vi også valgt, at benytte
aspekter fra især UP, men også XP.

Under planlægningen af projektet startede vi med at lave en product backlog i samarbejde med
kunden, hvilket er udgangspunktet i Scrum. I forbindelse med planlægningen af projektet, gjorde vi
nogle overvejelser i forbindelse med systemets arkitektur, hvor der var nogle bestemte krav fra
kunden. Her ønskede kunden en løs kobling imellem brugergrænseflade og forretningslogik. Dette
løste vi ved at opbygge systemet efter en 3-lags arkitektur, hvor vi placerede forretningslogikken på
en web service, som kan tilgås fra flere forskellige klienter. Dette gør systemet meget fleksibelt, så
der let kan tilføjes en ny brugergrænseflade. Der skulle også tages hensyn til sikkerhed, da der
bliver brugt en Dynamics Nav web service, hvor det kræves, at brugeren angiver brugernavn og
password. Det er planen, at der skal benyttes en https forbindelse når der logges ind, og herefter får
klienten en token, som bruges hver gang der skal kaldes metoder som bruger Dynamics Nav web
servicen. På nuværende tidspunkt er det dog kun en http forbindelse der benyttes, da systemet ligger
på en test server.

I projektets første sprint planlagde vi, at udvikle de første 3 user stories fra product backloggen,
men vi nåede at blive færdige med disse 3 user stories, inden sprintet var afsluttet, derfor tog vi én
ekstra user story ind i sprintet, som vi også nåede at udføre. Dette fik os til, at justere vores velocity


                                              Side 72 af 79
Malte Mortensen,                                 Hovedopgave                                  18-01-2012
Niklas Nøhr                                        JCD A/S
DM70

op, da vi arbejdede hurtigere end forventet. I første sprint lavede vi en domænemodel, for at give et
overblik over systemets klasser, da vi mente dette var nødvendigt, ud fra systemets kompleksitet.
Herefter valgte vi også, at lave et interaktionsdiagram, for systemets mest komplekse metode
"Oprettelse af en timeregistrering", for bedre at kunne overskue, hvilke klasser der skulle involveres
i denne metode. Disse aspekter fra UP har givet os et godt udgangspunkt i forhold til projektet, da
det har hjulpet os i forhold til planlægningen og udviklingen af projektet.

I 2. sprint havde vi planlagt, at implementere de 4 højest prioriterede user stories, som var tilbage i
product backloggen. Vi blev allerede færdige med, at implementere disse 4 user stories i løbet af de
første 6 dage i sprintet. Vi kunne derfor også nå, at udvikle én ekstra user story i dette sprint.

Efter afslutningen på 2. sprint, var der 2 user stories tilbage i product backloggen, som stadig ikke
var implementeret. Da vi ikke har nok tid, til at lave et 3. sprint, vil disse 2 user stories ikke blive
implementeret, hvilket vi har informeret kunden om. Disse 2 user stories var de lavest prioriterede i
product backloggen, derfor kunne kunden godt acceptere, at de ikke ville blive implementeret på
nuværende tidspunkt. Efter projektets afslutning kan de sidste user stories udarbejdes, således
systemet kommer til at indeholde alle funktioner og product backloggen bliver færdiggjort.

Vi udførte et sprint review med acceptance test efter hvert sprint. Kunden var meget tilfreds med
resultatet af begge sprints, men havde lidt feedback, i form af ønsker om nogle små justeringer til
systemet, hvilket vi fik rettet efterfølgende.

Vi lavede en risikoanalyse i forbindelse med planlægningen af projektet. Her betragtede vi vores
estimeringer som en risiko, fordi vi ikke har særlig meget erfaring med estimering. Dette blev dog
ikke noget problem, da vi nåede at implementere, det som vi forventede i de 2 sprints vi udførte. Vi
så også vores forventede velocity som en risikofaktor, da vi endnu ikke havde udført et sprint, og
derfor var usikre på, hvor præcis den ville være. Dette ville dog kun være aktuelt i vores først sprint.
Efter det første sprint erfarede vi, at have ramt rigtigt med vores velocity, men valgte dog at justere
den lidt op, da vi havde nået mere end forventet i første sprint. Derudover håndterede vi også
"Forbindelse til Dynamics Nav web service" og "GPS Funktion" som en risiko, da dette var ukendte
områder for os. Her valgte vi at håndtere risikofaktorerne ved, at lave spikes for begge disse, for at
få mere viden om disse områder.

Spikes har vi udarbejdet i planlægningen af 1. og 2. sprint, hvilket har givet os et godt indblik i,
hvordan nye teknologier skulle håndteres. Dette har resulteret i, at de såkaldte spikes ikke har voldt


                                                 Side 73 af 79
Malte Mortensen,                               Hovedopgave                                  18-01-2012
Niklas Nøhr                                      JCD A/S
DM70

os problemer under udviklingen af projektet. Når man kigger tilbage på projektet, kunne det have
været mere hensigtsmæssigt, at udvikle begge spikes fra start, inden sprints begyndte. Hvis vi ikke
havde fundet den fornødne teknologi til et spike, ville vi have fået problemer, da vi først ville finde
ud af det inde i et sprint og derved havde fortalt kunden, hvornår de kunne forvente produktet
færdigt. Hvis vi i stedet havde udarbejdet spikes i planlægningen, inden de forskellige sprint, ville
vi kunne informere kunden, hvis vi ikke kunne finde den fornødne teknologi. I fremtiden vil vi gøre
det på denne måde i stedet.

Overordnet set mener vi, at der er kommet et godt resultat ud af vores projekt, da vi har udviklet et
timeregistreringssystem, som fungerer sammen med Dynamics Nav, og som kunden ønsker at
benytte. Kunden har vist sig, at være tilfreds, hvilket vi også selv er efter projektets udfald. Vi har
fået udarbejdet en løsning, som på mange måder ligner kundens Dynamics Nav løsning, hvilket de
prioriterede højt. Den udarbejdede løsning er en "skrabet" model af kundens Dynamics Nav
løsning, da man ikke har brug for alle funktioner i browser og Windows Phone applikationerne.
Vores problemformulering indeholder en række udfordringer, samt krav fra kundens side. Vi er
kommet frem til en god løsning i forhold til problemformuleringen, som opfylder alle de opstillede
krav, og dette har resulteret i et tilfredsstillende system.

En udtalelse fra JCD A/S, om det udarbejdede system, kan læses efter afsnittet "Læring".




                                               Side 74 af 79
Malte Mortensen,                             Hovedopgave                                     18-01-2012
Niklas Nøhr                                    JCD A/S
DM70


Læring
For at få et overblik over hvordan projektforløbet er gået, vil vi under dette punkt komme ind på,
hvordan projektet er forløbet, samt hvordan vores udbytte har været, teknisk og mht. arbejdsgangen
i en virksomhed.

Samarbejdet under projektforløbet har fungeret godt, vi har begge ydet vores bedste, og har begge
deltaget ligeligt i arbejdsdagene. Vi har under projektet siddet og arbejdet hos JCD, hvilket har
givet os gode muligheder for, at komme i kontakt med virksomheden ved spørgsmål.
Arbejdsfordelingen mellem os har været ligelig, og vi har begge arbejdet med IT-Forundersøgelse,
projektplanlægningen og programmering af systemet - vi har derfor fået mest muligt ud af alle
områder. Derudover har vi vurderet de forskellige områder, således vi begge var enige om, hvad der
skulle skrives.

Det har været en del anderledes, at arbejde på et projekt i virksomheden i forhold til de normale
projekter på studiet. Dette skyldes, at vi ved dette projekt hele tiden har kunne holde kontakt med
virksomheden omkring hvilke krav de ønsker til systemet, samt hvordan de ønsker, at systemet skal
se ud - der har været en product owner i virksomheden. Opgaven vi blev stillet, var samtidig noget
virksomheden ønsker at benytte, og vi blev derfor stillet et virkeligt problem, som man ikke er vant
til fra tidligere projekter. Vi føler, at arbejdet med et virkeligt problem har været interessant, da man
ved, at man skal have produktet færdigt til den tid man har lovet, da man arbejder for en "rigtig"
kunde. Samspillet mellem teamet/os og kunden, har samtidig været interessant at prøve, da man
finder ud af, hvordan et virkeligt projekt forløber, når man skal udarbejde noget for en kunde.
Scrum har fungeret godt som planlægningsmetode under projektet, og bidraget til projektets succes.
Scrum har været godt til at håndtere krav i løbet af projektet, og givet projektforløbet en struktur, så
arbejdet er blevet organiseret bedre, og vi er endt ud med et brugbart system.

Teknisk set har vi lært meget nyt under dette projekt. Vi har arbejdet med Silverlight og Silverlight
til Windows Phone, hvilket vi aldrig havde arbejdet med før. Det har derfor løbende givet os en del
problemer, men vha. opstilling af spikes og grundig research, har vi kunne finde løsninger på de
forskellige områder hvor der var problemer. Derudover har vi også arbejdet med virksomhedens
Dynamics Nav, hvor vi har arbejdet med kommunikation dertil. Dette krævede også en del
forudgående arbejde, men vha. et udarbejdet spike dertil, var opgaven lettere, at gå til.




                                              Side 75 af 79
Malte Mortensen,                              Hovedopgave                                      18-01-2012
Niklas Nøhr                                     JCD A/S
DM70

Vi har under projektet fulgt medarbejdernes arbejdstider, og har derfor arbejdet fra 08:00-16:30.
Dette har været godt, da vi har kunne få udarbejdet meget i løbet af dagen. Vi har derfor ikke været
presset mod slutningen af projektet, da vi har arbejdet hårdt og fået lavet meget fra start. I forhold til
vores tidsplan, har vi fulgt denne godt, men vi har samtidig arbejdet mere effektivt end forventet,
hvilket har resulteret i, at de forskellige sprints er blevet udarbejdet hurtigere end forventet.

Overordnet set har projektforløbet været meget lærerigt, hvor det har været interessant, at arbejde
med en rigtig opgave fra en virksomhed, samt arbejde med nye teknikker indenfor programmering.
Vi har dermed haft stort udbytte af dette projekt med henblik på IT Forundersøgelse,
projektplanlægning, samt nye programmeringsteknikker.




                                              Side 76 af 79
Malte Mortensen,                             Hovedopgave                                      18-01-2012
Niklas Nøhr                                    JCD A/S
DM70

Udtalelse fra JCD A/S
Nedenfor en udtalelse fra kunden, omkring det udarbejdede system:

I forbindelse med en kommende opgradering af JCD A/S’ egen Microsoft Dynamics NAV løsning,
opstod ønsket, fra konsulenternes side, om at kunne registrere arbejdstid hos kunder, uden at skulle
være fysisk tilstede på JCDs adresse.

Den seneste udgave af Microsoft Dynamics NAV kan sættes op til at udbyde såkaldte web services,
der over internettet, bl.a. kan give adgang til programmets indbyggede funktioner og database
tabeller. Der er dog tale om mere eller mindre rå adgang, hvilket vil sige, at der i tabeller kun er
kontrol af hvilken datatype (f.eks. heltal) der indsættes, og ikke af den specifikke værdi.

Da der er visse krav for hvordan konsulenterne skal registrere deres arbejde for kunderne, bl.a. at
tid skal regnes i hele kvarterer, at der skal påføres en kontaktperson hos kunden mm., opstod
opgaven om at lave en gateway, der opfylder alle disse krav, og samtidig kan udbygges til at tillade
adgang fra flere forskellige systemer. JCD A/S udvikler selv løsninger inden for mobile enheder
som f.eks. Android og Windows Phone, samt web, som derfor var oplagte kandidater at kunne lave
integration fra.

Vi føler, at hovedopgavegruppen har løst opgaven med fuld tilfredshed. Der er blevet udviklet en
gateway, som overholder de specificerede krav, og dertil udviklet en web-applikation, i Microsoft
Silverlight, og en applikation til Windows Phone, der begge kan benyttes til at registrere sin
arbejdstid på farten, enten via en internet browser eller mobiltelefon. Gatewayen er, som ønsket,
udviklet med henblik på skalérbarhed, så vi selv har mulighed for at udbygge funktionaliteten i
fremtiden, skulle det blive nødvendigt.

- Thomas Søndergaard & Bjarke Nielsen, Udviklingsafdelingen.




                                              Side 77 af 79
Malte Mortensen,                           Hovedopgave                                 18-01-2012
Niklas Nøhr                                  JCD A/S
DM70

Litteraturliste
Forfatter               Titel                          Forlag       Udgave Udgivelsesår    ISBN-NR.
Hans Kjær               Organisation                   Trojka       4.     2007            978-87-
Hans Jørgen Skriver                                                                        92098-02-
Erik Staunstrup                                                                            3
Henrik Kniberg          Scrum and XP from              InfoQ                               978-1-
                        Trenches – How we do                                               4303-
                        scrum                                                              2264-1
Craig Larman            Applying UML and               Prentice     3.      2004           0-13-
                        Patterns                       Hall PTR                            148906-2
Craig Larman            Agile and iterative            Addison      1.      2003           0-13-
                        development – A                Wesley                              111155-8
                        managers guide.
Barry Boehm             Balancing Agility and          Addison      1.      2003           03211861
Richard Turner          Discipline: A Guide for        Wesley                              25
                        the Perplexed
Rolf Molich             Brugervenligt webdesign        Ingeniøren   2.      2003           87571248
                                                       Bøger                               17
Hjemmesider
   - http://msdn.microsoft.com/
   - http://www.silverlight.net/
   - http://dev.virtualearth.net/webservices/v1/routeservice/routeservice.svc/mex (Web service til
       route)

   -   http://tortoisesvn.net/

   -   http://www.extremeprogramming.org

Andre
  - Jørgen Bønsdorff, Adm. Direktør, JCD A/S – IT Forundersøgelse
   -   Thomas Søndergaard & Bjarke Nielsen, JCD A/S – Forskellige opgaver
               Har fungeret som kunde til produktet
   -   Peter Linnet, JCD A/S – Dynamics Nav web service
   -   Steffen Andersen, JCD A/S - Testperson ved tænke højt test




                                            Side 78 af 79
Malte Mortensen,                           Hovedopgave                      18-01-2012
Niklas Nøhr                                  JCD A/S
DM70

System & CD
Den udarbejdede web applikation kan testes på timeregtest.jcdhotel.dk med nedenstående
login (Der kræves installation af Silverlight plug-in):

Username: nima-censor

Password: 4Rfv6Yhn




CD indeholder:

TimeRegHop: Web applikation

TimeRegHopWP7: Windows Phone Applikation




                                           Side 79 af 79

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:0
posted:1/29/2013
language:Norwegian
pages:79