Deuxième partie : étude préalable
Chapitre I : domaine d’étude
Problématique et objectifs
Problématique
La gestion des courriers est l’une des taches du MAAC. Pour effectuer cette tache les agents des différents secrétariats du MAAC utilisent une application appelée SYGECO (Système de Gestion des Courriers) pour gérer les différents courriers.
Tout courrier est enregistré dans le SYGECO avant tout traitement. Cela permet d’en assurer la traçabilité. Au niveau de chaque département ou il est acheminé, le courrier peut être redirigé vers un ou plusieurs départements afin d’être traité conformément à ces instructions. Cependant, le SYGECO présente quelques limites qui ne rendent pas son utilisation optimale à savoir :
l’absence d’accusés de réception des courriers au niveau des secrétariats;
la non possibilité de transférer des fichiers physiques (scan de documents …) ;
la non possibilité de modifier les départements en fonction de l’organigramme du MAAC ;
la non possibilité de modifier les degrés d’urgence des courriers.
la non possibilité de modifier les catégories des courriers.
la non possibilité de modifier les types d’instructions faites sur les courriers.
Le MAAC comme toute structure public ou privé est exigeant en matière de gestion de son courrier. Au vue de ces nombreuses difficultés qui rendent le SYGECO en inadéquation avec le métier de gestionnaire de courrier, nous avons décidé en commun accord avec le groupe de pilotage de proposer la mise en place d’un nouveau système automatisé qui sera plus adapté que le premier. C’est donc dans l’optique de proposer une solution que le thème suivant : « Analyse et conception d’une application de gestion des courriers du MAAC : cas du SYGECO2
» nous a été soumis.
Objectifs de l’étude
L’objectif de ce travail se résume essentiellement à la réalisation d’une application Web dédié à la gestion des courriers du MAAC. Elle devrait permettre aux agents des secrétariats de :
enregistrer des courriers entrants et sortants ;
confirmer la réception d’un courrier ;
diffuser un courrier à d’autres départements ;
aux administrateurs de mieux paramétrer l’application (gestion des services, des instructions, du niveau d’urgence et de la catégorie des courriers) ;
avoir des statistiques sur le nombre de courriers en fonction de chaque département, chaque utilisateur et chaque type de courrier
Mise en œuvre du projet
Groupe de travail
Pour mener à bien notre étude, nous avons recensé les acteurs intervenant dans l’exécution et la réalisation du projet. Ils sont repartis dans trois (03) entités à savoir :
le groupe de pilotage ;
le groupe de projet ;
le groupe des utilisateurs.
Comité de pilotage
Le comité de pilotage est un groupe d’encadreurs chargés de veiller au bon fonctionnement du projet. Il valide les grands choix techniques et fonctionnels et fixe les orientations générales.
Pour le présent projet, ce groupe est composé de :
Capitaine Edgard SAKANA, notre maître de stage ;
Sous-Lieutenant Batièro KAMBOULE, informaticien a la DCSI ;
Groupe de projet
Le groupe de projet est chargé de l’exécution, la conception ainsi que la mise en place du projet. Ce groupe est composé de :
COMPAORE Donald Wend-Payangde étudiant en fin de cycle de licence professionnelle en Système d’Information et Réseaux à l’ESTA.
Groupe de projet de la version précédente
Le groupe utilisateur se compose de ceux qui ont eu à travailler sur la conception et la mise en place du SYGECO est chargé de fournir toutes les informations nécessaires à la bonne conduite du projet. Il se compose de :
Capitaine Damiba N.Gontran P.P
Adjudant Sanou Soungalo
Ressources
Pour le démarrage du projet nous allons décrire dans le tableau suivant les ressources nécessaires à la mise en place du projet. Ces ressources qui peuvent être humaines ou matérielles sont entre autres fournies par la DCSI, par l’ESTA ou acquises par l’étudiant.
| RESSOURCES | ESTA | DCSI | ETUDIANT | |
| Ressources humaines | Maitre de stage | Non | Oui | Non |
| Professeur de suivi | Oui | Non | Non | |
| Ressources matérielles | Ordinateur portable | Non | Non | Oui |
| Connexion internet | Non | Oui | Oui | |
| Machine serveur | Non | Oui | Non | |
| Onduleur | Non | Oui | Non |
Tableau 1 : Ressources nécessaires pour l’exécution du projet
Source : Personnel
Planning prévisionnel
Le planning prévisionnel est un outil de communication qui permet de représenter de façon synthétique l’organisation des travaux et l’affectation des ressources aux différentes tâches. Conscient de l’importance de cet outil dans la réalisation de notre projet, et en accord avec le groupe de pilotage, nous avons adopté un planning avec GanttProject qui est un logiciel de gestion de projets basé sur l’utilisation d’un diagramme de Gantt. Il permet de créer une liste de taches (groupées ou non) avec des indications de durée et d’affectation de ressources humaines.
Figure 4 : Planning prévisionnel
Source : Schémas réalisé avec Gantt Project
Chapitre II : méthodologie d’analyse et de conception
Langage de modélisation (UML)
Généralités
La modélisation est une technique d’ingénierie permettant de comprendre un système par l’établissement de modèles pour mettre au point une solution à un problème. Ne dit-on pas qu’une image vaut mieux que mille mots ? Ceci est l’illustration inspirante de la majorité des langages de modélisations, car elle permet aux informaticiens et personnes de métier d’un domaine de comprendre un système. UML, c’est l’acronyme anglais pour « Unified Modeling Language », il se traduit par « langage de modélisation unifié » en français. La notation UML est un langage visuel constitué d’un ensemble de schémas appelés diagrammes, qui donnent chacun une vision différente du projet à traiter. UML nous fournit donc des diagrammes pour représenter le logiciel à développer : son fonctionnement, sa mise en route, les actions susceptibles d’être effectuées par le logiciel, etc. Réaliser ces diagrammes revient donc à modéliser les besoins du logiciel à développer. UML est surtout utilisé lorsque l’on prévoit de développer des applications avec une démarche. Le langage UML ne préconise aucune démarche, ce n’est donc pas une méthode. Chacun est libre d’utiliser les types de diagramme qu’il souhaite, dans l’ordre qu’il veut. Il suffit que les diagrammes réalisés soient cohérents entre eux, avant de passer à la réalisation du logiciel, néanmoins il préconise d’adopter une démarche ayant les caractéristiques suivantes : itérative et incrémentale, guidée par le besoin des utilisateurs du système, centrée sur l’architecture logicielle.
Figure 5 : Champs d’application du langage UML dans la modélisation du SI
Source : https://
Pourquoi choisir UML
De nombreuses raisons militent en faveur du choix d’UML, ce sont les suivantes :
UML est un langage formel et normalisé ;
Il cadre l’analyse (il couvre toutes les phases d’un cycle de développement) ;
Il est stable, modulaire et sans ambiguïtés ;
Sa maintenance est souple en cas d’évolution ;
Son caractère polyvalent et sa souplesse en font un langage universel ;
UML est issu du terrain ;
UML est ouvert (il est indépendant du domaine d’application et des langages d’implémentation) ;
Les groupes d’utilisateurs UML favorisent le partage des expériences ;
Processus de développement
Définition d’un processus de développement
UML, vu précédemment, ne préconise aucune démarche à suivre ; alors, le choix d’un processus de développement adapté est nécessaire. Dans l’ouvrage UML 2 en action de Pascal Roque et Franck Vallée, nous avons la définition suivante : « Un processus définit une séquence d’étapes, en partie ordonnées, qui concourent à l’obtention d’un système logiciel ou à l’évolution d’un système existant. L’objet d’un processus de développement est de produire des logiciels de qualité qui répondent aux besoins de leurs utilisateurs dans des temps et des coûts prévisibles ». Pour déterminer le processus de développement adapté à notre projet, nous allons mener une étude comparative de quelques processus existants.
| Méthodes | Descriptions | Points forts | Points faibles |
| RUP (Rational Unified Process) | Promue par Rational et construite sur UML avec une approche applicative d’UP (Unified Process) ; Processus en 4 phases : Inception, Élaboration, construction, transition ; | Itérative et incrémentale, elle est pilotée par les besoins des utilisateurs et fait une place à la technologie et à la gestion des risques. Très souvent appelée méthode lourde car elle cible les grands projets dans de très grandes entreprises. | Elle est coûteuse à personnaliser et très axée processus, au détriment du développement. Parfois difficile à mettre en œuvre de façon spécifique. |
| 2TUP (Two Track Unified Process) | Dérivée d’UP (construite sur UML), elle propose un cycle de développement en Y et cible des projets de toutes tailles. Elle est basée sur un processus en 3 phases : fonctionnelle, technique, réalisation ; | Itérative et incrémentale, elle est pilotée par les besoins des utilisateurs et fait une place à la technologie et à la gestion des risques. Répond aux contraintes (techniques et fonctionnelles) de changement continuel imposées aux SI des entreprises contrairement à RUP. Elle offre un processus qui s’adapte à tout type de projets et est fréquemment utilisé en entreprise. | Cette méthode ne propose pas de documents types et son coût de réalisation est élevé ; |
| MERISE (Méthode D’Études et de Réalisations Informatiques) | C’est une méthode d’analyse et de conception structurelle. Elle propose un cycle de développement en trois (3) axes à savoir l’axe cycle de décision, l’axe cycle d’abstraction et l’axe cycle de vie. Elle est utilisée pour la modélisation des données en vue de la construction d’une base de données relationnelle | Basée sur une approche systémique, elle permet une appréhension globale et rapide du système d’information à concevoir. Elle est adaptée au contexte de création d’application. | Sa mise en œuvre est lourde car utilise un formalisme jugé assez complexe. |
Tableau 2 : Étude comparative des processus de développement
Source : https:// 2003 ; page 12)
Choix d’un processus de développement
En considération les avantages et inconvénients des processus ci-dessus cités, nous avons opté pour la méthode 2TUP (2 Track Unified Process) pour les raisons suivantes :
Le processus 2TUP s’appuie sur UML tout au long de son cycle de développement, car ses différents diagrammes permettent facilement et clairement, de bien modéliser le système à chaque étape ;
Le processus 2TUP répond aux contraintes de changement continuel imposées aux systèmes d’informations des entreprises ;
Le processus 2TUP peut être adapté à une large classe de système logiciel, à différents domaines d’application, à différents types d’entreprises, à différents niveaux de compétences et à différentes tailles de l’entreprise ;
Le processus 2TUP remplit les caractéristiques : Itérative, incrémentale, guidé par le besoin des utilisateurs du système, centrée sur l’architecture logicielle que UML préconise.
Figure 6 : Schémas du processus de développement 2TUP
Source :
