• Aucun résultat trouvé

Projet AllSchools : portage Android Cahier des Charges

N/A
N/A
Protected

Academic year: 2022

Partager "Projet AllSchools : portage Android Cahier des Charges"

Copied!
13
0
0

Texte intégral

(1)

Projet AllSchools : portage Android

Cahier des Charges

(2)

Cahier des Charges : Présentation générale du problème

1

Contenu

I. Présentation générale du problème ... 3

1. Projet ... 3

a. Présentation ... 3

b. Contexte ... 3

c. Retour sur investissement ... 3

2. Contexte ... 3

a. Situation du projet ... 3

b. Suites prévues ... 4

c. Nature des prestations demandées ... 4

d. Parties concernées par le déroulement du projet et ses résultats ... 4

3. Description de l’existant ... 5

4. Enoncé du besoin ... 5

5. Contexte ... 5

a. Moyens humains ... 5

a. Matériels utilisés ... 5

b. Langages & techniques utilisés ... 6

II. Expression fonctionnelle du besoin ... 7

1. Fonctions de service, contraintes et besoins en IHM ... 7

a. Fonctions de service principales ... 7

b. Contraintes ... 8

c. Besoins en IHM ... 8

1. Critères d’acceptabilité ... 9

2. Niveaux des critères d’appréciation et ce qui les caractérise ... 9

a. Niveaux dont l’obtention est imposée ... 9

b. Niveaux souhaités mais révisables ... 9

III. Cadre de Réponse ... 10

1. Solutions Proposées ... 10

a. Le MVC ... 10

b. L’authentification ... 10

c. Le parsage ... 11

d. La base de données SQLITE ... 11

2. Pour l’ensemble du produit ... 11

a. Prix de la réalisation de la version de base ... 11

(3)

Cahier des Charges

Cahier des Charges : Présentation générale du problème

2

b. Mesures prises pour respecter les contraintes ... 12 c. Prévisions de fiabilité ... 12

(4)

Cahier des Charges : Présentation générale du problème

3

I. Présentation générale du problème 1. Projet

a. Présentation

Du fait de la croissance rapide des parts de marché du système d’exploitation Androïd, AllSchools dans un souci d’être accessible à tous doit être porté sur cet OS.

b. Contexte

Apple est un support mobile qui propose des applications intuitives, parmi lesquelles se trouve l’application «AllSchools ». Cette application permet aux futurs étudiants d’obtenir une vue synthétique de l’offre de formations proposée par l’Université du Maine. Dans le cadre du développement des médias, l’ENSIM s’investit dans l’évolution de cette application.

Les améliorations de l’application « AllSchools » ont toujours pour but de promouvoir l’offre de formation de l’enseignement supérieur de l’Université du Maine sur support mobile Androïd.

Le portage de l’application sous Androïd permettra à l’application d’être plus accessible au public concerné.

c. Retour sur investissement

Il n’y a aucun retour sur investissement. En effet, l’application développée sera mise à disposition gratuitement sur l’Androïd Market, et ce, dans une optique de la rendre la plus accessible possible pour les utilisateurs.

2. Contexte

a. Situation du projet

Commencé en 2009, le projet AllSchools a été originellement développé sur support IPhone pour l’ENSIM, jusqu’à la version actuelle (v1.2 développée l’année dernière à l’ENSIM par des étudiants de 2ème année). Il a ensuite été sollicité pour être étendu à toute l’université du Maine voire la région (Universités de Nantes, Angers et Le Mans). Il a également été sollicité pour un portage sur Androïd par la société ST ERICSSON.

(5)

Cahier des Charges

Cahier des Charges : Présentation générale du problème

4

Le projet est développé par une équipe de six personnes de deuxième année filière Informatique à l’ENSIM (École Nationale Supérieure d’Ingénieurs du Mans), dans le cadre des projets de 2ème année de l’ENSIM. Il s’inscrit dans une optique de correction de l’application portée sur Androïd par un stagiaire ST ERICSSON.

b. Suites prévues

L’application sera reprise ensuite par ST-Ericsson qui poursuivra le projet dans le cadre d’un stage de niveau Master 2 au moins jusqu’à la v1.2. Le but du stage sera d’inclure de nouvelles fonctionnalités comme une connexion à l’ENT et un versioning.

c. Nature des prestations demandées

Notre travail est de développer le portage sur le système d’exploitation Androïd de l’application AllSchools en respectant le plus scrupuleusement possible l’architecture de l’application originelle.

d. Parties concernées par le déroulement du projet et ses résultats

Le maître d'ouvrage, directeur des études informatique de l’ENSIM : - M. Florent Carlier

- Email : florent.carlier@univ-lemans.fr La maîtrise d’œuvre est constituée de :

- M. Vincent Molliere

- Email : vincent.molliere.etu@univ-lemans.fr - M. Darryl Tadmi

- Email : Darryl.Tadmi_Tchangam.etu@univ-lemans.fr - M. Anass Chabbab

- Email : Anass.Chabbab.Etu@univ-lemans.fr - M. Amjed Chaouat

- Email : vincent.molliere.etu@univ-lemans.fr - M. Joffrey Durand

- Email : Joffrey.Durand.Etu@univ-lemans.fr - M. Abdellah Moustaid

- Email : abdellah.moustaid.etu@univ-lemans.fr

(6)

Cahier des Charges : Présentation générale du problème

5

3. Description de l’existant

Une version pour IPhone et IPad de Apple existe déjà. Il existe de plus une version non- dynamique de l’application sous Androïd. Les seuls points qui seront repris de cette application sont les interfaces.

4. Enoncé du besoin

La principale finalité de cette application est qu’elle doit permettre à des utilisateurs de pouvoir se renseigner sur les études post-bacs par le biais de l’application : les établissements, leurs associations, etc…

De plus, les utilisateurs appartenant à un UFR auront accès aux propositions de stage de cet UFR.

Aussi, un utilisateur pourra suivre les actualités liées aux parcours.

5. Contexte

a. Moyens humains

Voici les membres de l’équipe du projet : - Vincent MOLLIERE

- Darryl TADMI - Anass CHABBAB - Amjed CHAHOUAT - Joffrey DURAND - Abdellah MOUSTAID

En soutien dans ce projet, nous aurons la possibilité d’interroger nos enseignants de l’ENSIM sur les questions relatives au codage.

a. Matériels utilisés

Voici le matériel que nous utiliserons au cours du projet :

• Des ordinateurs portables

• Des ordinateurs de bureau en complément.

• Une machine distante hébergeant un serveur de contrôle de version.

(7)

Cahier des Charges

Cahier des Charges : Présentation générale du problème

6

i. Ordinateurs portables

Les ordinateurs portables nous serviront de plateforme de développement principale. De plus, leur aspect « portable » est pratique car il permet également de travailler sur le projet à tout moment et où que ce soit.

ii. Ordinateurs de bureau

Les ordinateurs de bureau seront des supports secondaires de développement. Il s’agit des machines de l’ENSIM sur lesquelles sont installés des machines virtuelles (AVD).

iii. Machine distante

La machine distante permettra l'hébergement d'un serveur de contrôle de version nommé TortoiseSVN. Cette machine n'aura pas d'autre intérêt que celui de centraliser les sources et documents du projet.

b. Langages & techniques utilisés

Pour le développement d’une telle application, il faudra mettre en œuvre une stratégie technique bien révisée, et nous tourner vers des outils de développement bien spécifiques. C’est pourquoi, nous combinerons :

- Pour l’application en elle-même, Java par le biais du SDK Eclipse avec les bibliothèques nécessaires à la programmation sous Eclipse.

- Pour le service de stage, les technologies Web habituelles.

(8)

Cahier des Charges : Expression fonctionnelle du besoin

7

II. Expression fonctionnelle du besoin

1. Fonctions de service, contraintes et besoins en IHM

a. Fonctions de service principales

L’application doit permettre, aux différents types d’utilisateurs concernés d’effectuer les tâches suivantes :

- Simple utilisateur :

 parcourir les écoles

 parcourir les formations

 parcourir les associations

 parcourir les fonctionnalités pratiques

 parcourir les contacts

 parcourir les partenaires

 lire l’information d’une fiche

 parcourir les différentes sections d’une fiche

 parcourir les vidéos d’une fiche

 parcourir les images d’une fiche

 lire une vidéo d’une fiche

 voir une image d’une fiche

 enregistrer un contact ou un partenaire

 envoyer un mail à un contact ou à un partenaire

 parcourir les différentes formations

 parcourir les différentes écoles.

 suivre les actualités.

- Etudiants d’une école :

 s’authentifier.

 utiliser les services propres à son école.

- Responsable d’une école

 s’authentifier

 ajouter des services

 mettre à jour les services

(9)

Cahier des Charges

Cahier des Charges : Expression fonctionnelle du besoin

8

b. Contraintes

Le porteur du besoin n’a pas vraiment émis de limites ou de contraintes, à part l’exigence de faire le portage de la version IPhone de l’application vers une version Androïd sans y ajouter d’autres fonctionnalités. Par exemple, un étudiant de l’université du Maine peut accéder à des fonctionnalités telles que le module stage, en utilisant son identifiant et son mot de passe de l’université.

Le module ENT ne sera pas disponible sur cette application ainsi que les fonctionnalités suivantes, même si elles nous semblent indispensables dans cette application :

- L’accès aux emplois du temps.

- L’accès aux événements

- L’accès à la messagerie de l’université - L’accès aux disponibilités des salles.

- L’accès aux relevés de notes

- Les inscriptions en ligne aux différents cursus et aux différentes activités de l’université (SUIAPS, CUEP, etc.)

- Autres

c. Besoins en IHM

Le support utilise pour l'application AllSchools, en l’occurrence l’IPhone Galaxy SII, suppose une interaction tactile entre les diffe rents menus. Pour naviguer entre les interfaces, au lieu d'avoir des liens sous forme textuelle, sont mis en place des ico nes qui se doivent d'e tre d'une taille optimale pour permettre une navigation aise e et adapte e aux mouvements digitaux.

Une fois l'ico ne en question touche e, le sous-menu correspondant apparaî t en une fraction de seconde. La notion de simplicite est essentielle pour ne pas perdre l'utilisateur dans la hie rarchie des interfaces. Les ico nes doivent ainsi respecter une charte graphique (couleur et forme), dont la fonction est facilement identifiable. Une barre d’onglets au bas de l’e cran permet de retourner a la racine de l’application, permettant de ce fait de choisir l’une des quatre sections principales.

Les cibles concerne es par l'application sont entre autres les e tudiants d'une e cole de l'enseignement supe rieur et les responsables de formation. Cela a un impact sur la manie re dont sont pre sente es et spe cifie es les informations. Un e tudiant doit pouvoir reconnaî tre les sections qui lui sont de die es d'un simple coup d’œil, sans avoir a acce der a celles-ci pour ve rifier. De me me, dans cette optique, en fonction de l'utilisateur authentifie , les sections disponibles varient. L'interface consacre e aux responsables de formation sera par conse quent plus fournie que celle de die e aux simples utilisateurs.

L'application doit supporter l'affichage de textes, notamment pour la section des actualite s, ainsi que des images et des vide os. Ces dernie res interagissent du point de vue tactile, une vide o se lance en touchant le bouton Lecture, s'interrompt avec le bouton Pause. Dans un ordre d’ide e similaire, les pages qui disposent d’un contenu exce dant la taille de l’e cran glissent selon la verticale, sous l’impulsion tactile de l’usager. Les interactions possibles entre l’humain et la machine varient donc suivant le contenu affiche .

(10)

Cahier des Charges : Expression fonctionnelle du besoin

9

1. Critères d’acceptabilité

Les critères obligatoires sont :

- L’application dispose des mêmes fonctionnalités que l’originale.

- L’architecture de l’application est identique sauf particularités du langage de l’application de départ et du support mobile.

Les critères importants sont :

- L’application doit être fiable et doit présenter le moins de bugs possible pour une expérience utilisateur optimale.

- L’application doit être rapide dans l’exécution de ses fonctionnalités.

Les critères accessoires sont :

- L’ajout de fonctionnalités est possible mais seulement après la finalisation du portage.

2. Niveaux des critères d’appréciation et ce qui les caractérise

a. Niveaux dont l’obtention est imposée

Un test approfondi du système pendant une durée à déterminer permettra de savoir si l’application présente les mêmes fonctionnalités que l’originale.

b. Niveaux souhaités mais révisables

Les utilisateurs doivent nous faire le moins de rapport de bug possible. Si des rapports sont soumis, les bugs devront être corrigés le plus vite possible. De plus, on notera dans le suivi des utilisateurs, les remarques sur l’application et si aucun retour important n’est recueilli, alors la condition est remplie.

On s’évertuera aussi à calculer les temps de réponse entre la demande d’une fonctionnalité et son affichage et ceci pour toutes les fonctionnalités. Si les valeurs relevées sont raisonnables, alors le critère est respecté.

(11)

Cahier des Charges

Cahier des Charges : Cadre de Réponse

10

III. Cadre de Réponse 1. Solutions Proposées

a. Le MVC

Comme dans tout bon développement, nous utiliserons le MVC (Model-View-Controller) pour notre implémentation. En effet, cela implique de diviser de manière indépendante les différentes parties du programme.

Le modèle ici sera constitué de tout le contenu et de toutes les classes d’objets, codées bien entendu en Java Androïd. Nous y rangerons les offres de formation, de stages (etc.), les associations, les débouchés, toutes les caractéristiques propres à l’école, ainsi que toutes les méthodes associées à ce contenu.

La vue quant à elle sera ici une sorte de vue contrôlée plutôt que d’avoir un contrôleur à part, ceci pour nous plier à l’existant. En effet, le Carrousel qui constitue la vue dispose d’un contrôleur intégré. Par ailleurs, le système Samsung Galaxy se charge lui-même du contrôle en ceci que c’est au travers de fonctions et boutons déjà présents que l’application sera contrôlée.

Ajoutés au carrousel pour compléter la vue, il y’aura la représentation, dans l’application, des différents contenus. Ces dernières seront le résultat du parsage de fichiers XML en provenance du serveur central AllSchools.

b. L’authentification

Un système d’authentification sera mis en place pour les accès en nécessitant une. Il ne sera notamment permis qu’aux étudiants d’UFR d’accéder aux offres de stage de cet UFR.

Dans ce cas le système se branchera au système d’authentification de l’ENT de

l’université concernée, pour éviter d’avoir à gérer une base de données de tous les étudiants de toutes les universités partenaires.

Une connexion internet sera bien sûr requise mais les informations consultées pourront être téléchargées et enregistrées dans le mobile pour un accès ultérieur.

Quant aux informations ne nécessitant pas d’authentification particulière, elles seront accessibles automatiquement et téléchargeables au même titre.

(12)

Cahier des Charges : Cadre de Réponse

11

c. Le parsage

Comme indiqué précédemment, les données du modèle seront complétées suite au parsage de fichiers en provenance du serveur central AllSchools. Ce dernier nous envoie des fichiers au format CDM (XML standardisé pour les offres de formation).

Ceci dit, au vu du caractère chronophage du parsage de fichiers XML dans le contexte d’une utilisation mobile, les données autres que les offres de formation, celles qui ne sont pas formatées CDM et donc sur lesquelles nous avons le contrôle, seront au format JSON, beaucoup plus pratique du point de vue vitesse de parsage.

Ainsi, il sera question d’avoir deux modes de parsage différents : un réservé aux fichiers CDM et un autre pour les fichiers JSON. Le résultat de ces 2 opérations en une sera ensuite exporté vers une base de données SQLITE, laquelle sera utilisée par la suite pour restituer les informations, plutôt que de les télécharger à chaque fois.

Par ailleurs, le processus de parsage intégrera une phase de téléchargement des fichiers : d’une part les CDM, d’autre part les JSON, avec un paramètre de versioning référencé dans une table, avant de les rediriger dans les répertoires correspondants dans le téléphone.

d. La base de données SQLITE

Les informations contenues dans cette base gérée de manière interne à l’application, seront, comme indiqué précédemment, le résultat du parsage des fichiers de contenu. Elle contiendra donc l’ensemble des offres de formations et de stage, ainsi que les différentes données propres à l’école.

Ces informations étant sujettes à changement, elles ne peuvent être statiques. C’est là qu’intervient la capacité de versioning du téléchargement. En effet, les fichiers référés dans la base de données ont un paramètre de version référencé dans une table de version permettant d’indiquer s’ils sont à jour ou pas ; auquel cas un nouveau téléchargement des fichiers non à jour uniquement est proposé à l’utilisateur.

2. Pour l’ensemble du produit

a. Prix de la réalisation de la version de base

Etant un projet au sein d’une école et donc exécuté par des étudiants, le budget pour la main- d’œuvre est nul.

De plus, tous les logiciels de développement et les langages de programmation sont libres et gratuits.

Le budget pour la réalisation du logiciel est donc nul.

(13)

Cahier des Charges

Cahier des Charges : Cadre de Réponse

12

b. Mesures prises pour respecter les contraintes

Afin de respecter les contraintes, plusieurs séries de test du produit ont été planifiées tout au long de la phase de réalisation afin de mieux intégrer le facteur d'évolution technologique, de portabilité, …

c. Prévisions de fiabilité

Prévoir la fiabilité d’un système relève essentiellement d’une étude statistique (intervalles de confiance notamment) et probabiliste sur des échantillons limités, afin d’estimer au mieux le taux de panne relatif à chaque module du projet.

Ces taux de panne étant obtenus sur des échantillons forcément limités en taille, leur valeur est gouvernée par les lois de la statistique (intervalles de confiance notamment).

Références

Documents relatifs

 Déterminer le niveau de service susceptible de définir le socle commun de l’engagement des différentes parties prenantes pour garantir à toute personne en

Corriger les problèmes présents sur la carte qui affiche le niveau de charge d'une batterie 12V Programmer le microcontrôleur ATMega3585 avec CodeVisionAVR.. Corriger voire réaliser

d’une base de données T1_6 Tester les classes métier X X X Rapport de test unitaire (se. répartir les classes

L’appel à projet concerne ainsi les mineurs de 13 à 18 ans, reconnus mineurs non accompagnés après l’évaluation de leur minorité pour lesquels une décision judiciaire les

Dans le cas de mise en place d’action de formation en situation de travail (AFEST), l’organisme de formation devra justifier le recours à l’AFEST et identifier au préalable

Je retourne sur le PC-Controller et je lance le logiciel Omada discovery utility qui va scanner le réseau et repérer le point d’accès TP-Link. Mon point accès est bien accessible

C’est la partie importante qui doit être bien comprise par le client, un peu comme la maquette et le plan de l’architecte, chaque fonction doit être décrite et détaillée

Ajoutez à votre cahier des charges toutes les maquettes et prototypes de vos idées concernant le résultat que vous aimeriez obtenir avec cette application