Rapport - PFE - Gestion - Incidents - (1) Zeghari & Hamdoun 12

Etude et mise en place dun systme de GESTION
DES INCIDENTS sous le rfrentiel ITIL

Ingnierie Informatique et Rseau

Option : MIAGE
ZEGHARI KAWTAR
HAMDOUN FATIMA ZAHRA

BELASLA MEHDI
Bouing Ali

Projet : Gestion des Incidents
2

Ddicace

A nos trs chers parents

En tmoignage de notre amour et de notre gratitude pour les sacrifices
consentis notre gard

A nos frres et surs

Pour leur soutien et leur encouragement

A nos familles

Pour avoir attendu avec patience les fruits
De leur bonne ducation

A nos amis

A tous ceux qui de prs ou de loin nous sont chers

Nous ddions ce mmoire.

2010-2011
3

REMERCIEMENTS

Nous tenons vivement exprimer au travers de ce document notre profonde
gratitude au corps professoral de lEcole Marocaine des sciences de lingnieur,
E.M.S.I, pour les bases techniques qui nous ont t inculques au cours de notre
formation dingnieur et qui nous ont permis davoir une approche analytique
beaucoup plus raffine lors de notre travail dtude.

Nous remercions plus particulirement,
Mr BELASLA notre encadrent de projet, E.M.S.I, pour navoir mnag aucun
instant de ses plus prcieux temps nous aider et nous orienter tout au long de notre
projet.

Nous noublions pas dadresser notre profond remerciement aux membres du jury
Pour avoir accept juger notre travail.

A toutes celles et ceux qui de prs ou de loin ont contribu la tenue et la russite de
ce travail, veuillez trouver ici lexpression de notre reconnaissance.

4

RESUME

Dans le cadre de notre formation en ingnierie informatique et rseaux et afin de
dappliquer nos connaissances thoriques requis lors de cette formation, nous
sommes amens raliser un Projet de Fin dEtude pour le compte de lentreprise
FBPMC.

La mission principale de ce projet est ltude, la conception et la mise en place dune
application Intranet de gestion des incidents, et cela en respectant les bonnes
pratiques du rfrentiel ITIL.

Pour un bon accomplissement de la mission du projet, la dmarche du
dveloppement choisie a suivi mthode XP, suivant le standard de modlisation
UML.

Les choix technologiques on t centrs sur le langage J2EE, Struts et Hibernate en se
basant sur le modle MVC. Le travail dtude des besoins et conception sont
modliss sous le langage UML.

Le prsent rapport synthtise tout le travail que nous avon effectu dans cette
perspective.

Mots cls : Gestion des incidents, ITIL, J2EE, MVC, UML,

5

Liste des tableaux

Tableau 1 Livrable du projet
Tableau 2 phases du projet
Tableau 3 Tableau comparatif des diffrents cycles de dveloppement
Tableau 4 Etude pralable
Tableau 5 Phase danalyse et de conception
Tableau 6 Phase dimplmentation et test
Tableau 7 Phase de Dploiement et recette
Tableau 8 Risques de projet
Tableau 9 Liste des modules
Tableau 10 Prsentation du use case sauthentifier
Tableau 11 Prsentation du use case grer les incidents
Tableau 12 Prsentation du use case Rechercher Incident
Tableau 13 Prsentation du use case grer les problmes

6
Liste des Figures
Figure 1 Organigramme de la FBPMC
Figure 2 Organigramme de la DSI
Figure 3 Cycle de vie XP
Figure 4 Planning initial du projet
Figure 5 Planning Rlle du projet
Figure 6 Processus gestion des incidents
Figure 7 Cycle de vie de lincident
Figure 8 Les niveaux dun incident
Figure 9 Diagramme illustrant les acteurs du systme
Figure 10 Diagramme de use case Gestion des Incidents .
Figure 11 Diagramme squence : Sauthentifier
Figure 12 Diagramme squence : Ajouter incident
Figure 13 Diagramme de classe gestion des incidents
Figure 14 Diagramme de use case gestion des problmes
Figure 15 Diagramme de squence supprimer un problme
Figure 16 Diagramme de classe gestion des problmes
Figure 17 Diagramme de cas d'utilisation du module Gestion des interventions
Figure 18 Diagramme de classe gestion des intervenants
Figure 19 Diagramme de classe
Figure 20 Diagramme de dploiement
Figure 21 La page dauthentification
Figure 22 La page gestion des incidents
Figure 23 La page dtail du ticket
Figure 24 La page de liste de problmes
Figure 25 La page dassocier une solution n incident
Figure 26 La page de cration dun incident

7
Table de matire
INTRODUCTION GENERALE .................................................................................................... 9
CHAPITRE 1 ................................................................................................................................. 11
CONTEXTE GENERAL DU PROJET ......................................................................................... 11
1-ORGANISME DACCUEIL : FONDATION BANQUE POPULAIRE POUR LE MICRO CREDIT (FBPMC) ...................... 12
1.1 PRESENTATION ................................................................................................................................. 12
1.2 MISSIONS ........................................................................................................................................ 12
1.3 ENTITE DU STAGE (DIRECTION DU SYSTEME DINFORMATION ET ORGANISATION) ........................................... 12
1.4 ORGANIGRAMMES ............................................................................................................................. 13
2- CADRE GENERAL DU PROJET................................................................................................................... 14
3 - POURQUOI GESTION DES INCIDENTS ....................................................................................................... 14
CHAPITRE 2 ................................................................................................................................. 15
CONTEXTE GENERAL DU PROJET ......................................................................................... 15
Partie I : Primtre du projet ......................................................................................................... 16
I. BUT DU PROJET .................................................................................................................................... 16
II. OBJECTIFS DU PROJET ........................................................................................................................... 16
III. LIVRABLE DU PROJET ........................................................................................................................... 17
TABLEAU 1 : LIVRABLE DE PROJET ............................................................................................................... 17
Partie II : Conduite du projet : ....................................................................................................... 17
I. PROCESSUS DE DEVELOPPEMENT XP ........................................................................................................ 17
II. PHASES DU PROJET ............................................................................................................................. 18
III. COMPARAISON DES DIFFERENTS CYCLES DE DEVELOPPEMENT ...................................................................... 19
IV. CYCLE DE VIE DU PROJET ...................................................................................................................... 20
V. DESCRIPTION DES PHASES ..................................................................................................................... 21
IV. PLANNING PREVISIONNELLE DU PROJET .................................................................................................. 22
FIGURE 4 : PLANNING INITIAL DU PROJET .......................................................................................... 23
VII. PLANNING REEL DU PROJET : .............................................................................................................. 23
VIII. RISQUES DU PROJET : ........................................................................................................................ 24
A. EQUIPE MOE ..................................................................................................................................... 25
B.EQUIPE MOA ...................................................................................................................................... 26
CONCLUSION ..................................................................................................................................... 26
CHAPITRE 3 ................................................................................................................................. 27
GESTION DES INCIDENTS SOUS ITIL .................................................................................. 27
DE NIVEAUX DE SERVICE (SLAS) ...................................................................................................... 28
CONCLUSION ..................................................................................................................................... 33
CHAPITRE 4 ................................................................................................................................. 34
CAHIER DES CHARGES ............................................................................................................ 34
1) OBJECTIFS DE LOUTIL GESTION DES INCIDENTS ................................................................ 34
CONCLUSION ..................................................................................................................................... 38
CHAPITRE 5 ................................................................................................................................. 39
ETUDE DES BESOINS ................................................................................................................ 39
8
1- Prsentation du langage de modlisation UML : .................................................................. 39
3. EXPLORATION ........................................................................................................................... 41
TABLEAU 9 : LISTE DES MODULES ...................................................................................................... 41
4 LES ACTEURS DU SYSTEME .............................................................................................................. 41
6 Modules et Fonctionnalits principale du systme : ................................................................... 42
FIGURE 15 : DIAGRAMME DE SEQUENCE SUPPRIMER UN PROBLEME ................................................. 50
FIGURE 17 : DIAGRAMME DE CAS D'UTILISATION DU MODULE GESTION DES INTERVENTIONS ........ 51
DIAGRAMME DE CLASSE GESTION DES INTERVENANTS : .................................................................. 52
Figure 18 : Diagramme de classe gestion des intervenants ........................................................... 52
6 Diagramme de classes Global ...................................................................................................... 52
CONCLUSION : .................................................................................................................................. 53
CHAPITRE 6 ................................................................................................................................. 54
REALISATION ............................................................................................................................. 54
LE DIAGRAMME DE DEPLOIEMENT PERMET DE VISUALISER LES ETAPES PRINCIPALES DU PROJET, IL DECRIT LA
DISTRIBUTION LAPPLICATION GESTION DES INCIDENTS ....................................................................... 55
2. TECHNOLOGIES UTILISES : ..................................................................................................................... 55
ENVIRONNEMENTS DE DEVELOPPEMENT ......................................................................................... 55
3. PRESENTATION DES INTERFACES DE LAPPLICATION : ................................................................................... 59
AUTHENTIFICATION : ............................................................................................................................... 59
ECRAN DES TICKETS : ................................................................................................................................ 60
* .......................................................................................................................................................... 61
FIGURE 22: LA PAGE GESTION DES INCIDENTS .................................................................................. 61
ECRAN DE DETAILS DES TICKETS : ................................................................................................................ 61
CONCLUSION ET PROSPECTIVES: ........................................................................................ 64
BIBLIOGRAPHIE .................................................................................................................................. 66
WEBOGRAPHIE................................................................................................................................... 67
- HTTP://STRUTS.APACHE.ORG .................................................................................................. 67
- HTTP://WWW.LEARNTECHNOLOGY.NET ................................................................................ 67
- HTTP://WWW.VAANNILA.COM ............................................................................................... 67
- HTTP://WWW.ROSEINDIA.NET/STRUTS2 ................................................................................ 67

9
Introduction gnrale

ITIL (Information Technology Infrastructure Library) est un rfrentiel dcrivant un
ensemble de processus de gestion de services technologiques utiliss par le mtier. Il
est focalis sur les processus de production, et ne couvre pas les processus de
dveloppement, de gestion de projet, ou encore de Gouvernance.
La gestion des incidents reste toujours le domaine le plus exploitable et pratiqu de
ce rfrentiel, voir le succs que prsente son application dans les diffrentes entits
de production et de helpdesk.
Dans ce cadre, notre mission sinscrit dans la mise en uvre dune solution
informatique susceptible qui consiste voluer et adapter un outil de gestion des
incidents suivant la norme ITIL. Et cela pour le service de la BPPMC.
L'objectif de ce projet est de mettre en pratique et dappliquer les tapes et les
spcifications dcrites dans le rfrentiel ITIL en termes de gestion des incidents,
travers ltude, la conception et la mise en place dune Intranet de gestion des
incidents pour le compte dune socit de service en ingnierie informatique.
Le prsent document rapport lessentiel de la mission du projet, il sorganise ainsi :
Le premier chapitre : a pour but de dfinir lorganisme daccueil ,nous allons
prsenter cet organisme, son organigramme ainsi que sa mission, fin dclaircir
lenvironnement du projet, nous allons prsenter finalement le cadre gnral du
projet.
Le deuxime chapitre : nous allons prsenter le primtre du projet, les livrables, les
risques, ainsi que le choix mthodologique adopt, et le planning suivi.
Le troisime chapitre: est consacr la Gestion des incidents sous la rfrence ITIL
Le quatrime chapitre : est consacr la dfinition du dfrent module de notre
application ainsi que les rgles de gestion de la gestion des incidents.
Le cinquime chapitre: est consacr lanalyse et la conception de lapplication et
nous prsentons ensuite les diffrents acteurs du systme et les diagrammes UML.
10
Le sixime chapitre : est consacr pour la partie ralisation du projet, nous
commencerons par dcrire l'architecture de dploiement, les outils et les Framework
utiliss pour ce dveloppement et enfin quelques interfaces.

11

Chapitre 1
Contexte gnral du projet
Le prsent chapitre a pour but de dfinir lorganisme
daccueil nous allons prsenter cet organisme, son
organigramme ainsi que sa mission, fin dclaircir
lenvironnement du projet, nous allons prsenter
finalement le cadre gnral du projet.
12
1-ORGANISME DACCUEIL : FONDATION BANQUE
POPULAIRE POUR LE MICRO CREDIT (FBPMC)

1.1 Prsentation

La Fondation Banque Populaire est une filiale du groupe Banque Populaire, cest une
association but non lucratif, ayant pour objectifs principaux le dveloppement et la
distribution de micro crdits. Elle a t cre en juin 1998 aprs avoir obtenu
lagrment par dcret ministriel.

La FBPMC constitue une rponse citoyenne du Groupe Banque Populaire qui vise
contribuer efficacement, aux cts de lEtat et dautres organisations non
gouvernementales leffort national de lutte contre la pauvret et le chmage et
promotion de lemploi.

1.2 Missions
Grce cette politique de proximit et son programme jumel
financement/accompagnement, la Fondation se fixe trois objectifs :
- Favoriser le dveloppement et la modernisation des units productives
soutenue par son programme.
- Faciliter le passage progressif de ces units du secteur informel vers le
secteur organis de lconomie.
- Concourir la bancarisation des clients.

1.3 Entit du stage (Direction du Systme dInformation et Organisation)

- La DSI est compose de trois dpartements : Dpartement Technique et
exploitation, Dpartement Organisation et Dpartement Etude et
dveloppement, au sein de ce dernier que jai effectu mon stage.
- Ce dpartement a pour objectif de dvelopper et optimiser les modules
du progiciel afin de rpondre aux besoins fonctionnels des branches.

13
1.4 Organigrammes
a) Lorganigramme de le FBPMC :

Figure 1 : Organigramme de la FBPMC

b) Organigramme de la DSI

14
Figure 2 : Organigramme de la DSI

2- CADRE GENERAL DU PROJET

Quelles que soient la qualit du systme dinformation mis en place dans lentreprise
ou les comptences des techniciens qui lexploitent, des incidents se produiront. Ces
incidents ont toujours un effet important sur la confiance que les utilisateurs
accordent lquipe qui gre ce systme dinformation.
La manire de grer ces crises et la rapidit de leur rsolution est un rvlateur de
la maturit de lquipe informatique. Cest pourquoi limplantation du processus qui
gre ces incidents, vritable fer de lance du centre de services, est particulirement
importante.
3 - Pourquoi Gestion des incidents

Minimiser limpact ngatif sur les activits de lentreprise des Incidents et Problmes
causs par des erreurs dans linfrastructure informatique et Prvenir la rapparition
des Incidents induites par ces erreurs selon ITIL
Conclusion :
Dans ce chapitre, jai mis laccent sur la prsentation de la socit. Dans le
chapitre suivant, je vais vous prsenter le primtre ainsi que le cadre gnral
du projet.

15

Dans ce chapitre nous allons prsenter le primtre du
projet, les livrables, les risques, ainsi que le choix
mthodologique adopt, et le planning suivi.

Chapitre 2
Contexte Gnral du projet
16
Partie I : Primtre du projet

I. But du projet

Lobjectif de Ce projet est la mise en place une application
Intranet de Gestion des incidents, dont lobjectif est de grer les interventions et les
solutions des problmes afin de restaurer une activit normale le plus rapidement
possible, afin de minimiser les interruptions de service au sein de lentreprise et
damliorer la qualit du service pour le compte de la DSI de la FBPMC, et Suivant le
rfrentiel ITIL, ladite application devra couvrir les modules suivants :
La gestion des incidents
La gestion des problmes
La gestion des interventions
La gestion des utilisateurs

II. Objectifs du projet

Lintitul de notre projet est La conception et la ralisation dune application de
Gestion des incidents selon le rfrentiel ITIL .
Les grands points du projet sont :
Etude comparative entre les diffrents logiciels du march.
Etude technique du portail existant.
Llaboration des dossiers de spcifications gnrales et dtailles.
Ralisation de lapplication
Tests.
Documentation
Dveloppement des dfrentes module savoir : la Gestion des incidents,
la Gestion des interventions, la Gestion de configuration, la Gestion de
changement, la gestion des problmes.

17

III. Livrable du Projet

Phase Livrable Responsable
Date de
livraison
prvue
Date de
livraison relle
Date
validation
prvue
Avant projet Plan de qualit projet &
Hamdoun &
Zeghari
18/06/2011 22/06/2011 22/06/2011
Etude pralable
Cahier des charges
Dossier de
spcifications gnrales
Hamdoun &
Zeghari
25/06/2011 30/06/2011 02/07/2011
Analyse et
Conception
Dossier des
spcifications dtailles.
Dossier de conception.
Hamdoun &
Zeghari
13/07/2011 27/07/2011 27/07/2011
Implmentation et
test
Code source.
Hamdoun &
Zeghari
29/07/2011 02/09/2011
Tableau 1 : Livrable de projet

Partie II : Conduite du projet :

I. processus de dveloppement XP

Chaque attente du client peut tre atteinte indpendamment des autres.
L'utilisation d'un cycle de vie permettant de dvelopper chacun des modules de bout
en bout sparment est donc approprie. Le produit final sera donc livr par lots,
chaque lot sera dvelopp, test et affin avant lintgration finale. La mthode
choisie est XP.

18
Figure 3 : Cycle de vie XP

II. Phases du Projet

Voici pour chaque tape du cycle de vie XP les documents requis et produits,
ainsi que les conditions de passage dune tape une autre.

Phases Activits
Exploration Dfinir les fonctionnalits du logiciel, et rdiger des
besoins sous forme de "user stories" et estimation de leur
dure.

Planning Runion entre client et dveloppeurs pour dterminer les actions
mettre en uvre et estimer leurs dures.
Ralisation Elle prend en charge le suivi des tches, ainsi que les activits
d'analyse du besoin, de conception, d'implmentation et de test
correspondantes.
Production Clture ditration aprs le dploiement du logiciel chez le client et
en cas ditration restante retourn la phase planning.
Tableau 1 : phases du projet

19

III. Comparaison des diffrents cycles de dveloppement

Pour justifier le choix du cycle de dveloppement vue le nombre de
mthodes qui existent : RUP, 2TUP, XP, Cascade. Nous avons mis en place
un tableau comparatif des principaux processus utiliss dans le
dveloppement logiciel

Descriptions Points forts Points
faibles
Processus
RUP

- Promu par Rational
Le RUP est la fois une
mthodologie et un outil
prt lemploi
- Cible des projets de plus
de 10 personnes

- Itratif
- Spcifie le dialogue
entre les diffrents
intervenants du
projet - Propose des
modles de
documents, et des
canevas pour des
projets types
- Coteux
personnaliser
- Trs ax processus,
au dtriment du
dveloppement
Processus XP

- Ensemble de Bests
Practices de
dveloppement
- Cible des projets de
moins de 10 personnes

- Itratif
- Simple mettre en
uvre
- Fait une large place
aux aspects
techniques
- Innovant

- Ne couvre pas les
phases en amont et
en aval au
dveloppement -
lude la phase
danalyse, si bien
quon peut dpenser
son nergie faire et
dfaire
- Assez flou dans sa
mise en uvre
Processus
2TUP

- Sarticule autour de
larchitecture
- Propose un cycle de
- Itratif
- Fait une large place
la technologie et
- Plutt superficiel
sur les phases situes
en amont et en aval
20
dveloppement en Y
- Dtaill dans UML en
action
- Cible des projets de
toutes tailles

la gestion du risque
- Dfinit les profils
des intervenants, les
livrables, les
plannings, les
prototypes

du dveloppement :
capture des besoins,
support,
maintenance, gestion
du changement - Ne
propose pas de
documents types
Tableau 3 : Tableau comparatif des diffrents cycles de dveloppement

IV. Cycle de vie du projet

La planification du projet doit faire lobjet dun document formel, approuv et utilis
pour diriger la fois l'excution et le contrle du projet. Il est principalement utilis
pour documenter les hypothses et dcisions relatives la planification, faciliter la
communication entre les parties permanentes et documenter les planifications
initiales.
Les phases du cycle de vie du projet sont les suivantes :

Phase dEtude pralable :
Cette phase dmarre par une identification et planification du projet, qui
consiste collecter les besoins fonctionnelles et techniques. Aussi une
identification et justification des choix techniques adopter pour la ralisation
des deux formes de lapplication. De plus quune tape de formation et
familiarisation avec les nouvelles technologies utiliser. Cette phase se termine
par une laboration dun PQP, un dossier de lexistent et un dossier technique
du projet.

Phase danalyse et Conception :
Dans cette phase, on dfini les acteurs et fonctionnalits du systme futur,
suivie dune spcification dtaille des diffrents processus dutilisation. Elle se
terminera par une laboration dune architecture dynamique (diagrammes de
squences) et statique (diagramme de classes) du systme.

21
Phase dimplmentation et test :
Elle contient le codage de toutes les fonctionnalits du projet, tests et
optimisation du code.

Phase de dploiement et recette :
Cest la phase o on met en production notre application dans son
environnement cible.

V. Description des phases

Etude pralable
Phase dtude pralable
Objectifs
Extraire les besoins du client
Dfinir toutes les rgles de gestions appropries aux
besoins demands.
Validation de la comprhension de lapplication
Livrables en sortie
Planning de suivi
Dossier de spcifications gnrales.
Critres de fin de
phase
Comprhension fonctionnelle et technique de lapplication.
Tableau 4 : Etude pralable
Phase danalyse et de conception
Objectifs
Appropriation fonctionnelle et technique de lapplication
Validation de la comprhension de lapplication
Ralisation de la spcification dtaille de tous les modules
en charge.
22
Phase danalyse et de conception :

Tableau 5 :Phase danalyse et de conception
Phase dimplmentation et test
Phase dimplmentation et test
Objectifs
Codage des modules spcifiques pour respecter la mthode
RUP ensuite passer aux modules suivants.
Recette de lapplication pour la dtection des anomalies.
Livrables en sortie Rapport de test
Critres de fin de
phase
Livraison du manuel dutilisateur.
Tableau 6 : Phase dimplmentation et test

Phase de Dploiement et recette
Phase de dploiement et recette
Objectifs
Assistance la mise en place en production
Correction des anomalies constates
Livrables en sortie Code source
Critres de fin de
phase
Fin de la priode du projet.
Tableau 7 : Phase de Dploiement et recette

IV. Planning Prvisionnelle du projet

Le projet sest droul en plusieurs tapes successives comportant des points de
validation chaque fin de tche

Livrables en sortie
Dossier de spcifications fonctionnelles et techniques
Critres de fin de
phase
Livraison dun dossier de spcification dtaille qui
prpare au dveloppement.
23

Figure 4 : Planning initial du projet

VII. Planning Rel du projet :

Le planning rel reflte le droulement rel des phases et taches du projet, ainsi subi
aux diffrentes contraintes du projet :

24

Figure 5: Planning Relle du projet

VIII. Risques du projet :

Risque Impact solution
Non-respect
des dlais
Le projet ne sera pas
achev dans la date
prvue, on peut avoir
un retard dans la
livraison de
-Doubler leffort et ajuster le
planning pour respecter la
planification faite au
dpart.

25
l'application

Les pannes
inattendues du
matriel
Ralentissement des
travaux

Utiliser les autres matriaux
disponibles.
-Recours une rparation rapide

Absence ou
maladie
Ralentissement des
travaux
Doubler leffort et travailler un
temps extra.
Insatisfaction
du client
Echec du projet

Prvoir des runions et des
points de validation avec le client
au fur et
mesure de lavancement du
projet

Tableau 8 : Riques de projet

IX. Organisation du Projet
a. Equipe MOE
Nom Fonction / rle pour le projet Mail
Hamdoun
Fatimazahra
Zeghari kawtar
Ingnieur tudes et dveloppement
Ingnieur tudes et dveloppement
Hamdoun.fatimazahra@gmail.com

Ingnieurs dveloppement :
- Elaborer le dossier de gestion de projet.
- Ralisation de la spcification dtaille.
- Codage de lapplication (contrle et modules spcifiques).
- Effectuer les tests unitaires
- Dploiement de lapplication,
26

b.Equipe MOA

Nom Fonction / rle pour le projet Mail
Banouig Ali

Chef Projet Banouig@hotmail.com

Le chef de projet MOA:
Valide le dossier des spcifications fonctionnelles.
Valide le codage et la recette.
Prsentation des besoins fonctionnels du projet.
Valide les livrables.
Contrle le respect des demandes.

Conclusion

Dans ce chapitre nous avons dfini les tapes que nous avons suivies pour la mise en
uvre du projet en dcrivant la mthode de dveloppement et en fournissant un
planning pour la ralisation de lextranet.

27

Nous avons consacr ce chapitre la Gestion des incidents
sous la rfrence ITIL
Chapitre 3
Gestion des incidents sous ITIL
28
1 Objectif
La dfinition ITIL de l'objectif de la Gestion des Incidents est la suivante :
Restaurer aussi vite que possible le fonctionnement normal des services et minimiser
limpact ngatif sur les activits
Mtiers et sassurer ainsi que les meilleurs niveaux de qualit de service et de
disponibilit sont maintenus.
Le fonctionnement normal des services sentend ici comme le fonctionnement des
services dans les limites des Contrats
De Niveaux de Service (SLAs)

2 Primtre
2.1 Dfinition dun Incident et extensions

La dfinition ITIL d'un Incident est la suivante :
Tout vnement qui ne fait pas partie du fonctionnement standard dun service et
qui cause, ou peut causer, une interruption ou une diminution de la qualit de ce
service.
Quelques exemples :

Application: application non disponible, erreur programme empchant
lUtilisateur de travailler, nombre d'E/S disques excessifs
Matriel: systme HS, remonte dalerte automatique, sortie imprimante
bloque
Demandes de services : demande dinformation, de conseil ou de
documentation, oubli dun mot de passe

2.2 Extensions de la dfinition

Le terme Incident est gnralement compris comme un dysfonctionnement signal
par un Utilisateur. Cependant, deux extensions cette dfinition sont gnralement
utilises car elles vont suivre le mme processus de traitement que les
dysfonctionnements proprement dits et sont donc assimils des Incidents :

29
Les demandes pour un nouveau service (ou lextension dun service existant)
sont considres comme des demandes de Changement (RFCs) mais
assimiles des incidents en pratique (traitement identique) et traites dans
le cadre de la Gestion des Incidents
Les Remontes dalertes automatiques (espace-disque satur par exemple) :
elles sont souvent considres Comme faisant partie de lexploitation
courante ; ces vnements sont traits dans le cadre de la Gestion des
incidents mme si le service dlivr aux Utilisateurs nest pas affect

2.3 Processus de Gestion des Incidents

Figure 6 : Processus gestion des incidents

En entre du processus, nous retrouvons :

Dtails des Incidents (du Centre de Services et des diffrentes sources
automatiques)
Dtails des Configurations (de la CMDB)
Recherche correspondances (matching) entre Incidents et Problmes &
Erreurs connues (de la base de donnesProblmes/Erreurs Connues)
Dtails de la rsolution de lIncident de nature similaire (de la mme base)
Retour des Demandes de Changement en correction dun Incident (du
processus Gestion des Changements)
30

En sortie du processus, nous avons :

Routage des demandes de services
Demandes de Changement pour rsoudre certains Incidents
Mise jour de la base des Problmes/Erreurs Connues
Communication aux Utilisateurs (pendant lavancement et la
fermeture)
Rapports la hirarchie

Dans le processus, les activits de la Gestion des Incidents sont les suivantes :

Dtection et enregistrement des Incidents
Support initial et classification
Investigation et diagnostic
Suivi global des Incidents
Rsolution et rtablissement
Fermeture des Incidents

3 Concepts de base
3.1 Cycle de vie dun Incident

31

Figure 7 : Cycle de vie de lincident

Le cycle de vie d'un Incident est le suivant :

Quelques remarques :

Le Centre de Services est responsable de laboutissement de tous les
Incidents enregistrs (propritaire des incidents).
Le processus de traitement est essentiellement ractif.
Les Incidents ne pouvant pas tre rsolus immdiatement doivent tre
assigns aux groupes de spcialistes.
La rsolution ou une solution de contournement doit intervenir le plus
vite possible pour rtablir le service impact

3.2 Cycle de vie dun Incident : Prconisations

Tout au long du cycle de vie de lIncident, lenregistrement doit tre jour pour
permettre nimporte quelle personne de lquipe du Centre de Services de
communiquer sur lIncident simplement en consultant l'enregistrement.
32
Il est ncessaire de conserver la description originelle de lIncident mme si la
description en cours volue. Par exemple, un Utilisateur signale un Incident avec son
imprimante (son dition ne s'imprime pas). Aprs investigation, il s'agit en ralit
d'un problme rseau mais, lorsque l'Incident est clos, il est prfrable que le Centre
de Services prvienne l'Utilisateur simplement en lui prcisant que son problme
imprimante est rgl plutt que de lui expliquer le problme rseau et sa rsolution.
Il faut aussi conserver un historique des modifications sur lenregistrement de
lIncident. Tous les changements d'tat doivent tre tracs (date/heure, personne qui
a provoqu le changement, etc.) Si lune des quipes na pas accs loutil de Gestion
des Incidents, il est impratif de bien mettre en place une procdure de
Mise jour de ces enregistrements faire lors des interventions de ces quipes (par
exemple: maintenance tierce ou support de nuit nayant pas accs loutil durant la
nuit)

3.3 Premier, deuxime et troisime niveaux de support

Voici un schma (classique) d'escalade d'un Incident sur les diffrents niveaux de
support, commencer par le Centre de services :

Figure 8 : Les niveaux dun incident

33

Il est noter que certains niveaux de support peuvent tre des socits extrieures
(externalisation du support ou appel aux constructeurs/diteurs dans le cadre de
contrats de support passs entre l'entreprise et ces socits extrieures).

Conclusion

Dans ce chapitre nous avons dfini le cycle de vie, le processus de gestion des
incidents.

34

1) Objecti
fs de
loutil
Gestion des incidents

L'objectif de la gestion des incidents est la remise en service des applications, dans les
dlais les plus courts, en minimisant limpact sur les utilisateurs.
Permet d'avoir un suivi fidle du parc informatique tant au niveau logiciel
que matriel
Gre les tickets (demandes dintervention ou incidents informatiques) suivant
la procdure de gestion des incidents
Nous avons consacr ce chapitre la dfinition du dfrent
module de notre application ainsi que les rgles de gestion
de la gestion des incidents.
Chapitre 4
Cahier des charges
35
Le cycle de vie de l'incident et les tapes de la gestion des incidents sont les
suivantes :
Dtection et enregistrement
Classification et support initial
Investigation
Rsolution
Clture

Notre outil sera excut sur un navigateur web (Intranet) dvelopp avec J2ee
(HIBERNET) li une base de donnes MySQL.

Les acteurs seront : un administrateur, intervenant, Agent
2) Les fonctions
Une fonction est un ensemble d'actions ou de privilges indpendants et qui
sera affecte aux acteurs dfinis par l'institution en fonction de leurs rles.
Elles peuvent tre regroupes en 5 sous ensembles qui sont :

La gestion des intervenants
La gestion des changements
La gestion de problme
La gestion des configurations

La gestion des changements

Lorsqu'un Changement est rendu ncessaire, il faut valuer les risques de sa mise en
uvre et la continuit de lactivit mtier
Pendant et aprs cette mise en uvre.
36
Il est essentiel pour trouver un quilibre entre la ncessit dun Changement et
limpact (ngatif) de ce Changement
Les qualits indispensables pour lisser les transitions sont les suivantes :
avoir des rseaux dinformation (grande visibilit sur la production et
lactivit)
avoir des rseaux de communication

La gestion des configurations

La qualit de service de la Production informatique doit tre fournie au moindre cot
et le contrle sur linfrastructure et les Services est impratif.
Le processus fournit un modle logique de linfrastructure en identifiant, contrlant,
maintenant et vrifiant les diffrents lments au cours de leur dure de vie.
Les objectifs pratiques qui en dcoulent sont les suivants
rendre compte lorganisation de tous les biens et configurations de la
Production Informatique
fournir de linformation pertinente sur les configurations pour supporter les
autres processus
fournir des bases solides pour la Gestion des Incidents, des Problmes, des
Changements et des Nouvelles Versions
comparer linformation stocke linfrastructure et corriger les diffrences


Restaurer aussi vite que possible le fonctionnement normal des services et minimiser
limpact ngatif sur les activits Mtiers et sassurer ainsi que les meilleurs niveaux
de qualit de service et de disponibilit sont maintenus.

3) Rgles de gestion
37

Lagent saisie le ticket et lenvoie ladministrateur.
Ladministrateur traite le ticket et lenregistre comme un incident
Ladministrateur envoie lincident lintervenant pour la traiter.
Lintervenant traite lincident et enregistre le problme de lincident et
la solution et indique ltat du traitement de lincident.
Aprs la rsolution de lincident lintervenant envoie
ladministrateur un e-mail.
Ladministrateur valide la rsolution de lincident et clture lincident.

4) Exigences non fonctionnels
L'interface a t cre de faon tre sobre, agrable et fonctionnelle. Plus
gnralement, elle rpond aux normes d'ergonomie connues pour les interfaces
homme-machine.
Charge de travail :
L'interface prsente un nombre rduit d'informations. Tout ce qui est utile
est crit et tout ce qui est crit est utile.
Homognit :

Le site prsente une complte homognit de sa prsentation. En effet, le
fond est toujours le mme, le menu principal en haut est statique, celui au
dessous volue mais est toujours situ au mme endroit et a toujours la mme
signification. Chaque type d'information se situe toujours la mme place, ce
qui simplifie la navigation en permettant une prise en main rapide.
Guidage :
Les types de contenu sont tous regroups entre eux : le menu gnral dans un
cadre en haut, le contenu dans un cadre au milieu avec tous les rappels
concernant l'utilisateur et sa navigation.
Signifiance et dnominations :
Les menus ou liens sont nomms de faon trs explicite, de faon ce que
l'utilisateur comprenne trs bien de quoi il s'agit. Les noms sont trs courants
38
et comprhensibles par tous.
Conclusion

Dans ce chapitre nous avons dfini le besoin fonctionnel et technique.

39

1- Prsentation du langage de modlisation UML :

UML (Unified Modeling Language traduit en franais par "langage de modlisation
objet unifi") est n de la fusion des trois mthodes qui ont le plus influenc la
Chapitre 5
Etude des besoins
Nous avons consacr ce chapitre lanalyse et la
conception de lapplication et nous prsentons ensuite les
diffrents acteurs du systme et les diagrammes UML.
40
modlisation objet au milieu des annes 90 : OMT, Booch et OOSE. Fruit d'un travail
d'experts reconnus, UML est le rsultat d'un large consensus. De trs nombreux
acteurs industriels de renom ont adopt UML et participent son dveloppement.
Il y a donc dj longtemps que l'approche objet est devenue une ralit. Les concepts
de base de l'approche objet sont stables et largement prouvs. De nos jours,
programmer "objet", c'est bnficier d'une panoplie d'outils et de langages
performants. L'approche objet est une solution technologique incontournable. Ce
n'est plus une mode, mais un rflexe quasi-automatique ds lors qu'on cherche
concevoir des logiciels complexes qui doivent "rsister" des volutions incessantes.
UML est un langage de modlisation objet trs puissant qui donne une dimension
mthodologique l'approche objet et qui permet de mieux matriser sa richesse.
Il permet de :
Reprsenter des concepts abstraits (graphiquement par exemple) ;
Limiter les ambiguts (parler un langage commun, au vocabulaire
prcis, indpendant des langages orients objet) ;
Faciliter l'analyse (simplifier la comparaison et l'valuation de
solutions).
Lapplication dune dmarche d'analyse et de conception objet, va permettre dviter
deffectuer une analyse fonctionnelle et de se contenter d'une implmentation objet,
mais il pousse penser objet ds le dpart. En plus, il permet de dfinir les vues qui
permettent de dcrire tous les aspects d'un systme avec des concepts objets.
UML permet donc de modliser une application selon une vision objet, en possdant
plusieurs facettes. C'est une norme, un langage de modlisation objet, un support de
communication et un cadre mthodologique. UML est tout cela la fois, ce qui
semble d'ailleurs engendrer quelques confusions.

2. Expressions des besoins
Une bonne expression des besoins est indispensable la ralisation ou lintgration
dune solution informatique russie. Pour russir une expression des besoins
41
pertinente et comprhensible lutilisation de dmarches et de mthodes spcifiques
est souhaitable.
3. Exploration

Le tableau suivant regroupe les diffrents modules :

Module Description
Incidents
Ce module permet de grer les incidents crer par
les Agents et affects aux intervenants.
Intervention
Ce module gre et garde la traabilit des
interventions raliss par les intervenants.
changements
Lorsqu'un Changement est rendu ncessaire, il faut
valuer les risques de sa mise en uvre et la
continuit de lactivit mtier

configurations
La qualit de service de la Production informatique
doit tre fournie au moindre cot et le contrle sur
linfrastructure et les Services est impratif.

problmes
Minimiser limpact ngatif sur les activits de
lentreprise des Incidents et Problmes causs par
des erreurs dans Linfrastructure informatique et
Prvenir la rapparition des Incidents induites par
ces erreurs

Tableau 9 : Liste des modules

4 Les acteurs du systme
Les acteurs qui interagissent avec lapplication sont :
Acteurs humains :

Agent.
Intervenant.
Administrateur.

Acteurs systme :
42
Aucun acteur systme nest identifi.
Nant

Figure 9 : Diagramme illustrant les acteurs du systme

6 Modules et Fonctionnalits principale du systme :
Cette partie est rserve lnumration des modules ainsi qu la description des
diffrentes fonctionnalits que la gestion des incidents doit assurer. Une analyse
profonde du dossier de spcification gnral et dtaill des utilisateurs, et suite aux
runions avec nos encadrant, nous a men dgager les modules de notre
application ainsi que leurs fonctionnalits.
A Module gestion des Incidents :

Cette partie permet de lister lensemble des fonctionnalits du module gestion des
Incidents :

Cration dune nouvelle Incidents.
Recherche Incident.
Modification dune Incident.
Suppression dune Incident.
Uti l i sateur
Agent Intervenant Admi ni strateur
43
Validation dune Incident.
Consulter la liste des Incidents.

Figure 10 : Diagramme de use case Gestion des Incidents .

Descriptions des cas dutilisations :
Nom Sauthentifier
Objectif Lutilisateur saisie son login et son mot de passe pour accder
au systme. Sil fait une erreur il est renvoy la page
dauthentification, autrement il accde son espace.
Acteurs
principaux
Intervenant, Agent, Administrateur
Acteurs
secondaires
---
Pr conditions Lutilisateur nest pas authentifi
Exceptions Utilisateur dsactiv
<<extends>>
<<i nl ucde>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
<<extends>>
Admi ni strateur
Gestion des Incidents
Sui vi d'i nci dent
Consul ter Inci dent
Agent
Intervenant
Aj outer un ti cket
Annul er un ti cket
Modi fi er un ti cket
Modi fi er i nci dent
Suppri mer i nci dent
Aj outer Inci dent
Edi ter un ti cket
<<extends>>
<<extends>>
<<extends>>
S'authenti fi er
Rechercher Inci dent
44
Flot dvnements 1. Lutilisateur saisi son login et son mot de passe
2. Le systme vrifie la validit des coordonnes saisies
2.1. Si les donnes sont correctes, lutilisateur accde son
espace
2.2. Sinon, laccs est refus et lutilisateur est pri de
recommencer
Post condition Lutilisateur est authentifi
Tableau 10 :Prsentation du use case sauthentifier

Nom Grer Incident
Objectif Lutilisateur ajoute une incident, la modifie, et supprime une
incident sil possde les droits appropris dans le cas o il
sagit dun utilisateur autre que ladministrateur.
Acteurs
principaux
Administrateur
Acteurs
secondaires
---
Pr conditions Lutilisateur est authentifi et possde les droits.
Flot dvnements 1. Lutilisateur consulte la liste des incidents
2. Lutilisateur modifie lincident
3. Lutilisateur supprime un incident sil a le droit de
suppression
4. Lutilisateur ajoute une exigence
4.1 Le systme vrifie le non duplication du nom de lincident
4.1.1 Si duplication, informer lutilisateur et recommencer
4.1.2 Sinon, enregistrer les donnes
Post condition ---
Tableau 11 :Prsentation du use case grer les incidents

Nom Rechercher Incident
Objectif Lutilisateur recherche un incident.
Acteurs principaux Administrateur, Intervenant
Acteurs
secondaires
---
Pr conditions Lutilisateur est authentifi.
45
Flot dvnements Lutilisateur recherche un incident
Post condition ---
Tableau 12 :Prsentation du use case Rechercher Incident

Diagramme de squence systme Sauthentifier :

Figure 11 : Diagramme squence : Sauthentifer

Diagramme de squence systme Ajouter incident :
46

Figure 12 Diagramme squence : Ajouter incident

47
Diagramme de classe du module gestion des incidents :
Figure 13 : Diagramme de classe gestion des incidents

B Module gestion des problmes :

Cette partie permet de lister lensemble des fonctionnalits du module gestion
des problmes :
Cration dun nouveau problme.
Modification dun problme.
Suppression dun problme.
Consulter la liste des problmes.

0..*
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
0..*
1..1
1..*
Uti l i sateur
-
-
-
-
Id_user
Logi n
E mai l
Tel
: i nt
: Stri ng
: Stri ng
: Stri ng
+
+
<<Getter>>
<<Setter>>
getId_user ()
setId_user (i nt newId_user)
...
Intervenant
-
-
-
Nom
Prenom
Nbr_aff_encours
: Stri ng
: Stri ng
: i nt
+ <<Getter>> getNom ()
...
: Stri ng
Agent
-
-
-
Nom
Prenom
Agence
: Stri ng
: Stri ng
: Stri ng
+
+
<<Getter>>
<<Setter>>
getNom ()
setNom (Stri ng newNom)
...
Inci dent
-
-
-
-
-
Id_i nci dent
Descri pti on
Type
Date_recl amati on
Date_cl oture
: i nt
: Stri ng
: Stri ng
: Date
: Date
Catgori e
-
-
Id_categori e
Nom_cat
: i nt
: Stri ng
EtatInci dent
-
-
Id_etat
Inti tul e_etat
: i nt
: Stri ng
Pri ori tInci dent
-
-
Id_pri ori t
Inti tul epri ori te
: i nt
: Stri ng
ti cket
-
-
num_msg
Nom_msg
: i nt
: Stri ng
48
Figure 14: Diagramme de use case gestion des problmes

Descriptions des cas dutilisations :

Nom Sauthentifier
Objectif Lutilisateur saisie son login et son mot de passe pour accder
au systme. Sil fait une erreur il est renvoy la page
dauthentification, autrement il accde son espace.
Acteurs
principaux
Intervenant, Administrateur
Acteurs
secondaires
---
Pr conditions Lutilisateur nest pas authentifi
Flot dvnements 1. Lutilisateur saisi son login et son mot de passe
2. Le systme vrifie la validit des coordonnes saisies
2.1. Si les donnes sont correctes, lutilisateur accde son
espace
2.2. Sinon, laccs est refus et lutilisateur est pri de
recommencer
49
Post condition Lutilisateur est authentifi
Tableau 13 :Prsentation du use case grer les problmes

Nom Grer Les problmes
Objectif Lutilisateur ajoute un problme, le modifie, et supprime un
problme sil possde les droits appropris dans le cas o il
sagit dun utilisateur autre que ladministrateur.
Acteurs
principaux
Administrateur
Acteurs
secondaires
---
Flot dvnements 1. Lutilisateur consulte la liste des problmes
2. Lutilisateur modifie le problme
3. Lutilisateur supprime un problme sil a le droit de
suppression
4. Lutilisateur ajoute un problme
4.1 Le systme vrifie le non duplication du nom du problme
4.1.1 Si duplication, informer lutilisateur et recommencer
4.1.2 Sinon, enregistrer les donnes
Post condition ---
50

Figure 15 : Diagramme de squence supprimer un problme

Diagramme de classe gestion des problmes :

Figure 16: Diagramme de classe gestion des problmes

C Module gestion des intervenants :

Cette partie permet de lister lensemble des fonctionnalits du module
gestion des problmes :
Associer un incident un intervenant.
Associer solution un incident.
Consulter la liste des intervenants disponibles.

0..*
0..*
0..*
1..*
0..*
1..*
Uti l i sateur
-
-
-
-
Id_user
Logi n
E mai l
Tel
: i nt
: Stri ng
: Stri ng
: Stri ng
+
+
<<Getter>>
<<Setter>>
getId_user ()
...
Intervenant
-
-
-
Nom
Prenom
Nbr_aff_encours
: Stri ng
: Stri ng
: i nt
...
: Stri ng
Inci dent
-
-
-
-
-
Id_i nci dent
Descri pti on
Type
Date_recl amati on
Date_cl oture
: i nt
: Stri ng
: Stri ng
: Date
: Date
Sol uti on
-
-
-
-
-
Id_sol u
Nom_sol
Descri pti on
Val i di t
Defi ni ti ve
: i nt
: Stri ng
: Stri ng
: Stri ng
: Stri ng
Probl me
-
-
-
Id_prob
Descri pti onprob
typeprob
: i nt
: Stri ng
: Stri ng
51

Figure 17 : Diagramme de cas d'utilisation du module Gestion des interventions

Description des cas des utilisations :

Nom Associer une solution un incident
Objectif
Ce cas d'utilisation permet aprs le traitement de
lincident dassocier la solution trouve lincident.
Acteurs
principaux
Administrateur, Intervenant
Acteurs
secondaires
---
Flot dvnements
1. demander la liste des incidents
2. choisir un incident et cliquer sur dtails
3 Associer solution lincident.

<<i ncl ude>>
<<extends>>
<<extends>>
<<extends>>
i ncl ude
Admi ni strateur
Intervenant
Associ er Sol uti on un
i nci dent
Associ er i nci dent un
i ntervenant
S'authenti fi er
Consul ter Di sponi bi l i t d
'i ntervenant
Modi fi er i ntervenant
associ er a un i nci dent
Trai ter l 'i nci dent
Sai si r fi che i nterventi on
52
Post condition ---

Diagramme de classe gestion des intervenants :

Figure 18 : Diagramme de classe gestion des intervenants

6 Diagramme de classes Global

0..*
0..*
0..*
1..*
0..*
1..*
Uti l i sateur
-
-
-
-
Id_user
Logi n
E mai l
Tel
: i nt
: Stri ng
: Stri ng
: Stri ng
+
+
<<Getter>>
<<Setter>>
getId_user ()
...
Intervenant
-
-
-
Nom
Prenom
Nbr_aff_encours
: Stri ng
: Stri ng
: i nt
...
: Stri ng
Inci dent
-
-
-
-
-
Id_i nci dent
Descri pti on
Type
Date_recl amati on
Date_cl oture
: i nt
: Stri ng
: Stri ng
: Date
: Date
Interventi on
-
-
-
Id_i nterventi on
Dure_i nterventi on
Date_i nterventi on
: i nt
: Stri ng
: Stri ng
Sol uti on
-
-
-
-
-
Id_sol u
Nom_sol
Descri pti on
Val i di t
Defi ni ti ve
: i nt
: Stri ng
: Stri ng
: Stri ng
: Stri ng
Probl me
-
-
-
Id_prob
Descri pti onprob
typeprob
: i nt
: Stri ng
: Stri ng
53
Cette tude nous amne dfinir le diagramme de classe suivant :
Figure 19 : Diagramme de classe

Conclusion :
Dans ce chapitre, nous avons dcrit la phase danalyse et conception de notre projet.
Nous avons prsent le langage utilis pour modlisation savoir UML. Ensuite
nous avons prsent et dfini quelques diagrammes du formalisme UML relatifs
notre projet et, afin dillustrer son fonctionnement. Le chapitre suivant est ddi la
phase de ralisation et implmentation de notre application.

0..*
0..*
1..1
0..*
1..1
0..*
1..1
0..*
0..*
1..*
1..*
1..*
1..1
1..*
1..*
1..1
1..*
1..1
Uti l i sateur
-
-
-
-
Id_user
Logi n
E mai l
Tel
: i nt
: Stri ng
: Stri ng
: Stri ng
+
+
<<Getter>>
<<Setter>>
getId_user ()
...
Intervenant
-
-
-
Nom
Prenom
Nbr_aff_encours
: Stri ng
: Stri ng
: i nt
...
: Stri ng
Agent
-
-
-
Nom
Prenom
Agence
: Stri ng
: Stri ng
: Stri ng
+
+
<<Getter>>
<<Setter>>
getNom ()
setNom (Stri ng newNom)
...
Inci dent
-
-
-
-
-
Id_i nci dent
Descri pti on
Type
Date_recl amati on
Date_cl oture
: i nt
: Stri ng
: Stri ng
: Date
: Date
Interventi on
-
-
-
Id_i nterventi on
Dure_i nterventi on
Date_i nterventi on
: i nt
: Stri ng
: Stri ng
Catgori e
-
-
Id_categori e
Nom_cat
: i nt
: Stri ng
Sol uti on
-
-
-
-
-
Id_sol u
Nom_sol
Descri pti on
Val i di t
Defi ni ti ve
: i nt
: Stri ng
: Stri ng
: Stri ng
: Stri ng
EtatInci dent
-
-
Id_etat
Inti tul e_etat
: i nt
: Stri ng
Pri ori tInci dent
-
-
Id_pri ori t
Inti tul epri ori te
: i nt
: Stri ng
Changement
-
-
-
-
Id_changement
Descri pti on
Date_chang
Type_change
: i nt
: Stri ng
: Date
: Stri ng
Probl me
-
-
-
Id_prob
Descri pti onprob
typeprob
: i nt
: Stri ng
: Stri ng
Message
-
-
num_msg
Nom_msg
: i nt
: Stri ng
54

Chapitre 6
Ralisation
Ce chapitre est consacr pour la partie ralisation du
projet, nous commencerons par dcrire l'architecture de
dploiement, les outils et les Framework utiliss pour ce
dveloppement et enfin quelques interfaces.
55

Prsentation de chapitre

Dans cette partie nous prsentons dans un premier temps la technologie et les outils
utiliss pour la ralisation du systme. Aprs nous prsentons les diffrentes
interfaces de notre systme.
1. Architecture de dploiement

Le diagramme de dploiement permet de visualiser les tapes principales du
projet, il dcrit la distribution lapplication GESTION DES INCIDENTS
Figure 20 : Diagramme de dploiement

2. Technologies utiliss :

Environnements de Dveloppement
TCP/IP
TCP/IP
HTTP
<<Tomcat>>
serveur d'apl i cati on
modul e gesti on des i nci dents
<<apach>>
serveur Web
poste de travai l
navi gateur
<<MySql >>
Serveur BD
56

Eclipse est une plate-forme de dveloppement n du travail d'un
consortium de grandes entreprises (IBM, Borland, Rational Rose,
HP...). C'est un IDE performant et Open Source qui a su trouver sa place
parmi les grosses pointures du march. Il supporte de nombreux outils de
dveloppement de haut niveau trs complets : un IDE complet Java tel que
le JDT, un environnement de cration de plug-in et un ensemble de
Frameworks de fondations qui garantissent une bonne interoprabilit des
plug-ins.
AVANTAGE:
L'ouverture de son noyau permet l'ajout de nouvelles fonctionnalits;
Moins gourmand en espace mmoire par rapport aux autres tel que
NetBeans .
Trs Facile installer et travailler avec.

Langage de dveloppement :
La plateforme Java entreprise (Java EE) est un ensemble de
spcifications coordonnes et pratiques qui permettent ensemble
des solutions pour le dveloppement, le dploiement, et de la
gestion des applications multitiers centralises sur un serveur.
Construit sur la plateforme de Java 2 dition standard (Java SE),
la plateforme Java EE ajoute les possibilits ncessaires pour fournir une plateforme
complte, stable, scurise, et rapide de Java au niveau entreprise.
J2EE comprend notament:

Les spcifications du serveur d'application, c'est--dire
l'environnement d'excution : J2EE dfinit finement les rles et les
interfaces pour les applications ainsi que l'environnement dans lequel
elles seront excutes.

Des services, au travers d'API, c'est--dire des extensions Java
indpendantes permettant d'offrir en standard un certain nombre de
57
fonctionnalits. Sun fournit une implmentation minimale de ces API
appele J2EE SDK (J2EE Software Dveloppement Kit).

L'architecture J2EE permet ainsi de sparer la couche prsentation, correspondant
l'interface homme-machine (IHM), la couche mtier contenant l'essentiel des
traitements de donnes en se basant dans la mesure du possible sur des API
existantes, et enfin la couche de donnes correspondant aux informations de
l'entreprise stockes dans des fichiers, dans des bases de donnes relationnelles ou
XML, dans des annuaires d'entreprise ou encore dans des systmes d'information
complexes.
Frameworks

Hibernante est un Framework open source grant
la persistance des objets en base de donnes
relationnelle.Hibernate est adaptable en termes d'architecture, il peut donc tre
utilis aussi bien dans un dveloppement client lourd, que dans un environnement
web lger de type Apache Tomcat ou dans un
environnement J2EE complet : WebSphere, JBoss Application Server et Oracle
WebLogic Server.
HIBERNETE :
Est un framework de mapping objet/relationnel pour applications java.
Permet de crer une couche daccs aux donnes (DAO) plus modulaires,
plus maintenable.
Gnre automatiquement le code SQL.
Fournit plusieurs stratgies pour interroger la base de donnes. Requtes
SQL, langage HQL

Apache Struts est un framework libre servant au
dveloppement d'applications web J2EE. Il utilise et tend
l'API Servlet Java afin d'encourager les dveloppeurs
adopter l'architecture Module-Vue-Contrleur.
58
Struts permet la structuration d'une application Java sous forme d'un ensemble
d'actions reprsentant des vnements dclenchs par les utilisateurs de
l'application. Ces actions sont dcrites dans un fichier de configuration de type XML
dcrivant les cheminements
possibles entre les diffrentes actions. En plus de cela, Struts permet d'automatiser la
gestion de certains aspects comme par exemple la validation des donnes entres par
les utilisateurs via l'interface de l'application. Plus besoin de venir coder le contrle
de chaque donne fournie par un utilisateur, il suffit de dcrire les vrifications
effectuer dans un fichier XML ddi cette tche.

SGBD & Server :

MySQL est un systme de gestion de base de donnes (SGBD).
Selon le type d'application, sa licence est libre ou propritaire. Il fait partie des
logiciels de gestion de base de donnes les plus utiliss au monde, autant par le
grand public (applications web Principalement) que par des professionnels, en
concurrence avec Oracle et Server. Il est fiable et simple utiliser, beaucoup des
socits les plus importantes et forte croissance.
Telles que Google, Lafarge rduisent leurs cots de manire significative en utilisant
MySQL Pour leurs sites Web, leurs applications critiques dentreprise, ou en
embarquant MySQL au Sein de leurs solutions. La version utilise dans notre projet
est 5.1
Apache Tomcat (sera notre serveur dapplication), est un
Conteneur libre de servlets J2EE. Issu du projet Jakarta,
Tomcat est un projet principal de la fondation Apache.
Tomcat implmente les spcifications des servlets et
des JSP du Java Community Process1 . Il est paramtrable par des fichiers XML et de
proprits, et inclut des outils pour la configuration et la gestion. Il comporte
galement un serveur http, Tomcat est un serveur Web qui gre les servlets et les JSP.
59
C'est le compilateur Jasper qui compile les pages JSP pour en faire des servlets. Le
moteur de servlet Tomcat est souvent employ en combinaison avec un serveur Web
Apache ou d'autres serveurs Web.Tomcat a t crit en langage Java. Il peut donc
s'excuter via la machine virtuelle Java sur n'importe quel systme d'exploitation la
supportant.
Outil de Modlisation :

PowerDesigner est une puissante solution de Modlisation des
Systmes d'Informations. Cet ensemble d'outils supporte plusieurs
techniques de modlisation standard : modlisation Merise (Donnes et
Traitements), Modlisation UML particulirement adapte la logique des
applications et Modlisation des Processus Mtiers

3. Prsentation des interfaces de lapplication :

Dans cette section, nous prsentons un aperu des crans dapplication qui sont le
fruit de la ralisation des diffrents modules fonctionnels conus.

Authentification :

Cet cran est un cran de scurit, il nous aide sauthentifier afin de pouvoir
accder lapplication.

60
Figure 21: La page dauthentification

Ecran des tickets :

Cet cran est un cran des tickets, il nous aide afficher la liste des tickets non traits.
61

*
Figure 22: La page gestion des incidents

Ecran de dtails des tickets :

Cet cran permet dafficher le dtail de chaque ticket.

62
Figure 23: La page dtail du ticket

Ecran des problmes
Cet cran permet dafficher la liste des problmes existants
Figure 24 : La page de liste de problmes

63

Ecran de gestion des intervenants
Cet cran permet dassocier une solution un incident
Figure 25 : La page dassocier une solution n incident

Ecran cration des incidents
Cet cran permet dajouter un nouvel incident par ladministrateur.

64

Figure 26 : La page de cration dun incident

Conclusion et prospectives:

Notre projet de fin dtudes consistait dvelopper un systme qui intgr la gestion
des exigences suivant le rfrentiel CMMI pour lentit BPLG du groupe MEDTI.
Pour mettre en uvre ce projet, nous tions amens, dans un premier lieu, tablir
une tude conceptuelle du sujet afin de dgager les diffrents modules et
fonctionnalits de cette application ainsi quune tude des outils et technologies
susceptibles de convenir sa ralisation. Dans un second lieu, nous avons fait une
analyse et conception du projet en se basant sur le formalisme UML. Un certain
nombre de diagrammes ont t labors afin de mieux dcouper le projet, ce qui a
facilit sa mise en uvre. Finalement, nous avons implment les diffrents modules
65
de cette application. Le rsultat de cette dernire phase rpond aux exigences et aux
besoins dj cits dans ce rapport.
Par ailleurs, ce projet de fin dtudes tait pour nous, une occasion intressante
dacqurir de nouvelles connaissances dans le domaine de la standardisation des
processus de dveloppement des logiciels CMMI. En particulier le domaine de
processus de la gestion des exigences REQM (Requirement Management).
Enfin, nous esprons que la ralisation du systme gestion des exigences continuera
sur la base de notre travail et intgrera de nouvelles technologies qui utilisent des
aspects dcisionnels comme le DataWarehouse.

66

Bibliographie

- UML 2 en action
De lanalyse des besoins la conception
4e dition

- ITIL pour un service informatique Optimal
2
nd
Edition
Christian DUMOND

- Gestion de projet, vers les mthodes agiles
2
nd
Edition

- Hibernate 3.0,
Anthony PATRICIO

- Practical Apache Struts 2 web 2.0 Projects
Ian ROUGHLEY

67

Webographie

- http://struts.apache.org
- http://www.learntechnology.net
- http://www.vaannila.com
- http://www.roseindia.net/struts2

68

Rapport - PFE - Gestion - Incidents - (1) Zeghari & Hamdoun 12

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Rapport - PFE - Gestion - Incidents - (1) Zeghari & Hamdoun 12

Diunggah oleh

Hak Cipta:

Format Tersedia

Etude et mise en place dun systme de GESTION

DES INCIDENTS sous le rfrentiel ITIL

Anda mungkin juga menyukai