Cahier des Charges - Intranet...

{EPITECH.}

EIP 2012

Cahier des Charges Meetopia

Team Meetopia

Meetopia – Cahier des charges

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


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


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


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


- 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)


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


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


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.


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).


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 :

http://www.meetopia.fr/reg/


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


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


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


Lieux


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 :


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


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).


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.


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.


Le fonctionnement de l’API de réalité augmentée peut donc être représenté par ce diagramme :


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 :


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


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.


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 –


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


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


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.


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.


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.


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.


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.


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.


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.


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.


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.


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.


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



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.




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.


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




capable de fournir des services de réalité augmentée dans des salons, centre commerciaux ou bien

même des gares souterraines.


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.


o Gratuit

o Portable Android, Iphone

o Affiche les points d’intérêts (lieu, personnes,…)



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=


http://www.clubic.com/smartphone/android/actualite-350492-qualcomm-sdk-realite-augmentee-android.html






http://forum.frandroid.com/topic/4372-layar-en-france/

http://fr.wikipedia.org/wiki/Réalité_augmentée

http://www.ebusiness.info/article.php3?id=12492&rub=TEC&search=&page=









http://forum.frandroid.com/topic/4372-layar-en-france/

Cahier des Charges - Intranet...

Documents

Transcript of Cahier des Charges - Intranet...