COMPTE RENDU GESTION DE FRAIS GSB APPLICATION WEB Sciences-U Lyon Linda ASLOUNE, 0514838873
Sommaire Contexte...3 Cahier des charges Définition de la problématique.....3 Contraintes....4 Différentes étapes Expression du besoin.....5 Analyse......5 Cas d utilisation......6 Choix de Conception......7 Architecture applicative.........8 Réalisation de l application.........9 Difficultés rencontrées.......10 Partie personnelle.... 10 Conclusion.....10 p. 2
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 d enregistrer 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), et de présenter un suivi daté des opérations menées par le service comptable (réception des pièces, validation de la demande de remboursement, mise en paiement, remboursement effectué). Forme de l objet L application Web destinée aux visiteurs, délégués et responsables de secteur, sera en ligne, accessible depuis un ordinateur. La partie utilisée par les services comptables sera aussi sous forme d une interface Web. Le module accessible à la force de visite sera intégré à l application de gestion des compte-rendu de visite, mais sous forme d une interface spécifique (elle ne doit pas être fusionnée à la saisie des comptes rendus, elle sera sur un onglet ou une page spécifique). 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. p. 3
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. Codage Le document ApplisWeb-NormesDevelpt présente 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 PHP et en faciliter la maintenance ; les deux applications fournies (GSB-AppliFrais et GSB-AppliFrais-MVC) s efforcent de les mettre en œuvre. 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 deux modules : - Enregistrement et suivi par les visiteurs (code fourni), - Enregistrement des opérations par les comptables 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. p. 4
Différentes Etapes Expression du besoin Cette application Web a pour but de permettre la centralisation des comptes rendus des visites. Les utilisateurs passeront par une page d authentification sécurisé. L application devra permettre aux utilisateurs de consulter/éditer des lignes de frais qui formeront des fiches consultables, le comptable pourra lui valider ou non ses fiches. Dans ces lignes l utilisateur pourra renseigner diverses informations propres aux lignes frais ou hors frais. Ces fiches seront consultables par l utilisateur et le comptable. Cette base d information sera utilisée afin d élaborer une démarche de communication auprès des comptables. Analyse 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. Modification effectuée : - Ajout des fonctions de FosUserBundle 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 (Doctrine, PHP, HTML, CSS ) 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. 5
Cas d utilisation Conception de la maquette IHM - Structure de base du site est simple avec le logo, les couleurs de base, le bouton déconnexion, - Les pages devaient être plus ou moins identiques afin de simplifier la navigation des utilisateurs, - Gestion des petits écrans avec le format responsif donc restructuration des informations, - Authentification de l utilisateur à partir de son adresse mail ainsi que de son mot de passe, - Possibilité de choisir tel ou tel fiche en fonction de différentes conditions comme par exemple le mois, l utilisateur Les différents rôles prévus pour l application Commercial - Saisie des lignes frais forfait ou hors frais forfait, - Modification des lignes, - Consultation des fiches Comptable - Consultation des fiches, - Modification des états des fiches Admin - Gestion des utilisateurs, - Gestion des frais, - Gestion des états p. 6
Voici notre diagramme d utilisation qui explique les droits des personnes connectées à l application. Par exemple, le comptable ne possède pas le droit de rédiger des frais tout comme l administrateur. Choix de Conception - PHP pour la conception des Controller et des actions à gérer dans l application, langage utilisé par Symfony, - HTML pour la rédaction du texte sur la partie visuelle du site web, dans notre projet l HTML est dans des fichiers Twig, gestion de l HTML utilisé par Symfony, permet de créer une base qui peut s étendre sur d autre page, - CSS pour la mise en forme du site web, gestion des couleurs, police, position d élément, - Bootstrap pour compléter notre CSS et gérer principalement le responsive, il apporte un gain de temps et propose déjà des éléments de design tels que des boutons, - 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, on peut ainsi facilement se renseigner ou résoudre des problèmes. p. 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. 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) : - Création de la base de données afin de pouvoir l exploiter dans nos Controller et formulaire, -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 rédiger leurs lignes frais au forfait ou hors forfait mais ils pourront aussi les consulter. Il est primordial que l affichage des fiches ne soit pas sur la même page que celle de la conception des lignes afin de rendre plus fluide l expérience utilisateur, -Création des pages pour les comptables pour qu ils puissent valider ou non les lignes frais des commerciaux. Ils ont dans un premier temps les fiches et lorsqu il clique dessus ils ont accès aux données de ses fiches (les lignes), -Création des pages d Admin ou ce dernier pourra gérer les utilisateurs avec leurs données ainsi que leurs rôles mais il pourra également gérer les types de frais sur une autre page. p. 9
Difficultés rencontrées - Débuter avec aucune connaissance en Symfony, - Récupération des données depuis la base de données, - Faire une synthèse des informations importantes tiré du cahier des charges, - Gérer les erreurs inconnues, - Gérer l intégration du projet dans deux systèmes d exploitation différents (Windows/Mac OS), Partie Personnelle Dans ce projet j ai travaillé sur la partie graphique du site Web et le logo en faisant leurs maquettes. De plus, avec l aide de mes collaborateurs, j ai été chargé du modèle conceptuel de la base de données, puis de sa création avec doctrine grâce aux informations retenues dans le cahier des charges. J ai également aider à la création des utilisateurs. 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 Web avec Symfony demande beaucoup de patience et d attention, il ne faut pas hésiter à faire de l autoformation afin de corriger les problèmes. Aussi, il faut penser et concevoir l application web de manière à ce que l expérience utilisateur soit la meilleur. Pour le faire, il faut se mettre à la place de l utilisateur pour pouvoir adapter et optimiser l application. p. 10