BTS Services informatiques aux organisations

Session 2017

E4 – Conception et maintenance de solutions

Coefficient 4

DESCRIPTION D’UNE SITUATION PROFESSIONNELLE

Épreuve ponctuelle : Parcours SLAM

NOM et prénom du candidat : ALBAC Thibault N° de candidat : 0514838969

Structure de la situation professionnelle : Contexte GSB

Intitulé de la situation professionnelle : Cahier des charges du projet

Période de réalisation : 10/05/2016 au 30/06/2016 Lieu : Lyon

Modalité : En équipe

Domaine de compétence : D1.1 - Analyse de la demande

D1.2 – Choix d’une solution D1.3 – Mise en production d’un service D1.4 - Travail en mode projet D2.1 - Exploitation des services D4.1 – Conception et réalisation d’une solution applicative D4.2 - Maintenance d’une solution applicative D5.2 – Gestion des compétences

Productions associées

Cahier des charges numérique : Gant Project :

MCD :

Modalités d’accès aux productions

URL du site web : http://www.albacthibault/wordpress.com

GSB – Galaxy Swiss Bourdin

Cahier des charges et Spécifications fonctionnelles

ALBAC Thibault

2015 – 2017

1 | P a g e

Sommaire

Table des matières ................................................................................................................................................. 2

I – Lexique .................................................................................................................. 3

II – Introduction ......................................................................................................... 3

III – Description de la demande ................................................................................. 4

IV – Contraintes ......................................................................................................... 5

V – Déroulement du projet ........................................................................................ 7

VI – La solution Web .................................................................................................. 9

VII – L’application mobile ......................................................................................... 12

VII – Modélisation : .................................................................................................. 20

VII – Bilan ................................................................................................................. 21

X- Annexes : ............................................................................................................. 22

2 | P a g e

I – Lexique

Pour aider à la compréhension du présent document, voici quelques définitions utiles des termes spécifiques au projet :

A – Utilisateur

En informatique, un utilisateur est tout simplement une personne lambda qui utilise un programme via un compte qui lui a été créé au préalable. Cette personne n’a pas la possibilité d’effectuer des changements qui affectent d’autres utilisateurs : ses droits sont limités. Ici, cela correspond au profil « Utilisateur », réservé aux visiteurs.

B – Administrateur

En informatique, un administrateur est un utilisateur qui peut effectuer des changements qui affectent les autres utilisateurs : modification de paramètres de sécurité, de droits d’accès, etc. Ici, le profil « Administrateur » ouvre plus de possibilités à celui qui le détient que le profil « Utilisateur » : il a des droits de gestion (création, modification, suppression) sur certaines données inaccessibles aux utilisateurs. Il y aura 2 niveaux d’Administrateur distinct : niveau 1 (Responsables), et niveau 2 (Délégués).

C – IDE

Un IDE (integrated, developpement, environment) ou EDI (environnement de développement intégré) est un outil qui permet de développer une solution logiciel le cas présent il a été utiliser pour le développement de la solution mobile, l’application Android.

II – Introduction

Le laboratoire Galaxy Swiss Bourdin (GSB) est issu de la fusion entre le géant américain Galaxy (spécialisé dans le secteur des maladies virales dont le SIDA et les hépatites) et le conglomérat européen Swiss Bourdin (travaillant sur des médicaments plus conventionnels), lui-même déjà union de trois petits laboratoires.

Dans un souci de cohérence et d’optimisation du fonctionnement du groupe, GSB souhaite informatiser au maximum le travail de ses collaborateurs, en leur mettant à disposition des outils web et mobile

3 | P a g e

III – Description de la demande

A – Version antérieure

En 2003, le laboratoire Swiss Bourdin avait mené un travail d'informatisation des comptes-rendus, qui devait permettre aux visiteurs de disposer d'un outil de gestion personnelle de leur activité et, par un module d'export, d'adresser aux délégués régionaux une synthèse mensuelle. L'application était prévue sous Access et certaines parties ont été développées. Toutefois, suite à diverses réorientations de la stratégie, ce développement n'a plus été une priorité et le système, en l'état, n'a été diffusé qu'à quelques visiteurs pour évaluation.

B – Découpage du territoire

L'entreprise compte 480 visiteurs médicaux en France métropolitaine (Corse comprise), et 60 dans les départements et territoires d'outre-mer. Les territoires sont répartis en 6 secteurs géographiques (Paris-Centre, Sud, Nord, Ouest, Est, DTOM Caraïbes, Amériques, DTOM Asie-Afrique).

Chaque secteur est divisé en zones. En ce qui concerne la France métropolitaine, les zones correspondent aux départements qui constituent les secteurs. C’est le terme « zone » qui sera utilisé ici. Par exemple : la zone « Haute-Savoie » fait partie du secteur « Est ».

C – Nouvelles attentes GSB souhaite repartir de l'étude de 2003 et produire une application Web, également accessible en version mobile (téléphone ou tablette). Les collaborateurs concernés par le projet développé ici sont les suivants :

1) Visiteurs

Les visiteurs sont en quelque sorte les « commerciaux », ou représentants, de l’entreprise. Leur mission est de promouvoir les produits GSB auprès des praticiens de santé (médecins, pharmaciens, etc.) susceptibles alors de les prescrire ou de les vendre à leurs patients. Pour atteindre cet objectif, ils se déplacent régulièrement, soit pour rendre visite aux praticiens avec lesquels ils sont déjà en contact, afin de maintenir leur intérêt pour les produits GSB, soit pour prospecter de nouveaux prescripteurs ou distributeurs potentiels. Leur champ d’action est limité à une zone. Dans le cadre des applications web et mobile présentées ci-dessous, ils sont les « Utilisateurs » (cf. lexique).

De ce fait les visiteurs ont besoins d’avoir plusieurs modules à leurs dispositions :

- Un agenda.

- Consultation des coordonnées.

- Consultation des Médicaments

- Un gestionnaire de compte rendu

4 | P a g e

2) Délégués

Les délégués représentent les supérieurs hiérarchiques au sein de l’entreprise vis-à-vis des visiteurs. Chaque délégué est affecté à une zone et la supervise. Ils ont donc le statut d’administrateur de niveau 2 (cf. lexique).

Les délégués ont accès aux modules suivants :

- Gestion d’agenda pour n’importe quel utilisateur.

- La modification et gestion des comptes-rendus des visiteurs.

- Gestion des coordonnées. 3) Responsables Les responsables sont les supérieurs des délégués. Ils sont affectés à un secteur, qui englobe plusieurs zones, et supervisent l’ensemble des délégués et des visiteurs. Ils ont le statut particulier d’administrateur de niveau 1 (cf. lexique).

Les responsables doivent disposer des modules d’administration suivants :

- Gestion agenda.

- Gestion des frais.

- Gestion des comptes rendus.

- Gestion Coordonnées.

D – Configuration matérielle Tous les visiteurs sont équipés d'une tablette sous Android, fournie par GSB. Cette tablette est paramétrée de sorte à permettre aux visiteurs d'effectuer toutes les tâches liées à leur activité :

- Éditeur de texte. - Feuille de calcul. - Messagerie. - Navigateur web. - Applications décrites ci-dessous.

IV – Contraintes

A – Contraintes financières

Le budget alloué à ce projet est inexistant. Donc aucun frais n’a pu être engagé pour son développement. Seuls les outils et matériels gratuits ou déjà à disposition de l’équipe ont été mis à contribution.

5 | P a g e

B – Contraintes techniques

1) Logiciel

L’application web doit fonctionner aussi bien en local qu’en accès externe sécurisé. L’hébergeur désigné est un serveur distant. Choix de l’hébergeur : OVH.

2) Matériel Pendant tout le processus de développement, chaque membre de l’équipe a travaillé sur son propre ordinateur et utilisé les logiciels de son choix :

• Matériel : PC sous l’OS Windows 10, smartphone Android. • Logiciel: Android Studio, Atom, Sublime Text, Wamp, MySQL Workbench, GennyMotion.

C – Contraintes de temps

1) Composition de l’équipe de développement

L’équipe a été composée définitivement le 01/11/2016. Chacun a réfléchit dans un premier temps au choix des technologie et la gestion du projet (par quoi le projet allait débuter).

2) Contraintes des membres de l’équipe Nous habitons tous les 3 à une certaine distance ce qui rend difficile un travail commun en dehors des horaires prévus en cours. De plus certain membre du groupe travaille le weekend ce qui rend difficile le travail en groupe en dehors des heures de cours.

3) Formation

Etant donné le temps imparti au développement de ce projet, il a fallu choisir les outils de travail en fonction des compétences des membres de l’équipe qui ont évolué à la suite des stages ; l’ensemble de l’équipe possède de solide base en HTML, CSS, PHP, l’un des membres à dû se familiariser avec le langage Java afin de développer le client lourd et ainsi l’adapter aux tablettes de l’entreprise. La combinaison de ces technologies a été définitif à la suite des stages en raison de la monté en compétence de chacun.

4) Date de rendu du projet L’application web et l’application mobile, ainsi que l’ensemble des documents connexes, doivent être mis

à disposition du jury pour le 07/04/2017 avec possibilité de mise à jour des solutions jusqu’en mai.

6 | P a g e

V – Déroulement du projet

A – L'équipe : répartition des tâches

Les grandes orientations du projet ont été décidées de façon commune. Ainsi, les premières étapes du développement ont été discutées et mises en place par les 3 membres de l'équipe, afin d'assurer la cohérence des différentes parties entre elles. Les différentes parties du développement, découlant de la première phase, ont été réparties comme suit :

1) Puiatti Robin développeur Frontend & Backend Web :

• module Agenda (visiteurs), • module Praticiens (responsables).

2) Crespin Loïc développeur Frontend & Backend Mobile :

Application :

- Module Agenda,

- Module Coordonnées,

- Module Médicaments,

- Module Compte rendu,

Document :

- Documentation technique application,

- Présent cahier des charges.

3) Albac Thibault développeur Frontend Web :

Application :

- Réalisation des menus

- Réalisation des formulaires

- Rendu et style de l’application

Document :

- Documentation technique sur l’application web

7 | P a g e

Chaque membre de l’équipe intervient sur différents points entre l’application Web et l’application Mobile. Cette solution permet une bonne répartition des tâches et d’intégrer tous les membres de l’équipe de développement au projet et de comprendre les différentes interactions entre les modules et fonctionnalité contenu au sein des deux solutions.

B- Langages utilisés

Pour le développement du projet différent langage de programmation ont été utilisé en raison de leurs différentes utilisation et besoins de deux solutions différentes à savoir le client lourd et léger. En fonction des différentes méthodes utilisé plusieurs langage son nécessaire afin de gérer d’une part le fonctionnelle et d’une autre part le visuel.

Pour le développement de la partie fonctionnelle de l’application Android, le langage java a été utilisé en raison de son orientation objet et de son utilisation par Google et ce qui permet donc de développer l’application mobile. Son utilisation est obligatoire pour l’utilisation de l’IDE Android Studio. Toute les interactions avec l’interface passent par le Java ainsi que l’utilisation des différentes méthodes.

Pour la partie esthétique, le langage XML ou langage de balisage extensible est le langage au sein d’Android Studio qui permet la mise en place de l’interface comme notamment les boutons d’action, zone de texte, menu etc. Les fichiers XML sont donc les fichiers sources ils restent statiques du début jusqu’à la fin du programme et permettent d’avoir une interface dite responsive qui s’adapte à un grand nombre de support.

8 | P a g e

Langage Web :

PHP est un langage de programmation utilisé pour produire les pages web dynamiques et qui s'intègre dans nos pages HTML. Il permet entre autres de rendre automatiques des tâches répétitives, notamment grâce à la communication avec la base de données (utilisation la plus courante de PHP).

Les principaux langages de programmation web qui nous ont permis à réaliser l’application web, définissent en elles-mêmes l’architecture d’un site. L’HyperText Markup Language est un langage de balisage, afin de structurer les pages. Le Cascading Style Sheet permet de modifier la présentation des éléments HTML (couleurs, tailles, positions, empilement etc..). Quant au JavaScript, c’est un langage qui est lu et exécuté par votre navigateur : le client (donc directement sur votre ordinateur) et qui permet de créer des réactions en réponse à des événements sur la page ou à des actions de l’utilisateur.

L’avantage de ces technologies sont leur capacité de communication entre elles un projet Android s’axe autour de ces deux éléments, le projet en lui-même est axé sur différente classe composé de plusieurs méthodes jouant un rôle déterminé au sein de l’application, exemple certaine son réserver à la communication avec la base de données d’autre à la gestion du cycle d’exécution des tâches comme la mise à jour des événements ainsi qu’à la vérification des identifiants etc. La solution se décompose autour de ses classes et permet donc de répartir la tâche de travail à travers des différents « Threads » afin de ne pas surcharger la Ram ou processeur.

La combinaison de ces éléments permet de développer une solution peut gourmande en ressource et efficace pour les visiteurs qui se trouvent toujours en déplacement.

C – Planning (Gantt)

Cf. annexe

VI – La solution Web

A-Objectif global La solution web doit permettre une gestion totale des modules proposés. Elle doit donc permettre un accès, une utilisation et une administration lié au profil de chaque utilisateur.

B-Connexion La première page de la solution web est une page de connexion. Elle est volontairement simple pour ne pas perdre l’utilisateur dès le début et aussi facilité l’accès direct au site :

• Logo GSB,

• Saisie du login,

• Saisie du mot de passe,

• Bouton de validation.

9 | P a g e

Capture d’écran de la page :

C- L’agenda :

L’agenda permet aux utilisateurs de vérifier les événements qu’ils ont de noté.

D- Les compte-rendu :

10 | P a g e

E- Le module coordonnées :

Le but de ce module pour les visiteurs est de rechercher les informations nécessaire d’un praticien et de l’afficher pour le visiteur.

F- Le module gestion de frais :

La gestion de frais permet aux utilisateurs de réaliser des notes de frais en fonction des différents déplacements professionnels effectués. Le formulaire d’envoi de note de frais est suffisamment poussé pour qu’il ne puisse pas y avoir de fraude. Une fois la note de frais rédigée, elle est envoyée à un administrateur qui doit la vérifier puis la valider ou la refuser.

11 | P a g e

VII – L’application mobile

A-Objectif global L’application mobile se base sur une charte graphique définit pour celle-ci en raison des besoins d’ergonomie spécifique.

Les modules accessibles via l’application mobile sont :

- Gestion d’agenda

- Consultation des coordonnées.

- Gestion de compte rendu.

- Consultation des médicaments.

Il ne s’agit donc que des modules destinés à l’activité des visiteurs, pour des raisons d’optimisation il est logique et important de cibler des fonctionnalités bien précise dans un souci d’utilisation et d’efficacité.

Dans le cas présent l’application fonctionne sur terminal Android dont la plupart des modules fonctionne en local et en ligne. Pour la mémorisation de connexion l’utilisateur peut se reconnecter si et seulement si l’utilisateur s’est connecter au préalable un première fois et à valider l’option de « rappel de mot de passe ».

B-Connexion

L'utilisateur doit s'identifier avec son login et son mot de passe. S'ils existent dans la base de données, l'utilisateur est redirigé, en SESSION sécurisée vers la vue agenda. En fonction du profil de l'utilisateur visiteur ou responsable, les modules accessibles seront différents. L’utilisateur peut cocher la case « se souvenir de moi » afin d’éviter de devoir de nouveau entrer ses identifiants.

12 | P a g e

C- Page d’accueil (Agenda) :

La vue d’accueil se divise comme suit :

- Le Header de navigation permettant d’accéder à deux modules différents à savoir l’ajout d’un nouvel événement et la consultation du calendrier.

- La liste des rendez-vous cliquable afin d’accéder aux détails du rendez-vous et au module de commentaire.

- Un accès à la navigation via le bouton en haut à gauche et ou via un slide depuis le bord gauche au bort droit de l’écran.

- Un menu accessible via un bouton en haut à droite permettant d’accéder à la fonction de « logout » pour permettre de détruire le token de sauvegarde des données et donc de se déconnecter.

13 | P a g e

D- Les modules

1) : Ajout d’événement

La vue d’ajout d’un nouvel événement se divise

comme suit :

- En haut à droite un bouton pour accéder à la fonction de déconnexion de l’application.

- Au centre de la page les champs obligatoires à remplir pour la création du nouvel événement.

- L’utilisateur entre la durée dans lechamp « Durées » et utilise le bouton

rafraichir afin que l’application lui propose

une date et plage horaire par défaut.

- Via le bouton filtre l’utilisateur peut

entrer un filtre pour une plage horaire et

pour une plage de date.

- En bas les boutons permettent de crée ou d’annuler la création du nouvel

événement.

Note : La section « membres » est accessible uniquement depuis un

compte Admin.

14 | P a g e

1) : Détail de l’événement et module de commentaire :

La vue de consultation des détails de l’événement

s’articule comme suit :

- En haut de la page l’utilisateur retrouve les détails relatifs au rendez-vous sélectionné comprenant plusieurs champs.

- Les données sont le jour, l’heure, la durée prévue du rendez-vous, la location ainsi que le descriptif.

- Dans la seconde section du module un champ permettant d’entrer un commentaire et de le publier via le bouton envoyer.

- En dessous le résumé des commentaires posté part un administrateur ou un simple utilisateur permettant d’ajouter des détails ou de converser avec les utilisateurs concernés par cet événement.

- Pour chaque section de commentaire on retrouve l’auteur, l’horodatage du message ainsi que son contenu.

15 | P a g e

3) : Module calendrier :

Cette vue de consultation du calendrier

s’organise comme suit :

- Au sommet de la vue un calendrier dater du jour permettant à l’utilisateur de s’organiser sans devoir quitter l’application.

- Un résumer des événements les plus récents afin de permettre à l’utilisateur de se situer par rapport à la date du jour.

Note : le calendrier en question est un calendrier

Google intégré directement dans l’API d’Android.

Le choix de ne pas enregistrer les rendez-vous à

l’intérieur résulte du fait que cela demande une

externalisation des données via Firebase

appartenant à Google et donc le choix pour

l’entreprise n’a pas paru pertinent.

16 | P a g e

2) : Coordonnées :

La vue de consultation des coordonnées des

praticiens se décompose comme suit :

- Le visiteur entre le nom, le prénom ou l’adresse du praticien pour que l’application lui propose des suggestions en rapport avec le mot entré dans la barre de recherche.

- Si un résultat est sélectionné dans les propositions de recherche l’application vas automatiquement remplir les champs dans la carte de visite en dessous pour permettre à l’utilisateur de consulter les informations.

- Les informations disponibles son conforme à la demande de l’entreprise

à savoir : le nom, prénom, adresse, ville, les numéros de portable et fixe, le coefficient de notoriété allant de 1 à 10 et le lieu d’exercice du praticien.

17 | P a g e

3) : Compte rendu :

La vue de rédaction de compte rendu se

décompose comme suit :

- L’utilisateur danscet onglet rentre les informations

relatives à la création d’un compte rendu suite à une visite. Toute les

informations demandées parl’application doivent être remplit pour tout envoie de compte rendu sur la base de données.

- L’utilisateur choisit un praticien présent dans la liste déroulante afin de le lier au compte rendu ainsi que des échantillons via la liste déroulante de proposition des médicaments et du bouton d’ajout.

- Dans la liste derésumé « vos échantillons »l’utilisateur peut régler la quantité d’échantillon d’un médicament viaune liste déroulante de quantité.

- Les croix rouges sur

chaque élément sont des boutons de

suppression en cas d’erreur de saisie.

18 | P a g e

4) : Médicament :

La vue de consultation des médicaments se

décompose comme suit :

- A l’image de la vue de consultation des

cordonnées l’utilisateur peut chercher un médicament via la barre de recherche par suggestion.

- L’utilisateur à accès à différente

information comme le nom commercial du médicament, la famille, le prix.

- Via les table vue l’utilisateur peut

naviguer entre les différents éléments comme la composition du médicament, les effets indésirables ainsi que les contres indications.

19 | P a g e

VII – Modélisation :

A- Modèle Conceptuel des Données

Le modèle ici représente l’entièreté de la base de données actuelle. Ce modèle risque de potentiellement évoluer jusqu’à la fin du développement. La base de données gère les différents

praticiens, utilisateur, droit d’accès, compte rendu, médicament, commentaire et agenda.

20 | P a g e

VII – Bilan

Application mobile :

- Module Agenda fonctionnel.

- Module d’ajout fonctionnel.

- Module de consultation des praticiens et médicament fonctionnel.

- Module compte rendu fonctionnel.

Site web :

- Module Agenda fonctionnel.

- Module d’ajout fonctionnel.

- Module de consultation des praticiens.

B- Amélioration possible

Application mobile :

- Ajout d’une fonctionnalité de contact et de navigation au module de consultation des coordonnées praticiens.

- Suppression des événements.

- Suppression d’un médicament.

Site web :

- Résolution de bug lié à l’agenda.

- Ajout des niveaux de connexions.

- Demande de location de véhicule.

21 | P a g e

A- Avancement du projet

X- Annexes :

A – Gantt du Projet

22 | P a g e