Upload
truongxuyen
View
227
Download
2
Embed Size (px)
Citation preview
{EPITECH.}
EIP 2012
Cahier des Charges Meetopia
Team Meetopia
Meetopia – Cahier des charges
Page 2
Notre idée est basée sur l'observation de notre entourage. Par exemple, Facebook
permet une visualisation des photos et informations relatives à une liste d'amis. Cependant, nous avons pu remarquer qu’il manque un aspect essentiel aux réseaux
sociaux. Ce dernier, par sa définition est un ensemble d'entités reliées par des liens sociaux. Un lien capital est la proximité géographique. C'est le cœur de notre projet.
En effet, les réseaux sociaux sont complets, nombreux et la géo-localisation a déjà
été intégrée dans quelques uns, mais son utilisation en plus d’être complexe reste très limitée voire inexistante.
Nous avons donc réfléchi au moyen de créer une application qui permettrait de
regrouper un maximum d’informations filtrées et modelées en fonction d’une position, pour les proposer à l’utilisateur. Ainsi ce dernier se verra situé au cœur d’un monde personnalisé selon ses goûts, tant au niveau social qu’au niveau économique.
Notre avantage ici, sera d'utiliser la géo-localisation pour pouvoir proposer un grand
nombre de services, qui deviendront des services de proximité. Profitant du développement des Smartphones, de l’engouement pour la technologie GPS, plus le balbutiement de ce type d'applications passé, notre projet possède de grandes chances de créer un nouveau phénomène.
Aujourd’hui nous pouvons designer Meetopia comme un réseau social basé sur la
géolocalisation permettant aux utilisateurs d’interagir et de rester en contact avec leur
environnement.
[Tapez une citation prise dans le
document ou la synthèse d'un
passage intéressant. Vous pouvez
placer la zone de texte n'importe où
dans le document. Utilisez l'onglet
Outils de zone de texte pour
modifier la mise en forme de la zone
de texte de la citation.]
Résumé du document
Meetopia – Cahier des charges
Page 3
Groupe : Sébastien BADEAU Kevin CHHOY Sébastien DEVEZA Jean-Damien DUMAS Jonathan DURAND Edem GBIKPI Christopher RETHORE Guillaume RICHARD Bastien SOHIER
Nom du projet : Meetopia
Type de document : Cahier des charges
Version : 1.1 Référence : MEETOPIA-CDC-1.1
Statut du document : À valider
Diffusion
Personne Email Rôle
Sébastien BADEAU [email protected] Kevin CHHOY [email protected]
Sébastien DEVEZA [email protected]
Jean-Damien DUMAS [email protected] Chef de projet Jonathan DURAND [email protected]
Edem GBIKPI [email protected]
Christopher RETHORE [email protected] Guillaume RICHARD [email protected]
Bastien SOHIER [email protected]
Historique des révisions du document Version Date Nom Description
0.1 07/06/2010 Dumas Création du document
0.1.1 14/06/2010 Dumas Résumé du document 0.1.2 23/06/2010 Durand Résumé partie Android
0.1.3 01/07/2010 Badeau Résumé partie Web
0.1.4 04/07/2010 Durand Résumé partie IPhone
0.1.5 13/07/2010 Deveza Ajout vu pour Android 0.1.6 14/07/2010 Richard Ajout vu pour IPhone
0.2 15/07/2010 Chhoy Mis en forme du document
0.2.1 31/07/2010 Badeau Ajout vu pour site web 1.0 24/08/2010 Deveza Réinitialisation du document
1.0 25/08/2010 Deveza Répartition des rôles
1.1 17/12/2010 Dumas Ajout réalité augmentée, BDD, architecture et SCRUM
Informations sur le projet
Rédaction et modification
Meetopia – Cahier des charges
Page 4
Table des matières I. Nature du document ................................................................................................................... 5
1. Objectif du document.............................................................................................................. 5
2. Périmètre ................................................................................................................................ 5
a. Ce que comprend le document ............................................................................................ 5
b. Ce que ne comprend pas le document ................................................................................. 5
II. Introduction ................................................................................................................................ 6
1. Contexte ................................................................................................................................. 6
2. Historique ............................................................................................................................... 8
a. Réseau social ....................................................................................................................... 8
b. Géolocalisation .................................................................................................................... 8
3. Rappel sur l’EIP........................................................................................................................ 9
a. Objectif de l’EIP ................................................................................................................... 9
b. Sujet de l’EIP........................................................................................................................ 9
III. Description de la demande .................................................................................................... 10
1. Les objectifs .......................................................................................................................... 10
2. Produits du projet ................................................................................................................. 10
a. Description générale.......................................................................................................... 10
b. Liste des fonctionnalités .................................................................................................... 12
c. Réalité augmentée ............................................................................................................ 18
d. La Base de données ........................................................................................................... 20
e. Livrables ............................................................................................................................ 21
3. Critères d’acceptabilité et de réception ................................................................................. 21
IV. Contraintes et verrous techniques ......................................................................................... 22
1. Contraintes techniques ......................................................................................................... 22
a. Application Web ................................................................................................................ 22
b. Application Android ........................................................................................................... 23
c. Application IPhone ............................................................................................................ 25
2. Contraintes de couts ............................................................................................................. 26
3. Contraintes de délais ............................................................................................................. 26
V. Déroulement du projet.............................................................................................................. 27
1. Ressources ............................................................................................................................ 27
a. Définitions des rôles .......................................................................................................... 28
b. Répartition des rôles ......................................................................................................... 31
Meetopia – Cahier des charges
Page 5
2. Planification / SCRUM ........................................................................................................... 31
3. Suivi récurent ........................................................................................................................ 32
VI. Annexes ................................................................................................................................ 33
Etude préliminaire réalité augmentée ........................................................................................... 33
I. Nature du document
1. Objectif du document
Ce cahier des charges vise à définir exhaustivement les « spécification de base » de
notre projet Meetopia.
En interne ce document va servir à formaliser les besoins et a les expliquer aux
différents acteurs pour s’assurer que tout le monde est d’accord. En particulier ce cahier des
charges va permettre de cadrer les missions des différents membres du groupe, et
notamment celles du chef de projet.
En externe ce document va servir de référentiel entre le lab EIP et l’équipe interne. Il
est un outil fondamental de communication du chef de projet.
2. Périmètre
a. Ce que comprend le document
Outre les spécifications de base, ce cahier des charges décrit :
- Les enjeux sous-jacents
- Les objectifs généraux à atteindre, y compris la livrable principale
(site web) et les livrables secondaires (Applications IPhone et
Android)
- Les modalités d’exécution (notamment couts estimes a priori,
délai, jalons,…), sans toutefois imposer des solutions
- Les critères d’évaluation des livrables
- Les contraintes principales
b. Ce que ne comprend pas le document
Ce cahier des charges ne comprend pas les choses suivantes :
- Les descriptions de comment les solutions vont être implémentés
Meetopia – Cahier des charges
Page 6
- Une liste exhaustive des réseaux sociaux avec lequel Meetopia pourra
s’interfacer.
- La répartition atomique des taches par membre du groupe.
II. Introduction
1. Contexte
Selon une étude réalisée par l'ACERP (L'Autorité de Régulation des Communications Electroniques et des Postes), la France compte 61,5 millions d'abonnes a un operateur mobile (au dernier trimestre 2009). Ce qui représente un taux de pénétration de plus de 92%. Selon une autre étude réalisée par l'AFOM (Association Française des Operateurs Mobiles), les utilisateurs de Smartphones, qui constituent évidemment notre cible privilégiée, sont au nombre de 7,3 million, au 31 Mai 2010. On note d'ailleurs une augmentation constante du nombre de possesseurs Smartphone.
Aussi, on constate que les operateurs mobiles et constructeurs ont décidé d'augmenter considérablement le taux de pénétration des Smartphones dans le secteur de la téléphonie mobile en augmentant de manière sensible le nombre d'offre de Smartphones, tout en réduisant l’offre des autres familles de téléphones mobiles.
57,98
58,21
59,18
59,66
61,47
56 57 58 59 60 61 62
T4 2008
T1 2009
T2 2009
T3 2009
T4 2009
Evolution du nombre de clients aux services mobile en France (en millions)
Meetopia – Cahier des charges
Page 7
Cette étude récente sur la répartition des Smartphones par système d'exploitation et
constructeurs nous permet d'avoir une bonne vue d'ensemble de la structure actuelle du marche des Smartphones.
Comme on peut le constater, Android et Iphone ont une place prédominante sur le
marche des Smartphones, ce qui explique que notre choix ce soit porte sur ces deux systèmes d'exploitation pour la diffusion de notre client Meetopia. Mais pas seulement.
86,00%
87,00%
88,00%
89,00%
90,00%
91,00%
92,00%
93,00%
Taux de pénétration du mobile en France
55%19%
10%
9%
3% 4%
Demandes de Smartphone par Marque: US
iPhone
HTC
RIM
Motorola
Palm
Other
55%27%
10%
3%2% 1% 2%
Demandes de Smartphone par OS: US
iPhone OS
Android
RIM OS
Web OS
Windows Mobile OS
Palm OS
Other
Meetopia – Cahier des charges
Page 8
En effet, nous avons opte pour deux plateformes diamétralement opposées. D'un cote, nous avons Android qui est un système ouvert et donc open source, qui n'est a proprement parle qu'un système d'exploitation librement distribue aux constructeurs de Smartphones qui l'installent et le modifient selon les besoins et objectifs du téléphone.
A contrario, IPhone d’Apple, constitue un système ferme, contrôle par la firme, puisque IPhone désigne non seulement le système d’exploitation mais aussi le Smartphones lui-même. Apple assure la partie logicielle et matérielle du Smartphone.
A ces deux philosophies correspondent deux voies possibles dans l'évolution du marché futur des Smartphones. Du même coup ce choix nous permettra d'être présent sur les deux marches principales des Smartphones, à savoir Android et Iphone, mais aussi de rester présent si l'une des deux philosophies précédemment citées prend le pas sur l'autre.
2. Historique
a. Réseau social
En 1995, le premier site web de réseautage social voyait le jour sous le nom de
domaine Classmates.com. Un peu plus tard, en 1997, Company of Friends, le réseau en ligne
de Fast Company introduisait le réseautage d’affaire. D’autres sites ont emboités le pas,
incluant Sixdegrees.com (1997), Epinions (1999), suivi par les équivalents européens Ciao,
Dooyoo et ToLuna. Jusqu’alors présent sous la forme d’intranet c’est seulement en 2001 que
des sites web de réseautage social en ligne commencent à apparaitre. Ils commencent à
devenir de plus en plus populaire a partir de 2002, avec notamment l’avènement du site web
appelé Friendster, avant de connaitre un tel succès qu’en 2006, MySpace a obtenu un plus
haut taux de pages visitées que le moteur de recherche Google.
Aujourd’hui comment ne pas parler de Facebook qui selon la firme contait en 2009
plus de 500 millions de membres actifs a travers la planète dont 17,2 millions en France, ou
encore de Twitter qui contait en 2009 environ 11,5 millions de membres dans le monde et
125 000 en France.
b. Géolocalisation
La géolocalisation se fait sur PC d’après l’adresse IP, sur mobile d’après les
informations de l’operateur mobile et le GPS du téléphone.
A l’origine le GPS était un projet de recherche militaire. Il a été lance dans les années
1960 et c’est a partir de 1978 que les premiers satellites GPS sont envoyés dans l’espace.
Toutefois ce n’est qu’à partir de 1995 que le nombre de satellite disponible permet de
rendre le GPS opérationnel. En 2000, le président américain confirme l’intérêt de la
Meetopia – Cahier des charges
Page 9
technologie a des fins civiles. La technologie c’est tellement démocratisé que la majorité des
téléphones mobiles sont désormais équipes du GPS.
Partis de cette constatation Google crée en 2009 le service Google Latitude qui
permet de déterminer la position d’une personne par le biais de son téléphone portable.
Dodgeball acquis en 2005 par Google proposait d’ailleurs un service similaire via SMS.
3. Rappel sur l’EIP
a. Objectif de l’EIP
L’Epitech Innovative Project est l’étape la plus importante dans le cursus de l’école. C’est ce
qui fait passer un Epitechéen du statut d’étudiant à celui de professionnel. Elle se déroule de la
4eme a la 5eme année.
Le but de l’EIP est de choisir un projet qui soit original et innovant et de le réaliser par groupe
de minimums 5 dans un délai de 18 mois. Pour parvenir à leurs fins les étudiants devront apprendre a
se gérer et devront pratiquer de la gestion de groupe.
L’EIP a un double but pour les étudiants:
- Leurs permettre aux étudiants d’acquérir une expérience de gestion
intégrale de projet par la pratique.
- Les aidera constituer une carte de visite professionnel de haut niveau
b. Sujet de l’EIP
Le projet est né de l’engouement nouveau pour la géocalisation associé à l’ampleur
débordante des réseaux sociaux. Le but est de créer une application pour Smartphone avec un support sur internet mêlant les deux.
Avec Meetopia sur son téléphone, il sera donc possible de localiser ses amis et ainsi les voir apparaitre et se déplacer sur une carte, leur parler, leur fixer rendez vous. Avec l’application ouverte, en se déplaçant on verra apparaitre des pop in ciblées qui auront été sélectionnées selon les préférences de l’utilisateur, les magasins auront ainsi une vitrine, pourront proposer leurs nouveautés, des promotions, des événements…
Le projet se destine donc à la population active et aux détenteurs d’un Smartphone,
nous visons donc les 16/55ans soit un public très large.
Meetopia – Cahier des charges
Page 10
III. Description de la demande
1. Les objectifs
Ce cahier des charges a été réalisé en se basant sur une connaissance des
technologies et du besoin des utilisateurs.
Ce besoin a été défini par le biais de recherches sur des sites communautaires et une
observation des utilisateurs actuels de réseaux sociaux, tels que Facebook, Twitter,
Foursquare... Nous avons constate un engouement de plus en plus prononcé pour la
geolocalisation ainsi qu’un besoin de plus en plus exacerbé de rencontre de nouvelles
personnes.
Les objectifs sont donc simple, proposé un réseau social de dernière génération, ou
les utilisateurs seront non seulement capable de geolocaliser des personnes ou des lieux
mais aussi d’afficher leurs informations a partir de la réalité augmentée.
2. Produits du projet
a. Description générale
La solution que nous allons mettre en place se découpe en plusieurs parties.
La principale partie est un site web qui va être l’interface principale à destination des
utilisateurs finaux. Cette application fera de la résolution de localisation par adresse IP
(précision approximative). Elle fournira une API afin que des applications mobiles puissent
communiquer avec elle.
La seconde partie de notre projet est donc un service (Web) permettant de stocker
les informations utilisées. Il va servir de liaison entre le site web et les applications mobiles.
Enfin en troisième partie il y aura les applications mobiles qui implémenteront l’API
afin de pouvoir communique avec le site web. Ces applications feront de la résolution de
localisation par GPS (grande précision).
Meetopia – Cahier des charges
Page 11
Il a été longtemps discuté, comment nous allions faire communiquer nos modules de façon a
ce que toutes les plateformes, quelles que ce soient leurs OS et leur provenance (mobile ou
PC)
Par exemple lors d’une requête pour finaliser son inscription tout sera retransmis avec une
URL de type http://www.meetopia.fr/reg/, corrélant notre volonté de modularité.
Le webservice gérant l’inscription aura toute les données nécessaires envoyées par
formulaire sécurisé.
C’est par ce biais que les informations d’un formulaire ou d’une page en général seront
transmises aux webservices et que ces derniers pourront par la suite interagir avec la base
de données. En plus d’ajouter une dimension sécurité au projet cette méthode nous permet
d’automatiser et de sérialiser notre traitement des informations. Au fur et à mesure que des
webservices seront nécessaires, il suffira de les ajouter au module père et la connexion entre
le nouveau webservice et la plateforme de gestion des WS se fera d’elle-même.
Pour illustrer cette conception, nous avons choisi d’expliquer comment la communication se
déroule au sein du projet par un diagramme :
Meetopia – Cahier des charges
Page 12
De plus le projet peut-être découpé de la manière suivante :
b. Liste des fonctionnalités
Utilisateurs
Fonctionnalité Dev Test
L’utilisateur peut s’inscrire en rentrant son nom complet, son login, son mot de passe et confirmation, son email et enfin en acceptant les conditions.
L’utilisateur pourra s’authentifier en rentrant son login et son mot de passe. Il pourra cocher un champ « se souvenir de moi » afin de ne pas avoir à entrer ces informations une nouvelle fois.
L’utilisateur doit pouvoir modifier ses informations : nom, prénom, mot de passe, numéro de téléphone, adresse postale, photo, préférences.
L’utilisateur pourra partager, définir, masquer sa position ou encore se déconnecter
L’utilisateur pourra choisir qui peut voir sa position
Meetopia – Cahier des charges
Page 13
D’un point de vue concret et technique, en prenant par exemple la procédure d’authentification, le
diagramme de séquence suivant représente exactement la marche à suivre :
Contacts
Fonctionnalité Dev Test
L’utilisateur doit pouvoir ajouter des amis à sa liste
L’utilisateur doit pouvoir supprimer des amis de sa liste L’utilisateur doit pouvoir localiser ses amis sur une Google Map
L’utilisateur doit pouvoir communiquer avec une personne via un chat
L’utilisateur doit pouvoir refuser une conversation
L’utilisateur doit pouvoir voir les informations de ses amis L’utilisateur doit pouvoir voir les informations des personnes aux alentours à partir de la réalité augmentée
Meetopia – Cahier des charges
Page 14
Lieux
Fonctionnalité Dev Test
L’utilisateur doit pouvoir localiser des lieux sur une Google Map
L’utilisateur doit pouvoir recevoir des informations sur les restaurant, bars, lieux touristiques situes a proximité de lui de manière simple ou grâce a la réalité augmentée.
L’utilisateur doit pouvoir recevoir des promotions des magasins situés à proximités
Un diagramme de séquence peut également donner ici une vision plus concrète de la gestion de la
géolocalisation, quelle soit des utilisateurs ou des lieux :
Meetopia – Cahier des charges
Page 15
Exemple avec l’application Android (image non contractuel et sujet a fort changement)
1.1 Page de démarrage
Cette page apparaitra au
lancement de l’application. Elle
permettra de se connecter à
Meetopia en renseignant son
adresse e-mail et son mot de
passe.
On pourra cocher « Se souvenir de
moi » afin de ne pas avoir a
rentrer ces informations a chaque
démarrage de l’application.
Si l’on est pas inscrit on pourra
accéder a la page d’inscription en
appuyant sur le lien
« Nouveau ? Inscrivez-vous »
1.2 Page d’inscription
Cette page permettra de
s’inscrire sur Meetopia.
Il suffira d’entrer son nom
complet (pour permettre aux
utilisateurs de faire des
recherches par nom), un login, un
mot de passe (a confirmer), son
adresse e-mail et enfin il faudra
accepter les conditions
d’utilisations
Meetopia – Cahier des charges
Page 16
1.3 Index
Mon compte : permettra d’accéder à
toutes les informations relatives à
l’utilisateur. Ce dernier pourra y
renseigner ses musiques préférées, ses
films, ses livres, etc.
Mes amis : permettra d’accéder à sa liste
d’amis. On pourra y voir leurs
informations, les localiser (cf vue 4), leurs
parler (chat), ajouter un ami, le
supprimer, etc.
Mes lieux : permettra d’accéder à la liste
de ses lieux préférés. On pourra y ajouter
un nouveau lieu (cf vue 5), supprimer un
lieu, localiser les lieux, etc.
Se localiser : permettra d’afficher notre
emplacement sur une carte. On pourra
aussi y voir les amis situés à proximités.
Recherche : Permettra de rechercher une
personne. On pourra faire des recherches
avancées, notamment par tag (music,
film, livre, sport, etc).
Meetopia – Cahier des charges
Page 17
1.4 Géolocalisation des utilisateurs
Affichage sur une google map des
utilisateurs.
A partir de cette page on pourra
accéder aux informations d’un
utilisateur en appuyant sur son
avatar. Ainsi on pourra voir qui
sont ses amis voir ses lieux
préférés, etc.
1.5 Géolocalisation des lieux
Affichage sur une google map de
ses lieux préférés.
On pourra ajouter un nouveau
lieu en utilisant soit une photo
présente sur le téléphone, soit en
prenant une photo du lieu a
partir de l’appareil photo.
En appuyant sur la photo du lieu
on pourra accéder aux
commentaires qu’un utilisateur
aura joints à la photo.
Meetopia – Cahier des charges
Page 18
c. Réalité augmentée Un changement drastique cote application mobile, donc autant dire, une révolution pour
Meetopia a été opérée lorsque le concept de Réalité Augmentée a été mis sur le tapis et
intégré a l’idée même du projet. En effet, lors de l’implémentation de la géolocalisation par
Facebook, Twitter et tous les grands pontes des réseaux sociaux, nous a forcés à
reconsidérer notre offre et notre placement sur le marché du « geosocial networking » en
allant nous nicher dans l’innovation et en se rangeant sous la bannière de ce qu’on pourrait
appeler une « killer app ».
Dans sa conception et son intégration au sein de nos applications, il est sans doute question
d’encapsuler la librairie ou l’API, au cœur de la notre. Le but étant de fournir via Meetopia,
une interface novatrice faisant appel a la réalité augmentée, elle-même, intégrée a
l’ensemble des services proposes par l’application.
Un exemple d’API déjà étudiée, mais malheureusement écartée est Layar. Cette dernière
proposait exactement la panoplie RA escomptée, cependant, son encapsulation était
impossible. Nous pouvions inclure notre API dans la leur mais pas l’inverse.
Lors de l’intronisation de l’idée au sein même du projet, le problème le plus évident a été de
savoir s’il allait être possible de trouver une libraire libre capable de répondre à nos besoins
et qui plus est libre de droits et de frais financiers. Finalement nous avons une personne qui
s’est consacrée entièrement à la recherche d’API ou de librairie de réalité augmentée. A
l’heure actuelle, et après le 1er rapport de l’étude préliminaire, 6 APIs ont été retenues.
Cependant après analyse, il se pourrait qu’une seule réponde parfaitement à nos exigences ;
son nom est Total Immersion. Notez bien tout de même que ce choix n’est pas validé.
Le module de réalité augmentée, toujours a l’état de concept, après avoir été sujet à
plusieurs rapports préliminaires a tout de même été étudié depuis un point de vue
technique. Cependant il n’y a toujours de nom d’API sur ce module. L’étude technique a
donc été basée sur l’API de Qualcomm qui apparaissait comme la plus adaptée (malgré sa
licence payante) a notre projet et a ses besoins.
Meetopia – Cahier des charges
Page 19
Le fonctionnement de l’API de réalité augmentée peut donc être représenté par ce diagramme :
Meetopia – Cahier des charges
Page 20
d. La Base de données La base de données est un point crucial, et surtout dans un projet comme le notre, qui est un
réseau social regroupant de nombreuses informations personnelles et en plus des
coordonnées GPS d’un grand nombre d’utilisateurs. Notre souci de conception premier a été
de penser la base de données de façon évolutive. C'est-à-dire, comme je l’ai déjà expliqué,
notre projet va se voir par la suite dote de plusieurs modules complémentaires pas
forcement anticipés aujourd’hui. Il nous fallait donc prévoir une manière d’intégrer de
futurs tables et champs. Le principe des metadatas intervient ici. Cela nous permettra
d’ajouter aisément de nouvelles informations sans pour autant remettre l’intégrité entière
de la base en question.
Dans l’optique de notre nouvelle méthode de travail SCRUM, et plus particul ièrement de
notre point de commit baptisé Opération Ninja, la base de données possède l’organisation
suivante :
Meetopia – Cahier des charges
Page 21
e. Livrables
Notre projet comprend deux livrables complètements fonctionnels. Ces derniers
comprendront le site web ainsi qu’une application IPhone et une application Android.
Le premier livrable, la version « alpha », sera livrée fin juin 2011. Elle présentera des
fonctionnalités limitées. Seules les fonctionnalités de l’utilisateur seront opérationnelles.
Le second livrable, la version « beta », sera livré fin mai 2012. Elle devra intégrer la
totalité des fonctionnalités listées dans ce cahier des charges.
3. Critères d’acceptabilité et de réception
Bugs
Les livrables devront bien évidemment être exempte de bug majeur mais ne devront
surtout pas présenter de fuite de ressource. Si une application mobile fait tomber le system
d’exploitation, il est bien évident que l’utilisateur s’en séparera.
Ergonomie
La facilite de téléchargement d'applications depuis les plateformes de téléchargement
respectives de chaque support – Apple Store et Android Market – rend l'utilisateur
relativement versatile. De ce fait, la première impression de l'utilisateur envers notre
application est absolument cruciale et déterminante. Des lors, certaines règles s'imposent.
Premièrement, le temps de prise en main de l'application devra être instantané. Il n'est
absolument pas pertinent de demander a l'utilisateur un effort cognitif, car cela l'amènerait
en cas de frustration vis a vis d'une interface mal pensée, a la suppression pure et simple de
l'application de son Smartphone.
Deuxièmement, l'interface devra être simple et efficace. Ainsi, chaque opération
demandée par l'utilisateur devra être réalisée avec le moins d'interactions possibles, limitant
des lors le risque d'erreurs.
Troisièmement, les composants de l'interface devront être conçus selon des principes
permettant de s'assurer du caractère immédiatement évocateur du composant
Meetopia – Cahier des charges
Page 22
IV. Contraintes et verrous techniques
1. Contraintes techniques
a. Application Web
Physique
L'offre d'hébergement mutualisée d'OVH "business" fournis 250 Go d'espace disque
ainsi que 2To de trafic par mois sur un serveur fonctionnant sous Linux. Un nom de domaine
est inclus avec la gestion de multi-domaines, sous domaines et alias de domaines, il est aussi
possible de créer jusqu'à 1000 comptes utilisateur ftp afin de pouvoir définir des répertoires
différents suivant les utilisateurs par exemple. En ce qui concerne les e-mails, un serveur
smtp ainsi qu'un client mail avec interface web sont fournis avec la possibilité de gérer de
multiples comptes e-mail disposant de 2Go de stockage chacun et d'une protection antispam
et antivirus. Le serveur autorise l'envoi de mails automatiques pour les actions particulières
au site (par exemple une inscription d'utilisateur) et peut gérer jusqu'a 100 mailing lists.
Quatre bases de données SQL sont fournies : 3 bases de 100 Mo et une de 1 To. Ces quatre
bases disposent toutes d'un maximum de 10 connexions simultanées. Les connexions SSL
sont possibles via un certificat SSL mutualisé. Les données du serveur sont sauvegardées
quotidiennement et 6 sauvegardes sont constamment disponibles en cas de problème.
Plusieurs outils sont mis à disposition : une interface de gestion, un système de statistiques
détaillées, un gestionnaire de version (SVN) ainsi qu'un planificateur de tâches.
Technologie de développement
Pour l’environnement de développement, nous utiliseront Symfony en mode
Doctrine qui est un Framework de développement PHP puissant et stable, il permet un
développement de formulaire rapide en ce basant sur la base de donnée. Avec sa myriade
de plugin facile à installer, cela en fait l’outil parfait pour notre application.
Récapitulatif de l’environnement (versions pouvant evoluer)
Système d’exploitation Windows Seven 32 Bits
Serveur HTTP Apache 2.2.11
Serveur SQL MySQL 5.1.36
Version PHP 5.3.0
Framework Symfony 1.4
ORM Doctrine 1.2
Library annexe JQuery 1.4.4
Web services
Les web services seront bases sur basés un échange de requêtes http 1.1 et de
contenu XML, ce qui permettra au serveur de traiter les requêtes rapidement et de ne pas
souffrir de ralentissement.
Meetopia – Cahier des charges
Page 23
b. Application Android
Android est un système d'exploitation fondé sur un noyau Linux. Disponible via une
licence Apache version 2, le système d'exploitation inclut tous les utilitaires requis par un
constructeur ou par un opérateur pour mettre en œuvre un téléphone portable. Android a
été conçu pour intégrer au mieux des applications existantes de Google comme le service de
courrier Gmail, Google Agenda, Google Talk, YouTube ou encore celui de la cartographie,
Google Maps. Un accent particulier est mis sur la géo localisation. Ce système d’exploitation
nous offre donc tous les outils nécessaires à la réalisation de notre projet en nous offrant des
APIs souple et facile d’utilisation.
Plateforme de développement
Le développement de la solution Android de notre client s'appuiera sur
l'environnement de développement intègre Eclipse. En effet, Android propose une extension
Eclipse stable permettant d'utiliser l'Android Development Tools (0.9.7), et d'accéder ainsi a
l'Android Software Development Kit. Nous utiliserons l'Android SDK r06, qui est la dernière
version du SDK disponible.
GNU/Linux sera le système d'exploitation utilise pour faire fonctionner Eclipse (dont
la version préconisée sera éclipse JEE-Galileo-SR2 64 bits). Enfin, la version du Java
Development Kit utilisée sera la 6.0.
Récapitulatif de l’environnement (sujet a modification)
Système d’exploitation GNU/Linux Ubuntu 10.04 LTS
IDE Eclipse JEE Galileo SR2 64bits
Java Development Kit JDK 6.0
Android Development Tools 0.9.7
Android Software Development Kit R06
Plateforme de tests
Afin de réaliser nos tests unitaires, nous nous appuierons sur un Framework de tests
reconnu et largement diffuse dans l'univers Java ME, JUnit. En sus, nous utiliserons
EasyMocking afin de simuler certains objets inaccessibles et/ou non implémentés au
moment des premières phases de développement.
Plateforme logique
La plupart de nos tests seront testes depuis la plateforme logique de tests fournie par
Android Development Tools. Celle-ci contient un émulateur de terminaux – base sur Qemu –
Meetopia – Cahier des charges
Page 24
qui permet de simuler le comportement de differents types de mobiles, dans des situations
particulières d'utilisation. Il fournit en plus une suite d'utilitaire pour tester le
fonctionnement en internet de l'application, comme un debugger. En outre, la plateforme
logique simule des objets systèmes d'Android couramment utilises, grâce a des objets mock,
librement manipulables.
Plateforme physique
Du fait qu'il existe de sensibles différences entre le comportement de la plateforme
logique et de la plateforme physique dans certaines conditions, nous ne pourrons nous
contenter d'effectuer nos tests unitaires et de production sur la plateforme logique
proposée par Google. Ainsi, nous aurons à notre disposition un Android HTC Legend
disposant du dernier firmware en date (actuellement 2.2), et d'un LG GW620 disposant du
firmware le plus répandu au moment des tests (actuellement 1.5/1.6), afin de s'assurer de la
compatibilité avec des firmware plus anciens, mais toujours utilises.
Publication
Pour pouvoir être installée sur un terminal Android, la solution doit être signée et
donc accompagnée d'une clé permettant de l'identifier et de certifier de son intégrité.
Il y aura deux types de publication. Premièrement une publication interne – debug
mode – qui permettra de tester la solution Android sur la plateforme physique a l'aide de clé
requise pour le debug mode. Ensuite, viendra la publication externe, c'est à dire la livraison
publique de la solution, sur l'Android Market, avec une release mode associée.
0,10%
38,00%
31,60%
0,30%
2,70%
27,30%
Répartition des Versions d'Android sur le marché
Android 1.1
Android 1.5
Android 1.6
Android 2.0
Android 2.0.1
Android 2.1
Meetopia – Cahier des charges
Page 25
c. Application IPhone
Au vu de la proportion d’Iphone parmi les Smartphones, il est indispensable de
réaliser une application sur ce support afin de permettre de toucher une plus grande part
d’utilisateurs potentiels. Malgré les contraintes techniques imposées par Apple, nous allons
donc mobiliser plusieurs développeurs sur la prise en main et la réalisation d’une application
en Objective C via le SDK fourni gratuitement par Apple. Cette application devra permettre le
même degré de fonctionnalité que les applications développées sur les plateformes plus
ouvertes (web et Java) sur les modèles d’Iphone les plus répandus, a savoir l’Iphone 3G, 3GS
ainsi que le récent Iphone 4G.
Plateforme de développement
Le développement de la solution Iphone de notre client utilisera l'environnement de
développement intègre Code, dans sa dernière version (actuellement 3.2.2). Ce dernier sera
exécute depuis une machine virtuelle faisant tourner le système d'exploitation Mac OSX
10.6.3. La version du Iphone SDK utilise sera la version 3.1.3 et 4.0, correspondant
respectivement au développement sur Iphone 3G/GS et 4G. Ne disposant pas d’Iphone, nous
testerons en premier lieu notre application sur l’Iphone simulator fourni avec le SDK.
Récapitulatif de l’environnement (sujet a modifications) Système d’exploitation Mac OSX 10.6.3
IDE Xcode 3.2.2
IPhone SDK SDK 3.1.3/4.0
Plateforme de tests
Afin de réaliser nos tests unitaires, nous nous appuierons sur un Framework de tests
reconnu et largement diffuse dans l'univers Java ME, Jaunit. En sus, nous utiliserons
EasyMocking afin de simuler certains objets inaccessibles et/ou non implémentes au
moment des premières phases de développement.
Plateforme logique
La plupart de nos tests se feront depuis la plateforme de tests logique qui est
représentée par le simulateur de terminal fourni par le SDK et qui peut être exécute depuis
Meetopia – Cahier des charges
Page 26
Xcode. Aussi, nous nous appuierons sur OCUnit afin de réaliser nos tests unitaires. Ce
Framework de tests est propose nativement par Xcode. Nous utiliserons aussi OCMock afin
de pouvoir tester de manière isolée certaines parties de l'application.
Plateforme physique
Il existe des différences de comportements entre le simulateur et le terminal
physique, notamment car la gestion de la mémoire est moins permissive pour ce dernier. En
conséquence, nous mettrons en place une plateforme physique de tests permettant de
vérifier le comportement de l'application en conditions réelles. Pour ce faire nous auront à
notre disposition deux terminaux Iphone 3G. L'un disposant du firmware 3.1.3 et l'autre du
firmware 2.2.1.
Publication
Tout comme pour Android, il existera deux modes de publication de notre application
Iphone. Premièrement une publication interne, qui consistera à obtenir le certificat de
développement auprès d'Apple, afin de pouvoir déployer notre application sur nos terminaux de
tests et ainsi vérifier le bon fonctionnement de notre application en conditions réelles d'utilisation.
Puis, dans un deuxième temps, nous procéderons a la publication externe, consistant a la mise en
ligne de notre application depuis l'Apple Store. Celle-ci sera distribuée de manière gratuite et
librement téléchargeable.
2. Contraintes de couts
Pour notre site web nous comptons utiliser l’offre d'hébergement mutualisée d'OVH
"business" qui coute 11.95euros par mois.
L’application IPhone devra pouvoir être rendue disponible sur l’AP Store afin que les
utilisateurs puissent l’utiliser, ce qui impliquera l’obtention d’une License développeur (99$
USD pour la License standard et 299$ USD pour la License entreprise). Nous devrons bien
évidemment à terme tester sur un Iphone, c’est pourquoi il faudra en considérer l’achat.
3. Contraintes de délais
A la fin du mois de septembre 2011 nous livrerons une première version de
notre projet (site web, application IPhone et Android) qui présentera des
fonctionnalités réduites.
Meetopia – Cahier des charges
Page 27
A la fin du mois de mai 2012 nous présenterons une version dite « Beta » de
Meetopia qui sera exempte de bugs majeurs. L’application IPhone sera disponible sur
l’Apple store et l’application Android sur l‘Android Market.
V. Déroulement du projet
1. Ressources
Le projet sera réalisé par 9 personnes :
- Sébastien BADEAU
- Kevin CHHOY
- Sébastien DEVEZA
- Jean-Damien DUMAS
- Jonathan DURAND
- Edem GBIKPI
- Christopher RETHORE
- Guillaume RICHARD
- Bastien SOHIER
Afin d’utiliser au mieux les ressources humaines dont nous disposons nous avons
décidé de faire une hiérarchisation a 3 niveaux. Ceci permet à chaque membre du groupe de
savoir à qui se référer en cas de problème. Pour que chacun sache précisément ce qu’il doit
ou ne doit pas faire nous avons définis les rôles de ces 3 niveaux.
Meetopia – Cahier des charges
Page 28
a. Définitions des rôles
Chef de Projet
Mission:
Le chef de projet conduit le développement d'un logiciel dans les meilleures
conditions de coûts, de délais et de qualité. De la conception à la réalisation d'un prototype, il est le garant du respect du cahier des charges, des méthodes et des normes de développement.
Activités:
Il réalise la définition du cahier des charges et l'étude des solutions techniques
adaptées. Il élabore le dossier de démarrage du projet (spécifications, programmes de tests...) et établit le planning de réalisation.
Il coordonne l'activité de conception et de réalisation des ingénieurs et des techniciens de son équipe. Il s'assure de la bonne application des méthodes de développement, du respect des étapes de contrôle.
Il est le garant du respect des délais, informe et explique les décalages éventuels aux responsables concernés. Il coordonne la réalisation des dossiers de développement et participe à leur transmission aux autres services techniques (intégration, validation, production).
Connaissances spécifiques:
Il peut être le spécialiste d'une technologie particulière. Il pratique de la gestion de
projet et des méthodes de développement.
Qualités majeures:
Le chef de projet doit faire preuve de capacités d'organisation et de planification, et
de sens de la gestion. Son rôle de garant du respect des délais et des coûts, et ses relations avec différents interlocuteurs, lui demandent de bonnes capacités relationnelles. Il doit savoir animer une équipe, en s'assurant de la qualité de la collaboration entre les différentes personnes.
Limites:
Le chef de projet est responsable d’une équipe. A ce titre il dirige plusieurs
personnes. Toutefois cela ne lui donne pas les droits de déléguer sa propre charge de travail
(gestion de projet, planification, élaboration des dossiers). Il parle pour le groupe au nom du
groupe, de ce fait pour toutes décisions importantes (tickets, inscription a une soutenance,
etc.) il devra préalablement consulter son équipe. Dans le cas ou le chef de projet ne donne
pas entière satisfaction a son équipe il pourra faire l’objet d’une rétrogradation.
Meetopia – Cahier des charges
Page 29
Responsable technique
Mission:
En relation directe avec le chef de projet, il est chargé de superviser l'ensemble de
l'activité technique d'un pôle particulier du projet.
Activités:
Il participe à la définition du cahier des charges et à l'étude des solutions techniques
adaptées (pour son pôle). Il aide a l’élaboration du dossier de démarrage du projet (spécifications, programmes de tests...) et a la planification de la réalisation.
Il s’occupe de la conception (design). À partir d’un cahier des charges, le développeur doit définir les spécifications techniques du programme : structure des données, communication entre les modules...
Il intervient ponctuellement sur le plan technique, pour aider les développeurs à résoudre les problèmes qu'ils rencontrent.
Connaissances spécifiques:
Il est le spécialiste d'une technologie particulière. Il pratique de la gestion de projet
et des méthodes de développement.
Qualités majeures:
Le responsable technique servant de passerelle entre les développeurs et le chef de
projet, il doit a la fois avoir de bonnes capacités d’organisation et de planification, et d’excellentes capacités dans la technologie de son pôle.
Limites:
Le responsable technique étant expert dans sa technologie, en cas de problème
rencontré par un de ses développeurs, il a le devoir de le résoudre. Tout comme le chef de
projet il n’a pas le droit de déléguer sa charge de gestion de projet et de planification a l’un
de ses développeurs. Il parle au chef de projet au nom de son pole a se titre pour toutes
décisions importantes il devra préalablement consulter son équipe. Dans le cas ou le
responsable technique ne donne pas entière satisfactions que ce soit pour le chef de projet
ou pour les développeurs il pourra faire l’objet d’une rétrogradation.
Meetopia – Cahier des charges
Page 30
Développeur
Mission:
Un développeur est un informaticien qui réalise du logiciel en créant des algorithmes
et en les mettant en œuvre dans un langage de programmation.
Activités:
Il participe à la définition du cahier des charges et à l'étude des solutions techniques
adaptées (pour son pôle). Il s’occupe de développer ce qui a été conçu par son responsable technique. Il s’occupe des tests, qui servent à détecter les non-conformités et les erreurs (bugs). Enfin il s’occupe de la maintenance, c'est-à-dire la correction des erreurs après la
sortie du logiciel, ainsi que l’amélioration et l'évolution du produit.
Connaissances spécifiques:
Un développeur est avant tout un expert des langages informatiques. Il doit donc
maîtriser un ou plusieurs langages ainsi que les concepts attenants (par exemple, le concept d'héritage pour un langage orienté objet).
La connaissance du secteur d'activité dans lequel va être utilisé le logiciel est un atout. Elle permet de mieux saisir les attentes des clients et leur approche du problème.
D'une manière générale, le développeur doit aussi maîtriser l'environnement d'exécution de son programme, que ce soit un système d'exploitation pour un logiciel PC ou un microcontrôleur pour un logiciel embarqué. C'est cet environnement qui impose des contraintes au logiciel (taille mémoire disponible, vitesse de calcul).
Qualités majeures:
Rigueur, sens de la méthode, qualités relationnelles, rapidité d'exécution et facilité
de s'adapter à de nouveaux langages sont autant de qualités demandées. Il faut également faire preuve d'autonomie.
Limites:
Fait ce que lui demande son responsable.
Meetopia – Cahier des charges
Page 31
b. Répartition des rôles
2. Planification / SCRUM Nous avons déterminé et ordonnancé les taches du projet, ainsi que nous avons estimé leurs
charges et déterminé les profils nécessaires à leurs réalisations. Ce planning prévisionnel se trouve
sous la forme d’un diagramme de Gantt et sera présent en annexe.
Cependant cette ancienne méthodologie n’ayant pas fonctionnée, et nous avons accumule beaucoup
de retard. Par la suite et depuis peu, un tournant a été pris, et le chef de projet a décidé de faire
passer le projet sous Agile, et plus précisément en cycles SCRUM.
Meetopia – Cahier des charges
Page 32
Basiquement, nous avons une pile de fonctionnalités à développer, appelée Features Backlog. Les
features placées dans la pile sont choisies à chaque début de cycle et doivent être finies pour le point
de commit.
Par exemple notre premier et prochain point de commit est nommé :
Point de commit
Date Fonctionnalités
Opération Ninja
31/01/2011 - Enregistrement - Authentification - Gestion de la liste d’amis - Localisation de soi même - Géolocalisation de ses amis
Tous les jours les pôles se réunissent entre eux pour voir l’avancement des taches et la réattribution
de ces dernières si besoin.
Tous les lundis les chefs de pole rendent un rapport écrit au chef de projet, sur l’avancement de
leurs teams respectives.
Parallèlement tous les mercredis 2 vidéo conférences plus complètes sont organisées, avec a 16h une
réunion du pole web et 19h du pole mobile. Le chef de projet assiste en observateur à ces 2
réunions.
De plus tous les mois une réunion mensuelle est organisée avec pour but de débriefer les actions du
mois, de fixer les objectifs a long terme et de réunir toute l’équipe du projet.
3. Suivi récurent
Afin de faire des suivis récurrents nous avons dut nous organiser en fonction du décalage horaire. En
effet dans le cadre de la 4eme année a l’étranger badeau_s et rethor_c seront au Canada, dumas_j,
richar_g et sohier_b seront en Suède, deveza_s et durand_a seront en Californie, chhoy_k sera a
Pekin, enfin gbikpi_e sera a Paris. Si nous considérons Paris comme notre référentiel (heure 0), cela
nous donne comme décalage horaire les valeurs suivantes :
- Pékin : +6h
- Suède : +0h
- Rimouski (Canada) : -6h
- Californie : -9h
Partant de cette constatation nous nous somme convenus que l’heure la plus raisonnable pour faire
ces réunions est 17h (Paris). Ce qui est équivalent a 8h en Californie, 11h a Rimouski, et 23h a Pékin.
Meetopia – Cahier des charges
Page 33
Les réunions auront donc lieu tous les premiers Samedi du mois. Ci-dessous les dites dates :
- samedi 4 septembre 2010 17h (paris).
- samedi 2 octobre 2010 17h (paris).
- samedi 6 novembre 2010 17h (paris).
- samedi 4 décembre 2010 17h (paris).
- samedi 8 janvier 2011 17h (paris). décalé d'une semaine parce
que le premier samedi du mois est le 1er janvier
- samedi 5 février 2011 17h (paris).
- samedi 5 mars 2011 17h (paris).
- samedi 2 avril 2011 17h (paris).
- samedi 7 mai 2011 17h (paris).
- samedi 4 juin 2011 17h (paris).
- samedi 2 juillet 2011 17h (paris).
- samedi 6 aout 2011 17h (paris).
Ces réunions ou tous les membres du groupe seront présents, permettront au chef de projet de
savoir ou chaque pole du projet en est dans son avancement. Il lui permettra ainsi de savoir si les
objectifs fixés lors de la dernière réunion sont remplis. Si les objectifs sont remplis le chef de projet
en donnera de nouveau à remplir pour la prochaine réunion. En cas d’échec le chef de projet devra
identifier le problème et le résoudre (la résolution de ce problème peut passer par la rétrogradation
d’un responsable technique incompétent).
VI. Annexes
Etude préliminaire réalité augmentée
Introduction :
La réalité augmentée consiste en la superposition d’un model virtuel en 3D ou 2D a la
perception que nous avons naturellement de la réalité et ceci en temps réel. La technologie insère
des images de synthèse sur les images du monde réel grâce notamment à l appareil photo d’un
téléphone portable.
La réalité augmentée désigne donc les différentes méthodes qui permettent d’incruster des
éléments fictifs dans une séquence d’images. Ses applications sont multiples et touchent de plus en
plus de domaines : jeux vidéo, chasse au trésor virtuelles, cinéma et télévision, etc. En l’occurrence la
réalité augmentée aura une part prépondérante dans notre projet Meetopia puisqu’elle va servir
pour afficher en temps réel la position de ses amis, des ses lieux préfèrés ainsi que les informations
les concernant.
Meetopia – Cahier des charges
Page 34
Toutefois il est important de noter que superposer une information sur une image prise par
la caméra d’un Smartphone n’est pas a la portée de tout le monde. A moins que l’on dispose d’un
SDK (Software Development Kit) ou de librairies de fonctions faciles a utiliser et qui se chargent de
toute la complexité.
Cette étude a donc pour but de recenser ses différents SDK, lister leurs avantages et leurs
inconvénients afin d’en choisir un (ou plusieurs si un par plateforme) qui soit le plus utile pour notre
projet. Nous allons donc regarder les produits des principaux éditeurs à savoir :
- Alcatel-Lucent
- SimpleGeo
- Tonchidot (Sekai Camera)
- Layar (SPRXmobile)
- Qualcomm
- Total Immersion
1) Qualcomm (QCAR)
https://ar.qualcomm.com/qdevnet/sdk
Lors du sommet Uplinq 2010 à San Diego, Qualcomm a levé le voile sur une plateforme et un kit de
développement afin de déployer des applications de réalité augmentée sur les Smartphones Android.
Il est distribue gratuitement et comprend un dispositif de reconnaissance des images.
A cette occasion Qualcomm à même lance un concours international auprès de sa communauté de
développeurs avec 200 000 dollars qui seront partages entre les créateurs des meilleurs applications.
Principales Caractéristiques :
a) SDK
Plateforme Package Dernière mise à jour
Windows qcar-sdk-0.9.7.exe 2010/11/10
Mac qcar-sdk-0.9.7.zip 2010/11/10
Linux qcar-sdk-0.9.7.bin 2010/11/10
Meetopia – Cahier des charges
Page 35
b) Appareils supportés
Marque Modèle OS
Google Nexus One Android 2.1 update 1, Android 2.2
HTC Desire Android 2.1 update 1, Android 2.2
HTC Incredible Android 2.1 update 1, Android 2.2
HTC EVO 4G Android 2.1 update 1, Android 2.2
HTC G2 (T-Mobile) / Desire Z Android 2.2
Autres systèmes Snapdragon
N/A Android 2.1 update 1, Android 2.2
Défaults :
o Pas portable sur iPhone
2) Total Immersion (D’Fusion Mobile)
http://www.t-immersion.com/en,mobility,35.html
Fort d’une cinquantaine de nouveaux projets annoncés chaque mois, Total Immersion est
certainement le numéro un du secteur de la réalité augmentée. L’éditeur basé dans l’ouest parisien,
a ouvert en 2010 sa technologie D’Fusion a l’environnement mobile (Symbian, Android, Apple iOS et
Windows Mobile).
Principales Caractéristiques : o Marche sur Android 2.X et iPhone 4.X
o Le contenue peut être encrypté pour prévenir les piratages. o Complètement empaqueté dans des fichiers mobiles standards. o Moins de reconnaissance de marqueur pour les supports 2D déjà existant.
o Reconnaissance faciale
o Service basé sur la localisation disponible
o Supporte l’accéléromètre. Defaults :
o Besoin de devenir « partenaire » pour beneficier du SDK. o Payant?
3) Alcatel-Lucent (Dekaps)
http://www.dekaps.com/solution.html
Alcatel-Lucent a fait le choix d’incuber une jeune pousse issue de l’ESCP. Dekaps s’appuie sur des
briques technologiques maison afin de concevoir des applications et services de réalité augmentée.
Meetopia – Cahier des charges
Page 36
Pour ce faire Dekaps utilise à la fois la géolocalisation, la reconnaissance d’image ainsi que les
données scannées issue d’un code barre.
Principales Caractéristiques : o Vente de licences de SDK, 3 différents :
SDK reconnaissance d’image
SDK réalité augmentée relocalisée. SDK codes 2D/Datamatrix
o Reconnaissance d’image
o Réalité augmentée géo-localisée
o Codes 2D/Datamatrix
o Service d’alerte SMS/MMS
Defaults : o Payant
o Peu de marge de manœuvre
4) SimpleGeo
http://simplegeo.com/docs/
Le discours commercial de SimpleGeo fait mouche : il suffit de 6 lignes de codes (on parlera donc plus
de librairie que de SDK), pour qu’une entreprise soit en mesure d’intégrer un service de localisation
sur des applications tournant sur Apple iOS4 et Android.
Principales Caractéristiques :
o Portable Android Iphone.
o API REST.
o Spécialisé dans la géo-localisation.
o Facile d’utilisation
o Gratuit
Defaults :
o Pas de réalité augmentée.
5) Metaio
http://www.metaio.com/products/mobile/
L’éditeur allemand Metaio propose lui aussi son SDK mobile baptise Unifeye Viewer depuis quelques
mois. La plateforme se différencie de ses concurrentes par sa capacité à fonctionner à l’intérieur,
grâce a une nouvelle technologie, baptisée LLA Marker. En s’affranchissant du GPS, Metaio est
Meetopia – Cahier des charges
Page 37
capable de fournir des services de réalité augmentée dans des salons, centre commerciaux ou bien
même des gares souterraines.
Principales Caractéristiques :
o Marche sur Android, Iphone, Symbian OS et WinMobile
o Reconnaissance d’image
o Optimisation pour les mobiles
o Version d’évaluation gratuite
Defaults :
o Version d’évaluation limitée:
Seul les contenues 3D préconfiguré peuvent être utilisées
Seul 3 objets peuvent être chargés en même temps.
Il y a un logo affiché.
o Pas de géo-localisation.
6) Layar
http://www.layar.com/
Le hollandais Layar a développé un navigateur de réalité augmentée qui permet aux concepteurs
d'applications sur iPhone ou Android d'intégrer des informations virtuelles en 3D sous forme de
calques qui viennent se superposer au monde réel tel que vu depuis la caméra d'un Smartphone.
Layar est un jeu de mots entre "layer" et "AR". "Layer" signifie "calque" et Layar est un navigateur
pour afficher des "calques" de réalité augmentée, en fait des ensemble de POIs (points d'intérêt =
coordonnées GPS + informations).
Les calques sont développés par des développeurs indépendants. Il y a une grande diversité, qui va
de l'étudiant qui fait un calque pour la gloire sur son temps libre à l'entreprise spécialisée dans la
réalisation et l'hébergement de calques.
Principales Caractéristiques :
o Gratuit
o Portable Android, Iphone
o Affiche les points d’intérêts (lieu, personnes,…)
Meetopia – Cahier des charges
Page 38
Defaults :
o Difficultés d’encapsulation
Références
http://fr.wikipedia.org/wiki/R%C3%A9alit%C3%A9_augment%C3%A9e
http://www.ebusiness.info/article.php3?id=12492&rub=TEC&search=&page=
https://ar.qualcomm.com/qdevnet/sdk
http://www.clubic.com/smartphone/android/actualite-350492-qualcomm-sdk-realite-augmentee-android.html
http://www.t-immersion.com/en,mobility,35.html
http://www.dekaps.com/solution.html
http://simplegeo.com/docs/
http://www.metaio.com/products/mobile/
http://www.layar.com/
http://forum.frandroid.com/topic/4372-layar-en-france/