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

<!-- Slide number: 6 -->

 # Problématique


Notes: Apres une étude approfondie de l’application existante on a trouvée plusieurs problèmes tel que

<!-- Slide number: 7 -->

 # Solution


Notes: Apres ses études, nous avons décidé d’amélioer notre app en :

<!-- Slide number: 8 --> # 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: 9 --> # 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: 10 --> # Besoin fonctionnelles

Notes: Nous exposons ainsi tous les besoins fonctionnels qui devront être implémentés au sein de notre projet pour les différents modules de notre applicatio Chaque utilisateur (administrateur et agent ), est déjà inscrit sur l’application et a un compte. Il possède un espace spécifique qui lui permet de s’authentifier avec un login et un mot de passe. super administrateur : supprime, consulte, modifie et ajoute un nouveau centre d'appel. administrateur : supprime, consulte, modifie et ajoute une nouvelle campagne. Nous exposons ainsi tous les besoins fonctionnels qui devront être implémentés au sein de notre projet pour les différents modules de notre application administrateur : supprime, de consulte, de modifie et ajoute un nouveau statut. administrateur : supprime, de consulte, de modifie et ajoute une nouvelle liste.

administrateur : supprime, de consulte, de modifie et ajoute un nouveau groupe

Nous exposons ainsi tous les besoins fonctionnels qui devront être implémentés au sein de notre projet pour les différents modules de notre application administrateur : consulte les statistiques des campagnes administrateur : supprime, de consulte, de modifie et ajoute une nouvelle liste.

<!-- Slide number: 11 -->

 #

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: 12 --> # 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: 13 --> # 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: 14 --> Diagramme de classe

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

<!-- Slide number: 15 -->


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


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

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


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


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

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

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









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





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

<!-- Slide number: 24 -->


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: 25 --> # Architecture Symfony4


<!-- Slide number: 26 -->


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: 27 --> # Jeux d’essai


<!-- Slide number: 28 --> # 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: 29 --> # Interface Menu campagnes


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


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


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

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


Notes:

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


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

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

 .


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

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

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


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