Notificatie voor snelle hulp

(1)

(2)

(3)

Notificatie service voor snelle hulp

Procesverslag

Auteur : Remco van Bers

Datum : 17 juni 2011

Versie : 1.0

Afstudeerbedrijf : Logica Nederland BV

Divisie : Working Tomorrow

Practice : JAVA

Bedrijfsbegeleiders : mr A.J. (Bert) de Neef rm Bedrijfsmentor : ing. E. (Erik) Pronk Onderwijsinstelling : Avans Hogeschool

Opleiding : Informatica – Software Engineering Examinator : ir. J. (Jan) Montizaan

(4)

page 4 of 39

Logica is a business and technology service company, employing 39,000 people. It provides business consulting, systems integration and outsourcing to clients around the world, including many of Europe's largest businesses. Logica creates value for clients by successfully integrating people, business and technology. It is committed to long term collaboration, applying insight to create innovative answers to clients‟ business needs.

Logica is listed on both the London Stock Exchange and Euronext (Amsterdam) (LSE: LOG; Euronext: LOG).

More information is available at www.logica.com.

Copyright statement:

This document contains information which is confidential and of value to Logica. It may be used only for the agreed purpose for which it has been provided. Logica‟s prior written consent is required before any part is reproduced. Except where indicated otherwise, all names, trade marks, and service marks referred to in this document are the property of a company in the Logica group or its licensors.

(5)

Versiebeheer

Versie Omschrijving v 0.1 Conceptversie

V 0.2 Feedback verwerkt en verbetering zinsbouw na feedback V 0.3 Feedback verwerkt V 0.3 Feedback verwerkt V 0.4 Feedback verwerkt V 0.5 Feedback verwerkt V 1.0 Final Tabel 1: Versiebeheer

Distributielijst

Naam Instantie Rol / Functie

Robin Mastenbroek Working Tomorrow Ter review

Jan Montizaan Avans Hogeschool Ter review

Erik Pronk Logica Ter review

Bert de Neef Working Tomorrow Ter review

(6)

page 6 of 39

Adresgegevens

Examinandus

Naam : Remco van Bers

Straat / Nummer : Achterom 50 Postcode / Plaats : 4811 LT Breda Telefoonnummer : 06-27576854

E-mailadres : info@remcovanbers.nl

Onderwijsinstelling : Avans Hogeschool Academie voor ICT & Business Afstudeerrichting : Informatica – Software Engineering

Studentnummer : 2000671

Examinator

Naam : ir. J. (Jan) Montizaan E-mailadres : jt.montizaan@avans.nl Telefoonnummer : 076-5250899

Bedrijfsgegevens

Naam : Logica Nederland BV

Afdeling : Working Tomorrow

Straat / Nummer : George Hintzenweg 89 Postcode / Plaats : 3068 AX Rotterdam

Bedrijfsbegeleiders

Naam : mr A.J. (Bert) de Neef rm Telefoonnummer : +31 88 564 6958

E-mailadres : bert.de.neef@logica.com Functie : Projectleider Working Tomorrow

Bedrijfsmentor

Naam : ing. E. (Erik) Pronk

Telefoonnummer : +31 (0)10 253 7000 E-mailadres : erik.pronk@logica.com Functie : Solution Architect

Practice Manager

Naam : Drs. J. (Jan) Willems Telefoonnummer : +31 88 56 47 916 E-mailadres : jan.willems@logica.com

(7)

Logica - Notificatie service voor snelle hulp Contents

“Notificatie voor snelle hulp”, is een applicatie op het Android platform die er voor zorgt dat mensen met elkaar in contact gebracht kunnen worden. Dit gebeurt doordat mensen die bij elkaar in de buurt zijn, gecheckt door (A)GPS locatie, een notificatie krijgen dat er iemand in de buurt iets nodig heeft. De gemaakte Android applicatie bevat de mogelijkheid een hulpvraag aan te maken en daarnaast ook te reageren op hulpvragen die in jouw buurt zijn gesteld. Er is eerst een Plan van Aanpak geschreven. Hierin is de probleemstelling gedefinieerd. Daarbij is globaal de oplossing bedacht die nu is uitgevoerd. Er is gekeken waarom er een Android applicatie zal worden gemaakt. Door middel van verankering zijn de verschillende disciplines vastgesteld die zullen worden gebruikt tijdens de bouw en ontwikkeling van de applicatie. Er is gekozen voor de RUP methodiek voor de ontwikkeling van de Android applicatie. In het vision document zijn de functionele eisen en niet-functionele eisen vastgesteld in samenspraak met de opdrachtgever. Door middel van een MoSCoW lijst zijn de functionele eisen daarna geprioriteerd. Van de belangrijkste eisen zijn ook use cases uitgewerkt.

In het Software Architect Document zijn de functionele en niet-functionele eisen verwerkt in de architectuur die de applicatie gaat krijgen. Zo zijn er verschillende diagrammen gemaakt waarin de uitwerking van de applicatie is gedefinieerd.

Nadat de architectuur bekend was, is er een start gemaakt met de applicatie. Deze Android applicatie is in verschillende iteraties gebouwd en deze zijn met elkaar geïntegreerd.

De volgende conclusies kunnen getrokken worden: het project is goed verlopen maar er zijn wel hobbels geweest die de ontwikkeling hebben gedrukt, alle hoogst geprioriteerde functionaliteiten zijn geïmplementeerd in de applicatie en de applicatie heeft een demogehalte zoals ook gewenst is tijdens de start van het project.

Daarnaast zijn er twee aanbevelingen. De eerste aanbeveling is dat er maatschappelijk onderzoek wordt uitgevoerd naar de gewenstheid van de applicatie indien deze voor het grote publiek gebruikt zal worden. De tweede aanbeveling is een verbetering van de applicatie op server niveau. Hiervoor zijn andere (betere) technieken voor handen dan de gebruikte technieken die nu te veel implementatietijd kostten voor dit project.

(10)

Logica - Notificatie service voor snelle hulp Voorwoord

page 10 of 39

VOORWOORD

Vier jaar studie is bijna ten einde. Het laatste toetsmoment van mijn studie is deze afstudeerstage bij Logica Working Tomorrow.

Afstuderen bij een groot bedrijf. Door onder andere deze wens ben ik bij Logica terecht gekomen. Samen met Working Tomorrow, het afstudeerprogramma binnen Logica, is er een opdracht samengesteld die mijn interesse heeft. Namelijk het bedenken en ontwerpen van een applicatie. Het liefst een opdracht geschikt voor een mobiele device of het mobiele gebied. Zoals Android of iOS (iPhone). Mijn opdracht is geworden: “Notificatie voor snelle hulp”. Een Android applicatie maken dus.

Working Tomorrow is een unieke ervaring te noemen. Je bent samen met veel andere afstudeerders bezig met allemaal hetzelfde doel. Binnen de opgegeven tijd afstuderen met een zo‟n hoog mogelijk cijfer. De sfeer tussen allemaal studenten is natuurlijk ook heel anders dan een sfeer bij collega‟s die niet afstuderen.

Een afstudeertraject voer je wel alleen uit, maar het traject beleef je niet in je eentje. Ik wil daarom Arnold bedanken voor de discussies in de trein over hoe we onze opdrachten vorm konden gaan geven. Robin en Bert dank ik voor hun feedback op alle producten die ik heb opgeleverd. Voor de rest heb ik veel aan mijn mentor Erik gehad die ook alle producten heeft beoordeeld en zijn feedback heeft gegeven. Als laatste wil ik Marja bedanken voor het nakijken van dit document op taaltechnisch gebied. Het leest nu allemaal net een stukje makkelijker.

(11)

Logica - Notificatie service voor snelle hulp Inleiding

1 INLEIDING

“Pang”, een lekke band en geen spullen bij om het te plakken. Wat nu? Die laatste kilometers naar huis lopen? Nee, je maakt gebruik van de applicatie „Help mij‟ op je smartphone. Je gaat naar de applicatie toe, vult in dat je een lekke band hebt en voor je het weet komt er iemand uit de buurt aangelopen met een bandenreparatiedoos. Werkt veel sneller dan bij elk huis apart aanbellen en hopen dat de bewoners willen en kunnen helpen.

Dit project gaat over de technische realisatie van deze applicatie. Een applicatie die er voor gaat zorgen dat mensen die bij elkaar in de buurt zijn, met elkaar in contact kunnen komen voor oplossingen van alledaagse, kleine problemen. Zoals een lekke band.

Dit project zal bestaan uit het maken een applicatie voor het Android besturingssysteem en het inrichten van een webserver die gegevens zal opslaan en mensen met elkaar in contact zal brengen.

In dit document zal eerst dieper op het probleem worden ingegaan. Wat is de precieze

probleemstelling? Als deze bekend is, wordt het tijd om het Plan van Aanpak te gaan realiseren. Voor elk project worden er methoden en technieken gebruikt. Deze zullen worden beschreven na het Plan van Aanpak. Elk project heeft resultaten die uitkomst zijn van onderzoek naar de methodes en technieken en die komen uit de uitvoering van het project.

Natuurlijk worden er conclusies getrokken. Ook zijn er enkele aanbevelingen geformuleerd. Dit document zal de belangrijkste, tijdens het project, genomen beslissingen belichten en beargumenteren. Denk hierbij onder andere aan waarom juist deze niet-functionele eisen zijn gebruikt en hoe is de architectuur van het project daarop afgestemd. Welke kennisgebieden worden gebruikt en hoe worden de kennisgebieden gebruikt. .

(12)

Logica - Notificatie service voor snelle hulp Organisatie

page 12 of 39

2 ORGANISATIE

2.1 Logica

Logica verleent zakelijke en technologische diensten. Wereldwijd telt Logica 39.000 medewerkers. Het bedrijf biedt zakelijke dienstverlening, systeemintegratie en outsourcing voor klanten over de hele wereld. Onder de klanten bevinden zich de grootste bedrijven van Europa. Logica helpt haar klanten door mensen, business en technologie op een succesvolle manier te integreren. Langlopende samenwerking staat centraal. Logica maakt gebruik van haar branchekennis om innovatieve oplossingen voor haar klanten te realiseren.

Logica staat genoteerd aan de beurs van Londen en aan Euronext in Amsterdam (LSE: LOG; Euronext: LOG).

2.2 Working Tomorrow

De opdracht wordt uitgevoerd binnen het programma Working Tomorrow (WT). Logica heeft dit programma opgestart om studenten de gelegenheid te geven af te studeren op een innovatieve opdracht met goede begeleiding. Innovatie staat centraal. Innovatief wat betreft technologie, concept of methodiek. Zo werken er studenten aan agent technologie, Multi touch technologieën, Augmented Reality, Smart Grids en slimme meters en mobiele oplossingen. Working Tomorrow is nu op 5 vestigingen van Logica in Nederland aanwezig, en biedt jaarlijks plaats aan circa 200 studenten van HBO en WO. Op iedere vestiging is een projectleider van Working Tomorrow die de studenten begeleidt.

Het Working Tomorrow programma heeft 4 hoofddoelen:

1. Een centrale plaats bieden waar studenten uitdagende en innovatieve afstudeerprojecten kunnen uitvoeren.

2. Het werven van toekomstige werknemers.

3. Verhogen van de reputatie van Logica op het gebied van innovatie.

4. Demo‟s en resultaten van projecten gebruiken voor het verkrijgen van betaalde opdrachten en vergaren van kennis.

Alle studenten die bij WT afstuderen zijn daarnaast ook onder gebracht bij een practice, een afdeling binnen Logica, die nauw aansluit bij de opdracht.

(13)

Logica - Notificatie service voor snelle hulp Organisatie

2.3 Begeleiding

Alle studenten die afstuderen bij Working Tomorrow, worden bij een practice geplaatst die past bij de richting van het project. Een student krijgt naast procesmatige begeleiding vanuit Working Tomorrow ook inhoudelijke begeleiding vanuit de practice.

Dit project valt onder de practice JAVA. Daarnaast is er vanuit Avans Hogeschool ook begeleiding. Deze begeleiding komt van de docent Jan Montizaan.

(14)

Logica - Notificatie service voor snelle hulp Probleemanalyse

page 14 of 39

3 PROBLEEMANALYSE

Heeft u al eens langs de weg gestaan met een platte band terwijl u juist die ochtend uw bandplakspullen bent vergeten? Of heeft u weleens een voorwerp nodig dat u niet heeft en uw directe omgeving ook niet? Dit zijn voorbeelden van problemen waarbij hulp van derden gewenst kan zijn.

Om een oplossing hiervoor te kunnen ontwikkelen is de volgende initiële opdrachtomschrijving geformuleerd:

“Soms heb je acute hulp nodig en zijn veel mensen in staat om met niet al te veel moeite jou te helpen, als ze maar wisten dat je hulp nodig had. Denk bijvoorbeeld aan iemand die een paar kilometer na het tankstation zonder benzine staat. Hij zou via een Location Based SMS om hulp kunnen vragen en het tankstation zou een jerrycan met benzine mee kunnen geven aan een klant die de richting op gaat. Dit concept zien we graag verder uitgewerkt en geïmplementeerd.”

Deze omschrijving is opgezet door een projectleider binnen het Working Tomorrow project. De definitie die uit de omschrijving kan worden gehaald is: De opdrachtgever wil een

oplossing voor mensen die hulp van derden nodig hebben en deze niet mondeling kunnen bereiken.

In de omschrijving wordt Location Based SMS als mogelijkheid genoemd van een techniek om het probleem te tackelen. Het is te voorbarig om direct deze mogelijkheid over te nemen als daadwerkelijk oplossing.

Er zal een (kort) onderzoek worden uitgevoerd om de te gebruiken techniek vast te stellen. Doordat de doorlooptijd van het project kort is en de doorlooptijd vast staat, zal er in het Plan van Aanpak (PvA) goed moeten worden gescoped. Daarnaast zal, voor zover het al mogelijk is, een verankering plaats moeten vinden om technieken vast te stellen.

Om het project in goede banen te leiden zal er worden gewerkt conform het Rational Unified Process (RUP) model. Het besluit hiervoor is genomen op basis van het feit dat RUP de mogelijkheid geeft om in verschillende iteraties te werken en dat na elke fase, die wordt doorlopen, een product wordt opgeleverd. Een product in de zin van documenten of applicatie. Door de verschillende iteraties is het nog mogelijk om wensen en eisen van het product bij te stellen indien dit gewenst wordt door een opdrachtgever of omdat er door uitgekomen of juist uitgebleven risico‟s minder of meer wensen en eisen in het systeem kunnen worden geïmplementeerd.

(15)

Logica - Notificatie service voor snelle hulp Plan van Aanpak

4 PLAN VAN AANPAK

Het Plan van Aanpak (PvA) definieert de definitieve opdrachtomschrijving en vormt de basis voor de planning van het project. In komende paragrafen wordt het Plan van Aanpak beschreven dat is opgesteld aan het begin van het project.

4.1 Probleemstelling

Mensen hebben soms een probleem dat kan worden opgelost met behulp van andere mensen die in de buurt aanwezig zijn. Je hebt bijvoorbeeld een lekke band of er is net iets kapot gegaan wat je echt nodig hebt op dat moment. Levensbedreigend is het niet, anders zouden de hulpdiensten wel worden gealarmeerd. Hoe kun je dan in contact komen met mensen die je kunnen helpen? Het is niet makkelijk om tussen al die potentiële mensen de juiste te vinden die je kan helpen en ook nog wilt helpen. Voor dit probleem, het zoeken van de juiste mensen in je omgeving waar je op dat moment bent, wordt een oplossing ontworpen in dit project.

4.1.1 Oplossing

Voor dit probleem zal er een oplossing worden ontwikkeld. Een oplossing om mensen met een niet-urgente hulpvraag in contact te laten komen met andere mensen die deze hulpvraag kunnen beantwoorden. In de samenleving komen steeds meer smartphones. Tevens wordt voorspeld dat Android zal uitgroeien tot de grootste speler van de markt. Daarom is het verstandig om te kiezen voor Android1_.

De keuze is dan ook gemaakt om een applicatie te ontwikkelen die op een telefoon kan draaien met het Android besturingssysteem. De keuze wordt in H4.5 verantwoord. Wel zal er een open architectuur worden gekozen waardoor, op platformspecifieke dingen, de architectuur te gebruiken is voor andere platforms. De koppelingen zullen zoveel mogelijk worden gestandaardiseerd.

De applicatie zal mensen die hulp nodig hebben (hulpbehoevende) en mensen die kunnen helpen (hulpverlener) met elkaar in contact brengen. Dit zal gebeuren door middel van een client-server model. Verderop in dit document wordt uitgelegd waarom er voor deze architectuur is gekozen.

Een hulpbehoevende moet in staat zijn om door middel van een keuzemenu een hulpvraag te selecteren. Daarna moet de locatie worden bevestigd waar de hulpbehoevende zich op dat moment bevindt. Als deze keuzes zijn gemaakt, zal er door middel van een pushfunctionaliteit een bericht naar alle hulpverleners in de buurt, die mogelijk in staat zijn om te helpen, worden verzonden.

Deze kunnen dan naar wens reageren op de hulpvraag waarna de hulpbehoevende een bericht krijgt dat er hulp onderweg is.

4.2 Verankering en relevantie

De opdrachtgever van dit project, een architect binnen Logica, heeft als doel gesteld, dat de combinatie van technieken wordt uitgeprobeerd met een demo als resultaat. In de conclusies zal hierover meer worden verteld.

Het project heeft een applicatie gedeelte en een server gedeelte. Zie Figuur 8 Package diagram Het applicatie gedeelte zal op Android gaan draaien. Zie H4.5. Android draait dan weer op verschillende smartphones.

(16)

page 16 of 39

Tijdens de scoping van het project is besloten dat het zwaartepunt van het project vooral aan de applicatiekant ligt en dat de webserver wel moet werken maar dat de focus daar niet ligt. Door de expertise in het ontwikkelingteam en de simpelheid van de webserver voor de demo is gekozen om de webserver in PHP te gaan schrijven die vervolgens zijn data opslaat in een MySQL database. De webserver zal een apache service zijn waarbij PHP en MySQL is geïnstalleerd. PHP en MySQL zijn respectievelijk de taal en de database die worden gebruikt aan de kant van de webserver.

De communicatie tussen de cliënt en de webserver zal geschieden door XML verkeer via het internet. Om de communicatie goed te laten verlopen en om de applicatie uitbreidbaar en transparant te houden, zal met UML de architectuur worden verduidelijkt met verschillende diagrammen.

4.3 Randvoorwaarden en risico’s

Randvoorwaarden zijn er om rekening mee te houden tijdens het uitvoeren van het project. De belangrijkste voorwaarden binnen dit project zijn;

- Binnen de afstudeerperiode: 1 februari 2011 tot en met 17 juni 2011 - Er dient een developer telefoon aanwezig te zijn

- Er dient een webserver aanwezig te zijn

- Er dient expertise op taaltechnisch gebied te worden geregeld voor de documentatie. Naast randvoorwaarden zijn er ook risico‟s tijdens een project. Tijdens het opstellen van het PvA zijn er algemene risico‟s in beeld gebracht en ingeschat. Daarbij zijn maatregelen bedacht voor het geval dat het risico werkelijkheid zou gaan worden.

4.4 Planning

Een goede planning is belangrijk voor een project. De planning ook daadwerkelijk volgen en bijstellen is nog belangrijker, zo niet het belangrijkst tijdens het project.

Om te beginnen zijn alle mijlpalen van het project gedefinieerd. Dit zijn de volgende mijlpalen;

 Plan van Aanpak opleveren

 Concept oriëntatieverslag opleveren  Definitief oriëntatieverslag opleveren  Vision opleveren

 Software Architecture Document opleveren  Concept scriptie opleveren

 Definitief scriptie opleveren  Demo opleveren

Deze mijlpalen zijn omgezet in een planning waarbij de verschillende op te leveren producten en iteraties zijn gedefinieerd met begin- en eindtijd. De initiële planning ziet er als volgt uit:

Plan van Aanpak 01-02-2011 25-02-2011

Oriëntatieverslag 14-02-2011 03-03-2011

Vision 21-02-2011 09-03-2011

Software Architecture Document 22-03-2011 01-04-2011 Iteratie 1 afronden 04-04-2011 15-04-2011 Iteratie 2 afronden 18-04-2011 29-04-2011 Iteratie 3 afronden 02-05-2011 13-05-2011

Demo opleveren 17-06-2011 17-06-2011

Scriptie opleveren 17-06-2011 17-06-2011

In de bijlage is de gehele planning opgenomen. Zoals daar te zien is, zijn de fases van RUP in de planning opgenomen. In de constructie fase wordt er gewerkt met drie iteraties.

(17)

De drie iteraties maken het mogelijk om het creëren van de functionaliteit goed in te plannen. Indien nodig kan er minder of juist meer functionaliteit worden toegevoegd.

Na deze iteraties is het de bedoeling dat de demo wordt opgeleverd.

4.5 Android applicatie

Een Android applicatie is een wens van de opdrachtgever. Daarnaast zijn er geen ontwikkeltools intern beschikbaar om voor bijvoorbeeld iPhone te kiezen. Ook is het ook een opdracht vanuit de JAVA practice. Android is JAVA dus is de keuze voor Android ook logisch. Om breder te kijken dan enkele bekende argumenten, is onderzoek gedaan naar twee andere oplossingen binnen het Android spectrum. Dit onderzoek is uitgewerkt in H5.3

Er is dus gekozen voor Android wegens de volgende argumenten: - Opdrachtgever wil een Android applicatie

- Developer zit bij JAVA practice

- Android is een groot en nog steeds groeiend platform - Developer heeft enige ervaring met Android

De applicatie wordt ontworpen voor algemeen gebruik dus een platform is niet bindend. Met dit argument en de argumenten hierboven is Android de beste keus voor dit project.

(18)

Logica - Notificatie service voor snelle hulp Methoden en technieken

page 18 of 39

5 METHODEN EN TECHNIEKEN

Tijdens het project zijn er veel technieken en een aantal methodes gebruikt om het product te ontwikkelen. De methoden en technieken van de onderstaande gebeurtenissen zullen worden uitgelegd en er zullen argumenten worden gegeven over de keuzes die in de documenten zijn gemaakt:

- Vision - RUP

o Software Architect Document o Android applicatie

- Webserver

Er is gekozen om de RUP methodiek te volgen voor dit project. Meer specifiek, een RUP op maat methodiek. Er was behoefte aan een methodiek die gebruik maakt van iteraties. Hierdoor valt bijvoorbeeld de watervalmethode af. Omdat het eindresultaat vaststaat en is ingeschat dat de te opleverende demo te maken is, zullen de specificaties in het begin van het ontwerp worden vastgesteld. Hierdoor is een scrum (agile) methodiek niet nodig omdat daar per sprint wordt vastgesteld wat er gedaan zal worden. Daarom is er uiteindelijk gekozen voor de RUP methodiek. Daarnaast zijn de fases zo, dat er telkens een eindproduct is dat inzetbaar is als demo. Zo kan er nog worden bijgestuurd mocht dit nodig zijn tijdens het proces.

5.1 Vision

Het vision is een document waarin de requirements worden opgesteld. Ook worden de keuzes gemaakt voor de technieken die worden gebruikt in de volgende fases van RUP.

De methode MoSCoW wordt gebruikt om de functionele eisen te prioriteren. Door de functionele eisen, die in samenwerking met Logica zijn opgesteld, te prioriteren, is de scope van het project nog beter vastgesteld. De functionele eisen die als MUST zijn betiteld, moeten tijdens de oplevering van de demo in de applicatie aanwezig zijn. De technieken die in het vision zijn besproken, zullen in dit hoofdstuk bij Android applicatie en Webserver worden behandeld. In het vision zijn de volgende functionele eisen als MUST geprioriteerd:

- Inloggen

- Hulpvraag maken op basis van locatie - Locatie op Google Maps aangeven - Op hulpvraag reageren

- Notificatie tijdstip mee verzenden

Ook de niet-functionele eisen die relevant zijn voor de applicatie, zijn vastgesteld. In het Software Architect Document zullen deze niet-functionele eisen tegen het architectuele licht worden gehouden op technisch gebied.

Van alle mogelijke niet-functionele eisen zijn de volgende zes eisen door de opdrachtgever als belangrijk aangemerkt:

- Extensibility: Het systeem wordt opgebouwd vanuit het idee dat er doorontwikkeling

plaats zou moeten kunnen vinden. Daarom wordt er rekening gehouden met future growth om het product breder in te kunnen zetten en het gebruiksgemak in positieve zin te verbeteren. Er moet zeker rekening worden gehouden met het realiseren van de should en coulds in de nabije toekomst.

- Privacy: Er moet worden gezorgd dat niet alle gegevens van de mensen die zich

hebben ingeschreven zomaar te benaderen zijn door personen die hiertoe niet bevoegd zijn.

(19)

- Response time: Omdat de applicatie zowel afhankelijk is van de mobiele telefoon

waarop hij draait als van de snelheid van de beschikbare internet verbinding, kunnen er geen beloftes worden gedaan over de totale response tijd van de applicatie. Na het inschieten van een hulpvraag zal de webserver de push server meestal binnen twee minuten een signaal geven om de eerste mensen in de buurt van de hulpvraag te informeren. Het Google Maps aspect heeft een uptime van 99.9%. Ook de webserver van het project heeft een uptime van 99.9%.

- Scalability: Er moet makkelijk geschaald worden. De cliënt moet meerdere servers

aankunnen zodat de capaciteit makkelijk kan worden verhoogd. Hierdoor kan er worden gereageerd als er veel meer gebruikers en/of request komen.

- Security: De gegevens die gebruikt worden, staan in een beveiligde omgeving

waardoor het systeem niet kan functioneren zonder de beschikking van een account en wachtwoord. De beveiligde omgeving zal bestaan uit een verbinding die met SSL is beveiligd.

- Usability: Om het maximale uit de applicatie te halen zal de bediening en de

gewoontes van Android applicaties worden overgenomen in het ontwerp van de GUI van de applicatie.

5.2 Use Cases

Om de functionaliteiten die zijn bedacht body te geven, zijn er voor de MUST en SHOULDs scenario‟s en use cases gemaakt. De uitwerking hiervan is te vinden in de bijlage.

Van het use case model is een hoog niveau gemaakt en een iets uitgebreider niveau. In het hoge niveau staan de twee belangrijkste functionaliteiten. Namelijk het maken van een hulpvraag en het reageren op de hulpvraag. Dat zijn immers de twee functionaliteiten waar de probleemstelling en oplossing ervan om draait. Dat mensen de vraag de wereld in kunnen schieten en dat de juiste mensen hierop kunnen reageren.

De use case model is in UML gemaakt. De scenario‟s en specificaties van de use cases zijn gewoon uitgeschreven in woorden zonder speciale technieken of tools.

5.3 Software Architect Document

In het Software Architect Document zijn de functionele eisen en de niet-functionele eisen uitgewerkt in verschillende views. Deze views zijn gelijk aan de views van het 4 +1 model wat is gekozen. Dit zijn de volgende views:

- Logical view

- Implementation view - Proces view

- Deployment view

Daarnaast zijn de eisen betreffende de architectuur beschreven.

Door middel van de techniek UML zijn er verschillende diagrammen uitgewerkt ten behoeve van het technische ontwerp. Door middel van verschillende Use Cases zijn de belangrijkste functionele eisen uitgewerkt. Hierbij wordt de flow beschreven; welke stappen zijn er nodig voor het bereiken van deze functionaliteit.

Een applicatie ontwikkel je met, verschillende architectuele patterns. Het ligt voornamelijk aan de niet-functionele eisen welke pattern(s) er worden gebruikt tijdens de ontwikkeling van de applicatie. Bij deze applicatie zullen de volgende patterns worden gebruikt;

- Client-Server - MVC

(20)

page 20 of 39

In de tabel hieronder is de architectuele relevantie van elke niet-functionele eis uitgezet.

De logical view laat zien dat het MVC model zal worden gebruikt. Het MVC bestaat uit de volgende 3 lagen;

View:

Deze laag produceert de user interface en geeft de acties die worden uitgevoerd door aan de controllerlaag van de applicatie

Naam niet functionele eisen Architectueel pattern Architecturele relevantie

Extensibility MVC Er is gekozen om het MVC model te gebruiken. Deze beslissing is genomen om te uitbreidbaarheid van de code te kunnen garanderen. Doordat deze uit drie lagen bestaat, kan er gemakkelijk functionaliteit worden toegevoegd, veranderd of verwijderd.

Client-Server De client-server architectuur is ook mede gekozen door deze eis. Door een splitsing van de applicatie en het opslaggedeelte( de server), kunnen de server en/of applicatie gemakkelijk worden vervangen of uitgebreid. Ook wordt het hierdoor mogelijk dat er app‟s voor andere devices worden ontwikkeld. Mocht de server over moeten gaan op een andere oplossing, dan is dit ook te realiseren zonder de applicatie op de devices te moeten aanpassen. Privacy Client-Server De client-server architectuur maakt het mogelijk dat de

gegevens van personen op een centrale server worden opgeslagen in plaats van op de device van een gebruiker. Zodoende heeft enkel de gebruiker acces tot zijn eigen gegevens en niet tot die van anderen. Door middel van SSL en token authenticatie worden de gegevens versleuteld doorgestuurd en kan alleen iemand met valide gegevens inloggen.

Response time

Client-Server Om de onzekerheden over de response time die er zijn niet te vergroten is gekozen om de communicatie tussen cliënt en server met XML te laten plaatsvinden. Deze XMLs zijn klein en eenduidig waardoor de XML geen vertragende factor zal zijn.

Scalability Client-Server Door de client-server architectuur kan de server makkelijker worden opgeschaald indien dat nodig is. De applicatie op een device zal daar niets van merken. Misschien een tijdelijke downtime indien dat niet te voorkomen is.

Security Client-Server Door middel van SSL en token authenticatie worden de gegevens versleuteld doorgestuurd en kan enkel iemand met valide gegevens inloggen. Voor deze beveiliging is de client-server architectuur geschikt.

Nadat iemand is geauthenticeerd wordt er gekeken of de persoon ook geautoriseerd is. Dit zal op de serverkant worden gedaan. Het is dus mogelijk om de beveiliging op te schalen zowel door de server als door uitbreiding van de cliënt beveiliging.

Usability MVC Door voor het MVC model te kiezen kan er altijd makkelijker worden ingesprongen op vernieuwde usability. Alleen de view laag hoeft te worden geüpdatet indien gewenst.

(21)

Controller:

Deze laag communiceert met de view laag en de model laag.

Het verwerkt de acties vanuit de viewlaag en stuurt de modellaag aan indien dat nodig is.

Model:

Deze laag communiceert met de controllerlaag. Het bestaat uit instanties die de informatie van de applicatie bevat.

Het MCV model zal gaan draaien op de applicatiekant van het project. Dit is ook aan te duiden als één deelsysteem. Het project heeft twee deelsystemen. Het andere deelsysteem is de webserver.

In de implementation view is de packagestructuur te vinden die aan de applicatiekant zal worden geïmplementeerd. De volgende packages zullen worden gebruikt:

- View - Model o XML - Controller o XML  Reader  Handler  Writer

De deployment view heeft in eerste instantie gelijkenissen met de implementation view. Alleen beschrijft de deployment view welke servers en software er nodig zijn voor het project. Denk hierbij aan: - Android device - Google services - Webserver o Apache o MySQL o PHP

Dan blijft er één view over. Namelijk de procesview. Voor de procesview is van elke Use Case een activiteitendiagram uitgewerkt. Deze diagrammen zijn allemaal te vinden in de bijlagen. Van het inloggen en het maken van een hulpvraag is een sequencediagram gemaakt. Dit ter verduidelijking van het proces. Van de andere functionaliteiten zijn geen sequencediagrammen gemaakt omdat deze geen toegevoegde waarde hadden voor de overdracht van de documenten. De ontvanger van de diagrammen is namelijk dezelfde persoon als degene die de diagrammen bedenkt.

Figuur 2 Package diagram

(22)

page 22 of 39

Dit geldt voor meer van de documentatie die is gemaakt. Het project is een demo opstelling en er is één uitvoerende medewerker. Hierdoor is zeer uitgebreide documentatie niet nodig. Natuurlijk is er wel voldoende gedocumenteerd om een mogelijke overdracht mogelijk te maken.

5.4 Android applicatie

In hoofdstuk 4.1 is beschreven dat er voor een Android-native applicatie is gekozen. In plaats van een Android-native applicatie zijn er ook nog andere vormen van techniek onderzocht. De volgende technieken zijn onderzocht:

- Website - Titanium - Phonegap Website:

Een alternatieve oplossing is een website ontwikkelen die geoptimaliseerd is voor mobile devices. Het nadeel van een website tegenover een mobiele applicatie is, dat de gebruiker makkelijker gegevens kan manipuleren door in het geheugen gegevens aan te passen. Hiervoor zijn veel plugins beschikbaar voor webbrowsers.

Daarnaast is het belangrijkste tegenargument om dit niet te gaan gebruiken, dat je geen notifications kunt starten zonder dat de website openstaat. Dit is namelijk een essentieel aspect van de gehele applicatie; Het zomaar starten van een notification als er een push is gedaan. Titanium & Phonegap

Alternatieve oplossingen zoals Titanium en Phonegap zijn ook mogelijk. Het zijn twee dezelfde soorten alternatieven. Daarom worden ze hier beide behandeld als één.

Door middel van Titanium en Phonegap applicatie kun je makkelijker voor Android, iOS en blackberry apps maken. Je gebruikt voor de lay-out HTML(5) en CSS en voor de logica zelf gebruik je een Javascript API.

Het voordeel van dit geheel is dat je eenmalig een applicatie maakt en dat je die vervolgens kunt uitrollen op drie verschillende besturingssystemen.

Deze oplossing kan een geschikte oplossing zijn als je niet diep de telefoonfuncties in hoeft te gaan en als de userinterface wat minder belangrijk is. Om een applicatie gebruikersvriendelijk te maken is het verstandig dat je de native userinterface mogelijkheden benut. Iets wat voor de applicatie van dit project een pre is.

Er is ook een nadeel voor het gebruik van deze oplossingen. Je hebt dan niet altijd alle mogelijkheden van de telefoon tot je beschikking. Ook al worden er steeds meer en meer native features (zie Figuur 4 Te gebruiken functions in phonegap) ondersteund.

Je zult altijd afhankelijk zijn van de API die je aangeleverd krijgt en die voornamelijk voor Android, JAVA ondersteunt. Daardoor zul je makkelijker functies missen die je niet of via een omweg kunt gebruiken.

Een voordeel is dat je enkel maar één API hoeft aan te spreken om een applicatie te kunnen ontwikkelen voor meerdere platforms. Je dient alleen wel een nieuwe API te leren met een flinke leercurve. Dit is het grootste nadeel van deze oplossing, waardoor je deze niet gaat gebruiken.

(23)

Figuur 4 Te gebruiken functions in phonegap Δ = gedeeltelijk ondersteunt.

Omdat er een hele nieuwe API moet worden geleerd en omdat alles in Javascript moet worden gemaakt, is dit alternatief geen goede oplossing voor dit project. Ook telt mee dat niet alle functionaliteiten optimaal mogelijk zijn.

Tijdens de uitvoering van het project kwam het volgende artikel[5] aan het licht. Geschreven door Martin Fowler, een expert op gebied van object-oriented analysis en design. Deze trekt dezelfde conclusie als hierboven is genoemd; Een applicatie maken doe je het beste met een native programmeertaal zodat de gebruikers het beste uit een applicatie halen en dat de applicatie ook volgens de (design)standaarden is van het platform.

5.5 Webserver

PHP & MySQL zullen worden gebruikt aan de kant van de webserver. Deze technieken zullen de communicatie verzorgen tussen de database (MySQL) en de applicatie (Android applicatie). De webserver zal de XML‟s ontvangen die worden gestuurd vanuit de applicatie naar de webserver toe. Deze zal ze verwerken, de benodigde dingen doen met de database en een XML terug sturen met het resultaat van de verwerking.

Naast PHP had ook JAVA een mogelijkheid kunnen zijn voor de webserver. JAVA:

Voor het maken en behandelen van XML in JAVA is er een API beschikbaar. Deze API kan een XML op twee manieren behandelen; serially (SAX) of in random acces mode (DOM). Ook om een XML te maken, zijn meerdere oplossingen mogelijk.

Daarnaast zou de backend gebruik maken van token oplossing voor de beveiliging. Hiervoor zijn nog niet heel erg veel oplossingen maar ze zijn wel te vinden op het internet.

(24)

page 24 of 39

PHP:

Om een XML te maken en te behandelen in PHP zijn er verschillende oplossingen. Er is een XMLReader beschikbaar en een XMLWriter. Beide standaardklassen die bij PHP zitten. Daarnaast staan er nog verschillende andere standaard mogelijkheden tot de beschikking. Ook voor tokens zijn er standaardoplossingen beschikbaar. De serverzijde moet wel zelf worden geschreven. Vergelijkingstabel: JAVA PHP Schaalbaarheid ++ ++ Privacy + + Beveiliging + + XML ++ ++

Design patterns algemeen ++ +

Ervaring developer -/+ ++

Conclusie:

De conclusie is dat PHP het meeste geschikt is voor de backend applicatie. Hieronder staan de argumenten voor deze conclusie:

1) Een risico van het project is dat door te weinig kennis het project in gevaar komt. Doordat er al veel kennis van PHP aanwezig is, is er geen leerproces voor het PHP gedeelte en kan de grootste aandacht naar de applicatie zelf gaan; datgene waar dit project voor het grootste deel op is gebaseerd. De PHP kennis ten opzichte van de JAVA kennis is groter en vooral de ervaring met PHP is velen malen groter dan de ervaring met JAVA.

2) In PHP zijn er meer kwalitatief goede voorbeelden te vinden van de situaties die opgelost moeten worden. Hierdoor zal er tijdwinst zijn met het maken van de backend. Daarnaast zullen de voorbeelden ook beter begrepen worden door de ervaring.

3) De JAVA omgeving opzetten en die functioneel krijgen is lastig en zal veel werk met zich meebrengen. Een PHP omgeving goed opzetten is in een paar uur gedaan. Deze tijdinschatting is gemaakt op basis van de ervaring van de developer. Daarnaast is het doel van het project de applicatie en niet de backend. Daarbij is de tijdinvestering een belangrijke factor.

4) De uiteindelijke keuze is zo gemaakt dat de meeste kwaliteit geleverd wordt binnen de tijd die voor dit project staat. Er zou te veel risico worden genomen met de JAVA backend waardoor de kwaliteit van het Android gedeelte in geding zou kunnen komen. Met de PHP oplossing zijn die risico‟s drastisch gereduceerd. Daarbij zal de beoogde applicatie in de prototype fase kleinschalig zijn. De plek waar PHP net wat beter uit de voeten kan dan een zware enterprise omgeving.

(25)

Logica - Notificatie service voor snelle hulp Uitvoering

6 UITVOERING

6.1 Plan van Aanpak

Gestart is met het maken van het Plan van Aanpak(PvA). Het PvA bestaat uit de volgende hoofdstukken:

- Omgeving en Organisatie - Definitie Afstudeeropdracht - Planning

De definitie van de opdracht voor het project beslaat het grootste deel van PvA. Samen met een architect van Logica is overlegd wat de opdracht precies gaat inhouden. Eerst is vastgesteld dat het om een project gaat met een demo als eindoplevering. Deze demo moet aantonen dat mensen die een hulpvraag hebben in contact kunnen komen met mensen in de omgeving die kunnen helpen. Personen in de buurt krijgen dan een notificatie dat er iemand een hulpvraag heeft.

In hoofdstuk 4.1 is te lezen dat er is gekozen voor het Android platform. Verder zijn de eerste resultaten van het brainstormen over de functionaliteit van de applicatie beschreven.

In het vision document is een onderzoek naar Android-native versus andere tools voor Android gedaan en beschreven.

Tijdens het maken van het PvA is duidelijk geworden welke kennisgebieden er tijdens het project aan de orde komen. Een overzicht:

- Backend - Data opslag - XML - JAVA - Android - UML - OOP - RUP - Authenticatie

De backend en data opslag zijn na onderzoek, zoals te lezen is in het vision, PHP en MySQL geworden als kennisgebied en oplossing.

De kennisgebieden backend en data opslag zijn bewust algemeen gehouden omdat deze pas een uitwerking moeten krijgen tijdens de inception fase in het vision document. De te gebruiken techniek voor deze twee kennisgebieden heeft namelijk niet veel te maken met de opdrachtomschrijving en verankering van het project.

(26)

page 26 of 39

Een planning is noodzakelijk voor de voortgang van het project. Om een planning te maken moet duidelijk zijn welke deliverables moeten worden opgeleverd. Uit de lijst van documenten die je volgens RUP kunt maken, zijn een viertal documenten gekozen die relevant voor het project zijn en die opleverbaar zijn. Dit zijn:

- Vision document - Use Cases

- Software Architecture Document

Bij deze documenten is per document een inschatting gemaakt hoeveel dagen nodig zijn om het document te maken. Na deze documenten te hebben ingepland, zijn de iteraties van de Construction fase daarachter ingepland. Eerst zouden zes iteraties van een week ingepland worden. Na overleg is besloten om drie iteraties te maken van twee weken. De Construction fase kan heel goed in drie delen worden opgedeeld. Namelijk het maken van de applicatie, het maken van de backend en het maken van de koppeling tussen de applicatie en de backend. Door deze verdeling in drie stukken is het maken van de applicatie en de backend uit elkaar getrokken en kan de koppeling tussen de applicatie en de backend als een zoveel mogelijk losstaand geval worden ontworpen. Door deze drie iteraties is er ook een werkende applicatie aanwezig aan het einde van een iteratie.

Naast deze opdeling is de conclusie getrokken dat een iteratie van één week te kort zou zijn. Bouwen, testen, bugfixen en procesverslag schrijven zouden dan in één week moeten worden geplaatst. Daarom is gekozen voor telkens één week bouwen. Anderhalve dag testen en gevonden bugs oplossen en dan nog 2 dagen werken aan het procesverslag. Deze indeling is passend voor het project.

Aan het einde zijn de overgebleven 20 dagen als buffer opgenomen mocht er vertraging plaatsvinden in het bouwen van de applicatie of bij het schrijven van het procesverslag. Er bestaat namelijk het risico dat er door redenen, zoals ziekte of tegenslagen, vertraging ontstaat tijdens het ontwerpen of bouwen van het project. Mocht dit risico zich voordoen dan is de buffer er om dit risico op te vangen. Mocht er geen uitloop zijn zal er dan worden gekeken hoe de buffertijd zal worden gebruikt. De buffertijd is enkel hiervoor niet gebruikt omdat er uitloop heeft plaatst gevonden. Dit wordt verderop in dit document besproken.

6.2 Inception fase

6.2.1 Vision

In het vision zijn verschillende onderzoeken geweest zoals Android native of andere tools en hoe moet de backend ingericht worden. Deze onderzoeken zijn te vinden in H5.3 en H5.4. Naast deze onderzoeken zijn ook de requirements vastgesteld en geprioriteerd. Functionaliteit maakt een applicatie. Nadat is gebrainstormd met de opdrachtgever over welke functionaliteit in de applicatie moet gaan komen, is de lijst, in samenwerking met de opdrachtgever, verdeeld onder Must, Should, Could en Won‟t. Er is gekeken wat daadwerkelijk nodig is voor de demo en wat een extraatje zou zijn. Naast de functionele eisen bestaan er ook niet-functionele eisen. Deze zijn te vinden in H5.3

Één van de onderzoeksvragen is: Hoe kan het kennisgebied authenticatie worden verwezenlijkt. De techniek die een oplossing kan brengen is de oAuth techniek. Alleen bleek deze techniek een groot risico voor het project. De kennis erover is nihil en de techniek zelf is nog jong. Het zou wel een goede manier zijn om de authenticatie te verzorgen tussen de applicatie en de backend. Om het risico goed in te kunnen schatten is er besloten een Proof of Concept (PoC) te maken. De PoC bestond uit een kleine Android applicatie die met een bestaande oAuthserver gaat communiceren. Om dit te werkend te krijgen zijn twee werkdagen aan het maken van de PoC gewijd. De bevinding van deze twee dagen is, dat de techniek oAuth inderdaad een dusdanig groot risico met zich meebrengt voor het project dat is besloten deze techniek niet in het project zal worden toegepast. De implementatie van oAuth zou de planning enorm kunnen drukken waardoor er mogelijk enkele dagen tot zelfs een week aan alleen deze implementatie zou gaan worden gewerkt. Dit is als onaanvaardbaar aangemerkt. Er is gekozen voor een simpelere oplossing. De oplossing om een unieke hash aan te maken voor elke gebruiker waardoor deze niet telkens hoeft in te loggen. Deze zal in de XML worden meegezonden als zijnde authenticatie.

(27)

Er zijn al systemen in gebruik om mensen op de hoogte te brengen van belangrijke dingen. Denk hierbij aan het amber alert en de regionale sms services zoals alarmbericht.nl.

Deze systemen hebben alleen een andere functionele werking. Bij amber alert en de regionale diensten moet men inschrijven om gebruik te kunnen maken van de dienst. In dit project is dit ook nodig. Een verschil is dat bij een amber alert en de regionale diensten iedereen die ingeschreven is een melding krijgt. Ook al ben je niet in de buurt van het probleem je wordt toch gealarmeerd.

In dit project wordt gebruik gemaakt van de locatie waar mensen zich op dat moment bevinden. Als er een hulpvraag wordt ingeschoten krijgt iedereen die in de buurt staat een notificatie dat er een hulpvraag in de buurt gesignaleerd is.

Het verschil tussen broadcast en geografisch mensen benaderen is uniek en het innovatieve gedeelte van het project.

Om tot deze alternatieven voor het maken de applicatie te komen is gezocht via zoekmachines naar een manier om een niet-native applicatie te maken op een mobiele telefoon. Zo kwam de oplossing van een mobiele website, Titanium en Phonegap in beeld.

(28)

page 28 of 39 6.2.2 Use case Model

Figuur 5 Use case model

De twee belangrijkste functionaliteiten staan hierboven in het use case model. Een hulpbehoevende moet namelijk in staat zijn een hulpvraag aan te maken. Nadat de hulpvraag door het systeem is verwerkt en bij een hulpverlener is aangekomen moet deze kunnen reageren op de betreffende hulpvraag. De use case en scenario‟s staan verder uitgewerkt in de bijlage.

6.3 Elaboration fase

6.3.1 Use Case Specification

De lijst van functionaliteiten is verdeeld in 4 categorieën. Voor de scenario‟s zijn de functionaliteiten van de Must en Should gebruikt. Van elk van deze functionaliteiten is er een succes scenario en een falend scenario geschreven. Dit om er achter te komen wat de juiste manier is van een functionaliteit uitvoeren en welke uitzonderingen er zijn. Een voorbeeld hiervan is de functionaliteit “Inloggen”. Hiervoor is een scenario “Correct inloggen” en een scenario “Foutief inloggen” geschreven. Elk met een andere eindtoestand.

Van deze twee scenario‟s is een use case gemaakt: “Inloggen hulpverlener/hulpbehoevende”. Elke functionaliteit van Must en Should is zo verwerkt. Hieruit zijn de use cases gekomen die zijn genoemd in H6.2.2.

(29)

6.3.2 Software Architect Document

De bedoeling van dit document is het achterhalen van de architectuur die moet worden gebruikt voor het maken van de applicatie voor dit project.

Er is gekozen om volgens RUP te werken. Hierbij heb je verschillende views als je kijkt naar de architectuur. Het zogenaamde 4 + 1 model.

Figuur 6 4+1 Model by P. Kruchten

De vier buitenste views worden één voor één behandeld. Maar eerst zijn de eisen voor de architectuur behandeld. De architectuur eisen worden tegenover de niet-functionele eisen en de use cases gezet. De uitwerking van de niet-functionele eisen is te vinden in H5.3.

Nadat de eisen bekend zijn en de relevantie is bepaald, zijn de vier verschillende views behandeld. Eerst is begonnen met de Logical view. Om de code goed te kunnen structuren is bedacht dat er gebruik zal worden gemaakt van een lagenmodel. Er is gekozen voor een bekend en veel gebruikt lagenmodel: het MVC model. Het MVC model bestaat uit 3 lagen, respectievelijk de View, de Controllerlaag en de Modellaag. Dit model is in staat de applicatie vorm te geven. Deze beslissing is gemaakt om te uitbreidbaarheid van de code te kunnen garanderen. Door deze drie lagen kan er gemakkelijk functionaliteit worden toegevoegd, veranderd of verwijderd. Door enkel de view aan te passen kan de frontend makkelijk worden gewijzigd.

Voor de andere views zijn diagrammen ontworpen, die hier onder staan, om een beter inzicht in de technische plannen te creëren.

Klassendiagram:

Hiernaast is het klassendiagram te vinden zoals deze opgesteld is aan het begin van het ontwerp. Van elke XML die zal worden verzonden is een XMLReader en XMLWriter klasse aanwezig. Deze worden aangeroepen door de verschillende controllers. Dit diagram is nodig om de structuur van de applicatie op klassenniveau in beeld te krijgen. Hierdoor kan er beter worden

(30)

page 30 of 39

Package diagram:

Het package diagram hieronder geeft aan welke packages in de applicatie zullen worden gebruikt. Er zijn dus acht verschillende packages binnen de applicatie. Het MVC model komt hierbij goed naar voren. Om de verantwoordelijkheden goed gescheiden te houden zijn de readers, handlers en writers bedacht en uitgewerkt. Dit heeft ook later als voordeel dat de XML laag makkelijker kan worden vervangen dan wanneer de verantwoordelijkheden niet van elkaar gescheiden zijn.

Deployment diagram:

Met het deployment diagram heb je het overzicht over welke devices er worden gebruikt tijdens het project en welke connectie deze met elkaar hebben.

Figuur 9 Deployment diagram Figuur 8 Package diagram

(31)

6.4 Construction fase

De Construction fase verliep niet zoals gepland. Er waren 8 constructieve uren per dag gerekend, iets wat niet is gehaald. Hierdoor werd het werk niet gehaald in de uren die er voor stonden en liep de planning uit. Dit is beschreven in H7.1.1 Ook de einddatum van het project was niet goed gepland, dit omdat er een verkeerde datum was gecommuniceerd die later werd bijgesteld, tijdens het proces. Achteraf bleek er toch nog wat meer tijd voor het maken van het project dan op voorhand was bedacht. De iteraties zijn wel gevolgd, alleen is er wel vertraging opgelopen.

In de iteraties zal getracht worden de volgende activiteiten te realiseren.

Deze iteraties verschillen wel met het oorspronkelijke plan. Dat plan was namelijk om eerst de applicatie te maken, dan de backend en daarna alles te gaan koppelen. Er is hierover verder nagedacht waarbij de conclusie is getrokken dat eerst een applicatie maken, dan de backend en dan hopen dat je alles goed aan elkaar kan koppelen een te groot risico zou gaan vormen voor de voortgang van de applicatie.

Hierdoor is besloten voor de onderstaande verdeling. Deze geeft telkens een applicatie die voldoende werkt om ingezet te kunnen worden en dekt een risico af dat er door omstandigheden te weinig tijd overblijft voor functionaliteit.

In de eerste iteratie zullen de volgende must‟s worden gerealiseerd: - Inloggen

- Backend werkend krijgen.

In de tweede iteratie zullen de volgende must‟s worden gerealiseerd: - Hulpvraag maken op basis van locatie

- Notificatie tijdstip mee verzenden

In de derde iteratie zullen de volgende must‟s worden gerealiseerd: - Locatie op Google Maps aangeven

- Op hulpvraag reageren

6.4.1 Iteratie 1

De eerste twee functionele eisen die zijn geïmplementeerd zijn het inloggen en het werkend krijgen van de backend. Allereerst is gestart met het inloggen gedeelte. Omdat er nog geen backend aanwezig is, zijn de XML‟s die worden gebruikt eerst hard in de code gezet.

De XML‟s zorgen voor de dataoverdracht tussen de server en de applicatie. Ze hebben een eenduidig formaat en dienen aan ontwerpregels te voldoen. Deze regels zijn opgenomen in zogenaamde XSD bestanden. Deze code hiervan is uitgewerkt en te vinden in de bijlagen. Hierdoor kan ook goed worden getest of het klassendiagram, en dus de flow, in de applicatie zelf goed vooraf is bedacht. Bij het opzetten van het klassendiagram is vooraf bedacht welke klassen er nodig zijn om de functionaliteit te realiseren die gewenst is. Een functionaliteit zal dus door verschillende klassen lopen en dat is de flow die de applicatie in zich heeft.

Dit bleek dus niet het geval te zijn. Er miste nog handler klassen in het klassendiagram. Deze zijn toegevoegd. In de bijlage is een rapport opgenomen met alle klassen die in de applicatie zitten.

(32)

page 32 of 39

De uiteindelijke flow door de applicatie zelf is de volgende:

Vanuit de applicatie komt een aanvraag om in te loggen. Deze aanvraag maakt via de writer klasse een XML met de gegevens die zijn ingevoerd door de gebruiker. Deze writer wordt door de reader gestuurd naar de webserver. Deze reader ontvangt ook het resultaat van webserver. Binnen de reader zal de XML worden geparsed door een handler. Deze handler geeft een XMLResponse terug aan de reader welke het resultaat teruggeeft aan klasse die de aanvraag deed. Het figuur hieronder geeft dit schematisch weer.

Figuur 10 Flow applicatie

Met de scheiding van de taken, schrijven, lezen en behandelen wordt de code gescheiden gehouden wat de herbruikbaarheid en onderhoudbaarheid ten goede komt.

Tijdens de ontwikkeling van het inloggen zijn ook het request en response XSD aangepast. Deze XSD valideert de XML. Nadat het inloggen werkt met de XML hard in de code geschreven, werd het tijd om aan de backend te gaan werken.

De backend is een PHP webserver en een MySQL database server. Deze twee zijn op één server geïnstalleerd. De bedoeling van dit project is een werkende applicatie. De focus ligt op de applicatie en niet op de backend. Daarom is de backend heel simpel gehouden en enkel die taken te laten doen die ook zijn bedacht. Namelijk het kunnen verwerken van een XML en een response teruggeven in de vorm van een XML.

Tussen de applicatie en de webserver wordt een POST request gestuurd waarin de XML staat en het type aanvraag wat wordt gedaan. Bijvoorbeeld: login.

Doormiddel van dit type maakt de XMLFactory klasse van de webserver de goede parser aan in de webserver. Deze verwerkt de XML en genereert een XML die als response wordt terug gestuurd.

Om de webserver goed in te kunnen richten, en dus ook goed te kunnen testen, is de webserver ook afzonderlijk gebouwd. De POST request wordt nagebootst zodat eventuele fouten niet door de communicatie tussen de applicatie en de webserver konden optreden.

Door telkens de request in de code te zetten tijdens het testen is er geen kans geweest op extra vertraging tijdens het ontwikkelen door communicatieproblemen. Dit heeft het hele proces bespoedigd.

(33)

Voor het inloggen is een database nodig met een tabel met de gegevens voor het inloggen. De tabel zit er als volgt uit:

Van de gebruikers wordt een ID aangemaakt en de gebruikersnaam en wachtwoord opgeslagen. Het wachtwoord is versleuteld als: SHA1(MD5(wachtwoord)+MD5(wachtwoord)). Er is voor deze versleuteling gekozen omdat deze niet heel veel wordt gebruikt en dat er hiervoor dan geen tabellen zijn te vinden waarbij staat dat hash X gelijk is aan wachtwoord X. Hierdoor is het wachtwoord voldoende beschermd in het geval dat iemand toegang krijgt tot de database die daar geen toegang tot heeft.

Als iemand succesvol wordt ingelogd, wordt er een rij in de tabel tokens aangemaakt. De combinatie van userID, deviceID en token wordt gehasht mee terugverzonden. Door deze hash hoeft een gebruiker niet telkens in te loggen. De relatie die tussen users en tokens is gelegd heeft een NO ACTION relatie op de update en CASCADE op de delete.

Voor deze twee functionaliteiten, het inloggen en het werkend krijgen van backend, is een week gepland. Dit is echter niet gehaald. Er was wel ervaring met het ontwikkelen van een Android applicatie, maar deze ervaring moest weer worden opgefrist. Daarnaast was er nog geen ervaring met het verwerken van een XML in Android. Ook is er vertraging in het ontwikkelen ontstaan door problemen met de webserver. Het was de bedoeling om een Linux webserver op te zetten. Dit door middel van een VirtualBox op de Windows ontwikkelcomputer. Door technische problemen veroorzaakte VirtualBox tot drie keer toe een vastlopende laptop. Daarna is besloten om de webserver gewoon onder Windows te laten draaien door middel van XAMPP. Dit is een platform wat direct Apache2, PHP 5.3 en MySQL 5.0 installeert en conFiguurert. Hierdoor zijn de vijf werkdagen om te ontwikkelen in deze iteratie onvoldoende. Ook het verslaggedeelte van twee werkdagen bleek te kort. Er is namelijk kort voor de Construction fase begonnen aan het schrijven van dit document. Hierdoor konden de twee werkdagen niet worden ingezet om over iteratie 1 te schrijven.

6.4.2 Iteratie 2

Twee functionaliteiten staan gepland in deze iteratie. Namelijk die van een hulpvraag aanmaken en een tijdstip van notificatie mee verzenden. Allereerst is begonnen met het ontwikkelen van een hulpvraag aanmaken. Dit proces bestond uit twee aparte delen: Namelijk het maken van het gedeelte in de applicatie en het maken van de verwerking in de backend. Allereerst is begonnen met het realiseren van de backend implementatie. Zodat het maken van hulpvraag in de applicatie op een goede manier kon worden uitgevoerd. Een hulpvraag dient te worden opgeslagen in de database. Hiervoor zijn de volgende tabellen gemaakt:

(34)

page 34 of 39

vastgestelde XML voldeed voor het maken van deze functionaliteit. Na het maken van het backend gedeelte van de functionaliteit moet ook de kant van de applicatie in elkaar worden gezet. Hiervoor is een menu toegevoegd waarbij het item „Nieuw hulpvraag‟ is toegevoegd. Als daarop wordt geklikt, wordt er een check gedaan of de gecachede items nog up-to-date zijn. Zo niet dan zullen de hulpvragen en categorieën opnieuw worden ingeladen. Anders wordt de cache opgevraagd. Vervolgens komt er een scherm naar voren waar je eerst een categorie moet selecteren en daarna een hulpvraag kunt selecteren. Nadat dit is gedaan wordt kan men de hulpvraag inschieten.

Nadat de hulpvraag aanmaken functionaliteit is geïmplementeerd kwam het item „Notificatie tijdstip mee verzenden‟ aanbod. Er is besloten om „Locatie op Google Maps aangeven‟ te ruilen met „Notificatie tijdstip mee verzenden‟. Dit omdat de locatie aangeven past bij het maken van een hulpvraag en dat het tijdstip van de notificatie mee verzenden heel goed past bij de functionaliteit van de derde iteratie. Namelijk die van „Op hulpvraag reageren‟.

Er kan immers enkel op een hulpvraag worden gereageerd als men een notificatie heeft gehad dat er een hulpvraag in de buurt aanwezig is.

Het scherm van een hulpvraag aanmaken is uitgebreid met een „verder‟knop waarbij een Google Maps kaart wordt geladen. Daar wordt het punt, waarvan de applicatie denkt dat je bent, aangegeven. Door op de juist locatie te klikken kan dit punt worden aangepast. Dit moet wel binnen een redelijk straal van de verwachte locatie liggen. Na de check of de locatie die je aanklikt wel in de buurt ligt, zal de waarde die is aangegeven worden mee verzonden aan de backend.

Deze iteratie ging ook niet altijd zo soepel als gepland. Voor het aspect van een goede GUI was een lastig stuk. Hieraan is wel wat meer tijd besteed dan verwacht. Er is moeilijker over de GUI gedacht dan achteraf nodig was. Denk hierbij aan het manipuleren van data en de GUI laten aanpassen op gedrag van de gebruiker. Dat heeft tijd gekost.

6.4.3 Iteratie 3

„Notificatie tijdstip mee verzenden‟ is naar iteratie drie verplaatst. De op te leveren functionaliteiten in deze iteratie zijn dus geworden: Het „Notificatie tijdstip mee verzenden‟ en „Op hulpvraag reageren‟.

Om een notificatie naar een hulpverlener te kunnen versturen moet eerst een service worden gemaakt die wordt gestart als het inloggen succesvol is verlopen.

Deze service zal elke minuut de locatie updaten van de persoon die is ingelogd. Zodoende weet het systeem twee dingen: Welke mensen waar aanwezig zijn en welke personen hun internet aan hebben en dus een notificatie kunnen ontvangen.

Elke minuut zal op de webserver een script draaien die kijkt of er nieuwe hulpvragen zijn gemaakt. Per hulpvraag zullen de gebruikers die in de buurt zijn, worden gezocht en zal er via een Google service een push bericht worden gestuurd. In dit bericht staat het tijdstip van de hulpvraag.

Als een notificatie binnenkomt, zal de applicatie de betreffende hulpvraag ophalen. Deze wordt in een lijst getoond. Door op een hulpvraag te klikken, komt er meer informatie beschikbaar. In dit scherm is de mogelijkheid om te reageren op de hulpvraag.

De Google services aanspreken maakte deze iteratie wat langer dan gepland. Het duurde even voordat alles werkte zoals het moest gaan werken. Dit door kleine fouten zoals verkeerde syntax, vergeten variabelen of meegegeven verkeerde variabelen.

(35)

6.5 Transition fase

Er is een werkende demoapplicatie. Hierdoor stelt de overdracht niet veel voor. De gemaakte documenten zullen worden overgedragen en de sourcecode wordt beschikbaar gesteld aan Logica.

Samen met dit document is daarmee de transition fase afgerond. Er hoeft niemand worden ingewerkt of worden bijgepraat over de documentatie en de source code. Ook hoeven er geen gebruikers worden ingewerkt of dient er support aanwezig te zijn voor mogelijke problemen die zouden ontstaan als de applicatie echt in gebruik wordt genomen.

6.5.1 Iteratie verloop

De iteraties verliepen niet zoals vooraf gepland. De week om de functionaliteiten te bouwen bleek achteraf gewoonweg te kort zijn geweest. Door verschillende bugs en nieuwigheden vlotte de implementatie van deze functionaliteiten niet altijd zoals gewenst. De drie dagen voor het testen en het oplossen van bugs zijn altijd wel met de ontwikkeltijd verweven geweest. Doordat de planning niet gehaald is, is er alleen getest of de MUSTs goed zijn geïmplementeerd. Het maken van unit-testen en deze uitvoeren zou ten koste gaan van de set functionaliteit. De MUST functionaliteiten moesten zeker worden ingevoerd. Daarom is besloten de unit-testen te laten vervallen.

Per iteratie zijn twee dagen gepland om aan dit document te werken. Dit blijkt dus ook onvoldoende tijd te zijn geweest.

Door de volle agenda‟s van de Logica-medewerkers die feedback moesten geven kwamen er andere deadlines van feedback uit dan van ten voren was gepland. Hierdoor zijn sommige iteraties meer geschreven dan geprogrammeerd en andersom.

6.5.2 Testen

In de oorspronkelijk planning was ruimte om de applicatie op een goede manier te kunnen testen. Zoals hierboven te lezen is, liep het project uit. Om de uitloop te drukken en de MUST functionaliteit te garanderen, is besloten om enkel te gaan testen op bewezen functionaliteit. Dit betekent dat alleen de geïmplementeerde functionaliteiten zijn getest op hun werking.

De volgende testen zijn niet uitgevoerd:

- Acceptatietest - De acceptatietest is wel uitgevoerd maar er is geen testplan opgesteld

voor deze test. Daarom staat deze test gewoon in deze lijst genoemd. - Unit-testen Android applicatie

- Unit-testen Webserver

- Systeemtest

- Integratietest

Functionaliteit Uitslag testen

Inloggen Werkt

Hulpvraag maken op basis van locatie Werkt

Locatie op Google Maps aangeven Werkt

Op hulpvraag reageren Werkt

Notificatie tijdstip mee verzenden Werkt

De intentie om alles te testen was wel aanwezig. Het is dan ook spijtig dat er geen tijd meer was om alle testen uit te voeren. Dat het enkel om een demo gaat, maakte het wel eenvoudiger dit besluit te nemen. De opdracht is immers dat er een demo moet worden opgeleverd.

Notificatie voor snelle hulp

Notificatie service voor snelle hulp

Procesverslag

Versiebeheer

Distributielijst

Adresgegevens

CONTENTS

Samenvatting

9

Voorwoord

10

1

Inleiding

11

2

Organisatie

12

2.1

Logica

12

2.2

Working Tomorrow

12

2.3

Begeleiding

13

3

Probleemanalyse

14

4

Plan van Aanpak

15

4.1

Probleemstelling

15

4.1.1 Oplossing

15

4.2

Verankering en relevantie

15

4.3

Randvoorwaarden en risico‟s

16

4.4

Planning

16

4.5

Android applicatie

17

5

Methoden en Technieken

18

5.1

Vision

18

5.2

Use Cases

19

5.3

Software Architect Document

19

5.4

Android applicatie

22

5.5

Webserver

23

6.2.1 Vision

26

6.2.2 Use case Model

28

6.3

Elaboration fase

28

6.3.1 Use Case Specification

28

6.3.2 Software Architect Document

29

6.4

Construction fase