Cahier interne

Cahier interne

^{Projet innovant 4TC - iSecours©}

Système d’assistance à l’interventiond’urgence





Groupe 2

Nicolas Abbal

Romain Favrelle

Léo Geoffroy

Noureddine Laklii

Arnaud Petit

Romain Urbe
Romain Favrelle

Umbrella Corp.

[Sélectionnez la date]

Informations sur le document

Nom du projet	iSecours^©©
Date de rendu du document	08/04/2010
Titre	Cahier interne
Type	Document
Version	1
Responsable projet	Romain Favrelle
Responsable Projet Innovant	Stéphane Frenot
Tuteur technique	Frédérique Laforest
Tuteur humanités	Irène Colin
Mots clefs	secours, iPhone, assistance, géolocalisation,android, smartphone

Historique

Version	Date	Etat
0	15/03/2010	Création du document
0.1	20/03/2010	Implémentation de l’analyse fonctionnelle externe
0.2	25/03/2010	Implémentation de l’analyse fonctionnelle interne
0.3	29/03/2010	Rédaction planning 2^nde phase
0.4	01/04/2010	Implémentation budget 2^nde phase
1	03/04/2010	Fusion de l’analyse fonctionnelle et du planning 2nde phase, mise en page

Sommaire

Informations sur le document 2

Historique 2

Analyse fonctionnelle détaillée 4

I) Application mobile 4

1) Analyse fonctionnelle externe 4

2) Analyse fonctionnelle interne 8

II) Applications de monitoring 11

1) Analyse fonctionnelle externe 11

2) Analyse fonctionnelle interne 13

Planning de la 2nde partie 17

I) Lotissement du projet 17

1) Application mobile 17

2) Applications de monitoring 18

3) Communication 19

II) Déroulement de la seconde partie 20

1) Application mobile 20

2) Applications de monitoring 20

3) Communication 20

III) Budget nécessaire a l’élaboration du prototype 22

Liste des tables 23

Liste des figures 23

Annexes 24

Diagramme de GANTT 24

ISecours^© est une solution technologique permettant de faciliter l’intervention des secours lors d’un accident. En complément de l’appel classique aux urgences, notre produit permet d’établir une connexion de donnée entre le téléphone mobile du témoin et le poste informatique de l’opérateur. Cette connexion peut ainsi créer une nouvelle interactivité témoin/opérateur, rendant l’échange de donnée possible. ISecours^© ne cherche pas à remplacer la conversation téléphonique, mais à améliorer celle-ci en vue d’offrir un nouveau moyen de communication entre témoins et opérateurs des urgences.

L’opérateur pourra ainsi obtenir des éléments d’information essentiels sur l’accident, tel que sa localisation GPS ou une photo de la scène, transmises par l’application mobile iSecours^© installée sur le téléphone du témoin.

Dans le cas où l’opérateur juge bon de demander au témoin d’effectuer des actions sur les lieux de l’accident (sécurisation des victimes, gestes de premiers secours), il sera capable de transmettre des supports textuels ou visuels susceptibles d’aider le témoin dans ces opérations.

Analyse fonctionnelle détaillée

Notre solution iSecours^© est divisée en deux sous-systèmes distincts : d’une part, l’application présente sur le téléphone cellulaire du témoin et d’autre part, le système de gestion présent chez les urgences.
Nous avons décidé d’effectuer pour ces sous-ensembles deux analyses fonctionnelles différentes, puisqu’ils ne répondent pas aux mêmes besoins. En effet, l’application mobile est destinée à des utilisateurs provenant du grand public alors que le système de gestion devra répondre à des critères provenant des urgences.

La plupart des critères que nous avons établis sont basés sur les avis des utilisateurs de l’application mobile et opérateur. Ces données sont fictives et permettent d’approximer la qualité finale du produit selon le critère. L’avis utilisateur est modélisé sous forme d’une note de 0 à 5, où 5 correspond à une qualité excellente.

I) Application mobile

1) Analyse fonctionnelle externe

Fp1 « Donner des informations aux urgences sur l’accident »

L’application mobile doit être capable de transmettre des informations aux urgences. La première partie des données seront envoyées par le témoin à partir d’une fonctionnalité d’appel fournie par l’application. D’autres informations, comme la localisation de l’accident, seront transmises de manière transparente en utilisant la connexion 3G. Certaines données pourront être obtenues sur demande de l’opérateur, telles que la photo de la scène de l’accident.

Poids	Critère	Niveau	Flexibilité
5

Table : Détail de la Fp1 de l’application mobile

Fp2 « Assister le témoin dans ses actions  »

L’application mobile servira également de support au témoin lorsque l’opérateur jugera bon que celui-ci intervienne sur l’accident. Sur commande de l’opérateur, elle sera capable d’afficher des procédures textuelles ou des vidéos explicatives.

Poids	Critère	Niveau	Flexibilité
4	Qualité de l’information	4/5	20%

Table : Détail de la Fp2 de l’application mobile

Fc1 « Etre interopérable avec l’OS du téléphone mobile »

L’application est destinée à être portée sur la plupart des systèmes d’exploitation mobiles actuels. Dans cette mesure, elle devra être compatible et devra utiliser les fonctions associées au système.

Poids	Critère	Niveau	Flexibilité
5	Compatibilité	100%	0%

Table : Détail de la Fc1 de l’application mobile

Fc2 « Pouvoir étendre et modifier facilement le code de l’application »

L’un des objectifs de notre service sera d’offrir une application mobile aux fonctionnalités évolutives. Dans cette mesure, des fonctionnalités devront pouvoir être implémentées avec facilité.

Poids	Critère	Niveau	Flexibilité
4	Facilité d’évolution	4/5	10%

Table : Détail de la Fc2 de l’application mobile

Fc3 « Etre facile d’utilisation »

L’application mobile sera utilisée par un témoin sur le lieu d’un accident. L’utilisateur en fera usage dans une situation de panique, elle se devra donc d’être intuitive, claire et facile d’utilisation.

Poids	Critère	Niveau	Flexibilité
3	Ressenti utilisateur	4/5	10%

Table : Détail de la Fc3 de l’application mobile

Fc4 « Authentifier l’utilisateur »

Pour un gain de temps lors de l’appel, notre application mobile devra authentifier son utilisateur. Les informations du témoin seront alors transmises lors de l’appel.

Poids	Critère	Niveau	Flexibilité
4

Table : Détail de la Fc4 de l’application mobile


Figure : Diagramme pieuvre de l'application mobile

AM

Services d’urgence

Témoin

Mobile

Standards

Fc41

Fc31

Fc21

Fc11

Fp21

Fp1

Diagramme pieuvre

2) Analyse fonctionnelle interne

i) Fonctions principales

Figure : Diagramme FAST des fonctions principales de l'application mobile

ii) Fonctions de contrainte

Figure : Diagramme FAST des fonctions de contrainte de l'application mobile

II) Applications de monitoring

1) Analyse fonctionnelle externe

Fp1 « Obtenir les informations de l’accident »

Le système opérateur doit être en mesure d’acquérir et d’enregistrer les informations des accidents transmises par les applications mobiles. On comprend dans cette fonction les phases de connexion et d’échange de données.

Poids	Critère	Niveau	Flexibilité
5

Table : Détail de la Fp1 de l'application de monitoring

Fp2 « Offrir une interaction témoin/opérateur »

Le système opérateur doit pouvoir mettre en relation le témoin et l’opérateur afin qu’ils puissent échanger des données. On comprend dans cette fonction l’opération de routage des informations entre le témoin et l’opérateur concerné, ainsi que l’interface permettant à l’opérateur d’interagir et de visualiser les informations.

Poids	Critère	Niveau	Flexibilité
5

Table : Détail de la Fp2 de l'application de monitoring

Fc1 « Gestion facile de l’interface opérateur »

L’interface qu’utilisera l’opérateur pour visualiser les informations relatives à l’accident et pour transmettre des procédures aux témoins devra être claire et facile d’utilisation. Les fonctions de l’interface doivent pouvoir être atteignables rapidement et le risque « d’erreurs d’utilisation » (transmissions d’une mauvaise procédure,…) doit être réduit par ce biais.

Poids	Critère	Niveau	Flexibilité
3	Ressenti de l’utilisateur	4/5	10%

Table : Détail de la Fc1 de l'application de monitoring

Fc2 « Résister aux actes de malveillances »

Le système de gestion des alertes possède une connexion vers internet pour permettre d’être joint par les téléphones mobiles. C’est également là que sont stockées la plupart des informations concernant les alertes. Il est donc nécessaire d’établir une sécurité aussi bien physique que logicielle sur le système.

Poids	Critère	Niveau	Flexibilité
5	Difficulté de corruption	4.5/5	5%

Table : Détail de la Fc2 de l'application de monitoring

Fc3 « Utiliser un standard logiciel »

Les différentes applications que nous allons développer et qui seront à destination des urgences doivent être compatibles quelque soit le support ou le système d’exploitation utilisé.

Poids	Critère	Niveau	Flexibilité
4	Attente des urgences	3.5/5	10%

Table : Détail de la Fc3 de l'application de monitoring

Fc4 « Offrir une durée d’activité élevée »

Le serveur auquel les applications se connecteront pour échanger les données doit être disponible 24/7.

Nous justifierons en revanche un temps de downtime estimé à environ 1h par an pour la maintenance. A noté que l’appel classique vers les urgences n’est pas affecté si le serveur de connexion ne fonctionne pas.

Poids	Critère	Niveau	Flexibilité
4	Temps de fonctionnement	99,99%	0,001%

Table : Détail de la Fc4 de l'application de monitoring

Monitoring

Operateur

Application Client

Application serveur

Interface de gestion

Fc31

Fc11

Fc41

Fp21

Fp1

Fc21

Extérieur

Diagramme pieuvre


Figure : Diagramme pieuvre du système opérateur

2) Analyse fonctionnelle interne

i) Fonctions principales

Figure : Diagramme FAST des fonctions principales de l'application opérateur

ii) Fonctions de contrainte

Figure : Diagramme FAST des fonctions de contrainte de l'application opérateur

Planning de la 2^nde partie

I) Lotissement du projet

Etant donnée la répartition du système global en deux sous-systèmes (application mobile et application de monitoring, voir cahier OSEO et analyse fonctionnelle ci-dessus), le lotissement du projet est logiquement :

• 
  Sous-système Application mobile
  
• 
  Sous-système Application de monitoring
  

1) Application mobile

La tâche prioritaire de l’application mobile est de pouvoir communiquer (dans le sens terminal > serveur et serveur > terminal) avec le serveur de connexion, pour pouvoir par la suite tester efficacement le fonctionnement coordonné de ces deux systèmes. Il faudra ensuite tester la présence d’une puce GPS et réussir à utiliser cette dernière pour géolocaliser le terminal grâce aux méthodes du SDK Android. Ces deux tâches peuvent être regroupées sous le nom de géolocalisation. Après avoir réussi à géolocaliser le téléphone, l’équipe en charge du système application mobile devra mettre au point les méthodes d’utilisation de l’appareil photo intégré. Une fois ces deux tâches effectuées, les données à envoyer au CTA seront prêtes et la connexion au serveur fonctionnelle, il faudra donc s’occuper de la partie réception de données. Cette partie s’articule autour de deux fonctions majeures : traduire les informations reçues, et afficher les instructions correspondantes. L’équipe devra donc développer les routines de décodage de message, de sélection d’instruction, et d’affichage.

Une fois l’envoi et la réception de données adéquates finies, l’application sera fonctionnelle et il restera des fonctions plus triviales (connexion au serveur d’annuaire pour identifier / inscrire l’utilisateur, pour récupérer l’IP du serveur à contacter). En suivant ce lotissement, les fonctions prioritaires de l’application seront développées en premier, et donc fonctionnelle, l’ajout de fonctionnalités se faisant une fois le noyau dur de l’application fini.

Ce système est donc découpé de cette manière (les tâches apparaissent par ordre chronologique) :

Echange de données avec le serveur de connexion Connexion Envoi de données Réception de données Géolocalisation Test de la présence d’une puce GPS Géolocalisation du terminal via cette puce Gestion des photos Prise de photo Enregistrement Informations complémentaires Formulaire de collecte d’informations sur l’accident Affichage des données en provenance du serveur Traduction des données Affichage

Noyau dur (collecte d’informations, échange avec le serveur, affichage)

Authentification de l’utilisateur Formulaire d’inscription Inscription dans la base de données utilisateur via le serveur d’annuaire Authentification de l’utilisateur grâce à cette base via le serveur d’annuaire Choix du CTA à contacter Connexion à la base de données département via le serveur d’annuaire Choix du serveur à contacter en fonction de la réponse du serveur d’annuaire

Fonctionnalités à ajouter une fois le cœur fonctionnel

Table : Lotissement du sous-système application mobile

2) Applications de monitoring

Pour la même raison que précédemment (pouvoir tester les deux systèmes en parallèle), la priorité est donnée ici au développement d’un serveur de connexion fonctionnel.

Une fois le serveur de connexion fonctionnel, les tests demanderont également que le terminal opérateur soit développé, pour pouvoir monitorer de manière efficace les échanges de données terminal mobile / serveur.

Enfin, une fois ces deux applications terminées, l’équipe en charge de ce sous-système pourra se pencher sur les serveurs d’annuaire (utilisateur et département). Ce développement devrait se faire en parallèle de celui des méthodes d’authentification de l’utilisateur dans le système application mobile, et donnera donc lieu a des tests coordonnés entre les deux sous-systèmes.

Le lotissement prévoit donc, selon la même logique que pour l’application mobile, de développer le cœur de l’application (serveur de connexion et terminal opérateur) avant de s’occuper des fonctionnalités annexes (serveurs d’annuaire). Voici le tableau récapitulatif du lotissement de cette partie du projet :

Echange de données avec l’application mobile Connexion Envoi de données Réception de données Terminal opérateur Echange de données avec le serveur de connexion Affichage de ces données de manière claire	Noyau dur (échange avec le terminal, affichage)
Serveur d’annuaire (utilisateurs) Inscription d’un utilisateur Recherche d’un utilisateur Serveur d’annuaire (départements) Mettre au point une table permettant de faire la correspondance localisation<>serveur CTA à contacter	Fonctionnalités à ajouter une fois le cœur fonctionnel

Table : Lotissement du sous-système applications de monitoring

3) Communication

La communication du projet se répartit en trois grands domaines :

• 
  Un site internet clair et concis, présentant la société, ses champs d’activité et notre produit phare
  
• 
  Une vidéo de présentation du produit iSecours^©
  
• 
  Un poster résumant l’activité de notre société et présentant le produit iSecours^©
  
• 
  
  

II) Déroulement de la seconde partie

Cette partie est complétée par le diagramme de GANTT fourni en annexe. La deuxième partie du Projet Innovant est considérée comme commençant le jeudi 8 Avril 2010 et se terminant le lundi 31 Mai. Les plannings globaux décrits ci-après ont été décidés arbitrairement en allouant 1/3 du temps disponible à chaque partie, et sont donc fortement susceptibles d’évoluer.

1) Application mobile

Le développement de cette application est confié à une équipe de deux personnes : Nicolas Abbal et Romain Urbe, qui se sont tout les deux portés volontaires pour découvrir le langage Android et mettre en œuvre la solution précédemment décrite.

Le développement de cette application se déroulera de cette façon, le planning de chaque sous-tâche est réservé à l’appréciation de l’équipe, même si le chef de projet se chargera de surveiller l’avancement interne :

Période	Tâche
08/04– 26/04	Développement du noyau dur décrit plus haut. Tests de connexion avec le serveur.
27/04 – 12/05	Développement des fonctionnalités additionnelles.
13/05 – 30/05	Test globaux, intégration des deux sous-systèmes.

Table : Planning du sous-système application mobile.

2) Applications de monitoring

Le développement de cette partie est assuré par une équipe de trois personnes : Romain Favrelle, Léo Geoffroy, et Noureddine Laklii. Cette partie étant la plus complexe, il est important que les deux personnes chargées de l’étude technique dans la rédaction du cahier OSEO y prennent part.

De la même manière que pour l’application mobile, voilà le planning global pour ce sous-système :

Période	Tâche
08/04– 26/04	Développement du noyau dur décrit plus haut. Tests de connexion avec le terminal.
27/04 – 12/05	Développement des fonctionnalités additionnelles.
13/05 – 30/05	Test globaux, intégration des deux sous-systèmes.

Table : Planning du sous-système applications de monitoring

3) Communication

Cette partie est prise en charge entièrement par Arnaud Petit. Etant chargé de l’étude de marché durant la phase de rédaction du cahier OSEO, il sera à même de mettre au point une opération de communication / marketing apte à séduire les clients potentiels.

Planning :

Période	Tâche
08/04– 26/04	Site internet : http://emergencytech.insa-lyon.fr
27/04 – 12/05	Vidéo de présentation
13/05 – 30/05	Poster de présentation

Table : Planning de communication

III) Budget nécessaire a l’élaboration du prototype

Le prototype sera développé dans un premier temps sur la plateforme Android. Pour mettre en place notre prototype, nous aurons besoin d’un terminal mobile ainsi que de trois ordinateurs portables dont un nous servira à mettre en place la plateforme de gestion et les deux autres nous permettrons de réaliser le développement et de faire les tests de notre produit.

Nom du produit	Quantité	Prix unitaire HT	Prix Total HT
PC	3	499,00 €	1 497,00 €
Terminal Android	1	249,00 €	249,00 €
		Total HT	1 746,00 €
		TVA (19,6 %)	342,22 €
		Total TTC	2 088,22 €

Table : Etude budgétaire du prototype

Dans le cadre de notre projet, nous disposons d’un terminal et de trois ordinateurs portables qui nous seront prêtés et qui nous permettront de réaliser le prototype de notre projet.

Liste des tables

Liste des figures

Annexes

Diagramme de GANTT

Figure : Diagramme de GANTT

/

/ 17

Projet Innovant 4TC – groupe 2 : iSecours^©