A F S T U D E E R V E R S L A G
Ontwikkelen van een mobiele
cross-platform applicatie
voor het vinden en reserveren van
oplaadpunten bij CGI
A F S T U D E E R V E R S L A G
Ontwikkelen van een mobiele
cross-platform applicatie voor het vinden en
reserveren van oplaadpunten bij CGI
12060534 J.M.N. Vrolijk
Student Informatica aan de Haagse Hogeschool CGI - OU Communications & Utilities Den Haag – 02-10-2015
Referaat
Vrolijk, Justin
Ontwikkelen van een mobiele cross-platform applicatie voor het vinden en reserveren van oplaadpunten bij CGI. Rotterdam, CGI, 2015
Afstudeerverslag van Justin Vrolijk, geschreven in het kader van het afstuderen bij de opleiding Informatica aan de academie voor ICT & Media aan de Haagse Hogeschool.
Het verslag behandelt het (ontwikkel)proces dat is doorlopen tijdens de afstudeerperiode van Justin Vrolijk bij CGI te Rotterdam. Deze opdracht stond in het kader van het ontwikkelen van een mobiele cross-platform applicatie voor de bestuurders van een elektrisch voertuig. De afstudeerder moest een geschikt platform selecteren en door middel van een scrumachtige methodiek toewerken naar een demonstreerbare versie.
Descriptoren:
• Afstudeeropdracht
• Mobiele cross-platform applicatie
• iOS • Android • Xamarin • PhoneGap • C# • .NET 4.5
• Model View Controller (MVC)
• JSON
• XML
• Scrum
Voorwoord
M ijn naam is Justin V rolijk. Ik volg de opleiding Inform atica aan de H aagse H ogeschool te D en H aag. M ijn affiniteit m et techniek heeft geresulteerd in deze studiekeuze. S tudenten die deze opleiding volgen, ronden hun studie af m et een afstudeeropdracht. M ijn vorige stage-opdracht heb ik uitgevoerd binnen een kleine organisatie. A ls afsluiting op deze opleiding w ou ik graag afstuderen binnen een grote organisatie. N ederland kent een aantal grote IT -gerelateerde organisaties dat w erkzaam is in m eerdere landen. C G I kende ik via een fam ilielid dat daar in het verleden heeft gew erkt. D aarbij is het kantoor, voor m ij, gunstig gevestigd. Ik besloot om contact op te nem en m et C G I om de m ogelijkheden te bespreken. M et de heer Jos S iem ons kw am ik in gesprek en hij bood m ij een afstudeeropdracht aan.
Ik had m ijn scriptie niet op deze m anier af kunnen ronden als ik niet zo goed begeleid w as door een aantal personen: E .M . van D oorn en O . Z or van de H aagse H ogeschool en R ém on van den B eem t en F ranc B uve van C G I. D e heren van D oorn en Z or w il ik bedanken voor de begeleiding door het gehele proces heen, het inzicht, de kennis, de vriendelijkheid en de leuke, opbouw ende gesprekken over m ijn afstudeerverslag. R ém on en Franc, bedankt voor de goede en leuke begeleiding bij C G I, bedankt voor het feit dat jullie altijd klaar stond en om vragen te beantw oorden, m ee te denken en te helpen. U w scherpheid en uw feedback op m ijn stukken. O ok een dankbetuiging naar de heer Jos S iem ons. Z onder u had ik niet aan deze opdracht kunnen beginnen. B edankt dat u m ij een afstudeeropdracht hebt aangeboden binnen C G I.
Inhoudsopgave
1
Inleiding ... 1
Deel I.
Context en opdrachtomschrijving ... 2
2
De organisatie ... 2
2.1
CGI ... 2
2.2
Probleemstelling ... 3
2.3
Begeleidingsteam ... 4
3
Werkomgeving ... 5
3.1
CiMS ... 5
3.2
Systeemontwikkelomgeving ... 6
3.3
PhoneGap ... 6
4
Opdrachtomschrijving ... 7
4.1
Het afstudeerplan ... 7
4.2
Probleemstelling ... 7
4.3
Doelstelling ... 7
Deel II.
Aanpak en uitvoering ... 9
5
Aanpak ... 9
5.1
Scrum als ontwikkelmethode ... 9
5.2
Afspraken ... 10
5.3
Globale planning ... 11
6
Uitvoering ... 13
6.1
Aanvang opdracht ... 13
6.2
Sprint één - De softwarearchitectuur ... 19
6.3
Sprint twee - Hoofscherm en wijzigbaarheid ... 21
6.4
Sprint drie - De user interface ... 24
6.5
Sprint vier - Talen ondersteuning en CiMS integratie ... 27
6.6
Sprint vijf - Oplaadpunten filteren ... 32
6.7
Sprint zes - Koppeling met een nieuw platform genaamd CRM ... 34
6.8
Sprint zeven - Reservatie en transacties starten of stoppen ... 38
6.9
Sprint acht - De interface ... 41
6.10
Sprint negen - Performance en security ... 43
6.11
Legacy ... 46
Deel III.
Resultaat en evaluatie ... 48
7
Resultaat ... 48
8
Evaluatie ... 49
8.1
Productevaluatie ... 49
8.2
Procesevaluatie ... 50
1
1 Inleiding
H oe ontw ikkelt een idee zich tot een m obiele app? In dit
verslag w ordt dat proces beschreven. Ik ga een
afstudeeropdracht uitvoeren binnen C G I. Ik ga een m obiele cross-platform applicatie ontw ikkelen voor A ndroid en iO S . M et deze app kunnen bestuurders van elektrische auto’s gem akkelijk oplaadpunten vinden en reserveren. M et bestaande apps kunnen deze al gelokaliseerd w orden, m aar doordat een
koppeling m et het platform voor laadpalen ontbreekt, zijn geavanceerde opties zoals reserveren tot op heden niet m ogelijk.
H et verslag is opgedeeld in drie delen. In het eerste deel w ordt de context en opdrachtom schrijving besproken. U kom t m eer te w eten over het afstudeerbedrijf C G I en het team . O ok krijgt u verdiepende inform atie over het C iM S platform ; het platform dat in m eerdere landen gebruikt w ordt om alle laadpalen op afstand te beheren. V ervolgens w ordt de opdracht om schreven zoals het in het afstudeerplan afgesproke n is.
D eel tw ee beschrijft de aanpak en uitvoering. E en goede aanpak is essentieel om een project succesvol af te ronden. In dat hoofdstuk licht ik toe hoe S crum is toegepast binnen dit project. D e softw are ontw ikkelm ethodiek m oest enigszins aangepast w orden om dat het project zelfstandig w ordt uitgevoerd. M et deze aanpak w ordt vervolgens in iteraties de app ontw ikkeld. H et proces vanaf de druk op ‘C reate new project’ knop tot de oplevering van de app, w ordt beschreven. Ideeën van stakeholders w orden vertaald naar functionaliteiten. D aarbij kunnen problem en ontstaan. D eze problem en w orden toegelicht en opgelost. D aarna w ordt de app op perform ance en security getest. M et zelfgeschreven code w orden m etingen uitgevoerd op het 3G - en 4G netw erk. V ervolgens w ord en de datapakketen bekeken die over het net w orden verstuurd. M et encryptie en decryptie w ordt data beveiligd.
In deel drie w ordt het resultaat getoond. V erder w ordt het doorlopen proces geëvalueerd. H et doel dat geform uleerd is, is behaald. E en app is o pgeleverd m et m eer functionaliteiten dan aanvankelijk w as afgesproken. C G I w as positief verast over het resulta at. In de evaluatie, gaven ze aan dat ik op som m ige punten boven app developer zit die w erkzaam zijn in het bedrijfsleven. O ok w ordt de evaluatie besproken. H et geeft m ijn leerproces w eer : w at ging goed en w at ging niet goed? W at zou ik in het vervolg anders doen?
Deel I. Context en opdrachtomschrijving
2 De organisatie
H oofdstuk tw ee gaat over de organisatie. In paragraaf 2.1 w ordt de oprichting, activiteiten en organigram w eergeven. H ierna w ordt hun probleem stelling m et betrekking tot de opdracht om schreven. T ot slot w ordt het team dat m ij begeleidt, geïntroduceerd in paragraaf 2.3.
2.1 CGI
C G I is opgericht in 1976 vanuit de kelder van S erge G odin. S erge heeft dit in sam enw erking m et A ndré Im beau gedaan. D it bedrijf is uitgegroeid tot de op vier na grootste onafhankelijke zakelijke en IT-dienstverlener van de w ereld. Z e zijn actief in 40 landen, m et ruim
68.000 professionals, gespecialiseerd in business consulting,
systeem integratie en IT-outsourcingdiensten.
W ereldw ijd m ogen ze de top 100 bedrijven tot hun klanten rekenen. In N ederland heeft C G I ongeveer 3.500 m edew erker s: ze w orden m em bers
genoem d. Z ij zijn actief bij alle grote bedrijven en
overheidsinstellingen in N ederland. H et dienstenaanbod van C G I bestaat uit een uitgebreid pakket aan oplossingen. D aardoor zijn ze actief in diverse m arkten, onder andere: com m unicatie, energie,
financiële dienstverlening, olie en gas, overheid, post en logistiek, productie, zorg en transport. D e bedrijfscultuur is door de om vang van het bedrijf aanzienlijk groot. H et m anagem entteam stuurt m eerdere sectoren aan. H et organigram is te zien in Figuur 2.2. Iedere sectorbestuurder is voorzien van zijn eigen team dat op hen beurt ook zogeheten O U ’s (operatie units) aanstuurt. E lke O U heeft een m anagem entteam m et team leiders. D e team leiders sturen de m em bers aan en zijn hun eerste aanspreekpunt.
F i g u u r 2 . 2 O r g a n i g r a m C G I M a n a g e m e n t t e a m N e d e r l a n d
D e afstudeeropdracht w ordt gem aakt voor de heer Jos Siem ons . H ij is directeur consulting services binnen C om m unicatie en U tilities O U . D eze O U w ordt bestuurd door m evrouw Jannine T jansen . Z ij neem t deel aan het m anagem entteam in de com m erciële sector. D e onderstaande tw ee organigram m en
Sake Algra SVP and General Manager Monique Mulder VP Public Sector Gerrit Bruggeman VP Financial Sector John Jaques VP Commercial Sector
Sicco-Jan van der Meulen VP Services Frank Budwilowitz BU Controller Henk Zeilstra Director HR Miriam Klijn Legal Marcel Sommeling VP Business Engineering Sander vd Born VP Marketing & Communications Peter Paardekooper VP Operations F i g u u r 2 . 1 H o o f d k a n to o r C G I i n R o t te r d a m
3
F i g u u r 2 . 3 O r g a n i g r a m C o m m e r c i a l S e c t o r
F i g u u r 2 . 4 O r g a n i g r a m O U C o m m u n i c a t i o n s & U t i l i t i e s
2.2 Probleemstelling
C G I ontw ikkelde als eerste een infrastructuur voor de oplaadpunten van elektrische auto’s. Z ij hebben dit systeem C harge point interactive M anagem ent S ystem (C iM S ) genoem d. M et dit systeem kunnen laadpunten beheerd en laadtransacties verw erkt en verrekend w orden. D oordat het systeem m et open standaarden w erkt, kunnen verschillende soorten oplaadpunten w orden aangesloten. H ierdoor kunnen m eerdere netbeheerders gebru ik m aken van C iM S . D it platform w ordt verder toegelicht in paragraaf 3.1.
In N ederland zijn m eer dan 3.000 oplaadpunten verbonden m et C iM S . D eze w orden beheerd door E laadN L . D aarnaast w ordt dit systeem gebruikt in m eerdere landen zoals: D uitsland, B elgië, L uxem burg, N oorw egen en Z w eden.
V eel m obiele apps hebben deze oplaadpunten in kaart gebracht. O m dat de com m unicatie m et C iM S ontbreekt, is het alleen m ogelijk om ze te lokaliseren. C G I heeft van m eerdere klanten die gebruik m aken van deze infrastructuur, de vraag gehad of zij een app hebben die niet alleen oplaadpunten kan tonen, m aar ook kan com m uniceren m et C iM S . H ierdoor zou het m ogelijk zijn om bijvoorbeeld oplaadpunten te reserveren of een transactie via de telefoon te starten en stopen. T evens zou de huidige status van het oplaadpunt opgevraagd kunnen w orden. D aarnaast w il C G I graag aantonen en onderzoeken hoe het systeem inspeelt op de huidige m obiele m arkt.
John Jaques VP Commercial Sector Richard Jacobs OU Manufacturing Roger Brepoels OU Region Southeast Janine Tjassens OU Communications & Utilities Frank Levert OU Transport & Logistics David Vriesendorp OU Region West Mark Mooy OU Shell Merith Baron Personal Assistant Finance: Frank Budwilowitz PMO: André Los HR: Jacqueline Trompetter BE: Andre van der Wiel Marketing & Comms: Marion de Regt Esther Vlemingh-Sanstra Coordinating Secretary Janine Tjassens OU Leader Jos Siemons Director Consulting Services Fred Batten Rémon van den Beemt
Wim de Jong Team Leads Michiel Homan Director Consulting Services Robin Oduber Sander Boer Dorita Goeijenbier Team Leads Lucien Smits Director Consulting Services Etiënne Kuijkhoven Kees Soonius Ben Hessing Lucien
Kamperveen William Ritchie Edwin de Vries Team Leads Secretary Yolanda Krielen Clarice Bannenberg Eric van der Laan
John Mohamed Maurice Gordijn Business Development
Sonja Snelderwaard Resourcing
2.3 Begeleidingsteam
F ranc B uve, S oftw are A rchitect, is h et eerste aanspreekpunt voor vragen en beslissingen over de opdracht. H ij bew aakt de voortgang van het project en levert feedback op de resultaten. R ém on van den B eem t , T echnical P roject L eader, kan benaderd w orden m et niet-opdracht gerelateerde vragen. H ij begeleidt m ij bij aanvang van het p roject. N ghia L e, P rincipal IT A rchitect, en Y ard N ijsten , S oftw are E ngineer, zijn bereikbaar voor technische problem en. V ragen die betrekking hebben op de gebruikersinterface kunnen gesteld w orden aan C hris van Schayk , S oftw are E ngineer.
5
3 Werkomgeving
In paragraaf 3.1 w ordt toegelicht w at de C iM S infrastructuur kan en doet. In paragraaf 3.2 staat de systeem ontw ikkelom geving bij C G I centraal. T ot slot w ordt in paragraaf 3.3 het platform PhoneG ap aan bod. D aarin w ordt uitgelegd w at PhoneG ap is en w at erm ee gedaan kan w orden.
3.1 CiMS
C iM S is een infrastructuur voor het verbinden en op afstand beheren van oplaadpunten. D e verbinding m et diverse oplaadpunten is m ogelijk door het O pen C harge Point Protocol (O C PP ). O ok kunnen transacties verw erkt w orden en zijn een tal van andere services verbonden m et C iM S . D eze zijn verbonden door het C IS platform . C IS is een open interface laag w aarm ee services verbonden w orden m et C iM S. D aarnaast is het C R M platform . D at systeem beheert de kaart - en klantgegevens. D eze com m uniceert direct m et C iM S en stuurt updates naar C IS . In F iguur 3.1 is C iM S schem atisch w eergegeven.
F i g u u r 3 . 1 : S c h e m a t i s c h e w e e r g a v e v a n C i M S , C I R e n C R M ( B r o n : h t t p : / / w w w . c g i n e d e r l a n d . n l )
O C PP is een open standaard voor de com m unicatie tussen oplaadpunten en een centraal systeem . D e standaard m aakt gebruik van S im ple O bject A ccess P rotocol (S O A P ). H ierm ee kunnen berichten tussen tw ee com ponenten over het internet verstuurd w orden. C iM S gebruikt m om enteel versie 1.5 van O C P P .
D eze versie is de facto standaard w ereldw ijd. H et protocol w ordt in m eer dan 50 landen gebruikt bij 10.000 plus oplaadpunten. H et is overgenom en door de O pen C harge A lliance (http://w w w .openchargealliance.org/). H un m issie is om de ontw ikkeling, goedkeuring, en de naleving van de com m unicatie protocollen in de elektrische auto laadinfrastructuur te bevorderen. C IS is een open interface -laag bovenop de C iM S infrastructuur. H et dient als ‘roam ing hub’ voor andere providers. E en roam ing hub verbindt m eerdere providers m et elkaar. S ervices com m uniceren m et C iM S via deze laag. D aarnaast is het voor derden m ogelijk om bijvoorbeeld nieuw e betaaloplossingen erbij te ontw ikkelen.
In C R M staan de gegevens van pashouders en hun transacties. M et dit systeem kunnen de pashouders beheert w orden. D aarnaast kunnen zij zelf inloggen op dit systeem om hun eigen transactiehistorie te zien en om gegevensw ijzigingen door te vo eren.
CiMS Infra + GUI
Charge points
CIS: CiMS Charge point Integration Services
Id
en
ti
ti
es
Tr a n sa c ti o n s Ch a rg e poi nt s CI R eV io li n OC HP VA S C P eP O I Mo b i. E Pu b li c Ma pOC P P
S t a n d a rd s e rv i c e s C l e a ri n g h o u s es C P a v a il a b il it y a n d m o b i l e p a y m e n t i n te g r a ti o nCiMS CRM + GUI
3.2 Systeemontwikkelomgeving
E én van de softw are ontw ikkelm ethodes die C G I gebruikt, is S crum . S crum is een iteratieve ontw ikkelm ethode. In zogeheten sprints w orden user story’s - vergelijkbaar m et requirem ents - geïm plem enteerd. E en sprint duurt tw ee tot vier w eken. A an het eind van die periode w ordt een w erkend stuk softw are opgeleverd. S takeholders kunnen hierdoor in een vroeg stadium de voortgang bekijken. Z ij w orden nauw betrokken bij het proces om dat ze sturing kunnen geven bij de vervolg sprints.
V olgens S chw aber en S utherland (2010, p. 5) bestaat een S crum T eam uit ‘S crum M aster’, ‘P roduct O w ner’ en het team . D e Scrum M aster bew aakt het scrum proces. E en Product O w ner beheert de ‘P roduct B acklog’. H et P roduct B acklog bestaat uit een lijst m et requirem ents. E n tot slot het team dat bestaat uit ontw ikkelaars. Z ij gebruiken het P roduct B acklog om story’s te selecteren voor de kom ende sprint.
C G I gebruikt norm aliter sprints die tw ee w eken duren. B ij aanvang van elke sprint w ordt m et het team en de Product O w ner een ‘groom ing’ sessie gehouden. D e geprioriteerde user story’s w orden geselecteerd en geanalyseerd. H ierna kan het team bepalen w elke story’s w orden opgenom en in de sprint.
H et scrum proces w ordt begeleid door de Scrum M aster. H et is zijn taak om ervoor te zorgen dat de scrum processen correct w orden uitgevoerd. S print review en een ‘D aily S crum ’ zijn voorbeelden van scrum processen. T eam s houden dagelijks een ‘stand up’ w aar zij drie vragen staand beantw oorden: W at heb ik gister bereikt? W at ga ik vandaag doen en w elke uitdagingen verw acht ik?
D e Product O w ner beheert het Product B acklog. H ij is verantw oordelijk voor de opgeleverde producten. O ok is hij degene die contact heeft m et de stakeholders. H et is zijn taak om de w ensen en eisen in kaart te brengen. D eze neem t hij op in het P roduct B acklog.
3.3 PhoneGap
E en eis, die beschreven is in hoofdstuk vier, is dat de applicatie gebouw d w ordt m et P honeG ap. H et is een platform w aarm ee m obiele cross-platform applicaties ontw ikkeld w orden m et behulp van H T M L 5, JavaScript en C S S . D e ontw ikkelaar bouw t in feite een w ebsite die gepresenteerd w ordt in een native app; ook w el een hybride app genoem d. D eze is voorzien van een brow ser. P honeG ap bouw t de app m et brow ser. D e ontw ikkelaar hoeft alleen de ‘w ebsite’ te ontw ikkelen .
D aardoor hoeft de ontw ikkelaar geen kennis te hebben van de platform specifieke ontw ikkeltalen. E en bijkom end voordeel is dat de app eenm alig gem aakt hoeft te w orden. M et m iniem e aanpassingen kan het uitgerold w orden naar platform en zoals: iO S , A ndroid en W indow s P hone. H et proces van een w ebsite (bestaande uit H T M L 5, C S S en JavaS cript) is w eergegeven in F iguur 3.2.
F i g u u r 3 . 2 : D e w e r k i n g v a n P h o n e G a p ( B r o n : h t t p : / / p h o n e g a p . c o m / a b o u t )
P honeG ap blijkt een succesvol platform te zijn om hybride applicaties te ontw ikkelen. Z o blijkt uit
een artikel op PhoneG ap: “PhoneG ap has been dow nloaded over 1 m illion tim es and is being used by
over 400,000 developers. T housands of apps built using P honeG ap are available in m obile app stores and directories.” ("A bout the P roject", z.j.)
7
4 Opdrachtomschrijving
In hoofdstuk 4 w ordt de aanvankelijke opdrachtom schrijving beschreven. D eze kom t overeen m et het afstudeerplan dat opgenom en is als bijlage ( B ijlage I). In paragraaf 4.1 w ordt de probleem stelling uit het afstudeerplan beschreven. Paragraaf 3.2 eindigt m et de doelstelling.
4.1 Het afstudeerplan
In het afstudeerplan is beschreven w aarom C G I dit project w il laten uitvoeren en hoe dit gedaan gaat w orden . B elangrijke onderdelen van het plan w orden hieronder herhaalt en w aar nodig toegelicht.
4.2 Probleemstelling
D erde partijen hebben apps ontw ikkeld w aar oplaadpunten in kaart zijn gebracht. H et is niet m ogelijk om daarm ee laadpalen te reserveren of de beschikbaarheid te controleren om dat integratie m et C iM S ontbreekt. D e klanten w illen graag een app die specifiek voor dit systeem is gebouw d m et hun eigen branding. E en app die geïntegreerd is m et C iM S door een interface, m aakt het m ogelijk om bijvoorbeeld laadpalen te reserveren of de beschikbaarheid te tonen.
D e app m oet kunnen com m uniceren m et C iM S om zulke functionaliteiten te realiseren. H et systeem heeft op dit m om ent nog geen interface die com m unicatie m et m obiele telefoons m ogelijk m aakt. E en generieke R E ST A PI m aakt integratie van m obiele telefoons m et het systeem m ogelijk.
B ovendien m oeten de app en interface voldoen aan de volgende punten:
• de com m unicatie tussen de interface en de app m oet beveiligd zijn;
• de app m oet gem akkelijk te gebruiken zijn en professioneel ogen;
• responsetijd m oet op het 3G en 4G netw erk snel zijn;
• binnen een dag m oet klantenbranding toegepast kunnen zijn op de app.
D aarnaast hoopt C G I m eer klanten te krijgen door het systeem uit te breiden. E en interface voor com m unicatie m et m obiele telefoons en een W hite-label app kan daaraan bijdragen. H et doel is om een m obiele cross-platform applicatie te ontw ikkelen m et behulp van P honeG ap, die aansluit op de w ensen van bestuurders van elektrische auto’s.
4.3 Doelstelling
D e doelstelling is h et ontw ikkelen van een m obie le cross-platform applicatie m et behulp van P honeG ap, die aansluit op de w ensen van bestuurders van elektrische auto’s. H et zal een overzicht tonen van beschikbare oplaadpalen en een reservering daarvan m ogelijk m aken. D aarnaast zal de w erking van de C iM S interface voor m obiele apps gedem onstreerd kunnen w orden.
T evens kan de app -gebruiker m et de app: laadpalen m arkeren als favoriet, zoeken naar specifieke laadpalen, w aarderingen geven en m elding m aken van onjuiste inform atie. B ovendien ligt de nadruk van de app en interface op de volgende kw aliteitseisen: beveiligbaarheid, gebruikersgem ak, aantrekkelijkheid, snelheid en w ijzigbaarheid.
4.3.1 Het beoogde resultaat
H et resultaat is een W hite -label m obiele cross-platform applicatie die ontw ikkeld is voor iO S en A ndroid. D oor m iddel van een R E ST A PI w ordt gecom m uniceerd m et C iM S. D eze A PI is in sam enw erking m et een ontw ikkelaar van C G I gedefinieerd, m aar door C G I gebouw d.
D e app kan in deze staat gedem onstreerd w orden aan de klant. M et m iniem e m oeite kan binnen een dag klantenbranding toegevoegd w orden. D e app-gebruiker kan hierm ee gem akkelijk en snel oplaadpunten vinden en reserveren. O ok is het volgende m ogelijk in de app:
• h et m ar k er en v an l aad p al en al s f av o r i et ;
• z oe ke n na a r l a a dpa l e n di e ge s c hi kt z i j n voor hun t ype a ut o ; • e en w aar d er i n g g ev en aan een l aad pa a l ;
T evens is de app gem akkelijk te gebruiken en heeft het een heldere en professionele uitstraling. O p zow el het 3G en 4G netw erk is de responsetijd snel. O ok is de com m unicatie tussen de app en C iM S is beveiligd zodat ongew ilde aanvragen en acties voorkom en w orden.
9
Deel II. Aanpak en uitvoering
5 Aanpak
D e gekozen aanpak die in het plan van aanpak staat beschreven, w ordt in dit hoofdstuk toegelicht. H et plan van aanpak is opgenom en in bijlage II. In paragraaf 5.1 w ordt gekeken of S crum toepasbaar is binnen dit project. V ervolgens w ordt de aanpak m et S crum beschreven. In paragraaf 5.2 kom en afspraken die gem aakt zijn op het gebied van: afbakening, risico’s en randvoorw aarden aan de orde. In paragraaf 5.3 staat de globale planning voor de uitvoer in hoofdstuk 6.
5.1 Scrum als ontwikkelmethode
D e opdrachtgever w enst dat een agile m ethodiek w ordt toegepast. B ij aanvang heeft hij aangegeven dat S crum gebruikt m oet w orden. H ij w il gebruik m aken van deze m ethode om dat C G I hierm ee bekend is en om dat een online-om geving klaarstaat. In deze online -om geving kunnen de scrum processen gem akkelijk ingericht w orden. D aarnaast bew eert hij dat het goed aansluit bij dit project aangezien het een agile aanpak is die w einig overhead oplevert.
B ij m ij ontstond de vraag of Scrum w el een bruikbare m ethode is bij dit project. Ik besluit daarom om te onderzoeken of het w el toepasbaar is. In hoofdstuk vier staan de w ensen en eisen die tot zover bekend zijn. E en reeks aan functionele en niet-functionele requir em ents. H et is duidelijk d at de opdrachtgever een app w il m et een aantal functionaliteiten. H et is niet bekend hoe die functionaliteiten, en de app zelf, eruit m oet kom en te zien. H ij heeft alleen aangegeven dat het professioneel m oet ogen en ergonom isch in gebruik m oet zijn. D aarnaast ontbreken details aan requirem ents. G edurende het project zullen deze w aarschijnlijk veranderingen ondergaan. D aaruit kan ik concluderen dat de opdrachtgever nog geen visueel beeld heeft van de app. E en agile m ethodiek m et iteratief karakter is dan aan te raden.
In paragraaf 3.2 staat dat S crum daaraan voldoet. D e Product O w ner k an het P roduct B acklog vullen m et de reeds bekende requirem ents. H ij interview t de stakeholders om die te vertalen naar user story’s en om de prioriteiten te achterhalen . D aar kunnen ook nieuw e story’s uit voortvloeien. P er sprint w ordt m et het team een aantal story’s uitgew erkt en geïm plem enteerd (vooraf gedetailleerde requirem ents zijn niet nodig). H ierna ontvangt de opdrachtgever een w erkend stuk softw are. H ij kan dan feedback leveren en gaande w eg w ordt de applicatie naar zijn w ensen en eisen ontw ikkeld. S crum is in dat opzicht toepasbaar. H et is echter bedoeld voor m ultidisciplinaire team s. S chw aber en S utherland (2010, p. 8) schrijft dat scrum team s bestaan uit ongeveer 7 personen. D at levert een probleem op om dat het project door één persoon w ordt uitgevoerd. E en scrum achtige m ethodiek zou de oplossing zijn. In sub paragraaf 5.1.1 w ordt die beschreven.
5.1.1 Aanpak voor scrumachtige methodiek
U it paragraaf 5.1 blijkt dat een scrum achtige m ethode de oplossing is. E en aantal delen binnen S crum w ordt w eggelaten. O ok zal ik m eerdere rollen op m ij nem en. H et gehele ‘team ’ bestaat uit één persoon. S crum w ordt op de volgende m anier aangepast:
• D e S c r u m M a s t e r k o m t t e v e r v a l l e n ; • D a D a i ly S c r u m k o m t te v e r v a lle n ;
• H e t o n t w i k k e l t e a m b e s t a a t u i t é é n p e r s o o n ; • D e o n t w i k k e l a a r i s o o k d e P r o d u c t O w n e r ; • S p r i n t R e v i e w k o m t t e v e r v a l l e n .
A ls Product O w ner ga ik eerst het scrum board inrichten. H ierna zoek ik contact m et de stakeholders en ga ik m et hun in bespreking. D oor die gesprekken kunnen de user story’s invulling krijgen . D eze w orden vervolgens opgenom en in het Product B acklog. D aarnaast bew aak ik het resultaat en blijf ik m et nauw e lijnen in contact m et de stakeholders.
In F iguur 5.1 w ordt de aanpak geïllustreerd. H et traject w ordt opgedeeld in negen sprints van ieder tw ee w eken. A an het eind van elke sprint w ordt van de P roduct B acklog een aantal geprioriteerde story’s geselecteerd. D eze w orden opgenom en in de S print B acklog en uitgew erkt. H et eind van iedere sprint resulteert in een w erkend stuk softw are . D eze is voorzien van docum entatie. D aarin staat het design- en ontw ikkelproces beschreven . S crum is norm aliter ‘lean’: w einig tot geen docum entatie. D e docum entatie schrijf ik om na te den ken over oplossingsm ogelijkheden. D aarnaast dient het als procesbeschrijving voor de opdrachtgever. H ij kan dan feedback geven op het doorlopen proces indien het nodig is. H et sprintproces dat doorlopen w ordt, is w eergegeven in F iguur 5.2.
F i g u u r 5 . 1 : S c r u m o n t w i k k e l p r o c e s v o o r d i t p r o j e c t
F i g u u r 5 . 2 : S p r i n t p r o c e s
5.2 Afspraken
5.2.1 Afbakening
E en project goed afbakenen is noodzakelijk. V ooraf m oet afgesproken w orden w at w el en niet gedaan w ordt. V erw achtingen van beide kanten kunnen nam elijk verschill en. In het plan van aanpak is te lezen dat ontw ikkeling aan de R E ST A PI buiten de scope valt van deze opdracht. D at geldt ook voor het publiceren van de apps. D it is de verantw oordelijkheid van C G I.
5.2.2 Randvoorwaarden
H et project w ordt zelfstandig uitgevoerd. V ragen w orden beantw oord door Jos S iem ons, R ém on van den B eem t, F ranc B uve en N ghia L e. Z ij zijn het aanspreekpunt voor beslissingen die genom en m oeten w orden. F ranc fungeert naast C iM S specialist ook als opdrachtgever.
11
5.2.3 Risico’s
In het plan van aanpak zijn de vooraf gesignaleerde risico’s in kaart gebracht. D e risico’s zijn w eergegeven in T abel 5.1. D eze tabel geeft ook de gevolgen, herkenningspunt, m aatregelen en verantw oordelijkheden w eer.
T a b e l 5 . 1 : R i s i c o a n a l y s e # R i s i c o G e v o l g e n H e r k e n n i n g s p u n t e n M a a t r e g e l e n V e r a n t w o o r d e l i j k 1 E e n t e c h n i s c h p r o b l e e m w a a r i k n i e t u i t k o m . P l a n n i n g k a n u i t l o p e n e n o n h a a l b a a r w o r d e n . N a t w e e u u r g e e n p r o g r e s s i e m e t h e t p r o b l e e m . C o n t a c t o p n e m e n m e t Y a r d N i j s t e n o f N g h i a L e . A a n h u n h e t p r o b l e e m v o o r l e g g e n . J u s t i n V r o l i j k 2 F u n c t i o n a l i t e i t n i e t m o g e l i j k o p i O S e n / o f A n d r o i d . E i n d p r o d u c t ( o f b e p a a l d p l a t f o r m ) h e e f t m i n d e r f u n c t i o n a l i t e i t e n . N a m a a t r e g e l u i t r i s i c o é é n n o g g e e n o p l o s s i n g . C o n t a c t o p n e m e n m e t F r a n c B u v e . M a a t r e g e l e n m e t h e m a f s t e m m e n . J u s t i n V r o l i j k 3 E e n n i e t - f u n c t i o n e l e e i s i s n i e t h a a l b a a r . H e t e i n d p r o d u c t v o l d o e t n i e t v o o r l e d i g a a n a l l e w e n s e n . N a e e n ( p e r f o r m a n c e ) t e s t o f f e e d b a c k b l i j k t d e e i s n i e t h a a l b a a r . C o n t a c t o p n e m e n m e t R é m o n v a n d e n B e e m t e n F r a n c B u v e . M e t h u n k i j k e n o f e r e e n o p l o s s i n g m o g e l i j k i s o f d e e i s v e r s o e p e l e n . J u s t i n V r o l i j k 4 D e a d l i n e b l i j k t n i e t h a a l b a a r . D e a d l i n e a a n h o u d e n b e t e k e n d e e n e i n d p r o d u c t m e t m i n d e r f u n c t i o n a l i t e i t e n e n w e l l i c h t n i e t b r u i k b a a r . H e r h a a l d e l i j k z i j n r i s i c o ’ s : é é n , t w e e o f d r i e v o o r t g e k o m e n . C o n t a c t o p n e m e n m e t R é m o n v a n d e n B e e m t . P l a n n i n g o p n i e u w b e k i j k e n e n e v e n t u e e l d e d e a d l i n e v e r s c h u i v e n . J u s t i n V r o l i j k 5 F u n c t i o n a l i t e i t e n b l i j k e n n i e t h a a l b a a r m e t P h o n e G a p M i n d e r f u n c t i o n a l i t e i t e n o f o n d e r z o e k e n a n d e r e m o g e l i j k h e d e n ( p l a t f o r m e n ) . M e e r d e r e f u n c t i o n a l i t e i t e n k u n n e n n i e t g e r e a l i s e e r d w o r d e n . E e n m e e t i n g p l a n n e n m e t R é m o n v a n d e n B e e m t , F r a n c B u v e e n N g h i a L e . J u s t i n V r o l i j k 6 O n t w i k k e l a a r i s n i e t g o e d g e f a c i l i t e e r d . E i n d p r o d u c t v o l d o e t n i e t a l l e w e n s e n e n e i s e n o f e i n d p r o d u c t k a n n i e t g e r e a l i s e e r d w o r d e n . O n t b r e k e n v a n l i c e n t i e s o f h a r d w a r e . C o n t a c t o p n e m e n m e t R é m o n v a n d e n B e e m t o f J o s S i e m o n s . C G I
5.3 Globale planning
In F iguur 5.2 staat de globale planning w eergegeven. O p 16 m aart 2015 begin ik aan de opdracht. D e activiteitennum m ers één tot en m et negen w orden in de eerste tw ee w eken uitgevoerd. D eze tw ee w eken staan in kader van kennism aking en het uitvoeren van de activiteiten. H ierna w ordt gestart m et de eerste sprint. S print één tot en m et zeven w orden achterelkaar doorlopen. W aarna ik tw ee w eken verlof neem . D aarna w orden de laatste tw ee sprints uitgevoerd. D e sprint indeling w ordt bepaald voor de start van de sprint. W eeknum m er 23 staat gereserveerd als uitloop w eek. In diezelfde w eek w orden ook voorbereidingen verricht voor de eindpresentatie. D eze presentatie is bedoeld voor C G I. In de laatste w eek, w eeknum m er 24, w ordt het project overgedragen. D aarna volgt ook de eindpresentatie en ontvang ik feedback van C G I.
13
6 Uitvoering
In hoofdstuk zes staan de uitgevoerd w erkzaam heden beschreven. C entraal in de beschrijving staan de vragen: • W a t h e b i k g e d a a n ? • H o e h e b i k h e t g e d a a n ? • W a a r o m h e b i k h e t z o g e d a a n e n w a a r o m o p di e m a ni e r ? • W i e w a r e n d e b e t r o k k e n e n ? • W e l k e o p l o s s i n g s r i c h t i n g e n w a r e n e r ? • W a t w a r e n m i j n k e u z e / b e s l i s m o m e n t e n ? • W a t w a s h e t r e s u l t a a t ?
In paragraaf 6.1 begint m et de aanvang van de opdracht. D aarin w orden de eerste tw ee w eken van de afstudeeropdracht beschreven. P aragraaf 6.2 begint m et de eerste sprint van S crum . D aarin w ordt de softw arearchitectuur bedacht en geïm plem enteerd. In sprint tw ee w ordt het hoofdscherm bedacht en kijk ik naar de w ijzigbaarheid van de app. S print tw ee w ordt beschreven in paragra af 6.3. D aarna w ordt in paragraaf 6.4 de user interface bedacht. Sprint drie bleek een goed m om ent om de storyboard te ontw erpen. P aragraaf 6.5 beschrijft de koppeling m et C iM S en de ondersteuning van m eerdere talen. In paragraaf 6.6 kom t het filteren van oplaadpunten aanbod. V ervolgens w ordt in paragraaf 6.7 een koppeling gem aakt m et een nieuw platform . D at platform heet C R M . P aragraaf 6.8 vervolgt m et drie lastige functionaliteiten. D aarin w ordt het starten, stoppen en reserveren van een transactie gerealiseerd. In paragraaf 6.9 w ordt de user interface nogm aals bekeken en verbeterd. D e applicatie w ordt in die sprint verstuurd een C G I w erknem er. P aragraaf 6.10 beschrijft de laatste sprint. D e feedback, die ik heb ontvangen van de C G I w erknem er die de app heeft ontvangen in de vorige paragraaf, w ordt in deze sprint bekeken. D aarnaast w ordt de perform ance getest en testen w e de app op security. T ot slot kom t in paragraaf 6.11 de legacy aanbod.
6.1 Aanvang opdracht
D e eerste tw ee w eken staan in het kader van orië ntatie, kennism aking en het plan van aanpak. O ok w ordt de docum entatie van C iM S, PhoneG ap en X am arin bestudeerd en w orden de scrum processen ingericht.
In het vorige hoofdstuk is het plan van aanpak beschreven. D aarna is er literatuuronderzoek gedaan naar C iM S, PhoneG ap en X am arin. X am arin is ook een platform w aarm ee m obiele cross -platform applicaties gebouw d kunnen w orden. P aragraaf 6.1.1 gaat over het initiatiedocum ent. D at docum ent dient ter voorbereiding op de scrum processen. D ie kom en in paragraaf 6.1.2 aan de orde. H et resultaat van de ondernom en activiteiten staat in paragraaf 6.1.3.
6.1.1 Initiatiedocument op het Product Backlog
T er voorbereiding op het Product B acklog is een initiatiedocum ent aangem aakt. D aarin zijn de requirem ents geanalyseerd, de use cases vastgesteld, de requirem ents die tegenstijdig zijn opgesom d, alle requirem ents gepriorite erd, belangrijke use c ases zijn beschreven en tot slot is er pakketselectie uitgevoerd tussen X am arin en P honeG ap.
D at docum ent is geschreven volgens de richtlijnen van de elaboratiefase uit (R )U P . In de planning w as w eek tw ee gereserveerd voor het inrichten van het Product B acklog. D it bleek ruim ingepland te zijn. Ik w ou graag de extra tijd gebr uiken om m eer inzicht te krijgen. D e elaboratiefase heeft daarbij in het verleden - bij projecten op school - vaak geholpen. S crum is echter lean en niks staat vast. H et initiatiedocum ent dient daarom alleen ter voorbereiding op het project. M et dit docum ent kan invulling w orden gegeven aan het Product B acklog, m aar het is niet leidend. Veranderingen w orden niet in dit docum ent doorgevoerd.
A llereerst zijn de stakeholders in kaart gebracht. Z ij staan opgesom d in T abel 6.1. M et interview s, e-m ails en telefonisch contact, w orden hun w ensen en eisen vastgesteld . M et hun w ordt in nauw e
lijnen koppeling gehouden om de voortgang te bew aken. F ranc B uve is het eerste aanspreekpunt. H ij neem t de rol van opdrachtgever op zich.
T a b e l 6 . 1 : S t a k e h o l d e r s z o n d e r c o n t a c t g e g e v e n s I D N a a m O r g a n i s a t i e e n f u n c t i e I n f o S A 1 B u v e , F r a n c C G I - S o f t w a r e A r c h i t e c t S o f t w a r e a r c h i t e c t v o o r E l a a d N L e n C i M S D C S 1 S i e m o n s , J o s C G I - D i r e c t o r C o n s u l t i n g S e r v i c e s M a r k e t i n g M a n a g e r I T 1 L e , N g h i a C G i - P r i n c i p a l I T A r c h i t e c t P L 1 B e e m t , R é m o n v a n d e n C G I - T e c h n i c a l P r o j e c t L e a d e r E V 1 S i e m o n s , J o s - W e n s e n v o o r d e a p p a l s E V b e s t u u r d e r E V 2 P e t z e r , G u i d o -
V ervolgens zijn de requirem ents opgesom d. A llereerst zijn de w ensen en eisen uit de opdrachtom schrijving (afstudeerplan) vertaald. E en onderscheid is gem aakt tussen gebruikers w ensen, project-, design- en ontw erpbeslissingen. D eze zijn te herkennen aan de eerste tw ee letters van het ID . G ebruikersw ensen beginnen m et U R , projectgrenzen m et PC , etc.
T a b e l 6 . 2 : R e q u i r e m e n t s u i t o p d r a c h t o m s c h r i j v i n g
I D O m s c h r i j v i n g S t a k e h o l d e r B r o n V e r s i e D a t u m
UR01 De eindgebruikers kunnen laadpalen zoeken. SA1 Afstudeerplan 1.0 16-03-2015
UR02 Eindgebruikers kunnen laadpalen reserveren. SA1 Afstudeerplan 1.0 16-03-2015
UR03 Eindgebruikers kunnen laadpalen markeren als favoriet. SA1 Afstudeerplan 1.0 16-03-2015
UR04 Eindgebruikers kunnen laadpalen zoeken die geschikt zijn
voor hun type oplaadstekker.
SA1 Afstudeerplan 1.0 16-03-2015
UR05 Eindgebruikers kunnen een waardering geven over het
oplaadpunt.
SA1 Afstudeerplan 1.0 16-03-2015
UR06 De eindgebruikers kunnen een melding maken van onjuiste
informatie.
SA1 Afstudeerplan 1.0 16-03-2015
UR07 De eindgebruikers kunnen zien welke laadpalen beschikbaar
zijn. SA1 Afstudeerplan 1.0 16-03-2015
PC01 Het project moet een Agile methodiek hanteren. Scrum
wordt geprefereerd.
SA1 Afstudeerplan 1.0 16-03-2015
PC02 Het project moet eind augustus demonstreerbaar zijn. SA1 Afstudeerplan 1.0 16-03-2015
DC01 Het project moet met PhoneGap ontwikkeld worden. SA1 Afstudeerplan 1.0 16-03-2015
DC02 Het project moet met Xamarin ontwikkeld worden. IT1 Gesprek 1.0 18-03-2015
O01 De laadpalen worden getoond in een geografische map. PL1 Gesprek 1.0 18-03-2015
D aarna ben ik interview s gaan inplannen. D aarm ee w ou ik de resterende w ensen en eisen achterhalen. O ok draagt een persoonlijk gesprek bij aan een gezam enlijk beeld. T er voorbereiding op die gesprekken ben ik eerst gaan onderzoeken hoe soortgelijke apps w erken. E en aantal stakeholders bezit nam elijk een elektrische auto. Z ij zullen gebruik m aken van bestaande apps en zij zullen verm oedelijk de m inheden benoem en. D e requirem ents uit die interview s zijn opgenom en in een aparte tabel in het initiatiedocum ent.
N u een aardige w aslijst aan requirem ents bekend is, m oeten ze geprioriteerd w orden. H iervoor m aakte ik gebruik van de M oS C oW m ethode. M et die m ethode w orden requirem ents verdeeld in één van de volgende categorieën: m ust have, should have, could have en w ont have. D eze prioritering kan toegepast w orden in het P roduct B acklog.
V ervolgens is een use case diagram gem aakt. R equirem ents die ingedeeld zijn in de m ust have categorie, zijn opgenom en als use cases. V ervolg ens zijn de actoren bepaald. N aast de gebruikersactor is er ook een pashouderactor toegevoegd, opdat de functionaliteiten niet voor iedereen beschikbaar zijn. C iM S is ook als actor opgenom en om dat het systeem daarm ee data
15
F i g u u r 6 . 1 : U s e c a s e d i a g r a m
6.1.1.1 Xamarin
D e term X am arin is eerder in dit hoofdstuk al eens benoem d. X am arin is een alternatief platform op P honeG ap. N et als P honeG ap kan m et dit platform m obiele cross-platform applicaties ontw ikkeld w orden. T w ee platform en die het zelfde einddoel hebben, m aar w ezenlijk verschillen van elkaar. D it platform w ordt bestudeerd om dat tw ee re quirem ents elkaar tegenspreken. F ranc B uve w il graag dat P honeG ap w ordt gebruikt als platform en N ghia L e prefereert X am arin. T eam leider R ém on heeft aangegeven dat het platform gebruikt m oet w orden dat het beste aansluit op de w ensen en eisen. Ik besloot daarom om de docum entatie van X am arin te bestuderen, zodat vervolgens pakketselectie uitgevoerd kan w orden.
U it een artikel op X am arin blijkt dat m et dit platform native applicaties geheel in de program m eertaal C # gebouw d kunnen w orden ("C reate native iO S , A ndroid, M ac and W indow s apps in C #", z.j.). A ndroid en A pple ondersteunen beide verschillende program m eertalen voor hun apparaten. A ndroid applicaties w orden geschreven in Java en die van A pple in O bjective -C (of S w ift). D it heeft tot op heden altijd een knelpunt gevorm d. O ntw ikkelaars die beide ontw ikkeltalen eigen zijn, zijn schaars. O ok m oet een app tw ee keer gebouw d w orden. D at is kostbaar en tijdsintensief. H et alternatief w as een P honeG ap app. D at zijn echter geen native applicaties, m aar hybride apps.
M et X am arin kunnen dus apps geheel in C # ontw ikkeld w orden. D e native U I en A PI’s kunnen aangeroepen w orden. H ierdoor ervaart de gebruiker de native perform ance. K ennis van beide ontw ikkelm ethodes blijft echter noodzakelijk. D e program m eertaal is dan w el gelijk, beide hebben hun eigen ontw ikkelm ethodes. A ndroid gebruikt bijvoorbeeld X A M L en A ctivity’s (scherm en). iO S pakt het heel anders aan. Z ij m aken gebruik van delegates en het M V C principe. D aarnaast verschillen hun codebibliotheken drastisch van elkaar.
O m die beperking te m inim aliseren, is X am arin F orm s ontw ikkeld. F orm s is als het w are een extra platform bovenop het huidige. H et heeft een eigen codebibliotheek die door de com piler vertaald w ordt naar iO S, A ndroid en W indow s Phone code. In F iguur 6.2 is te zien hoe dat in zijn w erk gaat. A an de linkerzijde w ordt een pagina aangem aakt m et behulp van objecten uit de F orm s bibliotheek. D e com piler handelt het verder intern af. H et resultaat zijn drie apps die gebouw d zijn m et de native scherm elem enten. V andaar het m erkbare verschil in uiterlijk.
F i g u u r 6 . 2 : X a m a r i n F o r m s v o o r b e e l d ( B r o n : h t t p s : / / x a m a r i n . c o m / f o r m s )
6.1.1.2 Pakketselectie tussen Xamarin en PhoneGap
T en slotte is er pakketselectie uitgevoerd tussen X am arin en P honeG ap. H ierm ee kan pragm atisch de beste kandidaat gekozen w orden. V an L eeuw en (2007) heeft een selectieproces in kaart gebracht. D eze bestaat uit: bedrijfsanalyse, analyse huidige situatie, analyse gew enste situatie, vaststellen m ogelijke oplossingen en selecteren definitieve oplossing. D oor m iddel van deze m ethode kan een product gekozen w orden dat aansluit op de w ensen en eisen. O ok w ordt rekening gehouden m et belangrijke aspecten die over het hoofd gezien kunnen w orden.
H et doorlopen van het gehele selectieproc es is bij dit project overbodig om dat de keuze gem aakt m oet w orden tussen tw ee, voor C G I bekende (en gebruikte), producten. A lleen de huidige en gew enste situatie zijn geanalyseerd. V ervolgens is een definitieve keuze - definitief voor deze selectie - gem aakt.
U it de analyse van de huidige situati e bleek dat C G I bekend w as m et beide producten. Z ow el X am arin als PhoneG ap is in eerdere projecten gebruikt. E r w ordt onderzocht of de gew enste functionaliteiten gerealiseerd kunnen w orden op beide platform en. D aarnaast w ordt ook gekeken in w elke m ate de platform en bijdragen aan de volgende aspecten: perform ance, security, bruikbaarheid en overdraagbaarheid.
In de gew enste situatie w ordt het platform gebruikt dat het m eest aan de gestelde eisen en aspecten voldoet. E en belangrijk punt is de overdraagbaarh eid naar toekom stige klanten . Z ij m oeten m et m iniem e m oeite de app kunnen branden.
B ij het selecteren van de definitieve oplossing zijn de w ensen en eisen in kaart gebracht. P er requirem ent is gekeken naar de m ogelijkheden. D eze w orden tegen elkaar afgewogen en voorzien van een beoordeling. T en slotte w orden de beoordelingen bij elkaar opgeteld w at resulteert in tw ee totaal scores. D eze w orden m et elkaar vergeleken voor de eindkeuze. H et resultaat is te zien in F iguur 6.3.
17
F iguur 6.3 : P akketselectie tussen X am arin en P honeG ap
D e conclusie is als volgt. O p veel punten scoort X am arin hoger. E en belangrijke afw eging is de overdraagbaarheid naar toekom stige klanten. V oor X am arin m oet één extra licentie w orden aangeschaft. D e Indie license is voldoende om w ijzigingen aan te brengen aan de app. D ie licentie kost m aandelijks 25 dollar. V oor beide producten m oet een A pple en A ndroid developers licentie aangeschaft w orden. D it kost de klant 99 dollar per jaar voor A pple en eenm alig 25 dollar voor A ndroid . T evens m oet m en in het bezit zijn van W indow s en A pple pc om op te testen en
com pileren. H ieruit is besloten om X am arin te adviseren. D it raam w erk scoort op vele punten beter
dan P honeG ap en een licentie van 25 dollar per m aand vorm t w aarschijnlijk geen drem pel voor bedrijven.
6.1.2 Scrumprocessen inrichten
B ij het inrichten van de scrum processen heb ik de Product B acklog aangevuld m et user story’s, acceptatiecriteria geschreven en een selectie gem aakt voor de eerste sprint.
T en eerste is het Product B acklog aangem aakt. C G I had een account ter beschikking gesteld voor V isual Studio O nline. O p die w ebsite staat een om geving klaar w aarin de scrum processen ingericht kunnen w orden. D e requirem ents en use cases uit het initiatiedocum ent heb ik gebruikt bij het aanm aken van de user story’s. O ok kw am de prioritering die ik gedaan had van pas. E lke story is daarvan voorzien. S tory’s m et een hoge prioriteit w orden autom atisch bovenaan geplaatst.
H et initiatiedocum ent heb ik gebruik voo r de story’s om dat daarin de requirem ents en use cases al staan opgesteld. D eze zijn reeds al besproken en overlegt m et de stakeholders. A lleen een vertaalslag w as nodig om dat user story’s anders beschreven w orden. D eze w orden norm aliter op de volgende m anier geschreven: als {persoon} w il ik dat {actie/w ens}.
D e opdrachtgever Franc B uve heeft toegang tot deze om geving. H ij kon de user story’s bekijken en valideren.
T en tw eede zijn de acceptatiecriteria vastgesteld. A cceptatiecriteria geven zow el aan m ij als aan de opdrachtgever duidelijkheid w anneer de app, sprint en of taak af is. D e app is afgerond w anneer de volgende punten afgestreept zijn:
• D e u s e r s t o r y ’ s m e t d e h o o g s t e p r i o r i t e i t z i j n a f g e r o n d ; • H e t v o ld o e t a a n d e n ie t - fu n c t i o n e l e e i s e n ;
o Com m unicatie tussen CiM S en de app is beveiligd;
o D e laadtijd voor het ophalen van laadpalen bedraagt m axim aal 3 seconden; • C o d e i s v o o r z i e n v a n co m m en t aar ;
• E i n d p r e s e n t a t i e i s g e g e v e n ;
• G e h e l e p r o j e c t i s o v e r g e d r a g e n a a n F ra n c B u v e .
Iedere sprint is ook voorzien van acceptatiecriteria. D eze zijn bij elke sprint hetzelfde. H et gaat m et nam e om de user story’s en taken. E lke story kan pas afgerond w orden w anneer alle taken doorlopen zijn, de code voorzien is van com m entaar, de functionaliteit uitgebreid is getest door eigen gebruikerstesten en nadat het is bekeken/goed gekeurd door F ranc B uve. V erder m oet elke sprint voorzien zijn van docum entatie w aarin het proces beschreven staat.
D e acceptatiecriteria m oet en echter w el haalbaar zijn. T ot zover is er een globale planning gem aakt die niet tot in detail is voorzien van activiteiten. D it is ook niet m ogelijk bij S crum . D esondanks m oet de haalbaarheid bekeken w orden. O p dit m om ent zijn er negen user story’s m et een ho ge prioriteit: de ‘m ust haves’ uit het initiatiedocum ent. D eze zouden onderverdeeld kunnen w orden in negen sprints. D at zou betekenen dat voor het behalen van de m inim ale eisen grofw eg één story per sprint w ordt gerealiseerd. D at is in m ijn ogen haalbaar.
T en slotte is er een selectie gem aakt voor de eerste sprint. N u het platform bekend is, m oet eerst de nodige softw are geïnstalleerd w orden. V ervolgens m oet het project aangem aakt w orden en het nodige ingesteld w orden. O ok lijkt het m ij verstandig om stil te staan bij de softw arearchitectuur. D it heeft er toe geleid dat het Product B acklog is aangevuld m et tw ee nieuw e user story’s. D eze krijgen een hoge prioriteit zodat ze direct opgepakt kunnen w orden.
H et Product B acklog is een levend ‘docum ent’. G edurende het proje ct zullen er story’s gew ijzigd en aangevuld w orden . B ij aanvullingen m oet ik kritisch blijven kijken of het project haalbaar blijft. H et installeren en instellen van de benodigde tools is noodzakelijk. E en softw arearchitectuur vooraf bedenken is ook verstandig. H ierdoor kunnen functionaliteiten sneller geïm plem enteerd w orden. O ok voorkom t het spaghetticode w aardoor het project overzichtelijk blijft. W ijzingen kunnen sneller w orden doorgevoerd.
6.1.3 Resultaat
D eze tw ee w eken hebben m eerdere resultaten opgeleverd. A llereerst is het initiatiedocum ent geschreven. D eze is opgenom en in bijlage III. H ierna heb ik de literatuur bestudeerd van C iM S , P honeG ap en X am arin. K ennis die ik daaruit heb opgedaan is beschreven in dit verslag. V ervolgens heb ik de scrum p rocessen ingericht. H ierbij zijn geen fysieke docum enten opgeleverd om dat het in een online om geving staat. T abel 6.3 toont de user story’s die zijn opgenom en in het P roduct B acklog. T a b e l 6 . 3 : U s e r s t o r y ’ s u i t h e t P r o d u c t B a c k l o g U ser story’s • A l s o p d r a c h t g e v e r w i l i k d a t d e a p p o p h e t 3 G e n 4 G n e t w e r k s n e l w e r k t • A l s o p d r a c h t g e v e r e n t e a m l e i d e r w i l i k d a t d e c o m m u n i c a t i e t u s s e n C i M S e n d e A P P b e v e i l i g d i s , z o d a t m i s b r u i k v o o r k o m e n w o r d t . • A l s o p d r a c h t g e v e r w i l i k d a t d e i n t e r f a c e e e n h e l d e r e e n p r o f e s s i o n e l e u i t s t r a l i n g h e e f t . • A l s g e b r u i k e r w i l i k e e n t r a n s a c t i e k u n n e n s t o p p e n v a n u i t d e a p p . • A l s g e b r u i k e r w i l i k e e n t r a n s a c t i e k u n n e n s t a r t e n v a n u i t d e a p p . • A l s g e b r u i k e r m e t e e n b e t a a l p a s , w i l i k e e n o p l a a d p u n t k u n n e n r e s e r v e r e n . • A l s g e b r u i k e r w i l i k e e n o v e r z i c h t v a n m i j n t r a n s a c t i e s k u n n e n i n z i e n . • A l s g e b r u i k e r w i l e e n p r o f i e l p a g i n a h e b b e n d i e i k k a n i n s t e l l e n • A l s g e b r u i k e r v a n d e a p p w i l i k i n k u n n e n l o g g e n a l s i k e e n p a s h o u d e r b e n . • A l s g e b r u i k e r w i l i k o p l a a d p u n t e n k u n n e n m a r k e r e n a l s f a v o r i e t . • A l s g e b r u i k e r w i l i k e e n m e l d i n g k u n n e n m a k e n v a n o n j u i s t e i n f o r m a t i e . • A l s g e b r u i k e r w i l i k o p l a a d p u n t e n k u n n e n b e o o r d e l e n . • A l s g e b r u i k e r w i l i k k u n n e n k i e z e n t u s s e n h e t • A l s o p d r a c h t g e v e r w i l i k d a t d e a p p
19
6.2 Sprint één - De softwarearchitectuur
H et uitgangspunt van sprint één is het bedenken van de softw arearchitectuur voor de app. D aarnaast staat op de planning om de benodigde tools en softw are te dow nloaden en installeren. In T abel 6.4 staan de story’s en bijhorende taken voor deze sprint.
A llereerst w orden de benodigde applicaties geïnstalleerd en geconfigureerd. V ervolgens w ordt de softw arearchitectuur ontw orpen. T ot slot w ordt het resultaat getoond in de vorm van een test.
T a b e l 6 . 4 : U s e r s t o r y ’ s v o o r s p r i n t é é n U s e r s t o r y ’ s T a k e n A l s d e v e l o p e r w i l i k d e s o f t w a r e a r c h i t e c t u u r v a n d e a p p b e d e n k e n • A n a l y s e p a c k a g e d i a g r a m o n t w e r p e n . • S o f t w a r e a r c h i t e c t u u r t e s t e n d o o r m i d d e l v a n e e n t e s t i m p l e m e n t a t i e . A l s d e v e l o p e r w i l i k e e r s t h e t p r o j e c t o p z e t t e n o m . • P r o j e c t a a n m a k e n i n X a m a r i n . • G I T i n s t e l l e n . A l s d e v e l o p e r w i l i k e e r s t e e n n a v i g a t i e m a p o n t w e r p e n . • N a v i g a t i e m a p c r e ë r e n m e t U M L . • N a v i g a t i e m a p o p n e m e n i n i n i t i a t i e d o c u m e n t . T en eerste is het project aangem aakt. D e integrated developm ent environm ent (ID E ) van X am arin w ordt gebruikt als ontw ikkelom geving . E en naam m oet opgegeven w orden bij de aanm aak van het project. Ik heb besloten om de app C hargeM e te noem en. V erder in dit verslag zal deze naam gehanteerd w orden. V erder is er een lokale G IT repository aangem aakt. D eze w ordt gesynchroniseerd m et de T F S repository van V isual S tudio O nline.
V ervolgens is het an alyse packagediagram ontw orpen. H ierm ee kan de softw arearchi tectuur gerepresenteerd w orden. C hargeM e is opgedeeld in drie losse projecten. E en project voor iO S , A ndroid en een gedeelde codebibliotheek . D e platform specifieke projecten bevatten hun platform gebonden klassen. B ijvoorbeeld de opstartklasse en de platform specifieke scherm en en code.
H et gedeelde codebibliotheek heet C hargeM e. C hargeM e.iO S en C hargeM e.A ndroid hebben een referentie naar dit project. N aast de verschillende lagen, heeft deze package ook een gedeelde U I- en applicatie-laag. D eze zijn bedoeld voor de scherm en en controllers van het F orm s platform . Ik ga gebruik m aken van het M V C design patroon: view s kom en in de U Ilaag, controller in de applicatie -laag en m odellen in de business -laag.
D e verschillende lagen hebben alle hun eigen verantw oordelijkheid. D e B usinessL ayer bestaat uit de m odellen en m anagerklassen. D e m anagers zijn het aanspreekpunt voor de U I- en applicatie-laag. D e andere lagen kunnen zij niet direct benaderen. A lleen de B usinessL ayer kan dat, opdat spaghetticode w ordt voorkom en. D e S ervice- en A ccesL ayer zijn bedoeld voor het ophalen en versturen van data naar externe en interne bronnen. F iguur 6.4 illustreert het analyse packagediagram . • A l s d e v e l o p e r w i l i k e e n k o p p e l i n g m a k e n m e t C i M S , z o d a t d a t a u i t d a t s y s t e e m g e b r u i k t k a n w o r d e n i n d e a p p . • A l s d e v e l o p e r w i l i k d e s o f t w a r e a r c h i t e c t u u r v a n d e a p p b e d e n k e n • A l s o p d r a c h t g e v e r w i l i k d a t h e t h o o f d s c h e r m w o r d t v o o r z i e n v a n e e n g e o g r a f i s c h e m a p • A l s d e v e l o p e r w i l i k e e r s t e e n n a v i g a t i e m a p o n t w e r p e n . • A l s d e v e l o p e r w i l i k e e r s t h e t p r o j e c t o p z e t t e n .
F i g u u r 6 . 4 : A n a l y s e p a c k a g e d i a g r a m C h a r g e M e
E en softw arearchitectuur bedenken , w ordt vaak niet gezien als agile. E en stuk vrijheid gaat verloren . H et is toch verstandig om stil te staan bij softw arearchitectuur. D at blijkt ook uit een artikel op C G I “A gilisten kunnen succesvoller w orden als ze de projectcontext m eenem en in hun oordeel over het nut van architectuur” (P oort, 2013). D e softw arearchitectuur w ordt vanaf een andere invalshoek bekeken. D eze biedt een goede basis om m ee te starten, m aar staat niet vast. G edurende het project kan het aangepast w orden. Ik heb besloten om gebruik te m aken van een analyse packagediagram . A nalyse diagram m en w orden niet tot in detail ontw orpen. D at is gunstig voor S crum .
D eze softw arearchitectuur heb ik toegepast om dat het de cohesie m axim aliseert en koppelingen m inim aliseert. H ierdoor w ordt het systeem robuuster . O ok kom t het ten goede van de beheerbaarheid. A rlow en N eustadt (2011, p. 235) en R ozanski en E oin (2008, p. 294) concluderen dat ook.
D e softw arearchitectuur is gebaseerd op die van A S P.N E T M V C . X am arin stelt een gelijke architectuur voor in hun guides. D e D ata- en S erviceA ccesL ayer zijn gebruikt om dat de app data ophaalt en verstuurt naar interne en externe bronnen. D eze lagen bieden een scheidingslaag door m iddel van ‘repository’s’. E en repository krijgt in allerlei vorm en data binnen. H et is zijn verantw oordelijkheid om die te converteren naar klassen binnen het systeem . F iguur 6.5 toont een voorbeeld van de w erking van deze lagen.
21
businessL ayer aangeroepen. D ie roept op zijn beurt de repository aan in de D ataA ccesL ayer. D eze spreekt vervolgens de D ataL ayer aan. H etzelfde principe geldt voor de service acceslaag. In F iguur 6.6 is het resultaat te zien.
F i g u u r 6 . 6 : S o f t w a r e a r c h i t e c t u u r t e s t
6.3 Sprint twee - Hoofscherm en wijzigbaarheid
In sprint tw ee kom en de volgende tw ee story’s aan de orde: bedenken en im plem enteren van het hoofdscherm respectievelijk een systeem bedenken die de w ijzigbaarheid ten goede kom t. H et hoofdonderdeel en tevens startpunt van de app, is het hoofdscherm . D it scherm is nodig om verder te kunnen w erken aan de vervolg scherm en. O ok w ordt in een vroeg stadium de m ogelijkheden van de geografische m ap onderzocht. D aarna w ordt een systeem bedacht die de w ijzigbaarheid bevordert. D e story’s zijn w eergegeven in T abel 6.5.
T a b e l 6 . 5 : U s e r s t o r y ’ s v a n s p r i n t t w e e S t o r y ’ s T a k e n A l s o p d r a c h t g e v e r w i l i k d a t h e t h o o f d s c h e r m w o r d t v o o r z i e n v a n e e n g e o g r a f i s c h e m a p . • U I v a n h o o f d s c h e r m o n t w e r p e n . • H o o f d s c h e r m i m p l e m e n t e r e n . • L a a d p a l e n t o n e n o p d e m a p ( t e s t d a t a ) . • F i l t e r m o g e l i j k h e i d m a k e n t u s s e n a c t i e v e e n n i e t a c t i e v e l a a d p a l e n . • Z o e k f u n c t i o n a l i t e i t i m p l e m e n t e r e n i n d e m a p , z o d a t n a a r e e n l o c a t i e w o r d t g e n a v i g e e r d d . m . v . e e n a d r e s . • Z e l f e e n g e b r u i k e r s t e s t u i t v o e r e n . A l s o p d r a c h t g e v e r w i l i k d a t d e a p p g e m a k k e l i j k t e w i j z i g e n i s , z o d a t k l a n t e n d i e d e a p p o v e r n e m e n e e n v o u d i g b r a n d i n g k u n n e n t o e p a s s e n . • N a d e n k e n o v e r e e n m o g e l i j k s y s t e e m ( d e s i g n ) . • D e s i g n i m p l e m e n t e r e n . • Z e l f e e n g e b r u i k e r s t e s t u i t v o e r e n .
6.3.1 De hoofdschermen
A llereerst heb ik de U I voor de hoofscherm en ontw orpen. H oew el het U I niet vast staat, is het bedenken van een eerste opzet verstandig. E r m oet rekening gehouden w orden m et het uiterlijk dat A ndroid en iO S hanteert. D e opdrachtgever w enst dat de app ergonom isch is in het gebruik. O ok een heldere en professionele uitstraling is vereist. E en interface die clean is en gebruik m aakt van platform afhankelijke com ponenten, draagt bij aan de w ens van de opdrachtgever. In F iguur 6.7 zijn de verschillen tussen iO S en A ndroid m erkbaar. H et behouden van de native elem enten is w enselijk voor de ergonom ie. D aarnaast draagt het bij aan de w ens voor een professionele en heldere interface.
F i g u u r 6 . 7 : U I h o o f d s c h e r m e n
V ervolgens is m et het design het hoofdscherm geïm plem enteerd. M et X am arin F orm s heb ik een hoofdpagina aangem aakt. E en geografische m ap heb ik daaraan toevoegd. D e S erviceA ccesL ayer heb ik gevuld m et test data. D e data w ordt getoond in de geografische m ap. O ok heb ik een sw itch gem aakt. D aarm ee kunnen laadpalen gefilterd w orden op beschikbaarheid. V erder is de m ap voorzien van een zoekvenster. D e gebruiker kan daarin een adres typen. E en lijst m et adressen w ordt vervolgens getoond. D e m ap navigeert naar het geselecteerde adres.
In F iguur 6.8 is het klassendiagram te zien. H et is volgens de softw arearchitectuur in paragraaf 6.2 gebouw d. D e service laag is uitgebreid m et een C iM S-repository-klasse. D eze klasse spreekt de klasse aan die uiteindelijk een koppeling heeft m et de R E S T A P I van C iM S . V oor nu stuurt die alleen test data. D e repository vertaalt die data naar een lijst van C hargepoints. D eze lijst w ordt bijgehouden in de m anagerklasse. Ik heb een abstracte generieke m anagerklasse geschreven om dat er m eerdere m anagerklassen in vervolg sprints kom en.
D e handige m apping van X am arin Form s brengt ook nade len m et zich m ee. Z o blijkt bij het im plem enteren van de hoofdpagina’s. D e speld -knoppen - de spelden w aarm ee een punt op de m ap gem arkeerd w ordt - in de geografische m ap bijvoorbeeld. H et uiterlijk kan niet zom aar gew ijzigd w orden; F orm s heeft nog een gelim iteerde interface. D it blijkt ook bij veel andere elem enten zo te zijn. K ort sam engevat: de gehele interface van A ndroid en iO S zijn nog niet volledig vertaald in F orm s.
D e bruikbaarheid van F orm s w ordt nog een keer onderzocht . H oew el het uitgangspunt is om het uiterlijk van de native elem enten niet te veel te veranderen, vorm t het w el een knelpunt. T w ee opties blijken m ogelijk: gebruik m aken van zelf geschreven renderers en de D ependency Service of geen gebruik m aken van F orm s. H et laatste, Form s niet gebruiken, betekent dat beide platform en apart ontw ikkeld w orden.
E erst kijk ik naar de zogeheten ‘custom renderers’ en ‘D ependency S ervices’ van F orm s. M et dat systeem kan de native functionaliteit aangeroepen w orden. H ierdoor is het m ogelijk om , w annee r het nodig is, platform specifieke im plem entatie bij te bouw en. D eze code kom t te staan in de platform specifieke projecten. D e ontw ikkelaar m oet de ‘uitbreiding’ w el voor elk ondersteund platform apart ontw ikkelen.
H et alternatief is de scherm en per platform zelf ontw ikkelen. F orm s w ordt dan niet gebruikt. H et project C hargeM e bestaat dan alleen uit de business rules en data- en service laag. D e U I en applicatie-laag staat in de platform specifieke projecten. P er platform w orden de scherm en naar
w ens ontw ikkeld. U itgebreide kennis van beide platform is noodzakelijk, w ant je m oet bekend zijn
