Administrationssystem med Android applikation Driving Academy

Transkript

1 Dette er produktrapporten til Bacheloropgaven på University College Nordjylland, omhandlende udviklingen af et Administrationssystem til Driving Academy. Opgaven indeholder alt information og dokumentation vedrørende produktet til Bacheloropgaven. Administrationssystem med Android applikation Driving Academy Produktrapport Professionsbachelor i Softwareudvikling Lasse Abelsen, Rasmus Rudbæk Laursen & Alex Østergaard

2 Titelblad Projekttitel: Administrationssystem med Android applikation Driving Academy Project title: Development of an Administration System including an Android Widget Driving Academy Samarbejdsvirksomhed: Driving Academy ApS Kontaktperson: Margareth Supplerende kontaktperson: Morten Munk Jensen Vejleder: Peter Qvist Afleveringsdato: 14 januar 2011 Eksamensdato: 25 januar 2011 Baggrunden for vores rapport er, at køreskolen Driving Academy præsenterede os for nogle af de daglige problemstillinger, de stod overfor, og i samarbejde med dem valgte vi at fokusere på en løsning til at lette disse. Vores rapport indeholder dels en analyse af og dels forslag til løsning af disse specifikke problemstillinger. Hertil har vi lavet to applikationer. Vi har i C# udviklet et program til at administrere køreskolen. Herunder bl.a. kalender funktioner, time registreringer på elever samt mulighed for udskrift af faktura. Derudover har vi i Eclipse udviklet et seperat program der skal fungere sammen med deres android telefoner. University College T & B 14. januar 2011 Alex Østergaard Lasse Abelsen Rasmus R. Laursen Side 1 af 55

3 Forord Denne rapport omhandler vores Bachelor opgave fra Professionsbachelor i software udviklings uddannelsen på UCN Technology & Business. Opgaven er lavet i samarbejde med Driving Academy ApS i perioden imellem 22. november til 14. januar Vi har valgt at dele vores dokumentation op i to rapporter. Vi har en produktrapport samt en procesrapport. I produktrapporten finder man det, der omhandler vores produkt, ligesom det også er heri vi har skrevet om de konklusioner vi er kommet frem til under arbejdet med de to applikationer. I procesrapporten har vi inkluderet alt det, der har haft med selve processen af projektforløbet at gøre. Det vil sige: tidsplaner, metodevalg, mødedagsordener og dertil hørende referater samt dagbøger over de enkelte uger. Det er desuden også her vi har skrevet om de overvejelser vi har haft under forløbet og hvorfor vi har gjort som vi har. Denne opdeling af rapporten har vi valgt, da dette efter vores mening giver et godt overblik samt, at det gør det muligt at adskille relevant information omkring vores produkt, fra informationer omkring hvordan vi har arbejdet. Side 2 af 55

4 Indholdsfortegnelse Titelblad... 1 Forord Indledning Om Driving Academy ApS Driving Academys problem Projektets formål Afgrænsning Problemformulering Metodevalg Brug af praktikker Overordnet Arkitektur Begreber Produkt Komponenterne Administrationssystemet Kravspecifikation: Stories Komponent Arkitektur Design Implementation Test Kvalitetssikring Android Applikationen Kravspecifikation: Stories: Komponent Arkitektur Design: Implementation: Test: Kvalitetssikring: Sikkerhed Domænemodel Database Design Side 3 af 55

5 6.0 Konklusion Ændringsforslag Bilag Brugermanualer Brugermanual Administrationssystemet Brugermanual Android Widget Side 4 af 55

6 1.0 Indledning Om Driving Academy ApS Driving Academy blev lanceret i 2006 af SMC-Biler Aalborg. Tankerne var at skabe en køreskole, der var cool hele vejen igennem processen, at tage et kørekort. Eleverne skulle være i højsædet og oplevelsen skulle være den bedste kan kunne få. Den coolness køreskolen fik opbygget gennem teorilokalerne, bilerne, kørelærerne, markedsføringen etc. har givet stor aktivitet og succes allerede fra lanceringsdatoen faktisk lidt for meget succes. Køreskolen fik svært ved at følge med efterspørgslen, hvilket medførte at SMC-Biler i solgte 2008 køreskolen til Erik og Morten. Dette har gjort, at der nu er 100% fokus på køreskolen. Driving Academy har lært af sin fortid og det skal nu sikre bedre kommunikation alle led imellem, mindre fejl, flere tilfredse kunder. 1 Driving Academys fortid og ønske om at være byens cooleste køreskole er også det der driver at de ønsker at få udviklet et system, som kan lette dagligdagen for både deres ansatte og for deres elever Driving Academys problem Der er i øjeblikket ikke nogen former for IT-afdeling i virksomheden og det kommer der formentligt heller ikke i fremtiden. Det betyder samtidig at alle processerne i virksomheden foregår på gammeldags facon, dvs. Med papir og blyant. Når en elev skal have en tid til en køretime, så bliver det skrevet ned i kørelærerens kalender. Det betyder at når en elev glemmer sin time, så kontakter de kørelæreren via f.eks. SMS. Det betyder at alle kørelærerne bruger meget tid på denne opgave. Derudover, så er det daglige arbejde med at registrere afholdte timer for både en lærer og en elev, en stor byrde for alle i firmaet. 1 Side 5 af 55

7 1.0.3 Projektets formål Dette projekt har til fordel at hjælpe Driving Academy med deres daglige opgaver, dette vil vi hjælpe til med ved at lave to applikationer: En android applikation som kørelærerne kan benytte sig af når de er ude at køre Et Administrationssystem der kører via en klient som de kan bruge enten på kontoret eller når de sidder derhjemme. Denne skal køre op mod en server de har til at stå på kontoret. 1.1 Afgrænsning I forhold til de ønsker DA har haft, har vi været nødt til at afgrænse opgaven på visse områder. DA ville gerne at widget en blev udviklet til iphone da mange af kørelærerne havde netop iphones. Det ville dog kræve at vi køber Apple iphone Developer Program samt en SDK-licens. Alternativt har vi valgt at udvikle til Android, hvilket er muligt at gøre, helt gratis. Samtidig med prisforskellen på at udvikle til henholdsvis Android eller iphone vurderede vi også at det ville være hurtigere at starte med at udvikle til Android. Grunden til dette er at udviklingssproget er kendt fra start modsat hvis det havde været til iphone. Det har betydet noget da det er begrænset hvor meget tid vi har til udvikling af widget en pga. tidsrammen. DA har også haft ønske om at den samlede løsning skulle kunne kobles sammen med deres nuværende økonomisystem. Det vurderede vi fra start at vi ikke ville kunne nå, da de andre krav til løsningen er prioriteret højere, og en sådan opkobling vil tage lang tid at udvikle. 1.2 Problemformulering I samarbejde med Driving Academy (DA) har vi fået synlig gjort deres problemer samt de ønsker de har til systemet: Elevoprettelse og registrering af køretimer foregår udelukkende manuelt nu. Det vil DA gerne have ændret således at man både kan registrere via android, samt via klienter der kan ligge på deres computere på kontoret. Til ovenstående ønsker DA altså en Android applikation. Denne skal bruges af kørelærerne. o Formålet med denne applikation er at lette administrationsarbejdet gennem: Mulighed for oprettelse af aftaler over mobilen Elev database for lettere at kunne finde og kontakte elever Kalender Side 6 af 55

8 Kørelærer o o Oprettelse af aftaler med elever Overblik over alle kommende aftaler Central klient hvorfra man kan se status på de forskellige elevers fremskridt med kørekort (lægeattest, betaling osv.) Oprettelse af timeregistreringer til fakturering af elever Se status på kørelærer (Fri, ude at køre osv.) Ved prioritering af opgaverne stillet fra DAs side har vi valgt at fokusere på kalendersystemet, herunder registrering af hvornår og hvilke timer eleverne har haft og med hvilke lærere. Dette har vi valgt, fordi det stod klart fra DAs side, at de primært var interesserede i at få dette lavet, fordi arbejdsgangen nu er for kludret. 1.3 Metodevalg Vi har valgt at benytte SCRUM som udviklingsmetode, da den bedst understøtter projektet ud fra de overvejelser vi har foretaget os i procesrapporten under punktet metodevalg. Hvis man skal arbejde konsekvent efter SCRUM er man også nødt til at overholde de indskrevne praktikker som vi også har defineret i vores procesrapport under SCRUM praktikker. Vores overvejelser omkring valget af udviklingsmetode er beskrevet i procesrapporten. I det følgende afsnit har vi beskrevet hvorledes vi har valgt at bruge disse og andre praktikker Brug af praktikker Da scrum kun sætter rammerne for processen har vi også tilvalgt nogle praktikker fra andre udviklingsmetoder. Vi valgte at bruge Planning Game fra extreme Programming. Vi valgte denne praktik til da vi fandt det nødvendigt at have en idé om hvor længe de enkelte dele ville tage at udvikle. Både fordi vi skulle kunne planlægge sprints, men også for at vide hvad vi vil kunne forvente at nå af det hele. Tidsestimaterne indgik som base for vores burndowncharts. Og netop fordi vores tidsestimeringer blev lavet ud fra Planning Game (hvilket betyder at estimaterne er relative) vil vi meget hurtigt være i stand til at Side 7 af 55

9 se hvor vi står tidsmæssigt i forhold til hvor vi burde stå. Derudover valgte vi at printe alle userstories ud, og hænge dem op på væggen. Vi placerede dem under 3 overskrifter på væggen; To Do, In Progress og Done. Kombinationen af både burndowncharts og den visuelle visning af opgaverne gjorde det let at få et hurtigt overblik. Vi valgte også at gøre brug af et klasse diagram, som man kender det fra UP. Det valgte vi, fordi vi i tidligere projekter haft haft stor gavn af at have det med. Det giver et hurtigt overblik over systemet, og tager ikke lang tid at udvikle i forhold til hvor stor en hjælp til det er. Side 8 af 55

10 2.0 Overordnet Arkitektur I dette afsnit beskrives den overordnede arkitektur, som har været udgangspunktet for udviklingen af systemet til Driving Academy. I arkitekturen er der taget højde for de ønsker DA har haft i forhold til funktionalitet samt overvejelser af en mere teoretisk natur, i forbindelse med Professionsbachelor uddannelsen, herunder bl.a. skalering. Den overordnede arkitektur bygger på de valg som er foretaget i samarbejde med DA. Her blev de spurgt hvilke ønsker, krav og lignende de havde samt at de blev præsenteret for tre mulige strukturer for systemet, heriblandt hvilken hostingform de fandt optimal. Disse overvejelser kan læses i procesrapporten. REST webservice kald DA LAN Internet Mobilenhed Kørelærer WCF kald mod Server Firewall WCF kald mod Server Administrationspersonale Server WCF til Windows klient REST mod Android Server IIS WCF til benyttelse af server forretningslogik Administrationspersonale Service Database Da vi holdte det første møde med DA, før projektets påbegyndelse, undersøgte vi hvilke ønsker kunden havde til drift af systemet. Driving Academy er en køreskole og benytter stort set ikke IT til andet end løn og de har derfor ikke en IT-afdeling. Virksomheden besidder, i det hele taget, ingen eller meget begrænsede IT-evner. Side 9 af 55

11 DA ønskede som udgangspunkt, selv at hoste systemet, af hensyn til prisen. Vi kunne derfor se af systemet var nødt til at bestå af en simpel server-side løsning, som indeholdte alt forretningslogik, således at klienten ikke indeholdte avancerede konfigurationsmuligheder, blot en en-gangs opsætning mod serveren. Serveren skulle derfor også være en low-maintenance, service arkitektur og en færdig freeware database. Serveren skulle helst udelukkende indeholde en start, stop og genstart-funktionalitet som automatisk kunne starte når serveren blev genstartet. Dette lå op til en service-løsning, som blot skulle installeres på serveren. Denne service skal således indeholde og hoste alt kommunikation med klienterne. Et af de funktionalitets krav som blev stillet af Driving Academy var at systemet skulle kunne erstatte deres gammeldags kalendere, som kørelærerne benytter til at holde styr på deres aftaler. Der skulle således laves en applikation til en mobilplatform, som indeholdt en kalender samt mulighed for at tidsregistrere løn. Sammen med DA bestemte vi os for at lave en Android applikation. Valget faldt på en Android applikation, da dette var en mindre teknisk og økonomisk udfordring end alternativet (iphone). Årsagen til dette valg, skal findes i vores begrænsede tidshorisont på projektet samt at DA ikke ønskede at investere i en iphone udviklingslicens, før det stod klart hvorvidt systemet dækkede deres basale behov. Det betød at vi skulle have en service, som kunne hoste både multiple samtidige Windows klienter samt mulighed for at nå systemet fra Android. Efter at have undersøgt det på nettet, så det ud til at Android primært benytter sig af REST webservices. Google har valgt ikke at understøtte SOAP, så det begrænsede brugen af standard -webservices. Man kunne muligvis benytte et API skrevet af en 3. part, sådan at man kunne benytte SOAP-webservices. Dette API så dog ud til ikke længere at blive supporteret og opdateret, så vi valgte at hvis dette kunne lade sig gøre, så ville vi benytte REST-webservices. Disse havde derudover også indgået som en del af pensum på Professionsbachelor-uddannelsen, hvorfor det faldt naturligt for projektet. Windows Communication Foundation, WCF, tilbød os alle det funktionalitet vi ønskede. WCF gav os mulighed for at bruge services så der kunne udvikles en.net-remoting -agtig løsning til Windows klienten samt at WCF understøtter REST-webservices, således der kunne kommunikeres med begge typer klienter fra samme framework. Dertil kom det at vi vidste at både WCF-services og REST-services i WCF kan hostes på både NT Services og på IIS. Driving Academy fortalte hvordan de godt kunne tænke sig at Windows klienten også kunne benyttes over Internettet. Således at deres Administrationspersonale kunne benytte klienten som en hjemmearbejdsplads. Dette stiller selvfølgelig nogle krav til sikkerheden. Der skal derfor implementeres Side 10 af 55

12 certifikater på WCF-services, således at servicen kan være tilgængelig fra Internettet, men kun kan benyttes at de korrekte personer. WCF understøtter også brug af certifikater. Den overordnede arkitektur blev derfor således at en NT Service på serveren indeholder alt forretningslogik og styring af Sessions, Notifikationer og kommunikation med Databasen. Derudover kommunikerer denne NT Service med omverdenen via WCF Services, som den hoster i servicen. For lettest at kunne gøre serveren tilgængelig fra nettet kan IIS benyttes. Der udvikles en WCF-service, som er hostet på IIS og som kalder WCF-services på NT-servicen. Disse kald benytter igen certifikater til sikkerheden. Udover at denne løsning gør WCF-services let tilgængelige fra Internettet, så bevirker det også at det giver en øget mulighed for skalerbarhed, distribution af services på forskellige maskiner og fail-over -sikkerhed. Valget af sådan en løsning understøtter også en senere overgang til et større driftsmiljø, hvis DA beslutter at de ikke længere kan eller vil hoste deres egen server. Derudover kan man også forestille sig at systemet er så generelt at det kan benyttes af andre køreskoler, dermed er det parat til at man kan drifte flere køreskoler på det samme sted, så man dermed kunne opnå nogle stordriftsfordele. Fordelen ved den ovenstående arkitektur er at man kan splitte modtagelsen af kald fra de forskellige klienter ud på to eller flere IIS eller benytte én IIS og flere servere, f.eks. i forbindelse med drift af flere selskaber på samme servermiljø. Det betyder også at man kan lave swimlanes på forskellige kunder hvis man ønsker at skalere på denne akse Begreber WCF: Windows Communication Foundation, er et framework til at bygge service-orienterede applikationer. WCF er designet I overensstemmelse med SOA principperne for at gøre det muligt at gøre services tilgængelige for alle der kan bruge dem. En klient kan gøre brug af flere services, ligesom en service kan være tilgængelig for mange klienter. Vi har altså en samlig af service der er tilgængelige. Disse services kan kommunikere med hinanden. Denne kommunikation kan involvere enten simpel afsendelse af data, eller det kan være to eller flere services der går sammen om at koordinere en aktivitet. At bruge WCF giver derfor nogle fordele. Vi får en lav kobling mellem services og de applikationer vi laver der skal bruge dem. Derudover er det platform uafhængigt, dvs. De services vi laver på vores server kan bruges både af vores C# administrationssystem, men også af vores android applikation (ved hjælp af REST). Side 11 af 55

13 En anden fordel er at der er en høj ROI (return of investment), netop fordi det er muligt at genbruge de metoder vi har lavet. Sidste fordel er at det, pga. den lave kobling, er noget nemmere at lave parallel udvikling. I vores tilfælde har det betydet at vi alle tre har været i stand til at udvikle på serveren på samme tid, uden at det vi hver især lavede havde indflydelse på de andres arbejde. Til at uploade og dele koden har vi brugt SVN. Endpoints: En WCF Client forbinder til en WCF Service via et endpoint. Hver service vi har lavet skal derfor vise sin kontrakt via et endpoint. I vores projekt hedder den kontrakt: ProDriveWCF.IProDriveWCFService Denne refererer til vores ProDriveWCF projekt på serveren. Herunder har vi en klasse IProDriveWCFService, der gør alle vores metoder tilgængelige. Dette gøres, som det fremgår af billedet nedenunder, vha. En operationscontract. Her er det metoderne: createstudent, EditStudent samt GetAllStudents der bliver gjort tilgængelige. En klient kan således bruge disse services, det eneste der er brug for er at vide metode navnet (kontrakten). Der er således en meget lav kobling mellem vores klient og serveren. Et endpoint har desuden en adresse, hvilket er en URL der specificerer hvorfra endpointet kan tilgåes, i vores tilfælde har vi brugt localhost, eftersom vi ikke havde nogen server til rådighed, så vores adresse blev: Når den skal ligges op på en anden server, er adressen ovenover således det eneste der skal ændres. Deruder skal der være nogle binding properties, dette blev ved os: wshttpbinding: fordelen ved wshttpbinding er at data bliver sendt sikkert og i et encryptet format, mens eksempelvis BasicHttpBinding sender data i plain tekst(et XML dokument f.eks.). denne specificeres altså hvordan dataen bliver overført. Side 12 af 55

14 Ovenstående er endpointet der ligger på vores server. For at kunne tilgå disse services på vores klient er det eneste der er nødvendigt at gøre, at tilføje en Service Reference. Adressen til denne er den samme som den der står ovenover, når den tilføjes bliver alle de metoder der har en operationscontract tilgængelige. Dette fremgår også af ovenstående billed. Når vi vil bruge metoder fra serveren skal vi derfor blot bruge denne reference. Hvor efter vi, som vist ovenfor, kan bruge alle de services der, via en OperationContract, er blevet gjort tilgængelige. REST: Representational State Transfer. Går på HTTP, bruger addresser til at navigere med. Dette skal bruges til de forskellige funktioner der skal ligge på vores android applikation. Det fungerer ligesom internettet, bare som services man henter istedet for dokumenter, dvs at vi kan gøre de wcf services vi lavede på serveren tilgængelige, sådan et vi ikke skal til at lave de samme metoder to gange. Det vil samtidig også sige at vi skal give alting et ID. Kan eksempelvis referere til en kunde, men Side 13 af 55

15 den kunne også referere til en kollektion. Dettte kan ikke ses udfra addressen, det skal man vide. Eftersom vi har arbejdet med REST har vi kun haft mulighed for at bruge standard metoder: Get (request ressource) Post (create new ressource) Put (update eller create ressource) Delete (delete ressource) Vi må altså, fordi vi burger rest, nøjes med de ovenstående metoder. Men det betyder bare at en metode i C# måske hedder getstudentinfo, mens den med rest istedet bliver til et GET kald til et URI der itentificerer en student. Resultatet bliver det samme. WCF Rest Services: Er ligesom normale WCF Services, blot at der er tilføjet funktionalitet, således at de kan blive consumed på en RESTful måde (URI vs URL, brug af HTTP verber, brug af forskellige data transfer formater som eksempelvis JSON eller YAML). Fordelen ved dette er at vi dermed kan bruge vores services i Eclipse og dermed også i vores Android applikation. 2 MySql DB: Driving Academy har ikke nogen database I forvejen, eftersom alt bliver skrevet ned med papir og blyant. Vi har derfor lavet en MySql database fra bunden. Denne skal både lagre data fra android applikationen samt fra administrationssystemet. Det drejer sig om alt lige fra hver enkelt elev til deres aftaler i kalenderen. Det overordnede database design samt tables kan ses under afsnittet Domæne Model. IIS: Internet Information Services. IIS er Microsoft Webserver produkt. Det understøtter bl.a. ASP.Net og andre.net produkter op til.net v IIS følger med i alle serverprodukter samt i nogle privatprodukter. GUID: Globally Unique Identifier. En GUID er en 32 karakters hexadecimal string, som pga. den måde den bliver genereret bør være totalt unik og kun burde blive genereret én gang nogensinde. Det totale antal GUID er er , dette er sat i relation til at der eksisterer atomer på jorden. Udtrykket GUID omtaler oftest Microsofts inplementation af Universally Unique Identifier (UUID) Side 14 af 55

16 3.0 Produkt Komponenterne Dette afsnit indeholder dokumentationen til de to komponenter af vores samlede produkt. Vi har forsøgt at følge den samme skabelon for begge moduler. Dette har vi gjort for at forsøge at skabe et godt overblik. Dette får et vandfaldsagtig udseende, som ser sådan ud: Kravspecifikation Stories Komponent Arkitektur Design Implementation Test Kvalitetssikring Side 15 af 55

17 3.1 Administrationssystemet Administrationssystemets formål er at gøre det muligt for Driving Academys sekretær nemmere at skabe sig et overblik over timeregisteringer til f.eks. løn og dermed også til fakturaer for firmaet kunder. Som beskrevet tidligere havde Driving Academy nogle krav og ønsker, som vi har forsøgt at indarbejde i systemet. Administrationssystemet kan betragtes som rygraden i projektet og vil være absolut mission critical for Driving Academy efter en evt. implementation Kravspecifikation: En kravspecifikation er et dokument, som beskriver, hvilket krav det system man udvikler skal kunne leve op til, når det er færdigudviklet. En kravspecifikation skal derfor indeholde en beskrivelse af de krav og forventninger en kunde har til systemet. Kravspecifikationen kan i udgangspunktet opbygges på to måder. Den ene måde er, at kunder kommer med en liste med præcise krav for de funktioner systemet skal indeholde. For kunden giver det den fordel, at den ønskede ydelse kan defineres med relativ stor præcision. Den anden måde er, at kunden opstiller abstrakte funtionelle krav. Her beskriver kunden hvilke opgaver og funktioner, som kunden forventer systemet skal kunne være i stand til at løse og håndtere. Her lægges ansvaret for at den samlede ydelse løser kundens behov på leverandøren.4 I vores tilfælde har vi gjort brug af den anden mulighed. Dette har vi gjort fordi Driving Academy, grundet deres manglende IT-viden, ikke selv har været i stand til at formulere de krav de havde til systemet. Derfor har de beskrevet hvad de skal bruge systemet til, hvorefter vi har fået en snak om hvad vi mente ville være smart, nærmere beskrivelser om dette kan findes under vores møde referater i processrapporten. 4 Side 16 af 55

18 Vores kravspecifikation er altså lavet ud fra vores første møde med Driving Academy. Ud fra dette er vi derefter kommet frem til nedenstående funktioner systemet skal indeholde: Elevdatabase o Oversigt over elever, elevinformationer osv. Kalendermodul o Kalender for lærer og elever Tidsregistreringsdatabase o Mulighed for udtræk til løn o Mulighed for udtræk af timer til grundlag for fakturering Notifikationsfunktion o Notifikation af elever omkring timer og lignende Ovenstående kaldes også for de funktionelle krav. Derudover har vi også det der kaldes de ikke funktionelle krav Denne del af en kravspecifikation er generelle vejledninger til opgaven, som der ikke skal programmeres funktioner til. Dette kunne eksempelvis være grafiske retningslinjer, begrænsninger eller ikke-målbare krav til løsningens kvalitet. 5 De ikke funktionelle krav kan også deles op i to; Performance begrænsninger og projekt begrænsninger. Performance begrænsninger: Internettet: Projektet generelle arkitektur beskriver hvordan forskellige dele af projektet kan ligge i forskellige miljøer og dermed kan mange kald ske over internettet. Dette har nogle betydninger for performance da disse kald over internettet ofte er langsommere end kald til en lokalserver. Under projektforløbet er der blevet benyttet en distribueret database til vores test data. Ved overgangen fra en lokaldatabase til den distribuerede oplevede vi mere end en fordobling af svartiden på vores administrationssystem. WCF: Da WCF er et framework som tilbyder en lang række standard services, så betyder det at disse services dækker mange behov og der sendes derfor, ved hvert kald, en stor mænge information som har lille eller ingen betydning for administrationssystemet. Dette betyder at serveren kan håndtere færre servicekald på engang. 5 Side 17 af 55

19 Projekt begrænsninger: Vi er selvfølgelig også stødt ind i nogle begrænsninger for projektet. Disse har indflydelse for hvad produkt man får i sidste ende. De tre klassiske projektbegrænsninger er: Ressourcer: I vores tilfælde har det gældt at vi ikke har haft mulighed for at hente flere personer ind i projektet, eftersom vi er bundet fast på tre personer. Tid: Vi har fra starten af haft en deadline, denne har vi ikke kunne ændre på. Dette kan have indflydelse på den endelige kvalitet af et system. Kvalitet: Kvaliteten af ens system hænger også sammen med de to ovenstående. Men handler også om brugervenlighed (se afsnittet om ydre kvalitet) og kvaliteten af koden (se afsnittet om indre kvalitet) Stories Nedenstående viser alle de stories vi er kommet frem til vi mener administrationssystemet skal indeholde. Hver enkelt story er blevet estimeret alt efter hvor svær vi mener den er, hvorefter vi har vurderet hvor lang tid vi vil tro den tager at implementere. Story liste for administrationssystemet Backlog item Som en... Vil jeg... Sådan at... Estimate (1-10) Hvor 10 er sværest WCF 10??? Log-ind Bruger Kunne logge ind Så systemet ved 2 5 hvem jeg er Sende Keep-Alive signal til server Alle 8?? Køre en eller anden form for Session Alle Sende Keep- Alive signal til server Køre en eller anden form for Session Skal ligge en process bagved og logge en ud hvis man har været inaktiv for lang tid For at holde styr på proces og evt. smide brugeren af 10?? Tidsestimering i Timer Kunne se kørerlærers kalender Bruger Kunne se en kørerlærers Jeg ved hvornår en lærer er ude og 4 8 Side 18 af 55

20 Kunne se elevers kalender Bruger kalender Kunne se elevers/en elevs kalender Kunne søge på elever Bruger Kunne så på elever/en specifik elev Kunne opdatere kalendere for kørelærere og elever Bruger Have mulighed for at foretage opdatering både for lærere og elever Kunne register elever Bruger Kunne registrere en elev Kunne godkende elever modtaget fra hjemmeside Bruger Godkende de elever der selv har tilmeldt sig over hjemmesiden Kunne redigere elever Bruger Have mulighed for at redigere elev Kunne lave timeregistreringer Kunne udtrække timeregistreringer for en kørerlærer Bruger Bruger Kunne lave timeregistreringer Kunne udtrække timeregistreringer for en kørerlærer kører og hvornår han kan stå til rådighed/kan kontaktes Der er mulighed for at se en elevs køre/teori planer og hvor langt en person er i forløbet Der er mulighed for at se en elevs køre/teori planer og hvor langt en person er i forløbet Der kan foretages ændringer i en persons kalender Nye elever bliver tilføjet til databasen/systemet Systemet/databasen ikke bliver fyldt med elever der måske ikke er interreseret alligevel. En elev kan findes frem fra databasen og der kan laves ændringer, nyt tlf nummer eksempelvis En time registreres både for en elev og for læreren der har haft eleven/eleverne Som skal bruges som løngrundlag Kunne udtrække timeregistreringer for en elev Kunne udtrække timeregistreringer for en elev Kan se hvor langt en elev er i forløbet og som faktura grundlag hvis de eksempelvis har brug for ekstre timer 7 12 Side 19 af 55

21 Kunne udtrække fakturagrundlag til elever Bruger Kunne udtrække fakturagrundlag til elever Kunne se elevdatabase Bruger Kunne se elevdatabasen Kunne se elevinformationer Kunne se kørelærerinformationer Bruger Bruger Kunne se elevinformationer Kunne se information om en kørerlærer Man ud fra registeret forløb kan se hvor mange timer en elev har haft og på baggrund af det lave en faktura Få et overblik over alle elever/søge efter en specifik elev Finde information om en specifik elev, f.eks. tlf nummer eller adresse Man f.eks. kan komme i kontakt med personen I ALT Komponent Arkitektur Ud fra vores overordnede arkitektur har vi så lavet en arkitektur som skulle beskrive den enkelte komponent. Dette afsnit vil beskrive Administrationssystemet. ProDrive_WCF_IIS_ Site IIS ProDrive_REST_IIS_ Site Efter samtalen med Driving Academy før projekt start, virkede det som om en tynd Windows-klient ville være at foretrække. Årsagen til dette var at det virkede som en fordel at have alt forretningslogikken liggende centralt, når Android applikationen skulle implementeres. Så vidste vi at den overholdte de samme regler som Windowsklienten. Derfor tog den efterfølgende WCF Kald (lokalt eller over netværk) ProDriveRuntime Service (Hosts ProDriveWCF) ProDriveWCF (Uses ProDriveServer) NT Service Database Server ProDriveServer (Forretningslogik Bruger ProDriveModel) Database Side 20 af 55 ProDriveModel

22 arkitektur for Administrationssystemet udgangspunkt i dette. Valget faldt på at lade Administrations-systemet bestå af en server og en klient, som beskrevet i den overordnede arkitektur. Det gav mulighed for nemt at lave en REST webservice, som kunne benytte den eksisterende server via WCF. Ovenfor ses et diagram for de 3 komponenter som serveren skal bestå af. Først en Database Server, som i bund og grund bare gør sit arbejde. Herefter ses en Service, som indeholder alt forretnings logik samt en WCF-service, således den kan kontaktes fra både lokale- og netværksplaceringer. Denne service kan dermed også vedligeholdes uafhængigt af de efterfølgende IIS-sites. Pakken ProDriveServer, under Servicen, indeholder en klasse, som sørger for bl.a. vores Session af hensyn til sikkerheden. Derudover vedligeholder et par separate tråde, som står for bl.a. for automatiske log-af samt fundamentet til et notifikations modul, hvor elever modtager en mail eller SMS omkring begivenheder, som f.eks. glatbane. Servicesen er opbygget ud fra princippet om en 3-lagsarkitektur, med det mål at gøre det nemmere at vedligeholde. Derfor ses der også en ProDriveModel-pakke på diagrammet. IIS-sites eksisterer for at kunne gøre vores WCF-Service synlig mod nettet. Dette kunne man have gjort uden, men det kræver mere opsætning end blot at lade dem leve på IIS. Af de ovenstående IIS-Sites er det kun ProDrive_WCF_IIS_Site der har relevans for Administrationssystemet. På tegningen ses det også visuelt hvordan man blot tilføjer en REST webservice på IIS en, som benytter Servicen, så har man allerede implementeret mulighed for at en Android applikation kunne benytte den samme forretningslogik. Dette giver også mulighed for at man efterfølgende ville kunne implementerede en Webservice til en 3. slags klient, f.eks. en iphone applikation. Driving Academy har allerede i begyndelsen af projektet vist interesse for en iphone applikation frem for en Android, men pga. tekniske og licensmæssige bekymringer faldt valget på en Android applikation til at starte med. Det er derfor på heller ingen måde umuligt at DA skulle ønske at udvide løsningen på et senere tidspunkt. Side 21 af 55

23 3.1.4 Design Vi har i design fasen til administrationssystemet valgt at gøre brug af prototyper. De følgende principper kommer fra udviklingsmetoden Unified Process (UP), grunden til vi har valgt at låne herfra er, at vi tidligere har haft god erfaring med at bruge disse. Fra UP har vi derfor gjort brug af horisontale prototyper. Disse har vi brugt til at vise vores ide frem for Driving Academy, mht. til hvordan en brugergrænseflade kunne se ud samt høre deres mening og forslag til forbedringer. Men mest af alt har vi brugt horisontale prototyper til gavn for os selv når vi udviklede. Disse prototyper har været med til at give os et bedre overblik over de forskellige funktioner der skal implementeres. Figure 1 - Første Mock-Up Ovenstående prototyper har blot været dette, nemlig en prototyper. Den har været med til at fastlægge en overordnet opstilling for hvordan programmet skal se ud, grupperinger og hvad informationer og funktioner der skal være på de enkelte sider. Da vi viste ovenstående frem for Driving Academy var der endnu ikke lavet noget bagved liggende kode, eftersom vi endnu ikke var færdige med serveren. Men vi brugte den, som før nævnt, til at vise frem for Driving academy. Først gennemgik vi hele programmet, hvorefter de selv havde mulighed for at navigere rundt i programmet, nærmest som en form for accept test, hvorefter de forskellige ændringer / rettelser blev skrevet ned. Side 22 af 55

24 3.1.5 Implementation Selve koden er lavet i C#. I det følgende afsnit vil vi vise og forklare enkelte udvalgte kode snippets fra vores administrationssystem. I ovenstående laver vi en tab og en kalender for hver lærer der er registreret i databasen. Hver tab bliver navngivet med lærerens for- og efternavn, samtidig med at hver lærer for knyttet sin egen kalender til sig (DayView, dw). Selve kalendermodulet 6 er et stykke Open-Source kode, som implementerer en kalender der ligner den som findes i Outlook. Kalendermodulet tilbyder kun selve kalenderen og ikke nogle funktioner ved siden af, det vil sige at man er stand til at oprette en aftale med et tidspunkt og en beskrivelse, intet andet. Hvilket passer fantastisk med vores behov. Kalender er som beskrevet før Open-Source og er udgivet under The Code Project Open License (CPOL). 6 Side 23 af 55

25 Dernæst bestemmer vi hvor stor kalenderen skal være, hvad dato den skal starte på, samt hvor mange timer og dage den skal vise på en gang. Metoden bliver kørt i constructeren når vi åbner formen. Det er også her vi bruger vores service reference (ProDriveWCFServiceClient), til at kalde metoderne getallteachers samt getallteacherappointments på serveren. Appointments bliver tilføjet til den kalender/tab som hver enkel aftale hører til, dette bestemmes ud fra det teacherid der sendes med i metodehovedet Test I løbet af udarbejdelsen af dette projekt har overvejelserne omkring test ofte været diskuteret. Da test som udgangspunkt spiller en vigtig rolle i udarbejdelsen af større projekter, samt på Professionsbachelor uddannelsen. Vi har derfor været nødt til at vurdere hvorvidt det tid som et ordentligt testforløb ville tage, kunne forsvares i forhold til den tid og de ressourcer vi har haft til rådighed under dette projekt. Derudover har projektets størrelse og hvor kritisk det er for Driving Academy haft en betydning for vores beslutning. I denne overvejelse har hensynet til projektet og vores meget begrænsede tidsrum, som vi har til rådighed, vægtet tungere end behovet for test af projektet. Dermed har vi udelukkende valgt at bruge test, som f.eks. black-box, hvor vi har testet vores metoders input og output parametre samt accepttest, som vi afholdte sammen med Driving Academy. Vores brug af Accept Test kan findes i process rapporten, under afsnittet Vores brug af accept-test. Side 24 af 55

26 Man kunne have valgt en mere test-tung tilgang til projektet, men dette ville have betydet at vi skulle afsætte en stor del af vores, i forvejen begrænsede udviklingstid, til at teste. Dette ville have betydet at projektet måtte begrænses yderligere end det i forvejen er. Hvis denne tilgang til projektet var valgt, så ville vi kunne have lavet test, som f.eks. unit-test og lignende. Her var vurderingen at det ville tjene projektet bedre at vi bruge tiden på at udvide funktionaliteten. Derfor er der som udgangspunkt ikke noget test dokumentation i denne rapport Kvalitetssikring Kvalitetssikring er et vigtigt emne at have kontrol over i løbet af de fleste projekter. Det er det ligeledes også i vores projekt. Når nogle personer bruger store dele af deres arbejdsdag med de programmer der er udviklet er det også vigtigt at de har en god oplevelse med programmet. Dvs. alt lige fra hvordan brugergrænsefladen ser ud, til om det virker som det skal og man ikke hele tiden for frustrerende fejl meddelelser. Desuden skal programmet også helst være så brugervenligt som muligt. Sidst nævnte krav kalder vi også for de ydre kvalitetskrav Ydre Kvalitet Der er lagt stor vægt på den ydre kvalitet i dette system. Grunden til dette er at der i systemet er meget brugerinteraktion. Systemet skal fungere som erstatning for nogle af de daglige arbejdsgange, som førhen foregik med papir og blyant. Det betyder samtidig at systemet skal kunne bruges af folk der har knap så meget erfaring med computere. Dette har vi prøvet at tage højde for ved at bruge gestaltlovene. Gestaltlovene går ud på hvordan en bruger opfatter designet som en helhed, altså om brugeren kan se de forskellige elementer i designet, samt forstå og anvende dem. Gestaltlovene i grove træk 7 : Loven om nærhed: Symboler, der er anbragt nær hinanden, opfattes som hørende sammen. Loven om lighed: Symboler, der ligner hinanden, opfattes som hørende sammen. Loven om lukkethed: Symboler, der står i samme ramme, opfattes som hørende sammen. Loven om forbundethed: Symboler, der er forbundet, opfattes som hørende sammen. 7 Side 25 af 55

27 Vi har brugt gestalt lovene til at sikre at vi har et fornuftigt layout, som vi desugen også har fremvist for Driving Academy, hvor de så har haft mulighed for at komme med rettelser til placeringen af elementer og komme med forslag til ændringer i layoutet. Vi har opbygget modulet således, at de elementer som hænger naturligt sammen, fx elev informationer, er lukket inde med bokse, således at man kan se disse informationer skal opfattes som sammenhængende. I ovenstående eksempel kan man se hvordan vores layout over elever ser ud. Her kan man se at vi har valgt at lave en boks der hedder kørekort status, som indeholder en oversigt over hvad den valgtes elevs status er på de forskellige ting man skal igennem for at få kortet. Ved at gøre sådan sikrer vi os at loven om lukkethed overholdes. Gestaltloven om nærhed opnår vi på den måde, ved at de elementer som står tæt på hinanden hænger naturligt sammen. Kravlegård, førstehjælp, teoriprøve osv, hænger naturligt sammen da de indgår som væsentlige elementer i den samlede status på kørekortet Indre Kvalitet Kodestandard: Når det gælder kodestandard er det vigtigste man skal tænke på at man holder den samme standard gennem alt sit kode. Dette skal aftales på forhånd mellem alle folk der skal arbejde med projektet. En fælles kodestandard gør det nemmere for alle at udvikle systemet, derudover bliver udvidelser nemmere at gå i gang med, også for folk der kommer til udefra, hvis man hurtigt kan sætte sig ind i koden. I Side 26 af 55

28 I vores tilfælde har vi valgt at bruge camelcase notation til at navngive vores metoder. Vi har i øvrigt sørget for at attributter og metoder har sigende navne. Derudover har vi valgt at attributter har en _ foran navnet, (_attribut), for lettere at kunne genkende disse. Alle metoder skal desuden starte med stort ( MetodeNavn). Incremental design: Incremental design er et princip vi har lånt fra XP2. De agile metoder og i dette tilfælde XP og XP2 bruger generelt mindre tid til at dokumentere sig frem til en fornuftig Indre Kvalitet end de procesdrevne metoder. Her er det mere overladt til udviklerens evner at sørge for at den Indre Kvalitet er på plads. I XP2 er der en praktik der hedder incremental design, denne praktik går ud på at man invester i designet af systemet hver dag. XP teams sørger for at det ikke er dyrt at lave ændringer i softwaren. Man skal ikke lave den fejl at man laver story efter story uden tanke på design. Dette kan resultere i det koster kassen at foretage ændringer, samt man ender ud i et dårligt design og et system det er svært at foretage ændringer i. Vi har i dette projekt gjort stort brug af incremental design. Dvs. vi har implementeret en story af gangen og derefter testet om den virker som den skal inden vi gik i gang med næste. Side 27 af 55

29 3.2 Android Applikationen Kravspecifikation: Vores kravspecifikation er altså lavet ud fra vores første møde med Driving Academy. Ud fra dette er vi derefter kommet frem til nedenstående funktioner som Android applikationen skal indeholde: Adgang til Elevdatabase o Oversigt over elever, elevinformationer osv. Kalendermodul o Kalender for lærer og elever o Mulighed for at oprette aftaler mellem en lære og elev Oprettelse af Tidsregistrering o Mulighed for, ud fra en eksisterende aftale, at oprette en tidsregistrering Side 28 af 55

30 3.2.2 Stories: Nedenstående viser alle de stories vi er kommet frem til vi mener vores android widget skal indeholde. Hver enkelt story er blevet estimeret alt efter hvor svær vi mener den er, hvorefter vi har vurderet hvor lang tid vi vil tro den tager at implementere. Backlog for Android Widget Backlog item Som en... Vil jeg... Sådan at... Estimate (1-10) Hvor 10 er sværest Log-ind Bruger Kunne logge ind Så systemet Køre som baggrundsproces Sende Keep- Alive signal til server Køre en eller anden form for Session Kunne se egen kalender Kunne opdatere kalender Kunne se elevers kalender Kunne oprette aftaler på kalender Kunne konvertere en aftale om til en Alle Alle Alle Bruger Bruger Bruger Bruger Bruger Køre som baggrundsproces Sende Keep- Alive signal til server Køre en eller anden form for Session Have mulighed for at se min kalender. Have mulighed for at opdatere min kalender Kunne se en specifik elevs kalender Have mulighed for at oprette nye aftaler/tider for en elev Kunne konveretere en ved hvem jeg er Skal ligge en process bagved og logge en ud hvis man har været inaktiv for lang tid For at holde styr på proces og evt. smide brugeren af Man kan se hvilken bruger der er logget ind. Jeg kan få et overblik over hvornår jeg skal arbejde Jeg har mulighed for at tilpasse hvis der sker ændringer. Jeg kan se hvor mange timer en elev har og hvordan de er fordelt Systemet opdater og tilføjer den nye aftale til kalenderen Man efter en køretime med ?? ?? Tidsestimering i timer Side 29 af 55

31 timeregistrering aftale om til en timeregistrering det samme kan registrere at timen med en elev er slut Kunne lave en timeregistrering Kunne se Elevdatabase Kunne se Elevinformationer (navn, adresse, telefonnummer, mail) Kunne benytte telefonnummer, mail osv. til at kontakte elev Bruger Bruger Bruger Bruger Kunne lave en timeregistrering Kunne se elevdatabasen Kunne se elevinformationer Kunne benytte telefonnummer, mail osv. til at kontakte elev Der bliver registreret at der er blevet kørt en time og med hvilken elev Kan se en oversigt over alle elever Kan gå ind under en specifik elev og finde tlf nummer eller adresse frem eksempelvis. Når man har fundet en elevs information i elevdatabasen skal man ud fra de oplysninger kunne ringe/maile til personen I ALT 151 Side 30 af 55

32 3.2.3 Komponent Arkitektur Som udgangspunkt er der ikke udarbejdet voldsomme arkitekturovervejelser i forhold til opbygning af en Android applikation. Dette skyldes at pga. den måde som Administrationssystemet fungerer, så skal der ikke overvejes så meget i forhold til den generelle benyttelse af forretningslogik og lignende. De fleste overvejelser har derfor haft bund i hvilken form for netværkskommunikation der skulle benyttes, SOAP, REST og lignende samt hvordan dette skulle implementeres. Valget af REST som webservice type er foretaget ud fra de oplysninger vi kunne indsamle. Vi brugte i starten af projektet noget Spike-tid på at undersøge de teknologier der skulle benyttes. Her var Android selvfølgelig en af dem og det generelle resultat der forelå efterfølgende var at; Android vil allerhelst benytte REST webservices. SOAP webservices kan benyttes men under udviklingen af Android har Google ikke ønsket at SOAP skulle være den fremherskende webservicetype og derfor er implementationen af SOAP også mindre gennemarbejdet end på REST. Derfor faldt valget i dette projekt også på REST, da valget af at forsøge og implementere SOAP ville betyde en ekstra usikkerhed i vores tidsplan. I forbindelse med at valget faldt på REST som webservicetype undersøgte vi også teknologier som kunne understøtte serveren. Her faldt valget på WCF da dette også tilbød REST webservices. Det gjorde det muligt, som det også er beskrevet i Komponent Arkitekturen til Administrationssystemet, at udvikle RESTwebservicen som en slags Add-on til det eksisterende kode. Dermed skar vi også ned i det nødvendige antal timer til kommunikationen mellem Android og Serveren. Dette understøttede også vores valg af REST Design: Vi har til denne applikation, som før nævnt, gjort rigtig meget brug af Spikes. Dette har vi været nødsaget til eftersom meget af det vi har arbejdet med, som nævnt ovenfor, har været noget vi ikke har haft kendskab til i forvejen, og vi har derfor startet fra bunden af. Det har betydet at vi har brugt meget tid på at finde ud af hvordan en android applikation er bygget og hvordan man eksempelvis laver en bruger grænseflade deri. Vi har lavet vores layout ud fra de krav vi, sammen med Driving Academy, kom frem til at vores android program skulle indeholde. Overordnet skal det kunne tre ting: Elev oversigt: Herinde skal man kunne søge på elever og finde oplysninger om dem. Adresse og telefon nummer eksempelvis. Side 31 af 55

33 Kalender: En oversigt over de forskellige aftaler en lærer har i løbet af dagen/ugen. Samt mulighed for at se hvornår den næste aftale finder sted, samt med hvilken elev/elever. Ny Aftale: Mulighed for at søge efter en elev, vælge tid og dato samt hvilken time det drejer sig om og derefter oprette aftalen. Ud fra de krav kom vi frem til at den bedste løsning ville være at bruge et tab-layout. Overvejelserne omkring designet og prototyping kan læses i afsnittet Brug af mock-ups og prototyping i procesrapporten. Som det fremgår af ovenstående billede har vi som sagt valgt et tablayout. Dette består af to tabs der hver især indeholder to af de funktioner der står ovenfor. Den sidste, ny aftale ligger under kalender tabben, hvor der skal trykkes på Aftaler. Databasen til denne applikation er den samme som vi også bruger til vores administrationssystem, denne tilgår vi når vi, via REST, kører en service på serveren. Side 32 af 55

34 3.2.5 Implementation: Selve koden er lavet i JAVA. I det følgende afsnit vil vi vise og forklare enkelte udvalgte kode snippets fra vores Android applikation. Måden hvorpå projektet er bygget op kan ses oven over. Dette er standarden når man opretter et nyt android projekt. Alle vores layouts ligger i layout folderen, dette er XML opbyggede filer vi så kan referere til i vores klasser. I vores scr folder har vi så de forskellige klasser. MainActivity klassen extendes så den bliver til en tabactivity. Main klassen indeholder så de forskellige klasser der skal tilhøre en tab. Elev tab hører til elevactivity klassen eksempelvis. Under elevactivity klassen er der en reference til elevlayout xml filen, som bygger vores layout. Androidmanifest.xml filen indeholder de nødvendige konfigurations informationer der skal bruges for at installere programmet på en telefon. Herunder klasse navne og typer af events en applikation kan køre, samt de forskellige krav en applikation har før den kan køre. Hvis en applikation eksempelvis kræver adgang til netværket, skal dette skrives ind i manifest filen. Java klasserne der kan ses i billedet ovenfor skal alle bruges i forbindelse med vores tab layout. Hver tab knyttes til en aktivitet, ligesom hvert klasses layout som sagt ligger under layout mappen. Side 33 af 55

35 Vores main klasse sætter hver af disse tabs (aktiviteter) op med en overskrift og et ikon. Vi laver først en reference til vore Tabhost via gettabhost(). For hver tab skal der laves en TabHost.TabSpec for at definere de properties der skal være til den givne tab. newtabspec metoden laver en ny TabHost.TabSpec, der idetificeres ved den givne string, elever eksempelvis. For hver ny tab der laves skal der kaldes setindicator, hvori vi først har hvad en tab skal hedde og derefter et billede, dette billede skal ligge i vores drawable mappe. setcontent sættes til intent, for at vi åbner den rigtige aktivitet. Til sidst addes tabben til vores tabhost Side 34 af 55

36 3.2.6 Test: Vi har ikke fået foretaget unit tests på vores android applikation. Den beslutning er taget ud fra et prioriteringsmæssigt synspunkt, hvor vi i stedet har valgt at opprioritere funktionaliteten selvom vi ved det kan gå ud over kvaliteten af systemet. Vi har dog stadig testet hver enkelt funktion manuelt for at se om den virker efter formålet. Dette er gjort efter hver gang vi er blevet færdig med en funktion/story. Når vi er sikre på at en funktion virker og den sender/modtager data korrekt, kan vi gå videre til den næste. Derudover har vi foretaget Accept-tests med Driving Academy, nærmere beskrivelse af dette kan findes i processrapporten under afsnittet: Vores brug af Accept-test Kvalitetssikring: Der er, ligesom med administrationssystemet, meget brugerinteraktion i vores android applikation. Hvis systemet skal fungere kræver det at kørelærerne registrere samtlige timer. Dette gøres nemmest fra deres telefoner, eftersom de kan bruge dem overalt, men de har dog også mulighed for at vente til de kommer hjem/tilbage på kontoret og så gøre det via klienten istedet. Det er derfor nødvendigt med datadisciplin fra alle medarbejdernes side. Dette betyder selvfølgeligt også at den indre kvalitet skal være i orden og timerne rent faktisk bliver registreret, hvad enten det er via android eller pc. Ligeledes skal den ydre kvalitet også være i orden, således at det er nemt, selv for uerfarne brugere, at bruge de forskellige funktioner Ydre Kvalitet: Vi har så vidt muligt sørget for at overholde gestaltlovene (gestaltlovene er uddybet nærmere i administrationssystem afsnittet om indre kvalitet) for at sikre os et fornuftigt layout, som vi også har fremvist til Driving Academy som har haft mulighed for at komme med rettelser til placeringen af elementer og komme med rettelser og ændringer til dette. Side 35 af 55

37 De gestaltlove vi har gjort brug af er loven om nærhed. På billedet ovenfor kommer det til udtryk ved at knapperne ok og clear er placeret ved siden af hinanden, samt lige under hvor de har relevans, nemlig ved søgefeltet hvor man indtaster elevens navn. Derudover har vi overholdt loven om lukkethed ved at adskille de forskellige funktioner fra hinanden vha. Tabs Indre Kvalitet: Det er, som tidligere nævnt, vigtigt at den indre kvalitet er i orden for android programmet. Eftersom det er essensielt for hele systemet at aftaler bliver oprettet og registreret rigtigt. For at overholde den indre kvalitet i android applikationen har vi været nødsaget til at gå andre veje end ved tidligere projekter, og administrationssystemet, hvor vi kun har arbejdet med C#. Med C# har vi haft en kodestandard og arkitektur som er gået igen gennem de fleste projekter vi har lavet. Med denne applikation har vi som sagt arbejdet med android i eclipse og er derfor startet fra scratch. Når det gælder kodestandaren har vi dog ladet os inspirere af tidligere C# projekter. Dvs. at vi har gjort meget ud af at give vores variabler sigende navne. Ligeledes har vi gjort brug af camelcase notation, denne notation går ud på at hvis en variabel består af flere ord skal det andet ord skrives med stort startbogstav, således at det er nemmere at læse, eksempelvis kunne der være en variabel der hed postnummer. På denne måde behøves man ikke sammensætte ordene med en bindestreg og man kan desuden ikke bruge mellemrum. Opbygningen af programmet kan ses under afsnittet implementation. Fordelen ved denne opbygning er, at vores user interface er adskilt i et lag bestående af xml filer. Mens alle vores klasser er samlet i et andet lag. Side 36 af 55

38 3.3 Sikkerhed Dette afsnit vil gennemgå de foranstaltninger vi har lavet for at sikre at udelukkende Driving Academys ansatte kan få adgang til deres data. Vi har gennemgået dette, da det data som DA skal bruge systemet til er absolut Mission Critical data. Det vil sige at de data der ligger i system er yderst kritiske for virksomhedens daglige drift. Hvis f.eks. en ubuden gæst fik adgang til systemet, så ville personen i princippet kunne se alle aftale DA har, hvilke aftaler de har haft, hvad deres kørerlærer har fået i løn osv. Det er derfor yderst vigtigt at vi sikre at udelukkende personer med et formål i systemet kan benytte det. Vi har derfor valgt at benytte nogle af de funktioner, som allerede var til rådighed for os i forbindelse med at vi havde valgt WCF til kommunikationen imellem klienterne og serveren. WCF giver mulighed for at benytte certifikater, både på WCF-services samt på en REST-webservice. At gøre brug af disse certifikater sikre at klienten samt serveren er hvem de giver sig ud for. Dertil har vi så krypteret de afsendte beskeder med TripleDes-algoritmen. Dette er også implementeret direkte i WCF. Derudover har vi selv lavet to løsninger. Dette er et standard Usernavn/Password -løsning samt en form for en Session implementation. Username/Password -delen er hvad navnet antyder et username og et password, som indtastes i klienterne for at kunne logge ind. Passwordet bliver krypteret til det der hedder SHA256, da denne algoritme er stor nok til ikke at kunne brydes og dermed opsætte passwordet tilbage til tekst. Sammen med krypteringen af trafikken bør dette beskytte brugeren mod at blive afluret digitalt. Session-delen af vores sikkerhed er vores implementation af en Session, som kører så længe en bruger er logget på. Session har så en udløbstid på 15 minutter, som sikre at hvis man forlader computeren uden at logge af, så sker dette automatisk. Sessionen returnerer også en GUID, som er et unikt id som repræsenterer en session. Dette id skal sendes med ved alle kald til serveren, fra begge klienter, dermed er man også sikker på at et kald kun kan ske forudsat en person er logget ind. Dermed sikre man sammenlagt at, ingen kan se hvilke kald der bliver foretaget, kald kan kun ske fra klienter med certifikatet iorden, en bruger skal logge ind for at bekræfte hvem han er og en kald skal komme fra en aktuelt aktiv person. Til sidst, så er serveren og klienten gjort klar til at man kan lave endnu en Authorization -løsning, da der allerede nu er implementeret en slags roller på hver bruger, som kan bruges til at begrænse adgange til funktioner, når man er logget ind. Side 37 af 55

39 4.0 Domænemodel Denne domænemodel er dækkende for de to moduler vi har lavet, det vil sige vi ser her domænemodellen for: Android applikationen lavet i Eclipse Administrationssystemet lavet i C# Appointment er den centrale klasse i vores model. En appointment skal have tilknyttet både en elev/elever samt en eller flere lærere. Derudover skal den være registreret i de forskellige læreres kalender, således at man kan gå ind og se appointments for de forskellige elever, men samtidig også for den enkelte kørelærer så man kan se hvornår personen er optaget. Appointment er desuden tilknyttet tidsregistrerings klassen. Når en køre- eller teoritime er færdig skal det registreres i systemet at timen har fundet sted, både så der er styr på hvor langt en elev er i forløbet, men også fordi det danner løngrundlag for en kørerlærer hvor meget han har arbejdet. Derudover skal en appoinment være tilknyttet en service. Når en elev er tilknyttet en appointment og denne efterfølgende bliver registreret, kan man således se hvilke timer en elev har haft. Dette skal bruges fordi en elev for et vist antal timer når vedkommende køber pakken til kørekort. Hvis en elev har brug for flere timer, eller dumper en af prøverne, skal vedkommende betale for de ekstra timer der skal bruges frem mod næste prøve. En prøve skal derfor være knyttet til en specifik elev. Denne skal indeholde information om en prøve: Hvor, hvornår osv. Samt om prøven er bestået eller dumpet og hvilken elev det gælder for. Side 38 af 55

40 Kontakt Information Person PersonKartotek 1..* 1 0..* 1 Kørelære Elev Prøve 1 1..* HoldKartotek 1 0..* 1..* 0..* Hold 1..* * 0..* 1 1 Elev Status * 1..* 0..* Appointment Kalender Tidsregistrering * 1..* 1..* KøretekniskAnlæg Service Køretime Glatbane Kravlegård Teori Mørkekørsel Motorvej Side 39 af 55

41 Hold og Personkartotek klasserne skal begge bruges til at holde styr på henholdsvis de forskellige hold der er igang, samt de personer der er knyttet til disse. Til Person klassen er der desuden lavet en klasse der hedder kontakt information, denne indeholder alle de kontakt informationer der er til en elev eller lærer. Grunden til at vi har lavet en seperat klasse, istedet for at ligge det på person klassen, er at det skal være muligt for en person at have mere end et tlf nummer eksempelvis, og dermed have flere kontakt tabeller i databasen tilknyttet den samme person. Den abstrakte Person-klasse generaliserer en elev eller en kørelærer såldes at vi er nødt til at betragte en person, som enten en elev eller en kørelære, men ellers kan de begge stå i stedet for en person. Således at man kan hente en person og returnere både elever kørelærer-instanser. Det samme gælder for services-klassen, denne generaliserer for alle de forskellige typer af services som der kan knyttes til en appointment. Det gælder: Køreteknisk anlæg o Herunder hører også glatbane og kravlegård Køretime o Herunder hører også mørkekørsel samt motorvej Teori timer Kalender klassen er, sammen med appointment klassen, den vigtigste klasse i systemet, det er den der danner grundlag for løn, timeregistreringer samt planlægning af alle de forskellige timer og prøver. Kalender klassen skal bruges til at registrere alle elevers køre og teori timer, samt hvilke kørelærere der er knyttet til hver af disse. Side 40 af 55

42 5.0 Database Design Driving Academy havde, som tidligere nævnt, ingen database i forvejen. Det har betydet at vi ikke har skulle tilpasse det vi har lavet til en eksisterende database. Tilgengæld har vi så været nød til at lave en ny database helt fra bunden af. Et ER-Diagram(Entity-Relationship Model) er en abstrakt og conceptuel repræsentation af data. Entityrelationship modeling er en database modelerings metode, ofte brugt til at lave et conceptuelt skema af et system, i vores tilfælde er det af vores relationelle database. Vores ER-Diagram indeholder alt lige fra de forskellige tabeller til deres relationer til hinanden. Vores tabeller indeholder nøgler til hver enkelt tabel samt deres parametre. Mellem tabellerne er der en forbindingslinie som forbinder tabellerne med hinanden. Vores to applikationer endte med at blive så store at den tilsvarende database havde så mange tables at vi mente det ville være bedst hvis vi lavede et ER-Diagram. Dette lavede vi for at give et bedre overblik. Vi har undervejs måtte foretage ændringer i selve databasen, i forhold til første ER-Diagram. Dette har hovedsageligt været tilføjelse af nye tabeller, men derudover også tilføjelse af attributter og ændringer af relationer tabeller imellem. Nedenstående viser vores endelige ER-Diagram både for både vores android widget, samt for administrationssystemet. Side 41 af 55

43 Side 42 af 55

44 Som man kan se af ovenstående er der, ligesom i domæne modellen, to helt centrale tabeller. Dette er appointment- samt studenttabellen. Student tabellen indeholder de standard informationer der hører til en elev, navn, addresse osv. Men derudover er tabellens primær nøgle (studentid) også tilføjet som fremmednøgle på fire andre tabeller: Student status tabellen: Når en student bliver oprettet bliver der samtidig oprettet en studentstatus tabel, dens værdier bliver som default bare sat til 0, undtagen aktiv der bliver sat til 1 (true). Denne tabel skal bruges til at registrere om eleven, der er tilknyttet tabellen, har gennemført de forskellige forløb der er i forbindelse med kørekortet. Proever: Det samme princip gælder her. Når eleven oprettes bliver der samtidig også lavet en prøve tabel der knyttes til eleven via studentid. Prøver tabellen indeholder info om de to prøver en elev skal til: teori og køreprøve, samt dato, beskrivelse og om prøven efterfølgende er bestået. ContactInformation: Denne bruges af både student og teachers. Det eneste den skal kunne er at registrere deres kontaktinformationer. Grunden til vi har lavet den som en seperat tabel, istedet for bare at smide de to attributter på hhv. Student- og teachertabelle, er at det skal være muligt at have mere end et tlf nummer/emal adresse. Sådan som vi har gjort det er der mulighed for at knytte så mange numre til en person som man har lyst til. Sidst har vi StudentAppointment: Denne er lavet fordi vi har fået en n:m relation mellem appointment og student tabellen og vi har derfor oprettet en tabel med fremmed nøgler der findes ud fra de berørte tabellers primær nøgle. (Samme princip gælder i øvrigt for teacherappointmentog classappointment tabellen) Den anden centrale tabel er som sagt appointment tabellen. Til en appointment kan der både være tilknyttet en elev, en klasse og en lærer. Disse relationer sker gennem student-, teacher- og classappointment tabellerne som vi nævnte før. Selve appointment tabellen indeholder start og slut tid på hvornår den foregår, samt en titel og en beskrivelse af hvad den går ud på. Appointment bruges ligeledes når der skal laves timetrack på timetrack tabellen, dette skal bruges til at registrere hvor mange timer hver enkelt kørelærer har kørt Appointment tabellen er desuden forbundet til Service tabellen (se billed længere nede) UserNamePassword tabellen bruges hver gang der logges ind på clienten. Hvis brugernavn og password stemmer overens med en række på tabellen bliver brugen logget ind. Side 43 af 55

45 Hvis det lykkes at logge ind for brugeren tildelt et autogeneret guid som bliver placeret på session tabellen. Rækken med dette guid indeholder desuden et bruger id, samt en boolean værdi der skal bruges til at se om den givne session stadig er igang (alive) eller er afsluttet. SessionCommunication indeholder Session tabellens primær nøgle som fremmednøgle samt en kommentar og tids attribut. Ovenfor ses vores service tabel, samt de tabeller der hører til denne. En appointment har en fremmed nøgle der refererer til service tabellens primær id. Service tabellen skal bruges hver gang der bliver lavet en ny appointment. Ideen er at man således kan se hvad type appointment det drejer sig om. Dette er nødvendigt at vide for hver enkelt elev, eftersom en person skal have et bestemt antal køre- og teoritimer, når en appointment bliver registretet tæller en eleves timer således op med den rigtige type service. Vi har her valgt at lave en tabel for hver enkelt undertype af en service. Dvs. At vi har en service som fungerer som en superklasse og så har vi eksempelvis teori tabellen, som så er en subklasse af service. Superklassens primær id er brugt som fremmed nøgle på subklasserne. Dette er den generelle, eller the nice way at gøre det på, det gør det nemmere at implementere i koden. Ulempen er vi får lidt ekstra joins på vores tabeller. Men vi mente dette ville være det smarteste. Alternativet ville nemlig have været eksempelvis at lave pull-up og altså samle det hele i en tabel, men dette ville føre til utrolig mange null værdier, specielt hvis der senere skal tilføjes ekstra attributter på enkelte af tabellerne. Vores måde at gøre det på gør det derfor også nemmere at udvide i designet senere. Side 44 af 55

46 6.0 Konklusion I perioden mellem d. 22. november 2010 og d. 14. januar 2011 har vi udarbejdet et projekt for Driving Academy (DA). DA har en meget papirtung administration og ønskede derfor en digitalisering af deres arbejdsgang. En digitalisering af deres arbejdsgang vil eliminere meget af det dobbeltarbejde der foregår. Istedet for at en kørelærer skriver timer ned på et stykke papir hver eneste gang han har haft en time og timer for eleven bliver noteret et andet sted, kunne vi samle det hele under et. På den måde kunne vi gøre deres arbejdsgange mere effektiv og spare DA for meget arbejde. Samtidig har DA været nødt til at bruge tid på elever der ringer ind fordi de ikke ved hvornår de skal møde, og ikke kan se det nogen steder. Gennem dialog med DA, og forslag fra vores side, fandt vi frem til en løsning på deres problem. Resultatet har været et tredelt system der består af: Servermodul Windows klient Android applikation Formålet med at have et system, der er delt op på den måde, er dels for at understøtte back-up, samt mulighed for et administrationssystem for DA s administration og en publicering af visse data for kørelærer såvel som elever. Af sikkerhedsmæssige og økonomiske grunde valgte DA en selvhostet løsning med off-site back-up, hvilket betyder at de vil have data liggende lokalt på en server og samtidig en backup server på nettet. Dette sparer den månedlige udgift til et hostingfirma samt at det stadig sikre data mod at forsvinde, f.eks. ved indbrud. Formålet med den Windows klient som skulle være den centrale del af Administrationssystemet, var at man skulle kunne se statussen på elever med hensyn til deres kørekort, økonomi og kalender. Formålet med dette var at reorganisere arbejdsgangene hos DA. Det har vi opnået ved at lave en klient-server løsning som er tilgængelig både på lokalt netværk samt over Internettet. Dermed opnår de en høj tilgængelighed og gør det nemt og bekvemt at opdatere kalendere og lignende. Side 45 af 55

47 Android widget en blev en android widget fremfor en iphone applikation, da hverken vi eller DA fandt det fornuftigt at skulle betale for licenser at udvikle en iphone applikation, som måske ikke ville komme i brug alligevel. Denne overvejelse faldt allerede på plads i løbet af det første møde med DA. Android widget en havde det formål at give kørelærerne adgang til deres egen og elevernes kalender fra bilen. Dette er opnået ved at benytte Open-Source kalenderen AnCal (Android Calendar) samt ved hjælp af en REST-webservice i Servermodulet. Sikkerheden omkring kommunikationen mellem de to klienter og serveren, bliver håndteret med certifikater, således at udelukkende mobiler, og maskiner med klienten, samt med det korrekte certifikat kan forsøge at logge ind. Derefter får klienten udleveret en Session med en GUID, som skal indsendes ved alle kald til serveren. Certifikatet og session GUID en ser vi som værende tilstrækkeligt til at sikre at udelukkende autoriserede personer får adgang til deres services og dermed oplysninger. Vi valgte at arbejde efter SCRUM fordi det passede godt til projektet, og vi gerne selv ville styre mængden af dokumentation. Vi valgte at inddrage praktikker fra andre udviklingsmetoder såsom at lave et klasse diagram som man kender det fra UP. Side 46 af 55

48 7.0 Ændringsforslag En åbenlys ændring eller tilføjelse nærmere, vil være at udvikle widget en til iphone også. Dette vil øge tilgængeligheden for både kørelærer og elever. Havde vi haft tiden, eller ressourcerne, ville dette være en del af den fuldstændige løsning, eftersom mange af kørelærerne har netop iphones. Det har vi dog været nødt til at vælge fra (Se evt. afsnit 1.1 Afgrænsning ). Eftersom Android Widget en allerede er udviklet, er det rimeligt at antage, at det vil være hurtigere at udvikle iphone applikationen, da designet er på plads, samt databasesiden også er udviklet. Den eneste forskel, hvis vi skulle udvikle den, vil være at vi naturligvis vil være nødt til at lære kodesproget for iphones, Objective C eller COCOA. Jævnfør mødet d havde DA en række ønsker til systemet, efter at have set den foreløbige version. Disse ønsker lød således: Elevkalender: o Man skal kunne se hvem der er kørelærer for eleven o Kommentarfelt På elevoversigten manglede et punkt om hvorvidt en elev havde kørt køreteknisk Hvis der i en kalender post nævnes en anden person skal man kunne klikke sig ind på personen fra posten Administration af kørelærer tilføjes (Opret/slet/opdater) Klasser skal kaldes hold Mærke på timer om hvorvidt der er faktureret løn for dem Automatisk afsendelse mail (Til elever når de skulle møde og til kørelærer at de skal huske at registrere deres timer) På elever såvel som kørelærer skal der være et link der åbner Outlook med det samme for at kunne afsende mail til den valgte person Som det kan læses ud fra listen, har DA ikke haft mange ændringsforslag. Og dem de har haft, har vi været i stand til at imødekomme. En anden ting vi ikke nåede, var at kunne godkende elever modtaget fra hjemmesiden. Grunden til vi ikke fik denne med i systemet var, at vi aldrig nåede at komme i kontakt med vedkommende der stod for deres hjemmeside og vi havde derfor ingen mulighed for at implementere funktionen. Side 47 af 55

49 Fordelen ved at have haft den med ville være, et elever dermed ikke skulle registreres både på hjemmesiden og i administrationssystemet. Dette kunne gøres ved at hjemmesiden benytter den database som vi har lavet. En anden ting, som vi også snakkede med Driving academy om, var at lave en sms funktion. Det den skulle gøre var at sende en sms til en elev/elever, dagen før de eksempelvis skal op til en køre- eller teoriprøve. En sådan funktion ville dog koste lidt ekstra penge for Driving acedemy, eftersom de ville være nød til at købe en sms gateway til et sende beskederne. Side 48 af 55

50 8.0 Bilag 8.1 Brugermanualer For at sikre kvaliteten yderligere af vores produkt har vi valgt at udarbejde en række brugermanualer til hvert af modulerne Brugermanual Administrationssystemet Denne brugermanual vil gennemgå og forklare funktionenerne i administrationssystemet. Systemet indeholder 7 hovedmenuer, og 11 undermenuer. Undermenu og funktionen heraf vil være beskrevet startende fra venstre. Menuerne er som følger: File o Udskriv o Exit Bruger o Log on o Log off Elever o Aftaler o Administration Kørelærer o Aftaler o Administration Hold Aftaler o Ny Aftale o Kalender Timeregistreringer o Udtræk Side 49 af 55

51 Generelt Meningen med administrationssystemet er at det skal køre I full screen. Når man skal bruge en funktion i systemet skal man således bare finde det man skal bruge i menulinien i toppen af skærmen. I ovenstående tilfælde er vi interreseret i at se en kørelæres aftaler. Når der trykkes åbnes der efterfølgende et nyt vindue inden i det grå område i vores hovedmenu. Tanken er at man således kan have flere vinduer åbne samtidig, men ved at de vinduer der åbnes holdes inden for det grå afgrænsede område, skulle det gerne være nemmere at holde overblikket. Dette er også illustreret i billedet nedenunder. Her har vi et overblik over de forskellige kørerlærere samt deres aftaler. Nederst i højre hjørne har vi mulighed for at åbne et nyt vindue, heri kan vi oprette aftaler. Når en aftale bliver oprettet lukkes vinduet og kalenderen bliver automatisk opdateret. Gennemgang af menuerne: Side 50 af 55

52 File Under File er der to menuer, Udskriv som udskriver hele siden. Sidste underpunkt er Exit, som lukker programmet. Bemærk, data der ikke er gemt inden, bliver ikke gemt ved Exit af programmet. Bruger Denne menu indeholder Log On og Log Off funktionerne. Det er nødvendigt at logge på inden resten af programmet bliver funktionelt. Ved Log On skal der bruges både et brugernavn og en kodeord. Dette er for at sikre det kun er autoriserede personer der anvender systemet, da det har med penge og gøre, og det er muligt at tilføje timer til personer. Log Off logger af systemet, men holder det dog kørende. Forlader man computeren kan man logge af, for at sikre systemet ikke bliver brugt af tredje-part mens man ikke er til stede. Elever Elever menuen indeholder Aftaler og Administration som undermenuer. Aftaler bringer et vindue frem som bruges til at se elever og deres aftaler. Øverst til venstre kan man under Find elev indtaste navnet på den elev man ønsker at finde, og alle mulige resultater vil blive vist i boksen under. Leder man efter en Lars, men er ikke sikker på om det var Knudsen eller Kaspersen, kan man nøjes med at skrive Lars K, så finder systemet alle der hedder Lars, og et efternavn med k. På samme måde er det muligt bare at skrive Lar, så vil systemet finde alle personer der indeholder den tekststreng. Det vil eksempelvis sige Lars Hansen, Kasper Larsen eller Kristian Klarup. Under søgefeltet er det muligt at markere om søgningen kun skal udføres på Aktive elever. Aktive elever er elever der stadig er ved at tage kørekortet. Det er dog også muligt at søge på alle elever. Der skelnes mellem de to fordi det som administrator kan blive uoverskueligt at lave aftaler for enkelte elever, efter noget tid, hvor man derfor vil have mange inaktive elever i databasen. Det kunne betyde at Side 51 af 55

53 hvis man vil lave en aftale for en person der hedder Lars, ville man risikere at finde så mange personer ved navn Lars, at det vil være for uoverskueligt at finde den rigtige. Dog skal det være muligt at finde inaktive elever, i tilfælde af, at det er nødvendigt at finde en tidligere elev som er uenig om de timer han eller hun er blevet faktureret for. På den måde kan man se historik for tidligere elever, om hvilke dage de har haft timer, og hvor mange de har haft. Når man har fundet den elev man leder efter, skal man markere denne i listen. Når dette gøres udfyldes Elev Information med den relevante information for en elev. Dette vindue bruges til at finde og se elevers aftaler, men det bruges også til at oprette nye aftaler for elever. Dette gøres ved, som anvist hvordan ovenover, at finde og markere en elev. Aftalen laves derefter ved at markere datoen for aftalen. Dette gøres ved at markere dagen i kalenderen i venstre side. Herefter kan man angive tidspunktet for aftalen ved at markere start tidspunkt, og derefter trække musen ned til sluttidspunktet. Administration af elever indeholde alle de værktøjer man som administrator har brug for, for at administrere elever. Her kan man se alle informationer omkring elever. Det er også her man kan oprette nye elever, og rette i eksisterende elever. De informationer man kan se her, udover alle de personlinge oplysninger, er hvilke timer eleven har haft, og hvor mange af dem han eller hun har haft. Det er også muligt at ændre status for en elevs teori- og køreprøve. Kørelærer Selvom kørelærer har de samme undermenuer, er den bygget anderledes op. Fordi der er et begrænset antal af kørelærer. Kørelærer er derfor sat ind som tabs over kalenderen, så man hurtigt og nemt kan skifte mellem de forskellige. Ved at vælge en kørelærere udfyldes Kørelærer Information også med den relevante kørelæreres informationer, og kalenderen der vises er den tilhørende den valgte kørelære. Det er også muligt at oprette en ny aftale for en kørelære her. Dette gøres ved at trykke på Ny Aftale nederst til højre i vinduet. I det nye vindue skal man indtaste alt relevant information for den nye aftale. Info der skal registreres er: Kørelære, elev eller hold, start tid, slut tid, dato og type. Man kan herudover vælge også at tilføje en titel og Side 52 af 55

54 en beskrivelse, men det er ikke nødvendigt. Vælger man ikke at skrive noget i titlen, får aftalen titel efter hvilken type time det er. I Administrations delen under kørelærere kan man øverst til venstre vælge hvilken kørelære man ser på, ved at vælge en kørelære henter programmet alle dennes elever. Disse elever vil herefter blive vist til højre i den store boks. Ønsker man at sende en mail til kørelæren er det blot at trykke på linket der hedder send mail. Ved at trykke på dette link åbner comuteren brugerens standard mail program, og til feltet bliver automatisk udfyldt med den pågældende lære. Hold Da Hold ikke har nogle underpunkter, åbnes Hold-vinduet ved en enkelt tast på menu-knappen i toppen. Som det kan ses på billedet til venstre vises hold øverst til venstre, når et hold på den liste bliver markeret udfyldes info øverst til højre. Den information er klasse-navn, beskrivelse af klassen og hvilken lærer der er tilknyttet klassen. Ligeledes udfyldes listen nederst til venstre med de elever der er i klassen. Til højre ses en statisk liste af alle aktive elever, og det er altså muligt at tilføje eller fjerne personer fra klassen. Det er også muligt at sortere, så det kun er aktive klasser der eksistere. Aktive klasser er klasser der er oprettet, men ikke afsluttede. Under listen af klasser er det også muligt at oprette en ny klasse. Dette gøres ved at trykke på Ny Klasse, hvilket resultere i et popup vindue. I dette vindue skal man skrive klasse navn, vælge en eksisterende lære fra en liste med alle lærere, og skrive en kort beskrivelse af klassen. Oftest bruges beskrivelse til at angive eksempelvis startdato for holdet. Aftaler Under aftaler er der to undermenuer; Ny aftale og Kalender. Ny aftale gør præcis det samme som Aftale gør under kørelærere, Ny Aftale her er bare en hurtigere måde at tilgå vinduet på. Side 53 af 55

55 Timeregistreringer Timeregistreringer åbner et nyt vindue, hvor man kan vælge at lave udtræk af timer eller lave en faktura for timer. Øverst til venstre vælger man enten kørelære eller elev. Alt efter hvad man vælger fyldes typen i den hvide boks under. I eksemplet her har vi valgt lærer, og markeret en lærere som har haft 3 køretimer og 2 glatbane time, resulterende i 5 timer i alt. Tallene er fundet ved at systemet har tjekket alle aftaler den pågældende lærer har haft, og talt disse timer sammen og sorteret dem efter type. Side 54 af 55

56 8.1.2 Brugermanual Android Widget Når først android applikationen er installeret på telefonen burde det være ret bruger venligt og nemt at finde rundt i. Ovenfor ses billedet som det ser ud når man kommer ind på applikationen. Her har man mulighed for at få en oversigt over de forskellige aftaler, enten vist for: dag, uge, måned eller idag. I billede nr. 2 er der valgt at få en oversigt for hele januar måned. Hvis man her trykker Idag knappen kommer man tilbage til det først billede igen. Herunder har man mulighed for at tage noter, oprette en aftale eller opgave. Billedet nedenunder viser skærmbilledet for at oprette en aftale. Når en aftalle bliver oprettet bliver den tilføjet til databasen og bliver derefter synlig når man åbner kalenderen. Side 55 af 55