Vous êtes sur la page 1sur 68

Etude et mise en place d’un système de GESTION

DES INCIDENTS sous le référentiel ITIL

Ingénierie Informatique et Réseau

Option : MIAGE

ZEGHARI KAWTAR BELASLA MEHDI


HAMDOUN FATIMA ZAHRA Bouing Ali
2
Projet : Gestion des Incidents

Dédicace

A nos très chers parents

En témoignage de notre amour et de notre gratitude pour les sacrifices


consentis à notre égard

A nos frères et sœurs

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 près ou de loin nous sont chers

Nous dédions ce mémoire.

2010-2011
3
Projet : Gestion des Incidents

REMERCIEMENTS

Nous tenons vivement à exprimer au travers de ce document notre profonde


gratitude au corps professoral de l’Ecole Marocaine des sciences de l’ingénieur,
E.M.S.I, pour les bases techniques qui nous ont été inculquées au cours de notre
formation d’ingénieur et qui nous ont permis d’avoir une approche analytique
beaucoup plus raffinée lors de notre travail d’étude.

Nous remercions plus particulièrement,


Mr BELASLA notre encadrent de projet, à E.M.S.I, pour n’avoir ménagé aucun
instant de ses plus précieux temps à nous aider et nous orienter tout au long de notre
projet.

Nous n’oublions pas d’adresser notre profond remerciement aux membres du jury
Pour avoir accepté juger notre travail.

A toutes celles et ceux qui de près ou de loin ont contribué à la tenue et à la réussite de
ce travail, veuillez trouver ici l’expression de notre reconnaissance.
4
Projet : Gestion des Incidents

RESUME

Dans le cadre de notre formation en ingénierie informatique et réseaux et afin de


d’appliquer nos connaissances théoriques requis lors de cette formation, nous
sommes amenés à réaliser un Projet de Fin d’Etude pour le compte de l’entreprise
FBPMC.

La mission principale de ce projet est l’étude, la conception et la mise en place d’un e


application Intranet de gestion des incidents, et cela en respectant les bonnes
pratiques du référentiel ITIL.

Pour un bon accomplissement de la mission du projet, la démarche du

développement choisie a suivi méthode XP, suivant le standard de modélisation


UML.

Les choix technologiques on été centrés sur le langage J2EE, Struts et Hibernate en se
basant sur le modèle MVC. Le travail d’étude des besoins et conception sont
modélisés sous le langage UML.

Le présent rapport synthétise tout le travail que nous avon effectué dans cette
perspective.

Mots clés : Gestion des incidents, ITIL, J2EE, MVC, UML,


5
Projet : Gestion des Incidents

Liste des tableaux

Tableau 1 Livrable du projet

Tableau 2 phases du projet

Tableau 3 Tableau comparatif des différents cycles de développement

Tableau 4 Etude préalable

Tableau 5 Phase d’analyse et de conception

Tableau 6 Phase d’implémentation et test

Tableau 7 Phase de Déploiement et recette

Tableau 8 Risques de projet

Tableau 9 Liste des modules

Tableau 10 Présentation du use case s’authentifier

Tableau 11 Présentation du use case gérer les incidents

Tableau 12 Présentation du use case Rechercher Incident

Tableau 13 Présentation du use case gérer les problèmes


6
Projet : Gestion des Incidents

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 Rélle du projet

Figure 6 Processus gestion des incidents

Figure 7 Cycle de vie de l’incident

Figure 8 Les niveaux d’un incident

Figure 9 Diagramme illustrant les acteurs du système

Figure 10 Diagramme de use case « Gestion des Incidents ».

Figure 11 Diagramme séquence : «S’authentifier»

Figure 12 Diagramme séquence : «Ajouter incident»

Figure 13 Diagramme de classe gestion des incidents

Figure 14 Diagramme de use case gestion des problèmes

Figure 15 Diagramme de séquence supprimer un problème

Figure 16 Diagramme de classe gestion des problèmes

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 déploiement

Figure 21 La page d’authentification

Figure 22 La page gestion des incidents

Figure 23 La page détail du ticket


Figure 24 La page de liste de problèmes

Figure 25 La page d’associer une solution à n incident

Figure 26 La page de création d’un incident


7
Projet : Gestion des Incidents

Table de matière
INTRODUCTION GENERALE.................................................................................................... 9
CHAPITRE 1 ................................................................................................................................. 11
CONTEXTE GENERAL DU PROJET......................................................................................... 11

1-ORGANISME D’ACCUEIL : 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 D’INFORMATION 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 : Périmètre 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
................................................................................................................................. 34
CHAPITRE 4
CAHIER DES CHARGES............................................................................................................ 34

1) OBJECTIFS DE L’OUTIL « GESTION DES INCIDENTS» ................................................................ 34


CONCLUSION ..................................................................................................................................... 38
CHAPITRE 5 ................................................................................................................................. 39
ETUDE DES BESOINS................................................................................................................ 39
8
Projet : Gestion des Incidents

1- Présentation du langage de modélisation UML : .................................................................. 39


3. EXPLORATION .................................................................................................. ......................... 41
TABLEAU 9 : LISTE DES MODULES ............................................................................. ......................... 41
4 LES ACTEURS DU SYSTEME..................................................................................... ......................... 41
6 Modules et Fonctionnalités principale du système : ................................................................... 42
FIGURE 15 : DIAGRAMME DE SEQUENCE SUPPRIMER UN PROBLEME................................................. 50
FIGURE 17 : DIAGRAMME DE CAS D'UTILISATION DU MODULEGESTION 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 L’APPLICATION « GESTION DES INCIDENTS» ....................................................................... 55
2. TECHNOLOGIES UTILISES : ..................................................................................................................... 55
ENVIRONNEMENTS DE DEVELOPPEMENT ......................................................................................... 55
3. PRESENTATION DES INTERFACES DE L ’APPLICATION : ..................................................................... .............. 59
AUTHENTIFICATION : ............................................................................................................................... 59
ECRAN DES TICKETS : ................................................................................................................................ 60
* .......................................................................................................................................................... 61
FIGURE 22: LA PAGE GESTION DES INCIDENTS ......................................................... ......................... 61
ECRAN DE DETAILS DES TICKETS : ................................................................. ............................................... 61

........................................................................................ 64
CONCLUSION ET PROSPECTIVES:
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
Projet : Gestion des Incidents

Introduction générale

ITIL (Information Technology Infrastructure Library) est un référentiel décrivant un


ensemble de processus de gestion de services technologiques utilisés par le métier. Il
est focalisé sur les processus de production, et ne couvre pas les processus de
développement, de gestion de projet, ou encore de Gouvernance.

La gestion des incidents reste toujours le domaine le plus exploitable et pratiqué de


ce référentiel, voir le succès que présente son application dans les différentes entités
de production et de helpdesk.

Dans ce cadre, notre mission s’inscrit dans la mise en œuvre d’une 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 d’appliquer les étapes et les


spécifications décrites dans le référentiel ITIL en termes de gestion des incidents, à
travers l’étude, la conception et la mise en place d’une Intranet de gestion des
incidents pour le compte d’une société de service en ingénierie informatique.

Le présent document rapport l’essentiel de la mission du projet, il s’organise ainsi :

Le premier chapitre : a pour but de définir l’organisme d’accueil ,nous allons


présenter cet organisme, son organigramme ainsi que sa mission, à fin d’éclaircir
l’environnement du projet, nous allons présenter finalement le cadre général du
projet.

Le deuxième chapitre : nous allons présenter le périmètre du projet, les livrables, les
risques, ainsi que le choix méthodologique adopté, et le planning suivi.

Le troisième chapitre: est consacré à la Gestion des incidents sous la référence ITIL

Le quatrième chapitre : est consacré à la définition du déférent module de notre


application ainsi que les règles de gestion de la gestion des incidents.

Le cinquième chapitre: est consacré à l’analyse et la conception de l’application et


nous présentons ensuite les différents acteurs du système et les diagrammes UML.
10
Projet : Gestion des Incidents

Le sixième chapitre : est consacré pour la partie réalisation du projet, nous


commencerons par décrire l'architecture de déploiement, les outils et les Framework
utilisés pour ce développement et enfin quelques interfaces.
11
Projet : Gestion des Incidents

Chapitre 1

Contexte général du projet

Le présent chapitre a pour but de définir l’organisme


d’accueil nous allons présenter cet organisme, son
organigramme ainsi que sa mission, à fin d’éclaircir
l’environnement du projet, nous allons présenter

finalement le cadre général du projet.


12
Projet : Gestion des Incidents

1-ORGANISME D’ACCUEIL: FONDATION BANQUE


POPULAIRE POUR LE MICRO CREDIT (FBPMC)

1.1 Présentation

La Fondation Banque Populaire est une filiale du groupe Banque Populaire, c’est une

association à but non lucratif, ayant pour objectifs principaux le développement et la


distribution de micro crédits. Elle a été créée en juin 1998 après avoir obtenu
l’agrément par décret ministériel.

La FBPMC constitue une réponse citoyenne du Groupe Banque Populaire qui vise à
contribuer efficacement, aux côtés de l’Etat et d’autres organisations non
gouvernementales à l’effort national de lutte contre la pauvreté et le chômage et
promotion de l’emploi.

1.2 Missions
Grâce à cette politique de proximité et à son programme jumelé
financement/accompagnement, la Fondation se fixe trois objectifs :
- Favoriser le développement et la modernisation des unités productives
soutenue par son programme.
- Faciliter le passage progressif de ces unités du secteur informel vers le
secteur organisé de l’économie.
- Concourir à la bancarisation des clients.

1.3 Entité du stage (Direction du Système d’Information et Organisation)

- La DSI est composée de trois départements : Département Technique et


exploitation, Département Organisation et Département Etude et
développement, au sein de ce dernier que j’ai effectué mon stage.
- Ce département a pour objectif de développer et optimiser les modules
du progiciel afin de répondre aux besoins fonctionnels des branches.
13
Projet : Gestion des Incidents

1.4 Organigrammes
a) L’organigramme de le FBPMC :

Figure 1 : Organigramme de la FBPMC

b) Organigramme de la DSI
14
Projet : Gestion des Incidents

Figure 2 : Organigramme de la DSI

2- CADRE GENERAL DU PROJET

Quelles que soient la qualité du système d’information mis en place dans l’entreprise
ou les compétences des techniciens qui l’exploitent, des incidents se produiront. Ces
incidents ont toujours un effet important sur la confiance que les utilisateurs
accordent à l’équipe qui gère ce système d’information.

La manière de gérer ces « crises » et la rapidité de leur résolution est un révélateur de


la maturité de l’équipe informatique. C’est pourquoi l’implantation du processus qui
gère ces incidents, véritable fer de lance du centre de services, est particulièrement
importante.

3 - Pourquoi Gestion des incidents

Minimiser l’impact négatif sur les activités de l’entreprise des Incidents et Problèmes
causés par des erreurs dans l’infrastructure informatique et Prévenir la réapparition
des Incidents induites par ces erreurs selon ITIL

Conclusion :
Dans ce chapitre, j’ai mis l’accent sur la présentation de la société. Dans le
chapitre suivant, je vais vous présenter le périmètre ainsi que le cadre général
du projet.
15
Projet : Gestion des Incidents

Chapitre 2
Contexte Général du projet
Dans ce chapitre nous allons présenter le périmètre du
projet, les livrables, les risques, ainsi que le choix

méthodologique adopté, et le planning suivi.


16
Projet : Gestion des Incidents

Partie I : Périmètre du projet

I. But du projet

L’objectif de Ce projet est la mise en place une application


Intranet de Gestion des incidents, dont l’objectif est de gérer les interventions et les
solutions des problèmes afin de restaurer une activité normale le plus rapidement
possible, afin de minimiser les interruptions de service au sein de l’entreprise et
d’améliorer la qualité du service pour le compte de la DSI de la FBPMC, et Suivant le
référentiel ITIL, ladite application devra couvrir les modules suivants :

 La gestion des incidents

 La gestion des problèmes

 La gestion des interventions

 La gestion des utilisateurs

II. Objectifs du projet

L’intitulé de notre projet est « La conception et la réalisation d’une application de


Gestion des incidents selon le référentiel ITIL ».
Les grands points du projet sont :
 Etude comparative entre les différents logiciels du marché.
 Etude technique du portail existant.
 L’élaboration des dossiers de spécifications générales et détaillées.
 Réalisation de l’application
 Tests.

Documentation
 Développement des déférentes module à savoir : la Gestion des incidents,
la Gestion des interventions, la Gestion de configuration, la Gestion de
changement, la gestion des problèmes.
17
Projet : Gestion des Incidents

III. Livrable du Projet

Date de Date
Date de
Phase Livrable Responsable livraison validation
livraison réelle
prévue prévue

Hamdoun &
vant projet  Plan de qualité projet & 18/06/2011 22/06/2011 22/06/2011
Zeghari
 Cahier des charges Hamdoun &
Etude préalable  Dossier de Zeghari 25/06/2011 30/06/2011 02/07/2011
spécifications générales
 Dossier des Hamdoun &
nalyse et
spécifications détaillées. Zeghari 13/07/2011 27/07/2011 27/07/2011
Conception
 Dossier de conception.
mplémentation et Hamdoun &
Code source. 29/07/2011 02/09/2011
test

Zeghari

Tableau 1 : Livrable de projet

Partie II : Conduite du projet :

I. processus de développement XP

Chaque attente du client peut être atteinte indépendamment des autres.


L'utilisation d'un cycle de vie permettant de développer chacun des modules de bout
en bout séparément est donc appropriée. Le produit final sera donc livré par lots,
chaque lot sera développé, testé et affiné avant l’intégration finale. La méthode

choisie est XP.


18
Projet : Gestion des Incidents

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 d’une étape à une autre.

Phases Activités
Exploration Définir les fonctionnalités du logiciel, et rédiger des
besoins sous forme de "user stories" et estimation de leur
durée.

Planning Réunion entre client et développeurs pour déterminer les actions à


mettre en œuvre et estimer leurs durées.

Réalisation Elle prend en charge le suivi des tâches, ainsi que les activités
d'analyse du besoin, de conception, d'implémentation et de test

correspondantes.
Production Clôture d’itération après le déploiement du logiciel chez le client et
en cas d’itération restante retourné à la phase planning.

Tableau 1 : phases du projet


19
Projet : Gestion des Incidents

III. Comparaison des différents cycles de développement

Pour justifier le choix du cycle de développement vue le nombre de


méthodes qui existent : RUP, 2TUP, XP, Cascade. Nous avons mis en place
un tableau comparatif des principaux processus utilisés dans le
développement logiciel

Descriptions Points forts Points


faibles
Processus - Promu par Rational - Itératif - Coûteux à
RUP Le RUP est à la fois une - Spécifie le dialogue personnaliser
méthodologie et un outil entre les différents - Très axé processus,
prêt à l’emploi intervenants du au détriment du
- Cible des projets de plus projet - Propose des développement
de 10 personnes modèles de
documents, et des

canevas pour des


projets types
Processus XP - Ensemble de « Bests - Itératif - Ne couvre pas les
Practices » de - Simple à mettre en phases en amont et
développement œuvre en aval au
- Cible des projets de - Fait une large place développement -
moins de 10 personnes aux aspects Élude la phase
techniques d’analyse, si bien
- Innovant qu’on peut dépenser
son énergie à faire et
défaire
- Assez flou dans sa
mise en œuvre
Processus - S’articule autour de - Itératif - Plutôt superficiel
2TUP l’architecture - Fait une large place sur les phases situées
- Propose un cycle de à la technologie et à en amont et en aval
20
Projet : Gestion des Incidents

développement en Y la gestion du risque du développement :


- Détaillé dans « UML en - Définit les profils capture des besoins,
action » des intervenants, les support,
- Cible des projets de livrables, les maintenance, gestion
toutes tailles plannings, les du changement - Ne
prototypes propose pas de
documents types
Tableau 3 : Tableau comparatif des différents cycles de développement

IV. Cycle de vie du projet

La planification du projet doit faire l’objet d’un document formel, approuvé et utilisé
pour diriger à la fois l'exécution et le contrôle du projet. Il est principalement utilisé
pour documenter les hypothèses et décisions 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 d’Etude préalable:


Cette phase démarre 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 réalisation
des deux formes de l’application. De plus qu’une étape de formation et
familiarisation avec les nouvelles technologies à utiliser. Cette phase se termine
par une élaboration d’un PQP, un dossier de l’existent et un dossier technique
du projet.

Phase d’analyse et Conception :


Dans cette phase, on défini les acteurs et fonctionnalités du système futur,
suivie d’une spécification détaillée des différents processus d’utilisation. Elle se
terminera par une élaboration d’une architecture dynamique (diagrammes de
séquences) et statique (diagramme de classes) du système.
21
Projet : Gestion des Incidents

 Phase d’implémentation et test :


Elle contient le codage de toutes les fonctionnalités du projet, tests et
optimisation du code.

 Phase de déploiement et recette :


C’est la phase où on met en production notre application dans son
environnement cible.

V. Description des phases

 Etude préalable

Phase d’étude préalable


 Extraire les besoins du client
 Définir toutes les règles de gestions appropriées aux
Objectifs besoins demandés.
 Validation de la compréhension de l’application
 Planning de suivi
Livrables en sortie
 Dossier de spécifications générales.

Critères de fin de  Compréhension fonctionnelle et technique de l’application.


phase
Tableau 4 : Etude préalable

Phase d’analyse et de conception


 Appropriation fonctionnelle et technique de l’application
 Validation de la compréhension de l’application
Objectifs
 Réalisation de la spécification détaillée de tous les modules
en charge.
22
Projet : Gestion des Incidents

Livrables en sortie  Dossier de spécifications fonctionnelles et techniques

Critères de fin de  Livraison d’un dossier de spécification détaillée qui


phase prépare au développement.
 Phase d’analyse et de conception :

Tableau 5 :Phase d’analyse et de conception


Phase d’implémentation et test
Phase d’implémentation et test
 Codage des modules spécifiques pour respecter la méthode
RUP ensuite passer aux modules suivants.
Objectifs  Recette de l’application pour la détection des anomalies.
Livrables en sortie  Rapport de test
Critères de fin de  Livraison du manuel d’utilisateur.
phase
Tableau 6 : Phase d’implémentation et test

Phase de Déploiement et recette


Phase de déploiement et recette
 Assistance à la mise en place en production
Objectifs  Correction des anomalies constatées
Livrables en sortie  Code source
Critères de fin de  Fin de la période du projet.
phase
Tableau 7 : Phase de Déploiement et recette

IV. Planning Prévisionnelle du projet

Le projet s’est déroulé en plusieurs étapes successives comportant des points de


validation à chaque fin de tâche
23
Projet : Gestion des Incidents

Figure 4 : Planning initial du projet

VII. Planning Réel du projet :

Le planning réel reflète le déroulement réel des phases et taches du projet, ainsi subi
aux différentes contraintes du projet :
24
Projet : Gestion des Incidents

Figure 5: Planning Réelle du projet

VIII. Risques du projet :

Risque Impact solution

Non-respect Le projet ne sera pas -Doubler l’effort et ajuster le

des délais achevé dans la date planning pour respecter la


planification faite au
prévue, on peut avoir
un retard dans la départ.
livraison de
25
Projet : Gestion des Incidents

l'application

Les pannes Ralentissement des Utiliser les autres matériaux


inattendues du travaux disponibles.
matériel
-Recours à une réparation rapide

Absence ou Ralentissement des Doubler l’effort et travailler un


maladie travaux temps extra.

Insatisfaction Echec du projet Prévoir des réunions et des


du client points de validation avec le client
au fur et à
mesure de l’avancement du
projet

Tableau 8 : Riques de projet

IX. Organisation du Projet

a. Equipe MOE
Nom Fonction / rôle pour le projet Mail
Hamdoun Ingénieur études et développement Hamdoun.fatimazahra@gmail.com
Fatimazahra Ingénieur études et développement
Zeghari kawtar

Ingénieurs développement :

- Elaborer le dossier de gestion de projet.


- Réalisation de la spécification détaillée.
- Codage de l’application (contrôle et modules spécifiques).
- Effectuer les tests unitaires
- Déploiement de l’application,
26
Projet : Gestion des Incidents

b.Equipe MOA

Nom Fonction / rôle pour le projet Mail


Banouig Ali Chef Projet Banouig@hotmail.com

Le chef de projet MOA:


 Valide le dossier des spécifications fonctionnelles.
 Valide le codage et la recette.
 Présentation des besoins fonctionnels du projet.
 Valide les livrables.
 Contrôle le respect des demandes.

Conclusion

Dans ce chapitre nous avons défini les étapes que nous avons suivies pour la mise en
œuvre du projet en décrivant la méthode de développement et en fournissant un
planning pour la réalisation de l’extranet.
27
Projet : Gestion des Incidents

Chapitre 3
Gestion des incidents sous ITIL

Nous avons consacré ce chapitre à la Gestion des incidents


sous la référence ITIL
28
Projet : Gestion des Incidents

1 Objectif
La définition ITIL de l'objectif de la Gestion des Incidents est la suivante :
Restaurer aussi vite que possible le fonctionnement normal des services et minimiser
l’impact négatif sur les activités
Métiers et s’assurer ainsi que les meilleurs niveaux de qualité de service et de
disponibilité sont maintenus.

Le « fonctionnement normal des services » s’entend ici comme le fonctionnemen t des


services dans les limites des Contrats
De Niveaux de Service (SLAs)

2 Périmètre
2.1 Définition d’un Incident et extensions

La définition ITIL d'un Incident est la suivante :


« Tout événement qui ne fait pas partie du fonctionnement standard d’un 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 empêchant


l’Utilisateur de travailler, nombre d'E/S disques excessifs
 Matériel: système HS, remontée d’alerte automatique, sortie imprimante
bloquée
 Demandes de services : demande d’information, de conseil ou de
documentation, oubli d’un mot de passe

2.2 Extensions de la définition

Le terme Incident est généralement compris comme un dysfonctionnement signalé


par un Utilisateur. Cependant, deux extensions à cette définition sont généralement
utilisées car elles vont suivre le même processus de traitement que les
dysfonctionnements proprement dits et sont donc assimilés à des Incidents :
29
Projet : Gestion des Incidents

 Les demandes pour un nouveau service (ou l’extension d’un service existant)
sont considérées comme des demandes de Changement (RFCs) mais
assimilées à des incidents en pratique (traitement identique) et traitées dans
le cadre de la Gestion des Incidents
 Les Remontées d’alertes automatiques (espace-disque saturé par exemple) :
elles sont souvent considérées Comme faisant partie de l’exploitation
courante ; ces événements sont traités dans le cadre de la Gestion des
incidents même si le service délivré aux Utilisateurs n’est pas affecté

2.3 Processus de Gestion des Incidents

Figure 6 : Processus gestion des incidents

En entrée du processus, nous retrouvons :

 Détails des Incidents (du Centre de Services et des différentes sources


automatiques)
 Détails des Configurations (de la CMDB)
 Recherche correspondances (matching) entre Incidents et Problèmes &
Erreurs connues (de la base de donnéesProblèmes/Erreurs Connues)
 Détails de la résolution de l’Incident de nature similaire (de la même base)
 Retour des Demandes de Changement en correction d’un Incident (du
processus Gestion des Changements)
30
Projet : Gestion des Incidents

En sortie du processus, nous avons :

 Routage des demandes de services


 Demandes de Changement pour résoudre certains Incidents
 Mise à jour de la base des Problèmes/Erreurs Connues
 Communication aux Utilisateurs (pendant l’avancement et à la
fermeture)
 Rapports à la hiérarchie

Dans le processus, les activités de la Gestion des Incidents sont les suivantes :

 Détection et enregistrement des Incidents


 Support initial et classification
 Investigation et diagnostic
 Suivi global des Incidents
 Résolution et rétablissement
 Fermeture des Incidents

3 Concepts de base
3.1 Cycle de vie d’un Incident
31
Projet : Gestion des Incidents

Figure 7 : Cycle de vie de l’incident

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

Quelques remarques :

 Le Centre de Services est responsable de l’aboutissement de tous les


Incidents enregistrés (propriétaire des incidents).
 Le processus de traitement est essentiellement réactif.
 Les Incidents ne pouvant pas être résolus immédiatement doivent être
assignés aux groupes de spécialistes.
 La résolution ou une solution de contournement doit intervenir le plus
vite possible pour rétablir le service impacté

3.2 Cycle de vie d’un Incident : Préconisations

Tout au long du cycle de vie de l’Incident, l’enregistrement doit être à jour pour
permettre à n’importe quelle personne de l’équipe du Centre de Services de
communiquer sur l’Incident simplement en consultant l'enregistrement.
32
Projet : Gestion des Incidents

Il est nécessaire de conserver la description srcinelle de l’Incident même si la


description en cours évolue. Par exemple, un Utilisateur signale un Incident avec son
imprimante (son édition ne s'imprime pas). Après investigation, il s'agit en réalité
d'un problème réseau mais, lorsque l'Incident est clos, il est préférable que le Centre
de Services prévienne l'Utilisateur simplement en lui précisant que son problème
imprimante est réglé plutôt que de lui expliquer le problème réseau et sa résolution.
Il faut aussi conserver un historique des modifications sur l’enregistrement de
l’Incident. Tous les changements d'état doivent être tracés (date/heure, personne qui
a provoqué le changement, etc.) Si l’une des équipes n’a pas accès à l’outil de Gestion
des Incidents, il est impératif de bien mettre en place une procédure de
Mise à jour de ces enregistrements à faire lors des interventions de ces équipes (par
exemple: maintenance tierce ou support de nuit n’ayant pas accès à l’outil durant la
nuit)

3.3 Premier, deuxième et troisième niveaux de support

Voici un schéma (classique) d'escalade d'un Incident sur les différents niveaux de
support, à commencer par le Centre de services :

Figure 8 : Les niveaux d’un incident


33
Projet : Gestion des Incidents

Il est à noter que certains niveaux de support peuvent être des sociétés extérieures
(externalisation du support ou appel aux constructeurs/éditeurs dans le cadre de
contrats de support passés entre l'entreprise et ces sociétés extérieures).

Conclusion
Dans ce chapitre nous avons défini le cycle de vie, le processus de gestion des
incidents.
34
Projet : Gestion des Incidents

Chapitre 4
Cahier des charges

Nous avons consacré ce chapitre à la définition du déférent


module de notre application ainsi que les règles de gestion
de la gestion des incidents.
1) Objecti
fs de
l’outil
« Gestion des incidents »

L'objectif de la gestion des incidents est la remise en service des applications, dans les

délais les plus courts, en minimisant l’impact sur les utilisateurs.

 Permet d'avoir un suivi fidèle du parc informatique tant au niveau logiciel


que matériel
 Gère les tickets (demandes d’intervention ou incidents informatiques) suivant
la procédure de gestion des incidents
35
Projet : Gestion des Incidents

Le cycle de vie de l'incident et les étapes de la gestion des incidents sont les
suivantes :

 Détection et enregistrement
 Classification et support initial
 Investigation
 Résolution
 Clôture

Notre outil sera exécuté sur un navigateur web (Intranet) développé avec J2ee
(HIBERNET) lié à une base de données MySQL.

Les acteurs seront : un administrateur, intervenant, Agent

2) Les fonctions

Une fonction est un ensemble d'actions ou de privilèges indépendants et qui


sera affectée aux acteurs définis par l'institution en fonction de leurs rôles.
Elles peuvent être regroupées en 5 sous ensembles qui sont :

 La gestion des incidents


 La gestion des intervenants
 La gestion des changements
 La gestion de problème
 La gestion des configurations

 La gestion des changements

Lorsqu'un Changement est rendu nécessaire, il faut évaluer les risques de sa mise en
œuvre et la continuité de l’activité métier

Pendant et après cette mise en œuvre.


36
Projet : Gestion des Incidents

Il est essentiel pour trouver un équilibre entre la nécessité d’un Changement et


l’impact (négatif) de ce Changement

Les qualités indispensables pour lisser les transitions sont les suivantes :

 avoir des réseaux d’information (grande visibilité sur la production et


l’activité)
 avoir des réseaux de communication

 La gestion des configurations

La qualité de service de la Production informatique doit être fournie au moindre coût


et le contrôle sur l’infrastructure et les Services est impératif.

Le processus fournit un modèle logique de l’infrastructure en identifiant, contrôlant,


maintenant et vérifiant les différents éléments au cours de leur durée de vie.

Les objectifs pratiques qui en découlent sont les suivants

 rendre compte à l’organisation de tous les biens et configurations de la


Production Informatique
 fournir de l’information pertinente sur les configurations pour supporter les
autres processus
 fournir des bases solides pour la Gestion des Incidents, des Problèmes, des
Changements et des Nouvelles Versions
 comparer l’information stockée à l’infrastructure et corriger les différences

 La gestion des incidents

Restaurer aussi vite que possible le fonctionnement normal des services et minimiser
l’impact négatif sur les activités Métiers et s’assurer ainsi que les meilleurs niveaux
de qualité de service et de disponibilité sont maintenus.

3) Règles de gestion
37
Projet : Gestion des Incidents

 L’agent saisie le ticket et l’envoie à l’administrateur.


 L’administrateur traite le ticket et l’enregistre comme un incident
 L’administrateur envoie l’incident à l’intervenant pour la traiter.
 L’intervenant traite l’incident et enregistre le problème de l’incident et
la solution et indique l’état du traitement de l’incident.
 Après la résolution de l’incident l’intervenant envoie à
l’administrateur un e-mail.
 L’administrateur valide la résolution de l’incident et clôture l’incident.

4) Exigences non fonctionnels

L'interface a été créée de façon à être sobre, agréable et fonctionnelle. Plus


généralement, elle répond aux normes d'ergonomie connues pour les interfaces
homme-machine.
 Charge de travail :
L'interface présente un nombre réduit d'informations. Tout ce qui est utile
est écrit et tout ce qui est écrit est utile.

 Homogénéité :

Le site présente une complète homogénéité de sa présentation. En effet, le


fond est toujours le même, le menu principal en haut est statique, celui au
dessous évolue mais est toujours situé au même endroit et a toujours la même
signification. Chaque type d'information se situe toujours à la même place, ce
qui simplifie la navigation en permettant une prise en main rapide.
 Guidage :

Les types de contenu sont tous regroupés entre eux : le menu général dans un

cadre en haut, le contenu dans un cadre au milieu avec tous les rappels
concernant l'utilisateur et sa navigation.

 Signifiance et dénominations:

Les menus ou liens sont nommés de façon très explicite, de façon à ce que
l'utilisateur comprenne très bien de quoi il s'agit. Les noms sont très courants
38
Projet : Gestion des Incidents

et compréhensibles par tous.

Conclusion

Dans ce chapitre nous avons défini le besoin fonctionnel et technique.


39
Projet : Gestion des Incidents

Chapitre 5
Etude des besoins
Nous avons consacré ce chapitre à l’analyse et la
conception de l’application et nous présentons ensuite les
différents acteurs du système et les diagrammes UML.

1- Présentation du langage de modélisation UML :

UML (Unified Modeling Language traduit en français par "langage de modélisation


objet unifié") est né de la fusion des trois méthodes qui ont le plus influencé la
40
Projet : Gestion des Incidents

modélisation objet au milieu des années 90 : OMT, Booch et OOSE. Fruit d'un travail
d'experts reconnus, UML est le résultat d'un large consensus. De très nombreux
acteurs industriels de renom ont adopté UML et participent à son développement.

Il y a donc déjà longtemps que l'approche objet est devenue une réalité. Les concepts
de base de l'approche objet sont stables et largement éprouvés. De nos jours,
programmer "objet", c'est bénéficier 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 réflexe quasi-automatique dès lors qu'on cherche à
concevoir des logiciels complexes qui doivent "résister" à des évolutions incessantes.

UML est un langage de modélisation objet très puissant qui donne une dimension
méthodologique à l'approche objet et qui permet de mieux maîtriser sa richesse.

Il permet de :

 Représenter des concepts abstraits (graphiquement par exemple) ;


 Limiter les ambiguïtés (parler un langage commun, au vocabulaire
précis, indépendant des langages orientés objet) ;

Faciliter l'analyse (simplifier la comparaison et l'évaluation de
solutions).
L’application d’une démarche d'analyse et de conception objet, va permettre d’éviter
d’effectuer une analyse fonctionnelle et de se contenter d'une implémentation objet,
mais il pousse à penser objet dès le départ. En plus, il permet de définir les vues qui
permettent de décrire tous les aspects d'un système avec des concepts objets.

UML permet donc de modéliser une application selon une vision objet, en possédant
plusieurs facettes. C'est une norme, un langage de modélisation objet, un support de
communication et un cadre méthodologique. 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 réalisation ou à l’intégration


d’une solution informatique réussie. Pour réussir une expression des besoins
41
Projet : Gestion des Incidents

pertinente et compréhensible l’utilisation de démarches et de méthodes spécifiques


est souhaitable.

3. Exploration

Le tableau suivant regroupe les différents modules :

Module Description
Incidents Ce module permet de gérer les incidents créer par
les Agents et affectés aux intervenants.
Intervention Ce module gère et garde la traçabilité des
interventions réalisés par les intervenants.
changements Lorsqu'un Changement est rendu nécessaire, il faut
évaluer les risques de sa mise en œuvre et la
continuité de l’activité métier

configurations La qualité de service de la Production informatique


doit être fournie au moindre coût et le contrôle sur
l’infrastructure et les Services est impératif.

problèmes Minimiser l’impact négatif sur les activités de


l’entreprise des Incidents et Problèmes causés par
des erreurs dans L’infrastructure informatique et
Prévenir la réapparition des Incidents induites par
ces erreurs

Tableau 9 : Liste des modules

4 Les acteurs du système


Les acteurs qui interagissent avec l’application sont :

Acteurs humains :


 Agent.
Intervenant.
 Administrateur.

Acteurs système :
42
Projet : Gestion des Incidents

Aucun acteur système n’est identifié.

 Néant

Utilisateur

Agen t Intervenant Administrateur

Figure 9 : Diagramme illustrant les acteurs du système

6 Modules et Fonctionnalités principale du système :


Cette partie est réservée à l’énumération des modules ainsi qu’à la description des
différentes fonctionnalités que la gestion des incidents doit assurer. Une analyse
profonde du dossier de spécification général et détaillé des utilisateurs, et suite aux
réunions avec nos encadrant, nous a mené à dégager les modules de notre
application ainsi que leurs fonctionnalités.

A – Module gestion des Incidents :

Cette partie permet de lister l’ensemble des fonctionnalités du module gestion des
Incidents :

 Création d’une nouvelle Incidents.


 Recherche Incident.
 Modification d’une Incident.
 Suppression d’une Incident.
43
Projet : Gestion des Incidents

 Validation d’une Incident.


 Consulter la liste des Incidents.

Ajou ter un ticket

<<extends>>

Modifier un ticket
Editer un ti cket <<extends>>

Agen t <<extends>>
Annu ler u n ti cket

S'authentifier

<<extends>>
<<inlucde>>

Modifier incident
<<extends>>

Gestion des Incidents


<<extends>>
Adm ini strateur

Supprimer incident

<<extends>>
<<extends>>
<<extends>>
Ajou ter Inci dent

Rechercher Incident
Intervenant <<extends>> Suivi d'incident

Consulter Inciden t

Figure 10 : Diagramme de use case « Gestion des Incidents ».

Descriptions des cas d’utilisations :

Nom S’authentifier
Objectif L’utilisateur saisie son login et son mot de passe pour accéder
au système. S’il fait une erreur il est renvoyé à la page
d’authentification, autrement il accède à son espace.

Acteurs Intervenant, Agent, Administrateur


principaux
Acteurs ---
secondaires
Pré conditions L’utilisateur n’est pas authentifié
Exceptions Utilisateur désactivé
44
Projet : Gestion des Incidents

Flot d’événements 1. L’utilisateur saisi son login et son mot de passe


2. Le système vérifie la validité des coordonnées saisies
2.1. Si les données sont correctes, l’utilisateur accède à son
espace
2.2. Sinon, l’accès est refusé et l’utilisateur est prié de
recommencer
Post condition L’utilisateur est authentifié
Tableau 10 :Présentation du use case s’authentifier

Nom Gérer Incident


Objectif L’utilisateur ajoute une incident, la modifie, et supprime une
incident s’il possède les droits appropriés dans le cas où il
s’agit d’un utilisateur autre que l’administrateur.
Acteurs Administrateur
principaux
Acteurs ---
secondaires
Pré conditions L’utilisateur est authentifié et possède les droits.
Exceptions Utilisateur désactivé

Flot d’événements 1. L’utilisateur consulte la liste des incidents


2. L’utilisateur modifie l’incident
3. L’utilisateur supprime un incident s’il a le droit de
suppression
4. L’utilisateur ajoute une exigence
4.1 Le système vérifie le non duplication du nom de l’incident
4.1.1 Si duplication, informer l’utilisateur et recommencer
4.1.2 Sinon, enregistrer les données
Post condition ---
Tableau 11 :Présentation du use case gérer les incidents

Nom Rechercher Incident


Objectif L’utilisateur recherche un incident.
Acteurs principaux Administrateur, Intervenant
Acteurs ---
secondaires
Pré conditions L’utilisateur est authentifié.
45
Projet : Gestion des Incidents

Exceptions Utilisateur désactivé


Flot d’événements L’utilisateur recherche un incident
Post condition ---
Tableau 12 :Présentation du use case Rechercher Incident

Diagramme de séquence système « S’authentifier» :

Figure 11 : Diagramme séquence : «S’authentifer»

Diagramme de séquence système « Ajouter incident» :


46
Projet : Gestion des Incidents

Figure 12 Diagramme séquence : «Ajouter incident»


47
Projet : Gestion des Incidents

Diagramme de classe du module gestion des incidents :


Utilisateur
- Id_user : int
- Login : String
- E mail : String
- Tel : String
+ <<Getter>> getId_user ()
+ <<Setter>> setId user int newI

ticket Agen t
Intervenant
- num_msg : int 1..* - Nom : String
- Nom_msg : String 1..1 - Prenom : String - Nom : String
- Prenom : String
- Agen ce : String
- Nbr_aff_encours : int
+ <<Getter>> getNom
+ <<Getter>> getNom () : Stri
...

1..1 0..*
0..*

Incident
- Id_incident : int
0..*
- Description : String 0..* Catégorie
- Type : String 1..1 - Id_categorie : int
- Date_reclamation : Date - Nom_cat : String
- Date_cloture : Date

0..* 0..*
1..1

EtatIncident
PrioritéIncident
1..1 - Id_etat : int
- Id_priorité : int
- Intitule_etat : String
- Intitulepriorite : String

Figure 13 : Diagramme de classe gestion des incidents

B – Module gestion des problèmes :

Cette partie permet de lister l’ensemble des fonctionnalités du module gestion


des problèmes :

 Création d’un nouveau problème.


 Modification d’un problème.
 Suppression d’un problème.
 Consulter la liste des problèmes.
48
Projet : Gestion des Incidents

Figure 14: Diagramme de use case gestion des problèmes

Descriptions des cas d’utilisations :

Nom S’authentifier
Objectif L’utilisateur saisie son login et son mot de passe pour accéder
au système. S’il fait une erreur il est renvoyé à la page
d’authentification, autrement il accède à son espace.
Acteurs Intervenant, Administrateur
principaux
Acteurs ---
secondaires
Pré conditions L’utilisateur n’est pas authentifié
Exceptions Utilisateur désactivé

Flot d’événements 1. L’utilisateur saisi son login et son mot de passe


2. Le système vérifie la validité des coordonnées saisies
2.1. Si les données sont correctes, l’utilisateur accède à son
espace
2.2. Sinon, l’accès est refusé et l’utilisateur est prié de
recommencer
49
Projet : Gestion des Incidents

Post condition L’utilisateur est authentifié

Nom Gérer Les problèmes


Objectif L’utilisateur ajoute un problème, le modifie, et supprime un
problème s’il possède les droits appropriés dans le cas où il
s’agit d’un utilisateur autre que l’administrateur.
Acteurs Administrateur
principaux

Acteurs
secondaires ---
Pré conditions L’utilisateur est authentifié et possède les droits.
Exceptions Utilisateur désactivé
Flot d’événements 1. L’utilisateur consulte la liste des problèmes
2. L’utilisateur modifie le problème
3. L’utilisateur supprime un problème s’il a le droit de
suppression
4. L’utilisateur ajoute un problème
4.1 Le système vérifie le non duplication du nom du problème
4.1.1 Si duplication, informer l’utilisateur et recommencer
4.1.2 Sinon, enregistrer les données
Post condition ---
Tableau 13 :Présentation du use case gérer les problèmes
50
Projet : Gestion des Incidents

Figure 15 : Diagramme de séquence supprimer un problème

Diagramme de classe gestion des problémes :

Utilisateur
- Id_user : int
- Login : String

-- Tel
E mail :: String
String

+ <<Getter>> getId_user ()
+ <<Setter>> setId user i nt newI

Intervenant
- Nom : String
- Prenom : String
- Nbr_aff_encours : int
+ <<Getter>> getNom () : Stri

0..*
0..*
Solution
Incident - Id_solu : int
0..*
- Id_incident : int Probléme - Nom_sol : String
- Description : String - Description : String
- Id_prob : int
- Type : String - Validité : String
1..* - Descriptionprob : String 1..*
- Date_reclamation : Date - Definitive : String
0..* - typeprob : String
- Date_cloture : Date

Figure 16: Diagramme de classe gestion des problèmes

C – Module gestion des intervenants :

Cette partie permet de lister l’ensemble des fonctionnalités du module


gestion des problèmes :

 Associer un incident à un intervenant.


 Associer solution à un incident.
 Consulter la liste des intervenants disponibles.
51
Projet : Gestion des Incidents

Traiter l'incident
<<extends>> Saisir fiche intervention

Associe r Sol uti on à un


incident
Intervenant

<<in clude>>

Associe r inci dent à un


intervenant

Adm in istrateu r
<<extends>>
S'authentifier
<<extends>>

include

Consulter Disponibilité d
Modifie r interv enant
'intervenant
associer a un incident

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 après le traitement de
l’incident d’associer la solution trouvée à l’incident.
Acteurs Administrateur, Intervenant
principaux
Acteurs ---
secondaires
Pré conditions L’utilisateur est authentifié et possède les droits.

Exceptions Utilisateur désactivé


Flot d’événements 1. demander la liste des incidents
2. choisir un incident et cliquer sur détails
3 Associer solution à l’incident.
52
Projet : Gestion des Incidents

Post condition ---

Diagramme de classe gestion des intervenants :

Utilisateur
- Id_user : int

- Login : String
- E mail : String
- Tel : String
+ <<Getter>> getId_user ()
+ <<Setter>> setId user int newI

Intervenant
- Nom : String
- Prenom : String
- Nbr_aff_encours : int
+ <<Getter>> getNom () : Stri

Intervention
0..*
- Id_intervention : int
- Durée_intervention : String
- Date_intervention : String
0..*

Incident
- Id_incident : int
- Description : String
- Type : String
- Date_reclamation : Date
- Date_cloture : Date

1..*
Solution
0..* 0..* - Id_solu : int
- Nom_sol : String
- Description : String
Probléme
- Validité : String
- Id_prob : int - Definitive : String
- Descriptionprob : String 1..*
- ypeprob : String

Figure 18 : Diagramme de classe gestion des intervenants

6 Diagramme de classes Global


53
Projet : Gestion des Incidents

Utilisateur
- Id_user : int
- Login : String
- E mail : String
- Tel : String
+ <<Getter>> getId_user ()
+ <<Setter>> setId user i nt newI

Message Agent
Intervenant
- num_msg : int - Nom : String
- Nom_msg : String 1..* - Prenom : String - Nom : String
1..1 - Prenom : String
- Agence : String
- Nbr_aff_encours : int
+ <<Getter>> getNom
+ <<Getter>> getNom () : Stri
1..* 1..* ...
Intervention

0..* - Id_intervention : int


0..* - Durée_intervention : String
- Date_intervention : String

Incident
- Id_incident : int
1..1 1..1 - Description : String 0..* Catégorie
- Type : String 1..1
1..* - Id_categorie : int
- Date_reclamation : Date - Nom_cat : String
Changement - Date_cloture : Date
- Id_changement : int
- Description : String
- Date_chang : Date
- Type_change : String 0..* 0..*
1..1 0..*

EtatIncident
PrioritéIncident Probléme
- Id_etat : int Solution
- Id_priorité : int 1..1
- Id_prob : int
- Intitule_etat : String 1..* - Id_solu : int
- Intitulepriorite : String - Descriptionprob : String 1..*
- Nom_sol : String
- ypeprob : String
- Description : String
- Validité : String
- Definitive : String

Cette étude nous amène à définir le diagramme de classe suivant :

Figure 19 : Diagramme de classe

Conclusion :

Dans ce chapitre, nous avons décrit la phase d’analyse et conception de notre projet.
Nous avons présenté le langage utilisé pour modélisation à savoir UML. Ensuite

nous avons présenté et défini quelques diagrammes du formalisme UML relatifs à


notre projet et, afin d’illustrer son fonctionnement. Le chapitre suivant est dédié à la
phase de réalisation et implémentation de notre application.
54
Projet : Gestion des Incidents

Chapitre 6
Réalisation

Ce chapitre est consacré pour la partie réalisation du


projet, nous commencerons par décrire l'architecture de
déploiement, les outils et les Framework utilisés pour ce
développement et enfin quelques interfaces.
55
Projet : Gestion des Incidents

Présentation de chapitre

Dans cette partie nous présentons dans un premier temps la technologie et les outils
utilisés pour la réalisation du système. Après nous présentons les différentes
interfaces de notre système.

1. Architecture de déploiement

Le diagramme de déploiement permet de visualiser les étapes principales du


projet, il décrit la distribution l’application « GESTION DES INCIDENTS»

<<Tomcat>>
serveur d'apli cation
TCP/IP
<<apach>>
serveur Web
module gestion des incidents

poste de travail
TCP/IP HTTP

navigateur

<<MySql>>
Serveur BD

Figure 20 : Diagramme de déploiement

2. Technologies utilisés :

Environnements de Développement
56
Projet : Gestion des Incidents

Eclipse est une plate-forme de développement 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
développement de haut niveau très complets : un IDE complet Java tel que

le JDT, un environnement de création de plug-in et un ensemble de


Frameworks de fondations qui garantissent une bonne interopérabilité des
plug-ins.

AVANTAGE:

 L'ouverture de son noyau permet l'ajout de nouvelles fonctionnalités;


 Moins gourmand en espace mémoire par rapport aux autres tel que
NetBeans .
 Très Facile à installer et à travailler avec.

Langage de développement :

La plateforme Java entreprise (Java EE) est un ensemble de


spécifications coordonnées et pratiques qui permettent ensemble
des solutions pour le développement, le déploiement, et de la
gestion des applications multitiers centralisées sur un serveur.
Construit sur la plateforme de Java 2 édition standard (Java SE),
la plateforme Java EE ajoute les possibilités nécessaires pour fournir une plateforme
complète, stable, sécurisée, et rapide de Java au niveau entreprise.
J2EE comprend notament:

 Les spécifications du serveur d'application, c'est-à-dire


l'environnement d'exécution : J2EE définit finement les rôles et les
interfaces pour les applications ainsi que l'environnement dans lequel
elles seront exécutées.

 Des services, au travers d'API, c'est-à-dire des extensions Java


indépendantes permettant d'offrir en standard un certain nombre de
57
Projet : Gestion des Incidents

fonctionnalités. Sun fournit une implémentation minimale de ces API


appelée J2EE SDK (J2EE Software Développement Kit).

L'architecture J2EE permet ainsi de séparer la couche présentation, correspondant à


l'interface homme-machine (IHM), la couche métier contenant l'essentiel des
traitements de données en se basant dans la mesure du possible sur des API
existantes, et enfin la couche de données correspondant aux informations de
l'entreprise stockées dans des fichiers, dans des bases de données relationnelles ou

XML, dans des annuaires d'entreprise ou encore dans des systèmes d'information
complexes.
Frameworks

Hibernanteest un Frameworkopen source gérant


la persistance des objetsbase
en de données
relationnelle.Hibernate est adaptable en termes d'architecture, il peut donc être
utilisé aussi bien dans un développement client lourd, que dans un environnement
web léger 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 créer une couche d’accès aux données (DAO) plus modulaires,
plus maintenable.

 Génère automatiquement le code SQL.

 Fournit plusieurs stratégies pour interroger la base de données. Requêtes


SQL, langage HQL

Apache Struts est un framework libre servant au


développement d'applications web J2EE. Il utilise et étend
l'API Servlet Java afin d'encourager les développeurs à
adopter l'architecture Module-Vue-Contrôleur.
58
Projet : Gestion des Incidents

Struts permet la structuration d'une application Java sous forme d'un ensemble
d'actions représentant des événements déclenchés par les utilisateurs de
l'application. Ces actions sont décrites dans un fichier de configuration de type XML
décrivant les cheminements

possibles entre les différentes actions. En plus de cela, Struts permet d'automatiser la
gestion de certains aspects comme par exemple la validation des données entrées par
les utilisateurs via l'interface de l'application. Plus besoin de venir coder le contrôle
de chaque donnée fournie par un utilisateur, il suffit de décrire les vérifications à
effectuer dans un fichier XML dédié à cette tâche.

SGBD & Server :

MySQL est un système de gestion de base de données (SGBD).


Selon le type d'application, sa licence est libre ou propriétaire. Il fait partie des
logiciels de gestion de base de données les plus utilisés 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
sociétés les plus importantes et à forte croissance.

Telles que Google, Lafarge réduisent leurs coûts de manière significative en utilisant
MySQL Pour leurs sites Web, leurs applications critiques d’entreprise, ou en
embarquant MySQL au Sein de leurs solutions. La version utilisée dans notre projet
est 5.1

Apache Tomcat (sera notre serveur d’application), est un

Conteneur libre de servlets J2EE. Issu du projet Jakarta,


Tomcat est un projet principal de la fondation Apache.
Tomcat implémente les spécifications des servlets et
des JSP du Java Community Process1 . Il est paramétrable par des fichiers XML et de
propriétés, et inclut des outils pour la configuration et la gestion. Il comporte
également un serveur http, Tomcat est un serveur Web qui gère les servlets et les JSP.
59
Projet : Gestion des Incidents

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'exécuter via la machine virtuelle Java sur n'importe quel système d'exploitation la
supportant.

Outil de Modélisation :

PowerDesigner est une puissante solution de Modélisation des


Systèmes d'Informations. Cet ensemble d'outils supporte plusieurs
techniques de modélisation standard : modélisation Merise (Données et
Traitements), Modélisation UML particulièrement adaptée à la logique des
applications et Modélisation des Processus Métiers

3. Présentation des interfaces de l’application :

Dans cette section, nous présentons un aperçu des écrans d’application qui sont le
fruit de la réalisation des différents modules fonctionnels conçus.

Authentification :

Cet écran est un écran de sécurité, il nous aide à s’authentifier afin de pouvoir
accéder à l’application.
60
Projet : Gestion des Incidents

Figure 21: La page d’authentification

Ecran des tickets :

Cet écran est un écran des tickets, il nous aide à afficher la liste des tickets non traités.
61
Projet : Gestion des Incidents

Figure 22: La page gestion des incidents

Ecran de détails des tickets :

Cet écran permet d’afficher le détail de chaque ticket.


62
Projet : Gestion des Incidents

Figure 23: La page détail du ticket

Ecran des problèmes

Cet écran permet d’afficher la liste des problèmes existants

Figure 24 : La page de liste de problèmes


63
Projet : Gestion des Incidents

Ecran de gestion des intervenants

Cet écran permet d’associer une solution à un incident

Figure 25 : La page d’associer une solution à n incident

Ecran création des incidents

Cet écran permet d’ajouter un nouvel incident par l’administrateur.


64
Projet : Gestion des Incidents

Figure 26 : La page de création d’un incident

Conclusion et prospectives:

Notre projet de fin d’études consistait à développer un système qui intégré la gestion
des exigences suivant le référentiel CMMI pour l’entité BPLG du groupe MEDTI.

Pour mettre en œuvre ce projet, nous étions amenés, dans un premier lieu, à établir
une étude conceptuelle du sujet afin de dégager les différents modules et
fonctionnalités de cette application ainsi qu’une étude des outils et technologies
susceptibles de convenir à sa réalisation. 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é élaborés afin de mieux découper le projet, ce qui a
facilité sa mise en œuvre. Finalement, nous avons implémenté les différents modules
65
Projet : Gestion des Incidents

de cette application. Le résultat de cette dernière phase répond aux exigences et aux
besoins déjà cités dans ce rapport.

Par ailleurs, ce projet de fin d’études était pour nous, une occasion intéressante
d’acquérir de nouvelles connaissances dans le domaine de la standardisation des
processus de développement des logiciels CMMI. En particulier le domaine de
processus de la gestion des exigences REQM (Requirement Management).

Enfin, nous espérons que la réalisation du système gestion des exigences continuera
sur la base de notre travail et intégrera de nouvelles technologies qui utilisent des
aspects décisionnels comme le DataWarehouse.
66
Projet : Gestion des Incidents

Bibliographie

- UML 2 en action
De l’analyse des besoins à la conception
4e édition

- ITIL pour un service informatique Optimal


2nd Edition
Christian DUMOND

- Gestion de projet, vers les méthodes agiles


2nd Edition

- Hibernate 3.0,
Anthony PATRICIO

- Practical Apache Struts 2 web 2.0 Projects


Ian ROUGHLEY
67
Projet : Gestion des Incidents

Webographie

- http://struts.apache.org
- http://www.learntechnology.net
- http://www.vaannila.com
- http://www.roseindia.net/struts2
68
Projet : Gestion des Incidents