Research and Development 1/2010-11/project/AppCetera/Project Initiation Document

Opdrachtgevers: Erik Barendsen en Sjaak Smetsers

Project: R&D 2011

Auteur: AppCetera

Versie: 1.0

Datum: 18 maart 2011

Projectdefinitie

Het product dat wij aan het einde van dit project willen afleveren, is een product dat gebruikt kan worden bij de werving van nieuwe studenten. Het product moet een positief beeld opleveren van de Informatica- en Informatiekundeopleidingen bij:

• de aankomend student
• personen die invloed hebben op de keuze van de aankomend student (ouders, vrienden, decanen)

De eis van dit project is dat het bovenstaande doel behaald wordt door middel van een maken van een Android applicatie. Om dit doel te bereiken hebben wij ervoor gekozen een applicatie te maken die gebruik gaat maken van de kenmerkende functionaliteiten van een moderne smartphone, GPS plaatsbepaling en een continue dataverbinding.

Tijdens dit project werken wij toe naar een applicatie voor realtime collaborative mapping. Zo'n applicatie maakt het mogelijk om kaarten met verschillende overlays en Points of Interest (POI) in realtime te bekijken en te bewerken binnen een groep gebruikers. Elke gebruiker binnen een groep maakt hierbij gebruik van een client - een Android smartphone - waarop de informatie uitgelezen en bewerkt kan worden. Deze informatie wordt vervolgens gesynchroniseerd met een centrale server die vervolgens de informatie naar andere clients stuurt.

Aangezien deze applicatie ontwikkeld moet worden voor een smartphone moet deze applicatie voldoen aan de volgende voorwaarden

• geschikt voor gebruik op een relatief klein beeldscherm
• geschikt voor touch gebruik
• gebruikt weinig resources (beperkte hoeveelheid geheugen, levensduur batterij)
• geschikt voor gebruik op relatief trage datanetwerken

Om te voldoen aan de laatste twee voorwaarden zijn wij van plan om gebruik te maken van zoveel mogelijk standaard functionaliteiten. Daarnaast zullen we kiezen voor een protocol dat een zo klein mogelijke hoeveelheid informatie verstuurt naar de server.

Omdat bij deze applicatie een centrale server nodig is, zal deze ook tijdens het project moeten worden ontwikkeld. Daarnaast hebben we kaarten nodig om onze data op te projecteren. Voor deze kaarten zullen we gebruik maken van de Google Maps API.

Projectaanpak

Wij hebben ons project als volgt opgedeeld.

Daarbij hoort de volgende planning.

Projectteam

Ons team bestaat hij twee programmeurs en één product ontwikkelaar. Hoewel elk lid eindverantwoordelijke is voor verschillende onderdelen van het project, zal er nauw samengewerkt worden, ook binnen deze onderdelen. Dit komt omdat deze verschillende onderdelen erg afhankelijk van elkaar zijn.

Joost Rijneveld (programmeur)

Joost is de eindverantwoordelijke voor mapping opties in de client. Denk hierbij aan het tekenen van polygonen, POIs en metadata van deze objecten. Daarnaast is hij verantwoordelijk voor de kwaliteitscontrole.

Mathijs Vos (programmeur)

Matthijs is de eindverantwoordelijke voor de client implementatie. Alle communicatie tussen de server en de client valt hieronder. Ook zal hij verantwoordelijk zijn voor het implementeren van de GUI (menu's en dergelijke).

Joël Cox (product ontwikkelaar)

Joël zal verantwoordelijk zijn voor de algemene documentatie van het project, de GUI van de applicatie, het opstellen van requirements en use-cases. Daarnaast zal het ontwerp en implementatie van het communicatie protocol in zijn handen liggen.

Kwaliteitsplan

Om de kwaliteit van ons eindproduct te kunnen waarborgen zullen wij het product testen op de volgende punten.

Gebruiksvriendelijkheid

De applicatie moet zonder enige training efficiënt te gebruiken zijn. Om dit te bewerkstelligen moet de interface zo ontworpen zijn, dat een gebruiker met een minimaal aantal handelingen, de meest voorkomende actie(s) kan uitvoeren. In ons product zal dat het tekenen van een polygoon zijn. Volgens het huidige ontwerp moet dit in twee stappen gedaan kunnen worden.

1. Het initialiseren van het menu
2. Het selecteren van de "Polygoon tekenen" optie.

Hierna moet de gebruiker een polygoon kunnen tekenen.

Bruikbaarheid

De applicatie moet altijd gebruikt kunnen worden zonder dat de gebruiker het gevoel heeft dat deze aan het wachten is. Bijvoorbeeld tijdens het synchroniseren van data met de centrale server. Dit systeem zal "non blocking" moeten zijn, zodat de gebruiker tijdens het synchroniseren normaal door kan werken. Wanneer dit niet mogelijk is - bijvoorbeeld tijdens de eerste synchronisatie - zal deze wachttijd niet langer dan 2 seconden mogen zijn. Aangezien een goede dataverbinding niet gegarandeerd kan worden, is deze kwaliteitseis moeilijk te bewaken. Wij proberen deze eis te bewaken door:

• De informatie die gesynchroniseerd moeten worden te beperken
• De applicatie en het protocol zo te ontwerpen dat er meerdere malen kleine stukjes data verwerkt kunnen worden, in plaats van te wachten op één groot stuk informatie

Kwaliteitsbewaking

Deze twee hoofdeisen moeten tijdens het project bewaakt en getest worden. Deze eisen worden tijdens de afronding van elke subproject getest. De gebruiksvriendelijkheid is vooral van belang voor subprojecten 1.1 tot en met 1.3, terwijl 1.4 en geheel subproject 2 onderhevig zal zijn aan de bruikbaarheid. Eigenlijk staat of valt de mate van bruikbaarheid (snelheid) bij een goed ontwikkeld protocol.

Risicomanagement

Omdat onze projectgroep geen monetaire vergoeding krijgt, zijn de consequenties gegeven in een percentage. Één procent staat gelijk aan 1% van ons uiteindelijke cijfer.

Categorie	Risico	Consequentie	Kans	Risicowaarde
Bruikbaarheid	Omdat onze applicatie erg leunt op een goede verbinding met de server is het van groot belang dat informatie snel wordt verwerkt.	15%	0.4	6%
Gebruiksvriendelijkheid	En gaan grote hoeveelheden informatie om in onze applicatie, maar deze informatie moet altijd goed inzichtbaar zijn.	30%	0.2	15%
Team	Wanneer er een van onze teamleden (langdurig) wegvalt door ziekte zal al het werk op twee personen komen te liggen en zal het aanzienlijk moeilijker worden om de gestelde deadline of functionaliteit te halen.	70%	0.05	3.5%

Indien blijkt dat er nog tijd over is na het implementeren van de eerder genoemde functionaliteiten, willen wij ons richten op de volgende functionaliteiten:

• Registratie en inloggen vanuit de app.
• Groepsmanagement (verschillende groepen met elk zijn eigen overlay)

Communicatie

Elke maandag stellen wij - voornamelijk Joël - een memo op voor onze opdrachtgevers. Hiernaast zullen er verschillende werkbesprekingen plaats vinden en twee presentaties, waarin we de voortgang met onze opdrachtgevers delen.

De onderlinge communicatie zal vooral via email verlopen en korte besprekingen. De hoeveelheid besprekingen is afhankelijk van de problemen die wij tijdens het project tegen komen. Binnen onze code repository hebben wij een issue tracker waarin verschillende problemen gecommuniceerd kunnen worden.