4 Projet: Gestion des Incidents

BELASLA MEHDIBouing AliZEGHARI KAWTARHAMDOUN FATIMA ZAHRAEtude et mise en place dun systme de GESTION DES INCIDENTS sous le rfrentiel ITILIngnierie Informatique et RseauOption: MIAGE

2010-2011

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 fruitsDe leur bonne ducation

A nos amis

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

Nous ddions ce mmoire.

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 juryPour 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.

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,

Liste des tableaux

Tableau 1Livrable du projet

Tableau 2phases du projet

Tableau 3Tableau comparatif des diffrents cycles de dveloppement

Tableau 4Etude pralable

Tableau 5Phase danalyse et de conception

Tableau 6Phase dimplmentation et test

Tableau 7Phase de Dploiement et recette

Tableau 8Risques de projet

Tableau 9Liste des modules

Tableau 10Prsentation du use case sauthentifier

Tableau 11Prsentation du use case grer les incidents

Tableau 12Prsentation du use case Rechercher Incident

Tableau 13Prsentation du use case grer les problmes

Liste des FiguresFigure 1Organigramme de la FBPMC

Figure 2Organigramme de la DSI

Figure 3Cycle de vie XP

Figure 4Planning initial du projet

Figure 5Planning Rlle du projet

Figure 6Processus gestion des incidents

Figure 7Cycle de vie de lincident

Figure 8Les niveaux dun incident

Figure 9Diagramme illustrant les acteurs du systme

Figure 10Diagramme de use case Gestion des Incidents .

Figure 11Diagramme squence : Sauthentifier

Figure 12Diagramme squence : Ajouter incident

Figure 13Diagramme de classe gestion des incidents

Figure 14Diagramme de use case gestion des problmes

Figure 15Diagramme de squence supprimer un problme

Figure 16Diagramme de classe gestion des problmes

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

Figure 18Diagramme de classe gestion des intervenants

Figure 19Diagramme de classe

Figure 20Diagramme de dploiement

Figure 21La page dauthentification

Figure 22La page gestion des incidents

Figure 23La page dtail du ticket

Figure 24La page de liste de problmes

Figure 25La page dassocier une solution n incident

Figure 26La page de cration dun incident

Table de matireIntroduction gnrale9Chapitre 111Contexte gnral du projet111-Organisme daccueil: FONDATION Banque Populaire Pour le Micro Credit (FBPMC)121.1 Prsentation121.2 Missions121.3 Entit du stage (Direction du Systme dInformation et Organisation)121.4 Organigrammes122- Cadre gnral du projet143 - Pourquoi Gestion des incidents14Chapitre 215Contexte Gnral du projet15Partie I: Primtre du projet16I. But du projet16II. Objectifs du projet16III. Livrable du Projet17Tableau 1 : Livrable de projet17Partie II: Conduite du projet:17I. processus de dveloppement XP17II. Phases du Projet18III. Comparaison des diffrents cycles de dveloppement19IV. Cycle de vie du projet20V. Description des phases21IV. Planning Prvisionnelle du projet22Figure 4 : Planning initial du projet23VII. Planning Rel du projet:23VIII. Risques du projet:24a. Equipe MOE25b.Equipe MOA25Conclusion26Chapitre 327Gestion des incidents sous ITIL27De Niveaux de Service (SLAs)28Conclusion32Chapitre 433Cahier des charges331)Objectifs de loutilGestion des incidents34Conclusion37Chapitre 538Etude des besoins381-Prsentation du langage de modlisation UML:393.Exploration40Tableau 9: Liste des modules404 Les acteurs du systme406 Modules et Fonctionnalits principaledu systme :41Figure 15: Diagramme de squence supprimer un problme48Figure 17: Diagramme de cas d'utilisation du module Gestion des interventions50Diagramme de classe gestion des intervenants:50Figure 18: Diagramme de classe gestion des intervenants516 Diagramme de classes Global51Conclusion:52Chapitre 653Ralisation53Le diagramme de dploiement permet de visualiser les tapes principales du projet, il dcrit la distribution lapplication GESTION DES INCIDENTS542. Technologies utiliss:54Environnements de Dveloppement543. Prsentation des interfaces de lapplication:58Authentification:58Ecran des tickets:59*59Figure 22: La page gestion des incidents59Ecran de dtails des tickets:59Conclusionet prospectives:62Bibliographie64Webographie65-http://struts.apache.org65-http://www.learntechnology.net65-http://www.vaannila.com65-http://www.roseindia.net/struts265

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.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.

Chapitre 1Contexte 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.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.

1.4 Organigrammesa) Lorganigramme de le FBPMC:

Figure 1: Organigramme de la FBPMC

b) Organigramme de la DSI

Figure 2: Organigramme de la DSI

2- Cadre gnral 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 ITILConclusion: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.

Chapitre 2Contexte Gnral du projet

Dans ce chapitre nous allons prsenter le primtre du projet, les livrables, les risques, ainsi que le choix mthodologique adopt, et le planning suivi.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.

II. III. Livrable du Projet

PhaseLivrableResponsableDate de livraison prvueDate de livraison relleDate validation prvue

Avant projet Plan de qualit projet & Hamdoun & Zeghari18/06/201122/06/201122/06/2011

Etude pralable Cahier des charges Dossier de spcifications gnralesHamdoun & Zeghari25/06/201130/06/201102/07/2011

Analyse et Conception Dossier des spcifications dtailles. Dossier de conception.Hamdoun & Zeghari13/07/201127/07/201127/07/2011

Implmentation et test Code source.Hamdoun & Zeghari29/07/201102/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.

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.

PhasesActivits

ExplorationDfinir les fonctionnalits du logiciel, et rdiger des besoins sous forme de "user stories" et estimation de leur dure.

PlanningRunion entre client et dveloppeurs pour dterminer les actions mettre en uvre et estimer leurs dures.

RalisationElle prend en charge le suivi des tches, ainsi que les activits d'analyse du besoin, de conception, d'implmentation et de test correspondantes.

ProductionClture ditration aprs le dploiement du logiciel chez le client et en cas ditration restante retourn la phase planning.

Tableau 2 : phases du projet

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

DescriptionsPoints fortsPoints faibles

ProcessusRUP

- 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

Processus2TUP

- Sarticule autour de larchitecture - Propose un cycle de dveloppement en Y - Dtaill dans UML en action - Cible des projets de toutes tailles

- Itratif - Fait une large place la technologie et la gestion du risque - Dfinit les profils des intervenants, les livrables, les plannings, les prototypes

- Plutt superficiel sur les phases situes en amont et en aval 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.

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

ObjectifsExtraire les besoins du client Dfinir toutes les rgles de gestions appropries aux besoins demands.Validation de la comprhension de lapplication

Livrables en sortiePlanning de suiviDossier de spcifications gnrales.

Critres de fin de phaseComprhension fonctionnelle et technique de lapplication.

Tableau 4: Etude pralablePhase danalyse et de conception

ObjectifsAppropriation fonctionnelle et technique de lapplicationValidation de la comprhension de lapplicationRalisation de la spcification dtaille de tous les modules en charge.

Livrables en sortieDossier de spcifications fonctionnelles et techniques

Critres de fin de phase Livraison dun dossier de spcification dtaille qui prpare au dveloppement.

Phase danalyse et de conception:

Tableau 5:Phase danalyse et de conception Phase dimplmentation et testPhase 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 sortieRapport de test

Critres de fin de phase Livraison du manuel dutilisateur.

Tableau 6: Phase dimplmentation et test

Phase de Dploiement et recettePhase 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

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:

Figure 5: Planning Relle du projet

VIII. Risques du projet:

RisqueImpactsolution

Non-respect des dlaisLe projet ne sera pasachev dans la date prvue, on peut avoir un retard dans la livraison de l'application

-Doubler leffort et ajuster le planning pour respecter la planification faite audpart.

Les pannes inattendues du matrielRalentissement des travaux

Utiliser les autres matriaux disponibles.-Recours une rparation rapide

Absence ou maladieRalentissement des travauxDoubler leffort et travailler un temps extra.

Insatisfaction du clientEchec 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 MOENomFonction / rle pour le projetMail

Hamdoun FatimazahraZeghari kawtar Ingnieur tudes et dveloppement Ingnieur tudes et dveloppementHamdoun.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,

b.Equipe MOA

NomFonction / rle pour le projetMail

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.

Chapitre 3Gestion des incidents sous ITIL Nous avons consacr ce chapitre la Gestion des incidents sous la rfrence ITIL 1 ObjectifLa 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 activitsMtiers 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 ContratsDe 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 :

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)

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 base3.1 Cycle de vie dun Incident

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.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 deMise 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

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.

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 4Cahier des charges

1) Objectifs de loutilGestion 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 incidentsLe 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, Agent2) 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 incidents 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 mtierPendant et aprs cette mise en uvre.Il est essentiel pour trouver un quilibre entre la ncessit dun Changement et limpact (ngatif) de ce ChangementLes 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

La gestion des incidents

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

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 et comprhensibles par tous. Conclusion

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

Chapitre 5Etude 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.

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 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 besoinsUne bonne expression des besoins est indispensable la ralisation ou lintgration dune solution informatique russie. Pour russir une expression des besoins pertinente et comprhensible lutilisation de dmarches et de mthodes spcifiques est souhaitable. 3. Exploration

Le tableau suivant regroupe les diffrents modules:

ModuleDescription

IncidentsCe module permet de grer les incidents crer par les Agents et affects aux intervenants.

InterventionCe module gre et garde la traabilit des interventions raliss par les intervenants.

changementsLorsqu'un Changement est rendu ncessaire, il faut valuer les risques de sa mise en uvre et la continuit de lactivit mtier

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

problmesMinimiser 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 systmeLes acteurs qui interagissent avec lapplication sont:Acteurs humains:

Agent. Intervenant. Administrateur.

Acteurs systme:Aucun acteur systme nest identifi. Nant

Figure 9: Diagramme illustrant les acteurs du systme

6 Modules et Fonctionnalits principaledu 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. Validation dune Incident. Consulter la liste des Incidents.

Figure 10: Diagramme de use case Gestion des Incidents .

Descriptions des cas dutilisations:NomSauthentifier

ObjectifLutilisateur 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 principauxIntervenant, Agent, Administrateur

Acteurs secondaires---

Pr conditionsLutilisateur nest pas authentifi

ExceptionsUtilisateur dsactiv

Flot dvnements1. Lutilisateur saisi son login et son mot de passe2. 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 conditionLutilisateur est authentifi

Tableau 10:Prsentation du use case sauthentifier

NomGrer Incident

ObjectifLutilisateur 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 principauxAdministrateur

Acteurs secondaires---

Pr conditionsLutilisateur est authentifi et possde les droits.

ExceptionsUtilisateur dsactiv

Flot dvnements1. Lutilisateur consulte la liste des incidents2. Lutilisateur modifie lincident3. 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

NomRechercher Incident

ObjectifLutilisateur recherche un incident.

Acteurs principauxAdministrateur, Intervenant

Acteurs secondaires---

Pr conditionsLutilisateur est authentifi.

ExceptionsUtilisateur dsactiv

Flot dvnementsLutilisateur recherche un incident

Post condition---

Tableau 12:Prsentation du use case Rechercher Incident

Diagramme de squencesystme Sauthentifier :

Figure 11: Diagramme squence : Sauthentifer

Diagramme de squencesystme Ajouter incident :

Figure 12 Diagramme squence : Ajouter incident

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.

Figure14: Diagramme de use case gestion des problmes

Descriptions des cas dutilisations:

NomSauthentifier

ObjectifLutilisateur 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 principauxIntervenant, Administrateur

Acteurs secondaires---

Pr conditionsLutilisateur nest pas authentifi

ExceptionsUtilisateur dsactiv

Flot dvnements1. Lutilisateur saisi son login et son mot de passe2. 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 conditionLutilisateur est authentifi

NomGrer Les problmes

ObjectifLutilisateur 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 principauxAdministrateur

Acteurs secondaires---

Pr conditionsLutilisateur est authentifi et possde les droits.

ExceptionsUtilisateur dsactiv

Flot dvnements1. Lutilisateur consulte la liste des problmes2. Lutilisateur modifie le problme3. 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---

Tableau 13:Prsentation du use case grer les problmes

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.

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

Description des cas des utilisations:

NomAssocier une solution un incident

ObjectifCe cas d'utilisation permet aprs le traitement de lincident dassocier la solution trouve lincident.

Acteurs principauxAdministrateur, Intervenant

Acteurs secondaires---

Pr conditionsLutilisateur est authentifi et possde les droits.

ExceptionsUtilisateur dsactiv

Flot dvnements1. demander la liste des incidents 2. choisir un incident et cliquer sur dtails3 Associer solution lincident.

Post condition---

Diagramme de classe gestion des intervenants:

Figure 18: Diagramme de classe gestion des intervenants

6 Diagramme de classes Global

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.

Chapitre 6Ralisation

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.

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 INCIDENTSFigure 20: Diagramme de dploiement

2. Technologies utiliss:

Environnements de Dveloppement

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 duserveur 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 fonctionnalits.Sunfournit une implmentation minimale de ces API appeleJ2EE 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

Hibernanteest unFrameworkopen sourcegrant lapersistancedesobjetsenbase de donnes relationnelle.Hibernate est adaptable en termes d'architecture, il peut donc tre utilis aussi bien dans undveloppementclient lourd, que dans un environnement web lger de typeApache Tomcatou dans un environnementJ2EEcomplet:WebSphere,JBoss Application ServeretOracle 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 Strutsest unframeworklibreservant au dveloppement d'applications webJ2EE. Il utilise et tend l'APIServlet Javaafin d'encourager les dveloppeurs adopter l'architectureModule-Vue-Contrleur. 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:

MySQLest unsystme de gestion de base de donnes(SGBD). Selon le type d'application, sa licence estlibreoupropritaire. Il fait partie des logiciels de gestion debase de donnesles plus utiliss au monde, autant par le grand public (applications web Principalement) que par des professionnels, en concurrence avecOracleetServer. 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 ConteneurlibredeservletsJ2EE. Issu du projetJakarta, Tomcat est un projet principal de lafondation Apache. Tomcat implmente les spcifications desservletset desJSPduJava Community Process1. Il est paramtrable par des fichiersXMLet de proprits, et inclut des outils pour la configuration et la gestion. Il comporte galement unserveur http, Tomcat est unserveur Webqui gre lesservletset lesJSP. C'est le compilateurJasperqui compile les pages JSP pour en faire des servlets. Le moteur de servlet Tomcat est souvent employ en combinaison avec unserveur Web Apacheou d'autres serveurs Web.Tomcat a t crit enlangage Java. Il peut donc s'excuter via lamachine virtuelle Javasur 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.

Figure21: La page dauthentification

Ecran des tickets:

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

*Figure 22: La page gestion des incidents

Ecran de dtails des tickets:

Cet cran permet dafficher le dtail de chaque ticket.

Figure23: La page dtail du ticket

Ecran des problmesCet cran permet dafficher la liste des problmes existantsFigure 24 : La page de liste de problmes

Ecran de gestion des intervenantsCet cran permet dassocier une solution un incidentFigure 25 : La page dassocier une solution n incident

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

Figure 26 : La page de cration dun incident

Conclusionet 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 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.

Bibliographie

UML 2 en actionDe lanalyse des besoins la conception4e dition

ITIL pour un service informatique Optimal2nd EditionChristian DUMOND

Gestion de projet, vers les mthodes agiles2nd Edition

Hibernate 3.0, Anthony PATRICIO

Practical Apache Struts 2 web 2.0 ProjectsIan ROUGHLEY

Webographie

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