Galaxy Swiss Bourdin Année

Transcription

1 Galaxy Swiss Bourdin Année Projet Application Frais DOSSIER RELATIF DU COMPTE RENDU DE LA GESTION DE FRAIS SUR UN TERMINAL ANDROID.

2 Sommaire Contexte...3 Cahier des charges Définition de la problématique Contraintes....4 Différentes étapes Expression du besoin Analyse Cas d utilisation Choix de Conception Gestion de la Conception Conception des étapes Difficultés rencontrées Diagramme des utilisateurs...8 Modèle conceptuel de données... 8 Partie personnelle Conclusion...9 p. 2 Scinces-U Lyon Tom PAYA

3 Contexte Le laboratoire GalaxySwiss Bourdin (GSB) est issu de la fusion entre le géant américain Galaxy et le conglomérat européen Swiss Bourdin, lui-même déjà union de trois petits laboratoires. Ces laboratoires se sont unis en 2009 afin de devenir un des leaders de l industrie pharmaceutique. Le laboratoire désire mettre à disposition des visiteurs médicaux une application WEB permettant de centraliser les comptes rendus de visite. Cette base d information sera utilisée à des fins d élaboration de la démarche de communication auprès des praticiens. Cahier des charges Définition de la problématique Définition de l objet Le suivi des frais est actuellement géré de plusieurs façons selon le laboratoire d origine des visiteurs. On souhaite uniformiser cette gestion L application doit permettre de consulter tout frais engagé, aussi bien pour l activité directe (déplacement, restauration et hébergement) que pour les activités annexes (événementiel, conférences, autres). Forme de l objet L application Android destinée aux visiteurs sera disponible sur la plateforme de téléchargement Play Store, accessible depuis un terminal Android. Accessibilité/Sécurité L environnement doit être accessible aux seuls acteurs de l entreprise. Une authentification préalable sera nécessaire pour l accès au contenu. Tous les échanges produits doivent être cryptés par le serveur Web. Contraintes Architecture L application respectera l architecture des scripts fournis concernant la gestion de l enregistrement des frais engagés par les visiteurs. Ergonomie Les pages fournies ont été définies suite à une consultation. Elles constituent une référence ergonomique. Des améliorations ou variations peuvent être proposées. p. 3

4 Codage Des tutoriels présentent des règles de bonnes pratiques de développement utilisées par le service informatique de GSB pour encadrer le développement d applications en Java et en faciliter la maintenance. Les éléments à fournir devront respecter le nommage des fichiers, variables et paramètres, ainsi que les codes couleurs et la disposition des éléments déjà fournis. Environnement Le langage de script côté serveur doit être le même que celui utilisé dans les pages fournies. L utilisation de bibliothèques, API ou Framework est à l appréciation du prestataire. Modules L application présente un module : - Suivi par les visiteurs Documentation La documentation devra présenter l arborescence des pages pour chaque module, le descriptif des éléments, classes et bibliothèques utilisées, la liste des Framework ou bibliothèques externes utilisés. Différentes Etapes Expression du besoin Cette application Android a pour but de permettre la consultation des frais des utilisateurs. Les utilisateurs passeront par une page d authentification sécurisé. L application devra permettre aux utilisateurs de consulter des lignes de frais qui formeront des fiches consultables. Dans ces lignes l utilisateur pourra consulter diverses informations propres aux lignes frais ou hors frais. Cette base d information sera utilisée afin d élaborer une démarche de communication auprès des comptables. Analyse Situation professionnelle et niveau d autonomie Nous avons réalisé le travail en équipe de 3, l équipe est constituée du chef de groupe Arthur Paille ainsi que Linda Asloune et Tom Paya. Chacun avait ses propres taches à faire afin de mieux avancer dans le projet touchant à chaque domaine (Java, Json, XML ) Nous nous concertions à chaque fois que quelqu un avait fini sa tâche ou qu un problème apparaissait afin qu il ne bloque pas. p. 4

5 Conception du MCD (Modèle Conceptuel des données) La première étape était de concevoir le MCD. L entreprise avait fourni un début du MCD, nous avons dû le modifier afin qu il réponde à nos attentes. Ce dernier a été fait avec Doctrine, un ORM de Symfony. Cas d utilisation Conception de la maquette IHM - Structure de base de l application est simple avec le logo, les couleurs de base, le bouton connexion sur la première page, - Les pages devaient être plus ou moins identiques afin de simplifier la navigation des utilisateurs, - Authentification de l utilisateur à partir de son adresse mail ainsi que de son mot de passe - Possibilité de choisir la fiche désirée afin d obtenir les informations détaillées de cette dernière Les différents rôles prévus pour l application Commercial - Connexion, - Consultation des fiches, - Consultation des lignes frais p. 5

6 Voici notre diagramme d utilisation qui explique les droits des personnes connectés à l application. Pour cette application, seul les commerciaux ont accès à la consultation de leurs fiches frais. Choix de Conception - Symfony pour une bonne gestion de l application ainsi qu un gain de temps grâce à ses composants déjà présents. C est un Framework flexible donc qui répond plus facilement à nos besoins de plus une importante communauté se sert de Symfony donc on peut facilement se renseigner ou résoudre des problèmes. - Java pour la conception de l application Android. Le Java est le seul langage de conceptions d applications Android. - Json pour le parsage des données entre l application Web édité sous Symfony en PHP avec le Java d Android p. 6

7 Architecture applicative Modèle MVC M : modèle : correspond aux fonctionnalités de récupération de données dans la base de données : toutes les interactions nécessaires avec la base de données GSB sont présentes dans un seul dossier, chaque fois qu il y en a besoin une fonction de ce fichier est appelée par le Controller. V : vue : les vues ont été réalisées à partir de maquette IHM préalablement analysé pour chaque fonctionnalité du site il y en a une, ces vues sont appelées par le Controller de la fonction associés. C : Controller : (cas d utilisation) : Les Controller leurs appellent les vues et les fonctions de la base de données, ainsi que les utilitaires de gestions d erreurs. Ils permettent d effectuer les différents traitements étudies dans les cas d utilisation, pour chaque Controller il y a un appel à une vue, un appel aux fonctions de la BDD si nécessaire et l appel aux fonctions de gestion d erreurs. Ce modèle est destiné à répondre aux besoins des applications interactives en séparant les problématiques liées aux différents composants au sein de leur architecture respective. Versionning avec Git Lors de la phase de développement, nous nous sommes servis d un serveur de versionning comme système de sauvegarde. Ainsi, chaque membre avait à sa disposition une version mise à jour grâce à un système de «push» et de «pull» permettant d envoyer et de récupérer les travaux effectués. p. 7

8 Réalisation de l application Après avoir étudié le contexte, nous avons cerné l objectif de cette application et tout en respectant les normes de développement fournit dans le contexte, nous avons créé l application Web. Nous sommes partis d aucun modèle, tout a été fait par notre groupe (Maquette, base de données, actions, aspect graphique) : - Utilisation de la base de données afin de pouvoir l exploiter dans notre affichage, -Création de la page d accueil qui est en fait la page de connexion des utilisateurs, elle regroupe juste un encadrer pour se connecter avec le logo, -Création des pages pour les commerciaux, dans ces pages les commerciaux pourront consulter leurs fiche frais mais ils pourront aussi les consulter leurs détails. Il est primordial que l affichage des fiches ne soit pas sur la même page que celle des lignes afin de rendre plus fluide l expérience utilisateur Difficultés rencontrées - Débuter avec le Json et le parsage, - Récupération les données depuis la base de données, - Gérer les erreurs inconnues, - S initier avec Android Studio et l utilisation de ses fonctions p. 8

9 Partie Personnelle Mon travail dans ce projet a été la partie graphique de l application Android, pour cela je me suis servi des fichiers XML. Je me suis basé sur les couleurs du logo tout en restant sobre. Je me suis chargé de créer les fichiers permettant l affichage des fiches ainsi que des détails. La liaison entre l application Android et le PHP avec Json et le fichier PhoneApiController afin de permettre l affichage des informations des commerciaux. Conclusion Ainsi, l analyse des besoins de l entreprise est primordiale avant de commencer le projet. En effet, la compréhension du cahier des charges est important pour que l on puisse en déduire les réels besoins de l entreprise. Concevoir une application Android avec du Java demande des connaissances non négligeables, il ne faut pas hésiter à faire de l autoformation afin de corriger les problèmes. Aussi, Android possède une importante communauté ceux qui permet de trouver facilement les réponses à nos questions. Aussi, il faut penser et concevoir l application Android de manière à ce que l expérience utilisateur soit la meilleur possible en la rendant simple et intuitif. Pour se faire, il faut se mettre à la place de l utilisateur pour pouvoir adapter et optimiser l application. p. 9