Rapport de pfe gestion de parc informatique et Helpdesk

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
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
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 »
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é
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
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
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é
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
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
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 »
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
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
L’utilisateur doit être authentifié La liste des ordinateurs est affichée
Scénario nominal
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
L’utilisateur doit être authentifié La liste des logiciels est affichée
Scénario nominal
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 »
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
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
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
L’utilisateur doit être authentifié Un téléphone est modifié
Scénario nominal
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
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
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
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
L’utilisateur doit être authentifié Un nouvelle carte SIM est ajouté
Scénario nominal
2. L’utilisateur choisit l’option « Ajouter une carte SIM »
2. Le système affiche un formulaire vide d’ajout d’une carte SIM
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
L’utilisateur doit être authentifié Une carte SIM est modifiée
Scénario nominal
2. L’utilisateur affiche la liste des cartes SIM enregistrés
3. L’utilisateur demande de modifier une carte SIM
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
L’utilisateur doit être authentifié Une carte SIM est supprimée
Scénario nominal
2. L’utilisateur affiche la liste des cartes SIM enregistrés
3. L’utilisateur demande de supprimer une carte SIM
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
L’utilisateur doit être authentifié Un prêt téléphonique est ajouté
Scénario nominal
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
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é
L’utilisateur doit être authentifié Une opération de prêt est modifiée
Scénario nominal

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
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
L’utilisateur doit être authentifié Une opération téléphonique est supprimée
Scénario nominal
5. L’utilisateur demande de supprimer une transaction
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
L’utilisateur doit être authentifié Téléphone et SIM récupérer
Scénario nominal
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.
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 »
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
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
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
L’utilisateur doit être authentifié Un profil utilisateur est modifié
Scénario nominal
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
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)
Titre Supprimer un compte
Objectif Supprimer un compte utilisateur
L’utilisateur doit être authentifié Un compte utilisateur est supprimé
Scénario nominal
2. L’utilisateur affiche la liste des comptes des utilisateurs enregistrés
3. L’utilisateur demande de supprimer un compte
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
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
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»
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
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
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
L’utilisateur doit être authentifié Une catégorie est modifiée
Scénario nominal
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
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
L’utilisateur doit être authentifié Une catégorie est supprimée
Scénario nominal
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
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.
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 »
Figure 52 : diagramme de cas d’utilisation« Gestion des départements »

SUPTECH
2014/2015
Page88
 Description textuelle : Ajouter un département (Superviseur)
Ajouter un département
Titre Ajouter un département
Objectif Ajouter un département
L’utilisateur doit être authentifié Un département est ajouté
Scénario nominal
1. L’utilisateur accède au menu « Département »
2. Le système affiche un formulaire de création d’un nouveau département
5. Le système fait les mis à jour et indique que le département est ajouté avec sucée
Tableau 26 : Description textuelle du cas d’utilisation « Ajouter un département »
 Description textuelle : modifier un département (Superviseur)
Modifier un compte utilisateur
Titre Modifier un département
Objectif Modifier un département
L’utilisateur doit être authentifié Un département est modifié
Scénario nominal
2. L’utilisateur affiche la liste des départements enregistrés
3. L’utilisateur demande de modifier un département
7. Le système fait les mis à jour et indique que le département est modifié avec sucée
Tableau 27 : Description textuelle du cas d’utilisation « Modifier un département »

SUPTECH
2014/2015
Page89
 Description textuelle : supprimer un département (Superviseur)
Titre Supprimer un département
Objectif Supprimer un département
L’utilisateur doit être authentifié Un département est supprimé
Scénario nominal
2. L’utilisateur affiche la liste des départements enregistrés
3. L’utilisateur demande de supprimer un département
6. Le système fait les mis à jour et indique que le département est supprimé avec sucée
Tableau 28 : Description textuelle du cas d’utilisation « Supprimer un département »
B. Raffinement du cas d’utilisation « Consulter les fichiers logs »
Figure 53 : diagramme de cas d’utilisation« Gérer l’historique »

SUPTECH
2014/2015
Page90
 Description textuelle : Consulter Historique (Superviseur)
Consulter l’historique
Titre Consulter l’historique
Objectif Consulter l’historique
L’utilisateur doit être authentifié Un fichier log est affiché
Scénario nominal
1. L’utilisateur accède au menu « Historiques »
2. Le système affiche l’historique des accès au système /transactions téléphoniques
Tableau 29 : Description textuelle du cas d’utilisation « Consulter l’historique »
 Description textuelle : Télécharger fichier log (Superviseur)
Télécharger l’historique
Titre Télécharger l’historique
Objectif Télécharger l’historique
L’utilisateur doit être authentifié Un fichier log est téléchargé
Scénario nominal
1. L’utilisateur accède au menu « Historiques »
2. Le système affiche l’historique des accès au système /transactions téléphoniques
3. L’utilisateur clique sur l’icône de téléchargement
4. Le système génère un fichier texte contenant l’historique
Tableau 30 : Description textuelle du cas d’utilisation « Télécharger fichier log »

SUPTECH
2014/2015
Page91
2. Cas d’utilisation globale de la troisième phase
Figure 54 : diagramme de cas d’utilisation globale du 3éme phase

SUPTECH
2014/2015
Page92
III. Conception
1. Diagramme de séquence du cas d’utilisation « Gérer les départements »
Figure 55 : Diagramme de séquence « Gérer les départements »

SUPTECH
2014/2015
Page93
2. Diagramme de séquence du cas d’utilisation « Gérer l’historique »
Toutes les opérations effectuées au cours de la navigation d’un utilisateur sur le système sont
enregistrés, le superviseur possède la possibilité de consulter l’historique des navigations des
membres et de télécharger le fichier log sur son poste local.
L’historique enregistré comprend :
- L’historique des accès aux systèmes
- L’historique des opérations des prêts téléphoniques
Voilà le diagramme de séquence ci-dessous qui illustre le scénario :
Figure 56 : Diagramme de séquence « Gérer l’historique »

SUPTECH
2014/2015
Page94
3. Diagramme de classe globale
Figure 57 : Diagramme de classe globale
 Description des classes
Société : Cette classe enregistre les coordonnées de YAZAKI. Elle contient les attributs suivants :
numéro (id), numéro téléphone (phone), fax (fax), site Web (webSite), e-mail (mail), adresse
(adresse), pays (country).
Département : Cette classe contient la listes des départements de la société YAZAKI, les
attributs sont : id, nom, société (id_societe).
Utilisateur : Cette classe organise les utilisateurs de l’application. Elle contient les attributs
suivants : id, nom, prénom, login, mot de passe (password), email (mail), numéro téléphone
(phone), position, département (id_departement).

SUPTECH
2014/2015
Page95
Tickets : Cette classe organise l’ensemble des tickets créé par les utilisateurs, elle contient les
attributs suivant : id ,titre ,description ,demandeur (requester) ,date d’ouverture
(openinig_date) ,date de fermeture (closing_date) ,état du ticket (state),priorité catégorie du
ticket (priority).
Ordinateurs : Cette classe organise l’ensemble des ordinateurs dans le parc , elle contient les
attributs suivant : id ,nom ,type ,modèle ,système (os) ,processeur , IP ,MAC.
Softwares : Cette classe organise l’ensemble des logiciels installés par ordinateurs, elle
contient les attributs suivant : id, nom, type, ordinateur (id_ordinateur).
Imprimantes : Cette classe organise l’ensemble des imprimantes installés dans les
ordinateurs du parc informatique, elle contient les attributs suivant : id, nom, ordinateur
(id_ordinateur), version, licence.
SIM : Cette classe organise l’ensemble des carte SIM enregistré dans la base, elle contient les
attributs suivant : id, numéro, PIN (pin) , PUK (puk) ,opérateur téléphonique (operateur)
,montant ,limitation.
Phone : Cette classe organise l’ensemble des appareils téléphonique enregistré dans la base,
elle contient les attributs suivant : id, marque, modèle (modele), IMEI (imei),couleur.
Prêts téléphoniques : Cette classe organise l’ensemble des opérations des prêts téléphoniques
enregistré dans la base, elle contient les attributs suivant : id, utilisateur (id_user), téléphone
(id_phone), carte sim (id_sim), date, description.
Catégories des problèmes : Cette classe organise l’ensemble des catégories des problèmes
informatiques qui peuvent se produire dans le parc, elle contient les attributs suivant : id, nom
du catégorie (nom), le technicien en charge (id_utilisateur).
Historique : Cette classe organise l’ensemble des transactions téléphoniques enregistré dans
la base, elle contient les attributs suivant : id, description, date.
Statistiques : Cette classe organise l’ensemble des statistiques disponible par l’application
,elle contient les attributs suivants : id, description et la valeur (val).

SUPTECH
2014/2015
Page96
4. La base des données de l’application
La Figure 58 représente les tables utilisées dans notre base des données.
Figure 58 : Schéma de la base des données

SUPTECH
2014/2015
Page97
IV. Elaboration de quelques prototypes des interfaces utilisateurs
1. Prototype de l’interface « Gérer les départements »
Pour ajouter, modifier ou supprimer un département, il est nécessaire au Responsable
Informatique de passer à l’interface de gestion des départements comme illustre la figure
suivante :
Figure 59 : Interface « Gérer les départements

SUPTECH
2014/2015
Page98
2. Prototype de l’interface « Consulter/Télécharger fichier log »
Pour consulter ou bien télécharger l’historique des opérations des prêts téléphoniques, il est
nécessaire au Responsable Informatique de passer à l’interface d’historique des transactions
téléphoniques comme illustre la figure suivante :
Figure 60 : Interface « Historiques des transactions téléphoniques »
Conclusion
A ce niveau notre application est terminée, il reste d’élaborer un manuel utilisateur que nous
allons le présenter dans le chapitre suivant.

SUPTECH
2014/2015
Page99
Chapitre VI. Phase transition

SUPTECH
2014/2015
Page100
Chapitre 6
Phase transition
Introduction
Il s’agit dans cette partie qui est la dernière phase de processus unifié de vérifier si le système
offre véritablement les services exigés par les utilisateurs et de détecté les parties là où il y a
des défaillances. Cette partie présente initialement l’architecture de notre produit.
I. Architecture logicielle du système
Aujourd'hui, les logiciels « Change On Demande» sont devenus très populaires, les besoins
changent vite et il faut s'adapter le plus rapidement possible. De nombreux producteurs de
logiciels, proposent dorénavant une solution évolutive. Une des approches pour réaliser ce
genre de produit est une Architecture Orientée Services.
Celle-ci est devenue très répandue avec l'explosion des Services Web.
Cette approche consiste à diviser le logiciel répondant à un problème, en un ensemble
d'entités proposant des services. Chacune de ces entités peut utiliser les services proposés par
d'autres entités. Nous obtenons ainsi un réseau de services interagissant entre eux. Cette
architecture s'appuie sur une architecture à composants.
Figure 61 : Modèle générale de l’architecture orienté service
J’ai découpé mon application logicielle en plusieurs couches logiques. Cette architecture
permet de créer de manière incrémentale de nouvelles fonctions, de les combiner aux services
existants pour créer des applications composites tout en garantissant un bon niveau de
maintenance et de flexibilité et elle répond ainsi aux caractéristiques tracées pour notre outil.

SUPTECH
2014/2015
Page101
D'où le schéma récapitulatif suivant :
Figure 62 : Les couches de l’application
 Couche Présentation :
Elle implémente la logique présentation de l’application. La couche présentation est liée au
type de client utilisé.
Dans notre cas nous avons trois types de client :
- Client Leger (Web HTML, Java Script, CSS) : c’est le client principale du notre
système représenté par une application web de gestion du parc informatiques en tant
que matériels et logiciels et de gestion des interventions.
- Client .Net représenté par l’application AgentInventory ceci est une application
exécutable chargé de collecter les données en relation avec les ressources des
machines clients et les stocker dans la base de données via le protocole SOAP
[7](HTTP+XML) .
- Client Androide [9]: c’est une application mobile qui se communique avec les
composants Web Services en utilisant le protocole SOAP [8], son rôle est de détecter
les nouveaux tickets créer par les utilisateurs et d’envoyer des SMS au techniciens
informatiques afin de les alerter en cas de problèmes informatiques qui peuvent se
produiser dans le parc.

SUPTECH
2014/2015
Page102
 Couche Web :
Elle utilise les composants web Servlet et JSP , elle sert de médiateur entre la couche
présentation et la couche métier. Son rôle est de :
- recevoir les requêtes http clientes
- Vérifier les autorisations d’accès de chaque session
- Assure la validation des données envoyées par le client
- Fait appel au composant métier pour assurer les traitements nécessaires
- Génère une vue qui sera envoyée à la couche présentation.
 Couche Métier :
Cette couche comporte les différents paquetages métier du système. Ces paquetages sont
appelés par les composants de la couche Web pour répondre aux requêtes des utilisateurs.
 Couche de données
La couche donnée est assurée par une base de données relationnelle (MySQL), les échanges
entre le serveur d’applications et le serveur de base de données se fait au moyen du
protocole ODBC de Microsoft.
II. Environnement de réalisation
Dans cette partie avons présentés l’environnement matériel et logiciel de la réalisation de notre
projet.
1. Environnement matériel
L’application a été développée sur un ordinateur portable avec les caractéristiques suivantes :
Marque Lenovo T440
Processeur Intel(R) Core(TM) i5-3550 CPU @ 3.30GHz
Mémoire vive 8Go
Disque dur 160Go
Système d’exploitation Windows7
Tableau 31 : Caractéristique poste de travail

SUPTECH
2014/2015
Page103
2. Environnement logiciel
Lors de développement de notre application, nous avons exploité plusieurs technologies et
logiciels, ça ce qu’on va présenter dans cette partie.
Outil Description
Eclipse Luna Environnement de Travail Intégré (IDE)
Eclipse ADT Environnement de Travail avec des outils de développement pour Androïde
Visual Basic 2010
Est un IDE communautaire gratuit et complet pour développer des
applications Web, Windows Store, Windows Desktop, et même Androïde et
iOS en utilisant des langages de programmation dont C #, C ++ , HTML /
JavaScript et Visual Basic .
UltiDev Est un outil utilisé pour l'hébergement des services web
XAMP
XAMPP est un ensemble de logiciels permettant de mettre en place
facilement un serveur Web confidentiel, un serveur FTP et un serveur de
messagerie électronique
Star UML
Est un logiciel permettant aux programmeurs de mettre en place des
diagrammes UML.
Tableau 32 : Environnement logiciel
III. Mise en place de l’application
1. Interface « Authentification »
Figure 63 : interface « authentification »
Cette interface permet à chaque utilisateur de se connecter à travers un login et un mot de
passe.
 Si le Superviseur est connecté : tout le menu affiché.
 Si le Technicien informatique est connecté, selon les droits d’accès qui lui sont
attribués, il peut effectuer des tâches bien déterminées.

SUPTECH
2014/2015
Page104
 Si un Simple utilisateur est connecté, seule l’interface de création des tickets est
affichée.
2. Interface « Liste des tickets ouverts »
La consultation des tickets ouverts se réalise à partir du menu « Liste des tickets ouverts », se
sont les tickets qui ne sont pas encore traiter par les techniciens informatiques.
Figure 64 : interface « liste des tickets ouverts»

SUPTECH
2014/2015
Page105
3. Interface « Les détails d’un ticket »
Figure 65 : interface « les détails d’un tickets»
4. Interface « Les détails d’un ordinateur inventorié»
Figure 66 : interface « les détails d’un ordinateur»

SUPTECH
2014/2015
Page106
5. Interface « Liste des logiciels installés dans un ordinateur »
Ci-dessous un exemple de la liste des logiciels installés dans l’ordinateur YAPTPCA366
Figure 67 : interface « liste des logiciels installés dans un ordinateur»
6. Interface « Liste des imprimantes installés dans un ordinateur »
Ci-dessous un exemple de la liste de l’imprimante installée dans l’ordinateur YAPTPCA366
Figure 68 : interface « liste des imprimantes installés dans un ordinateur»

SUPTECH
2014/2015
Page107
7. Interface « Les détails d’un prêt téléphonique »
Ci-dessous un exemple des détails d’un prêt téléphonique, le superviseur et les techniciens
informatiques peuvent l’extraire sous forme un fichier PDF et par la suite l’imprimer.
Une extraction des toutes les enregistrements en un seul fichier Excel est aussi possible.
Figure 69 : interface « les détails d’un prêt téléphonique»
Conclusion
Nous avons présenté dans cette dernière partie l’architecture de l’implémentation de notre
système et un guide utilisateur en montrant les interfaces basique du produit en vue que
l’utilisateur comparant bien l’architecture de l’application.

SUPTECH
2014/2015
Page108
Conclusion générale
Notre projet de fin d’étude effectué au sein de YAZAKI a consisté de concevoir et de réaliser
une application Web de gestion de son parc informatique en intégrant le module de gestion
des prêts téléphoniques et la gestion des interventions par un système de ticket en vue d’avoir
un produit complet, ainsi notre but principale était la livraison d’un produit qui répond aux
besoins des utilisateurs, afin d’être exploité par la société.
Tout au long de ce projet, nous avons utilisé l’approche objet en profitant de l’aspect itératif et
incrémental du Processus Unifié. La réalisation a été faite avec trois technologies différentes
Java JEE, Visual Basic .Net et Androïde, en utilisant MySQL comme SGBD.
Nous avons utilisé l’architecture orientée service (SOAP)[7] pour garantir l’extensibilité du
système développé et permettre d’ajouter d’autres services pour répondre aux futurs besoins
éventuels.
La réalisation du présent projet nous a permis de renforcer et d’enrichir nos connaissances en
conception et en programmation et de bien comprendre et de mettre en œuvre le déroulement
de cycle de vie d’un logiciel. Ce stage était une expérience avantageuse puisqu’il nous a offert
la possibilité de découvrir de près le monde informatique.
Les difficultés majeures que nous avons rencontrées durant ce projet résident essentiellement
dans la nouveauté des technologies Dot Net en particulier Visual Studio 2010 et surtout les
nouvelles fonctions qui sont ajoutées par rapport à la version 2008 de la même firme.
Comme une extension, cette application peut être enrichie avec un module qui gère les
consommables comme les toners et les rams papiers. Ce module peut être développé en
bénéficiant de notre architecture orienté service, la solution sera une application installé sur
des terminaux mobiles «Palm ».

SUPTECH
2014/2015
Page109
Annexes
Send Email in VB.NET
In previous section, I introduced how to send email without SMTP server. In this section, I will
introduce how to compose and send HTML email in VB.NET.
If you want to specify the font, color or insert pictures in your email, you should use Html email format
instead of Plain text email format.
Remarks: All of samples in this section are based on first section: Send email in a simple VB.NET
project. To compile and run the following example codes successfully, please click here to learn how
to create the test project and add reference of EASendMail to your project.
[VB.NET- Send HTML Email - Example]
The following example codes demonstrate how to send email in HTML body format in VB.NET. To get
full sample projects, please refer to Samples section.
Imports EASendMail 'Add EASendMail namespace
Module Module1
Sub Main()
Dim oMail As New SmtpMail("TryIt")
Dim oSmtp As New SmtpClient()
' Set sender email address, please change it to yours
oMail.From = "test@emailarchitect.net"
' Set recipient email address, please change it to yours
oMail.To = "support@emailarchitect.net"
' Set email subject
oMail.Subject = "test HTML email from VB.NET project"
' Set HTML body
oMail.HtmlBody = "This is a
test"
' Your SMTP server address

SUPTECH
2014/2015
Page110
Dim oServer As New SmtpServer("smtp.emailarchitect.net")
' User and password for ESMTP authentication, if your server doesn't
require
' User authentication, please remove the following codes.
oServer.User = "test@emailarchitect.net"
oServer.Password = "testpassword"
' If your SMTP server requires SSL/TLS connection, please add this line
' oServer.ConnectType = SmtpConnectType.ConnectSSLAuto
Try
Console.WriteLine("start to send HTML email ...")
oSmtp.SendMail(oServer, oMail)
Console.WriteLine("email was sent successfully!")
Catch ep As Exception
Console.WriteLine("failed to send email with the following error:")
Console.WriteLine(ep.Message)
End Try
End Sub
End Module
After you received the email by your email client, the body text is like this:
Of course, you don't have to write the HTML source body text in your application manually. You can
build a html file with HTML tools and use ImportHtmlBody method to import the html file directly.
You can also refer to the htmlmail.* samples in EASendMail Installer. Those samples demonstrate how
to build a HTML email editor and send HTML email with attachment or embedded images/pictures.

SUPTECH
2014/2015
Page111
Consuming Web services with KSOAP2
SOAP (Simple Object Access Protocol) is a lightweight protocol used for the
exchange of information in a de-centralized environment. It was developed by
Microsoft and has been proposed as a standard interface to the Internet Engineering
Task Force (IETF). A SOAP request mainly consists of three parts:
1. Envelope – It defines a framework for describing what is in a message and how
to process it.
2. Rules – It includes a set of encoding rules for expressing instances of application-
defined datatypes.
3. Convention – Used for representing remote procedure calls and responses.
In this tutorial, we will learn how to send SOAP requests using Android. To
implement SOAP requests using Android, we can use the Ksoap2 library. It is a
lightweight SOAP client library for the Android platform.
Pre-requisites: Eclipse IDE, Android SDK
Step 1: Create Android project
Create an Android application project called AndroidKSoapExample with package
name com.example
Step 2: Download Ksoap2 for Android
Next, you need to download the latest version of ksoap2 from over here. Add
theksoap2.jar in the libs folder of your Android project.
Step 3: Add Java code to Activity class
Now, let’s add the ksoap2 Java code in order to send the SOAP request. We would be
connecting to a public webservice available on the Internet. It is important to note
that all network related requests need to be executed on anon-UI thread post
Android 3.0. Here’s what our Activity class looks like,
MainActivity.java
package com.example;

SUPTECH
2014/2015
Page112
import java.io.IOException;
import org.ksoap2.SoapEnvelope;
import org.ksoap2.SoapFault;
import org.ksoap2.serialization.SoapObject;
import org.ksoap2.serialization.SoapSerializationEnvelope;
import org.ksoap2.transport.HttpResponseException;
import org.ksoap2.transport.HttpTransportSE;
import org.xmlpull.v1.XmlPullParserException;
import android.os.AsyncTask;
import android.os.Bundle;
import android.util.Log;
import android.widget.TextView;
import android.app.Activity;
public class MainActivity extends Activity {
private static final String SOAP_ACTION = "http://footballpool.dataaccess.eu/TopGoalSc
private static final String METHOD_NAME = "TopGoalScorers";
private static final String NAMESPACE = "http://footballpool.dataaccess.eu";
private static final String URL = "http://footballpool.dataaccess.eu/data/info.wso?WSD
private TextView tv;
private String response;
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_main);
tv= (TextView)findViewById(R.id.txt2);
myAsyncTask myRequest = new myAsyncTask();
myRequest.execute();
}

SUPTECH
2014/2015
Page113
private class myAsyncTask extends AsyncTask<Void, Void, Void> {
@Override
protected void onPostExecute(Void result) {
super.onPostExecute(result);
tv.setText(response);
}
@Override
protected void onPreExecute() {
super.onPreExecute();
}
@Override
protected Void doInBackground(Void... arg0) {
SoapObject request = new SoapObject(NAMESPACE, METHOD_NAME);
request.addProperty("iTopN", "5");
SoapSerializationEnvelope envelope = new
SoapSerializationEnvelope(SoapEnvelope.VER11);
envelope.setOutputSoapObject(request);
HttpTransportSE httpTransport = new HttpTransportSE(URL);
httpTransport.debug = true;
try {
httpTransport.call(SOAP_ACTION, envelope);
} catch (HttpResponseException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {

SUPTECH
2014/2015
Page114
} catch (XmlPullParserException e) {
} //send request
SoapObject result = null;
try {
result = (SoapObject)envelope.getResponse();
} catch (SoapFault e) {
}
Log.d("App",""+result.getProperty(1).toString());
response = result.getProperty(1).toString();
return null;
}
}
}
Step 4: Add permissions in manifest file
Before you run the application, you need to add the network and Internet
permissions in the AndroidManifest.xml file as follows,
AndroidManifest.xml
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.example"
android:versionCode="1"
android:versionName="1.0" >
<uses-sdk
android:minSdkVersion="8"
android:targetSdkVersion="18" />
<uses-permission android:name="android.permission.INTERNET"/>
<uses-permission

SUPTECH
2014/2015
Page115
android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE"/>
<application
android:allowBackup="true"
android:icon="@drawable/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<activity
android:name="com.example.MainActivity"
android:label="@string/app_name" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
</application>
</manifest>
Finally, save all changes. Make sure no errors are present. Run the application on an
Android device and you should see the following output!

SUPTECH
2014/2015
Page116
Bibliographie
[1] Site officiel de YAZAKI « http://www.yazaki-europe.com » consulter le 10/01/2015
[2] Site officiel de l’application Clarilog « http://www.clarilog.com/accueil » consulter le 10/01/2015
[3] Site officiel de l’application Spiceworks « http://www.spiceworks.com/ » consulter le 10/01/2015
[4] Site officiel de l’application GLPI « http://www.glpi-project.org/ » consulter le 10/01/2015
[5] Jérémie Guiochet : « Le Processus Unifié » IUP NTIE 4/11/09
[6] Xavier Blanc & Isabelle Mounier, UML 2 pour les développeurs, Eyrolles, 2006 ISBN 2-212-12029-5
[7] Tutoriel vidéo sur les services web SOAP avec Java et Dot Net
https://www.youtube.com/watch?v=ve4riMjcp08 consulté le 30/01/2015
[8] Tutoriel SOAP sous Android
http://www.obellianne.fr/alexandre/tutorials/Android/tuto_android_soap.php consulté le
15/02/2015
[9] Tutoriel « Utilisation du Web services SOAP sous Android »
http://dsilvera.developpez.com/tutoriels/android/utilisation-web-service-soap-sous-android/
consulté le 15/03/2015
[10] Tutoriel en ligne « Send email using exchange Web service »
https://www.emailarchitect.net/easendmail/kb/vbnet.aspx?cat=16 consulté le
17/03/2015
[11] Tutoriel sur l’utilisation du bibliothèque jfreechart pour la création des histogrammes avec Java
http://www.if.pw.edu.pl/~ertman/pojava/?download=jfreechart_tutorial.pdf consulté le
22/04/2015

Rapport de pfe gestion de parc informatique et Helpdesk

Contenu connexe

Tendances

En vedette

Similaire à Rapport de pfe gestion de parc informatique et Helpdesk

Rapport de pfe gestion de parc informatique et Helpdesk