SlideShare uma empresa Scribd logo
1 de 96
Baixar para ler offline
Mémoire de Fin d’Etudes
Pour l’obtention du diplôme
D’Ingénieur d’Etat
Génie Informatique
Promotion 2013 – 2014
Développement d’une application
de gestion d’un parc informatique
M. Hicham BENMOUSSA
Soutenance le 26 Juin 2014
Membres de jury :
M. Souhail CHELBAT Encadrant Société
M. Youness TABII Encadrant ENSATé
M. Mohamed LAZAAR Enseignant ENSATé
M. Mohamed CHRAYEH Enseignant ENSATé
Année Universitaire : 2013-2014
Remerciements
Il m’est agréable de m’acquitter d’une dette de reconnaissance auprès de toutes
les personnes, dont l’intervention au cours de mon stage, a favorisé son
aboutissement.
Ainsi, j’exprime ma profonde gratitude et je tiens à remercier M. Safi Mustafa de
m’avoir accordé l’opportunité de passer mon stage de fin d’études au sein de la
société ADDLOG.
Je remercie aussi infiniment toutes les personnes qui m’ont aidées à m’intégrer
au sein de la société et qui m’ont encadrées tout au long de mon stage parleurs
directives précieuses, conseils pertinents, à citer M. CHELBAT Souhail mon
encadrent société, EL BAKKALI Mohamed qui m’ont accompagnés durant le
stage au sein de la société et Mr ACHRAK Mehdi qu’y a permis, en grande partie,
de trouver ce stage.
Sans oublier M. TABII Youness, mon encadrant à l’école, auquel j’adresse tous
mes sentiments de reconnaissance les plus distingués.
Mes vifs remerciements s’adressent également aux membres du jury qui ont
accepté d’évaluer mon travail.
Enfin, j’espère que ce travail sera à la hauteur et pourra répondre aux attentes
et exigences auxquels il a été destiné.
BENMOUSSA Hicham
Résumé
Dans le cadre de mon projet de fin d’études à l’Ecole Nationale des Sciences Appliquées de
Tétouan (ENSAT) et en vue de l’obtention du titre d’ingénieur d’état en informatique, j’ai
effectué un stage de quatre mois à ADDLOG.
Durant mon séjour dans ladite société, j’avais pour mission dans un premier temps de concevoir
et de réaliser une application de gestion d’un parc informatique en suivant un cycle de vie qui
commence à l’étape de la conception/production/création jusqu'à la publication finale dans le
parc informatique en passant par les étapes de la vérification, de la validation et de
l’approbation. Dans un deuxième temps, j’étais amené à intégrer mon application dans le portail
interne de la société et assurer son opérabilité avec les différentes applications de son système
d’information.
Mon projet suit le model de cycle de vie en V, l’utilisation du formalisme UML pour la
réalisation de l’ensemble de diagrammes et enfin la modélisation MERISE puisqu’on nécessite
une base de données robuste, vise à détourner le problème. Ainsi, au terme de ce projet, j’ai pu
:
• Etablir une étude fonctionnelle et technique globale qui servira par la suite à continuer la
réalisation du système de gestion de parc informatique.
• Intégrer l’application dans le système d’information de la société
Liste des figures
Figure 1 : l’organigramme de la société ADDLOG .................................................................4
Figure 2 : les marques des matériels de la société ADDLOG ..................................................7
Figure 3 : les marques des matériels réseaux de la société ADDLOG......................................7
Figure 4 : Le model de cycle de vie en V ................................................................................9
Figure 5 : Diagramme de gant.................................................................................................9
Figure 6 : La navigation dans l'application............................................................................14
Figure 7 : Diagramme des cas d'utilisations de l'application..................................................18
Figure 8 : Diagramme de séquence du processus de visualisation des matériels ....................20
Figure 9 : fenêtre du cas d’utilisation ‘Consulter les matériels’ .............................................21
Figure 10 : Diagramme de séquence du processus de l’affichage des matériels achetés dans
une période...........................................................................................................................22
Figure 11 : fenêtre du cas d’utilisation ‘Afficher les matériels achetés dans une période’......23
Figure 12 : Diagramme de séquence du processus de l’ajout d’un nouveau matériel .............24
Figure 13 : fenêtre du cas d’utilisation ‘ ajouter un nouveau matériel ’..................................25
Figure 14 : Diagramme de séquence du processus de la modification du logiciel ..................26
Figure 15 : fenêtre du cas d’utilisation ‘ modifier un logiciel ’ ..............................................27
Figure 16 : Diagramme de séquence du processus de la création d’un groupe et la
modification de ses droits .....................................................................................................28
Figure 17 : fenêtre du cas d’utilisation ‘ gestion des groupes d’utilisateurs ’ .........................29
Figure 18 : Diagramme de séquence du processus de la visualisation l’historique des
connexions d’un utilisateur ………………………………………………………………...30
Figure 19 : fenêtre du cas d’utilisation ‘ gestion des connexions des utilisateurs ’ .................31
Figure 20 : schéma de l’architecture technique de l’application du parc ................................33
Figure 21 : diagramme d’activité ‘ Gestion des logiciels ’.....................................................34
Figure 22 : diagramme d’activité ‘ Gérer les utilisateurs ’.....................................................35
Figure 23 : diagramme d’activité ‘ Gérer les droits d’accès ’.................................................36
Figure 24 : diagramme d’activité ‘Attribuer un utilisateur à une machine ’ ...........................37
Figure 25 : diagramme d’activité ‘Rechercher un matériel ’..................................................38
Figure 26 : Le modèle logique des données du l’application .................................................39
Figure 27 : la table ‘ Société ’...............................................................................................40
Figure 28 : la table ‘ Département ’......................................................................................40
Figure 29 : la table ‘ Service ’...............................................................................................41
Figure 30 : la table ‘ Utilisateur ’..........................................................................................41
Figure 31 : la table ‘ Matériel ’ .............................................................................................42
Figure 32 : la table ‘ Machine ’.............................................................................................43
Figure 33 : la table ‘ Accessoire ’ .........................................................................................43
Figure 34 : la table ‘ Fournisseur ’ ........................................................................................44
Figure 35 : la table ‘ Logiciel ’..............................................................................................44
Figure 36 : la table ‘ Loueur ’ ...............................................................................................45
Figure 37 : la table ‘ Contrat ’...............................................................................................45
Figure 38 : la table ‘ paramètre ’...........................................................................................46
Figure 39 : la table ‘ Réparateur ’ .........................................................................................46
Figure 40 : la table ‘ Demande intervention ’ ........................................................................47
Figure 41 : Environnement WinDev .....................................................................................48
Figure 42 : Architecture logicielle.........................................................................................52
Figure 43 : Avantages de Méthode RAD...............................................................................54
Figure 44 : Evolution d’un projet avec la méthode RAD.......................................................55
Figure 45 : Parallélisassions et sérialisation des phases de projet avec la méthode RAD. ......56
Figure 46 : HyperFileSQL ....................................................................................................60
Figure 47 : logo du logiciel Edraw MAX..............................................................................64
Figure 48 : Logo du l’atelier génie logiciel WinDev 18.........................................................65
Figure 49 : fenêtre d’authentification....................................................................................66
Figure 50 : fenêtre compte administrateur.............................................................................66
Figure 51 : fenêtre de l’administration des utilisateurs et les groupes ....................................67
Figure 52 : fenêtre de l’ajout d’un nouvel utilisateur.............................................................68
Figure 53 : fenêtre de la gestion des droits ............................................................................69
Figure 54 : paramétrage des droits pour la fenêtre ‘ Fiche département ’...............................69
Figure 55 : fenêtre des statistiques de connexion de l’application..........................................70
Figure 56 : fenêtre des statistiques de connexion de l’application..........................................70
Figure 57 : fenêtre principale de l’application.......................................................................71
Figure 58 : Alerte de l’expiration de la garantie d’un matériel...............................................72
Figure 59 : La liste des entreprises et la fiche de création d’une nouvelle entreprise..............72
Figure 60 : La liste des utilisateurs (employeurs) et la fiche de création d’un nouvel employé
.............................................................................................................................................73
Figure 61 : La liste des matériels et la fiche d’ajout d’un nouvel matériel .............................74
Figure 62 : Rechercher un matériel .......................................................................................75
Figure 63 : La liste des logiciels et la fiche d’ajout d’un nouvel logiciel................................75
Figure 64 : La liste des machines (poste de travail) et la fiche d’ajout d’une nouvelle machine
.............................................................................................................................................76
Figure 65 : Architecture MVC..............................................................................................80
Figure 66 : Différence entre la théorie (les spécifications) et la pratique (ce qui a été produit)
.............................................................................................................................................85
Liste des tableaux
Tableau 1 : références et partenaires de la société ADDLOG ..................................................6
Tableau 2 : Acteurs du système ............................................................................................15
Tableau 3 : Répartition des rôles en fonction des étapes........................................................84
Tableau 4 : Documents en fonction des étapes......................................................................85
Sommaire
Introduction............................................................................................................................1
Chapitre 1 : Contexte général du projet.................................................................................3
1. Présentation de l’organisme d’accueil............................................................................3
1.1 La société ADDLOG :............................................................................................3
1.2 L’organigramme de la société :...............................................................................4
1.3. Les objectifs : ........................................................................................................4
1.4. Les activités :.........................................................................................................5
1.5. Produits :...............................................................................................................6
1.6. Les références et partenaires :................................................................................6
1.7. Les marques représentées : ....................................................................................7
2. Présentation du projet : objectifs et champ d’application................................................8
2.1. Présentation du projet ............................................................................................8
2.2. La démarche suivie................................................................................................8
Chapitre 2 : Etude et spécification des besoins....................................................................13
1. La navigation dans l’application ..................................................................................13
2. Identification des acteurs .............................................................................................14
3. Scénarios.....................................................................................................................15
3.1. Actions du fonctionnaire......................................................................................15
3.2. Actions du magasinier .........................................................................................15
3.3. Actions du comptable ..........................................................................................16
3.4. Actions du responsable........................................................................................16
3.5. Actions du superviseur ........................................................................................17
4. Les cas d’utilisation du système...................................................................................17
4.1. Cas d’utilisation ‘ Consulter les matériels et les logiciels ’...................................19
4.2. Cas d’utilisation ‘Afficher les matériels achetés dans une période ’ .....................21
4.3. Cas d’utilisation ‘ ajouter un nouveau matériel ’..................................................23
4.4. Cas d’utilisation ‘ modifier un logiciel ’...............................................................25
4.5. Cas d’utilisation ‘ gestion des groupes d’utilisateurs ’..........................................27
4.6. Cas d’utilisation ‘ gestion des connexions d’un utilisateur ’ .................................29
Chapitre 3 : Conception ......................................................................................................32
1. Stratégie de développement .........................................................................................32
2. Architecture technique de l’application........................................................................32
3. Comportement dynamique de l’application..................................................................34
3.1. Gestion des logiciels............................................................................................34
3.2. Gérer les utilisateurs............................................................................................34
3.3. Gérer les droits d’accès........................................................................................35
3.4. Attribuer un utilisateur à une machine .................................................................36
3.5. Rechercher un matériel........................................................................................37
4. Description de la base de données................................................................................38
4.1. Le modèle logique des données du l’application (MLD) ......................................38
4.2. Description des tables..........................................................................................40
Chapitre 4 : Etude technique du projet ................................................................................48
1. L’environnement WinDev ...........................................................................................48
1.1 Présentation WinDev............................................................................................48
1.2 Argumentaires généraliste WINDEV....................................................................49
1.3 Que fait-on avec WinDev .....................................................................................49
1.4 L’argumentaire technique .....................................................................................50
1.5 Argumentaire Base de Données ............................................................................50
1.6 Argumentaire réactivité et vitesse de développement ............................................51
2. Architecture et outils ...................................................................................................51
2.1 Architecture logicielle du système ........................................................................51
2.2 Choix des langages et outils..................................................................................53
2.3 Système de gestion de la base de données relationnelle.........................................58
Chapitre 5 : mise en œuvre du projet...................................................................................62
1. Présentation.................................................................................................................62
2. Réalisation de la solution.............................................................................................63
2.1 La couche Données : ............................................................................................63
2.2 La couche Mapping et Persistance : ......................................................................63
5.3 La couche Métier :................................................................................................63
5.4 La couche Services :.............................................................................................63
5.5 La couche Présentation :.......................................................................................63
3. Développement : .........................................................................................................63
3.1 Outils de développement : ....................................................................................63
3.2 Environnement de modélisation Edraw :...............................................................64
3.3 Environnement de développement WinDev ..........................................................65
4. Présentation de quelques interfaces..............................................................................65
Conclusion et perspectives....................................................................................................77
Bibliographie........................................................................................................................78
Webographie ........................................................................................................................79
Annexe 1 : Le Design Pattern MVC....................................................................................80
1. Le design pattern MVC ...............................................................................................80
1.1. Architecture MVC...............................................................................................80
2. Avantages et inconvénients..........................................................................................81
Annexe 2 : Le cycle de vie en V .........................................................................................83
1. Définition....................................................................................................................83
2. Les étapes....................................................................................................................83
3. Rôles ...........................................................................................................................83
4. Documents par phase...................................................................................................84
5. Risques inhérents au Cycle en V..................................................................................85
6. Comité de pilotage.......................................................................................................86
1 Développement d’une application de gestion d’un parc informatique
Introduction
La plupart des organisations possèdent aujourd’hui un réseau d'ordinateurs privé. Au travers de
ce réseau, les postes échangent des fichiers, partagent des imprimantes et parfois utilisent des
applicatifs (logiciels) en commun.
De nos jours, la plupart des applicatifs de gestion ont une architecture client-serveur (les
données sont sur le serveur qui assume l’essentiel du travail, le client ne fait qu’envoyer des
requêtes). Ces applicatifs constituent le cœur de ce que l'on appelle le système d'information
central.
Ces applicatifs gèrent des plannings, des annuaires, des ressources, des stocks, des commandes,
des livraisons, etc. Ce qui permet de mettre facilement à la disposition des employés des
documents divers et variés et oblige un accès centralisé à la mémoire de l'entreprise. Il est donc
généralement nécessaire de définir des droits d'accès pour les utilisateurs de l'intranet et par
conséquent une authentification de ceux-ci afin de leur permettre un accès personnalisé aux
fonctionnalités assurées par l’intranet.
De cette façon, un intranet favorise la communication au sein de l'entreprise et limite les erreurs
dues à la mauvaise circulation d'une information.
Au sein de la société ADDLOG, ma mission était de choisir un portail répondant à ses exigences
et le mettre en place. L’application de la Gestion de parc informatique après avoir été conçue
et développée doit s’intégrer dans ce portail avec l’ensemble des applications du système
d’information de la société. En effet, La gestion de parc permet de suivre en temps réel du
patrimoine informatique, matériel et logiciel de l’entreprise. Elle offre une vision globale de
l’état, du suivi et des coûts des appareils utilisés dans l’entreprise et de bien Gérer les différents
types d’équipements (Unités Centrales, Ecrans, Imprimantes, Matériels Réseaux, Matériels non
informatiques) ainsi que leurs Composants Hard et Soft (Processeurs, Mémoires, Disques durs,
OS, Logiciels…) et aussi visant à assurer le bon fonctionnement des PC et serveurs.
Le présent rapport décrit les différentes étapes de la réalisation du projet. Il comporte cinq
chapitres. Le premier chapitre définit le contexte général du projet et se compose de deux
parties. La première donne une présentation de la société au sein de laquelle j’ai effectué mon
stage. Quant à La deuxième partie, elle est consacrée à la présentation du projet et ses objectifs.
Le deuxième chapitre présente l’ensemble des spécifications du projet pour faire l’inventaire
des différentes fonctionnalités du système à réaliser. Le troisième chapitre présente la phase
conceptuelle du projet. L’étape de l’étude technique de l’application fait l’objet du quatrième
chapitre, celle-ci dresse l’environnement dans lequel s’inscrit l’application ainsi que le choix
2 Développement d’une application de gestion d’un parc informatique
du portail résultant d’une étude comparative passant au crible un ensemble de portails répondant
aux exigences de la société. Enfin, le cinquième chapitre est consacré à la phase de la réalisation
et la mise en œuvre du système. Il est constitué de deux parties, à savoir la partie réalisation
dans laquelle on a décrit les outils que j’ai manipulés et la partie de la mise en marche de
l’application qui présente quelques interfaces.
Ce rapport se termine par une conclusion contenant quelques perspectives pour le système de
gestion d’un parc informatique.
En complément, on présente les différentes annexes qui serviront pour élargir la portée du projet
tout en restant dans son environnement, à savoir la suite des spécifications du système, ainsi
que quelques annexes traitant l’aspect technique et organisationnel du projet.
3 Chapitre 1 : Contexte général du projet
Chapitre 1 : Contexte général du projet
Dans ce chapitre je présente l'organisme d'accueil ADDLOG où s'est déroulé mon projet de fin
d’études. Ensuite, je définis la problématique et les objectifs escomptés par le projet.
1. Présentation de l’organisme d’accueil
1.1 La société ADDLOG :
Crée en 2004 par une équipe d’ingénieurs polyvalents ayant tous la volonté d’accompagner les
entreprises du Nord Ma roc au cours de leur développement en matière des nouvelles
technologies. En fait, elle préfère la dénomination « partenaires » pour désigner les entreprises
qui lui font confiance pour les aider à s’adapter aux mutations constantes des nouvelles
technologies de l’information.
Aujourd’hui, elle a l’honneur d’affirmer sa réussite d’exposer cette vision à un grand nombre
de partenaires, ce qui lui donne la passion d’être présent à côté du client pour être toujours à la
hauteur des attentes.
Pour cela, elle n’épargne aucun effort, et surtout pas celui de former et d’assister leur
collaborateurs et partenaires.
4 Chapitre 1 : Contexte général du projet
1.2 L’organigramme de la société :
Figure 1 : l’organigramme de la société ADDLOG
1.3. Les objectifs :
Dans le cadre de sa vocation, ses objectifs sont :
 Améliorer la position de ses clients sur un marché globalisé, en gagnant les défis qui
leur permettent d’augmenter leur compétitivité ainsi que leurs perspectives de chiffre
d’affaire.
 Combiner son expérience avec ses ressources humaines de qualité pour innover et
améliorer notre service client continuellement.
5 Chapitre 1 : Contexte général du projet
1.4. Les activités :
1.4.1. Réseaux et Systèmes :
La configuration des réseaux est le point de départ de son service. Elle examine la situation
initiale du client et concevra une infrastructure de réseaux qui s’ajuste à leur besoins.
En tant que Partners certifiés de Cisco Systems, DELL et Microsoft et dans le cadre d’un suivi
constant de l’évolution des nouvelles technologies, elle possède d’amples connaissances sur les
environnements suivants :
 Systèmes opérationnels Linux et Windows
 Conception, installation et extension des réseaux informatiques.
 Pose et installation de la fibre optique
 Conception et installation des salles de serveurs et des équipements en Rack.
 Equipement des salles de réunion par des systèmes de projection et D’audioconférence.
 Système téléphonique analogique et solution VOIP.
 Interconnexion des réseaux distants d’entreprises
 Système de pointage.
 Vidéosurveillance et système anti-intrusion.
1.4.2. Serveurs :
Les serveurs disponibles dans la société ADDLOG sont :
 Serveurs de messagerie (Microsoft Exchange server)
 Serveurs de fichier et de partage avec une gestion d’accès aux ressources partagées.
 Pare-feu et solutions de filtrage entrant /Sortant
 Serveurs de backup pour des systèmes critiques.
1.4.3. Prestation de services et Maintenance
Pour répondre aux exigences de ses clients, elle se base sur la compétence de son équipe
technique, certifiée CISCO networks et Microsoft Systems, ainsi que sur l’expérience qu’elle a
acquis dans ce domaine en travaillant avec des entreprises de grande envergure (la liste après
ci-dessous), ainsi elle accompagne ses activités par quelque services pour mieux servir le
client :
 Service après-vente.
 Maintenance informatique par intervention ou sous contrat de maintenance
 Location des équipements : Imprimantes, photocopieurs ….
6 Chapitre 1 : Contexte général du projet
1.5. Produits :
Les produits de la société varient beaucoup ce qui lui donne un avantage dans le marché. Voici
une liste des produits et services de cette société :
 Vente de Matériel Informatique :
La société propose au client une large gamme de solution et de produits informatiques comme
: DELL, FUJITSU SIEMENS, HP, IBM, CIS CO, CANON, LEXMARK, XEROX, …
 Systèmes de pointage et gestion de personnels :
Marque représentée : ACRONYM
 Vidéosurveillance, Systèmes d’alarme et détection d’intrusion :
Marque représentée : TEXECOM, JABLOTRON
 Standard téléphonique et système VOIP :
Marque représentée : NORTEL NETWORKS, LG-NORTEL Alcatel, Siemens, Système VOIP
basé sur ASTE RISK.
1.6. Les références et partenaires :
Voici la liste de quelques références et partenaires de la société ADDLOG (tableau 1 ci-
dessous)
AWSM1 COFICAB TAKATA TMSA Medi1TV SRPTM
RENAULT
MAROC
EADS
MAROC
NUCAIN JOBELSA
MAROC
ZIMED
CONSULTING
TREMSA
(San Jose
Lopez)
COFELY POLYDESIGN ARFADEL ADDOHA EUROGATE …
Tableau 1 : références et partenaires de la société ADDLOG
7 Chapitre 1 : Contexte général du projet
1.7. Les marques représentées :
Les marques des produits se varient beaucoup selon le besoin du client pour le satisfaire voici
une liste des marques au niveau matériel :
Et au niveau réseaux :
Figure 2 : les marques des matériels de la société ADDLOG
Figure 3 : les marques des matériels réseaux de la société ADDLOG
8 Chapitre 1 : Contexte général du projet
2. Présentation du projet : objectifs et champ d’application
Dans cette partie, je présente le projet, les objectifs s’inscrivant dans le cadre de ce dernier et le
champ d’application.
2.1. Présentation du projet
Au terme d’une réunion entre le directeur de la société, mon encadrent et moi-même, j’ai
convenu que la plus grande faiblesse du système d’information du ADDLOG était l’absence
d’inventaire du parc informatique.
Le projet a donc été définit comme la mise en place d’une solution de gestion de parc
informatique capable d’inventorier automatiquement ce dernier.
Ainsi, ADDLOG a exprimé un besoin pressant de mettre à niveau son système d’information
et d’adopter un système efficace et ouvert afin de remédier aux problèmes de la gestion du parc
informatique.
Le but de l’application de la gestion du parc informatique est :
• L’accès simple à l'information,
• Classification, enregistrement et archivage des matériels achetés ou loués,
• Gestion de la sécurité (droits d’accès aux fonctionnalités de l’application),
• Gain du temps,
• La gestion et la traçabilité de tous les processus de travail,
• Communication souple entre les machines
• L’évolutivité et l'anticipation des besoins futurs.
La première phase du présent projet était de comprendre l’objectif du sujet et d’arriver à
délimiter le champ de travail pour pouvoir intervenir par la suite de manière plus efficace.
C’est ainsi que les premières entrevues avec mon encadrant m’ont permises de bien cerner le
sujet dans son contexte et de dégager la problématique et les objectifs visés. Une fois que la
vision sur le projet s’est éclaircie, il m’a été possible d’énumérer les fonctionnalités et de définir
la méthodologie de travail et de faire la version préliminaire du projet et par la suite la version
finale.
2.2. La démarche suivie
2.2.1. Cycle de vie du projet
Le « cycle de vie d'un logiciel » (en anglais software lifecycle), désigne toutes les étapes du
développement d'un logiciel, de l’idée à sa disparition. L'objectif d'un tel découpage est de
permettre de définir des jalons intermédiaires permettant la validation du développement
9 Chapitre 1 : Contexte général du projet
logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés et la vérification du
processus de développement, c'est-à-dire l'adéquation des méthodes mises en œuvre.
L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé
qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de
détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa
réalisation et les coûts associés.
2.2.2. Approche, méthodologie et planning du projet
Le model du cycle de vie adopté pour la réalisation de ce projet est le model en V, la figure ci-
après (Figure 4) présente ce model sous ses différentes étapes :
Figure 4 : Le model de cycle de vie en V
L’ensemble des activités de ce model suivant le temps est :
Figure 5 : Diagramme de gant
10 Chapitre 1 : Contexte général du projet
 Etude de faisabilité et analyse des besoins :
Il s’agit du recueil et de la formalisation des besoins du client selon mon
encadrent dans la société (ADDLOG) et de l'ensemble des contraintes.
 documentation sur les parcs informatiques et l'étude de l'existant :
J’ai lit pas mal des articles sur les parcs informatiques comment ils fonctionnent,
les principaux composants … . Et aussi j’ai fait du benchmarking sur les
solutions libres et propriétaires des logiciels de gestion de parc informatique afin
de prendre des idées sur ma future application.
 Spécifications :
Il s'agit de l'élaboration des spécifications de l'architecture générale du logiciel.
Pendant laquelle j’ai décrit l’ensemble des cas d’utilisation du système avec
proposition des maquettes d’Interface Homme/Machine répondant aux besoins.
 Conception :
J’ai décrit dans cette étape l’ensemble des tables, objets et activités de
l’application et aussi la création du MCD après la génération du MLD du
l’application et ainsi la génération de la base de données.
 Codage :
La traduction dans le langage de programmation choisi des fonctionnalités
définies lors de la phase de la conception et j’ai réussi à développer l’application
en sa totalité sans la réviser et corriger les erreurs ou faire la gestion des
exceptions.
 Tests unitaire ,tests d’intégration et modification et correction des erreurs :
Permettant de vérifier individuellement que chaque sous-ensemble du logiciel
est implémenté conformément aux spécifications et
qu’il s’intégrera bien avec l’ensemble, et aussi la correction des erreurs
d’orthographes et faire la gestion des exceptions et de manipulation de
l’application
 Tests de validation et recette finale :
pour valider l’ensemble des spécifications du système conçu un test de validation
est requis , aussi la mise en place de l’application répondant au cahier des charges
défini.
2.2.3. Le méthode d’analyse et de modélisation MERISE :
La méthode Merise est une méthode d'analyse, de conception et de réalisation de systèmes
d'informations.
11 Chapitre 1 : Contexte général du projet
En amont, elle se situait dans le prolongement naturel d'un schéma directeur, souvent conduit
suivant la méthode RACINES, très présente notamment dans le secteur public.
Les projets Merise étaient généralement des projets de grande ampleur de refonte d'un existant
complexe, dans un environnement grand système. La méthode a aussi connu des tentatives
d'adaptation avec les SGBD relationnels, les différentes interfaces homme-machine IHM,
l'Orienté objet, le développement micro, les outils CASE, la rétro-ingénierie... mais qui n'ont
pas connu le même succès.
La méthode est essentiellement française. Elle a des équivalents à l'étranger en ce qui concerne
les modèles de données (avec des différences, par exemple les cardinalités ne sont pas aussi
détaillées dans les modèles anglosaxons). En revanche la modélisation des traitements est
beaucoup plus complexe que dans les méthodes anglo-saxonnes.
Sa mise en œuvre peut paraître lourde. On consacre beaucoup de temps à concevoir et à pré-
documenter avant de commencer à coder, ce qui pouvait sembler nécessaire à une époque où
les moyens informatiques n'étaient pas aussi diffusés qu'aujourd'hui. Cela dit, elle évite l'écueil
inverse du développement micro, qui souffre du manque de documentation, et où les erreurs
sont finalement très coûteuses à réparer a posteriori.
Même si les échanges et la consultation entre concepteurs et utilisateurs sont formellement
organisés, on a aussi reproché à Merise d'utiliser un formalisme jugé complexe (surtout pour
les modèles de données), qu'il faut d'abord apprendre à manier, mais qui constitue ensuite un
véritable langage commun, puissant et rigoureux pour qui le maîtrise.
L'articulation très codifiée et bien balisée des différentes étapes, avec un descriptif très précis
des résultats attendus est ce qui reste aujourd'hui de mieux connu et de plus utilisé.
Pour mon projet j’ai utilisé MERISE pour concevoir seulement la base de données puisque cette
application nécessite une base de données robuste.
2.2.4. Le langage de modélisation UML :
Dans le but de concevoir un système extensible, évolutif, modulaire et orienté objet, le
formalisme UML s’est imposé comme un outil performant afin d’élaborer ce projet. En effet,
le langage de modélisation UML permet de mener la phase de conception tout en bénéficiant
de la puissance et de la simplicité de ses diagrammes.
UML est un langage de modélisation de troisième génération, normalisé par l'OMG (Object
Management Group) début 1997. C'est une fusion des idées des méthodes Booch, OMT et
OOSE (Object Oriented Software Engineering). Il a été conçu pour servir de langage de
modélisation objet, indépendamment de la méthode de mise en œuvre.
12 Chapitre 1 : Contexte général du projet
UML définit 9 diagrammes pour donner à l’utilisateur les moyens de visualiser et de manipuler
des éléments de modélisation : diagrammes d’activités, diagrammes de cas d’utilisation,
diagrammes de classes, diagrammes de collaboration, diagrammes de composants, diagrammes
de déploiement, diagrammes d’états transitions, diagrammes d’objets et diagrammes de
séquences.
Le choix d’UML, comme outil de modélisation des flux et les différentes actions de
l’application, peut être justifié par plusieurs raisons :
• UML facilite la compréhension et la communication d’une modélisation objet,
• La notation UML s'impose comme un standard de fait à l'heure actuelle sur le marché,
• Il est adopté par les grands constructeurs de logiciel du marché,
• L’utilisation d’UML offre l’avantage de disposer de vues de haut niveau d'abstraction,
• Pour favoriser la communication entre utilisateurs, spécialistes et informaticiens.
Conclusion
Dans ce chapitre j’ai décrit le contexte général dans lequel s’inscrit le projet. Au début, j’ai
présenté l’entreprise d’accueil à savoir ADDLOG. Ensuite, j’ai déterminé la problématique et
les objectifs du projet qui se résument en la réalisation d’un système de gestion du parc
informatique. Après, j’ai présenté la démarche que j’ai suivie pour arriver à mon but et cela
par la présentation du processus de développement ou cycle de vie du projet que j’ai adopté en
l’occurrence le model en V. Puis, le formalisme merise pour la conception de la base de
données et aussi UML qui m’a servi de standard dans la réalisation des diagrammes de
modélisation relatifs à notre projet et ce, afin d’illustrer son fonctionnement.
Dans le chapitre suivant je présentera les spécifications du système.
13 Chapitre 2 : Etude et spécification des besoins
Chapitre 2 : Etude et spécification des besoins
Ce chapitre détaille les spécifications pour la réalisation de l’application de la ‘Gestion de
parc informatique’. Il décrit l’ensemble des cas d’utilisation du système avec des propositions
de prototypes d’Interfaces Homme/Machine (IHM) possibles pour l’application.
En effet, le présent chapitre définira les interactions entre le collaborateur et l’application de
la Gestion de parc informatique tout au long du cycle de vie des machines et des ordinateurs.
Ce dernier commence de la phase de remplissage de différentes domaines de l’application (par
exemple les utilisateurs, matériels, machines, réseaux …) en passant par les phases du
paramétrage de l’application, et enfin d’établir des opérations sur les ordinateurs et les
périphériques associés au réseau.
Ainsi pour assurer le suivi de l’état du parc, on pourra définir beaucoup de types des
utilisateurs : administrateurs, Magasinier, fonctionnaires, Comptables, réparateurs,
responsables d’achats, ….
1. La navigation dans l’application
La figure ci-après (Figure 6) décrit la navigation dans l’application Gestion de parc
informatique.
14 Chapitre 2 : Etude et spécification des besoins
Figure 6 : La navigation dans l'application
(*) L’apparition des sous menu du menu principal varie selon l’utilisateur et ses droits
2. Identification des acteurs
Le tableau ci-après (Tableau 2) illustre les différents acteurs du système.
15 Chapitre 2 : Etude et spécification des besoins
Tableau 2 : Acteurs du système
3. Scénarios
3.1. Actions du fonctionnaire
Le fonctionnaire est un collaborateur au sein du parc qui n’a pas des rôles supplémentaires dans
l’application. Ci-après ses actions possibles :
o Consulter les matériels et les logiciels
o Imprimer la liste des matériels selon un critère
o Rechercher un matériel ou logiciel
o Filtrer les données afin de voir les matériels achetés dans une période
o Imprimer des factures de l’achat du matériel ou logiciel
3.2. Actions du magasinier
Le magasinier est aussi un collaborateur au sein du parc, c’est-à-dire qu’il possède toutes les
actions citées précédemment en tant que fonctionnaire. De plus, il a des actions suivantes :
o Saisir les informations du matériel et du logiciel
o Mise à jour des informations sur les matériels et les logiciels (modification)
o Affectation d’un matériel ou logiciel à un utilisateur du parc
est un employé de la société qui va consulter les informations sur
des matériels et des logiciels du parc
Est la personne qui s’en charge de saisir les informations du
matériel ou logiciel entré en respectant des règles de gestion
précise
est responsable de l'administration financière du parc, il paie des
factures des fournisseurs et il est responsable de valider les
contrats de la société
Le rôle majeur est d’assurer l’évolution et la maintenance du par
cet aussi de donner l’accord d’acquisition du matériel ou du
logiciel et du staff
Est en charge du paramétrage de la base et il fait la gestion de
n’importe quelle composant du parc qui existe dans l’application
(matériel, logiciel, machine, utilisateur,….) etc.
16 Chapitre 2 : Etude et spécification des besoins
o prêter du matériel aux utilisateurs du parc
o Récupérer le matériel déjà affecté
o Rédaction d’une commande
3.3. Actions du comptable
Le comptable est aussi un collaborateur au sein du parc, il a des actions concernant le
domaine de comptabilité. Ci-après ses actions :
o La gestion des contrats de location des matériels (création, modification, suppression)
o Consultation des informations sur les utilisateurs du parc
o Consulter le graphe de reporting concernant les matériels acheté depuis la création du
parc
o Affirmation de retour de garantie des matériels
o Ecrire une nouvelle intervention
o L’impression de : matériels en stock, les contrats de location, les retours en garantie…
3.4. Actions du responsable
Le responsable est aussi un collaborateur au sein du parc, c’est-à-dire qu’il possède toutes les
actions en tant qu’un magasinier et d’un fonctionnaire. De plus, il a des actions sur le parc
auxquels il a été désigné comme responsable. Ci-après ses actions :
o Gestion des utilisateurs du parc (ajouter, modifier, supprimer)
o Mettre une sauvegarde des données
o Récupération de données sauvegardées
o Afficher les statistiques de connexions dans une période selon un utilisateur de
l’application
o Effectuer les achats informatiques (matériels ou logiciels)
o Création d’une nouvel Intervention sur incident
o Gestion des postes de travail (machines)
o Gestion des fournisseurs
o Faire le suivi des pannes et des réparations
o Elaboration des besoins en matériel pour la maintenance
o Remise les matériels en différents états (affecté, intervention réparation, …)
17 Chapitre 2 : Etude et spécification des besoins
3.5. Actions du superviseur
Le superviseur de l’application pourrait lui aussi être considéré comme étant un fonctionnaire,
magasinier et aussi d’un responsable au sein du parc. De plus, il a des actions supplémentaires
dans l’application. Ci-après ses actions :
o Création, modification, suppression des utilisateurs de l’application
o Gestion des groupes d’utilisateurs
o Mise hors service d’un matériel
o Gestion des départements et les services de la société
o Effacer les statistiques de connexions dans une période selon un utilisateur de
l’application
o Gestion des réparateurs et des loueurs
o Paramétrage des alertes de différentes actions en cours
4. Les cas d’utilisation du système
Le diagramme ci-après (Figure 7) illustre les différents cas d’utilisation de l’application de la
Gestion du parc informatique résumant les différentes actions des acteurs, les sous parties
suivantes détailleront les plus importants cas d’utilisation de mon application ainsi que des
prototypes de fenêtres proposées.
18 Chapitre 2 : Etude et spécification des besoins
Figure 7 : Diagramme des cas d'utilisations de l'application
19 Chapitre 2 : Etude et spécification des besoins
4.1. Cas d’utilisation ‘ Consulter les matériels et les logiciels ’
4.1.1. Description du cas d’utilisation
Ce cas d’utilisation permet de voir les différents matériels et logiciels en vue de leur ajout dans
la base du parc informatique, dans cet exemple, je vais expliquer la partie matériel, la même
démarche s’applique sur les logiciels. Ci-après l’ensemble des informations sur ce cas
d’utilisation :
 Acteurs : Les acteurs pouvant consultés les matériels et les logiciels sont :
fonctionnaire, magasinier, responsable, superviseur de l’application
 Pré-conditions : l’authentification dans l’application.
 Action de départ : Accéder à l’application du parc.
 Enchaînement :
 Enter le nom d’utilisateur et le mot de passe
 La vérification du système si les informations sont correctes
 Si les informations sont erronées un message apparait qui dit que soit l’utilisateur
n’existe pas soit le mot de passe est incorrect, sinon il accède au menu principale
du l’application
 Dans le menu matériel il clique sur liste des matériels pour les visualiser
 Action de fin : quitter la fenêtre des matériels
 Post-conditions : Aucune
4.1.2. Diagramme de séquence
Le diagramme ci-après (Figure 8) illustre le processus de visualisation des matériels qui doit
être précédé par une authentification.
20 Chapitre 2 : Etude et spécification des besoins
Figure 8 : Diagramme de séquence du processus de visualisation des matériels
4.1.3. Fenêtre de la liste des matériels
La figure ci-après (Figure 9) propose la fenêtre d’interface IHM pour la visualisation de la liste
des matériels.
Dans cette fenêtre l’acteur qui l’a accédé est le responsable car le fonctionnaire voit les
boutons : nouveau, modifier, supprimer grisés.
21 Chapitre 2 : Etude et spécification des besoins
Le double clic sur un matériel affiche ses détails, le bouton ‘ fermer ’ pour clôturer la fenêtre et
revenir à la fenêtre principale.
4.2. Cas d’utilisation ‘Afficher les matériels achetés dans une période ’
4.2.1. Description du cas d’utilisation
Ce cas d’utilisation permet de voir les différents matériels achetés de la base du parc
informatique tel que la date d’achat est comprise entre deux dates saisies dans la fenêtre de
« les matériels achetés dans une période »,. Ci-après l’ensemble des informations sur ce cas
d’utilisation :
 Acteurs : Les acteurs pouvant consultés les matériels achetés dans une période sont :
fonctionnaire, magasinier, responsable, superviseur de l’application
 Pré-conditions : l’authentification dans l’application.
 Action de départ : Accéder à l’application du parc.
 Enchaînement :
 L’authentification (vérification du nom d’utilisateur et mot de passe).
 L’accès au menu principale du l’application
 Dans le menu matériel il clique sur matériels achetés dans une période
 Saisir la date de début et la date de fin ou choisir une période déjà prédéfinie
 Clic sur le bouton Afficher les matériels
Figure 9 : fenêtre du cas d’utilisation ‘Consulter les matériels’
22 Chapitre 2 : Etude et spécification des besoins
 Remplissage automatique de la table par les matériels qui répond au critère de la
recherche
 Action de fin : quitter la fenêtre des matériels
 Post-conditions : Aucune
4.2.2. Diagramme de séquence
Le diagramme ci-après (Figure 10) illustre le processus de la recherche des matériels achetés
dans une période, bien sûr qui doit être précédé par une authentification.
Figure 10 : Diagramme de séquence du processus de l’affichage des matériels achetés
dans une période
4.2.3. Fenêtre de la liste des matériels
La figure ci-après (Figure 11) propose la fenêtre d’interface IHM pour la visualisation de la
liste des matériels achetés entre la date de début et la date de fin.
Dans cette fenêtre l’acteur qui l’a accédé est le fonctionnaire.
23 Chapitre 2 : Etude et spécification des besoins
Le bouton ‘ Période prédéfinie ’ permet de dérouler une liste contient des différentes périodes
comme : semaine en cours, semaine flottante, mois en cours …
Le bouton ‘ Afficher les matériels ‘ affiche des informations dans la table selon la période saisie,
aussi en peut imprimer le résultat à l’aide du bouton ‘ Imprimer ‘ mais si la table est vide et on
veut imprimer le résultat, un message d’erreur s’affiche indiquant qu’il n’existe rien à imprimer.
4.3. Cas d’utilisation ‘ ajouter un nouveau matériel ’
4.3.1. Description du cas d’utilisation
Ce cas d’utilisation permet d’ajouter un nouveau matériel dans l’application. Ci-après
l’ensemble des informations sur ce cas d’utilisation :
 Acteurs : Les acteurs pouvant modifiés les logiciels sont : magasinier, responsable,
superviseur de l’application
 Pré-conditions : l’authentification dans l’application.
 Action de départ : Accéder à l’application du parc.
 Enchaînement :
 L’authentification (vérification du nom d’utilisateur et mot de passe).
 L’accès au menu principale du l’application
 Dans le menu matériel il clique sur création d’un nouveau matériel
 Remplir toutes les informations nécessaires
Figure 11 : fenêtre du cas d’utilisation ‘Afficher les matériels achetés dans une période’
24 Chapitre 2 : Etude et spécification des besoins
 Clic sur le bouton Valider
 Vérification du système des champs obligatoires
 Renvoyer le message d’affirmation d’ajout du matériel
 Action de fin : quitter la fenêtre de la création d’un nouveau matériel
 Post-conditions : vérification du système du format des champs (date, email,
numéro,…)
4.3.2. Diagramme de séquence
Le diagramme ci-après (Figure 12) illustre le processus de l’ajout d’un nouveau matériel au
sein du l’application après avoir choisi le type et le modèle.
Figure 12 : Diagramme de séquence du processus de l’ajout d’un nouveau matériel
4.3.3. Fenêtre de l’ajout du matériel
La figure ci-après (Figure 13) propose la fenêtre d’interface IHM pour la création d’un nouvel
matériel.
Dans cette fenêtre l’acteur qui l’a accédé est le magasinier.
25 Chapitre 2 : Etude et spécification des besoins
Figure 13 : fenêtre du cas d’utilisation ‘ ajouter un nouveau matériel ’
La case à cocher ‘Partager en réseau’ permet d’afficher le champ ‘Adresse IP’ pour renseigner
une adresse pour le matériel, si la case est décochée alors le champ ‘Adresse IP ’ est invisible.
Le sélecteur d’achat ou location permet de visualiser des champs selon le cas sélectionné, s’il
s’agit de la location les champs loueurs et le N° de contrat s’affiche sinon les autres champs qui
s’affichent (Figure 13)
4.4. Cas d’utilisation ‘ modifier un logiciel ’
4.4.1. Description du cas d’utilisation
Ce cas d’utilisation permet de mise à jour des informations sur u logiciel (augmenter le nombre
de licences, modifier l’éditeur,…). Ci-après l’ensemble des informations sur ce cas
d’utilisation :
 Acteurs : Les acteurs pouvant modifiés les logiciels sont : magasinier, responsable,
superviseur de l’application
 Pré-conditions : l’authentification dans l’application.
 Action de départ : Accéder à l’application du parc.
 Enchaînement :
26 Chapitre 2 : Etude et spécification des besoins
 L’authentification (vérification du nom d’utilisateur et mot de passe).
 L’accès au menu principale du l’application
 Dans le menu logiciel il clique sur liste des logiciels
 Sélectionner un logiciel et cliquer sur le bouton modifier
 Mise à jour des champs concernés
 Vérification du système des formats des champs et aussi les champs obligatoires
 Message d’affirmation de la mise à jour des données du logiciel en cours
 Action de fin : quitter la fenêtre de la modification du logiciel
 Post-conditions : Aucune
4.4.2. Diagramme de séquence
Le diagramme ci-après (Figure 14) illustre le processus de la mise à jour des informations sur
un logiciel, bien sûr qui doit être précédé par une authentification.
Figure 14 : Diagramme de séquence du processus de la modification du logiciel
4.4.3. Fenêtre de la modification du logiciel
La figure ci-après (Figure 15) propose la fenêtre d’interface IHM pour la visualisation de la
liste des matériels achetés entre la date de début et la date de fin.
Dans cette fenêtre l’acteur qui l’a accédé est le superviseur.
27 Chapitre 2 : Etude et spécification des besoins
Figure 15 : fenêtre du cas d’utilisation ‘ modifier un logiciel ’
Si on a sélectionné le nombre de licences à définir alors les champs ‘ Nombre max de licences
’ et ‘ Prix unitaire ’ apparaitront pour les remplir après le champ ‘ Prix achat HT ‘ se calcule
automatiquement à partir de les champs mentionnés ci-dessus.
Aussi on peut joindre un fichier avec le logiciel par exemple une image ou un fichier texte et le
voir à l’aide du bouton voir (l’œil).
4.5. Cas d’utilisation ‘ gestion des groupes d’utilisateurs ’
4.5.1. Description du cas d’utilisation
Ce cas d’utilisation permet de faire la gestion totale des groupes d’utilisateurs. Dans ce scénario
on va créer un groupe modifier les droits de ce groupe .Ci-après l’ensemble des informations
sur ce cas d’utilisation :
 Acteurs : L’acteur pouvant faire la gestion des groupes d’utilisateurs est le superviseur
 Pré-conditions : l’authentification dans l’application.
 Action de départ : Accéder à l’application du parc.
 Enchaînement :
 L’authentification autant qu’un superviseur (vérification du nom d’utilisateur et
mot de passe).
28 Chapitre 2 : Etude et spécification des besoins
 L’accès au menu de présentation de l’application et choisir ‘ configurer le
groupeware ‘
 L’affichage de la fenêtre du groupeware utilisateur
 Clic sur ‘ l’onglet utilisateurs et groupes ‘ puis sur le bouton ‘ nouveau’ pour la
partie des groupes
 Saisir le nom du groupe et valider
 le message d’affirmation de l’ajout du groupe apparaîtra
 clic sur l’onglet gestion des droit et choisir le groupe créé précédemment
 faire modification des droits souhaités et un message indiquant que la modification
a réussi apparaitra
 Action de fin : quitter la fenêtre du groupeware utilisateur
 Post-conditions : Aucune
4.5.2. Diagramme de séquence
Le diagramme ci-après (Figure 16) illustre le processus de l’ajout d’un groupe et modifier ses
droits.
4.5.3. Fenêtre de la gestion des droits
La figure ci-après (Figure 17) propose la fenêtre d’interface IHM pour la modification des droits
d’un groupe nommé ‘ Fonctionnaires ‘ quoi concerne les fonctionnaires du parc.
Dans cette fenêtre l’acteur qui l’a accédé est le superviseur.
Figure 16 : Diagramme de séquence du processus de la création d’un groupe et la modification de
ses droits
29 Chapitre 2 : Etude et spécification des besoins
Figure 17 : fenêtre du cas d’utilisation ‘ gestion des groupes d’utilisateurs ’
Il s’agit ici la gestion des droits pour la fenêtre principale de l’application, comme on a déjà
discuté dans ce rapport, le fonctionnaire peut voir la liste des matériels et aussi voir les matériels
acheté dans une période ce qui est indiqué dans la figue ci-dessus, donc le superviseur a mis les
autres menus comme : Sites, Utilisateurs, Machines … grisés.
4.6. Cas d’utilisation ‘ gestion des connexions d’un utilisateur ’
4.5.1. Description du cas d’utilisation
Ce cas d’utilisation permet d’afficher les statistiques des connexions d’un utilisateur, dans ce
cas d’utilisation on va visualiser les statistique d’un utilisateur selon une période sélectionner
afin de filtrer les résultats, .Ci-après l’ensemble des informations sur ce cas d’utilisation :
 Acteurs : Les acteurs pouvant visualisés les connexions d’un utilisateur sont : le
responsable et le superviseur
 Pré-conditions : l’authentification dans l’application.
 Action de départ : Accéder à l’application du parc.
 Enchaînement :
 L’authentification (vérification du nom d’utilisateur et mot de passe).
 L’accès au menu de présentation de l’application et choisir ‘ configurer le
groupeware ‘
 L’affichage de la fenêtre du groupeware utilisateur
30 Chapitre 2 : Etude et spécification des besoins
 Clic sur l’onglet ‘ Statistiques‘
 Saisir le nom de l’application et aussi de l’utilisateur
 Sélectionner une période prédéfinie ou saisir la date de début et la date de fin
 clic sur le bouton ‘ appliquer le filtre ’
 remplissage automatique de la table des connexions
 Action de fin : quitter la fenêtre du groupeware utilisateur
 Post-conditions : Aucune
4.5.2. Diagramme de séquence
Le diagramme ci-après (Figure 18) illustre le processus de la visualisation de l‘historique des
connexions d’un utilisateur.
Figure 18 : Diagramme de séquence du processus de la visualisation l’historique des
connexions d’un utilisateur
4.5.3. Fenêtre de la visualisation des connexions d’un utilisateur
La figure ci-après (Figure 19) propose la fenêtre d’interface IHM pour la l’affichage l’historique
des connexions concernant un utilisateur.
Dans cette fenêtre l’acteur qui l’a accédé est le superviseur.
31 Chapitre 2 : Etude et spécification des besoins
Figure 19 : fenêtre du cas d’utilisation ‘ gestion des connexions des utilisateurs ’
Après le saisie le nom du l’application, le login concernant un utilisateur spécifique et aussi la
date de début et la date de fin et en cliquant sur appliquer le filtre on voit clairement les résultats
sur la table de l’historique des connexions pour cet utilisateur on peut aussi autant qu’un
superviseur d’effacer cet historique à l’aide du bouton ‘ Effacer l’historique ’
Conclusion
Ce chapitre a donné une première vision sur les fonctionnalités de l’application de la gestion
du parc informatique. Dans ce chapitre, j’ai choisi de décrire 6 cas d’utilisation primaires
dans l’application.
Le chapitre suivant donnera la vision conceptuelle de l’application.
32 Chapitre 3 : Conception
Chapitre 3 : Conception
Ce chapitre définit les éléments résultant de l’analyse des spécifications de l’application de la
Gestion de parc informatique. Les contraintes et les choix de conception seront présentés dans
ce chapitre.
1. Stratégie de développement
L’application à développer sera sous forme d’une application et un petit portail web qui sert à
faire la communication entre l’application et le serveur d’application, Un portail traite les
requêtes d'une tâche ou d'un service donné et génère dynamiquement le contenu web affiché à
l’utilisateur, aussi l’application permet de faire la configuration complète du parc informatique
on se basant sur le serveur qui va faire les traitements qui concerne le parc , aussi elle va me
permettre de me fournir toutes sortes de services généralistes ou spécialisés ( interface de
consultation des informations sur la société, panneau d'information, La gestion des licences, la
gestion des contrats fournisseurs, …)
De point de vue de l’interface de l’application j’ai préféré de travailler avec des fenêtres
modales qui sont , dans une interface graphique, des fenêtres qui prennent le contrôle total du
clavier et de l'écran. Elles sont en général associées à une question à laquelle il est impératif
que l'utilisateur réponde avant de poursuivre, ou de modifier quoi que ce soit, c.à.d. pour
l'application : seule cette application est bloquée jusqu'à la réponse ou l’attente de la valeur de
retour de cette fenêtre ;
Et finalement l’application utilise un seul gabarit (style de l’interface) pour toutes ses
composantes (fenêtres, boutons, Listes déroulantes,…) afin d’être ergonomique et facile à
utiliser.
2. Architecture technique de l’application
Le schéma ci-après (Figure 20) montre l’architecture technique générale et le contexte de
déploiement de l’application.
33 Chapitre 3 : Conception
- Le serveur Manta est composé :
 du service Manta Manager permet de communiquer avec l'application "Centre de
Contrôle HFSQL" (outil d'administration à distance) et d'arrêter et/ou de lancer le ou les
serveurs.
 du service Manta.
Le service Manta est l'application (en mode service) qui traite les demandes et les connexions"
client/serveur " des applications connectées au serveur.
Par défaut, un seul service Manta est présent sur le poste serveur. Cependant, il est possible
d'avoir plusieurs services Manta sur le même poste serveur. Cette configuration permet par
exemple d'associer mon application à un service Manta. Ainsi, si mon application surcharge le
service Manta, seules les applications associées à ce service seront bloquées ou ralenties.
Pour utiliser cette configuration, il est nécessaire que chaque service Manta utilise un port
réseau et un chemin de répertoire de bases de données différents.
Remarque : En cas de défaillance, le service est automatiquement redémarré.
Aussi le serveur HyperFileSQL contient toute la base de données de l’application de la gestion
du parc informatique.
Figure 20 : schéma de l’architecture technique de l’application du parc
34 Chapitre 3 : Conception
3. Comportement dynamique de l’application
Cette partie présente les activités (diagrammes d’activités) majeures du système de l’application
de la gestion du parc informatique.
3.1. Gestion des logiciels
Le processus de la gestion des logiciels commence tout d’abord par l’identification et la
vérification du système des droits d’accès pour l’utilisateur connecté, ensuite cet utilisateur va
accéder à l’interface principale pour aller vers le menu logiciel et après choisir liste des logiciels
pour faire le traitement souhaité qui va être géré par le système.
Le diagramme d’activités ci-après (Figure 21) présente le processus de gestion des logiciels du
parc informatique.
Figure 21 : diagramme d’activité ‘ Gestion des logiciels ’
3.2. Gérer les utilisateurs
Pour gérer les utilisateurs avec leurs droits d’accès, il faut tout d’abord s’authentifier autant
qu’un superviseur, puis l’accès à la fenêtre de la présentation du l’application puis aller à la
configuration du groupeware et ensuite accéder à la création d’un nouveau utilisateur en
remplissant le nom et prénom, le login, le mot de passe, la confirmation du mot de passe et le
35 Chapitre 3 : Conception
téléphone et indiquer si l’utilisateur est un superviseur ou non , finalement on peut soit de
valider et quitter le formulaire ou de valider et de créer un nouvel utilisateur .
Le diagramme d’activités ci-après (Figure 22) présente le processus de gestion des utilisateurs.
Figure 22 : diagramme d’activité ‘ Gérer les utilisateurs ’
3.3. Gérer les droits d’accès
Concernant les droits le superviseur accède à l’onglet du l’application gestion des droits et
sélectionner un utilisateur et puis modifier les droits d’accès puis enregistrer les modifications.
Le diagramme d’activités suivant (Figure 23) présente la gestion des droits pour un utilisateur
ou un groupe choisi.
36 Chapitre 3 : Conception
Figure 23 : diagramme d’activité ‘ Gérer les droits d’accès ’
3.4. Attribuer un utilisateur à une machine
Cette activité sert à lier un utilisateur à un poste de travail de la société, pour effectuer cette
activité il faut accéder à la fenêtre des machines puis sélectionner une machine pour la modifier,
ensuite sur la zone des utilisateurs on clique sur l’icône de l’utilisateur puis la liste des
utilisateurs disponibles apparaitra , finalement on sélectionne un utilisateur concerné et on
valide le choix.
Le diagramme d’activités suivant (Figure 24) présente l’attribution d’un utilisateur à une
machine.
37 Chapitre 3 : Conception
Figure 24 : diagramme d’activité ‘Attribuer un utilisateur à une machine ’
3.5. Rechercher un matériel
La recherche d’un matériel est une activité très importante lorsque qu’il existe des milliers des
matériels dans un parc, il s’agit d’accéder au menu matériel et cliquer sur recherche puis saisir
les informations concerné dans les champs spécifiés par exemple la marque , modèle , durée de
garantie …, finalement la table des matériels se remplie automatiquement s’il existe des
résultats sinon un message apparait dit que aucun résultat trouvé après ça soit rechercher à
nouveau ou quitter la fenêtre de recherche.
Le diagramme d’activités suivant (Figure 25) présente la recherche d’un matériel du parc
informatique.
38 Chapitre 3 : Conception
Figure 25 : diagramme d’activité ‘Rechercher un matériel ’
4. Description de la base de données
4.1. Le modèle logique des données du l’application (MLD)
A partir de l’analyse que j’ai déjà faite lors de la partie analyse du projet, j’ai dégagé un
ensemble d’entités et de dépendances, cela a été traduit par ce modèle de conception de la base
de données qui modélise le système réel étudié.
L’application de gestion de base de données a besoin d’une base de données robuste qui va
contenir un nombre très importants de données ce qui donne une interaction de données et de
l’application souple et sans difficulté c’est pourquoi j’ai choisi la méthode d’analyse merise.
Le diagramme MLD suivant (Figure 26) présente le schéma général de la base de données
réalisé.
39 Chapitre 3 : Conception
Figure 26 : Le modèle logique des données du l’application
40 Chapitre 3 : Conception
4.2. Description des tables
Dans cette partie je vais expliquer les plus importantes tables puisque le schéma contient plus
de 30 tables.
Le champ Rédacteur nous permet de savoir qui est l’utilisateur qui a ajouté un enregistrement
dans une table.
4.2.1. La table ‘ Société ’
Figure 27 : la table ‘ Société ’
Cette table représente la société qui sert à enregistrer les données qui lui concernent le nom,
l’adresse, code postal, la ville …
L’acteur qui remplit cette table à l’aide de l’application est le superviseur
4.2.2. La table ‘ Département ’
Figure 28 : la table ‘ Département ’
Le MLD qu’on a déjà vu chaque société à au moins un département par exemple département
vente, marketing, comptabilité…
41 Chapitre 3 : Conception
4.2.3. La table ‘ Service ’
On voit ici la clé ‘ IDDepartement ’ existe dans cette table ce qui signifie la relation directe
entre elle et la table département c.à.d. chaque département à des services.
Par exemple on peut trouver dans le département marketing le service publicité…
4.2.4. La table ‘ Utilisateur ’
L’une des plus importantes table de cette application, un utilisateur peut s’exister dans un seul
service qui un département de la société.
Cette table contient le nom d’utilisateur, prénom, téléphone, securid est un numéro privé de
l’utilisateur, login et mot de passe, commentaire pour additionner des informations
supplémentaires sur l’utilisateur, fichier lié par exemple il peut être un document ou une image
de l’utilisateur.
Figure 29 : la table ‘ Service ’
Figure 30 : la table ‘ Utilisateur ’
42 Chapitre 3 : Conception
4.2.5. La table ‘ Matériel ’
Cette table contient les informations détaillées sur un matériel, on trouve tous ce qui concerne
la location, la commande, date d’acquisition et d’achat, prix d’achat en cas ou le matériel est
acheté, durée de garantie …
Aussi on trouve que cette table est reliée avec les tables suivantes : modèle, type par exemple
un ordinateur ou imprimante …, fournisseur, machine (poste de travail), contrat et type de
garantie.
Figure 31 : la table ‘ Matériel ’
43 Chapitre 3 : Conception
4.2.6. La table ‘ Machine ’
Une machine comme on a déjà dit est un poste de travail du parc informatique, on trouve des
champs sur cette table comme : le nom, description, Affecté ou non, prête ou non, la date
d’affectation…
La table est en relation avec la table utilisateur puisqu’une machine peut contenir un ou
plusieurs utilisateurs.
4.2.7. La table ‘ Accessoire ’
Cette table concerne les accessoires des machines, les informations qui concerne un accessoire
sont : le nom, référence, type, modèle, prix unitaire, quantité, la facturation et la commande…
On peut trouver comme accessoires : souris, claviers, câbles, hubs ….
Figure 32 : la table ‘ Machine ’
Figure 33 : la table ‘ Accessoire ’
44 Chapitre 3 : Conception
La table est relié directement avec la table marque et fournisseur.
4.2.8. La table ‘ Fournisseur ’
Là on trouve des fournisseurs du parc informatique soit des autres sociétés ou des personnes.
Cette table contient les champs comme il est indiqué sur la figure ci-dessous.
4.2.9. La table ‘ Logiciel ’
Les logiciels sont aussi importants que les matériels, c’est l’esprit vivant de la société, cette
table contient les logiciels avec leur noms, numéros de série, licences, prix d’achat unitaire et
total …
La table est en relation avec la table fournisseur et la table éditeur.
Figure 34 : la table ‘ Fournisseur ’
Figure 35 : la table ‘ Logiciel ’
45 Chapitre 3 : Conception
4.2.10. La table ‘ Loueur ’
Le loueur est la personne qui prend un matériel pour une période bien définie, il a comme
caractéristiques : nom, adresse, code postale, contact, email ….
4.2.11. La table ‘ Contrat ’
Chaque opération de location d’un matériel nécessite un contrat entre le locateur et la société
donc c’est le rôle de cette table qui contient comme champs : date de début de location,
commande de loueur, les frais, cotisation par mois, la durée de location …
Cette table est reliée avec la table loueur et la table société.
Figure 36 : la table ‘ Loueur ’
Figure 37 : la table ‘ Contrat ’
46 Chapitre 3 : Conception
4.2.12. La table ‘ Paramètre ’
Cette table contient les paramètres de l’application concernant les alertes, on trouve par exemple
si la durée de contrat a dépassé le paramètre ‘ échéance contrat ’ une alerte s’affiche lors du
lancement du l’application, la même chose s’applique aux autres paramètres.
4.2.13. La table ‘ Réparateur ’
Les réparateurs sont des personnes qui faire des réparations au matériels du parc il peut s’agit
des ordinateurs, imprimantes, routeurs …
Figure 38 : la table ‘ paramètre ’
Figure 39 : la table ‘ Réparateur ’
47 Chapitre 3 : Conception
4.2.14. La table ‘ Demande intervention ’
Cette table est très importante, La gestion des interventions permet de suivre les incidents gérer
en interne et/ou donnant lieu à une réparation, un retour en garantie.
La création d'une intervention nécessite un code, un numéro de série, une date de demande et
un objet.
La clôture d'une intervention se fait en renseignant la date de fin d'intervention.
Cette table est en relation avec les tables : matériel, machine, utilisateur (intervenant), service,
département et finalement la société.
Conclusion
Ce chapitre a donnée l’aspect conceptuel de l’application de la Gestion du parc informatique,
où j’ai détaillé l’aspect workflow du composant du parc, quel que soit matériel, logiciels,
utilisateurs …
Le chapitre suivant fera l’objet d’une étude technique qui justifiera le choix des technologies
pour la réalisation de l’application.
Figure 40 : la table ‘ Demande intervention ’
48 Chapitre 4 : Etude technique du projet
Chapitre 4 : Etude technique du projet
Ce chapitre met la lumière sur la plateforme utilisée et les outils de développement adoptés
avec la justification de chaque utilisation d’un outil afin de mettre en œuvre l’application de
gestion du parc informatique.
1. L’environnement WinDev
1.1 Présentation WinDev
WinDev 18 permet de gérer, étape par étape, de la conception à la finalisation, le cycle complet
du développement d’une application.
WinDev permet de réaliser toutes les applications dont vous rêvez.
L’environnement WinDev se présente de la manière suivante (figure 41 ci-dessous) :
Figure 41 : Environnement WinDev
WinDev 18 permet de créer des applications qui gèrent des données. Les applications WinDev
accèdent à toutes les bases données, relationnelles ou non du marché. Toutes les bases de
données sont supportées. WinDev 18 est livré en standard avec :
49 Chapitre 4 : Etude technique du projet
• Hyper File Classic, une puissante base de données relationnelle, déjà utilisée sur des
millions de sites.
• Hyper File Client/ Serveur, une puissante base données relationnelle Client/ Serveur.
WinDev 18 propose certainement l’environnement de travail le plus puissant, le plus facile et
le plus intégré du marché ! Les Développeurs Créeront facilement des superbes applications.
L’éditeur de fenêtres de WinDev 18 est 100% WYSIWYG (« ce que vous voyez est ce que
vous aurez »). Il permet de réaliser facilement de superbes fenêtres reliées aux données.
1.2 Argumentaires généraliste WINDEV
Logiciel commercialisé pour la première fois en 1993, il dispose d’une expérience hors du
commun.
WINDEV a évolué sans cesse depuis sa création, a innové et innove sans relâche pour le plus
grand bénéfice de ses utilisateurs.
Précurseur dans le domaine du « Framework » (mis en place dès 1993), de l’intégration totale
des outils nécessaires à la gestion du cycle de vie des applications, du déploiement libre et
gratuit, et chantre de l’ouverture totale à toutes les technologies. Numéro un incontesté en
France depuis des années, il n’est pas près de laisser sa place à quiconque, principalement en
raison de son évolution permanente dans le respect des besoins réels des équipes de
développement.
Aujourd’hui en version 19, WINDEV, comme son célèbre slogan l’affirme, permet de
développement réellement « 10 fois plus vite », pour le plus grand bénéfice des développeurs
et des utilisateurs.
1.3 Que fait-on avec WinDev
WinDev est un AGL (Atelier de Génie Logiciel). Il vous permet de développer des applications
dans tous les domaines :
 Gestion (Comptabilité, Paie, Finances, Commerce, Stock, ERP, CRM, EAI,
EDI, VPC, GRM, …) ;
 Industrie (Robots, Caisses, Automates, Balances, Lecteur de badge, Supervision, …) ;
 Médical ;
 Multimédia ;
 Internet ;
 Accès Distant...
50 Chapitre 4 : Etude technique du projet
WinDev est un outil de développement complet qui intègre tous les outils nécessaires au cycle
de réalisation d’une application.
Contrairement à d’autres langages de développement traditionnels, il n’est pas de chercher et
de rajouter des modules pour concevoir, tester et installer une application.
Le L5G (Langage de 5éme Génération) de WinDev, le WLangage, vous étonnera par sa
simplicité : quelques heures suffisent pour appréhender le langage, une semaine suffit en
général pour maitriser toute sa puissance.
Comme il est en français, le WLangage (disponible également en anglais) vous fera gagner du
temps.
1.4 L’argumentaire technique
Les technologies innovantes mises en œuvre par WINDEV profitent de la maturité de celui-ci.
La réalité du terrain est souvent éloignée des théories des instituts d’analyse et de prospective…
Les besoins de performance des utilisateurs sont une réalité qui ne permet aucuns errements.
Une entreprise n’est en général pas un laboratoire de recherche et doit utiliser des logiciels
robustes, rapides et qui répondent aux besoins réels des utilisateurs.
WINDEV s’appuie sur des technologies éprouvées, aux performances et à la sécurité qui
permettent une utilisation réelle.
Les équipes de PC Soft travaillent en permanence surtouts les technologies émergentes, mais
n’implémentent pas celles qui sont manifestement immatures ou dangereuses ou vouées
indubitablement à l’échec.
WINDEV et WEBDEV évoluent en permanence.
Il est important que les solutions mises en œuvre soient pérennes : c’est le cas avec WINDEV,
depuis sa version 1.
WINDEV évolue souvent (en assurant la compatibilité avec l’existant).
1.5 Argumentaire Base de Données
WINDEV est ouvert à toutes les bases de données du marché : Oracle, SQL Server, MySQL,
AS/400, Sybase, Informix, DB2, Access, dbase, etc…; il est également livré avec la puissante
base de données HyperFileSQL.
L’accès aux bases de données s’effectue par ODBC, OLE DB ou nativement (A savoir : certains
accès natif doivent être acquis séparément).
51 Chapitre 4 : Etude technique du projet
A la différence des autres environnements, la structure des bases de données est connue de
l’environnement : cela permet d’automatiser et sécuriser les phases du développement et de
maintenance.
1.6 Argumentaire réactivité et vitesse de développement
C’est un lieu commun de dire que le monde bouge vite.
Les lois évoluent sans cesse, la concurrence est acharnée dans de nombreux secteurs, les besoins
sont souvent urgents.
Les applications informatiques doivent se conformer à ces évolutions. Il est donc nécessaire de
pouvoir créer et modifier vite des applications.
C’est là un avantage qui est le fondement même de WNDEV : sa vitesse de développement, ses
capacités de modification automatique, sa gestion intégrée de la base déployée (live-update en
particulier) permettent aux équipes une réactivité inconnue sans lui.
Seul WINDEV permet un développement robuste aussi rapide. Des projets qui demanderaient
plusieurs mois avec d’autres outils sont souvent réalisés en quelques jours avec WINDEV.
2. Architecture et outils
2.1 Architecture logicielle du système
Une architecture logicielle est un schéma d'organisation structurel fondamental pour les
systèmes logiciels. Elle fournit un jeu de sous-systèmes prédéfinis, spécifie leurs
responsabilités, et inclut les rôles et les instructions générales pour organiser les relations entre
eux. Sans une bonne architecture, un système d'information est difficile à comprendre, prédire,
gérer et optimiser. Les buts d'une architecture sont :
- La compréhension du système étudié, en définissant ses limites.
- La gestion de la croissance du système.
La future architecture du système doit satisfaire un certain nombre d’exigences telles que la
sécurité, la disponibilité et la maintenance.
Parmi les différentes façons de structurer une architecture, la mieux comprise et maîtrisée en
informatique est l'approche par couches. Une couche est une division logique, horizontale d'un
système qui fournit une abstraction particulière du système aux couches supérieures.
Chaque couche possède des responsabilités spécifiques. Dans une structuration par couches, les
couches inférieures prennent en charge des responsabilités qui offrent un socle de base pour les
52 Chapitre 4 : Etude technique du projet
couches supérieures, permettant d'abstraire celles-ci des problématiques qui ne les concernent
pas.
Aujourd'hui, les logiciels « Change On Demand» 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.
J’ai découpé mon application logicielle en cinq 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.
D'où le schéma récapitulatif suivant :
Figure 42 : Architecture logicielle
• Couche Présentation :
Cette couche est faite principalement pour gérer le domaine visuel de l’application et pour gérer
les interactions avec les utilisateurs. Chargée de dessiner les fenêtres et autres composants
graphiques, elle intercepte les événements et appelle la couche Service, après la vérification des
autorisations auprès d’un service de sécurité.
• Couche services :
53 Chapitre 4 : Etude technique du projet
C’est l’intermédiaire entre la couche métier et la couche présentation, cette couche expose
différentes entités proposant les services offerts par la couche métier, en effet, la couche
présentation ne manipule plus directement les objets métier de la couche métier mais passe par
des services. De cette manière, les fonctionnalités sont restreintes et la réduction des échanges
entre les couches est assurée.
• Couche métier :
Cette couche est concentrée sur le métier de l’application, c'est-à-dire les règles métier,
sémantiques et logiques. Sa charge principale consiste à garantir la validation sémantique de
l'information métier. Cette couche est basée sur le modèle objet.
• Couche Persistance :
Cette couche est certainement l'une des plus importantes. C'est dans cette couche que je trouve
les fonctionnalités de base qui permettent de créer, rechercher et supprimer des entités métier
dans le respect des propriétés transactionnelles. C'est également dans celle-là que les
mécanismes de conversion objet/relationnel peuvent prendre place.
• Couche Stockage :
Cette couche est responsable du stockage physique de données. Elle assure un support
transactionnel et elle est basée sur un modèle relationnel.
2.2 Choix des langages et outils
2.2.1 Modèle RAD
La méthode de Développement Rapide d'Applications, dite méthode RAD (acronyme de
l'anglais Rapid Application Development), est la première méthode de développement de
logiciels où le cycle de développement est en rupture fondamentale par rapport à celui des
méthodes antérieures. Ce nouveau cycle qualifié d'itératif, d'incrémental et d'adaptatif, se
retrouvera ensuite dans toutes les méthodes dites « agiles » publiées par la suite.
 Aperçu :
La méthode RAD, après deux courtes phases de formalisation structurée de l'expression des
besoins (CADRAGE) et de définition globale de l'architecture technique (DESIGN), inclut dans
sa phase principale(CONSTRUCTION) la réalisation, la validation immédiate et les tests d'une
application en mode itératif-incrémental-adaptatif. L'objectif de la méthode, qui implique
activement l'utilisateur final dans un principe de "validation permanente", est d'obtenir un
applicatif en adéquation avec les réels besoins.
54 Chapitre 4 : Etude technique du projet
Figure 43 : Avantages de Méthode RAD.
 Développement :
James Martina développé la méthode RAD à la fin des années 1980, à IBM, en se basant sur
les publications de Barry Boehm (modèle en spirale), Tom Gilb (cycle de vie évolutif), Scott
Shultz (production en itérations rapides) ainsi que Brian Gallagheret Alex Balchin. Il l'a
formalisée en la publiant en 1991.
Des compléments et des actualisations sont introduits à partir de 1994, notamment par Jean-
Pierre Vickoff pour l'aspect francophone (processus RAD2 publié par le Gartner Group) et
Jennifer Stapleton en Grande-Bretagne (processus DSDM).
L’apport de J. Martin avec la méthode RAD fut de formaliser techniquement le premier postulat
« agile », à savoir que pour qu'une prédiction de projet puisse se réaliser à tous les coups, il
fallait que certains aspects du pilotage soient d’autres soient variables. Il proposa des techniques
de priorisation pour gérer les deux principales variantes possibles de ces situations (délais fixe
ou budget fixe). Les notions additionnelles de visibilité, de risque et de fiabilité (ou de qualité)
comme variables de planification stratégique d’un projet furent introduites plus tard.
 Structure de la méthode :
La méthode RAD implique :
 Un cycle de développement sécurisant et court fondé sur un phasage simple : Cadrage,
Design, Construction et l’absolu respect d’une dimension temporelle (90 jours
optimum, 120 jours maximum) [Martin 1991].
 Une architecture de communication engageant des groupes de travail de structure et de
composition variable selon les besoins des phases et respectant un mode opératoire
précis structuré en trois étapes : précession, post post-session [Mucchielli 1987].
55 Chapitre 4 : Etude technique du projet
 Des méthodes, techniques et outils permettant de définir et d’appliquer des choix
portant sur quatre natures d'objectifs potentiellement contradictoires : budget, délais,
qualité technique, qualité fonctionnelle et visibilité [Vickoff 1998].
 Une architecture de conception s’appuyant sur les techniques de l'objet et
particulièrement sur celles qui permettent une conception «en vue de modifications»
[McCarty 1997].
 Une architecture de réalisation qui impose, pour garantir la qualité technique, des
normes minimales, des revues de projet, des jalons zéro défaut et qui recommande,
pour garantir la qualité fonctionnelle, le prototypage actif et les focus de visibilité
[McConnell 1996].
Figure 44 : Evolution d’un projet avec la méthode RAD
La méthode RAD structure le cycle de vie du projet en 5 phases (dont 3 systématiques) :
1. L’initialisation prépare communication.
2. Le CADRAGE définit un espace d’objectifs, de solutions et de moyens.
3. Le DESIGN modélise la solution et valide sa cohérence systémique.
4. La CONSTRUCTION réalise en prototypage
5. La finalisation est réduite à un contrôle final de qualité en site pilote.
56 Chapitre 4 : Etude technique du projet
Figure 45 : Parallélisassions et sérialisation des phases de projet avec la méthode RAD.
 Initialisation :
Préparation de l’organisation et communication.
Cette phase permet de définir le périmètre général du projet, de structurer le travail par thèmes,
de sélectionner les acteurs pertinents et d’amorcer une dynamique de projet. Cette phase
représente environ 6% du projet en charge.
 Cadrage :
Analyse et expression des exigences.
La spécification des exigences est du ressort des utilisateurs. Ils expriment leurs besoins lors
d’entretiens de groupe.
Il est généralement prévu de 2 à 5 jours de sessions par commission (thème). Cette phase
représente environ 9% du projet.
 Design :
Conception et modélisation.
Les utilisateurs sont également impliqués dans cette étape. Ils participent à l’affinage et à la
validation des modèles organisationnels : flux, traitements, données. Ils valident également le
premier niveau de prototype présentant l’ergonomie et la cinématique générale de l’application.
Il est prévu entre 4 et 8 jours de sessions par commission.
Cette phase représente environ 23% du projet. A partir de la phase de Design la parallélisassions
du travail est possible
 Construction :
Réalisation, prototypage.
57 Chapitre 4 : Etude technique du projet
Durant cette phase, l’équipe RAD (SWAT) doit construire l’application module par module.
L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des
prototypes. Plusieurs sessions itératives sont nécessaires. Cette phase représente environ 50%
du projet. A partir de la phase de Construction, à la parallélisassions du travail peut s’ajouter la
sérialisation.
 Finalisation :
Recette et déploiement.
Des recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phase
d’officialiser une livraison globale et de transférer le système en exploitation et maintenance.
Cette phase représente environ 12% du projet.
 Outils RAD :
La méthode, sans être liée aux outils, recommande l'utilisation d'outils de programmation à
interface graphique (CASE), qui permet d'obtenir rapidement des prototypes. A ce sujet, il ne
faut pas confondre la méthode RAD (d'où sont issues les approches Agiles actuelles) qui
recherche la qualité applicative fonctionnelle et technique avec les outils RAD, dont la
production automatique de code est souvent qualifiée de "sale".
• Powerbuilder
• uniPaaS (anciennement connu sous le nom de Magic eDeveloper) est une plateforme
RAD qui accélère le développement d'applications Métier en associant un paradigme de
développement unique de bout en bout à un moteur de règles fondé sur les métadonnées.
Le développement est accéléré de par le fait que le code est précompilé dans le système.
• Delphi (Lazarus ou ainsi que le Visual Basic) est un outil RAD en ce sens qu'il permet
assez facilement de créer des programmes à l'aide d'une interface graphique dotée de
nombreux outils et de modules prêts à l'emploi.
• WinDev (ainsi que WebDev) est un outil RAD plus avancé car il permet à partir d'une
analyse Merise ou UML de produire un applicatif final et opérationnel.
WinDev Mobile permet lui de créer rapidement des applications pour les matériels
mobiles.
• Authorware crée lui-aussi un applicatif final en dessinant un diagramme à l'aide
d'icônes.
• JBuilder
• C++ Builder
• C# Builder
• Leonardi est un outil RAD adapté au développement des IHM.
58 Chapitre 4 : Etude technique du projet
• Limbas est un outil RAD 100% web (développement et application cible) sous licence
GNU GPL 2 incluant notamment des fonctionnalités GED et Groupware.
2.2.2 WLangage
Le WLangage est un langage de programmation de 5éme génération inclus dans les outils de
développement WinDev, WebDev et WinDev Mobile. Il est propriétaire et ne peut être
manipulé qu'avec les outils PC SOFT. Le WLangage est né en 1992 avec la première version
de WinDev.
Même s'il y a explicitement une première phase précoce de compilation, le byte code WLangage
est exécuté par une machine virtuelle ou converti en code natif lors de l'exécution par un
compilateur à la volée (Just in time, JIT). Le Framework est disponible sous Windows (32 bits,
64 bits et CE) et partiellement sous Linux (sans interface graphique).
Le WLangage peut également s'appuyer sur le Framework Java pour une partie de ses
fonctionnalités, ce qui permet une indépendance relative et limitée du fichier exécutable par
rapport au système d'exploitation cible. Il en va de même dans WebDev, où le WLangage peut
s'appuyer sur le Framework PHP, sans toutefois permettre d'utiliser toutes les possibilités de ce
dernier.
Initialement prévu pour Windows, une partie des fonctions du WLangage est basée sur l'API
Microsoft Windows.
Le WLangage est un langage de programmation procédurale qui permet la programmation
impérative et la programmation orientée objet. C'est en fait un langage de programmation multi-
paradigme.
Le WLangage contient des fonctions de haut niveau, telle que la fonction EcranVersFichier,
qui effectue les affectations du contenu des champs d'une fenêtre vers des tables stockées dans
un fichier ou des variables, auxquelles les champs ont été préalablement reliés (databinding).
Le WLangage autorise une utilisation souple du typage. Les variables doivent être typées mais
les paramètres formels des procédures ou les itérateurs de boucles peuvent ne pas l'être. Il est
ainsi possible dans un même projet de combiner des procédures avec typage strict pour profiter
de la rigueur du typage statique et des procédures sans typage pour profiter de la souplesse du
typage dynamique et du duck typing.
2.3 Système de gestion de la base de données relationnelle
HyperFileSQL est un système de gestion de base de données relationnel exploité par les
logiciels WinDev, WebDev et WinDev Mobile.
59 Chapitre 4 : Etude technique du projet
Le système de gestion de base de données relationnelle HyperFileSQL nous permet de gérer
ces données en toutes sécurités. Les performances sont remarquables.
Utilisé sur plusieurs millions de postes à travers le monde, la flexibilité et l’évolutivité de
HyperFileSQL permettent de répondre aux besoins les plus exigeants des applications à mission
critique en temps réel.
2.3.1 Généralités :
HyperFileSQL est un puissant SGBDR (Système de Gestion de Base de Données
Relationnelle).
HyperFileSQL est décliné en trois versions :
• Version mobile (embarquée) ;
• Version locale (monoposte ou réseau) ;
• Version Client/ Serveur (et cluster).
HyperFileSQL est adapté à tous les types d’applications : applications métiers, applications
critiques temps réel, progiciels, serveurs d’applications, serveurs Web, PC stand-alone ou
périphériques mobiles.
2.3.2 Performance, Sécurité, Ouverture, Flexibilité :
HyperFileSQL est le choix idéal comme moteur de bases de données.
• Ouverture : basé sur les standards de l’industrie, HyperFileSQL ne vous enferme pas
dans une technologie propriétaire.
• Flexibilité : le support des volumes de données importants (plusieurs dizaines de
milliards de lignes dans une table) est assuré.
• Indépendance : vis-à-vis de la plateforme : les tables peuvent être déplacées d’un
Client/ Serveur vers un mobile, d’un serveur Windows vers un serveur linux, etc.…
• Extensibilité : vous passez sans contraintes d’un utilisateur à plusieurs centaines
d’utilisateurs, d’une architecture 2 tiers à une architecture multi-tiers…
• Econome ressources : le moteur client/serveur occupe moins de 20Mo sur disque.
HyperFileSQL fonctionne en environnement hétérogène : Windows, Linux, Mac, TSE,
Citrix, ADSL, VPN, Wi-Fi…
• La compatibilité ascendante et descendante des tables est assurée.
• Pérennité de l’éditeur : PC Soft est présent depuis plus de 25ans, et est n°1 en France
dans le monde des AGL.
• Performance : grâce à une gestion optimisée des index et une gestion affinée des
caches, la vitesse est permanente.
60 Chapitre 4 : Etude technique du projet
• Sécurité d’accès : la protection contre l’injection SQL est assurée via la création
automatique d’IHM sécurisées.
2.3.3 Coût d’usage (TCO) réduit :
Une caractéristique de HyperFileSQL est son déploiement illimité libre et gratuit.
Il n’y a aucun coût facturé, ni en fonction du nombre de processeur du serveur, ni en fonction
du nombre de postes client, ni annuellement, ni en fonction du type d’application…
HyperFileSQL est livré en une édition systématiquement complète, avec toutes les
fonctionnalités, gratuite. Les coûts de maintenance sont très réduits.
Figure 46 : HyperFileSQL
61 Chapitre 4 : Etude technique du projet
Conclusion
Ce chapitre avait comme but de présenter l’ensemble de mes recherches au niveau des
technologies et de l’environnement dans lequel s’inscrit mon projet, aussi j’ai introduit les
outils et les langages que j’ai utilisés pour la réalisation de mon application le chapitre suivant
présente la réalisation et la mise en marche de l’application
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique
Rapport Projet  de fin d'etude sur le parc informatique

Mais conteúdo relacionado

Mais procurados

Rapport stage pfe
Rapport stage  pfe Rapport stage  pfe
Rapport stage pfe rimeh moussi
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATSiwar GUEMRI
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique ayoub daoudi
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSFaissoilMkavavo
 
Rapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueRapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueEric Maxime
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...Hajer Dahech
 
Rapport de stage boite à idées innovantes avec dashboard
Rapport de stage boite à idées innovantes avec dashboardRapport de stage boite à idées innovantes avec dashboard
Rapport de stage boite à idées innovantes avec dashboardSiwar GUEMRI
 
réalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiquesréalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiquesMedk Salhi
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Yasmine Tounsi
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Karim Ben Alaya
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCGhodbane Heni
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEOussama Djerba
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidBadrElattaoui
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...Madjid Meddah
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webSalma Gouia
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileNader Somrani
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Anouar Kacem
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Mohamed Aziz Chetoui
 

Mais procurados (20)

Rapport stage pfe
Rapport stage  pfe Rapport stage  pfe
Rapport stage pfe
 
rapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSATrapport PFE ingénieur génie logiciel INSAT
rapport PFE ingénieur génie logiciel INSAT
 
Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique Rapport du Projet de Fin d'année Génie informatique
Rapport du Projet de Fin d'année Génie informatique
 
Conception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTSConception et Réalisation Application Web Laravel PFE BTS
Conception et Réalisation Application Web Laravel PFE BTS
 
Rapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueRapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc Informatique
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...Rapport  PFE  "Conception et développement d'un Portail web pour le Smart Met...
Rapport PFE "Conception et développement d'un Portail web pour le Smart Met...
 
Rapport de stage boite à idées innovantes avec dashboard
Rapport de stage boite à idées innovantes avec dashboardRapport de stage boite à idées innovantes avec dashboard
Rapport de stage boite à idées innovantes avec dashboard
 
réalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiquesréalisation une application web de gestion des informations météorologiques
réalisation une application web de gestion des informations météorologiques
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 12 (PFE Licence)
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
 
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNCRappport PFE 2012 Ghodhbane Hani - OpenSNC
Rappport PFE 2012 Ghodhbane Hani - OpenSNC
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 

Destaque

Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiquejihene Ab
 
Projet de fin d'etude sur le parc informatique
Projet  de fin d'etude sur le parc informatiqueProjet  de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatiqueHicham Ben
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Sofien Benrhouma
 
PFE : ITIL - Gestion de parc informatique
PFE : ITIL - Gestion de parc informatiquePFE : ITIL - Gestion de parc informatique
PFE : ITIL - Gestion de parc informatiquechammem
 
Presentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskPresentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskRaef Ghribi
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Riadh K.
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRaef Ghribi
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebHarrathi Mohamed
 
présentation soutenance PFE.ppt
présentation soutenance PFE.pptprésentation soutenance PFE.ppt
présentation soutenance PFE.pptMohamed Ben Bouzid
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Ben Abdelwahed Slim
 
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...HAFID Ait Bihi
 
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...Ayoub Minen
 
Soutenance mémoire de fin d'études
Soutenance mémoire de fin d'étudesSoutenance mémoire de fin d'études
Soutenance mémoire de fin d'étudesFabrice HAUHOUOT
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesMajdi SAIBI
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Ilyas CHAOUA
 
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...Arnold Stellio
 
Soutenance De Stage
Soutenance De StageSoutenance De Stage
Soutenance De Stageguesta3231e
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Anas Riahi
 

Destaque (20)

Projet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatiqueProjet de fin d'etude gestion informatique
Projet de fin d'etude gestion informatique
 
Projet de fin d'etude sur le parc informatique
Projet  de fin d'etude sur le parc informatiqueProjet  de fin d'etude sur le parc informatique
Projet de fin d'etude sur le parc informatique
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 
PFE : ITIL - Gestion de parc informatique
PFE : ITIL - Gestion de parc informatiquePFE : ITIL - Gestion de parc informatique
PFE : ITIL - Gestion de parc informatique
 
Presentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help deskPresentation pfe gestion parc informatique et help desk
Presentation pfe gestion parc informatique et help desk
 
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
Rapport PFE : Développement D'une application de gestion des cartes de fidéli...
 
Rapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et HelpdeskRapport de pfe gestion de parc informatique et Helpdesk
Rapport de pfe gestion de parc informatique et Helpdesk
 
Rapport De PFE
Rapport De PFERapport De PFE
Rapport De PFE
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site Web
 
présentation soutenance PFE.ppt
présentation soutenance PFE.pptprésentation soutenance PFE.ppt
présentation soutenance PFE.ppt
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
 
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
Projet de fin d'études licence Pro TCF Université Ibn Zohr Agadir {Gestion de...
 
Rapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFERapport Projet Fin d'Études PFE
Rapport Projet Fin d'Études PFE
 
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
Rapport projet de fin d'études: Elaboration d’un tableau de bord et politique...
 
Soutenance mémoire de fin d'études
Soutenance mémoire de fin d'étudesSoutenance mémoire de fin d'études
Soutenance mémoire de fin d'études
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'études
 
Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...Conception et réalisation d’un Système d’information des étudiants du départe...
Conception et réalisation d’un Système d’information des étudiants du départe...
 
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
Memoire de fin d'études pour le diplome de Chef de Projet Informatique et Rés...
 
Soutenance De Stage
Soutenance De StageSoutenance De Stage
Soutenance De Stage
 
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
Rapport PFE : Réalisation d'une application web back-office de gestion pédago...
 

Semelhante a Rapport Projet de fin d'etude sur le parc informatique

Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti MohammedMohammed JAITI
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...younes elmorabit
 
Rapport-de-perfectionnement-Jasser-Degani.pdf
Rapport-de-perfectionnement-Jasser-Degani.pdfRapport-de-perfectionnement-Jasser-Degani.pdf
Rapport-de-perfectionnement-Jasser-Degani.pdfAlaChihaoui1
 
1601896849 rapport fluttercopie
1601896849 rapport fluttercopie1601896849 rapport fluttercopie
1601896849 rapport fluttercopieRamiJOUDI2
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !Massimo Russo
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !Massimo Russo
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Adem Amen Allah Thabti
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesHosni Mansour
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...Mohamed Amine Mahmoudi
 
hasnfra3rapp113.pdf
hasnfra3rapp113.pdfhasnfra3rapp113.pdf
hasnfra3rapp113.pdfnassimatorby
 
Thèse Bureautique 2.0 - Stephane LAU
Thèse Bureautique 2.0 - Stephane LAUThèse Bureautique 2.0 - Stephane LAU
Thèse Bureautique 2.0 - Stephane LAUstephou85
 
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Alexis Legrand
 
POO en C++
POO en C++POO en C++
POO en C++elharraj
 
Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8HORIYASOFT
 
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...Khadidja BOUKREDIMI
 
Développement d’une application de gestion des licences des contrôleurs aériens
Développement d’une application de gestion des licences des contrôleurs aériensDéveloppement d’une application de gestion des licences des contrôleurs aériens
Développement d’une application de gestion des licences des contrôleurs aériensGhassen Chaieb
 

Semelhante a Rapport Projet de fin d'etude sur le parc informatique (20)

Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
 
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...Rapport PFE: PIM (Product Information Management) - A graduation project repo...
Rapport PFE: PIM (Product Information Management) - A graduation project repo...
 
Rapport-de-perfectionnement-Jasser-Degani.pdf
Rapport-de-perfectionnement-Jasser-Degani.pdfRapport-de-perfectionnement-Jasser-Degani.pdf
Rapport-de-perfectionnement-Jasser-Degani.pdf
 
1601896849 rapport fluttercopie
1601896849 rapport fluttercopie1601896849 rapport fluttercopie
1601896849 rapport fluttercopie
 
Rapport PFE2021.pdf
Rapport PFE2021.pdfRapport PFE2021.pdf
Rapport PFE2021.pdf
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
 
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
La VoIP, une solution d'avenir pour les entreprises... mais pas seulement !
 
Deploy automatic in the cloud
Deploy automatic in the cloudDeploy automatic in the cloud
Deploy automatic in the cloud
 
Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...Conception et développement d'une marketplace basée sur l'architecture micros...
Conception et développement d'une marketplace basée sur l'architecture micros...
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...Rapport (Mémoire de Master) de stage PFE pour  l’obtention du Diplôme Nationa...
Rapport (Mémoire de Master) de stage PFE pour l’obtention du Diplôme Nationa...
 
hasnfra3rapp113.pdf
hasnfra3rapp113.pdfhasnfra3rapp113.pdf
hasnfra3rapp113.pdf
 
Thèse Bureautique 2.0 - Stephane LAU
Thèse Bureautique 2.0 - Stephane LAUThèse Bureautique 2.0 - Stephane LAU
Thèse Bureautique 2.0 - Stephane LAU
 
Rapport de stage
Rapport de stage Rapport de stage
Rapport de stage
 
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
Mémoire_SciencesPo_Alexis-Legrand_L’INTERNET-DES-OBJETS,-UN-PAS-VERS-LA-TRAN...
 
POO en C++
POO en C++POO en C++
POO en C++
 
Tpe nguyen tien-thinh
Tpe nguyen tien-thinhTpe nguyen tien-thinh
Tpe nguyen tien-thinh
 
Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8Migration gmao de openerp 6.1 vers odoo 8
Migration gmao de openerp 6.1 vers odoo 8
 
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
AUTOMATISATION DU DEPLOIEMENT ET DE LA GESTION DES RESEAUX VIRTUELS DANS LE C...
 
Développement d’une application de gestion des licences des contrôleurs aériens
Développement d’une application de gestion des licences des contrôleurs aériensDéveloppement d’une application de gestion des licences des contrôleurs aériens
Développement d’une application de gestion des licences des contrôleurs aériens
 

Rapport Projet de fin d'etude sur le parc informatique

  • 1. Mémoire de Fin d’Etudes Pour l’obtention du diplôme D’Ingénieur d’Etat Génie Informatique Promotion 2013 – 2014 Développement d’une application de gestion d’un parc informatique M. Hicham BENMOUSSA Soutenance le 26 Juin 2014 Membres de jury : M. Souhail CHELBAT Encadrant Société M. Youness TABII Encadrant ENSATé M. Mohamed LAZAAR Enseignant ENSATé M. Mohamed CHRAYEH Enseignant ENSATé Année Universitaire : 2013-2014
  • 2. Remerciements Il m’est agréable de m’acquitter d’une dette de reconnaissance auprès de toutes les personnes, dont l’intervention au cours de mon stage, a favorisé son aboutissement. Ainsi, j’exprime ma profonde gratitude et je tiens à remercier M. Safi Mustafa de m’avoir accordé l’opportunité de passer mon stage de fin d’études au sein de la société ADDLOG. Je remercie aussi infiniment toutes les personnes qui m’ont aidées à m’intégrer au sein de la société et qui m’ont encadrées tout au long de mon stage parleurs directives précieuses, conseils pertinents, à citer M. CHELBAT Souhail mon encadrent société, EL BAKKALI Mohamed qui m’ont accompagnés durant le stage au sein de la société et Mr ACHRAK Mehdi qu’y a permis, en grande partie, de trouver ce stage. Sans oublier M. TABII Youness, mon encadrant à l’école, auquel j’adresse tous mes sentiments de reconnaissance les plus distingués. Mes vifs remerciements s’adressent également aux membres du jury qui ont accepté d’évaluer mon travail. Enfin, j’espère que ce travail sera à la hauteur et pourra répondre aux attentes et exigences auxquels il a été destiné. BENMOUSSA Hicham
  • 3. Résumé Dans le cadre de mon projet de fin d’études à l’Ecole Nationale des Sciences Appliquées de Tétouan (ENSAT) et en vue de l’obtention du titre d’ingénieur d’état en informatique, j’ai effectué un stage de quatre mois à ADDLOG. Durant mon séjour dans ladite société, j’avais pour mission dans un premier temps de concevoir et de réaliser une application de gestion d’un parc informatique en suivant un cycle de vie qui commence à l’étape de la conception/production/création jusqu'à la publication finale dans le parc informatique en passant par les étapes de la vérification, de la validation et de l’approbation. Dans un deuxième temps, j’étais amené à intégrer mon application dans le portail interne de la société et assurer son opérabilité avec les différentes applications de son système d’information. Mon projet suit le model de cycle de vie en V, l’utilisation du formalisme UML pour la réalisation de l’ensemble de diagrammes et enfin la modélisation MERISE puisqu’on nécessite une base de données robuste, vise à détourner le problème. Ainsi, au terme de ce projet, j’ai pu : • Etablir une étude fonctionnelle et technique globale qui servira par la suite à continuer la réalisation du système de gestion de parc informatique. • Intégrer l’application dans le système d’information de la société
  • 4. Liste des figures Figure 1 : l’organigramme de la société ADDLOG .................................................................4 Figure 2 : les marques des matériels de la société ADDLOG ..................................................7 Figure 3 : les marques des matériels réseaux de la société ADDLOG......................................7 Figure 4 : Le model de cycle de vie en V ................................................................................9 Figure 5 : Diagramme de gant.................................................................................................9 Figure 6 : La navigation dans l'application............................................................................14 Figure 7 : Diagramme des cas d'utilisations de l'application..................................................18 Figure 8 : Diagramme de séquence du processus de visualisation des matériels ....................20 Figure 9 : fenêtre du cas d’utilisation ‘Consulter les matériels’ .............................................21 Figure 10 : Diagramme de séquence du processus de l’affichage des matériels achetés dans une période...........................................................................................................................22 Figure 11 : fenêtre du cas d’utilisation ‘Afficher les matériels achetés dans une période’......23 Figure 12 : Diagramme de séquence du processus de l’ajout d’un nouveau matériel .............24 Figure 13 : fenêtre du cas d’utilisation ‘ ajouter un nouveau matériel ’..................................25 Figure 14 : Diagramme de séquence du processus de la modification du logiciel ..................26 Figure 15 : fenêtre du cas d’utilisation ‘ modifier un logiciel ’ ..............................................27 Figure 16 : Diagramme de séquence du processus de la création d’un groupe et la modification de ses droits .....................................................................................................28 Figure 17 : fenêtre du cas d’utilisation ‘ gestion des groupes d’utilisateurs ’ .........................29 Figure 18 : Diagramme de séquence du processus de la visualisation l’historique des connexions d’un utilisateur ………………………………………………………………...30 Figure 19 : fenêtre du cas d’utilisation ‘ gestion des connexions des utilisateurs ’ .................31 Figure 20 : schéma de l’architecture technique de l’application du parc ................................33 Figure 21 : diagramme d’activité ‘ Gestion des logiciels ’.....................................................34 Figure 22 : diagramme d’activité ‘ Gérer les utilisateurs ’.....................................................35 Figure 23 : diagramme d’activité ‘ Gérer les droits d’accès ’.................................................36 Figure 24 : diagramme d’activité ‘Attribuer un utilisateur à une machine ’ ...........................37 Figure 25 : diagramme d’activité ‘Rechercher un matériel ’..................................................38 Figure 26 : Le modèle logique des données du l’application .................................................39 Figure 27 : la table ‘ Société ’...............................................................................................40 Figure 28 : la table ‘ Département ’......................................................................................40
  • 5. Figure 29 : la table ‘ Service ’...............................................................................................41 Figure 30 : la table ‘ Utilisateur ’..........................................................................................41 Figure 31 : la table ‘ Matériel ’ .............................................................................................42 Figure 32 : la table ‘ Machine ’.............................................................................................43 Figure 33 : la table ‘ Accessoire ’ .........................................................................................43 Figure 34 : la table ‘ Fournisseur ’ ........................................................................................44 Figure 35 : la table ‘ Logiciel ’..............................................................................................44 Figure 36 : la table ‘ Loueur ’ ...............................................................................................45 Figure 37 : la table ‘ Contrat ’...............................................................................................45 Figure 38 : la table ‘ paramètre ’...........................................................................................46 Figure 39 : la table ‘ Réparateur ’ .........................................................................................46 Figure 40 : la table ‘ Demande intervention ’ ........................................................................47 Figure 41 : Environnement WinDev .....................................................................................48 Figure 42 : Architecture logicielle.........................................................................................52 Figure 43 : Avantages de Méthode RAD...............................................................................54 Figure 44 : Evolution d’un projet avec la méthode RAD.......................................................55 Figure 45 : Parallélisassions et sérialisation des phases de projet avec la méthode RAD. ......56 Figure 46 : HyperFileSQL ....................................................................................................60 Figure 47 : logo du logiciel Edraw MAX..............................................................................64 Figure 48 : Logo du l’atelier génie logiciel WinDev 18.........................................................65 Figure 49 : fenêtre d’authentification....................................................................................66 Figure 50 : fenêtre compte administrateur.............................................................................66 Figure 51 : fenêtre de l’administration des utilisateurs et les groupes ....................................67 Figure 52 : fenêtre de l’ajout d’un nouvel utilisateur.............................................................68 Figure 53 : fenêtre de la gestion des droits ............................................................................69 Figure 54 : paramétrage des droits pour la fenêtre ‘ Fiche département ’...............................69 Figure 55 : fenêtre des statistiques de connexion de l’application..........................................70 Figure 56 : fenêtre des statistiques de connexion de l’application..........................................70 Figure 57 : fenêtre principale de l’application.......................................................................71 Figure 58 : Alerte de l’expiration de la garantie d’un matériel...............................................72 Figure 59 : La liste des entreprises et la fiche de création d’une nouvelle entreprise..............72 Figure 60 : La liste des utilisateurs (employeurs) et la fiche de création d’un nouvel employé .............................................................................................................................................73 Figure 61 : La liste des matériels et la fiche d’ajout d’un nouvel matériel .............................74
  • 6. Figure 62 : Rechercher un matériel .......................................................................................75 Figure 63 : La liste des logiciels et la fiche d’ajout d’un nouvel logiciel................................75 Figure 64 : La liste des machines (poste de travail) et la fiche d’ajout d’une nouvelle machine .............................................................................................................................................76 Figure 65 : Architecture MVC..............................................................................................80 Figure 66 : Différence entre la théorie (les spécifications) et la pratique (ce qui a été produit) .............................................................................................................................................85
  • 7. Liste des tableaux Tableau 1 : références et partenaires de la société ADDLOG ..................................................6 Tableau 2 : Acteurs du système ............................................................................................15 Tableau 3 : Répartition des rôles en fonction des étapes........................................................84 Tableau 4 : Documents en fonction des étapes......................................................................85
  • 8. Sommaire Introduction............................................................................................................................1 Chapitre 1 : Contexte général du projet.................................................................................3 1. Présentation de l’organisme d’accueil............................................................................3 1.1 La société ADDLOG :............................................................................................3 1.2 L’organigramme de la société :...............................................................................4 1.3. Les objectifs : ........................................................................................................4 1.4. Les activités :.........................................................................................................5 1.5. Produits :...............................................................................................................6 1.6. Les références et partenaires :................................................................................6 1.7. Les marques représentées : ....................................................................................7 2. Présentation du projet : objectifs et champ d’application................................................8 2.1. Présentation du projet ............................................................................................8 2.2. La démarche suivie................................................................................................8 Chapitre 2 : Etude et spécification des besoins....................................................................13 1. La navigation dans l’application ..................................................................................13 2. Identification des acteurs .............................................................................................14 3. Scénarios.....................................................................................................................15 3.1. Actions du fonctionnaire......................................................................................15 3.2. Actions du magasinier .........................................................................................15 3.3. Actions du comptable ..........................................................................................16 3.4. Actions du responsable........................................................................................16 3.5. Actions du superviseur ........................................................................................17 4. Les cas d’utilisation du système...................................................................................17 4.1. Cas d’utilisation ‘ Consulter les matériels et les logiciels ’...................................19 4.2. Cas d’utilisation ‘Afficher les matériels achetés dans une période ’ .....................21 4.3. Cas d’utilisation ‘ ajouter un nouveau matériel ’..................................................23 4.4. Cas d’utilisation ‘ modifier un logiciel ’...............................................................25
  • 9. 4.5. Cas d’utilisation ‘ gestion des groupes d’utilisateurs ’..........................................27 4.6. Cas d’utilisation ‘ gestion des connexions d’un utilisateur ’ .................................29 Chapitre 3 : Conception ......................................................................................................32 1. Stratégie de développement .........................................................................................32 2. Architecture technique de l’application........................................................................32 3. Comportement dynamique de l’application..................................................................34 3.1. Gestion des logiciels............................................................................................34 3.2. Gérer les utilisateurs............................................................................................34 3.3. Gérer les droits d’accès........................................................................................35 3.4. Attribuer un utilisateur à une machine .................................................................36 3.5. Rechercher un matériel........................................................................................37 4. Description de la base de données................................................................................38 4.1. Le modèle logique des données du l’application (MLD) ......................................38 4.2. Description des tables..........................................................................................40 Chapitre 4 : Etude technique du projet ................................................................................48 1. L’environnement WinDev ...........................................................................................48 1.1 Présentation WinDev............................................................................................48 1.2 Argumentaires généraliste WINDEV....................................................................49 1.3 Que fait-on avec WinDev .....................................................................................49 1.4 L’argumentaire technique .....................................................................................50 1.5 Argumentaire Base de Données ............................................................................50 1.6 Argumentaire réactivité et vitesse de développement ............................................51 2. Architecture et outils ...................................................................................................51 2.1 Architecture logicielle du système ........................................................................51 2.2 Choix des langages et outils..................................................................................53 2.3 Système de gestion de la base de données relationnelle.........................................58 Chapitre 5 : mise en œuvre du projet...................................................................................62 1. Présentation.................................................................................................................62
  • 10. 2. Réalisation de la solution.............................................................................................63 2.1 La couche Données : ............................................................................................63 2.2 La couche Mapping et Persistance : ......................................................................63 5.3 La couche Métier :................................................................................................63 5.4 La couche Services :.............................................................................................63 5.5 La couche Présentation :.......................................................................................63 3. Développement : .........................................................................................................63 3.1 Outils de développement : ....................................................................................63 3.2 Environnement de modélisation Edraw :...............................................................64 3.3 Environnement de développement WinDev ..........................................................65 4. Présentation de quelques interfaces..............................................................................65 Conclusion et perspectives....................................................................................................77 Bibliographie........................................................................................................................78 Webographie ........................................................................................................................79 Annexe 1 : Le Design Pattern MVC....................................................................................80 1. Le design pattern MVC ...............................................................................................80 1.1. Architecture MVC...............................................................................................80 2. Avantages et inconvénients..........................................................................................81 Annexe 2 : Le cycle de vie en V .........................................................................................83 1. Définition....................................................................................................................83 2. Les étapes....................................................................................................................83 3. Rôles ...........................................................................................................................83 4. Documents par phase...................................................................................................84 5. Risques inhérents au Cycle en V..................................................................................85 6. Comité de pilotage.......................................................................................................86
  • 11. 1 Développement d’une application de gestion d’un parc informatique Introduction La plupart des organisations possèdent aujourd’hui un réseau d'ordinateurs privé. Au travers de ce réseau, les postes échangent des fichiers, partagent des imprimantes et parfois utilisent des applicatifs (logiciels) en commun. De nos jours, la plupart des applicatifs de gestion ont une architecture client-serveur (les données sont sur le serveur qui assume l’essentiel du travail, le client ne fait qu’envoyer des requêtes). Ces applicatifs constituent le cœur de ce que l'on appelle le système d'information central. Ces applicatifs gèrent des plannings, des annuaires, des ressources, des stocks, des commandes, des livraisons, etc. Ce qui permet de mettre facilement à la disposition des employés des documents divers et variés et oblige un accès centralisé à la mémoire de l'entreprise. Il est donc généralement nécessaire de définir des droits d'accès pour les utilisateurs de l'intranet et par conséquent une authentification de ceux-ci afin de leur permettre un accès personnalisé aux fonctionnalités assurées par l’intranet. De cette façon, un intranet favorise la communication au sein de l'entreprise et limite les erreurs dues à la mauvaise circulation d'une information. Au sein de la société ADDLOG, ma mission était de choisir un portail répondant à ses exigences et le mettre en place. L’application de la Gestion de parc informatique après avoir été conçue et développée doit s’intégrer dans ce portail avec l’ensemble des applications du système d’information de la société. En effet, La gestion de parc permet de suivre en temps réel du patrimoine informatique, matériel et logiciel de l’entreprise. Elle offre une vision globale de l’état, du suivi et des coûts des appareils utilisés dans l’entreprise et de bien Gérer les différents types d’équipements (Unités Centrales, Ecrans, Imprimantes, Matériels Réseaux, Matériels non informatiques) ainsi que leurs Composants Hard et Soft (Processeurs, Mémoires, Disques durs, OS, Logiciels…) et aussi visant à assurer le bon fonctionnement des PC et serveurs. Le présent rapport décrit les différentes étapes de la réalisation du projet. Il comporte cinq chapitres. Le premier chapitre définit le contexte général du projet et se compose de deux parties. La première donne une présentation de la société au sein de laquelle j’ai effectué mon stage. Quant à La deuxième partie, elle est consacrée à la présentation du projet et ses objectifs. Le deuxième chapitre présente l’ensemble des spécifications du projet pour faire l’inventaire des différentes fonctionnalités du système à réaliser. Le troisième chapitre présente la phase conceptuelle du projet. L’étape de l’étude technique de l’application fait l’objet du quatrième chapitre, celle-ci dresse l’environnement dans lequel s’inscrit l’application ainsi que le choix
  • 12. 2 Développement d’une application de gestion d’un parc informatique du portail résultant d’une étude comparative passant au crible un ensemble de portails répondant aux exigences de la société. Enfin, le cinquième chapitre est consacré à la phase de la réalisation et la mise en œuvre du système. Il est constitué de deux parties, à savoir la partie réalisation dans laquelle on a décrit les outils que j’ai manipulés et la partie de la mise en marche de l’application qui présente quelques interfaces. Ce rapport se termine par une conclusion contenant quelques perspectives pour le système de gestion d’un parc informatique. En complément, on présente les différentes annexes qui serviront pour élargir la portée du projet tout en restant dans son environnement, à savoir la suite des spécifications du système, ainsi que quelques annexes traitant l’aspect technique et organisationnel du projet.
  • 13. 3 Chapitre 1 : Contexte général du projet Chapitre 1 : Contexte général du projet Dans ce chapitre je présente l'organisme d'accueil ADDLOG où s'est déroulé mon projet de fin d’études. Ensuite, je définis la problématique et les objectifs escomptés par le projet. 1. Présentation de l’organisme d’accueil 1.1 La société ADDLOG : Crée en 2004 par une équipe d’ingénieurs polyvalents ayant tous la volonté d’accompagner les entreprises du Nord Ma roc au cours de leur développement en matière des nouvelles technologies. En fait, elle préfère la dénomination « partenaires » pour désigner les entreprises qui lui font confiance pour les aider à s’adapter aux mutations constantes des nouvelles technologies de l’information. Aujourd’hui, elle a l’honneur d’affirmer sa réussite d’exposer cette vision à un grand nombre de partenaires, ce qui lui donne la passion d’être présent à côté du client pour être toujours à la hauteur des attentes. Pour cela, elle n’épargne aucun effort, et surtout pas celui de former et d’assister leur collaborateurs et partenaires.
  • 14. 4 Chapitre 1 : Contexte général du projet 1.2 L’organigramme de la société : Figure 1 : l’organigramme de la société ADDLOG 1.3. Les objectifs : Dans le cadre de sa vocation, ses objectifs sont :  Améliorer la position de ses clients sur un marché globalisé, en gagnant les défis qui leur permettent d’augmenter leur compétitivité ainsi que leurs perspectives de chiffre d’affaire.  Combiner son expérience avec ses ressources humaines de qualité pour innover et améliorer notre service client continuellement.
  • 15. 5 Chapitre 1 : Contexte général du projet 1.4. Les activités : 1.4.1. Réseaux et Systèmes : La configuration des réseaux est le point de départ de son service. Elle examine la situation initiale du client et concevra une infrastructure de réseaux qui s’ajuste à leur besoins. En tant que Partners certifiés de Cisco Systems, DELL et Microsoft et dans le cadre d’un suivi constant de l’évolution des nouvelles technologies, elle possède d’amples connaissances sur les environnements suivants :  Systèmes opérationnels Linux et Windows  Conception, installation et extension des réseaux informatiques.  Pose et installation de la fibre optique  Conception et installation des salles de serveurs et des équipements en Rack.  Equipement des salles de réunion par des systèmes de projection et D’audioconférence.  Système téléphonique analogique et solution VOIP.  Interconnexion des réseaux distants d’entreprises  Système de pointage.  Vidéosurveillance et système anti-intrusion. 1.4.2. Serveurs : Les serveurs disponibles dans la société ADDLOG sont :  Serveurs de messagerie (Microsoft Exchange server)  Serveurs de fichier et de partage avec une gestion d’accès aux ressources partagées.  Pare-feu et solutions de filtrage entrant /Sortant  Serveurs de backup pour des systèmes critiques. 1.4.3. Prestation de services et Maintenance Pour répondre aux exigences de ses clients, elle se base sur la compétence de son équipe technique, certifiée CISCO networks et Microsoft Systems, ainsi que sur l’expérience qu’elle a acquis dans ce domaine en travaillant avec des entreprises de grande envergure (la liste après ci-dessous), ainsi elle accompagne ses activités par quelque services pour mieux servir le client :  Service après-vente.  Maintenance informatique par intervention ou sous contrat de maintenance  Location des équipements : Imprimantes, photocopieurs ….
  • 16. 6 Chapitre 1 : Contexte général du projet 1.5. Produits : Les produits de la société varient beaucoup ce qui lui donne un avantage dans le marché. Voici une liste des produits et services de cette société :  Vente de Matériel Informatique : La société propose au client une large gamme de solution et de produits informatiques comme : DELL, FUJITSU SIEMENS, HP, IBM, CIS CO, CANON, LEXMARK, XEROX, …  Systèmes de pointage et gestion de personnels : Marque représentée : ACRONYM  Vidéosurveillance, Systèmes d’alarme et détection d’intrusion : Marque représentée : TEXECOM, JABLOTRON  Standard téléphonique et système VOIP : Marque représentée : NORTEL NETWORKS, LG-NORTEL Alcatel, Siemens, Système VOIP basé sur ASTE RISK. 1.6. Les références et partenaires : Voici la liste de quelques références et partenaires de la société ADDLOG (tableau 1 ci- dessous) AWSM1 COFICAB TAKATA TMSA Medi1TV SRPTM RENAULT MAROC EADS MAROC NUCAIN JOBELSA MAROC ZIMED CONSULTING TREMSA (San Jose Lopez) COFELY POLYDESIGN ARFADEL ADDOHA EUROGATE … Tableau 1 : références et partenaires de la société ADDLOG
  • 17. 7 Chapitre 1 : Contexte général du projet 1.7. Les marques représentées : Les marques des produits se varient beaucoup selon le besoin du client pour le satisfaire voici une liste des marques au niveau matériel : Et au niveau réseaux : Figure 2 : les marques des matériels de la société ADDLOG Figure 3 : les marques des matériels réseaux de la société ADDLOG
  • 18. 8 Chapitre 1 : Contexte général du projet 2. Présentation du projet : objectifs et champ d’application Dans cette partie, je présente le projet, les objectifs s’inscrivant dans le cadre de ce dernier et le champ d’application. 2.1. Présentation du projet Au terme d’une réunion entre le directeur de la société, mon encadrent et moi-même, j’ai convenu que la plus grande faiblesse du système d’information du ADDLOG était l’absence d’inventaire du parc informatique. Le projet a donc été définit comme la mise en place d’une solution de gestion de parc informatique capable d’inventorier automatiquement ce dernier. Ainsi, ADDLOG a exprimé un besoin pressant de mettre à niveau son système d’information et d’adopter un système efficace et ouvert afin de remédier aux problèmes de la gestion du parc informatique. Le but de l’application de la gestion du parc informatique est : • L’accès simple à l'information, • Classification, enregistrement et archivage des matériels achetés ou loués, • Gestion de la sécurité (droits d’accès aux fonctionnalités de l’application), • Gain du temps, • La gestion et la traçabilité de tous les processus de travail, • Communication souple entre les machines • L’évolutivité et l'anticipation des besoins futurs. La première phase du présent projet était de comprendre l’objectif du sujet et d’arriver à délimiter le champ de travail pour pouvoir intervenir par la suite de manière plus efficace. C’est ainsi que les premières entrevues avec mon encadrant m’ont permises de bien cerner le sujet dans son contexte et de dégager la problématique et les objectifs visés. Une fois que la vision sur le projet s’est éclaircie, il m’a été possible d’énumérer les fonctionnalités et de définir la méthodologie de travail et de faire la version préliminaire du projet et par la suite la version finale. 2.2. La démarche suivie 2.2.1. Cycle de vie du projet Le « cycle de vie d'un logiciel » (en anglais software lifecycle), désigne toutes les étapes du développement d'un logiciel, de l’idée à sa disparition. L'objectif d'un tel découpage est de permettre de définir des jalons intermédiaires permettant la validation du développement
  • 19. 9 Chapitre 1 : Contexte général du projet logiciel, c'est-à-dire la conformité du logiciel avec les besoins exprimés et la vérification du processus de développement, c'est-à-dire l'adéquation des méthodes mises en œuvre. L'origine de ce découpage provient du constat que les erreurs ont un coût d'autant plus élevé qu'elles sont détectées tardivement dans le processus de réalisation. Le cycle de vie permet de détecter les erreurs au plus tôt et ainsi de maîtriser la qualité du logiciel, les délais de sa réalisation et les coûts associés. 2.2.2. Approche, méthodologie et planning du projet Le model du cycle de vie adopté pour la réalisation de ce projet est le model en V, la figure ci- après (Figure 4) présente ce model sous ses différentes étapes : Figure 4 : Le model de cycle de vie en V L’ensemble des activités de ce model suivant le temps est : Figure 5 : Diagramme de gant
  • 20. 10 Chapitre 1 : Contexte général du projet  Etude de faisabilité et analyse des besoins : Il s’agit du recueil et de la formalisation des besoins du client selon mon encadrent dans la société (ADDLOG) et de l'ensemble des contraintes.  documentation sur les parcs informatiques et l'étude de l'existant : J’ai lit pas mal des articles sur les parcs informatiques comment ils fonctionnent, les principaux composants … . Et aussi j’ai fait du benchmarking sur les solutions libres et propriétaires des logiciels de gestion de parc informatique afin de prendre des idées sur ma future application.  Spécifications : Il s'agit de l'élaboration des spécifications de l'architecture générale du logiciel. Pendant laquelle j’ai décrit l’ensemble des cas d’utilisation du système avec proposition des maquettes d’Interface Homme/Machine répondant aux besoins.  Conception : J’ai décrit dans cette étape l’ensemble des tables, objets et activités de l’application et aussi la création du MCD après la génération du MLD du l’application et ainsi la génération de la base de données.  Codage : La traduction dans le langage de programmation choisi des fonctionnalités définies lors de la phase de la conception et j’ai réussi à développer l’application en sa totalité sans la réviser et corriger les erreurs ou faire la gestion des exceptions.  Tests unitaire ,tests d’intégration et modification et correction des erreurs : Permettant de vérifier individuellement que chaque sous-ensemble du logiciel est implémenté conformément aux spécifications et qu’il s’intégrera bien avec l’ensemble, et aussi la correction des erreurs d’orthographes et faire la gestion des exceptions et de manipulation de l’application  Tests de validation et recette finale : pour valider l’ensemble des spécifications du système conçu un test de validation est requis , aussi la mise en place de l’application répondant au cahier des charges défini. 2.2.3. Le méthode d’analyse et de modélisation MERISE : La méthode Merise est une méthode d'analyse, de conception et de réalisation de systèmes d'informations.
  • 21. 11 Chapitre 1 : Contexte général du projet En amont, elle se situait dans le prolongement naturel d'un schéma directeur, souvent conduit suivant la méthode RACINES, très présente notamment dans le secteur public. Les projets Merise étaient généralement des projets de grande ampleur de refonte d'un existant complexe, dans un environnement grand système. La méthode a aussi connu des tentatives d'adaptation avec les SGBD relationnels, les différentes interfaces homme-machine IHM, l'Orienté objet, le développement micro, les outils CASE, la rétro-ingénierie... mais qui n'ont pas connu le même succès. La méthode est essentiellement française. Elle a des équivalents à l'étranger en ce qui concerne les modèles de données (avec des différences, par exemple les cardinalités ne sont pas aussi détaillées dans les modèles anglosaxons). En revanche la modélisation des traitements est beaucoup plus complexe que dans les méthodes anglo-saxonnes. Sa mise en œuvre peut paraître lourde. On consacre beaucoup de temps à concevoir et à pré- documenter avant de commencer à coder, ce qui pouvait sembler nécessaire à une époque où les moyens informatiques n'étaient pas aussi diffusés qu'aujourd'hui. Cela dit, elle évite l'écueil inverse du développement micro, qui souffre du manque de documentation, et où les erreurs sont finalement très coûteuses à réparer a posteriori. Même si les échanges et la consultation entre concepteurs et utilisateurs sont formellement organisés, on a aussi reproché à Merise d'utiliser un formalisme jugé complexe (surtout pour les modèles de données), qu'il faut d'abord apprendre à manier, mais qui constitue ensuite un véritable langage commun, puissant et rigoureux pour qui le maîtrise. L'articulation très codifiée et bien balisée des différentes étapes, avec un descriptif très précis des résultats attendus est ce qui reste aujourd'hui de mieux connu et de plus utilisé. Pour mon projet j’ai utilisé MERISE pour concevoir seulement la base de données puisque cette application nécessite une base de données robuste. 2.2.4. Le langage de modélisation UML : Dans le but de concevoir un système extensible, évolutif, modulaire et orienté objet, le formalisme UML s’est imposé comme un outil performant afin d’élaborer ce projet. En effet, le langage de modélisation UML permet de mener la phase de conception tout en bénéficiant de la puissance et de la simplicité de ses diagrammes. UML est un langage de modélisation de troisième génération, normalisé par l'OMG (Object Management Group) début 1997. C'est une fusion des idées des méthodes Booch, OMT et OOSE (Object Oriented Software Engineering). Il a été conçu pour servir de langage de modélisation objet, indépendamment de la méthode de mise en œuvre.
  • 22. 12 Chapitre 1 : Contexte général du projet UML définit 9 diagrammes pour donner à l’utilisateur les moyens de visualiser et de manipuler des éléments de modélisation : diagrammes d’activités, diagrammes de cas d’utilisation, diagrammes de classes, diagrammes de collaboration, diagrammes de composants, diagrammes de déploiement, diagrammes d’états transitions, diagrammes d’objets et diagrammes de séquences. Le choix d’UML, comme outil de modélisation des flux et les différentes actions de l’application, peut être justifié par plusieurs raisons : • UML facilite la compréhension et la communication d’une modélisation objet, • La notation UML s'impose comme un standard de fait à l'heure actuelle sur le marché, • Il est adopté par les grands constructeurs de logiciel du marché, • L’utilisation d’UML offre l’avantage de disposer de vues de haut niveau d'abstraction, • Pour favoriser la communication entre utilisateurs, spécialistes et informaticiens. Conclusion Dans ce chapitre j’ai décrit le contexte général dans lequel s’inscrit le projet. Au début, j’ai présenté l’entreprise d’accueil à savoir ADDLOG. Ensuite, j’ai déterminé la problématique et les objectifs du projet qui se résument en la réalisation d’un système de gestion du parc informatique. Après, j’ai présenté la démarche que j’ai suivie pour arriver à mon but et cela par la présentation du processus de développement ou cycle de vie du projet que j’ai adopté en l’occurrence le model en V. Puis, le formalisme merise pour la conception de la base de données et aussi UML qui m’a servi de standard dans la réalisation des diagrammes de modélisation relatifs à notre projet et ce, afin d’illustrer son fonctionnement. Dans le chapitre suivant je présentera les spécifications du système.
  • 23. 13 Chapitre 2 : Etude et spécification des besoins Chapitre 2 : Etude et spécification des besoins Ce chapitre détaille les spécifications pour la réalisation de l’application de la ‘Gestion de parc informatique’. Il décrit l’ensemble des cas d’utilisation du système avec des propositions de prototypes d’Interfaces Homme/Machine (IHM) possibles pour l’application. En effet, le présent chapitre définira les interactions entre le collaborateur et l’application de la Gestion de parc informatique tout au long du cycle de vie des machines et des ordinateurs. Ce dernier commence de la phase de remplissage de différentes domaines de l’application (par exemple les utilisateurs, matériels, machines, réseaux …) en passant par les phases du paramétrage de l’application, et enfin d’établir des opérations sur les ordinateurs et les périphériques associés au réseau. Ainsi pour assurer le suivi de l’état du parc, on pourra définir beaucoup de types des utilisateurs : administrateurs, Magasinier, fonctionnaires, Comptables, réparateurs, responsables d’achats, …. 1. La navigation dans l’application La figure ci-après (Figure 6) décrit la navigation dans l’application Gestion de parc informatique.
  • 24. 14 Chapitre 2 : Etude et spécification des besoins Figure 6 : La navigation dans l'application (*) L’apparition des sous menu du menu principal varie selon l’utilisateur et ses droits 2. Identification des acteurs Le tableau ci-après (Tableau 2) illustre les différents acteurs du système.
  • 25. 15 Chapitre 2 : Etude et spécification des besoins Tableau 2 : Acteurs du système 3. Scénarios 3.1. Actions du fonctionnaire Le fonctionnaire est un collaborateur au sein du parc qui n’a pas des rôles supplémentaires dans l’application. Ci-après ses actions possibles : o Consulter les matériels et les logiciels o Imprimer la liste des matériels selon un critère o Rechercher un matériel ou logiciel o Filtrer les données afin de voir les matériels achetés dans une période o Imprimer des factures de l’achat du matériel ou logiciel 3.2. Actions du magasinier Le magasinier est aussi un collaborateur au sein du parc, c’est-à-dire qu’il possède toutes les actions citées précédemment en tant que fonctionnaire. De plus, il a des actions suivantes : o Saisir les informations du matériel et du logiciel o Mise à jour des informations sur les matériels et les logiciels (modification) o Affectation d’un matériel ou logiciel à un utilisateur du parc est un employé de la société qui va consulter les informations sur des matériels et des logiciels du parc Est la personne qui s’en charge de saisir les informations du matériel ou logiciel entré en respectant des règles de gestion précise est responsable de l'administration financière du parc, il paie des factures des fournisseurs et il est responsable de valider les contrats de la société Le rôle majeur est d’assurer l’évolution et la maintenance du par cet aussi de donner l’accord d’acquisition du matériel ou du logiciel et du staff Est en charge du paramétrage de la base et il fait la gestion de n’importe quelle composant du parc qui existe dans l’application (matériel, logiciel, machine, utilisateur,….) etc.
  • 26. 16 Chapitre 2 : Etude et spécification des besoins o prêter du matériel aux utilisateurs du parc o Récupérer le matériel déjà affecté o Rédaction d’une commande 3.3. Actions du comptable Le comptable est aussi un collaborateur au sein du parc, il a des actions concernant le domaine de comptabilité. Ci-après ses actions : o La gestion des contrats de location des matériels (création, modification, suppression) o Consultation des informations sur les utilisateurs du parc o Consulter le graphe de reporting concernant les matériels acheté depuis la création du parc o Affirmation de retour de garantie des matériels o Ecrire une nouvelle intervention o L’impression de : matériels en stock, les contrats de location, les retours en garantie… 3.4. Actions du responsable Le responsable est aussi un collaborateur au sein du parc, c’est-à-dire qu’il possède toutes les actions en tant qu’un magasinier et d’un fonctionnaire. De plus, il a des actions sur le parc auxquels il a été désigné comme responsable. Ci-après ses actions : o Gestion des utilisateurs du parc (ajouter, modifier, supprimer) o Mettre une sauvegarde des données o Récupération de données sauvegardées o Afficher les statistiques de connexions dans une période selon un utilisateur de l’application o Effectuer les achats informatiques (matériels ou logiciels) o Création d’une nouvel Intervention sur incident o Gestion des postes de travail (machines) o Gestion des fournisseurs o Faire le suivi des pannes et des réparations o Elaboration des besoins en matériel pour la maintenance o Remise les matériels en différents états (affecté, intervention réparation, …)
  • 27. 17 Chapitre 2 : Etude et spécification des besoins 3.5. Actions du superviseur Le superviseur de l’application pourrait lui aussi être considéré comme étant un fonctionnaire, magasinier et aussi d’un responsable au sein du parc. De plus, il a des actions supplémentaires dans l’application. Ci-après ses actions : o Création, modification, suppression des utilisateurs de l’application o Gestion des groupes d’utilisateurs o Mise hors service d’un matériel o Gestion des départements et les services de la société o Effacer les statistiques de connexions dans une période selon un utilisateur de l’application o Gestion des réparateurs et des loueurs o Paramétrage des alertes de différentes actions en cours 4. Les cas d’utilisation du système Le diagramme ci-après (Figure 7) illustre les différents cas d’utilisation de l’application de la Gestion du parc informatique résumant les différentes actions des acteurs, les sous parties suivantes détailleront les plus importants cas d’utilisation de mon application ainsi que des prototypes de fenêtres proposées.
  • 28. 18 Chapitre 2 : Etude et spécification des besoins Figure 7 : Diagramme des cas d'utilisations de l'application
  • 29. 19 Chapitre 2 : Etude et spécification des besoins 4.1. Cas d’utilisation ‘ Consulter les matériels et les logiciels ’ 4.1.1. Description du cas d’utilisation Ce cas d’utilisation permet de voir les différents matériels et logiciels en vue de leur ajout dans la base du parc informatique, dans cet exemple, je vais expliquer la partie matériel, la même démarche s’applique sur les logiciels. Ci-après l’ensemble des informations sur ce cas d’utilisation :  Acteurs : Les acteurs pouvant consultés les matériels et les logiciels sont : fonctionnaire, magasinier, responsable, superviseur de l’application  Pré-conditions : l’authentification dans l’application.  Action de départ : Accéder à l’application du parc.  Enchaînement :  Enter le nom d’utilisateur et le mot de passe  La vérification du système si les informations sont correctes  Si les informations sont erronées un message apparait qui dit que soit l’utilisateur n’existe pas soit le mot de passe est incorrect, sinon il accède au menu principale du l’application  Dans le menu matériel il clique sur liste des matériels pour les visualiser  Action de fin : quitter la fenêtre des matériels  Post-conditions : Aucune 4.1.2. Diagramme de séquence Le diagramme ci-après (Figure 8) illustre le processus de visualisation des matériels qui doit être précédé par une authentification.
  • 30. 20 Chapitre 2 : Etude et spécification des besoins Figure 8 : Diagramme de séquence du processus de visualisation des matériels 4.1.3. Fenêtre de la liste des matériels La figure ci-après (Figure 9) propose la fenêtre d’interface IHM pour la visualisation de la liste des matériels. Dans cette fenêtre l’acteur qui l’a accédé est le responsable car le fonctionnaire voit les boutons : nouveau, modifier, supprimer grisés.
  • 31. 21 Chapitre 2 : Etude et spécification des besoins Le double clic sur un matériel affiche ses détails, le bouton ‘ fermer ’ pour clôturer la fenêtre et revenir à la fenêtre principale. 4.2. Cas d’utilisation ‘Afficher les matériels achetés dans une période ’ 4.2.1. Description du cas d’utilisation Ce cas d’utilisation permet de voir les différents matériels achetés de la base du parc informatique tel que la date d’achat est comprise entre deux dates saisies dans la fenêtre de « les matériels achetés dans une période »,. Ci-après l’ensemble des informations sur ce cas d’utilisation :  Acteurs : Les acteurs pouvant consultés les matériels achetés dans une période sont : fonctionnaire, magasinier, responsable, superviseur de l’application  Pré-conditions : l’authentification dans l’application.  Action de départ : Accéder à l’application du parc.  Enchaînement :  L’authentification (vérification du nom d’utilisateur et mot de passe).  L’accès au menu principale du l’application  Dans le menu matériel il clique sur matériels achetés dans une période  Saisir la date de début et la date de fin ou choisir une période déjà prédéfinie  Clic sur le bouton Afficher les matériels Figure 9 : fenêtre du cas d’utilisation ‘Consulter les matériels’
  • 32. 22 Chapitre 2 : Etude et spécification des besoins  Remplissage automatique de la table par les matériels qui répond au critère de la recherche  Action de fin : quitter la fenêtre des matériels  Post-conditions : Aucune 4.2.2. Diagramme de séquence Le diagramme ci-après (Figure 10) illustre le processus de la recherche des matériels achetés dans une période, bien sûr qui doit être précédé par une authentification. Figure 10 : Diagramme de séquence du processus de l’affichage des matériels achetés dans une période 4.2.3. Fenêtre de la liste des matériels La figure ci-après (Figure 11) propose la fenêtre d’interface IHM pour la visualisation de la liste des matériels achetés entre la date de début et la date de fin. Dans cette fenêtre l’acteur qui l’a accédé est le fonctionnaire.
  • 33. 23 Chapitre 2 : Etude et spécification des besoins Le bouton ‘ Période prédéfinie ’ permet de dérouler une liste contient des différentes périodes comme : semaine en cours, semaine flottante, mois en cours … Le bouton ‘ Afficher les matériels ‘ affiche des informations dans la table selon la période saisie, aussi en peut imprimer le résultat à l’aide du bouton ‘ Imprimer ‘ mais si la table est vide et on veut imprimer le résultat, un message d’erreur s’affiche indiquant qu’il n’existe rien à imprimer. 4.3. Cas d’utilisation ‘ ajouter un nouveau matériel ’ 4.3.1. Description du cas d’utilisation Ce cas d’utilisation permet d’ajouter un nouveau matériel dans l’application. Ci-après l’ensemble des informations sur ce cas d’utilisation :  Acteurs : Les acteurs pouvant modifiés les logiciels sont : magasinier, responsable, superviseur de l’application  Pré-conditions : l’authentification dans l’application.  Action de départ : Accéder à l’application du parc.  Enchaînement :  L’authentification (vérification du nom d’utilisateur et mot de passe).  L’accès au menu principale du l’application  Dans le menu matériel il clique sur création d’un nouveau matériel  Remplir toutes les informations nécessaires Figure 11 : fenêtre du cas d’utilisation ‘Afficher les matériels achetés dans une période’
  • 34. 24 Chapitre 2 : Etude et spécification des besoins  Clic sur le bouton Valider  Vérification du système des champs obligatoires  Renvoyer le message d’affirmation d’ajout du matériel  Action de fin : quitter la fenêtre de la création d’un nouveau matériel  Post-conditions : vérification du système du format des champs (date, email, numéro,…) 4.3.2. Diagramme de séquence Le diagramme ci-après (Figure 12) illustre le processus de l’ajout d’un nouveau matériel au sein du l’application après avoir choisi le type et le modèle. Figure 12 : Diagramme de séquence du processus de l’ajout d’un nouveau matériel 4.3.3. Fenêtre de l’ajout du matériel La figure ci-après (Figure 13) propose la fenêtre d’interface IHM pour la création d’un nouvel matériel. Dans cette fenêtre l’acteur qui l’a accédé est le magasinier.
  • 35. 25 Chapitre 2 : Etude et spécification des besoins Figure 13 : fenêtre du cas d’utilisation ‘ ajouter un nouveau matériel ’ La case à cocher ‘Partager en réseau’ permet d’afficher le champ ‘Adresse IP’ pour renseigner une adresse pour le matériel, si la case est décochée alors le champ ‘Adresse IP ’ est invisible. Le sélecteur d’achat ou location permet de visualiser des champs selon le cas sélectionné, s’il s’agit de la location les champs loueurs et le N° de contrat s’affiche sinon les autres champs qui s’affichent (Figure 13) 4.4. Cas d’utilisation ‘ modifier un logiciel ’ 4.4.1. Description du cas d’utilisation Ce cas d’utilisation permet de mise à jour des informations sur u logiciel (augmenter le nombre de licences, modifier l’éditeur,…). Ci-après l’ensemble des informations sur ce cas d’utilisation :  Acteurs : Les acteurs pouvant modifiés les logiciels sont : magasinier, responsable, superviseur de l’application  Pré-conditions : l’authentification dans l’application.  Action de départ : Accéder à l’application du parc.  Enchaînement :
  • 36. 26 Chapitre 2 : Etude et spécification des besoins  L’authentification (vérification du nom d’utilisateur et mot de passe).  L’accès au menu principale du l’application  Dans le menu logiciel il clique sur liste des logiciels  Sélectionner un logiciel et cliquer sur le bouton modifier  Mise à jour des champs concernés  Vérification du système des formats des champs et aussi les champs obligatoires  Message d’affirmation de la mise à jour des données du logiciel en cours  Action de fin : quitter la fenêtre de la modification du logiciel  Post-conditions : Aucune 4.4.2. Diagramme de séquence Le diagramme ci-après (Figure 14) illustre le processus de la mise à jour des informations sur un logiciel, bien sûr qui doit être précédé par une authentification. Figure 14 : Diagramme de séquence du processus de la modification du logiciel 4.4.3. Fenêtre de la modification du logiciel La figure ci-après (Figure 15) propose la fenêtre d’interface IHM pour la visualisation de la liste des matériels achetés entre la date de début et la date de fin. Dans cette fenêtre l’acteur qui l’a accédé est le superviseur.
  • 37. 27 Chapitre 2 : Etude et spécification des besoins Figure 15 : fenêtre du cas d’utilisation ‘ modifier un logiciel ’ Si on a sélectionné le nombre de licences à définir alors les champs ‘ Nombre max de licences ’ et ‘ Prix unitaire ’ apparaitront pour les remplir après le champ ‘ Prix achat HT ‘ se calcule automatiquement à partir de les champs mentionnés ci-dessus. Aussi on peut joindre un fichier avec le logiciel par exemple une image ou un fichier texte et le voir à l’aide du bouton voir (l’œil). 4.5. Cas d’utilisation ‘ gestion des groupes d’utilisateurs ’ 4.5.1. Description du cas d’utilisation Ce cas d’utilisation permet de faire la gestion totale des groupes d’utilisateurs. Dans ce scénario on va créer un groupe modifier les droits de ce groupe .Ci-après l’ensemble des informations sur ce cas d’utilisation :  Acteurs : L’acteur pouvant faire la gestion des groupes d’utilisateurs est le superviseur  Pré-conditions : l’authentification dans l’application.  Action de départ : Accéder à l’application du parc.  Enchaînement :  L’authentification autant qu’un superviseur (vérification du nom d’utilisateur et mot de passe).
  • 38. 28 Chapitre 2 : Etude et spécification des besoins  L’accès au menu de présentation de l’application et choisir ‘ configurer le groupeware ‘  L’affichage de la fenêtre du groupeware utilisateur  Clic sur ‘ l’onglet utilisateurs et groupes ‘ puis sur le bouton ‘ nouveau’ pour la partie des groupes  Saisir le nom du groupe et valider  le message d’affirmation de l’ajout du groupe apparaîtra  clic sur l’onglet gestion des droit et choisir le groupe créé précédemment  faire modification des droits souhaités et un message indiquant que la modification a réussi apparaitra  Action de fin : quitter la fenêtre du groupeware utilisateur  Post-conditions : Aucune 4.5.2. Diagramme de séquence Le diagramme ci-après (Figure 16) illustre le processus de l’ajout d’un groupe et modifier ses droits. 4.5.3. Fenêtre de la gestion des droits La figure ci-après (Figure 17) propose la fenêtre d’interface IHM pour la modification des droits d’un groupe nommé ‘ Fonctionnaires ‘ quoi concerne les fonctionnaires du parc. Dans cette fenêtre l’acteur qui l’a accédé est le superviseur. Figure 16 : Diagramme de séquence du processus de la création d’un groupe et la modification de ses droits
  • 39. 29 Chapitre 2 : Etude et spécification des besoins Figure 17 : fenêtre du cas d’utilisation ‘ gestion des groupes d’utilisateurs ’ Il s’agit ici la gestion des droits pour la fenêtre principale de l’application, comme on a déjà discuté dans ce rapport, le fonctionnaire peut voir la liste des matériels et aussi voir les matériels acheté dans une période ce qui est indiqué dans la figue ci-dessus, donc le superviseur a mis les autres menus comme : Sites, Utilisateurs, Machines … grisés. 4.6. Cas d’utilisation ‘ gestion des connexions d’un utilisateur ’ 4.5.1. Description du cas d’utilisation Ce cas d’utilisation permet d’afficher les statistiques des connexions d’un utilisateur, dans ce cas d’utilisation on va visualiser les statistique d’un utilisateur selon une période sélectionner afin de filtrer les résultats, .Ci-après l’ensemble des informations sur ce cas d’utilisation :  Acteurs : Les acteurs pouvant visualisés les connexions d’un utilisateur sont : le responsable et le superviseur  Pré-conditions : l’authentification dans l’application.  Action de départ : Accéder à l’application du parc.  Enchaînement :  L’authentification (vérification du nom d’utilisateur et mot de passe).  L’accès au menu de présentation de l’application et choisir ‘ configurer le groupeware ‘  L’affichage de la fenêtre du groupeware utilisateur
  • 40. 30 Chapitre 2 : Etude et spécification des besoins  Clic sur l’onglet ‘ Statistiques‘  Saisir le nom de l’application et aussi de l’utilisateur  Sélectionner une période prédéfinie ou saisir la date de début et la date de fin  clic sur le bouton ‘ appliquer le filtre ’  remplissage automatique de la table des connexions  Action de fin : quitter la fenêtre du groupeware utilisateur  Post-conditions : Aucune 4.5.2. Diagramme de séquence Le diagramme ci-après (Figure 18) illustre le processus de la visualisation de l‘historique des connexions d’un utilisateur. Figure 18 : Diagramme de séquence du processus de la visualisation l’historique des connexions d’un utilisateur 4.5.3. Fenêtre de la visualisation des connexions d’un utilisateur La figure ci-après (Figure 19) propose la fenêtre d’interface IHM pour la l’affichage l’historique des connexions concernant un utilisateur. Dans cette fenêtre l’acteur qui l’a accédé est le superviseur.
  • 41. 31 Chapitre 2 : Etude et spécification des besoins Figure 19 : fenêtre du cas d’utilisation ‘ gestion des connexions des utilisateurs ’ Après le saisie le nom du l’application, le login concernant un utilisateur spécifique et aussi la date de début et la date de fin et en cliquant sur appliquer le filtre on voit clairement les résultats sur la table de l’historique des connexions pour cet utilisateur on peut aussi autant qu’un superviseur d’effacer cet historique à l’aide du bouton ‘ Effacer l’historique ’ Conclusion Ce chapitre a donné une première vision sur les fonctionnalités de l’application de la gestion du parc informatique. Dans ce chapitre, j’ai choisi de décrire 6 cas d’utilisation primaires dans l’application. Le chapitre suivant donnera la vision conceptuelle de l’application.
  • 42. 32 Chapitre 3 : Conception Chapitre 3 : Conception Ce chapitre définit les éléments résultant de l’analyse des spécifications de l’application de la Gestion de parc informatique. Les contraintes et les choix de conception seront présentés dans ce chapitre. 1. Stratégie de développement L’application à développer sera sous forme d’une application et un petit portail web qui sert à faire la communication entre l’application et le serveur d’application, Un portail traite les requêtes d'une tâche ou d'un service donné et génère dynamiquement le contenu web affiché à l’utilisateur, aussi l’application permet de faire la configuration complète du parc informatique on se basant sur le serveur qui va faire les traitements qui concerne le parc , aussi elle va me permettre de me fournir toutes sortes de services généralistes ou spécialisés ( interface de consultation des informations sur la société, panneau d'information, La gestion des licences, la gestion des contrats fournisseurs, …) De point de vue de l’interface de l’application j’ai préféré de travailler avec des fenêtres modales qui sont , dans une interface graphique, des fenêtres qui prennent le contrôle total du clavier et de l'écran. Elles sont en général associées à une question à laquelle il est impératif que l'utilisateur réponde avant de poursuivre, ou de modifier quoi que ce soit, c.à.d. pour l'application : seule cette application est bloquée jusqu'à la réponse ou l’attente de la valeur de retour de cette fenêtre ; Et finalement l’application utilise un seul gabarit (style de l’interface) pour toutes ses composantes (fenêtres, boutons, Listes déroulantes,…) afin d’être ergonomique et facile à utiliser. 2. Architecture technique de l’application Le schéma ci-après (Figure 20) montre l’architecture technique générale et le contexte de déploiement de l’application.
  • 43. 33 Chapitre 3 : Conception - Le serveur Manta est composé :  du service Manta Manager permet de communiquer avec l'application "Centre de Contrôle HFSQL" (outil d'administration à distance) et d'arrêter et/ou de lancer le ou les serveurs.  du service Manta. Le service Manta est l'application (en mode service) qui traite les demandes et les connexions" client/serveur " des applications connectées au serveur. Par défaut, un seul service Manta est présent sur le poste serveur. Cependant, il est possible d'avoir plusieurs services Manta sur le même poste serveur. Cette configuration permet par exemple d'associer mon application à un service Manta. Ainsi, si mon application surcharge le service Manta, seules les applications associées à ce service seront bloquées ou ralenties. Pour utiliser cette configuration, il est nécessaire que chaque service Manta utilise un port réseau et un chemin de répertoire de bases de données différents. Remarque : En cas de défaillance, le service est automatiquement redémarré. Aussi le serveur HyperFileSQL contient toute la base de données de l’application de la gestion du parc informatique. Figure 20 : schéma de l’architecture technique de l’application du parc
  • 44. 34 Chapitre 3 : Conception 3. Comportement dynamique de l’application Cette partie présente les activités (diagrammes d’activités) majeures du système de l’application de la gestion du parc informatique. 3.1. Gestion des logiciels Le processus de la gestion des logiciels commence tout d’abord par l’identification et la vérification du système des droits d’accès pour l’utilisateur connecté, ensuite cet utilisateur va accéder à l’interface principale pour aller vers le menu logiciel et après choisir liste des logiciels pour faire le traitement souhaité qui va être géré par le système. Le diagramme d’activités ci-après (Figure 21) présente le processus de gestion des logiciels du parc informatique. Figure 21 : diagramme d’activité ‘ Gestion des logiciels ’ 3.2. Gérer les utilisateurs Pour gérer les utilisateurs avec leurs droits d’accès, il faut tout d’abord s’authentifier autant qu’un superviseur, puis l’accès à la fenêtre de la présentation du l’application puis aller à la configuration du groupeware et ensuite accéder à la création d’un nouveau utilisateur en remplissant le nom et prénom, le login, le mot de passe, la confirmation du mot de passe et le
  • 45. 35 Chapitre 3 : Conception téléphone et indiquer si l’utilisateur est un superviseur ou non , finalement on peut soit de valider et quitter le formulaire ou de valider et de créer un nouvel utilisateur . Le diagramme d’activités ci-après (Figure 22) présente le processus de gestion des utilisateurs. Figure 22 : diagramme d’activité ‘ Gérer les utilisateurs ’ 3.3. Gérer les droits d’accès Concernant les droits le superviseur accède à l’onglet du l’application gestion des droits et sélectionner un utilisateur et puis modifier les droits d’accès puis enregistrer les modifications. Le diagramme d’activités suivant (Figure 23) présente la gestion des droits pour un utilisateur ou un groupe choisi.
  • 46. 36 Chapitre 3 : Conception Figure 23 : diagramme d’activité ‘ Gérer les droits d’accès ’ 3.4. Attribuer un utilisateur à une machine Cette activité sert à lier un utilisateur à un poste de travail de la société, pour effectuer cette activité il faut accéder à la fenêtre des machines puis sélectionner une machine pour la modifier, ensuite sur la zone des utilisateurs on clique sur l’icône de l’utilisateur puis la liste des utilisateurs disponibles apparaitra , finalement on sélectionne un utilisateur concerné et on valide le choix. Le diagramme d’activités suivant (Figure 24) présente l’attribution d’un utilisateur à une machine.
  • 47. 37 Chapitre 3 : Conception Figure 24 : diagramme d’activité ‘Attribuer un utilisateur à une machine ’ 3.5. Rechercher un matériel La recherche d’un matériel est une activité très importante lorsque qu’il existe des milliers des matériels dans un parc, il s’agit d’accéder au menu matériel et cliquer sur recherche puis saisir les informations concerné dans les champs spécifiés par exemple la marque , modèle , durée de garantie …, finalement la table des matériels se remplie automatiquement s’il existe des résultats sinon un message apparait dit que aucun résultat trouvé après ça soit rechercher à nouveau ou quitter la fenêtre de recherche. Le diagramme d’activités suivant (Figure 25) présente la recherche d’un matériel du parc informatique.
  • 48. 38 Chapitre 3 : Conception Figure 25 : diagramme d’activité ‘Rechercher un matériel ’ 4. Description de la base de données 4.1. Le modèle logique des données du l’application (MLD) A partir de l’analyse que j’ai déjà faite lors de la partie analyse du projet, j’ai dégagé un ensemble d’entités et de dépendances, cela a été traduit par ce modèle de conception de la base de données qui modélise le système réel étudié. L’application de gestion de base de données a besoin d’une base de données robuste qui va contenir un nombre très importants de données ce qui donne une interaction de données et de l’application souple et sans difficulté c’est pourquoi j’ai choisi la méthode d’analyse merise. Le diagramme MLD suivant (Figure 26) présente le schéma général de la base de données réalisé.
  • 49. 39 Chapitre 3 : Conception Figure 26 : Le modèle logique des données du l’application
  • 50. 40 Chapitre 3 : Conception 4.2. Description des tables Dans cette partie je vais expliquer les plus importantes tables puisque le schéma contient plus de 30 tables. Le champ Rédacteur nous permet de savoir qui est l’utilisateur qui a ajouté un enregistrement dans une table. 4.2.1. La table ‘ Société ’ Figure 27 : la table ‘ Société ’ Cette table représente la société qui sert à enregistrer les données qui lui concernent le nom, l’adresse, code postal, la ville … L’acteur qui remplit cette table à l’aide de l’application est le superviseur 4.2.2. La table ‘ Département ’ Figure 28 : la table ‘ Département ’ Le MLD qu’on a déjà vu chaque société à au moins un département par exemple département vente, marketing, comptabilité…
  • 51. 41 Chapitre 3 : Conception 4.2.3. La table ‘ Service ’ On voit ici la clé ‘ IDDepartement ’ existe dans cette table ce qui signifie la relation directe entre elle et la table département c.à.d. chaque département à des services. Par exemple on peut trouver dans le département marketing le service publicité… 4.2.4. La table ‘ Utilisateur ’ L’une des plus importantes table de cette application, un utilisateur peut s’exister dans un seul service qui un département de la société. Cette table contient le nom d’utilisateur, prénom, téléphone, securid est un numéro privé de l’utilisateur, login et mot de passe, commentaire pour additionner des informations supplémentaires sur l’utilisateur, fichier lié par exemple il peut être un document ou une image de l’utilisateur. Figure 29 : la table ‘ Service ’ Figure 30 : la table ‘ Utilisateur ’
  • 52. 42 Chapitre 3 : Conception 4.2.5. La table ‘ Matériel ’ Cette table contient les informations détaillées sur un matériel, on trouve tous ce qui concerne la location, la commande, date d’acquisition et d’achat, prix d’achat en cas ou le matériel est acheté, durée de garantie … Aussi on trouve que cette table est reliée avec les tables suivantes : modèle, type par exemple un ordinateur ou imprimante …, fournisseur, machine (poste de travail), contrat et type de garantie. Figure 31 : la table ‘ Matériel ’
  • 53. 43 Chapitre 3 : Conception 4.2.6. La table ‘ Machine ’ Une machine comme on a déjà dit est un poste de travail du parc informatique, on trouve des champs sur cette table comme : le nom, description, Affecté ou non, prête ou non, la date d’affectation… La table est en relation avec la table utilisateur puisqu’une machine peut contenir un ou plusieurs utilisateurs. 4.2.7. La table ‘ Accessoire ’ Cette table concerne les accessoires des machines, les informations qui concerne un accessoire sont : le nom, référence, type, modèle, prix unitaire, quantité, la facturation et la commande… On peut trouver comme accessoires : souris, claviers, câbles, hubs …. Figure 32 : la table ‘ Machine ’ Figure 33 : la table ‘ Accessoire ’
  • 54. 44 Chapitre 3 : Conception La table est relié directement avec la table marque et fournisseur. 4.2.8. La table ‘ Fournisseur ’ Là on trouve des fournisseurs du parc informatique soit des autres sociétés ou des personnes. Cette table contient les champs comme il est indiqué sur la figure ci-dessous. 4.2.9. La table ‘ Logiciel ’ Les logiciels sont aussi importants que les matériels, c’est l’esprit vivant de la société, cette table contient les logiciels avec leur noms, numéros de série, licences, prix d’achat unitaire et total … La table est en relation avec la table fournisseur et la table éditeur. Figure 34 : la table ‘ Fournisseur ’ Figure 35 : la table ‘ Logiciel ’
  • 55. 45 Chapitre 3 : Conception 4.2.10. La table ‘ Loueur ’ Le loueur est la personne qui prend un matériel pour une période bien définie, il a comme caractéristiques : nom, adresse, code postale, contact, email …. 4.2.11. La table ‘ Contrat ’ Chaque opération de location d’un matériel nécessite un contrat entre le locateur et la société donc c’est le rôle de cette table qui contient comme champs : date de début de location, commande de loueur, les frais, cotisation par mois, la durée de location … Cette table est reliée avec la table loueur et la table société. Figure 36 : la table ‘ Loueur ’ Figure 37 : la table ‘ Contrat ’
  • 56. 46 Chapitre 3 : Conception 4.2.12. La table ‘ Paramètre ’ Cette table contient les paramètres de l’application concernant les alertes, on trouve par exemple si la durée de contrat a dépassé le paramètre ‘ échéance contrat ’ une alerte s’affiche lors du lancement du l’application, la même chose s’applique aux autres paramètres. 4.2.13. La table ‘ Réparateur ’ Les réparateurs sont des personnes qui faire des réparations au matériels du parc il peut s’agit des ordinateurs, imprimantes, routeurs … Figure 38 : la table ‘ paramètre ’ Figure 39 : la table ‘ Réparateur ’
  • 57. 47 Chapitre 3 : Conception 4.2.14. La table ‘ Demande intervention ’ Cette table est très importante, La gestion des interventions permet de suivre les incidents gérer en interne et/ou donnant lieu à une réparation, un retour en garantie. La création d'une intervention nécessite un code, un numéro de série, une date de demande et un objet. La clôture d'une intervention se fait en renseignant la date de fin d'intervention. Cette table est en relation avec les tables : matériel, machine, utilisateur (intervenant), service, département et finalement la société. Conclusion Ce chapitre a donnée l’aspect conceptuel de l’application de la Gestion du parc informatique, où j’ai détaillé l’aspect workflow du composant du parc, quel que soit matériel, logiciels, utilisateurs … Le chapitre suivant fera l’objet d’une étude technique qui justifiera le choix des technologies pour la réalisation de l’application. Figure 40 : la table ‘ Demande intervention ’
  • 58. 48 Chapitre 4 : Etude technique du projet Chapitre 4 : Etude technique du projet Ce chapitre met la lumière sur la plateforme utilisée et les outils de développement adoptés avec la justification de chaque utilisation d’un outil afin de mettre en œuvre l’application de gestion du parc informatique. 1. L’environnement WinDev 1.1 Présentation WinDev WinDev 18 permet de gérer, étape par étape, de la conception à la finalisation, le cycle complet du développement d’une application. WinDev permet de réaliser toutes les applications dont vous rêvez. L’environnement WinDev se présente de la manière suivante (figure 41 ci-dessous) : Figure 41 : Environnement WinDev WinDev 18 permet de créer des applications qui gèrent des données. Les applications WinDev accèdent à toutes les bases données, relationnelles ou non du marché. Toutes les bases de données sont supportées. WinDev 18 est livré en standard avec :
  • 59. 49 Chapitre 4 : Etude technique du projet • Hyper File Classic, une puissante base de données relationnelle, déjà utilisée sur des millions de sites. • Hyper File Client/ Serveur, une puissante base données relationnelle Client/ Serveur. WinDev 18 propose certainement l’environnement de travail le plus puissant, le plus facile et le plus intégré du marché ! Les Développeurs Créeront facilement des superbes applications. L’éditeur de fenêtres de WinDev 18 est 100% WYSIWYG (« ce que vous voyez est ce que vous aurez »). Il permet de réaliser facilement de superbes fenêtres reliées aux données. 1.2 Argumentaires généraliste WINDEV Logiciel commercialisé pour la première fois en 1993, il dispose d’une expérience hors du commun. WINDEV a évolué sans cesse depuis sa création, a innové et innove sans relâche pour le plus grand bénéfice de ses utilisateurs. Précurseur dans le domaine du « Framework » (mis en place dès 1993), de l’intégration totale des outils nécessaires à la gestion du cycle de vie des applications, du déploiement libre et gratuit, et chantre de l’ouverture totale à toutes les technologies. Numéro un incontesté en France depuis des années, il n’est pas près de laisser sa place à quiconque, principalement en raison de son évolution permanente dans le respect des besoins réels des équipes de développement. Aujourd’hui en version 19, WINDEV, comme son célèbre slogan l’affirme, permet de développement réellement « 10 fois plus vite », pour le plus grand bénéfice des développeurs et des utilisateurs. 1.3 Que fait-on avec WinDev WinDev est un AGL (Atelier de Génie Logiciel). Il vous permet de développer des applications dans tous les domaines :  Gestion (Comptabilité, Paie, Finances, Commerce, Stock, ERP, CRM, EAI, EDI, VPC, GRM, …) ;  Industrie (Robots, Caisses, Automates, Balances, Lecteur de badge, Supervision, …) ;  Médical ;  Multimédia ;  Internet ;  Accès Distant...
  • 60. 50 Chapitre 4 : Etude technique du projet WinDev est un outil de développement complet qui intègre tous les outils nécessaires au cycle de réalisation d’une application. Contrairement à d’autres langages de développement traditionnels, il n’est pas de chercher et de rajouter des modules pour concevoir, tester et installer une application. Le L5G (Langage de 5éme Génération) de WinDev, le WLangage, vous étonnera par sa simplicité : quelques heures suffisent pour appréhender le langage, une semaine suffit en général pour maitriser toute sa puissance. Comme il est en français, le WLangage (disponible également en anglais) vous fera gagner du temps. 1.4 L’argumentaire technique Les technologies innovantes mises en œuvre par WINDEV profitent de la maturité de celui-ci. La réalité du terrain est souvent éloignée des théories des instituts d’analyse et de prospective… Les besoins de performance des utilisateurs sont une réalité qui ne permet aucuns errements. Une entreprise n’est en général pas un laboratoire de recherche et doit utiliser des logiciels robustes, rapides et qui répondent aux besoins réels des utilisateurs. WINDEV s’appuie sur des technologies éprouvées, aux performances et à la sécurité qui permettent une utilisation réelle. Les équipes de PC Soft travaillent en permanence surtouts les technologies émergentes, mais n’implémentent pas celles qui sont manifestement immatures ou dangereuses ou vouées indubitablement à l’échec. WINDEV et WEBDEV évoluent en permanence. Il est important que les solutions mises en œuvre soient pérennes : c’est le cas avec WINDEV, depuis sa version 1. WINDEV évolue souvent (en assurant la compatibilité avec l’existant). 1.5 Argumentaire Base de Données WINDEV est ouvert à toutes les bases de données du marché : Oracle, SQL Server, MySQL, AS/400, Sybase, Informix, DB2, Access, dbase, etc…; il est également livré avec la puissante base de données HyperFileSQL. L’accès aux bases de données s’effectue par ODBC, OLE DB ou nativement (A savoir : certains accès natif doivent être acquis séparément).
  • 61. 51 Chapitre 4 : Etude technique du projet A la différence des autres environnements, la structure des bases de données est connue de l’environnement : cela permet d’automatiser et sécuriser les phases du développement et de maintenance. 1.6 Argumentaire réactivité et vitesse de développement C’est un lieu commun de dire que le monde bouge vite. Les lois évoluent sans cesse, la concurrence est acharnée dans de nombreux secteurs, les besoins sont souvent urgents. Les applications informatiques doivent se conformer à ces évolutions. Il est donc nécessaire de pouvoir créer et modifier vite des applications. C’est là un avantage qui est le fondement même de WNDEV : sa vitesse de développement, ses capacités de modification automatique, sa gestion intégrée de la base déployée (live-update en particulier) permettent aux équipes une réactivité inconnue sans lui. Seul WINDEV permet un développement robuste aussi rapide. Des projets qui demanderaient plusieurs mois avec d’autres outils sont souvent réalisés en quelques jours avec WINDEV. 2. Architecture et outils 2.1 Architecture logicielle du système Une architecture logicielle est un schéma d'organisation structurel fondamental pour les systèmes logiciels. Elle fournit un jeu de sous-systèmes prédéfinis, spécifie leurs responsabilités, et inclut les rôles et les instructions générales pour organiser les relations entre eux. Sans une bonne architecture, un système d'information est difficile à comprendre, prédire, gérer et optimiser. Les buts d'une architecture sont : - La compréhension du système étudié, en définissant ses limites. - La gestion de la croissance du système. La future architecture du système doit satisfaire un certain nombre d’exigences telles que la sécurité, la disponibilité et la maintenance. Parmi les différentes façons de structurer une architecture, la mieux comprise et maîtrisée en informatique est l'approche par couches. Une couche est une division logique, horizontale d'un système qui fournit une abstraction particulière du système aux couches supérieures. Chaque couche possède des responsabilités spécifiques. Dans une structuration par couches, les couches inférieures prennent en charge des responsabilités qui offrent un socle de base pour les
  • 62. 52 Chapitre 4 : Etude technique du projet couches supérieures, permettant d'abstraire celles-ci des problématiques qui ne les concernent pas. Aujourd'hui, les logiciels « Change On Demand» 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. J’ai découpé mon application logicielle en cinq 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. D'où le schéma récapitulatif suivant : Figure 42 : Architecture logicielle • Couche Présentation : Cette couche est faite principalement pour gérer le domaine visuel de l’application et pour gérer les interactions avec les utilisateurs. Chargée de dessiner les fenêtres et autres composants graphiques, elle intercepte les événements et appelle la couche Service, après la vérification des autorisations auprès d’un service de sécurité. • Couche services :
  • 63. 53 Chapitre 4 : Etude technique du projet C’est l’intermédiaire entre la couche métier et la couche présentation, cette couche expose différentes entités proposant les services offerts par la couche métier, en effet, la couche présentation ne manipule plus directement les objets métier de la couche métier mais passe par des services. De cette manière, les fonctionnalités sont restreintes et la réduction des échanges entre les couches est assurée. • Couche métier : Cette couche est concentrée sur le métier de l’application, c'est-à-dire les règles métier, sémantiques et logiques. Sa charge principale consiste à garantir la validation sémantique de l'information métier. Cette couche est basée sur le modèle objet. • Couche Persistance : Cette couche est certainement l'une des plus importantes. C'est dans cette couche que je trouve les fonctionnalités de base qui permettent de créer, rechercher et supprimer des entités métier dans le respect des propriétés transactionnelles. C'est également dans celle-là que les mécanismes de conversion objet/relationnel peuvent prendre place. • Couche Stockage : Cette couche est responsable du stockage physique de données. Elle assure un support transactionnel et elle est basée sur un modèle relationnel. 2.2 Choix des langages et outils 2.2.1 Modèle RAD La méthode de Développement Rapide d'Applications, dite méthode RAD (acronyme de l'anglais Rapid Application Development), est la première méthode de développement de logiciels où le cycle de développement est en rupture fondamentale par rapport à celui des méthodes antérieures. Ce nouveau cycle qualifié d'itératif, d'incrémental et d'adaptatif, se retrouvera ensuite dans toutes les méthodes dites « agiles » publiées par la suite.  Aperçu : La méthode RAD, après deux courtes phases de formalisation structurée de l'expression des besoins (CADRAGE) et de définition globale de l'architecture technique (DESIGN), inclut dans sa phase principale(CONSTRUCTION) la réalisation, la validation immédiate et les tests d'une application en mode itératif-incrémental-adaptatif. L'objectif de la méthode, qui implique activement l'utilisateur final dans un principe de "validation permanente", est d'obtenir un applicatif en adéquation avec les réels besoins.
  • 64. 54 Chapitre 4 : Etude technique du projet Figure 43 : Avantages de Méthode RAD.  Développement : James Martina développé la méthode RAD à la fin des années 1980, à IBM, en se basant sur les publications de Barry Boehm (modèle en spirale), Tom Gilb (cycle de vie évolutif), Scott Shultz (production en itérations rapides) ainsi que Brian Gallagheret Alex Balchin. Il l'a formalisée en la publiant en 1991. Des compléments et des actualisations sont introduits à partir de 1994, notamment par Jean- Pierre Vickoff pour l'aspect francophone (processus RAD2 publié par le Gartner Group) et Jennifer Stapleton en Grande-Bretagne (processus DSDM). L’apport de J. Martin avec la méthode RAD fut de formaliser techniquement le premier postulat « agile », à savoir que pour qu'une prédiction de projet puisse se réaliser à tous les coups, il fallait que certains aspects du pilotage soient d’autres soient variables. Il proposa des techniques de priorisation pour gérer les deux principales variantes possibles de ces situations (délais fixe ou budget fixe). Les notions additionnelles de visibilité, de risque et de fiabilité (ou de qualité) comme variables de planification stratégique d’un projet furent introduites plus tard.  Structure de la méthode : La méthode RAD implique :  Un cycle de développement sécurisant et court fondé sur un phasage simple : Cadrage, Design, Construction et l’absolu respect d’une dimension temporelle (90 jours optimum, 120 jours maximum) [Martin 1991].  Une architecture de communication engageant des groupes de travail de structure et de composition variable selon les besoins des phases et respectant un mode opératoire précis structuré en trois étapes : précession, post post-session [Mucchielli 1987].
  • 65. 55 Chapitre 4 : Etude technique du projet  Des méthodes, techniques et outils permettant de définir et d’appliquer des choix portant sur quatre natures d'objectifs potentiellement contradictoires : budget, délais, qualité technique, qualité fonctionnelle et visibilité [Vickoff 1998].  Une architecture de conception s’appuyant sur les techniques de l'objet et particulièrement sur celles qui permettent une conception «en vue de modifications» [McCarty 1997].  Une architecture de réalisation qui impose, pour garantir la qualité technique, des normes minimales, des revues de projet, des jalons zéro défaut et qui recommande, pour garantir la qualité fonctionnelle, le prototypage actif et les focus de visibilité [McConnell 1996]. Figure 44 : Evolution d’un projet avec la méthode RAD La méthode RAD structure le cycle de vie du projet en 5 phases (dont 3 systématiques) : 1. L’initialisation prépare communication. 2. Le CADRAGE définit un espace d’objectifs, de solutions et de moyens. 3. Le DESIGN modélise la solution et valide sa cohérence systémique. 4. La CONSTRUCTION réalise en prototypage 5. La finalisation est réduite à un contrôle final de qualité en site pilote.
  • 66. 56 Chapitre 4 : Etude technique du projet Figure 45 : Parallélisassions et sérialisation des phases de projet avec la méthode RAD.  Initialisation : Préparation de l’organisation et communication. Cette phase permet de définir le périmètre général du projet, de structurer le travail par thèmes, de sélectionner les acteurs pertinents et d’amorcer une dynamique de projet. Cette phase représente environ 6% du projet en charge.  Cadrage : Analyse et expression des exigences. La spécification des exigences est du ressort des utilisateurs. Ils expriment leurs besoins lors d’entretiens de groupe. Il est généralement prévu de 2 à 5 jours de sessions par commission (thème). Cette phase représente environ 9% du projet.  Design : Conception et modélisation. Les utilisateurs sont également impliqués dans cette étape. Ils participent à l’affinage et à la validation des modèles organisationnels : flux, traitements, données. Ils valident également le premier niveau de prototype présentant l’ergonomie et la cinématique générale de l’application. Il est prévu entre 4 et 8 jours de sessions par commission. Cette phase représente environ 23% du projet. A partir de la phase de Design la parallélisassions du travail est possible  Construction : Réalisation, prototypage.
  • 67. 57 Chapitre 4 : Etude technique du projet Durant cette phase, l’équipe RAD (SWAT) doit construire l’application module par module. L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des prototypes. Plusieurs sessions itératives sont nécessaires. Cette phase représente environ 50% du projet. A partir de la phase de Construction, à la parallélisassions du travail peut s’ajouter la sérialisation.  Finalisation : Recette et déploiement. Des recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phase d’officialiser une livraison globale et de transférer le système en exploitation et maintenance. Cette phase représente environ 12% du projet.  Outils RAD : La méthode, sans être liée aux outils, recommande l'utilisation d'outils de programmation à interface graphique (CASE), qui permet d'obtenir rapidement des prototypes. A ce sujet, il ne faut pas confondre la méthode RAD (d'où sont issues les approches Agiles actuelles) qui recherche la qualité applicative fonctionnelle et technique avec les outils RAD, dont la production automatique de code est souvent qualifiée de "sale". • Powerbuilder • uniPaaS (anciennement connu sous le nom de Magic eDeveloper) est une plateforme RAD qui accélère le développement d'applications Métier en associant un paradigme de développement unique de bout en bout à un moteur de règles fondé sur les métadonnées. Le développement est accéléré de par le fait que le code est précompilé dans le système. • Delphi (Lazarus ou ainsi que le Visual Basic) est un outil RAD en ce sens qu'il permet assez facilement de créer des programmes à l'aide d'une interface graphique dotée de nombreux outils et de modules prêts à l'emploi. • WinDev (ainsi que WebDev) est un outil RAD plus avancé car il permet à partir d'une analyse Merise ou UML de produire un applicatif final et opérationnel. WinDev Mobile permet lui de créer rapidement des applications pour les matériels mobiles. • Authorware crée lui-aussi un applicatif final en dessinant un diagramme à l'aide d'icônes. • JBuilder • C++ Builder • C# Builder • Leonardi est un outil RAD adapté au développement des IHM.
  • 68. 58 Chapitre 4 : Etude technique du projet • Limbas est un outil RAD 100% web (développement et application cible) sous licence GNU GPL 2 incluant notamment des fonctionnalités GED et Groupware. 2.2.2 WLangage Le WLangage est un langage de programmation de 5éme génération inclus dans les outils de développement WinDev, WebDev et WinDev Mobile. Il est propriétaire et ne peut être manipulé qu'avec les outils PC SOFT. Le WLangage est né en 1992 avec la première version de WinDev. Même s'il y a explicitement une première phase précoce de compilation, le byte code WLangage est exécuté par une machine virtuelle ou converti en code natif lors de l'exécution par un compilateur à la volée (Just in time, JIT). Le Framework est disponible sous Windows (32 bits, 64 bits et CE) et partiellement sous Linux (sans interface graphique). Le WLangage peut également s'appuyer sur le Framework Java pour une partie de ses fonctionnalités, ce qui permet une indépendance relative et limitée du fichier exécutable par rapport au système d'exploitation cible. Il en va de même dans WebDev, où le WLangage peut s'appuyer sur le Framework PHP, sans toutefois permettre d'utiliser toutes les possibilités de ce dernier. Initialement prévu pour Windows, une partie des fonctions du WLangage est basée sur l'API Microsoft Windows. Le WLangage est un langage de programmation procédurale qui permet la programmation impérative et la programmation orientée objet. C'est en fait un langage de programmation multi- paradigme. Le WLangage contient des fonctions de haut niveau, telle que la fonction EcranVersFichier, qui effectue les affectations du contenu des champs d'une fenêtre vers des tables stockées dans un fichier ou des variables, auxquelles les champs ont été préalablement reliés (databinding). Le WLangage autorise une utilisation souple du typage. Les variables doivent être typées mais les paramètres formels des procédures ou les itérateurs de boucles peuvent ne pas l'être. Il est ainsi possible dans un même projet de combiner des procédures avec typage strict pour profiter de la rigueur du typage statique et des procédures sans typage pour profiter de la souplesse du typage dynamique et du duck typing. 2.3 Système de gestion de la base de données relationnelle HyperFileSQL est un système de gestion de base de données relationnel exploité par les logiciels WinDev, WebDev et WinDev Mobile.
  • 69. 59 Chapitre 4 : Etude technique du projet Le système de gestion de base de données relationnelle HyperFileSQL nous permet de gérer ces données en toutes sécurités. Les performances sont remarquables. Utilisé sur plusieurs millions de postes à travers le monde, la flexibilité et l’évolutivité de HyperFileSQL permettent de répondre aux besoins les plus exigeants des applications à mission critique en temps réel. 2.3.1 Généralités : HyperFileSQL est un puissant SGBDR (Système de Gestion de Base de Données Relationnelle). HyperFileSQL est décliné en trois versions : • Version mobile (embarquée) ; • Version locale (monoposte ou réseau) ; • Version Client/ Serveur (et cluster). HyperFileSQL est adapté à tous les types d’applications : applications métiers, applications critiques temps réel, progiciels, serveurs d’applications, serveurs Web, PC stand-alone ou périphériques mobiles. 2.3.2 Performance, Sécurité, Ouverture, Flexibilité : HyperFileSQL est le choix idéal comme moteur de bases de données. • Ouverture : basé sur les standards de l’industrie, HyperFileSQL ne vous enferme pas dans une technologie propriétaire. • Flexibilité : le support des volumes de données importants (plusieurs dizaines de milliards de lignes dans une table) est assuré. • Indépendance : vis-à-vis de la plateforme : les tables peuvent être déplacées d’un Client/ Serveur vers un mobile, d’un serveur Windows vers un serveur linux, etc.… • Extensibilité : vous passez sans contraintes d’un utilisateur à plusieurs centaines d’utilisateurs, d’une architecture 2 tiers à une architecture multi-tiers… • Econome ressources : le moteur client/serveur occupe moins de 20Mo sur disque. HyperFileSQL fonctionne en environnement hétérogène : Windows, Linux, Mac, TSE, Citrix, ADSL, VPN, Wi-Fi… • La compatibilité ascendante et descendante des tables est assurée. • Pérennité de l’éditeur : PC Soft est présent depuis plus de 25ans, et est n°1 en France dans le monde des AGL. • Performance : grâce à une gestion optimisée des index et une gestion affinée des caches, la vitesse est permanente.
  • 70. 60 Chapitre 4 : Etude technique du projet • Sécurité d’accès : la protection contre l’injection SQL est assurée via la création automatique d’IHM sécurisées. 2.3.3 Coût d’usage (TCO) réduit : Une caractéristique de HyperFileSQL est son déploiement illimité libre et gratuit. Il n’y a aucun coût facturé, ni en fonction du nombre de processeur du serveur, ni en fonction du nombre de postes client, ni annuellement, ni en fonction du type d’application… HyperFileSQL est livré en une édition systématiquement complète, avec toutes les fonctionnalités, gratuite. Les coûts de maintenance sont très réduits. Figure 46 : HyperFileSQL
  • 71. 61 Chapitre 4 : Etude technique du projet Conclusion Ce chapitre avait comme but de présenter l’ensemble de mes recherches au niveau des technologies et de l’environnement dans lequel s’inscrit mon projet, aussi j’ai introduit les outils et les langages que j’ai utilisés pour la réalisation de mon application le chapitre suivant présente la réalisation et la mise en marche de l’application