État de l’art des applications de « Gestion de courriers »

STAGE DE FIN D’ÉTUDES Master Professionnel en Nouvelles Technologies des Télécommunications et Réseaux

Solution proposée et objectifs

Dans le but de changer en mieux le Système d’Information actuel et d’acquiescer au même temps aux éventuelles attentes du futur système, en apportant certaines améliorations dans le déroulement de travail et le fonctionnement de service concerné par la gestion de courriers, afin de réduire certaines erreurs et difficultés ayant trait à cette gestion, c’est-à-dire d’essayer de suivre toute procédure à effectuer.

Et vu ce qui précède, on doit concevoir et développer une application qui nous permet de prendre la solution aux problématiques et de remédier aux dysfonctionnements et des obsolescences les plus frappantes de certains systèmes actuels et aux problèmes qui ont été relevés et étudiés ; Donc il s’agit de proposer la réalisation d’une application pour le service de « Gestion de courriers (Bureau d’Ordre) d’une entreprise » avec une Base de Données ; Ce qui permettra d’alléger les charges des traitements manuels, le coût et d’assurer un accès facile et rapide aux différentes données, historiques.
Le choix de cette solution, est dans le but de pouvoir satisfaire les objectifs attendus de différents acteurs et services intéragissants dans la gestion de courriers (Bureau d’Ordre), qui permettra de :

• Gagner du temps pour mieux mâtriser la chaîne de traitement de courriers en évitant les problèmes liés à l’enregistrement, le suivi, la traçabilité et la gestion des courriers et des correspondances ( Arrivé e et départ ) des entreprises : Courrier simple, fax, facture, note de service, demande, réclamation, … ; • Etablir des listes des courriers : Impression de différents état s ; • Obtenir une vision claire sur les différents courriers selon des critères : Recherche ; • Avoir les possibilités d’ajouter, de rechercher, de consulter, de modifier et de supprimer facilement ; • Gestion des droits d’accès à l’application : Pour l’enregistrement des courriers, la recherche, la consultation, la modification et la suppression .

Les performances du système que nous proposons constitueraient une garantie pour la gestion des courriers (Bureau d’Ordre) d’une société, le choix porté sur ce sujet revêt d’une importance capitale au bon déroulement du travail au sein des entreprises et établissements, car le traitement et la diffusion de l’information constituent une force ou une faiblesse dans le rendement de toute entreprise. « Le service de gestion de courriers » ne peut plus être un service secondaire dans l’entreprise : C’est le coeur des flux entrants et sortants ; De ce fait, ce service requiert l’attention des entreprises à la hauteur de sa valeur stratégique afin d’en assurer la traçabilité et le suivi de tout courrier.

Ce travail nous permettra d’apporter une certaine amélioration dans le fonctionnement de différents services d’une entreprise, dans le but de réduire certaines erreurs et difficultés ayant trait à la gestion et l’acheminement et le déroulement de travail, par la suite suivre toutes procédures effectuées, afin de pouvoir éditer automatiquement les résultats ; C’est-à-dire que sur le plan pratique, cette nouvelle application apportera des nouvelles évolutions technologiques sur les méthodes de gestion de courriers (Bureau d’Ordre) de la société en assurant une bonne gestion : La rapidité, la performance et aussi bien la présence de l’information immédiatement tant au présent que dans le futur, ce qui permettra à la société de réaliser un pas de plus vers les nouvelles technologies.

Les Acteurs

Nous commençons, tout d’abord, par définir ce qui est « un Acteur » : « Un Acteur» représente l’abstraction d’un rôle joué par des entités externes (Utilisateur, dispositif matériel, … ou autre système) qui interagissent directement avec le système étudié.

Nous allons, par la suite, énumérer les acteurs susceptibles d’interagir avec le système ; « Les Acteurs » de notre application sont :
• « Le Responsable du Bureau d’Ordre
» : C’est  » le responsable de courriers « , qui peut : – Ajouter les courriers. – Rechercher les courriers. – Consulter les courriers. – Mettre à jour les courriers. – Imprimer la liste des courriers. – Supprimer les courriers départ.
• « L’Agent du Bureau d’Ordre
» : Cet acteur peut : – Ajouter les courriers. – Rechercher les courriers. – Consulter les courriers. – Imprimer la liste des courriers.
• « L’Administrateur » : C’est  » le responsable de gestion de l’application et de s utilisateurs « , qui peut : – Ajouter les utilisateurs. – Modifier les utilisateurs. – Supprimer les utilisateurs. – Rechercher les courriers. – Consulter les courriers.

Besoins fonctionnels

Les besoins fonctionnels représentent les réponses du système aux demandes formulées, auxquelles doit répondre notre application :
• Enregistrement de s différents types de courriers arriv é e et départ ,
• Gestion de courriers : Ajout, recherche, modification ( Mise à jour ), suppression, lister et / ou imprimer,
• Recherche de courriers selon critère : Par type, par date, …,
• Impression de différents états de suivi ,
• Établir la liste de différen ts établissements / structures en relation avec l’entreprise (Concernant les courriers arrivé e et départ ) ,
• Impression de différentes listes ,
• Gestion des droits d’accès à l’application : Pour l’enregistrement des courriers, la recherche, la consultation, la modification et la suppression,

Besoins non – fonctionnels

Les performances du système que nous proposons constitueraient une garantie pour la gestion de courriers (Bureau d’Ordre), nous mettons l’accent sur les besoins d’ordre non-fonctionnels qui spécifient les propriétés du système, telles que les contraintes d’environnement et d’implémentation, la performance, la maintenance, l’extensibilité et la flexibilité. Certains besoins non-fonctionnels sont généraux et ne peuvent pas être rattachés à un cas d’utilisation particulier, à part les besoins fondamentaux ; Notre futur système doit répondre aux critères suivants, à savoir :

• La performance : Une application doit être, avant tout, performante c’est à-dire à diverses fonctionnalités, répond aux exigences des futurs utilisateurs d’une manière presque optimale, cohérente et avec le minimum de manipulations.
• La fiabilité : L’application doit fonctionner sans erreurs, ni bugs d’une façon cohérente entre ses différents modules.
• La convivialité : La future application doit être facile à utiliser. En effet, les interfaces utilisateurs doivent être conviviales c’est-à-dire simples et adaptées aux besoins des utilisateurs.
• L’érgonomie : Qui a pour objectif d’améliorer l’Interaction Homme-Machine ( I n terface H omme – M achine : I.H.M. ), la facilité d’utilisation, en mettant l’accent, par exemple, sur la conception des interfaces utilisateurs simples et compréhensibles afin qu’elles soient en adéquation avec les caractéristiques, perceptives et cognitives de leurs utilisateurs.
• Présentation des informations aux utilisateurs d’une façon simple, claire et compréhensive des différentes rubriques, des interfaces, des menus, …
• La sécurité : Notre nouvelle application doit permettre un accès sécurisé aux données (Authentification et sécurité d’accès et droits attribués aux différents utilisateurs).
• Gérer les accès : Application Multi-Utilisateurs.
• L’application doit signaler les erreurs de manipulations ou les alertes par des messages d’erreur (Par exemple : Date erronée, manque de destinataire, …).

Les Diagrammes des Cas d’Utilisations

Dans cette partie, nous schématisons les Diagrammes des Cas d’Utilisations (En Anglais : « Use Case Diagram ») (« Un cas d’utilisation » décrit une fonctionnalité du système , utilisée par un utilisateu r / acteur et tell e que se manifeste pour ce dernie r ) qui représentent la structure des grandes fonctionnalités et besoins nécessaires et possibles que doit fournir le système à ses utilisateurs (Acteurs) en permettant d’identifier et de décrire les possibilités des interactions entre eux, le comportement et les fonctions du système du point de vue de l’utilisateur, c’est-à-dire la relation entre l’utilisateur et les objets que le système met en œuvre. Les diagrammes des cas d’utilisation modélisent à  » QUOI  » sert le système.

Table des matières

INTRODUCTION GÉNÉRALE
CHAPITRE 1 : ÉTAT D E L’ART ET ÉTUDE PRÉALABLE 
1.1 : État de l’art des applications de « Gestion de courries »
1.1.1 : « MENARA – GBO : Gestion du courrier (Bureau d’Ordre) », de la société « SIAT »
1.1.2 : « Gestion de Bureau d’Ordre et de courriers (GBO) », de la société « Xtensus »
1.1.3 : « MyGBO (Gestion Bureau d’Ordre) », de la société « nTIS »
1. 2 : Critiques des solutions existantes
Conclusion
CHAPITRE 2 : ANALYSE ET SPÉCIFICATION DES BESOINS 
2. 1 : Solution proposée et objectifs
2 .2 : Les Acteurs
2. 3 : Besoins fonctionnels
2. 4 : Besoins non-fonctionnels
2 . 5 : Les Diagrammes des Cas d’Utilisations
2 . 6 : Description textuelle des Cas d’Utilisations
2.6.1 : Cas d’Utilisations : « S’Authentifier »
2.6.2 : Cas d’Utilisations : « Ajouter_Courrier »
2.6.3 : Cas d’Utilisation : « Ajouter_Utilisateur »
2. 7 : Cycle de vie logiciel
2 . 8 : Chronogramme prévisionnel (Théorique) du projet
Conclusion
CHAPITRE 3 : CONCEPTION 
3. 1 : Modélisation des Besoins
3.1.1 : Description d’UML
3.1.2 : Modélisation Statique ou Diagrammes Structurels du système
3.1.2.a : Le Diagramme des Classes
3.1.2.b : Le Diagramme de Composants
3.1.2.c : Le Diagramme de Paquetages
3.1.3 : Modélisation Dynamique ou Diagrammes Comportementaux du système
3.1.3.a : Les Diagrammes des Séquences
3 3.1.3.b : Les Diagrammes d’États-transitions
3.1.3.c : Les Diagrammes d’Activités
3. 2 : Schéma Relationnel de la Base de Données
Conclusion
CHAPITRE 4 : RÉALISATION 
4 . 1 : Le Diagramme de Déploiement
4 . 2 : Environnement de travail
4.2.1 : Environnement matériel
4 4.2.2 : Environnement logiciel
4 4. 3 : Création de la Base de Données
4. 4 : Chronogramme réel du projet
Conclusion
CONCLUSION GÉNÉRAL E ET PERSPECTIVES
BIBLIOGRAPHIE

Télécharger le rapport complet