Projet de fin d'etude gestion informatique

UNIVERSITE DE LA MANOUBAEcole Supérieure de Commerce de Tunis

MEMOIRE DE FIN D’ETUDES

Présenté en vue de l'obtention de la Maîtrise en«Méthodes Informatiques Appliqués à la Gestion des Entreprises »

Sujet :

Conception et réalisation d’uneapplication pour la gestion de la relation client

Présenté et soutenu publiquement par

Mlle. Ben Dhia Imen Mlle. Ben Hamouda Manel

Encadré par:Mlle. Ben Mustapha Nesrine Mr. Tebourbi haytham &

Mme.Aloulou Jaber Zeineb

Année Universitaire 2008- 2009

RésuméLa gestion de la relation avec la clientèle (GRC), est une stratégie adoptée par les entreprises pour

fidéliser et mieux gérer la relation avec ses clients. Notre objectif est la conception et la réalisation

d’un module marketing pour une application de GRC.

Le système a été modélisé selon le processus unifié en utilisant « UML » et développé sous une

plateforme J2EE avec une base de données « SQL SERVER ».

Mots clés : CRM, Marketing, RUP, Java, JSF, Spring, Hibernate, Servlet, Apache, SQL

SERVER.

AbstractCustomer Relationship Management (CRM) is a strategy adopted by companies to develop

customer and to better manage the relation with its customers. Our object is the design and the

realization of a marketing application for a CRM system.

The system was designed using the RUP (Unified Rational Process) and it was developed under a

J2EE framework with an « SQL SERVER » data base.

Key words: CRM, Marketing, RUP, Java, JSF, Spring, Hibernate, Servlet, Apache, SQL

SERVER.

Remerciements

Nous voulons exprimer par ces quelques lignes de remerciements notre gratitude

envers tous ceux en qui par leur présence, leur soutien, leur disponibilité et leurs

conseils, nous avons eu courage d’accomplir ce projet.

Nous commençons par remercier Mme Ben Mustapha Nesrine qui nous a fait

l’honneur d’être notre encadrante.

Nous la remercions profondément pour son encouragement continue et aussi

d’être toujours la pour nous écouter, nous aider et nous guider à retrouver le bon

chemin par sa sagesse et ses précieux conseils.

Ainsi que son soutien moral et sa preuve de compréhension, ce qui nous a donné

la force et le courage d’accomplir ce projet.

Nos remerciements les plus sincères s’adressent de même à Monssieur Tebourbi

Haithem et Mme Alouloy Zaineb, nos encadreurs à la société Cynapsys pour

leurs conseils intéressants, leur encouragement continu, ainsi que le temps qu’ils

nous ont réservé malgré leurs grandes occupations.

Nous tenons à remercier également toute l’équipe de Cynapsys, et plus

particulièrement, Monsieur Salem Shouickh, pour leur aide et leur soutien, en

leur souhaitant une bonne continuation.

Nous tenons d’autre part à remercier les respectables membres du jury pour bien

vouloir nous accorder de leur temps précieux pour commenter, discuter et juger

notre travail.

En fin, nous ne pouvons achever ce mémoire sans exprimer notre gratitude à

tous les professeurs de l’Ecole Supérieure de Commerce, pour leur dévouement

et leur assistance tout au long de nos études universitaires.

Imen & Manel

DédicacesJe dédie ce mémoire à :

Mes chers parents, que nulle dédicace ne puisse

exprimer mes sincères sentiments, pour leur

patience illimitée, leur encouragement contenu,

leur aide, en témoignage de mon profond amour

et respect pour leurs grands sacrifices.

Mes chers frères : Samy, Mariem, Anis et Rym,

pour leur grand amour et leur soutien qu’ils

trouvent ici l’expression de ma haute gratitude.

Mon très cher ami Karim.

Mes chers amis qui sans leur encouragement ce

travail n’aura jamais vu le jour.

Et à toute ma famille et à tous ceux que j’aime.

Ben Dhia Imen

DédicacesJe dédie ce modeste travail :

A mes parents, en guise de reconnaissance et de

gratitude pour les

sacrifices qu’ils ont fait.

A mes frères, à qui je dois tout l’amour, avec tous

mes vœux de

les voir réussir dans leurs vies.

A ma cousine Olfa et son mari Nabil.

A mes ami(e) s, à qui je souhaite le succès, pour

l’amitié qui nous a

toujours unis.

A tous ceux qui me sont chers.

Ben Hammouda Manel

SommaireIntroduction Générale...............................................................................................................................1

Chapitre I : Etude Préalable et spécification des besoins.........................................................................3

Introduction :............................................................................................................................................3

I Présentation du cadre du projet :..................................................................................................3

I.1 Présentation de l’organisme d’accueil:.....................................................................................3

I.2 Présentation de CYNCRM :.....................................................................................................4

I.2.1 Les axes stratégiques:...............................................................................................................5

I.2.2 Les axes opérationnels:.............................................................................................................5

II Les motivations.............................................................................................................................6

III Etude préalable : le processus CRM.............................................................................................6

III.1 Définition:.................................................................................................................................6

III.2 Interactions du système :..........................................................................................................7

III.3 Les éléments du CRM :............................................................................................................7

III.4 Les domaines du CRM :...........................................................................................................8

III.5 Le processus Marketing :..........................................................................................................9

III.5.1 La gestion des campagnes :................................................................................................10

III.5.2 La gestion des communications :........................................................................................11

III.5.3 La gestion des comptes et des contacts :............................................................................11

IV Choix de la méthodologie de conception adoptée:.....................................................................12

IV.1 Choix de la méthode de conception :......................................................................................13

IV.2 Choix du cycle de vie logiciel :..............................................................................................13

V Planning des tâches :...................................................................................................................15

VI Identification des besoins fonctionnels :....................................................................................16

VI.1 Identification des acteurs du système :...................................................................................16

VI.2 Identification des cas d’utilisation du système :.....................................................................17

VI.2.1 Définition d’un cas d’utilisation :.......................................................................................17

VI.2.2 Classification des cas d’utilisation par acteur :..................................................................17

VI.2.3 Structuration des cas d’utilisation en packages :................................................................18

VI.3 Diagramme général des cas d’utilisation :..............................................................................18

VI.4 Modèle du domaine:...............................................................................................................20

VI.5 Spécification des cas d’utilisation:.........................................................................................22

VI.6 Raffinement du cas d’utilisation « Gérer produits » :............................................................23

VI.7 Raffinement du cas d’utilisation « Gérer campagne » :.........................................................23

VI.8 Raffinement du cas d’utilisation « Gérer documents » :........................................................25

VI.9 Raffinement du cas d’utilisation « Gérer comptes » :............................................................25

VI.10 Raffinement du cas d’utilisation « Gérer contacts » :........................................................26

VI.11 Raffinement du cas d’utilisation « Gérer prospects » :......................................................26

VI.12 Raffinement du cas d’utilisation « Gérer opportunités » :..................................................27

VI.13 Raffinement du cas d’utilisation « Gérer communication » :.............................................28

VI.14 Raffinement du cas d’utilisation « Gérer utilisateurs » :....................................................29

VII Identification des besoins non fonctionnels :.........................................................................30

VIII Identification des risques :......................................................................................................31

Conclusion :............................................................................................................................................31

Chapitre II : Analyse et Conception.......................................................................................................35

Introduction :..........................................................................................................................................35

I Analyse :.........................................................................................................................................35

I.1 Analyse du cas d’utilisation « Gérer produits » :.......................................................................35

I.1.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse du cas d’utilisation « Gérer produits » :.................................................................................................................................35

I.1.2 Diagramme de classe d’analyse du cas d’utilisation « Gérer produit » :...................................36

I.1.3 Diagrammes de collaboration du cas « Gestion de produits » :.................................................36

I.1.3.1 Diagramme de collaboration du cas « Créer produit » :.........................................................36

I.1.3.2 Diagramme de collaboration du cas « Rechercher produits » :..............................................37

I.1.3.3 Diagrammes de collaboration du cas « Consulter produits » :...............................................37

I.2 Analyse du cas d’utilisation « Créer campagne » :....................................................................38

I.2.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Créer campagne » :..............................................................................................................................38

I.2.2 Diagramme de classe d’analyse du cas « Créer campagne » :...................................................38

I.2.3 Diagramme de collaboration du cas « Créer campagne » :.......................................................39

I.3 Analyse du cas d’utilisation « Contrôler campagne » :..............................................................40

I.3.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Contrôler campagne » :.......................................................................................................................40

I.3.2 Modèle de classe d’analyse du cas « Contrôler campagne » :....................................................40

I.3.3 Diagrammes de collaboration du cas « Contrôler campagne » :...............................................41

I.4 Analyse du cas d’utilisation « Planifier campagne » :................................................................42

I.4.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation« Planifier campagne » :.....................................................................................................42

I.4.2 Modèle de classe d’analyse du cas d’utilisation « Planifier campagne » :.................................42

I.4.3 Diagramme de collaboration du cas d’utilisation du cas « Planifier campagne » :....................43

I.5 Analyse du cas d’utilisation « Lancer campagne » :..................................................................44

I.5.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Lancer campagne » :...........................................................................................................................44

I.5.2 Diagramme de classe d’analyse du cas d’utilisation « Lancer campagne » :.............................45

I.5.3 Diagramme de collaboration du cas d’utilisation « Lancer campagne » :..................................45

I.6 Analyse du cas d’utilisation « Suivre campagne » :...................................................................46

I.6.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Suivre campagne » :............................................................................................................................46

I.6.2 Diagramme de classe d’analyse du cas d’utilisation « Suivre campagne » :.............................46

I.6.3 Diagramme de collaboration du cas d’utilisation « Suivre campagne » :.................................47

I.7 Analyse du cas d’utilisation « Gérer comptes » :.......................................................................47

I.7.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Gérer comptes » :................................................................................................................................47

I.7.2 Diagramme de classe d’analyse du cas « Gérer comptes » :......................................................48

I.7.3 Diagrammes de collaboration du cas « Gérer comptes » :........................................................48

I.8 Analyse du cas d’utilisation « Gérer contacts » :.......................................................................49

I.8.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Gérer contacts » :................................................................................................................................49

I.8.2 Diagramme de classe d’analyse du cas « Gérer contacts » :......................................................50

I.8.3 Diagrammes de collaboration du cas « Gérer contacts » :.........................................................50

I.9 Analyse du cas d’utilisation « Gérer prospects » :.....................................................................50

I.9.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Gérer prospects » :..............................................................................................................................50

I.9.2 Diagramme de classe d’analyse du cas « Gérer prospects » :....................................................51

I.9.3 Diagramme de collaboration du sous cas « Créer prospect » :...................................................51

I.10 Analyse du cas d’utilisation « Gérer opportunités » :................................................................52

I.10.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Créer opportunité » :......................................................................................................52

I.10.2 Modèle de classe d’analyse du cas « Créer opportunité » :....................................................53

I.10.3 Diagrammes de collaboration du cas « Créer opportunité» :................................................54

I.11 Analyse du cas d’utilisation « Gérer appels » :..........................................................................55

I.11.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Gérer appels » :..............................................................................................................55

I.11.2 Modèle de classe d’analyse du cas « Gérer appels» :.............................................................56

I.11.3 Diagrammes de collaboration du cas « Gérer appel » :..........................................................56

I.11.3.1 Diagramme de collaboration du cas « Enregistrer appel » :..............................................56

I.11.3.2 Diagramme de collaboration du cas d'utilisation "Effectuer appel" :.................................57

I.11.3.3 Diagramme de collaboration du cas d'utilisation « Planifier appel » :...............................57

I.11.3.4 Diagramme de collaboration du cas d'utilisation "Suivre appel" :.....................................58

I.12 Analyse du cas d’utilisation « Gérer profils » :..........................................................................59

I.12.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Gérer profils » :..............................................................................................................59

I.12.2 Modèle de classe d’analyse du cas « Gérer profils » :............................................................59

I.12.3 Diagrammes de collaboration du cas « Gérer profils » :.......................................................60

I.13 Analyse du cas d’utilisation « Gérer agents » :.........................................................................61

I.13.1 Réalisation-Analyse du cas d’utilisation « Gérer agents » :...................................................61

I.13.2 Modèle de classe d’analyse du cas « Gérer agents » :............................................................61

I.13.3 Diagrammes de collaboration du cas « Gérer agents » :.......................................................62

I.14 Analyse du cas d’utilisation « Gérer Comptes Utilisateur » :...................................................62

I.14.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « Gérer Comptes Utilisateur » :.........................................................................................62

I.14.2 Modèle de classe d’analyse du cas « Gérer Comptes Utilisateur » :......................................63

I.14.3 Diagrammes de collaboration du cas « Gérer Comptes Utilisateur » :...................................64

I.15 Analyse du cas d’utilisation « S’authentifier » :.........................................................................65

I.15.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse pour le cas d’utilisation « S’authentifier » :..............................................................................................................65

I.15.2 Modèle de classe d’analyse du cas « S’authentifier » :..........................................................65

I.15.3 Diagrammes de collaboration du cas « S’authentifier » :.......................................................66

II Conception :....................................................................................................................................67

II.1 Conception du cas d’utilisation « Gérer produits » :..................................................................67

II.2 Du modèle de classe d’analyse au modèle de classe conception :.............................................67

II.3 Diagramme de classe de conception relatif au cas « Gérer produit » :.......................................67

II.4 Diagrammes de séquence du cas « Gestion de produits » :........................................................68

III Conception du cas d’utilisation « Gérer campagne » :...............................................................68

III.1 Conception du cas d’utilisation « Créer campagne » :..............................................................68

III.1.1 Du modèle d’analyse au modèle de conception du cas d’utilisation « Créer campagne » :..68

III.1.2 Modèle de classe d’analyse du cas « Créer campagne » :......................................................69

III.1.3 Diagramme de séquence du cas « Créer campagne » :..........................................................69

III.2 Conception du cas d’utilisation « Modifier campagne » :..........................................................71

III.3 Conception du cas d’utilisation « Contrôler campagne » :.........................................................71

III.3.1 Traçabilité Analyse-Conception du cas d’utilisation « Contrôler campagne » :...................71

III.3.2 Diagramme de classe de conception du cas « Contrôler campagne » :..................................71

III.3.3 Diagrammes de séquence du cas « Contrôler campagne » :..................................................71

III.4 Conception du cas d’utilisation « Planifier campagne » :..........................................................72

III.4.1 Traçabilité Analyse-Conception du cas d’utilisation « Planifier campagne » :.....................72

III.4.2 Diagramme de classe de conception du cas d’utilisation « Planifier campagne » :...............72

III.4.3 Diagrammes de séquence du cas d’utilisation du cas « Planifier campagne » :.....................72

III.5 Conception du cas d’utilisation « Lancer campagne » :.............................................................74

III.5.1 Traçabilité Analyse-Conception du cas d’utilisation « Lancer campagne » :.......................74

III.5.2 Diagramme de classe d’analyse du cas d’utilisation « Lancer campagne » :.........................74

III.5.3 Diagrammes de séquence du cas d’utilisation « Lancer campagne » :...................................74

III.6 Conception du cas d’utilisation « Suivre campagne » :..............................................................75

III.6.1 Traçabilité Analyse-Conception du cas d’utilisation « Suivre campagne » :........................75

III.6.2 Diagramme de classe de conception du cas d’utilisation « Suivre campagne » :..................75

III.6.3 Diagrammes de séquence du cas d’utilisation « Suivre campagne » :..................................75

IV Diagramme de classes entités :...................................................................................................76

Conclusion :............................................................................................................................................78

Chapitre III : Réalisation et Mise en œuvre............................................................................................81

Introduction :..........................................................................................................................................81

I Présentation de la base de données :...............................................................................................81

I.1 Les règles de passage d’un modèle objet à un modèle relationnel:............................................81

I.2 Le schéma relationnel :...............................................................................................................82

II Le modèle de déploiement:.............................................................................................................83

III Le modèle de composants :.........................................................................................................83

III.1 Traçabilité entre le modèle de conception et le modèle d’implémentation :..............................83

III.2 Diagramme de composants générique :......................................................................................84

IV Architecture adoptée :.................................................................................................................86

V Choix des outils et des logiciels utilisés :.......................................................................................87

V.1 Choix de la plateforme : J2EE (Java 2 Entreprise Edition)........................................................87

V.2 Choix du serveur d’application: Apache Tomcat.......................................................................87

V.3 Choix de l’environnement logiciel :...........................................................................................87

V.4 Choix du système de gestion de la base de données : Microsoft SQL Server 2005 :.................88

VI Tests de l’application :................................................................................................................88

VI.1 Cas d’utilisation « S’identifier » :...............................................................................................88

VI.2 Cas d’utilisation « Gérer produits » :..........................................................................................89

VI.3 Cas d’utilisation « Gérer campagne » :......................................................................................92

VII Constations et perspectives :.......................................................................................................96

Conclusion :............................................................................................................................................97

Conclusion Générale...............................................................................................................................93

Annexes..................................................................................................................................................94

Glossaire...............................................................................................................................................109

Bibliographie et Netographie................................................................................................................110

Table des figuresFigure 1: les pôles technologiques de CYNAPSYS.................................................................................4Figure 2: Interactions du système.............................................................................................................7Figure 3: Triangle CRM...........................................................................................................................7Figure 4: Domaines du CRM....................................................................................................................9Figure 5: Processus Marketing...............................................................................................................10Figure 6: Gestion des campagnes...........................................................................................................10Figure 7: Gestion des Communications..................................................................................................11Figure 8: Gestion des comptes et des contacts.......................................................................................11Figure 9: Les différentes vues du langage UML....................................................................................13Figure 10: Le schéma synthétique du PU (Processus Unifié)................................................................15Figure 11: Planning de réalisation..........................................................................................................15Figure 12: Diagramme de classe des acteurs..........................................................................................16Figure 13: Structuration des cas d'utilisation en packages.....................................................................18Figure 14: Diagramme général des cas d'utilisation...............................................................................19Figure 15: Modèle du domaine...............................................................................................................21Figure 16: Raffinement du cas " Gérer produits"...................................................................................23Figure 17: Raffinement du cas " Gérer campagnes"..............................................................................23Figure 18: Diagramme d'états-transitions de l'objet "Campagne"..........................................................24Figure 19: Raffinement du cas " Gérer documents"...............................................................................25Figure 20: Raffinement du cas " Gérer comptes"...................................................................................25Figure 21: Raffinement du cas " Gérer contacts"...................................................................................26Figure 22: Raffinement du cas " Gérer prospects".................................................................................26Figure 23: Diagramme d'états-transitions de l'objet "Prospect".............................................................27Figure 24: Raffinement du cas " Gérer opportunités"............................................................................27Figure 25: Diagramme d'états-transitions de l'objet "opportunité"........................................................28Figure 26: Raffinement du cas " Gérer Communications".....................................................................28Figure 27: Diagramme d’états-transitions de l'objet appel.....................................................................29Figure 28: Raffinement du cas d'utilisation " Gérer Utilisateurs"..........................................................29Figure 29: Diagramme d’états-transitions de l'objet utilisateur..............................................................30Figure 30: Traçabilité du cas d’utilisation «Gérer produits"..................................................................35Figure 31: Diagramme de classe d'analyse du cas "Gérer produit"........................................................36Figure 32: Diagramme de collaboration du cas "Créer produit"............................................................36

Figure 33: Diagramme de collaboration du cas "Rechercher produit"...................................................37Figure 34: Diagramme de collaboration du cas "Consulter produit".....................................................37Figure 35: Traçabilité du cas "Créer campagne"....................................................................................38Figure 36: Diagramme de classe d'analyse du cas "Créer campagne"...................................................39Figure 37: Diagramme de collaboration du sous cas d'utilisation "Créer campagne"............................39Figure 38: Traçabilité du cas "Contrôler Campagne".............................................................................40Figure 39: Le modèle de classe d'analyse du cas "Contrôler campagne"...............................................40Figure 40: Diagramme de collaboration du sous cas d'utilisation "Contrôler campagne".....................41Figure 41: Traçabilité du cas "Planifier campagne"...............................................................................42Figure 42: Diagramme de classe d'analyse du cas "Planifier campagne"..............................................42Figure 43: Diagramme de collaboration "Planifier campagne"..............................................................43Figure 44: Traçabilité du cas "Lancer campagne"..................................................................................44Figure 45: Diagramme de classe d'analyse du cas "Lancer Campagne"................................................45Figure 46 : Diagramme de collaboration "Lancer campagne"...............................................................45Figure 47: Traçabilité du cas d'utilisation "Suivre campagne"...............................................................46Figure 48: Diagramme de classe d'analyse "Suivre campagne".............................................................46Figure 49: Diagramme de collaboration "Suivre campagne".................................................................47Figure 50: traçabilité du cas d'utilisation "Gérer comptes"....................................................................48Figure 51: Le modèle de classe d'analyse du cas "Gérer compte".........................................................48Figure 52: Diagramme de collaboration du cas d'utilisation "Créer Compte".......................................49Figure 53: Traçabilité du cas d'utilisation "Gérer contacts"...................................................................49Figure 54: Diagramme de classe d'analyse du cas d'utilisation "Gérer contacts"..................................50Figure 55: Diagramme de collaboration du cas "Créer Contact"...........................................................50Figure 56: Traçabilité du cas "Gérer prospects".....................................................................................51Figure 57: Diagramme de classe d'analyse du cas "Gérer prospects"....................................................51Figure 58: Diagramme de collaboration du cas d'utilisation "Créer prospect"......................................52Figure 59: Traçabilité du cas d'utilisation "Gérer opportunités"............................................................53Figure 60: Diagramme de classe d'analyse du cas "Gérer opportunités"...............................................53Figure 61: Diagramme de collaboration du cas d'utilisation "Créer opportunité"..................................54Figure 62: Traçabilité du cas "Gérer appels"..........................................................................................55Figure 63: Diagrammes de classes d'analyse du cas "Gérer communications"......................................56Figure 64: Diagramme de collaboration du cas d'utilisation "Créer appel"...........................................56Figure 65: Diagramme de collaboration du cas d'utilisation "Effectuer appel".....................................57Figure 66: Diagramme de collaboration du cas d'utilisation "Planifier appel"......................................58Figure 67: Diagramme de collaboration du cas d'utilisation "Suivre appel"..........................................58Figure 68: Traçabilité du cas "Gérer profils".........................................................................................59Figure 69: Diagrammes de classes d'analyse du cas "Gérer profils"......................................................59Figure 70: Diagramme de collaboration du cas d'utilisation "Créer profil"...........................................60Figure 71: Traçabilité du cas "Gérer agents"..........................................................................................61Figure 72: Diagrammes de classes d'analyse du cas "Gérer agents"......................................................61Figure 73: Diagramme de collaboration du cas d'utilisation "Créer agent"...........................................62Figure 74: Traçabilité du cas "Gérer comptes utilisateur"......................................................................63Figure 75: Diagrammes de classes d'analyse du cas "Gérer comptes utilisateur"..................................63Figure 76: Diagramme de collaboration du cas d'utilisation "Créer utilisateur"....................................64Figure 77: Traçabilité du cas "S’authentifier"........................................................................................65Figure 78: Diagrammes de classes d'analyse du cas "Gérer comptes utilisateur"..................................65Figure 79: Diagramme de collaboration du cas d'utilisation "S’authentifier"........................................66

Figure 80: Traçabilité entre le modèle d’analyse et le modèle de conception du cas d’utilisation « gérer produits »................................................................................................................................................67Figure 81: Diagramme de classe de conception du cas "Gérer produit"................................................67Figure 82: Diagramme de séquence du cas "Créer produit"...................................................................68Figure 83: Traçabilité entre le modèle d’analyse et le modèle de conception du cas d’utilisation « Créer campagne »...................................................................................................................................68Figure 84: Le modèle de classe de conception du cas "Créer campagne"..............................................69Figure 85: Diagramme de séquence du sous cas d'utilisation "Créer campagne"..................................70Figure 86: Traçabilité entre le modèle d’analyse et le modèle de conception du cas "Contrôler Campagne"..............................................................................................................................................71Figure 87: Diagramme de classe de conception du cas "Contrôler campagne".....................................71Figure 88: Diagramme de séquence du sous cas d'utilisation "Contrôler campagne"............................71Figure 89: Traçabilité du cas "Planifier campagne"...............................................................................72Figure 90: Le modèle de classe de conception du cas "Planifier campagne".........................................72Figure 91: Diagramme de séquence "Planifier campagne"....................................................................73Figure 92: Traçabilité analyse-conception du cas "Lancer campagne"..................................................74Figure 93: Diagramme de classe de conception du cas "Lancer Campagne".........................................74Figure 94 : Diagramme de séquence "Lancer campagne"......................................................................74Figure 95: Traçabilité analyse-conception du cas "Suivre campagne"..................................................75Figure 96: Diagramme de classe de conception du cas "Suivre campagne"..........................................75Figure 97: Diagramme de séquence du cas "Suivre campagne"............................................................75Figure 98: Diagramme de classes entités...............................................................................................77Figure 99: Modèle de déploiement.........................................................................................................83Figure 100: Traçabilité entre le modèle de conception et le modèle d'implémentation.........................84Figure 101: Diagramme de composants générique................................................................................85Figure 102: Architecture J2EE basée sur les technologies JSF, Spring et Hibernate............................86Figure 103: Page d'identification............................................................................................................88Figure 104: Page d'accueil......................................................................................................................89Figure 105: Page d'accueil Produits........................................................................................................89Figure 106: Création d'un nouveau produit............................................................................................90Figure 107: Confirmation.......................................................................................................................90Figure 108: Modification de produit......................................................................................................91Figure 109: Produit ajouté......................................................................................................................92Figure 110: Page d'accueil Campagnes..................................................................................................92Figure 111: Créer campagne...................................................................................................................93Figure 112: Choix des comptes..............................................................................................................93Figure 113: Choix des produits..............................................................................................................94Figure 114: Comptes et produits ajoutéss...............................................................................................94Figure 115: Modifications effectués.......................................................................................................95Figure 116: Contrôler campagne............................................................................................................96Figure 117: Saisie de notes.....................................................................................................................96Figure 118: Le processus de vente.......................................................................................................104Figure 119: Gestion des devis..............................................................................................................105Figure 120: Gestion des contrats..........................................................................................................105Figure 121: Envoi au service comptable..............................................................................................105Figure 122: Après-Vente......................................................................................................................106Figure 123: Gestion des incidents........................................................................................................106Figure 124: Support technique.............................................................................................................107

Figure 125: Interactions entre le modèle, la vue et le contrôleur.........................................................107Figure 126: Architecture n-tiers...........................................................................................................108

Gestion de la Relation Client Introduction générale

Introduction Générale

Dans notre société, l’information est devenue un élément à la fois stratégique pour développer

les activités, et essentiel pour assurer un avantage concurrentiel (optimisation des coûts,

meilleure satisfaction des clients…) aux entités qui savent l’utiliser. Ce constat explique la

raison pour laquelle les entreprises cherchent aujourd’hui à mettre en place des systèmes de

collecte et de traitement de données plus performants.

De même, la satisfaction du client est plus que jamais au centre des préoccupations des

entreprises et se concrétise par une gestion personnalisée de la relation client : comprendre les

clients et leurs attentes, les fidéliser, les inciter à consommer davantage. Le CRM (Customer

Relationship Management), dit aussi GRC (Gestion de la relation Client) a pour objet

d'identifier, attirer et conserver les meilleurs clients et de maximiser le chiffre d'affaire et la

rentabilité.

La GRC englobe l'ensemble des activités et des processus que doit mettre en place une

entreprise pour interagir avec ses clients et ses prospects afin de leur fournir des produits et

des services adéquats au bon moment. Les entreprises ont, de plus en plus, recours à une

approche de type de CRM, afin de se différencier. Une exigence accrue du client conduit les

entreprises à faire évoluer leur offre dans le sens d'une plus grande personnalisation.

Ce projet consiste à concevoir et à réaliser un module marketing pour une application de

gestion de la relation client, intitulée CYNCRM.

Dans ce cadre, la modélisation de ce module se base sur le Processus Unifié et la notation

UML.

Rappelons que le processus unifié est constitué de quatre phases (Création, Elaboration,

Construction et Transition), chacune comportant les activités suivantes : spécification des

besoins, analyse, conception, réalisations et tests.

Dans ce rapport, on considère uniquement les activités, puisque le projet est présenté en une

seule itération. De ce fait, les différentes phases sont incorporées dans les différentes activités,

qui se présentent en trois principaux chapitres :

Page | 1

Gestion de la Relation Client Introduction générale

Le premier chapitre intitulé ‘Etude préalable et spécification des besoins’ est le point

de départ. Il consiste, dans un premier lieu, à donner un aperçu sur l’organisme

d’accueil ‘Cynapsys’ et à présenter le projet ainsi que les objectifs et les motivations.

En second lieu, il présente une étude succincte de l’état de l’art permettant de se situer

par rapport aux solutions et technologies des applications de gestion de la relation

client existantes sur le marché. De même, il met en valeur les besoins attendues par les

futurs utilisateurs du système ainsi que la justification du choix de la méthode de

conception adoptée.

Le deuxième chapitre intitulé ‘Analyse et conception’ porte sur l’analyse des besoins

décrits dans le chapitre précédant. Il met, également, en exergue l’aspect conceptuel de

l’application en présentant les différents scénarios par l’intermédiaire du langage de

conception et de modélisation UML. Cette phase est primordiale puisqu’elle assure le

développement d’une carte dont on pourra se servir pour la programmation.

Le troisième chapitre intitulé ‘Réalisation et tests’ est consacré à la présentation de

l’environnement de réalisation de l’application et de l’outil de représentation de la

persistance des données. Il schématise la transformation des besoins capturés, analysés

et conçus dans les précédents chapitres en un produit qui répond aux attentes des

utilisateurs.

Enfin, une conclusion qui, synthétise le travail et présente les perspectives envisagées.

Page | 2

Gestion de la Relation Client Etude préalable et spécification des besoins

Chapitre I : Etude Préalable et spécification des besoins

Introduction :

Ce chapitre présente, en premier lieu, l’organisme d’accueil, dans lequel le projet a été

effectué, ainsi que les objectifs et les motivations de ce dernier. En second lieu, il

introduit, d’une manière générale, la notion de gestion de la relation client et il détaille

le processus Marketing, sur lequel porte ce rapport. Enfin, il justifie la méthodologie de

conception adoptée et mentionne le plan de travail à suivre tout au long du projet.

I Présentation du cadre du projet :

Cette première partie constitue une présentation générale du cadre de ce projet de fin

d’étude. En premier lieu, l’organisme d’accueil, qui est la société Cynapsys, dans

laquelle ce travail a été menu, sera présenté. Ensuite, la problématique sera soulevée

ainsi que les différents objectifs à atteindre. Enfin, les motivations, qui viennent justifier

le choix de ce sujet, seront évoquées.

I.1 Présentation de l’organisme d’accueil:

Fondée en 2003, CYNAPSYS est une entreprise tunisienne de prestation de services en

technologie de l’information spécialisée dans le domaine du développement de logiciel

pour la télécommunication et l'industrie. Ayant acquis une grande expérience dans la

gestion des projets off-shore et near-shore. Elle a l’ambition d’être un partenaire

compétent auprès de ses clients à chaque étape du processus de développement logiciel.

Cynapsys est totalement exportatrice. En effet, elle a développé une bonne connaissance

du marché européen (principalement la France et l’Allemagne).

Elle s’appuie sur la puissance des normes internationales. En effet, depuis 2007, des

décisions de la direction ont été prises en vue de la certification CMMI niveau 31 et ISO

9001 - v 20002 afin d'optimiser ses processus internes et de donner à ses clients le

meilleur rapport qualité / prix.

1 Voir glossaire.2 Voir glossaire.

Page | 3


Le management de l’entreprise adossé à ces compétences a permis à CYNAPSYS

d’avoir la confiance de grandes enseignes : Siemens Communication, BenQ-Mobile,

Synchronica, Vodafone D2, Orascom Telecom…etc.

Son équipe se compose d’architectes de logiciel, de programmeurs de logiciel, de

conseillers et de chefs de projet expérimentés.

CYNAPSYS est organisée en trois directions : une direction commerciale, une direction

technique et une direction administrative.

La direction technique, dans laquelle nous avons menu notre travail, comporte trois

principaux pôles (cf. figure 1) :

Figure 1: les pôles technologiques de CYNAPSYS

Le Pôle J2EE a pour tâche la réalisation des applications sur demande en

utilisant la technologie Java/J2EE (JAVA 2 Entreprise Edition).

Le Pôle Microsoft .Net est chargé du développement des applications en

utilisant la technologie «.Net » pour la gestion et la réparation de la

téléphonie mobile.

Le Pôle Systèmes Embarqués a pour rôle le développement des

applications embarquées3.

I.2 Présentation de CYNCRM :

Dans un environnement turbulent où la concurrence devient de plus en plus accrue, les

clients ne vont pas choisir n’importe quel produit ou service offert sur le marché mais

3 Voir glossaire.

Page | 4


plutôt celui qui répond le plus à leur besoins. Dans cette situation, les entreprises, y

compris CYNAPSYS, doivent offrir un avantage concurrentiel pour attirer et fidéliser

ses clients et assurer sa part de marché.

C’est pourquoi, soucieuse d’assouvir les besoins de sa clientèle, CYNAPSYS a décidé

de mettre en place un système informatique chargé de la gestion de sa relation avec ses

clients aussi bien en Tunisie qu’à l’étranger.

Elle doit disposer d’outils et de moyens efficaces pour orienter ses principaux services à

savoir ; le marketing, la vente et l’après-vente.

En effet, CYNAPSYS envisage la mise en place d’un CRM. Ce système, intitulé

CYNCRM, lui permettra la conquête, le suivi et la fidélisation de ses clients. De plus, il

fera l’objet d’une publication en libre code (Open Source), à la disponibilité des autres

entreprises.

C’est dans ce cadre que s’inscrit notre mémoire de fin d’études universitaires de la

maîtrise en Informatique Appliquée à la Gestion, qui consiste à proposer une solution

dans le but de mieux gérer la relation avec le client. Notre choix a été fixé sur

l’utilisation des nouvelles technologies de l’information et de communication à savoir

le WEB, J2EE etc.

I.2.1 Les axes stratégiques:

Cette application CRM s’inscrit dans le cadre d’un projet pilote qui vient répondre à

des objectifs d’ordre stratégique (à long terme).Ces axes stratégiques desquels découle

la mise en place de cette application sont les suivants:

La consommation de la baisse des charges provoquées par la crise économique

mondiale qui a réduit l’acquisition des nouveaux projets : il s’agit de mettre à

jour les profils des ingénieurs et les motiver pour faire face aux problèmes

engendrés par cette crise.

La production d’une action de marketing à travers la publication de ce projet en

code libre (open source) : ceci permet de promouvoir le produit et d’avoir des

activités autour de lui tels que le consulting, la personnalisation (customizing) et

la formation, dans l’optique de prévoir des versions payantes encore plus

personnalisés en fonction des clients.

L’obtention de la certification CMMI niveau 3 et ISO 9001 - v 2000 : à travers

le déploiement des processus qualité exigés par ces modèles et normes.

Page | 5


I.2.2 Les axes opérationnels:

Les objectifs opérationnels que les entreprises cherchent à atteindre à travers la mise en

place d’un tel système CRM, consistent à :

offrir aux spécialistes de vente des outils permettant d’augmenter leur chiffre

d’affaires ;

accélérer les décisions d’achat ;

maximiser la productivité de l’équipe.

II Les motivations

Le choix du projet de fin d’étude est une étape délicate, puisqu’elle matérialise la

transaction entre l’environnement éducationnel et la vie professionnelle.

Plusieurs motivations ont orienté notre choix :

En premier lieu, notre sujet fait le lien entre nos atouts qui sont l’informatique et

la gestion.

En second lieu, le CRM est devenu un sujet très important voire un sujet

d’actualité ; il est au cœur des préoccupations de toutes les entreprises qui

cherchent à accroître et fidéliser leurs portefeuilles clients. C’est pour cette

raison qu’un système CRM est devenu un ingrédient professionnel en passe de

devoir indispensable pour les entreprises.

En troisième lieu, il nous permet d’approfondir encore plus nos connaissances

en matière d’informatique en ayant l’occasion de travailler avec des technologies

innovantes telle que la technologie J2EE.

III Etude préalable : le processus CRM

III.1 Définition:

La gestion de la relation client (CRM) se définit comme une démarche qui vise à

identifier, attirer et fidéliser les meilleurs clients afin d’augmenter la valeur du capital

client de l’entreprise.

Les actions de CRM sont en général supportées par un environnement informatique ou

un ensemble d’outils articulés autour d’une base de données client centralisée, ce qui a

conduit à donner aujourd’hui une acception plus "informatique" à l’acronyme CRM.

On utilise généralement le terme CRM pour désigner les systèmes et outils

informatiques mis en œuvre pour gérer la relation avec le client, mais le CRM peut

Page | 6


impliquer, au-delà des considérations techniques, un changement certain dans la culture

de l’entreprise.

Au-delà de nombreuses définitions publiées, le CRM se résume, tout simplement, en

trois processus clefs qui sont le marketing, la vente et le service.

III.2 Interactions du système :

CRM

Accounting system

Stock Managment EDM

Figure 2: Interactions du système

Le CRM n’est pas un système autonome, il n’évolue pas tout seul, mais il interagit avec

d’autres systèmes. En effet, il interagit avec trois systèmes différents (cf. figure 2):

Un système de gestion des disponibilités ; pour vérifier la disponibilité du stock

(produit) ou du service demandé.

Un système GED ; pour la gestion électronique des Documents.

Un système de comptabilité; pour le suivi des statuts de commandes et la

vérification des garanties.

III.3 Les éléments du CRM :

Figure 3: Triangle CRM

Les principaux éléments du CRM sont (cf. figure 3):

Le client : il s’agit de l’élément fondamental du CRM. Il représente, pour

l’entreprise, la seule source de son profit à présent et de son développement dans

Page | 7


le futur. Cependant, il est à noter que, de nos jours, l’environnement est devenu

de plus en plus concurrentiel et que les clients sont devenus, à leur tour, encore

plus éduqués et plus rationnels. Par conséquent, ces clients peuvent choisir un

autre concurrent pour la simple raison que celui-ci satisfait mieux leurs besoins.

Il n’est donc pas une tâche facile de distinguer les meilleurs clients. C’est pour

cette raison que le recours à la mise en place d’un CRM constitue semble être

un remède pour ce problème. En effet, le CRM offre des outils qui permettent la

distinction des clients et leur gestion.

Le management: Les informations collectées et relatives aux clients sont

transformées en connaissances qui seront utilisées pour organiser des activités

permettant de tirer profit des opportunités du marché (elles conditionnent les

activités de l’entreprise). Le CRM implique donc un changement continu dans la

culture de l’entreprise, de ses différents processus et du comportement de ses

employés qui doivent être dans un état d’esprit CRM.

La relation entre les deux : elle matérialise la communication et les différentes

interactions entre l’entreprise et ses clients. Cette relation peut durer à long-

terme ou à court-terme, elle peut être continue ou discrète, répétée ou unique.

Elle est reliée aux attitudes et aux comportements. Un client peut manifester une

attitude positive envers une entreprise mais son comportement d’achat est

occasionnel. Ce type de relation est mesuré par le CLV (valeur du cycle de vie

client).

Le CRM consiste donc à gérer cette relation pour qu’elle soit mutuellement bénéfique.

III.4 Les domaines du CRM :

Le CRM ou GRC est l'intégration technologique des processus transversaux liés au

marketing, à la vente et aux services clients, dans une optique d'automatisation et

d'amélioration de la gestion de la relation avec le client.

En tant qu’outil orienté client, le CRM s’adresse avant tout aux services suivants, qui

sont étroitement liés les uns aux autres (cf. figure 4):

Le Marketing : il s’agit de l’avant-vente consistant à étudier le marché ; c'est-à-

dire les besoins des clients et à démarcher les prospects. L’analyse des

informations collectées sur le client permet à l’entreprise de revoir sa gamme de

produits afin de répondre plus précisément à ses attentes. En effet, il sert pour le

Page | 8


ciblage, la gestion des actions marketing et l’identification des opportunités de

vente.

La Vente : elle couvre tout le processus de vente depuis la découverte d’une

affaire ou vente potentielle, jusqu’au règlement des factures par le client.

L’Après-vente : elle concerne les actions entreprises suite aux ventes dans le but

de répondre aux réactions et réclamations des clients.

Figure 4: Domaines du CRM

Chaque domaine est décrit par un processus spécifique comportant un ensemble

d’activités. Dans ce qui suit, nous allons nous intéresser, seulement, au processus

Marketing. En effet, ce processus constitue le module qui nous concerne dans le

projet « CYNCRM ».

III.5 Le processus Marketing :

Pour garantir la réussite de la relation avec la clientèle, et ce à long terme, un travail

préliminaire est obligatoire au sein de l’entreprise permettant d’attirer d’abord et de

fidéliser ensuite les meilleurs clients. Ce travail d’avant-vente s’appuie sur un aspect

marketing-marché. Cet aspect vise le lancement de compagnes et de promotions

diverses. Pour cela, la conception des campagnes nécessitent de choisir la période, le

produit, le coût, le lieu, la clientèle, les communications et les moyens impliqués.

Tous ces aspects ont un objectif unique qui est celui de mieux vendre et donc

d’augmenter les bénéfices.

Ainsi, l’entreprise doit être en mesure de constituer toutes les informations utiles et

nécessaires afin de les analyser facilement et d’y accéder en temps réel. La gestion des

relations clients permet d’effectuer le suivi des données des clients, y avoir accès et

interagir avec l’ensemble des données.

Page | 9

Mar

keti

ng

Gestion des

campagne

s

Gestion des communications

Gestion des

comptes

clients


Le processus de Marketing correspond à un processus itératif et incrémental constitué

par les étapes suivantes (cf. figure 5) :

La gestion des campagnes.

La gestion des communications.

La gestion des comptes clients.

Figure 5: Processus Marketing

Page | 10


III.5.1 La gestion des campagnes :

Figure 6: Gestion des campagnes

Bien que le client constitue, le centre d’intérêt des entreprises, l’importance des produits

et des services commercialisés ne disparaît pas pour autant. L’entreprise doit gérer de

façon détaillée l’ensemble de ses produits ou services.

Elle doit, également, être en mesure de gérer ses campagnes d’une manière efficace. En

effet, Les campagnes représentent les actions permettant d’envoyer les informations de

l’entreprise vers l’ensemble du public ou vers un public ciblé. Elle doit, donc, disposer

d’outils et de moyens nécessaires pour la planification, le lancement et le suivi de ces

dernières, tout en tenant compte des notions qui s’y rapporte (en relation avec elles) y

compris les promotions, les produits, l’équipe commerciale…etc. (cf. figure 6)

III.5.2 La gestion des communications :

Page | 11

Gestion des

produits

Création et

édition des

compagnes

Contrôle des

campagnes

Planification des campag

nesLancement des campag

nes

Gestion éléctroniqu

e des documents

Agent Marketing

Agent Marketing

Suivi des

campagnes

Unité organisationnelleGestion des

rendez-vous

Gestion des

appelsGestion des FAXGestion des E-mails

Gestion des

lettresGestion des SMS


Figure 7: Gestion des Communications

La gestion des communications est une fonction transversale mise à la disposition des

acteurs du processus marketing, vente et après-vente. Elle consiste à gérer les

communications entrantes et sortantes et à garder trace de ces communications. On

distingue différents types de communications, à savoir les appels, les fax, les emails, les

sms, les rendez-vous…etc.

La diversité des moyens de communication est expliquée par la nature des préférences

qui diffèrent d’un client à un autre. En effet, pour chaque client, on doit préciser son

moyen de communication préféré qui sera le moyen le plus efficace pour le contacter. Il

peut être le téléphone, le fax, le courrier postal, le courrier électronique…etc. Cette

information est renseignée par le service marketing et elle peut changer dans le temps.

Ainsi, lors des campagnes marketing, le moyen de communication utilisé peut être fixé

pour touts les clients ou bien on peut utiliser pour chaque client son moyen de

communication préféré. (cf. figure 7)

III.5.3 La gestion des comptes et des contacts :

Figure 8: Gestion des comptes et des contacts

L’entreprise doit rassembler les informations lui permettant de décrire et de caractériser

sa clientèle, de la positionner sur son marché et de détecter de nouveaux prospects. De

ce fait, elle doit disposer d’un moyen technologique pour mieux constituer, gérer et

analyser des masses d’informations relatives aux clients.

Les clients avec lesquels l’entreprise établit des relations peuvent être des particuliers ou

des entreprises.

Un particulier est toujours contacté à travers une seule personne appelé contact alors

qu’une entreprise peut être contactée à travers plusieurs personnes (le PDG, le directeur

Page | 12

Agent Marketing

Directeur Marketin

g

Gestion des

prospects

Gestion des

produitsGestion

des comptes et des contact

s

Assignement ou

Reassignement des prospects

Exclusion des

prospects

Gestion des

opportunités

Directeur Commerci

al

Agent Commerc

ialSuivi des

opportunités


technique, l’attaché commercial…etc.). Dans ce deuxième cas, des informations

relatives à ces contacts doivent être disponibles pour pouvoir les contacter.

Suite aux campagnes effectuées par le service de l’avant-vente, il y aura,

éventuellement, la découverte des besoins des clients à un ou plusieurs produits. Cette

découverte peut être déclenchée par la réception d’une consultation directe envoyée par

un client, un appel d’offre paru dans les médias ou une découverte par un canal

quelconque de l’intérêt d’un client pour un produit donné. Par conséquent, L’entreprise

est en mesure d’enregistrer les nouveaux prospects qui sont apparus.

Une fois que les prospects sont enregistrés, une décision de poursuite ou non de cette

affaire sera prise.

Dans le cas où une décision de poursuite à été prise, le prospect se transforme, donc, en

une opportunité à laquelle on affectera des agents pour s’en occuper. (cf. figure 8)

La suite de cette tâche s’inscrit dans le cadre des processus suivants qui sont le

processus de vente et le processus d’après-vente. La description de ces processus est

présentée dans l’annexe [B].

IV Choix de la méthodologie de conception adoptée:

« La qualité du processus de développement d’un logiciel est garante de la qualité du

produit.» [4]. La conception est une étape fondamentale dans le cycle de vie d’une

application informatique. En effet, c’est d’elle que dépendent la qualité et la cohérence

du produit réalisé au développement. Des méthodes de génie logiciel ont alors été

développées afin de guider le concepteur dans sa tâche.

Pour mener à bien ce travail, il est nécessaire de définir une méthodologie de travail.

Dans cette partie, nous présentons les choix conceptuels en termes de méthode de

conception, d’outils techniques et de cycle de vie logiciel.

IV.1 Choix de la méthode de conception :

Le plus grand avantage d’une méthode orientée objet est qu’elle permet de structurer un

système sans centrer l’analyse uniquement sur les données ou uniquement sur les

traitements mais sur les deux à la fois. Une telle approche a pour but de modéliser les

propriétés statiques et dynamiques de l’environnement du système. Elle met en

correspondance le problème et la solution, en préservant la structure et le comportement

du système analysé.

Page | 13


Ceci, nous a conduit à adopter l’approche orientée objet pour modéliser notre système

en se basant sur les diagrammes UML [3]. (cf. figure 9).

Figure 9: Les différentes vues du langage UML

IV.2 Choix du cycle de vie logiciel :

Le choix de la méthodologie qui sera utilisée doit répondre aux critères suivants :

Exprimer au mieux les besoins des futurs clients

Permettre de développer une application robuste et évolutive

Elaborer une application répondant aux besoins des clients dans des

délais respectables.

C’est pour cette raison qu’on a choisi d’adopter le processus unifié comme étant la

méthode de l’étude conceptuelle. En effet, cette méthode englobe l’ensemble des

activités exigées par un projet logiciel à travers un ensemble de principes génériques,

adaptables en fonction des spécificités des projets.

Donc c’est un Framework de processus générique pouvant être adapté à une large classe

de systèmes logiciels, à différents domaines d’application, à différents types

d’entreprises, à différents niveaux de compétences et à différentes tailles de projets.

Ce processus présente plusieurs avantages, que nous citons :

Limiter les coûts, en termes de risques, aux strictes dépenses liées à une seule

itération.

Limiter les risques de retard de mise en place du produit développé.

Accélérer le rythme de l’ensemble du développement.

Page | 14


Prendre en compte le fait que les besoins des utilisateurs et les exigences

correspondantes ne puissent être intégralement définies à l’avance.

A cet effet, il est intéressant de voir de quoi est composée la méthodologie, choisie dans

le cadre de ce projet, « Processus unifié (PU) » :

En fait, le Processus Unifié (UP) est un processus de développement logiciel « itératif

et incrémental, centré sur l’architecture, guidé par les cas d’utilisation et piloté par

les risques » :

Itératif et incrémentale : le projet est découpé en itérations ou étapes de courte

durée qui permettent de mieux suivre l’avancement global. A la fin de chaque

itération une partie exécutable du système finale est produite de façon

incrémentale (par ajout).

Centré sur l’architecture : tout système complexe doit être décomposé en partie

modulaire afin d’en faciliter la maintenance et l’évolution. Cette architecture

(fonctionnelle, logique, matérielle, etc.) doit être modélisée en UML, et pas

seulement documentée en texte.

Piloté par les risques : les risques majeurs du projet doivent être identifiés au

plutôt mais surtout levés le plus rapidement possible. Les mesures à prendre

dans ce cadre déterminent l’ordre d’itération.

Guidé par les cas d’utilisation : le projet est mené en tenant compte des besoins

et des exigences des utilisateurs. Les cas d’utilisation du futur système sont

identifiés, décrits avec précision et classés par priorité.

La gestion d’un tel processus est organisée selon les quatre phases suivantes :

initialisation, élaboration, construction et transition. (cf. figure 10)

La phase d’initialisation conduit à définir la « vision » du projet, sa portée, sa faisabilité,

son « business case », pour décider au mieux de sa poursuite ou de son arrêt.

La phase d’élaboration poursuit trois objectifs principaux en parallèle :

Identifier et décrire la majeure partie des besoins utilisateurs ;

Construire (et pas seulement décrire dans un document) l’architecture de base du

système ;

Lever les risques majeurs du projet.

Page | 15


La phase de construction consiste surtout à concevoir et à implémenter l’ensemble des

éléments opérationnels (autres que ceux de l’architecture de base). C’est la phase la plus

consommatrice en ressources et en efforts.

Enfin, la phase de transition permet de faire passer le système informatique des mains

des développeurs à celles des utilisateurs finaux. Les mots-clés en sont : conversion des

données, formation des utilisateurs, déploiement, bêta-tests.

Les activités de développement sont définies par cinq disciplines fondamentales qui

décrivent la capture des exigences, l’analyse et la conception, l’implémentation, le test

et le déploiement. La modélisation métiers est une discipline en amont, optionnelle et

transverse aux projets. PU doit donc être compris comme une trame commune des

meilleures pratiques de développement et non comme l’ultime tentative d’élaborer un

processus universel.

Figure 10: Le schéma synthétique du PU (Processus Unifié)

V Planning des tâches :

La figure ci-dessous (cf. figure 11) illustre la planification des tâches, qu’on a prévues,

durant la période du stage :

Page | 16


Figure 11: Planning de réalisation

VI Identification des besoins fonctionnels :

Nous présentons dans ce qui suit les différentes fonctionnalités du système. Ces

fonctionnalités doivent exprimer les attentes des différents utilisateurs envers notre

application. Les besoins spécifiés doivent être persistants, spécifiques et réalisables.

Les besoins fonctionnels doivent répondre aux questions suivantes :

A quoi sert le système ?

Ce qui doit faire le système et ces fonctions outils ?

La description des données manipulées ?

VI.1 Identification des acteurs du système :

Un acteur représente une personne, un matériel ou un logiciel qui interagit directement

avec le système en question.

Un acteur peut consulter et/ou modifier directement l’état du système en émettant ou

recevant des messages susceptible d’être porteurs de données.

Les types d’acteurs qui participent à notre système sont les suivants: (cf. figure 12)

Utilisateur.

Administrateur.

Responsable Marketing.

Responsable Commercial.

Agent Marketing.

Agent Commercial.

Page | 17


Utilisateur

Agent Commercial

Agent Marketing

Administrateur

Responsable Commercial

Responsable Marketing

Figure 12: Diagramme de classe des acteurs

VI.2 Identification des cas d’utilisation du système :

VI.2.1 Définition d’un cas d’utilisation :

Un cas d’utilisation représente une fonctionnalité du système qui a une plus value

attendue et mesurable à chacun des utilisateurs potentiels du système [3]. Ainsi, un cas

d’utilisation représente un ensemble de séquences d’actions qui sont réalisées par le

système et qui produisent un résultat observable et intéressant pour un acteur particulier.

Il modélise un service rendu par le système. Il exprime les interactions acteurs/système

et apporte une valeur ajoutée « notable » à l’acteur concerné.

De ce fait, les cas d’utilisation sont, principalement, utilisés pour :

définir le contour du système à modéliser (ils précisent le but à atteindre),

et aussi, pour permettre d'identifier les fonctionnalités principales (critiques) du

système.

VI.2.2 Classification des cas d’utilisation par acteur :

Dans cette partie, nous recensons les principales fonctionnalités offertes par le système,

tout en les associant aux acteurs qui devront en bénéficier.

Les acteurs du système Les cas d’utilisation à travers lesquels ils réagissent

Gérer les utilisateurs.

Page | 18


Gérer campagne.

Planifier campagne.

Lancer campagne.

Suivre campagne.

Gérer compte.

Gérer contact.

Gérer opportunités.

Gérer prospect.

Gérer produit.

Créer campagne.

Modifier campagne.

Gérer compte

Gérer contact.

Gérer opportunités.

Gérer les appels.

VI.2.3 Structuration des cas d’utilisation en packages :

Dans le but d’élaborer le modèle de cas d’utilisation et le regrouper en ensembles

fonctionnels cohérents, nous utiliserons le concept général d’UML qui s’appelle le

«package ».

L’organisation adoptée est faite de cette manière :

Page | 19


Figure 13: Structuration des cas d'utilisation en packages

VI.3 Diagramme général des cas d’utilisation :

Dans cette section, nous structurons les fonctionnalités du système dans un diagramme

de cas d‘utilisation général (cf. figure 14), permettant de donner une vision globale du

comportement fonctionnel du système.

Page | 20


Gérer communicationsUtil isateur

Gérer util isateursAdministrateur

Gérer contacts

Gérer comptes

Gérer produits

Gérer opportunités

Gérer campagnes

Agent Marketing Gérer prospects



Agent Commercial

Gérer documents

Figure 14: Diagramme général des cas d'utilisation

Page | 21


Description textuelle des cas généraux :

« Gérer utilisateurs » : cette fonctionnalité permet à l’administrateur de CYNCRM de

bien gérer :

Les agents.

Les comptes utilisateur (les utilisateurs du système).

Les profils utilisateur.

« Gérer comptes » : elle assure une bonne gestion des tiers de l’entreprise représentés

par des comptes.

« Gérer contacts » : elle assure une bonne gestion des contacts représentant les

comptes.

« Gérer produits » : elle assure une bonne gestion des produits ou des services offerts

par l’entreprise.

« Gérer campagnes » : elle assure une bonne gestion des campagnes de l’entreprise

ainsi que leur contrôle, planification, lancement et suivi.

« Gérer prospects » : elle assure une bonne gestion des prospects, ou encore, les clients

potentiels de l’entreprise.

« Gérer opportunités » : elle assure une bonne gestion des opportunités, dites aussi,

affaires. Ces opportunités peuvent, éventuellement, se transformer en des devis, et par la

suite en des contrats de vente.

« Gérer documents » : elle joue le rôle d’un GED (système de Gestion Electronique de

Documents). En effet, elle permet d’associer des documents aux produits et/ou aux

campagnes enregistrés dans la base de données du système.

« Gérer communications » : elle assure une bonne gestion des appels téléphoniques

entre l’entreprise et ses tiers.

VI.4 Modèle du domaine:

Dans cette section, après avoir mis au point une description fonctionnelle, nous

aborderons l’identification des concepts du domaine, appelés « objets métiers » à partir

de l’expression initiale des besoins de notre projet.

Etant donnée qu’on adopte la méthode de conception orienté objet, cette dernière

demande une description structurelle et statique sous forme de classes logicielles (classe

de conception).

Page | 22


Les meilleures classes candidates sont celles issues d’une analyse du domaine (appelée

aussi une analyse métier). Ces classes sont des concepts réels manipulés par les experts

du domaine. Elles sont déterminées directement à partir de la connaissance des

domaines ou par interviews des acteurs métiers.

En pratique, on s’est servis du modèle du domaine comme sources complémentaires

d’information à l’expression initiale des besoins et au modèle de cas d’utilisation et on a

adopté les étapes suivantes :

L’identification des concepts du domaine (classes conceptuelles) pour chaque

cas d’utilisation

L’élaboration d’un diagramme de classe du modèle du domaine.

Ainsi, en reprenant les cas d’utilisation un par un on extrait les concepts du domaine

suivants (cf. figure 15) :

Compte

idComptenom

Contact

idContactnom

1..n

1

1..n

1

Activité

idActiviténom

Utilisateur

idUtilisateurnom

0..n

1

0..n

1

effectuer

Opportunité

idOpportuniténom

Prospect

idProspectnom

0..11 0..11

correspondre

Campagne

idCampagnenom

1..n

0..n

1..n

0..ncibler

Document

idDocumenturl

1

0..n

Produit

idProduitnom

0..n

0..n

0..n

0..n

concerner

1

0..n

décrire

décrire2

0..n

1

0..n

1

Figure 15: Modèle du domaine

Dans le cadre de la gestion des campagnes, la classe Campagne représente la classe

principale autour de laquelle opèrent toutes les autres classes.

De plus, une campagne cible des comptes (représentés par la clase Compte) qui sont

invités à cette dernière. La notion d’invitation est représentée par la classe d’association

Invitation. Le résultat de cette invitation dépend de la réponse des comptes à l’égard de

la campagne ; cette réponse peut être positive, négative, neutre ou sans réponse.

Page | 23


La classe Compte représente un tiers de l’entreprise entretenant des relations avec cette

dernière.

De plus, un compte peut être représenté par un ou plusieurs contacts (représentés) par la

classe Contact.

Lorsqu’un contact est intéressé par un produit, celui-ci représentera pour l’entreprise un

Prospect (un client potentiel). Un prospect pourra éventuellement se transformer en une

opportunité de vente, c’est à dire une affaire, (représentée par la classe Opportunité),

dans le cas où il passe un devis ou une commande.

Les activités représentent les moyens de communications par l’intermédiaire desquels

l’entreprise communique avec ses comptes. Une activité peut être soit un appel, un mail,

un fax, une lettre.

Dans le cadre de ce projet, on a prévu seulement le cas de l’appel (représenté par la

classe Call).

La classe Document sert à référencer les documents relatifs aux produits et aux

campagnes.

Enfin, dans le cadre de la gestion des utilisateurs, la classe Agent représente le

personnel de l’entreprise et plus particulièrement qui appartient qui département

commercial ou marketing. La classe Utilisateur représente un agent qui possède un

compte utilisateur lui permettant d’accéder à l’application. En effet, à chaque profil, est

associé un ou plusieurs cas d’utilisation. Par conséquent, un utilisateur ne peut exécuter

que les cas qui correspondent à son ou ses profil(s).

VI.5 Spécification des cas d’utilisation:

Un cas d’utilisation “complexe” peut être décomposé en sous cas d’utilisation. Cette

décomposition, connue sous le nom de raffinement, permet de détailler les cas

d’utilisation afin d’associer au comportement des cas d’utilisation les opérations de

bases des classes reliées. Un cas d’utilisation “père” peut se connecter à ses “fils” par

deux types de relations : la relation d’utilisation - stéréotypée par «include» et a relation

d’extension -stéréotypée par «extend»

De plus, un état d'objet est un stade transitoire par lequel passe un objet (instance d’une

classe) au cours de son cycle de vie.

Dans cette section, nous procédons aux raffinements des cas d’utilisation généraux,

précédemment identifiés. Ensuite, nous déterminons les cycles de vie de certains objets

Page | 24


de système à réaliser, en modélisant les évolutions d’états de ces derniers, à l’aide des

diagrammes d’états-transitions.

VI.6 Raffinement du cas d’utilisation « Gérer produits » :

consulter produit

modifier produit

créer produit

gérer document

gérer produitAgent Marketing

<<extend>>

S'authentifier

<<include>>

Figure 16: Raffinement du cas " Gérer produits"

C’est la première brique du CRM qui permet à l’utilisateur de gérer les produits offerts

par l’entreprise. En effet, ce module permet à l’agent ou au responsable Marketing de

créer de nouveaux produits, de les modifier et de les consulter. En créant ou en

modifiant un produit, l’utilisateur a la possibilité d’associer ou de supprimer un ou

plusieurs documents qui sont en relation avec ce produit. De plus, il lui est possible de

chercher un produit précis en saisissant les critères de recherche désirés. (cf. figure 16)

Page | 25


VI.7 Raffinement du cas d’utilisation « Gérer campagne » :


Gérer campagnes

consulter campagne

contrôler

planif ier campagne

lancer campagne

suiv re campagne

céer campagne

modif ier campagne

Agent Marketing

gérer documents<<extend>>

S'autehentif ier

<<include>>

<<extend>>

Figure 17: Raffinement du cas " Gérer campagnes"

Le module « Gérer les campagnes » assure l’automatisation du processus de gestion des

actions marketing organisées par l’entreprise. En effet, il permet à l’utilisateur de créer

des campagnes. Une fois qu’une campagne est crée, l’agent marketing a la possibilité de

la rechercher, de la consulter ou de la modifier. Il est à noter qu’en créant ou en

modifiant une campagne, l’agent marketing peut lui associer ou supprimer des

documents qui sont en relation avec elle (comme est le cas dans la gestion des produits).

La fonction de contrôle permet au responsable marketing de vérifier le détail des

campagnes ajoutées afin de les valider, de les soumettre à la correction ou de les

annuler.

Une fois qu’une campagne est validée, le système offre la possibilité à l’utilisateur de la

planifier en précisant son cadre temporel et en lui associant les informations selon son

type (promotions, comptes, agents ou groupes d’agents).

La fonction de lancement permet de lancer une campagne qui a été déjà planifiée.

Quant à la fonction de suivi, elle offre des outils statistiques illustrant les résultats des

campagnes lancées. (cf. figure 17)

Diagramme d’état-transitions de l’objet « Campagne » :

Page | 26


Lorsqu’une campagne est crée, elle a le statut «nouvelle ». Ensuite, selon le résultat de

contrôle du responsable, elle sera « valide », « invalide » ou « annulée ». A chaque fois

que l’utilisateur la modifie, elle prend le statut « modifiée ». Suite à sa planification, elle

prend le statut « planifiée ». Puis, elle est « lancée ». Et enfin, quand sa date de fin est

échue, elle est, systématiquement, « clôturée ». (cf. figure 18)

modifiée

nouvelle

invalide

valide planifiée lancée

annulée

Clôturée

Figure 18: Diagramme d'états-transitions de l'objet "Campagne"

VI.8 Raffinement du cas d’utilisation « Gérer documents » :

Le module « gérer document » permet de gérer les documents associés aux produits ou

aux campagnes. En effet, l’utilisateur à la possibilité d’associer des documents à un

produit ou à une campagne ainsi que de les consulter. (cf. figure 19)

Utilisateur Gérer documents

Ajouter document

Consulter document

Supprimer document

Figure 19: Raffinement du cas " Gérer documents"

Page | 27


VI.9 Raffinement du cas d’utilisation « Gérer comptes » :

Créer compte

Consulter compte

Gérer comptesAgent Marketing

Modifier compte

S'authentifier

Gérer contacts

<<include>>

<<include>>

Supprimer compte

Figure 20: Raffinement du cas " Gérer comptes"

Le module « gérer comptes » assure la gestion des tiers/comptes de l’entreprise.

L’agent Marketing peut créer un compte. Pour chaque compte, il a la possibilité de créer

un ou plusieurs contacts. Une fois que le compte est crée, l’utilisateur peut le

rechercher, le consulter, le modifier ou le supprimer.

Il est à noter que la gestion des comptes fait, impérativement, appel à la gestion des

contacts. En effet, un compte ne peut pas exister tout seul, mais il doit être représenté

par un contact ou plusieurs. (cf. figure 20)

VI.10 Raffinement du cas d’utilisation « Gérer contacts » :

S'authentifier

Créer contact

Consulter contacts

Modifier contact

Gérer comptes

Gérer contacts

<<include>>

Agent Marketing

<<include>>

Supprimer contact

Figure 21: Raffinement du cas " Gérer contacts"

Page | 28


Le module « Gérer contacts » assure la gestion des contacts qui ont pour rôle de

représenter les comptes. L’utilisateur peut créer un contact. Par la suite, il a la

possibilité de l’associer à un compte soit en faisant appel à un compte déjà existant ou

en créant un nouveau.

Grâce à la fonction de consultation, l’utilisateur peut visualiser touts les contacts

disponibles comme il peut consulter le détail d’un contact précis. Il a aussi la possibilité

de rechercher un contact, de le modifier et de le supprimer. (cf. figure 21)

VI.11 Raffinement du cas d’utilisation « Gérer prospects » :

S'authentifier

Créer prospect

Consulter prospectAgent Marketing Gérer prospects

Supprimer prospect

<<include>>

Figure 22: Raffinement du cas " Gérer prospects"

La gestion des prospects est un moyen permettant d’automatiser le processus de

prospection.

Elle regroupe l'ensemble des activités ayant pour but de se faire connaître des clients

potentiels afin d'entrer en contact avec eux. L’utilisateur a la possibilité de créer un

nouveau prospect par l’association d’un couple (contact, produit). Selon l’origine du

prospect (campagne ou autres), il y a une procédure spécifique de création. S’il provient

d’une campagne, l’utilisateur peut consulter la liste des campagnes pour en choisir celle

qui est appropriée. De plus, en créant un prospect, l’utilisateur peut consulter la liste des

contacts ainsi que celle des produits. Il aussi possible de consulter la liste des prospects

disponibles et de supprimer les prospects, à volonté. (cf. figure 22)

Page | 29


Nouveau Modifié Converti en opportunité

Exclu

Figure 23: Diagramme d'états-transitions de l'objet "Prospect"

Lorsqu’il est crée, le prospect a le statut « nouveau ». Il peut être « modifié » une ou

plusieurs fois. Si l’utilisateur le supprime, il est alors « exclu ». Sinon, il sera « converti

en opportunité ». (cf. figure 23)

VI.12 Raffinement du cas d’utilisation « Gérer opportunités » :

Créer opportunité/Assigner prospect

Modifier opportunité

Consulter opportunité

Gérer communications

S'authentifier

Evaluer opportunité

Agent Marketing Gérer opportunités

<<include>>

<<include>>

Figure 24: Raffinement du cas " Gérer opportunités"

La gestion des opportunités constitue une continuité de la gestion des prospects. En

effet, l’utilisateur a la possibilité de créer une nouvelle opportunité, et ce en assignant

un agent à un prospect.

Une fois que l’opportunité est créée, elle pourrait alors être consultée ou modifiée une

ou plusieurs fois. (cf. figure 24)

Créée Modifiée Convertie en commande

Page | 30


Figure 25: Diagramme d'états-transitions de l'objet "opportunité"

Tout d’abord, une opportunité est « créée ». Ensuite, elle peut être « modifiée » une ou

plusieurs fois et puis, « convertie en commande » ou alors directement convertie en

commande. (cf. figure 25)

VI.13 Raffinement du cas d’utilisation « Gérer communication » :

Planifier appel

Utilisateur Gérer communications

S'autehentifier

<<include>>

Enregistrer appel

Consulter appels

Figure 26: Raffinement du cas " Gérer Communications"

La gestion des communications est un module qui intervient dans tous les processus

CRM. Elle permet à chaque utilisateur d’enregistrer les appels qui lui sont relatifs. En

effet, l’utilisateur a la possibilité d’enregistrer un appel qu’il a effectué avec un contact

et ce en introduisant les informations nécessaires. De même, il peut planifier un appel

pour être effectué par un agent (dont il est un supérieur hiérarchique) qu’il désigne à une

date donné. Ainsi, un utilisateur peut consulter la liste des appels qui lui sont affectés et

les effectuer. Il est à noter que si l’utilisateur n’est pas administrateur, il ne pourra

planifier un appel que pour lui-même. De plus, l’utilisateur peut consulter la liste des

appels effectués ainsi que ceux non encore effectués. Pour les appels non effectués, il

peut consulter les appels planifiés ainsi que ceux non encore planifiés. Si un appel

effectué est sans réponse, alors il pourra le consulter et le reporter pour une autre date.

(cf. figure 26)

Page | 31


Crée Planifié Effectué

Modifié

reporté

Figure 27: Diagramme d’états-transitions de l'objet appel

Le premier état d’un appel est « crée ». Il pourrait, par la suite, être « modifié » une ou

plusieurs fois. Lorsque l’utilisateur le planifie pour une certaine, il est alors « planifié ».

Puis, il est sera « effectué ». S’il n’y a pas eu de réponse, il sera « reporté ». (cf. figure

27)

VI.14 Raffinement du cas d’utilisation « Gérer utilisateurs » :

Gérer agents

Gérer comptes-util isateur

Gérer profi ls

Créer agent

Modifier agent

Consulter agent

<<extend>>

Gérer uti lisateurAdministrateur

Créer profil

Modifier profi l

Supprimer profil

Consulter profi l

Créer compte-util isateur

Modifier compte-uti lisateur

Supprimer compte-util isateur

Consulter compte-uti lisateur

S'authentifier

<<include>>

Figure 28: Raffinement du cas d'utilisation " Gérer Utilisateurs"

Cette fonctionnalité permet à l’administrateur de gérer les profils des utilisateurs et

d’affecter les droits d’accès aux différents modules du système. L’administrateur a la

possibilité de gérer les agents de l’entreprise (création, modification, consultation). De

Page | 32


même, il a la possibilité de créer des comptes utilisateurs permettant l’accès au système.

Pour chaque compte, il peut associer un ou plusieurs profils définissant les privilèges. Il

peut aussi consulter la liste des comptes-utilisateurs disponibles et de supprimer des

comptes.

En plus, la fonction de gestion des profils permet de créer des profils en leur affectant

des cas d’utilisation et/ou des sous cas d’utilisation. Il peut aussi consulter la liste des

profils disponibles et de supprimer les profils qu’il désire. (cf. figure 28)

Crée Désactivé

Activé

Supprimé

Figure 29: Diagramme d’états-transitions de l'objet utilisateur

L’objet utilisateur représente un compte qui peut être, dans un premier temps, « crée ».

Ensuite, celui-ci peut être soit « désactivé » soit « supprimé ». De plus, il a été désactivé

il pourra être « activé » de nouveau.

Tout dépend des décisions de l’administrateur. (cf. figure 29)

VII Identification des besoins non fonctionnels :

Ce sont des besoins qui spécifient des contraintes physiques sur les besoins fonctionnels

tels que :

La sécurité, la cohérence et l’intégrité des données présentes au niveau de la

base de données : Certaines données étant confidentielles et ne pouvant être utilisés

qu’après identification. Il est donc important de ne pas permettre l’accès à la base que

pour les utilisateurs légitimes.

L’ergonomie des interfaces : Il s’agit surtout de définir :

Les couleurs des zones de saisie, couleur de fond, images, images de fond.

La présentation des menus.

Les textes défilant, les changements de style et de la couleur.

La gestion des erreurs : L’application doit gérer mieux ces exceptions par

l’apparition d’un message d’alerte qui permettra de filtrer les données et de ne prendre

en considération que les données qui correspondent aux types adéquats.

La maintenance : On distingue trois sortes de maintenance :

Corrective : qui traite les défaillances des programmes ;

Page | 33


Adaptative : faire adapter le logiciel de recouvrement à des changements

matériels et logiciels.

Perfective : qui améliore la performance de notre système.

VIII Identification des risques :

Un risque qui se présente est la non fiabilité des informations sais auprès du

personnel.

Le non réalisation du système dans les délais souhaités.

L’incompréhension des besoins des utilisateurs ainsi que leur réalisation.

Le non disponibilité des matériels requis pour implanter l’architecture J2EE.

Conclusion :

Ce premier chapitre, a été consacré, en premier lieu, à la présentation générale du cadre

de notre travail : (présentation de la société d’accueil, description des objectifs et des

motivations…). En second lieu, nous avons procédé à l’étude préalable qui nous a

permis de comprendre les principes de base d’un système de gestion de la relation

client, en général. Ces principes nous ont permis, par la suite, d’identifier les principaux

besoins des utilisateurs et de tracer les grandes lignes de notre système en définissant

ses fonctionnalités et les acteurs qui interagissent avec. Puis, grâce au modèle de cas

d’utilisation, nous avons essayé de lever les ambiguïtés sur les besoins et les exigences.

L’analyse et la conception des cas d’utilisation seront détaillées dans le chapitre suivant.

Page | 34

Gestion de la Relation Client Analyse et Conception

Chapitre II : Analyse et Conception

Introduction :

Ce chapitre se consacre, en premier lieu, à l'analyse des besoins décrits dans le chapitre

précédant, en les affinant et en les structurant. L'objectif est d'accéder à une compréhension

plus aiguë des besoins et des exigences et d'en livrer une description facile à entretenir,

favorisant la structuration de l'ensemble du système, y compris de son architecture.

Il s’agit, donc, d’analyser les cas d’utilisation qui ont été identifiés et raffinés pendant la

spécification des besoins. En deuxième lieu, ce chapitre procède à l’enchaînement de

conception, ayant pour but de produire les spécifications d’implémentation du système en se

basant sur les produits de l’analyse. L’objectif est façonner le système et à lui donner une

forme répondant à tous les besoins et exigences.

I Analyse :

L’enchaînement d’analyse présente une analyse détaillée de chaque d’utilisation à travers les

diagrammes d’analyse, de classe et de collaboration.

I.1 Analyse du cas d’utilisation « Gérer produits » :

I.1.1 Traçabilité entre le modèle de cas d’utilisation et le modèle d’analyse

du cas d’utilisation « Gérer produits » :

La figure ci-dessous (cf. figure 30) illustre les classes d’analyse qui participent au cas

d’utilisation « Gérer produit » :

Figure 30: Traçabilité du cas d’utilisation «Gérer produits"

Page | 35


I.1.2 Diagramme de classe d’analyse du cas d’utilisation « Gérer

produit » :

Figure 31: Diagramme de classe d'analyse du cas "Gérer produit"

Pour gérer ses produits, l’utilisateur peut interagir avec le système grâce à des interfaces

dédiées à faciliter cette communication:

IUProduit : Cette interface permet à l’utilisateur de consulter la liste de ses produits et

d’effectuer une recherche rapide selon des critères bien définis. C’est à partir d’elle que

l’utilisateur peut passer à une interface de création ou de modification d’un produit.

IUAjoutProduit : Cette interface permet à l’utilisateur de créer un nouveau produit.

InterfaceModificationProduit : Elle permet à l’utilisateur de créer un produit donné.

Pour réaliser toutes ces opérations, le système se dote d’un GestionnaireProduit permettant

d’exécuter les fonctions. En effet, ce gestionnaire extrait les données nécessaires de la classe

Produit contenant les informations de touts les produits. (cf. figure 31)

I.1.3 Diagrammes de collaboration du cas « Gestion de produits » :

I.1.3.1 Diagramme de collaboration du cas « Créer produit » :

Dans ce paragraphe, on va décrire les scénarios de réalisation des opérations possibles sur les

produits par l’intermédiaire du diagramme de collaboration. On va traiter, seulement le cas de

création d’un nouveau produit car le cas de modification lui est similaire.

Figure 32: Diagramme de collaboration du cas "Créer produit"

Page | 36


Le modèle de collaboration ci-dessus (cf. figure 32) décrit le scénario de réalisation de la

création d’un nouveau produit. On suppose, pour ce diagramme, que, l’identification de

l’utilisateur est effectuée et que le formulaire de création du produit est affiché, après clic sur

le lien ‘Créer Produit’.

Description textuelle : L’utilisateur remplit le formulaire d’ajout en introduisant les

données dans leurs champs appropriés de l’interface IUAjoutProduit puis il valide. (1) et (2)

L’interface IUAjoutProduit demande au GestionnaireProduit de créer le produit. (3) Le

GestionnaireProduit crée un nouveau produit. (4) Le produit a été bien ajouté. (5) et (6) Un

message, indiquant à l’utilisateur que le produit a été bien enregistré, s’affiche. (7)

I.1.3.2 Diagramme de collaboration du cas « Rechercher produits » :

: Agent Marketing

: GestionnaireProduit : IUProduit

: Produit

1: Critères de recherche saisis

2: Bouton 'Recherche' cliqué

3: Récupérer produits

6: Liste produits retournée




Figure 33: Diagramme de collaboration du cas "Rechercher produit"

Description textuelle :

L’utilisateur saisit les critères de recherche dans les champs appropriés et clique sur le bouton

‘Recherche’. (1) et (2) L’interface IUProduit demande au GestionnaireProduit de rechercher

les produits correspondant aux critères de recherche saisis. (3) Le GestionnaireProduit extrait

les produits correspondant aux critères de recherche saisis. (4) Liste produits recherchés

retournée et affichée. (5) (6) (7) (cf. figure 33)

I.1.3.3 Diagrammes de collaboration du cas « Consulter produits » :

: Agent Marketing

: GestionnaireProduit : IUProduit

: Produit

1: Critères de recherche saisis

2: Bouton 'Recherche' cliqué






Figure 34: Diagramme de collaboration du cas "Consulter produit"

Page | 37


Description textuelle : L’utilisateur choisit le menu ‘Liste produit’. (1) L’interface

IUProduit demande au GestionnaireProduit de récupérer la liste des produits disponibles. (2)

Le GestionnaireProduit extrait la liste des produits disponibles. (3) Liste produits retournée et

affichée. (4) (5) (6) (cf. figure 34)

Remarque : Le traitement des fonctions de recherche et de consultation est le même pour

toute les entités de l’application. Pour cela, on a procédé à les analyser seulement pour le cas

du produit. En effet, le reste des entités sont traitées de la même manière.

I.2 Analyse du cas d’utilisation « Créer campagne » :

Vue sa richesse, l’analyse du cas « Gérer campagne » va être subdivisée en plusieurs

sections ; chaque section constituera l’analyse d’un cas.


pour le cas d’utilisation « Créer campagne » :

La figure ci-dessous (cf. figure 35) illustre les classes d’analyse qui participent dans le cas

d’utilisation « Créer campagne » :

Figure 35: Traçabilité du cas "Créer campagne"

I.2.2 Diagramme de classe d’analyse du cas « Créer campagne » :

Pour créer une campagne, l’utilisateur interagit avec le système à travers des interfaces

dédiées à faciliter cette communication :

IUCreationCampagne : Cette interface permet à l’utilisateur de saisir les données

nécessaires pour l’ajout d’une nouvelle campagne. Elle permet, également, de choisir des

produits à partir d’une liste des produits, afin de les associer à la nouvelle campagne. Et de

même pour les comptes.

Pour réaliser toutes ces opérations, le système se dote des gestionnaires

GestionnaireCampagne, GestionnaireProduit et GestionnaireCompte qui permettent

Page | 38


d’exécuter les opérations nécessaires à la création d’une nouvelle campagne. En effet, les

gestionnaires GestionnaireProduit et GestionnaireCompte extraient les données nécessaires,

respectivement des classes Produit et Compte contenant toutes les informations qui se

rapportent aux produits et aux comptes. Quant au GestionnaireCampagne, il permet

d’enregistrer des informations de la campagne créée dans la classe Campagne (cf. figure 36)

Campagne

Produit

Compte

Agent Marketing

GestionnaireProduit

GestionnaireCompte

IUCreationCampagne

ProduitCampagne

GestionnaireCampagne

Invitation

Figure 36: Diagramme de classe d'analyse du cas "Créer campagne"

I.2.3 Diagramme de collaboration du cas « Créer campagne » :

Le modèle de collaboration ci-dessous (cf. figure 37) décrit le scénario de réalisation de la

création d’une nouvelle campagne.

On suppose, pour ce diagramme, que l’identification de l’acteur est effectuée et que le

formulaire de création de campagne est affiché.

: Agent Marketing : IUCreationCampagne

: GestionnaireProduit

: GestionnaireCampagne

: GestionnaireCompte

: Campagne

: Produit

: Compte

: Invitation

: ProduitCampagne

1: Informations campagne saisies

2: Bouton 'Ajouter Produits' cliqué

7: Liste des produits affichée

8: Produits choisis

9: Bouton 'Ajouter Comptes' cliqué

14: Liste comptes affichée

15: Comptes choisis16: Bouton 'Valider' cliqué

25: Message "Campagne créée" affiché

17: Créer campagne

24: Campagne créée

10: Récupérer la liste des comptes

13: Liste comptes

4: Récupérer la liste des produits

5: Liste produits

3: Récupérer la liste des produits

6: Liste produits

22: Créer campagne

23: Campagne créée

18: Ajouter ProduitCampagne

19: ProduitCampagne Ajouté

20: Ajouter CompteCampagne

21: CompteCampagne ajouté

11: Récupérer la liste des comptes

12: Liste comptes

Figure 37: Diagramme de collaboration du sous cas d'utilisation "Créer campagne"

Page | 39



L’utilisateur remplit le formulaire en introduisant les données dans leurs champs appropriés

d’IUCreationCampagne et clique sur le bouton ‘Ajouter Produits’. (1) (2)

L’interface IUCreationCampagne demande au GestionnaireProduit de récupérer la liste des

produits disponibles. (3) Le GestionnaireProduit récupère les produits disponibles et les

affiche. (4) (5) (6) (7) L’utilisateur choisis les produits à ajouter à la campagne. (8) Même

scénario, pour l’ajout de comptes. (9) (15) L’utilisateur valide la création de la campagne.

(16) L’interface IUCreationCampagne demande au GestionnaireCampagne de créer la

nouvelle campagne. (17) Le GestionnaireCampagne ajoute une nouvelle campagne à la table

Campagne. (18) La campagne a été bien créée. (19) (20) (21)

I.3 Analyse du cas d’utilisation « Contrôler campagne » :


pour le cas d’utilisation « Contrôler campagne » :


d’utilisation « Créer campagne » :

Figure 38: Traçabilité du cas "Contrôler Campagne"

I.3.2 Modèle de classe d’analyse du cas « Contrôler campagne » :

Figure 39: Le modèle de classe d'analyse du cas "Contrôler campagne"

Page | 40


Pour contrôler ses campagnes, l’utilisateur interagit avec le système à travers l’interface

IUControleCampagne qui lui permet de choisir une campagne parmi la liste des celles créées

dans le but de vérifier sa validité.

Le système se dote d’un gestionnaire GestionnaireCampagne, qui permet d’exécuter les

opérations nécessaires pour le contrôle des campagnes. Il extrait les données nécessaires de la

classe Campagne contenant toutes les informations qui se rapportent aux campagnes. (cf.

figure 39)

I.3.3 Diagrammes de collaboration du cas « Contrôler campagne » :

Le modèle de collaboration ci-dessous (cf. figure 40) décrit le scénario de réalisation du

contrôle d’une campagne créée ou modifiée.

On suppose, pour ce diagramme, que, l’identification de l’acteur est effectuée et que la liste

des campagnes créées et modifiées est affichée.

Remarque : On va supposer que l’utilisateur va valider la campagne ; le traitement est le

même s’il la soumet à la correction ou l’annule.

Figure 40: Diagramme de collaboration du sous cas d'utilisation "Contrôler campagne"


L’utilisateur choisit la campagne à contrôler. (1) L’interface InterfaceContrôlerCampagne

demande au GestionnaireCampagne d’afficher le détail de la campagne choisie. (2) Le

GestionnaireCampagne extrait les données de la campagne choisie. (3) Le détail de la

campagne a été bien extrait et, puis, affiché. (4) (5) (6) L’utilisateur valide la campagne. (7)

L’interface InterfaceContrôlerCampagne demande au GestionnaireCampagne de valider la

campagne. (8) Le GestionnaireCampagne change le statut de la campagne en « valide ». (9)

La campagne a été bien validée. (10) (11) (12)

Page | 41


I.4 Analyse du cas d’utilisation « Planifier campagne » :


pour le cas d’utilisation« Planifier campagne » :


d’utilisation « Planifier campagne » :

Figure 41: Traçabilité du cas "Planifier campagne"

I.4.2 Modèle de classe d’analyse du cas d’utilisation « Planifier

campagne » :

Figure 42: Diagramme de classe d'analyse du cas "Planifier campagne"

Pour planifier une campagne, l’utilisateur interagit avec le système grâce à des interfaces


IUPlanificationCampagne.

IUAjoutPromotion.

Le système se dote des gestionnaires GestionnaireCampagne, GestionnaireProdui-

tCampagne, GestionnairePromotion et GestionnaireAssignement permettant de traiter les

données nécessaires, respectivement, des classes Campagne, ProduitCampagne, Promotion,

Page | 42


et Assignement contenant toutes les informations qui se rapportent aux campagnes, produits,

promotions, et assignements. (cf. figure 42)

I.4.3 Diagramme de collaboration du cas d’utilisation du cas « Planifier

campagne » :


planification d’une campagne validée.

On suppose, pour ce diagramme, que, le responsable marketing est identifié, le formulaire de

planification de la campagne choisie est affiché, la liste des agents qui n’ont pas été encore

assignés à un compte est aussi affichée et que la liste des comptes invités à la campagne mais

qui n’ont pas été encore assignés à des agents est également affichée.

Figure 43: Diagramme de collaboration "Planifier campagne"


L’utilisateur complète le formulaire de planification en introduisant les données dans leurs

champs appropriés de l’interface IUPlanificationCampagne et clique sur le bouton ‘Ajouter

Promotion ‘. (1) (2) L’interface IUPlanificationCampagne demande à l’interface

IUAjoutPromotion d’être affichée. (3) L’interface IUAjoutPromotion est affichée. (4)

L’utilisateur saisit les informations relatives à la promotion dans les appropriés de l’interface

IUAjoutPromotion et clique sur le bouton ‘Ajouter Produit’ de l’interface IUAjoutPromotion.

Page | 43


(5) (6) L’interface IUAjoutPromotion demande au GestionnaireProduitCampagne d’afficher

la liste des produits associés à la campagne lors de sa création. (7)° Le

GestionnaireProduitCampagne extrait la liste des produits relatifs à la campagne, qui va être

affichée par l’interface IUAjoutPromotions. (8) (9) (10) (11) L’utilisateur sélectionne la liste

des produits et valide. (12) (13) L’interface IUAjoutPromotion demande au

GestionnairePromotion de créer la promotion. (14) Le GestionnairePromotion crée une

nouvelle promotion et l’ajoute à la classe Promotion. (15) (16) (17) L’interface

IUPlanificationCampagne rafraîchit la liste des promotions, initialement vide, et l’affiche.

(18) L’utilisateur sélectionne les agents et des comptes qu’il souhaite assigner les aux autres

et clique sur le bouton ‘Assignement’. (19) (20) L’interface IUPlanificationCampagne

demande au GestionnaireAssignement d’assigner les comptes et les agents choisis. (21) Le

GestionnaireAssignement assigne les agents et les comptes les aux autres. L’interface

IUPlanificationCampagne rafraîchit la liste des assignements, initialement vide, et l’affiche.

(25) L’interface IUPlanificationCampagne demande au GestionnaireCampagne d’enregistrer

la planification effectuée. (27) Le GestionnaireCampagne enregistre les informations entrées

et change le statut de la campagne de ‘valide’ à ‘planifiée’. (28)

I.5 Analyse du cas d’utilisation « Lancer campagne » :


pour le cas d’utilisation « Lancer campagne » :


d’utilisation « Lancer campagne ».

Figure 44: Traçabilité du cas "Lancer campagne"

Page | 44


I.5.2 Diagramme de classe d’analyse du cas d’utilisation « Lancer

campagne » :

CampagneGestionnaireCampagneResponsable Marketing IULancementCampagne

Figure 45: Diagramme de classe d'analyse du cas "Lancer Campagne"

Pour lancer une campagne, l’utilisateur peut interagir avec le système grâce à l’interface

IULancement Campagne dédiée à faciliter cette communication.

De même, le système se dote d’un GestionnaireCampagne permettant de traiter les données

nécessaires de la classe Campagne contenant toutes les informations qui se rapportent aux

campagnes. (cf. figure 45)

I.5.3 Diagramme de collaboration du cas d’utilisation « Lancer

campagne » :

Le modèle de collaboration ci-dessous (cf. figure 46) décrit le scénario de réalisation du

lancement d’une campagne planifiée. On suppose, pour ce diagramme, que :

Le responsable marketing est identifié.

La liste des campagnes planifiées est affiché, après clic sur le sous-menu ‘Lancer

Campagne’.

: Responsable Marketing

: GestionnaireCampagne

: Campagne

: IULancementCampagne

1: Campagne choisie

6: Détails campagne affiché

7: Bouton 'Lancer' cliqué

12: Message "Campagne lancée" affiché

3: Récupérer détails campagne

4: Détails campagne

9: Modifier campagne

10: Campagne modifiée

2: Récupérer détails campagne

5: Détails campagne retourné

8: Modifier campagne

11: Campagne lancée

Figure 46 : Diagramme de collaboration "Lancer campagne"


L’utilisateur choisit la campagne qu’il a décidé lancer et clique sur le lien ‘Détails’. (1)

L’interface IULancementCampagne demande au gestionnaireCampagne d’afficher les détails

de la campagne choisie. Le GestionnaireCampagne extrait les données de la campagne

choisie. (3) Données campagne retournées. (4) (5) (6) L’utilisateur lance la campagne en

Page | 45


cliquant sur le bouton ‘Lancer’. (7) L’IULancementCampagne demande au

gestionnaireCampagne de la lancer. (8) Le GestionnaireCampagne change son statut de

« planifiée » à « lancée». (9) La campagne a été bien lancée. (10) (11) (12)

I.6 Analyse du cas d’utilisation « Suivre campagne » :


pour le cas d’utilisation « Suivre campagne » :


d’utilisation « Suivre campagne » :

Figure 47: Traçabilité du cas d'utilisation "Suivre campagne"

I.6.2 Diagramme de classe d’analyse du cas d’utilisation « Suivre

campagne » :

Responsable Marketing IUSuiviCampagne CampagneGestionnaireCampagne

Invitation

Figure 48: Diagramme de classe d'analyse "Suivre campagne"

C’est grâce à la fonction de suivi des campagnes que le responsable marketing a la possibilité

de suivre les campagnes lancées. Pour ce faire, l’utilisateur interagit avec le système via

l’interface IUSuiviCampagne dédiée à faciliter cette communication.

De même, le système se dote d’un GestionnaireCampagne permettant de traiter les données

nécessaires de la classe Campagne contenant toutes les informations qui se rapportent aux

campagnes. (cf. figure 48)

Page | 46


I.6.3 Diagramme de collaboration du cas d’utilisation « Suivre

campagne » :

Le modèle de collaboration ci-dessous (cf. figure 49) décrit le scénario de réalisation du suivi

d’une campagne lancée.

On suppose, pour ce diagramme, que :

Le responsable marketing est identifié.

La liste des campagnes lancées est affiché, après clic sur le sous-menu ‘Suivi

Campagne’.

Figure 49: Diagramme de collaboration "Suivre campagne"


L’utilisateur choisit la campagne qu’il désire suivre et clique sur le lien ‘Suivi’. (1)

L’interface IUSuiviCampagne demande au gestionnaireCampagne d’afficher le suivi de la

campagne choisie. (2) Le GestionnaireCampagne extrait le suivi de la campagne choisie. (3)

Le suivi campagne est retourné. (4) (5) (6) L’utilisateur change la nature d’une réponse. (7)

Le GestionnaireCampagne met à jour la réponse et l’enregistre. (9) La réponse a été bien

mise à jour. (10) (11) (12)

I.7 Analyse du cas d’utilisation « Gérer comptes » :


pour le cas d’utilisation « Gérer comptes » :


d’utilisation « Gérer comptes » :

Page | 47


Figure 50: traçabilité du cas d'utilisation "Gérer comptes"

I.7.2 Diagramme de classe d’analyse du cas « Gérer comptes » :

Compte

Agent Marketing

Contact

IUAjoutCompte

IUModoficationCompte

GestionnaireContact

IUCompte

GestionnaireCompte

Figure 51: Le modèle de classe d'analyse du cas "Gérer compte"

Pour gérer ses comptes, l’utilisateur peut interagir avec le système grâce à des interfaces


IUCompte .

InterfaceAjoutCompte .

InterfaceModificationCompte .

Mais, pour réaliser toutes ces opérations, le système se dote d’un gestionnaire

GestionnaireCompte, qui permet d’exécuter les fonctions selon le choix de l’utilisateur. Les

gestionnaires GestionnaireCompte et GestionnaireContact extraient les données nécessaires,

respectivement des classes Compte et Contact contenant toutes les informations qui se

rapportent aux comptes et aux contacts. (cf. figure 51)

I.7.3 Diagrammes de collaboration du cas « Gérer comptes » :


création d’un nouveau compte.


Page | 48


L’identification de l’acteur est effectuée.

Le formulaire de création d’un nouveau compte, après clic du sous-menu ‘Créer

compte’.

Remarque :

On va supposer que l’utilisateur va créer un compte ; le traitement est identique pour la

modification et qu’il est possible, au de la création d’un nouveau compte, d’ajouter des

contacts à ce dernier ; dans ce cas le système exécute le cas d’utilisation « Créer contact ».

: Agent Marketing : IUCompte : GestionnaireCompte : Compte

1: Informations comptes saisies

2: bouton 'valider' cliqué 3: demande d'ajout compte 4: ajouter compte

5: compte ajouté6: compte ajouté7: message 'compte ajouté' affiché

Figure 52: Diagramme de collaboration du cas d'utilisation "Créer Compte"


L’utilisateur remplit le formulaire d’ajout en introduisant les données dans leurs champs

appropriés de l’Interface IUAjoutCompte. (1) L’interface IUAjoutCompte demande au

gestionnaire GestionnaireCompte d’ajouter un nouveau compte. (2) L’interface

InterfaceAjoutCompte demande au GestionnaireCompte d’ajouter le compte. (3) Le

GestionnaireCompte ajoute un nouveau compte à la classe Compte. Le compte a été bien

crée. (5) (6) (7)

I.8 Analyse du cas d’utilisation « Gérer contacts » :


pour le cas d’utilisation « Gérer contacts » :

Figure 53: Traçabilité du cas d'utilisation "Gérer contacts"

Page | 49


I.8.2 Diagramme de classe d’analyse du cas « Gérer contacts » :

Agent Marketing

Contact

Compte

IUContact

GestionnaireCompte

IUAjoutContact

GestionnaireContact

IUModoficationContact

Figure 54: Diagramme de classe d'analyse du cas d'utilisation "Gérer contacts"

Pour gérer ses contacts, l’utilisateur peut interagir avec le système grâce à des interfaces


IUContacts .

InterfaceAjoutContact .

InterfaceModificationContact .

Mais, pour réaliser toutes ces opérations, le système se dote des gestionnaires

GestionnaireCompte et GestionnaireContact qui permettent d’exécuter les fonctions selon le

choix de l’utilisateur. Les gestionnaires GestionnaireCompte et GestionnaireContact extraient

les données nécessaires, respectivement des classes Compte et Contact contenant toutes les

informations qui se rapportent aux comptes et aux contacts. (cf. figure 52)

I.8.3 Diagrammes de collaboration du cas « Gérer contacts » :

: Agent Marketing

: IUContact : GestionnaireContact

1: informations contacts saisies

2: bouton 'valider' cliqué 3: demande d'ajout contact

: Contact

4: ajouter contact

5: contact ajouté6: contact ajouté7: message 'contact ajouté' affiché

Figure 55: Diagramme de collaboration du cas "Créer Contact"

I.9 Analyse du cas d’utilisation « Gérer prospects » :


pour le cas d’utilisation « Gérer prospects » :


d’utilisation « Gérer prospects » :

Page | 50


Figure 56: Traçabilité du cas "Gérer prospects"

I.9.2 Diagramme de classe d’analyse du cas « Gérer prospects » :


GestionnaireCampagne Campagne

Produit

Contact

Prospect

GestionnaireProduit

GestionnaireContact

IUAjoutProspect

IUProspect

IUSuppressionProspect

GestionnaireProspect

Figure 57: Diagramme de classe d'analyse du cas "Gérer prospects"

Pour gérer ses prospects, l’utilisateur peut interagir avec le système grâce à des interfaces


L’interface IUProspect est une classe interface permettant à l’utilisateur de gérer les prospects. Les

fonctionnalités, qu’offre cette interface, sont l’ajout (création), la consultation, la recherche et la

suppression des prospects. (cf. figure 57)

Remarque : La description du reste des classes est identique au cas analysés, ci-dessous.

I.9.3 Diagramme de collaboration du sous cas « Créer prospect » :


création d’un nouveau prospect.



Le formulaire de création d’un nouveau prospect est affiché.

Le prospect, à créer, ne provient pas d’une campagne (c’est le cas nominal).

Page | 51


: Agent Marketing

: IUProspect

: IUAjoutProspect : GestionnaireContact

: GestionnaireProspect

: Gestionnaire Produit

: Contact

: Produit

: Prospect

1: Informations prospects saisies2: Bouton "Ajouter produits" cliqué

7: liste produits affichée

8: Produits choisis

9: Bouton "Ajouter contact" cliqué

14: liste contacts affichée

15: Contacts choisis

16: valider

21: message 'prospect crée' affiché

3: Récupérer liste produits

6: Produits récupérés

10: Récupérer liste contacts

13: Contacts récupérés

17: Créer prospect

11: Récupérer liste contacts

12: Contacts récupérés

18: Créer prospect

19: Prospect crée20: Prospect crée

4: Récupérer liste produits

5: Produits récupérés

Figure 58: Diagramme de collaboration du cas d'utilisation "Créer prospect"


L’utilisateur remplit le formulaire d’ajout de prospect en introduisant les données dans leurs

champs appropriés de l’Interface IUAjoutProspect et clique sur le bouton ‘Ajouter Produit’.

(1) (2) Le GestionnaireProduit extrait la liste des produits à partir de la classe Produit. (4)

L’utilisateur choisit les produits auxquels le prospect s’intéresse et clique sur le bouton

‘Ajouter Contact’. (8) (9) Le GestionnaireContact extrait la liste des contacts à partir de la

classe Contact. (11) L’utilisateur choisit le contact intéressé par les produits et valide. (15)

(16) Le GestionnaireProspect crée le prospect et l’enregistre dans la classe prospect. (18) Le

prospect a été bien crée. (19) (20) (21)

I.10 Analyse du cas d’utilisation « Gérer opportunités » :

Dans notre analyse, nous nous sommes contentées d’analyser les cas qui entrent dans le cadre

du module marketing.

I.10.1 Traçabilité entre le modèle de cas d’utilisation et le modèle

d’analyse pour le cas d’utilisation « Créer opportunité » :


d’utilisation « Gérer opportunités » :

Page | 52


Figure 59: Traçabilité du cas d'utilisation "Gérer opportunités"

I.10.2 Modèle de classe d’analyse du cas « Créer opportunité » :

OpportunitéResponsable Commercial

IUEvaluationOpportunité

GestionnaireOpportunitéIUModificationOpportunité

GestionnaireAgent Agent

IUOpportunité

IUAjoutOpportunité

Figure 60: Diagramme de classe d'analyse du cas "Gérer opportunités"

Pour gérer les opportunités, l’utilisateur peut interagir avec le système grâce à des interfaces


IUOpportunité : Elle permet à l’utilisateur de consulter la liste des opportunités,

d’effectuer une recherche rapide dans la liste des opportunités disponibles selon des

critères de recherche bien définis. C’est à partir d’elle que l’utilisateur peut passer à une

interface de création (ajout), de modification ou d’évaluation d’une opportunité.

IUAjoutOpportunité : Elle va être affichée lorsque l’utilisateur décide d’ajouter une

opportunité. C’est à partir de cette page que l’utilisateur puisse introduire une nouvelle

opportunité.

Page | 53


IUModificationOpportunité : Elle va être affichée lorsque l’utilisateur décide de modifier

une opportunité donnée.

IUEvaluationModification : Elle va être affichée lorsque l’utilisateur décide d’évaluer une

opportunité donnée.

Pour réaliser toutes ces opérations, le système se dote d’un gestionnaire

GestionnaireOpportunité, qui permet d’exécuter les fonctions selon le choix de l’utilisateur.

Le gestionnaire GestionnaireOpportunié traite les données nécessaires de la classe

Opportunité contenant toutes les informations concernant les opportunités. (cf. figure 60)

I.10.3 Diagrammes de collaboration du cas « Créer opportunité» :


création d’un nouveau prospect. On suppose, pour ce diagramme, que :


Le formulaire d’ajout d’opportunité est affiché.

Remarque : On va supposer que l’utilisateur va créer une opportunité ; le traitement est

identique pour la modification et l’évaluation.

: Responsable Commercial

: IUAjoutOpportunité

: IUOpportunité

: GestionnaireOpportunité : Opportunité

: Agent : GestionnaireAgent

1: Infos opportunité saisies

2: Bouton 'Assigner Agent' cliqué

7: liste des agents affichée

8: Agents choisis et bouton 'Valider' cliqué

9: Créer opportunité

3: Récupérer liste des agents

6: liste des agents

13: Message "Opportunité créée" affiché

10: Créer opportunité

11: opportunité créée

12: opportunité créée

4: Récupérer liste des agents

5: liste des agents

Figure 61: Diagramme de collaboration du cas d'utilisation "Créer opportunité"


L’utilisateur saisit les informations de l’opportunité et clique sur le lien ‘Assigner Agents’ de

l’interface IUAjoutOpportunité. (1) (2) Le GestionnaireAgent extrait la liste des agents à

partir de la classe agents. (4) La liste des agents a été bien retournée. (5) (6) (7) L’utilisateur

choisit la liste des agents et clique sur le bouton ‘Valider’. (8) Le GestionnaireOpportunité

crée une nouvelle opportunité et l’ajoute à la table Opportunité. (10) L’opportunité a été bien

créée. (11) (12) (13)

Page | 54


I.11 Analyse du cas d’utilisation « Gérer appels » :


pour le cas d’utilisation « Gérer appels » :


d’utilisation « Gérer appels » :

Figure 62: Traçabilité du cas "Gérer appels"

Pour gérer les appels, l’utilisateur peut interagir avec le système grâce à des interfaces dédiées

à faciliter cette communication :

IUAjoutAppel : C’est une classe interface qui permet d’enregistrer un appel effectué.

IUEffectuationAppel : C’est une classe interface permettant à l’utilisateur de consulter la

liste des appels assignés et planifiés et de les effectuer.

IUPlanificationAppel : C’est une classe interface qui permet de planifier un appel.

IUSuiviAppel : C’est une classe interface permettant à l’utilisateur de consulter la liste des

appels effectués et de reporter des appels n’ayant pas de réponse.

GestionnaireAppel : C’est une classe contrôle qui permet de gérer toutes les opérations

possibles sur les appels.

GestionnaireAgent : C’est une classe contrôle qui permet de gérer toutes les opérations

possibles sur les agents.

GestionnaireContact : C’est une classe contrôle qui permet de gérer toutes les opérations

possibles sur les contacts.

Appe l : C’est une classe entité contenant toutes les informations de chaque appel.

Agent: C’est une classe entité contenant toutes les informations de chaque agent.

Contact: C’est une classe entité contenant toutes les informations de chaque contact.

Page | 55


I.11.2 Modèle de classe d’analyse du cas « Gérer appels» :

Appel

Utilisateur

Contact

Utilisateur

IUEffectuationAppel

IUSuiviAppel

IUAjoutAppel GestionnaireAppel

GestionnaireUtilisateur

IUPlanificationAppel GestionnaireContact

Figure 63: Diagrammes de classes d'analyse du cas "Gérer communications"

I.11.3 Diagrammes de collaboration du cas « Gérer appel » :

I.11.3.1 Diagramme de collaboration du cas « Enregistrer appel » :

Le modèle de collaboration ci-dessous (cf. figure 64) décrit le scénario de réalisation

d’enregistrement/ajout instantané d’un appel.



Le formulaire d’ajout d’appel est affiché.

: IUAjoutAppel : Utilisateur

: GestionnaireAppel

: GestionnaireContact : Contact

: Appel

3: Récupérer la liste des contacts

6: Liste contacts

10: Créer appel

13: Appel Crée

1: Formulaire rempli

2: Bouton 'Ajouter contact' cliqué

7: Liste contacts affichée

8: Contact choisi

9: Bouton 'Valider' cliqué

14: Message "Appel crée" affiché

4: Récupérer la liste des contacts

5: Liste contacts

11: Créer appel

12: Appel Crée

Figure 64: Diagramme de collaboration du cas d'utilisation "Créer appel"


L’utilisateur saisit les informations de l’appel et clique sur le bouton ‘Ajouter contact’(1)

(2).Le GestionnaireContact extrait les contacts de la table Contact (4). Liste des contacts

retournée et affichée (5) (6) (7). L’utilisateur choisit un contact et clique sur le bouton

Page | 56


‘Créer’(8) (9). Le GestionnaireAppel ajoute un nouvel appel à la table Appel (11). L’appel a

été bien crée (12) (13) (14).

I.11.3.2 Diagramme de collaboration du cas d'utilisation "Effectuer appel" :

Le modèle de collaboration ci-dessous (cf. figure 65) décrit le scénario d’effectuation d’un

appel. On suppose, pour ce diagramme, que l’identification de l’acteur est effectuée et que le

formulaire d’effectuation d’appels est affiché.

Remarque : On va supposer que l’utilisateur va effectuer un appel assigné ; le traitement est

le même pour un appel planifié.

Figure 65: Diagramme de collaboration du cas d'utilisation "Effectuer appel"


L’utilisateur saisit une date dans le champ approprié et valide (1). Le GestionnaireAppel

extrait la liste des appels assignés pour être effectués à la date saisie (3). La liste des

appels assignés est bien retournée et affichée (4) (5) (6). L’utilisateur choisit un appel et

clique sur le lien détails (7). Le GestionnaireAppel extrait les détails de l’appel choisi (9).

Les détails de l’appel sont bien retournés (10) (11) (12). L’utilisateur saisit la durée de

l’appel et éventuellement des notes concernant cet appel et valide (13) (14). Le

GestionnaireAppel enregistre l’appel effectué (16). L’appel effectué est bien

enregistré(17) (18) (19).

I.11.3.3 Diagramme de collaboration du cas d'utilisation « Planifier appel » :

Le modèle de collaboration ci-dessous (cf. figure 66) décrit le scénario de réalisation de

planification d’un appel. On suppose, pour ce diagramme, que, l’identification de l’acteur est

effectuée et que le formulaire de planification d’appel est affiché.

Remarque : On va supposer que l’utilisateur est, dans ce cas administrateur ; c'est-à-dire qu’il

a le privilège d’assigner des appels à des utilisateurs autres que lui même. Le traitement est

Page | 57


similaire pour un simple utilisateur ; il est, par défaut, l’utilisateur à être affecté à l’appel en

cours de planification.

Figure 66: Diagramme de collaboration du cas d'utilisation "Planifier appel"

Description textuelle : L’utilisateur remplit le formulaire de planification de l’appel et

clique sur le bouton ‘Ajouter contact’. (1) (2) Le GestionnaireContact extrait les contacts de la

table Contact. (4) La liste des contacts retournée et affichée. (5) (6) (7) L’utilisateur choisit un

contact et clique sur le bouton ‘Assigner utilisateur’. (8) (9) Le GestionnaireUtilisateur extrait

les contacts de la table Utilisateur. (11) (12) La liste des utilisateurs est bien retournée. (13)

(14) (15) L’utilisateur choisit un utilisateur et valide la planification de l’appel. (16) Le

GestionnaireAppel ajoute un nouvel appel et le planifie dans la classe Appel. (18) L’appel est

bien crée et planifié. (19) (20) (21)

I.11.3.4 Diagramme de collaboration du cas d'utilisation "Suivre appel" :

Le modèle de collaboration ci-dessous (cf. figure 67) décrit le scénario de suivi d’un appel

effectué. On suppose, pour ce diagramme, que, l’identification de l’acteur est effectuée et que

la liste des appels effectués est affichée.

Figure 67: Diagramme de collaboration du cas d'utilisation "Suivre appel"


Page | 58


L’utilisateur choisit un appel et clique sur le bouton ‘Détails’. (1) Le GestionnaireAppel

extrait les détails de l’appel de la table Appel. (3) Les détails de l’appel sont bien

retournés. (4) (5) (6) L’utilisateur saisit les informations relatives au reportage de l’appel

et valide. (7) Le GestionnaireAppel met à jour l’appel reporté dans la table Appel. (9)

L’appel a été bien reporté. (10)

I.12 Analyse du cas d’utilisation « Gérer profils » :


pour le cas d’utilisation « Gérer profils » :


d’utilisation « Gérer profils » :

Figure 68: Traçabilité du cas "Gérer profils"

I.12.2 Modèle de classe d’analyse du cas « Gérer profils » :

Administrateur

IUModificationProfil

IUProfil

IUCreationProfil

GestionnaireProfil Profil

Figure 69: Diagrammes de classes d'analyse du cas "Gérer profils"

Pour gérer les profils, l’utilisateur interagit avec le système grâce à des interfaces dédiées à

faciliter cette communication :

Page | 59


IUProfil : Cette interface permet à l’utilisateur de consulter la liste des profils et

d’effectuer une recherche rapide dans la liste des profils disponibles selon des critères de

recherche bien définis. C’est à partir d’elle que l’utilisateur peut supprimer un profil ou

passer à une interface de création (ajout) ou de modification d’un nouveau profil.

IUCreationProfil : Elle va être affichée lorsque l’utilisateur décide d’ajouter un nouveau

profil.

IUModificationProfil : Elle va être affichée lorsque l’utilisateur décide modifier un profil

donné.

Pour réaliser toutes ces opérations, le système se dote d’un GestionnaireProfil permettant

d’exécuter les fonctions selon le choix de l’utilisateur. En effet, ce gestionnaire extrait les

données nécessaires de la classe Profil qui contient toutes les informations se rapportant à

touts les profils. (cf. figure 69)

I.12.3 Diagrammes de collaboration du cas « Gérer profils » :


profils par l’intermédiaire du diagramme de collaboration. On va traiter, donc, seulement le

cas de création d’un nouveau profil car le cas de modification lui est similaire. Le modèle de

collaboration ci-dessous (cf. figure 70) décrit le scénario de réalisation de la création d’un

nouveau profil.



Le formulaire de création du profil est affiché, après clic sur le lien ‘Créer Profil’.

Figure 70: Diagramme de collaboration du cas d'utilisation "Créer profil"


L’utilisateur remplit le formulaire d’ajout en introduisant les données dans leurs champs

appropriés de l’interface IUCreationProduit. (1) (2) Le GestionnaireProfil crée un nouveau

profil et l’ajoute dans la classe Profil. (4) Le profil a été bien crée. (5) (6) (7)

Page | 60


I.13 Analyse du cas d’utilisation « Gérer agents » :

I.13.1 Réalisation-Analyse du cas d’utilisation « Gérer agents » :


d’utilisation « Gérer agents » :

Figure 71: Traçabilité du cas "Gérer agents"

I.13.2 Modèle de classe d’analyse du cas « Gérer agents » :

Administrateur AgentGestionnaireAgent

IUCreationAgent

IUAgent

IUModificationAgent

Figure 72: Diagrammes de classes d'analyse du cas "Gérer agents"

Pour gérer les agents, l’utilisateur interagit avec le système grâce à des interfaces dédiées à

faciliter cette communication :

IUAgent : Cette interface permet à l’utilisateur de consulter la liste des profils et

d’effectuer une recherche rapide dans la liste des profils disponibles selon des critères de

recherche bien définis. C’est à partir d’elle que l’utilisateur peut supprimer un profil ou

passer à une interface de création (ajout) ou de modification d’un nouveau profil.

IUCreationAgent : Elle va être affichée lorsque l’utilisateur décide d’ajouter un nouveau

profil.

IUModificationAgent : Elle va être affichée lorsque l’utilisateur décide modifier un agent.

Page | 61


Pour réaliser toutes ces opérations, le système se dote d’un GestionnaireAgent permettant

d’exécuter les fonctions selon le choix de l’utilisateur. En effet, ce gestionnaire extrait les

données nécessaires de la classe Agent qui contient toutes les informations se rapportant à

touts les agents. (cf. figure 72)

I.13.3 Diagrammes de collaboration du cas « Gérer agents » :


agents par l’intermédiaire du diagramme de collaboration.

On va traiter, donc, seulement le cas de création d’un nouvel agent car le cas de modification

lui est similaire.


création d’un nouvel agent.

On suppose, pour ce diagramme, que l’identification de l’acteur est effectuée et que le

formulaire de création de l’agent est affiché.

Figure 73: Diagramme de collaboration du cas d'utilisation "Créer agent"

Description textuelle : L’utilisateur remplit le formulaire d’ajout en introduisant les

données dans leurs champs appropriés de l’interface IUCreationAgent et valide. (1) (2) Le

GestionnaireAgent crée un nouvel agent et l’ajoute à la classe Agent. (4) L’agent a été bien

crée et l’utilisateur est informé. (5) (6) (7)

I.14 Analyse du cas d’utilisation « Gérer Comptes Utilisateur » :


pour le cas d’utilisation « Gérer Comptes Utilisateur » :


d’utilisation « Gérer comptes utilisateur » :

Page | 62


Figure 74: Traçabilité du cas "Gérer comptes utilisateur"

I.14.2 Modèle de classe d’analyse du cas « Gérer Comptes Utilisateur » :

Profil

Agent

UtilisateurGestionnaireComptesUtilisateur

GestionnaireAgent

IUCreationCompteUtilisateur GestionnaireProfilAdministrateur

IUModificationCompteUtilisateur

IUComptesUtilisateur

Figure 75: Diagrammes de classes d'analyse du cas "Gérer comptes utilisateur"

Pour gérer les comptes utilisateurs, l’administrateur interagit avec le système grâce à des

interfaces dédiées à faciliter cette communication :

IUCompteUtilisateur : Cette interface permet à l’administrateur de consulter la liste des

utilisateurs et d’effectuer une recherche rapide dans la liste des utilisateurs disponibles

selon des critères de recherche bien définis. C’est à partir d’elle que l’administrateur peut

supprimer un utilisateur ou passer à une interface de création (ajout) ou de modification

d’un nouvel utilisateur.

IUCreationUtilisateur : Elle va être affichée lorsque l’utilisateur décide d’ajouter un

nouvel utilisateur.

IUModificationUtilisateur : Elle va être affichée lorsque l’utilisateur décide modifier un

utilisateur.

Pour réaliser toutes ces opérations, le système se dote des gestionnaires

GestionnaireCompteUtilisateur, GestionnaireAgent et GestionnaireProfil permettant

Page | 63


d’exécuter les fonctions selon le choix de l’administrateur. En effet, ce gestionnaire extrait les

données nécessaires des classes Utilisateur, Agent et Profil qui contiennent toutes les

informations se rapportant, respectivement, à touts les utilisateurs, les agents et les profils. (cf.

figure 75)

I.14.3 Diagrammes de collaboration du cas « Gérer Comptes Utilisateur » :


comptes utilisateurs par l’intermédiaire du diagramme de collaboration.

On va traiter, donc, seulement le cas de création d’un nouvel utilisateur car le cas de

modification lui est similaire.


création d’un nouvel utilisateur.



Le formulaire de création de l’utilisateur est affiché, après clic sur le lien ‘Créer

utilisateur’.

Figure 76: Diagramme de collaboration du cas d'utilisation "Créer utilisateur"


L’administrateur remplit le formulaire de création en introduisant les données dans leurs

champs appropriés de l’interface IUCreationCompteUtilisateur. (1) L’administrateur clique

sur le bouton ‘Associer agent’. (2) Le GestionnaireAgent extrait la liste des agents de la classe

Agent. (4) La liste des agents est bien retournée. (5) (6) (7) L’utilisateur choisit un agent et

clique sur le bouton ‘Associer profils’. (8) (9) Le GestionnaireProfil extrait la liste des profils

de la classe Profil. (11) La liste des profils est bien retournée et affichée. (12) (13) (14)

L’administrateur choisit un ou plusieurs profils et valide. (15) (16) Le

Page | 64


GestionnaireCompteUtilisateur ajoute un utilisateur à la classe Utilisateur. (17) L’utilisateur

est bien crée et l’administrateur est informé. (19) (20) (21)

I.15 Analyse du cas d’utilisation « S’authentifier » :


pour le cas d’utilisation « S’authentifier » :


d’utilisation « S’authentifier » :

Figure 77: Traçabilité du cas "S’authentifier"

I.15.2 Modèle de classe d’analyse du cas « S’authentifier » :

Figure 78: Diagrammes de classes d'analyse du cas "Gérer comptes utilisateur"

La fonction d’identification ne représente pas une fonctionnalité du système mais elle vient

répondre à un besoin de sécurité. Donc, pour s’authentifier, les utilisateurs interagissent avec

le système grâce à des interfaces dédiées à faciliter cette communication :

IUAuthentification : Cette interface permet à chaque utilisateur de saisir son nom et son

mot de passe à fin de pouvoir accéder à sa session.

IUAcceuil : Elle va être affichée lorsque l’authentification de l’utilisateur réussie.

Page | 65


GestionnaireAuthentification : Cette classe contrôle gère l’identification et la

reconnaissance de tous les acteurs du système. Elle permet de rediriger l’utilisateur

concerné vers sa page d’accueil selon son profil.

Pour réaliser toutes ces opérations, le système se dote du gestionnaire

GestionnaireAuthentification permettant d’exécuter les fonctions selon le choix de

l’administrateur. En effet, ce gestionnaire extrait les données nécessaires des classes

Utilisateur et Profil qui contiennent toutes les informations se rapportant, respectivement, à

touts les utilisateurs et les profils. (cf. figure 78)

I.15.3 Diagrammes de collaboration du cas « S’authentifier » :

Dans ce paragraphe, on va décrire les scénarios de réalisation de la fonction

d’authentification.

Le modèle de collaboration ci-dessous (cf. figure 36) décrit le scénario de réalisation d’une

authentification réussie.

Figure 79: Diagramme de collaboration du cas d'utilisation "S’authentifier"

Description textuelle : L’utilisateur saisi son nom d’utilisateur et son mot de passe et valide.

(1) (2) Le GestionnaireAuthentification contrôle l’existence de cet utilisateur en vérifiant son

nom d’utilisateur et son mot de passe. (4) L’utilisateur a été identifié. (5) Le

GestionnaireAuthentification vérifie le profil de cet utilisateur. (6) La classe entité Profil va

attribuer le profil correspondant à cet utilisateur. (7) Le GestionnaireAuthentification ouvre la

session et l’accueil est affiché. (8)

Page | 66


II Conception :

L’enchaînement d’activité de la conception, se base sur une conception détaillée de chaque

cas d’utilisation dégagé à travers les diagrammes des classes de conception et les diagrammes

des séquences.

II.1 Conception du cas d’utilisation « Gérer produits » :

Nous présentons ci-dessous le modèle de conception du cas d’utilisation « gérer produits ».

II.2 Du modèle de classe d’analyse au modèle de classe conception :

Figure 80: Traçabilité entre le modèle d’analyse et le modèle de conception du cas d’utilisation « gérer produits »

II.3 Diagramme de classe de conception relatif au cas « Gérer produit » :

AcceuilProduit.jspx

RechercherProduit()SupprimerProduit()

<<boundary>>

Produit.java

idProduitnomtype...

Produit()setProduit()getProduit()

<<entity>>

CreationProduit.jspx

nom...

Valider()Annuler()

<<boundary>>

SuccesModification

Fermer()

<<boundary>>

SuccesCreation.jspx

Fermer()

<<boundary>>

ModificationProduit.jspx

nom...

Valider()Annuler()

<<boundary>>

ConfirmationModification.jspx

Confirmer()Annuler()

<<boundary>>

Agent Marketing

ServiceProduit

ConsulterProduit()CréerProduit()ModifierProduit()

<<boundary>>

ConfirmationCreation.jspx


<<boundary>>

Figure 81: Diagramme de classe de conception du cas "Gérer produit"

Page | 67


II.4 Diagrammes de séquence du cas « Gestion de produits » :

Figure 82: Diagramme de séquence du cas "Créer produit"

III Conception du cas d’utilisation « Gérer campagne » :

III.1 Conception du cas d’utilisation « Créer campagne » :

III.1.1 Du modèle d’analyse au modèle de conception du cas d’utilisation « Créer

campagne » :

Figure 83: Traçabilité entre le modèle d’analyse et le modèle de conception du cas d’utilisation « Créer campagne »

Page | 68


III.1.2 Modèle de classe d’analyse du cas « Créer campagne » :

Compte.java

idComptenom...

getComptes()

<<entity>>

ServiceCompte

RécupérerComptes()

<<control>>

Produit.java

idProduitnomtype...

getProduits()

<<entity>>

CreationCampagne.jspx

nomtype...

Quitter()Valider()

<<boundary>>

ConfirmationCreation.jspx


<<boundary>>

Campagne.java

idCampagnenomstatut...

setIdCampagne()setNom()setStatut()

<<entity>>

SuccesCreation.jspx

Fermer()

<<boundary>>

ListeComptes.jspx

AjouterComptes()Annuler()

<<boundary>>

Agent Marketing

ServiceProduit

RécupérerProduits()

<<boundary>>ListeProduits.jspx

AjouterProduits()Annuler()

<<boundary>>

Invitation.java

idCompteidCampagne

Invitation()setIdCompte()setIdCampagne()

<<entity>>

ServiceCampagnes

AjouterComptes()AjouterProduits()CréerCampagne()

<<control>>

ProduirCampagne.java

idProduitidCampagne

ProduitCampagne()setIdProduit()setIdCampagne()

<<entity>>

Figure 84: Le modèle de classe de conception du cas "Créer campagne"

III.1.3 Diagramme de séquence du cas « Créer campagne » :

Page | 69


: ProduirCampagne.java

: ProduirCampagne.java : Agent

Marketing : Agent

Marketing

: CreationCampagne.jspx : CreationCampagne.jspx : ListeComptes.jspx : ListeComptes.jspx : ListeProduits.jspx : ListeProduits.jspx : ConfirmationCreation.jspx

: ConfirmationCreation.jspx

: SuccesCreation.jspx : SuccesCreation.jspx : ServiceCampagne : ServiceCampagne : ServiceCompte

: ServiceCompte

: ServiceProduit

: ServiceProduit

: Campagne

: Campagne

: Invitation...

: Invitation...

: Compte : Compte : Produit : Produit

AjouterComptes() RécupérerComptes()

getComptes()

Liste produits

AjouterProduits( )

AjouterProduits(produits)

Produits retournés

Afficher(ConfirmationCreation)

Confirmer()

Confirmer() CréerCampagne(InformationsCampagne,listeProduits,l isteAgents)

Infos saisies

Liste comptes

Liste comptes

Produits choisis

'ConfirmationCreation' affichée

Campagne créée

Afficher(SuccesCreation)

Message "Campagne créée avec succès" affiché

Liste comptes

AjouterComptes( )

AjouterComptes(comptes)

Comptes retounés

RécupérerProduits()

getProduits()

Liste produits

Liste produits

Comptes choisis

Invitation(Campagne,Compte)

Comptes retournés

Liste comptes actualisée

AjouterProduits()

ProduitCampagne(Campagne,Produit)

Produits retournés

Valider() CréerCampagne(InformationsCampagne,listeProduits,l isteAgents)

Liste produits actualisée

Figure 85: Diagramme de séquence du sous cas d'utilisation "Créer campagne"

Page | 70


III.2 Conception du cas d’utilisation « Modifier campagne » :

La conception du cas d’utilisation « Modifier campagne » est identique au cas d’utilisation

« Créer campagne » conçu ci-dessous.

III.3 Conception du cas d’utilisation « Contrôler campagne » :

III.3.1 Traçabilité Analyse-Conception du cas d’utilisation « Contrôler campagne » :

Figure 86: Traçabilité entre le modèle d’analyse et le modèle de conception du cas "Contrôler Campagne"

III.3.2 Diagramme de classe de conception du cas « Contrôler campagne » :

Controle.jspx

nomstatut...

Valider()Soumettre à la correction()Annuler()

<<boundary>>

Campagne.java


<<entity>>

ConfirmationValidation.jspx


<<boundary>>

ServiceCampagne

MettreAjourCampagne()

<<control>>

SuccesValidation.jspx

Fermer()

<<boundary>>


Figure 87: Diagramme de classe de conception du cas "Contrôler campagne"

III.3.3 Diagrammes de séquence du cas « Contrôler campagne » :

: SuccesValidation.jspx

: SuccesValidation.jspx

: IUControle : IUControle : ConfirmationValidation.jspx

: ConfirmationValidation.jspx



: ServiceCampagne

: ServiceCampagne

c : Campagne.java

c : Campagne.java

Valider()

Valider(C)

Afficher(ConfirmationValidation)'ConfirmationValidation' affichée

Confirmer

Valider(C)

setStatutCampagne(Validée)

Afficher(SuccesValidation)

Informations campagne vérifiées

Campagne validée

Message "Campagne validée avec succès" affiché

Figure 88: Diagramme de séquence du sous cas d'utilisation "Contrôler campagne"

Page | 71


III.4 Conception du cas d’utilisation « Planifier campagne » :

III.4.1 Traçabilité Analyse-Conception du cas d’utilisation « Planifier campagne » :

Figure 89: Traçabilité du cas "Planifier campagne"

III.4.2 Diagramme de classe de conception du cas d’utilisation « Planifier campagne » :

Promotion.java

idPromotionname

<<entity>>

Campagne.java


<<entity>>

ProduitCampagne.java

idProduitidCampagne...

<<entity>>

Assignement.java

idCampagneidCompteidAgent

<<entity>>

ServiceProduitcampagne

ConsulterProduitsCampagne()...

<<control>>

ServiceAssignement

AssignerCompteAgent()...

<<control>>

ConfirmationPlanification.jspx<<boundary>>

SuccesPlanification.jspx<<boundary>>


ServicePromotion

CréerPromotion()...

<<control>>

PlanificationC.jspx

dateDébutdateFin...

AjouterPromotions()...

<<boundary>>

ServiceCampagne

AjouterPromotions()...

<<control>>

AjoutPromotion.jspx

AjouterProduits()CréerPromotion()

<<boundary>>

Figure 90: Le modèle de classe de conception du cas "Planifier campagne"

III.4.3 Diagrammes de séquence du cas d’utilisation du cas « Planifier campagne » :

Page | 72




: AjoutPromotion.jspx : AjoutPromotion.jspx : PlanificationC.jspx : PlanificationC.jspx : SuccesPlanification.jspx : SuccesPlanification.jspx : ConfirmationPlanification.jspx : ConfirmationPlanification.jspx : ProduitCampagne.java : ProduitCampagne.java : Promotion.java : Promotion.java : ServiceCampagne : ServiceCampagne : ServiceProduitcampagne : ServiceProduitcampagne : ServicePromotion : ServicePromotion : Campagne.java : Campagne.java : Assignement.java : Assignement.java : ServiceAssignement : ServiceAssignement

AjouterPromotions()

AjouterPromotions()

Afficher(AjoutPromotion)

'AjoutPromotion' affichée

Informations promotions saisies

AjouterProduits()

ConsulterProduits()

ConsulterProduits()

Liste produitsListe produits

Liste produits

Produits choisis

Valider()

CréerPromotion(InfomationsPromotion)

CréerPromotion(InfomationsPromotion)

Promotion créée

Promotion créée

Promotion affichée

Agents et comptes choisis

Assigner(Comptes,Agents)

Assigner(Comptes, Agents)

Assigner(Comptes, Agents)

Assignement créeAssignement crée

Assignement affiché

Bouton 'Valider' cliqué

Planifiner(Campagne, info° planification)

Afficher(()ConfirmationPlanification)

'ConfirmationPlanification' affichée

Confirmer()

Planifiner(Campagne, info° planification) Planifiner(Campagne, info° planification)

Campagne planifiée

Afficher(SuccesPlanification)

Message "Campagne planifiée avec succès" affiché

Informations de planif° saisies

Figure 91: Diagramme de séquence "Planifier campagne"

Page | 73


III.5 Conception du cas d’utilisation « Lancer campagne » :

III.5.1 Traçabilité Analyse-Conception du cas d’utilisation « Lancer campagne » :

Figure 92: Traçabilité analyse-conception du cas "Lancer campagne"

III.5.2 Diagramme de classe d’analyse du cas d’utilisation « Lancer campagne » :

Campagne.java


<<entity>>

ConfirmationLancement.jspx


<<boundary>>

SuccesLancement.jspx

Fermer()

<<boundary>>


ServiceCampagne

ConsulterCampagne()LancerCampagne()

<<control>>Lancement.jspx

ConsulterCampagne()LancerCampagne()Quitter()

<<boundary>>

Figure 93: Diagramme de classe de conception du cas "Lancer Campagne"

III.5.3 Diagrammes de séquence du cas d’utilisation « Lancer campagne » :



: Lancement.jspx

: Lancement.jspx

: ServiceCampagne

: ServiceCampagne

: SuccesLancement.jspx

: SuccesLancement.jspx

: ConfirmationLancement.jspx

: ConfirmationLancement.jspx

C : Campagne.java

C : Campagne.java

Campagne sélectionnée

Valider()

ConsulterCampagne(CampagneSelectionnée)

ConsulterCampagne(C)

Détails campagne

Détails campagne

Détails campagne

Lancer(C)

Lancer(C)

Afficher(ConfirmationLancement)'ConfirmationLancement' affichée

Confirmer()

Modifier(C)Modifier(C)

Afficher(SuccesLancement)Message "Campagne lancée avec succès" affiché

Campagne lancée

Figure 94 : Diagramme de séquence "Lancer campagne"

Page | 74


III.6 Conception du cas d’utilisation « Suivre campagne » :

III.6.1 Traçabilité Analyse-Conception du cas d’utilisation « Suivre campagne » :

Figure 95: Traçabilité analyse-conception du cas "Suivre campagne"

III.6.2 Diagramme de classe de conception du cas d’utilisation « Suivre campagne » :

ConfiramationSuivi.jspx


<<boundary>>

Campagne.java


<<entity>>

Suivi.jspx

SuivreCampagne()MettreAjourReponse()...Quitter()

<<boundary>>

ServiceCampagne

SuivreCampagne()MettreAjourReponse()...

<<control>>

SuccesSuivi.jspx

Fermer()

<<boundary>>


Figure 96: Diagramme de classe de conception du cas "Suivre campagne"

III.6.3 Diagrammes de séquence du cas d’utilisation « Suivre campagne » :



: ConfiramationSuivi.jspx

: ConfiramationSuivi.jspx

c : Campagnec : Campagne : ServiceCampagne

: ServiceCampagne

: SuccesSuivi.jspx

: SuccesSuivi.jspx

: Suivi.jspx : Suivi.jspx

Suivre(c)

Récupérer(c)

Récupérer(c)

Suivi campagne

Suivi campagne affiché

Valider()

Modifier(reponse)

Afficher(ConfirmationSuivi)

'ConfirmationSuivi' affiché

Confirmer()

setReponse(positive)

setReponse(positive)

Afficher(SuccesSuivi)

Suivi camapgne

Campagne choisie

Modifier réponse

Réponse mise à jour

Message "Réponse mise à jour avec succès"

Figure 97: Diagramme de séquence du cas "Suivre campagne"

Page | 75


IV Diagramme de classes entités :

A ce niveau et à stade encore plus approfondi de modélisation, on arrive à dégager de

nouvelles notions, dans le cadre du domaine étudié (marketing). Ces notions viennent

compléter le modèle de domaine, précédemment établi, afin d’aboutir à un diagramme de

classe complet (cf. figure 98). Ce diagramme de classe va servie de base pour pouvoir

déterminer le modèle de la base de données à mettre en œuvre ainsi que les différentes tables

qu’elle doit comporter.

En effet, une campagne est caractérisée par une catégorie (représentée par la classe

Categorie). De plus, elle peut être, soit promotionnelle, soit informationnelle ou encore de

prospection. Lorsqu’il s’agit d’une campagne promotionnelle, celle-ci va comporter une ou

plusieurs promotions (représentées par la classe Promotion). Chaque promotion est en relation

avec un ou plusieurs produits. Lorsqu’il s’agit d’une campagne de prospection, elle sera alors

directement reliée aux produits qui la concernent. Par contre, lorsqu’il s’agit d’une campagne

informationnelle, cette dernière n’est pas nécessairement liée à un produit.

De même, une campagne est en relation avec un lieu (représenté par la classe Lieu) dans

lequel elle sera réalisée. Ce dernier est situé à une ville donné (représenté par la classe Ville)

qui est localisée à son tour dans un pays donné (représenté par la classe Pays).

En vue de garder un historique sur les opérations effectuées par les utilisateurs (représentés

par la classe Utilisateur) sur les campagnes (ajout, modification, planification, lancement,

etc…), on a eu recours à la modélisation de la classe l’association Trace.

Par ailleurs, un compte est caractérisé par un type de relation (représenté par la classe

NatureRelation) spécifiant la nature de la relation de ce tiers qui peut être soit fournisseur, soit

client, soit partenaire…etc. Il est, également, caractérisé par un secteur d’activité (représenté

par la classe SecteurActivité).

Un contact est, à son tour caractérisé par un rôle (représenté par la classe role) indiquant son

grade ou sa fonction au sein du compte qu’il représente.

La classe GroupeUtilisateur est composé de plusieurs utilisateurs qui peuvent être affecté à

une tâche commune.

Enfin, pour chaque compte, on associe un ou plusieurs profils (représentés par la classe Profil)

qui servent à déterminer ses privilèges lors de l’utilisation de l’application.

Page | 76


Af f ectation

Af f ectation()

<<entity >>

Inv itation

reponse

Inv itation()

<<entity >>

Prospect

statutcauseExclusion

Prospect()

<<entity >>

Appel

heureDébutheureFin

Appe()

<<entity >>

Trace

natureTache

Trace()

<<entity >>

Pay s

idPay snom

Pay s()

<<entity >>

Role

idRolenom

Role()

<<entity >>

CasDutilisation

idCasDutilisationnomdescription

CasDutilisation()

<<entity >>SecteurActiv ité

idSecteurActiv iténom

SecteurActiv ité()

<<entity >>

NatureRelation

idNatureRelationnom

NatureRelation()

<<entity >>

Ville

idVillenom

Ville()

<<entity >>

1

0..n

1

0..n

se_situer2

Guarantie

idGuarantiedateDebutdateFin...

Guarantie()

<<entity >>

Contact

idContactciv iliténomprénomadresse...

Contact()

<<entity >>

0..n

1

0..n

1

avoir3

Opportunité

idOpportunitéév aluation

<<entity >>0..n

1

0..n

1

concerner2

Activ ité

idActiv itéty peobjetnotedate

Activ ité()

<<entity >>

0..n

1

0..n

1

viser

Scenario

idScénarionom

Scenario()

<<entity >>

1..n1 1..n1

Compte

idComptenomadressesiteWeb...

Compte()

<<entity >>

0..n

1

0..n

1

avoir

1

0..n

1

0..navoir2

1..n1 1..n1

Document

idDocumenttitreobjetty pedescription

Document()

<<entity >>

Promotion

idPromotionnomdateDébutdateFinv aleur

Promotion()

<<entity >>

Place

idLieunomadresscodePostal

Place()

<<entity >>

1 0..n1 0..n

se_situer

Categorie

idCategorienom

Categorie()

<<entity >>

Produit

idProduitnomty peprixStandard...

Produit()

<<entity >>

0..1

0..1

0..1

0..1

concerner3

1

0..n

1

0..n décrire

1..n

0..n

1..n

0..n

concerner

0..n

0..n

0..n

0..n

1 0..n1 0..n

concerner

Agent

idAgentciv iliténomprénomdateNaissance...

Agent()

<<entity >>

0..n0..n

Assignement

Assignemnt()

<<entity >>

0..n0..n

Prof il

idProf ilname

Prof il()

<<entity >>

1..n

0..n

1..n

0..n

correspondre

Campagne

idCampagnenomdateDebutdateFinbudget...

Campagne()

<<entity >>

0..n

0..n

0..n

0..n

1

0..n

1

0..n

décrire2

1

0..n

1

0..n

1

0..n

1

0..n

se_dérouler

1

0..n

1

0..n

avoir

0..n

0..n

0..n

0..n

concerner2

Utilisateur

idUtilisateurnomUtilisateurmotDePassedateCreationdateExpiration

Utilisateur()

<<entity >>0..1

1

0..1

1

0..n 0..n0..n0..n

0..n0..n

1..n

0..n

1..n

0..n

avoir2

1..n

0..n

1..n

0..n

0..n

0..n

0..n

0..n

être_Affecté

GroupeUtilisateur

idGroupenom

GroupeUtilisateur()

<<entity >>

0..n

0..n

0..n

0..n

être_affecté2

0..n

1..n

0..n

1..n

Figure 98: Diagramme de classes entités

Page | 77


Conclusion :

Dans le présent chapitre, nous avons traité l’enchaînement d’analyse, qui élabore un modèle

objet conceptuel servant à analyser les besoins et les exigences, en les affinant et en les

structurant. A la fin de cet enchaînement, nous avons abouti à un modèle d’analyse, qui nous a

permis de procéder à l’enchaînement de conception par la prise en compte de la majeure

partie des exigences non fonctionnelles et autres contraintes liées à l’environnement.

Dans le prochain chapitre, nous allons montrer comment nous avons traduit cette étude

conceptuelle et à l’aide de quels outils nous avons pu mettre en place notre système.

Page | 78

Gestion de la Relation Client Réalisation

Chapitre III : Réalisation et Mise en œuvre

Introduction :

Pour aboutir à la finalité de notre projet, nous entamons la partie réalisation qui est partie

importante, tant pour nous, que pour la société.

Nous commençons par l’élaboration du schéma de la base de données. Ensuite, nous

argumentons, les choix matériel et logiciel en présentant l’architecture du système ainsi

que les technologies utilisés pour l’implémentation.

Enfin, nous passons à la présentation de l’application par à l’élaboration des captures

d’écrans produites lors de la réalisation des jeux de test.

I Présentation de la base de données :

Dans cette section, nous présentons la structure de notre base de données. Cette dernière est

obtenue en respectant les règles de passage du diagramme de classe vers la base de données

relationnelle.

I.1 Les règles de passage d’un modèle objet à un modèle relationnel:

L’utilisation d’un SGBDR impose un changement de représentation entre la structure des

classes et la structure des données relationnelles.

Règle 1 : Une classe définit une structure de données à laquelle souscrivent des

instances; elle correspond donc à une table du modèle relationnel.

Règle 2 : Chaque attribut donne lieu à une colonne.

Règle 3 : Chaque instance stocke ses données dans une ligne (T-uplet) et son OID sert

de clé primaire.

Règle 4 : Chaque association « un à plusieurs » est représentée par une clé étrangère

dans la table fille ;

Règle 5 : Chaque association « plusieurs à plusieurs » entre deux classes est

représentée par une nouvelle table qui prend pour clé primaire la concaténation des

clés primaires des deux classes ;

Règle 6 : Chaque association « un à un » est représentée par l’intégration d’une clé

étrangère dans la table la moins récente.

Règle 7 : Une classe association entre deux classes est représentée par une table qui

prend pour clé primaire la concaténation des clés primaires des deux classes ;

Page | 81


I.2 Le schéma relationnel :

Le schéma relationnel est basé sur une organisation des données sous forme de tables en

suivant les règles de passage, évoquées ci-dessus.

Les tables générées sont les suivantes :

Activité (idActivité, type, objet, notes, date, #idCompte, #idContact)

Affectation (idAffectation, #idAdministrateur, #idUtilisateur, #idOpportunité)

Agent (idAgent, civilité, nom, prénom, dateNaissance, dateRecrutement, SituationFamiliale,

nombreDenfant, #idGroupAgent)

UtilisateurCampagne (#idUtilisateur, #idUtilisateur2, #idCampagne)

Appel (idActivité, heureDebut, heureFin)

Assignement (idAssignement, #idUtilisateur, #idAdministrateur, #idActivité, nature)

Campagne (idCampagne, nom, staut, dateDebut, dateFin, objectif, description, budget,

typeAssignement, notes, moyensDeCommunication #idCategorie, #idLieu)

Categorie (idCategorie, nom)

Compte (idCompte, nom, telephonne, fax, adresse, email, siteWeb, dateCreation,

#idNatureRelaion, #idSecteurDactivité, #defaultContact)

Contact (#idAccount, idContact, nom, prenom, civilité, mobile, telephonne, adresse, email,

fax, dateNaissance, photo, situatuonFamiliale, nombreEnfant, dateP, heureP, méthodeP,

appel, mail, fax ; lettre, #idRole)

Document (idDocument, titre, type, description, url, #idProduit, #idCampagne)

Garantie (#idProduit, idGarantie, société, groupe, nature, dateDebut, dateFin)

GroupeUtilisateur (idGroupe, nom)

GroupeCampagne (#idGroupeAgent, #idCampagne, #idUtilisateur)

Invitation (#idCampagne, #idCompte, réponse)

Lieu (#idVille, idLieu, nom, adresse, codePostal)

Opportunité (idOpportunité, #idProduit, #idCompte, #idContact)

Pays (idPays, nom)

Produit (idProduit, nom, type, prixStandard, prixEffectif, tarif, description, dateCreation,

#idCampagne)

Profil (idProfil, nom)

ProfilOption (#idProfil, #idUseCase, #idSousCas)

Promotion (#idCampagne, idPromotion, nom, dateDebut, dateFin, valeur, #idProduit)

Prospect (#idCompte, #idContact, #idProduit, statut, Origine, causeExclusion)

Page | 82


Role (idRole, nom)

SecteurDactivité (idSecteurActivité, nom)

SousCas (#idUseCase, idSousCas, nom, description)

TraceCampagne (#idUtilisateur, #idCampagne, nature, date, heure)

TypeRelation (idTypeRelation, nom)

UseCase (idUseCase, nom, description)

Utilisateur (idUtilisateur, login, motDePasse, dateCreation, dateExpiration, #idAgent)

UtilisateurOption (#idUtilisateur, #idProfil)

Ville (#idPays, idVille, nom)

II Le modèle de déploiement:

Le modèle de déploiement montre la disposition physique des matériels qui composent le

système et la répartition des composants sur ces matériels. Les ressources matérielles sont

représentées sous forme de nœuds qui sont connectés entre eux, à l'aide d'un support de

communication.

Figure 99: Modèle de déploiement

III Le modèle de composants :

III.1 Traçabilité entre le modèle de conception et le modèle

d’implémentation :

Pour un besoin de lisibilité, on va présenter la traçabilité entre le modèle de conception et le

modèle d’implémentation par un diagramme générique.

On substitue les classes « contrôle » par une classe générique appelée

« Gestionnaire ».

On substitue les classes « Entité » par une classe générique appelée «Entité ».

Page | 83


On substitue les classes « Interface » (« boundary ») par une classe générique appelée

« interface ».

La figure ci-dessous présente un digramme simplifié, vue que les technologies apportées par

J2EE est relativement complexe à schématiser.

Figure 100: Traçabilité entre le modèle de conception et le modèle d'implémentation

III.2 Diagramme de composants générique :

Le diagramme de composants décrit l’organisation et la dépendance entre les différents

composants du système. Il modélise les aspects physiques du système dans un environnement

de réalisation.


Interface1.jspx, Interface2.jspx, …, InterfaceN.jspx représentent les interfaces, à travers

lesquelles l’utilisateur interagit avec le système. La servlet Controller représente un

contrôleur frontal qui assure la communication entre l’interface utilisateur et le modèle. Model

est le modèle représentant les données. Service locator sert à l’instanciation des services.

Service1, …, Servi ceN englobent les services à invoquer. Dao1, …, Dao N englobent les

méthodes à invoquer pour exécuter des opérations sur les entités. Entities, englobent les

classes représentant chacune des tables de la base de données. HibernateSupport.java, assure

le lien entre la représentation objet des données et sa représentation relationnelle. (c’est le

mapping objet/relationnel). Base de données représente la base de données.

Page | 84


Interface1.jspx<<fichier>>


InterfaceN.jspx<<fichier>>

Service1

Service1able.java<<fichier>>

Service1impl.java<<fichier>>

ServiceN

ServiceNable.java

<<fichier>>

ServiceNimpl.java

<<fichier>>

ServiceLocator

ServiceLocatorBean.java

<<fichier>>


Dao1

DaoN

Dao1able.java<<fichiet>>

Dao1impl.java<<fichiet>>

DaoNable.java<<fichier>>

DaoNimpl.java<<fichier>>

Entities

Entity1.java<<fichier>>

EntityN.java<<fichier>>

Base de données

Table1<<Table sql>>

Table2<<Table sql>>

ServiceLocator.java

<<fichier>>

Controller<<Servlet>>

Model

Model1.java<<fichier>>

Model2.java<<fichier>>

ModelN.java<<fichier>>

HibernateDaoSupport.java

<<fichier>>

BaseBean.java

<<fichier>>

Page | 85


Figure 101: Diagramme de composants générique

Page | 86


IV Architecture adoptée :

En méditant dans le contexte de notre système, on perçoit que la solution architecturale qu’on

estime utiliser doit satisfaire les contraintes techniques et logiques qu’on vise adopter.

Rappelons que la solution proposée consiste à implanter un module de gestion de la relation

client. Ainsi, devant le nombre impressionnant de produits et technologies Web, on dispose

de plusieurs architectures d’application Web variées qui répondent à notre contexte.

Le choix d’une solution ou d’une autre dépend de plusieurs critères tels que :

Performance d’interactivité.

Partage d’informations par plusieurs utilisateurs simultanément connectés.

Sécurité des données.

A ce faire, on a choisi d’utiliser l’architecture N-tiers/ J2EE (Java2 Entreprise Edition), en

respectant le modèle MVC (cf. figure 102) :

Figure 102: Architecture J2EE basée sur les technologies JSF, Spring et Hibernate

Browser/Navigateur représente le navigateur web sur lequel va être exécutée

l’application (exemple : Internet Explorer 6).

Java Server Faces (JSF) représente la vue du modèle MVC ; c’est l’interface

graphique de l’application.

Spring Framework représente le contrôle du modèle MVC ; c’est une plateforme qui

permet de « remplacer » la lourdeur des serveurs d’application lourds. En effet, on

Page | 86

Browser/Navigateur

Java Server Faces (JSF)

Spring Framework

HibernateBase de

donnéesArchitecture

J2EE


parle de « conteneur léger ». Il prend en charge la création et la mise en relation

d’objets par l’intermédiaire d’un fichier de configuration décrivant l’ensemble de ces

relations. L’un des avantages principal est qu’il n’impose pas d’hériter ou

d’implémenter une quelconque interface ou classe contrairement aux EJB.

Hibernate représente le modèle du modèle MVC ; c’est une plateforme qui permet de

« mapper » une base de données relationnelle en objets (POJO : Plain Old Java

Object). Il permet donc d’abstraire totalement l’accès à la base de données et propose

donc un accès totalement orienté objet aux données.

Base de données c’est la base de données relationnelle qui va contenir toutes les

données.

V Choix des outils et des logiciels utilisés :

V.1 Choix de la plateforme : J2EE (Java 2 Entreprise Edition)

Java Enterprise Edition, ou Java EE (anciennement J2EE), est une spécification pour la

technologie Java de Sun plus particulièrement destinée aux applications d’entreprise.

Il s’agit d’une norme qui va spécifier à la fois l'infrastructure de gestion des applications et

les API des services utilisées pour concevoir ces applications.

La plateforme J2EE est essentiellement un environnement fournissant une infrastructure

d'exécution pour faire tourner les applications et un ensemble de services accessibles via

l'API J2EE pour aider à concevoir des applications.

Dans la mesure où J2EE s'appuie entièrement sur le Java, il bénéficie des avantages de ce

langage, en particulier une bonne portabilité et une facilité de maintenance du code.

De plus, l'architecture J2EE repose sur des composants distincts, interchangeables et

distribués, ce qui signifie notamment :

Qu'il est simple d'étendre l'architecture.

Qu'un système reposant sur J2EE peut posséder des mécanismes de haute

disponibilité, afin de garantir une bonne qualité de service.

Que la facilité de maintenance des applications est facilitée.

V.2 Choix du serveur d’application: Apache Tomcat

Tomcat est un conteneur libre de servlet Java 2 Enterprise Edition. Il implémente les

spécifications des servlets et des JSP de Sun Microsystems. Il inclut des outils pour la

configuration et la gestion, mais peut également être configuré en éditant des fichiers de

configuration XML. Il est aussi considéré comme un serveur HTTP.

Page | 87


V.3 Choix de l’environnement logiciel :

Pour développer des applications complexes, il faut, impérativement, utiliser les IDEs

(Integrated Environnement Development) appropriés.

A la lumière de ceci, on a utilisé Rational Rose 7.0 pour la présentation et la modélisation des

différents diagrammes présentés dans le rapport.

Et, on a choisi l’atelier de génie logiciel Eclipse Ganymede pour le développement de notre

application.

V.4 Choix du système de gestion de la base de données : Microsoft SQL

Server 2005 :

SQL Server 2005, est une solution complète de base de données et d'analyse entièrement

conçu pour le Web permettant d’effectuer des requêtes et des analyses de données en toute

simplicité sur le Web et d’accéder facilement aux données en toute sécurité. Ce système de

gestion de base de données relationnel réparti la charge des bases de données pour obtenir une

montée en puissance linéaire aux applications. Il assure une rapidité de mise en œuvre, les

applications peuvent être développées, déployées et administrées plus rapidement.

VI Tests de l’application :

L’intérêt de cette partie est la présentation des jeux de tests effectués, pour les cas critiques du

système, afin de s’assurer de leur bon fonctionnement. Ceci, dans l’optique de vérifier, en

premier lieu, que les cas réalisés sont conformes à la spécification et de les valider par rapport

aux exigences des futurs utilisateurs, d’éviter, en second lieu, les erreurs d’exécution, qui

peuvent se produire. Et enfin, pour s’assurer que les interfaces réalisées sont présentables et

ergonomiques.

Page | 88


VI.1 Cas d’utilisation « S’identifier » :

Figure 103: Page d'identification

Cette interface permet à l’utilisateur d’accéder au système après une validation de son login et son mot de passe.

Figure 104: Page d'accueil

Cette interface représente la page d’accueil de l’application, à partir de laquelle l’utilisateur peut choisir n’importe quelle fonctionnalité.

Page | 89


VI.2 Cas d’utilisation « Gérer produits » :

Figure 105: Page d'accueil Produits

Cette interface représente la page d’accueil de la gestion des produits. L’utilisateur

peut consulter la liste des produits disponibles et il peut rechercher ou modifier un produit de

cette liste.

Figure 106: Création d'un nouveau produit

Page | 90


Cette interface permet la création d’un nouveau produit, l’utilisateur doit saisir les

informations relatives à ce dernier.

Figure 107: Confirmation

Le produit ne sera enregistré qu’après la confirmation de l’utilisateur.

Page | 91


Figure 108: Modification de produit

Pour modifier un produit, l’utilisateur choisit un, de la liste et puis, il clique sur le lien

d’édition. Ceci va aboutir à l’apparition d’un formulaire de modification qui offre à l’utilisateur

d’effectuer les mises à jour nécessaires et puis de les valider.

Page | 92


Figure 109: Produit ajouté

Suite à la confirmation de modification du produit, l’utilisateur va être redirigé vers

l’accueil, là où figure la liste des produits disponibles, y compris celui qu’il vient de modifier.

VI.3 Cas d’utilisation « Gérer campagne » :

Figure 110: Page d'accueil Campagnes

Page | 93


Cette interface représente la page d’accueil de la gestion des campagnes. L’utilisateur

peut consulter la liste des campagnes disponibles et il peut rechercher, modifier ou

supprimer une campagne de cette liste.

Figure 111: Créer campagne

Pour la création d’une nouvelle campagne, l’utilisateur doit suivre les étapes

suivantes :

Saisir les informations relatives à la campagne, en remplissant le formulaire affiché.

Choisir la liste des comptes à associer à la campagne.

Choisir la liste des produits à associer à la campagne.

Et enfin, valider et confirmer.

Figure 112: Choix des comptes

Page | 94


Figure 113: Choix des produits

Figure 114: Comptes et produits ajoutéss

Page | 95


Figure 115: Modifications effectués

Cette interface permet de contrôler une campagne. En effet, l’utilisateur choisit une

campagne de la liste des campagnes crées et consulte son détails. Ensuite, il vérifie les

informations pour décider s’il doit valider la campagne, la soumettre à la correction, ou

l’annuler. Il a la possibilité de saisir d’éventuels notes, justifiant sa décision.

Page | 96


Figure 116: Contrôler campagne

Figure 117: Saisie de notes

Page | 97


VII Constations et perspectives :

Il est vrai d’après les différents scénarios des tests d’exécution effectués précédemment que

nous sommes arrivés à satisfaire les besoins de la société.

Mais ceci ne nous empêche pas à penser à des améliorations à apporter au portail comme

perspectives de ce travail.

Nous pouvons faire évoluer notre application en prévoyant un espace collaboratif permettant

aux clients d’avoir leurs propres espaces personnels aux quels ils peuvent accéder pour

communiquer avec l’entreprise.

Conclusion :

Dans ce chapitre, on a présenté l’environnement matériel et logiciel du projet. Nous avons,

par la suite, élaboré quelques aperçus du fruit de notre travail à travers des interfaces résultant

des jeux de tests effectués

Page | 98

Gestion de la Relation Client Conclusion générale

Conclusion Générale

Dans l’environnement concurrentiel d’aujourd’hui, il est primordial pour toute organisation de

maîtriser parfaitement sa relation avec ses clients. Recueillir toutes les informations à leur

propos, automatiser les processus de prospection et de vente et augmenter l’efficacité des

actions commerciales, tels sont les objectifs du CRM.

Ce projet a été réalisé dans le cadre du mémoire de fin d’étude pendant quatre mois de stage

au sein de la société de développement logiciel ‘Cynapsys’.

Le présent travail se résume dans la conception et la réalisation d’un module marketing d’une

application de gestion de la relation client. Il s’agit d’informatiser certaines fonctionnalités

essentielles qui serviront de base pour des travaux ultérieurs.

Ainsi, dans ce mémoire on a appliqué les différents enchaînements du cycle de vie du

processus unifié et on s’est basé sur le paradigme MVC comme schéma de programmation

qui propose de séparer l’application en trois parties (Modèle, Vue, Contrôleur).

De plus, on s’est servi de l’architecture J2EE (la plus récente en ces temps) pour la réalisation

et le déploiement de notre application.

Par ailleurs, ce stage nous a donné la chance de manipuler des techniques innovantes et

évolutives et nous a permis aussi de tester et d’appliquer nos connaissances acquises au sein

de l’école supérieure de commerce de Tunis et de les améliorer.

De même, il nous a fournit l’occasion d’être intégré dans la vie professionnelle et nous a

donné une vision globale sur notre avenir comme concepteur et développeur.

Cependant, comme tout projet de fin d’étude nous avons rencontré des problèmes de divers

types. L’implémentation de notre système fut l’une des majeures difficultés que nous avons

rencontrées vu le nouvel environnement de travail et sa complexité.

Nous avons pu dépasser ces problèmes par notre volonté à présenter un bon travail, à

apprendre et à utiliser les nouvelles technologies de programmation et en appliquant nos

connaissances.

Page | 93

Gestion de la Relation Client Annexes

Annexes

Annexe [A] : Base de données

L'objectif de cette partie est de présenter le dictionnaire des données relatif à la base de données

du projet « CYNCRM ».

Activité

Attribut Description Type contrainte

idActivité désigne l’identifiant de l’activité. entier Clé primaire

type Indique si l’activité est entrante ou sortante. texte

objet désigne l’objectif de l’activité. texte

notes désigne les remarques concernant l’activité. texte

date désigne la date de l’activité. date

idCompte désigne le compte concerné par l’activité entier Clé étrangère

idContact désigne la personne concernée par l’activité. entier Clé étrangère

Affectation


idAffectation désigne l’identifiant de l’affectation. entier Clé primaire

idAdministrateur désigne la personne qui a affecté l’opportunité à un utilisateur.

entier Clé étrangère

idUtilisateur désigne l’utilisateur qui est affecté à l’opportunité.


idOpportunité désigne l’opportunité qui a été affectée à l’utilisateur.


Agent


idAgent désigne l’identifiant de l’agent. entier Clé primaire

civilité désigne la civilité de l’agent (monsieur, madame ou mademoiselle).

texte


nom Désigne le nom de l’agent. texte

prénom Désigne le prénom de l’agent. texte

dateNaissance Désigne sa date de naissance. date

dateRecrutement désigne sa date de recrutement. date

situationFamiliale désigne sa situation familiale (célibataire, mariée, divorcée, …).

texte

nombreDenfant désigne le nombre de ses enfants. entier

UtilisateurCampagne


idUtilisateur désigne l’utilisateur qui a affecté l’agent à la campagne.

entier Clé primaire, Clé étrangère

idUtilisateur2 désigne l’utilisateur assigné à la campagne. entier Clé primaire, Clé étrangère

idCampagne désigne la campagne à laquelle l’utilisateur est affecté.


Appel


idActivité désigne l’activité qui représente l’appel. entier Clé primaire, Clé étrangère

heureDebut désigne le temps de début de l’appel. entier

heureDebut désigne le temps de fin de l’appel. entier

Assignement


idAssignement désigne l’identifiant de l’assignement. entier Clé primaire

idUtilisateur désigne l’utilisateur auquel est assignée l’activité. entier Clé étrangère

idAdministrateur désigne la personne qui a fait l’assignement. entier Clé étrangère

idActivité désigne l’activité assignée à l’utilisateur. entier Clé étrangère

nature Désigne la nature de l’assignement (agent ou groupe).

texte


Campagne


idCampagne désigne l’identifiant de la campagne. entier Clé primaire

nom désigne le nom de la campagne. texte

statut désigne le statut de la campagne. texte

dateDebut désigne sa date de début. date

dateFin désigne sa date de fin. date

objectif désigne ses objectifs. texte

description désigne sa description. texte

budget désigne son budget. réel

idCategorie désigne sa catégorie. entier Clé étrangère

idLieu désigne lieu où elle va être réalisée. entier Clé étrangère

typeAssignement désigne si la campagne est assignée à un groupe ou un agent.

notes désigne les remarques de correction associée à la campagne.

moyenDeCommunication

désigne le moyen de communication utilisé.

Catégorie


idCategorie désigne l’identifiant de la catégorie. entier Clé primaire

nom désigne son nom. texte

Compte


idCompte désigne l’identifiant du compte. entier Clé primaire

nom désigne le nom du compte. texte

telephone désigne son numéro de téléphone. entier

fax désigne son fax. entier


adresse désigne son adresse. texte

email désigne son adresse électronique. texte

siteweb désigne son site internet. texte

dateCreation désigne sa date de création. date

idNatureRelation désigne sa nature de relation avec l’entreprise. entier Clé étrangère

idSecteurDactivité désigne son secteur d’activité. entier Clé étrangère

defaultContact Désigne le contact par défaut. entier Clé étrangère

Contact


idContact désigne l’identifiant du contact. entier Clé primaire


prenom désigne sonprénom. texte

civilité désigne sa civilité. texte

mobile désigne son numéro de téléphone portable. entier

téléphone désigne son numéro de téléphone portable. entier


email désigne son adresse électronique. texte

fax désigne son fax. entier

dateNaissance désigne sa date de naissance. date

Photo désigne sa photo. photo

situationFamiliale désigne sa situation familiale. texte

nombreEnfant désigne son nombre d’enfant. entier

dateP désigne sa date de contact privilégiée. date

heureP désigne son heure de contact privilégiée. entier

appel désigne s’il préfère recevoir des appels téléphoniques ou non.

booléen


mail désigne s’il préfère recevoir des mails ou non. booléen

fax désigne s’il préfère recevoir des fax ou non. booléen

lettre désigne s’il préfère recevoir des lettres ou non. booléen

idRole désigne le rôle qu’il occupe au sein du compte auquel il appartient.


idAccount désigne le compte auquel appartient le contact.

Document


idDocument désigne l’identifiant du document. entier Clé primaire

titre désigne son titre. texte

type désigne son type. texte


url désigne son chemin depuis la racine. texte

idProduit désigne le produit avec lequel il est en rapport. entier Clé étrangère

idCampagne désigne la campagne avec laquelle il est en rapport.


Guarantie


idGarantie désigne l’identifiant de la garantie. entier Clé primaire

société désigne sa société. texte

groupe désigne son groupe. texte

nature désigne sa nature. texte



idProduit désigne le produit qu’elle concerne. entier Clé étrangère

GroupeUtilisateur



idGroupe désigne l’identifiant du groupe d’utilisateurs. entier Clé primaire

nom désigne le nom du groupe. texte

GroupeCampagne


idGroupeCampagne

désigne l’identifiant du groupe affecté à la campagne.

entier Clé primaire

idCampagne désigne la campagne à la quelle le groupe a été affecté.

texte Clé primaire, Clé étrangère

idUtilisateur désigne l’utilisateur qui a affecté le groupe à la campagne.

texte Clé primaire, Clé étrangère

Invitation


idCampagne désigne l’identifiant de la campagne à quelle est invité le compte.


idCompte désigne le compte invité à la campagne. entier Clé primaire, Clé étrangère

réponse désigne la réponse du compte à l’égard de l’invitation.

texte

Lieu


idLieu désigne l’identifiant du lieu. entier Clé primaire



codePostal désigne son code postal. entier

idVille désigne la ville dans la quelle il est situé. entier Clé étrangère

Opportunité



idOpportunité désigne l’identifiant de l’opportunité. entier Clé primaire

idProduit désigne le produit en relation avec l’opportunité. entier Clé étrangère

idCompte désigne le compte en relation avec l’opportunité. entier Clé étrangère

idContact désigne le contact en relation avec l’opportunité. entier Clé étrangère

Pays


idPays désigne l’identifiant du pays. entier Clé primaire

nom désigne le nom du pays. texte

Produit


idProduit désigne l’identifiant du produit. entier Clé primaire

nom désigne le nom du produit. texte

type désigne s’il s’agit d’un produit ou d’un service. texte

prixStandard désigne le prix standard du produit. réel

prixEffectif désigne le prix effectif du produit. réel

tarif désigne le tarif du produit. réél

description désigne la description du produit. texte


idCampaign

Profil


idProfil désigne l’identifiant du profil. entier Clé primaire

nom désigne le nom du profil. texte

ProfilOption



idProfil désigne l’identifiant du profil. entier Clé primaire, Clé étrangère

idUseCase désigne le nom du cas d’utilisation associé au profil.


idSousCas désigne le nom du cas d’utilisation associé au profil.


Promotion


idPromotion désigne l’identifiant de la promotion. entier Clé primaire

nom désigne le nom du cas d’utilisation associé au profil.

texte



valeur désigne la valeur de la promotion. réel

idCampagne désigne la campagne en relation avec la promotion.


idProduit désigne le produit en promotion. entier Clé étrangère

Prospect


idCompte désigne le compte représentant le prospect. entier Clé primaire, Clé étrangère

idContact désigne le contact représentant le prospect. entier Clé primaire, Clé étrangère

idProduit désigne le produit auquel est intéressé le contact. entier Clé primaire, Clé étrangère

statut désigne le statut du prospect. texte

origine désigne l’origine du prospect. texte

causeExclusion désigne la cause d’exclusion du prospect dans le cas où il a été supprimé.

texte

Profil



idRole désigne l’identifiant du rôle. entier Clé primaire

nom désigne le nom du rôle. texte

SecteurDactivité


idSecteurActivité désigne l’identifiant du secteur d’activité. entier Clé primaire

nom désigne le nom du secteur d’activité. texte

SousCas


idUseCase désigne le cas d’utilisation auquel appartient le sous cas.


idSousCas désigne l’identifiant du sous cas. entier Clé primaire

nom désigne le nom du sous cas. texte

description Désigne sa description. texte

TraceCampagne


idUtilisateur désigne l’utilisateur qui a effectué une tâche relative la campagne.


idCampagne désigne la campagne affectée par l’utilisateur. entier Clé primaire, Clé étrangère

nature désigne la nature de la tâche effectuée. texte

date désigne la date de la tâche. date

heure désigne l’heure de la tâche. entier

TypeRelation


idTypeRelation désigne l’identifiant du type de la relation. entier Clé primaire



UseCase


idUseCase désigne l’identifiant du cas d’utilisation. entier Clé primaire



Utilisateur


idUtilisateur désigne l’identifiant de l’utilisateur. entier Clé primaire

login désigne son login. texte

motDePasse désigne son mot de passe. texte


dateExpiration désigne sa date d’expiration. date

idAgent désigne l’agent en relation avec le compte utilisateur.


idGroupe désigne le groupe auquel appartient l’utilisateur. Clé étrangère

UtilisateurOption


idUtilisateur désigne l’identifiant de l’utilisateur. entier Clé primaire, Clé étrangère

idProfil désigne le profil associé à l’utilisateur. entier Clé primaire, Clé étrangère

Ville


idVille désigne l’identifiant de la ville. entier Clé primaire

idPays désigne le pays dans lequel est située la ville. entier Clé primaire, Clé étrangère

nom désigne le nom de la ville. texte


Annexe [B] : Suite du processus CRM (les modules Vente et Après-Vente) Le processus de Vente :

L’augmentation de la productivité de la force de vente reste l’objectif traditionnel principal. Dans une

approche CRM, le produit ne fournit pas à long terme un avantage concurrentiel mais plutôt l’accent

doit être mis sur l’amélioration de la relation et des services offerts aux clients autour du produit. Cette

nouvelle approche de vente exige de l’entreprise qu’elle donne plus d’autonomie à sa force de vente et

que les systèmes d’informations soutiennent les vendeurs dans leur activité.

Pour ce faire, la gestion de la vente s’articule atour des activités suivantes :

Gestion des devis.

Gestion des communications.

Gestion des contrats.

Suivi des commandes.

Figure 118: Le processus de vente

Il s’agit de préparer des devis/propositions pour les opportunités précédemment créées. Ces devis

concernent les produits pour lesquels le client a manifesté un intérêt en se basant sur les informations

relatives à cette opportunité. Ces propositions seront, par la suite, envoyée aux clients appropriés par

l’intermédiaire d’un moyen de communication.

Après relances éventuelles, le sort des propositions s’inscrira dans l’un des cas suivants :

Une demande de révision, dans le cas où le client exige d’apporter certaines modifications à la

proposition.

Refus, dans le cas ou le client manifeste explicitement son désaccord ou implicitement lorsque

la durée de validité est dépassée.

Acceptation (c’est le cas le plus général).

Ve nte s

Gestio

n des devis

Gestion des contrat

s

Suivi

des co

mmandes

Gestion des communication

s


Figure 119: Gestion des devis

Une fois le devis est accepté, il sera concrétisé par l’établissement d’un contrat de vente entre

l’entreprise et le client.

Figure 120: Gestion des contrats

Ce contrat sera, à son tour, traduit par la création d’une ou plusieurs commandes qui seront envoyées au

service comptable qui se chargera de la livraison et de la facturation.

Figure 121: Envoi au service comptable

Le processus d’Après-Vente :

Le service après-vente devient l'occasion privilégiée de concrétiser une relation personnalisée et

durable avec le client, en lui proposant une offre encore mieux adaptée à ses besoins. Le vecteur

idéal de cette relation est le centre d'appel (call center) qui permet d'orchestrer tous les éléments de

la stratégie client, depuis la base de connaissance qui fournit la vue unique du client nécessaire à

cette relation "one to one", jusqu'au scénario personnalisé qui guide l'entretien pour lui présenter

une offre adaptée à ces besoins. Cette qualité de service supplémentaire permet à l'entreprise

Directeur Commercial

Agent CommercialCréatio

n et édition

des devis

Contrôle des devisFermet

ure des opportu

nités

Envoi des

devisTransformation

en comma

nde

Suivi des

devis

Fermeture des incident

s

Commercial director

Commercial agentCreate

or edit contra

ct

Control

contract

Electronic

Document

Management

Agent Commercial

Mise à jour du

statut de la

commande

Envoi au service

comptabilité


d'améliorer en permanence sa connaissance du client, d'affiner sa stratégie et d'accroître son

efficacité commerciale. Les principales activités de ce processus sont donc :

Gestion des communications.

Gestion des incidents.

Support technique.

Figure 122: Après-Vente

Figure 123: Gestion des incidents

L’entreprise est en mesure de suivre sa clientèle même après la livraison du produit. Elle doit toujours

veiller une meilleure gestion des incidents. En fait, un incident représente une manifestation de la part

d’un client auprès de l’entreprise par un moyen de communication. Il peut être à l’origine d’un

problème ou d’une initiative pour demander des informations.

La déclaration d’un incident donne lieu à un processus d’identification de ce dernier. Le résultat de ce

processus conditionne le sort de l’incident. En effet, il peut être soit résolus et puis clôturé soit

directement clôturé.

Une fonction de suivi des incidents s’avère aussi indispensable.

Apr ès

-Ve

nte

s

Gestion des incident s

Support techniqu

e

Gestion des communications

Conseiller client

Identification des

incidentsCréation

des comptes ou

contacts

Vérification des

garantis


Figure 124: Support technique

Annexe [C] : Modèle MVC:

L'architecture Modèle/Vue/Contrôleur (MVC) est une façon d'organiser une interface

graphique d'un programme. Elle consiste à distinguer trois entités distinctes qui sont, le

modèle, la vue et le contrôleur ayant chacun un rôle précis dans l'interface.

Bien que la façon MVC d'organiser une interface ne soit pas la solution miracle, elle fournit

souvent une première approche qui peut ensuite être adaptée. Elle offre aussi un cadre pour

structurer une application. Dans l'architecture MVC, les rôles des trois entités sont les

suivants :

Modèle : données (accès et mise à jour).

Vue : interface utilisateur (entrées et sorties).

Contrôleur : gestion des événements et synchronisation.

Les différentes interactions entre le modèle, la vue et le contrôleur sont résumées par le schéma

de la figure suivante.

Figure 125: Interactions entre le modèle, la vue et le contrôleur

Annexe [B] : Architecture « complexe »

Nous parlons d’architecture complexe lorsque les applications qui doivent être développées

Agent support technique

Directeur support technique

Clôture des incidents

Suivi des incidents

Analyse des problèmesRésolution

des problèmes

Modèle(les

données et

opérations)

Contrôleur

(gestion des

événements)

Vue(interfa

ce homme/machi

ne)Donne les opérations à effectuer

Effectue les opérations qui seront affichée par la vue

Evènements


sont de type client/serveur ; cela signifie qu’il existe des « tiers ». D’où, on parle des

architectures « n-tiers ». Du fait que ce type d’architecture met en place des connexions

client/serveur, les différents serveurs vont devoir communiquer entre eux. Voici un diagramme

présentant l’architecture de type « n-tiers » :

Figure 126: Architecture n-tiers

Nous retrouvons, dans l’API J2EE, un ensemble de composant permettant d’interconnecter ces

différents types de technologie. Voici un ensemble d’avantages (non exhaustif) que procure

l’élaboration d’une architecture « complexe », et pensée :

Structure de l’application propre.

Modularité de l’application. (une forte cohésion et un faible couplage)

Evolution de l’application facilitée.

Factorisation de code et utilisation de plateformes ou composants génériques.

L’inconvénient principal est la difficulté à mettre en place une architecture correcte et stable.

Cette phase demande une très bonne connaissance des outils disponibles sur le marché mais

également une très bonne aptitude à utiliser l’abstraction et les concepts objets pour le

développeur.

Gestion de la Relation Client Glossaire

Glossaire

CMMI, sigle de Capability Maturity Model + Integration, est un modèle de référence, un ensemble structuré de bonnes pratiques, destiné à appréhender, évaluer et améliorer les activités

des entreprises d'ingénierie.

Campagne Marketing, c’est un ensemble cohérent d’actions marketing entreprises sur une même période et visant à promouvoir le même produit ou service.

Campagne informationnelle, c’est une campagne Marketing dont l’objectif est de passer des informations qui ne sont pas nécessairement lié aux produits ou services de l’entreprise.

Campagne promotionnelle, c’est une campagne Marketing dont l’objectif est de stimuler les ventes à travers l’organisation des promotions sur des produits ou des services.

Campagne de prospection, c’est une campagne Marketing dont l’objectif est d’identifier de nouveaux clients potentiels et à les transformer en clients réels (prospection-vente).

Compte, il représente une personne ou une société qui entretient des relations avec l’entreprise (il pourrait être un client, un fournisseur, un partenaire…etc). Un compte est représenté par un ou plusieurs contacts, mais il possède toujours un contact par défaut.

Contact, c’est un représentant du compte. Il désigne la personne qu’on doit contacter pour représenter le compte

ISO 9001 fait partie de la série des normes ISO 9000, relatives aux systèmes de gestion de la qualité, elle donne les exigences organisationnelles requises pour l'existence d'un système de gestion de la qualité.

Opportunité de vente, il s’agit d’une solution originale pour répondre aux besoins et attentes détectées chez son client.

Prospect, c’est client potentiel (une personne ou entreprise susceptible de devenir un client) à qui on cherche à vendre un produit ou un service.

C’est une personne ou entreprise intéressé par un produit ou service.

Système embarqué, c’est un système électronique, piloté par un logiciel (Un logiciel ou une application est un ensemble de programmes, qui permet à un ordinateur ou à un système informatique...), qui est complètement intégré au système qu'il contrôle. On peut aussi définir un système embarqué comme un système électronique soumis à diverses contraintes.

Gestion de la Relation Client Bibliographie et Netographie

Bibliographie et Netographie

Bibliographie

[1] Nathalie Lopez, Jorge Migueis et Emmanuel Pichon, Intégrer UML dans vos projets,

Editions Eyrolles, 2000.

[2] Ivar Jackobson, Grady Boosh, James Rambaugh, Le processus unifié de développement

logiciel, Editions Eyrolles, 1999.

Cours

[3] Cours UML (3ème IAG) enseigné par Mme Selima Besbes, 2008.

[4] Cours ‘Génie logiciel et conduite de projet’ (4ème IAG) enseigné par Mme Chiraz Laatiri,

2008.

[5] Cours ‘Conception orientée objet des systèmes d’information’ (4ème IAG) enseigné par Mme

Bouthaïna Jlifi, 2008.

Netographie

[6] http://fr.wikipedia.org/wiki/CMMI

[7] http://fr.wikipedia.org/wiki/Syst%C3%A8mes_embarqu%C3%A9

[8] http://www.labo-sun.com/

[9] http://fr.wikipedia.org/wiki/JavaServer_Faces

http://fr.wikipedia.org/wiki/JavaServer_Faces

http://www.labo-sun.com/

http://fr.wikipedia.org/wiki/Syst%C3%A8mes_embarqu%C3%A9

http://fr.wikipedia.org/wiki/CMMI

Projet de fin d'etude gestion informatique

Text of Projet de fin d'etude gestion informatique

Bureau d'Etude Mecanique

Chapitre : METHODES D'ETUDE DE LA CELLULEeric.vinas.free.fr/IMG/pdf/Methodes_etude_cellule-eleves.pdf · Chapitre : METHODES D'ETUDE DE LA CELLULE 1ère PARTIE: METHODES D'ETUDE DE

Projet de fin d'etude :Control d’acces par empreintes digitale

Projet de Memoire pour la fin d'etude Joseph Haba

Travail Ecrit de Fin D'Etude

Projet de Fin d'Etude

MEMOIRE DE FIN D'ETUDE - LAULHERE

Projet de fin d'etude sur le parc informatique

Memoire de fin d'etude 353

Projet Fin d'Etude

Rapport Fin d'Etude Younes CNAM

Projet de fin d'etude ikrame final

PROGRAMME D'ETUDE JAZZ

RAPPORT DE PROJET DE FIN D'ETUDE - … · RAPPORT DE PROJET DE FIN D'ETUDE ... RTLINUX 10 3.1 ... hardware interrupt is detected by the processor and the moment an interrupt handler

Projet de Fin d'Etude Licence Appliquée En Gestion Comptable Par Hamed KHARRAZ La Santé Financière de Tunisie Télécom

Rapport Projet de fin d'etude sur le parc informatique

rapport fin d'etude

Memoire de Fin d'Etude Ingénieur de Conception en Électricité TIOMO DUCLAIR

Memoire de fin d'etude . marketing evenementiel : cas de la cellule de communication CMN/AVAL SONATRACH

Rapport : Projet de Fin d'Etude

Stage de Fin d'Etude AGE

Memoire Fin D'etude Master 2 Optoelectronique

Rapport de fin d'etude ; etude conception d'un journal lumineux

PROGRAMME D'ETUDE DRUMSET

projet fin d'etude : ouvrage d'art

Rapport de Projet de Fin d'Etude - INSA de Lyondocinsa.insa-lyon.fr/these/doc/rapport_final.pdf · Projet CITHER - Rapport de Projet de Fin d'Etude - Version 1.0 Rédacteur : Julien

Rapport de Projet de Fin d'Etude

Rapport de Projet de fin d'etude - Google Groups

STAGE DE FIN D'ETUDE

106 VOYAGE D'ETUDE

Engineering

Projet de fin d'etude gestion informatique

Text of Projet de fin d'etude gestion informatique