21 juni
Eindverslag Enterprise App Authors: Salim Hadri 4090993 -‐ Viresh Jagesser 4101626 -‐ Kaj Oudshoorn 4009444
2013
Inhoudsopgave INHOUDSOPGAVE ...................................................................................................................... 2 VOORWOORD ............................................................................................................................. 4 INLEIDING .................................................................................................................................... 5 ABSTRACT .................................................................................................................................. 6 OPDRACHT ................................................................................................................................. 7 DOELGROEP VAN DE APPLICATIE .................................................................................................... 8 DOELSTELLING ............................................................................................................................... 8 OPDRACHTFORMULERING ............................................................................................................... 8 PLANNING ................................................................................................................................... 8 EISEN ......................................................................................................................................... 10 FUNCTIONELE EISEN ..................................................................................................................... 10 PLATFORM-EISEN ......................................................................................................................... 11 BEVEILIGINGSEISEN...................................................................................................................... 11 ONTWERP ................................................................................................................................. 12 DESIGN PROCES ........................................................................................................................... 12 ONTWERP-RICHTLIJNEN ................................................................................................................ 14 INLOGSCHERM .............................................................................................................................. 14 AANMELDSCHERM ........................................................................................................................ 14 GROEPEN SCHERM ....................................................................................................................... 14 PROBLEMENLIJST SCHERM ............................................................................................................ 14 PROBLEEMBESCHRIJVING SCHERM ................................................................................................ 14 HOOFD NAVIGATIE ........................................................................................................................ 14 FEEDBACK ................................................................................................................................... 15 VERSIE 1 ...................................................................................................................................... 15 VERSIE 2 ...................................................................................................................................... 16 IMPLEMENTATIE EN SYSTEEM ONTWERP ........................................................................... 17 MODEL ......................................................................................................................................... 17 CLIENT-SIDE MODEL ..................................................................................................................... 18 DATABASE .................................................................................................................................... 19 VIEW ............................................................................................................................................ 22 CONTROLLER ............................................................................................................................... 23 CLIENT-SIDE CONTROLLER ........................................................................................................... 23 SERVER-SIDE CONTROLLER - MIDDLEWARE .................................................................................. 24 TESTEN ...................................................................................................................................... 25 MIDDLEWARE TESTEN................................................................................................................... 25 OBJECTIVE-C INTEGRATIE TESTEN ................................................................................................ 25
2
SCENARIO TESTEN ....................................................................................................................... 26 USABILITY TESTEN ....................................................................................................................... 26 SOFTWARE IMPROVEMENT GROUP FEEDBACK ................................................................ 27 VERBETERINGEN .......................................................................................................................... 27 CONCLUSIE ............................................................................................................................... 28 AANBEVELINGEN VOOR TOEKOMSTIGE WERKZAAMHEDEN ............................................................. 28 SYSTEEM UITBREIDING ................................................................................................................. 28 OPTIMALISATIE............................................................................................................................. 29 AANBEVELINGEN VOOR MILVUM ................................................................................................... 29 APPENDIX A – KLASSEN DIAGRAM VAN HET MVC-MODEL .............................................. 30 APPENDIX B – SIG CODE EVALUATIE ................................................................................... 31 APPENDIX C – ORIËNTATIEVERSLAG ................................................................................... 32 APPENDIX D – PLAN VAN AANPAK ....................................................................................... 41 APPENDIX E – FUNCTIONEEL ONTWERP ............................................................................. 52 APPENDIX F – BUSINESS PLAN ............................................................................................. 57 APPENDIX G – WIREFRAMES VERSIE 1 ................................................................................ 72 APPENDIX H – WIREFRAMES VERSIE 2 ................................................................................ 78
3
Voorwoord Dit rapport concludeert het ontwikkel proces van Acceleratie dat is ontwikkeld in opdracht van Milvum. Milvum is een Nederlands mobiele software ontwikkel bedrijf en ontwikkeld applicaties voor iOS, Android en Windows Phone 8. Het project is uitgevoerd voor het vak TI3800 - Bachelorproject aan de TU Delft. De looptijd van dit project is tien weken en is gestart op 22 April 2013 en eindigde op 5 juli 2013. De ontwikkeling en onderzoek heeft plaats gevonden op verschillende locaties de TU Delft bibliotheek, Drebbelweg - gebouw 35, Faculteit Techniek, Bestuur en Management, faculteit Elektrotechniek, Wiskunde en Informatica. Verder is er ook gewerkt op kantoor bij Milvum. We willen graag de volgende mensen bedanken: Sam Solaimani, voor het begeleiden van het project en feedback op onze verslagen met name de business plan. ● Martha Larson, voor het coördineren van het project. ● Arvind Jagesser, voor het begeleiden van het project en voor de kans dat we dit project mochten uitvoeren. ● Shahid voor het komen naar onze presentatie en voor de interesse in het product. ●
4
Inleiding De mobile applicatie industrie is op dit moment een booming markt. Sinds de iOS Store is gelanceerd, is er 10 biljoen dollar aan apps aan ontwikkelaars uitbetaald. Hiervan is vorig jaar al 5 biljoen dollar uitbetaald1. De mobile applicatie industrie is dus nog ontzettend aan het groeien. Daarom heeft Milvum ervoor gekozen om mobiele applicaties te ontwikkelen voor iOS, Android en Windows Phone 8. Voor die BSc eindproject is er gekozen voor een iPad applicatie, omdat er veel informatie op de beeld scherm vertoond moet worden, dit werkt prettiger op een tablet. Verder is de iPad op dit moment de meest gebruikte tablet2. Acelera is een iPad applicatie dat ontwikkeld is voor Milvum. De applicatie maakt het mogelijk om mensen waarmee je samen werkt uit te nodigen in je groep. Vervolgens kunnen er in groepen problemen worden aan gekaart, zodat ze snel bekend zijn bij teamleden en teamleiders. Het doel van deze applicatie is om het mogelijk te maken om problemen in projecten/groepen in een vroeg stadium op te lossen. Problemen kan je toewijzen aan mensen die het moeten oplossen. Deze personen kunnen er voor kiezen om een email te krijgen zodra een verandering optreed. Wanneer een probleem is opgelost kan deze in de applicatie worden aan gegeven als “opgelost”. Dit is in het kort hoe de applicatie ongeveer werkt. De kennis die is opgedaan tijdens de studie en de documentatie die door Apple wordt geleverd is gebruikt om de applicatie te bouwen. Het doel van dit rapport is om een gedetailleerde beschrijving te geven van het proces van het project, de implementatie, de software architectuur, het test proces, toekomst plannen en het resultaat. De structuur van dit rapport is als volgt: In hoofdstuk 2 wordt de opdracht en de eisen waar aan voldaan moet worden gedetailleerd beschreven. Vervolgens wordt er in hoofdstuk 3 uitgelegd waarom er is gekozen voor scrum als project methodologie en wordt de planning beknopt beschreven. In hoofdstuk 4 wordt er uitvoerig ingegaan op de implementatie en systeem ontwerp. Daarna wordt er in hoofdstuk 5 uitgelegd hoe dit systeem is getest. Tot slot wordt er in hoofdstuk 6 besproken wat er verder ontwikkeld kan worden in de toekomst en worden de resultaten van dit project geconcludeerd.
1 2
http://bit.ly/13uhC6R http://bit.ly/13jdOpk
5
Abstract Mobiele applicaties zijn de afgelopen jaren niet meer weg te denken. Het is inmiddels een markt geworden waarin wordt verwacht dat het in 2013, 25 biljoen dollar omzet zal draaien1. De mobiele markt is de laatste jaren zo belangrijk geworden, dat bedrijven die het nieuws verzorgen nu ook beschikbaar zijn op mobiele apparaten. Een voorbeeld hiervan is de RTLNieuws 365 iPad applicatie die in januari 2012 is uitgebracht. De mobiele markt is dusdanig gegroeid dat het niet meer genegeerd kan worden. Milvum is een bedrijf dat anderhalf jaar bezig is met het ontwikkelen van mobiele applicaties voor de iOS, Android en Windows Phone 8. In verband met het streven naar een mobiele applicatie dat gericht is op de consumenten, is dit bachelor eindproject tot stand gekomen. Er is in opdracht van Milvum een iPad applicatie ontwikkeld genaamd Acelera. Het doel van deze applicatie is om het mogelijk te maken om problemen in projecten/groepen in een vroeg stadium op te lossen en te archiveren. De applicatie bestaat uit drie componenten, de front-end geschreven in Objective-C, de middleware geschreven in PHP en de MySQL database met een innoDB engine dat is geschreven in SQL. Een innoDB engine is ontworpen voor maximale prestatie tijdens het verwerken van grote hoeveelheden data. De front-end is de code dat op de iPad draait en als het ware de applicatie Acelera vorm geeft. De middleware zorgt ervoor dat de data uit de database wordt uitgelezen en bewerkt op aanvraag van de front-end. Acelera maakt het mogelijk om mensen waarmee je samen werkt uit te nodigen in je groep. Vervolgens kunnen er in groepen problemen worden aan gekaart, zodat ze snel bekend zijn bij teamleden en teamleiders. Problemen kan je toewijzen aan mensen die het moeten oplossen. Gebruikers kunnen er voor kiezen om een email te krijgen zodra een verandering optreed. Wanneer een probleem is opgelost kan deze in de applicatie worden aan gegeven als “opgelost”. Acelera ondersteund al veel functionaliteiten zoals, inloggen/uitloggen, email notificaties, email notificaties aan/uit zetten, gebruikers profiel wijzigen, groepen aanmaken/verwijderen, teamleden toevoegen/verwijderen, problemen toevoegen/oplossen, reageren op problemen in vorm van tekst, een overzicht biedt van alle bekende problemen geordend op prioriteit en deze kan groeperen op toegewezen problemen, problemen in de groep en problemen die de gebruiker heeft aangemaakt.
1
http://bit.ly/16ltyKq
6
Acelera zit echter nog in een begin fase en moet nog verder worden ontwikkeld. De stadium van ontwikkeling waarin Acelera nu zit is de Alpha1 fase.
Opdracht Milvum biedt tot nu toe alleen maar maatwerk voor haar klanten. Milvum wil niet alleen afhankelijk zijn van opdrachten van buitenaf en wil daarom op eigen initiatief een product op de markt brengen. Op deze manier wordt er een poging gedaan een stabiel inkomen te vergaren voor het bedrijf. Arvind Jagesser de Operations Director van Milvum heeft Salim Hadri, Kaj Oudshoorn en Viresh Jagesser - de studenten voor die BSc project(Bachelor-project) - benaderd om als BSc project een Enterprise Applicatie te maken: een applicatie die bedrijven helpt bij het verbeteren van hun bedrijfsprocessen en knowledge sharing. Deze applicatie zal na oplevering in de appstore worden gezet. Tijdens de oriëntatiefase is er voor gekozen om het project te laten concentreren op procesmanagement en knowledge sharing, omdat het een positief effect heeft op innovatie in bedrijven2. In dit geval ligt de focus op het coördineren en aanpassen van een fase tussen het initiëren en afronden van een ontwikkeling. Hierbij speelt problemsolving een belangrijke rol. De impact op de capaciteit van de bedrijfsinnovatie heeft een sterk positieve associatie met werknemers van een bedrijf die bereid zijn om kennis te delen en te verzamelen.3 Dit zijn de redenen waarom Acelera zich richt op problemsolving en knowledge sharing. Problemen binnen een bedrijf zijn een probleem. Ze worden vaak mondeling of per email gemeld, waardoor er kans is dat ze tijdelijk vergeten worden. Ook wordt er soms te lang gewacht met het melden van een probleem, omdat men te lang het zelf probeert op te lossen. Soms geeft een probleem aan dat een persoon A zijn werk niet goed doet. Als A wel weet dat het probleem er is, maar vanwege zijn reputatie het niet durft te melden, dan wordt dit probleem niet of laat opgemerkt door het bedrijf. Dit alles heeft als gevolg dat problemen te langzaam worden opgelost, wat invloed heeft op de efficiëntie van het bedrijf.
1
In dit stadium is er een werkende applicatie, maar het heeft nog niet alle functionaliteiten. De belangrijkste functionaliteiten draaien al en kunnen uitgebreid getest worden. 2 Mary J. Benner , Michael I. Tushman (2003) Exploitation, Exploration and Process Mangament: The Productivity Dilemma Revisited. Acedemy of Management Review, Vol 28 (2), 238-256 3 Hsiu-Fen Lin, (2007) "Knowledge sharing and firm innovation capability: an empirical study", International Journal of Manpower, Vol. 28 Iss: 3/4, pp.315 - 332
7
Doelgroep van de applicatie Het is belangrijk om goed te weten wat de doelgroep is van de applicatie. Zodra het bekend is wat de behoefte zijn van de doelgroep, kan de applicatie qua functionaliteit en design hierop worden aangepast. De doelgroep van de applicatie bestaat uit bedrijven die bestaan uit meerdere afdelingen/groepen.
Doelstelling Het doel van dit project is om met een iPad applicatie een duidelijk overzicht te geven van wat er gaande is binnen het bedrijf d.m.v. het aankaarten van relevante problemen binnen een projectgroep. Ook moet de applicatie bij oplevering een product zijn dat gelanceerd kan worden op de markt. Het is de bedoeling om managers een duidelijker overzicht te geven over problemen binnen projecten, zodat de manager op tijd op de hoogte is van eventuele problemen. De voordelen voor een bedrijf zijn: ● Tijd besparen ● Geld besparen ● Fiasco’s voorkomen Er kan tijd bespaard worden, wanneer managers en projectleiders snel en gemakkelijk toegang krijgen tot de problemen binnen een project. Er kan meer geld bespaard worden, doordat het gemakkelijker is om problemen direct aan het licht te brengen, waardoor de problemen sneller opgelost kunnen worden. Door in een vroeg stadium een probleem op te lossen kunnen fiasco’s worden voorkomen. Hoe dit gedaan zal worden moet nog onderzocht worden. "You don't drown by falling in the water; you drown by staying there." — Edwin Louis Cole
Opdrachtformulering De opdrachtformulering voor dit project is het maken van een iPad applicatie. Deze applicatie dient het makkelijker om problemen binnen groepen op te lossen. Managers en projectleiders moeten een goed overzicht hebben over de problemen binnen de groepen die zij leiden. In de applicatie kunnen groepsleden problemen aan kaarten. De manager moet deze weer gemakkelijk en overzichtelijk terug kunnen zien op de applicatie.
Planning
8
Aan het begin van het project was er een planning gemaakt voor het verloop van het project. Het project werd in drie fases opgedeeld: een oriëntatiefase, een implementatiefase en een afrondingsfase. Tijdens de oriëntatiefase zou de opdracht uitgewerkt worden tot een implementeerbaar idee en zou er voor onderzoek worden gedaan om benodigde kennis hiervoor op te doen. Tijdens de implementatie fase zou het daadwerkelijke programmeren plaatsvinden en zou er ondertussen ook aan het eindrapport worden gewerkt. Het programmeren werd verdeeld over sprints, hierbij werd gebruik gemaakt van de Scrum methode. In de afrondingsfase was er tijd vrij gehouden voor het afmaken voor het eindrapport en eventuele uitloop van de implementatiefase. Tabel 1: Planning
fase \ week
1
2
oriëntatiefase
X
X
implementatiefase afrondingsfase
3
4
5
6
7
8
X
X
X
X
X
X
9
10
X
X
9
Eisen Bij elk project zijn er eisen waaraan voldaan moet worden. De MoSCoW-methode1 zal worden gebruikt om een goed beeld te krijgen van de prioriteit van de functionele eisen voor dit project. Vervolgens zal er worden ingegaan op de platform-eisen, denk hierbij aan op welk systeem de applicatie moet kunnen draaien. Tot slot zullen de beveiligingseisen worden behandeld, dit zijn eisen die betrekking hebben tot de beveiliging van de data van de applicatie.
Functionele eisen De functionele eisen van een software project beschrijven wat het programma moet kunnen. Elk van deze eisen heeft een bepaalde prioriteit. Deze prioriteit wordt in dit hoofdstuk beschreven m.b.v. de MoSCoW-methode. Bij de MoSCoW methode wordt er uit gegaan van 4 verschillende prioriteiten: 1. Must haves: Dit zijn eisen die nodig zijn om tot een werkend product te komen (de kwaliteit is hierbij niet belangrijk). 2. Should haves: Dit zijn eisen die zeer gewenst zijn van het product (ze zijn een grote meerwaarde). 3. Could haves: Dit zijn eisen die alleen worden gewaarborgd als er tijd over is. Het is fijn om ze te hebben, maar zijn niet uitermate belangrijk 4. Won’t haves: Ook wel bekend als “Would like to haves”. Eisen die het programma niet zal hebben, maar die wel interessant kunnen zijn voor toekomstige projecten in verband met dit product (uitbreidingen). Must have ● Een centraal punt voor een relationele database die ook mogelijkheid geeft voor uitbreiding tot Android en Windows Phone. ● Authenticatie om gebruik te mogen maken van het programma. ● Een aanpasbaar overzicht van groepen (toevoegen, verwijderen). ● Mensen uitnodigen voor een groep/groepen. ● Problemen kunnen melden en als opgelost kunnen markeren.
1
De MoSCoW-methode is een manier van prioriteiten stellen. De eisen aan het resultaat van een project worden ermee ingedeeld.
10
Should have ● Verschillende rechten per persoon (bekijken, uitnodigen, rechten geven, kicken). ● Prioriteren van problemen (risico waarde aangeven). ● Een probleem kunnen opeisen (aangeven dat iemand er mee bezig is). ● De mogelijkheid om een probleem anoniem te kunnen insturen. (zelfde idee als een anonieme tiplijn bij de politie) ● De mogelijkheid om als groepsleider anonieme problemen toe te staan of te verbieden. ● Categoriseren van problemen. ● Discussie of opmerkingen op een probleem geven ● Status van een probleem aangeven ● Archiveren van opgeloste problemen. ● Aangeven wat de oplossing is geweest voor een probleem. Could have ● Mogelijke toekomstige problemen kunnen aangeven. ● Aanleidingen van problemen aangeven. ● Notificatie van nieuwe problemen en aanpassingen aan problemen Won’t have ● Chat systeem ● Importeren van groepen/projecten uit project management systemen zoals basecamp
Platform-eisen In de eerste plaats is het de bedoeling dat de applicatie werkt op de iPad. Een werkende versie voor de iPhone wordt gewaardeerd, maar is geen must voor het project. Het besturingssysteem van de iPad is iOS. De applicatie moet compatibel zijn met de nieuwste versie van iOS (6.1) zodat het maximale uit het besturingssysteem kan worden gehaald. Updaten naar de nieuwste versie van iOS is gratis, dus het feit dat iOS 6.1 wordt gebruikt levert geen beperkingen op voor gebruikers.
Beveiligingseisen De applicatie zal gebruik maken van bedrijfsgegevens. Van dit soort gegevens is het niet de bedoeling dat ze voor iedereen toegankelijk zijn. Er zijn twee mogelijkheden waarbij de gegevens door onbevoegden te zien zijn: 1. Toegang tot de database krijgen buiten de applicatie om. 2. Onbevoegd gebruik van de applicatie. Om de veiligheid van de gegevens te waarborgen kunnen we de volgende eisen stellen: 1. Gegevens uit de database moeten onleesbaar/onbegrijpbaar zonder hulp van de applicatie. 2. Er moeten restricties zijn voor het gebruik maken van de database.
11
3. Er moeten restricties zijn voor het gebruik maken van de applicatie.
De laatste twee eisen spreken voor zich. Het moet zo lastig mogelijk zijn om bij de gegevens te komen (het is onmogelijk om 100% te beveiligen). De eerste eis zorgt ervoor dat als er zich toch een geval voordoet dat de database bereikt wordt, de data die erop staat niet te begrijpen is.
Ontwerp Naast eisen over hoe de applicatie moet werken, is het ook belangrijk om voor ogen te hebben hoe het applicatie er uit moet komen te zien. Een goed ontwerp is belangrijk voor de gebruikers. Een applicatie kan qua functionaliteit nog zo goed werken, maar zonder gebruiksvriendelijkheid wordt een applicatie niet gebruikt. In dit hoofdstuk komen de ontwerp-richtlijnen, de wireframes en de uiteindelijke designs van de applicatie aan bod.
Design proces Om tot een goede applicatie te komen, moet er van tevoren worden nagedacht over de user interface1. Als eerst werden de requirements van de app opgesteld, door middel van de MoSCoW methode. Met de must haves en de should haves als basis, is er een globale beschrijving gegeven voor 5 schermen van de app. Namelijk het inlogscherm, aanmeldingsscherm, groepenscherm, problemenlijstscherm en probleembeschrijvingsscherm. Zie Ontwerp-richtlijnen voor de gedetailleerde beschrijvingen van de schermen. Er is nagedacht over hoe dit het beste in een applicatie kan worden gezet, dit resulteerde uiteindelijk in vijf schermen. Belangrijk was snelheid, gemakkelijkheid, plaatsing van interactie elementen, en het aantal klikken om een actie stap uit te kunenn voeren. Dit is afgekeken van bestaande en goede applicaties zoals Fancy2, Path3, Facebook4 en Asana5 (gebaseerd op hun populariteit werden deze uitgekozen). Vervolgens werd er met potlood en papier schetsen gemaakt. Deze werden naar de designer gestuurd, en hij heeft hiervan digitale wireframes van gemaakt6. Via Notism7 is er feedback gegeven op de wireframes, dit resulteerde in versie 2 van de wireframes8. Uiteindelijk was er nog een laatste ronde aan feedback nodig, dit leidde tot versie 3 van 1
De interface tussen een computer(of andere machine in dit geval de iPad) en de mens die de computer gebruikt. 2
https://itunes.apple.com/en/app/fancy/id407324335?mt=8 https://itunes.apple.com/en/app/path/id403639508?mt=8 4 https://itunes.apple.com/en/app/facebook/id284882215?mt=8 5 https://itunes.apple.com/us/app/asana-mobile/id489969512?mt=8 6 Zie bijlage.... voor wireframes versie 1. 7 https://www.notism.io/ 8 Zie bijlage.... voor wireframes versie 2. 3
12
de wireframes1. Met de wireframes als basis, zijn er van de wireframes uiteindelijke designs gemaakt. Met uiteindelijke designs wordt het design bedoeld, zoals het eruit hoort te zien na implementatie van de applicatie.
1
Zie bijlage.... voor wireframes versie 3.
13
Ontwerp-richtlijnen De applicatie zal bestaan uit 5 schermen. Voor gemak worden de 5 schermen als volgt benoemd: inlogscherm, aanmeldscherm, groepenscherm, problemenlijstscherm en probleembeschrijvingscherm. Inlogscherm Bij het inlogscherm moet er de mogelijkheid worden gegeven om een account aan te maken. Als je al een account hebt aangemaakt, dan kan je inloggen met behulp van je e-mail adres en wachtwoord. Er is voor inloggen met e-mail adres gekozen, omdat deze altijd uniek is en de gebruiker niet een gebruikersnaam hoeft te verzinnen en onthouden. Aanmeldscherm De volgende gegevens zijn belangrijk bij het aanmaken van een account: naam, bedrijf, e-mail en wachtwoord (+verificatie van wachtwoord) van de gebruiker. Groepen scherm Bij dit scherm wordt er een overzicht gegeven van de groepen, waarvan de persoon lid van is of beheerd. Bovendien kan hier ook een nieuwe groep worden aangemaakt, waarbij elke lid aan een rol gekoppeld is. Enkele voorbeelden zijn manager, projectleider, medewerker ect.. Bij het uitnodigen van een persoon voldoet de naam van de persoon. Problemenlijst scherm Bij het problemenlijst scherm (de inhoud van een groep) kan je alle problemen zien die horen bij een groep waar je op hebt geklikt. Je kan vervolgens elk probleem aangeven als opgelost/niet-opgelost. Ook zie je de risico categorie en datum van invoering bij elke probleem. Als je klikt op een probleem dan ga je naar het probleembeschrijving scherm. Er moet ook een optie zijn om een overzicht van de leden te krijgen. Je moet hier ook een probleem kunnen toevoegen, bij het toevoegen moet een optie zijn om het anoniem te doen. Ook moeten er de opties worden gegeven om: mensen uit de groep te verwijderen, toe te voegen, rechten geven, beheer aan overplaatsen. Niet iedereen zal overigens toegang krijgen tot alle opties. Probleembeschrijving scherm Bij dit scherm wordt een probleem gedetailleerd beschreven en zie je bij welk project dit probleem hoort. Zaken die staan beschreven zijn: Risico factor, omschrijving, oorzaak, mislukte pogingen om het probleem op te lossen. Is het opgelost? Zo ja, wie heeft het op gelost, hoe en wanneer. Hoofd navigatie Het moet altijd mogelijk zijn om naar de volgende schermen te gaan: groepenscherm, problemenlijstscherm, settingsscherm.
14
Feedback Tijdens het ontwerp proces werden er diverse keren feedback gegeven aan de designer voor de wireframes. Hier zal worden besproken wat voor feedback de designer heeft gekregen en waarom deze keuzes zijn gemaakt. Versie 1 Bij het aanmeldscherm moet de mogelijkheid worden gegeven om ook het telefoonnummer in te vullen. Dit is handig omdat er dan korte vragen gesteld kunnen worden over de telefoon en het minder tijd kost dan mail. Het moet niet mogelijk zijn om in de hoofdnavigatie uit te kunnen loggen, dit kan beter in de settings menu. De reden hiervoor is om het de gebruiker makkelijk te maken om de applicatie te gebruiken, omdat hij/zij hierdoor niet opnieuw hoeft in te loggen. Door op het klikken van een groep moet eerst de problemen van de groep tevoorschijn komen, aangezien deze belangrijker zijn om te zien dan de leden van de groep. Het is namelijk vaak al bekend wie er allemaal in een groep zit. Ook moet hier de mogelijkheid worden gegeven om een nieuwe probleem te kunnen toevoegen. Bij het klikken op een lid van het groep is het niet mogelijk om deze persoon te bellen, mailen is wel een optie. Er kan niet gebeld worden met een iPad. Het moet mogelijk een probleem als opgelost te markeren door te swipen. Veel apps die populair zijn zoals Mailbox, gebruiken deze manier om dingen te verwijderen. Tevens is het een snelle en handige manier, wat de bruikbaarheid ten goede komt. In het problemenlijstscherm moet er een 3-spliting van problemen komen. Problemen die door de gebruiker zijn toegevoegd, problemen die naar aan de gebruiker zijn toegewezen om op te lossen en overige problemen( die niet aan de gebruiker zijn toegewezen en ook niet door de gebruiker zijn aan gemaakt). Zo wordt het overzichtelijker voor de gebruiker, omdat hij zo weet waar de problemen, die voor hem belangrijk zijn, staan In het probleembeschrijvingsscherm moet het mogelijk zijn om een probleem te volgen en aan iemand anders aan te wijzen die verantwoordelijk is voor het oplossen van het probleem. Een of meerdere verantwoordelijke aanwijzen is belangrijk omdat het anders voor kan komen dat mensen verwachten dat iemand anders het voor hun oplost. Problemen volgen kan worden gebruikt om selectief mensen meldingen over updates te sturen via mail of push notificatins.
15
Ook moet het moeilijkheidsgraad van het oplossen van een probleem veranderd worden naar een bar in plaats van sterren. Sterren zien er te positief uit voor een probleem. Een bar is meer gepast, want het is neutraler. De volgende elementen moeten terugkomen in het settingsmenu: ● ● ● ●
E-mail ontvangen uitzetten. Push berichten uitzetten. Profiel van de gebruiker kunnen wijzigen Profiel van een groep kunnen wijzigen
Versie 2 In het aanmeldscherm moet het mogelijk zijn om een nieuw wachtwoord op te vragen, mocht je deze vergeten zijn. Dit om de gebruiksvriendelijkheid te verhogen. Ook moet het mogelijk zijn om je werktitel te kunnen toevoegen. Zodat voor de teamleden in een groep duidelijk is wie wat doet, ook al zijn het niet zulke goede bekenden (bijv. bij een nieuweling). Als je een nieuwe groep toevoegt moet er een pop-up verschijnen waar je de verdere details in kan vullen. Zoals, naam van de groep en de personen die een uitnodiging moeten krijgen tot de groep. Een pop-up om iets in te vullen biedt duidelijkheid over dat er iets moet gebeuren, voordat de gebruiker verder kan. Bij het bekijken van de groep details moet het ook mogelijk zijn om een nieuwe gebruiker toe te voegen aan de groep. Hiervoor moet ook een pop-up tevoorschijn komen. Hiervoor geldt dezelfde redenatie als hiervoor. Bij het wijzigen van de profiel van de gebruiker moet ook de gebruiker in staat zijn functie te kunnen veranderen in geval van promotie of iets dergelijks.
16
Implementatie en systeem ontwerp Voor het ontwerp van het systeem is er gebruik gemaakt van het Model-ViewController-Model (MVC-Model), zie afbeelding 1. Dit houdt in dat de data (Model), de logica (controller) en de user interface (view) gescheiden wordt houden. Door gebruik te maken van dit model kan een van deze onderdelen makkelijk worden aangepast zonder dat het invloed heeft op de werking van de andere onderdelen. Het overzicht van dit ontwerp staat in appendix A In dit hoofdstuk zal worden uitgelegd hoe deze verschillende onderdelen zijn ontworpen en waarom dat zo is gedaan.
Afbeelding 1: Model-View-Controller Model
Model Het model gedeelte kan worden gezien als het geheugen van het systeem. De gegevens die het systeem nodig heeft staan hier opgeslagen en kunnen door de controller worden opgevraagd en aangepast. In dit systeem is het model opgesplitst in twee delen: de lokale (client-side) gegevens en de server gegevens. Dit is gedaan omdat het de bedoeling is dat meerdere mensen toegang hebben tot dezelfde data. Het is natuurlijk wel mogelijk om dit peer-to-peer te doen, maar in het geval dat een peer nieuwe data heeft, maar niet online is, dan hebben de andere peers geen toegang tot die data terwijl dit wel wenselijk is. Een server zorgt ervoor dat de data up-to-date is en voor iedereen bereikbaar blijft. Waarom zijn er dan nog lokale gegevens nodig? Als er geen lokale gegevens zouden zijn, zou de server als werkgeheugen moeten dienen. Dat zou er toe leiden dat de server een veel kleinere hoeveelheid clients aan kan omdat de server per client veel meer werk moet doen. Het is daarom beter om clients alleen te laten praten met de server als een van beide een update nodig heeft. Omdat de data die er client-side data en de server-side data verschillend zijn, zijn er twee verschillende model architecturen ontworpen. Deze zullen hier worden uitgelegd aan de hand van bijbehorende diagrammen.
17
Client-side Model De client is geïmplementeerd met de object-georiënteerde taal Objective-C. Dat betekent dat de data kan worden gerepresenteerd door middel van objecten die te relateren zijn aan de echte wereld. Het systeem heeft als doel, verschillende problemen die voorkomen in een afdeling/project/enz. (groep) op te slaan en weer te geven aan de leden van die groep.
Afbeelding 2 : Model – klassendiagram Client-side In afbeelding 2 is te zien hoe de verschillende objecten die afgeleid zijn van het doel in relatie tot elkaar staan. Te zien is dat een groep bestaat uit een aantal personen, een aantal problemen kan hebben en kan horen bij een bedrijf. Je zou ook kunnen zeggen dat een persoon in een of meerdere groepen zit of dat een bedrijf bestaat uit een aantal groepen, maar als dit ook in het ontwerp zou zitten, zou dit leiden tot circulaire referenties: een groep heeft een persoon, die persoon heeft een groep, die groep heeft een persoon enz. Over het algemeen is het beter om circulaire referenties te vermijden, omdat ze voor extra problemen zorgen zoals: ● De klassen kunnen niet zomaar gecompileerd worden: A moet gecompileerd worden om B te compileren en B moet gecompileerd worden om A te compileren. ● Hogere koppeling: allebei de klassen moeten gerecompileerd worden als een van hen is veranderd. ● Geen van de klassen kan individueel getest worden. ● Kans op het voor komen van oneindige loops. Client-side wordt er alleen gekeken vanuit het oogpunt van één persoon, het is dus niet interessant om te weten in welke groepen andere personen zitten. Vandaar dat deze relatie is weggelaten. Verder kan een probleem een aantal opmerkingen hebben, zodat het probleem ook besproken kan worden via de applicatie. Ook kan een persoon bij een bedrijf horen, deze informatie kan worden gebruikt om een aanbeveling te doen bij het uitnodigen van personen aan een groep.
18
Database Voor dit project wordt er tijdens de ontwikkelingsfase gebruik gemaakt van een lokale MySQL database om zonder kosten te kunnen testen. MySQL is open source en gratis te gebruiken. De database wordt op een MySql Server 5.0.11 gedraaid, er is voor MySql gekozen doordat deze makkelijk en flexibel te schalen is en door de sterke data bescherming mogelijkheden. Dit zijn vereisten voor de Acelera applicatie, derhalve er vertrouwelijke informatie opgeslagen moet worden. Ook schaalbaarheid en flexibiliteit is belangrijk voor de Acelera applicatie, de applicatie moet snel voorbereid zijn op een groot aantal gebruikers. Voordat de applicatie in de appstore wordt gezet, zal er een overstap plaatsvinden naar een betaalde database, genaamd de Amazon RDS (Relational Database Server). Hier is voor gekozen, omdat de Amazon RDS MySQL databases ondersteund waardoor er makkelijk overgestapt kan worden. Amazon RDS ook nog als voordeel dat het in de cloud is. Een cloud database heeft de volgende voordelen: het is in realtime te schalen, de locatie van de database kan worden gewijzigd en er is hoge garantie op beschikbaarheid van de data. Hieronder is een EER-model2 te zien van de Acelera applicatie.
1
http://www.mysql.com/ Het Enhanced Entity–Relationship Diagram is een diagram voor het representeren van een conceptueel datamodel. 2
19
Afbeelding 3 : Enhanced Entity-Relationship diagram v/d ontworpen database EER-Model Het EER(Enhanced Entity–Relationship) Diagram in afbeelding 3 bevat 11 tabellen, waaronder een closure tabel1 (Team_Structure). Deze tabel representeert de hiërarchie van de groepen (vaak is dit managerteam, afdeling/project, maar verdere dieptegang is hierdoor ook mogelijk). Verder geven de tabellen Person, Company, Team, Device, Problem en Comment de verschillende instanties aan. De tabel Works_In_Team is een tussenstap om aan te geven dat een persoon in meerdere groepen kan zitten en dat een groep uit meerdere personen kan bestaan. Dit geldt ook voor de tabel works_for_company, een persoon kan in meerdere bedrijven 1
Een Closure Tabel is een manier voor het weergeven van bomen in een relationele database.
20
zitten en een bedrijf kan meerdere personen hebben. In de tabellen Follow en Assign_To wordt bijgehouden welk persoon een probleem volgt of aangewezen is om een probleem op te lossen. De tabellen hebben ook inhoud (in de vorm van attributen). Er zijn hier drie verschillende vormen van: primary keys (gele sleutel), foreign keys (rode ruit) en overige gegevens (lege ruit). Een primary key is een unieke identificatie methode voor een instantie van een tabel (zoals een burgerservicenummer een unieke identificatie is voor een persoon uit Nederland). Een foreign key uit een tabel verwijst naar een primary key uit een andere tabel om aan te geven dat die twee iets met elkaar te maken hebben. Een persoon werkt bijvoorbeeld voor een bedrijf (dus heeft de tabel Person een foreign key van Company). De verschillende keys zorgen dus voor de uniekheid van instanties en relaties tussen de instanties. De overige gegevens, zijn gegevens die inhoudelijke informatie geven over de instantie (wat is de naam, beschrijving enz.).
21
View Het view gedeelte is hetgeen waar een gebruiker mee te maken heeft als hij het systeem gebruikt. Hier kan een gebruiker informatie zien die door het systeem wordt vertoond. Verder kan de gebruiker interacteren met de gepresenteerde informatie reageren. Door het gebruik van Xcode (de iOS editor van Apple), is de view ontworpen met behulp van een interface builder (een storyboard). Dit storyboard is dan ook terug te zien in het ontwerp (appendix A). Dit geeft alleen niet weer hoe de view zelf in elkaar zit. De werking van de view is wel te zien in afbeelding 4
Afbeelding 4 : Flow-Diagram van de views in het systeem Te zien is dat de view bestaat uit drie schermen: Log In View, Sign Up View en Main View. Main View heeft echter ook een aantal tabs (Groups, Problems en Settings) die weer andere subschermen laten zien. Log In View en Sign Up View spreken vrijwel voorzich: hier kan de gebruiker inloggen of zich inschrijven, waarna hij automatisch wordt ingelogd. Main View is waar het programma om draait. Er zijn echter ook een aantal schermen weggelaten in dit diagram: de pop-up schermen. Deze pop-up schermen dienen als een formulier, dat betekent dat er een aantal velden ingevuld en vervolgens ingediend kunnen worden. De schermen worden dus aangemaakt en vervolgens weer verwijderd.
22
Controller De controller is het brein van het systeem: het verwerkt en reageert op de handelingen van de gebruiker. Dit gebeurt niet alleen client-side maar ook server-side. Bijvoorbeeld als een server is verbonden met twee clients Alice en Bob, die allebei in dezelfde groep zitten. Als Alice een nieuw probleem aanmaakt, moet de server-side controller ervoor zorgen dat Bob hiervan op de hoogte is. De server-side is in dit systeem ervoor verantwoordelijk dat de database geüpdatet wordt en dat de client-side controllers hiervan op de hoogte zijn. Client-side Controller In het systeem heeft elk scherm van de view een aparte controller klasse. Deze klasses zijn in afbeelding 5 weergegeven. Hier zie je de Log In, Sign Up en Main View weer in terug en ook de Sub Views en Pop Up Views van Main View (subklassen van SubViewController en PopUpViewController zijn weggelaten i.v.m. de duidelijkheid van het diagram). Nieuw is DBHelper. Dit is een hulpklasse die communiceert met het server gedeelte van het systeem voor de controllers.
Afbeelding 5 : Controller – klassendiagram Client-side
23
Server-side Controller - Middleware De middleware zorgt ervoor dat de nodige aanpassingen in de database worden gemaakt, zodat gebruikers onderling op de hoogte zijn van veranderingen binnen de Acelera omgeving. De middleware is daarom het belangrijkste component in een systeem, omdat andere componenten afhankelijk zijn van deze communicatie laag. De middleware is opgedeeld in vier klassen, de RequestHandler, de InputHandler, de DatabaseHandler en de Postmark. De taak die de InputHandler heeft is, het verwerken van informatie die de client heeft aangepast of aanvraagt en stuurt dit door naar de RequestHandler. De RequestHandler zorgt ervoor dat de nodige gegevens in de database worden gezet of worden opgevraagd. Denk hierbij aan het valideren van het inloggen van een gebruiker of het toevoegen van een nieuwe probleem aan een groep. De DataBaseHandler zorgt ervoor dat er een connectie met de database gemaakt kan worden. Postmark zorgt ervoor dat er met de API van postmarkapp.com kan worden gecommuniceerd voor het e-mailen van de gebruikers. De communicatie tussen de klassen is in onderstaand diagram terug te zien.
Afbeelding 6 : Controller - klassendiagram Server-side
24
Testen Om de kwaliteit van de geschreven code te garanderen is er gekozen om unit testen en integratie testen te schrijven. Unit testen worden geschreven om software modules onafhankelijk van elkaar te testen. Het voordeel hiervan is dat er gekeken kan worden of er na wijziging van code, de software module nog steeds naar behoren werkt. Bij integratie testen worden de software modules met elkaar verbonden en als geheel getest. Ook voordat er aan integratie van code wordt gedaan is het essentieel om te weten of de software modulen onafhankelijk van elkaar werken. Als de module onafhankelijk van elkaar al niet naar behoren functioneren, dan zullen ze zeker niet werken als ze afhankelijk van elkaar zijn. Voor de front end en voor de middleware zijn er unit testen en integratie testen geschreven.
Middleware testen De middleware is de PHP server, die de data van en naar de front-end verwerkt. De PHP server kan data uitgelezen en opgeslagen in de database. Om dit voor dit component unit tests te schrijven is er gebruik gemaakt van een bestaand framework genaamd simpletest1. Dit is een framework die speciaal geschreven is om unit testing voor PHP mogelijk te maken. Alle functies die behoren tot de PHP server worden in unit tests gezet, om te controleren of ze naar behoren functioneren. Wanneer alle unit test slagen, is dit component klaar voor een integratie test met andere componenten.
Objective-C integratie testen De code dat in Objective-C is geschreven is merendeel gebaseerd op front-end functionaliteiten. De juiste data moet opgehaald worden afhankelijk van welke gebruiker is ingelogd. Ook moet deze data op de juiste manier worden gepresenteerd. De integratie tests die geschreven zijn voor Objective-C zijn hierop gericht. Er werd op de volgende manier getest, functionaliteit van de applicatie werd nagebootst door automatische testen en dummy data die in de backend zit. Vervolgens werd er gekeken of de juiste aanpassingen in de back end zijn gemaakt. De integratie tests zijn geschreven in Objective-C, waarin de functies uit de middleware worden aangeroepen om informatie te halen uit de database. De integratie test duurde het langst, vanwege het koppelen van losstaande systemen, namelijk de middleware koppelen met de frontend.
1
http://www.simpletest.org/
1
25
Scenario testen Scenario tests worden geschreven om typische en bijzondere situaties die zich kunnen voor doen in de applicatie te testen. Een scenario test bestaat uit een aantal test cases waarin in een functionaliteit van start tot eind wordt doorlopen. De applicatie wordt hier getest door middel van het drukken op knopen en het invoeren van data in de applicatie zelf. Hier zijn een aantal scenario’s die zijn getest. Registreren: De tester start de applicatie en drukt op “sign up”. De gebruiker navigeert naar de registratie scherm en vult alles in behalve zijn username. Daarna druk de gebruiker op “sign up”. De tester controleert of de applicatie een fout melding geeft. Nu vult de tester de registratie formulier ook in met een username en drukt op “sign up”. De test controleert nu of de gebruiker correct staat opgeslagen in de database. Probleem toevoegen aan een nieuwe Groep: De tester logt in met een bestaande account en voegt een groep toe. Daarna nodigt de tester andere mensen uit. De tester controleert of er een uitnodiging mail is verstuurt. Hierna wordt er een probleem toegevoegd aan de groep. De tester controleert of de leden van de groep een mail hebben gekregen van de probleem dat is toegevoegd. De leden zetten mail notification uit in de settings scherm. De tester voegt nogmaals een probleem toe. Nu controleert de tester of er geen mail is verzonden naar de leden die de mail notification hebben uitgezet. Probleem oplossen: De tester logt in op een bestaande account en navigeert naar een groep. In de groep verwijderd hij een probleem door op het probleem te swippen naar links. De tester drukt op “solve” en controleert of het probleem in de applicatie is verwijderd. Verder controleert de tester ook of het probleem in de database daad werkelijk is verwijderd.
Usability testen Usability testen worden gedaan om na te gaan of een applicatie werkt naar verwachting van gebruikers. Daarom worden deze tests uitgevoerd door echte gebruikers. Deze gebruikers krijgen een script waarin staat wat de taken zijn die zij moeten uitvoeren. Op deze manier wordt getest of de applicatie voldoet aan de user-centered interaction design.
26
Software Improvement Group Feedback Tegen het eind van het project werd de code van het project gecontroleerd door de Software Improvement Group (SIG). SIG is een bedrijf dat advies geeft aan hun klanten (grotendeels software ontwikkelaars) zodat die kosten kunnen reduceren, de effectiviteit kunnen verhogen en IT-projecten sneller kunnen opleveren. Na de evaluatie bleek dat de kwaliteit van de code vier van de vijf sterren waard was dit is een bovengemiddelde scoren. Voor de beoordeling van de code werd er gekeken naar de volgende criteria punten: - Volume van de code - Duplicatie van code - Unit complexiteit - Unit size - Unit interface - Module coupling Er waren twee punten waar niet goed op gescoord was waardoor de vijf sterren niet bereikt waren: unit size en module coupling. Voor unit size wordt er gekeken naar het percentage van methodes dat bovengemiddeld groot is. Voor Module Coupling wordt er gekeken naar het percentage van de code wat relatief vaak wordt aangeroepen.
Verbeteringen Om de unit size te verbeteren is er in de code gezocht naar de bovengemiddeld grote methodes. Vervolgens is er gekeken naar welke functionaliteit in een kleinere methode gestopt kon worden. Door de methodes op deze manier in stukjes te knippen, werd de code overzichtelijker en de inhoudelijke werking toch behouden. Verder is ervoor gekozen het systeem ontwerp niet aan te passen voor de module coupling. De reden is namelijk dat er vanaf de client een connectie moet gemaakt worden naar de server. Hier zorgt in dit systeem de DBHelper klasse voor. Vandaar dat alle controller klassen van de client gebruik maken van de DBHelper en de coupling dus hoog is. Als er meerdere klassen voor de connectie naar de database gebruikt zouden worden, zou de DBHelper geen hoge koppeling meer hebben, maar de InputHandler klasse van de server wel. Meerdere InputHandlers zouden dit probleem weer oplossen, maar ook een nieuwe creëren. Het punt is dat de controllers voor de connectie van de database ergens convergeren en dat daar de hoge coupling ontstaat. Dit zou alleen tegen te gaan zijn door minder controllers te gebruiken, maar dan zouden de controllers zelf erg groot moeten worden om meerdere views te kunnen besturen.
27
Conclusie Het doel van dit project was om een iPad applicatie te ontwikkelen dat stimuleert om problemen in groepen/project in een vroeg stadium op te lossen. Hierbij is er gekeken naar bestaande applicatie die veel gebruikt worden en een goede design hebben. Acelera is een nieuwe tool die managers helpt projecten/groepen beter te leiden, omdat de applicatie manager op de hoogte houdt van problemen die zicht voordoen in groepen/projecten die hij/zij leidt. De applicatie maakt het niet alleen mogelijk om problemen aan te kaarten in een groep/project, maar je kan problemen in je groep/project “volgen” en ”toewijzen” aan mensen in de groep/project, zodat mensen email notificaties krijgen als het probleem is gewijzigd en ze kunnen zien wie er mee bezig is/zijn. Het stadium van ontwikkeling waar Acelera nu in zit is Alpha1 fase en is pas een Bèta versie als de functionaliteiten die meerwaarde leveren zijn geïmplementeerd en getest. De Bèta versie kan dan worden ingediend in de App Store, zodat de eerste gebruikers feedback kunnen gegeven op het product.
Aanbevelingen voor toekomstige werkzaamheden Tijdens het implementeren van Acelera is er een SWOT analyse2 gemaakt. Hieruit volgde dat de applicatie weaknesses heeft die verholpen moeten worden in de toekomst. Hoewel alle must haves uit de requirements en een groot deel van de should haves zijn geimplementeerd. Zijn er nog steeds uitbreidingen mogelijk die de applicatie veel meerwaarde geven.
Systeem uitbreiding Uit de weaknesses in de SWOT analyse kwam duidelijk naar voren dat Acelera op meer platformen beschikbaar moet zijn. Deze zwakte kan in het vervolg traject verholpen worden door de systeem uit te breiden om het beschikbaar te stellen voor meerdere platformen. Ideaal zou zijn om de Acelera applicatie zowel op Android en Windows 8 als in een internet browser beschikbaar te hebben. Op deze manier is de applicatie toegankelijk voor iedereen en is het geen vereiste meer om in het bezit te zijn van een iPad. Bij het ontwikkelen van de back-end3 voor Acelera is er rekening gehouden met deze uitbreiding naar andere platformen. Als er dus voor wordt gekozen om systeem uit te breiden, dan kan dit gerealiseerd worden zonder een totaal nieuwe back-end en middleware systeem te ontwikkelen. 1
In dit stadium is er een werkende applicatie, maar het heeft nog niet alle functionaliteiten. De belangrijkste functionaliteiten draaien al en kunnen uitgebreid getest worden. 2 Een SWOT analyse is een gestructureerde planning methode dat gebruikt wordt om de Strengths, Weaknesses, Opportunities en Threats van een product of business te bepalen. 3 Een back-end is server/applicatie die de front-end ondersteund en fungeert als een data leverancier.
28
Optimalisatie Op dit moment laadt Acelera haar data in vanuit de database in een redelijke tijd, maar dit kan nog beter. Op dit moment wordt data, zoals in welke groep de gebruiker zit en welke problemen er spelen in elke groep geladen vanuit de database. Dit wordt elke keer gedaan wanneer de applicatie wordt opgestart. Om de laadtijd van deze data te optimaliseren kan Acelera haar data lokaal opslaan. Dit kan gedaan worden door deze data lokaal op te slaan in XML-files, die vervolgens worden uitgelezen als de applicatie wordt gestart. Dit is sneller, omdat het uitlezen van data op het apparaat zelf sneller gaat dan het opvragen van data in een database. Ook zorgt dit voor minder belasting van de server en is er geen internet connectie vereist.
Aanbevelingen voor Milvum Acelera kan op dit moment problemen in groepen aankaarten, zodat ze snel worden opgelost. Dit kan echter worden uitgebreid door het aankaarten van risico’s voordat een project begint. Als risico’s voordat een project begint bekend zijn, zijn deze beter te controleren of te vermijden door acties te ondernemen. Het invoeren van risico’s vooraf gaand van een project kan dus helpen bij risk management1. Ook is het erg handig als er bijlages kunnen worden toegevoegd aan een probleem, om het probleem sneller duidelijk te maken. Na het toevoegen van een probleem moet het ook mogelijk zijn om een deadline aan te gegeven om het op te lossen. Verder kan de applicatie uitgebreid worden met een logboek, waarin wordt vermeld hoe problemen en risico’s zijn opgelost of vermeden. Een goede reden om dit te implementeren is, dat groepen in de toekomst kunnen leren van fouten in het verleden. Dit kan veel tijd en geld besparen en stimuleert de knowledge management binnen het bedrijf. "If only HP knew what it knows it would make three times more profit tomorrow" Lew Platt, ex CEO Hewlett Packard
1
Risk management is het identificeren/controleren en elimineren van onacceptabele risico’s.
29
Appendix A – Klassen diagram van het MVC-model
30
Appendix B – SIG code evaluatie De code van het systeem scoort 4 sterren op ons onderhoudbaarheidsmodel, wat betekent dat de code bovengemiddeld onderhoudbaar is. De hoogste score is niet behaald door een lagere score voor Unit Size en Module Coupling. Voor Unit Size wordt er gekeken naar het percentage code dat bovengemiddeld lang is. Het opsplitsen van dit soort methodes in kleinere stukken zorgt ervoor dat elk onderdeel makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden wordt. Binnen de langere methodes in dit systeem, zoals bijvoorbeeld de 'initWithJSON'methode, zijn aparte stukken functionaliteit te vinden welke ge-refactored kunnen worden naar aparte methodes. Commentaarregels zoals bijvoorbeeld '//find the right company in the list of companies' en '//add the right persons to the group as member (and admin)' zijn een goede indicatie dat er een autonoom stuk functionaliteit te ontdekken is. Het is aan te raden kritisch te kijken naar de langere methodes binnen dit systeem en deze waar mogelijk op te splitsen. Voor Module Coupling wordt er gekeken naar het percentage van de code wat relatief vaak wordt aangeroepen. Normaal gesproken zorgt code die vaak aangeroepen wordt voor een minder stabiel systeem omdat veranderingen binnen dit type code kan leiden tot aanpassingen op veel verschillende plaatsen. In dit systeem wordt de module 'DBHelper' op verschillende plaatsen aangeroepen, daarnaast is deze module vrij fors. Het lijkt erop alsof deze module twee verschillende type functionaliteit bevat. Gegeven de prefix van de methoden is er functionaliteit gerelateerd aan de Database en voor JSON-conversie binnen deze module geimplementeerd. Om zowel de grootte als het aantal aanroepen te verminderen zouden deze functionaliteiten gescheiden kunnen worden, wat er ook toe zou leiden dat de afzonderlijke functionaliteiten makkelijker te begrijpen, te testen en daardoor eenvoudiger te onderhouden worden. Over het algemeen scoort de code bovengemiddeld, hopelijk lukt het om dit niveau te behouden tijdens de rest van de ontwikkelfase. De aanwezigheid van test-code is in ieder geval veelbelovend, hopelijk zal het volume van de test code ook groeien op het moment dat er nieuwe functionaliteit toegevoegd wordt.
31
Appendix C – Oriëntatieverslag
Oriëntatie verslag Introductie project Probleem analyse Milvum opdracht Interviews Interview met Directeur - Verstegen Interview met Floormanager/Passenger Assistant - Schiphol Group Concurrentie onderzoek Asana Tracky Omniplan Basecamp Fogbugz Bestaansrecht Data opslag Gegevens en Account beheer Eisen voor de appstore Xcode
32
Introductie project Het uiteindelijke product dat opgeleverd moet worden voor het project is een applicatie die voor de iPad geoptimaliseerd is. Dit betekent dat er gekeken moet worden welke tools er gebruikt worden voor het ontwikkelen van applicaties voor iOS. De gegevens die gecreëerd of uitgelezen worden door de applicatie moeten voorzien zijn van enige beveiliging, aangezien dit gevoelige informatie van het bedrijf kan zijn. Ook is het de bedoeling dat de gegevens vanaf meerdere systemen beheerd kan worden.
Probleem analyse Milvum opdracht De opdracht voor dit project is het maken van een iPad applicatie. Deze applicatie dient het makkelijker om problemen binnen projecten op te lossen. Doordat managers en projectleiders een goed overzicht hebben over de problemen binnen en project. In de applicatie kunnen projectleden problemen aan kaarten. De manager moet deze weer gemakkelijk en overzichtelijk terug kunnen zien op de applicatie.
Interviews Voor de vooronderzoek zullen er een aantal managers worden geïnterviewd. Uit dit interview zal blijken of de applicatie elementen mist en of de applicatie praktisch is op de werkvloer. Verder zal er goed overwogen worden of de suggesties van de geïnterviewde verwerkt kunnen worden in de applicatie.
Interview met Directeur - Verstegen
Verstegen is een bedrijf van ongeveer 400 man, waarvan 300 gevestigd zijn in Nederland. Ze verkopen kruiden en sauzen aan supermarkten, maar ook aan andere voedsel industrieën en cateringen. Het bedrijf bestaat uit onder andere een productielocatie (fabriek) die weer is opgedeeld in droge producten en sauzen. De afdelingen in het bedrijf bestaan uit verkoop, verkoop ondersteuning, personeelszaken, planbureau, inkoop en ontwikkeling.
Al deze afdelingen zijn afhankelijk van elkaar en ondersteunen elkaar waar nodig. Doordat ze van elkaar afhankelijk zijn, zijn projecten afdelingsoverschrijdend. Een project valt dus niet onder één afdeling, maar is een onderdeel van meerdere afdelingen tegelijk.
33
Projecten hebben vaak een wekelijkse bijeenkomst en een maandelijkse voortgangspresentatie (gegeven door de projectleider). Kleinere problemen komen naar voren tijdens de wekelijkse bijeenkomst. Zaken zoals geld en tijd te korten komen bij de maandelijkse rapportage aanbod. Omdat het bedrijf niet uitzonderlijk groot is, zien mensen elkaar vaak. Iedereen kent elkaar, hierdoor worden project problemen ook sneller besproken en afgehandeld.
Tijdens evaluatie van een project wordt eigenlijk enkel gekeken naar wat er fout is gegaan (en hoe dat in het vervolg verbeterd kan worden). Alle handelingen zijn tijdens een project in een logboek beschreven, de projectleider concludeert aan de hand van dit logboek de werkzaamheden en rapporteert dit.
Veiligheidsschendingen worden ook gemeld, grotendeels door de leidinggevenden. Degene die de veiligheid schend krijgt een brief thuis gestuurd. Dit proces is ook vooral door regelgeving gestimuleerd, genaamd “verantwoordelijkheid voor werknemers”. Collega’s onderling melden dit niet zo vaak, maar worden door optreden van de leidinggevenden gestimuleerd om dit wel te doen.
De directie is blij met zo veel mogelijk rapportages, omdat hier veel conclusies uit getrokken kunnen worden. Eerlijkheid in het bedrijf Verstegen wordt erg gewaardeerd en heeft dan ook nooit vervelende gevolgen. Het melden en rapporteren heeft geen grote consequenties voor de werknemers, omdat rapporteren grote voordelen heeft voor de directie.
Er wordt verwacht dat anonimiteit de werksfeer niet ten goede zou komen, maar in sommige gevallen zou het misschien toch handig zijn. Er zijn hier ideeën bussen voor.
De directeur is van mening dat de iPad applicatie geen meer waarde levert voor zijn bedrijf. Dit onderbouwde hij door te zeggen dat problemen bij werknemers al snel worden gemeld en afgehandeld.
Interview met Floormanager/Passenger Assistant - Schiphol Group De functie houdt in dat er assistentie wordt verlenen op de werkvloer binnen Schiphol. Hierbij gaat het om Plaza(begane grond/winkels), alle vertrekhallen en alle lounges achter de douane. Taken als floormanager zijn onder andere: · Baairegulatie · Reguleren van de passagier doorstroming · Assistentie bieden aan de luchtvaartmaatschappijen en passagiers
34
Schiphol is verdeeld in talloze afdelingen en groepen. De afdeling Floormanagement (FLM) is een van de afdelingen binnen Schiphol. Het Floormangement bestaat uit Duty Managers, Floormanagers, Assistent-Managers en Passenger Assistants. Voor het oplossen van problemen is het belangrijk dat er een goede communicatie is en dat er vaak wordt geëvalueerd. Binnen de afdeling wordt er 2-4 keer per dag is er een debriefing tussen de duty managers, floormanagers en assistent-managers. Hier worden alle positieve zaken zowel als negatieve zaken besproken omtrent de werkvloer. Alle problemen zijn bekend bij Duty Managers en Operationel Managers.
Een elektronisch systeem zoals een applicatie, waarmee werknemers problemen bekent kunnen maken wordt nog niet gebruikt. Problemen en klachten van zowel passagiers als medewerkers worden besproken tijdens de briefing onder de werknemers. Waarna wordt nagedacht over een geschikte oplossing.
Smartphones zijn niet toegestaan op de werkvloer voor de passenger-assistants. Hoewel smartphones wel worden gebruikt door alle managers als communicatiemiddel. iPads worden al gebruikt door passenger-assistants voor achter de douane. Deze iPads laten de prognose rondom de drukte zien op Schiphol. Zodoende zijn de passenger assistants voorbereid op de piekmomenten en dus extra alert.
Problemen in deze afdeling hebben prioriteiten hoe hoger de prioriteit hoe sneller het probleem wordt aangepakt door de Duty Manager. Prolemen worden voor de debriefing vaak kort er krachten beschreven en gecommuniceerd met medewerkers.
De Floormanager is van mening dat anonimiteit het bekent maken van problemen zal bevorderen. Aangezien mensen vaak verlegen of bang zijn om iets te melden aan leidinggevende.
Na het vragen of de iPad applicatie een goed idee is, werd er dit geantwoord door de Floormanager: “Op het eerste gezicht lijkt het een goed idee. Ik denk dat het belangrijk is dat er gekeken moet worden naar het type bedrijf. Punten zoals: wat voor bedrijf is het, nationaal of internationaal, hiërarchie, specialisatie en omvang zullen belangrijk zijn als voorwaarden voor de app. Mijn afdeling, het Floormanagement zal waarschijnlijk niet wachten op de app aangezien er constant gebriefd worden tussen de verschillende samenwerkingspartijen. Zo wordt er onder elkaar gebriefd maar ook met KLM, security en de marechaussee. Dit houdt dus in dat eventuele problemen/conflicten/situaties altijd bekend zijn binnen de afdeling. Er is dus niet een apart middel nodig om dit naar voren te brengen. Het idee klinkt goed maar er zal zeker kritisch naar het bedrijf gekeken moeten worden wil het gebruik van de app slagen.”
35
Concurrentie onderzoek Om van de Enterpise App van Milvum een succes te maken, zal er goed gekeken moeten worden naar de concurrentie. Dit zal gedaan worden door soortgelijke bestaande applicaties te benchmarken. De applicaties die gebruikt zullen worden voor de analyse zijn: Asana, Tracky, Omniplan, Basecamp en Fogbugz. Deze hebben allemaal namelijk dezelfde doelgroep: bedrijven die bestaan uit meerdere afdelingen/groepen.
Asana Asana is een web gebaseerde projectmanagement tool, het biedt geen native mobiele applicaties aan. Het is opgericht door 2 leidinggevenden bij Facebook die vonden dat de huidige technologie geen uitkomst bood om efficiënt in een teamverband te werken. Asana werd al gauw gebruikt door Facebook. De teams die ervan gebruik maakten kregen meer gedaan met minder moeite: er waren minder meetings en het volume van het aantal e-mails ging omlaag. Met Asana is het mogelijk om taken te verdelen over teamleden. Ook is het mogelijk om taken weer in subtaken onder te verdelen. Bij deze taken kunnen ook bijlages worden toegevoegd en is het mogelijk om commentaar toe te voegen bij een taak. Taken waarvoor een datum bekend zijn kunnen worden gekoppeld aan een datum.
Er zijn twee versies van Asana die je kan gebruiken: de gratis en de premium versie. Bij de gratis versie kunnen er maximaal 15 gebruikers in een team zitten. Bij de premium versie zijn de kosten afhankelijk van de grootte van een team. Tot 15 teamleden kost Asana 50 euro per maand. Tot 30 gebruikers kost het 100 euro per maand. De hoogst aangegeven prijs is voor teams van 100 gebruikers: 800 euro per maand. Bij grotere teams wordt er gevraagd om persoonlijk contact op te nemen met Asana, maar er kan aangenomen worden dat het meer zal kosten dan 800 euro per maand.
Tracky Tracky biedt dezelfde mogelijkheden als Asana, het ziet er weliswaar iets grafischer uit. Dit maakt het wel wat minder zakelijker. Tracky biedt naast een web versie ook een applicatie voor de iPhone aan. Tracky kost 5 dollar per gebruiker per maand.
Omniplan Omniplan is niet web gebaseerd, maar biedt native applicaties aan voor de Mac en iPad. De gegevens worden via de server van Omnigroup gesynchroniseerd. Het biedt ook de mogelijkheid om taken direct in je agenda te zetten, dit kan ook via Google Agenda. Omniplan kost eenmalig 199 dollar, dit is een licentie die voor één enkele gebruiker geldig is.
Basecamp
36
Basecamp is web gebaseerd en biedt naast dit ook een iPhone applicatie aan. Waarin deze applicatie echter verschilt van de andere applicaties, is dat de Application programming interface van Basecamp opensource is. Dit betekent dat andere softwareontwikkelaars extra functionaliteiten aan Basecamp kunnen toevoegen. Er zijn verschillende abonnementen, er wordt niet per gebruiker betaald, maar per project. Het goedkoopste abonnement begint bij 20 dollar per maand.
Fogbugz Fogbugz is een online issue & bug tracking, project management en customer support tool. Het is bedoeld om software projecten efficiënter te laten verlopen. De doelgroep van Fogbugz zijn bedrijven die software projecten hebben lopen. Fogbugz kost 25 dollar per gebruiker. Fogbugz biedt geen native mobiele applicaties aan. Het wordt gebruikt door grote en bekende bedrijven, zoals Apple, Intel, Microsoft en Sony.
Bestaansrecht Er zijn veel applicaties al beschikbaar die de mogelijkheid bieden om werk goed te kunnen verdelen. Ook bestaan er applicaties zoals Fogbugz die issue tracking mogelijk maken voor projecten. Applicaties zoals deze richten zich op software projecten en taken waar software geen rol speelt. Er is nu niets op de markt wat de mogelijkheid biedt om gemakkelijk en mobiel de problemen binnen een bedrijf te bekijken m.b.v. een hiërarchie van groepen.
Data opslag Voor dit project wordt er tijdens de ontwikkelings fase gebruik gemaakt van een lokale MySQL database en wordt de applicatie uitvoerig getest. MySQL is open source en gratis te gebruiken. Voordat de applicatie in de appstore wordt gezet, zal er een overstap plaatsvinden naar een betaalde database, genaamd de Amazon RDS (Relational Database Server). Hier is voor gekozen, omdat de Amazon RDS MySQL databases ondersteund waardoor er makkelijk overgestapt kan worden. Amazon RDS heeft nog meer voordelen, want het is een cloud database. Een cloud database heeft de volgende voordelen: het is in realtime te schalen, de locatie van de database kan worden gewijzigd en er is hoge garantie op beschikbaarheid van de data.
37
fig. 1 EER Diagram
Dit EER(Enhanced Entity–Relationship) Diagram bevat zes tabellen, waaronder een closure tabel (Groep_Structuur). Deze tabel representeert de hiërarchie van de groepen (vaak is dit managerteam, afdeling/project, maar verdere dieptegang is hierdoor ook mogelijk). Verder geven de tabellen Persoon, Bedrijf, Groep en Probleem de verschillende instanties aan. De tabel WerktIn is een tussenstap om aan te geven dat een persoon in meerdere groepen kan zitten en dat een groep uit meerdere personen kan bestaan. De tabellen hebben ook inhoud (in de vorm van attributen). Er zijn hier drie verschillende vormen van: primary keys (gele sleutel), foreign keys (rode ruit) en overige gegevens (lege ruit). Een primary key is een unieke identificatie methode voor een instantie van een tabel (zoals een burgerservicenummer een unieke identificatie is voor een persoon uit Nederland). Een foreign key uit een tabel verwijst naar een primary key uit een andere tabel om aan te geven dat die twee iets met elkaar te maken hebben. Een persoon werkt bijvoorbeeld voor een bedrijf (dus heeft de tabel Persoon een foreign key van Bedrijf). De verschillende keys zorgen dus voor de uniekheid van instanties en relaties tussen de instanties. De overige gegevens, zijn gegevens die inhoudelijke informatie geven over de instantie (wat is de naam, beschrijving enz.).
38
Gegevens en Account beheer Het is belangrijk de veiligheid van de data tot op zekere hoogte te kunnen garanderen. Als het gebruik maken van deze applicatie betekent dat onbevoegde mensen over je schouder kunnen meekijken, wordt de kans klein dat er daadwerkelijk gebruik wordt gemaakt van de applicatie. Het gebruiken van een Amazon RDS heeft als voordeel dat er een redelijke beveiliging op je database zit: zonder account is het niet mogelijk om data te verkrijgen. Er zijn echter een aantal bekende manieren om toch onbevoegd toegang te krijgen tot de database1: • Brute-force wachtwoord raden. • Wachtwoord en data sniffing. • SQL injecties. • Privilege escalatie. • Privilege misbruik. Sommige van deze manieren zijn te voorkomen, andere niet. Het brute-force raden van het wachtwoord is bijvoorbeeld niet te voorkomen, alleen moeilijk te maken door goede wachtwoorden te gebruiken (wachtwoorden die niet in het woordenboek voorkomen bijvoorbeeld). Ook privilege misbruik is niet te voorkomen. Sommige mensen hebben nou eenmaal bepaalde rechten nodig in een database om hun werk te kunnen doen. Als database administrator is het niet te voorkomen dat die mensen hier misbruik van maken (foto van een scherm is makkelijk gemaakt).
Andere risico’s zijn beter te voorkomen. Bij SQL injectie worden SQL queries aangepast via de invoer mogelijkheden (bijvoorbeeld door een SQL commando in te voeren als een gebruikersnaam). Hierdoor kan er meer data uit de database worden verkregen dan is toegestaan. Doordat SQL injectie afhankelijk is van invoer velden kan het worden tegen gegaan door alle invoer te controleren, voordat dat daadwerkelijk naar de database wordt doorgestuurd. Privilege escalatie komt voor als accounts meer rechten hebben dan ze nodig hebben. Door de rechten van gebruikers minimaal te houden, verklein je de schade die zo’n gebruiker potentieel kan aanrichten. Wachtwoord en data sniffing (ook wel bekend als Man-in-the-middle-attack) kan misschien niet worden voorkomen, maar het kan wel worden tenietgedaan door middel van encryptie: onleesbare gegevens zijn onbruikbare gegevens.
Eisen voor de appstore Apple zet zich in om de app store te voorzien van kwalitatieve Apps. Daarom wordt een applicatie gecontroleerd op veel richtlijnen voordat hij toegelaten wordt tot de Appstore. Een aantal richtlijnen wat betreft de functionaliteit van de Applicatie zijn: de Applicatie mag niet crashen. Voor de User Interface zijn er ook regels. Verder mag een app geen bugs bevatten. Een aantal van dit soort richtlijnen zijn: de logo van de app, de toolbar en de application bar moeten een vaste afmeting hebben. Verder mag de app geen standaard functionaliteiten zoals de volume knop laten dienen voor andere doeleinde. De volledige lijst is te vinden op App store review guidelines. Voordat een applicatie wordt ingeleverd is het
1
http://www.darkreading.com/authentication/hackers-choice-top-six-database-attacks/211201064
39
dus belangrijk om deze punten na te gaan, omdat het certificeren van een applicatie 2 weken duurt.
Xcode Xcode is de IDE waarmee iOS applicaties gemaakt kunnen worden. Het functioneert als code editor, simulator, compiler en het is mogelijk om het gedrag en performance van de applicatie te meten.
40
Appendix D – Plan van aanpak
Plan van aanpak
Auteurs: Viresh Jagesser Kaj Oudshoorn Salim Hadri
41
Plan van aanpak 1 Inleiding 1.1 Het plan van aanpak 1.2. Schets van het bedrijf 1.3. Achtergrond en aanleiding van de opdracht 2 Opdrachtomschrijving 2.1 Inleiding 2.2 De opdrachtgever 2.3 Contactpersonen 2.4 Probleemstelling 2.5 Doelstelling 2.6 Opdrachtformulering 2.7 Op te leveren producten 2.8. Randvoorwaarden 2.9. Risicofactoren 3 Aanpak 3.1. Inleiding 3.2 Methodiek 3.3 Technieken 3.4 Werkzaamheden 3.5 Planning 4 Projectinrichting 4.1 Inleiding 4.2 Betrokkenen 4.3 Informatie 4.4 Faciliteiten 5 Kwaliteitsborging 5.1 Inleiding 5.2 De kwaliteit 5.3 Versiebeheer 5.4 Evaluatie
42
1 Inleiding 1.1 Het plan van aanpak Dit rapport beschrijft het plan van aanpak voor het maken van de mobiele Enterprise Applicatie voor Milvum. In dit rapport zal de opzet van het project worden besproken. Dit rapport bestaat uit 5 hoofdstukken. De opdrachtomschrijving wordt in hoofdstuk 2 beschreven. In hoofdstuk 3 wordt er dieper ingegaan op de aanpak. Vervolgens wordt de project inrichting beschreven in hoofdstuk 4. Tot slot wordt er in hoofdstuk 5 de kwaliteitsborging beschreven.
1.2. Schets van het bedrijf Milvum is een bedrijf dat opgericht is door studenten in 2012. Het bedrijf specialiseert zich in het maken van mobiele applicaties voor Windows Phone, iOS en Android. Milvum richt zich zowel op Business to Consumer als op Business to Business Applicaties. Op de Windows Phone Store heeft dit bedrijf al een applicatie genaamd Voetbal Uitslagen die op nummer 1 staat. De Enterprise Applicatie welke voor de iPad ontwikkeld wordt is vooral gericht op de management laag in bedrijven en valt in de categorie Business to Business Applicaties.
1.3. Achtergrond en aanleiding van de opdracht Milvum biedt tot nu toe alleen maar maatwerk voor haar klanten, waarbij elk project van scratch af aan wordt begonnen. Dit kost veel tijd en geld, daarom wil Milvum een product lanceren met relatief minder ontwikkel tijd, dat verkocht kan worden aan meerdere klanten. Arvind Jagesser de Operations Director van Milvum heeft Salim Hadri, Kaj Oudshoorn en Viresh Jagesser - de studenten voor die BSc project(Bachelor-project) - benaderd om als BSc project een Enterprise Applicatie te maken. Deze applicatie zal na oplevering in de appstore worden gezet.
43
2 Opdrachtomschrijving 2.1 Inleiding In dit hoofdstuk wordt er dieper ingegaan op het doel van het project en wordt er beschreven wat er gemaakt gaat worden. Als eerst wordt er in paragraaf 2.2 en 2.3 beschreven wie de opdrachtgever is en de contact personen zijn voor dit project. Daarna zal de probleemstelling worden behandeld in paragraaf 2.4. Vervolgens wordt de doelstelling van de Enterprise Applicatie gegeven in paragraaf 2.5. In paragraaf 2.6 wordt de opdracht beschreven. Vervolgens wordt er in paragraaf 2.7 de op te leveren producten beschreven. De randvoorwaarden worden beschreven in paragraaf 2.8 en tot slot wordt er in paragraaf 2.9 de risicofactoren beschreven.
2.2 De opdrachtgever De opdrachtgever voor dit project is Arvind Jagesser, de Operations Director van Milvum. Hij heeft Milvum opgericht in 2012 samen met technische informatica studenten aan de TU Delft. Als opdrachtgever van dit project zal Arvind elke week feedback geven op de in te leveren zaken van het project.
2.3 Contactpersonen Naast de opdrachtgever zijn er ook andere contactpersonen van belang voor dit project. De begeleider vanuit de TU Delft is Sam Solaimani. De coördinators van het BSc project zijn Gerd Gross en Martha Larsson.
2.4 Probleemstelling Problemen binnen een bedrijf zijn een probleem. Ze worden vaak mondeling of per email gemeld, waardoor er kans is dat ze tijdelijk vergeten worden. Ook wordt er soms te lang gewacht met het melden van een probleem, omdat men te lang het zelf probeert op te lossen. Soms geeft een probleem aan dat een persoon A zijn werk niet goed doet. Als A wel weet dat het probleem er is, maar vanwege zijn reputatie het niet durft te melden, dan wordt dit probleem niet of laat opgemerkt door het bedrijf. Dit alles heeft als gevolg dat problemen te langzaam worden opgelost, wat invloed heeft op de efficiëntie van het bedrijf.
2.5 Doelstelling Het doel van dit project is om met een iPad applicatie een duidelijk overzicht te geven van wat er gaande is binnen het bedrijf d.m.v. het aankaarten van relevante problemen binnen een projectgroep. Ook moet de applicatie bij oplevering een product zijn dat gelanceerd kan worden op de markt. Het is de bedoeling om managers een duidelijker overzicht te geven over problemen binnen projecten, zodat de manager op tijd op de hoogte is van eventuele problemen. De voordelen voor een bedrijf zijn: ● Tijd besparen ● Geld besparen ● Fiasco’s voorkomen
44
Er kan tijd bespaard worden, wanneer managers en projectleiders snel en gemakkelijk toegang krijgen tot de problemen binnen een project. Er kan meer geld bespaard worden, doordat het gemakkelijker is om problemen direct aan het licht te brengen, waardoor de problemen sneller opgelost kunnen worden. Door in een vroeg stadium een probleem op te lossen kunnen fiasco’s worden voorkomen. Hoe dit gedaan zal worden moet nog onderzocht worden. "You don't drown by falling in the water; you drown by staying there." — Edwin Louis Cole
2.6 Opdrachtformulering De opdrachtformulering voor dit project is het maken van een iPad applicatie. Deze applicatie dient het makkelijker om problemen binnen groepen op te lossen. Managers en projectleiders moeten een goed overzicht hebben over de problemen binnen de groepen die zij leiden. In de applicatie kunnen groepsleden problemen aan kaarten. De manager moet deze weer gemakkelijk en overzichtelijk terug kunnen zien op de applicatie.
2.7 Op te leveren producten Milvum heeft de opdracht gegeven om een Enterprise Applicatie te maken voor iOS 6.1, die geoptimaliseerd is voor de iPad, met een back-end systeem. Het is een applicatie waarop je kan inloggen en relevante problemen van een project kan bekijken of toevoegen. Voorbeelden van relevante informatie over een project zijn: ● opmerkingen over een project ● geleerde lessen bij een project ● problemen in een project De applicatie moet ook goed beveiligd worden, omdat het bedrijfsgevoelige informatie kan bevatten. Bovendien moet het een goede User-Experience & Interaction-Experience – design hebben. Dit houdt in dat de applicatie zo ontworpen moet worden, zodat het een optimale gebruikers ervaring geeft.
2.8. Randvoorwaarden De applicatie heeft de volgende minimale eisen: ● Het moet werken op de iPad. ● De bedrijfsgegevens moeten goed beveiligd zijn. ● De applicatie moet een back-end systeem hebben, waarop data opgeslagen en opgevraagd kan worden.
45
2.9. Risicofactoren De eerste risicofactor is dat de doelstelling niet gerealiseerd kan worden binnen het tijdsbestek. De communicatie met de designer van Milvum die de wireframes1 maakt moet goed zijn, zodat de implementatie fase2 goed kan verlopen. Zolang het ontwerp niet goed wordt uitgevoerd, kan de implementatie fase ook niet tot een goede oplevering leiden.
1 2
Schetsen van hoe de applicatie eruit komt te zien. Fase waarin het daadwerkelijke construeren van het programma plaats vindt.
46
3 Aanpak 3.1. Inleiding Voor het bachelor project zijn er 10 weken ingepland. Het eindproduct voor ogen is, zoals in 2.7 is gezegd, een werkende mobiele applicatie geoptimaliseerd voor de iPad. De requirements worden opgezet door de product eigenaar en worden verder uitgewerkt m.b.v. benchmarking van reeds bestaande applicaties en het interviewen van managers. Aan de hand van de requirements volgt er een functioneel ontwerp Het functioneel ontwerp zal bestaan uit de volgende onderdelen: doel van de applicatie, doelgroep van de applicatie, de eisen aan de applicatie en het ontwerp. Door uitbundig feedback op het functioneel ontwerp te krijgen door de product eigenaar, de begeleider en potentiële eindgebruikers, is al snel bekend of de goede weg wordt genomen. Het vergaren van de feedback zal gebeuren door wekelijkse meetings met de product eigenaar en door het afleggen van interviews met enkele eindgebruikers. Ook zal er in deze fase een oriëntatie verslag gemaakt worden, hierin zal beschreven worden welke literatuur en tools er zullen worden gebruikt en welke kennis er moest worden opgedaan voor het project. In de tweede fase wordt er begonnen met het ontwikkelen van de applicatie, er zijn in totaal 6 weken de tijd hiervoor. Het belangrijkste hierbij is dat de deadlines van de Software Improvement Group (SIG) worden gehaald. Deze zal de code op drie onderdelen beoordelen: leesbaarheid(gegeven namen, grootte, complexiteit en documentatie), testbaarheid(unit tests voor de code) en modulariteit(afhankelijkheden tussen de verschillende modulen en interfaces). De laatste twee weken zijn gereserveerd om de laatste puntjes op de i te zetten voor het eindrapport en om de eindpresentatie voor te bereiden. Het eindrapport bestaat uit het functioneel ontwerp, het orientatie verslag, de bevindingen tijdens de implementatie van de applicatie, de beperkingen van de applicatie, de toekomstige mogelijkheden van de applicatie waar nog onderzoek kan worden gedaan en de eindconclusie.
3.2 Methodiek Er is voor het project een agile ontwikkelingsmethode gekozen, namelijk Agile Scrum. Dit is gedaan op aanraden van de opdrachtgever. Bij Agile Scrum wordt er aan het begin van de dag een scrum meeting gehouden door de scrum master. Deze stelt de volgende drie vragen volgens het Agile Scrum Model: 1. Wat heb je gisteren gedaan? 2. Wat ga je vandaag doen? 3. Zijn er ergens problemen ontstaan? De scrum zal bestaan uit 3 sprints van 2 weken voor de implementatie. Er wordt alleen tijdens de implementatie fase gebruik gemaakt van Agile Scrum. Een sprint is een tijd gelimiteerde inspanning waarin de belangrijkste features worden geimplementeerd. Er is gekozen voor een sprint van 2 weken, zodat er net genoeg werk kan worden geleverd door het team waarop feedback door de product owner kan worden gegeven. Rollen
47
Voor Agile Scrum zijn er verschillende rollen die vervuld moeten worden. Een daarvan is de product owner, deze zorgt ervoor dat het team het gevraagde probleem oplost. Ook bepaalt de product owner de prioriteiten. Bij dit project is Arvind Jagesser van Milvum de product owner. Een andere rol die vervuld moet worden is die van de scrum master. Deze begeleidt het team zodat het zijn doelstellingen behaald. De scrum master moet ervoor zorgen dat het scrumproces nageleefd wordt. Dit zal worden gedaan door Viresh Jagesser. De overige teamleden zijn Salim Hadri en Kaj Oudshoorn, zij hebben geen speciale scrum rol.
3.3 Technieken Om het project te ondersteunen wordt er gebruik gemaakt van een aantal hulpmiddelen: ● Subversion (SVN) een manier om code synchroon te houden. ● Google docs een manier om documentatie synchroon te houden. ● Een excel bestand in google docs wordt gebruikt om de uurbesteding en planning bij te houden in de vorm van een ticket systeem. ● Xcode de code editor voor het maken van iOS applicaties, zal worden gebruikt bij het implementeren van de applicatie. ● LateX een teksteditor, zal worden gebruikt voor het maken van het Oriëntatieverslag en het eindrapport (andere documentatie via google docs). ● scrumdo.com zal worden gebruikt voor het bijhouden van het scrumproces.
3.4 Werkzaamheden Tijdens het project zullen er een aantal werkzaamheden moeten worden verricht: ● Vooronderzoek voor missende kennis en rapportage hiervan. ● Requirements analyse ● Functioneel ontwerp ● Implementatie van de functionaliteit, het daadwerkelijk coderen. ● Testen van de functionaliteit, door unit testing en integratie testing. ● Eindrapport
48
3.5 Planning Startdatum
Einddatum
doorlooptijd
fase
taak
deliverables
22-04-2013
03-05-2013
2 weken
Oriëntatie fase
Vooronderzoek
Oriëntatieverslag
22-04-2013
29-04-2013
1 week
Oriëntatie fase
Requirements analyse
draft eindrapport
22-04-2013
29-04-2013
1 week
Oriëntatie fase
functioneel ontwerp
draft eindrapport
06-05-2013
14-06-2013
6 weken
Implementatie fase
Implementatie v/d functionaliteit
draft eindrapport
06-05-2013
14-06-2013
6 weken
Implementatie fase
testen v/d functionaliteit
draft eindrapport
17-06-2013
28-06-2013
2 weken
Afrondingsfase
Eindrapport
eindrapport
49
4 Projectinrichting 4.1 Inleiding In dit hoofdstuk worden een aantal algemene zaken besproken die betrekking hebben tot de inrichting van het project: wie de betrokkenen zijn, wat onze informatie bronnen zijn en over wat voor faciliteiten er beschikbaar zijn.
4.2 Betrokkenen Naast het project-team zijn er nog een paar andere mensen die betrokken zijn bij dit project: de designer (wordt nog gerekruteerd), Sam als begeleider vanuit de TU Delft en Arvind als opdrachtgever vanuit Milvum.
4.3 Informatie Als informatie bron zal met name de iOS documentatie van Apple zelf gebruikt worden en de kennis van de opdrachtgever. Verder is er het plan om mensen in een manager positie te interviewen om extra inzicht te krijgen in het probleem en mogelijke oplossingen. Overige nodige bronnen zullen later gezocht worden.
4.4 Faciliteiten Tijdens het project hebben kan er gebruik worden gemaakt van MacBooks, een licentie voor Xcode en iOS en een designer voor de uiteindelijke design. Voorlopig wordt de bibliotheek van TU Delft gebruikt als werkplek tot er een betere plek is gevonden.
50
5 Kwaliteitsborging 5.1 Inleiding Bij veel projecten staat kwaliteit hoog in het vaandel, ook bij dit project. De kwaliteit van het programma is natuurlijk belangrijk, maar ook van de rapportage ervan. In dit hoofdstuk wordt beschreven hoe deze kwaliteit wordt gewaarborgd.
5.2 De kwaliteit Goede, duidelijke structuur is belangrijk voor programmeren. Vanzelfsprekend doen wordt er moeite gedaan om dit aan te houden, maar hoe kan iemand zeker weten dat hij op de goede weg zitten? Hier komt SIG om de hoek kijken. Zij zullen halverwege het project de broncode doornemen en feedback geven op de structuur ervan. Hoewel dit maar eenmalig is, helpt het wel met bijsturen als het nodig is. Verder moet ervoor gezorgd worden dat er vertrouwen is dat de functies v/h programma naar behoren werken. Hiervoor zal uitgebreid unit testing (het testen van individuele functies) en integratie testing (het testen van functies als een geheel) worden toegepast. Wederom zal SIG dit beoordelen, ditmaal door te kijken naar de codedekking van de tests1. Algemene kwaliteit van het programma zal worden bepaalt m.b.v. pilots. Aan het eind van elk van de drie sprints is het de bedoeling om een werkende versie2 van het project te hebben. Deze pilot kan dan worden bekeken door de begeleider en de opdrachtgever voor feedback. De kwaliteit van de documentatie zal worden gewaarborgd door de begeleider en de opdrachtgever. Aan het eind van elke week wordt er een draft versie van de documentatie ingeleverd zodat die aan het begin van de week erop kan worden besproken.
5.3 Versiebeheer Zoals gezegd in 3.3 wordt er tijdens het project gebruik gemaakt van SVN. Er is afgesproken geen code te uploaden als het niet te compileren is. Op deze manier heeft iedereen toegang tot een code dat getest kan blijven worden (als een programma niet compileert door een fout in A, kan niet worden getest of B werkt). Bij grote fouten kunnen kan er m.b.v. SVN een stap terug worden genomen naar een oudere, werkende versie van het programma.
1
Het percentage van alle mogelijke invoer dat getest is. een versie waarbij alle geïmplementeerde functies naar behoren werken en terug te vinden zijn in het gebruik van het programma 2
51
Appendix E – Functioneel Ontwerp
Functioneel Ontwerp 1 Inleiding 1.1 Doelgroep van de applicatie 1. 2 Doelstelling van de applicatie 2 Eisen 2.1 Functionele eisen 2.2 Platform-eisen 2.3 Beveiligingseisen 3 Ontwerp 3.1 Ontwerp-richtlijnen Inlogscherm Groepen scherm Problemenlijst scherm Probleembeschrijving scherm 3.2 Wireframes 3.3 Design
52
1 Inleiding In dit rapport worden de functionele en niet functionele eisen van de applicatie vastgelegd. Ook komen wireframes en de uiteindelijke designs aan bod in dit rapport. Dit is erg belangrijk om voor het start van de implementatiefase bepaald te hebben. Zodat er later veel minder aanpassingen nodig zijn.
1.1 Doelgroep van de applicatie Het is belangrijk om goed te weten wat de doelgroep is van de applicatie. Zodra het bekend is wat de behoefte zijn van de doelgroep, kan de applicatie qua functionaliteit en design hierop worden aangepast. De doelgroep van de applicatie bestaat uit bedrijven die bestaan uit meerdere afdelingen/groepen.
1. 2 Doelstelling van de applicatie Het doel van de applicatie is om een overzicht te geven van alle problemen die zich voor doen binnen een groep mensen1 die samenwerken. Dit kan verschillen van een te kort aan middelen tot aan seksuele intimidatie. Door een goed overzicht kunnen problemen eerder worden aangepakt, waardoor er minder vertraging in het werk komt en er een betere werksfeer is.
1
een projectteam, een afdeling of iets dergelijks
53
2 Eisen Bij elk project zijn er eisen waaraan voldaan moet worden. De MoSCoW-methode zal worden gebruikt om een goed beeld te krijgen van de prioriteit van de functionele eisen voor dit project. Vervolgens zal er worden ingegaan op de platform-eisen, denk hierbij aan op welk systeem de applicatie moet kunnen draaien. Tot slot zullen de beveiligingseisen worden behandeld, dit zijn eisen die betrekking hebben tot de beveiliging van de data van de applicatie.
2.1 Functionele eisen De functionele eisen van een software project beschrijven wat het programma moet kunnen. Elk van deze eisen heeft een bepaalde prioriteit. Deze prioriteit wordt in dit hoofdstuk beschreven m.b.v. de MoSCoW-methode. Bij de MoSCoW methode wordt er uit gegaan van 4 verschillende prioriteiten: 1. Must haves: Dit zijn eisen die nodig zijn om tot een werkend product te komen (de kwaliteit is hierbij niet belangrijk). 2. Should haves: Dit zijn eisen die zeer gewenst zijn van het product (ze zijn een grote meerwaarde). 3. Could haves: Dit zijn eisen die alleen worden gewaarborgd als er tijd over is. Het is fijn om ze te hebben, maar zijn niet uitermate belangrijk 4. Won’t haves: Ook wel bekend als “Would like to haves”. Eisen die het programma niet zal hebben, maar die wel interessant kunnen zijn voor toekomstige projecten in verband met dit product (uitbreidingen). Must have ● Een centraal punt voor een relationele database die ook mogelijkheid geeft voor uitbreiding tot Android en Windows Phone. ● Authenticatie om gebruik te mogen maken van het programma. ● Een aanpasbaar overzicht van groepen (toevoegen, verwijderen). ● Mensen uitnodigen voor een groep/groepen. ● Problemen kunnen melden en als opgelost kunnen markeren. Should have ● Verschillende rechten per persoon (bekijken, uitnodigen, rechten geven, kicken). ● Prioriteren van problemen (risico waarde aangeven). ● Een probleem kunnen opeisen (aangeven dat iemand er mee bezig is). ● De mogelijkheid om een probleem anoniem te kunnen insturen. (zelfde idee als een anonieme tiplijn bij de politie) ● De mogelijkheid om als groepsleider anonieme problemen toe te staan of te verbieden. ● Categoriseren van problemen. ● Discussie of opmerkingen op een probleem geven ● Status van een probleem aangeven ● Archiveren van opgeloste problemen. ● Aangeven wat de oplossing is geweest voor een probleem. Could have
54
● Mogelijke toekomstige problemen kunnen aangeven. ● Aanleidingen van problemen aangeven. ● Notificatie van nieuwe problemen en aanpassingen aan problemen Won’t have ● Chat systeem ● Importeren van groepen/projecten uit project management systemen zoals basecamp
2.2 Platform-eisen In de eerste plaats is het de bedoeling dat de applicatie werkt op de iPad. Een werkende versie voor de iPhone wordt gewaardeerd, maar is geen must voor het project. Het besturingssysteem van de iPad is iOS. De applicatie moet compatibel zijn met de nieuwste versie van iOS (6.1) zodat het maximale uit het besturingssysteem kan worden gehaald. Updaten naar de nieuwste versie van iOS is gratis, dus het feit dat iOS 6.1 wordt gebruikt levert geen beperkingen op voor gebruikers.
2.3 Beveiligingseisen De applicatie zal gebruik maken van bedrijfsgegevens. Van dit soort gegevens is het niet de bedoeling dat ze voor iedereen toegankelijk zijn. Er zijn twee mogelijkheden waarbij de gegevens door onbevoegden te zien zijn: 1. Toegang tot de database krijgen buiten de applicatie om. 2. Onbevoegd gebruik van de applicatie. Om de veiligheid van de gegevens te waarborgen kunnen we de volgende eisen stellen: 1. Gegevens uit de database moeten onleesbaar/onbegrijpbaar zonder hulp van de applicatie. 2. Er moeten restricties zijn voor het gebruik maken van de database. 3. Er moeten restricties zijn voor het gebruik maken van de applicatie. De laatste twee eisen spreken voor zich. Het moet zo lastig mogelijk zijn om bij de gegevens te komen (het is onmogelijk om 100% te beveiligen). De eerste eis zorgt ervoor dat als er zich toch een geval voordoet dat de database bereikt wordt, de data die erop staat niet te begrijpen is.
55
3 Ontwerp Naast eisen over hoe het programma moet werken, is het ook belangrijk om voor ogen te hebben hoe het programma er uit moet komen te zien. Een goed ontwerp is belangrijk voor de gebruikers. Een programma kan qua functionaliteit nog zo goed werken, maar zonder gebruiksvriendelijkheid wordt een programma niet gebruikt. In dit hoofdstuk komen de ontwerprichtlijnen, de wireframes en de uiteindelijke designs van de applicatie aan bod.
3.1 Ontwerp-richtlijnen De applicatie zal bestaan uit 4 schermen. Voor gemak worden de 4 schermen als volgt benoemd: inlogscherm, groepenscherm, problemenlijstscherm en probleembeschrijvingscherm.
Inlogscherm Bij het inlogscherm moet er de mogelijkheid worden gegeven om een account aan te maken. De volgende gegevens zijn belangrijk bij het aanmaken van een account: naam, bedrijf, e-mail en wachtwoord (+verificatie van wachtwoord) van de gebruiker. Als je al een account hebt aangemaakt, dan kan je inloggen met behulp van je e-mail adres en wachtwoord.
Groepen scherm Bij dit scherm wordt er een overzicht gegeven van de groepen, waarvan de persoon lid van is of beheerd. Bovendien kan hier ook een nieuwe groep worden aangemaakt, waarbij elke lid aan een rol gekoppeld is. Enkele voorbeelden zijn manager, projectleider, medewerker ect.. Bij het uitnodigen van een persoon voldoet de naam van de persoon.
Problemenlijst scherm Bij het problemenlijst scherm (de inhoud van een groep) kan je alle problemen zien die horen bij een groep waar je op hebt geklikt. Je kan vervolgens elk probleem aangeven als opgelost/nietopgelost. Ook zie je de risico categorie en datum van invoering bij elke probleem. Als je klikt op een probleem dan ga je naar het probleembeschrijving scherm. Er moet ook een optie zijn om een overzicht van de leden te krijgen. Je moet hier ook een probleem kunnen toevoegen, bij het toevoegen moet een optie zijn om het anoniem te doen. Ook moeten er de opties worden gegeven om: mensen uit de groep te verwijderen, toe te voegen, rechten geven, beheer aan overplaatsen. Niet iedereen zal overigens toegang krijgen tot alle opties.
Probleembeschrijving scherm Bij dit scherm wordt een probleem gedetailleerd beschreven en zie je bij welk project dit probleem hoort. Zaken die staan beschreven zijn: Risico factor, omschrijving, oorzaak, mislukte pogingen om het probleem op te lossen. Is het opgelost? Zo ja, wie heeft het op gelost, hoe en wanneer.
56
Appendix F – Business Plan
Business Plan
Salim Hadri Viresh Jagesser Kaj Oudshoorn
57
Inhoud Inhoud Mission Unique Selling Point Market analysis Tracky Omniplan Basecamp Fogbugz User analysis Managers Teamleden Cost and Benefit Kosten Fasen Fase 1 Fase 2 Fase 3 Kostenplaatje Pricing mechanism Benefits Return of Investment (ROI) Break-even Risk and oppurtunities Strengths Weaknesses Opportunities Concurrentie richt zich vooral op software ontwikkeling. Threats Omgaan met Weaknesses en Threats
58
Mission Acelera heeft als doel om de maximale potentie uit teams te halen. Het is onze missie om een applicatie te ontwikkelen die bedrijven helpen bij het verbeteren van hun bedrijfsprocessen en knowledge sharing. We willen ons concentreren op procesmanagement en knowledge sharing, omdat dit een positief effect heeft op innovatie in bedrijven. Voor procesmanagement ligt de focus op het coördineren en aanpassen van een fase tussen het initiëren en afronden van een ontwikkeling. Hierbij speelt problem-solving een belangrijke rol.1 De impact op de capaciteit van de bedrijfsinnovatie heeft een sterk positieve associatie met werknemers van een bedrijf die bereid zijn om kennis te delen en te verzamelen.2 Dit zijn de redenen waarom Acelera zich richt op problem-solving en knowledge sharing. Veel bedrijven van profit tot non-profit bedrijven en van groot tot klein, hebben wel eens problemen die opgelost moeten worden. Dit kunnen problemen zijn die te maken hebben met een veranderende vraag op de markt, tot het optimaliseren van een langdurig proces in een bedrijf. De doelgroep van de Acelera is daarom erg breed, m.a.w. elk bedrijf die haar teamleden beter met elkaar wil laten samenwerken. We willen teamleden de mogelijkheid geven om snel en gemakkelijk problemen te melden en kunnen inzien. Op deze manier wordt er gebruik gemaakt van alle kennis die aanwezig is in de groep om een probleem op te lossen. Dit maakt het mogelijk om met innovatieve en creatieve oplossingen te komen. Acelera helpt dus bij de bekwaamheid om te komen op creatieve of innovatieve oplossingen en dit is belangrijk op momenten wanneer de vraag op de markt veranderd. Wie weet hoort u argumenten waar u zelf nooit op gekomen was. Werken in een team staat gelijk aan: elkaar respecteren, elkaar helpen en van elkaar leren. Onze motto is dan ook: Samen hebben we de mogelijkheid om het beste uit een ieder te halen.
Unique Selling Point Het is belangrijk om je te kunnen onderscheiden van concurrenten. Dit kan worden gedaan door unieke eigenschappen of functionaliteiten van een product of dienst, ook wel unique selling point genoemd. Acelera doet dit met de volgende unique selling points: Het offline kunnen inzien van problemen, de concurrentie is web gebaseerd er is dus een actieve internet connectie nodig.
1
Mary J. Benner , Michael I. Tushman (2003) Exploitation, Exploration and Process Mangament: The Productivity Dilemma Revisited. Acedemy of Management Review, Vol 28 (2), 238-256 2 Hsiu-Fen Lin, (2007) "Knowledge sharing and firm innovation capability: an empirical study", International Journal of Manpower, Vol. 28 Iss: 3/4, pp.315 - 332
59
Er kan heel snel een overzicht worden weergegeven van alle problemen van de groepen waar de gebruiker lid van is.
Market analysis Het concept knowledge-sharing en problem-solving in een bedrijf met behulp van een applicatie is uniek. Acelera stimuleert team leden en managers om kennis te delen om de problemen die zijn ontstaan op te lossen. Dit wordt gedaan door het bekend maken van problemen aan alle teamleden in een groep, waarop gereageerd kan worden. Met deze inkijk hebben we geen directe concurrentie. De concurrentie richt zich vooral op to-do lijsten en het maken van een planning. Het concept van knowledge sharing en problem-solving kan van toegevoegde waarde zijn en daarom zorgen voor een potentiële overname. Waarbij het op hypen van dit product en het trekken van veel gebruikers een grote rol zal spelen. Om de kans van Acelera op de markt te vergroten, zal er goed gekeken worden naar applicaties die elementen van dit concept bevatten, zoals werken in groepen en overzichten tonen. Met deze applicaties wordt benchmarken mogelijk. De applicaties die gebruikt zullen worden voor de analyse zijn: Asana1, Tracky2, Omniplan3, Basecamp4 en Fogbugz5.
Asana Asana is een web gebaseerde projectmanagement tool, het biedt native mobiele applicaties aan voor iOS & Android. Het is opgericht door 2 leidinggevenden bij Facebook die vonden dat de huidige technologie geen uitkomst bood om efficiënt in een teamverband te werken. Asana werd al gauw gebruikt door Facebook. De teams die ervan gebruik maakten kregen meer gedaan met minder moeite: er waren minder meetings en het volume van het aantal e-mails ging omlaag. Met Asana is het mogelijk om taken te verdelen over teamleden. Ook is het mogelijk om taken weer in subtaken onder te verdelen. Bij deze taken kunnen ook bijlages worden toegevoegd en is het mogelijk om commentaar toe te voegen bij een taak. Taken waarvoor een datum bekend zijn kunnen worden gekoppeld aan een datum. Er zijn twee versies van Asana die je kan gebruiken: de gratis en de premium versie. Bij de gratis versie kunnen er maximaal 15 gebruikers in een team zitten. Bij de premium versie zijn de kosten afhankelijk van de grootte van een team. Tot 15 teamleden kost Asana 50 euro per maand. Tot 30 gebruikers kost het 100 euro per maand. De hoogst aangegeven prijs is voor teams van 100 gebruikers: 800 euro per maand. Bij grotere teams wordt er gevraagd om persoonlijk contact op te nemen met Asana, maar er kan aangenomen worden dat het meer zal kosten dan 800 euro per maand.
1
https://app.asana.com https://tracky.com 3 http://www.omnigroup.com/products/omniplan/features/ 4 http://basecamp.com 5 http://www.fogcreek.com/fogbugz/ 2
60
Tracky Tracky biedt dezelfde mogelijkheden als Asana, het ziet er weliswaar iets grafischer uit. Dit maakt het wel wat minder zakelijker. Tracky biedt naast een web versie ook een applicatie voor de iPhone aan. Tracky kost 5 dollar per gebruiker per maand.
Omniplan Omniplan is niet web gebaseerd, maar biedt native applicaties aan voor de Mac en iPad. De gegevens worden via de server van Omnigroup gesynchroniseerd. Het biedt ook de mogelijkheid om taken direct in je agenda te zetten, dit kan ook via Google Agenda. Omniplan kost eenmalig 199 dollar, dit is een licentie die voor één enkele gebruiker geldig is.
Basecamp Basecamp is web gebaseerd en biedt naast dit ook een iPhone applicatie aan. Waarin deze applicatie echter verschilt van de andere applicaties, is dat de Application programming interface van Basecamp opensource is. Dit betekent dat andere softwareontwikkelaars extra functionaliteiten aan Basecamp kunnen toevoegen. Er zijn verschillende abonnementen, er wordt niet per gebruiker betaald, maar per project. Het goedkoopste abonnement begint bij 20 dollar per maand.
Fogbugz Fogbugz is een online issue & bug tracking, project management en customer support tool. Het is bedoeld om software projecten efficiënter te laten verlopen. De doelgroep van Fogbugz zijn bedrijven die software projecten hebben lopen. Fogbugz kost 25 dollar per gebruiker. Fogbugz biedt geen native mobiele applicaties aan. Het wordt gebruikt door grote en bekende bedrijven, zoals Apple, Intel, Microsoft en Sony.
61
User analysis De applicatie is gericht op 2 verschillende gebruikers: managers en teamleden. Het globale idee is namelijk dat teamleden verdeeld zijn over groepen en die de problemen die voorkomen binnen die groepen melden en oplossen, managers hebben zicht op meerdere groepen wat er voor zorgt dat ze weten wat er afspeelt en dit kunnen gebruiken voor toekomstige verbeteringen.
Managers De managers zijn de leidinggevenden van bedrijven/afdelingen/projecten. Het is onder andere hun taak om werknemers zo efficiënt mogelijk te laten werken en om de kwaliteit van het product te waarborgen. Dit kunnen ze bereiken door inzicht te krijgen over de problemen die binnen de werkproces. Het is soms lastig voor managers om problemen binnen meerdere groepen te detecteren. Acelera stimuleert team leden en managers om kennis te delen om de problemen die zijn ontstaan op te lossen. Daarom is de de doelgroep erg breed en niet zomaar te classificeren. Uit interviews is gebleken dat managers graag zo veel mogelijk kennis vergaren en opslaan. Hoe meer er gerapporteerd wordt, hoe beter. Omdat dit leid tot een beter begrip over het bedrijf en wat er verbeterd kan worden. Problemen rapporteren is hier geen uitzondering. Het is natuurlijk belangrijk om de problemen op te lossen, maar het archiveren ervan zodat er op een later moment nog van geleerd kan worden is ook erg belangrijk.
Teamleden De teamleden zijn degene die de taken/opdrachten binnen een bedrijf/afdeling/project verrichten. Het is hun verantwoordelijkheid om hun taken zo efficiënt mogelijk uit te voeren. Dit is te realiseren door problemen die ze tegenkomen te melden aan hun leidinggevenden. Teamleden zijn niet altijd gemotiveerd om alles op te schrijven en te rapporteren. Soms is het gewoon makkelijker om een telefoontje te plegen en het daarbij te laten, dan om een volledig rapport in te dienen en daarin om hulp te vragen. teamleden kiezen dus vaak voor de aanpak met het snelste resultaat (hoewel dat niet altijd de beste is). Het is dus aan Acelera om ervoor te zorgen dat het gebruik makkelijk is (invoer mag niet veel tijd kosten) en dat het snel resultaten oplevert (andere mensen die snel reageren).
62
Cost and Benefit Kosten Om de applicatie tot zijn recht te laten komen zijn er enkele kosten aan verbonden om het project te kunnen realiseren. Zo moet er servers en designers worden ingehuurd, moet er een website gelanceerd worden, Apple developer license moet aangeschaft worden, er moet een video gemaakt worden om de applicatie te marketen en moet er proof of credibility worden opgebouwd.
Fasen Er kunnen 3 verschillende fasen worden onderscheiden voor het project. In de eerste fase wordt er aan de applicatie, backend en middleware gewerkt voor de iPad. De tweede fase bestaat uit het marketen van de applicatie. De laatste fase is optioneel en kan worden uitgevoerd als de applicatie voldoende succes behaald.
Fase 1 In deze fase moet het design van Acelera nog verder worden uitgewerkt, er is naar schatting nog 20 uur nodig voor het volledig designen van de schermen en leveren van assets voor de iPad versie. Een freelance designer voor iOS kost al gauw rond de 50 euro per uur. De kosten voor het design zal dan ook neerkomen op 1000 euro. Verder is Acelera in de huidige versie nog in de Alfa versie. Om tot een final release te komen moeten er nog enkele werkzaamheden door programmeurs worden uitgevoerd. Naar schatting komt dit uit op 350 uur, programmeurs krijgen bruto 15 euro per uur. De kosten om dit verder te ontwikkelen bedragen 5250 euro. De database moet beveiligd worden door encryptie ook moet een ssl certificaat worden aangeschaft, zodat er een beveiligde connectie is van en naar de database en middleware. Een ssl certificaat kost 226,04 euro per jaar. Nu is de applicatie klaar om te worden toegevoegd aan de App store van Apple. Echter kost het toevoegen van de applicatie aan de App store. Om een applicatie aan de App store te kunnen toevoegen is er een licentie nodig die jaarlijks vernieuwd moet worden, deze kost 79 euro. Ook moet er server kosten worden betaald, op jaar basis komt dit neer op 2222,42 euro.
63
Fase 2 Een goede applicatie ontwikkelen is niet genoeg, het marketen van een goed product is ook belangrijk. Het aantal applicaties op iOS heeft namelijk een behoorlijke vlucht ondernomen. Er zijn drie goede manieren om een applicatie op te hypen. Door het hebben van een video waar wordt laten zien wat er met de applicatie gedaan kan worden en waarom dit anders is of beter dan wat er nu al te vinden is op iOS. Het maken van zo een video kost +/- 3000 euro. De tweede manier is door het adverteren in andere applicaties in iOS. Het budget van zo een campagne is zelf te bepalen. Echter wij zijn van mening dat deze op 3000 euro moet neerkomen. Zo kunnen er bij een CPM1 van 4 euro 750.000 gebruikers worden bereikt. De derde manier is het hebben van een website waar de applicatie gemarket wordt, dit wordt ook wel een landing page genoemd. Het laten maken van zo een website kost 3500 euro.
Fase 3 Als Acelera met de iPad versie voldoende succes behaald, en er een vraag is naar applicaties op andere platformen dan kan aan deze vraag ook worden voldaan. Er is een mogelijkheid om uit te breiden naar iPhone, Android, Windows Phone en Windows 8.
Kostenplaatje De volgende kosten worden per fase gemaakt. Er wordt een onderscheid gemaakt tussen eenmalige kosten en jaarlijks terugkerende kosten. Fase 1: Eenmalige kosten: 6250 euro Jaarlijkse kosten: 2527,46 euro Fase 2: Eenmalige kosten: 9500 euro Fase 3: Nog nader te bepalen.
Pricing mechanism Om van de volledige functies van de applicatie gebruik te mogen maken moet er eenmalig een bedrag worden betaald. Dit kan gedaan worden in iOS met In-app purchases2. De gebruiker heeft standaard de mogelijkheid tot het deelnemen in groepen, het creëren van problemen en commentaar geven op de problemen. Waar er echter voor betaald moet worden is het aantal groepen waaraan de gebruiker kan deelnemen. Er zullen 2 verschillende pakketten worden aan geboden. 1 2
Cost per impression, online advertentie kosten per 1000 bezichtigingen Dit is een manier om een aankoop binnen een app te doen.
2
64
Als eerst wordt het pakket worden besproken waar niet betaald voor hoeft te worden: De gebruiker kan aan maximaal 5 groepen deelnemen en kan maximaal een nieuwe groep creëren die een groepsgrootte van maximaal 5 kan hebben. Het tweede pakket kost 0.79 euro, de gebruiker kan maximaal 15 groepen creëren en deelnemen aan maximaal 25 groepen, er kunnen niet meer dan 20 mensen in een groep. Er is gekozen voor een prijs van 0.79 euro, dit zorgt voor een laagdrempelig gebruik van de app. Dit is ook de goedkoopst mogelijk in-app purchase die gemaakt kan worden op iOS. Als de gebruiker groepen wil hebben die meer gebruikers dan 20 kunnen bevatten, dan moet hier betaald voor worden. Dit is een in-app purchase van 0.79 euro, zo kan een groep 10 extra gebruikers bevatten.
Benefits Met behulp van het prijs mechanisme kunnen we de bruto benefits bepalen. Aangezien er per maand, per gebruiker gerekend wordt, betekent dit dat voor elk pakket i de winst per maand wi bepaald wordt door de prijs pi en het aantal gebruikers g (waarvan Apple 30% krijgt)i: wi = pi *gi *0.70 . Om de netto benefits te bepalen hebben we ook de vaste kosten nodig. Dit bestaat uit de Apple licentie, systeem onderhoud en server kosten. De server kosten s zijn afhankelijk van het totaal aantal gebruikers g. Als er meer gebruikers zijn, is er meer data verkeer en is er een grotere data opslag nodig wat resulteert in een duurdere server. Systeem onderhoud o is een bedrag per maand dat flexibel aangepast kan worden, hierbij is het wel belangrijk te weten dat systeem onderhoud belangrijk is voor het behouden van je gebruikers. Een verouderd systeem is namelijk een mooi doelwit voor hackers, waardoor de data in het systeem niet langer veilig is. Dit heeft dan weer als gevolg dat mensen het systeem liever niet gebruiken (mensen brengen geen geld naar een onveilige bank, op dezelfde manier brengen ze ook geen data naar een onveilige database). Als we de prijzen uit Pricing Mechanism meenemen komen we uiteindelijk op een formule voor de netto benefit b: b = 0.79 *g2 * 0.70-‐(s + o + 76 ). Merk op dat w1 niet in de formule staat. Vanwege de prijzen is dit toch gelijk aan niets.
Return of Investment (ROI) Zoals in kosten beschreven staat is er een investering nodig voordat het product werkelijk de markt op kan. Uiteindelijk is het de bedoeling dat deze investering geld op leverd. De relatieve hoeveelheid hiervan is te berekenen met de formule: ROI = (netto benefits / total cost) * 100. Als we uitgaan van een grote database zoals in kosten beschreven staat en geen onderhoud volgt hieruit dat er per jaar een ROI is van: ROI = ((0.79 *g2 *0.70 -‐2527,46) / 15750) * 100
65
Break-even ROI = ((0.79 *g2 *0.70-‐2527,46) / 15750) * 100 Het break-even punt wordt bereikt als de ROI gelijk aan 100 is. 100 = ((0.79 *g2 *0.70-‐2527,46 )/ 15750) * 100 g2 =(15750 + 2527.46) / 0.553 g2 = 33052 gebruikers
Dit betekent dat er minimaal 33052 betalende gebruikers moeten zijn. Dit in een jaar tijd, dat betekend dat er ongeveer per maand 2755 nieuwe gebruikers moeten komen die betalen. Dit is een heel laag aantal voor een platform zo groot als iOS1.
1
Volgens Apple zijn er sinds 12 september 2012, 400 miljoen apparaten verkocht die op iOS werken.
66
Risk and oppurtunities Om een beter beeld te krijgen van het product kan er een SWOT analyse worden toegepast. Hierbij wordt er gekeken naar de goede en de slechte punten van het product en de markt: ●
Strengths: eigenschappen van het product die voordelig zijn ten opzichte van de concurrentie.
●
Weaknesses: eigenschappen die nadelig zijn ten opzichte van de concurrentie.
●
Oppertunities: elementen die het product kan uitbuiten in de markt.
●
Threats: elementen binnen de markt die voor moeilijkheden kunnen zorgen voor het product.
Strengths ● ● ● ● ●
Werkt op mobiele apparaten (iPad). Overzicht van problemen op één plek. Schaalbaar naar meerdere groepen. Meer stress om een probleem op te lossen dan een taak. Meerdere projecten managen gaat makkelijker.
Weaknesses ● ●
Invoer is niet gebruiksvriendelijk, want het kan (voorlopig) alleen op een iPad. Het bedrijf dat het product maakt is nog relatief onbekend (geen ondersteuning van een grote naam).
Opportunities ● ● ●
Concurrentie richt zich vooral op software ontwikkeling. Concurrerende programma’s zijn rond een browser applicatie heen gebouwd en exploiteren mobiliteit niet. Gebruikers hebben de mogelijkheid om een applicatie te beoordelen. (kan leiden tot sneller grotere bekendheid).
Threats ●
Bedrijven zoals Asana / Tracky / Basecamp kunnen onze functionaliteiten overnemen in hun product, zoals Google+ heeft gedaan bij Facebook.
Omgaan met Weaknesses en Threats Om de impact van de weaknesses en de threats te verkleinen moet er een plan voor komen. Om de weaknesses te verzachten of te elimineren moet Acelera beschikbaar worden gemaakt op meerdere platformen d.m.v. een browsers applicatie of applicaities op Android/Windows 8 tablets. Door dit product op een zo goed mogelijke manier op te hypen zal het zelfstandig een naam bekendheid kunnen krijgen. Dit heeft direct te maken met de threat. Als iedereen weet dat
67
Acelera de eerste is met dit conecpt, dan zullen andere partijen worden gezien als namakers en er geen credit voor krijgen. Daarom is marketen van producten ontzettend belangrijk.
68
Use Case 1 - Bug Tracking & Reporting Pixar - Animatie Studio. Actie Een animator is bezig met het maken van een animatie en wil de geleverde geluiden erbij synchroniseren. Probleem Bij het synchroniseren blijkt het één van de geluiden niet klopt, terwijl zijn deadline al morgen is. De animator wilt graag een ander geluid hiervoor gebruiken. De animator is er ongeveer 10 uur mee bezig om een nieuw geluid te maken of aan te passen en wilt graag dat de audio afdeling dit afhandelt, want dan kost het maar 1 uur. Acelera/ Oplossing De animator pakt zijn iPad/ Webinterface en voert het probleem in, met een audio boodschap en deadline. De taak wordt gegeven aan de hoofdverantwoordelijke van de Audio Afdeling, omdat de animator niet precies weet wie dit kan oplossen Uitvoering van de Oplossing Het hoofd van de audio afdeling is niet op locatie en ziet dat er een probleem is gemeld met een redelijk hoog prioriteit. Het hoofd van de audio afdeling geeft dit probleem door aan een audio editor, die dit gelijk oplost. De issue wordt gezet op de naam van de creator (de animator) met een link naar de audiofile.
69
Use Case 2 Tower Climbers Actie Een toren reparateur klimt op een 500 meter hoge toren om een lampje te repareren. Probleem Onder het klimmen is de reparateur in de veronderstelling dat een aantal trap treden behoorlijk aan het slijten zijn. Zelf heeft hij er niet zo veel verstand van, dus hij kan niet zo snel beoordelen wat er aan zou moeten gebeuren. Een specialist laten komen om de schade op te meten is niet handig met zo’n lastige klim en kost veel tijd (en dus geld). Acelera / Oplossing De reparateur heeft gelukkig zijn smartphone bij en maakt een aantal foto’s. Vervolgens maakt hij een nieuw probleem aan en zet deze foto’s erbij. Uitvoering van de oplossing De baas/voorman van de reparateur krijgt vervolgens een berichtje van het nieuwe probleem en haalt er een specialist bij die de foto’s eens goed bekijkt. De treden blijken inderdaad wat verouderd te zijn, maar niet zo zeer dat ze aan vervanging toe zijn. Het probleem wordt als opgelost aangegeven voordat de reparateur weer beneden is. Het loze alarm heeft wel wat geld gekost, de hoeveelheid is beperkt gebleven.
70
Use Case 3 Voor af gaand een brainstorm sessie Actie Een bedrijf bestaat 5 jaar en ontwikkeld elk jaar nieuwe producten. Probleem De vraag op de markt is veranderd: de klanten verwachten meer voor hun geld en de concurrentie neemt toe. Er moet een nieuw innovatief product worden ontwikkeld. Acelera / Oplossing De CEO van het bedrijf maakt een probleem in Acelera, zodat het probleem bekent is bij alle medewerkers. Uitvoering van de oplossing Op deze manier kan samen aan een oplossing worden gewerkt en zijn brainstorm sessies effectiever. Door knowledge sharing en problem solving is het beter mogelijk om een innovatief of creatieve oplossing te vinden voor het probleem.
71
Appendix G – Wireframes versie 1 SCHERM 1
SCHERM 2
72
SCHERM 3
73
SCHERM 4
74
SCHERM 5
75
SCHERM 6
76
SCHERM 7
77
Appendix H – Wireframes versie 2 SCHERM 1
1. Log in Hier kun je inloggen wanneer je al een account hebt. De app navigeert naar scherm 3 2. Sign up Hier is het mogelijk om je aan te melden voor de app. De app navigeert naar scherm 2. Hier wordt gevraagd om uw persoonlijke gegevens.
78
SCHERM 2
3. Sign up scherm In dit scherm wordt de gebruiker gevraagd om persoonlijke informatie. Alle velden dienen ingevuld te worden om de sign up te voltooien. 4. Take a photo Door middel van deze knop, schakelt de app de native camera van het device aan. De gebruiker kan zo een foto van zichzelf maken, die vervolgens gebruikt wordt als avatar binnen het platform. 5. Sign up bevestiging Deze knop bevestigt de sign up, mits alle velden correct zijn ingevuld. Het account is aangemaakt.
79
SCHERM 3
6. Groups Met deze knop uit de hoofdnavigatie, wordt scherm 3 geladen, waar alle groepen waar de gebruiker affiniteit mee heeft worden weergegeven. Aan de knoppen uit de hoofdnavigatie is duidelijk te zien, waar de gebruiker zich bevindt binnen de app. 7. Problems Met deze knop uit de hoofdnavigatie, wordt scherm 8 geladen, waar alle problemen binnen het bedrijf in drie verschillende categorien worden weergegeven. Zie scherm 8 voor meer informatie. 8. Settings
80
Met deze knop uit de hoofdnavigatie, wordt scherm 11 geladen, waar de gebruiker bepaalde instellingen kan aanpassen. Zie scherm 11 voor meer informatie. 9. Group Hier wordt een groep met ondertitel weergegeven. Wanneer de gebruiker op de afbeelding drukt, wordt er nieuwe content zichtbaar, door middel van drop-down. Zie scherm 4. 10. New Group Met deze knop kan er een nieuwe groep worden toegevoegd door de gebruiker.
81
SCHERM 4
11. Group Problems Hier worden alle problemen van de gekozen groep weergegeven. De problemen zijn door middel van kleur geordend op mate van belang. 12. Group Members Hier worden alle collega’s weergegeven die ook tot de groep behoren. Wanneer de gebruiker op een van de collega’s avatars drukt, verschijnt de persoonlijke informatie en de avatar van de collega in een lightbox. Zie scherm 5. 13. Add New Problem Met deze knop kan er een nieuw probleem worden geformuleerd en worden toegewezen. Hier is nog geen scherm voor ontworpen.
82
SCHERM 5
14. Groups Member Profile In deze lightbox wordt de persoonlijk informatie van de collega weergegeven. De persoonlijke informatie bestaat uit naam, titel, emailadres, telefoonnummer en avatar. 15. Mail Groups Member Met deze knop kan er direct een mail gestuurd worden aan de desbetreffende groepsgenoot.
83
SCHERM 6
16. Problem Solved Om aan te geven dat een probleem opgelost is, moet de gebruiker over het probleem heen swipen. Er verschijnt een groene kleur. De gebruiker laat de balk weer los en het probleem wordt weergegeven als voltooid. In scherm 7 kan je zien hoe dit eruit ziet.
84
SCHERM 7
17. Problem Solved Als eerder besproken is het mogelijk om een probleem weer te geven als voltooid. Na annotatie 16, komt het probleem er als volgt uit te zien. Het probleem kan natuurlijk nog wel bekeken worden.
85
SCHERM 8
18. My Added Problems Hier wordt een lijst aan problemen weergegeven die de gebruiker specifiek volgd. Dit kan per probleem gedaan worden door middel van de knop op annotatie 23. 19. Responsible Problems Hier wordt een lijst aan problemen weergegeven waar de gebruiker voor verantwoordelijk is gesteld door groepsgenoten. 20. Other Group Problems Hier wordt een lijst aan problemen weergegeven die zowel niet door de gebruiker aangemaakt zijn, als dat de gebruiker hier specifiek voor verantwoordelijk is. Wel kan de gebruiker hierover meedenken en op reageren. Zie scherm 9.
86
SCHERM 9
21. Degree of Importance Hier wordt weergegeven wat de mate van belang is van het probleem. Dit net als eerder in de lijsten. 22. Responsible People Hier worden alle personen weergegeven die specifiek verantwoordelijk zijn voor dit probleem. Het is ook mogelijk om mensen hieraan toe te voegen. 23. Follow Problem Met deze knop kan de gebruiker het probleem toevoegen aan de lijst ‘My Added Problems’ lijst. 24. Textfield Hier kan de gebruiker een bericht typen als reactie op het probleem. 87
25. Post Message Met deze knop wordt het bericht verstuurd en zichbaar tussen de comment’s van het probleem. 26. Add Photo Met deze knop is het mogelijk om ook een foto toe te voegen aan het bericht.27. Comment Hier is een reactie zien op het probleem of op eerdere reacties. De naam, foto en datum van de schrijver worden ook weergegeven. 28. React Met deze knop kan de gebruiker reageren op eerder geplaatste reacties op het probleem.
88
SCHERM 10
29. Problem Solved Zoals eerder vermeld is het mogelijk om een probleem als opgelost weer te geven. Ook in deze weergave wordt dit er op een vergelijkbare manier laten zien.
89
SCHERM 11
30. Edit Personal Profile Hier is het mogelijk om persoonlijke informatie of gegevens aan te passen. In scherm 12 komt dit aan bod. 31. Edit Group Profiles Hier is het mogelijk als gebruiker en onderdeel van een groep, om de afbeelding en naam van de groep aan te passen. In scherm 13 komt dit aan bod. 32. E-mail Notifications Hier is het voor de gebruiker mogelijk om de E-mail Notifications aan of uit te zetten. 33. Push Messages
90
Hier is het voor de gebruiker mogelijk om de Push Messages aan of uit te zetten.
91
SCHERM 12
34. Edit Personal Info Hier is het mogelijk om persoonlijke informatie of gegevens aan te passen door op het pennetje binnen het veld te drukken. 35. Change Picture Hier is het mogelijk als gebruiker om een nieuwe foto te maken of een foto up te loaden.
92
SCHERM 13
34. List of Groups Hier is een lijst zichbaar waar alle groepen worden weergegeven worden waar de gebruiker onderdeel van is. 35. Edit Group Name Hier is het mogelijk om de titel van de groep aan te passen door op het pennetje te drukken. 36. Delete Group Hier is het mogelijk om een groep te verwijderen door op het icoon te drukken.
93
