· Ministère des Enseignements Secondaire Supérieur et Année universitaire 2005-2006 de la Recherche Scientifique (MESSRS) Université polytechnique de Bobo-Dioulasso(UPB) BP

Ministère des Enseignements Secondaire Supérieur et Année universitaire 2005-2006 de la Recherche Scientifique (MESSRS)

Université polytechnique de Bobo-Dioulasso(UPB)� BP. 1096 Bobo-Dioulasso�

--,----Ecole Supérieure d'Informatique (ESI)�

Tel : 20972764�

Cycle des Ingénieurs de Travaux Informatiques (CITI)

. _ ......L .... -....lre

En vue de l'obtention du diplôme d'Ingénieur de Travaux Informatiques

Période de juillet à octobre 2006

Thème� Mise en place d'une plate tonne de téléservices :�

•� Téléservice de gestion des comptes d'accès distant et� de messagerie�

•� Téléservice de gestion des formations en informatique •� Téléservice de gestion des noms de domaine

Réalisé par Superviseur Maître de stage CISSE Mahomadou Mme NIKIEMA Yvon ne M. BOUDA Ahmed OUEDRAOGO M. Anselme Informaticien à la DELGI

Projet de fin d'étude

DEDICACES Nous dédions ce modeste travail à :

~ nos parents, pour leur soutien sans faille,

~ nos frères et sœurs, pour leur confiance,

~ nos amis, pour leurs encouragements,

~ nos camarades de promotion;

~ à tous ceux qui nous ont soutenu.

Mise en place d'une plate forme de téléservices

Projet defin d'étude

Au terme de ce travail qui n'aurait pas pu aboutir sans le soutien moral et

matériel de plusieurs personnes, nous tenons à remercier:

~ Monsieur le Délégué Général à l'Informatique de nous avoir accepté

comme stagiaires dans son institution;

~ Monsieur Alassani OUEDRAOGO ;

~ Monsieur Hamed BOUDA;

~ tout le personnel des départements de la DELGI ;

~ tout le corps professoral et administratif de l'ESI, pour les soins apportés à

la formation dont nous avons bénéficié;

~ tous les amis et connaissances qui ont contribué à l'élaboration de ce

document.

Mise en place d'une plate forme de téléservices


SOMMAIRE

SOMMAIRE 1

SIGLES ET ABREVIATIONS 4

INTRODUCTION GENERALE 5

CHAPITRE 1 : PRESENTATION DU CADRE ET DU THEME D'ETUDE. 6

1.1. PRESENTATION DE LA DELGI 6

1.1.1. Historique 6

1.1.2. Missions 7

1.1.3. Axes d'intervention 7

1.1.4. Organisation 8

1.2. PRESENTATION DU THEME Il

1.2.1. Etat des lieux Il

1.2.2. Les téléservices Il

1.2.3. Enjeux 12

1.2.4. Contraintes à respecter 12

1.3. METHODOLOGIE '" 13

1.4. ACTEURS 18

1.5. PLANNING PREVISIONNEL 19

CONCLUSION 20

CHAPITRE II : ETUDE DE L'EXISTANT 21

2.1. PARTIE 1: LES COMPTES D'ACCES DISTANT ET DE MESSAGERIE 22

2.1.1. PHASE 1 : REPERAGE DU DOMAINE 23

2.1.2. PHASE 2: DECOUVERTE DES INFORMATIONS 25

2.1.3. PHASE 3: MODELISATION DU WORKFLOW 29

2.1.4. PHASE 4 : DIAGNOSTIC 34

2.2. PARTIE 2: LES FORMATIONS INFORMATIQUES 35



2.2.3. PHASE 3 : MODELISATION DU WORKFLOW 42


2.3. PARTIE 3: LES TOP-LEVEL- BURKINA FASO 49


Mise en place d'une plate forme de téléservices 1



2.3.3. PHASE 3: MODELISATION DU WORKFLOW 58


CONCLUSION 66

CHAPITRE III: ETUDE DES SCENARII PROPOSES 67

3.1. ARCHITECTURE DE L'APPLICATION 67

3.2. OUTILS DE REALISATION PROPOSES 69

3.2.1. RESSOURCES LOGICIELLES 69

3.2.2. CARACTERISTIQUES MATERIELLES 72

3.3. METHODE DE CALCUL DU COUT DE REALISATION 73

3.4. DESCRIPTION DES SCENARII 76

3.4.1. PROPOSITIONS DES SCENARII 77

3.4.2. SCENARIO RETENU 82

3.4.3. ARCHITECTURE DU SCENARIO RETENU 84

3.5. OUTILS DE REALISATION RETENUS 85

3.5.1. CONFIGURATION MATERIELLE REQUISE 85

3.5.2. LOGICIELS RETENUS 85

3.6. EVALUATION DES COUTS 85

3.6.1. COUT DES OUTILS DE REALISATION 85

3.6.2. COUT DE DEVELOPPEMENT 86

3.6.3. COUT DE FORMATION 86

3.6.4. COUT TOTAL DE LA MISE EN ŒUVRE 86

3.7. SCENARIO DE MISE EN ŒUVRE GENERAL 87

CONCLUSION 88

CHAPITRE IV : RECONFIGURATION ET MODELISATION DU SYSTEME

D'INFORMATION 89

4.1. PHASE 5 : RECONFIGURATION DU SYSTEME D'INFORMATION 89

4.2. PHASE 6: MODELISATION DU FUTUR SySTEME 91

4.2.1. DIAGRAMME DE COLLABORATION 91

4.2.2. DIAGRAMME DES CAS D'UTILISATION 92

4.2.3. DIAGRAMME DE SEQUENCES 108

4.2.4. DIAGRAMME D' ACTIVITES 121



4.2.5. DIAGRAMME DE CLASSES D'ENTITES 133

4.3. PROCEDURES TRANSITOIRES 142

4.3.1. RECUPERATION ET TRANSFERT DES DOI\JNEES ACTUELLES 142

4.3.2. PROCEDURE TRAI\ISITOIRE AU NIVEAU ORGANISATIONNEL 143

4.4. POLITIQUE DE SECURITE 143

4.5. PROCEDURES DE SECOURS 145 1

CONCLUSION GENERALE 147

ANNEXE 148t

ApPROCHE DES REGLES QUI GOUVERNENT L'EXTENSION INTERNET 148

1 PRESENTATION UML 149

LES MAQUETTES D'ECRAN 166

1 BIBLIOGRAPHIE-WEBOGRAPHIE 171

1

1

1

1

1

1

1

1

1

1

1



SIGLES ET ABREVIATIONS

(La) DELGI: La Délégation Générale à l'Informatique (Structure);

(Le) DELGI : Le Délégué Général à l'Informatique;

ESI: Ecole Supérieure d'Informatique;

SI: Système d'Information;

TIC: Technologies de l'Information et de la Communication;

FAI: Fournisseur d'Accès Internet;

UML: Unified Modeling Language;

DEI: Département des Etudes et de l'Informatisation;

DFPI: Département de la Formation et de la Promotion Informatique;

DAGFI: Département de l'Administration Générale et des Finances;

DICIM: Département des Infrastructures et de Communications Informatiques et

de la Maintenance;

ONATEL: Office National des Télécommunications;

SIGASPE: Système Intégré de Gestion Administrative et Salariale du Personnel;

ICANN: Internet Corporation for Assigned l'James and Numbers;

SNI: Semaine Nationale de l'Informatique;

BD : Base de Données;

SGBDR : Système de Gestion de Bases de Données Relationnelles;

ONS: Domaine Name Server ;

OSC : Organisation de la Société Civile;

WAN: Wide Area Network (Réseau étendu);

LS: Ligne Spécialisée.


1 Projet de fin d'étude

1 INTRODUCTION GENERALE

1 Pour répondre aux multiples exigences professionnelles du monde informatique,

l'Ecole Supérieure d'Informatique (ESI) intègre dans le cursus de formation de ses 1 étudiants en fin de Cycle des Ingénieurs de Travaux Informatiques option

Analyste-programmeur, un stage pratique de réalisation d'un projet informatique.1 Ce stage vise l'informatisation d'un domaine d'activité donné au sein d'un

organisme ou d'une structure de la place. C'est à cet effet que nous avons été1 reçus à la Délégation Générale à l'Informatique (DELGI) pour mener une étude

complète d'analyse et de conception sur le thème « Mise en place d'une plate forme1 de téléservices ».

1 Dans ce présent rapport nous ferons une présentation succincte de notre structure

d'accueil, de la méthode d'analyse et de conception retenue, ensuite nous

modéliserons le système d'information (SI) actuel, puis nous proposerons des1 solutions pour le système d'information futur, enfin nous ferons une étude

détaillée de la solution retenue. 1

1

1

1

1

1

1

1

1

1

1

1



CHAPITRE 1: PRESENTATION DU CADRE ET DU THEME D'ETUDE

Le présent chapitre se veut celui d'une présentation succincte de notre structure

d'accueil, la DELGI, du thème d'étude et de la méthode choisie pour mener à bien

le projet. Enfin nous présenterons les différents acteurs du projet et donnerons un

planning prévisionnel du déroulement des différentes phases de l'analyse.

1.1. PRESENTATION DE LA DELGI

1.1.1. Historique

Les Technologies de l'Information et de la Communication (TIC) jouent

incontestablement un rôle déterminant dans le développement socio-économique

de toute nation en général, et du Burkina Faso en particulier à travers:

../ la réduction des effets négatifs de l'enclavement et de

l'inexistence des infrastructures de base (écoles, structures

sanitaires, routes, etc.) ;

../ L'amélioration de l'existence de tout individu qui dépend en

grande partie de la qualité et de la pertinence de l'information à

laquelle il peut accéder;

../ le renforcement de la bonne gouvernance;

../ la création de nouvelles opportunités d'affaires et de services;

../ l'amélioration de la compétitivité des secteurs productifs et de

l'économie dans le contexte actuel de la mondialisation.

La création de la DELGI en 1990 traduit la volonté du Gouvernement du BURKINA

FASO de saisir ces opportunités pour le développement économique et social du

pays.



1

1.1.2. Missions

1 La DELGI a pour missions:

.:. la planification, la réglementation et le contrôle de l'informatique; 1

.:. la planification, le suivi de la formation et de la recherche en

1 informatique;

.:. la délivrance des agréments pour la fourniture d'équipements et de

1 services informatiques;

.:. l'assistance et le contrôle technique des services informatiques, des 1 départements ministériels et institutions d'Etat, des centres de

traitement informatique, des centres de formation en informatique et de 1 toutes autres structures pbliques dont l'activité entre dans le cadre de

ses attributions; 1

.:. la supervision et la validation des schémas directeurs informatiques des

ministères et établissements publics;1

.:. la promotion et la vulgarisation de l'outil informatique;

1 .:. de donner son avis sur tout marché informatique de l'Etat et de ses

démembrements.

1

1.1.3. Axes d'intervention1

Pour s'acquitter de sa mission, la DELGI a développé au fil des années des

1 compétences et une expertise sur six axes d'intervention:

./ conduire des études d'intérêt national, élaborer des normes et susciter

1 des prises de décisions favorables au développement du secteur;

./ accorder des agréments techniques aux sociétés de services, autoriser la 1 création des noms de domaines et contrôler l'exécution des marchés

publics concernant des produits ou services informatiques; 1

1

1

1

1



1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1 1

1

./ susciter et/ou soutenir les initiatives et les projets structurants,

stratégiques ou innovants :

~ par la sensibilisation et le conseil ;

~ en apportant une caution morale;

~ en recherchant les financements nécessaires;

~ en mettant à disposition du personnel technique qualifié;

~ ou en servant d'incubateur;

./ coordonner les projets interministériels d'intérêt national afin de garantir

leur cohérence;

./ acquérir et gérer les ressources devant pour des raisons économiques ou

techniques être partagées par les départements ministériels et

institutions (salles de formation, salles de développement, réseaux

d'interconnexion, passerelle d'accès à Internet, etc.) ;

./ suivre et gérer la carrière du personnel informaticien de l'Etat.

NB : informations recueillies sur le site de la DELGI [www.delqi.qov.bf7

1.1.4. Organisation

La DELGI est dirigée par un Délégué Général à l'informatique et comprend quatre

(4) départements:

./ Le Département de la Formation et de la Promotion de l'Informatique (DFPI)

Ce département est chargé:

- des formations informatiques;

- de la promotion de l'outil informatique à travers des activités

comme la Semaine Nationale de l'Internet et des autres

technologies de l'information et de la communication.



./ Le Département des Etudes et de l'Informatisation (DEI) :


- du suivi des projets d'informatisation gouvernementaux;

- de la conception et gestion des sites web ministériels et

institutionnels;

- du suivi des stagiaires en informatique.

./ Le Département des Infrastructures de Communications Informatiques et de

la Maintenance (DICIM) :


- de la gestion des infrastructures de

communication informatique;

- de la maintenance du matériel informatique.

./ Le Département de l'Administration Générale et des Finances (DAGFI)


- de la gestion administrative et financière;

- de la gestion du personnel (suivi des carrières, les congés).



1.1.5. Organigramme

Cabinet du DELGI

1 1 1 1

DAGFI DEI DFPI DICIM

Figure 1.1 : organigramme de la DELGI

DAGFI : Département de l'Administration Générale et des Finances

DEI: Département des Etudes et de l'Informatisation

DFPI : Département de la Formation et de la Promotion de l'Informatique

DICIM : Département des Infrastructures de Communications Informatiques et de

la Maintenance.



1.2. PRESENTATION DU THEME

1.2.1. Etat des lieux

L'une des attributions de la DELGI est la promotion et la vulgarisation de l'outil

informatique. A ce titre, elle offre des services au grand public principalement aux

agents des ministères et institutions publics de l'Etat auprès desquels elle est le

principal Fournisseur d'Accès Internet. La création des comptes d'accès distants et

de messagerie, l'autorisation de la création des noms de domaine « .bf » et les

formations informatiques sont des services spécifiques qu'elle exécute dans ce

cadre. La gestion de ceux-ci, jusqu'à présent manuelle, s'avère difficile compte

tenu:

• du nombre de plus en plus grandissant des utilisateurs de ces services;

• de la lenteur dans les traitements et la circulation des informations avec les

services externes ;

• de l'impossibilité d'établir des statistiques fiables par l'absence de base de

données fiables.

Face à ces difficultés, la Délégation Générale à l'Informatique (DELGI) s'est

tournée vers une solution informatique afin de faciliter d'une part l'accès des

utilisateurs à ses services et d'autre part les tâches qui lui incombent dans

l'accomplissement de ceux-ci, d'où la mise en place des téléservices.

1.2.2. Les téléservices

C'est un ensemble de services de télécommunication proposés par une

organisation publique ou privée (à interface usager). Ces services reposent sur la

mise en œuvre de téléprocédures complexes entre acteurs publics et privés

permettant de répondre à l'intégralité d'une démarche administrative.

Les téléprocédures reposent sur la mise en place d'un service interactif permettant

de remplir depuis un ordinateur la totalité d'un formulaire puis de l'adresser via le

réseau Internet aux destinataires publics ou privés avec réponse en ligne des

organismes sollicités, sous forme d'un accusé de réception et / ou d'un récépissé.

En d'autres termes, le téléservice est tout système d'information permettant aux

usagers de procéder par voie électronique (l'Internet) à des démarches ou

formalités administratives.



Exemple de téléservice au Burkina Faso: le SIGASPE (Système Intégré de Gestion

Administrative et Salariale du Personnel) sur le site de la fonction publique

(www.fonction-publigue.gov.bf).

Notre étude sur « la mise en place d'une plate forme de téléservices », aura pour

objectifs de mettre en place une plate forme de trois (3) téléservices pour les

services suivants:

../ les comptes d'accès distants et de messagerie;

../ les formations en Informatique;

../ les TOP-LEVEL - BURKINA FASO (enregistrement des noms de

domaine Internet dans la zone « .BF »).

1.2.3. Enjeux

Le système à mettre en place devra résoudre dans une grande mesure les

problèmes rencontrés dans la gestion actuelle de ces trois (3) services qu'offrent

la DELGI et prendre en compte les perspectives d'évolution et les besoins des

utili sate LI rs.

Pour cela, il devra permettre:

.. un meilleur suivi des demandes;

.. l'accès des informations en temps réel;

4. l'établissement de statistiques fiables;

.. la rapidité et la facilité dans la recherche d'information;

... une plus grande productivité;

.. Une grande sécurité des données particulièrement sur les mesures

d'authentification des utilisateurs du futur système et de la

confidentialité de l'information véhiculée.

1.2.4. Contraintes à respecter

Notre travail consiste à mettre en place une application qui devrait permettre aux

utilisateurs du futur système de procéder à l'exploitation des fonctions qui

satisferont aux sous thèmes:

../ la gestion des comptes d'accès distants et de messagerie;

../ la gestion des formations en Informatique;



../ la gestion des TOP-LEVEL (enregistrement des noms de domaine

Internet dans la zone « .BF »).

Le système futur devrait être accessible depuis le site web de la DELGI

(www.delgi.gov.bf ) et fonctionnera en parallèle avec le système présent. De ce

fait, l'étude qui va suivre consistera à la mise en place d'une Base de Données et

d'une application web qui permettra de s'y connecter pour effectuer les tâches

attendues. En outre, le système devrait toujours respecter la hiérarchie actuelle de

circulation de l'information.

1.3. METHODOLOGIE

La conception d'un Système d'Information est une tâche complexe d'où la

nécessité de suivre une démarche d'analyse. Le langage de modélisation que nous

avons choisi est Unified lV10deling Language (Ut"IL) et la démarche empruntée est

celle de sept (7) phases présentée dans le livre de Chantal 1V10RLEY, Jean HUGUES

et Bernard LEBLANC, « UML pour l'analyse d'un système d'information - Le Cahier 1

de charge du maître d'ouvrage », Edition Dunod, Paris, 2002.

1 1.3.1. Le langage UML

Né de la fusion des trois méthodes qui ont le plus influencé la modélisation objet 1

au milieu des années 90 : OMT, Booch et OOSE, UIV1L ou langage de modélisation

objet unifié est un langage de modélisation conçu pour: 1

.,. visualiser un système;

.,. spécifier un système; 1

... construire un système;

... documenter un système. 1

UML offre des éléments pour décrire les différents aspects d'un système: les 1

diagrammes.

Les dlaqrarnrnes permettent de représenter le système selon différentes vues 1

complémentaires. Une vue est constituée d'un ou de plusieurs diagrammes. On

distingue deux (2) types de vues:1

1

1

1

-les vues statiques: les diagrammes de cas d'utilisation, de classes, d'objets,

de composants, de déploiement.



-les vues dynamiques: les diagrammes de collaboration, de séquences,

d'activités, états-transitions.

Diagrammes

structurels

Diagramme de classe

Diagramme d'objets

STATIQUE

Diagramme des cas d'utilisation

Diagramme de collaboration

Diagramme de séquence

DYNAMIQUE Diagramme d'états

transitions

Diagramme d'activités

Objectifs et fonctionnalités

Décrit les classes du système Décrit les relations entre les classes

Décrit les instances de classes et leurs relations qui composent l'application Donne une vue statique du système à partir de

cas réels

Décrit les fonctionnalités du système, l'application et les différents cas d'utilisation.

Définit les interactions d'un point de vue temporel entre les différents objets du système Dour un cas d'utilisation donné.

Il présente l'ordonnancement des messages (aspect temporel) pour une fonctionnalité donnée du système.

Attaché à une classe ou à un cas d'utilisation, il présente une classe par rapport à ses états possibles et aux transitions qui le font évoluer. Permet de spécifier ce que doit faire l'objet en réponse aux événements (ou traitements) qui lui sont Appliqués.

En s'intéressant ici plus aux actions qu'aux états, il montre l'activité et le fonctionnement d'une opération d'une classe.


Projetdefin d'étude

1.3.2. Pourquoi UML?

En tant que langage de modélisation objet, UML conserve tous les avantages du

paradigme objet. Les avantages de l'approche objet sont la stabilité de la

modélisation par rapport aux entités du monde réel, la construction itérative

facilitée par le couplage faible entre composants et la possibilité de réutiliser des

éléments d'un développement à un autre.

Un autre avantage de UML est la simplicité du modèle utilisé qui fait appel à

seulement cinq concepts (les objets, les messages, les classes, l'héritage et le

polymorphisme) pour exprimer de façon uniforme et le plus souvent visuelle

l'analyse, la conception et la réalisation d'une application informatique.

Enfin UML est aujourd'hui le standard de la modélisation objet et à été adopté par

les plus grands du monde de l'informatique: IBM, Microsoft, Oracle, Hewlett

Packard...

Les créateurs d'UML insistent tout particulièrement sur le fait que la notation UML

est un langage de modélisation objet et non pas une méthode. UML se concentre

sur la description des artefacts du développement du logiciel plutôt que sur la

formalisation du processus de développement lui-même.

1.3.3. Démarche d'analyse

Le langage UrvlL est intentionnellement indépendant de toute démarche de

développement. Le concepteur ou l'organisation peut choisir la démarche de

développement qui lui convient. Toutefois, les auteurs d'UML conseillent

l'utilisation d'une démarche itérative et incrémentale, centrée sur l'architecture et

dirigée par les besoins des utilisateurs .

./ itérative et incrémentale: pour modéliser le système (comprendre et

représenter) il vaut mieux s'y prendre plusieurs fois en affinant son

analyse par étape;

./ centrée sur l'architecture: Elle décrit des choix stratégiques qui

déterminent en grande partie les qualités du logiciel (adaptabilité,

performances, fiabilité ... ) ;



./ dirigée par les besoins des utilisateurs: les utilisateurs guident la

définition des modèles (périmètre du système à modéliser, le but du

système à modéliser ... ).

Nous avons choisi pour cela la démarche d'analyse en sept (07) phases présentée

dans le livre de Chantal MORLEY, Jean HUGUES et Bernard LEBLANC, « UML pour

l'analyse d'un système d'information - Le Cahier de charge du maître d'ouvrage»,

Edition Dunod, Paris, 2002.

- phasel : Repérage du domaine

Cette phase a pour objet principal de déterminer la finalité du projet, son

périmètre, ainsi que les acteurs concernés.

- phase2 : Découverte des informations

Cette partie a pour objet de prendre connaissance et comprendre les différents

aspects du système d'information et aussi de repérer les grands concepts

d'information gérés dans le domaine.

- phase 3: Modélisation du Workflow

Au cours de cette phase, les rôles des différents acteurs seront identifiés ainsi que

leur manière de collaborer afin d'atteindre la finalité du domaine;

- phase4 : Diagnostic

Cette phase permet de porter une appréciation sur la gestion des informations et

sur les processus;

- phaseS: Reconfiguration du système d'information

Elle permet de fixer les nouveaux principes portant sur la gestion des informations

et sur la configuration des processus;

- phase6 : Modélisation du futur système d'information

L'objectif de cette phase est de modéliser les différents aspects du futur système

d'information en s'appuyant sur les règles arrêtées lors de la phase précédente;



- phase7 : Rédaction du cahier de charges

Elle a pour objet de mettre en forme le cahier des charges du futur système

d'information qui permettra au maître d'œuvre de développer le système.

Le résumé de toutes ces phases est spécifié sur la figure ci-dessous

.................... . ..................... . .

~~r~~rt~!~ffi~0~[m~~i P!~f~~m~:~~:pl~~~è~::::::::::::::::::::: : ........ . .. . .

Phaseë:RECONFIGURATlQNOU .. 1

SYSTÈMEO'INFORMATION . 1

;.' .

Phase6:MQOElI~ATlON OU SYSTÈME " P·I.~FQRMATION

.Oiag[ari1fn~d~~II~bor~tiÔn·(dOmaine)

,Di~gramm~ri~ri[a,~é~$ (entli~s) Phase 7: REDACTION DU , ,;

CAHIER DES CHARGES

Légende:

1:::::::: :~Hd,è: d,~ :f~Hi~i~~~:::::::: 1 ReconfigLiration et Modélisation

du futur systeme

Cahier des charges

Figure 1.2. Diagrammes UML de la démarche d'analyse adoptée.

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Mise en place d'une plate forme de téléservices 17

1

1


1.4. ACTEURS

Plusieurs acteurs interviennent dans la réalisation de cette étude. Nous les avons

reparti en trois (3) groupes:

• Le groupe de pilotage;

• Le groupe de projet;

• Le groupe utilisateur.

Rôle Membres

- prend les décisions relatives aux

objectifs recherchés;

- Il fixe les orientations générales, - M. Moustapha BANDE (Chef du DEI) ; Groupe de

les délais à respecter; - M. Ahmed BOUDA (maître de stage) ; pilotage

- Il définit également les moyens à - Mme. Yvonne NIKIEMA (Superviseur).

mettre en place pour la réalisation

du projet.

chargé de l'exécution du projet c'est- M. Anselme 1"1 OUEDRAOGO ;

Groupe de à-dire l'étude, la conception et - M. Mahomadou CISSE.

projet éventuellement la réalisation de

l'application.

- Les responsables des départementsA un rôle consultatif;

DICIM et DFPI, DEI - est chargé de fournir toutes les

- L'ensemble des agents intervenant informations nécessaires à la

Groupe des dans le fonctionnement du système bonne conduite du projet;

utilisateurs actuel - Il intervient également dans la

FASONET validation des dossiers d'études

Demandeurs des services concernés produits par le groupe de projet.

Mise en place d'une plate forme de téiéservices 18


1.5. PLANNING PREVISIONNEL

Le planning prévisionnel est établi en fonction des différentes phases de notre

démarche d'analyse:

• L'étude de l'existant qui regroupe les phases 1 (repérage du domaine), 2

(découverte des informations), 3 (modélisation du Workflow) et 4

(diagnostic) ;

• L'étude du dossier de choix qui regroupe les phases 5 (reconfiguration du

système d'information) et 6 (modélisation du futur système d'information) ;

• L'étude du cahier de charges utilisateur qui associe la phase 7 (rédaction du

cahier de charges).

Phases Août Septembre Octobre

1

2

3

4

N.B: Une cellule du tableau représente une semaine.



CONCLUSION

Ce premier chapitre nous a permis d'une part de mieux cerner la problématique du

thème, des résultats attendus de notre travail d'analyse et de conception. Nous

avons aussi fait une brève présentation du langage UML que nous utiliserons pour

la modélisation et expliquer la démarche d'analyse adoptée pour mener à bien

notre étude.

Le prochain chapitre concerne l'étude du système existant. Cette étude sera faite

suivant les phases l, 2, 3 et 4 de notre démarche d'analyse adoptée 1

1

1

1

1

1

1

1

1

1

1

1 1 1 1 1



CHAPITRE II: ETUDE DE L'EXISTANT

Le chapitre précédent nous a permis de baliser la problématique tout en mettant

en place un planning prévisionnel pour notre étude. Nous entamons l'étude de

l'existant au cours de laquelle nous modéliserons le système d'information actuel

puis nous le critiquerons afin de dégager ses forces et ses insuffisances.

L'étude de l'existant par la démarche UML présentée au chapitre 1 se réalise grâce

aux phases 1 (repérage du domaine), 2 (découverte des informations), 3

(modélisation du Workflow) et 4 (diagnostic). Pour ce faire nous procéderons à des

interviews des acteurs du domaine et à la consultation de documents des

différents départements mis à notre disposition.

L'objectif de cette étude est d'obtenir une description détaillée des différents

traitements opérés dans chaque département quant aux services concernés et de

comprendre le fonctionnement actuel des différents postes de travail, d'identifier

les points positifs et les points de dysfonctionnement et de répertorier les

contraintes à prendre en compte. Ainsi, cette étude devra permettre d'aboutir

dans les prochaines phases à un système d'information composé de la partie

stable de l'existant, diminué des choix de gestion et d'organisation et augmenté

des nouveaux choix proposés.



1

1

1

1

1

1

2.1. PARTIE 1: LES COMPTES D'ACCES DISTANT ET DE

MESSAGERIE

Un compte d'accès distant est un compte qui permet à tout utilisateur bénéficiaire,

muni d'un modem, d'une ligne téléphonique analogique ou de toute autre

connexion WAN (Wide Area Network) et d'un logiciel d'accès distant de se

connecter au réseau Internet via son compte. (Voir figure 2.1)

DELGI

Agent Internet

Figure 2.1.1

Un compte de messagerie est un service de courrier électronique accessible depuis

un navigateur web (concept de Webmail).

Exemples:

• Compte de messagerie: [email protected], [email protected];

• Webmail: Yahoo mail, Hotmail.


mailto:[email protected]

1 1 1 1 1 1 1 1 1 1 1 1

1

1

1

1 1

1 1 1 1


2.1.1. PHASE 1 : REPERAGE DU DOMAINE

C'est la première phase de notre démarche d'étude. Rappelons qu'elle a pour objet

principal de déterminer la finalité du projet, son périmètre, ainsi que les acteurs

concernés.

2.1.1.1. Périmètre du domaine

Dans l'organisation actuelle du système présent, les échanges entre les unités se

font de la manière suivante:

Un agent public, demandeur de compte d'accès distant et de messagerie, remplit

un formulaire de demande qu'il peut retirer à la DELGI, précisément au

Département des Infrastructure de Communication Informatique et de la

Maintenance (DICIM). Le demandeur reproduira le formulaire en deux (2)

exemplaires qu'il remplira avec les mêmes informations. Une fois remplis, les

formulaires devront être visés par son Responsable administratif.

Les formulaires sont ensuite retournés à la DELGI pour traitement. Ils sont reçus

au Cabinet du DELGI pour validation puis imputés au DICIM pour création. Après

la création du compte, les formulaires sont complétés par les informations du

compte à savoir le nom du compte créé, l'adresse de messagerie et le mot de

passe de première connexion et un exemplaire est envoyé au bénéficiaire.

Les demandes de modification suivent les mêmes procédures.

Il arrive qu'une institution publique effectue des demandes de

création/modification de comptes pour ses agents. Dans ce cas les formulaires

sont regroupés et envoyés par bordereau à la DELGI. Le traitement de ses

formulaires reste inchangé.

NB: La création d'un compte d'accès distant et de messagerie est gratuite et

concerne uniquement les agents de l'Administration publique et de ses

démem brements.



2.1.1.2. Diagramme de collaboration

Il permet de percevoir les limites du projet et de visualiser les échanges du

domaine d'étude et les acteurs externes du projet.

t

Cabinet duDELGI

1

1

1

1

Oganismes publics Ql Agents del'administration publique"0c:1 m E Ql "0 c o iii1 CIl

'E CIl

ê ~ /

1 ~ 1

1

Departement DICIM1

Figure 2.1.2: Diagramme de collaboration

l 1

1

1

Mise en place d'une plate forme de téléservices 1 24


2.1.2. PHASE 2 : DECOUVERTE DES INFORMATIONS

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

1

C'est la deuxième phase de notre démarche d'étude. Elle nous conduira à la

définition des règles de gestion du système actuel et à la construction du

diagramme de classes des entités.

2.1.2.1. Règles de gestion

RG 01 : un organisme public dispose de plusieurs agents;

RG 02 : u agent relève d'un organisme public;

RG 03 : un agent peut effectuer plusieurs demandes;

RG 04 : une demande est effectuée par un et un seul agent;

RG 05 : une demande concerne un et un seul compte;

RG 06 : un compte peut être concerné par plusieurs demandes.

RG 07 : un compte appartient à un et un seul agent;

RG 08 : un agent peut avoir plusieurs comptes;

1 Mise en place d'une plate forme de téléservices 25

1


2.1.2.2. Diagramme des classes d'entités

agent • relève 1

-num_matricule (id) organisme...... -nom_agent ..... -num_organisme (id)-prenom_agent

-nom_organisme-autresprenorns -nom domaine organisme-fonction_agent

-telephone_prof -telephone_perso -adresseprof -adresse perso

1

1 appartient effectue

1." compte

demande -num_compte (id) O." -nom_compte-num_demande (id) concerne -mot_deyasse-nature_demande

-adresse électronique-date demandde O." 1 -créert)

+validerO +modifier()+rejeterO +suspendre() +supprimerO

Figure 2.1.3: Diagramme des classes d'entités

Mise en place d'une plate forme de tétéserviœs 26


DESCRIPTION DETAILLEE DES CLASSES D'ENTITES

Classe: agent

Attributs

Nom Description Type

num_matricule (id) l\Iuméro matricule Alphanumérique

nom_ agent Nom de l'agent Texte

prenom_ agent Prénom de l'agent Texte

autres_prenoms Autres prénoms de l'agent Texte

fonction_agent Fonction occupée de l'agent texte

service_ agent Service de l'agent texte

telephone_perso numéro de téléphone personnel Numérique

telephone_prof numéro de téléphone Numérique

professionnel de l'agent

adresse_perso Adresse boite postale Alphanumérique

personnelle de l'agent

adresse_prof Adresse boite postale Alphanumérique

professionnelle de l'agent

Méthodes

Nom Description

- -

Classe: organisme_public

Attributs


num_organisme (id) Numéro d'identification Numérique

nom_organisme Nom complet de l'organisme Texte

nom_domaine_organisme Nom de domaine de l'organisme texte

Méthodes

Nom Description

- -



Nom

num_demande (id)

nature_demande

date_demande

Nom

Valider 0 Rejeter 0

Nom

num_compte (id)

nom_compte

mot_de_passe

adresse_electronique

Nom

Créert)

ModifierO

suspendreï)

Classe: demande_compte

Attributs

Description Type

Numéro d'identification Numérique

Nature de la demande Booléen

(création/modification)

Date d'établissement Date

Méthodes

Description

Valide une demande

Rejette une demande

Classe: compte

Attributs

Description Type


Nom du compte utilisateur Texte

Mot de passe de première Alphanumérique

connexion

Adresse électronique Alphanumérique

Méthodes

Description

Crée un nouveau compte pour un utilisateur

Modifie un compte déjà existant

Suspens temporairement un compte

Mise en place d'une plate forme de télé services 28

1


2.1.3. PHASE 3 : MODELISATION DU WORKFLOW

2.1.3.1. Diagramme des cas d'utilisation

Système

effectuer une demande

Agent public \ ite }} \

\ Cabinet du DELGI

\ \

\ \ ffectuer une demand effectuer une demande \

\ de modification de de création de compte « include }~\ compte

\ \

\ \

\

Toute demande de compte doit faire l'objet de l'appreciation du DELGI

Valider une demande

créer 1modifier

chefDICIM un compte

1 1 agent DICIM 1 1 herite » 1 1 1

« inclüde }} modifier un compte 1 1 créer un compte

Informer le demandeur

Figure 2.1.4 : Diagramme des cas d'utilisations



DESCRIPTION DES CAS D'UTILISATIONS

Titre: Effectuer une demande

Résumé

Acteurs

Actions

0 Le demandeur vient retirer un formulaire

demande au secrétariat du Département

(DICIM) ;

0 Après remplissage, le demandeur dépose

au cabinet du DELGI deux (2) exemplaires

du formulaire;

0 La secrétaire du DELGI vérifie si les

formulaires sont correctement remplis

avant de les introduire chez le DELGI pour

validation;

0 Le DELGI vérifie les informations sur les

formulaires puis les valide;

0 Les formulaires sont ensuite imputés au

département DICIM avec un avis

favorable;

0 Les demandes rejetées sont retournées au

demandeur avec les raisons de son

invalidité.

Document reçu

Document utilisé

Document produit

Ce cas d'utilisation permet à un agent

d'effectuer une demande de compte.

Agent public, cabinet du DELGI

Règles de gestions et d'organisations

• Les agents des organismes publics sont

seuls habilités à effectuer les demandes de

compte d'accès distant et de messagerie.

• Toute demande doit être signée par le

responsable administratif du demandeur de

compte.

• Le demandeur doit déposer deux

exemplaires du formulaire. Après

traitement, un exemplaire lui sera

retourné.

• L'agent doit remplir sur le formulaire

seulement les informations administratives

et préciser l'opération demandée. Le nom

du compte, l'adresse électronique et le mot

de passe lui seront attribués après la

création. Cette partie sur le formulaire

sera donc remplie au DICIM et on lui

transmettra le formulaire d'où la raison de

deux exemplaires du formulaire à déposer.

L'autre sera conservé au DICIM.

• Très souvent la vérification de la secrétaire

du DELGI est faite sur place en présence

du demandeur

Formulaire de demande de compte

Formulaire de demande de compte

-



Titre: Créer /rnodlfler un compte

Résumé permet de créer ou de modifier un compte

Acteurs Chef DICIM, agent DICIM

Actions Règles de gestions et d'organisations

0 Réception des demandes validées par le • Le nom du compte, le mot de passe de

DELGI au DICIM ; première connexion et l'adresse de

0 Le chef DICIM transmet le formulaire à un messagerie électronique sont attribués par le

agent du DICIM pour création ou DICIM

modification du compte;

0 L'agent, grâce aux informations sur le • La DELGI conserve un exemplaire du

formulaire, crée ou modifie le compte sur formulaire (deux au départ) pour ses

le serveur; archives

0 L'agent complète sur le formulaire le nom

du compte créé, le mot de passe de • Le mot de passe attribué au demandeur est

première connexion et l'adresse de standard. Il est recommandé de changer le

messagerie ; mot de passe dès la première connexion

0 L'agent transmet le formulaire complété

chez le chef DICIM

0 La secrétaire du chef DICIM prépare un

bordereau avec le formulaire transmis par

l'agent qui sera signé par le chef DICIM ;

0 Le bordereau est envoyé au bénéficiaire du

compte (demandeur de compte)

Document reçu Formulaire de demande de compte

Document utilisé Formulaire de demande de compte

Document produit Bordereau signé par le chef DICIM



2.1.3.2. Diagramme de séquences

1 1DI:~ 1

retrait fiche de demande creation/modification

~~-----------------------------

1111

1 11

11

Dépôt du fonnulaire de demande (2) 1 1 11

1 11 111 111 11 1 11 1 111

Vérification fonnelle de la demande~

l> verification de l'authenticité de la demandl

l> Validation de lademande

Imputation du formulaire de demande de compte

1 111

11

1 1

Figure 2.1.5: Diagramme de séquence l : Processus de validation d'une demande de compte.



DICIM

Agent du DICIM Demandeur de compte

Reception du formulaire

Transmission du formulaire

création/mise à jour du compte

completer formulaire

retour du formualire completé

1Signature du bordereau 11 1 1 1

Transmission bordereau

Figure 2.1.6 : Diagramme de séquence2 : Processus de création ou de mise à jour d'un compte

Mise en place d'une plate forme de tétéservices 33


2.1.4. PHASE 4: DIAGNOSTIC

2.1.4.1. Faiblesses

Quelques difficultés apparaissent au niveau de la gestion des comptes d'accès

distant et de messagerie dont la majeure partie est due à la gestion manuelle des

différentes tâches. Au nombre de ces difficultés, nous pouvons citer:

• l'absence de structures décentralisées dans les autres villes du pays;

• la lenteur administrative dans le processus de création et modification d'un

compte;

• les difficultés à établir des statistiques fiables dues à l'absence d'une base

de données;

• le travail fastidieux de vérification des formulaires de demande;

• dans le système actuel un agent de l'administration publique peut avoir

plusieurs comptes dut à l'absence de base de données ne permettant pas le

contrôle des demandes multiples de création de compte d'un agent.

2.1.4.2. Forces

La gestion actuelle des comptes d'accès distants comporte des points positifs qui

sont:

• la bonne hiérarchisation dans la circulation des informations;

• la gestion centralisée des informations des comptes;

• la sécurité et confidentialité des informations véhiculées.



2.2. PARTIE 2: LES FORMATIONS INFORMATIQUES

2.2.1. PHASE 1: REPERAGE DU DOMAINE


Dans le cas de la formation, le fonctionnement du système présent est le suivant:

La DELGI, à travers son Département de la Formation et la Promotion de

l'Informatique (DFPI), propose des stages de formation sur des modules bien

déterminés à l'endroit des agents de l'administration publique et de ses

démembrements mais aussi aux particuliers.

En chaque début d'année, le DFPI adresse des lettres d'information aux différents

organismes publics, annonçant les formations qu'elle offre (modules, sessions,

dates) pour l'année en cours. Les organismes publics informés répondent (s'ils

sont intéressés) en précisant les modules, les sessions et le nombre de leurs

participants.

Le DFPI établit ensuite un planning sur la base de ces réponses tout en essayant

de satisfaire le maximum des souhaits. Une fois le planning établi, les organismes

en sont informés par une lettre administrative leur précisant le module, la session

et le nombre de participants retenus dans leur structure.

Les particuliers et les OSC (Organisation de la Société Civile) peuvent effectuer

des demandes de formations en adressant une demande adressée au Délégué

Général à l'Informatique. Ses demandes après validation du DELGI sont imputées

au DFPI pour programmation.

Après la formation, des attestations sont délivrées aux stagiaires puis le DFPI

enregistre le module et les organismes l'ayant suivi afin de mieux organiser leur

répartition les années à venir.

Pour satisfaire aux demandes des particuliers, le DFPI associe à chaque session

quelques particuliers suivant le module demandé. Cependant, des sessions

exceptionnelles sont programmées pour les particuliers et les OSC ayant effectué

une demande.

Il existe également des possibilités de demande de formation sur des modules

autres que ceux proposés par la DELGI sur demande de l'organisme.



NB:

Les formations sont gratuites et ouvertes à tout public conformément à sa

mission (promotion et vulgarisation de l'outil informatique). Cependant le

public cible est les agents de l'administration publique.

les réponses des organismes aux offres des propositions des formations de la

DELGI sont considérées comme des demandes de formation auprès de ce

dernier.


CabinetDELGI

Département DFPI

Figure 2.2.1 : Diagramme de collaboration



1

1 1

1 1 1

1


2.2.2.1. Règles de gestion

RG 01 : un particulier ou un organisme peut effectuer plusieurs demandes de

formation;

RG 02 : une demande est effectuée par un particulier ou par un organisme public;

RG 03: une demande de formation peut concerner plusieurs modules de

formation;

RG 04 : un module peut être concerné par plusieurs demandes;

RG 05 : un module comporte plusieurs sessions;

RG 06 : plusieurs particuliers ou agents publics peuvent participer à une session;

RG 07 : un particulier ou un agent public peut participer à plusieurs sessions;

RG 08 : une session concerne un module à la fois;

RG 09 : un agent relève d'un organisme;

RG 10 : un formateur peut assurer plusieurs sessions;

RG 11 : une session est assurée par un formateur.



2.2.2.2. Diagramme des classes d'entité

particulier

-num"'particulier(id) -nom"'particulier

Participe 1 -prenom"'particulier -fonction"'particulier -service"'particulier 0,,'-telephone"'particulier -adresse"'particulier

Effectue 1

1.,·

1..'

module sessionOemande_formallon formaleur

concerne -num_module (id) comporte assure +num_demande (id) -num_fonmaleur (id)

-intitule f---------I-nom fonmateur +creer_module{) -prenom_fonmaleur

+dete demande +valider{) 1 1... 1... 11..' 1 +modifier_module{)+refuser{)

+supprimer module{)

1..'

Effectue 2

1..' Participe2

organisme IlIenl

-num_organisme (id) -num_agent (id) +nom_organisme ~ relève -i-nom_egent +telephone_organisme -prenom_agent +adresse_organisme -fonction_agent 1...

Orllanlsme"public -num_ose -num_org"'public -nom ose -nom organisme"public

Figure 2.2.2 Diagramme des classes d'entité



DESCRIPTION DETAILLEE DES CLASSES D'ENTITE

Nom

num_particulier (id)

nom_ particulier

prenom_ particulier

adresse_particulier

telephone_particulier

fonction_particulier

service_pa rticu 1ier

Nom

-

Nom

num_module (id)

intitule

Nom

Classe: particulier

Attributs

Description

Numéro d'identification

Nom

Prénom

adresse boîte postale

numéro de téléphone

Statut du particulier (élève,

travailleur...)

Service où travaille le particulier

Méthodes

Classe: module

Attributs

Description


Intitulé

Méthodes

Type

Alphanumérique

Texte

Texte

alphanumérique

numérique

texte

texte

Description

-

Type

Alphanumérique

Texte

Description

Creer_module 0 Crée un nouveau module de formation

Modifier_module 0 Modifie le contenu d'un module de formation

Classe: demande_formation

Attributs


num_demande (id) Numéro d'identification Alphanumérique

Date_demande Date d'arrivée de la demande Date

Méthodes

Nom Description

Valider 0 Valide une demande de formation

Refuser 0 Refuse une demande de formation



Classe: organisme

Attributs


num_organisme (id) Numéro d'identification alphanumérique

nom_organisme Nom entier Texte

telephone_organisme Numéro de téléphone numérique

adresse_organisme Adresse boîte postale alphanumérique

Méthodes

Nom Description

- -

Classe: organisme public Il

Attributs


num_org_public Numéro d'identification alphanumérique

nom_organisme_public Nom entier Texte

Méthodes

Nom Description

- -

Classe: ose

Attributs


num_osc Numéro d'identification alphanumérique

nom_ose Nom entier de l'ose Texte

Méthodes

Nom Description

- -



Classe: session

Attributs


num_session (id) Numéro d'identification Alphanumérique

date_debut Date de début date

date_fin Date de fin date

Méthodes

Nom Description

reporter_session 0 reporte une session de formation

annuler_session 0 Annule une session de formation

Classe: agent

Attributs


num_agent (id) Numéro d'identification alphanumérique

nom_agent Nom de l'agent Texte

prenom_agent Prénom de l'agent texte

fonction_agent Fonction occupée texte

Méthodes

Nom Description

- -

Classe: formateur

Attributs


num_formateur (id) Numéro d'identification alphanumérique

nom_fomateur Nom du formateur Texte

prenom_formateur Prénom du formateur texte

Méthodes

Nom Description

- -



2.2.3. PHASE 3: MODELISATION DU WORKFLOW


Système

Effectuer une demandepourparticulier

Particulier

Effecluerune demande de formation

« herite»

Effectuer une demandepourOrganisme

\ \ \ \ \ \ \ \

~include » \ \ \ \ \

Organisme public Etablirle calendrier de

formation annuelle desagentsde l'administration publique

Personnes qui suivent les formations (agents, particulier...)

Programmer unesession de formations exceptionnelle

DFPI Misea jour du

calendrier deformation

Delivrerune attestation

stagiaire

Figure 2.2.3 : Diagramme des cas d'utilisations



Actions

0 Envoi du programme de formation

(modules, sessions proposées) aux

organismes publics;

0 Réponses des organismes publics voulant

y participer;

0 Etude de la programmation des organismes

suivant les modules et sessions

demandés;

0 Etablissement du calendrier annuel;

0 Notification des programmations aux

organismes.

Document reçu

Document utilisé

Document produit

DESCRIPTION DES CAS D'UTILISATION

Titre: Etablir le calendrier annuel des formations

Ce cas d'utilisation relate le processus normal de

Résumé la programmation des formations publiques

Acteurs Chef DFPI, organismes publics

•

•

Règles de gestion et d'organisation

Tous les organismes publics et leurs

démembrements sont informés à travers les

lettres d'information;

Le DFPI grâce à la réponse des différents

organismes et suivant les informations

antérieures existantes, établit son planning

de l'année en cours. Cela dans le souci

d'étendre au maximum les formations.

Lettre de réponse des organismes

Lettre de réponse des organismes

Calendrier des formations

Titre: Effectuer une demande de formation

Résumé

Acteurs

Actions

0 Demande de formation adressée au DELGI ;

0 Réception de la demande au secrétariat du

cabinet du DELGI ;

0 Vérification formelle de la demande puis

transmission au DELGI ;

0 Appréciation du DELGI ;

0 Imputation de la demande au DFPI.

Document reçu

Document utilisé

Document produit

Mise en place d'une plate forme de télé services

Ce cas d'utilisation permet aux particuliers et aux

organismes (OSC y compris) d'effectuer des

demandes de formation;

Particulier ou organismes, cabinet du DELGI


• Toute demande est préalablement soumise

à l'avis du Délégué Général;

• En général les demandes reçoivent un avis

favorable car les formations entre dans les

missions de la DELGI.

Demande de formation

Demande de formation

-

43


Titre: Programmer une session de formation exceptionnelle

Ce cas d'utilisation permet de programmer une

Résumé session de formation exceptionnelle

Acteurs Chef DFPI

Actions Règles de gestion et d'organisation

0 Réception des demandes validées par le

DELGI; • En vue de satisfaire au maximum les

0 Consultation du calendrier des formations; demandes des particuliers et des OSC, le

0 Etude de la possibilité de programmation; DFPI programme des sessions

0 Programmation de la session exceptionnelle; particulières;

0 Notification de la programmation au • Les demandes exceptionnelles des

demandeur. organismes publics concernent

généralement des modules autres que

ceux proposés par la DELGI .

Document reçu Demande manuscrite ou administrative

Document utilisé Demande manuscrite ou administrative

Document produit

Titre: Délivrer une attestation

Ce cas d'utilisation permet à la suite d'une

Résumé formation de délivrer des attestations

Acteurs DFPI, stagiaires

Actions Règles de gestion et d'organisation

0 Effectuer la formation des agents

programmés; • Les attestations sont délivrées à ceux

0 Remplissage de la liste de présence; ayant leur nom sur la liste de présence;

0 Préparation de l'attestation; preuve qu'ils ont suivi la formation;

0 Délivrance de l'attestation. • D'autre formateur sanctionne la fin de la

formation avec un examen

Document reçu

Document utilisé Liste de présence

Document produit Attestions de formation



2.2.3.2. Diagrammes de séquences

1 Demandeur de formation 1 1 cabinetDELGI 1 1 Departement DEPI 1

1 1 1 1

1

Demande de formation 11 1 1

examen de la demande

validation de la demande

imputation au DFPI

Figure 2.2.4: Diagramme de séquence 1: Processus de validation d'une demande de formation



Qrganisme public 1

1 1D~PI 1

1 1 1 1

r-e- 1 propositions de formation (calendrier des sessions) 1

1

réponses

~ établissement du calendrier des formations

lettre administrative d'information

Figure 2.2.5: Diagramme de séquence 2: Processus d'établissement du calendrier des formations

des organismes publics.



Demandeurs 1 1D~PI

1 1

Reception de la demande de formation

Consulter le calendrier de formation

Programmation de la session

Notification de la programmation

Figure 2.2.6: Diagramme de séquence 3: Processus de programmation d'une session de

formation exceptionnelle



2.2.4. PHASE 4 : DIAGNOSTIC

2.2.4.1. Faiblesses

• L'insuffisance en nombre des formateurs;

• la faible capacité d'accueil des salles de formation;

• l'absence de supports de cours (sur CD-ROM ou sur papier) accompagnant

les formations;

• l'absence de structures décentralisées pour les autres villes du pays;

• la pénible tâche de planification des sessions de formations;

• l'impossibilité d'établir de statistiques fiables par l'absence d'une base de

données.

2.2.4.2. Forces

• Les formations sont sanctionnées par des attestations;

• les matériels de formation adéquats (postes de travail performants);

• une équipe compétente et dynamique malgré le nombre réduit de

formateurs.

Mise en place d'une plate forme de téléservlces 48


2.3. PARTIE 3: LES TOP-LEVEL- BURKINA FASO

Un nom de domaine est une suite de caractères alphanumériques (A à Z, 0 à 9

avec le trait d'union) composée d'un vocable et d'une « extension» (top-Ievel)

séparée par un point. Cette suite constitue l'essentiel d'une adresse internet.

C'est le nom de domaine qui permet notamment d'identifier un site et de s'y

rendre.

Prenons une société «ab-cd»

>- L'adresse de son site web pourra être: http://www.ab-cd.bf

>- Sa messagerie électronique sera de type: [email protected]

Dans toutes ses adresses il y a une partie commune:

2.3.1. PHASE 1 : REPERAGE DU DOMAINE


La gestion des top-Ievel-Burkina Faso fait intervenir deux (2) organes essentiels:

• un organe décisionnel, la DELGI, qui est l'instance suprême de régulation

de l'informatique au Burkina Faso. Elle examine les différentes demandes

de domaine, les apprécie avant d'ordonner leur exécution;

• un organe exécutif qui est FASONET: il est chargé de mettre en application

les demandes validées par la DELGI. Ceci, conformément à son rôle de

gestionnaire du nœud national (back bon) d'accès à Internet.

Mise en place d'une plate forme de téléserviœs 49

mailto:[email protected]


La procédure est résumée sur la figure ci-dessous:

demandeur du DELGI nom de domaine

.bf Systeme de controle et

de validation de la gestionnaire

.bf demande

Figure 2.3.1 : attribution de nom de domaine .bf

L'organisation actuelle du système de gestion des noms de domaine se passe

comme suit:

Le demandeur doit remplir un formulaire disponible à la DELGI, précisément au

Secrétariat du DICIM. Une fois rempli, le formulaire est retourné au Secrétariat

Particulier du Délégué Général pour validation. A ce niveau, le Délégué Général

examine le formulaire de demande avant de le valider.

Le formulaire est après imputé au DICIM pour une seconde vérification. Cette

vérification concerne l'identité de l'organisme demandeur et est faite par le chef

DICIM. Dans le cas ou l'identité du demandeur est douteuse le demandeur est

contacté pour la confirmation de son identité (envoie des papier justificatif de

l'existence de l'organisme).

A la suite de l'identification du demandeur, le formulaire est transmis à FASONET

pour traitement final (enregistrement ou de modification).

Lorsqu'un formulaire est jugé invalide, il est rejeté puis le demandeur en est

informé des raisons de l'invalidité.

Rappelons que l'attribution des noms de domaines suit certains principes de

territorialité. La validation des demandes de domaine suit les règles qui

gouvernent les extensions des noms de domaine sur Internet, adaptés au

contexte du Burkina (voir annexe). Ses règles couvrent les aspects administratifs,

légaux et techniques des noms de domaine pouvant être enregistrés sous

extension «.bf ».

Par exemple, toute personne souhaitant enregistrer un nom de domaine sous

extension « .bf » doit posséder des droits sur le nom de domaine demandé en

justifiant d'une marque, d'une raison sociale, du récépissé de l'organisme, etc.



Dans le cas où le demandeur est un organisme de l'administration publique ou de

ses démembrements, la DELGI peut joue un double rôle. En ce sens qu'en plus

d'être l'organe décisionnel qui décidera de la validité de la demande, elle pourrait

être le FAI si l'organisme public décide d'y être hébergé.

A cet effet, l'organisme public adressera une lettre administrative de demande de

nom de domaine au Délégué Général. Celle-ci sera imputée au département DEI

où l'administrateur web de la fonction publique prendra attache avec l'organisme

public demandeur pour effectuer les formalités de demande (remplissage du

formulaire de demande de nom de domaine). L'organisme remplira les

informations administratives du formulaire (nom de domaine souhaité, références

de l'organisme, références du responsable du domaine ...) et l'administrateur web

les informations techniques (adresse ip du serveur, responsable technique du

domaine a attribué).

Le formulaire rempli est déposé par l'administrateur web au cabinet du DELGI

pour traitement déjà décrit.




cv j!!

t'li)

"Ci. E a o cv "0 c:~ III cvE .: cv.!!! "0::1

.!!!E cv.E"0 ~

c: a 'iii

'EUl

Ul c: III

~

Lettre dedemande • Demande de création/modification Autres organismesde création/modification ---.

Cabinet DELGI

c: a

.~ ~ « :5

Q.

.ê

Domaine d'etude:DICIM

c: a 'iii

'EUl

Ul c: ~ 1

FASONET (Onatel )

Figure 2.3.2 : Diagramme de collaboration




2.3.2.1. Définition des règles de gestion

RG 01: un organisme peut effectuer plusieurs demandes;

RG 02: une demande est effectuée par un et un seul organisme;

RG 03: une demande concerne un domaine;

RG 04: un domaine peut être concerné par plusieurs demandes;

RG 05 : l'organisme peut employer un prestataire;

RG 06 : un prestataire peut être employé par plusieurs organismes;

RG 07: un domaine est géré par un prestataire: l'organisme pouvant être son

propre prestataire;

RG OS: un prestataire gère plusieurs domaines;

RG 09: un domaine est sous la responsabilité d'un agent de l'organisme, le

responsable administratif;

RG 10 : un agent pouvant être le responsable administratif de plusieurs domaines

de l'organisme;

RG 11: un prestataire déclare au moins un réseau;

RG 12 : un réseau étant déclaré par un et seul prestataire;

RG 13 : un serveur pouvant identifier plusieurs domaines;

RG 14: un domaine est identifié par un serveur DNS;

RG 15: plusieurs agents techniques peuvent intervenir sur un serveur DNS.



2.3.2.2. Diagramme des classes d'entité

organisme

-num_organisme (id) -norn complet Demande_domaine -service

-num_demande (id) -forme juridique effectue

-nature_demande -pays

-date_demande-code postal

-specifications-ville 1 1.."

+valider_demande 0 ..J", -rue

+rejeter_demande()v -numero -sigle

1.." appartient

1.." t 1-1

concerne

emploie 1 ~ prestataire 1 domaine

gère-oum_prestataire (id) -num_domaine (id) -nom_prestataire -nom domaine -adresse prestataire +enregistrer()

+modifierO 1 1.'

relève1 1.." 1.."

déclare identifie

" 1.'responsable

AISeaUll agent 1 -num_reseau (id) -num_agent (id) 1.." -adresse_reseau -nom_agent

-prenom_agent -responsable administratif -service_agent Serveur DNS -fonction_agent 1.,'* 1.....

intervenir -num-serveur (id) -telephone_agent

-nom_serveur-ernall agent Agent technique -adresses IP

Figure 2.3.3 : Diagramme des classes d'entités



DESCRIPTION DETAILLEE DES CLASSES D'ENTITES

Nom

num_organisme (id)

nom complet

service

forme juridique

pays

code_postal

ville

rue

numero

sigle

Nom

-

Nom

num_agent (id)

nom_agent

prenom_agent

societe_ agent

service_ agent

fonction _ agent

telephone_ agent

email_ agent

Nom

-

Classe: organisme

Attributs

Description


Nom complet

Service

Forme juridique

Pays

Boite postale

Ville

Rue

Numéro

Sigle de l'organisme

Méthodes

Classe: agent

Attributs

Description


Nom

prénom

Société

service

Fonction occupée

Numéro téléphone

Adresse électronique

Méthodes

Type

alphanumérique

Texte

Texte

Texte

Texte

alphanumérique

Texte

Numérique

Numérique

Texte

Description

-

Type

Alphanumérique

texte

texte

texte

texte

Texte

numérique

alphanumérique

Description

-


- -

- -


Classe: demande

Attributs


num_demande (id) Numéro d'identification Alphanumérique

date_demande Date d'enregistrement date

nature_demande Nature de la demande texte

spécifications spécifications texte

Méthodes

Nom Description

valider_demande 0 Permet de valider une demande

rejeter_demande 0 Permet de rejeter une demande

Classe: prestataire

Attributs


num_prestataire (id) Numéro d'identification alphanumérique

nom_prestataire Nom complet texte

adresse_prestata ire Adresse du prestataire texte

Méthodes

Nom Description

Classe: serveur_DNS

Attributs


num_serveur (id) Numéro d'identification alphanumérique

adresse_IP Adresse IP du serveur numérique

nom_serveur Nom complet du serveur texte

Méthodes

Nom Description



Classe: reseaux

Attributs


num_reseau (id) Identifiant du réseau à déclarer alphanumérique

adresse_reseau Adresse du réseau numérique

Méthodes

Nom Description

- -

Classe: domaine

Attributs


num_domaine (id) Numéro d'identification alphanumérique

nom_domaine Nom du domaine texte

Méthodes

Nom Description

- -



2.3.3. PHASE 3 : MODELISATION DU WORKFLOW


Système

Adresserlettre de demandede

creetion/modiflcation

administrateur web (DEI)

Effectuerune demande

Organisme (autres) \ « herite»

\ Cabinetdu DELGI \

\ \

effectuerune demande \ \

\ effectuer une demande d'enregistrement de \

\ de modificationde domaine domaine \

« includ\» \

\ \

\ \ le DELGIdoit donner le chef DICMeffectueune

une appreciation de verification administrative afin la demander(validerou rejeter) authentifier l'organismedemandeur

Apprecier une avant toute autresoperatons et autresrenseignements fournis --demande la concernant avant toutetransmissionà FASONET

Verifier l'autenticltéde l'organisme

FASONET

ChefDICIM

Transmettre une demande

Figure 2.3.4 : Diagramme des cas d'utilisation



DESCRIPTION DES CAS D'UTILISATION

Titre: Adresser une lettre de demande de création/modification

Ce cas d'utilisation permet à l'organisme public

Résumé d'adresser une lettre de création/modification de

domaine

Acteurs Organisme public, Délégué Général à

l'informatique, administrateur web (DEI)

Actions Règles de gestions et d'organisations

0 L'organisme public adresse une lettre au • Cette procédure est due au fait que la

DELGI demandant l'enregistrement ou la DELGI est le FAI de l'administration

modification du domaine; publique et des ses démembrements;

0 la lettre est imputée au DEI où se trouve

l'administrateur web de l'administration

publique; • La demande une fois déposée par

0 l'administrateur web prend attache avec l'administrateur web suit la procédure de

l'organisme public en question pour qu'il traitement que les autres demandes.

remplisse les informations administratives

de la fiche de demande, lui remplit les

informations techniques;

0 La demande est ensuite déposée par

l'administrateur web au cabinet du DELGI.

Document reçu Lettre de demande de création/modification du

nom de domaine

Document utilisé Lettre de demande de création/modification du

nom de domaine

Document produit

Mise en place d'une plate forme de téléserviœs 59


Titre: Effectuer une demande

Résumé

Acteurs

Actions

0 Retrait du formulaire de demande de nom de

domaine;

0 Dépôt du formulaire dûment rempli au

cabinet du DELGI ;

0 Vérification formelle du formulaire par la

secrétaire;

0 Transmission du formulaire au DELGI ;

0 Appréciation du formulaire;

Avis favorable :

0 Imputation du formulaire au DICIM ;

Avis non favorable:

0 Rejet de la demande.

Document reçu

Document utilisé

Document produit

Ce cas d'utilisation permet à tout organisme

d'effectuer une demande de nom de domaine

Organisme demandeur, Délégué Général à

l'i nformatique


La vérification du DELGI se situe

principalement au niveau du nom de domaine

et aussi du formalisme des adresses IP du

serveur;

Les noms de domaine choisis doivent respecter

les normes de la charte de nommage ;

Les adresses IP des serveurs doivent être

conformes à la norme des adresses IP du

BURKINA FASO.

Formulaire d'enregistrement ou de modification

de domaine Internet dans la zone « .bf »


de domaine Internet dans la zone « .bf »

-


0


Titre: Vérifier l'authenticité de l'organisme

Résumé

Acteurs

Actions

0 Réception des demandes validées par le

DELGI;

0 Vérification de l'existence de l'organisme

demandeur;

Organisme existe

0 Préparation du bordereau d'envoi;

0 Transmission du bordereau d'envoi à

FASONET ;

Doute sur l'existence de l'organisme

Demande de pièce justificative de l'existence

de l'organisme au demandeur de compte.

Document reçu

Document utilisé

Document produit

Dans ce cas d'utilisation, une vérification de

l'authenticité de l'organisme demandeur est faite

au DICIM.

OICIM, FASONET


Le chef DICIM effectue un contrôle surtout

administratif à savoir vérifier l'existence de

l'organisme, l'authenticité des pièces

justificative jointes, etc.

Ce contrôle administratif permet d'éviter les

usurpations de nom de domaine dans un but

malhonnête quelconque;

Ce contrôle suit les règles de la charte de

nommage.


de domaine Internet dans la zona « .bf »


de domaine Internet dans la zona « .bf »

Bordereau d'envoi



2.3.3.2. Diagrammes de séquences

Les diagrammes de séquences présentés ci-dessous représentent les cas où les

processus (cas d'utilisation) se déroulent normalement.

Administrateur Web (DEI)Organisme Public cabinet du DELGI

r-e-

Lettre de demande de creation/modification 1 11

j

1 1 " 1 1

1 1 1,1 1 1 1 1 1 1 imputation de la lettre 1 1 1 1 1 1 1 1

,1 ..:.. 1 1 1 1 1 1

Inkrmation de la procedure à s~ivre 1 1 1 1 1 1

retrait du fonnulaire d'enregistrement ,1 '-

11

1 1 1

1 1 1 1

~--------------------- 1 1 1 1 1

4- 1 1

,1 11~ Remplissage du le formulait (1) 1 ,

1 1 1 1 1 1 1 1 1 1 1

transmission du formulaire à mo;ti~ rempli 1 ,1

1 1 1

1 1 Remplissage 1 ,1 du formulaire (2)1 ~

11 11 1 1 1 transmission formulaire, 1 1 11 1

Figure 2.3.5 : Diagramme de séquence 1 : Processus de demande de création/modification de

nom de domaine d'un organisme public



Organisme demandeur Cabinet du DELGI 1 DICIM 1

1 1 1 1 1 1 1 1 1

r-e- I Retrait du formulaire 1

1

1 1

~ --- - - - -- --- - - -- --- - - ---- - - ----- -- -:-1

- - - -- - - --- - --- -- - -- - - - ----- - --- - --1

1 1 u, 1 1 1

Dépôt du formulaire dûment rempli 1 1

1

D Appréciation 1 1 1 1

Imputation au DICIM 11

1 /'

~

1 1

, 1 1

,1 1 1

'

Figure 2.3.6 : Diagramme de séquence 2 : Processus de demande de création/modification de

domaine d'un autre organisme (autre que celui de l'administration publique)



ONATEL

1 DICIM 1 1 FASONET 1

11 1

1 1

1 1 1

réception du formulaire

Authentification de l'organisme

Préparation du bordereau d'envoi

transmission du bordereau

Figure 2.3.7: Diagramme de séquence 3 : Contrôler l'authenticité de l'organisme



2.3.4. PHASE 4 : DIAGNOSTIC

2.3.4.1. Faiblesses

• L'absence de suivi des demandes après la DELGI ;

• la lenteur dans les procédures de traitement et la complexité des

procédures de vérification;

• le problème d'accessibilité: par l'absence de service décentralisé ou de mise

en ligne de ce service pour éviter les longues distances à parcourir;

• le manque de statistiques fiables dues à l'absence d'une base de données.

2.3.4.2. Forces

• Un contrôle administratif rigoureux des demandes afin d'éviter d'éventuel

conflit;

• une gestion centralisée des noms de domaine regroupant les organismes

publics et privés;

• une bonne circulation de l'information depuis la DELGI jusqu'à FASONET.



CONCLUSION

L'étude de l'existant nous a permis de mieux appréhender le fonctionnement

actuel des différents services offerts par la DELGI.

L'étude de l'existant nous servira de référence dans notre prochain chapitre (Etude

des scénarii) dans l'élaboration d'une approche de solution afin de consolider les

points positifs du système et de remédier aux problèmes notés dans le but

d'obtenir les résultats attendus.



CHAPITRE III : ETUDE DES SCENARII PROPOSES

Après l'étude du système d'information existant, il nous revient de proposer des

solutions informatiques qui respectent les exigences de l'étude du système

d'information futur. Cette étude correspond à la phase 5 de notre démarche

d'analyse.

Dans ce chapitre, il s'agira de déterminer une architecture de l'application à

mettre en place, les scenarii possibles pour le système futur et de les évaluer en

terme de coûts matériel, logiciel et des besoins en ressources humaines. Par

ailleurs, une estimation des gains et des risques sera établie en vue de permettre

aux utilisateurs du futur système de voir les avantages et les inconvénients de

chacun des scenarii. Cette étude nous permettra de choisir le scénario qui

convient le mieux.

3.1. ARCHITECTURE DE L'APPLICATION

L'application à mettre en place est une application web. Et comme toute

application web, elle suit l'architecture qui lui convient le mieux: L'architecture

client/serveur à 3 niveaux (3-tiers).

L'architecture s-tters est une structure logicielle à trois niveaux partagée entre:

1. un client, c'est-à-dire l'ordinateur demandeur de ressources, équipé d'une

interface utilisateur (généralement un navigateur web) chargée de la

présentation ;

2. le serveur d'application (appelé également middleware), chargé de fournir la

ressource mais faisant appel à un autre serveur;

3. le serveur de données, fournissant au serveur d'application les données dont il

a besoin.



Clientléger:Navigateur web

NIVEAU 2 NIVEAU 3 Client léger: Navigateur web

NIVEAU 1

Figure 3.1 : Architecture 3-tiers

Dans l'architecture à trois niveaux, les applications au niveau serveur sont

délocalisées, c'est-à-dire que chaque serveur est spécialisé dans une tâche d'où

les appellations de serveur de données, serveur d'application. L'architecture à trois

niveaux permet:

• un allègement du poste de travail client ce qui permet une plus

grande flexibilité et souplesse;

• Une prise en compte de l'hétérogénéité des plates-formes (serveurs,

clients, langages, etc.) ;

• une sécurité accrue étant donné qu'elle peut être définie

indépendamment pour chaque service, et à chaque niveau;

• et enfin, une meilleure répartition de la charge entre différents

serveurs d'application.



3.2. OUTILS DE REALISATION PROPOSES

La DELGI dispose des moyens matériels et logiciels lui permettant d'assurer sa

fonction de principal fournisseur d'accès Internet des ministères et institutions

publiques. Dans le souci d'optimiser les coûts de réalisation, nous adapterons les

ressources matérielles et logicielles déjà existantes à notre étude.

3.2.1. RESSOURCES LOGICIELLES

Nous allons procéder à une étude comparative des différents logiciels qui peuvent

éventuellement être utilisés pour la mise en œuvre de nos différentes solutions.

3.2.1.1.Système de Gestion de Bases de Données

Relationnelles (SGBDR)

·Dé~igri.ation· . IncôrivénjE~hts Pdx

• Solution très courante en Ne gère pas par

hébergement public, l'intégrité référentielle, les

• Très bonne intégration transactions,

dans l'environnement

Apache/PHP, Ne gère pas les procédures

stockées, les triggers et les• OpenSource, bien que les

critères de licence soient vues, MySQL4.1 Existant

de plus en plus difficiles

à supporter, Ne gère que l'opérateur

ensembliste « UNION »,• Facilité de déploiement Ne prend pas en charge tous les et de prise en main,

types de jointures, • Plusieurs moteurs de

stockage adaptés aux Gestion des transactions quedifférentes depuis la version 4, et avecproblématiques. InnoDB qui est payante,

Très peu de richesse

fonctionnelle.



, Ava.ntages Inconvénients Prix

• Administration aisée, • Distributions fortement

• Indépendance entre les diverses liées au système

bases, facilitant l'intégration de d'exploitation,

plusieurs applications dans une • Depuis la version 2005,

même instance, plus de prise directe sur

• Une des bases les plus les tables système

performantes sous Windows en (remplacées par de vues

configuration par défaut, système),

• Frontaux et assistants très • Pas de possibilité de SQL Server

poussés (sauf pour MSDE) donner des priorités aux Existant

• Procédures stockées simples à traitements, hormis en

écrire, passant par le Workflow,

• Sous-SELECT possible dans • Pas certifié SQU, pas

clause FROM, d'intégration Java,

• Services Web. orientation C,

• Pas d'héritage de table.

, i .,... ... Avantages -x, ::IncQnV'énients Prix

Assistants performants via Oracle Gourmand en

Manager Server, possibilité de ressources vives,

gérer en interne des tâches et des - Coût prohibitif,

alarmes, Oracle n'est pas un

Gestion centralisée de plusieurs SGBDR optimisé pour

instances, de petites bases de

Réglages fins (presque TOUT est données.

paramétrable),

Accès aux données système via Oracle des vues, bien plus aisément Existant

manipulables que des procédures

stockées,

Interface utilisateur remaniée et

extrêmement riche en services

Web

- Grande portabilité, SGBD portable

sur plus de 80 plates-formes

majeures du marché.

NB :(références http://fadace.developpez.comlsqbdcmp)



3.2.1.2. Langages de programmation proposés

iOésignation

PHP

JSP

JAVA

ASP

Prix

G .ratuit

Gratuit

Gratuit

Existant

Avantages'.

- Support objet complet, -

- Nouvelle extension MySQLi

permettant de gérer les nouvelles

possibilités de MySQL 4.1 et +,

- Amélioration de la gestion des flux,

- Permet de développer tout type

d'application.

Peut se connecter à tout type de

bases de données (avec :lDBe) ;

Grand nombre d'API;

Processus léger, utilise les-

Threads ;

Programmes portables;

Bonne intégration du code Java et

du HTML.

-portabilité;

-programmation modulaire et

dynamique;

-adaptabilité dans de nombreux

domaines, autant pour le web que

pour les systèmes embarqués.

-possibilité de développer des

applications web dynamiques quelque

soit le navigateur;

-possibilité de contrôler l'interaction

entre les serveurs web et le navigateur

-

Inconvénients

PHP 5 ne dispose pas

de container,

Problème de

portabilité.

Plus gourmand en

ressources à cause de

la JVM,

Travaille en interprété

donc plus lent,

Non visibilité du code

du servlet peut

engendrer une

certaine confusion.

-nécessité d'une machine

virtuelle pour fonctionner;

-gestion de la mémoire;

-Besoin en ressources

systèmes

- nécessité d'un serveur

Microsoft (Ils),

-nécessité de Windows

2000.



3.2.1.3. Les anti-virus

La DELGI dispose d'un anti-virus « Norton Anti-virus Corporate Edition» installé

en réseau pour la protection des machines. Cet anti-virus a pour but de

protéger les données stockées sur le serveur.

Vu que notre application interagira avec une BD installée sur ce serveur, les

données seront soumises à la protection de cet anti-virus déjà efficace.

3.2.2. CARACTERISTIQUES MATERIELLES

Les caractéristiques matérielles suivantes sont communes aux différents scénarii

qui seront proposés. Elles concernent les ordinateurs et leurs périphériques

indispensables à l'utilisation de l'application à mettre en œuvre.

Pour l'utilisation de l'application, des imprimantes, des onduleurs, des micros

ordinateurs et des serveurs (serveurs de données, serveurs web et serveur

d'applications) seront requis.

Le réseau de la DELGI dispose de deux serveurs web physiques :

./ Apache, qui tourne sur un système d'exploitation REDHAT.

Les serveurs d'applications reconnaissent le PHP (Apache) et le ]SP

(TOMCAT) et le serveur de données où est installé MySQL ;

./ Ils qui utilise un système d'exploitation Windows 2000.

Le serveur d'application qui reconnaît de l'ASP et le serveur de

donnée SQL 2000.



3.3. METHODE DE CALCUL DU COUT DE REALISATION

Une estimation des coûts et délai de réalisation est plus que nécessaire afin

d'éviter les erreurs de budget et les retards de livraison, qui sont

malheureusement habituels dans l'industrie de développement logiciel.

Il existe plusieurs méthodes d'évaluation des coûts logiciels dont la méthode

COCOMO (acronyme de l'anglais Constructive Cost Model) est de loin la plus

connue. Elle permet de définir l'effort à fournir dans un développement logiciel et

la durée que ce dernier prendra en fonction des ressources allouées.

Le premier modèle COCOMO date de 1981, et a été développé par Dr. Barry

Boehm pour estimer le coût, en nombre d'Homme/Mois (HM), et le temps de

développement (TDev) d'un produit logiciel.

COCOMO est divisée en trois (3) modèles, qui affinent l'estimation en prenant en

compte de plus en plus de paramètres:

• le modèle de base effectue un simple calcul de l'effort et de la durée en

fonction du nombre d'instructions que l'application doit contenir et la

complexité de cette dernière. Une ventilation est également possible,

permettant de déterminer le temps de développement et l'effort nécessaire

pour chaque partie du cycle de développement;

• le modèle intermédiaire reprend l'effort et la durée du modèle de base, en

appliquant cette fois-ci des coefficients prenant en compte des facteurs de

coût (compétence de l'équipe, complexité de l'environnement technique,

etc) ;

• le modèle détaillé reprend les données du modèle intermédiaire en affinant

notamment les facteurs de coût en fonction de chaque phase du cycle de

développement. Ce modèle n'est véritablement nécessaire que pour de très

gros projets.



On distingue trois (3) types de projet de part la complexité de l'application à

fournir:

.. projet de mode organique: ces projets sont réalisés par une équipe de taille

relativement petite travaillant dans un environnement familier et dans un

domaine d'application connu de l'équipe. En conséquence, le surcoût dû à la

communication est faible, les membres de l'équipe savent ce qu'ils ont à

faire et le font rapidement.

.. projet de mode semi-détaché : ce mode représente un intermédiaire entre le

mode organique et le mode embarqué décrit ci-dessous. Pour les projets de

mode semi-détaché, l'équipe projet peut être composée de programmeurs

de divers niveaux d'expérience. Les membres de l'équipe ont une

expérience limitée de ce type de système. Ils peuvent êtres totalement

inexpérimentés en ce qui concerne quelques-uns des aspects du système à

développer mais pas tous.

4. projet de mode embarqué: la caractéristique d'un projet en mode embarqué

est que le système doit fonctionner sur des contraintes particulièrement

fortes. Le système à développer est une partie d'un système complexe et

fortement connecté de matériel et de logiciel, de normes et de procédures

opérationnelles. En conséquence, les modifications de spécification

destinées à contourner des problèmes logiciels sont en général impossibles

et les coûts de validation extrêmement élevés. Du fait de la nature même

de ces projets il est habituel de disposer d'ingénieurs logiciels expérimentés

dans le domaine d'application.

Les formules permettant de calculer le coût ou plus exactement l'effort requis pour

le développement du logiciel dans le modèle de base sont les suivantes :

mode organique : HM = 2,4*(KL5L) 1,05 ;

mode semi-détaché : HM =3*(KLSL) 1,12 ;

mode embarqué: HM = 3,6*(KL5L) 1,20 ;

Où : HM est le nombre d'Homme/Mois nécessaire à la réalisation du projet et KLSL

est le nombre de Kilo Lignes Sources Livrées.



Le modèle COCOMO de base permet également d'estimer le temps de

développement nécessaire au projet (TDev). Le temps de développement est le

temps requis pour terminer le projet, en supposant que les ressources requises

sont disponibles. Les équations pour les différents modes de projets sont les

suivantes:

mode organique : TDev = 2,5*(HM) 0,38 ;

mode semi-détaché : TDEV = 2,5*(HM) 0,35 ;

mode embarqué: TDEV = 2,5*(HM) 0,32.

Le nombre de personnes requises pour réaliser le projet dans cet intervalle de

temps est donc: N =HM/fDev.

Le coût total de réalisation sera dans notre cas estimé à HM*Valeur HM où Valeur

HM représente le salaire moyen d'un informaticien au Burkina Faso que nous

l'estimons à 200.000 FCFA.



3.4. DESCRIPTION DES SCENARII

L'application à mettre en œuvre devrait respecter les contraintes décrites dans le

premier chapitre «présentation du cadre d'étude et du thème ». Notre étude

consistera à mettre en place une base de données et une application web

permettant de s'y connecter via le réseau internet. La base de données sera

installée sur le serveur de données de la DELGI et l'application qui permettra de

s'y connecter sera accessible depuis le site web de la DELGI.

L'étude de l'existant révèle certaines similitudes dans les procédures actuelles des

demandes de services: les différentes demandes effectuées sont d'abord

adressées au Cabinet du Délégué Général pour validation avant imputation aux

départements concernés pour traitement.

Le système est résumé sur la figure suivante:

Acteurs

il.ActeursDecincheurs

Declencheurs

. ,If

Acteurs de DELGI traitementNiveau declslonnel

Cabinet du DELGi

DEI DICIM DFP!

(Cas de noms de domaine)

FASONET



Dans le système actuel nous remarquons trois (3) niveaux d'organisation:

./ le niveau procédure de demande (acteurs externes) ;

./ le niveau Décisionnel (Cabinet du DELGI) ;

./ le niveau Traitement (Différents départements).

Nous proposerons alors des scenarii suivants chaque niveau.

3.4.1. PROPOSITIONS DES SCENARII

3.4.1.1. Niveau procédure de demande

Scénario 1

.:. Description du scénario

Dans ce scénario, la possibilité d'effectuer des demandes en ligne est offerte à

tout demandeur de service (création de compte, enregistrement de domaine et

formation), qui pourra se connecter à la BD via l'application pour enregistrer sa

demande. Si l'enregistrement réussi, le système lui enverra un mail de

confirmation de l'enregistrement.

Ainsi dans les cas suivants les procédures se décriront comme suit:

~ GESTION DES COMPTES D'ACCES DISTANT ET DE MESSAGERIE

Tout agent de l'administration publique peut effectuer directement une demande

en ligne (création/ modification de compte). Un système d'authentification basé

sur le numéro matricule devra permettre d'identifier l'agent. L'échec de son

authentification implique le rejet de la demande.

~ GESTION DES FORMATIONS

Le programme des formations sera mis en ligne et permettra à tout internaute s'il

le désire de s'inscrire (en ligne) à un module après consultation du programme de

formation. Afin de rester fidèle à la procédure actuelle qui vise à prioriser les

agents de l'administration publique, notre système devra permettre d'identifier ses

agents par leur numéro matricule. Si l'identification échoue, le système

l'enregistre comme tout autre demandeur (particulier).



Un mail de confirmation de l'enregistrement est envoyé au demandeur à la fin de

l'inscription.

~ GESTION DES NOMS DE DOMAINE

Tout demandeur de nom de domaine devra remplir un formulaire de demande

disponible en ligne. Il devra spécifier d'abord le nom domaine puis le soumettre au

système qui procédera à la vérification de la disponibilité du nom de domaine

choisi. Si le domaine est libre, le système lui permet en ce moment de remplir le

formulaire de demande (références du responsable du domaine, références de la

structure, les informations techniques demandées) .

•:. Avantages

L'avantage principal de ce scénario réside dans l'accessibilité des services à tous

les demandeurs. En outre, il traduit fidèlement la procédure actuelle des

demandes de services offerts par la DELGI.

.:. Inconvénients

La difficulté majeure de ce scénario réside dans:

• la difficulté d'authentification des agents de l'administration publique puis

la complexité d'une éventuelle mise en œuvre de celle-ci;

• dans le cas des formations, la limitation des demandes de formations à

ceux seulement qui savent naviguer;

• une exposition plus grande du système aux diverses formes d'attaque sur

Internet.

Scénario 2

.:. Description du scénario

Dans ce scénario, il est désigné des responsables habilités à effectuer les

demandes de services en ligne auprès de la DELGI. Ses responsables ont les droits

d'accès à la BD pour enregistrer les demandes.

Les cas suivants se décriront comme suit:



~ GESTION DES COMPTES D'ACCES DI STANT ET DE MESSAGERIE

Il sera désigné dans chaque organisme public un responsable chargé des

demandes de comptes qui, seul, sera habilité à se connecter à la BD pour

enregistrer une demande.

Ainsi, tout agent désirant ouvrir un compte ou le modifier doit s'adresser au

Responsable chargé des comptes de sa structure pour être enregistré.

L'organisation de l'enregistrement des demandes relèvera de l'organisme

concerné.


- L'établissement du planning annuel

Le programme annuel des formations (modules, sessions) sera mis en ligne. Dans

chaque organisme public, il sera désigné un Responsable aux formations qui sera

habilité à inscrire les agents. L'organisation interne du choix des agents à former

révèle de la structure.

Le responsable de formation (RF) devrait spécifier l'organisme, le nombre

d'agents, les sessions et module souhaités.

Après traitement de ses informations à la DELGI, et si l'organisme est retenu pour

la formation, une notification de sa programmation lui sera envoyée. Elle précisera

les sessions, les modules et le nombre d'agents retenus ainsi que le code

d'inscription. Le RF devrait se connecter à nouveau pour inscrire les références des

agents participants. Cette inscription n'est possible qu'après authentification du

code d'inscription. Pour les agents dont le RF aurait fourni l'e-mail, le système leur

enverra une convocation pour la formation dans laquelle Ils ont été retenus

- La gestion des demandes particulières

Dans la présentation des modules et sessions en ligne, nous donnons la possibilité

aux particuliers de s'inscrire aux modules de formation sans procédure

d'authentification. Ses informations aussi seront enregistrées dans la BD mais de

façon distincte permettant leur traitement distinctement à la DELGI. La validation

de la demande d'un particulier est suivie de l'envoi d'une convocation à son

adresse mail (s'il en a).

Mise en place d'une plate forme de télésetvlces 79


- La gestion des demandes exceptionnelles

Les organismes souhaitant une formation exceptionnelle (modules autres que ceux

proposés par la DELGI) devront remplir un formulaire d'inscription des organismes

en ligne. Cette opération ne nécessite pas une authentification.

Dans le souci d'étendre la formation à un plus grand nombre de particuliers, ce

scénario ne suspend pas la procédure de demande manuscrite et administrative.

Nombreux sont les particuliers qui ne manient pas l'outil informatique. Très

généralement, les demandes reçues concernent l'initiation à l'informatique. Alors

la mise en ligne uniquement des procédures de demande manquerait son but

(public cible).

Pour ce faire, dans le scénario, les demandes manuscrites ou administratives

reçues seront enregistrées dans la BD par un agent de saisie et subiront les

mêmes procédures de traitements.


Toute personne ou tout organisme souhaitant obtenir un nom de domaine devra

s'adresser à un prestataire (ou à un autre organisme disposant d'une ligne

spécialisée) enregistré à la DELGI. Seuls ces derniers seront habilités à effectuer

les demandes d'enregistrement de domaine.

Dans son rôle de prestataire de la fonction publique, le DEI également sera

habilité à effectuer les demandes de noms de domaine pour les organismes

publics.

La possibilité sera offerte au demandeur de vérifier la disponibilité d'un nom de

domaine avant d'effectuer une demande d'enregistrement.

•:. Avantages

Ce scénario a l'avantage de responsabiliser les procédures de demandes de

services. Il permet également:

- une meilleure organisation des procédures de demande;

- une conservation de la hiérarchie dans la circulation de l'information;

- de pallier à la complexité de la mise en œuvre des validations des

demandes de compte au niveau de l'organisme du demandeur.



.:. Inconvénients

La difficulté majeure de ce scénario réside dans l'information des acteurs

concernés de la nouvelle procédure de demande.

3.4.1.2. Niveau Décisionnel

Au niveau décisionnel, les procédures de validation demeurent inchangées. Les

demandes effectuées en ligne subiront une double validation à savoir la validation

de la secrétaire du DELGI et celle du DELGI.

La procédure se décrit comme suit:

) Validation de la secrétaire du DELGI (première validation): les demandes

enregistrées dans la BD par les acteurs externes seront d'abord validées par la

secrétaire du DELGI. Celle ci, du fait de sa position, a alors un rôle de première

validation car dans le système présent elle contrôle toutes les arrivées et

départs du courrier de la DELGI suivant le principe protocolaire (toute demande

adressée à la DELGI devra transiter d'abord par l'instance supérieure de la

structure). Elle aura la charge de vérifier l'intégrité des informations fournies et

de soumettre la demande au DELGI.

) Validation du DELGI (seconde validation) : le système alertera le DELGI de

l'arrivée d'une demande pour appréciation. Après examen, le DELGI validera la

demande à son tour pour traitement. Cette validation confirme la valeur des

informations fournies par le demandeur donc autorise le traitement demandé.

Le système alertera le chef du département concerné de l'arrivée d'une

demande pour traitement.

3.4.1.3. Niveau de Traitement

La procédure des traitements des demandes reste inchangée. Les demandes

seront accessibles par le département de traitement concerné juste après

validation du cabinet du DELGI. Le visa du cabinet du DELGI autorise le traitement

de la demande.

Ainsi les procédures se décriront comme suit:



~ GESTION DES COMPTES D'ACCES DISTANT ET DE MESSAGERIE

Après validation du DELGI, le système alertera le chef du DICIM de l'arrivée d'une

demande de compte pour traitement. Le chef DICIM après constatation validera la

demande pour création/modification. Cette validation donne l'autorisation à l'agent

de création de créer/modifier le compte. L'agent, après création du compte, devra

fournir au système les informations complémentaires du compte créé/modifié (le

nom du compte, l'adresse électronique et le mot de passe de première

connexion). Le Système éditera une notification comportant ses informations qui

sera envoyé au Responsable des demandes de compte mais aussi à l'agent

demandeur si son e-mail a été fourni sur la demande.


Dans ce le cas de la formation, la tâche principale à effectuer est l'établissement

du planning. Cette tâche, faite par le chef DFPI, et grâce à une interface

appropriée permettra à ce dernier d'établir le planning directement en consultant

les demandes faites en ligne. En cas de programmation d'un organisme ou d'un

particulier, le système envoie une convocation pour la date programmée. Dans le

cas des demandes exceptionnelles qui sont validées par le DELGI, la

programmation du demandeur entraînera une mise à jour du calendrier déjà

établi.


Dans le traitement des noms de domaine, le chef DICIM doit vérifier l'identité du

demandeur avant la validation finale au niveau de la DELGI. Le système alertera

les agents de création de nom de domaine au niveau de FASONET de l'arrivée

d'une demande de création/modification de domaine. Après la

création/modification du domaine, les acteurs de création devraient valider la 1

demande pour que le domaine soit pris en compte comme existant. Le système

enverra une notification de la création du domaine à l'adresse e-mail indiquée sur 1 la demande (prestataire, demandeur).

l 1

1

1

3.4.2. SCENARIO RETENU

Au vu de certains inconvénients révélés dans le premier scénario au niveau

« procédure de demande» à savoir la complexité d'authentification des agents de



l'administration publique, la limitation des demandes de formation à seulement

ceux savant naviguer, etc. le choix du groupe de pilotage s'est porté sur le

deuxième scénario (scénario 2). Ce choix se justifie principalement du fait de la

responsabilisation des procédures de demandes.

Ainsi, le scénario final à mettre en œuvre, se décrit comme suit:

- la désignation des responsables habilités à effectuer les demandes;

- la double validation au cabinet du DELGI ;

- le traitement suivant la procédure actuelle dans les départements

concernés.



3.4.3. ARCHITECTURE DU SCENARIO RETENU

DELGI

Organisme PUBLIC

DICIM

DEI

,} ~j

PRESTATAIRE



3.5. OUTILS DE REALISATION RETENUS

3.5.1. CONFIGURATION MATERIELLE REQUISE

L'organisme dispose déjà d'un réseau avec des serveurs (web, applications,

données) de grande capacité et de matériels suffisants pour la mise en œuvre de

l'application. L'utilisateur n'aura besoin que d'un micro ayant un navigateur et

d'une connexion à Internet pour son exploitation.

Cependant l'acquisition d'une imprimante et d'un onduleur de grande puissance

sera un atout dans l'exploitation du système.

3.5.2. LOGICIELS RETENUS

3.5.2.1. Les logiciels de développement

Au vu des logiciels de développement proposés et de leur disponibilité dans la

structure d'accueil, au vu des avantages et inconvénients que présente chacun

d'eux, le choix du groupe de pilotage s'est porté sur les logiciels suivants:

.:. Système de gestion de Base de données choisi: MySQL, du fait d'abord de

sa disponibilité dans la structure puis des avantages qu'il offre;

.:. Langage de développement: JSP, du fait de sa disponibilité et sa facilité de

déploiement. En outre le JSP intègre très bien le code JAVA, Langage

orienté objet.

3.6. EVALUATION DES COUTS

3.6.1. COUT DES OUTILS DE REALISATION

La DELGI ne supportera pas de coût matériel et de coût d'outils de réalisation du

fait de leur existence dans la structure. Elle dispose déjà d'un serveur de données

où est installé le SGBDR MySQL et d'un serveur d'application où est installé

Apache TOMCAT qui interprète le code JSP. Aucune charge matérielle et logicielle

ne sera de ce fait supportée par la structure.



3.6.2. COUT DE DEVELOPPEMENT

Pour l'évaluation du coût de développement de l'application à mettre en œuvre,

les formules du mode semi-détaché s'adaptent le mieux. Nous aurons alors:

HM =3*(KLSL) 1,12 ;

TDev = 2,5*(HM) 0,35 ;

Coût total = HM*Valeur HM.

Nous avons subdivisé l'application en trois grands modules suivant les sous

thèmes et nous estimons à 4000 le nombre de lignes du code source de chaque

module.

Par application des valeurs approximatives, nous aurons:

HM = 3*(3*4000/1000) 1,12 = 48.50 HlM

TDev =2,5*(48,50)0,35 =9,72 Mois -10 Mois

Coût total = 48.50*200.000 = 9.700.000 FCFA

3.6.3. COUT DE FORMATION

Nous avons évalué les coûts de formation des utilisateurs à une somme forfaitaire

de 25.000 FCFA par jour sur une période de 40 jours. Soit 1.000.000 FCFA pour

les formations.

3.6.4. COUT TOTAL DE LA MISE EN ŒUVRE

Coût matériel à acquérir a Coût logiciel à acquérir a

Coût de développement 9.700.000

Coût de la formation 1.000.000

Coût total 10.700.000



3.7. SCENARIO DE MISE EN ŒUVRE GENERAL

La mise en œuvre des solutions proposées se fera comme suit:

• le développement de l'application;

• l'installation de l'application;

• la formation des utilisateurs;

• le test du nouveau produit;

• la récupération des données existantes;

• la mise en exploitation de l'application.



CONCLUSION

Dans ce chapitre, nous avons présenté les solutions envisagées pour pallier aux

insuffisances du système existant en tenant compte des contraintes (financières,

humaines, et organisationnelles) exprimées par le groupe de pilotage et des

utilisateurs.. Nous pouvons maintenant entamer l'étape la plus importante de

notre étude, à savoir la «reconfiguration et la modélisation du futur système

d'information ».



CHAPITRE IV: RECONFIGURATION ET MODELISATION DU

SYSTEME D'INFORMATION

L'étude du système existant faite précédemment au chapitre 1 nous a permis de

déceler dans son fonctionnement, un certain nombre d'insuffisances, mais aussi

certaines forces. Il s'avère donc nécessaire de pallier aux insuffisances constatées

et de consolider les forces en proposant un système de fonctionnement tel qu'il est

perçu par les utilisateurs et conformément à la solution qui a été retenue au

chapitre précédent (Etude des scénarii proposés).

La reconfiguration et la modélisation du système d'information par la démarche

UML présentée au chapitre 1 se réalise grâce aux phases 5 (reconfiguration du

système d'information) et 6 (modélisation du futur système d'information). Pour

ce faire nous procéderons à des modifications et des ajouts au système actuel afin

d'améliorer son fonctionnement, puis nous modéliserons le futur système.

4.1. PHASE 5 : RECONFIGURATION DU SYSTEME D'INFORMATION

Nous proposerons des orientations répondant aux problèmes soulevés lors du

diagnostic de l'existant. La reconfiguration du futur système vise cinq (05) grands

objectifs:

~ améliorer les échanges d'informations

Les échanges d'informations seront automatisés en ce sens que:

• les acteurs principaux (demandeurs de services) ne seront plus

contraints de se déplacer pour effectuer les demandes: ils

pourront remplir les formulaires de demande directement en

ligne;

• les acteurs secondaires (ceux qui effectuent les traitements ou qui

y participent) n'auront plus besoin de se déplacer pour

transmettre les demandes: une possibilité leur est offerte de les

faire à partir d'Internet et même d'effectuer certains traitements.



• intégration des acteurs:

o «Internaute»: pour désigner ceux qui peuvent exploiter

les fonctionnalités premières du système

o «Agent de saisie»: pour permettre d'ajouter des

demandes de service en « offline » (ceux qui auront choisi

de s'inscrire selon le mode classique).

~ régénération des processus

Regroupement des processus «enregistrer une demande» et «valider des

demandes» ;

~ ouvrir le système

Le système futur rendra plus accessible les services offerts par la DELGI aux

internautes car il devra fonctionner sur Internet. Ce qui occasionne du même

coup l'ouverture du système au monde, son rapprochement au public et la facilité

d'acquisition des services proposés.

~ renforcer le pilotage

Un système d'alerte sera mis en place afin de prévenir les différents acteurs de

l'arrivée des demandes pour traitement. .

Un système de notification sera également mis en place pour informer les

demandeurs de service du statut de leurs demandes.

Les demandeurs particuliers pourront s'inscrire directement aux formations: étant

donné que leurs demandes ne sont jamais refusées, elles ne feront l'objet plus

l'objet d'une validation par le Cabinet du Délégué Général dans le futur système.

Elles seront désormais adressées au Chef DFPI pour programmation.

~ prise en compte des contraintes

Le futur système devra prendre en compte l'existence du réseau local et du site

web de la DELGI (http://www.delgi.gov.bf).

Il ne devra pas substituer le système actuel mais venir renforcer le

fonctionnement de celui-ci. De ce fait, il devra fonctionner en parallèle avec le

système actuel.



4.2. PHASE 6 : MODELISATION DU FUTUR SYSTEME

L'objectif de cette phase est de modéliser les différentes facettes du système

d'information en s'appuyant sur les principes et les règles arrêtés à la phase

précédente.

4.2.1. DIAGRAMME DE COLLABORATION

"Responsable des formations 'cabinet du DELGI

c:

:;o

E .e Q)

't:l Q)

-g III E Q)

Cl

+ projet- Plate fOrme de teleservice

t E oc: Q)

't:l

'E Q)

Q) CIl

E Q)c:

e.5 8. Q)

-.!!! IIIE 0:: 01 0~'t:l c: Q)

.Q) 't:l 't:l Q)

't:l"Responsable des comptes c: III E Q)

Cl

Figure4.1 : diagramme de collaboration



4.2.2. DIAGRAMME DES CAS D'UTILISATION

a. Les acteurs de notre système et leur rôle

.:. Les acteurs principaux (ceux qui exploitent directement les fonctionnalités

principales du système)

• L'internaute, il peut:

-/ consulter l'aide générale d'utilisation des téléservices ;

-/ consulter les modules et les sessions de formation proposés;

-/ consulter la liste des prestataires (organismes habilités à effectuer

les demandes d'enregistrement de domaine) enregistrés à la

DELGI;

-/ vérifier la disponibilité d'un nom de domaine;

-/ s'inscrire à une formation.

• Responsable des demandes de compte (Re)

C'est la personne, désignée par l'organisme public et possédant un droit

d'accès à la BD pour effectuer les demandes de compte pour les agents. Les

opérations du RC sont supposées être faites par l'organisme dont il relève.

Ses principales opérations sont:

Enregistrer un agent de son organisme souhaitant avoir un

compte d'accès distant et de messagerie mais en

s'authentifiant;

Consulter la liste des agents de son organisme ayant un

compte;

• Responsable de formation (RF)

Le RF a les mêmes responsabilités que le RC. II s'occupe des demandes de

formation des agents de son organisme. Il peut:

- Postuler à un module de formation en précisant le module, la

session et le nombre d'agents) ;

Inscrire des agents à une session;

- Consulter la liste des agents de son organisme participant à une

formation donnée.



• Prestataire

Le prestataire est celui habilité à effectuer les demandes de domaine. Le

prestataire peut être toute autre structure possédant une LS et enregistrée

à la DELGI comme ayant les droits de demandes de domaine. Ses

opérations principales sont:

- Enregistrer une demande de nom de domaine pour un organisme;

- Consulter les domaines dont il a la charge .

•:. Les acteurs secondaires du système (ceux qui effectuent les tâches

administratives)

• Cabinet du DELGI

11 se compose de la secrétaire particulière et du DELGI. C'est l'organe

décisionnel chargé de la validation des demandes. En outre, il peut éditer

ou consulter des listes dans la BD (liste des comptes créés, liste des

domaines enregistrés, liste des participant à une formation);

• Agent de saisie (agent du DFPI)

L'agent de saisie est chargé d'enregistrer les demandes manuscrites des

particuliers ou administratives des organismes dans la BD.

• Chef DICIM

Sa tâche est située après la validation des demandes par le DELGI. Il a un

rôle de deuxième validation sur les demandes du fait de sa position. Ses

principales opérations sont:

o Dans la procédure de demande de nom de domaine:

- Vérifier l'identité du demandeur du domaine;

- Deuxième validation des demandes: cette action autorise le

traitement final des demandes par FASOI'JET ;

- Editer des notifications aux demandeurs en cas de besoin de

justificatifs sur l'existence de la structure demandeur.

o Dans la procédure de demande de compte:

Deuxième validation des demandes de compte: cette action autorise la

création/modification du compte par l'agent de création;

o Editer des états pour impression.



• Chef DFPI

II est chargé de la gestion des formations. Ses opérations principales sont:

- mettre en ligne le programme de formation (module et session

- valider les demandes de formations; cette action implique la

programmation du demandeur de formation (organisme public et

particulier) ;

- programmer une session de formation à titre exceptionnel. Cette action

précède la validation de la demande par le DELGI. (cas d'une demande

exceptionnelle de formation) ;

- éditer des attestations.

• Agent de création de compte, il peut:

- consulter les demandes de compte validées par le chef DICIM pour la

création/modification du compte sur le serveur;

- enregistrer le compte créé, l'adresse électronique et fournir (dans le

cas d'une création) le mot de passe de première connexion.

• FASONET, il peut:

- consulter les demandes de nom de domaine validées par la DELGI

pour l'enregistrement/ modification;

- confirmer l'enregistrement/modification du domaine.

• Administrateur du système

Il a tous les droits d'accès dans le système. 11 est chargé de la maintenance

du système. Il :

- administre le système;

- octroie les droits d'accès au système.

NB : une nuance doit être faite entre « Enregistrer une demande» et « s'inscrire

à un module» dans la rubrique de la formation (action faite par les acteurs

externes). En général, une demande comme décrite dans notre système est

soumise à l'appréciation du DELGI. Cependant une inscription est directement

traitée dans le DFPI.

Mise en ptece d'une plate forme de téléservices 94


Système

consulter informations enligne

Internaute

S'inscrire à un module deformation

Particulier

«hent

OSC

Postuler à un module deformation

Inscrire unagent à une session

Valider desCabinet du DELGI demandes

,, «eiltend»,,

Vénfierla disponibilité d'un domaine

Effectuer une demande deservice reservée

Enregistrer une demande denom dedomaine

Consulter des listes

Editer des listings

Consulter laliste des prestataires/structures

enegistrer une demande manuscrite/administrative

«hente» Agent de saisie (DFPI)

Enregistrer une demande decompte

Consulter liste des agents deson organisme ayant

uncompte

nte J

Consulter liste des domaine dont il aen

charge

cette validation marque l'approbation duDELGI pour ietraitement dela demande



lesdemandes validées parle DELGI doivent comporter leVISA duchef DICIM avant laaeationdu Autoriser la compte surleserveur parcréation/modification descomptes l'agent decreation

,

'«~~~~:: ~----Mise à jourdes comptes créés

Agenl chargé dela ChefDICIM Creaion/mofication

descomptes

Enregistrer nomducompte Enregistrer leset lesparamétres depremiére

mises à joureffectuéesconnexion

Confirmer l'identité dudemandeur dedomaine

LechefDICIM devratt verifier rexistence de --l'organisme dudemandeur avant laaéation dunom dedomaine à FASONET

Confirmer l'enregistrement dudomaine

Mettre à jour le FASONET programme deformation

Mettre enligne les modules deformation Octroyer les

droits d'aeees

Valider une inscription

Etablir lecaiendrier defOlTTlation(planning)

Programmer unorganisme public à unmodule de

Programmer ia formation d'un formalion Administrateurorganisme ayant faitune Dusystemedemande particuliere

«incl~de » \ \

Edilerune Administrer lenotification systeme

Editer des attestations

Figure 4.2 : Diagramme des cas d'utilisation

NB : Pour une meilleure lisibilité du diagramme et pour sa bonne compréhension, nous n'avons pas

représenté le CU «authentifier l'utilisateur », En effet, ce CU est utilisé par les autres qui sont

représentés ci-dessus puisque l'utilisation du système sera conditionnée par une authentification. Il

est donc relié aux autres par la relation « include »,


----


Description textuelle des cas d'utilisations

Titre

Résumé

Acteurs

Date de création

Version

Scénario nominal

Scénario alternatif

Titre

Résumé

Acteurs

Date de création

Version

Scénario nominal


Authentifier l'utilisateur

Ce CU permet d'authentifier toute personne voulant se connecter à la

BD

Utilisateur, système d'information (SI)

20 sept 2006

V 1.0

DEBUT

1- L'utilisateur demande à s'authentifier;

2- Le SI affiche l'interface d'authentification;

3- L'utilisateur saisie ses références;

4- Le SI vérifie la validité des références saisies;

5- Le SI affiche les opérations autorisées pour l'utilisateur (Al).

FIN

(Al) : références non valides

Ce scénario commence au point 4 du scénario nominal

6- Le SI indique que les références saisies ne sont pas valides. Le

scénario reprend au point 2 du scénario nominal

Consulter Informations en ligne

Ce CU permet aux Internautes de consulter les informations en ligne

(aide d'utilisation, description des procédures à suivre...)

Internaute, système d'information (SI)

20 sept 2006

V 1.0

DEBUT

1- L'internaute accède via le site de la DELGI à la page d'accueil du

système;

2- Le système lui affiche le menu général;

3- L'internaute sélectionne dans le menu la rubrique de son choix;

4- Le système charge la page concernée avec les informations

nécessaires;

5- L'internaute demande une opération offerte par le système (vérifier

la disponibilité du nom de domaine par exemple) ;

6- Le système effectue l'opération demandée et lui affiche les résultats.

FIN



Titre Enregistrer une demande de formation sans authentification

Résumé Ce CU permet aux particuliers et autres organismes d'effectuer les

demandes de formation

Acteurs Demandeur->DF (Particulier ou OSC), système d'information (SI)

Date de création 20 sept 2006

Version V 1.0

DEBUT

Dans la rubrique «formation », le SI affiche le programme de

formation;

1 Le DF sélectionne l'option d'inscription de son choix (inscription

>particulierjinscription->organisme) ;

2 Le SI affiche le formulaire d'inscription associé à l'option choisie;

Scénario nominal 3 Le DF fournit les informations demandées puis valide;

4 Le SI vérifie les informations fournies; (Al)

5 Le SI affiche les informations fournies et la page de confirmation;

6 Le SI affiche le formulaire de confirmation (l'intéressé doit saisir un

code sur une image affichée afin de vérifier que la procédure n'est

pas effectuée par un programme quelconque) ;

7 Le DF saisit le code de confirmation puis valide; (A2)

8 Le SI vérifie l'authenticité du code de confirmation fourni ;(A3)

9 Le SI enregistre les informations fournies dans la BD ;

10- Le SI envoie un mail de confirmation de la réussite son inscription à

l'adresse électronique de convocation fournie.

FIN

(Al) : informations fournies incorrectes ou incomplètes


Scénario alternatif 5 Le SI renvoie le formulaire d'inscription avec un message d'erreur

(informations fournies non valides ou incomplètes)

Le scénario reprend au point 3 du scénario nominal

(A2) : le DF choisit de modifier


8- le SI affiche le formulaire avec les informations fournies au préalable


(A3) : code fourni invalide


10-le SI affiche à nouveau la page de confirmation avec un autre code

de confirmation sur une image

le scénario reprend au point 6 du scénario nominal



Titre Effectuer une demande de service réservée en ligne

Résumé Ce cas d'utilisation permet aux différents responsables d'effectuer des

demandes de service (nom de domaine, compte, postuler à un module

de formation) mais en s'authentifiant

Acteurs Différents responsables (RC, RF, Prestataire), système Informatique

(SI)


Version V 1.0

DEBUT

1 Le Responsable choisit la rubrique de son choix;

2 Le SI affiche la page d'accueil de la rubrique choisie;

3 Le Responsable sélectionne « connexion» ;

4 Inclusion du cas d'utilisation « Authentifier l'utilisateur» ;

5 Le SI affiche le formulaire associé à la rubrique choisie

6 Le Responsable fournit les informations demandées;

Scénario nominal 7 Le Responsable valide les informations fournies;

8 Le SI vérifie les informations fournies; (Al)

9 Le SI affiche la page de confirmation;

10- Le Responsable saisit le code de confirmation puis valide;

11- Le SI authentifie le code de confirmation; (A2)

12- Le SI enregistre les informations fournies dans la BD ;

13- Le SI envoie un mail de confirmation de la réussite de

l'enregistrement de la demande à l'adresse électronique du

responsable;

14- Le SI affiche à nouveau le formulaire de demande en ligne;

FIN

(Al) : données du formulaire non complètes


9- Le SI réaffiche le formulaire remplit avec un message d'erreur

(<< informations incomplètes ») et des marques indiquant les

Scénario alternatif informations manquantes.


(A2): code fourni invalide


11- le SI réaffiche la page de confirmation avec un autre code de

confirmation sur une image


FIN

Mise en place d'une plate forme de télésetvices 99


Titre Valider des demandes

Résumé Ce cas d'utilisation permet de marquer l'approbation du DELGI sur les

demandes

Acteurs Cabinet du DELGI (Secrétaire->SD, le DELGI),

Système Informatique (SI)


Version V 1.0

DEBUT

1 Le SI alerte la secrétaire de l'arrivée d'une demande faite en ligne;

2 La secrétaire demande au SI à s'authentifier

3 Inclusion du CU « authentifier l'utilisateur» ;

4 La 5D examine l'intégrité des informations fournies;

Scénario nominal 5 La 5D valide (première validation) le formulaire; (Al)

6 Le SI fait une mise à jour des informations de la demande (marquer la

demande comme validée par la 5D)

7 Le SI charge la demande suivante à traiter;

B- Le SI alerte le DELGI de l'arrivée d'une nouvelle demande;

9 Le DELGI demande à s'authentifier;

10- Inclusion du cas d'utilisation « Authentifier l'utilisateur» ;

11- Le SI affiche la demande validée par la 5D ;

12- Le DELGI examine la demande;

13- Le DELGI valide la demande ;(A2)

14- Le SI effectue la mise à jour des informations de la demande;

15- Le SI charge la demande suivante validée par la 5D ;

FIN

(Al) : la secrétaire ne valide pas la demande;


5- la 5D invalide la demande;

6- le SI affiche l'interface de saisie du rapport d'erreur;

7- la 5D fournit les raisons de l'invalidation;

Scénario alternatif B- le SI prépare le rapport d'erreur;

9-le SI affiche un aperçu du rapport puis demande la confirmation de l'envoi;

10- la 5D confirme l'envoi;

11-le SI envoie le rapport;

12- le SI charge la demande suivante;

(A2) : le DELGI ne valide pas la demande;


12- Le DELGI invalide la demande;

13- le SI affiche l'interface de saisie du rapport d'erreur;

14-le DELGI fournit les raisons de l'invalidité puis valide;

ls-le SI prépare le rapport d'erreur;

16-le SI alerte la 5D de l'invalidation du formulaire;

Le scénario reprend au 9 du scénario alternatif (Al)

FIN



Titre Consulter des listes

Résumé Ce CU permet aux utilisateurs ayant les droits d'accès aux listes d'éditer

des états pour impression.

Acteurs Cabinet du DELGI, Responsables (formation, compte), Prestataires (et

autres structures habilitées), système d'information (SI)


Version V 1.0

DEBUT

1 L'utilisateur demande à s'authentifier;

2 Inclusion du CU « Authentifier l'utilisateur» ;

Scénario nominal 3 Le SI affiche l'interface de travail correspondant au profil de

l'utilisateur;

4 L'utilisateur sélectionne l'option « consultation» ;

5 Le SI affiche les listes accessibles à son profil;

6 L'utilisateur choisit l'élément à consulter;

7 Le SI affiche les informations sur l'élément choisi.

FIN

Scénario alternatif --



Titre Autoriser la création/ modification du compte

Résumé Ce CU permet à l'agent de création de compte, avec l'accord du chef

DICIM de créer/modifier le compte sur le serveur et d'enregistrer le

compte créé ou d'effectuer la mise à jour du compte dans le système

Acteurs Chef DICIM (DICIM), L'agent chargé de la création des comptes (agent),

système informatique (SI)


Version V 1.0

DEBUT

1 Le SI alerte DICIM de l'arrivée d'une nouvelle demande de compte

validée par le DELGI ;


3 Le SI affiche la demande validée par le DELGI ;

4 DICIM sélectionne l'option « à créer» dans les options offertes par le

SI ;

5 Le SI marque la demande du VISA du chef DICIM ;

6 Le SI alerte l'agent de création de la présence de demandes validées

Scénario nominal pour création/modification;


8 Le SI affiche les demandes comportant le VISA du chef DICIM ;

9 Après création/modification du compte, l'agent demande au système à

enregistrer le compte créé/modifié;

10- Le SI affiche l'interface d'enregistrement des comptes et autres

paramètres;

11- L'agent saisit le nom du compte créé et dans le cas de la création

fournit le mot de passe de première connexion puis valide;

12- Le SI lui demande de confirmer les données saisies;

13- L'agent confirme les données saisies; (Al)

14- Le SI enregistre le nom du compte créé/enregistre les mises à jour

faites;

15- Le SI envoie une notification par mail (comportant le nom du compte,

l'adresse électronique et le mot de passe de première connexion) de la

création du compte au responsable des demandes de compte.

16- Le SI (dans le cas ou le bénéficiaire a un mail alternatif) lui envoie

aussi un exemplaire de la notification

FIN

(Al) : l'agent ne confirme pas les informations saisies


Scénario alternatif 13- l'agent demande à annuler ses informations;

14- le SI annule les données saisies;


FIN



Confirmer l'identité du demandeur de domaine

Ce CUpe~~:~.~~c~erqIcM après vérification de l'identité du demandeur

validen(vaHdation finale à la D.ELGI) les demandes pour la

·\·1~~~ètion/modific~h6n du domaine

(QJCIM),··FASONET,.système.inform.atique(SI)

V 1.0

DEBUT

1- Le SI alerte DICIM de l'arrivée d'une nouvelle demande de nom de

domaine validée par le cabinet du DELGI ;

2- Inclusion du cas d'utilisation « Authentifier l'utilisateur» ;

3- Le SI affiche la demande de nom de domaine validé par le DELGI ;

4- Après vérification de l'identité du demandeur, le chef DICIM valide la

demande en guise de la confirmation de l'identité du demandeur (Al)

5- Le SI effectue la mise à jour de la demande;

6- Le SI alerte l'agent de FASONET (acteur de l'enregistrement du nom

de domaine) de la présence de demandes validées par la DELGI ;

7- FASONET demande à s'authentifier;

Scénario nominal 8- Inclusion du cas d'utilisation « Authentifier l'utilisateur» ;

9- Le SI affiche la demande d'enregistrement de nom domaine validée

par la DELGI ;

10- Après enregistrement/modification du nom de domaine, FASONET

valide les demandes (cela suppose que le nom de domaine est

enregistré) ;

11- Le SI effectue la mise à jour des informations de la demande;

12- Le SI envoie un mail de notification de l'enregistrement du nom de

domaine au prestataire et au demandeur du domaine (s'il a fournie un

mail alternatif)

FIN

(Al) : le chef DICIM invalide la demande;

Cela suppose que l'identité de l'organisme demandeur est douteuse.


4- le chef DICIM invalide la demande; Scénario alternatif 5- le SI envoie une notification et au prestataire et au demandeur;

Si le demandeur réagis en envoyant les justificatifs demandés le scénario

reprend au point 4 du scénario nominal

FIN



Titre Mettre à jour le programme de formation

Résumé Ce scénario permet au chef DFPI de mettre à jour le programme annuel de

formation

Acteurs Chef DFPI, système d'information (SI)


Version V 1.0

DEBUT


2 Le SI affiche le menu de la rubrique formation réservé à son profil;

Scénario nominal 3 Le chef DFPI sélectionne l'option « mise à jour» dans le menu;

4 Le SI affiche l'interface de mise à jour des modules et sessions;

5 Le chef DFPI effectue la mise à jour (ajouter, modifier...) les modules

et sessions;

6 Le SI enregistre progressivement les mises à jour faites puis demande

de confirmer la mise en ligne;

7 Le chef DFPI confirme la mise en ligne ;(Al)

8 Le SI marque les informations à mettre en ligne dans la BD ;

9 Le SI affiche à la fin des différentes mises à jour (en guise d'aperçu) la

page des modules et sessions offerts

FIN

(Al) : le chef DFPI ne confirme pas la mise en ligne


Scénario alternatif 7- Le SI enregistre les informations, mais ne les marque pas pour la mise

en ligne.


FIN



Titre Etablir le calendrier de formation (planning)

Résumé Ce CU permet au chef DFPI d'établir le calendrier de formation

Acteurs Chef DFPI, système d'information (SI), Responsable de Formation (RF),

organisme privé, particulier


Version V 1.0

DEBUT



3 Le chef DFPI sélectionne l'option « Programmation» dans le menu;

4 Le SI affiche l'interface de l'application réservé à la programmation

des formations;

5 Le chef DFPI consulte la liste des inscrits (particuliers) et des

organismes publics ayant postulé à un module de formation;

Dans le cas des particuliers.

6 le Chef DFPI valide leur inscription à un module dans une session

quelconque;

7 Le SI leur envoie un mail de convocation pour la date de la session

Scénario nominal choisie;

Dans le cas des organismes publics

8 Le Chef DFPI choisit les organismes retenus,

9 Chef DFPI demande l'édition d'une notification de confirmation de leur

inscription à une session d'un module;

10- Le SI affiche l'interface d'édition de notification;

11- Chef DFPI précise le nombre d'agents retenu puis confirme l'envoi de

la notification ;

12- Le SI génère un code d'inscription correspondant au nombre d'agents

retenu;

13- Le SI envoie la notification avec le code d'inscription;

Dans le cas des organismes privés

14 Le chef DFPI consulte les demandes exceptionnelles validées par le

DELGI ;

15- Le chef DFPI étudie de la possibilité de programmation;

16- Le chef DFPI programme l'organisme demandeur;

17- Le SI envoie une notification à l'organisme programmé;

FIN




Titre Inscrire les agents à une session

Résumé Ce CU permet au responsable de formation d'inscrire les agents de

son organisme à une session après que son organisme soit retenu

pour la formation

Acteurs Responsable de formation (RF), système informatique (SI)


Version V 1.0

DEBUT

1 Le RF demande à s'authentifier;

2 Inclusion du CU « authentifier l'utilisateur» ;

3 Le RF demande le formulaire d'inscription des agents;

4 Le SI affiche l'interface d'authentification du code

d'inscription;

Scénario nominal 5 Le RFsaisit le code d'inscription puis valide;

6 Le SI authentifie le code d'inscription; (Al)

7 Le SI affiche le formulaire d'inscription correspondant au

nombre d'agents retenus par le chef DFPI ;

8 Le RF fournit les références de agents participants puis

valide;

9 Le SI affiche la page de confirmation;

10- Le RFsaisie le code de confirmation;

11- Le SI vérifie le code de confirmation ;(A2)

12- Le SI enregistre les informations fournies puis envoie une

notification de confirmation de l'enregistrement des agents.

FIN

(Al) : code d'inscription invalide;


Scénario alternatif 7-Le SI réaffiche l'interface d'authentification du code

Ce scénario reprend au point 5 du scénario nominal

(A2) : code de confirmation invalide;


12- le SI affiche la page de confirmation avec un nouveau code de

confirmation sur une image


FIN



Titre Editer des attestations

Résumé Ce CU permet au chef DFPI d'éditer des attestions pour les participants

à une session d'un module

Acteurs Chef DFPI, système d'information (SI)


Version V 1.0

DEBUT



Scénario nominal 3 Le chef DFPI sélectionne l'option « Editer attestions» dans le

menu;

4 Le SI affiche la liste des participants ayant suivi une formation (liste

des formés) ;

5 Le chef DFPI sélectionne un formé dans la liste; (Al)

6 Le SI lui affiche les références du formé;

7 Le chef DFPI lance l'édition de son attestation;

8 Le SI effectue l'édition de son attestation;

9 Le SI affiche un aperçu de l'attestation;

10- Le SI lance l'impression de l'attestation.

FIN

Scénario alternatif (Al) : le chef DFPI lance l'édition des attestations de toute la liste


4- le SI effectue l'édition des attestations

5- le SI lance l'impression des attestations

FIN



4.2.3. DIAGRAMME DE SEQUENCES

Utilisateur Systeme informatique

1 1 1/ l'

affichage de lapage d'accueil r-'

Selectionner"connexion" -,

"

1" l'

affichage interface de connexion

v 1 1

saisie des références de l'utilisateur (nom_utilisateur, mot de passe)

Afficher espace de travail correspondant au profil l'utilisateur

-,

"

-

D Authentification des refereces saisies

Diagramme deséquence 1 : scénario nominal CU li; authentifier l'utilisateur»

Mise en place d'une plate forme de tétéservtces 108


Internaute Systeme jnformatique

leSI affiche la page d'acceuil avec enoptions les opérations

~

ouverture delapage d'accueil 1 1 1

bles parl'internaute. Pour deverifier ladisponibilité

possi le cas

maine, le formualire estdudo é surla page d'acceuil.affich

affichage delapage d'accueil (menu général) /

/ /

/

Choisir rubrique dans lemenu (choix de la rubrique "nom dedomaine") / /

/ /

/

affichage delapage d'accueil dela rubrique (sous menu)

Afficher formulaire de verification dedomaine~

> Verifier la disponibilité du domaine

Saisie dans leformulaire deverification ledomaine souhaité

Affichage duresultat de fa verticalion

L.I 1 1

piagramme deséquence 2 ; scénario nominal CU Consulter informations enligne

(Exemple decas: vérifier ladisponibilité dunom dedomaine)



Systemeinformatique 1 1parti~ulier

1 1 1 1 1

...J- I

Selectionner (dans la rubrique des formations) "Inscrire->participants" 1 1

'-

Affichagedu formulaire d'inscription 1..1....

Saisiedes informations demandées

vérification des informat Affichagede la page de confirmation v t.> Saisiedu codede confirmation

' ..

> Verification du code de confirmation

D Enregistrement des informations

1..-envoi du mail de confirmation de l'enregistrement

r

,11 L,

piagramme de séquence 3 : scénario nominal CU Enregistrer une demandede formation sans authentification (Exemple d'inscriptiond'un particulier a un modulede formation)



Responsable (deformation decompte. Systeme Informatique

de domaine)

,.... 1 Selectionner rubrique 1

1

affichage dela page d'accueil de la rubrique

Selectionner "connexion"

Affcihege interface d'authentification

Authentification

affichage du formulaire ( suivant la rubrique choisie) 1

Saisie desinformations demandées

Affichage de la page de confirmation ~ vérification desinformations

Saisie ducode deconfirmation

~ Verification ducode

deconfirmation

Envoie du mail deconfirmation de l'enregistrement ~

Enregistrement des informations

Affichage duformulaire de demande en ligne

Diagramme de séquence4: scénario nominal CU Enregistrer unedemande deservice réservée enligne



Cabinet du DELGI

Systeme informatique Secrétaire 1 DE~GI !

1

r- I 1alerte "arrivée d'une nouvelle demande" 11

1 1

Authentifier11 1 1

Afficher demande arrivée 1 11 1 1

~ Vérification de l'integrité de la demande

validation de lademande (première validation)

1 111 111

1

1

, 1 1

~ Mise à jour de la demande validée 1par la secretaire 1

1

Alerte de l'arrivée d'une demande 1, 1

J

Authentification

afficher demande validée 'par la secretaire

1 11 1 Examiner les informations 1 ~ 11

de lademande

Valider demande (deuxieme validation)

~ Mise à jour de la demande validée par leDELGI

:=:> Chargement de lademande suivante t

11 I

L.

Diagramme de sequence 5: Scénario nominal du CU valider les demandes



Cabinet du DELGI

Systeme informatique 1 Secretaire

1

1IQM

1 111 1

11

alerte "arrivée d'une nouvelle demande"

Authentifieri

1 1

I 1

11111 111

afficher demande

Verifier integrité

~ delademande

1 11

Invalider demande

1 interface desaisie des raisons de J'invalidation

fournir lesraisons del'invalidation

~ preparer rapport d'erreur

11111111

apercu durapport d'erreur

confirmation del'envoi durapport d'erreur

envoi durapport

~ Chargement delademande suivante c..

1 1111

'"r

Diagramme desequence 5.1: Scénario alternatif (A1)duCU valider lesdemandes



Cabinet du DELGI

Systeme informatique 1 Secretaire 1 1 DELGI 1

1 1 1 1

1 1 Alerter rarrivé d'une nouveNe demande 1

1 11

1 1 1 1 1 1 1 Authentifier 1

1 1 1 1 afficher demande 1 1 1 1 1 1 1 1 1

11

~ Verifier l'integrité 11

1 de lademande 1 1 11 11 Valider lademande 11 1 1 11 11

11 1 ~ Mise à jourde lademande validée 1 1

1 1 par tasecretaire 1 1

1

1 , 1 Alerte de l'arrivée d'une demande

111 1 1

1 1 1 Authentification : 1 1 1 afficher demande validée par I~ secretaire 1 1 11 1 1 1 1 1 Examiner les informations 1 1

11 de lademande

1 ~ 1 11 Invalidation de lademande 1 1 Afficher interface desaisie des raisan de l'invaliqation1

11 1 1 1 Fournir raisons de finvalidation 1 1 11 1 1 1

111 ~ Préparer rapport d'invalidité

11 1 11 Alerte derinvalialion de lademande 1 1

1 11 1

1 Authentification 11

1

1 11

1 Apercu du rappport d'invalidité 1

1 1

1 1

1 confirmation de l'envoi 11

1 1

1

envoi durapport d'erreur 1

1

~ Chargement de lademande suivante 1 1

1 1 1 1 1 1 1l..,.

Diagramme desequence 5.2: Scénario allernatif (A2) duCU valider les demandes



Utilis~teur Systeme informatique

~

1

: Authentification .... "

" Afficher l'espace de travail reservé au profil

,......

Selectionner l'option "consultation" -,

"

'" Afficher menu consultation

....

choix de "élément à consulter .... "

.. affichage des informations sur l'élément choisi <,

'i 1 1

Séquence 6: scénario nominal du CU consulter listes



1 Chef DICJM 1 Systeme informatique 1 FASONET 1 ! prest:taire )

1 11 111

1 ,..L 1 1

1 1 1

1 Alerte de J'arrivée d'une nouvelle demande 1 1

11

1 1 Authentification 1 1

1 1 1 1

Afficher demande validée par leDELGI 1 1

11

1 1 1 1

1 1

~ Verification de l'identité 1 1 1

1

du demandeur 11

11

1 1 1 1

1 1

valider l'identité du demandeur 11

1 1

1 1 1 1 1 1 1 1 1 1P mise à jour de lademande 1 1 1 1

Alerte de farrivée d'une demande de domaine 11 1

1

1 1

Authentification

Affichage de lademande validée par laDELGI

1 ~ enregistrement 1

du nom de domaine 11

1 1 1 1 1 1

Confirmer lacreation/modification

~ mise à jour de lademande 11

1 1

1 1 1P Chargement de ladmande suivante

1

1 1 1 1

1 1 1 Notification de l'enregistrement: 1

1 1 1 1

1 Notification de l'enregistrement1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1

piagramme de Séouence 7:scénario nominal du CU Vérifier l'identité du demandeur de domaine

Beneficiaire du domaine

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 j

1 1 1 1 1 j

1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1



Systeme informatique1 chef,DFPI 1

1

,11 1 ,,Auti'lentification

1

Afficherinterface reservée auprofil1/

" Selectionner l'option "Mise à jour"

affichage de l'interface de miseà jour (modules et sessions)

Effectuer la miseà jour

miseà jour des informations~ Demande confirmation de la miseen ligne

Confirmation miseen ligne

p marquage des informations à

Affichage apercu de la miseen ligne

plaaramme de Séquence 8: scénario nominal du CUMettre à jour le programme de formation

117Mise en place d'une plate forme de télé services


Systeme informatique1 Chef,DFPI 1

1 1 1 1 1

.J..

IF (organisme publics) ,11

1 1

1 1

1 1

1 J

1

J

Else

IF (Particuliers) 1

J

1 1 1 J

1 Else (d~mande exceptionnelle)

1 1 1 1 1 1 1 1 1 1 1 1 1

J End If 1

J

1

1 1 1 1

End If

Authentification

Afficher interface correspondant au profil

selectionner l'option'programmation''

Afficher interface de programmation

Consullations

choisir organismes retenus

affICher inetrface d'ed~ion de notification

saisir (nombre de candidats retenus, sessions ...)

valider inscription àune session de modules

Consu"er les demandes excepUonnelles validêes par leDELGI

~ etudier laprogrammation

Programmer l'organisme demandeur

~

~

..."'_d

:=:> mise à jour des inscriptions :

envoi de convocation pour ladate de lasession: 1 1 1

1 1 1 1 e,1 1 l 1 1 1 1 1 1

1 1

1 1 1 1 1 1

1~ mise à jour des inscriptions i 1

1

1

Envoi convocation pour ladate programmêe 1

, 1 1

1 1 1

1 1 1

1 1 1

1 1 1 1 1 1 1 1

1 1

mise àjour des informations i1

1 1

Generer code d'inscription i ......"'00 (""0"',," y.'oN']

Diagramme de Séquence 9:scénario nominal du CU Etablir lecalendrier de formalion



Responsable deformations Systeme informatique

r-e- I,Authentification "/

affichage delapage d'accueil delarubrique formation

selectionner "inscrire->agents"

affichage formulaire d'autthentification ducode d'inscription

Saisie code d'inscription

Authentification ducode d'inscription:==>

affichage duformulaire d'insription des agents

saisie des références des agents

verification delacompletude des informations fournies:==>

Affichage delapage deconfirmation

saisie code deconfirmation

Authentification du code deconfirmation:==>

enregistrement des informations fournies~

envoi dumail deconfirmation del'enregistrement

'1 L- I

Diagramme deSéquence 10:scénario nominal duCU Inscrire des agents a une session



1Systeme informatiqueChef ,DFPI 1

1 1 11 1

~ Authentification

affichage del'interface reservée auprofil

sélectionner "édition d'attestations"

Affichage interface d'edition des attestations

selectionner "affichage liste des formés"

affichage liste des formés

Selectionner un formé

affichage référeaces duformé

Selectionner dans lemenu "edite('

111

111

édition del'attestation dL~ affichage del'apereu del'attestation

Confirmer l'impression

D Lancer l'impression del'attestation

Diagramme deSéquence 11: scénario nominal du CU éditer des attestations



4.2.4. DIAGRAMME D'ACTIVITES

SystemeUtilisateur

Choisir "connexion" I?------'--------

Fenêtre de connexion I?--------~ 1 1

I[SinOn )

[besoin de connexion] [non OK]saisir nom utilisateur et mot de passe

'------------'---~-----~ Vérifier mot de passe et nom utilisateur

[Ok]

Diagramme d'activité 1: CU Authentification un utilisateur

M;se en place d'une plate forme de télésetvices 121


SystemeInternaute

Choisir "rubrique nom de domaine" IE--l--------------j Afficher page d'accueil

L-------f-----71 Afficher page d'accueil de la rubrique nom de domaine

[Quitter page1 [Sinon]

(besoin de verifier disponibilitédu domaine]Saisir nom de domaine à vérifier

L---------f-----71 Verifier disponibilité du nom de domaine saisi

[Nom de domaine disponible]

[Non][Oui]

1

1111 1

Piagramme d'activité 2: CU Consulter informations en ligne (vérifier la disponibilité du nom de domaine)



Particulier 1 Systeme

[besoin d'inscription] : t------------t-------=~ Afficher formulaire d'inscription à une formation

....-------+Annuler inscription iE-----..,----------,

Vérifier complétude desinformations saisies

[informations complets]

[Oui][Non]

Compléter informations manquantes iE------l---j Afficher formulaire avec lemessage d'erreur

Annuler operation IE--------'-------,

)E-------------1 Afficher page deconfirmation

Saisir code deconfirmation afficher \E-----;.-------'

Enregistrer informations fournies f-----~ Envoi mail deconfirmation

Diagramme d'activité 3: CU Enregistrer une demande de formation sans authentification (exemple d'inscription d'un particulier)



Responsable 11 1 Systeme

(forrnatlon, compte) Iprestataire 1 11

[Authentification reussie] ...----------;-----------;71 Afficher Formulaire \<E=-----------,

Verfier la completude des informations fournies

[informatio~s complets]

[Oui][Non]

[Non] [Infonnations completées]

Completer infonnations manquantes IE---l-J Afficher formulaire avec le message d'erreur

Saisir code de confinnation afficher ioE'---t---------------------j

[code saisie]

111, 1

[Oui]

1111 [Non OK]

1 1 1 1 1 1 1 1

1

, 1 11 1

1 Envoie mail de confinnation f 1

1 1

111

piagramme d'activité 4: CU Effectuer une demande de service reservée en ligne



Secretaire du DELGI Systeme Le DELGI [";thentification reussie]

Afficher lademande

p~7_in_te_gr_el ~

[Non]

!Oui}~ .

[Authentification reussie]

...=)i Mise ajour de lademande validée

par lasecretaire

[Non]

[Oui]

'------e-t-----------"lI Preparer rapport d'erreur iE-----1'-------,

Confirmer l'envoie du rapport I?---i-----------J

[confirmation de l'envoie)

:r------''i>! Envoie durapport d1nvaiidM

~_+-

(Approbation]...J

Chargement de lademande suivante

[Invalidation d DELGI)

-------i--------------~I

piagramme d'activité 5: CU Valider les demandes



Utilisateur Systeme

[Authentification reussie]~------+--------:7t::.( Affiche espace detravail reservé au profil

1

(ChoiSir l'option "consultion" \E:<:.....-~---I----------~----

'--------~--+------_?t> Afficher lemenu consultation

( Choisir "element a consulter" 1oEl<:'---+--------------'

[Non] '---------+-------:::':><~ Afficher information sur l'element choiSie)

~mprimer I!information]

)1[Oui]

.---------<. )---------,

1 [Non]

\1/

(confirmation del'impression \1E(----+-l\Afficher apercu del'etat)

1 [Confirmer]

[Oui] '------{J)---------+--------3>f:: Lancer l'impression

\1• Diagramme d'activité 6: CU Consulter les informations privées



ChefDICIM

a• [Authelification reussie]

Systeme

~Afficher la demande de compte

Agent de creation

(confirmer la creation du compte}:

>(Mise ajour de la demande

l''"'"t""';'1

(Afficher demande confirmer pour creatbnIMAJ)

1 ~Consuner demande)

(creation 1MAJ du compte

(AffiCher interface de Mise ajour de comple~

\ 1

(selectiOnner "enregistrer comple"

r---~ 1

1

( Envoie mail de COnfirmatiO~

(Enregistrer Mise ajour du compte

L '/

'"

~Saisie Mise ajour afaire

• Diagramme d'activité 7: CU Autoriser la création/modification des comptes

127Mise en place d'une plate forme de téléservices


1 FASONETChefDICIM 1 Systeme .. 1

IAuthentifiCation reussie]

•1

1

1 1

1 1 1

1

(confirmer l'identité du demandeur de domaine}1E<-' 1:------------'1

!tI . 1 . 1 1 ~ . [organisme enstant i

1 1

IOui] 1 1

1 1

1

1 1

1

1 1 (Afficher demande validée par la DELG~1

INon] 1 1

1[Non] '--------1J'------1------OlI;>'\..Consuller demande de comptes 1 J

~reparer notification 1 1 1 \ 1

[afficher apertU] 1 (creation IMAl du domaine 1(confinner l'envoie de la notification IE:<-l-I---- 1

J 1

1 1

1 1

1 1

1 1 \ lM 1

1 : (confirmer lacreation! MAI du domaine)1

1 J

,1 1

1 1 1(Mise ajour de la demande}IE<-----:--------J1 1,1 1 1

1 1

1 1 1 1 1 1 1 1

\1 1

1 111 1

1 1

1 J

Diagramme d'activité 8: CU Vérifier l'identité du demandeur de nom de domaine



SystemeChef DFPI 1

1

1 [Authentification reussie]

l----------I----------7I Afficher interface reserve auprofil

Selectionner l'opton"Mise ajour" IE-----I---------------J

'------------'-----71 Afficher interface deMAJ desmodules et sessions

~----t Annuler operation /E-------'----,

Effectuer lamise a jour tl':------'-----'

'---~------l------....;;.tEnregistrer les mise a jour

Afficher interface deconfinnation de lamise enligne[Non]

Confinnation dela mise enligne IE-----.------------J

[Oui] >-------~--~ Mise a jourdes informations a mettre enligne

Apercu delamise en ligne

Diagramme d'activité 9: CU Mise a jour duprigramme deformation



ChefDFPI 1 1

Systeme 1

[Authentification reusse]

Selectionner "option "programmation" jE- ...J.... ---'

l...-----------........-------71 Afficher interface deProgrammation

Consulter demande deformation exceptionnelle 1Ec-----j--,

[Autre programmations]

Valider inscriptions desparticuliers IE-----+---"

[Pogrammer organisme public]choisir organismes ~ublics pour leurformation

L--- --l-_71 Affiicher interface denotification

Saisir condition a suivre (nombre_agents,session)

Generer code d'inscription

Envoie notification deprogrammation (nombre_agents,code d'inscription)

Piagramme d'activité 10:CUEtablir le calendrier de fonnation



SystemeResponsable de formations

l----------t---------:7I Afficher interface reservé au profil

L...- -'- ~ Afficher formulaire d'authentification code d'inscription

Annuler operation IE-------t----,

L...-----------,r--------------:;;>i Verifier code d'inscription (Non]

[Verification reussie]

[Oui]

Afficher formulaire d'inscription pour agent IE--------,

Saisir references des agents 10---;---------'

(Non]

[Infomnations completes]

envoie mail de confirmations de l'enregistrement

L....---------i------------....;.<'.

Diagramme d'activité 11: CU Inscrire les agents a une session



1 1

Chef DFPI 1 Systeme

1 [Authentification reusste]

f-------------J..-------7I Afficher interface du profil

Selectionner "edition desattestations" )E------t-----------------J

~---------_t--_?tAfficher interface d'edition desattestations

Selectionne listedesparticipant a afficher

"-------------1-----71 afficher listedesparticipants choisie

Choisir dans le menu edition "editer toute la liste" iE----t--,

Choisir un formé )E----------t---"

~------------':----_7tafficher reference du formé

confirmer edition IE--------.L..---------'

• piagramme d'activité 12:CU Éditerattestation



4.2.5. DIAGRAMME DE CLASSES D'ENTITES

REGLES DE GESTION

RG 01 : Les organismes (organismes publics et ose) peuvent effectuer plusieurs

demandes de formation pour leurs agents;

RG 02 : une demande de formation est effectuée par un et un seul organisme;

RG 03 : une demande de formation concerne un module de formation;

RG 04 : un module peut être concerné par plusieurs demandes;

RG 05 : un module comprend plusieurs sessions de formation;

RG 06 : une session concerne un et un seul module;

RG 07 : une session est assurée par un formateur;

RG 08 : un formateur peut assurer plusieurs sessions;

RG 09 : à une session peuvent participer plusieurs particuliers et/ou agents d'un

organisme;

RG 10: les organismes publics peuvent effectuer des demandes de compte

utilisateur pour leurs agents;

RG 11 : une demande de compte concerne un compte utilisateur;

RG 12 : un compte appartient à un et un seul agent d'un organisme public;

RG 13 : un agent ne peut disposer que d'un seul compte;

RG 14: une demande de compte est effectuée par un et un seul organisme

public;

RG 15: une demande d'enregistrement de domaine concerne un et un seul

domaine;

RG 16: un domaine est sous la responsabilité d'un responsable administratif; ce

dernier faisant partie de l'organisme propriétaire du domaine.

RG 17 : un domaine est identifié par un serveur;

RG 18 : un serveur peut identifier plusieurs domaines;

RG 19 : Les agents techniques interviennent sur les serveurs DNS;

RG 20 : un domaine appartient à un et un seul organisme;

RG 21 : un organisme peut disposer de plusieurs domaines;

RG 22 : un prestataire peut déclarer plusieurs réseaux pour un domaine.

RG 23 : un réseau est déclaré par un seul prestataire;

RG 24 : un domaine est géré par un prestataire: l'organisme pouvant être son

propre prestataire;



Nouvelles règles de gestion

RG 25 : les particuliers peuvent s'inscrire aux modules de formation;

RG 26: les bureaux de demande sont habilités à effectuer les demandes

d'enregistrement de domaines;

RG 27 : une demande d'enregistrement de domaine est effectuée par Lin et un

seul bureau de demande;

RG 28 : un organisme public peut postuler à plusieurs modules de formation;

RG 29 : un module peut être postulé par plusieurs organismes publics.

RG 30 : un prestataire peut être un bureau de demande;

RG 31 : un bureau de demande est un prestataire.



-_no \=numJll'rsonne (kI) -nom..P8~e

--prenomJMtnsonne -fonction..Pef'Sonne -fu-,Personne ...f:elephone-P8rsonne -aeresee..JJ8I'SO"ne l--1- ....--emall

dOmlll,..App8ltlenl1 1..' 1 num domaine (id)

-nom_domaine 1..' 1 etll!ler()

oru...lsme +modlfier() 1.."

f-num_0I"Q8ntsme (k::I) -nom_organisme 1..' îden!ifi -numera respons b1e 1

1 l -rueose ..... ~vUle\-cod__.'~~_osccm ose 1."..... relève gére

.-5ervice _nt res nsabl ad f Serveurs ONS-rcrme juridque .. ~~m_agent1 -sigle 1 -num_serveur (id)l 8gdnt techniqueliIutres.J'r8noms

-nom_serveurintervient1 r f .: -adresse_'PQ. 1..'O.." particulier lPartJcipa1 1

-num...P2lrticuller 1Err" uel NbeJlarticuliers .L

O..' 1 org...lsma publio lposlule -num_organismeJ'Ublic ~

S'inscrit tnom_domaine organisme 1 1..' r

Concerne 3 . prastatatr1 Participe 2 -numJX'estataire (id)

1.'- -nomJ)restatalre f-- 1.." 1.." Nbe_sgents appartient -adress.eyestataire1.:1

+ajouter()session

modula formateur -num_sesion1 l assure comprend Concerne 1 1 Demand._"".....n l 0 ..1 -num_module (id)

-num formateur ---- -intitule -num_demlllntM_formation En: clue:] est-cIate_debut -date_"n

l 1 1.... +reporter() 1.: 1 +creer() 1 1.: L- ~_-------I

+annuler() O.. t+modifier(1 1.: 1 1.'

bureau de demandeConceme 2 comptltuttll...ur Demand._dom~"n. loemandtLcompWJ Effectue 3 -num_bureau (id)

-num_compte (id)1 -num demande_domaine -nom_bureau

1 !-nom_compte -adresse_ureeur -mot_deJ'asse

Fnum~emande_compte l 1.: 1.: 1

-adresse electronlque

dédare

<& ..m.....

rn••u 1 O••' -num_demande (id) 1

" -naturs_demande 1...., l~num_reseau (id) -date_demande f-----'-adresses_reseau

+vellderO +rejeter()

Diagramme de classe d'entités



DESCRIPTION DETAILLEE DES CLASSES D'ENTITE

Nom

num_organisme (id)

nom_organisme

service

forme juridique

pays

code_postal

ville

rue

numéro

sigle

Nom

Nom

num_organisme_public

nom_domaine_organisme

Nom

-

Nom

num_osc

nom_ose

Nom

-

Classe: organisme

Attributs

Description

Numéro d'identification de

l'organisme

Nom complet de l'organisme

demandeur

Service

Forme juridique

Pays

Boite postale de l'organisme

Ville

Rue où est situé l'organisme

Numéro

Sigle de l'organisme

Méthodes

Classe: organisme public

Attributs

Description


Nom de domaine

Méthodes

Classe: ose Attributs

Description


Nom d'un ose

Méthodes

Type

alphanumérique

Texte

Texte

Texte

Texte

Numérique

Texte

Numérique

Numérique

Texte

Description

Type

Numérique

texte

Description

-

Type

Numérique

texte

Description

-



Nom

num_agent

autres_prenoms

Nom

-

Classe: agent

Attributs

Description

Numéro d'identification de

l'agent

Autres prénoms de l'agent

Méthodes

Type

Alphanumérique

Texte

Description

-

Nom

num_demande_formation

Nom

-

Classe: demande_formation

Attributs

Description

Numéro d'identification de la

demande de formation

Méthodes

Numérique

Description

-

Type

- -

Nom

num_demande_compte

Nom

-

Classe: demande_compte

Attributs

Description

Numéro d'identification de la

demande de compte

Méthodes

Type

Numérique

Description

-- -

Nom

num_demande_compte

Nom

-

Classe: demande_domaine

Attributs

Description


Méthodes

Type

Numérique

Description

-



Nom

num_demande

nature_demande

date_demande

Nom

Valider 0 Rejeter 0

Nom

num_compte

nom_compte

moCde_passe

adresse_electronique

Nom

Créer 0 Modifier 0

Suspendre 0

Nom

num_module

intitule

Nom

Creer_module 0 Modifier_module 0

Classe: demande

Attributs

Description Type


Nature (création/modification) Booléen

Date d'établissement Date

Méthodes

Description

Valide une demande

Rejette une demande

Classe: compte utilisateur

Attributs

Description Type


Nom du compte utilisateur Texte

Mot de passe Alphanumérique

Adresse électronique Alphanumérique

Méthodes

Description

Crée un nouveau compte pour un utilisateur

Modifie un compte déjà existant

Suspens temporairement un compte

classe: module

Attributs

Description Type

Numéro d'identification Alphanumérique

Intitulé du module Texte

Méthodes

Description

Crée un nouveau module de formation

Modifie le contenu d'un module de formation



,

Nom

num_session

date_debut

date_fin

Nom

reporter_session 0 annuler_session 0

Nom

num_formateur

Nom

-

Nom

num_particulier

Nom

-

Nom

num_reseau (id)

Adresses_reseau

Nom

-

Classe : session

Attributs

Description Type

Numéro d'identification Alphanumérique

Date de début date

Date de fin date

Méthodes

Description

reporte une session de formation

Annule une session de formation

Classe: formateur

Attributs

Description Type

Numéro d'identification du alphanumérique

formateur

Méthodes

Description

-

Classe: particulier

Attributs

Description Type

Numéro d'identification du alphanumérique

particulier

Méthodes

Description

-

Classe: réseaux

Attributs

Description Type

Numéro d'identification alphanumérique

Adresses du réseau numérique

Méthodes

Description

-



Classe: personne

Attributs


num_personne (id) Numéro d'identification d'une alphanumérique

personne

nom_personne Nom de la personne texte

prenom_personne Prénom de al personne texte

fonction_personne Fonction de la personne texte

fax_personne Numéro de fax numérique

telephone_personne Numéro de téléphone numérique

adresse_personne Adresse de la personne texte

email Adresse électronique texte

Méthodes

Nom Description

- -

Classe: domaine

Attributs


num_domaine (id) Identifiant du domaine alphanumérique

nom_domaine Nom du domaine texte

Méthodes

Nom Description

- -

Classe: serveur_DNS

Attributs 1

Nom Description Type 1---

num_serveur (id) Identifiant du serveur alphanumérique

adresse_IP Adresse IP du serveur numérique

nom_serveur Nom complet du serveur texte

Méthodes

Nom Description

- -



Nom

num_resp_admin

service_resp_admin

Fax_resp_admin

Email_resp_admin

Nom

-

Nom

num_agent

nom_tech

societe_agent

service_agent

fax_agent

emaiLagent

Nom

-

Nom

num_prestataire (id)

nom_prestata ire

adresse_prestataire

Nom

-

Classe association: Responsable administratif

Attributs

Description Type

Numéro d'ldentlflcatlon Alphanumérique

service texte

Numéro du fax Texte

Adresse électronique Texte

Méthodes

Description

-

Classe: agents techniques

Attributs

Description Type

Numéro d'identlftcetton Alphanumérique

Numéro texte

Société du technicien texte

service texte

Numéro du fax Texte

Adresse électronique Texte

Méthodes

Description

-

Classe: prestataire

Attributs

Description Type

Numéro d'identlfiant alphanumérique

Nom complet du prestataire texte

Adresse du prestataire texte

Méthodes

Description

-



4.3. PROCEDURES TRANSITOIRES

Les procédures transitoires sont des tâches à exécuter pour passer du système

d'information actuel au système futur.

La spécification des procédures transitoires concerne :

• la récupération et le transfert des données actuelles;

• la définition des tâches organisationnelles à exécuter pour le passage

du système actuel vers le système futur.

4.3.1. RECUPERATION ET TRANSFERT DES DONNEES ACTUELLES

A ce niveau, il s'agira essentiellement:

• de définir la nature des informations à récupérer dans le système actuel;

• de spécifier les tâches prenant en charge ce transfert.

4.3.1.1. Les données à récupérer

Le système d'information actuel comporte des données qui sont récupérables. Il

s'agit essentiellement des données archivées présentement disponibles. La plupart

de ces données sont stockées sur du support papier. Elles sont relatives aux

activités du cabinet du DELGI et des départements DICIM et DFPI dans les

gestions des formations informatiques et des comptes utilisateurs. Pour les noms

domaines, la DELGI dispose sur son site d'un « Portail des sites web du Burkina »,

donc un moyen de récupérer les noms de domaines serait de consulter cette

rubrique sur le site.

4.3.1.2. Les tâches à exécuter pour le transfert des données

Comme défini ci-dessus, l'archivage actuel ne contient pas à cent pour cent des

données cohérentes. Les tâches à exécuter pour le transfert des données ne se

chargeront pas uniquement de transférer les données de l'archivage actuel vers la

base de données future, mais procédera d'abord à des traitements.

Les traitements à ce niveau seront essentiellement une vérification des données

avant leur transfert. Il sera demandé aux différents acteurs du système de



renseigner les formulaires habituels pour une mise à jour des données afin de

transférer des données cohérentes du système actuel vers le système futur.

Les chefs de département DICIM et DFPI devront procéder à des collectes

d'informations récentes nécessaires concernant chaque domaine:

- les demandes de formations, les modules de formations proposés, les

sessions de formations programmées;

- les demandes de modification ou de création de comptes utilisateurs, les

comptes créés par organisme;

- le recensement de touts les domaines sous l'extension «.bf» et la

désignation des prestataires et structures habilité à faire la demande de nom

de domaine.

4.3.2. PROCEDURE "rRANSITOIRE AU NIVEAU ORGANISATIONNEL

Le système futur devra être soumis à une série de tests afin de s'assurer de son

adéquation avec les besoins et exigences exprimés par les utilisateurs. Les

éventuelles défaillances décelées au cours de ces tests seront progressivement

corrigées jusqu'à l'obtention d'une application conforme aux besoins.

Les systèmes futur a pour objectif d'apporter un plus dans le système présent et

non un remplacement total. De ce fait nous proposons une période de deux (02)

ans pendant laquelle nous évaluerons la capacité du système a assurer tous les

traitements aussi bien voir mieux que l'ancien système. Et aussi étudier les

tendances des utilisateurs (utilisation de l'ancien système ou du nouveau) dans le

but toujours d'améliorer le système.

4.4. POLITIQUE DE SECURITE

La sécurité est une stratégie préventive qui s'inscrit dans une approche

d'intelligence économique. Elle ne permet pas de gagner de l'argent, mais évite

d'en perdre. L'objectif de la sécurité des systèmes d'information est de garantir,

qu'aucun préjudice ne puisse mettre en péril la pérennité de l'organisme. La

sécurité repose sur un ensemble cohérent de mesures, de procédures, de



personnes et d'outils. Elle n'est jamais acquise définitivement. Elle se vit au

quotidien.

La politique de sécurité a pour but de minimiser les risques de panne, d'éviter que

la base de données soit dans un état d'incohérence, d'éviter les accès non

autorisés à la base et d'éviter la présence de programmes indésirables dans le

réseau. Il s'agit donc de prendre toutes les dispositions utiles afin de réduire au

minimum les effets néfastes des pannes matérielles ou logicielles.

~ PROTECTION CONTRE LES CATASTROPHES

Les catastrophes naturelles susceptibles d'endommager les installations sont les

incendies, les orages, les inondations et la foudre. La DELGI dispose déjà d'une

politique de protection contre les catastrophes naturelles qui répond à nos

attentes.

~ PROTECTION CONTRE LES INCIDENTS D'EXPLOITATION

Lorsqu'un incident se produit, les utilisateurs devront faire appel à une personne

ayant des compétences en informatique (l'administrateur système par exemple) et

pouvant apporter une solution au problème. S'il s'agit d'un incident lié à

l'application, elle pourra éventuellement se servir des dossiers de programmation

pour résoudre le problème. Si le problème persiste, la DELGI pourra faire recours

aux programmeurs.

~ PROTECTION CONTRE LES VIRUS INFORMATIQUES

La précaution consiste à installer un logiciel antivirus au niveau des différents

postes de travail et du serveur d'application. Il faudra également faire une mise à

jour régulière de l'antivirus.

~ PROTECTION CONTRE LES COUPURES D'ELECTRICITE

Les coupures d'électricité peuvent provoquer l'incohérence des données dans la

base. L'utilisation d'onduleurs et d'un groupe électrogène permettra la bonne

continuité du travail en cas de coupures prolongées.

~ PROTECTION DES DONNEES



Pour des questions de sécurité et de confidentialité, certaines informations ne

reposent pas uniquement sur des outils de sécurité mais également sur une

stratégie, une organisation et des procédures cohérentes. Cela nécessite une

structure de gestion adéquate dont les missions sont de mettre en place, de

valider, de contrôler et de faire comprendre à l'ensemble des acteurs de

l'organisme, l'importance de la sécurité.

> CONFIDENTIALITE DES DONNEES

La confidentialité des données requiert la définition des droits d'accès. Ceci se

traduit par l'utilisation de mots de passe et de noms de connexion pour l'accès aux

données de la base de données. De cette façon l'accès à la base de données sera

restreint aux personnes qui sont autorisées tout en contrôlant qui peut afficher et

modifier les informations de la base de données.

NB : les dates et heures de connexion et de déconnexion seront automatiquement

enregistrées par le système, ce qui permettra d'identifier tout utilisateur qui aura

ou qui tentera de lui causer des désagréments.

4.5. PROCEDURES DE SECOURS

Les procédures de secours sont des procédures organisationnelles à appliquer lors

d'une indisponibilité des ressources informatiques indispensables au

fonctionnement du système.

Ces procédures permettent d'offrir un minimum de services conformément aux

exigences des utilisateurs. Elles seront exécutées lors du fonctionnement en mode

dégradé du système. Le mode dégradé est une situation où le système n'est pas

en mesure d'offrir toutes les fonctionnalités aux utilisateurs. Ce système peut être

entièrement incapable de fonctionner. Diverses situations peuvent être à l'origine

du mode dégradé du système.

• POSTE DE TRAVAIL INDISPONIBLE

La panne d'un ordinateur ne saurait arrêter totalement les traitements effectués

sur le poste de travail correspondant. Au vu des possibilités offertes par le

système à mettre en place, les utilisateurs de ce système pourront effectuer des



traitements de concert avec les utilisateurs d'autres postes afin d'éviter un blocus

dans le circuit des traitements en attendant la réparation du poste ou son

remplacement.

• PANNE DU SERVEUR

En cas de panne du serveur, nous préconisons de dupliquer la sauvegarde

effectuée par le robot sur un autre poste de travail afin de transformer ce poste en

serveur temporaire. La base de données sera réinstallée telle qu'elle était lors de

la dernière sauvegarde ainsi que le logiciel d'application



CONCLUSION GENERALE

Dans le cadre de notre stage, il nous a été demandé de mettre en place une plate

forme de téléservices. En effet, la DELGI connaît actuellement une gestion

entièrement manuelle des services (formations, comptes utilisateurs et les

domaines) qu'elle offre ce qui rend les tâches harassantes et complexes. Tout en

nous appuyant sur le système d'information existant avec ses avantages et ses

imperfections, nous avons proposé des solutions pour palier à ces insuffisances

afin d'atteindre les résultats attendus de son informatisation. De concert avec le

groupe utilisateur, un scénario fut retenu et modélisé dans le dernier chapitre du

document (reconfiguration et modélisation du futur système).

En somme, dans ce document qui est une fusion du dossier de l'existant et du

cahier des charges utilisateurs, nous avons défini le futur système d'information et

les procédures de secours et de sécurité adéquates à son utilisation. Nous

aimerions que le travail que nous avons entrepris à la DELGI connaisse son

achèvement pour permettre de voir nos efforts couronnés par la mise en place de

cette plate forme.



ANNEXE

ApPROCHE DES REGLES QUI GOUVERNENT L'EXTENSION INTERNET

Afin de mieux gérer les domaines, l'ICANN (Organisme de Gouvernance de

l'Internet niveau international) a établit des règles de validité des noms de

domaines. Ainsi des termes tels que les termes injurieux, raciste, grossiers, utilisé

comme nom de domaine seront invalide. Aussi les termes réservés tels que les

termes techniques de l'Internet, les termes liés lié au fonctionnement de l'état, les

termes consacré a des organisations internationales seront refusé. (Pour ne citer

que quelque exemple des règles établies par l'ICANN)

Suivant ses règles chaque pays peut l'adapter au contexte de son milieu. Ainsi

pour les termes racistes ou injurieux un pays peut décider d'en rajouter.

L'ensemble de ses différentes règles établies par un pays pour l'enregistrement

des domaines constitue la charte de nommage

NB: ICANN: Internet Corporation for Assigned Names and Numbers

http://www.icann.org/tr/french.html



PRESENTATION UML

Comme précédemment décrit, UML (Unified l'v1odeling Language) est non

seulement un langage de modélisation conçu pour construire, visualiser, et

spécifier les systèmes d'information, mais aussi un support de communication et

un cadre méthodologique.

) Support de communication en ce sens qu'il facilite la représentation et la

compréhension de solutions objets:

.. Sa notation graphique permet d'exprimer visuellement une solution

objet, ce qui facilite la comparaison et l'évaluation de solutions;

.. L'aspect formel de sa notation, limite les ambiguïtés et les

incompréhensions;

.. Son indépendance par rapport aux langages de programmation, aux

domaines d'application et aux processus, en font LIn langage universel;

) Cadre méthodologique car il permet de représenter un système selon

différentes vues complémentaires: les diagrammes.



CONCEPTS FONDAMENTAUX

Le modèle

~ Un modèle est une abstraction de la réalité:

• Il s'agit d'un processus qui consiste à identifier les

caractéristiques intéressantes d'une entité, en vue d'une utilisation

précise.

• L'abstraction désigne aussi le résultat de ce processus, c'est-à

dire l'ensemble des caractéristiques essentielles d'une entité,

retenues par un observateur.

~ Un modèle est une vue subjective mais pertinente de la réalité:

Un modèle définit une frontière entre la réalité et la perspective de

l'observateur. Ce n'est pas "la réalité", mais une vue très subjective de

la réalité.

Bien qu'un modèle ne représente pas une réalité absolue, un modèle reflète des

aspects importants de la réalité, il en donne donc une vue juste et pertinente.

Le métamodèle

Le métamodèle d'UML décrit de manière très précise tous les éléments de

modélisation (les concepts véhiculés et manipulés par le langage) et la sémantique

de ces éléments (leur définition et le sens de leur utilisation).

Classe

Une classe est une abstraction du monde réel qui regroupe un ensemble d'objets

ayant des caractéristiques et des comportements communs. Chaque classe est

définie par un ensemble d'attributs (qui représentent les caractéristiques ou

propriétés de la classe), et un ensemble d'opérations qu'elle peut exécuter. Ces

opérations représentent un ensemble de traitements.



Class

+attribute +ope ration ()

Objet

Un objet est une unité élémentaire d'une classe. II hérite des propriétés de la

classe à laquelle il appartient, et il est caractérisé par les valeurs affectées à ces

propriétés.

..Qbje~t

+attribute +operation 0

Message

Les messages sont le seul moyen de communication entre les objets. Ils sont

décrits essentiellement par l'objet émetteur et l'objet récepteur. Leur description

peut être complétée par un nom, une séquence, des arguments, un résultat

attendu, une synchronisation, une condition d'émission.

message -+

Acteur

Un acteur définit un ensemble cohérent de rôles qu'un utilisateur ou une entité

externe peut jouer en interagissant avec le système. Un acteur peut consulter

et/ou modifier directement l'état du système en émettant et/ou en recevant des

messages susceptibles d'être porteurs de données.

« Actor »

Nom Acteur



LES DIAGRAMMES UML

Ce sont des éléments graphiques qui décrivent le contenu des vues, qui sont des

notions abstraites.

UML l.x propose neuf (9) diagrammes (13 diagrammes dans sa version 2.0),

dont sept (7) interviennent en phase d'analyse du système d'information, et deux

(2) en phase de réalisation et sont utilisés exclusivement par les informaticiens.

En ce qui nous concerne, nous nous intéressons plus particulièrement aux

diagrammes qui ont pour fonction de faciliter la spécification et la compréhension

du système au cours de son élaboration. On distingue parmi eux les diagrammes

structurels des diagrammes comportementaux:

./ Les diagrammes structurels permettent de visualiser, spécifier, construire et

documenter l'aspect statique ou structurel du système d'information. Il s'agit

des diagrammes de classes, d'objets, mais aussi de déploiement et de

composants. Les deux premiers permettent de modéliser les entités qui

seront manipulées par le système d'information et qui représentent les objets

du monde réel. Les deux derniers sont exclusivement utflisés en phase de

réalisation du système.

./ Les diagrammes comportementaux modélisent les aspects dynamiques du

système, c'est à dire les différents éléments qui sont susceptibles de subir

des modifications. Parmi eux on distingue, les diagrammes de cas

d'utilisation, de séquence, de collaboration, d'états - transitions et d'activités.

Ils représentent la dynamique du système, à savoir, non seulement les

interactions entre le système lui même et les différents acteurs du système,

mais aussi, la façon dont les différents objets contenus dans le système

communiquent entre eux

4. Diagramme de collaboration

Les diagrammes de collaboration montrent des interactions entre les différents . objets (instances de classes et acteurs). Il fait apparaître les interactions entre

les objets et les messages qu'ils s'échangent.

Dans le cadre de l'analyse, il sera utilisé d'une part pour préciser le contexte

dans lequel chaque objet évolue et d'autre part pour mettre en évidence les

Mise en place d'une plate forme de téiéservices 152


dépendances entre les différents objets impliqués dans l'exécution du

processus ou d'un cas d'utilisation.

Formalisme du diagramme de collaboration

Lettre de demande de creation/modification

Cabine! du DELGI : Classe1Organisme public

'lll- Diagramme de classes

Le diagramme de classes est une collection d'éléments de modélisation statiques,

qui montre la structure d'un modèle. Le diagramme de classes fait abstraction des

aspects dynamiques et temporels.

• Attribut: C'est une information élémentaire (propriété) composant une

classe. Un attribut peut permettre d'identifier la classe;

• Méthode: une méthode est une fonctionnalité assurée par une classe;

• Association: une association est un lien sémantique entre deux classes.

Nom Association

Min..max Min..max

• Association réflexive: une association réflexive est une association mettant

en relation une classe avec elle même.

• Classe association: une classe association est une association porteuse

d'attributs.

ClasseAssociation

-min..max Nom Association -min..max



• Multiplicité: la multiplicité est le nombre d'instances d'une classe impliquée

dans une association. Elle est la traduction d'une règle de gestion. En

général, on fait apparaître deux nombres (entiers) représentant le minimum

(min) obligatoire et le maximum autoriser (max). Parfois ces deux sont

égaux.

Pour les associations binaires la multiplicité s'exprime comme indiqué à la figure

suivante:

q1..q2~l..P2ClasseA ----------------11 ClasseB

Pour une instance de ClasseA, il y a au minimum ql instance(s) de ClasseB et au

maximum q2. De la même façon, pour une instance de ClasseS, il y a au

minimum pl instances de ClasseA et au maximum p2.

• Agrégation: C'est un type particulier d'association. Elle met en évidence une

classe agrégat et une classe agrégée. Chaque objet de la classe agrégée est

associé à un ou plusieurs objets de la classe agrégat. L'agrégation définit

une relation «tout ou partie» entre l'agrégat (le tout) et l'agrégée (la

partie).

L'agrégation est représentée par un losange clair associé à l'agrégat.

1 Classe Agrégat ~-------------IClasse Agrégée

min ..max min ..max

• Composition: C'est une forme d'agrégation qui véhicule des notions de fortes

propriétés et de la vie coïncidente des parties par rapport au tout. Dans une

composition, le tout est responsable de la mise à disposition de ses parties.

La suppression d'un objet agrégat entraîne la suppression des objets

agreges. La valeur maximale de multiplicité du conteneur ne doit pas

excéder 1 puisque les objets, instances de la classe des composants,

doivent tous appartenir au même objet conteneur.



La composition est représentée par un losange noir.

~ I Classe Agrégée 1 Classe Agrégat

1 min..max

• Généralisation/Spécialisation:

Le principe de généralisation/spécialisation permet d'identifier parmi les objets

d'une classe (générique) des sous-ensembles d'objets (des classes spécialisées)

ayant des caractéristiques spécifiques.

La généralisation est une relation entre un élément général (super-classe ou

classe mère) et un élément dérivé de celui-ci mais plus spécifique désigné par le

terme sous-classe ou classe fille. La généralisation est qualifiée de relation "est

une sorte de",

La spécialisation d'une classe permet de mettre en facteur commun certaines

descriptions, soit préciser de nouvelles contraintes sur le modèle de classes.

Classe Générique sG Pé éAttributs Communs n cé 1 r aL.~a 11

1 s

S aa Classe Spécialisée tt 1i

Attributs Spécifiques o o nn



• Polymorphisme

C'est la possibilité pour un même message de déclencher des traitements

différents, suivant les objets spécialisés auxquels il est adressé.

Formalisme du diagramme des classes

Classe générique Nom association 1

1Attributs communs: String Classe agrégat 1.-.

minl..maxl min2 ..max2 J'"1

Méthodes communes () 0 /j

, Classe

Classe spécialisée Nom association

1 Classe agrégée Attributs spécifiques: real min3 ..max3 min4 ..max4 : 11

1metnooes specmques U 1 1

Classe association

Attributs : integer

'" Diagramme des cas d'utilisations

Le diagramme des cas d'utilisation montre l'ensemble des processus du domaine

d'étude. Chaque processus, ou plus précisément, chaque variante de processus,

sera modélisée au moyen d'un diagramme d'états-transitions et/ou d'un

diagramme de séquences et/ou d'un diagramme d'activités.


1


• cas d'utilisation

Il s'agit de la solution UML pour représenter le modèle conceptuel.

Les cas d'utilisation (use cases) permettent de structurer les besoins des

utilisateurs et les objectifs correspondants d'un système.

Ils centrent l'expression des exigences du système sur ses utilisateurs: ils partent

du pnncipe que les objectifs du système sont tous motivés.

Ils se limitent aux préoccupations "réelles" des utilisateurs; ils ne présentent pas

de solutions d'implémentation et ne forment pas un inventaire fonctionnel du

système.

Ils identifient les utilisateurs du système (acteurs) et leur interaction avec le

système.

Ils permettent de classer les acteurs et structurer les objectifs du système.

Ils servent de base à la traçabilité des exigences d'un système dans un processus

de développement intégrant UML.

• Relations dans un cas d'utilisation

Les cas d'utlllsation sont liés par des relations de plusieurs types :

o Include (utilise) :

11 existe des sous ensembles communs à plusieurs processus. Pour éviter la

duplication, il est courant d'employer la relation « include », Le cas d'utilisation A

« include » le cas B signifie (A include B):

A engendre B

- A connaît B c'est-à-dire que A dépend de B

B n'existe pas tout seul et A n'existe pas sans B



o Extend (étend) :

On dit qu'un cas d'utilisation X étend un cas d'utilisation Y lorsque le cas

d'utilisation X peut être appelé au cours de l'exécution du cas d'utilisation Y.

Quand un processus B « extend » un processus A (B extend A):

A engendre B ;

B connaît A c'est-à-dire B dépend de A ;

B n'existe pas tout seul et A existe sans B.

o herite

La relation « herite » exprime l'héritage entre les cas d'utilisation. A «herite» B

signifie A peut prendre le comportement spécifié de B.

•:. Formalisme d'un cas d'utilisation

Domaine d'étude

« actor> Acteur

A\ « inclnde> 1

1

1

1 A r.tP.llT 1

« extend> 1

'V


.. Diagramme de séquence

Le diagramme de séquence montre les interactions entre les objets en mettant

l'accent sur l'aspect temporel (la chronologie des envois de messages).

Il permet de mieux visualiser la séquence des messages pour une lecture du haut

vers le bas. L'axe vertical représente le temps, l'axe horizontal représente les

objets qui collaborent. Une ligne verticale en pointillé est attachée à chaque objet

et représente sa ligne de vie.

L'utilisation du diagramme de séquence dans l'analyse a pour but de faciliter la

représentation d'un processus en se centrant sur le Workl'low et les échanges

entre acteurs ou avec le système d'information voire le système informatique. On

pourra donc l'utiliser pour représenter LIn processus existant, sans entrer dans le

détail des activités, soit pour modéliser des variantes de processus à partir d'un

processus de référence.

• Message

Un message est un moyen de communication entre objets. Ici, le message

caractérise un événement c'est-à-dire une information envoyée à un objet et

provoquant en réponse le déclenchement d'actions associées à cet objet.

Un message peut être réflexif si l'objet émetteur et l'objet récepteur appartiennent

à la même classe.

- message simple

Message dont on ne spécifie aucune caractéristique d'envoi ou de réception

particulière.

- message minuté (timeout)

Bloque l'expéditeur pendant un temps donné (qui peut être spécifié dans une

contrainte), en attendant la prise en compte du message par le récepteur.

L'expéditeur est libéré si la prise en compte n'a pas eu lieu pendant le délai

spécifié.



- message synchrone

Bloque l'expéditeur jusqu'à la prise en compte du message par le destinataire. Le

flot de contrôle passe de l'émetteur au récepteur (l'émetteur devient passif et le

récepteur actif) à la prise en compte du message.

- message asynchrone

N'interrompt pas l'exécution de l'expéditeur. Le message envoyé peut être pris en

compte par le récepteur à tout moment ou ignoré (jamais traité).

Le retour des messages asynchrones devrait toujours être matérialisé, lorsqu'il

existe.

- message dérobant

N'interrompt pas l'exécution de l'expéditeur et ne déclenche une opération chez le

récepteur que s'il s'est préalablement mis en attente de ce message .

•:. Formalisme du diagramme de séquence

un acteur un objet (une instance d'une classe)

~.J ~ : Acteur «Actor »

:übjet11 1 1

un objet créé dynamiquement~ messageSimpleO ---->~i 1 1 1 1 1 1r---- messageMinutéO ---0 >1 ~ : 1--:- créerO ---).~ «Actor» : : :Objet2r--messageSynchroneO x >: 1 1 1 1 1 1 1 1 1 1 1 1

~ messageAsynchroneO .........: 1: : }tl1 +-.1--- détruireO --- : ~! ~ ~ messageDérobantO -=-)1 l1 1 1 1 1 1 1 1 1 1 mort de l'objet

Mise en place d'une plate forme de tétésetvtces 160

Projet dejin d'étude

• Activation d'un objet

Sur un diagramme de séquence, il est aussi possible de représenter de manière

explicite les différentes périodes d'activités d'un objet au moyen d'une bande

rectangulaire superposée à la ligne de vie de l'objet. Pour représenter de manière

graphique une exécution conditionnelle d'un message, on peut documenter un

diagramme de séquence avec du pseudo code et représenter des bandes

d'activation conditionnelles.

Un objet peut être actif plusieurs fois au cours de son existence (voir exemple ci

dessus).

Le pseudo code peut aussi être utilisé pour indiquer des itérations (avec

incrémentation d'un paramètre d'un message par exemple).

«Actor» « Actor»

L :Objet1 :Objet2 bande ~ériode)

1 d'activation de l'objet

bande d'activation ...... ! 1

~.ctiYalionAsy_one()~"''''t-- _

r---. retourEXPliCiteo-.l) ......t--- fin d'activité 1 1

msgo~

u~ Recursion

ligne devie

'-----1.,.... """-,1 ~ représentation grq:Jhique d'un ~, ~ branchement conditionnel , , ,l ' " if X cas(A) 1 1

else cas(S)

~ endif 1 ,J

1 1

, ,/

1 1 /

,/

Y -, 1 1



.. Diagramme d'activités

Le diagramme d'activités permet de représenter la dynamique du système

d'information. Il est considéré comme une variante du diagramme d'états

transitions où les états sont des activités. Le diagramme d'activités est attaché à

une classe (processus, acteur ou entité), à un cas d'utilisation ou à une opération.

C'est un graphe orienté qui décrit un enchaînement de traitements. Le

déroulement ainsi présenté est appelé flot de contrôle. On peut aussi faire figurer

des objets impliqués dans les activités: la participation de ces objets à des

traitements représente un flot d'objet. L'enchaînement des activités peut être

soumis à des branchements ou à des synchronisations.

La visualisation de couloirs d'activités permet de représenter la répartition de la

responsabilité des activités entre les différents acteurs .

•:. Concepts

• Activité ou état action

Une activité représente une exécution d'un mécanisme, un déroulement d'étapes

séquentielles. C'est une opération ayant une certaine durée utilisée pour décrire le

comportement d'une classe.

• Transition

Une transition matérialise le passage d'une activité vers une autre. Les transitions

sont déclenchées par la fin d'une activité et provoquent le début d'une autre (elles

sont automatiques).

Un événement, c'est quelque chose qui a une signification pour

le domaine et pouvant se produire suffisamment fréquemment pour que l'on

puisse définir à priori le comportement à adopter. L'événement peut être

interne (il provient de l'intérieur du domaine), externe (il provient de

l'extérieur du domaine) ou temporel (expiration d'un délai ou avènement

d'une date).



Une condition de garde est une condition devant être vérifiée

pour permettre la transition. Elle est optionnelle.

Une action est une opération atomique (non interruptible)

déclenchée par une transition. Elle est optionnelle.

Notation : activité, transition

événement [garde] 1action une activité r--~------r--------3>!autre activité

Transition

• Synchronisation

Une barre de synchronisation permet d'ouvrir et de fermer des branches parallèles

au sein d'un flot d'exécution. Les transitions qui partent d'une barre de

synchronisation ont lieu en même temps. On ne franchit une barre de

synchronisation qu'après réalisation de toutes les transitions qui s'y rattachent.

Représentation graphique Barre de synchronisation

r---(ici, représente le déclenchement simultané de deux transitions)

Barre de synchronisation ---' (ici, représente la synchronisation de deux transitions)



• Branchement conditionnel ou décision

Un flot de contrôle (représentation du déroulement d'un ensemble d'activités) peut

comprendre des chemins alternatifs. Chaque branche est soumise à une condition,

qui est une condition de garde comme le montre la figure suivante.

[si ...] [sinon]

• Couloirs d'activité ou partition

Afin de décrire les acteurs responsables de chaque activité, on va dessiner une

colonne (un couloir) pour représenter chaque acteur jouant un rôle. Chaque

activité sera placée dans le couloir correspondant à l'acteur qui en est chargé.



.:. Formalisme du diagramme d'activités

(couloir 1) (couloir 2)

acteur acteur

Etat initial'--+-------------~

[sinon][si ...]

L--------~'.l<;"_____+_-------'

Etatfinal -_-1



LES MAQUETTES D'ECRAN

PAGE D'ACCEUIL

,~_lirll'er ~~Is~re ~~ <' ~~~'I'I"",""*,,,DELGI • Burklnafaso '

Au.. Mtmbl'U

Votre nom de domaine est'il diPOIÛb)p1

Rt'chedlt'I' tu" fOl1llation

PrOCl'~SUS d. demlltul. de nmn.' dt" dOLnde (.BF!

Mile A j.U>" le JJIMMJAA ê DElGI 2006 - Ce>ntactez-nou:: - Pland'..uite - N()lnreautés



INTERFACE PROPOSE POUR LE PROGRAMME EN LIGNE

~'-~~._=-~~=~r========:v~;~~;~~·~~~~! i ' IObj.ctifs:!

L. iPubllrsn"bl..

······M._····_._····· 1

Ir>w-ee dt'la fonn.tion

;'"'-"'"'"'" '"_.'""'''.._-'"~,.-._- .... ·····_···········-1 fü·u d..11 formaGo.u 1 ~ "0'--- ., , •• , •••• - ,~ ••••- ••• -._••• ...;'-.-" _-•••••" •• -.--.-"=:....-"..--h.-..;...,,H'_ ,

~;?Eiï~~::·~~~·· L::= -;;;;:~;,~~;;ji ::::::::::::::::]



INSCRIPTION D'UN PARTICULIER

DELGI

AttuMembres

M. 0 Mlle (> Mm, 0

NOIR ..

Pr,n.,.(,j·

Adreui(' •

La sl1S1e de votreadressee-mailnOUf permettrade vous répendre rapidement

Til'lephollil"

Conunenta.i1.

o J'accepte lesc:ondinons d'mscnption



INTERFACE PROPOSEE POUR LA DEMANDE DE FORMATION A TITRE EXCEPTIONNEL D'UN

ORGANISME/OSe

A<:Cf-S J\.1f-lnbres

Relereuce do responnblt d. la debuuld.

Idel\ti~ M OMIl,OMmeO

Nom·

Ienctien"

TelephoDe

.4..dnue

votreadresse e-mail nouspermettra devousrepondre pNsrapidement

Referent" de orlani:no.IOSC demandeur-

Nom'"

Nerebre d'acenb'''

l'adresse e-mail det'organisme serasouhaitable



PAGE DE CONFIRMATION DES DIFFERENTES INSCRIPTIONS

~ -. eJftJ-. ..... ~ ï ..... ' .~ l

o+':-~~':i-(ftïiiti~~;~~~!~~~~~~""iï;;;;;;~~.;';::~.o ..' .... 0...0•....0. ..00.............. ..,lrJo~i~:'-<> ..'

DELGI '. '-.1.',....

• ti}.flll,.rMtîilstè';' ,:< ~Gfj,f,W)l'I"""",-,!,

, BUrftl~Faso

"ncnum"

VeiBetcon6nner .es WOrmabons pourvoire InScription

Nom:

E-mail

DRte d'În.tliptioll:

CouflJ1l1.er vetre insoiption

code sur l'image ci-dellou,"

Cusé

Mobamed

[email protected]

LINUX

15/10106

cette ctape sert • eV'lter les mscnpaoQJ .utomatis~eB

(Jo cooprrno J

MiseAjour leJJIMMlAA ~ DELGI 2006 - Contactet-nc.uf: - Plandume • NOU"oi-eautés



BIBLIOGRAPHIE-WEBOGRAPHIE

BIBLIOGRAPHIE

1. De MERISE à UML par Nasser KETfANI, Dominique MIGNET, Pascal PARE et

Camille Rosenthal SABROUX aux Editions Eyrolles.

2. UML pour l'analyse d'un système d'information. Le cahier des charges

du maÎtre

d'ouvrage 2é édition par Chantal Morley, Jean Hugues et Bernard LeBlanc

aux Editions DUNOD, Paris, 2000, 2002.

WEBOGRAPHIE

http//www.uml.free

http://www.developpez.com

http://www.commentcamarche.net

http://www.learningtree.fr

http://www.objetdirect.com

http://www.greenstone. org

http://www.delgi.gov.bf

Mise en lace d'une plate forme de téléservices 171


Travail réalisé par Cissé Mahomadou et Ouédraogo M. Anselme� Octobre 2006�


Documents

· Ministère des Enseignements Secondaire Supérieur et Année universitaire 2005-2006 de la Recherche Scientifique (MESSRS) Université polytechnique de Bobo-Dioulasso(UPB) BP