Conception et mise en place d’un CRM dédiée au centre d’appel à l’aide de Symfony4

Notes:

Après une recherche et collecte des informations approfondis nous avons remarqué qu’à Ophony le CRM VICIdial représente les limites suivantes

<!-- Slide number: 8 -->

 # Solution


Notes: La mise en place d’une solution décisionnelle est devenue nécessaire pour la société Ophony Notre mission est de concevoir et développer une nouvelle application permettant la gestion de la relation client qui permet de

Visualiser des tableaux de bord. • Améliorer les fonctionnalités de l’application. • Utiliser une architecture MVC, cette architecture sert à simplifier la tâche du développeur qui tenterait d’effectuer une amélioration sur le projet. • De plus, elle doit être ergonomique et facile à utiliser.

<!-- Slide number: 9 --> # Spécification des besoins

Notes: L’analyse fonctionnelle est une démarche qui consiste à caractériser les fonctions offertes par un produit pour satisfaire les besoins d’un utilisateur

<!-- Slide number: 10 --> # Identification des acteurs

 Agent Super administrateur Administrateur

Notes: Super administrateur : C’est l’acteur qui a une visibilité totale sur la base de données. Il a comme tâche de gérer tout le système. Il gère les utilisateurs et les droits pour chacun d’eux

Administrateur : C’est l’acteur qui a comme tâche de gérer les agents ainsi les groupes d’agents, gérer les listes, les campagnes, le suivi de la production en temps réel, consulter les statistiques par campagnes, par liste ou par utilisateurs. Agent : C’est l’acteur qui a comme tâche de consulter ces fiches des rendez-vous sur une ou plusieurs campagnes, d'accéder à l'historique de son activité, récupérer le temps d'appel, les appels sortants, les enregistrements pour tous les communications et de lancer les appels .

<!-- Slide number: 11 -->

Besoin fonctionnelles

Notes: Notre système intitulé VICIdial doit satisfaire les besoins fonctionnels suivants :

<!-- Slide number: 12 -->

 #

Notes: Diagramme de cas d’utilisation global le diagramme de cas d’utilisation décrit l’interaction entre le système et l’acteur en déterminant les besoins de l’utilisateur et tout ce que doit faire le système pour l’acteur

<!-- Slide number: 13 --> # Besoin non fonctionnelles





Notes: En plus des fonctionnalités capitales citées précédemment, notre solution doit prendre en considération certaines contraintes additionnelles et répondre à un ensemble de besoins non fonctionnels. Il s’agit des besoins qui caractérisent le système à savoir Rapidité :la vitesse d’affichage influence fortement l’efficacité de l’application. Sécurité :

<!-- Slide number: 14 --> # Conception

 Architecture physique

Notes: Couche Présentation : Elle correspond à la partie de l’application visible et interactive avec les utilisateurs ; — Couche Serveur Web : Elle sert de médiateur entre la couche présentation et la couche métier, recevoir les requêtes http clientes, et assure la validation des données envoyées par le client ; — Couche Métier : Elle responsable de service web et comporte les différents paquetages métier du système. Ces paquetages sont appelés par les composants de la couche Web pour répondre aux requêtes des utilisateurs ; — Couche données : Elle responsable du stockage physique de données.

<!-- Slide number: 15 --> Diagramme de classe

Notes: une vue statique sous forme de diagramme de classe générale associe à notre projet

<!-- Slide number: 16 -->


Notes: Le diagramme de classe permet de représenter l’ensemble des informations formalisées. Ces informations sont structurées c’est-à-dire qu’elles sont regroupés dans des classes. Ainsi, toutes les informations mémorisées, manipulées, transformées, analysées et partagées pour accomplir les finalités du domaine doivent figures quelque part dans le diagramme de classe.

<!-- Slide number: 17 -->


<!-- Slide number: 18 --> Diagramme de séquence

<!-- Slide number: 19 --> # Ajouter


<!-- Slide number: 20 --> # Réalisation


<!-- Slide number: 21 --> # Environnement logiciel

Notes: Les technologies utilisées lors de la phase de conception et de développement sont les suivants :

<!-- Slide number: 22 --> # Technologie Utilisés Back-end Base de données Front-end









<!-- Slide number: 23 --> # Outils utilisés





<!-- Slide number: 24 --> Pourquoi Symfony 4?

<!-- Slide number: 25 -->


Notes: Notre choix s’est orienté vers Symfony car en premier lieu, nous avons trouvé que Symfony est le Framework le plus adéquat qui répond à nos besoins, en deuxième lieu, Il le suit le motif de conception MVC,

<!-- Slide number: 26 --> # Architecture Symfony4


Notes: On remarque bien que chaque phase du travail est séparée, ce qui permet une organisation plus claire du code. Chaque chose à sa place.

<!-- Slide number: 27 -->


Notes: VICIdial répond à des caractéristiques jugées importants pour les utilisateurs, parmi ces aspects nous retrouvons les scores de confiance, la valeur, les nombres d’utilisateurs, ou encore la valeur selon les utilisateurs. Voici la liste complète des aspects évalué : • Capacité du point de vue des utilisateurs • L’éventail des fonctionnalités • Caractéristiques • Intégration • Confiance

<!-- Slide number: 28 --> # Jeux d’essai


<!-- Slide number: 29 --> # Interface Authentification



Notes: L’utilisateur (administrateur ou agent ) doit indiquer son nom d’utilisateur et son mot de passe pour qu’il puisse accéder à l’application. Le mot de passe est cryptés et donc illisible même si avec un accès direct à la base de données.

<!-- Slide number: 30 --> # Interface Menu campagnes


<!-- Slide number: 31 --> # Interface Menu statuts


<!-- Slide number: 32 --> # Interface des listes


Notes: L’administrateur doit remplit les informations nécessaires et il valide

<!-- Slide number: 33 --> # Interface des fiches


Notes:

<!-- Slide number: 34 --> # Interface Liste centre d’appel


<!-- Slide number: 35 --> # Interface des statistiques


<!-- Slide number: 36 --> # Conclusion ET perspectives

 .


Notes: nous avons réussi à concevoir et développer un CRM complèt et fonctionnel

<!-- Slide number: 37 --> # Conclusion ET perspectives & Perspective

Améliorer l’apparence de l’application. Déploiement de l’application


<!-- Slide number: 38 --> #