BTS Services informatiques aux organisations Session 2019

E4 – Conception et maintenance de solutionsCoefficient 4

DESCRIPTION D’UNE SITUATION PROFESSIONNELLE

Épreuve ponctuelle: Parcours SLAM

NOM et prénom du candidat : TRAN Christophe N° de candidat : M326110102

Structure de la situation professionnelle : Contexte GSB

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

Période de réalisation : 10/07/2018 au 05/06/2018 Lieu : Lyon

Modalité : Seul

Domaine de compétence : D1.1 - Analyse de la demande D1.2 – Choix d’une solutionD1.3 – Mise en production d’un service D1.4 - Travail en mode projetD2.1 - Exploitation des servicesD4.1 – Conception et réalisation d’une solution applicative D4.2 - Maintenance d’une solution applicativeD5.2 – Gestion des compétences

Productions associées Cahier des charges numérique :MCD :

Modalités d’accès aux productions

URL du site web : https://tranchristophe.wordpress.com

1 | P a g e

GSB – Galaxy Swiss BourdinCahier des charges et Spécifications fonctionnelles

TRAN Christophe

2016 – 2019

2 | 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

3 | 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

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 Sous le framework Ionic.

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

4 | 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 attentesGSB 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) VisiteursLes 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 :

- Consultation des coordonnées (Practiciens)

- Consultation des Médicaments

- Un gestionnaire de compte rendu

5 | 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 :

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

- Gestion des coordonnées.

3)ResponsablesLes 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 des frais.

- Gestion des comptes rendus.

- Gestion Coordonnées.

D – Configuration matérielleTous les visiteurs sont équipés d'une tablette sous Android ou IOS, 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.

6 | 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érielPendant 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 IOS.

• Logiciel: Atom, Sublime Text, Wamp, MySQL Workbench, Ionic

C – Contraintes de temps

1) Composition pour le développement

L’application Mobile/Web a été réaliser par un développeur.

2) FormationEtant donné le temps imparti au développement de ce projet, il a fallu choisir les outils de travail en fonction des compétences qui ont évolué à la suite des stages. Je possède de solide base en HTML, CSS, PHP. J’ai dû me familiariser avec le Framework Ionic afin de développer l’application mobile et ainsi l’adapter aux tablettes de l’entreprise.

3) Date de rendu du projetL’application web et l’application mobile, ainsi que l’ensemble des documents connexes, doivent être mis à disposition du jury pour le 24/05/2019 avec possibilité de mise à jour des solutions jusqu’en Juin.

7 | P a g e

V– Déroulement du projet

A –répartition des tâches

1) Tran Christophe développeur Frontend & Backend Web/Mobile :

• Module Coordonnées,

• Module Médicaments,

• Module Compte rendu,• Réalisation des menus

• Réalisation des formulaires

• Rendu et style de l’application

Document:

- Documentation technique application,

- Présent cahier des charges.

- Documentation technique sur l’application web

8 | P a g e

En tant que développeur j’interviens sur différents points entre l’application Web et l’application Mobile. Cette solution permet une bonne répartition des tâches 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.

Le FrameworkIonic sera utilisé pour tout la création de l’application Mobile il utilise plusieurs langages de développement :

- Pour le développement de la partie fonctionnelle de l’application Mobile, le langage Angula a été utilisé car nous utilisons IONIC pour développer une application mobile Multi-plateforme.

- Apache Cordova ou plus anciennement Apache Callback ou Phone Gap, est un Framework open-source développé par la Fondation Apache. Il permet de créer des applications pour différentes plateformes en HTML, CSS et JavaScript.

De plus l’application Mobile Utilise aussi les mêmes langages que l’application WEB ci-dessous

9 | 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.

VI– La solution Web

A-Objectif globalLa solution web doit permettre une gestion totale des modules proposés. Elle doit donc permettre un accès, une utilisation par utilisateur.

B-C onnexionLa 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.

10 | 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 :

11 | 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.

Les images Ci-dessus représenter des maquettes des vue du site web car le visuel du site est encore en developpement

12 | P a g e

VII – L’application mobileA-O bjectif globalL’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 :

- 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/IOS/Windows phone.

B-C onnexion

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 accueil. En fonction du profil de l'utilisateur visiteur ou responsable, les modules accessibles seront différents.

13 | P a g e

C- Page d’accueil:

La vue d’accueil se divise comme suit :

-Petit bouton déconnexion pour permettre à l’utilisateur de se déconnecté

-Logo et message de bienvenue sur la page d’accueil

- .

-Menu avec les differents onglets de navigation (exemple la l’onglet liste des

Medicaments)

14 | P a g e

D- Les modules

1) : Ajout Medicaments (l’image ne représente pas vraiment l’application, elle représente juste une maquette de ce que peut ressembler la vue)

La vue d’ajout d’un médicament qui se divise comme la façon suivante :

En haut à gauche un bouton pour accéder au menus de l’application.

-Au centre de la page les champs obligatoires à remplir pour la création d’un médicament.

-L’utilisateur remplie les champs et utiliser le bouton valider afin que l’application puisse enregistrer

-Vous avez la méthode Ajouter/Supprimer disponible directement en cliquant sur un produit/médicament

15 | P a g e

déjà créer.

2) : Détail du module Coordonnées Praticiens : (l’image ne représente pas vraimentL’application elle représente juste une maquette de ce que peut ressembler la vue)

En haut à gauche un bouton pour accéder au menus de l’application.

-Au centre de la page les champs obligatoires à remplir pour la création des coordonnées d’un praticien.

-L’utilisateur remplie les champs et utiliser le bouton valider afin que l’application puisse enregistrer

16 | P a g e

Le visiteur entre le nom, le prénom ou l’adresse du praticien.

Les informations disponibles son conforme à la demande de l’entreprise à savoir : le nom, prénom, adresse, ville.

3: Compte rendu : (l’image ne représente pas vraiment l’application , elle représente juste une maquette de ce que peut ressembler la vue)

17 | P a g e

La vue de rédaction de compte rendu se décompose comme suit :

L’utilisateur dans cet onglet rentre les informations Relatives À la création d’un compte rendu suite à une visite. Toutes les informations demandées par l’application doivent être remplit pour tout envoie de compte rendu sur la base de données.

L’utilisateur choisit un praticien présent ainsi que des échantillons.

Les croix rouges sur chaque élément sont des boutons de suppression en cas d’erreur de saisie

18 | 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, compte rendu, médicament, commentaire.

19 | P a g e

VII – Bilan

A- Avancement du projet

Application mobile:

- Module d’ajout/supprimer fonctionnel.

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

- Module compte rendu fonctionnel.

Site web:

- Module Agenda fonctionnel.

- Module d’ajout/suppression/modifier fonctionnel.

- Module de consultation des praticiens.

B- Amélioration possible

Application mobile :

- Suppression d’un medicament/practiciens.

Site web :

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

- CRUD (Create/Read/Update/Delet

20 | P a g e

22 | P a g e