SlideShare une entreprise Scribd logo
1  sur  116
Télécharger pour lire hors ligne
SUPTECH
2014/2015
Page1
Table des matières
Chapitre I. Présentation générale........................................................................................................... 10
I. Organisme d’accueil...................................................................................................................... 11
1. YAZAKI.................................................................................................................................... 11
A. Historique du groupe YAZAKI............................................................................................. 11
B. Logo ...................................................................................................................................... 11
C. Les filiales de YAZAKI ........................................................................................................ 12
D. YAZAKI Tunisie................................................................................................................... 12
E. YAZAKI Bizerte ................................................................................................................... 13
II. Présentation du projet.................................................................................................................... 14
2. Problématique............................................................................................................................ 14
A. La non maitrise du hardware et du software.......................................................................... 14
B. Le manque de traçabilité et de suivi de l’équipement ........................................................... 14
C. Equipements non recensés..................................................................................................... 15
D. Gestion rapide des incendies ................................................................................................. 15
3. Objectif...................................................................................................................................... 15
4. Description du projet................................................................................................................. 15
Chapitre II. Etat de l’art......................................................................................................................... 17
I. Etude de l’existant......................................................................................................................... 18
1. Clarilog[2]................................................................................................................................... 18
2. Spiceworks[3] ............................................................................................................................. 19
3. GLPI[4] ....................................................................................................................................... 19
II. Critique de l’existant ..................................................................................................................... 20
III. Solution Proposée...................................................................................................................... 20
IV. Méthodologie du développement .............................................................................................. 21
1. Langage de modélisation........................................................................................................... 21
2. Méthodologie adopté................................................................................................................. 22
Chapitre III. Phase incubation............................................................................................................... 24
I. Identification des besoins .............................................................................................................. 25
1. Les besoins fonctionnels............................................................................................................ 25
2. Les besoins non fonctionnels..................................................................................................... 26
SUPTECH
2014/2015
Page2
3. Acteurs et cas d’utilisation ........................................................................................................ 27
A. Acteurs du système................................................................................................................ 27
B. Cas d’utilisation par acteur.................................................................................................... 29
4. Cas d’utilisations par priorité .................................................................................................... 31
5. Raffinement des cas d’utilisation de priorité « 1 ».................................................................... 33
A. Raffinement du cas d’utilisation « S’authentifier »............................................................... 33
B. Raffinement du cas d’utilisation « Gérer les tickets »........................................................... 34
C. Raffinement du cas d’utilisation « Gérer l’inventaire » ........................................................ 37
D. Raffinement du cas d’utilisation « Gérer les prêts téléphoniques » ...................................... 39
6. Diagramme du cas d’utilisation global...................................................................................... 46
II. Conception..................................................................................................................................... 47
1. Diagramme de classe « gestion de parc informatique »............................................................ 47
2. Diagramme de séquence du cas d’utilisation « S’authentifier »................................................ 48
3. Diagramme de séquence du cas d’utilisation « Gérer les tickets »........................................... 49
A. Diagramme de séquence « Créer un ticket »......................................................................... 49
B. Diagramme d’activité « Créer un ticket » ............................................................................. 50
C. Diagramme de séquence « Modifier un ticket ».................................................................... 51
D. Diagramme de séquence « Supprimer un ticket »................................................................. 53
E. Diagramme de séquence détaillé « Envoi SMS par l’application Android »........................ 54
4. Diagramme de séquence de cas d’utilisation « Gérer l’inventaire » ........................................ 55
A. Diagramme de séquence « Créer un inventaire » avec Agent Inventory .............................. 55
B. Diagramme de séquence « Consulter détails de l’inventaire ».............................................. 56
5. Diagramme de séquence « Gérer les prêts téléphoniques » ...................................................... 57
A. Diagramme de séquence « Gérer les cartes SIM »................................................................ 58
B. Diagramme de séquence « Gérer les téléphones mobiles »................................................... 59
C. Diagramme de séquence « Gérer les utilisateurs des téléphones » ....................................... 60
D. Diagramme de séquence « Gérer les opérations de prêts » ................................................... 61
E. Diagramme de séquence « Télécharger la décharge téléphonique en PDF»......................... 62
III. Elaboration des prototypes des interfaces utilisateurs............................................................... 62
1. Prototype de l’interface « Authentification » ............................................................................ 62
2. Prototype de l’interface « Créer ticket ».................................................................................... 63
3. Prototype de l’interface « Gérer inventaire » ............................................................................ 65
4. Prototype de l’interface « Gérer les prêts téléphoniques »........................................................ 66
5. Prototype de l’interface « Imprimer la décharge téléphonique » .............................................. 67
SUPTECH
2014/2015
Page3
Chapitre IV. Phase d’élaboration .......................................................................................................... 69
I. Identification des besoins .............................................................................................................. 70
1. Raffinement des cas d’utilisation de priorité « 2 ».................................................................... 70
A. Raffinement de cas d’utilisation « Gérer les comptes »........................................................ 70
B. Raffinement du cas d’utilisation « Afficher les statistiques»................................................ 73
C. Raffinement de cas d’utilisation « Gérer les catégories des problèmes informatiques» ....... 75
2. Cas d’utilisation global de la deuxième phase........................................................................... 77
II. Conception..................................................................................................................................... 78
1. Diagramme de classe................................................................................................................. 78
2. Diagramme de séquence de cas d’utilisation« Gérer les comptes ».......................................... 78
3. Diagramme de séquence de cas d’utilisation « Afficher les statistiques »................................ 80
4. Diagramme de séquence de cas d’utilisation« Gérer les catégories »....................................... 80
II. Elaboration de quelques prototypes des interfaces utilisateurs ..................................................... 82
1. Prototype de l’interface « Gérer comptes »............................................................................... 82
2. Prototype de l’interface « Afficher les statistiques »................................................................. 83
3. Prototype de l’interface « Gérer les catégories des problèmes»................................................ 85
Chapitre V. Phase construction ............................................................................................................. 86
I. Identification des besoins .............................................................................................................. 87
1. Raffinement des cas d’utilisation de priorité « 3 ».................................................................... 87
A. Raffinement du cas d’utilisation « Gérer les départements »................................................ 87
B. Raffinement du cas d’utilisation « Consulter les fichiers logs » ........................................... 89
2. Cas d’utilisation globale de la troisième phase ......................................................................... 91
III. Conception................................................................................................................................. 92
1. Diagramme de séquence du cas d’utilisation « Gérer les départements »................................. 92
2. Diagramme de séquence du cas d’utilisation « Gérer l’historique »......................................... 93
3. Diagramme de classe globale.................................................................................................... 94
4. La base des données de l’application ........................................................................................ 96
IV. Elaboration de quelques prototypes des interfaces utilisateurs ................................................. 97
1. Prototype de l’interface « Gérer les départements ».................................................................. 97
2. Prototype de l’interface « Consulter/Télécharger fichier log » ................................................. 98
Chapitre VI. Phase transition................................................................................................................. 99
I. Architecture logicielle du système .............................................................................................. 100
II. Environnement de réalisation..................................................................................................... 102
1. Environnement matériel ......................................................................................................... 102
SUPTECH
2014/2015
Page4
2. Environnement logiciel............................................................................................................ 103
III. Mise en place de l’application................................................................................................. 103
1. Interface « Authentification ».................................................................................................. 103
2. Interface « Liste des tickets ouverts » ..................................................................................... 104
3. Interface « Les détails d’un ticket » ........................................................................................ 105
4. Interface « Les détails d’un ordinateur inventorié»................................................................. 105
5. Interface « Liste des logiciels installés dans un ordinateur » .................................................. 106
6. Interface « Liste des imprimantes installés dans un ordinateur »............................................ 106
7. Interface « Les détails d’un prêt téléphonique »...................................................................... 107
Conclusion générale ............................................................................................................................ 108
Annexes............................................................................................................................................... 109
Bibliographie....................................................................................................................................... 116
SUPTECH
2014/2015
Page5
Liste des figures
Figure 1: Logo de YAZAKI.................................................................................................................. 11
Figure 2: YAZAKI à travers le monde.................................................................................................. 12
Figure 3: Câblage fini............................................................................................................................ 13
Figure 4 : Clarilog ................................................................................................................................. 18
Figure 5 : Spiceworks............................................................................................................................ 19
Figure 6 : GLPI...................................................................................................................................... 19
Figure 7 : Architecture adoptée pour le développement de l’application.............................................. 21
Figure 8 : schéma de la méthodologie................................................................................................... 23
Figure 9 : fonctionnalités de Responsable informatique/Superviseur ................................................... 29
Figure 10 : fonctionnalités d’un technicien informatique ..................................................................... 30
Figure 11 : fonctionnalités d’un Employé administratif........................................................................ 31
Figure 12 : diagramme de cas d'utilisation « s’authentifier »................................................................ 33
Figure 13 : diagramme de cas d'utilisation « Gérer les tickets »........................................................... 34
Figure 14 : diagramme de cas d'utilisation « Gérer l’inventaire »......................................................... 37
Figure 15 : diagramme de cas d'utilisation « Gérer les prêts téléphoniques »....................................... 39
Figure 16 : Diagramme de cas d’utilisation globale.............................................................................. 46
Figure 17 : Diagramme de classe du système ....................................................................................... 47
Figure 18 : Diagramme de séquence « Authentification ».................................................................... 48
Figure 19 : Diagramme de séquence « Créer un ticket »....................................................................... 49
Figure 20 : Diagramme d’activité « Créer un ticket »........................................................................... 50
Figure 21 : Diagramme de séquence « Modifier un ticket » ................................................................. 52
Figure 22 : Diagramme de séquence « Supprimer un ticket »............................................................... 53
Figure 23 : Diagramme de séquence détaillé de « l’envoi SMS par Android ».................................... 54
Figure 24 : Diagramme de séquence « Créer un inventaire » ............................................................... 55
Figure 25 : Diagramme de séquence « Consulter détails de l’inventaire » ........................................... 56
Figure 26 : Diagramme de séquence « Gérer les cartes SIM » ............................................................. 58
Figure 27 : Diagramme de séquence « Gérer les téléphones mobiles »................................................ 59
Figure 28 : Diagramme de séquence « Gérer les utilisateurs des téléphones»...................................... 60
Figure 29 : Diagramme de séquence « Gérer les opérations de prêts »................................................. 61
Figure 30 : Diagramme de séquence « Télécharger la décharge en PDF »........................................... 62
Figure 31 : Interface d’authentification................................................................................................. 63
Figure 32 : Interface d’ajout d’une nouvelle demande d’intervention .................................................. 63
Figure 33 : Interface de ticket reçu avec Microsoft Outlook................................................................. 64
Figure 34 : Interface de ticket reçu par SMS......................................................................................... 64
Figure 35 : Interface de l’application Android...................................................................................... 65
Figure 36 : Interface des listes des ordinateurs inventoriés................................................................... 65
Figure 37 : Interface d’ajout d’un nouveau prêt téléphonique .............................................................. 66
Figure 38 : Interface exemple d’une décharge téléphonique en PDF.................................................... 67
Figure 39 : diagramme de cas d'utilisation « Gérer les comptes » ........................................................ 70
Figure 40 : diagramme de cas d'utilisation « Afficher les statistiques » ............................................... 73
SUPTECH
2014/2015
Page6
Figure 41 : Description textuelle du cas d’utilisation « Afficher les statistiques » ............................... 74
Figure 42 : diagramme de cas d'utilisation « Gérer les catégories » ..................................................... 75
Figure 43 : diagramme de cas d'utilisation global du 2éme phase ........................................................ 77
Figure 44 : diagramme de classe de priorité « 2 »................................................................................. 78
Figure 45 : Diagramme de séquence « Gérer les comptes » ................................................................. 79
Figure 46 : Diagramme de séquence « Gérer les catégories »............................................................... 80
Figure 47 : Diagramme de séquence « Gérer les catégories »............................................................... 81
Figure 48: interface « Gestion des comptes » ....................................................................................... 82
Figure 49 : Interface Consulter les statistiques systèmes (1)................................................................. 83
Figure 50 : Interface Consulter les statistiques systèmes (2)................................................................. 84
Figure 51: interface « Gestion des catégories »..................................................................................... 85
Figure 52 : diagramme de cas d’utilisation« Gestion des départements » ............................................ 87
Figure 53 : diagramme de cas d’utilisation« Gérer l’historique »......................................................... 89
Figure 54 : diagramme de cas d’utilisation globale du 3éme phase...................................................... 91
Figure 55 : Diagramme de séquence « Gérer les départements ».......................................................... 92
Figure 56 : Diagramme de séquence « Gérer l’historique ».................................................................. 93
Figure 57 : Diagramme de classe globale.............................................................................................. 94
Figure 58 : Schéma de la base des données........................................................................................... 96
Figure 59 : Interface « Gérer les départements ..................................................................................... 97
Figure 60 : Interface « Historiques des transactions téléphoniques » ................................................... 98
Figure 61 : Modèle générale de l’architecture orienté service ............................................................ 100
Figure 62 : Les couches de l’application............................................................................................. 101
Figure 63 : interface « authentification » ............................................................................................ 103
Figure 64 : interface « liste des tickets ouverts» ................................................................................. 104
Figure 65 : interface « les détails d’un tickets»................................................................................... 105
Figure 66 : interface « les détails d’un ordinateur»............................................................................. 105
Figure 67 : interface « liste des logiciels installés dans un ordinateur» .............................................. 106
Figure 68 : interface « liste des imprimantes installés dans un ordinateur»........................................ 106
Figure 69 : interface « les détails d’un prêt téléphonique».................................................................. 107
SUPTECH
2014/2015
Page7
Liste des tableaux
Tableau 1: Affectation des priorités aux cas d’utilisations.................................................................... 32
Tableau 2 : Description textuelle du cas d’utilisation « S’authentifier » .............................................. 34
Tableau 3 : Description textuelle du cas d’utilisation « Créer/Ouvrir un ticket »................................. 35
Tableau 4 : Description textuelle du cas d’utilisation « Répondre/Fermer un ticket » ......................... 35
Tableau 5 : Description textuelle du cas d’utilisation « Consulter un ticket »...................................... 36
Tableau 6 : Description textuelle du cas d’utilisation « Supprimer un ticket »..................................... 37
Tableau 7 : Description textuelle du cas d’utilisation «Consulter liste des imprimantes».................... 38
Tableau 8 : Description textuelle du cas d’utilisation « Consulter liste des ordinateurs ».................... 38
Tableau 9 : Description textuelle du cas d’utilisation « Consulter liste des logiciels » ........................ 38
Tableau 10 : Description textuelle du cas d’utilisation « Ajouter un téléphone »................................. 40
Tableau 11: Description textuelle du cas d’utilisation « Modifier un téléphone »................................ 40
Tableau 12 : Description textuelle du cas d’utilisation « Supprimer un téléphone »............................ 41
Tableau 13 : Description textuelle du cas d’utilisation « Ajouter une carte SIM »............................... 41
Tableau 14 : Description textuelle du cas d’utilisation « Modifier une carte SIM »............................. 42
Tableau 15 : Description textuelle du cas d’utilisation « Supprimer une carte SIM ».......................... 42
Tableau 16 : Description textuelle du cas d’utilisation « Ajouter un prêt ».......................................... 43
Tableau 17 : Description textuelle du cas d’utilisation « Modifier une opération de prêt » ................. 44
Tableau 18 : Description textuelle du cas d’utilisation « Supprimer une transaction » ........................ 44
Tableau 19 : Description textuelle du cas d’utilisation « Récupérer téléphone & SIM » ..................... 45
Tableau 20 : Description textuelle du cas d’utilisation « Créer un nouveau compte » ......................... 71
Tableau 21 : Description textuelle du cas d’utilisation « Modifier un compte » .................................. 72
Tableau 22 : Description textuelle du cas d’utilisation « Supprimer un compte »................................ 72
Tableau 23 : diagramme de cas d'utilisation « Ajouter une catégorie »................................................ 75
Tableau 24 : diagramme de cas d'utilisation « Modifier une catégorie ».............................................. 76
Tableau 25 : Description textuelle du cas d’utilisation « Supprimer une catégorie » ........................... 76
Tableau 26 : Description textuelle du cas d’utilisation « Ajouter un département » ............................ 88
Tableau 27 : Description textuelle du cas d’utilisation « Modifier un département » .......................... 88
Tableau 28 : Description textuelle du cas d’utilisation « Supprimer un département »........................ 89
Tableau 29 : Description textuelle du cas d’utilisation « Consulter l’historique » ............................... 90
Tableau 30 : Description textuelle du cas d’utilisation « Télécharger fichier log ».............................. 90
Tableau 31 : Caractéristique poste de travail ...................................................................................... 102
Tableau 32 : Environnement logiciel .................................................................................................. 103
SUPTECH
2014/2015
Page8
Introduction générale
Avec le développement de plus en plus de l’utilisation des ressources informatiques dans les
entreprises, l’objectif de ces derniers devient la recherche perpétuelle de solutions pratiques
pour la gestion efficace de leur parc. Un parc informatique est un ensemble de ressources
matérielles et logicielles dont dispose une entreprise dans le traitement automatisé de
l’information.
Pour assurer la survie et la pérennité de ses ressources, il est important d’avoir une gestion
efficiente du parc informatique de l’entreprise. La gestion du parc informatique consiste donc
d’une part à lister et à localiser les équipements de l’entreprise, d’autre part à effectuer des
tâches de maintenance, d’assistance aux utilisateurs. Ces opérations peuvent être effectuées
par une personne qualifiée, mais bien souvent ce travail dépasse ses compétences.
Pour pallier à cela, il est nécessaire qu’un ou plusieurs outils soient mis en place au sein de
l’entreprise afin d’avoir un suivi régulier du parc informatique et parfois anticiper sur les
défaillances de ses ressources.
Notre projet de fin d’étude abordera ainsi les différentes phases de développement d’une
application de gestion de l’inventaire des composantes matérielles et logicielles d’un parc
informatique et la gestion de l’assistance aux utilisateurs, il sera divisé en cinq chapitres
principaux.
 Nous abordons par un premier chapitre intitulé « Présentation générale », qui détaille
le contexte du projet en introduisant l’organisme d’accueil et en présentant le sujet de
projet.
 Nous étudions aussi dans le deuxième chapitre intitulé « Etat de l’art » quelques
applications de gestion des parcs informatiques en vue de les critiquer et dégager les
points forts pour les exploiter dans notre produit.
 Dans le troisième chapitre intitulé « Phase d’incubation », nous allons concentrer sur
la compréhension du contexte en levant l’ambiguïté sur les besoins ainsi que la
définition des besoins fonctionnels et non fonctionnels, l’identification des acteurs,
etc.
 Après la compréhension des exigences du système en passe au quatrième chapitre
intitulé « Phase d’élaboration », ou nous allons continuer la construction de notre
système. Nous allons présenter également le modèle de conception et
d’implémentation des cas d’utilisation.
SUPTECH
2014/2015
Page9
 Dans le cinquième chapitre intitulé « Phase de Construction », nous allons présenter
tous les besoins restants en continuant l’analyse, la conception et l’implémentation de
tous les cas d’utilisation.
 Le dernier chapitre intitulé « Phase de Transition », nous allons présenter notre
architecture qu’on a utilisée, l’environnement de travail et quelque interface sous
forme d’un guide utilisateur.
Notre rapport se terminera par une conclusion générale donnant une synthèse de travail
effectué. Par ailleurs, certaines annexes sont jointes pour fournir plus de détails.
SUPTECH
2014/2015
Page10
Chapitre I. Présentation générale
SUPTECH
2014/2015
Page11
Chapitre 1
Présentation générale
Introduction
Ce chapitre a pour objectif de situer le projet dans son contexte général. Pour ce faire,
nous présentons dans un premier lieu l’organisme d’accueil, ensuite, nous décrivons
minutieusement le projet en dégagent les problèmes en vue de préciser les objectifs.
I. Organisme d’accueil
Dans le cadre du projet de fin d’étude et pour le but de l’obtention du diplôme national
d’ingénieur en informatique appliquée à la multimédia au sein de l’école Supérieure
Privée de Technologie et de Management, la Société YAZAKI Automotive Products
(YAPT) nous propose un projet a réalisé pour quatre mois.
1. YAZAKI
A. Historique du groupe YAZAKI
YAZAKI [1] est l’un des plus grand producteur du monde de câblage automobile et un
joueur dans la fabrication des systèmes de la distribution électrique et électroniques,
l’instrumentation électronique et les composants pour les voitures.
La date de succès de YAZAKI était en 1929, quand Sadami YAZAKI a commencé à
vendre les câblages pour les automobiles. En 1939, l’affaire pourrait être étendue et en
1941, YAZAKI Fil Electrique Industriel Co. Ltd a été établi avec approximativement
70 employés.
B. Logo
Figure 1: Logo de YAZAKI
SUPTECH
2014/2015
Page12
C. Les filiales de YAZAKI
YAZAKI est représentée dans 38 pays dans le monde, 175 sites, 410 unités réparties
entre usines de production et centres de service au client et centres de Recherche &
Développement.
Figure 2: YAZAKI à travers le monde
D. YAZAKI Tunisie
L'usine du groupe japonais YAZAKI est opérationnelle en Tunisie depuis juin 2010.
Dans une première étape, le groupe japonais a installé une unité pilote chargée de former,
jusqu'à fin 2009, les futurs travailleurs (800) et cadres (150) de l'usine. L'unité est gérée par
des compétences Tunisiennes.
Le coût total de réalisation et d'équipement du projet japonais s'élèvera à 24 millions d'Euros
et devra créer 2500 emplois directs (dont 308 emplois de cadres supérieurs (bac +2)). Le
choix de la Tunisie, le deuxième pays africain dans lequel le groupe japonais réalise un projet
s'explique essentiellement par le niveau de compétence de ses cadres.
En 2012, le processus s’est poursuivi. En effet, après le site de Gafsa, le groupe japonais lance
son deuxième site en Tunisie, plus précisément à Bizerte.
SUPTECH
2014/2015
Page13
E. YAZAKI Bizerte
Le groupe japonais YAZAKI s’est installé dans la région de Bizerte en faisant
l’acquisition de la société de câblage de voiture « SCV » du groupe italien
« Cabletettra » installée en Tunisie depuis 2001.YAZAKI a acquis tous les sites du
groupe italien situé à Menzel Djemil et à Menzel Bourguiba et qui possédaient un
effectif d’environ 1200.
Le choix de la ville de Bizerte est légitimé par plusieurs raisons dont les principales
sont:
 La proximité avec le continent européen.
 La fréquence des liaisons et correspondances maritimes.
 La vocation même de la ville.
 Une culture ouverte et internationale : Depuis longtemps, la ville a été considérée
comme zone internationale justifiant la multiplicité des usages linguistiques : arabe,
français et anglais;
 Une abondance de main-d’œuvre régionale d’un bon niveau.
Le site de Bizerte comptait, en 2012, 1300 employés avec un objectif de 4000
employés à atteindre en 2015.
Les Activités de YAZAKI-Bizerte
L’activité principale de YAZAKI-Bizerte est l’assemblage des câbles électriques afin de
produire un câblage qui permet de connecter des différents éléments dans un système
électromécanique et de fournir de l’énergie électrique et des signaux électronique à différents
périphériques du système.
Figure 3: Câblage fini
SUPTECH
2014/2015
Page14
II. Présentation du projet
Nous présentons dans ce qui suit le projet du stage ainsi que les motivations pour lesquelles ce
projet a été mis en œuvre pour bien le comprendre et délimiter ce qui est demandé pour passer
à l’action et répondre aux spécifications d’une façon concise et efficace.
2. Problématique
L’idée générale du projet consiste à concevoir un outil applicatif qui pourra de façon concrète
permettre à un utilisateur de circonscrire un incident ou une demande de service à travers les
tickets.
Les techniciens informatiques seront capables de recevoir instantanément ces demandes via
Mail et SMS afin d’assurer le bon déroulement de l’information et la rapidité des
interventions.
L’administrateur utilisera le même système pour gérer le prêt des téléphones mobiles, les
cartes SIM et leurs accessoires.
Ce système devra offrir aussi la possibilité d’inventorier les machines d’un parc informatique.
Avant de plonger dans l’étude proprement dite de la solution, il est indispensable de prendre
du recul et de faire un résumé des problèmes concrets existants qui peuvent rencontrer les
acteurs.
C’est donc dans cette optique qu’une petite enquête a été menée auprès de ces personnes et la
plupart des problèmes recensés dans le parc de la société YAZAKI sont les suivants :
A. La non maitrise du hardware et du software
En tête de liste, ce problème est le plus récurrent chez la plupart des administrateurs réseaux
et systèmes. En effet, le nombre croissant d’équipements et l’hétérogénéité du parc ne
permettent pas à ceux-ci de maitriser tous les systèmes, logiciels et matériaux installés.
B. Le manque de traçabilité et de suivi de l’équipement
De nos jours, le contrôle et le suivi des équipements dans les entreprises devront se faire
d’une manière informatisé et automatique, dans le cas de la société YAZAKI ils manquent le
suivi et la traçabilité des téléphones mobiles et les cartes SIM utilisés par les personnels de la
société.
SUPTECH
2014/2015
Page15
C. Equipements non recensés
Dans le réseau d’une entreprise, lorsqu’un équipement tombe en panne, nous avons du mal à
le remplacer par un équipement adéquat (même système, même modèle, même
périphérique…) qui remplirait exactement les mêmes fonctions. Ceci est dû au fait que le
stock des ressources de l’entreprise n’est pas inventorié.
D. Gestion rapide des incendies
Les techniciens informatiques sensés de résoudre et répondre aux demandes d’interventions
peuvent être ne pas informer de ces problèmes s’ils sont loin de leurs PCs ou leurs boites mail
chargés ne leurs permet pas de bien voir la demande et de le récupérer à temps.
L’application proposée devra ainsi être à mesure d’apporter une solution concrète à la prise en
charge des différents problèmes ci-dessus.
3. Objectif
Dans ce cadre, le service IT pense aux innovations technologiques qui prennent de plus en
plus de l’importance dans les nouvelles entreprises, on parle notamment des technologies qui
transforment les habitudes de travail quotidiennes, elles les automatisent en partie, réduisent
généralement le volume de tâches bureautiques et améliorent la coordination.
Pour ce faire YAZAKI cherche la mise en place d’une application qui aborde les nouveaux
enjeux dans le service informatique à fin d’automatiser les activités et les organiser, dans le
cadre de ce projet on s’intéresse en particulier à développer une solution web de gestion des
parcs informatique et de Help Desk.
4. Description du projet
Ce projet, qui consiste a réalisé une application web permettant de couvrir trois modules. Le
premier module concerne la gestion des interventions et qui comprend la notification par Mail et
par SMS de chaque nouvelle demande envoyé.
Le deuxième module destiné à faire l’inventaire d’un parc informatique en tant que machines
et logiciels d’une manière automatique grâce à une application exécutable. Le troisième
module offre la possibilité de faire la gestion des prêts des téléphones mobiles et des cartes
SIM avec l’impression des décharges.
SUPTECH
2014/2015
Page16
Conclusion
Dans ce chapitre introductif, nous avons présenté l’organisme d’accueil ainsi que le projet à
réaliser. Nous allons entamer maintenant la phase de préparation de ce projet qui est l’étude
de l’existant et la présentation des différentes solutions disponibles sur le marché.
SUPTECH
2014/2015
Page17
Chapitre II. Etat de l’art
SUPTECH
2014/2015
Page18
Chapitre 2
Etat de l’art
Introduction
Ce chapitre a pour objet de présenter quelques applications pour la gestion des parcs
informatiques d’une manière détaillée, en exposant leurs fonctionnalités.
I. Etude de l’existant
Parmi les produits existants sur le marché, nous retrouvons principalement:
1. Clarilog[2]
Cette application a été créée par l’entreprise Clarilog France et permet entre autre :
 L’audit du parc informatique en utilisant le module clarilog Fast Inventory qui
permet de récolter les données sans déploiement d’agent ;
 Une cartographie complète des équipements du parc ;
Clarilog SNMP Discovery récupère les informations présentes dans le réseau via le
protocole SNMP et fait appel à un référentiel d’information alimenté par les équipes
Figure 4 : Clarilog
SUPTECH
2014/2015
Page19
2. Spiceworks[3]
Cette solution offre aux usagers les possibilités suivantes :
 Effectuer l’inventaire des machines sans déploiement d’agent ;  Gérer les
incidents (HelpDesk) ;
 Scanner le réseau ;
 Effectuer la gestion des configurations.
Figure 5 : Spiceworks
3. GLPI[4]
Cette solution open source est capable de :
 Administrer plusieurs parcs pour optimiser la maintenance
 Inventorier les machines d’un parc informatique ;
 Gérer les incidents (HelpDesk) ;
 Gérer un système de base de connaissances hiérarchique
 Donner la possibilité d’ajouter des modules complémentaires
Figure 6 : GLPI
SUPTECH
2014/2015
Page20
II. Critique de l’existant
Une analyse des solutions existantes montre que la plupart de ces applications offrent des
fonctionnalités de base de gestion d’un parc informatique à savoir l’inventaire, l’accès au
Helpdesk et le scan du réseau. Au regard de ces informations, nous pouvons relever qu’elles
répondent au besoin principal des utilisateurs. Néanmoins, nous pouvons aussi noter les
inconvénients suivants :
 Clarilog n’est pas une application open source ; Ainsi il est impossible de l’adapter
aux besoins spécifiques de YAZAKI .
 Spiceworks ne permet pas à un utilisateur d’intégrer ses propres modules pour
améliorer la performance de son parc ou pour des fonctionnalités supplémentaires.
 GLPI est un système lourd, peu ergonomique et trop chargés des fonctionnalités
inutiles. Ainsi l’accès à une fonctionnalité précise n’est pas toujours une tache facile.
 Aucun de ces solutions ne permet de recevoir les demandes d’interventions par SMS
ou par une application mobile. Ceci nous semble un obstacle pour la diffusion des
informations urgents.
 Absence d’un module de gestion de prêt des téléphones mobiles et cartes SIM.
Pour des raisons de sécurités la direction de YAZAKI préfère toujours si c’est possible de
concevoir leurs propres logiciels open sources et les développer localement selon les besoins,
et évitent toute autre solution gratuite téléchargeable sur internet.
III. Solution Proposée
Après une étude comparative sur les différentes solutions existantes, il est ainsi primordial au
regard des inconvénients et limitation recensés de proposer une solution qui pourra répondre à
nos besoins. Nous avons choisi de développer une application Web avec l’architectures Web
service offrant les fonctionnalités basiques d’un système de gestion d’un parc informatique tel
que la gestion des interventions et d’inventaires et qui offre aussi des fonctionnalités
supplémentaire telles que la gestion des prêts des téléphones mobiles et des cartes SIM et la
notification par SMS.
La solution logicielle à mettre en œuvre est décomposée en plusieurs modules :
1. Une application lourde ayant accès à des Web services distants prenant en charge le
collecte des différentes caractéristiques matérielles et logicielles d’une machine, ces
dernières seront stockés dans une base de données MySQL distante.
SUPTECH
2014/2015
Page21
2. Une application Web en J2E chargée de faire le suivi en ligne des ressources
informatiques et gérer l’ensemble des interventions ainsi que la résolution des
problèmes.
3. Un système de gestion des tickets à mettre en place pour la gestion des interventions.
Figure 7 : Architecture adoptée pour le développement de l’application
IV. Méthodologie du développement
1. Langage de modélisation
Nous avons choisi comme langage de modélisation UML[6] (Unified Modeling Languge)
reconnue comme étant le standard industriel par excellence de la modélisation objet. Il
permet, ainsi, de nous aider à modéliser un système robuste, fiable et évolutif et de limiter de
nombreux risques d’erreur vue sa simplicité de modéliser les diagrammes.
SUPTECH
2014/2015
Page22
2. Méthodologie adopté
Après avoir défini la problématique et les objectifs à atteindre, une petite étude déjà faite pour
fixer un processus de travail, donc parmi les méthodologies du développement qui existent et
en coordination avec notre projet, nous avons trouvé que le PU (Processus Unifié)[5] est la
méthodologie de travail qui peut nous orienter tout au long du projet, c’est une méthodologie
qui vient de compléter la systématique des modèles UML, elle est générique, itérative et
incrémentale, piloter par les risque, centré sur l’architecture et conduite par les cas
d’utilisation permettant de décrire les besoins et exigences des utilisateurs, autrement dit c’est
une méthode orientée par les besoins des utilisateurs.
Le Processus Unifié répète un certain nombre de fois de cycle. Le résultat de chaque cycle est
une partie exécutable du système, testée et intégrée, mais qui n’est pas prête à être livrée
(Chaque cycle se décompose par l’analyse des besoins, la conception, l’implémentation et les
tests unitaires). Nous présentons ainsi les quatre phases de cycle de vie Processus Unifié :
Phase d’incubation
Définir le champ d’action de projet : spécification des besoins et présenter l’architecture de
système.
Phase d’élaboration
On développe de façon incrémentale l'architecture du noyau, préciser la plus part des cas
d’utilisateurs afin de présenter l’architecture de système sous forme de vue de présentation
pour chaque modèle.
Phase de construction
C’est la phase de réalisation de produit, il contient en fin tous les cas d’utilisation.
Phase de transition
Le produit final est livré à la disposition des utilisateurs. Les activités comme les formations
et la correction des anomalies seront supposé dans cette phase.
SUPTECH
2014/2015
Page23
Figure 8 : schéma de la méthodologie
Conclusion
Dans ce chapitre nous avons essayé d’étudier quelques applications de gestion des parcs
informatiques dans le but d’avoir une idée sur les fonctionnalités de ces dernières et de
ressortir leurs points forts. En deuxième lieu, nous avons précisé la méthodologie de travail à
suivre pour réaliser le système.
Ceci nous permet de passer au chapitre suivant ou nous allons présenter la première phase de
Processus Unifié.
SUPTECH
2014/2015
Page24
Chapitre III. Phase incubation
SUPTECH
2014/2015
Page25
Chapitre 3
Phase incubation
Introduction
Nous entamons dans ce chapitre la première phase de processus unifié « phase incubation ». Il
s’agit d’identifier les acteurs de système, de lever l’ambigüité sur les besoins et les exigences
dans cette phase afin d’essayer de construire une architecture candidate.
I. Identification des besoins
L'objectif principal d'un système logiciel est de rendre service à ses utilisateurs, il faut par
conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Donc dans ce qui
suit, nous commencerons par énumérer les exigences explicites et implicites ainsi que
l’ensemble des fonctionnalités du logiciel.
1. Les besoins fonctionnels
Les besoins fonctionnels sont définis comme étant des services attendus par l’utilisateur de
produit. Ils doivent constituer un ensemble complet et cohérent. Dans ce qui suit, nous allons
présenter les besoins fonctionnel ébauchés durant la proposition de la solution.
L’application conçue se présente sous forme de trois modules :
 Un module de gestion des incendies et des demandes d’interventions
 Un module de gestion de l’inventaire d’un parc informatique
 Un module de gestion des prêts des téléphones mobiles et des cartes SIM
Commençant par :
 Module de gestion des incendies et des demandes d’interventions
o Gérer les tickets : Une demande d’intervention correspond à un ticket ouvert par un
utilisateur quelconque, pour cela ce dernier doit accéder au système et remplir un
formulaire qui va être par la suite traité et fermer par un technicien informatique.
o Gérer les notifications par SMS : chaque nouvelle demande d’intervention crée par un
utilisateur sera transmis par SMS aux techniciens informatiques du parc.
o Gérer les notifications par Mail [10]: au plus des SMS les nouvelles demandes
d’interventions seront transmis aussi par email aux techniciens informatiques.
o Gérer les profils : La création d’un nouveau profil utilisateur ainsi que la modification
et la suppression des profils existants ne sont faits que par l’administrateur système.
o Gérer les statistiques : des statistiques en graphe seront disponibles pour une
visualisation globale et analyse rapide de l’état du parc informatique.
SUPTECH
2014/2015
Page26
 Module de gestion de l’inventaire d’un parc informatique
o Gérer les ressources matérielles du parc : le système doit récolter automatiquement et
systématiquement les caractéristiques de différentes ressources matérielles des PCs
présents dans le parc. Ces ressources comprennent la mémoires, disques dur,
processeur..
o Gérer les ressources logicielles du parc : le système indique la liste des logiciels
installés dans chaque PC tel que le système d’exploitation utilisé.
o Gérer le caractéristique réseau de chaque ordinateur (adresse IP, MAC, domaine,..)
 Module de gestion des prêts des téléphones mobiles et des cartes SIM
o Gérer les utilisateurs des téléphones mobiles : Un utilisateur de téléphone mobile et
celui que la société YAZAKI lui assigne à partir du service informatique un appareil
téléphonique et une carte SIM afin de les utiliser pour un duré déterminé.
La ligne et l’appareil téléphonique sont à la propriété de YAZAKI.
o Gérer les téléphones mobiles : faire la gestion des appareils téléphoniques qui vont
être utilisé par l’ensemble du personnelle de la société.
Les caractéristiques des appareils seront stocké dans la base du système, ces
caractéristiques comprennent la marque, le modèle, IMEI, couleur,..
o Gérer la liste des cartes SIM : faire la gestion des cartes SIM qui vont être utilisé par
l’ensemble du personnelle de la société.
Les caractéristiques cartes SIM seront stocké dans la base du système, ces
caractéristiques comprennent le numéro, code PIN, code PUK, opérateur,..
o Gérer les transactions : une transaction est l’opération de l’assignement d’un appareil
téléphonique et une carte SIM à un utilisateur
o Gérer l’historique : donner la possibilité au responsable du système de consulter
l’historique des transactions téléphoniques et des accès au système.
2. Les besoins non fonctionnels
Les besoins non fonctionnel se basent sur le respect des normes de l’ergonomie et des
interactions homme/machine qu’on fournit à l’application. Donc, les contraintes techniques
nécessaires qui garantissent la performance à notre solution se résument en :
 La rapidité de traitement
En effet, vu le nombre important des activités et des utilisateurs, il est impérativement
nécessaire que la durée d’exécution des traitements soit minimale.

 La portabilité
Il s’agit de minimiser l’effort pour se faire transporter dans un autre environnement matériel
et/ou logiciel.
 La conformité
SUPTECH
2014/2015
Page27
Contenir un minimum d’erreurs et satisfaire les spécifications.

 L’ergonomie des interfaces
Les interfaces doivent être claires et bien structurées. A ce propos, un thème sera choisi et
utilisé au cours de développement de l’application pour assurer le bon choix du design. Les
interfaces doivent obéir à un ensemble de critères ergonomiques tel que l’accessibilité, la
lisibilité et la convivialité afin d’assurer l’interaction entre l’utilisateur et l’application.

 L’intégrité
Les fonctionnalités offertes à chaque utilisateur doivent être restreintes à celles qui lui sont
autorisées. L’information n’est modifiée que par les personnes y ayants droit. Dans ce cas,
nous définissons pour chaque utilisateur ces droits d’accès au système.

 La fiabilité
Le système doit prouver la sureté de son fonctionnement. C’est pour cette raison qu’il doit
exécuter correctement toutes ses structures, pour répondre convenablement aux besoins de
l’utilisateur.

 La sécurité
Le système doit traiter les failles de sécurité d’où le besoin d’un login et d’un mot de passe
pour accéder au système. Les messages d’erreurs doivent identifier tous les cas d’erreurs de
saisie et leur source.
3. Acteurs et cas d’utilisation
Nous détaillons dans ce qui suit les acteurs intervenant dans notre application :
A. Acteurs du système
Nous parvenons à une étape clé du processus. C’est elle qui grâce à l’étude réalisée dans la
partie précédente mettra en valeur le rôle de chaque acteur du système ainsi que les
fonctionnalités présentées plus haut.
La gestion des interventions, la gestion de l’inventaire et la gestion des prêts des équipements
téléphoniques, peuvent parvenir des différents acteurs. Dans cette partie nous allons
énumérer les différents acteurs susceptibles d’interagir avec le système, citant :
SUPTECH
2014/2015
Page28
 Employés administratifs
 Responsable informatique
 Techniciens informatique
- L’acteur « Employé administratif » est l’utilisateur qui va lancer la demande
d’intervention en cas de problème informatique, pour le faire il doit accéder au système via
ces paramètres d’authentification et il doit ouvrir un ticket en remplissant un formulaire de
demande d’intervention , ainsi ces rôles sont résumés comme décrit ci-dessous :
- Ouvrir un ticket
- Suivre l’état de son ticket
- Consulter l’historique des tickets
- Gérer son profil
- L’acteur « Responsable informatique » représente le superviseur de notre système à
développer qui va :
- Créer des nouveaux comptes
- Créer une transaction téléphonique
- Modifier ou supprimer une transaction téléphonique
- Répondre aux demandes d’intervention et fermer les tickets
- Suivre l’inventaire du parc informatique
- Afficher les statistiques de l’inventaire
- Consulter les fichiers logs .
- Ajouter un téléphone
- Ajouter une carte SIM
- Gérer les catégories des problèmes
- L’acteur « Technicien informatique » est l’agent responsable de suivre tous les demandes
d’intervention, répondre et fermer les tickets, ainsi ces rôles sont résumés comme décrit ci-
dessous :
- Répondre aux demandes d’interventions
- Consulter l’historique des tickets
- Suivre l’inventaire du parc informatique
- Afficher les statistiques de l’inventaire
- Ajouter un téléphone
- Ajouter une carte SIM
SUPTECH
2014/2015
Page29
B. Cas d’utilisation par acteur
a) Diagramme associé au Responsable informatique
Le diagramme ci-dessous présente le diagramme de cas d’utilisation décrivant les différentes
fonctionnalités que le « Responsable informatique ».
Figure 9 : fonctionnalités de Responsable informatique/Superviseur
Il décrivant les fonctionnalités du « Superviseur » du système qui est lui-même le
responsable informatique, il se charge de suivre toutes les fonctionnalités principales des trois
modules du système gestionnaire du parc ainsi que des fonctions supplémentaires tel que la
gestion des départements et la consultation des fichiers logs.
SUPTECH
2014/2015
Page30
b) Diagramme associé au Technicien informatique
Sur la figure ci-dessous, nous découvrons les mêmes fonctionnalités principales mais qui
correspond au technicien informatique, lui également a la possibilité de gérer les tickets,
l’inventaire et la gestion des téléphones mobiles et carte SIM.
Figure 10 : fonctionnalités d’un technicien informatique
Le « Technicien informatique » est l’acteur qui se charge de répondre aux demandes des
interventions, suivre l’état de l’inventaire ainsi que la gestion des prêts téléphoniques.
SUPTECH
2014/2015
Page31
c) Diagramme associé à un Employé administratif
Le diagramme ci-dessus présent le diagramme de cas d’utilisation décrivant les différentes
fonctionnalités qu’un « Employé administratif».
Figure 11 : fonctionnalités d’un Employé administratif
« L’employé administratif», c’est tout acteur qui admet un compte sur l’application
afin de créer ces tickets et suivre leurs états.
4. Cas d’utilisations par priorité
Nous allons dans un premier temps distingué les cas d’utilisation les plus prioritaires que les
autres du point de vue fonctionnel, pour ce focalisé dans un second temps à les détailler.
 Affectation des priorités
Parmi les caractéristiques qui caractérisent le PU c’est qu’il est piloté par les cas d’utilisation,
dans ce sens, nous allons les classés selon leur ordre d’importance pour chacun des acteurs
d’où, la nécessité de définir un ordre de priorité pour les cas d’utilisation.
Dans notre cas, les cas d’utilisation qui s’avèrent les plus prioritaires ont la priorité « 1 » et les
moins prioritaire ont la priorité « 3 ».
SUPTECH
2014/2015
Page32
Priorité Cas d'utilisation Acteurs Description
1 Authentification
Superviseur
Tous les utilisateurs doivent s’authentifier pour se
connecter à la plateforme de l’application
Technicien
Employé
1 Gérer les tickets
Superviseur
Après authentification, le responsable informatique et
le technicien ont le droit de consulter, d’ajouter, de
modifier, de supprimer ou de répondre aux demandes
d’intervention.
Technicien
1 Gérer l’inventaire
Superviseur Après authentification, le responsable informatique et
le technicien ont le droit d’afficher l’état de
l’inventaire.Technicien
1
Gérer les prêts
téléphoniques
Superviseur
Après authentification, le responsable informatique et
le technicien ont le droit de d’ajouter, modifier ou de
supprimer un téléphone mobile ou une carte SIM aussi
de créer une opération de prêt téléphonique (prêter,
récupérer) à une personne.
Technicien
2 Gérer les comptes Superviseur
Après authentification le responsable informatique a
le droit de créer, de modifier ou de supprimer un
compte pour un employé administratif.
2
Afficher les
statistiques
Superviseur Après authentification le responsable informatique et
les techniciens ont le droit de consulter les statistiques
du parc informatiques.Technicien
2
Gérer les
catégories des
problèmes
informatiques
Superviseur
Après authentification, le superviseur a le droit de
saisir d’ajouter, modifier ou de supprimer une
catégorie de problème informatique.
3
Consulter
l’historique
Superviseur
Après authentification, le superviseur peut consulter
les fichiers logs enregistrer dans les systèmes et les
télécharger.
3
Gérer les
départements
Superviseur
Après authentification, le superviseur a le droit de
saisir d’ajouter, modifier ou de supprimer un
département.
Tableau 1: Affectation des priorités aux cas d’utilisations
SUPTECH
2014/2015
Page33
5. Raffinement des cas d’utilisation de priorité « 1 »
A. Raffinement du cas d’utilisation « S’authentifier »
 Diagramme de cas d’utilisation
Figure 12 : diagramme de cas d'utilisation « s’authentifier »
Pour pouvoir accéder au système, chaque utilisateur doit tout d’abord s’authentifier. Cette
authentification est nécessaire pour assurer la sécurité et la confidentialité des données.
Sommaire d’authentification
Titre Authentification
Objectif Etre connue par le système
Acteurs
Employé administratif, Superviseur/Responsable informatique,
Technicien
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être connu par le système L’utilisateur avoir l’accès à son espace privé
Scénario nominal
1. L’utilisateur lance l’application
SUPTECH
2014/2015
Page34
2. Le système affiche un formulaire de connexion à l’acteur
3. L’utilisateur saisie le « login » et le « mot de passe »
4. L’utilisateur demande la connexion
5. Le système vérifie les données saisies
6. Le système valide les données et permet l’accès
Tableau 2 : Description textuelle du cas d’utilisation « S’authentifier »
B. Raffinement du cas d’utilisation « Gérer les tickets »
 Diagramme de cas d’utilisation
La figure suivante nous présente de façon plus détaillée le cas d’utilisation « Gérer tickets ».
Nous pouvons donc entrevoir plusieurs fonctions qui servent à construire le cycle de vie d’un
ticket.
Figure 13 : diagramme de cas d'utilisation « Gérer les tickets »
Il est clair dans ce diagramme que :
- Seul le superviseur qui peut supprimer un ticket
- L’employé n’a la possibilité que de créer ou de consulter ces tickets
SUPTECH
2014/2015
Page35
 Description textuelle : Créer un ticket (Superviseur, Technicien, Employé)
Créer un ticket
Titre Créer un ticket
Objectif Demander une intervention informatique
Acteurs Superviseur, Technicien, Employé
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un nouveau ticket est ajouté
Scénario nominal
1. L’utilisateur accède au menu « Ticket »
2. Le système affiche un formulaire de création d’un ticket
3. L’utilisateur remplit le formulaire
4. Le système valide les données saisies
5. Le système fait les mis à jour et indique que la demande est ajouté avec sucée
Tableau 3 : Description textuelle du cas d’utilisation « Créer/Ouvrir un ticket »
 Description textuelle : Fermer un ticket (Superviseur, Technicien)
Fermer un ticket
Titre Fermer un ticket
Objectif Résoudre le problème informatique et fermer le ticket
Acteurs Superviseur, Technicien
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un ticket est fermé
Scénario nominal
1. L’utilisateur consulte son courrier électronique
2. L’utilisateur clique sur le lien disponible dans le message
3. Le système affiche les détails du ticket
4. L’utilisateur résout le problème informatique
5. L’utilisateur change l’état du ticket à « Résolu » et remplit le formulaire
6. Le système valide les données saisies
7. Le système fait les mis à jour et indique que les changements sont fait avec sucée
8. Le système envoie un SMS au demandeur indiquant que le problème est résolu
Tableau 4 : Description textuelle du cas d’utilisation « Répondre/Fermer un ticket »
SUPTECH
2014/2015
Page36
 Description textuelle : Consulter un ticket (Superviseur, Technicien, Employé)
Un employé ne peut afficher que les tickets qu’il a créé lui-même, tandis que le superviseur et
les techniciens peuvent afficher n’importe quel ticket.
Consulter un ticket
Titre Consulter un ticket
Objectif Afficher les détails d’un ticket
Acteurs Superviseur, Technicien, Employé
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un ticket est affiché
Scénario nominal
1. L’utilisateur consulte son courrier électronique
2. L’utilisateur clique sur le lien disponible dans le message
3. Le système affiche les détails du ticket
4. L’utilisateur résout le problème informatique
5. L’utilisateur change l’état du ticket à « Résolu » et remplit le formulaire
6. Le système valide les données saisies
7. Le système fait les mis à jour et indique que les changements sont fait avec sucée
8. Le système envoie un SMS au demandeur indiquant que le problème est résolu
Tableau 5 : Description textuelle du cas d’utilisation « Consulter un ticket »
 Description textuelle : Supprimer un ticket (Superviseur)
Supprimer un compte utilisateur
Titre Supprimer un ticket
Objectif Supprimer un ticket de la liste
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un ticket est supprimé
Scénario nominal
1. L’utilisateur accède au menu « Ticket »
SUPTECH
2014/2015
Page37
2. L’utilisateur affiche la liste des tickets enregistrés
3. L’utilisateur demande de supprimer un ticket
4. Le système demande la confirmation de suppression
5. L’utilisateur confirme la suppression
6. Le système fait les mis à jour et indique que le ticket est supprimé avec sucée
Tableau 6 : Description textuelle du cas d’utilisation « Supprimer un ticket »
C. Raffinement du cas d’utilisation « Gérer l’inventaire »
 Diagramme de cas d’utilisation
Figure 14 : diagramme de cas d'utilisation « Gérer l’inventaire »
Après l’authentification il’est possible pour le superviseur ou le technicien d’afficher la liste
des imprimantes fonctionnelles ainsi que la listes des ordinateurs installés dans le parc
informatique.
Chaque ordinateur enregistré dans le système est identifié par ces caractéristiques :
- Matériels (processeur, RAM,..)
- Logiciels (OS, version,..)
- Réseaux (IP, MAC, domaine,..)
SUPTECH
2014/2015
Page38
 Description textuelle : Consulter la liste des imprimantes (Superviseur, Technicien)
Consulter la liste des imprimantes
Titre Consulter la liste des imprimantes
Objectif Afficher la liste des imprimantes disponibles dans le parc
Acteurs Superviseur, Technicien
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié La liste des imprimant est affiché
Scénario nominal
1. L’utilisateur accède au menu « Inventaire »
2. L’utilisateur choisit « Imprimantes » dans le menu
3. Le système affiche la liste des imprimantes disponibles dans le parc
Tableau 7 : Description textuelle du cas d’utilisation «Consulter liste des imprimantes»
 Description textuelle : Consulter la liste des ordinateurs (Superviseur, Technicien)
Consulter la liste des ordinateurs
Titre Consulter la liste des ordinateurs
Objectif Afficher la liste des ordinateurs disponibles dans le parc
Acteurs Superviseur, Technicien
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié La liste des ordinateurs est affichée
Scénario nominal
1. L’utilisateur accède au menu « Inventaire »
2. L’utilisateur choisit « Ordinateurs » dans le menu
3. Le système affiche la liste des ordinateurs disponibles dans le parc
Tableau 8 : Description textuelle du cas d’utilisation « Consulter liste des ordinateurs »
 Description textuelle : Consulter la liste des logiciels (Superviseur, Technicien)
Consulter la liste des logiciels
Titre Consulter la liste des logiciels
Objectif Afficher la liste des logiciels disponibles dans le parc
Acteurs Superviseur, Technicien
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié La liste des logiciels est affichée
Scénario nominal
1. L’utilisateur accède au menu « Inventaire »
2. L’utilisateur choisit « logiciels » dans le menu
3. Le système affiche la liste des imprimantes disponibles dans le parc
Tableau 9 : Description textuelle du cas d’utilisation « Consulter liste des logiciels »
SUPTECH
2014/2015
Page39
D. Raffinement du cas d’utilisation « Gérer les prêts téléphoniques »
 Diagramme de cas d’utilisation
Pour améliorer la communication entre les employés de l’entreprise et garantir la haute
disponibilité des gens, YAZAKI met à la disposition de ces personnels des téléphones
mobiles et des cartes SIM pré rechargés .Ces derniers sont données à titre de prêt et restent à
la propriété de YAZAKI.
Pour cela une solution informatique sera développé pour améliorer la gestion de cette tâche et
facilite le suivie des équipements.
Figure 15 : diagramme de cas d'utilisation « Gérer les prêts téléphoniques »
SUPTECH
2014/2015
Page40
Gérer les téléphones mobiles
 Description textuelle : Ajouter un téléphone (Superviseur, Technicien)
Ajouter un téléphone
Titre Ajouter un téléphone
Objectif Ajouter un nouveau téléphoné dans la base
Acteurs Superviseur, Technicien
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un nouvel appareil téléphonique est ajouté
Scénario nominal
1. L’utilisateur accède au menu « Téléphones »
2. L’utilisateur choisit l’option « Ajouter téléphone »
2. Le système affiche un formulaire vide d’ajout d’un téléphone
3. L’utilisateur remplit le formulaire
4. Le système valide les données saisies
5. Le système fait les mis à jour et indique que le téléphone est ajouté avec sucée
Tableau 10 : Description textuelle du cas d’utilisation « Ajouter un téléphone »
 Description textuelle : Modifier un téléphone (Superviseur, Technicien)
Modifier un téléphone
Titre Modifier un téléphone
Objectif Modifier un téléphone mobile
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un téléphone est modifié
Scénario nominal
1. L’utilisateur accède au menu « Téléphones »
2. L’utilisateur affiche la liste des téléphones enregistrés
3. L’utilisateur demande de modifier un téléphone
4. Le système affiche un formulaire avec les données enregistrées
5. L’utilisateur modifie le formulaire
6. Le système valide les données saisies
7. Le système fait les mis à jour et indique que le téléphone est modifié avec sucée
Tableau 11: Description textuelle du cas d’utilisation « Modifier un téléphone »
SUPTECH
2014/2015
Page41
 Description textuelle : Supprimer un téléphone (Superviseur, Technicien)
Supprimer un téléphone
Titre Supprimer un téléphone
Objectif Supprimer un téléphone de la liste
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un téléphone est supprimé
Scénario nominal
1. L’utilisateur accède au menu « Téléphone »
2. L’utilisateur affiche la liste des téléphones enregistrés
3. L’utilisateur demande de supprimer un téléphone
4. Le système demande la confirmation de suppression
5. L’utilisateur confirme la suppression
6. Le système fait les mis à jour et indique que le téléphone est supprimé avec sucée
Tableau 12 : Description textuelle du cas d’utilisation « Supprimer un téléphone »
Gérer les cartes SIM
 Description textuelle : Ajouter une carte SIM (Superviseur, Technicien)
Ajouter une carte SIM
Titre Ajouter une carte SIM
Objectif Ajouter une nouvelle carte SIM dans la base du système
Acteurs Superviseur, Technicien
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un nouvelle carte SIM est ajouté
Scénario nominal
1. L’utilisateur accède au menu « Téléphones »
2. L’utilisateur choisit l’option « Ajouter une carte SIM »
2. Le système affiche un formulaire vide d’ajout d’une carte SIM
3. L’utilisateur remplit le formulaire
4. Le système valide les données saisies
5. Le système fait les mis à jour et indique que la carte SIM est ajouté avec sucée
Tableau 13 : Description textuelle du cas d’utilisation « Ajouter une carte SIM »
SUPTECH
2014/2015
Page42
 Description textuelle : Modifier une carte SIM (Superviseur, Technicien)
Modifier une carte SIM
Titre Modifier une carte SIM
Objectif Mettre à jour une carte SIM
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Une carte SIM est modifiée
Scénario nominal
1. L’utilisateur accède au menu « Téléphones »
2. L’utilisateur affiche la liste des cartes SIM enregistrés
3. L’utilisateur demande de modifier une carte SIM
4. Le système affiche un formulaire avec les données enregistrées
5. L’utilisateur modifie le formulaire
6. Le système valide les données saisies
7. Le système fait les mis à jour et indique que la carte SIM est modifié avec sucée
Tableau 14 : Description textuelle du cas d’utilisation « Modifier une carte SIM »
 Description textuelle : Supprimer une carte SIM (Superviseur, Technicien)
Supprimer une carte SIM
Titre Supprimer une carte SIM
Objectif Supprimer une carte SIM de la liste
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Une carte SIM est supprimée
Scénario nominal
1. L’utilisateur accède au menu « Téléphone »
2. L’utilisateur affiche la liste des cartes SIM enregistrés
3. L’utilisateur demande de supprimer une carte SIM
4. Le système demande la confirmation de suppression
5. L’utilisateur confirme la suppression
6. Le système fait les mis à jour et indique que la carte SIM est supprimé avec sucée
Tableau 15 : Description textuelle du cas d’utilisation « Supprimer une carte SIM »
SUPTECH
2014/2015
Page43
Gérer les transactions téléphoniques
 Description textuelle : Ajouter un prêt (Superviseur, Technicien)
L’ajout d’une opération de prêt téléphonique dans la base du système veut dire qu’on a
assigner une appareil téléphonique et une carte SIM à un utilisateur qui va les exploiter pour
une durée non déterminé.
Ajouter un prêt
Titre Ajouter une opération de prêt téléphonique
Objectif Assigner un appareil téléphonique et une carte SIM à un utilisateur
Acteurs Superviseur, Technicien
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un prêt téléphonique est ajouté
Scénario nominal
1. L’utilisateur accède au menu « Téléphones »
2. L’utilisateur choisit l’option « Gestion des prêts »
3. Le système affiche un formulaire vide d’ajout d’une opération de prêt téléphonique
4. L’utilisateur remplit le formulaire
5. Le système valide les données saisies
6. Le système fait les mis à jour et indique que l’opération est ajouté avec sucée
Tableau 16 : Description textuelle du cas d’utilisation « Ajouter un prêt »
 Description textuelle : Modifier une opération de prêt (Superviseur, Technicien)
Modifier une carte SIM
Titre Modifier une opération de prêt
Objectif Mettre à jour une opération de prêt pour un utilisateur donné
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Une opération de prêt est modifiée
Scénario nominal
1. L’utilisateur accède au menu « Téléphones »
2. L’utilisateur choisit l’option « Gestion des prêts »
SUPTECH
2014/2015
Page44
2. Le système affiche la liste de transactions enregistrées
3. L’utilisateur demande d’afficher les détails de l’opération
4. Le système affiche les détails de l’opération
5. L’utilisateur demande de modifier une transaction
6. Le système affiche un formulaire avec les données enregistrées
7. L’utilisateur modifie le formulaire
8. Le système valide les données saisies
9. Le système fait les mis à jour et indique que la transaction est modifié avec sucée
Tableau 17 : Description textuelle du cas d’utilisation « Modifier une opération de prêt »
 Description textuelle : Supprimer une opération de prêt (Superviseur,
Technicien)
Supprimer une opération de prêt
Titre Supprimer une opération de prêt
Objectif Supprimer une opération de prêt de la liste
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Une opération téléphonique est supprimée
Scénario nominal
1. L’utilisateur accède au menu « Téléphone »
2. L’utilisateur choisit l’option « Gestion des prêts »
4. Le système affiche la liste de transactions enregistrées
5. L’utilisateur demande de supprimer une transaction
4. Le système demande la confirmation de suppression
5. L’utilisateur confirme la suppression
6. Le système fait les mis à jour et indique que la transaction est supprimé avec sucée
Tableau 18 : Description textuelle du cas d’utilisation « Supprimer une transaction »
SUPTECH
2014/2015
Page45
 Description textuelle : Récupérer le téléphone mobile et la carte SIM
Récupérer le téléphone et la carte SIM
Titre Récupérer le téléphone et la carte SIM
Objectif Récupérer le téléphone et la carte SIM
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Téléphone et SIM récupérer
Scénario nominal
1. L’utilisateur accède au menu « Téléphone »
2. L’utilisateur choisit l’option « Gestion des prêts »
3. Le système affiche la liste de transactions enregistrées
4. L’utilisateur demande d’afficher les détails du prêt pour un utilisateur donné
5. Le système affiche les détails
6. L’utilisateur demande de faire une opération de récupération
7. Le système affiche le formulaire pré-remplit
8. L’utilisateur confirme la récupération
9. Le système fait les mis à jour et indique que la récupération est effectué avec sucée
Tableau 19 : Description textuelle du cas d’utilisation « Récupérer téléphone & SIM »
SUPTECH
2014/2015
Page46
6. Diagramme du cas d’utilisation global
Figure 16 : Diagramme de cas d’utilisation globale
SUPTECH
2014/2015
Page47
II. Conception
La conception est une étape primordiale pour la réalisation d’un produit informatique. Dans
cette étape nous allons spécifiés les cas d’utilisation les plus prioritaires d’une manière
détaillé afin d’organiser le système et de décrire leur fonctionnement.
Nous allons utiliser le diagramme de classe et le diagramme de séquence en vue de présenter
le comportement statique et dynamique de notre modèle : le diagramme de classe exprime
d’une manière générale la structure statique d’un système, en termes de classes et de relation
entre classes et le diagramme de séquence illustre d’une manière dynamique le scénario de
réalisation des fonctions du système.
1. Diagramme de classe « gestion de parc informatique »
Figure 17 : Diagramme de classe du système
SUPTECH
2014/2015
Page48
2. Diagramme de séquence du cas d’utilisation « S’authentifier »
Figure 18 : Diagramme de séquence « Authentification »
La figure ci-dessus présente le scénario d’authentification pour le cas d’utilisation
« s’authentifier », donc pour accéder au système il faut tout d’abord saisi le login et le mot de
passe dans l’interface de l’utilisateur, après la validation des paramètres d’accès, l’utilisateur
accède au système.
SUPTECH
2014/2015
Page49
3. Diagramme de séquence du cas d’utilisation « Gérer les tickets »
A. Diagramme de séquence « Créer un ticket »
La figure suivante nous présente de façon détaillée le diagramme de séquence « Créer un
tickets ». Nous pouvons donc entrevoir que par des simples clicks l’employé administratif
peut construire une demande d’intervention qui sera envoyé automatiquement par mail et par
SMS.
Figure 19 : Diagramme de séquence « Créer un ticket »
SUPTECH
2014/2015
Page50
B. Diagramme d’activité « Créer un ticket »
Figure 20 : Diagramme d’activité « Créer un ticket »
SUPTECH
2014/2015
Page51
C. Diagramme de séquence « Modifier un ticket »
La modification d’un ticket revient à modifier son état de « En cours » à « Résolu », le cycle
de vie d’un ticket prend son fin lorsque le technicien ou le superviseur vient de résoudre le
problème informatique en liaison avec ce ticket.
Comme indique le diagramme de séquence ci-après, le formulaire de modification d’un ticket
est accessible via boite de réception du compte mail du technicien/superviseur ou directement
via l’interface Web sous le menu « Ticket ».
SUPTECH
2014/2015
Page52
Figure 21 : Diagramme de séquence « Modifier un ticket »
SUPTECH
2014/2015
Page53
D. Diagramme de séquence « Supprimer un ticket »
Pour des raisons de traçabilités et de statistique les tickets ne doivent pas être supprimés que
par le superviseur du système, on évite dans ce cas que le technicien ignore une demande
d’intervention ou la supprime de la base des données.
Figure 22 : Diagramme de séquence « Supprimer un ticket »
SUPTECH
2014/2015
Page54
E. Diagramme de séquence détaillé « Envoi SMS par l’application Android »
L’application Android permet d’envoyer un SMS à chaque création d’un nouveau ticket, pour
le faire le système doit comparer d’une façon périodique la date du dernier ticket enregistré
dans la base avec une valeur initialement récupérer lors de démarrage de l’application.
L’envoi de l’SMS se déclenche lorsque la dernière date récupérer est supérieur à la date
initiale ,ce qui signifie qu’un nouveau ticket vient de se créer, ainsi la valeur initiale est
remplacé en mémoire du système par la dernière valeur lu et le processus continue.
Figure 23 : Diagramme de séquence détaillé de « l’envoi SMS par Android »
SUPTECH
2014/2015
Page55
4. Diagramme de séquence de cas d’utilisation « Gérer l’inventaire »
A. Diagramme de séquence « Créer un inventaire » avec Agent Inventory
Agent Inventory est une application native qui permet de donner des informations sur des
ressources physiques se trouvant dans les différentes machines du parc, la communication
avec le serveur d’application se fait via le protocole http et la solution adoptée est basé sur les
services Web.
Les ressources inventoriées sont :
- Les caractéristiques des ordinateurs (MAC, IP, Processeur, RAM, OS,..)
- Les imprimantes installées sur les PC
- Les logiciels installés sur les PC.
Figure 24 : Diagramme de séquence « Créer un inventaire »
SUPTECH
2014/2015
Page56
B. Diagramme de séquence « Consulter détails de l’inventaire »
Figure 25 : Diagramme de séquence « Consulter détails de l’inventaire »
SUPTECH
2014/2015
Page57
5. Diagramme de séquence « Gérer les prêts téléphoniques »
Cette conception concerne les sous-modules -suivants :
- Gérer les cartes SIM
- Gérer les téléphones mobiles
- Gérer les phones users
- Gérer les opérations de prêts
Ces sous-modules concernent quatre fonctionnalités à savoir l’ajout, la modification, la
suppression et la consultation, le troisième module nécessite un module complémentaire qui
est le module « Récupérer mobile et carte SIM ».
SUPTECH
2014/2015
Page58
A. Diagramme de séquence « Gérer les cartes SIM »
Figure 26 : Diagramme de séquence « Gérer les cartes SIM »
SUPTECH
2014/2015
Page59
B. Diagramme de séquence « Gérer les téléphones mobiles »
Figure 27 : Diagramme de séquence « Gérer les téléphones mobiles »
SUPTECH
2014/2015
Page60
C. Diagramme de séquence « Gérer les utilisateurs des téléphones »
Figure 28 : Diagramme de séquence « Gérer les utilisateurs des téléphones»
SUPTECH
2014/2015
Page61
D. Diagramme de séquence « Gérer les opérations de prêts »
Figure 29 : Diagramme de séquence « Gérer les opérations de prêts »
SUPTECH
2014/2015
Page62
E. Diagramme de séquence « Télécharger la décharge téléphonique en PDF»
Figure 30 : Diagramme de séquence « Télécharger la décharge en PDF »
III. Elaboration des prototypes des interfaces utilisateurs
1. Prototype de l’interface « Authentification »
Il très important de noter que chaque opération ne peut être réalisée qu’après authentification.
Seul le Superviseur qui se charge de définir les login et mot de passe de chaque employé alors
qu’un employé pour modifier la tienne.
Au lancement de l’application, la fenêtre d’authentification s’affiche automatiquement, elle
permet à l’utilisateur de se connecter. S’il y a des problèmes lors de la connexion, un message
d’erreur est affiché.
SUPTECH
2014/2015
Page63
Voilà la figure suivante qui présente l’interface d’authentification :
Figure 31 : Interface d’authentification
2. Prototype de l’interface « Créer ticket »
Figure 32 : Interface d’ajout d’une nouvelle demande d’intervention
SUPTECH
2014/2015
Page64
La figure ci-dessous montre un exemple d’un ticket reçu avec Microsoft Outlook, ce système
de messagerie est celui utilisé par l’ensemble des employés dans notre société YAZAKI.
Figure 33 : Interface de ticket reçu avec Microsoft Outlook
La figure ci-dessous montre un exemple d’un ticket reçu par SMS, dans le téléphone d’un
technicien informatique, le nombre maximum des caractères standard dans un SMS est de 160
caractères.
Figure 34 : Interface de ticket reçu par SMS
SUPTECH
2014/2015
Page65
Figure 35 : Interface de l’application Android
3. Prototype de l’interface « Gérer inventaire »
La figure ci-dessous montre une liste des ordinateurs inventoriés par AgentInventory,
l’utilisateur (Superviseur, technicien) peut afficher les détails d’un ordinateur ou bien le
supprimer de la liste.
Figure 36 : Interface des listes des ordinateurs inventoriés
SUPTECH
2014/2015
Page66
4. Prototype de l’interface « Gérer les prêts téléphoniques »
Pour ajouter un prêt téléphonique le superviseur ou le technicien doit accèdera au menu
« Gestion des prêts » , trois listes sont affichés il contiennent respectivement une liste de tous
les utilisateurs téléphonique ,une deuxième pour les appareils téléphonique et une troisième
pour les cartes SIM.
Il suffit de faire trois cliques dans chaque liste pour créer un formulaire remplit avec tous les
détails d’un prêt téléphonique.
Il reste de poster le formulaire et télécharger la décharge téléphonique en format PDF pour
impression.
Figure 37 : Interface d’ajout d’un nouveau prêt téléphonique
SUPTECH
2014/2015
Page67
5. Prototype de l’interface « Imprimer la décharge téléphonique »
Figure 38 : Interface exemple d’une décharge téléphonique en PDF
SUPTECH
2014/2015
Page68
Conclusion
Nous avons consacré cette phase pour l’identification des besoins du système ainsi que ses
exigence qui nous ont permis de passer à la phase suivante « Phase d’élaboration »,ou nous
allons entamer des nouveaux besoins et traiter les cas d’utilisation de priorité « 2 ».
SUPTECH
2014/2015
Page69
Chapitre IV.Phase d’élaboration
SUPTECH
2014/2015
Page70
Chapitre 4
Phase élaboration
Introduction
Après avoir compris notre système et dégager les fonctionnalités de bases, en passe à la
deuxième phase de notre processus, phase d’élaboration.
Dans cette partie, nous allons capturer les nouveaux besoins, analyser et concevoir les
nouveaux cas d’utilisations afin d’implémenter et de tester ces derniers.
I. Identification des besoins
1. Raffinement des cas d’utilisation de priorité « 2 »
Dans cette partie nous allons traiter les cas d’utilisations de priorité « 2 »
- Gérer les comptes
- Afficher les statistiques
- Gérer les catégories des problèmes informatiques
A. Raffinement de cas d’utilisation « Gérer les comptes »
 Diagramme de cas d’utilisation
Figure 39 : diagramme de cas d'utilisation « Gérer les comptes »
SUPTECH
2014/2015
Page71
Le lancement d’une nouvelle procédure de création d’un compte utilisateur ainsi que les
opérations de suppression et de modification ne sont disponibles que par le responsable
informatique par contre certaines donnés peuvent être modifiés par l’employé administratif
tel que le cas de changement de son mot de passe.
 Description textuelle : Créer un compte utilisateur (Superviseur)
Créer un compte utilisateur
Titre Créer un compte
Objectif Donner accès au système
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un nouveau compte est ajouté
Scénario nominal
1. L’utilisateur accède au menu « Compte »
2. Le système affiche un formulaire de création d’un compte
3. L’utilisateur remplit le formulaire
4. Le système valide les données saisies
5. Le système fait les mis à jour et indique que la demande est ajouté avec sucée
Tableau 20 : Description textuelle du cas d’utilisation « Créer un nouveau compte »
 Description textuelle : modifier un compte utilisateur (Superviseur)
Modifier un compte utilisateur
Titre Modifier un compte
Objectif Modifier un profil utilisateur
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un profil utilisateur est modifié
Scénario nominal
1. L’utilisateur accède au menu « Compte »
2. L’utilisateur affiche la liste des comptes des utilisateurs enregistrés
3. L’utilisateur demande de modifier un compte
SUPTECH
2014/2015
Page72
4. Le système affiche un formulaire avec les données enregistrés
5. L’utilisateur modifie le formulaire
6. Le système valide les données saisies
7. Le système fait les mis à jour et indique que la demande est modifié avec sucée
Tableau 21 : Description textuelle du cas d’utilisation « Modifier un compte »
 Description textuelle : supprimer un compte utilisateur (Superviseur)
Supprimer un compte utilisateur
Titre Supprimer un compte
Objectif Supprimer un compte utilisateur
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Un compte utilisateur est supprimé
Scénario nominal
1. L’utilisateur accède au menu « Compte »
2. L’utilisateur affiche la liste des comptes des utilisateurs enregistrés
3. L’utilisateur demande de supprimer un compte
4. Le système demande la confirmation de suppression
5. L’utilisateur confirme la suppression
6. Le système fait les mis à jour et indique que la demande est supprimé avec sucée
Tableau 22 : Description textuelle du cas d’utilisation « Supprimer un compte »
SUPTECH
2014/2015
Page73
B. Raffinement du cas d’utilisation « Afficher les statistiques»
Après authentification le superviseur et les techniciens auront la possibilité de consulter tous
les statistiques du système, ces statistiques comprennent :
- Statistiques par systèmes d’exploitation
- Statistiques par domaine ou groupe de travail
- Statistiques par techniciens informatiques
- Statistiques par tickets
- Statistiques par catégorie de problèmes
 Diagramme de cas d’utilisation
Figure 40 : diagramme de cas d'utilisation « Afficher les statistiques »
SUPTECH
2014/2015
Page74
 Description textuelle : Afficher les statistiques
Afficher les statistiques
Titre Afficher les statistiques
Objectif Afficher les différents types des statistiques
Acteurs Superviseur, Technicien informatiques
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Des statistiques sont affichés
Scénario nominal
1. L’utilisateur accède au menu « Statistiques »
2. Le système affiche les statistiques
Figure 41 : Description textuelle du cas d’utilisation « Afficher les statistiques »
SUPTECH
2014/2015
Page75
C. Raffinement de cas d’utilisation « Gérer les catégories des problèmes
informatiques»
 Diagramme de cas d’utilisation
Figure 42 : diagramme de cas d'utilisation « Gérer les catégories »
 Description textuelle : Ajouter une catégorie (Superviseur)
Ajouter une catégorie
Titre Ajouter une catégorie
Objectif Ajouter une catégorie aux listes des problèmes informatique
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Une catégorie est ajoutée
Scénario nominal
1. L’utilisateur accède au menu « Catégorie des problèmes »
2. Le système affiche un formulaire de création d’une catégorie
3. L’utilisateur remplit le formulaire
4. Le système valide les données saisies
5. Le système fait les mis à jour et indique que la catégorie est ajouté avec sucée
Tableau 23 : diagramme de cas d'utilisation « Ajouter une catégorie »
SUPTECH
2014/2015
Page76
 Description textuelle : Modifier une catégorie (Superviseur)
Modifier une catégorie
Titre Modifier une catégorie
Objectif Modifier une de problèmes informatique
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Une catégorie est modifiée
Scénario nominal
1. L’utilisateur accède au menu « Catégorie des problèmes »
2. Le système affiche la liste des catégories
3. L’utilisateur choisit une catégorie à modifier
4. Le système affiche un formulaire pré-remplit de la catégorie choisit
5. L’utilisateur modifie le formulaire
6. Le système valide les données saisies
7. L’utilisateur poste le formulaire
8. Le système fait les mis à jour et indique que la catégorie est modifié avec sucée
Tableau 24 : diagramme de cas d'utilisation « Modifier une catégorie »
 Description textuelle : supprimer une catégorie (Superviseur)
Supprimer une catégorie
Titre Supprimer une catégorie
Objectif Supprimer une catégorie de liste des problèmes
Acteurs Superviseur/Responsable informatique
Description des enchainements
Pré-condition Post-condition
L’utilisateur doit être authentifié Une catégorie est supprimée
Scénario nominal
1. L’utilisateur accède au menu « Catégorie des problèmes »
2. Le système affiche la liste des catégories
3. L’utilisateur choisit une catégorie à supprimer
4. L’utilisateur demande de supprimer une catégorie
5. Le système demande la confirmation de suppression
6. L’utilisateur confirme la suppression
7. Le système fait les mis à jour et indique que la catégorie est supprimé avec sucée
Tableau 25 : Description textuelle du cas d’utilisation « Supprimer une catégorie »
SUPTECH
2014/2015
Page77
2. Cas d’utilisation global de la deuxième phase
Figure 43 : diagramme de cas d'utilisation global du 2éme phase
SUPTECH
2014/2015
Page78
II. Conception
1. Diagramme de classe
Figure 44 : diagramme de classe de priorité « 2 »
2. Diagramme de séquence de cas d’utilisation« Gérer les comptes »
Pour ajouter, modifier et supprimer un utilisateur, le Superviseur accède à l’interface «
Gestion des comptes », là où il peut faire ses opérations.
SUPTECH
2014/2015
Page79
Voilà le diagramme de séquence ci-dessous qui illustre le scénario :
Figure 45 : Diagramme de séquence « Gérer les comptes »
SUPTECH
2014/2015
Page80
3. Diagramme de séquence de cas d’utilisation « Afficher les
statistiques »
Figure 46 : Diagramme de séquence « Gérer les catégories »
4. Diagramme de séquence de cas d’utilisation« Gérer les catégories »
Chaque catégorie d’un problème est assigné à un technicien informatique ainsi lorsque un
employé lance une demande d’intervention un ticket sera ouvert et envoyé automatiquement
au technicien concerné.
Le diagramme de séquence ci-après illustre le scenario de gestion des catégories.
SUPTECH
2014/2015
Page81
Figure 47 : Diagramme de séquence « Gérer les catégories »
SUPTECH
2014/2015
Page82
II. Elaboration de quelques prototypes des interfaces utilisateurs
1. Prototype de l’interface « Gérer comptes »
Pour ajouter, modifier ou supprimer des comptes utilisateurs, il est nécessaire au superviseur
de passer à l’interface de gestion des comptes comme illustre la figure suivante :
Figure 48: interface « Gestion des comptes »
SUPTECH
2014/2015
Page83
2. Prototype de l’interface « Afficher les statistiques »
Pour consulter l’état global du parc informatique, il est nécessaire aux utilisateurs concernés
d’accéder à la page des statistiques [11] du système comme illustre les deux figures ci-dessous.
Les statistiques comprennent :
- Statistiques par systèmes d’exploitation
- Statistiques par domaine ou groupe de travail
- Statistiques par rendement des techniciens (nombre des tickets fermés par chaque
technicien par rapport à la totalité des tickets ouverts)
- Statistiques par tickets ouverts et fermés
- Statistiques par catégorie des problèmes
Figure 49 : Interface Consulter les statistiques systèmes (1)
SUPTECH
2014/2015
Page84
Figure 50 : Interface Consulter les statistiques systèmes (2)
SUPTECH
2014/2015
Page85
3. Prototype de l’interface « Gérer les catégories des problèmes»
Pour assigné une catégorie à un technicien informatique ou bien ajouter, modifier ou
supprimer des catégories, il est nécessaire au superviseur de passer à l’interface de gestion des
comptes comme illustre la figure suivante :
Figure 51: interface « Gestion des catégories »
Conclusion
Dans cette partie, nous avons concentré sur l’identification des besoins du système ainsi que
ses exigences qui ont permis de passer à la phase suivante « Phase construction » ou nous
allons entamer des nouveaux besoins et traiter les cas d’utilisation de priorité « 3 ».
SUPTECH
2014/2015
Page86
Chapitre V. Phase construction
SUPTECH
2014/2015
Page87
Chapitre 5
Phase construction
Introduction
Après avoir réalisés la plus part des cas d’utilisation dans les parties précédente, nous allons
passer maintenant à la troisième phase « la phase construction ». Dans cette partie, nous avons
capturés le reste des cas d’utilisation en continuant leurs analyses et conceptions afin de
finaliser l’implémentation de notre produit. A la fin de cette phase, nous allons avoir une
version exécutable du produit.
I. Identification des besoins
1. Raffinement des cas d’utilisation de priorité « 3 »
Dans cette partie nous allons traiter les cas d’utilisations de priorité « 3 »
- Gérer les départements
- Consulter les fichiers logs
A. Raffinement du cas d’utilisation « Gérer les départements »
 Diagramme de cas d’utilisation
Figure 52 : diagramme de cas d’utilisation« Gestion des départements »
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk

Contenu connexe

Tendances

Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Mohamed Aziz Chetoui
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Mohamed Boubaya
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"étudesMohamed Boubaya
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développementDonia Hammami
 
PFE : ITIL - Gestion de parc informatique
PFE : ITIL - Gestion de parc informatiquePFE : ITIL - Gestion de parc informatique
PFE : ITIL - Gestion de parc informatiquechammem
 
Projet de fin d'etude sur le parc informatique
Projet  de fin d'etude sur le parc informatiqueProjet  de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatiqueHicham Ben
 
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborativeMémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborativeMessaoud Hatri
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiDonia Hammami
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatiqueHicham Ben
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESTombariAhmed
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti MohammedMohammed JAITI
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile Raoua Bennasr
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaIlef Ben Slima
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Yasmine Lachheb
 

Tendances (20)

Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
Rapport de projet de fin d"études
Rapport de projet de fin d"étudesRapport de projet de fin d"études
Rapport de projet de fin d"études
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
PFE : ITIL - Gestion de parc informatique
PFE : ITIL - Gestion de parc informatiquePFE : ITIL - Gestion de parc informatique
PFE : ITIL - Gestion de parc informatique
 
Projet de fin d'etude sur le parc informatique
Projet  de fin d'etude sur le parc informatiqueProjet  de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatique
 
Mémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborativeMémoire PEF application client server gestion des projet collaborative
Mémoire PEF application client server gestion des projet collaborative
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Rapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammamiRapport pfe talan_2018_donia_hammami
Rapport pfe talan_2018_donia_hammami
 
Rapport Projet de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatiqueRapport Projet  de fin d'etude sur le parc informatique
Rapport Projet de fin d'etude sur le parc informatique
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
Pfe 2015
Pfe 2015Pfe 2015
Pfe 2015
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
Rapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben SlimaRapport PFE Ilef Ben Slima
Rapport PFE Ilef Ben Slima
 
Rapport pfev7
Rapport pfev7Rapport pfev7
Rapport pfev7
 
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
Rapport PFE BIAT Conception et mise en place d’une plate-forme de gestion des...
 

En vedette

Presentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskPresentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskRaef Ghribi
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiquejihene Ab
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaNazih Heni
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Addi Ait-Mlouk
 
Présentation GLPI
Présentation GLPIPrésentation GLPI
Présentation GLPIINTEGER SPRL
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebHarrathi Mohamed
 
Gestion de parc avec OCS et GLPI
Gestion de parc avec OCS et GLPI Gestion de parc avec OCS et GLPI
Gestion de parc avec OCS et GLPI guest3be047
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Ben Abdelwahed Slim
 
Presentation pfe
Presentation pfePresentation pfe
Presentation pfezinebcher
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFENadir Haouari
 
GLPI et FusionInventory, des solutions libres et innovantes
GLPI et FusionInventory, des solutions libres et innovantesGLPI et FusionInventory, des solutions libres et innovantes
GLPI et FusionInventory, des solutions libres et innovantesIgniteStrasbourg
 
Manipulation GLPI / OCS
Manipulation GLPI / OCSManipulation GLPI / OCS
Manipulation GLPI / OCSChris Dogny
 
Application de gestion, suivi,et de sécurité des chantiers en temps réels.
Application  de gestion, suivi,et de sécurité des chantiers en temps réels.Application  de gestion, suivi,et de sécurité des chantiers en temps réels.
Application de gestion, suivi,et de sécurité des chantiers en temps réels.Sabri El gharbi El yahmadi
 
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...HAFID Ait Bihi
 
Présentation OCS et GLPI aux Solutions Linux 2008
Présentation OCS et GLPI aux Solutions Linux 2008Présentation OCS et GLPI aux Solutions Linux 2008
Présentation OCS et GLPI aux Solutions Linux 2008Nouh Walid
 

En vedette (20)

Presentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskPresentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help desk
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
Rapport De PFE
Rapport De PFERapport De PFE
Rapport De PFE
 
Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...Conception et réalisation d'une application de gestion intégrée au sein de la...
Conception et réalisation d'une application de gestion intégrée au sein de la...
 
Présentation GLPI
Présentation GLPIPrésentation GLPI
Présentation GLPI
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site Web
 
Gestion de parc avec OCS et GLPI
Gestion de parc avec OCS et GLPI Gestion de parc avec OCS et GLPI
Gestion de parc avec OCS et GLPI
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
 
Presentation pfe
Presentation pfePresentation pfe
Presentation pfe
 
Présentation de mon PFE
Présentation de mon PFEPrésentation de mon PFE
Présentation de mon PFE
 
PROJET JAVA BD MySQL
PROJET JAVA BD MySQLPROJET JAVA BD MySQL
PROJET JAVA BD MySQL
 
GLPI et FusionInventory, des solutions libres et innovantes
GLPI et FusionInventory, des solutions libres et innovantesGLPI et FusionInventory, des solutions libres et innovantes
GLPI et FusionInventory, des solutions libres et innovantes
 
Manipulation GLPI / OCS
Manipulation GLPI / OCSManipulation GLPI / OCS
Manipulation GLPI / OCS
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
Application de gestion, suivi,et de sécurité des chantiers en temps réels.
Application  de gestion, suivi,et de sécurité des chantiers en temps réels.Application  de gestion, suivi,et de sécurité des chantiers en temps réels.
Application de gestion, suivi,et de sécurité des chantiers en temps réels.
 
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
 
Présentation OCS et GLPI aux Solutions Linux 2008
Présentation OCS et GLPI aux Solutions Linux 2008Présentation OCS et GLPI aux Solutions Linux 2008
Présentation OCS et GLPI aux Solutions Linux 2008
 

Similaire à Rapport de pfe gestion de parc informatique et Helpdesk

Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMohamed Arar
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...mouafekmazia
 
Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010CLES-FACIL
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Codendi
 
Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Digimind
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD) Ben Ahmed Zohra
 
Description open erp_v_7
Description open erp_v_7Description open erp_v_7
Description open erp_v_7Ab Rafaoui
 
Bureau virtuel
Bureau virtuelBureau virtuel
Bureau virtuelraymen87
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Oussama Ben Sghaier
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifsSafaAballagh
 
Administration reseau ok
Administration reseau ok Administration reseau ok
Administration reseau ok moisejean
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Houssem Eddine Jebri
 
Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0ACDISIC
 
initiation-au-langage-c-et-exercices-corriges
initiation-au-langage-c-et-exercices-corrigesinitiation-au-langage-c-et-exercices-corriges
initiation-au-langage-c-et-exercices-corrigesjojo sekkat
 

Similaire à Rapport de pfe gestion de parc informatique et Helpdesk (20)

Mémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventionsMémoire fin d'étude gestion des interventions
Mémoire fin d'étude gestion des interventions
 
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
Rapport Projet De Fin D'étude de Conception et développement d’une applicatio...
 
Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010Dossier de clôture : Fusex Padmée 2010
Dossier de clôture : Fusex Padmée 2010
 
Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0Guide Utilisateur Codendi 4.0
Guide Utilisateur Codendi 4.0
 
Bureautique
BureautiqueBureautique
Bureautique
 
Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008Barometre des Pratiques de Veille 2008
Barometre des Pratiques de Veille 2008
 
Technocles2010 1
Technocles2010 1Technocles2010 1
Technocles2010 1
 
Outpatient Department System (OPD)
Outpatient Department System (OPD) Outpatient Department System (OPD)
Outpatient Department System (OPD)
 
Rapport atef
Rapport atefRapport atef
Rapport atef
 
19
1919
19
 
C08 site
C08 siteC08 site
C08 site
 
Academy system manuel
Academy system manuelAcademy system manuel
Academy system manuel
 
Description open erp_v_7
Description open erp_v_7Description open erp_v_7
Description open erp_v_7
 
Bureau virtuel
Bureau virtuelBureau virtuel
Bureau virtuel
 
Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .Rapport de Projet de Fin d'étude .
Rapport de Projet de Fin d'étude .
 
Gestion des actifs applicatifs
Gestion des actifs applicatifsGestion des actifs applicatifs
Gestion des actifs applicatifs
 
Administration reseau ok
Administration reseau ok Administration reseau ok
Administration reseau ok
 
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...Implémentation et mise en place d’un système décisionnel pour la solution Meg...
Implémentation et mise en place d’un système décisionnel pour la solution Meg...
 
Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0Cadre commun d'urbanisation du SI de l'etat v1.0
Cadre commun d'urbanisation du SI de l'etat v1.0
 
initiation-au-langage-c-et-exercices-corriges
initiation-au-langage-c-et-exercices-corrigesinitiation-au-langage-c-et-exercices-corriges
initiation-au-langage-c-et-exercices-corriges
 

Rapport de pfe gestion de parc informatique et Helpdesk

  • 1. SUPTECH 2014/2015 Page1 Table des matières Chapitre I. Présentation générale........................................................................................................... 10 I. Organisme d’accueil...................................................................................................................... 11 1. YAZAKI.................................................................................................................................... 11 A. Historique du groupe YAZAKI............................................................................................. 11 B. Logo ...................................................................................................................................... 11 C. Les filiales de YAZAKI ........................................................................................................ 12 D. YAZAKI Tunisie................................................................................................................... 12 E. YAZAKI Bizerte ................................................................................................................... 13 II. Présentation du projet.................................................................................................................... 14 2. Problématique............................................................................................................................ 14 A. La non maitrise du hardware et du software.......................................................................... 14 B. Le manque de traçabilité et de suivi de l’équipement ........................................................... 14 C. Equipements non recensés..................................................................................................... 15 D. Gestion rapide des incendies ................................................................................................. 15 3. Objectif...................................................................................................................................... 15 4. Description du projet................................................................................................................. 15 Chapitre II. Etat de l’art......................................................................................................................... 17 I. Etude de l’existant......................................................................................................................... 18 1. Clarilog[2]................................................................................................................................... 18 2. Spiceworks[3] ............................................................................................................................. 19 3. GLPI[4] ....................................................................................................................................... 19 II. Critique de l’existant ..................................................................................................................... 20 III. Solution Proposée...................................................................................................................... 20 IV. Méthodologie du développement .............................................................................................. 21 1. Langage de modélisation........................................................................................................... 21 2. Méthodologie adopté................................................................................................................. 22 Chapitre III. Phase incubation............................................................................................................... 24 I. Identification des besoins .............................................................................................................. 25 1. Les besoins fonctionnels............................................................................................................ 25 2. Les besoins non fonctionnels..................................................................................................... 26
  • 2. SUPTECH 2014/2015 Page2 3. Acteurs et cas d’utilisation ........................................................................................................ 27 A. Acteurs du système................................................................................................................ 27 B. Cas d’utilisation par acteur.................................................................................................... 29 4. Cas d’utilisations par priorité .................................................................................................... 31 5. Raffinement des cas d’utilisation de priorité « 1 ».................................................................... 33 A. Raffinement du cas d’utilisation « S’authentifier »............................................................... 33 B. Raffinement du cas d’utilisation « Gérer les tickets »........................................................... 34 C. Raffinement du cas d’utilisation « Gérer l’inventaire » ........................................................ 37 D. Raffinement du cas d’utilisation « Gérer les prêts téléphoniques » ...................................... 39 6. Diagramme du cas d’utilisation global...................................................................................... 46 II. Conception..................................................................................................................................... 47 1. Diagramme de classe « gestion de parc informatique »............................................................ 47 2. Diagramme de séquence du cas d’utilisation « S’authentifier »................................................ 48 3. Diagramme de séquence du cas d’utilisation « Gérer les tickets »........................................... 49 A. Diagramme de séquence « Créer un ticket »......................................................................... 49 B. Diagramme d’activité « Créer un ticket » ............................................................................. 50 C. Diagramme de séquence « Modifier un ticket ».................................................................... 51 D. Diagramme de séquence « Supprimer un ticket »................................................................. 53 E. Diagramme de séquence détaillé « Envoi SMS par l’application Android »........................ 54 4. Diagramme de séquence de cas d’utilisation « Gérer l’inventaire » ........................................ 55 A. Diagramme de séquence « Créer un inventaire » avec Agent Inventory .............................. 55 B. Diagramme de séquence « Consulter détails de l’inventaire ».............................................. 56 5. Diagramme de séquence « Gérer les prêts téléphoniques » ...................................................... 57 A. Diagramme de séquence « Gérer les cartes SIM »................................................................ 58 B. Diagramme de séquence « Gérer les téléphones mobiles »................................................... 59 C. Diagramme de séquence « Gérer les utilisateurs des téléphones » ....................................... 60 D. Diagramme de séquence « Gérer les opérations de prêts » ................................................... 61 E. Diagramme de séquence « Télécharger la décharge téléphonique en PDF»......................... 62 III. Elaboration des prototypes des interfaces utilisateurs............................................................... 62 1. Prototype de l’interface « Authentification » ............................................................................ 62 2. Prototype de l’interface « Créer ticket ».................................................................................... 63 3. Prototype de l’interface « Gérer inventaire » ............................................................................ 65 4. Prototype de l’interface « Gérer les prêts téléphoniques »........................................................ 66 5. Prototype de l’interface « Imprimer la décharge téléphonique » .............................................. 67
  • 3. SUPTECH 2014/2015 Page3 Chapitre IV. Phase d’élaboration .......................................................................................................... 69 I. Identification des besoins .............................................................................................................. 70 1. Raffinement des cas d’utilisation de priorité « 2 ».................................................................... 70 A. Raffinement de cas d’utilisation « Gérer les comptes »........................................................ 70 B. Raffinement du cas d’utilisation « Afficher les statistiques»................................................ 73 C. Raffinement de cas d’utilisation « Gérer les catégories des problèmes informatiques» ....... 75 2. Cas d’utilisation global de la deuxième phase........................................................................... 77 II. Conception..................................................................................................................................... 78 1. Diagramme de classe................................................................................................................. 78 2. Diagramme de séquence de cas d’utilisation« Gérer les comptes ».......................................... 78 3. Diagramme de séquence de cas d’utilisation « Afficher les statistiques »................................ 80 4. Diagramme de séquence de cas d’utilisation« Gérer les catégories »....................................... 80 II. Elaboration de quelques prototypes des interfaces utilisateurs ..................................................... 82 1. Prototype de l’interface « Gérer comptes »............................................................................... 82 2. Prototype de l’interface « Afficher les statistiques »................................................................. 83 3. Prototype de l’interface « Gérer les catégories des problèmes»................................................ 85 Chapitre V. Phase construction ............................................................................................................. 86 I. Identification des besoins .............................................................................................................. 87 1. Raffinement des cas d’utilisation de priorité « 3 ».................................................................... 87 A. Raffinement du cas d’utilisation « Gérer les départements »................................................ 87 B. Raffinement du cas d’utilisation « Consulter les fichiers logs » ........................................... 89 2. Cas d’utilisation globale de la troisième phase ......................................................................... 91 III. Conception................................................................................................................................. 92 1. Diagramme de séquence du cas d’utilisation « Gérer les départements »................................. 92 2. Diagramme de séquence du cas d’utilisation « Gérer l’historique »......................................... 93 3. Diagramme de classe globale.................................................................................................... 94 4. La base des données de l’application ........................................................................................ 96 IV. Elaboration de quelques prototypes des interfaces utilisateurs ................................................. 97 1. Prototype de l’interface « Gérer les départements ».................................................................. 97 2. Prototype de l’interface « Consulter/Télécharger fichier log » ................................................. 98 Chapitre VI. Phase transition................................................................................................................. 99 I. Architecture logicielle du système .............................................................................................. 100 II. Environnement de réalisation..................................................................................................... 102 1. Environnement matériel ......................................................................................................... 102
  • 4. SUPTECH 2014/2015 Page4 2. Environnement logiciel............................................................................................................ 103 III. Mise en place de l’application................................................................................................. 103 1. Interface « Authentification ».................................................................................................. 103 2. Interface « Liste des tickets ouverts » ..................................................................................... 104 3. Interface « Les détails d’un ticket » ........................................................................................ 105 4. Interface « Les détails d’un ordinateur inventorié»................................................................. 105 5. Interface « Liste des logiciels installés dans un ordinateur » .................................................. 106 6. Interface « Liste des imprimantes installés dans un ordinateur »............................................ 106 7. Interface « Les détails d’un prêt téléphonique »...................................................................... 107 Conclusion générale ............................................................................................................................ 108 Annexes............................................................................................................................................... 109 Bibliographie....................................................................................................................................... 116
  • 5. SUPTECH 2014/2015 Page5 Liste des figures Figure 1: Logo de YAZAKI.................................................................................................................. 11 Figure 2: YAZAKI à travers le monde.................................................................................................. 12 Figure 3: Câblage fini............................................................................................................................ 13 Figure 4 : Clarilog ................................................................................................................................. 18 Figure 5 : Spiceworks............................................................................................................................ 19 Figure 6 : GLPI...................................................................................................................................... 19 Figure 7 : Architecture adoptée pour le développement de l’application.............................................. 21 Figure 8 : schéma de la méthodologie................................................................................................... 23 Figure 9 : fonctionnalités de Responsable informatique/Superviseur ................................................... 29 Figure 10 : fonctionnalités d’un technicien informatique ..................................................................... 30 Figure 11 : fonctionnalités d’un Employé administratif........................................................................ 31 Figure 12 : diagramme de cas d'utilisation « s’authentifier »................................................................ 33 Figure 13 : diagramme de cas d'utilisation « Gérer les tickets »........................................................... 34 Figure 14 : diagramme de cas d'utilisation « Gérer l’inventaire »......................................................... 37 Figure 15 : diagramme de cas d'utilisation « Gérer les prêts téléphoniques »....................................... 39 Figure 16 : Diagramme de cas d’utilisation globale.............................................................................. 46 Figure 17 : Diagramme de classe du système ....................................................................................... 47 Figure 18 : Diagramme de séquence « Authentification ».................................................................... 48 Figure 19 : Diagramme de séquence « Créer un ticket »....................................................................... 49 Figure 20 : Diagramme d’activité « Créer un ticket »........................................................................... 50 Figure 21 : Diagramme de séquence « Modifier un ticket » ................................................................. 52 Figure 22 : Diagramme de séquence « Supprimer un ticket »............................................................... 53 Figure 23 : Diagramme de séquence détaillé de « l’envoi SMS par Android ».................................... 54 Figure 24 : Diagramme de séquence « Créer un inventaire » ............................................................... 55 Figure 25 : Diagramme de séquence « Consulter détails de l’inventaire » ........................................... 56 Figure 26 : Diagramme de séquence « Gérer les cartes SIM » ............................................................. 58 Figure 27 : Diagramme de séquence « Gérer les téléphones mobiles »................................................ 59 Figure 28 : Diagramme de séquence « Gérer les utilisateurs des téléphones»...................................... 60 Figure 29 : Diagramme de séquence « Gérer les opérations de prêts »................................................. 61 Figure 30 : Diagramme de séquence « Télécharger la décharge en PDF »........................................... 62 Figure 31 : Interface d’authentification................................................................................................. 63 Figure 32 : Interface d’ajout d’une nouvelle demande d’intervention .................................................. 63 Figure 33 : Interface de ticket reçu avec Microsoft Outlook................................................................. 64 Figure 34 : Interface de ticket reçu par SMS......................................................................................... 64 Figure 35 : Interface de l’application Android...................................................................................... 65 Figure 36 : Interface des listes des ordinateurs inventoriés................................................................... 65 Figure 37 : Interface d’ajout d’un nouveau prêt téléphonique .............................................................. 66 Figure 38 : Interface exemple d’une décharge téléphonique en PDF.................................................... 67 Figure 39 : diagramme de cas d'utilisation « Gérer les comptes » ........................................................ 70 Figure 40 : diagramme de cas d'utilisation « Afficher les statistiques » ............................................... 73
  • 6. SUPTECH 2014/2015 Page6 Figure 41 : Description textuelle du cas d’utilisation « Afficher les statistiques » ............................... 74 Figure 42 : diagramme de cas d'utilisation « Gérer les catégories » ..................................................... 75 Figure 43 : diagramme de cas d'utilisation global du 2éme phase ........................................................ 77 Figure 44 : diagramme de classe de priorité « 2 »................................................................................. 78 Figure 45 : Diagramme de séquence « Gérer les comptes » ................................................................. 79 Figure 46 : Diagramme de séquence « Gérer les catégories »............................................................... 80 Figure 47 : Diagramme de séquence « Gérer les catégories »............................................................... 81 Figure 48: interface « Gestion des comptes » ....................................................................................... 82 Figure 49 : Interface Consulter les statistiques systèmes (1)................................................................. 83 Figure 50 : Interface Consulter les statistiques systèmes (2)................................................................. 84 Figure 51: interface « Gestion des catégories »..................................................................................... 85 Figure 52 : diagramme de cas d’utilisation« Gestion des départements » ............................................ 87 Figure 53 : diagramme de cas d’utilisation« Gérer l’historique »......................................................... 89 Figure 54 : diagramme de cas d’utilisation globale du 3éme phase...................................................... 91 Figure 55 : Diagramme de séquence « Gérer les départements ».......................................................... 92 Figure 56 : Diagramme de séquence « Gérer l’historique ».................................................................. 93 Figure 57 : Diagramme de classe globale.............................................................................................. 94 Figure 58 : Schéma de la base des données........................................................................................... 96 Figure 59 : Interface « Gérer les départements ..................................................................................... 97 Figure 60 : Interface « Historiques des transactions téléphoniques » ................................................... 98 Figure 61 : Modèle générale de l’architecture orienté service ............................................................ 100 Figure 62 : Les couches de l’application............................................................................................. 101 Figure 63 : interface « authentification » ............................................................................................ 103 Figure 64 : interface « liste des tickets ouverts» ................................................................................. 104 Figure 65 : interface « les détails d’un tickets»................................................................................... 105 Figure 66 : interface « les détails d’un ordinateur»............................................................................. 105 Figure 67 : interface « liste des logiciels installés dans un ordinateur» .............................................. 106 Figure 68 : interface « liste des imprimantes installés dans un ordinateur»........................................ 106 Figure 69 : interface « les détails d’un prêt téléphonique».................................................................. 107
  • 7. SUPTECH 2014/2015 Page7 Liste des tableaux Tableau 1: Affectation des priorités aux cas d’utilisations.................................................................... 32 Tableau 2 : Description textuelle du cas d’utilisation « S’authentifier » .............................................. 34 Tableau 3 : Description textuelle du cas d’utilisation « Créer/Ouvrir un ticket »................................. 35 Tableau 4 : Description textuelle du cas d’utilisation « Répondre/Fermer un ticket » ......................... 35 Tableau 5 : Description textuelle du cas d’utilisation « Consulter un ticket »...................................... 36 Tableau 6 : Description textuelle du cas d’utilisation « Supprimer un ticket »..................................... 37 Tableau 7 : Description textuelle du cas d’utilisation «Consulter liste des imprimantes».................... 38 Tableau 8 : Description textuelle du cas d’utilisation « Consulter liste des ordinateurs ».................... 38 Tableau 9 : Description textuelle du cas d’utilisation « Consulter liste des logiciels » ........................ 38 Tableau 10 : Description textuelle du cas d’utilisation « Ajouter un téléphone »................................. 40 Tableau 11: Description textuelle du cas d’utilisation « Modifier un téléphone »................................ 40 Tableau 12 : Description textuelle du cas d’utilisation « Supprimer un téléphone »............................ 41 Tableau 13 : Description textuelle du cas d’utilisation « Ajouter une carte SIM »............................... 41 Tableau 14 : Description textuelle du cas d’utilisation « Modifier une carte SIM »............................. 42 Tableau 15 : Description textuelle du cas d’utilisation « Supprimer une carte SIM ».......................... 42 Tableau 16 : Description textuelle du cas d’utilisation « Ajouter un prêt ».......................................... 43 Tableau 17 : Description textuelle du cas d’utilisation « Modifier une opération de prêt » ................. 44 Tableau 18 : Description textuelle du cas d’utilisation « Supprimer une transaction » ........................ 44 Tableau 19 : Description textuelle du cas d’utilisation « Récupérer téléphone & SIM » ..................... 45 Tableau 20 : Description textuelle du cas d’utilisation « Créer un nouveau compte » ......................... 71 Tableau 21 : Description textuelle du cas d’utilisation « Modifier un compte » .................................. 72 Tableau 22 : Description textuelle du cas d’utilisation « Supprimer un compte »................................ 72 Tableau 23 : diagramme de cas d'utilisation « Ajouter une catégorie »................................................ 75 Tableau 24 : diagramme de cas d'utilisation « Modifier une catégorie ».............................................. 76 Tableau 25 : Description textuelle du cas d’utilisation « Supprimer une catégorie » ........................... 76 Tableau 26 : Description textuelle du cas d’utilisation « Ajouter un département » ............................ 88 Tableau 27 : Description textuelle du cas d’utilisation « Modifier un département » .......................... 88 Tableau 28 : Description textuelle du cas d’utilisation « Supprimer un département »........................ 89 Tableau 29 : Description textuelle du cas d’utilisation « Consulter l’historique » ............................... 90 Tableau 30 : Description textuelle du cas d’utilisation « Télécharger fichier log ».............................. 90 Tableau 31 : Caractéristique poste de travail ...................................................................................... 102 Tableau 32 : Environnement logiciel .................................................................................................. 103
  • 8. SUPTECH 2014/2015 Page8 Introduction générale Avec le développement de plus en plus de l’utilisation des ressources informatiques dans les entreprises, l’objectif de ces derniers devient la recherche perpétuelle de solutions pratiques pour la gestion efficace de leur parc. Un parc informatique est un ensemble de ressources matérielles et logicielles dont dispose une entreprise dans le traitement automatisé de l’information. Pour assurer la survie et la pérennité de ses ressources, il est important d’avoir une gestion efficiente du parc informatique de l’entreprise. La gestion du parc informatique consiste donc d’une part à lister et à localiser les équipements de l’entreprise, d’autre part à effectuer des tâches de maintenance, d’assistance aux utilisateurs. Ces opérations peuvent être effectuées par une personne qualifiée, mais bien souvent ce travail dépasse ses compétences. Pour pallier à cela, il est nécessaire qu’un ou plusieurs outils soient mis en place au sein de l’entreprise afin d’avoir un suivi régulier du parc informatique et parfois anticiper sur les défaillances de ses ressources. Notre projet de fin d’étude abordera ainsi les différentes phases de développement d’une application de gestion de l’inventaire des composantes matérielles et logicielles d’un parc informatique et la gestion de l’assistance aux utilisateurs, il sera divisé en cinq chapitres principaux.  Nous abordons par un premier chapitre intitulé « Présentation générale », qui détaille le contexte du projet en introduisant l’organisme d’accueil et en présentant le sujet de projet.  Nous étudions aussi dans le deuxième chapitre intitulé « Etat de l’art » quelques applications de gestion des parcs informatiques en vue de les critiquer et dégager les points forts pour les exploiter dans notre produit.  Dans le troisième chapitre intitulé « Phase d’incubation », nous allons concentrer sur la compréhension du contexte en levant l’ambiguïté sur les besoins ainsi que la définition des besoins fonctionnels et non fonctionnels, l’identification des acteurs, etc.  Après la compréhension des exigences du système en passe au quatrième chapitre intitulé « Phase d’élaboration », ou nous allons continuer la construction de notre système. Nous allons présenter également le modèle de conception et d’implémentation des cas d’utilisation.
  • 9. SUPTECH 2014/2015 Page9  Dans le cinquième chapitre intitulé « Phase de Construction », nous allons présenter tous les besoins restants en continuant l’analyse, la conception et l’implémentation de tous les cas d’utilisation.  Le dernier chapitre intitulé « Phase de Transition », nous allons présenter notre architecture qu’on a utilisée, l’environnement de travail et quelque interface sous forme d’un guide utilisateur. Notre rapport se terminera par une conclusion générale donnant une synthèse de travail effectué. Par ailleurs, certaines annexes sont jointes pour fournir plus de détails.
  • 11. SUPTECH 2014/2015 Page11 Chapitre 1 Présentation générale Introduction Ce chapitre a pour objectif de situer le projet dans son contexte général. Pour ce faire, nous présentons dans un premier lieu l’organisme d’accueil, ensuite, nous décrivons minutieusement le projet en dégagent les problèmes en vue de préciser les objectifs. I. Organisme d’accueil Dans le cadre du projet de fin d’étude et pour le but de l’obtention du diplôme national d’ingénieur en informatique appliquée à la multimédia au sein de l’école Supérieure Privée de Technologie et de Management, la Société YAZAKI Automotive Products (YAPT) nous propose un projet a réalisé pour quatre mois. 1. YAZAKI A. Historique du groupe YAZAKI YAZAKI [1] est l’un des plus grand producteur du monde de câblage automobile et un joueur dans la fabrication des systèmes de la distribution électrique et électroniques, l’instrumentation électronique et les composants pour les voitures. La date de succès de YAZAKI était en 1929, quand Sadami YAZAKI a commencé à vendre les câblages pour les automobiles. En 1939, l’affaire pourrait être étendue et en 1941, YAZAKI Fil Electrique Industriel Co. Ltd a été établi avec approximativement 70 employés. B. Logo Figure 1: Logo de YAZAKI
  • 12. SUPTECH 2014/2015 Page12 C. Les filiales de YAZAKI YAZAKI est représentée dans 38 pays dans le monde, 175 sites, 410 unités réparties entre usines de production et centres de service au client et centres de Recherche & Développement. Figure 2: YAZAKI à travers le monde D. YAZAKI Tunisie L'usine du groupe japonais YAZAKI est opérationnelle en Tunisie depuis juin 2010. Dans une première étape, le groupe japonais a installé une unité pilote chargée de former, jusqu'à fin 2009, les futurs travailleurs (800) et cadres (150) de l'usine. L'unité est gérée par des compétences Tunisiennes. Le coût total de réalisation et d'équipement du projet japonais s'élèvera à 24 millions d'Euros et devra créer 2500 emplois directs (dont 308 emplois de cadres supérieurs (bac +2)). Le choix de la Tunisie, le deuxième pays africain dans lequel le groupe japonais réalise un projet s'explique essentiellement par le niveau de compétence de ses cadres. En 2012, le processus s’est poursuivi. En effet, après le site de Gafsa, le groupe japonais lance son deuxième site en Tunisie, plus précisément à Bizerte.
  • 13. SUPTECH 2014/2015 Page13 E. YAZAKI Bizerte Le groupe japonais YAZAKI s’est installé dans la région de Bizerte en faisant l’acquisition de la société de câblage de voiture « SCV » du groupe italien « Cabletettra » installée en Tunisie depuis 2001.YAZAKI a acquis tous les sites du groupe italien situé à Menzel Djemil et à Menzel Bourguiba et qui possédaient un effectif d’environ 1200. Le choix de la ville de Bizerte est légitimé par plusieurs raisons dont les principales sont:  La proximité avec le continent européen.  La fréquence des liaisons et correspondances maritimes.  La vocation même de la ville.  Une culture ouverte et internationale : Depuis longtemps, la ville a été considérée comme zone internationale justifiant la multiplicité des usages linguistiques : arabe, français et anglais;  Une abondance de main-d’œuvre régionale d’un bon niveau. Le site de Bizerte comptait, en 2012, 1300 employés avec un objectif de 4000 employés à atteindre en 2015. Les Activités de YAZAKI-Bizerte L’activité principale de YAZAKI-Bizerte est l’assemblage des câbles électriques afin de produire un câblage qui permet de connecter des différents éléments dans un système électromécanique et de fournir de l’énergie électrique et des signaux électronique à différents périphériques du système. Figure 3: Câblage fini
  • 14. SUPTECH 2014/2015 Page14 II. Présentation du projet Nous présentons dans ce qui suit le projet du stage ainsi que les motivations pour lesquelles ce projet a été mis en œuvre pour bien le comprendre et délimiter ce qui est demandé pour passer à l’action et répondre aux spécifications d’une façon concise et efficace. 2. Problématique L’idée générale du projet consiste à concevoir un outil applicatif qui pourra de façon concrète permettre à un utilisateur de circonscrire un incident ou une demande de service à travers les tickets. Les techniciens informatiques seront capables de recevoir instantanément ces demandes via Mail et SMS afin d’assurer le bon déroulement de l’information et la rapidité des interventions. L’administrateur utilisera le même système pour gérer le prêt des téléphones mobiles, les cartes SIM et leurs accessoires. Ce système devra offrir aussi la possibilité d’inventorier les machines d’un parc informatique. Avant de plonger dans l’étude proprement dite de la solution, il est indispensable de prendre du recul et de faire un résumé des problèmes concrets existants qui peuvent rencontrer les acteurs. C’est donc dans cette optique qu’une petite enquête a été menée auprès de ces personnes et la plupart des problèmes recensés dans le parc de la société YAZAKI sont les suivants : A. La non maitrise du hardware et du software En tête de liste, ce problème est le plus récurrent chez la plupart des administrateurs réseaux et systèmes. En effet, le nombre croissant d’équipements et l’hétérogénéité du parc ne permettent pas à ceux-ci de maitriser tous les systèmes, logiciels et matériaux installés. B. Le manque de traçabilité et de suivi de l’équipement De nos jours, le contrôle et le suivi des équipements dans les entreprises devront se faire d’une manière informatisé et automatique, dans le cas de la société YAZAKI ils manquent le suivi et la traçabilité des téléphones mobiles et les cartes SIM utilisés par les personnels de la société.
  • 15. SUPTECH 2014/2015 Page15 C. Equipements non recensés Dans le réseau d’une entreprise, lorsqu’un équipement tombe en panne, nous avons du mal à le remplacer par un équipement adéquat (même système, même modèle, même périphérique…) qui remplirait exactement les mêmes fonctions. Ceci est dû au fait que le stock des ressources de l’entreprise n’est pas inventorié. D. Gestion rapide des incendies Les techniciens informatiques sensés de résoudre et répondre aux demandes d’interventions peuvent être ne pas informer de ces problèmes s’ils sont loin de leurs PCs ou leurs boites mail chargés ne leurs permet pas de bien voir la demande et de le récupérer à temps. L’application proposée devra ainsi être à mesure d’apporter une solution concrète à la prise en charge des différents problèmes ci-dessus. 3. Objectif Dans ce cadre, le service IT pense aux innovations technologiques qui prennent de plus en plus de l’importance dans les nouvelles entreprises, on parle notamment des technologies qui transforment les habitudes de travail quotidiennes, elles les automatisent en partie, réduisent généralement le volume de tâches bureautiques et améliorent la coordination. Pour ce faire YAZAKI cherche la mise en place d’une application qui aborde les nouveaux enjeux dans le service informatique à fin d’automatiser les activités et les organiser, dans le cadre de ce projet on s’intéresse en particulier à développer une solution web de gestion des parcs informatique et de Help Desk. 4. Description du projet Ce projet, qui consiste a réalisé une application web permettant de couvrir trois modules. Le premier module concerne la gestion des interventions et qui comprend la notification par Mail et par SMS de chaque nouvelle demande envoyé. Le deuxième module destiné à faire l’inventaire d’un parc informatique en tant que machines et logiciels d’une manière automatique grâce à une application exécutable. Le troisième module offre la possibilité de faire la gestion des prêts des téléphones mobiles et des cartes SIM avec l’impression des décharges.
  • 16. SUPTECH 2014/2015 Page16 Conclusion Dans ce chapitre introductif, nous avons présenté l’organisme d’accueil ainsi que le projet à réaliser. Nous allons entamer maintenant la phase de préparation de ce projet qui est l’étude de l’existant et la présentation des différentes solutions disponibles sur le marché.
  • 18. SUPTECH 2014/2015 Page18 Chapitre 2 Etat de l’art Introduction Ce chapitre a pour objet de présenter quelques applications pour la gestion des parcs informatiques d’une manière détaillée, en exposant leurs fonctionnalités. I. Etude de l’existant Parmi les produits existants sur le marché, nous retrouvons principalement: 1. Clarilog[2] Cette application a été créée par l’entreprise Clarilog France et permet entre autre :  L’audit du parc informatique en utilisant le module clarilog Fast Inventory qui permet de récolter les données sans déploiement d’agent ;  Une cartographie complète des équipements du parc ; Clarilog SNMP Discovery récupère les informations présentes dans le réseau via le protocole SNMP et fait appel à un référentiel d’information alimenté par les équipes Figure 4 : Clarilog
  • 19. SUPTECH 2014/2015 Page19 2. Spiceworks[3] Cette solution offre aux usagers les possibilités suivantes :  Effectuer l’inventaire des machines sans déploiement d’agent ;  Gérer les incidents (HelpDesk) ;  Scanner le réseau ;  Effectuer la gestion des configurations. Figure 5 : Spiceworks 3. GLPI[4] Cette solution open source est capable de :  Administrer plusieurs parcs pour optimiser la maintenance  Inventorier les machines d’un parc informatique ;  Gérer les incidents (HelpDesk) ;  Gérer un système de base de connaissances hiérarchique  Donner la possibilité d’ajouter des modules complémentaires Figure 6 : GLPI
  • 20. SUPTECH 2014/2015 Page20 II. Critique de l’existant Une analyse des solutions existantes montre que la plupart de ces applications offrent des fonctionnalités de base de gestion d’un parc informatique à savoir l’inventaire, l’accès au Helpdesk et le scan du réseau. Au regard de ces informations, nous pouvons relever qu’elles répondent au besoin principal des utilisateurs. Néanmoins, nous pouvons aussi noter les inconvénients suivants :  Clarilog n’est pas une application open source ; Ainsi il est impossible de l’adapter aux besoins spécifiques de YAZAKI .  Spiceworks ne permet pas à un utilisateur d’intégrer ses propres modules pour améliorer la performance de son parc ou pour des fonctionnalités supplémentaires.  GLPI est un système lourd, peu ergonomique et trop chargés des fonctionnalités inutiles. Ainsi l’accès à une fonctionnalité précise n’est pas toujours une tache facile.  Aucun de ces solutions ne permet de recevoir les demandes d’interventions par SMS ou par une application mobile. Ceci nous semble un obstacle pour la diffusion des informations urgents.  Absence d’un module de gestion de prêt des téléphones mobiles et cartes SIM. Pour des raisons de sécurités la direction de YAZAKI préfère toujours si c’est possible de concevoir leurs propres logiciels open sources et les développer localement selon les besoins, et évitent toute autre solution gratuite téléchargeable sur internet. III. Solution Proposée Après une étude comparative sur les différentes solutions existantes, il est ainsi primordial au regard des inconvénients et limitation recensés de proposer une solution qui pourra répondre à nos besoins. Nous avons choisi de développer une application Web avec l’architectures Web service offrant les fonctionnalités basiques d’un système de gestion d’un parc informatique tel que la gestion des interventions et d’inventaires et qui offre aussi des fonctionnalités supplémentaire telles que la gestion des prêts des téléphones mobiles et des cartes SIM et la notification par SMS. La solution logicielle à mettre en œuvre est décomposée en plusieurs modules : 1. Une application lourde ayant accès à des Web services distants prenant en charge le collecte des différentes caractéristiques matérielles et logicielles d’une machine, ces dernières seront stockés dans une base de données MySQL distante.
  • 21. SUPTECH 2014/2015 Page21 2. Une application Web en J2E chargée de faire le suivi en ligne des ressources informatiques et gérer l’ensemble des interventions ainsi que la résolution des problèmes. 3. Un système de gestion des tickets à mettre en place pour la gestion des interventions. Figure 7 : Architecture adoptée pour le développement de l’application IV. Méthodologie du développement 1. Langage de modélisation Nous avons choisi comme langage de modélisation UML[6] (Unified Modeling Languge) reconnue comme étant le standard industriel par excellence de la modélisation objet. Il permet, ainsi, de nous aider à modéliser un système robuste, fiable et évolutif et de limiter de nombreux risques d’erreur vue sa simplicité de modéliser les diagrammes.
  • 22. SUPTECH 2014/2015 Page22 2. Méthodologie adopté Après avoir défini la problématique et les objectifs à atteindre, une petite étude déjà faite pour fixer un processus de travail, donc parmi les méthodologies du développement qui existent et en coordination avec notre projet, nous avons trouvé que le PU (Processus Unifié)[5] est la méthodologie de travail qui peut nous orienter tout au long du projet, c’est une méthodologie qui vient de compléter la systématique des modèles UML, elle est générique, itérative et incrémentale, piloter par les risque, centré sur l’architecture et conduite par les cas d’utilisation permettant de décrire les besoins et exigences des utilisateurs, autrement dit c’est une méthode orientée par les besoins des utilisateurs. Le Processus Unifié répète un certain nombre de fois de cycle. Le résultat de chaque cycle est une partie exécutable du système, testée et intégrée, mais qui n’est pas prête à être livrée (Chaque cycle se décompose par l’analyse des besoins, la conception, l’implémentation et les tests unitaires). Nous présentons ainsi les quatre phases de cycle de vie Processus Unifié : Phase d’incubation Définir le champ d’action de projet : spécification des besoins et présenter l’architecture de système. Phase d’élaboration On développe de façon incrémentale l'architecture du noyau, préciser la plus part des cas d’utilisateurs afin de présenter l’architecture de système sous forme de vue de présentation pour chaque modèle. Phase de construction C’est la phase de réalisation de produit, il contient en fin tous les cas d’utilisation. Phase de transition Le produit final est livré à la disposition des utilisateurs. Les activités comme les formations et la correction des anomalies seront supposé dans cette phase.
  • 23. SUPTECH 2014/2015 Page23 Figure 8 : schéma de la méthodologie Conclusion Dans ce chapitre nous avons essayé d’étudier quelques applications de gestion des parcs informatiques dans le but d’avoir une idée sur les fonctionnalités de ces dernières et de ressortir leurs points forts. En deuxième lieu, nous avons précisé la méthodologie de travail à suivre pour réaliser le système. Ceci nous permet de passer au chapitre suivant ou nous allons présenter la première phase de Processus Unifié.
  • 25. SUPTECH 2014/2015 Page25 Chapitre 3 Phase incubation Introduction Nous entamons dans ce chapitre la première phase de processus unifié « phase incubation ». Il s’agit d’identifier les acteurs de système, de lever l’ambigüité sur les besoins et les exigences dans cette phase afin d’essayer de construire une architecture candidate. I. Identification des besoins L'objectif principal d'un système logiciel est de rendre service à ses utilisateurs, il faut par conséquent bien comprendre les désirs et les besoins des futurs utilisateurs. Donc dans ce qui suit, nous commencerons par énumérer les exigences explicites et implicites ainsi que l’ensemble des fonctionnalités du logiciel. 1. Les besoins fonctionnels Les besoins fonctionnels sont définis comme étant des services attendus par l’utilisateur de produit. Ils doivent constituer un ensemble complet et cohérent. Dans ce qui suit, nous allons présenter les besoins fonctionnel ébauchés durant la proposition de la solution. L’application conçue se présente sous forme de trois modules :  Un module de gestion des incendies et des demandes d’interventions  Un module de gestion de l’inventaire d’un parc informatique  Un module de gestion des prêts des téléphones mobiles et des cartes SIM Commençant par :  Module de gestion des incendies et des demandes d’interventions o Gérer les tickets : Une demande d’intervention correspond à un ticket ouvert par un utilisateur quelconque, pour cela ce dernier doit accéder au système et remplir un formulaire qui va être par la suite traité et fermer par un technicien informatique. o Gérer les notifications par SMS : chaque nouvelle demande d’intervention crée par un utilisateur sera transmis par SMS aux techniciens informatiques du parc. o Gérer les notifications par Mail [10]: au plus des SMS les nouvelles demandes d’interventions seront transmis aussi par email aux techniciens informatiques. o Gérer les profils : La création d’un nouveau profil utilisateur ainsi que la modification et la suppression des profils existants ne sont faits que par l’administrateur système. o Gérer les statistiques : des statistiques en graphe seront disponibles pour une visualisation globale et analyse rapide de l’état du parc informatique.
  • 26. SUPTECH 2014/2015 Page26  Module de gestion de l’inventaire d’un parc informatique o Gérer les ressources matérielles du parc : le système doit récolter automatiquement et systématiquement les caractéristiques de différentes ressources matérielles des PCs présents dans le parc. Ces ressources comprennent la mémoires, disques dur, processeur.. o Gérer les ressources logicielles du parc : le système indique la liste des logiciels installés dans chaque PC tel que le système d’exploitation utilisé. o Gérer le caractéristique réseau de chaque ordinateur (adresse IP, MAC, domaine,..)  Module de gestion des prêts des téléphones mobiles et des cartes SIM o Gérer les utilisateurs des téléphones mobiles : Un utilisateur de téléphone mobile et celui que la société YAZAKI lui assigne à partir du service informatique un appareil téléphonique et une carte SIM afin de les utiliser pour un duré déterminé. La ligne et l’appareil téléphonique sont à la propriété de YAZAKI. o Gérer les téléphones mobiles : faire la gestion des appareils téléphoniques qui vont être utilisé par l’ensemble du personnelle de la société. Les caractéristiques des appareils seront stocké dans la base du système, ces caractéristiques comprennent la marque, le modèle, IMEI, couleur,.. o Gérer la liste des cartes SIM : faire la gestion des cartes SIM qui vont être utilisé par l’ensemble du personnelle de la société. Les caractéristiques cartes SIM seront stocké dans la base du système, ces caractéristiques comprennent le numéro, code PIN, code PUK, opérateur,.. o Gérer les transactions : une transaction est l’opération de l’assignement d’un appareil téléphonique et une carte SIM à un utilisateur o Gérer l’historique : donner la possibilité au responsable du système de consulter l’historique des transactions téléphoniques et des accès au système. 2. Les besoins non fonctionnels Les besoins non fonctionnel se basent sur le respect des normes de l’ergonomie et des interactions homme/machine qu’on fournit à l’application. Donc, les contraintes techniques nécessaires qui garantissent la performance à notre solution se résument en :  La rapidité de traitement En effet, vu le nombre important des activités et des utilisateurs, il est impérativement nécessaire que la durée d’exécution des traitements soit minimale.   La portabilité Il s’agit de minimiser l’effort pour se faire transporter dans un autre environnement matériel et/ou logiciel.  La conformité
  • 27. SUPTECH 2014/2015 Page27 Contenir un minimum d’erreurs et satisfaire les spécifications.   L’ergonomie des interfaces Les interfaces doivent être claires et bien structurées. A ce propos, un thème sera choisi et utilisé au cours de développement de l’application pour assurer le bon choix du design. Les interfaces doivent obéir à un ensemble de critères ergonomiques tel que l’accessibilité, la lisibilité et la convivialité afin d’assurer l’interaction entre l’utilisateur et l’application.   L’intégrité Les fonctionnalités offertes à chaque utilisateur doivent être restreintes à celles qui lui sont autorisées. L’information n’est modifiée que par les personnes y ayants droit. Dans ce cas, nous définissons pour chaque utilisateur ces droits d’accès au système.   La fiabilité Le système doit prouver la sureté de son fonctionnement. C’est pour cette raison qu’il doit exécuter correctement toutes ses structures, pour répondre convenablement aux besoins de l’utilisateur.   La sécurité Le système doit traiter les failles de sécurité d’où le besoin d’un login et d’un mot de passe pour accéder au système. Les messages d’erreurs doivent identifier tous les cas d’erreurs de saisie et leur source. 3. Acteurs et cas d’utilisation Nous détaillons dans ce qui suit les acteurs intervenant dans notre application : A. Acteurs du système Nous parvenons à une étape clé du processus. C’est elle qui grâce à l’étude réalisée dans la partie précédente mettra en valeur le rôle de chaque acteur du système ainsi que les fonctionnalités présentées plus haut. La gestion des interventions, la gestion de l’inventaire et la gestion des prêts des équipements téléphoniques, peuvent parvenir des différents acteurs. Dans cette partie nous allons énumérer les différents acteurs susceptibles d’interagir avec le système, citant :
  • 28. SUPTECH 2014/2015 Page28  Employés administratifs  Responsable informatique  Techniciens informatique - L’acteur « Employé administratif » est l’utilisateur qui va lancer la demande d’intervention en cas de problème informatique, pour le faire il doit accéder au système via ces paramètres d’authentification et il doit ouvrir un ticket en remplissant un formulaire de demande d’intervention , ainsi ces rôles sont résumés comme décrit ci-dessous : - Ouvrir un ticket - Suivre l’état de son ticket - Consulter l’historique des tickets - Gérer son profil - L’acteur « Responsable informatique » représente le superviseur de notre système à développer qui va : - Créer des nouveaux comptes - Créer une transaction téléphonique - Modifier ou supprimer une transaction téléphonique - Répondre aux demandes d’intervention et fermer les tickets - Suivre l’inventaire du parc informatique - Afficher les statistiques de l’inventaire - Consulter les fichiers logs . - Ajouter un téléphone - Ajouter une carte SIM - Gérer les catégories des problèmes - L’acteur « Technicien informatique » est l’agent responsable de suivre tous les demandes d’intervention, répondre et fermer les tickets, ainsi ces rôles sont résumés comme décrit ci- dessous : - Répondre aux demandes d’interventions - Consulter l’historique des tickets - Suivre l’inventaire du parc informatique - Afficher les statistiques de l’inventaire - Ajouter un téléphone - Ajouter une carte SIM
  • 29. SUPTECH 2014/2015 Page29 B. Cas d’utilisation par acteur a) Diagramme associé au Responsable informatique Le diagramme ci-dessous présente le diagramme de cas d’utilisation décrivant les différentes fonctionnalités que le « Responsable informatique ». Figure 9 : fonctionnalités de Responsable informatique/Superviseur Il décrivant les fonctionnalités du « Superviseur » du système qui est lui-même le responsable informatique, il se charge de suivre toutes les fonctionnalités principales des trois modules du système gestionnaire du parc ainsi que des fonctions supplémentaires tel que la gestion des départements et la consultation des fichiers logs.
  • 30. SUPTECH 2014/2015 Page30 b) Diagramme associé au Technicien informatique Sur la figure ci-dessous, nous découvrons les mêmes fonctionnalités principales mais qui correspond au technicien informatique, lui également a la possibilité de gérer les tickets, l’inventaire et la gestion des téléphones mobiles et carte SIM. Figure 10 : fonctionnalités d’un technicien informatique Le « Technicien informatique » est l’acteur qui se charge de répondre aux demandes des interventions, suivre l’état de l’inventaire ainsi que la gestion des prêts téléphoniques.
  • 31. SUPTECH 2014/2015 Page31 c) Diagramme associé à un Employé administratif Le diagramme ci-dessus présent le diagramme de cas d’utilisation décrivant les différentes fonctionnalités qu’un « Employé administratif». Figure 11 : fonctionnalités d’un Employé administratif « L’employé administratif», c’est tout acteur qui admet un compte sur l’application afin de créer ces tickets et suivre leurs états. 4. Cas d’utilisations par priorité Nous allons dans un premier temps distingué les cas d’utilisation les plus prioritaires que les autres du point de vue fonctionnel, pour ce focalisé dans un second temps à les détailler.  Affectation des priorités Parmi les caractéristiques qui caractérisent le PU c’est qu’il est piloté par les cas d’utilisation, dans ce sens, nous allons les classés selon leur ordre d’importance pour chacun des acteurs d’où, la nécessité de définir un ordre de priorité pour les cas d’utilisation. Dans notre cas, les cas d’utilisation qui s’avèrent les plus prioritaires ont la priorité « 1 » et les moins prioritaire ont la priorité « 3 ».
  • 32. SUPTECH 2014/2015 Page32 Priorité Cas d'utilisation Acteurs Description 1 Authentification Superviseur Tous les utilisateurs doivent s’authentifier pour se connecter à la plateforme de l’application Technicien Employé 1 Gérer les tickets Superviseur Après authentification, le responsable informatique et le technicien ont le droit de consulter, d’ajouter, de modifier, de supprimer ou de répondre aux demandes d’intervention. Technicien 1 Gérer l’inventaire Superviseur Après authentification, le responsable informatique et le technicien ont le droit d’afficher l’état de l’inventaire.Technicien 1 Gérer les prêts téléphoniques Superviseur Après authentification, le responsable informatique et le technicien ont le droit de d’ajouter, modifier ou de supprimer un téléphone mobile ou une carte SIM aussi de créer une opération de prêt téléphonique (prêter, récupérer) à une personne. Technicien 2 Gérer les comptes Superviseur Après authentification le responsable informatique a le droit de créer, de modifier ou de supprimer un compte pour un employé administratif. 2 Afficher les statistiques Superviseur Après authentification le responsable informatique et les techniciens ont le droit de consulter les statistiques du parc informatiques.Technicien 2 Gérer les catégories des problèmes informatiques Superviseur Après authentification, le superviseur a le droit de saisir d’ajouter, modifier ou de supprimer une catégorie de problème informatique. 3 Consulter l’historique Superviseur Après authentification, le superviseur peut consulter les fichiers logs enregistrer dans les systèmes et les télécharger. 3 Gérer les départements Superviseur Après authentification, le superviseur a le droit de saisir d’ajouter, modifier ou de supprimer un département. Tableau 1: Affectation des priorités aux cas d’utilisations
  • 33. SUPTECH 2014/2015 Page33 5. Raffinement des cas d’utilisation de priorité « 1 » A. Raffinement du cas d’utilisation « S’authentifier »  Diagramme de cas d’utilisation Figure 12 : diagramme de cas d'utilisation « s’authentifier » Pour pouvoir accéder au système, chaque utilisateur doit tout d’abord s’authentifier. Cette authentification est nécessaire pour assurer la sécurité et la confidentialité des données. Sommaire d’authentification Titre Authentification Objectif Etre connue par le système Acteurs Employé administratif, Superviseur/Responsable informatique, Technicien Description des enchainements Pré-condition Post-condition L’utilisateur doit être connu par le système L’utilisateur avoir l’accès à son espace privé Scénario nominal 1. L’utilisateur lance l’application
  • 34. SUPTECH 2014/2015 Page34 2. Le système affiche un formulaire de connexion à l’acteur 3. L’utilisateur saisie le « login » et le « mot de passe » 4. L’utilisateur demande la connexion 5. Le système vérifie les données saisies 6. Le système valide les données et permet l’accès Tableau 2 : Description textuelle du cas d’utilisation « S’authentifier » B. Raffinement du cas d’utilisation « Gérer les tickets »  Diagramme de cas d’utilisation La figure suivante nous présente de façon plus détaillée le cas d’utilisation « Gérer tickets ». Nous pouvons donc entrevoir plusieurs fonctions qui servent à construire le cycle de vie d’un ticket. Figure 13 : diagramme de cas d'utilisation « Gérer les tickets » Il est clair dans ce diagramme que : - Seul le superviseur qui peut supprimer un ticket - L’employé n’a la possibilité que de créer ou de consulter ces tickets
  • 35. SUPTECH 2014/2015 Page35  Description textuelle : Créer un ticket (Superviseur, Technicien, Employé) Créer un ticket Titre Créer un ticket Objectif Demander une intervention informatique Acteurs Superviseur, Technicien, Employé Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un nouveau ticket est ajouté Scénario nominal 1. L’utilisateur accède au menu « Ticket » 2. Le système affiche un formulaire de création d’un ticket 3. L’utilisateur remplit le formulaire 4. Le système valide les données saisies 5. Le système fait les mis à jour et indique que la demande est ajouté avec sucée Tableau 3 : Description textuelle du cas d’utilisation « Créer/Ouvrir un ticket »  Description textuelle : Fermer un ticket (Superviseur, Technicien) Fermer un ticket Titre Fermer un ticket Objectif Résoudre le problème informatique et fermer le ticket Acteurs Superviseur, Technicien Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un ticket est fermé Scénario nominal 1. L’utilisateur consulte son courrier électronique 2. L’utilisateur clique sur le lien disponible dans le message 3. Le système affiche les détails du ticket 4. L’utilisateur résout le problème informatique 5. L’utilisateur change l’état du ticket à « Résolu » et remplit le formulaire 6. Le système valide les données saisies 7. Le système fait les mis à jour et indique que les changements sont fait avec sucée 8. Le système envoie un SMS au demandeur indiquant que le problème est résolu Tableau 4 : Description textuelle du cas d’utilisation « Répondre/Fermer un ticket »
  • 36. SUPTECH 2014/2015 Page36  Description textuelle : Consulter un ticket (Superviseur, Technicien, Employé) Un employé ne peut afficher que les tickets qu’il a créé lui-même, tandis que le superviseur et les techniciens peuvent afficher n’importe quel ticket. Consulter un ticket Titre Consulter un ticket Objectif Afficher les détails d’un ticket Acteurs Superviseur, Technicien, Employé Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un ticket est affiché Scénario nominal 1. L’utilisateur consulte son courrier électronique 2. L’utilisateur clique sur le lien disponible dans le message 3. Le système affiche les détails du ticket 4. L’utilisateur résout le problème informatique 5. L’utilisateur change l’état du ticket à « Résolu » et remplit le formulaire 6. Le système valide les données saisies 7. Le système fait les mis à jour et indique que les changements sont fait avec sucée 8. Le système envoie un SMS au demandeur indiquant que le problème est résolu Tableau 5 : Description textuelle du cas d’utilisation « Consulter un ticket »  Description textuelle : Supprimer un ticket (Superviseur) Supprimer un compte utilisateur Titre Supprimer un ticket Objectif Supprimer un ticket de la liste Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un ticket est supprimé Scénario nominal 1. L’utilisateur accède au menu « Ticket »
  • 37. SUPTECH 2014/2015 Page37 2. L’utilisateur affiche la liste des tickets enregistrés 3. L’utilisateur demande de supprimer un ticket 4. Le système demande la confirmation de suppression 5. L’utilisateur confirme la suppression 6. Le système fait les mis à jour et indique que le ticket est supprimé avec sucée Tableau 6 : Description textuelle du cas d’utilisation « Supprimer un ticket » C. Raffinement du cas d’utilisation « Gérer l’inventaire »  Diagramme de cas d’utilisation Figure 14 : diagramme de cas d'utilisation « Gérer l’inventaire » Après l’authentification il’est possible pour le superviseur ou le technicien d’afficher la liste des imprimantes fonctionnelles ainsi que la listes des ordinateurs installés dans le parc informatique. Chaque ordinateur enregistré dans le système est identifié par ces caractéristiques : - Matériels (processeur, RAM,..) - Logiciels (OS, version,..) - Réseaux (IP, MAC, domaine,..)
  • 38. SUPTECH 2014/2015 Page38  Description textuelle : Consulter la liste des imprimantes (Superviseur, Technicien) Consulter la liste des imprimantes Titre Consulter la liste des imprimantes Objectif Afficher la liste des imprimantes disponibles dans le parc Acteurs Superviseur, Technicien Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié La liste des imprimant est affiché Scénario nominal 1. L’utilisateur accède au menu « Inventaire » 2. L’utilisateur choisit « Imprimantes » dans le menu 3. Le système affiche la liste des imprimantes disponibles dans le parc Tableau 7 : Description textuelle du cas d’utilisation «Consulter liste des imprimantes»  Description textuelle : Consulter la liste des ordinateurs (Superviseur, Technicien) Consulter la liste des ordinateurs Titre Consulter la liste des ordinateurs Objectif Afficher la liste des ordinateurs disponibles dans le parc Acteurs Superviseur, Technicien Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié La liste des ordinateurs est affichée Scénario nominal 1. L’utilisateur accède au menu « Inventaire » 2. L’utilisateur choisit « Ordinateurs » dans le menu 3. Le système affiche la liste des ordinateurs disponibles dans le parc Tableau 8 : Description textuelle du cas d’utilisation « Consulter liste des ordinateurs »  Description textuelle : Consulter la liste des logiciels (Superviseur, Technicien) Consulter la liste des logiciels Titre Consulter la liste des logiciels Objectif Afficher la liste des logiciels disponibles dans le parc Acteurs Superviseur, Technicien Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié La liste des logiciels est affichée Scénario nominal 1. L’utilisateur accède au menu « Inventaire » 2. L’utilisateur choisit « logiciels » dans le menu 3. Le système affiche la liste des imprimantes disponibles dans le parc Tableau 9 : Description textuelle du cas d’utilisation « Consulter liste des logiciels »
  • 39. SUPTECH 2014/2015 Page39 D. Raffinement du cas d’utilisation « Gérer les prêts téléphoniques »  Diagramme de cas d’utilisation Pour améliorer la communication entre les employés de l’entreprise et garantir la haute disponibilité des gens, YAZAKI met à la disposition de ces personnels des téléphones mobiles et des cartes SIM pré rechargés .Ces derniers sont données à titre de prêt et restent à la propriété de YAZAKI. Pour cela une solution informatique sera développé pour améliorer la gestion de cette tâche et facilite le suivie des équipements. Figure 15 : diagramme de cas d'utilisation « Gérer les prêts téléphoniques »
  • 40. SUPTECH 2014/2015 Page40 Gérer les téléphones mobiles  Description textuelle : Ajouter un téléphone (Superviseur, Technicien) Ajouter un téléphone Titre Ajouter un téléphone Objectif Ajouter un nouveau téléphoné dans la base Acteurs Superviseur, Technicien Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un nouvel appareil téléphonique est ajouté Scénario nominal 1. L’utilisateur accède au menu « Téléphones » 2. L’utilisateur choisit l’option « Ajouter téléphone » 2. Le système affiche un formulaire vide d’ajout d’un téléphone 3. L’utilisateur remplit le formulaire 4. Le système valide les données saisies 5. Le système fait les mis à jour et indique que le téléphone est ajouté avec sucée Tableau 10 : Description textuelle du cas d’utilisation « Ajouter un téléphone »  Description textuelle : Modifier un téléphone (Superviseur, Technicien) Modifier un téléphone Titre Modifier un téléphone Objectif Modifier un téléphone mobile Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un téléphone est modifié Scénario nominal 1. L’utilisateur accède au menu « Téléphones » 2. L’utilisateur affiche la liste des téléphones enregistrés 3. L’utilisateur demande de modifier un téléphone 4. Le système affiche un formulaire avec les données enregistrées 5. L’utilisateur modifie le formulaire 6. Le système valide les données saisies 7. Le système fait les mis à jour et indique que le téléphone est modifié avec sucée Tableau 11: Description textuelle du cas d’utilisation « Modifier un téléphone »
  • 41. SUPTECH 2014/2015 Page41  Description textuelle : Supprimer un téléphone (Superviseur, Technicien) Supprimer un téléphone Titre Supprimer un téléphone Objectif Supprimer un téléphone de la liste Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un téléphone est supprimé Scénario nominal 1. L’utilisateur accède au menu « Téléphone » 2. L’utilisateur affiche la liste des téléphones enregistrés 3. L’utilisateur demande de supprimer un téléphone 4. Le système demande la confirmation de suppression 5. L’utilisateur confirme la suppression 6. Le système fait les mis à jour et indique que le téléphone est supprimé avec sucée Tableau 12 : Description textuelle du cas d’utilisation « Supprimer un téléphone » Gérer les cartes SIM  Description textuelle : Ajouter une carte SIM (Superviseur, Technicien) Ajouter une carte SIM Titre Ajouter une carte SIM Objectif Ajouter une nouvelle carte SIM dans la base du système Acteurs Superviseur, Technicien Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un nouvelle carte SIM est ajouté Scénario nominal 1. L’utilisateur accède au menu « Téléphones » 2. L’utilisateur choisit l’option « Ajouter une carte SIM » 2. Le système affiche un formulaire vide d’ajout d’une carte SIM 3. L’utilisateur remplit le formulaire 4. Le système valide les données saisies 5. Le système fait les mis à jour et indique que la carte SIM est ajouté avec sucée Tableau 13 : Description textuelle du cas d’utilisation « Ajouter une carte SIM »
  • 42. SUPTECH 2014/2015 Page42  Description textuelle : Modifier une carte SIM (Superviseur, Technicien) Modifier une carte SIM Titre Modifier une carte SIM Objectif Mettre à jour une carte SIM Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Une carte SIM est modifiée Scénario nominal 1. L’utilisateur accède au menu « Téléphones » 2. L’utilisateur affiche la liste des cartes SIM enregistrés 3. L’utilisateur demande de modifier une carte SIM 4. Le système affiche un formulaire avec les données enregistrées 5. L’utilisateur modifie le formulaire 6. Le système valide les données saisies 7. Le système fait les mis à jour et indique que la carte SIM est modifié avec sucée Tableau 14 : Description textuelle du cas d’utilisation « Modifier une carte SIM »  Description textuelle : Supprimer une carte SIM (Superviseur, Technicien) Supprimer une carte SIM Titre Supprimer une carte SIM Objectif Supprimer une carte SIM de la liste Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Une carte SIM est supprimée Scénario nominal 1. L’utilisateur accède au menu « Téléphone » 2. L’utilisateur affiche la liste des cartes SIM enregistrés 3. L’utilisateur demande de supprimer une carte SIM 4. Le système demande la confirmation de suppression 5. L’utilisateur confirme la suppression 6. Le système fait les mis à jour et indique que la carte SIM est supprimé avec sucée Tableau 15 : Description textuelle du cas d’utilisation « Supprimer une carte SIM »
  • 43. SUPTECH 2014/2015 Page43 Gérer les transactions téléphoniques  Description textuelle : Ajouter un prêt (Superviseur, Technicien) L’ajout d’une opération de prêt téléphonique dans la base du système veut dire qu’on a assigner une appareil téléphonique et une carte SIM à un utilisateur qui va les exploiter pour une durée non déterminé. Ajouter un prêt Titre Ajouter une opération de prêt téléphonique Objectif Assigner un appareil téléphonique et une carte SIM à un utilisateur Acteurs Superviseur, Technicien Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un prêt téléphonique est ajouté Scénario nominal 1. L’utilisateur accède au menu « Téléphones » 2. L’utilisateur choisit l’option « Gestion des prêts » 3. Le système affiche un formulaire vide d’ajout d’une opération de prêt téléphonique 4. L’utilisateur remplit le formulaire 5. Le système valide les données saisies 6. Le système fait les mis à jour et indique que l’opération est ajouté avec sucée Tableau 16 : Description textuelle du cas d’utilisation « Ajouter un prêt »  Description textuelle : Modifier une opération de prêt (Superviseur, Technicien) Modifier une carte SIM Titre Modifier une opération de prêt Objectif Mettre à jour une opération de prêt pour un utilisateur donné Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Une opération de prêt est modifiée Scénario nominal 1. L’utilisateur accède au menu « Téléphones » 2. L’utilisateur choisit l’option « Gestion des prêts »
  • 44. SUPTECH 2014/2015 Page44 2. Le système affiche la liste de transactions enregistrées 3. L’utilisateur demande d’afficher les détails de l’opération 4. Le système affiche les détails de l’opération 5. L’utilisateur demande de modifier une transaction 6. Le système affiche un formulaire avec les données enregistrées 7. L’utilisateur modifie le formulaire 8. Le système valide les données saisies 9. Le système fait les mis à jour et indique que la transaction est modifié avec sucée Tableau 17 : Description textuelle du cas d’utilisation « Modifier une opération de prêt »  Description textuelle : Supprimer une opération de prêt (Superviseur, Technicien) Supprimer une opération de prêt Titre Supprimer une opération de prêt Objectif Supprimer une opération de prêt de la liste Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Une opération téléphonique est supprimée Scénario nominal 1. L’utilisateur accède au menu « Téléphone » 2. L’utilisateur choisit l’option « Gestion des prêts » 4. Le système affiche la liste de transactions enregistrées 5. L’utilisateur demande de supprimer une transaction 4. Le système demande la confirmation de suppression 5. L’utilisateur confirme la suppression 6. Le système fait les mis à jour et indique que la transaction est supprimé avec sucée Tableau 18 : Description textuelle du cas d’utilisation « Supprimer une transaction »
  • 45. SUPTECH 2014/2015 Page45  Description textuelle : Récupérer le téléphone mobile et la carte SIM Récupérer le téléphone et la carte SIM Titre Récupérer le téléphone et la carte SIM Objectif Récupérer le téléphone et la carte SIM Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Téléphone et SIM récupérer Scénario nominal 1. L’utilisateur accède au menu « Téléphone » 2. L’utilisateur choisit l’option « Gestion des prêts » 3. Le système affiche la liste de transactions enregistrées 4. L’utilisateur demande d’afficher les détails du prêt pour un utilisateur donné 5. Le système affiche les détails 6. L’utilisateur demande de faire une opération de récupération 7. Le système affiche le formulaire pré-remplit 8. L’utilisateur confirme la récupération 9. Le système fait les mis à jour et indique que la récupération est effectué avec sucée Tableau 19 : Description textuelle du cas d’utilisation « Récupérer téléphone & SIM »
  • 46. SUPTECH 2014/2015 Page46 6. Diagramme du cas d’utilisation global Figure 16 : Diagramme de cas d’utilisation globale
  • 47. SUPTECH 2014/2015 Page47 II. Conception La conception est une étape primordiale pour la réalisation d’un produit informatique. Dans cette étape nous allons spécifiés les cas d’utilisation les plus prioritaires d’une manière détaillé afin d’organiser le système et de décrire leur fonctionnement. Nous allons utiliser le diagramme de classe et le diagramme de séquence en vue de présenter le comportement statique et dynamique de notre modèle : le diagramme de classe exprime d’une manière générale la structure statique d’un système, en termes de classes et de relation entre classes et le diagramme de séquence illustre d’une manière dynamique le scénario de réalisation des fonctions du système. 1. Diagramme de classe « gestion de parc informatique » Figure 17 : Diagramme de classe du système
  • 48. SUPTECH 2014/2015 Page48 2. Diagramme de séquence du cas d’utilisation « S’authentifier » Figure 18 : Diagramme de séquence « Authentification » La figure ci-dessus présente le scénario d’authentification pour le cas d’utilisation « s’authentifier », donc pour accéder au système il faut tout d’abord saisi le login et le mot de passe dans l’interface de l’utilisateur, après la validation des paramètres d’accès, l’utilisateur accède au système.
  • 49. SUPTECH 2014/2015 Page49 3. Diagramme de séquence du cas d’utilisation « Gérer les tickets » A. Diagramme de séquence « Créer un ticket » La figure suivante nous présente de façon détaillée le diagramme de séquence « Créer un tickets ». Nous pouvons donc entrevoir que par des simples clicks l’employé administratif peut construire une demande d’intervention qui sera envoyé automatiquement par mail et par SMS. Figure 19 : Diagramme de séquence « Créer un ticket »
  • 50. SUPTECH 2014/2015 Page50 B. Diagramme d’activité « Créer un ticket » Figure 20 : Diagramme d’activité « Créer un ticket »
  • 51. SUPTECH 2014/2015 Page51 C. Diagramme de séquence « Modifier un ticket » La modification d’un ticket revient à modifier son état de « En cours » à « Résolu », le cycle de vie d’un ticket prend son fin lorsque le technicien ou le superviseur vient de résoudre le problème informatique en liaison avec ce ticket. Comme indique le diagramme de séquence ci-après, le formulaire de modification d’un ticket est accessible via boite de réception du compte mail du technicien/superviseur ou directement via l’interface Web sous le menu « Ticket ».
  • 52. SUPTECH 2014/2015 Page52 Figure 21 : Diagramme de séquence « Modifier un ticket »
  • 53. SUPTECH 2014/2015 Page53 D. Diagramme de séquence « Supprimer un ticket » Pour des raisons de traçabilités et de statistique les tickets ne doivent pas être supprimés que par le superviseur du système, on évite dans ce cas que le technicien ignore une demande d’intervention ou la supprime de la base des données. Figure 22 : Diagramme de séquence « Supprimer un ticket »
  • 54. SUPTECH 2014/2015 Page54 E. Diagramme de séquence détaillé « Envoi SMS par l’application Android » L’application Android permet d’envoyer un SMS à chaque création d’un nouveau ticket, pour le faire le système doit comparer d’une façon périodique la date du dernier ticket enregistré dans la base avec une valeur initialement récupérer lors de démarrage de l’application. L’envoi de l’SMS se déclenche lorsque la dernière date récupérer est supérieur à la date initiale ,ce qui signifie qu’un nouveau ticket vient de se créer, ainsi la valeur initiale est remplacé en mémoire du système par la dernière valeur lu et le processus continue. Figure 23 : Diagramme de séquence détaillé de « l’envoi SMS par Android »
  • 55. SUPTECH 2014/2015 Page55 4. Diagramme de séquence de cas d’utilisation « Gérer l’inventaire » A. Diagramme de séquence « Créer un inventaire » avec Agent Inventory Agent Inventory est une application native qui permet de donner des informations sur des ressources physiques se trouvant dans les différentes machines du parc, la communication avec le serveur d’application se fait via le protocole http et la solution adoptée est basé sur les services Web. Les ressources inventoriées sont : - Les caractéristiques des ordinateurs (MAC, IP, Processeur, RAM, OS,..) - Les imprimantes installées sur les PC - Les logiciels installés sur les PC. Figure 24 : Diagramme de séquence « Créer un inventaire »
  • 56. SUPTECH 2014/2015 Page56 B. Diagramme de séquence « Consulter détails de l’inventaire » Figure 25 : Diagramme de séquence « Consulter détails de l’inventaire »
  • 57. SUPTECH 2014/2015 Page57 5. Diagramme de séquence « Gérer les prêts téléphoniques » Cette conception concerne les sous-modules -suivants : - Gérer les cartes SIM - Gérer les téléphones mobiles - Gérer les phones users - Gérer les opérations de prêts Ces sous-modules concernent quatre fonctionnalités à savoir l’ajout, la modification, la suppression et la consultation, le troisième module nécessite un module complémentaire qui est le module « Récupérer mobile et carte SIM ».
  • 58. SUPTECH 2014/2015 Page58 A. Diagramme de séquence « Gérer les cartes SIM » Figure 26 : Diagramme de séquence « Gérer les cartes SIM »
  • 59. SUPTECH 2014/2015 Page59 B. Diagramme de séquence « Gérer les téléphones mobiles » Figure 27 : Diagramme de séquence « Gérer les téléphones mobiles »
  • 60. SUPTECH 2014/2015 Page60 C. Diagramme de séquence « Gérer les utilisateurs des téléphones » Figure 28 : Diagramme de séquence « Gérer les utilisateurs des téléphones»
  • 61. SUPTECH 2014/2015 Page61 D. Diagramme de séquence « Gérer les opérations de prêts » Figure 29 : Diagramme de séquence « Gérer les opérations de prêts »
  • 62. SUPTECH 2014/2015 Page62 E. Diagramme de séquence « Télécharger la décharge téléphonique en PDF» Figure 30 : Diagramme de séquence « Télécharger la décharge en PDF » III. Elaboration des prototypes des interfaces utilisateurs 1. Prototype de l’interface « Authentification » Il très important de noter que chaque opération ne peut être réalisée qu’après authentification. Seul le Superviseur qui se charge de définir les login et mot de passe de chaque employé alors qu’un employé pour modifier la tienne. Au lancement de l’application, la fenêtre d’authentification s’affiche automatiquement, elle permet à l’utilisateur de se connecter. S’il y a des problèmes lors de la connexion, un message d’erreur est affiché.
  • 63. SUPTECH 2014/2015 Page63 Voilà la figure suivante qui présente l’interface d’authentification : Figure 31 : Interface d’authentification 2. Prototype de l’interface « Créer ticket » Figure 32 : Interface d’ajout d’une nouvelle demande d’intervention
  • 64. SUPTECH 2014/2015 Page64 La figure ci-dessous montre un exemple d’un ticket reçu avec Microsoft Outlook, ce système de messagerie est celui utilisé par l’ensemble des employés dans notre société YAZAKI. Figure 33 : Interface de ticket reçu avec Microsoft Outlook La figure ci-dessous montre un exemple d’un ticket reçu par SMS, dans le téléphone d’un technicien informatique, le nombre maximum des caractères standard dans un SMS est de 160 caractères. Figure 34 : Interface de ticket reçu par SMS
  • 65. SUPTECH 2014/2015 Page65 Figure 35 : Interface de l’application Android 3. Prototype de l’interface « Gérer inventaire » La figure ci-dessous montre une liste des ordinateurs inventoriés par AgentInventory, l’utilisateur (Superviseur, technicien) peut afficher les détails d’un ordinateur ou bien le supprimer de la liste. Figure 36 : Interface des listes des ordinateurs inventoriés
  • 66. SUPTECH 2014/2015 Page66 4. Prototype de l’interface « Gérer les prêts téléphoniques » Pour ajouter un prêt téléphonique le superviseur ou le technicien doit accèdera au menu « Gestion des prêts » , trois listes sont affichés il contiennent respectivement une liste de tous les utilisateurs téléphonique ,une deuxième pour les appareils téléphonique et une troisième pour les cartes SIM. Il suffit de faire trois cliques dans chaque liste pour créer un formulaire remplit avec tous les détails d’un prêt téléphonique. Il reste de poster le formulaire et télécharger la décharge téléphonique en format PDF pour impression. Figure 37 : Interface d’ajout d’un nouveau prêt téléphonique
  • 67. SUPTECH 2014/2015 Page67 5. Prototype de l’interface « Imprimer la décharge téléphonique » Figure 38 : Interface exemple d’une décharge téléphonique en PDF
  • 68. SUPTECH 2014/2015 Page68 Conclusion Nous avons consacré cette phase pour l’identification des besoins du système ainsi que ses exigence qui nous ont permis de passer à la phase suivante « Phase d’élaboration »,ou nous allons entamer des nouveaux besoins et traiter les cas d’utilisation de priorité « 2 ».
  • 70. SUPTECH 2014/2015 Page70 Chapitre 4 Phase élaboration Introduction Après avoir compris notre système et dégager les fonctionnalités de bases, en passe à la deuxième phase de notre processus, phase d’élaboration. Dans cette partie, nous allons capturer les nouveaux besoins, analyser et concevoir les nouveaux cas d’utilisations afin d’implémenter et de tester ces derniers. I. Identification des besoins 1. Raffinement des cas d’utilisation de priorité « 2 » Dans cette partie nous allons traiter les cas d’utilisations de priorité « 2 » - Gérer les comptes - Afficher les statistiques - Gérer les catégories des problèmes informatiques A. Raffinement de cas d’utilisation « Gérer les comptes »  Diagramme de cas d’utilisation Figure 39 : diagramme de cas d'utilisation « Gérer les comptes »
  • 71. SUPTECH 2014/2015 Page71 Le lancement d’une nouvelle procédure de création d’un compte utilisateur ainsi que les opérations de suppression et de modification ne sont disponibles que par le responsable informatique par contre certaines donnés peuvent être modifiés par l’employé administratif tel que le cas de changement de son mot de passe.  Description textuelle : Créer un compte utilisateur (Superviseur) Créer un compte utilisateur Titre Créer un compte Objectif Donner accès au système Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un nouveau compte est ajouté Scénario nominal 1. L’utilisateur accède au menu « Compte » 2. Le système affiche un formulaire de création d’un compte 3. L’utilisateur remplit le formulaire 4. Le système valide les données saisies 5. Le système fait les mis à jour et indique que la demande est ajouté avec sucée Tableau 20 : Description textuelle du cas d’utilisation « Créer un nouveau compte »  Description textuelle : modifier un compte utilisateur (Superviseur) Modifier un compte utilisateur Titre Modifier un compte Objectif Modifier un profil utilisateur Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un profil utilisateur est modifié Scénario nominal 1. L’utilisateur accède au menu « Compte » 2. L’utilisateur affiche la liste des comptes des utilisateurs enregistrés 3. L’utilisateur demande de modifier un compte
  • 72. SUPTECH 2014/2015 Page72 4. Le système affiche un formulaire avec les données enregistrés 5. L’utilisateur modifie le formulaire 6. Le système valide les données saisies 7. Le système fait les mis à jour et indique que la demande est modifié avec sucée Tableau 21 : Description textuelle du cas d’utilisation « Modifier un compte »  Description textuelle : supprimer un compte utilisateur (Superviseur) Supprimer un compte utilisateur Titre Supprimer un compte Objectif Supprimer un compte utilisateur Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Un compte utilisateur est supprimé Scénario nominal 1. L’utilisateur accède au menu « Compte » 2. L’utilisateur affiche la liste des comptes des utilisateurs enregistrés 3. L’utilisateur demande de supprimer un compte 4. Le système demande la confirmation de suppression 5. L’utilisateur confirme la suppression 6. Le système fait les mis à jour et indique que la demande est supprimé avec sucée Tableau 22 : Description textuelle du cas d’utilisation « Supprimer un compte »
  • 73. SUPTECH 2014/2015 Page73 B. Raffinement du cas d’utilisation « Afficher les statistiques» Après authentification le superviseur et les techniciens auront la possibilité de consulter tous les statistiques du système, ces statistiques comprennent : - Statistiques par systèmes d’exploitation - Statistiques par domaine ou groupe de travail - Statistiques par techniciens informatiques - Statistiques par tickets - Statistiques par catégorie de problèmes  Diagramme de cas d’utilisation Figure 40 : diagramme de cas d'utilisation « Afficher les statistiques »
  • 74. SUPTECH 2014/2015 Page74  Description textuelle : Afficher les statistiques Afficher les statistiques Titre Afficher les statistiques Objectif Afficher les différents types des statistiques Acteurs Superviseur, Technicien informatiques Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Des statistiques sont affichés Scénario nominal 1. L’utilisateur accède au menu « Statistiques » 2. Le système affiche les statistiques Figure 41 : Description textuelle du cas d’utilisation « Afficher les statistiques »
  • 75. SUPTECH 2014/2015 Page75 C. Raffinement de cas d’utilisation « Gérer les catégories des problèmes informatiques»  Diagramme de cas d’utilisation Figure 42 : diagramme de cas d'utilisation « Gérer les catégories »  Description textuelle : Ajouter une catégorie (Superviseur) Ajouter une catégorie Titre Ajouter une catégorie Objectif Ajouter une catégorie aux listes des problèmes informatique Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Une catégorie est ajoutée Scénario nominal 1. L’utilisateur accède au menu « Catégorie des problèmes » 2. Le système affiche un formulaire de création d’une catégorie 3. L’utilisateur remplit le formulaire 4. Le système valide les données saisies 5. Le système fait les mis à jour et indique que la catégorie est ajouté avec sucée Tableau 23 : diagramme de cas d'utilisation « Ajouter une catégorie »
  • 76. SUPTECH 2014/2015 Page76  Description textuelle : Modifier une catégorie (Superviseur) Modifier une catégorie Titre Modifier une catégorie Objectif Modifier une de problèmes informatique Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Une catégorie est modifiée Scénario nominal 1. L’utilisateur accède au menu « Catégorie des problèmes » 2. Le système affiche la liste des catégories 3. L’utilisateur choisit une catégorie à modifier 4. Le système affiche un formulaire pré-remplit de la catégorie choisit 5. L’utilisateur modifie le formulaire 6. Le système valide les données saisies 7. L’utilisateur poste le formulaire 8. Le système fait les mis à jour et indique que la catégorie est modifié avec sucée Tableau 24 : diagramme de cas d'utilisation « Modifier une catégorie »  Description textuelle : supprimer une catégorie (Superviseur) Supprimer une catégorie Titre Supprimer une catégorie Objectif Supprimer une catégorie de liste des problèmes Acteurs Superviseur/Responsable informatique Description des enchainements Pré-condition Post-condition L’utilisateur doit être authentifié Une catégorie est supprimée Scénario nominal 1. L’utilisateur accède au menu « Catégorie des problèmes » 2. Le système affiche la liste des catégories 3. L’utilisateur choisit une catégorie à supprimer 4. L’utilisateur demande de supprimer une catégorie 5. Le système demande la confirmation de suppression 6. L’utilisateur confirme la suppression 7. Le système fait les mis à jour et indique que la catégorie est supprimé avec sucée Tableau 25 : Description textuelle du cas d’utilisation « Supprimer une catégorie »
  • 77. SUPTECH 2014/2015 Page77 2. Cas d’utilisation global de la deuxième phase Figure 43 : diagramme de cas d'utilisation global du 2éme phase
  • 78. SUPTECH 2014/2015 Page78 II. Conception 1. Diagramme de classe Figure 44 : diagramme de classe de priorité « 2 » 2. Diagramme de séquence de cas d’utilisation« Gérer les comptes » Pour ajouter, modifier et supprimer un utilisateur, le Superviseur accède à l’interface « Gestion des comptes », là où il peut faire ses opérations.
  • 79. SUPTECH 2014/2015 Page79 Voilà le diagramme de séquence ci-dessous qui illustre le scénario : Figure 45 : Diagramme de séquence « Gérer les comptes »
  • 80. SUPTECH 2014/2015 Page80 3. Diagramme de séquence de cas d’utilisation « Afficher les statistiques » Figure 46 : Diagramme de séquence « Gérer les catégories » 4. Diagramme de séquence de cas d’utilisation« Gérer les catégories » Chaque catégorie d’un problème est assigné à un technicien informatique ainsi lorsque un employé lance une demande d’intervention un ticket sera ouvert et envoyé automatiquement au technicien concerné. Le diagramme de séquence ci-après illustre le scenario de gestion des catégories.
  • 81. SUPTECH 2014/2015 Page81 Figure 47 : Diagramme de séquence « Gérer les catégories »
  • 82. SUPTECH 2014/2015 Page82 II. Elaboration de quelques prototypes des interfaces utilisateurs 1. Prototype de l’interface « Gérer comptes » Pour ajouter, modifier ou supprimer des comptes utilisateurs, il est nécessaire au superviseur de passer à l’interface de gestion des comptes comme illustre la figure suivante : Figure 48: interface « Gestion des comptes »
  • 83. SUPTECH 2014/2015 Page83 2. Prototype de l’interface « Afficher les statistiques » Pour consulter l’état global du parc informatique, il est nécessaire aux utilisateurs concernés d’accéder à la page des statistiques [11] du système comme illustre les deux figures ci-dessous. Les statistiques comprennent : - Statistiques par systèmes d’exploitation - Statistiques par domaine ou groupe de travail - Statistiques par rendement des techniciens (nombre des tickets fermés par chaque technicien par rapport à la totalité des tickets ouverts) - Statistiques par tickets ouverts et fermés - Statistiques par catégorie des problèmes Figure 49 : Interface Consulter les statistiques systèmes (1)
  • 84. SUPTECH 2014/2015 Page84 Figure 50 : Interface Consulter les statistiques systèmes (2)
  • 85. SUPTECH 2014/2015 Page85 3. Prototype de l’interface « Gérer les catégories des problèmes» Pour assigné une catégorie à un technicien informatique ou bien ajouter, modifier ou supprimer des catégories, il est nécessaire au superviseur de passer à l’interface de gestion des comptes comme illustre la figure suivante : Figure 51: interface « Gestion des catégories » Conclusion Dans cette partie, nous avons concentré sur l’identification des besoins du système ainsi que ses exigences qui ont permis de passer à la phase suivante « Phase construction » ou nous allons entamer des nouveaux besoins et traiter les cas d’utilisation de priorité « 3 ».
  • 87. SUPTECH 2014/2015 Page87 Chapitre 5 Phase construction Introduction Après avoir réalisés la plus part des cas d’utilisation dans les parties précédente, nous allons passer maintenant à la troisième phase « la phase construction ». Dans cette partie, nous avons capturés le reste des cas d’utilisation en continuant leurs analyses et conceptions afin de finaliser l’implémentation de notre produit. A la fin de cette phase, nous allons avoir une version exécutable du produit. I. Identification des besoins 1. Raffinement des cas d’utilisation de priorité « 3 » Dans cette partie nous allons traiter les cas d’utilisations de priorité « 3 » - Gérer les départements - Consulter les fichiers logs A. Raffinement du cas d’utilisation « Gérer les départements »  Diagramme de cas d’utilisation Figure 52 : diagramme de cas d’utilisation« Gestion des départements »