Développement d'une application mobile métier: cas de l'application de gestion commerciale de Togo 3000 informatique

MINISTERE DE L'ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE

REPUBLIQUE TOGOLAISE TRAVAI-LIBERTE-PATRIE

Master International

en Informatique

Université de Lomé/

CIC

Centre Informatique et de Calcul(CIC)

01 BP 1515 Lomé 01 - Togo/ Tél : [phone]/Fax : [phone]

Adresse : Rue de Leupe, 90400 Sevenans, France

Telephone: [phone]

i

Lieu de recherche : TOGO 3000 INFORMATIQUE

N° Matricule : 467148

Mémoire pour l'obtention du diplôme de Master II en

Informatique, Spécialité Génie Logiciel ;

Présenté et soutenu publiquement

Le 13 Novembre 2019

Par

KASSANKOGNO Essowiyaou

Développement d'une application mobile métier :

Cas de l'application de gestion commerciale de TOGO 3000 INFORMATIQUE

Composition du jury :

Président : ATCHONOUGLO Kossi

Examinateur : ABOLO-SEWOVI Romain

SUPERVISEUR MAÎTRE DE STAGE

M. Sid Ahmed LAMROUS M. Justin ADJOGBLE

Maître de conférences en Informaticien à TOGO 3000

Informatique ; INFORMATIQUE

Responsable du Master conjoint en Informatique, UL / UTBM

Promotion 2017-2019

ii

DEDICACE

A ma très chère maman, qui a veillé durant mes nuits pour faire la réussite de mes jours.

A mon cher défunt papa, qui m'a poussé et motivé dans mes études et à qui je dois ma place maintenant pour ses sacrifices.

A mon cher oncle KASSANKOGNO Yao qui m'a beaucoup soutenu, conseillé et encouragé. A tous mes frères et soeur, qui m'ont beaucoup soutenu tout au long de mes études.

Que ce travail soit l'accomplissement de vos voeux tant, et le fuit de votre soutien infaillible, Merci d'être toujours là pour moi.

iii

REMERCIEMENTS

REMERCIEMENTS

Je tiens avant tout à remercier notre Bon Dieu tout Puissant de m'avoir donné le courage, la force et la volonté pour achever ce modeste travail.

Je remercie :

Monsieur ATCHONOUGLO Kossi, Maître de Conférences, Directeur Général du

Centre Informatique et de Calcul (CIC), pour le cadre d'études qu'il nous a offert et pour tous les efforts entrepris pour nous offrir de bonnes conditions d'études ;

Monsieur Sid LAMROUS, Maître de Conférences à l'UTBM, Co-Responsable de la formation Master Informatique à UTBM ; pour son encadrement, ses remarques et critiques, son attachement à la perfection, qui a contribué à la réussite de ce travail.

Monsieur BOROZE Tchamye Tcha-Esso, Maître Assistant, Directeur adjoint du Centre Informatique et de Calcul (CIC) ;

Monsieur AGBETI Kodjo Constant, Ingénieur Informaticien, Directeur Général du CENETI et Représentant Résident de l'IAI-TOGO ;

Mr ABIGUIME Pétik-abalo Directeur Général de TOGO 3000 INFORMATIQUE de m'avoir accueilli dans son entreprise pour la réalisation de ce travail, ainsi que tout le personnel de l'entreprise pour leur accueil et leur soutien ;

Mr ADJOGBLE Komlavi Mawuli, mon maître de stage, pour son aide et sa disponibilité

Et enfin,

Je tiens à remercier toutes les personnes qui ont contribué de près ou de loin à l'accomplissement de ce travail

iv

RESUME

RESUME

L'évolution des besoins des entreprises nécessite énormément d'efforts quant à la conception et à la réalisation des systèmes d'information modernes. Cette évolution des besoins demande une prise en charge des paramètres spécifiques lors de la conception des systèmes devant répondre à des besoins spécifiques. Ainsi, le développement des applications devant satisfaire les besoins d'une entreprise, qui généralement évoluent dans le temps devrait se faire suivant un processus projet qui s'adapte aux changements.

Le thème de notre étude est : « Développement d'une application mobile métier : cas de l'application de gestion commerciale de TOGO 3000 INFORMATIQUE »

L'objectif de cette étude est d'analyser le système d'information du département commercial de TOGO 3000 INFORMATIQUE et réaliser une application mobile professionnelle, destinée à la gestion de son activité commerciale, suivant un processus garantissant le succès du projet. Le processus de réalisation de cette application doit en effet s'adapter aux exigences organisationnelles et aux contraintes du projet.

Nous utilisons le processus unifié 2TUP¹ pour la gestion du cycle projet tout en adoptant la méthode agile SCRUM² spécifiquement pour la phase de réalisation. Le principe fondamental de la méthode agile SCRUM est l'implication du client de bout en bout dans le processus de création ; Il devient important d'adapter l'analyse préalablement faite suivant le processus 2TUP et tenir compte de l'évolution des besoins du client.

Mots clés : métier, processus, 2TUP, SCRUM

¹ 2TUP (2 track unified process, prononcez "toutiyoupi") est un processus de développement logiciel qui implémente le Processus Unifié. Le 2TUP propose un cycle de développement en Y, qui dissocie les aspects techniques des aspects fonctionnels

²Scrum : Framework lié aux méthodes agiles de gestion de projet, utilisées notamment en développement logiciel

RESUME

ABSTRACT

The changing needs of companies require a great deal of effort in the design and implementation of modern information systems. These changing needs require support for specific parameters when designing systems to meet specific needs. Thus, the development of applications to meet the needs of a business, which generally evolve over time should be done following a project process that adapts to changes.

The theme of our study is: "BUSINESS MOBILE APPLICATION DEVELOPMENT: CASE OF TOGO 3000 INFORMATIQUE BUSINESS MANAGEMENT APPLICATION" The objective of this study is to analyze the information system of the commercial department of TOGO 3000 INFORMATIQUE and to realize a professional mobile application, intended for the management of its commercial activity, following a process guaranteeing the success of the project. The realization process of this application must indeed adapt to the organizational requirements and constraints of the project.

We use the unified 2TUP process for project cycle management while adopting the agile SCRUM method specifically for the implementation phase. The fundamental principle of the SCRUM agile method is end-to-end customer engagement in the creative process; It becomes important to adapt the analysis previously made according to the 2TUP process and to take into account the evolution of the needs of the client.

v

Keywords: business, process, 2TUP, SCRUM

vi

TABLE DES MATIERES

TABLE DES MATIERES

DEDICACE ii

REMERCIEMENTS iii

RESUME iv

ABSTRACT v

TABLE DES MATIERES vi

LISTE DES TABLEAUX viii

LISTE DES FIGURES ix

CHRONOGRAMME x

GLOSSAIRE xi

INTRODUCTION GENERALE 1

CONTEXTE ET ETUDE DU PROJET 3

1. Contexte du projet 3

1.1. Présentation du centre de formation 3

1.2. PRESENTATION DU CENTRE D'ACCUEIL 4

1.3. LES ACTEURS DU PROJET 5

2. ÉTUDE DU PROJET 6

2.1. OBJECTIF DE L'ETUDE 6

2.2. ÉTUDE ET CRITIQUE DE L'EXISTANT 6

2.3. PROPOSITIONS ET CHOIX DE SOLUTION 10

3. CONCLUSION 16

ANALYSE ET CONCEPTION 17

1. PRESENTATION DE LA METHODE D'ANALYSE 17

1.1. Présentation du langage UML 17

1.2. Présentation du processus 2TUP 18

1.3. Présentation du processus SCRUM 18

2. PRESENTATION DE L'OUTIL DE MODELISATION 19

2.1. Qu'est-ce que PowerAMC ? 19

2.2. Quels sont les atouts de PowerAMC ? 19

3. ÉTUDE DÉTAILLÉE DE LA SOLUTION 20

3.1. Étude fonctionnelle 20

3.2. Étude technique 37

4. CONCLUSION 43

REALISATION ET MISE EN OEUVRE 44

1. MISE EN OEUVRE 44

1.1. Choix matériels 44

1.2. Choix logiciels 44

vii

TABLE DES MATIERES

1.3. Sécurité de l'application 48

1.4. Architecture physique de l'application 50

1.5. Gestion des tests 50

1.6. Rapport de réalisation 51

2. PRESENTATION DE L'APPLICATION 57

2.1. Présentation 57

2.2. Structure de l'application 59

3. GUIDE D'EXPLOITATION 60

3.1. Configuration matérielle et logicielle 60

3.2. Déploiement et suivi 60

4. GUIDE D'UTILISATION 62

4.1. Présentation de l'application 63

4.2. Maintenance 67

5. CONCLUSION 68

CONCLUSION GENERALE 69

REFERENCES BIBLIOGRAPHIQUES 70

ANNEXES 71

Annexe 1 : Coordonnées du centre d'accueil 71

Annexe 2 : Gestion des anomalies 72

viii

LISTE DES TABLEAUX

LISTE DES TABLEAUX

Tableau 1 : Chronogramme x

Tableau 2 : définition des sigles xi

Tableau 3: Tableau des participants au projet 5

Tableau 4: Représentation de la durée d'établissement des documents 9

Tableau 5: Représentation du temps de recherche 9

Tableau 6: Le coût matériel 12

Tableau 7: Tableau du coût de conception 12

Tableau 8: coût de déploiement 12

Tableau 9: Tableau du coût de formation 13

Tableau 10: Tableau du coût total 13

Tableau 11: Planning prévisionnel 14

Tableau 12: liste des cas d'utilisation du système 20

Tableau 13: Cas d'utilisation techniques 38

Tableau 14: avantages et inconvenients de chaque plateforme mobile 47

Tableau 15 : participants à la phase de réalisation 52

Tableau 16: Rapport SPRINT 1 53

Tableau 17: Rapport SPRINT 2 54

Tableau 18: Rapport SPRINT 3 55

Tableau 19: Rapport SPRINT 4 56

Tableau 20: Rapport SPRINT 5 57

Tableau 21 : menus, boutons et champs 65

Tableau 22: description des erreurs courantes et les actions à mener 68

Tableau 23: anomalies, signification et niveau de graveté 72

Tableau 24: fréquence d'apparition de problème en niveau 72

Tableau 25: gestion des anomalies (tableau AMDEC) 73

ix

LISTE DES FIGURES

LISTE DES FIGURES

Figure 1: organigramme de TOGO 3000 INFORMATIQUE 5

Figure 2: diagramme de GANTT du planning de réalisation 15

Figure 3: processus de développement 2TUP 18

Figure 4 : diagramme de cas d'utilisation 21

Figure 5: Diagramme de classe gestion des utilisateurs 26

Figure 6: diagramme de classe gestion des caution 27

Figure 7:diagramme de classe gestion achats et ventes 28

Figure 8: Diagramme de séquence du cas d'utilisation « ajouter un utilisateur » 29

Figure 9: Diagramme de séquence du cas d'utilisation « éditer un profil » 30

Figure 10: Diagramme de sequence du cas d'utilisation « s'authentifier » 30

Figure 11: Diagramme de séquence du cas d'utilisation « demander une cotation » 31

Figure 12: Diagramme de séquence du cas d'utilisation « commander un produit » 32

Figure 13: Diagramme de séquence du cas d'utilisation « gérer une facture fournisseur » 33

Figure 14: Diagramme de séquence du cas d'utilisation « Gérer une reception » 33

Figure 15: Diagramme de séquence du cas d'utilisation « gérer un devis client » 34

Figure 16: Diagramme de séquence du cas d'utilisation « gérer une commande client » 35

Figure 17: Diagramme de séquence du cas d'utilisation « gérer une facture client » 36

Figure 18: Diagramme de séquence du cas d'utilisation « livrer une marchandise » 36

Figure 19: Diagramme de sequence du cas d'utilisation « Gérer article » 37

Figure 20: Architecture en cinq couches 39

Figure 21: Modèle logique de conception 40

Figure 22: Noyau de présentation 40

Figure 23 : Le noyau de sécurité 41

Figure 24:Diagramme de déploiement 42

Figure 25: diagramme de composants 42

Figure 26: Architecture physique de l'application 50

Figure 27: structure de l'application 59

Figure 28: 1.1 Interface de connexion et d'accueil 63

Figure 29: architecture de navigation de l'application 66

Figure 30:plan de localisation de TOGO 3000 INFORMATIQUE 71

x

CHRONOGRAMME

CHRONOGRAMME

TÂCHE DEBUT DUREE FIN

PROJET GESTION COMMERCIALE TOGO 3000			15/04/19	132	15/10/19
	PRISE DE CONTACT ET CADRAGE DU PROJET		15/04/19	11	29/04/219
	ELABORATION DU CAHIER DES CHARGES		30/04/19	5	06/05/19
	PHASE D'ANALYSE ET MODELISATION		07/05/19	28	13/06/19
	PHASE DE REALISATION ET DEPLOIEMENT		14/06/19	88	15/10/19
		REALISATION	14/06/19	71	20/09/19
		DEPLOIEMENT	23/09/19	13	09/10/19
	FORMATION DES UTILISATEURS		03/10/19	5	09/10/19
	SUIVI		10/10/19	4	15/10/19

Tableau 1 : Chronogramme

xi

GLOSSAIRE

GLOSSAIRE

Sigle	Définition
2TUP	Two Track Unified Process
CIC	Centre Informatique et de Calcul
GL	Génie Logiciel
IAI	Institut Africain d'Informatique
MERISE	Méthode d'Etude et de Réalisation Informatique pour les Systèmes d'Entreprise
NTIC	Nouvelles Technologies de l'Information et de la Communication
SI	Système d'Information
SR	Systèmes et Réseaux
UP	Unified Process
UML	Unified Modeling Language
UTBM	Université de Technologie Belford-Monbéliard
XML	eXtensible Markup Language

Tableau 2 : définition des sigles

1

INTRODUCTION GENERALE

INTRODUCTION GENERALE

Les plus grands défis pour une entreprise sont la recherche d'une plus grande efficacité, la réduction des coûts et l'innovation, entre autres les points qui pourraient déboucher sur une croissance. Afin de relever ce challenge, on assiste de plus en plus à l'intégration des NTIC (Nouvelles Technologies de l'Information et de la Communication) dans les systèmes de gestion des entreprises. De nos jours, presque toutes les entreprises les utilisent et TOGO 3000 INFORMATIQUE, une entreprise spécialisée dans les NTIC n'en fait pas l'exception. L'essor de nouvelles techniques numériques provoquent une révolution technologique entraînant de profonds bouleversements dans ce domaine. Les « smartphones » plus mobiles et plus pratiques dans certaines situations sont de plus en plus utilisés que les ordinateurs. Une inversion totale des tendances par rapport aux années précédentes, qui témoigne de l'élan de la téléphonie mobile au détriment des PC (ordinateurs portables).

TOGO 3000 INFORMATIQUE se fixant comme objectif la saisie des opportunités offertes par les NTIC pour une amélioration continue des relations clients et pour une efficacité des opérations commerciales initie un projet ayant pour thème « Développement d'une application mobile métier : cas de l'application de gestion commerciale de TOGO 3000 INFORMATIQUE ». Un projet qui a fait l'objet de mon stage au sein de l'entreprise du 15 Avril au 15 Octobre 2019.

La réalisation de ce projet a permis de mettre en évidence sur le plan opérationnel la nécessité d'adapter un processus aux exigences organisationnelles et aux contraintes du projet. Un projet peut commencer par un processus classique, qui permet de définir le projet dans sa globalité, mais il se fait que face à un certain nombre de contraintes et d'évolution des besoins, un projet classique peut paraître trop rigide pour mener à terme le projet avec succès.

Mohamed Salah Benselim dans sa thèse soutenue en 2009 sous le thème « Une approche pour le développement d'application sensibles au contexte », propose une nouvelle démarche de développement qui permet de prendre en compte les changements perpétuels de la situation courante d'un utilisateur de systèmes logiciels. Selon son étude les systèmes d'information ubiquitaires³ doivent présenter un caractère sensible au contexte et nécessitent, par conséquent, la prise en considération des variations du contexte d'utilisation d'une situation à une autre. C'est-à-dire que ces systèmes doivent, selon le contexte de chaque situation d'exécution, fournir l'information correspondante. Pour l'utilisateur, cette information correspondante signifie qu'elle soit ajustée, adaptée et personnalisée suivant ses souhaits préférés comme le nombre, le contenu, la présentation, etc. D'où, l'utilité de faire

³ D'après le Wikipédia, l'informatique ubiquitaire est la troisième ère de l'histoire de l'informatique, qui succède à l'ère des ordinateurs personnels et celle des ordinateurs centraux. Dans cette ère, l'utilisateur a à sa disposition une gamme de petits appareils informatiques tels que le téléphone multifonction ou l'assistant personnel, et leur utilisation fait partie de sa vie quotidienne.

2

INTRODUCTION GENERALE

appel aux processus d'adaptation et de personnalisation pour augmenter et améliorer l'application et la performance des systèmes d'information ubiquitaires. ⁴

La mise en pratique des connaissances acquises dans l'analyse et le développement en plus des recherches effectuées sur les nouvelles méthodes de recherche, de conception (objets) et de gestion de projets (2TUP et Agile) nous ont permis d'aboutir à la réalisation de notre étude. L'application issue de ce projet telle que conçue dans sa version actuelle sera un indicateur de gestion permettant de maîtriser l'activité et la relation client du département commercial de TOGO 3000 INFORMATIQUE.

Ce document a pour objet de fournir un rapport détaillé sur les étapes suivis pour la réalisation du projet. Il se subdivise en trois chapitres. Dans un premier chapitre, nous ferons une étude de l'existant ; ensuite nous examinerons dans un deuxième chapitre le projet en détails à travers une analyse aboutissant à sa réalisation dans un troisième chapitre.

⁴ http://dspace.univ-

guelma.dz:8080/xmlui/bitstream/handle/123456789/440/MEMOIRE%20BENSELIM%20JUILLET2009.pdf ?sequence=1&isAllowed=y

3

CONTEXTE ET ETUDE

Chapitre1

CONTEXTE ET ETUDE DU PROJET

Ce chapitre a pour objectif de situé le projet dans son contexte général. Il se subdivise en deux parties. Dans un premier temps nous allons présenter le cadre d'étude et le centre d'accueil pour l'étude ; ensuite nous passerons à l'étude du projet. A travers l'étude du projet, nous présenterons l'objectif de l'étude suivi de l'étude de l'existant et la solution à mettre en oeuvre pour répondre aux problèmes identifiés.

1. Contexte du projet

1.1. Présentation du centre de formation 1.1.1. Présentation du CIC-UL

Le Centre Informatique et de Calcul (CIC) est un établissement et un centre de ressources de l'Université de Lomé créés par arrêté N°67/MENRS du 26 Septembre 1988 pour apporter un appui logistique en informatique aux établissements et à l'administration de l'Université de Lomé et pour former des cadres supérieurs en informatiques. Dans le cadre de la formation, le Centre Informatique et de Calcul offre, dans le domaine des Sciences et

Technologie (ST), deux (2) parcours au grade Licence à savoir :

v Licence Professionnelle Informatique, Spécialité Génie Logiciel

v Licence Professionnelle Informatique, Spécialité Maintenance et Réseaux Informatiques.

Le CIC offre également en collaboration avec l'Université de Technologie de Belfort-Montbéliard (UTBM) de France, une formation de Master Informatique dans deux options :

v Master Informatique, Spécialité Génie Logiciel ;

v Master Informatique, Spécialité Systèmes et Réseaux.

1.1.2. Présentation de l'UTBM

Créée en 1999, l'UTBM est un établissement public à caractère scientifique, culturel et professionnel. Membre du réseau des universités de technologie, elle est née du regroupement de deux établissements d'enseignement supérieur : l'Ecole Nationale d'Ingénieurs de Belfort (1962) et l'Institut Polytechnique de Sevenans (antenne de l'UTC implantée à Sevenans en 1985). L'Université de Technologie Belfort-Montbéliard forme des ingénieurs rapidement opérationnels, particulièrement adaptables aux évolutions de la technologie et aux mutations de la société. Ses formations s'appuient sur les activités de recherche et sur la valorisation.

4

CONTEXTE ET ETUDE

L'UTBM est habilitée par le ministère de l'Enseignement supérieur et de la Recherche

après l'avis de la commission des titres d'ingénieur ⁵pour délivrer les diplômes d'ingénieur

suivants dans les spécialités suivantes :

+ Spécialité automatique, électronique et informatique industrielle

+ Spécialité informatique

+ Spécialité mécanique

+ Spécialité systèmes de production

+ Spécialité mécanique, design et ergonomie

+ Spécialité génie électrique

+ Spécialité logistique industrielle

+ Spécialité systèmes d'information

Spécialité conception mécanique en formation par apprentissage et en partenariat avec

l'ITII (Instituts des Techniques d'Ingénieur de l'Industrie) de Franche-Comté.

1.2. PRESENTATION DU CENTRE D'ACCUEIL

TOGO 3000 INFORMATIQUE est une société togolaise spécialisée dans les prestations de services informatiques pour PMI/PME et grandes entreprises qu'elles soient du secteur public ou privé. Elle a été créée le 5 Novembre 1996 sous la forme juridique d'un établissement et transformée en SARL le 17 Septembre 2009. C'est une société Togolaise à capital entièrement togolais qui s'est entouré de partenaires étrangers (France et zone UEMOA) lui permettant ainsi d'être au contact des nouvelles technologies dans un domaine très évolutif.

TOGO3000 INFORMATIQUE (adresses en annexes) couvre quatre principaux domaines d'activités toutes tournées vers les technologies de l'information et de la communication. + Conseil & Consultance en système d'information (Audit & Conseil Informatique, Gestion et suivi des projets, Conduite du changement, Placement du personnel en régie)

+ Ingénierie Informatique (Conception et Développement de logiciels, Conception et réalisation des sites web, Conception et mise en place d'une GED, Câblage réseaux et télécommunications)

+ Formation (Oracle 10g, 11g : DBA, Développeurs, Bureautique avancée : Word, Excel, PowerPoint, Publisher, Logiciels de comptabilité : Saari, Perfecto)

+ Autres services (Distribution de matériels informatiques et bureautiques, Maintenance des équipements informatiques et bureautiques)

5 En France, la commission des titres d'ingénieur (CTI) a été créée par la loi du 10 juillet 1934 relative aux conditions de délivrance et à l'usage du titre d'ingénieur diplômé.

CONTEXTE ET ETUDE

5

Figure 1: organigramme de TOGO 3000 INFORMATIQUE

1.3. LES ACTEURS DU PROJET

Le tableau suivant présente les différentes personnes ayant participé à l'élaboration du projet.

Nom et prénom	Fonctions		Rôles	KASSSANKOGNO Essowiyaou
Étudiant master II Génie Logiciel	Analyste programmeur		M. ADJOGBLE Komlavi Mawuli
Informaticien à TOGO 3000 Informatique	Maître de stage		M. Sid Ahmed LAMROUS
Enseignant au Master CIC/UTM	Directeur de mémoire		M. ABIGUIME Pétik-abalo
Directeur Général de TOGO 3000 INFORMATIQUE	Client		Mme DAMADO Djigbodi Pascaline
Directrice de l'administration et Chef service commercial	Utilisateur

Tableau 3: Tableau des participants au projet

6

CONTEXTE ET ETUDE

2. ÉTUDE DU PROJET

2.1. OBJECTIF DE L'ETUDE 2.1.1. Objectif général

L'objectif de cette étude est de garantir le succès du projet de développement de l'application mobile de gestion de l'activité commerciale de TOGO 3000 INFORMATIQUE qui répond aux besoins spécifiques de l'entreprise tout en tenant compte de l'évolution des besoins du client tout au long du projet,des exigences organisationnelles et des contraintes techniques du projet.

2.1.2. Objectifs spécifiques

Déployer un processus flexible permettant de prendre en compte l'évolution des besoins

du client tout au long du projet. Les besoins initiaux du client étant de réaliser une application

mobile permettant de :

+ Stocker de façon cohérente, fiable et sécurisée toutes les informations relatives à la

gestion commerciale de TOGO 3000 INFORMATIQUE ;

+ Assurer l'accessibilité des informations liées à son activité commerciale en temps

réel ;

+ Gérer l'accès aux différentes informations liées à la gestion commerciale par la mise

en oeuvre d'un système de gestion des identités et des habilitations ;

+ Éviter la répétition de certaines tâches et des erreurs liées au traitement manuel des

données ;

+ Générer automatiquement des états lies à la gestion commerciale ;

+ Assurer la traçabilité de toutes les actions utilisateurs.

+ Alerter sur les évènements urgentes

+ Planifier, suivre et évaluer les différentes tâches commerciales ;

2.1.3. Pertinence du sujet

La mise en oeuvre d'un processus adapté dans le cadre du projet de développement de l'application mobile de gestion commerciale de TOGO 3000 INFORMATIQUE a permis de produire un logiciel sur mesure tout en respectant les exigences organisationnelles et les contraintes techniques du projet.

Les résultats obtenus, peuvent dans un contexte général, faciliter la qualification des processus de développement des logiciels métier de qualité et qui répondent aux attentes du client.

2.2. ÉTUDE ET CRITIQUE DE L'EXISTANT

2.2.1. Etude de l'existant

Cette étape est indispensable dans tout projet informatique. En effet une bonne conception doit reposer sur une connaissance du système existant, qui constitue la base de l'étude du projet ;

7

CONTEXTE ET ETUDE

a) Présentation des processus de gestion ? Gestion des relations

Les principales relations de l'entreprise sont classées en trois catégories : les prospects, les clients et les fournisseurs.

Les prospects sont des personnes qui n'ont pas encore signé d'accord avec l'entreprise et que l'entreprise présente ses produits ou services. Une fois que le prospect signe un accord avec l'entreprise il devient client.

Les fournisseurs sont des personnes chez qui l'entreprise achète ses produits ou qui offrent à l'entreprise leurs services.

Toutes les informations relatives à un partenaire sont enregistrées sur une fiche qui est classée en fonction du type de partenaire dans le dossier correspondant.

Dès qu'un client contacte l'entreprise ou se présente, sa fiche est recherchée dans le classeur correspondant. Dès que l'entreprise a besoin des services d'un fournisseur, ses coordonnées sont cherchées dans un carnet d'adresse dans le but de le contacter.

? Gestion des achats

Les acteurs principaux dans le processus de gestion des achats sont le fournisseur, le service commercial et le gestionnaire de stock.

L'événement déclencheur du processus est la rupture du stock ou le besoin d'un service. Le responsable commercial envoie une demande de cotation auprès du fournisseur, le fournisseur répond par une facture pro-forma. Le commercial valide la facture pro-forma puis passe une commande auprès du fournisseur. Une fois la commande reçue, le fournisseur élabore une facture qu'il renvoie à l'entreprise. Dès la réception de la facture, elle est soumise au chef service commercial pour être validée. Après la validation de la facture, le service commercial débourse les fonds pour le règlement de la facture via la comptabilité. Une fois la facture réglée, le fournisseur livre la marchandise qui est reçue par le gestionnaire de stock. Il arrive que les frais de livraison ne soient pas pris en charge par le fournisseur et sont donc intégrées à la facture.

Concernant les fournisseurs étrangers, il y'a aussi les taxes de douane qui s'appliquent sur la marchandise.

? Gestion des ventes

Les acteurs principaux dans le processus de gestion des ventes sont le client et le service commercial. L'événement déclencheur de ce processus est la réception d'une commande ou d'une demande de devis de la part d'un client. Dès la réception de la requête, s'il s'agit d'une demande de devis, le devis est élaboré puis envoyé au client. Le bon pour accord du client fait l'objet d'une commande. Dès la réception de la commande le service commercial facture la commande. Aussi dès le règlement de la facture par le client, le service commercial demande au gestionnaire de stock d'exécuter la livraison. Après la livraison, un reçu est émis au client.

8

CONTEXTE ET ETUDE

? Gestion des cautions bancaires

Une caution bancaire est un contrat stipulant qu'un organisme financier se porte caution pour l'un de ses clients et qu'il se substituera à lui, en cas de défaillance (ou d'impossibilité) de payement.

Lorsque l'entreprise gagne un marché, elle fait une demande de caution auprès de sa banque. En cas de remboursement anticipé de la caution, l'entreprise n'aura pas à payer des frais de mainlevée qui représentent un taux donné du capital restant dû. Normalement à la fin des travaux, le prestataire retourne le document de garanti (caution) à l'entreprise qui doit être ramené à la banque.

b) L'étude des postes de travail

Il s'agit d'une étude qui va nous permettre d'identifier les missions de chaque poste de travail dans les processus de gestion commerciale, de représenter la charge informationnelle de chaque poste, de mettre en évidence les circuits d'informations entre les postes et de détecter les principaux dysfonctionnements. Nous avons recensé les postes de travail suivants : Commercial et gestionnaire de stock.

? Poste de travail : Commercial

Moyens utilisés : Téléphone, fax, ordinateur, calculatrice, imprimante

Responsabilité : Gestion des achats et des ventes

Tâches à accomplir :

+ Demande de cotation auprès des fournisseurs ;

+ Envoi des commandes d'achat ;

+ Effectuer des règlements de factures fournisseur,

+ S'assurer de la réception des produits commandés ;

+ Envoyer des facture-proforma aux clients ;

+ Recevoir et gérer les commandes des clients ;

+ Gérer la facturation des clients ;

+ Gérer les paiements et acomptes ;

+ Validation des bons de commandes d'achat de marchandise et du décaissement des

fonds

Documents générés : fiche client, fiche fournisseur, fiche RDV⁶ client, bon de commande, facture proforma, facture, reçu de payement.

? Poste de travail : Gestionnaire de stock

Moyens utilisés : Excel ; Word et manuel

Responsabilité : Gestion du stock

Tâches à accomplir : Gérer l'enregistrement des produits et les entrées-sorties en stock Documents générés : bon de livraison

⁶ Rendez-vous

9

CONTEXTE ET ETUDE

c) Évaluation de la durée de gestion des documents ? Durée d'établissement des documents

Objet		Durée d'établissement	Fiche client
5 min en moyenne		Fiche RDV client
5 min en moyenne		Factures
7 min en moyenne		Bon de commande
7 min en moyenne		Bon de réception
7 min en moyenne		Reçu de paiement
4 min en moyenne

Tableau 4: Représentation de la durée d'établissement des documents

? Durée de recherche d'un document

Objet		Temps de recherche	Dossier commercial complet
10 min en moyenne		Dossier archivé
30 min au minimum		Une fiche
10 min en moyenne

Tableau 5: Représentation du temps de recherche

2.2.2. Critique de l'existant

a) Les forces du système existant

L'étude de l'existant montre très clairement que les processus sont bien structurés. Toutes les fiches concernant un dossier sont regroupées ensemble dans un classeur qui constitue un dossier. Ce qui constitue un moyen d'archivage de l'entreprise.

? Identification des anomalies

A l'issue de l'étude de l'existant, nous avons identifié quelques insuffisances listées ci-dessous.

v Certaines tâches sont effectuées en double, ce qui augmente la charge de travail ;

v L'archivage des différents documents manipulés se fait sur support papier. Une cause d'une perte immense de temps à la recherche de ces derniers ;

v Retard dans l'établissement des documents dû au fait que certaines tâches sont manuelles et d'autres semi manuelles ;

v Manque de relance systématique des alertes permettant la prise de connaissance sur des éventuels évènements ;

v Une grande utilisation des supports papier, augmentant le risque des pertes, touchant ainsi l'archivage des informations ;

10

CONTEXTE ET ETUDE

+ Manque des états statistiques (nombre de dossiers en cours, nombre d'opérations effectuées au cours d'une période, etc.) ;

+ Difficulté à effectuer toutes les tâches manuellement ;

+ Calcul manuel des montants, entrainant des erreurs.

2.3. PROPOSITIONS ET CHOIX DE SOLUTION 2.3.1. Spécifications de la solution

a) Aspect fonctionnel

+ Disposer d'un module RELATIONS permettant de gérer toutes les informations relatives aux partenaires et de faciliter les relations avec ceux-ci.

+ Disposer d'un module STOCK permettant de gérer les produits, les entrées-sorties et de gérer le niveau du stock

+ Disposer d'un module OPERATIONS permettant de gérer toutes les opérations commerciales de l'achat à la vente

+ Disposer d'un module STATISTIQUE permettant d'effectuer un suivi périodique de l'activité commerciale.

+ Disposer du module PARAMETRES permettant de gérer les utilisateurs et le système

+ Disposer d'un système d'alerte permettant de prendre connaissance des évènements urgents.

b) Aspect sécurité

+ La solution doit garantir à l'utilisateur l'intégrité et la confidentialité de ses données. + Assurer la disponibilité qui s'avère primordiale pour le bon fonctionnement.

+ Assurer la fiabilité et la rapidité ainsi que la flexibilité, l'évolutivité et la réutilisabilité de ses ressources.

+ Tout utilisateur de la solution doit être lié à un profil bien défini en fonction de sa plage d'opérations encore appelée habilitations.

2.3.2. Approches de solution

a) Première solution : achat d'une application ? Description

Cette solution consiste à acheter une application déjà opérationnelle sur le marché qui permet de gérer toutes les activités liées à la gestion commerciale ; et qui s'adapte plus ou moins aux besoins de chaque organisation. Exemple de l'application ApSales dont les principales fonctionnalités sont la gestion des rendez-vous, la gestion des informations Clients et l'analyse des résultats de l'activité commerciale.

? Avantages

Gain considérable par rapport à la durée d'acquisition, vu que l'application est déjà conçue et que dès qu'il y a une commande, la livraison est aussitôt faite ;

11

CONTEXTE ET ETUDE

· Inconvénients

+ L'application est conçue pour un cas général et ne pourrait pas prendre en compte

toutes les particularités du service commercial de TOGO 3000 INFORMATIQUE ; + Les utilisateurs ne peuvent se fier qu'à eux-mêmes ou faire déplacer l'un des

concepteurs pour le déploiement ou la formation en tenant compte des frais ;

+ La maintenance de l'application sera complexe et très couteuse : l'application est conçue en externe. Donc pour faire la maintenance, on doit faire payer un billet s'avion, le logement au concepteur qui viendra s'en charger.

b) Deuxième solution : acquisition d'une application open source

· Description

Cette solution consiste à acquérir une application Open Source. TOGO 3000 INFORMATIQUE aura juste à débourser les frais de déploiement et de formation.

· Avantages

+ Elle est Gratuite

+ La modification de l'application est possible. Il est donc facile de la conformer aux besoins spécifiques de l'entreprise ou d'un projet

· Inconvénients

Malgré ses avantages, cette application aura quelques insuffisances

+ Les utilisateurs ne peuvent que se fier à eux-mêmes ou à un développeur de modules pour pallier aux insuffisances

+ Le coût de formation et de maintenance peut être onéreux

c) Troisième solution : développement d'une application

· Description

Elle consiste à développer une application mobile qui prend en compte tous les besoins et spécificités du département commercial de TOGO 3000 INFORMATIQUE.

· Avantages

Comme avantages nous pouvons citer :

+ Une meilleure adaptation du logiciel à toutes les particularités du service commercial vu que le logiciel sera conçu uniquement pour répondre aux besoins spécifiques du département commercial de TOGO 3000 INFORMATIQUE ;

+ Une maintenance en temps réel et moins couteuse : étant donné que le concepteur est

sur le terrain, le coût du transport sera moindre, et la maintenance peut se faire
dans de brefs délais.

+ Une meilleure sécurité des données.

12

CONTEXTE ET ETUDE

? Inconvénients

Délai de livraison moins bref : attente de quelques mois avant l'utilisation dudit logiciel, puisque c'est un nouveau projet qui a été soumis, il faut un peu de temps pour sa réalisation.

2.3.3. Solution retenue

Après analyse des besoins, des contraintes de temps, des spécificités du service et en commun accord avec l'entreprise, nous avons retenu la troisième solution proposée qui consiste à concevoir une application mobile à partir d'une étude approfondie du système existant.

a) Evaluation financière de la solution

? Coût matériel

Désignation	Description	Coût unitaire (FCFA)	Quantit é	Montant (FCFA)
Serveur de base de données	Machine pour héberger la base de données sur le serveur distant	650.000	1	650.000
Onduleur	Puissance de 500 VA et de trois prises secourues par la batterie, sortie 3Kva	350.000	1	350.000
Total				1.000.000

Tableau 6: Le coût matériel

? Le coût de conception

Désignation	Descriptio n	Coût unitaire chargé (FCFA)	Du rée	Nomb re	Montant (FCFA)
Ingénieur Informatique	Concepteu r et Programmeur	100.000/j	120 j	1	12.000.000
Total					12.000.000

Tableau 7: Tableau du coût de conception

? Coût de déploiement

Désignation			Description		Coût	Montant
					(FCFA)	(FCFA)
Publication store	sur	Play	Formation utilisateurs	des	16400	16400
Total						16400

Tableau 8: coût de déploiement

13

CONTEXTE ET ETUDE

? Le coût de la formation

Désignation	Description	Coût (FCFA)	Durée	Montant (FCFA)
Formation	Formation des utilisateurs	100.000/j	5j	500.000
Total				500.000

Tableau 9: Tableau du coût de formation

? Cout total de la solution

Le coût total du projet est présenté dans le tableau suivant :

Désignation	Montant (FCFA)
Coût matériel	1.000.000
Coût de conception	12.000.000
	16400
Coût de formation	500.000
Total	13.516.400

Tableau 10: Tableau du coût total

14

CONTEXTE ET ETUDE

b) Le planning prévisionnel de réalisation

TÂCHE				DEBUT	DUREE	FIN
	ELABORATION DU CAHIER DES CHARGES			30/04/19	5	06/05/19
	PHASE D'ANALYSE ET MODELISATION			07/05/19	28	13/06/19
		Analyse		07/05/19	14	24/05/19
		Modélisation		27/05/19	14	13/06/19
	PHASE DE REALISATION ET DEPLOIEMENT			14/06/19	88	15/10/19
		REALISATION		14/06/19	71	20/09/19
			Gestion des utilisateurs	14/06/19	5	20/06/19
			Gestion des fournisseurs	21/06/19	3	25/06/19
			Gestion des produits	26/06/19	2	27/06/19
			Gestion des achats	28/06/19	20	25/07/19
			Gestion du stockage	26/07/19	2	29/07/19
			Gestion des clients/prospects	30/07/19	3	01/08/19
			Gestion des ventes	02/08/19	19	28/08/19
			Gestion du déstockage	29/08/19	2	30/08/19
			Gestion des délais de cautions bancaires	02/09/19	5	06/09/19
			Administration du système	09/09/19	10	20/09/19
		DEPLOIEMENT		23/09/19	13	09/10/19
			Test et correction des erreurs	23/09/19	3	25/09/19
			Déploiement	26/09/19	1	26/09/19
			Rédaction du guide d'exploitation	27/09/19	2	30/09/19
			Rédaction du guide d'utilisateur	01/10/19	2	02/10/19
	FORMATION DES UTILISATEURS			03/10/19	5	09/10/19
	SUIVI			10/10/19	4	15/10/19

Tableau 11: Planning prévisionnel

CONTEXTE ET ETUDE

15

Figure 2: diagramme de GANTT du planning de réalisation

16

CONTEXTE ET ETUDE

3. CONCLUSION

Ce chapitre décrit d'une façon générale l'analyse de l'existant et du besoin (objectifs) ainsi que l'estimation des coûts et délais pour passer de l'idée de projet à sa réalisation. Il donne en fait les informations nécessaires sur le contexte du projet, la présentation des objectifs de l'étude, l'étude de l'existant suivi de l'étude des solutions possibles en vue d'amélioration, puis de l'évaluation des coûts de la solution retenue et la planification des tâches. Cette étude ainsi faite a permis d'élaborer un cahier des charges permettant d'avoir une appréhension des contours du projet. Cette partie étant ainsi achevée, nous entamons le chapitre suivant décrivant la phase d'analyse et de conception du système.

17

ANALYSE ET CONCEPTION

Chapitre 2

ANALYSE ET CONCEPTION

Comme tout projet informatique, notre projet nécessite une phase d'analyse et conception du système. Il s'agit d'une phase primordiale et déterminante dans la réalisation du projet. Elle nous permet de bien comprendre les besoins du client afin de mettre en oeuvre des solutions adéquates. La gestion de cette phase nécessite l'utilisation d'un langage d'analyse et de modélisation en plus d'une démarche à suivre.

1. PRESENTATION DE LA METHODE D'ANALYSE

Deux approches d'analyse se présentent : l'approche systémique et l'approche objet. Mais dans la cadre de notre projet nous allons nous intéresser qu'à l'approche objet, qui a été adoptée comme méthode d'analyse.

L'approche systémique définit un système comme un ensemble d'éléments en interaction dynamique, organisé en fonction d'un but. Le concept de base de cette approche est la séparation des données et des traitements. Ce type d'approche est efficace lorsque les interactions sont non linéaires et fortes. Mais en cas d'évolution, elle rend la maintenance des systèmes complexe et implique une lenteur dans le développement de logiciel.

L'approche objet désigne l'ensemble des processus et langages utilisés au cours du cycle de vie du logiciel, qui reposent sur la manipulation des objets. Dans cette approche un logiciel est vu comme un ensemble d'objets qui coopèrent. Avec cette approche, nous avons une vision externe définissant les actions qu'il est possible de faire subir à un objet ; et une vision interne dans laquelle, seule sa structure sera considérée.

Un autre concept qui est très souvent lié à l'approche objet est celui de classe qui permet de regrouper les propriétés communes des objets.

En conséquence, nous utiliserons dans le cadre de notre projet le processus unifié 2TUP avec le langage UML tout en adoptant la méthode agile SCRUM pour la gestion de la phase de réalisation.

1.1. Présentation du langage UML

En anglais, Unified Modeling Language (Langage de Modélisation Unifié), UML est un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue.

C'est un langage de modélisation constitué de diagrammes. La version actuelle, UML 2.5, propose 14 types de diagrammes dont 7 structurels et 7 comportementaux. Ces diagrammes sont tous réalisés à partir du besoin des utilisateurs et

peuvent être regroupés selon les deux aspects suivants
( https://openclassrooms.com/fr/courses/2035826-debutez-lanalyse-logicielle-avec-uml/2048781-les-differents-types-de-diagrammes):

ANALYSE ET CONCEPTION

v Les aspects fonctionnels : Qui utilisera le logiciel et pour quoi faire ? Comment les actions devront-elles se dérouler ? Quelles informations seront utilisées pour cela ?

v Les aspects liés à l'architecture : Quels seront les différents composants logiciels à utiliser (base de données, librairies, interfaces, etc.) ? Sur quel matériel chacun des composants sera installé ?

1.2. Présentation du processus 2TUP

Les processus unifiés sont des processus de développement logiciel itératifs, centrés sur l'architecture, pilotés par des cas d'utilisation et orientés vers la diminution des risques⁷.

Pour un modèle 2TUP, tout développement peut être décomposé et traités en parallèle selon un axe fonctionnel et un axe technique. Nous pouvons ainsi suivre les évolutions liées aux changements des besoins fonctionnels et aux changements des besoins techniques. Ci-dessous, une représentation graphique du processus unifié 2TUP.

Figure 3: processus de développement 2TUP

Source : https://www.researchgate.net/figure/Methode-2TUP-etendue-31_fig17_299286702

1.3. Présentation du processus SCRUM

1.3.1. Définition

SCRUM est un schéma d'organisation de développement de produits complexes. Il est défini par ses créateurs comme un « cadre de travail holistique itératif⁸ qui se concentre sur les buts communs en livrant de manière productive et créative des produits de la plus grande valeur possible ⁹» (Wikipédia).

Cette méthode défini trois principaux rôles dans le processus.

v Le Scrum Master : il a pour rôle de vérifier l'application des principes de Scrum, s'assure que la communication fonctionne correctement au sein de l'équipe et explore toutes les pistes d'améliorations en termes de productivité et de savoir-faire.

⁷ https://sabricole.developpez.com/uml/tutoriel/unifiedProcess/

⁸ Le processus itératif est une séquence d'instructions destinée à être exécutée plusieurs fois et autant de fois qu'on peut en avoir besoin. C'est aussi une exécution de la séquence.

⁹ https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-French.pdf

18

19

ANALYSE ET CONCEPTION

+ L'équipe Scrum : il s'agit de l'équipe chargée de la réalisation des différentes tâches. Chaque membre est au même niveau, il n'y a pas de hiérarchie et chacun peut contribuer en fonction de ses compétences. L'objectif de l'équipe est de livrer le produit par incréments. Ainsi, à tout instant, il existe une version du produit « potentiellement livrable » disponible.

+ Le Product Owner : il est un expert du processus métier du client, définit les spécifications fonctionnelles et arbitre les priorités dans les réalisations.

1.3.2. Caractéristiques

+ C'est une démarche orientée client ; c'est-à-dire une focalisation sur les besoins du client tout au long du projet. Le changement est permanent. Bien entendu, réorienter un projet lorsqu'il le faut est la seule manière de livrer un produit conforme aux attentes clients.

+ C'est une démarche orientée produit ; une préoccupation sur le produit à réaliser plutôt que des principes et théories pour le réaliser. Le produit voit très rapidement le jour. Puis il est amélioré, perfectionné selon les spécifications, attentes et les exigences qualité.

+ La souplesse remplace la rigidité ; fondées sur un dialogue permanent avec le client, cette méthode vise la conformité quasi parfaite de la réalisation selon les attentes actuelles du client.

+ Planifier à volonté ; la modification des spécifications en cours de réalisation, véritable tourment pour les développeurs des projets classiquement conduits, est le principe fondateur de cette démarche. Pas de planning rigide aux stricts impératifs. Au contraire, on a la capacité non pas de chambouler les plans mais bien de « replanifier » à volonté. Un seul objectif : délivrer très rapidement un nouveau produit « fin » prêt à être évalué et amélioré. Le produit livré sera la nouvelle référence des échanges et du projet.

2. PRESENTATION DE L'OUTIL DE MODELISATION

2.1. Qu'est-ce que PowerAMC ?

PowerAMC actuellement devenu PowerDesigner est un logiciel de conception créé par la société SAP, qui permet de modéliser les traitements informatiques et leurs bases de données associées (Wikipédia). Il est basé sur le langage de modélisation UML.

2.2. Quels sont les atouts de PowerAMC ?

PowerAMC est un outil permettant d'effectuer les tâches suivantes :

+ Modélisation intégrée via l'utilisation de méthodologies et de notation standard : données (E/R, Merise), application (UML)

+ Génération automatique de code via des templates personnalisables : SQL (avec plus de 50 SGBD), Java, NET

+ Fonctionnalités de reverse engineering pour documenter et mettre à jour des systèmes existants ;

20

ANALYSE ET CONCEPTION

v Une solution de référentiel d'entreprise avec des fonctionnalités de sécurité et de gestion des versions très complètes pour permettre un développement multiutilisateur ;

v Fonctionnalités de génération et de gestion de rapports automatisés et personnalisables ;

Un environnement extensible, qui nous permet d'ajouter des règles, des commandes, des concepts et des attributs à nos méthodologies de modélisation et de codage.

3. ÉTUDE DÉTAILLÉE DE LA SOLUTION 3.1. Étude fonctionnelle

Dans cette partie nous allons identifier les différents acteurs qui vont interagir avec le système ainsi que les actions effectuées par ces derniers. Cette partie sera subdivisée en trois parties : la capture des besoins fonctionnels, l'analyse fonctionnelle statique et l'analyse fonctionnelle dynamique.

3.1.1. Capture des besoins fonctionnels

a) Identification des cas d'utilisation fonctionnels

L'étude de l'existant nous a permis de déceler un certain nombre de cas d'utilisation que nous résumons dans le tableau suivant.

N°	Cas d'utilisation	Acteur(s)
1	Gérer le système	Administrateur
2	Gérer les utilisateurs	Administrateur
3	Gérer les profils	Administrateur
4	Gérer les privilèges	Administrateur
5	S'authentifier	Administrateur, Commercial, Gestionnaire de stock, Comptable
6	Gérer les relations	Commercial
7	Gérer les devis	Administrateur, Commercial
8	Gérer les commandes	Administrateur, Commercial
9	Générer les factures	Administrateur, Commercial
10	Générer les livraisons	Administrateur, Commercial
11	Gérer les produits	Administrateur, Gestionnaire de stock
12	Gérer le stock	Administrateur, Gestionnaire de stock
13	Gérer les cautions	Administrateur, Comptable
14	Consulter les statistiques	Administrateur, Commercial

Tableau 12: liste des cas d'utilisation du système

21

ANALYSE ET CONCEPTION

b) Diagramme de cas d'utilisation

c)

^<<include>>

^{Gérer le stock}

^<<include>>

^<<include>>

^{gérer livraisons}

^{Administrateur}

^{Gérer les utilisateurs}

^{Gérer relations}

^<<include>>

^{gérer produits}

^<<include>>

^<<include>>

^{Gérer les achats}

^<<include>>

^<<include>>

^<<include>>

^{gérer factures}

^{Gérer devis gérer commandes}

^{Gérer règlements}

^{Agent commercial}

^<<include>>

^<<include>>

^<<include>>

^{Gérer les ventes}

^<<include>>

^<<include>>

^{Valider les operations}

^<<include>>

^<<include>>

^{Chef service commercial}

^{Consulter l'historique}

^<<include>>

^{S'authentifier}

^Comptable

^{Agent approvisionnement}

^{Gérer les cautions bancaires}

^<<include>>

^{Gérer les règlements}

^<<include>>

Figure 4 : diagramme de cas d'utilisation

^<<include>>

^<<include>>

^{Gérer les paramètres}

Description textuelle des cas d'utilisation

Cette description permet d'avoir une idée sur le fonctionnement de chaque cas d'utilisation.

22

ANALYSE ET CONCEPTION

? Cas d'utilisation « Gérer les utilisateurs » Sommaire d'identification :

Titre : Gérer les utilisateurs. But : inscription, activation, désactivation ou suppression des comptes utilisateurs. Résumé : L'administrateur créer un utilisateur en saisissant ses informations personnelles dans un formulaire, l'active et peut par la suite le désactiver si nécessaire via la page administrative. Acteurs : Administrateur
Préconditions : l'administrateur s'authentifie
Scénario nominal : 1-l'administrateur accède à la page de gestion des utilisateurs. 2-L'administrateur saisit les informations personnelles de l'utilisateur et valide 3-Le système vérifie(A1) (E1) 4-Le système envoie une notification de réussite de l'enregistrement Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur champ obligatoire ou données incorrectes. L'administrateur peut réessayer au point 2. Scénario d'exception : · E1 : le système détecte un échec d'enregistrement dans la base de données et affiche un message précisant un échec d'inscription ; Le scénario nominal se termine par un échec.		Postconditions : l'utilisateur est inscrit sur la plateforme

? Cas d'utilisation « s'authentifier »

Titre : Authentification. But : la connexion d'un utilisateur au système. Résumé : L'utilisateur s'authentifie en saisissant son email et son mot de passe. Acteurs : Administrateur, utilisateur.

Préconditions : l'utilisateur lance l'application

Scénario nominal :

1-L'utilisateur saisit son email et son mot de passe puis valide

2-Le système vérifie(A1) (E1) (E2)

3-Le système envoie une notification de réussite

Scénario alternatif :

· A1 : le système détecte une erreur dans un champ de formulaire pour une 1ere ou 2ème fois et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 1. Au bout d'un troisième essaie exécuter E2

Scénario d'exception :

· E1 : l'utilisateur n'existe pas dans la base de données et le système affiche un message précisant le précisant. Le scénario nominal se termine par un échec.

· E2 : Le système affiche un message de demande de réinitialisation du mot de passe

23

ANALYSE ET CONCEPTION

Postconditions : l'utilisateur se connecte au système et peut ainsi accéder aux rubriques correspondantes

? Cas d'utilisation « Gérer les relations »

Titre : Gérer les clients/prospects/fournisseurs.

But : Créer, mettre à jour ou supprimer une relation.

Résumé : le commercial se connecte à l'application, saisit les informations nécessaires dans les champs s'il s'agit de la création. Ou recherche le contact pour le mettre à jour via un champ de formulaire ou le supprime de la liste des relations.

Acteurs : Commercial.

Préconditions : L'utilisateur accède à la plateforme avec le profil requis

Scénario nominal :

1-Le commercial accède à l'interface de gestion des relations.

2- le commercial accède au formulaire d'ajout de la relation.

3- le commercial saisit les informations dans les champs puis valide 2-Le système vérifie(A1) (E1)

3-Le système envoie une notification de réussite

Scénario alternatif :

· A1 : le système détecte une erreur dans un champ de formulaire et affiche un message
d'erreur données incorrectes. L'utilisateur peut réessayer au point 3.

Scénario d'exception :

· E1 : la relation existe déjà dans la base de données et Le système affiche un message
précisant un échec de création ou de mise à jour. Le scénario nominal se termine par un échec.

- Postconditions : le commercial a pu créer ou mettre à jour une relation.

? Cas d'utilisation « Rechercher une entité »

Titre : rechercher une entité. But : Consulter une entité. Résumé : L'utilisateur effectue la recherche d'une entité en saisissant une information relative à l'entité recherchée. Acteurs : Tous les acteurs du système.
Préconditions : l'utilisateur s'authentifie
Scénario nominal : 1-L'utilisateur accède à l'interface affichant la liste des entités de la catégorie de l'entité recherchée. 2- saisit une information concernant l'entité recherché dans le champ de recherche puis valide. (A1) 3- le système affiche l'entité. Scénario alternatif : · A1 : Le système affiche un message indiquant que l'information n'existe pas dans la base. L'utilisateur peut réessayer au point 2.		Postconditions : L'utilisateur consulte l'information recherchée

24

ANALYSE ET CONCEPTION

? Cas d'utilisation « Gérer les devis »

Titre : Enregistrer un devis. But : Enregistrer un devis dans la base de données. Résumé : Le client demande un devis, le devis est enregistré pour être imprimer plus tard et envoyé au client. Acteurs : Commercial		Préconditions : Le commercial s'authentifie
Scénario nominal : 1-Le commercial accède à la page de gestion des devis, 2-Le commercial saisit les informations relatives au devis puis valide. 3-Le système vérifie(A1) (E1) 4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2.
Postconditions : devis enregistré

? Cas d'utilisation « Gérer les commandes »

Titre : Gestion des commandes. But : Mettre à jour les commandes. Résumé La validation d'un devis fait l'objet d'une commande, la commande est enregistrée. Elle peut ainsi être supprimée, imprimée ou modifiée plus tard. Acteurs : Commercial		Préconditions : Le commercial s'authentifie
Scénario nominal : 1-Le commercial accède à la page de gestion des commandes, 2-Le commercial saisit les informations relatives à la commande puis valide. 3-Le système vérifie(A1) (E1) 4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2.
Postconditions : Commande enregistrée

? Cas d'utilisation « Gérer les factures »

Titre : Gestion des factures. But : Gérer une facture. Résumé : Création, mise à jour, suppression ou édition d'une facture. Acteurs : Commercial

Préconditions : le commercial s'authentifie

Scénario nominal : 1-Le commercial accède à la page de gestion des factures, 2-Le commercial saisit les informations relatives à la facture puis valide. 3-Le système vérifie(A1) (E1)

25

ANALYSE ET CONCEPTION

4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2.

Postconditions : facture enregistrée et générée

? Cas d'utilisation « Gérer les livraisons »

Titre : Gérer les livraisons But : Mise à jour des livraisons. Résumé : le livreur enregistre, met à jour ou supprime une livraison. Acteurs : gestionnaire de stock		Préconditions : le gestionnaire de stock s'authentifie, facture réglée
Scénario nominal : 1-Le gestionnaire de stock accède à la page de gestion des livraisons, 2- Le gestionnaire de stock saisit les informations relatives à la livraison puis valide. 3-Le système vérifie(A1) (E1) 4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2.
Postconditions : bon de livraison généré

? Cas d'utilisation « Gérer le stock »

Titre : Gérer le stock. But : Ajouter, mettre à jour ou retirer un article du stock. Résumé : le gestionnaire de stock se connecte à l'application, puis effectue l'opération suivant qu'il s'agit d'un déstockage ou d'un stockage de marchandise ou s'il s'agit d'une mise à jour. Acteurs : le gestionnaire de stock.		Préconditions : l'utilisateur accède à la plateforme avec le profil requis
Scénario nominal : 1-Le gestionnaire de stock accède à l'interface de gestion du stock. 2-S'il s'agit d'un stockage, il accède au formulaire spécifié pour la création de l'article s'il s'agit d'un nouvel article ou au formulaire de stockage via l'interface de réception de marchandise pour ajouter au stock. 3-le système vérifie. (A1) (E1) (E2) 4-Le système envoie une notification de réussite Scénario alternatif : · A1 : le système détecte une erreur dans un champ de formulaire et affiche un message d'erreur données incorrectes. L'utilisateur peut réessayer au point 2. Scénario d'erreur : · E1 : le système détecte un échec d'enregistrement dans la base de données et affiche un message précisant un échec d'inscription ;
Postconditions : stock mis à jour

26

ANALYSE ET CONCEPTION

? Cas d'utilisation « Consulter les statistiques »

Titre : Consultation des statiques.

But : Affichage des états statistiques

Résumé : le système affiche à l'utilisateur les états statistiques (nombre d'achats ou de

ventes, le montant total des achats et le montant total des ventes, ...)

Acteurs : Administrateur, Commercial

Préconditions : L'administrateur ou le commercial s'authentifie.

Scénario nominal :

1-L'administrateur ou le commercial accède à la rubrique statistique appropriées. 2-Il choisit le type d'information.

3-Le système l'affiche les statistiques selon les paramètres choisis.

Postconditions : des états statistiques sont consultés

3.1.2. Analyse fonctionnelle statique

a) Diagrammes de classes participantes

Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci.

L'élaboration du diagramme de classes commence par l'identification des classes participantes du future modèle statique.

A partir de la description textuelle des cas d'utilisation nous pouvons tirer les classes candidates Client, Fournisseur, Prospect, Devis, LigneDevis, Commande, LigeCommande, Facture, Livraison, LigneLivraison, Article, Caution

Ce qui nous permet d'élaborer les diagrammes de classes suivant

b) Gestion des utilisateurs

^1..1

- ^{id_utilisateur}

- ^nom

- ^prenom

- ^email

- ^password

- ^status

^Utilisateur

: ^int

: ^String

: ^String

: ^String

: ^String

: ^boolean

- ^date_debut - ^date_fin

^{0..* 1..1}

^Avoir

- ^libelle

- ^{début_operation} - ^{fin_operation}

: ^Date : ^Date

- ^id_profil - ^libelle

^Operation

^Profil

: ^int

: ^String

- ^peut_lire

- ^peut_creer

- ^{peut_modifier} - ^{peut_suprimer}

: ^String
: ^Date
: ^Date

^Privilege

^1..1

: ^boolean : ^boolean : ^boolean : ^boolean

^1..1

- ^id_objet - ^libelle

^Objet

^1..1

: ^int

: ^String

Figure 5: Diagramme de classe gestion des utilisateurs

27

ANALYSE ET CONCEPTION

c) Gestion des cautions

^Organisme

^Projet

^{id_projet libelle description date_debut date_fin}

: ^int : ^String : ^String : ^Date : ^Date

-

-

-

-

-

^0..*

^0..1

^1..*

: ^int

: ^String

-

*

-

^1..1

^{id_type_caution}

^libelle_type

^Type_caution

^Caution

- ^id_type - ^libelle - ^montant - ^{date_emission} - ^{date_echeance} - ^condition

: ^int

: ^String : ^double : ^Date : ^Date : ^String

^0..*

- ^identifiant

^-type

- ^nom

- ^email

- ^adresse

- ^telephone

- ^observation

- ^bp

- ^pays

- ^ville

^PERSONNE

^{abstract}

: ^int

: ^String : ^String : ^String : ^String : ^String : ^String : ^String : ^String : ^String

^Banque

^1..1

^1..1

Figure 6: diagramme de classe gestion des caution

ANALYSE ET CONCEPTION

d) Gestion des achats et ventes

Le diagramme de classe ci-dessous est à la troisième forme normale.

^PERSONNE

^{abstract}

- ^{id_ligne_retour_client} - ^quantite

: ^int : ^int

^1..1

^0..*

^RETOUR_CLI

^0..*

-

-

-

^{id_livraison_client}

^{num_livraison}

^{date_livraison}

^{LIVRAISON_CLI}

^1..1

^0..*

^0..*

: ^int

: ^int

: ^Date

^1..1

^0..*

- ^{id_facture_client} - ^{date facture} - ^total__TTC

^FACTURE_CLI

^0..*

: ^int

: ^Date : ^int

^1..1

^0..1

^1..1

^1..1

^1..1

- ^activite : ^String

- ^{dernier_achat} : ^String

- ^{id_commande_client} - ^{date_commande} - ^{date_livraison} - ^total_TTC

^COMMANDE_CLI

^CLIENT

^1..1

^0..*

^1..1

^1..1

: ^int

: ^Date : ^Date : ^int

^0..*

^0..1

^0..*

^identifiant

^type

^nom

^{email adresse telephone observation bp}

^pays

^ville

- ^id_devis

- ^{date_commande} - ^{date_livraison} - ^total_TTC

- ^activite : ^String

^PROSPECT

^1..*

^DEVIS

^1..1

: ^int : ^String : ^String : ^String : ^String : ^String : ^String : ^String : ^String : ^String

: ^int

: ^Date : ^Date : ^int

^{ARTICLE_SERVICE}

^1..1

^1..1

^1..1

^1..*

^{LigneCommandeCli}

^LigneDevis

^0..*

^0..*

*

- ^{id_ligne_com_client} - ^prixTTC

-

^quantite

- ^tva

- ^remise

: ^int : ^double : ^int : ^double : ^double

: ^int

: ^double : ^int

^{id_ligne_devis}

^prixTTC

^quantite

^1..1

^1..*

^{LigneRetourCli}

^1..*

^{LigneLivraisonCli}

^1..1

^FOURNISSEUR

^1..1

^{numero_compte} : ^int

^1..1

^0..1

^1..1

^0..*

^0..*

^0..*

^COMMANDE_FRS

^FACTURE_FRS

^RECEPTION

: ^Date
: ^Date
: ^int

^1..1

- ^{id_facture_frs} - ^{date facture} - ^total__TTC

: ^int

: ^Date : ^int

- ^id_reception

- ^{num_reception} - ^{date_reception}

: ^int

: ^int

: ^Date

^1..1

^0..*

^0..1

- ^{id_commande_frs} - ^{date_commande} - ^{date_livraison} - ^total_TTC

: ^int

^RETOUR_FRS

^0..*

: ^int

: ^Date : ^int

- ^{id_retour_frs}

-

^{date reception}

- ^total__TTC

^{id_ligne_retour_frs}

^quantite

: ^int : ^int

^1..1

^1..

^0..1

^0..*

^{LigneRetourFrs}

1..1 0..*

^1..1

^1..1

^1..*

^{LigneCommandeFrs}

^0..* - - - - -

^1..*

^{LigneReception}

^{id_ligne_commande_frs}

^prixTTC

^quantite

^tva

^remise

: ^int : ^double : ^int : ^double : ^double

: ^int
: ^int
: ^int

^{id_ligne_reception}

^{quantite recu}

^{quantite__totale}

^0..*

- ^{id_service_article}

- ^libelle

- ^description

- ^prix_HT

: ^int

: ^String : ^String

: ^double

: ^int

: ^Date : ^int

- ^id

- ^{date_reception} - ^{total TTC}

: ^int
: ^int
: ^int

^{id_ligne_liv_client}

^{quantite_livree}

^{quantite_totale}

28

Figure 7:diagramme de classe gestion achats et ventes

29

ANALYSE ET CONCEPTION

3.1.3. Analyse fonctionnelle dynamique a) Diagrammes de séquences

? Administration

v Cas d'utilisation « ajouter un utilisateur »

^{Ajouter utilisateur}

^loop

		^Système

^ref

^{[Pour chaque ajout]}

^{Administrateur}

^{Demande l'accès à l'espace de gestion compte}

^{rempli les champs de formulaire}

^{demande d'ajout d'un utilisateur}

^{affiche formulaire d'ajout}

^{affiche l'epace demandé}

^{S'authentifier()}

^{verifie les champs}

^BDD

^{alt champs incomplet}

^{affiche un message d'erreur}

^{champ complet}

^{transfere les informations}

^{alt Utilisateur} existe

^{affiche message d'erreur}

^{informations incorectes}

^{Utilisateur n'existe} pas

^{affiche message de confirmation}

^{confirme la demande}

Figure 8: Diagramme de séquence du cas d'utilisation « ajouter un utilisateur »

30

ANALYSE ET CONCEPTION

v Cas d'utilisation « éditer un profil »

^{Editer_profil}

^loop

^ref

^{alt champs} incomplet ^{affiche un message d'erreur}

^{champ complet}

^{transfere les informations}

^Execute

^alt echec ^{affiche message d'erreur echec d'enregistrement}

succès ^{message de confirmation informations enregistrées}

^{[Pour chaque authentification]}

^{Administrateur}

^{Demande de la page profil}

^{saisir les informations}

^{S'authentifier()}

^Système

^{verifie les champs}

^BDD

^{affiche la page demandée}

Figure 9: Diagramme de séquence du cas d'utilisation « éditer un profil »

v Cas d'utilisation « s'authentifier »

^{S'authentifier}

^loop

^verifie

^Utilisateur

^{alt champs incomplet}

^{affiche un message d'erreur}

^champ complet ^{transfere les informations}

^alt

existe ^{affiche message d'erreur informations incorectes}

^{Utilisateur n'existe pas}

^{renvoie vers la page d'accueil}

^informations correctes

^{[Pour chaque authentification]}

^Utilisateur

^{saisir l'email et le mot de passe puis valider}

^{Demande de la page d'authentification}

^{affiche la page demandée}

^Système

^{verifie les champs}

^BDD

Figure 10: Diagramme de sequence du cas d'utilisation « s'authentifier »

31

ANALYSE ET CONCEPTION

? Achat

v Cas d'utilisation « demander une cotation »

^BDD

^Système

^Fournisseur

^{demander_cotation}

^ref

^{S'authentifier()}

^Commercial

^{Demande de la page de gestion des cotations}

^{affiche la page demandée}

^loop [Pour chaque demande] ^saisir les informations
^verifie les champs
					^alt champs incomplet ^affiche un message d'erreur
					^champ complet
^transfere les informations
			^Execute
^alt echec ^affiche message d'erreur	^echec d'enregistrement
succès ^message de confirmation	^informations enregistrées
^demande action utilisateur	^génère un pdf
^choisit action
alt^action=imprimer ouvrir_pdf()
^imprimer
^envoyer
^action=envoyer	^envoyer_pdf_par_email

Figure 11: Diagramme de séquence du cas d'utilisation « demander une cotation »

32

ANALYSE ET CONCEPTION

v Cas d'utilisation « commander un produit »

^commander_produit

^Système

^BDD

^Fournisseur

^Commercial

^ref S'authentifier()

^ref demandercotation()

^envoyer proforma

^Demande de la page d'enregistrement proforma

^affiche la page demandée

^saisir les informations

^verifie les champs

^alt champs incomplet affiche un message d'erreur

^champ complet

^transfere les informations ^Execute

^alt echec ^affiche message d'erreur

^echec d'enregistrement

succès ^message de confirmation

^informations enregistrées

^demande action utilisateur (valider toutes les lignes?) loop^pour chaque ligne de produit]

alt^â ligne devis approuvé valider la ligne

^reponse alt reponse=oui

^créer ligne commande

^ânon ^rejeter la ligne

^générer commande ^transferer informations commande

^renvoyer les données stocker

^reponse=non ^afficher interface de validation de la proforma

^générer la commande ^transférer informations commande

^renvoyer les données stocker

^choix action

^imprimer

^envoyer

action=envoyer

envoyer_pdf_par_email()

^demande action utilisateur

^générer pdf()

alt action=imprimer ^ouvrir pdf()

Figure 12: Diagramme de séquence du cas d'utilisation « commander un produit »

33

ANALYSE ET CONCEPTION

v

^{recevoir_marchandise}

^{Gérer_facture_frs}

^ref

^ref

^ref

^alt champs incomplet affiche un message d'erreur					^champ complet ^alt rapport=echec ^affiche message d'erreur rapport=succès ^message de confirmation ^demande action utilisateur (règler la facture?) ^reponse
^transfere les informations ^rapport de stockage stocker
alt reponse=oui ^message de confirmation ^reponse=non		^demande mise à jour état facture confirmation ^mise à jour

Figure 13: Diagramme de séquence du cas d'utilisation « gérer une facture fournisseur »

v Cas d'utilisation « Gérer une réception »

^Commercial

^{Demande de la page d'enregistrement facture}

^{affiche la page demandée}

^{saisir les informations}

^{commanderproduit()}

^{demandercotation()}

^{S'authentifier()}

^Système

^Système

^{envoyer facture}

^{verifie les champs}

^BDD

^BDD

^Fournisseur

^Fournisseur

Cas d'utilisation « gérer facture fournisseur »

^Commercial

^ref

^{S'authentifier()}

^ref

^{demandercotation()}

^ref

^{commanderproduit()}

^ref

^{Gérerfacturefrs()}

^{Demande de la page d'enregistrement de la reception}

^{affiche la page demandée}

^{saisir les informations}

^{verifie les champs}

alt ^{champs incomplet affiche un message d'erreur}

^champ complet	^transfere les informations
		^rechercher produit
alt^ancien produit ^message de confirmation	^confirmation	^mise à jour quantité et prix
^nouveau produit
loop^pour chaque ligne de produit] ^message de confirmation	^confirmation	^ajouter en stock

Figure 14: Diagramme de séquence du cas d'utilisation « Gérer une reception »

34

ANALYSE ET CONCEPTION

? Vente

v Cas d'utilisation « gérer un devis client »

^Système

^BDD

^Client

^gérer_devis

^Commercial

^ref

^S'authentifier()

^{demander devis}

^{Demande de la page de gestion des devis}

^{affiche la page demandée}

^loop [Pour chaque demande] saisir les informations
^verifie les champs
					^alt champs incomplet ^affiche un message d'erreur
					^champ complet
^transfere les informations
^rapport d'execution			^Execute
^alt echec ^affiche message d'erreur
succès ^message de confirmation
^demande action utilisateur	^génère un pdf
^choisit action
alt action=imprimer ouvrir_pdf()
^imprimer
^envoyer
action=envoyer

^{envoyer pdf par email}

Figure 15: Diagramme de séquence du cas d'utilisation « gérer un devis client »

35

ANALYSE ET CONCEPTION

v Cas d'utilisation « gérer une commande client »

^gérer_commande_client

^Système

^BDD

^Client

^Commercial

^ref S'authentifier()

^ref gérer_devis()

^commander produit

^Demande de la page d'enregistrement commande

^affiche la page demandée

^saisir les informations

^verifie les champs

^alt champs incomplet ^affiche un message d'erreur

^champ complet

^transfere les informations

^rapport d'execution

^Execute

^alt echec ^affiche message d'erreur

succès ^message de confirmation

^reponse

alt reponse=oui

^générer commande ^transferer informations commande

^renvoyer les données ^stocker commande

^créer facture

reponse=non ^afficher interface de validation des devis

loop^pour chaque ligne de produit]

^demande action utilisateur (valider toutes les lignes?) alt^si ligne devis approuvée ^valider la ligne

^créer ligne commande

^sinon rejeter la ligne

^générer la commande ^transférer informations commande

^renvoyer les données stocker commande

^créer facture

^demande action utilisateur

^générer facture en pdf()

^choix action

alt action=imprimer ouvrir_pdf()

^imprimer

^envoyer

action=envoyer

envoyer_facture_en_pdf_par_email()

Figure 16: Diagramme de séquence du cas d'utilisation « gérer une commande client »

36

ANALYSE ET CONCEPTION

v Cas d'utilisation « gérer une facture client »

^Commercial

^{S'authentifier()}

^{gérerdevis()}

^{ref gérer_commande_client()}

^{règler facture}

^ref

^ref

^{verifie les champs}

^{Demande de la page de règlement facture}

^{affiche la page demandée}

^{saisir les informations}

^alt champs incomplet affiche un message d'erreur						^champ complet
^transfere les informations
^rapport de mise à jour				^mise à jour facture
					^alt rapport=echec ^affiche message d'erreur
					rapport=succès ^message de confirmation
^générer bon de livraison ^transmettre informations livraison					^demande action utilisateur
^générer_pdf_livraison()				^reponse
alt imprimer ouvrir_pdf()
^imprimer
^envoyer le bon de livraison
envoyer	transmettre_pdf_bon_de_livraison_par_email()

^{Gérer_facture_client}

^Système

^BDD

^Client

Figure 17: Diagramme de séquence du cas d'utilisation « gérer une facture client »

v Cas d'utilisation « livrer une marchandise »

^recevoir_marchandise

^Système

^BDD

^Client

^Commercial

^ref S'authentifier()

^créer livraison ^ref gérer_devis()

^ref gérercommandeclient()

^ref Gérerfactureclient()

^Demande de la page d'enregistrement de la livraison

^affiche la page demandée

^saisir les informations

alt^champs incomplet ^affiche un message d'erreur

^verifie les champs

^champ complet

^confirmation

^mise à jour quantité

loop^pour chaque ligne de produit] ^n'existe pas ^message d'erreur

^transfere les informations ^produit absent

^rechercher produit en stock

alt existe

^message de confirmation

Figure 18: Diagramme de séquence du cas d'utilisation « livrer une marchandise »

ANALYSE ET CONCEPTION

? Stock

v Cas d'utilisation « Gérer article »

^{Gestionnaire de stock}

^ref	^S'authentifier()

^{demande la page de gestion des articles}

^{affiche la page demandée}

^{choix operation}

^alt nouveau	^affiche formulaire
^mise à jour	^selectionne l'article à mettre à jour
	^affiche le formulaire de mise à jour

^{saisit les informations puis valide}

^{vérifie les informations}

^alt données incorrectes	^envoie un message d'erreur
^données correctes		^transmet les informations

^te

^{Gérer_article}

^Système

^BDD

^l'operation

^{rapport d'execution}

^{message d'erreur}

^{message de confirmation}

Figure 19: Diagramme de sequence du cas d'utilisation « Gérer article »

37

^alt erreur

^succès

3.2. Étude technique

^execu

3.2.1. Capture des besoins techniques

La capture des besoins techniques permet de recenser toutes les contraintes techniques et logicielles exprimées dans l'étude préliminaire lors de l'expression des besoins opérationnels et des choix stratégiques de développement. Elle doit être suffisamment détaillée pour permettre d'aborder la conception générique du système.

Les choix stratégiques de développement faits au niveau du cahier des charges vont donner lieu à des contraintes relatives à la configuration du système. Ces contraintes concernent les performances d'accès aux données, la sécurité du système, l'interopérabilité, l'intégration des applications, la volumétrie et le mode d'utilisation du système.

38

ANALYSE ET CONCEPTION

a) Identification des cas d'utilisation techniques ? Les exploitants du système

L'exploitant est un acteur au sens d'UML, si ce n'est qu'il ne bénéficie que des fonctionnalités techniques du système.

Les exploitants de notre système sont :

V' L'utilisateur qui utilise une des applications du système. (La majorité des acteurs de la branche fonctionnelle sont donc des utilisateurs dans la dimension technique).

V' L'ingénieur d'exploitation qui est chargé de déployer et de dépanner le système.

? Les cas d'utilisations techniques

Un cas d'utilisation technique est destiné à l'exploitant. C'est une séquence d'action produisant une valeur ajoutée opérationnelle ou purement technique. Le tableau suivant résume les cas d'utilisation techniques.

Cas d'utilisation	Acteurs	Messages
Gérer les erreurs et exceptions	Utilisateur	Emet : erreurs
	Administrateur	Reçoit : liste erreurs
Gérer la sécurité	Utilisateur	Emet : ouverture de session, mot de passe crypté
	Administrateur	Reçoit : liste des sessions ouvertes Emet : sauvegarde des données
Utiliser l'aide	Utilisateur	Reçoit : l'aide

Tableau 13: Cas d'utilisation techniques

? Gérer les erreurs et les exceptions

Ce cas d'utilisation permet au système d'être exploitable ; il faut qu'il soit en mesure de générer des traces et des alertes qui vont faciliter la maintenance, ce qui introduit l'ingénieur d'exploitation comme exploitant du système.

Ci-dessous la description de ce cas d'utilisation.

V' Le système enregistre toute erreur survenue dans un fichier ;

V' Le responsable d'exploitation consulte le fichier d'erreurs et recherche les causes des erreurs ;

V' L'application propose au responsable d'exploitation un menu de résolution de problèmes liés à sa recherche ;

V' Le responsable d'exploitation choisit l'option lui permettant de résoudre le problème. V' Le système lui confirme la réussite de l'opération.

V' Le responsable d'exploitation fait un test. Si le test ne donne pas les résultats escomptés alors on repart au point (4). Si le test est ok le responsable d'exploitation valide puis ferme la fenêtre.

ANALYSE ET CONCEPTION

? Gérer la sécurité

Ce cas d'utilisation permet de protéger le système des intrusions externes. Les exploitants sont soumis à des règles de sécurité qui sont l'authentification, le cryptage.

? Utiliser l'aide

Ce cas d'utilisation permet d'exploiter le système de manière efficace. Chaque utilisateur doit disposer d'une aide contextuelle.

b) Architecture en 5 couches

Une couche logicielle représente un ensemble de spécifications ou de réalisations qui respectivement expriment ou mettent en oeuvre un ensemble de responsabilités techniques et homogènes pour un système logiciel.

Les couches s'empilent en niveaux pour couvrir des transformations logicielles successives, de sorte que la couche d'un niveau ne puisse utiliser que les services des couches des niveaux inférieurs.

	^Restituer les données aux utilisateurs, et transformer ses ^actions en évènement de l'application
	^l'application
^Exploitant

^{Présentation}

^Application

	^Implémente les objets du metier et implémente leurs ^règles de gestion
		^de stockage

^{représente les objets de contrôle et pilote les règles de}

^{Assure la persistence des données}

^Métier

^{Accès aux données}

^{Stockage de données}

39

^{Restitue les représentations métiers à partir du moyen}

Figure 20: Architecture en cinq couches

3.2.2. Conception générique

La conception générique est une activité de la branche technique (droite) du processus en « Y ». Elle s'appuie sur les couches logicielles déjà identifiées lors de l'étape précédente qui est la capture des besoins techniques. Cette conception est qualifiée de générique, car elle est entièrement indépendante des aspects fonctionnels. En effet, elle consiste à développer la solution qui répond aux spécifications techniques en construisant les classes techniques qu'on groupera dans des Framework techniques et en organisant ces Framework dans un modèle logique de conception technique.

40

ANALYSE ET CONCEPTION

a) Modèle logique de conception

En analyse, nous avons fait un découpage en catégorie des classes, ici les classes techniques seront regroupées non pas dans des catégories, mais dans des Frameworks techniques que nous allons organiser dans le modèle logique de conception technique.

Un Framework est un réseau de classes qui collaborent à la réalisation d'une responsabilité qui dépasse celle de chacune des classes qui y participent.

A chaque couche logicielle définie dans l'étape de la capture des besoins techniques correspond un Framework technique, l'organisation de ces derniers permet d'élaborer le modèle logique de conception qui est schématisé dans la figure suivante.

^{Noyau métier}

^{Noyau application}

^{Noyau accès aux données}

^{Noyau sécurité}

^{Noyau présentation}

Figure 21: Modèle logique de conception

b) Description des noyaux ? Le noyau présentation

Définit les classes, les Interfaces Homme/Machine (IHM) qui sont nécessaires à l'affichage des objets

^Page

^0..*

^0..*

^{Zone de saisie}

^Interface

^{1..1 1..*}

^1..1

^1..1

^1..1

^0..*

^{1..* 1..1}

^{0..* 0..1}

^Formulaire

^Bouton

Figure 22: Noyau de présentation

ANALYSE ET CONCEPTION

? Le noyau applicatif

Contient les éléments pour rafraichir les vues, gérer les exceptions, charger les modèles de fonctionnement et contrôler les commandes d'une application.

? Le noyau métier

Définit les éléments permettant d'identifier les objets métier et de définir leurs attributs caractéristiques.

? Le noyau d'accès aux données

Définit les mécanismes de chargement, de sauvegarde de mise à jour et de recherche des objets.

? Le noyau sécurité

Pilote les règles de sécurité pour les accès aux environnements de travail définis pour les acteurs du système. Il définit aussi les mécanismes d'authentification.

^Avoir

^{1..* 1..1}

^Rôle

^Privilège

^1..1

^{1..* 1..*}

^1..*

^1..*

^1..*

^Utilisateur

^Session

^Interface

41

Figure 23 : Le noyau de sécurité

42

ANALYSE ET CONCEPTION

c) Diagramme de déploiement

^Smartphone

^{Application mobile}

^<<HTTP>>

^Serveur

^{Administration}

^{Javascript+html}

^Navigateur

^{Web Services: JSON}

^<<HTTP>>

^PHP

^SGBD

^MySQL

Figure 24:Diagramme de déploiement

d) Diagramme de composants

^{<<Component>>}

^View

^{Notify changes Changes setting}

^{Port_1 Port_2}

^Port_1

^{Android Services}

^{<<Component>>}

^Model

^{Android widget}

^Port_1

^{<<Component>>}

^Controller

Figure 25: diagramme de composants

43

ANALYSE ET CONCEPTION

4. CONCLUSION

L'analyse du système étant élaborée, elle nous a permis de comprendre le fonctionnement du système à mettre en place. Le document d'analyse ainsi obtenu permettra d'entreprendre la réalisation du logiciel en répondant aux besoins du département commercial de TOGO 3000 INFORMATIQUE.

44

REALISATION ET MISE EN OEUVRE

Chapitre 3

REALISATION ET MISE EN OEUVRE

La phase d'analyse et de conception nous a conduits à déterminer les données à utiliser dans le domaine de notre étude et les traitements qui y seront effectués. Nous allons à présent entamer la réalisation ainsi que la mise en oeuvre de l'application. Il s'agit de l'étape de développement de l'ouvrage proprement dite. Dans cette partie du document, nous présenterons la technologie utilisée, les matériels et le système d'exploitation adopté, les outils de développement, et l'architecture de l'application. L'accent sera mis sur les politiques de sécurité de l'application ainsi que les pratiques de programmation mises en oeuvre.

1. MISE EN OEUVRE 1.1. Choix matériels

Pour la réalisation de la solution retenue pour notre projet, nous avons utilisés 1 laptop

ayant pour caractéristiques :

+ Processeur : Intel® coreTM i3-6006U CPU @ 2.00GHz 2.00GHz

+ Mémoire RAM : 4Go

+ Disque dur : 465 Go

+ Carte réseau : Oui

+ Lecteur : DVD Blue ray

+ Graveur : Oui

+ Systèmes d'exploitation : Windows10 Professionnel

Et un Smartphone Android Infinix HOT7, modèle Infinix X624, version d'Adroid 8.1.0

1.2. Choix logiciels

La rubrique des logiciels choisis est scindée en deux (2) parties :

+ Outils de développement + Langages et technologies

1.2.1. Outils de développement

a) Environnement de développement : Android Studio

Android Studio permet principalement d'éditer les fichiers Java et les fichiers de configuration XML d'une application Android.

Il propose entre autres des outils pour gérer le développement d'applications multilingues et permet de visualiser rapidement la mise en page des écrans sur des écrans de résolutions variées simultanément. Il intègre par ailleurs un émulateur permettant de faire tourner un système Android virtuel sur un ordinateur.

45

REALISATION ET MISE EN OEUVRE

b) Gestionnaire de version « Git »

Git est un système de Gestion de Version décentralisé très populaire et utile pour le suivi, la gestion du cycle de vie d'une application, le travail collaboratif et la gestion des risques. GIT permet de conserver l'historique des versions dans un dépôt (repository).

Il est très utile :

+ Pour revenir facilement et à tout instant en arrière, en récupérant les fichiers d'un état précédent. Cela peut représenter une part non négligeable du (sur)coût en cas d'absence de système de Gestion de Version.

+ Pour suivre l'évolution d'un fichier texte ligne de code par ligne de code

+ Pour ajouter, modifier, supprimer les fichiers,

+ Pour gagner du temps et de l'efficacité dans la livraison,

+ Pour faciliter le travail collaboratif et gérer correctement les modifications concurrentes des fichiers, la fiabilité du code conservé, et ne permettre que les changements autorisés,

+ Pour identifier rapidement les impacts, car on peut faire de la vraie relecture de code a priori très simplement avec la gestion des branches simplifiés

1.2.2. Systèmes de gestion de base de données : SQLite et MySQL

Derrière toute application informatique appelée à manipuler des informations, il faut un système dédié à la gestion des différentes bases de données. Pour la gestion de la base de données de notre système, nous retenons « SQLite » en local et « MySQL » comme serveur distant.

SQLite est une bibliothèque écrite en C qui propose un moteur de base de données SQL. Contrairement aux serveurs de bases de données comme MySQL ou PostgreSQL, elle ne reproduit pas le schéma habituel client-serveur mais elle est directement intégrée aux programmes en utilisant des fichiers de bases de données. L'intégralité de la base de données (déclarations, tables, index et données) est stockée dans un fichier indépendant de la plateforme.

MySQL est un serveur de base de données SQL multi-utilisateurs et multithreads fonctionnant sous Linux et Windows. Ses principaux atouts sont :

- La rapidité et la robustesse

- La facilité d'utilisation et la gratuité

1.2.3. Langages et technologies a) Langages

? JAVA

Java est le langage le plus utilisé dans le développement Android. Il s'agit en fait du langage qui a été choisi par Google pour créer des applications Android. Avec un petit coup de main de Google, qui nous fournit l'environnement de développement Android Studio, nous pourrons créer notre application.

46

REALISATION ET MISE EN OEUVRE

? XML

Nous utilisons ce langage de balisage pour gérer l'affichage des contenus sur l'écran. Bien qu'il n'est pas indispensable pour créer une application Android, il facilite le développement en permettant de séparer l'affichage des algorithmes. Ce qui nous fait gagner du temps et nous simplifie le code de l'application, et permet ainsi d'éviter des erreurs.

? PHP

Nous utilisons ce langage de script pour créer l'API REST qui va nous permettre de communiquer avec le serveur.

b) Technologies

Pour la réalisation de notre solution, nous avons le choix entre 3 plateformes majeures qui permettent de développer sur mobile : Android, iOS, Windows Phone. Mais pour cibler ces plateformes, nous avons le choix entre du web (application web adaptatif), du natif (application mobile spécifique pour une plateforme), et de l'hybride (Multi-plateformes). Dans cette partie du document nous présentons les critères qui ont guidé nos choix.

? Etude des différentes technologies de développement mobile

Plateforme	Avantages	Inconvénients
	· Pas de téléchargement	· Ne fonctionne pas hors
· Pas de mise à jour (les	connexion
nouvelles versions sont	· Expérience utilisateur moins
disponibles automatiquement	intéressante que sur une
en temps réel)	application native. Moins	Le web
· Pas d'utilisation du stockage	interactif et intuitif. L'URL
de l'appareil	rajoute une étape dans le
· Plus facile à développer, facile	processus et complique
à construire et à déployer	l'expérience utilisateur
· Moins coûteux	· Plus lent que les applications
· Plus ouverts comparés aux	natives
applications natives	· Ne convient pas à certains
· Une application pour toutes les	besoins (notamment ceux
plateformes, tant qu'elle	qui nécessite du
fonctionne sur un navigateur)	développement complexe)
	· Accès plus difficile aux fonctionnalités du smartphone

REALISATION ET MISE EN OEUVRE

Le natif		L'hybride

· Stables, rapides et adaptatif car

construites pour une
plateforme spécifique

· Accès aux fonctionnalités de l'appareil

· Plus puissantes, plus poussées

· L'expérience utilisateur est la meilleure, c'est fluide, intuitif et interactif

· Ne nécessite pas une connexion internet

·

· Code multi-plateforme : Un seul code pour créer une application sur Android & iOS.

· Un développeur JavaScript suffit pour la création d'une application.

· Plus simple pour trouver la cause d'un bug, car React

Native utilise la
programmation déclarative.

· Le rechargement instantané, permet de mettre à jour l'application pendant qu'elle est utilisé. Ce qui avantage la procédure de mise en production (cependant l'Apple Store ...)

·

L'application est sur l'écran d'accueil de l'utilisateur

· Nécessite un développement pour chaque OS · Nécessite d'apparaître sur un store · Les contraintes de Apple et Google peuvent être très importantes dans le développement · Plus long à développer et plus coûteux. L'hybride peut cependant aider à couper les coûts · Ne convient aux projets de développement très simple.		· Fonctionnalités : Pas toutes les fonctionnalités propres aux smartphones sont accessibles en langage hybride. Il faut alors développer certaines fonctionnalités en langage natif pour pouvoir les utiliser depuis React Native. · Gestion des performances : un langage hybride n'a pas la même performance qu'un langage natif. Réduction des performances lors d'utilisation de grosses données. · Navigation moins fluide : React Native n'a pas de solution idéale pour naviguer entre les interfaces, ce qui contraint l'expérience utilisateur. · Profile de développeur compliqué à trouver, connaissance du Web (JS) + connaissance du langage natif pour utiliser certaines fonctionnalités.

47

Tableau 14: avantages et inconvenients de chaque plateforme mobile

48

REALISATION ET MISE EN OEUVRE

? Notre choix

Pour choisir il faut prendre en compte plusieurs critères imposés par le projet. Voici quelques éléments sur lesquels nous nous sommes basés pour faire le choix.

+ L'utilisateur doit pouvoir accéder à l'application même en étant hors ligne (sans connexion internet) ; ce qui écarte systématiquement l'option de développement d'une application web.

+ Tous les employés du département commercial de TOGO 3000 Informatique disposent d'un smartphone Android ; ce qui n'est pas le cas concernant les autres plateformes mobiles ; ce qui écarte le développement d'une application iOS ou Windows.

+ L'application n'est pas destinée au grand public mais sera conçu spécialement pour le département commercial de TOGO 3000 Informatique.

En tenant compte de tous ces paramètres, nous tournons notre choix vers le développement d'une application native spécifiquement pour la plateforme Android.

1.3. Sécurité de l'application

Il est primordial de nos jours de développer une application dans une logique de sécurité dès le départ et tout au long du processus. Étant donné qu'il n'existe pas de solution miracle pour détecter toutes les vulnérabilités des applications mobiles, nous avons préconisé mettre en place ces règles à suivre pour garantir la sécurité de notre application :

1.3.1. Sécurisation de l'accès aux données

+ L'utilisateur doit s'authentifier avant de pouvoir accéder à l'application. Cela permet de s'assurer qu'il n'y a pas eu usurpation d'identité.

+ Les messages d'erreur renvoyés doivent être génériques pour ne pas aiguiller les attaquants potentiels.

+ Les données sensibles doivent être chiffrées dans la base de données.

+ La protection des mots de passe, des identifiants de session afin de permettre de se prémunir contre l'usurpation d'identité. Pour cela, le mot de passe doit avoir au moins huit caractères, voire dix pour les accès aux données sensibles(administration). Il doit également contenir au moins trois types de caractères, tels que des chiffres, des lettres minuscules, des lettres majuscules ou des caractères spéciaux. Il doit avoir une période de validité de quatre-vingt-dix jours au maximum. Au-delà, il doit être changé.

+ Le compte de l'utilisateur doit être verrouillé, au moins temporairement, si trois tentatives de connexion consécutives ont échoué.

+ Le mot de passe doit être chiffré ou haché avec un algorithme fort. Seule sa valeur chiffrée sera comparée lors de l'authentification de l'utilisateur.

+ Un système de déconnexion automatique doit être mis en place en cas de fermeture de l'application.

1.3.2. Vérification des données

Les valeurs saisies dans un formulaire doivent être validées avant d'être envoyées dans la base, car le client n'est pas toujours une source fiable. Pour cela il faudrait :

49

REALISATION ET MISE EN OEUVRE

+ Vérifier que le type de caractère ou la valeur saisie correspond à celui ou celle

attendue ;

+ Pour plus de sécurité, les données seront converties dans le bon format avant de les

mettre dans des variables ;

+ Vérifier la présence de tous les arguments attendus ;

+ Pour les nombres, contraindre la valeur entre deux bornes ;

+ Pour les listes, vérifier que la valeur appartient à la liste des valeurs autorisées ;

+ Contraindre la longueur de la valeur saisie avec une taille minimale et une taille

maximale ;

+ Vérifier la valeur avec une expression régulière ;

+ N'accepter que les lettres de l'alphabet et/ou les chiffres par défaut, tous les autres

caractères devant être refusés. Dans le cas où d'autres caractères doivent être

autorisés, ils doivent être limités à une liste prédéfinie ;

+ Vérifier si la valeur nulle doit être acceptée ;

+ Définir le jeu de caractères de la donnée.

Même les données envoyées vers l'utilisateur doivent être vérifiées, avec un minimum

d'action.

1.3.3. Sécurité de la base de données

+ Contrôle de l'accès à la base de données

+ Protection des données sensibles grâce au chiffrement + Sauvegarde régulière de la base de données

50

REALISATION ET MISE EN OEUVRE

1.4. Architecture physique de l'application

Figure 26: Architecture physique de l'application

1.5. Gestion des tests

La phase de test, représente une partie importante de tout projet logiciel dont le but est d'arriver à un produit « zéro défaut ». Cette phase nous a permis de détecter les problèmes ou les bugs de manière à pouvoir les corriger avant le déploiement de l'application. Les tests constituent en effet la base permettant de gérer les remontées d'anomalies (confère annexe 2).

Nous utilisons trois types de tests comme décrit ci-dessous 1.5.1. Les tests unitaires

Ces tests se sont faits sur chaque unité de notre application. Ils présentent une procédure permettant de vérifier et tester chaque partie de notre application ou chaque module, indépendamment du reste du programme, ceci afin de s'assurer qu'il répond aux spécifications fonctionnelles. Et qu'il fonctionne correctement en toutes circonstances.

51

REALISATION ET MISE EN OEUVRE

1.5.2. Les tests d'intégration

Ces tests ont suivi les tests unitaires. Ces tests d'intégration ont consisté à assembler toutes les parties de l'application afin de tester l'ensemble. Ce qui nous a permis de valider leur cohérence après l'intégration

1.5.3. Les tests d'acceptation ou (recette)

Ces tests se sont passés à chaque sprint. Ils consistaient à vérifier que le système livré est opérationnel et fonctionne conformément aux besoins initiaux du client

1.6. Rapport de réalisation 1.6.1. Processus

La phase de réalisation a commencé par la description des fonctionnalités du produit dans des Users Stories¹⁰ . Chaque User Story comprend un identifiant, un nom (descriptif court), une priorité, une estimation de la charge de travail, la description d'un test de validation et éventuellement des commentaires. C'est en fait un élément des spécifications fonctionnelles.

Ensuite un référentiel des besoins (le product backlog¹¹) a été créé. Il regroupe l'ensemble des Users Stories décrites, donc l'ensemble des fonctionnalités désirées, hiérarchisées par ordre de réalisation souhaité. La product backlog a évolué durant tout le projet à partir des nouvelles fonctionnalités voulues par le client.

Le déroulement de cette phase du projet a été organisé en itérations, ou sprints¹². Chaque sprint a duré trois semaines. Une réunion de planification était organisée avant le début de chaque sprint, afin de sélectionner les fonctionnalités qui seront réalisées durant le sprint. L'ensemble des fonctionnalités qui doivent être implémentées au cours du sprint composent le sprint backlog¹³. La fin De chaque sprint a été marquée par une démonstration des derniers développements effectués. Cette démonstration permettait de valider la correspondance entre les besoins exprimés et les fonctionnalités réalisées. Un bilan est fait également, lors d'une réunion d'examen du sprint. Ce qui nous permettait de mettre en avant ce qui allait bien, ce qui allait moins bien et proposer des axes d'améliorations. A la fin du dernier sprint, le produit fini a été remis au client.

1.6.2. Comptes rendus

¹⁰ User stories : une description simple d'un besoin ou d'une attente exprimée par un utilisateur et utilisée dans le domaine du développement de logiciels et de la conception de nouveaux produits pour déterminer les fonctionnalités à développer.

¹¹ le backlog scrum est destiné à recueillir tous les besoins du client que l'équipe projet doit réaliser. Il contient donc la liste des fonctionnalités intervenant dans la constitution d'un produit, ainsi que tous les éléments nécessitant l'intervention de l'équipe projet.

¹²Un sprint est une itération de développement de la méthode Scrum.

¹³ Le sprint backlog est une partie des user stories du backlog produit que l'équipe s'engage à livrer d'ici la fin du sprint

52

REALISATION ET MISE EN OEUVRE

Participants
Nom	Fonction	Rôle
KASSANKOGNO Essowiyaou	Stagiaire	Analyste développeur
M. ADJOGBLE Komlavi Mawuli	Informaticien	Validation du produit par rapport aux besoins du client
Mme DAMADO Djigbodi Pascaline	Directrice de l'administration et Chef service commercial	Explication des besoins

Tableau 15 : participants à la phase de réalisation

a) Rapport du sprint 1

Projet : Conception et réalisation d'une application mobile de gestion commerciale : cas du département commercial de TOGO 3000 INFORMATIQUE				SPRINT 1 Carnet de sprint (sprint backlog) :
				Ø Implémentation des fonctionnalités de gestion des utilisateurs Ø Implémentation des fonctionnalités de gestion des fournisseurs Ø Implémentation des fonctionnalités de gestion des produits Ø Implémentation des fonctionnalités de gestion des cotations			Phase : Réalisation et mise en OEuvre
Date fin 05/07/2019				Incrément I : L'utilisateur peut se connecter à l'application, enregistrer un fournisseur, enregistrer un produit puis envoyer une demande de cotation au fournisseur. L'utilisateur a le choix de générer automatiquement la demande de cotation qu'il peut lancer vers l'imprimante à partir de son téléphone ou la transmettre automatiquement au fournisseur via son compte mail ou vers un autre compte de messagerie. Produit=Incrément I
Fini : Tous les éléments du carnet de sprint
Validation :
Délais	Réalisé dans le respect des délai établis
	Les coûts ont été respectés
	Délais de réponse acceptable		Apports du maître de stage (Scrum master) : Proposition de l'optimisation au niveau de l'IHM^14
Difficultés : les besoins n'étant pas tous identifiés dès le départ, cela demande une adaptation continue par rapport aux nouveaux besoins de l'utilisateur.
Participants
Nom
Fonction		Rôle				KASSANKOGNO Essowiyaou
Stagiaire		Analyste programmeur

¹⁴ Interface Homme-Machine

53

REALISATION ET MISE EN OEUVRE

M. ADJOGBLE Justin	Informaticien		Validation du produit par rapport aux besoins du client	Mme DAMADO Djigbodi Pascaline
Directrice de l'administration et Chef service commercial	Explication des besoins

Tableau 16: Rapport SPRINT 1

b) Rapport du sprint 2

Projet : Conception et réalisation d'une application mobile de gestion commerciale : cas du département commercial de TOGO 3000 INFORMATIQUE Phase : Réalisation et mise en OEuvre				SPRINT 2 Eléments du carnet de sprint (sprint
				Date début 08/07/2019
Date fin 26/07/2019				Incrément II : Après réception de la facture pro-forma du fournisseur, l'utilisateur a la possibilité via l'application de valider la facture pro-forma puis commander les lignes de produit dont le prix le convient et générer automatiquement un bon de commande qui peut être lancé vers l'imprimante à partir du téléphone ou transmis automatiquement au fournisseur via son compte mail ou vers un autre compte de messagerie. L'utilisateur a aussi la possibilité d'enregistrer les factures et les règlements de la facture-fournisseur, ainsi que l'enregistrement de la réception de marchandise. L'enregistrement de la réception de marchandise prend en compte les taxes et les frais de livraison et de transport qui permettent ainsi un calcul automatique des coûts d'achats et du prix de vente de la marchandise. Produit = Incrément I + Incrément II
Finis : Tous les éléments du carnet de sprint
Validation :
Délais		Réalisé dans le respect des délais établis
		Les coûts ont été respectés
		Délais de réponse acceptable	Apports du maître de stage (Scrum master) : Proposition de l'amélioration de la mise en forme des états générés
Difficultés : la remise et la tva s'appliquent-elles sur les lignes de commande ou sur toute la commande ? Solution : permettre les deux options à l'utilisateur. L'utilisateur aura à choisir l'une ou l'autre suivant les cas
Participants
Nom Fonction Rôle

REALISATION ET MISE EN OEUVRE

KASSANKOGNO Essowiyaou	Stagiaire		Analyste développeur	M. ADJOGBLE Justin
Informaticien	Validation du produit par rapport aux besoins du client		Mme DAMADO Djigbodi Pascaline
Directrice de l'administration et Chef service commercial	Explication des besoins

Tableau 17: Rapport SPRINT 2

54

c) Rapport du sprint 3

Projet : Conception et réalisation d'une application mobile de gestion commerciale : cas du département commercial de TOGO 3000 INFORMATIQUE Phase : Réalisation et mise en OEuvre		SPRINT 3 Eléments du carnet de sprint (sprint
		Date début 29/07/2019
Date fin 16/08/2019

55

REALISATION ET MISE EN OEUVRE

Incrément III : La réception de la marchandise entraine automatique son entrée en stock. L'utilisateur a ainsi la possibilité de définir la marge bénéficiaire sur le produit afin que l'application mette à jour automatiquement le prix de vente de l'article en tenant compte de la marge bénéficiaire défini. Les produits rentrés en stock sont alors disponibles pour la vente. La version actuelle donne la possibilité à l'utilisateur de : + Gérer les clients/prospects ; + Enregistrer les demandes de devis-clients ; + Générer automatiquement la facture proforma et la lancer lancée vers l'imprimante à partir du téléphone ou la transmettre au fournisseur via son compte mail ou vers un autre compte de messagerie ; + Enregistrer la commande-client. Produit = Incrément I + Incrément II + Incrément III						Fini : Tous les éléments du carnet de sprint
Validation :
Délais		Réalisé dans le respect des délai établis
		Les coûts ont été respectés
		Délais de réponse acceptable		Apports du maître de stage (Scrum master) : Aucun
Difficultés : aucune
Participants
Nom
Fonction			Rôle		KASSANKOGNO Essowiyaou
Stagiaire			Analyste développeur		M. ADJOGBLE Justin
Informaticien			Validation du produit par rapport aux besoins du client		Mme DAMADO Djigbodi Pascaline
Directrice de l'administration et Chef service commercial			Explication des besoins

Tableau 18: Rapport SPRINT 3

d) Rapport du sprint 4 Projet : Conception et réalisation d'une application mobile de gestion commerciale : cas du département commercial de TOGO 3000 INFORMATIQUE		SPRINT 4 Eléments du carnet de sprint (sprint backlog) : Ø Implémentation des fonctionnalités
de gestion des factures/client Ø Implémentation des fonctionnalités de gestion des livraisons		Phase : Réalisation et mise en OEuvre
		Implémentation de déstockage	des fonctionnalités
		Implémentation	des fonctionnalités

de gestion cautions bancaires

56

REALISATION ET MISE EN OEUVRE

Date début 19/08/2019 Date fin 06/09/2019						Incrément IV : Après l'enregistrement de la commande du client, l'utilisateur a la possibilité de générer automatiquement la facture qui peut être lancée vers l'imprimante à partir du téléphone ou transmise automatiquement au fournisseur via son compte mail ou vers un autre compte de messagerie. Une fois la facture réglée par le client un bon de livraison est transmis au service livraison qui déstocke les produits puis enregistre la livraison des marchandises ; cette livraison entraine une décrémentation automatique du stock au niveau de l'application. L'utilisateur a aussi la possibilité d'enregistrer une caution sur marché si besoin dont l'application tiendra compte des dates pour alerter sur le délai de libération de la caution. Produit = Incrément I + Incrément II + Incrément III + Incrément IV
Fini : Tous les éléments du carnet de sprint
Validation :
Délais		Réalisé dans le respect des délai établis
		Les coûts ont été respectés
		Délais de réponse acceptable		Apports du maître de stage (Scrum master) : Aucun
Difficultés : identification de tous les paramètres intervenant dans le calcul des coûts et du prix de vente des produits.
Participants
Nom
Fonction			Rôle		KASSANKOGNO Essowiyaou
Stagiaire			Analyste développeur		M. ADJOGBLE Justin
Informaticien			Validation du produit par rapport aux besoins du client		Mme DAMADO Djigbodi Pascaline
Directrice de l'administration et Chef service commercial			Explication des besoins

Tableau 19: Rapport SPRINT 4

e) Sprint 5

Projet : Conception et réalisation d'une application mobile de gestion commerciale : cas du département commercial de TOGO 3000 INFORMATIQUE Phase : Réalisation et mise en OEuvre		SPRINT 5 Eléments du carnet de sprint (sprint
Date début 09/09/2019		Date fin 27/09/2019

57

REALISATION ET MISE EN OEUVRE

Incrément V : L'administrateur a la possibilité de gérer les paramètres du système ainsi que d'administrer la base de données. Produit = Incrément I +Incrément II + Incrément II + Incrément IV + Incrément V
Fini : Tous les éléments du carnet de sprint
Validation :	Délais	Réalisé dans le respect des délai établis
	Coûts	Les coûts ont été respectés
	Performance	Délais de réponse acceptable
Apports du maître de stage (Scrum master) : Amélioration de l'IHM des interfaces d'administration.
Difficultés : difficulté d'implémentation des certaines fonctionnalités relatives à l'administration de la base de données SQLite.

Tableau 20: Rapport SPRINT 5

2. PRESENTATION DE L'APPLICATION

2.1. Présentation

L'application mise en place est une solution mobile permettant d'accélérer la gestion de l'activité commerciale de TOGO 3000 INFORMATIQUE en automatisant l'exécution des opérations commerciales. L'application conçue, dans sa version actuelle permet de consulter, mettre à jour, créer de nouveaux clients, fournisseurs ou prospects, de les contacter directement via l'application : de gérer les ventes et les achats. Elle permet en effet de créer directement sur smartphone les commandes, devis, factures, bons de livraison, et de les imprimer ou de les envoyer par mail.

La consultation des statistiques est gérée telles que le nombre de ventes et d'achats durant une période donnée, le bénéfice fait durant une période, et le nombre d'articles vendus. Ainsi il est proposé une alerte sur les évènements urgents tels que le délai de paiement d'une facture, le délai de retour sur caution et bien d'autre.

L'application permet précisément de :

v Stocker de façon cohérente, fiable et sécurisée toutes les informations relatives à la gestion commerciale ;

o Gestion des relations (fournisseurs, clients, prospects) ;

o Gestion des achats (les cotations, les commandes, les factures, la réception de marchandise) ;

o Gestion des ventes (les devis-client, les commandes-client, la facturation, la livraison) ;

o Gestion du stock et produits (enregistrement des entrées-sorties en stock, mise à jour des produits, calcul automatique du prix des produits, alerte sur le niveau du stock) ;

o Gestion des cautions (alerter sur les délais de retour du document de caution) ;

v Assurer l'accessibilité des informations en temps réel ;

v Éviter la répétition de certaines tâches et des erreurs liées au traitement manuel des données ;

58

REALISATION ET MISE EN OEUVRE

v Gérer l'accès aux différentes informations liées à la gestion commerciale ;

v Générer automatiquement des états lies à la gestion commerciale ;

v Assurer la traçabilité de toutes les actions des utilisateurs ;

v Alerter sur les évènements urgentes ;

v Planifier, suivre et évaluer les différentes tâches commerciales.

REALISATION ET MISE EN OEUVRE

^Connexion

^{Créer un compte}

2.2. Structure de l'application

^{Mot de passe oublié}

^Accueil

^{Gestion paramètres}

^{Gestion stock}

^Utilisateurs

^{Gestion produits}

^Système

^{Gestion livraisons}

^Gestion achats	^Gestion ventes
^Gestion relations

59

^{Demandes de cotations}

^Commandes

^{Règlements factures}

^{Reception Marchandises}

Figure 27: structure de l'application

60

REALISATION ET MISE EN OEUVRE

3. GUIDE D'EXPLOITATION

3.1. Configuration matérielle et logicielle

3.1.1. Performances minimales des smartphones clients

Performance minimale pour un meilleur rendu des fonctionnalités qu'offre l'application :

§ Système d'exploitation : Android

§ Version minimale 7.0.0;

3.1.2. Performances minimales du serveur de base de données distant

Caractéristiques de la machine hôte :

§ Système d'exploitation : Windows 7 ou UNIX/Linux

§ Processeur : 2.2 GHz ;

§ Disque dur : 320 Go ;

§ Mémoire RAM : 4 Go (conseillée) ;

§ Clavier et souris ;

3.2. Déploiement et suivi

3.2.1. Déploiement de l'application

a) Création de la base de données

Pour créer la base de données centralisée, suivre les étapes suivantes :

Exécution du script de la page http://le_serveur/nom_espace/bd.php (lien confidentiel) ; script contenant la création de la base de données et des tables en ligne ; Accessible uniquement par l'administrateur. Le script de création de la base de données (Annexe 1).

b) Mise en production en local

Il existe différentes manières de signer une application Android. Cela est assez simple avec l'utilisation d'Android Studio. Ci-dessous les démarches étape par étape pour créer votre APK avec sa signature :

· Ouvrez votre projet d'application dans Android Studio. Cliquez sur « Build » dans le menu puis « Generate Signed APK ».

· Dans la nouvelle fenêtre qui apparaît, définissez ce que l'on appelle le Key Store Path (l'emplacement pour sauvegarder votre signature - la clé). Si vous êtes déjà passé par cette étape pour une autre application Android, vous pouvez tout simplement réutiliser le dossier. Si vous n'avez en revanche jamais créé de Key Store Path ou si vous souhaitez en créer un nouveau pour votre application, définissez votre emplacement et créez un mot de passe (nous vous conseillons par ailleurs de noter ce Key Store Path pour vos utilisations futures). Ensuite, entrez sous « Alias » le nom de la clé puis enfin le mot de passe. La durée de validité de la signature doit également être stipulée (préférablement au moins 25 ans) ainsi qu'au moins une

61

REALISATION ET MISE EN OEUVRE

information personnelle sur le certificat (par exemple votre nom ou celui de votre entreprise).

· Après avoir choisi un nouvel ou ancien emplacement pour votre signature et entré le mot de passe nécessaire, passez à l'étape suivante en cliquant sur « Next ». Vous pouvez alors indiquer si vous installez une version test de l'application (« debug ») ou l'application finale (« release »). Dès que vous avez choisi la version Release sous « Build type », il est nécessaire de remplir les champs donnés et notamment indiquer si vous souhaitez que votre application soit gratuite ou payante (avec Windows ou Linux, en utilisant la touche Strg / pour Mac avec l'aide de la touche de commande). Une fois les paramètres définis, confirmez vos choix en sélectionnant « Finish ». Le fichier APK signé est généré dans le dossier choisi et peut permettre le lancement de votre app sur Play Store.

c) Mise en production en réseau

Pour pouvoir publier l'application sur Google Play, il est nécessaire de s'enregistrer sur de nombreuses plateformes : outre le compte général Google, nous devons également compter sur un accès à Google Play Developer Console.

Une fois en ligne, avant de pouvoir télécharger l'application sur une boutique en ligne, plusieurs comptes Google doivent être créés.

· Tout d'abord, la création d'un compte général Google. Si l'on n'a pas de compte ou si l'on souhaite en créer un spécifiquement pour l'application, rendez-vous sur la page d'inscription de Google.

· Une fois le compte créé, on s'enregistre sur le site Google Play Developer Console. Pour devenir membre de cette plateforme, des frais uniques de 25 dollars US sont à payer par carte bancaire. Le compte personnel Developer Console est alors prêt à l'emploi après avoir fourni les informations requises A savoir, le « nom du développeur » qui sera utilisé comme nom d'auteur sur Google Play Store. Il sera possible toutefois de le changer ultérieurement.

· Après avoir créé tous les comptes Google exigés, on peut charger l'application pour le Play Store. L'application ne sera pas immédiatement disponible sur Google Play Store, car chaque nouvelle application doit d'abord être vérifiée par Google avant sa publication. Le temps nécessaire à sa publication varie suivant les cas. La plupart du temps, l'application est tout de même disponible seulement quelques heures plus tard.

62

REALISATION ET MISE EN OEUVRE

· L'application se télécharge sur le Google Play Developer Console. Après s'être logué sur la plateforme, un clique sur « Toutes les applications » puis « Créer une application ». Indiquez la langue utilisée pour l'application et entrez un nom (même si vous pourrez modifier ces deux informations plus tard). En cliquant sur « Téléchargement APK », vous atterrissez sur un nouveau menu qui porte le nom de votre application. Sur la gauche, vous trouverez ensuite différentes rubriques (« APK », « Classification du contenu » etc.) auxquelles vous pouvez vous consacrer.

3.2.2. Suivi de l'application

Le suivi de l'application consiste à relever tout incident se produisant au cours de l'exploitation. Ces relevés serviront de support pour une maintenance voire une mise à jour de l'application. Afin de pouvoir conserver ces erreurs, elles seront notées dans un registre d'évènements que l'administrateur devra tenir. Les utilisateurs de l'application disposent eux aussi de la page suggestion pour soumettre les erreurs ou bugs auxquels ils seront confrontés ainsi que les améliorations qu'ils proposent pour une meilleure optimisation de l'application.

De plus l'absence d'une politique de sauvegarde des données d'une application est un fait délicat et pourrait couter chère à la vie d'une entreprise. Il est donc nécessaire d'instaurer une politique de sauvegarde.

4. GUIDE D'UTILISATION

Le guide d'utilisateur est un document très important pour l'utilisation d'une application. Il est d'une grande utilité pour la formation des futurs utilisateurs de l'application. Il décrit les différentes fonctionnalités de l'application. Le présent document permet d'expliquer le fonctionnement de notre application.

63

REALISATION ET MISE EN OEUVRE

4.1. Présentation de l'application

4.1.1. Interface de connexion et d'accueil

Figure 28: 1.1 Interface de connexion et d'accueil

64

REALISATION ET MISE EN OEUVRE

4.1.2. Menus, boutons et champs

						Champ de saisie, le libelle à l'intérieur indique l'information à saisir.
						Bouton, le libelle indique l'action du bouton
						Boutons de la page d'accueil, les libellés indique vers quel module le bouton nous dirige.
						Bouton retour vers la précédente page
						Bouton permettant de réinitialiser le mot de passe
						Bouton permettant de créer un nouveau compte
						Bouton permettant de retourner vers l'interface de connexion
						Bouton permettant d'ajouter de créer un nouvel enregistrement
						Bouton permettant de trier les informations
						Bouton permettant d'effectuer une recherche
						Bouton permettant de synchroniser les données avec le serveur
						Boutons permettant de naviguer sur les pages de données

65

REALISATION ET MISE EN OEUVRE

Liste d'informations. En gris les informations synchronisées avec le serveur et en rouge celles qui ne sont pas encore envoyé vers le serveur.

Tableau 21 : menus, boutons et champs

66

REALISATION ET MISE EN OEUVRE

4.1.3. Navigation

Figure 29: architecture de navigation de l'application

67

REALISATION ET MISE EN OEUVRE

4.2. Maintenance

4.2.1. Les erreurs courantes

Certaines erreurs courantes que pourra générer notre application sont résumées dans le tableau ci-dessous avec les actions à mener :

Code Erreur	Description	Action à mener
Échec de synchronisation avec la base de données.	Impossible d'envoyer les données locales vers la base de données distante	Il faut vérifier si la connexion internet est bonne ; si ce n'est pas un souci de connexion internet, redémarrer le serveur et s'assurer que la base de données est bien installée (Administrateur)
Problèmes de fonctionnement	L'application plante, ne s'ouvre pas, ne répond pas ou ne fonctionne pas correctement.	Étape 1 : Redémarrez l'appareil et effectuez les mises à jour - Redémarrer l'appareil - Vérifier les mises à jour Android - Mettre l'application à jour Si le problème persiste, - Forcer l'arrêt de l'application - Vider le cache de l'application - Supprimer les données de l'application - Contacter le développeur de l'application - Désinstaller l'application
Erreur 505	L'application n'est pas compatible avec la version d'Android du terminal.	Annuler le téléchargement et attendre qu'elle soit compatible ou de le signaler aux développeurs.
Erreur 905	Échec de téléchargement de l'application	Désinstaller les mises à jour du Play Store
Erreur 941	Impossibilité d'effectuer une mise à jour de l'application	Vider le cache du Play Store

68

REALISATION ET MISE EN OEUVRE

Erreur 919	L'espace de stockage disponible sur votre terminal est insuffisant pour installer l'application	Supprimer des applications inutiles
Erreur 101	Le téléchargement ne	Désinstallez les
	fait pas suite à la mémoire	applications inutiles pour
	pleine	récupérer de l'espace de stockage. Si cela persiste, supprimer le cache du Google
		Play Store : Paramètres /
		Applications / Google Play
		Store / Supprimer le cache et les données

Tableau 22: description des erreurs courantes et les actions à mener

4.2.2. Les autres erreurs

En cas d'erreur, dans l'application, autre que celles citées dans le tableau ci-dessus, l'utilisateur doit informer l'administrateur ou se rendre à la Direction le signaler.

5. CONCLUSION

Dans cette partie de notre document, nous avons décrit les différents outils qui ont contribué au développement de notre plateforme, son architecture, les interfaces de la version actuelle de l'application, ainsi que le guide d'utilisation et le guide d'exploitation de l'application. Cette partie du document conclut ainsi le rapport de la phase de réalisation du projet.

69

CONCLUSION GENERALE

CONCLUSION GENERALE

Cette étude a consisté à la réalisation d'une application mobile de gestion commerciale au sein de l'entreprise TOGO 3000 INFORMATIQUE en utilisant un ensemble de processus de gestion de projet qui nous ont permis de faire face aux contraintes et à l'évolution des besoins exprimés au cours de la réalisation. Le processus unifié 2TUP a été utilisé dans la gestion globale du projet alors que la méthode agile SCRUM nous a servi pour la gestion de la phase de réalisation. Il faut noter que cette gestion du projet avec deux processus imbriqués très flexibles a été d'une grande efficacité lorsqu'il s'agissait d'adapter le projet par rapport à l'évolution des besoins du client qui devenait de plus en plus exigent au cours du projet quant aux nouvelles fonctionnalités à intégrer dans l'application ; des fonctionnalités qui n'était pas prévues dès le début du projet. Et comme résultat notre application intègre tous les modules implémentant des fonctionnalités répondant avec efficacité aux besoins du département commercial de TOGO 3000 INFORMATIQUE.

Une première version de l'application étant actuellement en expérimentation, la prochaine étape consistera à s'assurer de sa conformité par rapport à tous les besoins exprimés afin de la mettre en production. Mais d'ores et déjà, elle permet de tester tous les scénarios de l'activité commerciale. On pourra aller au-delà en y ajoutant un module de contrôle de la gestion des activités commerciales qui permettra aux responsables de mieux piloter ces activités. Les différents modules de notre application pourront servir de base à la conception d'un tel système qui pourra permettre une meilleure optimisation des résultats de l'entreprise.

70

REFERENCES BIBLIOGRAPHIQUES

REFERENCES BIBLIOGRAPHIQUES

[1] Sharp, H., & Hall, T. (2016). Agile Processes, in Software Engineering, and Extreme Programming: 17th International Conference, XP 2016, Edinburgh, UK, May 24-27, 2016, Proceedings. Edinburgh,Royaume-Uni : Springer International Publishing.

[2] Schwaber, K. (1997). SCRUM Development Process. Advanced Development Methods. Consulté à l'adresse http://jeffsutherland.com/oopsla/schwapub.pdf

[3] Méthodologie Agile de développement de logiciels, wikipedia.org [en ligne] ( https://fr.wikipedia.org/wiki/Scrum_(d%C3%A9veloppement)) (Consulté le 10 juin 2019)

[4] Murphy, M. (2010). L'Art du développement Android (2^e éd.). Paris, France : Pearson.

[5] 1&1 IONOS.(2017, juillet 31). Créer son application : déployer son app sur Android. Consulté le 17 septembre 2019, sur https://www.ionos.fr/digitalguide/sites-internet/developpement-web/creer-son-application-deployer-son-app-sur-android/

[6] Google Play Store : Erreurs et solutions, avismobiles.fr [en ligne] ( https://avismobiles.fr/android/google-play-store-erreurs-et-solutions/) (Consulté le 19 septembre 2019)

[7] TADJER, MÉRABET, F. Z., Nassima. (2018). Réalisation d'une application mobile sur la base du module de gestion de la maintenance industrielle (GMAO) Odoo. Consulté à l'adresse http://193.194.71.234/handle/112/14346

[8] Créer et utiliser une API REST en PHP[en ligne]( https://waytolearnx.com/2019/07/creer-et-utiliser-une-api-rest-en-php.html) (consulté le 12 Septembre 2019)

71

ANNEXES

ANNEXES

Annexe 1 : Coordonnées du centre d'accueil

Direction Générale : 2447, avenue des tecks (près du service des passeports au quartier

GTA)

BP : 3446 Lomé TOGO

E-mail : peticka@ togo-imet.com

Site web : www.togo3000.tg

Tél: [phone] / fax: [phone]

Figure 30:plan de localisation de TOGO 3000 INFORMATIQUE

72

ANNEXES

Annexe 2 : Gestion des anomalies

Une application informatique a forcément quelques bugs. Ces anomalies sont mises en évidence par la phase des tests cités dans l'annexe 1. Pour pouvoir mesurer la qualité globale de notre application, il a été important d'associer à chaque déclaration d'anomalie un niveau précis. Pour cela nous avons classé les anomalies en quatre niveaux qui sont présentés dans le tableau ci-dessous.

Niveau	Signification	Explication
1	Sans conséquence	Services phares sont toujours disponibles
2	Gravité faible	Services secondaire altéré
3	Gravité moyenne	Adaptation des modules coté clients (mise a jours des fonctions du site, lenteur d'accès au site)
4	Gravité forte	Plusieurs services indisponibles (authentification, option de recherche)
5	Catastrophique	La plate-forme n'est plus accessible (plate-forme piratée,)

Tableau 23: anomalies, signification et niveau de graveté

Nous avons classé la fréquence d'apparition des anomalies en niveaux qui sont présenté dans le tableau ci-dessous.

Probabilité/Fréquence (5 niveaux)
Niveau	Signification	Explication
1	Exceptionnel	Ne se produit qu'une fois tous les 5 ans
2	Très rare	L'incident peut survenir 1 fois tous les 2 ans
3	Rare	L'incident peut survenir 1 fois tous les ans
4	Fréquent	L'incident peut survenir 1 fois tous les 3 mois
5	Très fréquent	L'incident peut survenir 1 fois tous les 2semaines

Tableau 24: fréquence d'apparition de problème en niveau

Lélaboraton des deuix tableaux ci-dessus nous a permis d'éffectuer l'analyse prévisionnelle de la fiabilité du système en recensant les modes de défaillances potentielles dont les conséquences affectent le bon fonctionnement de l'application

73

ANNEXES

Application mobile
GesComTG3000
Fonction	Mode de défaillance	Cause	Effet	té	Probabili	Grav ité	té	Critici	Action envisagée
Installation	Oui	Insuffisance de la mémoire, ressources corrompues, insuffisance de permission, format invalide	Impossibilité d'installer		4	4		16	Libérer de la mémoire sur l'appareil, autoriser l'installation des applications tiers, essayer un autre fichier d'installation,
Gestion de la sécurité	Oui	Piratage de l'application, module de sécurité obsolète	Accès non autorisé aux données		2	4		8	Mise à jour fréquente des paramètres de sécurité
Système de gestion de la base de données		Panne au niveau du gestionnaire de la base de données	Perte de données des utilisateurs ou vol d'informations sensibles des utilisateurs		1	5		5	Sauvegarde régulière de la base de données, mise en place des systèmes de récupération
Gestion de l'ergonomie du site (affichage et mise en forme)		Interfaces non responsives	Mauvais affichage du contenu sur certains téléphones (smartphones, tablettes,)		1	3		3	Mise en place des interfaces responsives design

Tableau 25: gestion des anomalies (tableau AMDEC)

ANNEXES

74