Transcript
Page 1: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 2: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 3: Rapport Projet  de fin d'etude sur le parc informatique

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é

Page 4: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 5: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 6: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 7: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 8: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 9: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 10: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 11: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 12: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 13: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 14: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 15: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 16: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 17: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 18: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 19: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 20: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 21: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 22: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 23: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 24: Rapport Projet  de fin d'etude sur le 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.

Page 25: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 26: Rapport Projet  de fin d'etude sur le parc informatique

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, …)

Page 27: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 28: Rapport Projet  de fin d'etude sur le parc informatique

18 Chapitre 2 : Etude et spécification des besoins

Figure 7 : Diagramme des cas d'utilisations de l'application

Page 29: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 30: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 31: Rapport Projet  de fin d'etude sur le parc informatique

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’

Page 32: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 33: Rapport Projet  de fin d'etude sur le parc informatique

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’

Page 34: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 35: Rapport Projet  de fin d'etude sur le parc informatique

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 :

Page 36: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 37: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 38: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 39: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 40: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 41: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 42: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 43: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 44: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 45: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 46: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 47: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 48: Rapport Projet  de fin d'etude sur le 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é.

Page 49: Rapport Projet  de fin d'etude sur le parc informatique

39 Chapitre 3 : Conception

Figure 26 : Le modèle logique des données du l’application

Page 50: Rapport Projet  de fin d'etude sur le parc informatique

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é…

Page 51: Rapport Projet  de fin d'etude sur le parc informatique

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 ’

Page 52: Rapport Projet  de fin d'etude sur le parc informatique

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 ’

Page 53: Rapport Projet  de fin d'etude sur le parc informatique

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 ’

Page 54: Rapport Projet  de fin d'etude sur le parc informatique

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 ’

Page 55: Rapport Projet  de fin d'etude sur le parc informatique

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 ’

Page 56: Rapport Projet  de fin d'etude sur le parc informatique

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 ’

Page 57: Rapport Projet  de fin d'etude sur le parc informatique

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 ’

Page 58: Rapport Projet  de fin d'etude sur le parc informatique

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 :

Page 59: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 60: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 61: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 62: Rapport Projet  de fin d'etude sur le parc informatique

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 :

Page 63: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 64: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 65: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 66: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 67: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 68: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 69: Rapport Projet  de fin d'etude sur le parc informatique

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.

Page 70: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 71: Rapport Projet  de fin d'etude sur le parc informatique

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

Page 72: Rapport Projet  de fin d'etude sur le parc informatique

62 Chapitre 5 : mise en œuvre du projet

Chapitre 5 : mise en œuvre du projet

Cette partie a pour but la description de la phase de mise en œuvre de la solution. Je présente

d’abord l’architecture applicative du système et je détaille ensuite la réalisation de

l’application.

1. Présentation

Afin de gérer et contrôler la gestion de parc informatique, les opérateurs utilisent des fichiers

Excel pour l’accumulation des données techniques afin d’élaborer un fiche des résultats

journaliers de parc concernant l’achat des matériels, renouvellement des licences des antivirus

Il existe plusieurs types de matériels et logiciels, Cependant la quantité des données techniques

à gérer quotidiennement est immense, les données totalisant en moyenne 80 à 100 par poste de

travail, donc on peut se trouver avec un flux dépassant les 400 données journalières. Ces

informations demeurent non classées et mal organisées, on aura des difficultés pour accéder

aux données récentes cause le manque d’organisation, quantité immense des données, la non

disponibilité des fichiers sur le serveur de la société...

Il est donc indispensable pour la direction de s’appuyer sur une démarche d’organisation de la

gestion des biens technologiques et des moyens humains afin de diminuer et de rationaliser les

coûts de la gestion et le suivi de parc.

Donc le but de mon projet est la conception et la réalisation d’une solution permettant une

meilleure gestion et un suivi quotidien de l’évolution du parc.

Cette solution sera composée principalement de six modules :

Gestion des utilisateurs

Gestion des machines

Gestions des matériels

Gestions des logiciels

Gestions des incidents

Gestions des interventions

Page 73: Rapport Projet  de fin d'etude sur le parc informatique

63 Chapitre 5 : mise en œuvre du projet

2. Réalisation de la solution

Le système développé suit l’architecture applicative déjà présentée dans le chapitre IV. Il

comporte les différentes couches applicatives du système :

• Couche Présentation.

• Couche Services.

• Couche Métier.

• Couche Persistance.

• Couche Données.

2.1 La couche Données :

Cette couche comporte le schéma de la base de données du système. Ce schéma qui le modèle

physique de donnée, a été généré à partir du MCD de l’application.

2.2 La couche Mapping et Persistance :

Cette couche se charge de la persistance des objets métier manipulés par les services. En effet,

cette couche se compose des descripteurs des classes métier et des tables associées à ces classes

dans la base de données.

5.3 La couche Métier :

Cette couche comporte les différents paquetages métier du système. Ces paquetages sont

appelés par les composants de la couche Services pour répondre aux requêtes des utilisateurs.

5.4 La couche Services :

Cette couche fait appel aux paquetages de la couche métier par des composants pour répondre

aux requêtes des utilisateurs.

5.5 La couche Présentation :

Cette couche concerne les interfaces Homme-Machine que j’ai développé en utilisant WinDev

code behind WLangage.

3. Développement :

3.1 Outils de développement :

Planification : Edraw max

Page 74: Rapport Projet  de fin d'etude sur le parc informatique

64 Chapitre 5 : mise en œuvre du projet

Développement : WinDev.

Conception de la base de données : WinDev.

Modélisation (diagrammes) : Edraw max

3.2 Environnement de modélisation Edraw :

Pour réaliser les différents diagrammes du projet j’ai utilisé le logiciel « Edraw Max 7.2 »

Figure 47 : logo du logiciel Edraw MAX

Edraw Max est un utilitaire de création de plans, de schémas et de diagrammes qui couvre un

nombre impressionnant de types de documents.

Citez n'importe quel type de document de type modélisation en 2D, Edraw Max le propose.

Pour le management ? Organigrammes, brainstorming, schémas cognitifs... Pour la

construction ? Circuits électriques, plans d'aménagement en 2D... Pour l'aménagement du

territoire ? Cartes de ville ou de pays, plans de métro... La liste inclut aussi des modélisations

de sites internet et même des dessins de mode (plutôt basiques, mais tout de même).

Malgré l'avalanche de possibilité, l'interface rassure, reprenant l'aspect de Microsoft Office

2007. On est en terrain connu : les objets s'insèrent par un simple glisser/déposer et sont

redimensionnables à volonté.

La base de données des cliparts inclut plus de 2000 objets. Cela correspond à quelques centaines

de dessins pour chaque type de diagramme, ce qui est impressionnant, d'autant plus qu'ils sont

souvent de bonne qualité.

Edraw Max permet de créer un diaporama à partir de plusieurs documents. Pas de format PPT,

réservé à PowerPoint : c'est ici un exécutable au format .EXE qui est exporté. C'est aussi là que

commencent les ennuis : l’EXE en question alerte l'antivirus de l'ordinateur. Impossible de le

faire tester par virustotal.com, qui bizarrement n'arrive pas à l'analyser.

Page 75: Rapport Projet  de fin d'etude sur le parc informatique

65 Chapitre 5 : mise en œuvre du projet

3.3 Environnement de développement WinDev

Figure 48 : Logo du l’atelier génie logiciel WinDev 18

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.

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 :

• Hyper File Classic, une puissante base donnée 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 10 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.

4. Présentation de quelques interfaces

Un exemple d’interfaces est représenté par les figures suivantes :

Page 76: Rapport Projet  de fin d'etude sur le parc informatique

66 Chapitre 5 : mise en œuvre du projet

Figure 49 : fenêtre d’authentification

Pour bénéficier des services de mon application chaque utilisateur doit saisir un nom

d’utilisateur et un mot de passe valide. Ce dernier sera redirigé soit pour l’interface des

administrateurs, ou des utilisateurs simples.

Figure 50 : fenêtre compte administrateur

Après l’authentification d’un superviseur est réussie, la fenêtre ‘ comptes d’administrateur ’

ouvre automatiquement.

Le superviseur a le choix de soit d’ouvrir la fenêtre principale soit de configurer le groupeware

utilisateur (gestions des utilisateurs, gestions des droits …) ou de quitter l’application.

Page 77: Rapport Projet  de fin d'etude sur le parc informatique

67 Chapitre 5 : mise en œuvre du projet

Partie Superviseur

Figure 51 : fenêtre de l’administration des utilisateurs et les groupes

Dans cette fenêtre on fait la gestion des utilisateurs de l’application (ajout, modification,

suppression) ainsi que des groupes lorsqu’on clique sur Nouveau dans la partie ‘ Utilisateurs ’

cette fenêtre s’affiche :

Page 78: Rapport Projet  de fin d'etude sur le parc informatique

68 Chapitre 5 : mise en œuvre du projet

Figure 52 : fenêtre de l’ajout d’un nouvel utilisateur

Après l’affichage de cette fenêtre on doit la remplir par les informations demandées ci-dessous

(login, nom prénom, téléphone), après ça on peut laisser le choix à ce nouvel utilisateur de créer

son mot de passe au premier lancement ou de le mentionner directement.

Aussi lorsqu’on ne mentionne pas le login par exemple, un message d’erreur apparaît

demandant de remplir le champ ‘ login ’.

Page 79: Rapport Projet  de fin d'etude sur le parc informatique

69 Chapitre 5 : mise en œuvre du projet

Figure 53 : fenêtre de la gestion des droits

Le superviseur fait l’appel à cette fenêtre pour bien gérer les droits de chaque utilisateur ou

groupe il commence par choisir un enregistrement puis la liste des éléments de l’application

s’afficheront t il choisit l’élément qui souhaite modifier ses droits d’accès où il y a quatre

types d’états pour les champs d’un élément : Défaut, inactive, Grisé et invisible.

Figure 54 : paramétrage des droits pour la fenêtre ‘ Fiche département ’

Page 80: Rapport Projet  de fin d'etude sur le parc informatique

70 Chapitre 5 : mise en œuvre du projet

Figure 55 : fenêtre des statistiques de connexion de l’application

Cette fenêtre permet au superviseur de voir les différents utilisateurs qui ont connecté à

l’application en précisant la date de début et la date de fin ou choisir une période déjà prédéfinie

comme la semaine en cours, le mois en cours… , elle donne les informations sur le login de cet

utilisateur, son adresse IP, la date de l’accès à l’application et l’heure après l’application du

filtre de la période.

Figure 56 : fenêtre de récupération des données

Page 81: Rapport Projet  de fin d'etude sur le parc informatique

71 Chapitre 5 : mise en œuvre du projet

Le superviseur demande cette fenêtre pour qu’il récupère une liste déjà fait concernant les

utilisateurs et leurs mots de passe ainsi les groupes et la configuration des droits, ces données

peuvent être en n’importe quels formats : Hyperfile SQL, Accès natif MySQL, dBase ….

Fenêtre principale

Figure 57 : fenêtre principale de l’application

C’est le point d’accès de l’application, juste après l’affichage un message d’alerte s’affiche

indiquant que un la date de garantie d’un matériel prend fin dans 30 jours ou moins (figure ci-

dessous), cette fenêtre d’alerte peut s’afficher plusieurs fois selon les matériels concernés.

Page 82: Rapport Projet  de fin d'etude sur le parc informatique

72 Chapitre 5 : mise en œuvre du projet

Figure 58 : Alerte de l’expiration de la garantie d’un matériel

Gestion des entreprises

Figure 59 : La liste des entreprises et la fiche de création d’une nouvelle entreprise

Page 83: Rapport Projet  de fin d'etude sur le parc informatique

73 Chapitre 5 : mise en œuvre du projet

Gestion des utilisateurs

Figure 60 : La liste des utilisateurs (employeurs) et la fiche de création d’un nouvel

employé

Cette fenêtre permet de faire la gestion des employés de la société, chaque utilisateur se

caractérise par le nom, prénom, la société qui travaille avec, le département concerné et aussi

le service qu’il s’en charge …

Gestion des matériels

Page 84: Rapport Projet  de fin d'etude sur le parc informatique

74 Chapitre 5 : mise en œuvre du projet

Figure 61 : La liste des matériels et la fiche d’ajout d’un nouvel matériel

La fiche de la création d’un nouvel matériel commence par choisir le type : ordinateur,

imprimante, écran…, ensuite choisir la marque et le modèle.

Le type, la marque, le modèle et la machine se créent par des autres fenêtres qui existent dans

l’application, 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

champs : date commande, N° commande, date d’achat et le prix achat HT qui s’affichent

Dans le pied de la fenêtre on trouve le fournisseur, la durée de garantie, numéro de facture, et

le type de garantie.

Page 85: Rapport Projet  de fin d'etude sur le parc informatique

75 Chapitre 5 : mise en œuvre du projet

Figure 62 : Rechercher un matériel

Dans cette fenêtre on choisit le type de matériel et aussi la marque afin que l’application nous

donne une liste contient les matériels qui répond au critère de la recherche.

Gestion des logiciels

Figure 63 : La liste des logiciels et la fiche d’ajout d’un nouvel logiciel

Le même principe que les logiciel sauf qu’ici le logiciel se caractérise par son éditeur et le

nombre de licences : soit de sélectionner illimité en cas d’un logiciel libre, soit de mentionné le

nombre de licences dans ce cas on doit déterminer le nombre de licence et aussi le prix unitaire.

Le champ ‘ Prix achat ’ se remplie automatiquement.

Page 86: Rapport Projet  de fin d'etude sur le parc informatique

76 Chapitre 5 : mise en œuvre du projet

Figure 64 : La liste des machines (poste de travail) et la fiche d’ajout d’une nouvelle

machine

Le superviseur demande cette fenêtre pour gérer les postes de travails du parc, pour ajouter une

nouvelle machine on mentionne : le nom du machine, on lui attribue un utilisateur et en coche

en attente dans le cas que ce poste attend l’activation ou cocher ‘ En prêt ’ s’il est prêt, la date

d’affectation et date pose

Conclusion

Ce chapitre a été consacré à la présentation des outils et technologies manipulés ainsi que la

présentation de l’application Gestion du parc informatique à travers la description de ses

différentes interfaces.

La conclusion de notre rapport fera l’objet de la section suivante.

Page 87: Rapport Projet  de fin d'etude sur le parc informatique

77 Conclusion et perspectives

Conclusion et perspectives

Ce projet m’a permis de mettre en pratique mon esprit d’étude, d’analyse et de critique. De

mettre en application certaines de nos connaissances et notre savoir acquis lors de la période de

la formation à l’ENSA et de découvrir la différence entre les projets professionnels et ceux à

caractère pédagogique.

Je rappelle que mon projet de fin d’études avait pour objectif la Réalisation et l’Intégration

d’une application de Gestion du parc informatique dans le portail interne d’ADDLOG.

L’analyse des besoins, la conception, la réalisation du système de gestion du parc informatique,

les tests unitaires et les tests d’intégrations ont été les phases du cycle de développement de

notre projet.

Ce stage a été également l’occasion de découvrir le dynamisme et l’enthousiasme qui

caractérise les équipes ADDLOG. Les réunions régulières effectuées avec mon encadrants dans

la société et à l’école m’ont permis de mettre en œuvre les concepts de gestion de projets acquis

à l’ENSA.

Les difficultés majeures que j’ai rencontrées durant ce projet résident essentiellement dans la

nouveauté des technologies WinDev 18 et surtout les nouvelles fonctions qui sont ajoutées par

rapport à la version 17 qui manque une documentation importante.

L’applicatif réalisé répond à la plupart des besoins actuels qui ont été formulé par les différents

intervenants que j’ai rencontrés. Reste à préciser que la conception effectuée et l’architecture

technique adoptée garantiront l’extensibilité du système développé et permettront d’ajouter

d’autres services pour répondre aux futurs besoins éventuels, aussi sans oublier j’ai eu une

occasion d’implanter le système de gestion du parc informatique au sein d’une autre société qui

s’appelle COFICAB , maintenant je fais le stage avec cette société, mais ici le travail demandé

c’était de transformer l’application selon les besoins de COFICAB.

Les perspectives possibles à la suite du présent projet sont multiples et couvrent plusieurs

aspects, tels que rendre l’application en architecture client-serveur, contrôler les postes de

travail à distant et ajouter des fonctionnalités comme les codes-barres imprimés dans les

factures…

Page 88: Rapport Projet  de fin d'etude sur le parc informatique

78 Développement d’une application de gestion d’un parc informatique

Bibliographie

[1] Addlog, Présentation de ADDLOG, Tanger, 27/06/212.

[2] Addlog, Organigramme de ADDLOG, Tanger, 29/05/2012.

[3] M. SAFY et S. Chelbat, Cahier des charges relatif à la Réalisation de l’application

de la Gestion du parc, Tanger, 25/04/2014.

[4] H. BENMOUSSA, Besoins et spécifications du parc informatique, Tétouan,

14/03/2014.

[5] H. BENMOUSSA, Plan d'action du projet : parc informatique, Tétouan,

26/03/2014.

[6] M. Blay-Fornarino, Activity Diagrams, Paris, 29/12/2013.

[7] JB, Pourquoi une méthode 'analyse' ?, 27/07/2007.

[8] D. Longuet, UML : Diagrammes de séquence, Paris-Sud, 22/10/2012.

[9] WinDev Développer 10 fois plus vite, Auto-formation version 18.

Page 89: Rapport Projet  de fin d'etude sur le parc informatique

79 Développement d’une application de gestion d’un parc informatique

Webographie

[10] http://fr.wikipedia.org/wiki/Merise_%28informatique%29

[11] http://www.commentcamarche.net/genie-logiciel/cycle-de-vie.php3

[12] http://fr.wikipedia.org/wiki/Gestion_libre_de_parc_informatique

[13] http://www.reseaucerta.org/docs/cotelabo/coteLaboOCSGLPI_V1.pdf

[14] http://fr.slideshare.net/nazihnemri/final-2-30702429

[15] http://www.pcsoft.fr/ - site officiel du windev

[16] https://www.facebook.com/groups/335517059889202/ - groupe de discussion

sur les problèmes techniques WinDev

[17]

http://fr.wikipedia.org/wiki/Cycle_en_V

Page 90: Rapport Projet  de fin d'etude sur le parc informatique

80 Annexe 1 : Le Design Pattern MVC

Annexe 1 : Le Design Pattern MVC

1. Le design pattern MVC

Le Modèle-Vue-Contrôleur (en abrégé MVC, de l'anglais Model-View-Controller) est une

architecture et une méthode de conception qui organise l'interface Homme-machine d'une

application logicielle. Il divise l'IHM en un modèle (modèle de données), une vue (présentation,

interface utilisateur) et un contrôleur (logique de contrôle, gestion des évènements,

synchronisation), chacun ayant un rôle précis dans l'interface. Cette méthode a été mise au point

en 1979 par Trygve Reenskaug, qui travaillait alors sur Smalltalk dans les laboratoires de

recherche Xerox PARC.

1.1. Architecture MVC

L'organisation globale d'une interface graphique est souvent délicate. L'architecture MVC ne

résout pas tous les problèmes. Elle fournit souvent une première approche qui peut ensuite être

adaptée. Elle offre aussi un cadre pour structurer une application.

Figure 65 : Architecture MVC

Page 91: Rapport Projet  de fin d'etude sur le parc informatique

81 Annexe 1 : Le Design Pattern MVC

Ce modèle d'architecture impose la séparation entre les données, les traitements et la

présentation, ce qui donne trois parties fondamentales dans l'application finale : le modèle, la

vue et le contrôleur.

1.1.1. Le modèle

Le modèle représente le comportement de l'application : traitements des données, interactions

avec la base de données, etc. Il décrit ou contient les données manipulées par l'application. Il

assure la gestion de ces données et garantit leur intégrité. Dans le cas typique d'une base de

données, c'est le modèle qui la contient. Le modèle offre des méthodes pour mettre à jour ces

données (insertion, suppression, changement de valeur). Il offre aussi des méthodes pour

récupérer ces données. Les résultats renvoyés par le modèle sont dénués de toute présentation.

Dans le cas de données importantes, le modèle peut autoriser plusieurs vues partielles des

données.

1.1.2. La vue

La vue correspond à l'interface avec laquelle l'utilisateur interagit. Sa première tâche est de

présenter les résultats renvoyés par le modèle. Sa seconde tâche est de recevoir toutes les actions

de l'utilisateur (clic de souris, sélection d'une entrées, boutons, …). Ses différents évènements

sont envoyés au contrôleur. La vue n'effectue aucun traitement, elle se contente d'afficher les

résultats des traitements effectués par le modèle. Plusieurs vues, partielles ou non, peuvent

afficher des informations d'un même modèle.

1.1.3. Le contrôleur

Le contrôleur prend en charge la gestion des évènements de synchronisation pour mettre à jour

la vue ou le modèle et les synchroniser. Il reçoit tous les évènements de l'utilisateur et enclenche

les actions à effectuer. Si une action nécessite un changement des données, le contrôleur

demande la modification des données au modèle et ensuite avertit la vue que les données ont

changé pour qu'elle se mette à jour. Certains évènements de l'utilisateur ne concernent pas les

données mais la vue. Dans ce cas, le contrôleur demande à la vue de se modifier. Le contrôleur

n'effectue aucun traitement, ne modifie aucune donnée. Il analyse la requête du client et se

contente d'appeler le modèle adéquat et de renvoyer la vue correspondante à la demande.

2. Avantages et inconvénients

Un avantage apporté par ce modèle est la clarté de l'architecture qu'il impose. Cela simplifie la

tâche du développeur qui tenterait d'effectuer une maintenance ou une amélioration sur le

projet. En effet, la modification des traitements ne change en rien la vue. Par exemple on peut

Page 92: Rapport Projet  de fin d'etude sur le parc informatique

82 Annexe 1 : Le Design Pattern MVC

passer d'une base de données de type SQL à XML en changeant simplement les traitements

d'interaction avec la base, et les vues ne s'en trouvent pas affectées.

Le MVC montre ses limites dans le cadre des applications utilisant les technologies du web,

bâties à partir de serveurs d'applications. Des couches supplémentaires sont alors introduites

ainsi que les mécanismes d'inversion de contrôle et d'inversion de dépendance.

Page 93: Rapport Projet  de fin d'etude sur le parc informatique

83 Annexe 2 : Le cycle de vie en V

Annexe 2 : Le cycle de vie en V

1. Définition

Le modèle du cycle en V ou Waterfall (en comparaison avec les méthodes dites Agile) est un

modèle conceptuel de gestion de projet imaginé suite au problème de réactivité du modèle en

cascade. Il permet, en cas d'anomalie, de limiter un retour aux étapes précédentes. Les phases

de la partie montante doivent renvoyer de l'information sur les phases en vis-à-vis lorsque des

défauts sont détectés, afin d'améliorer le logiciel.

Le cycle en V est devenu un standard de l'industrie logicielle depuis les années 1980 et depuis

l'apparition de l'ingénierie des systèmes est devenu un standard conceptuel dans tous les

domaines de l'Industrie. Le monde du logiciel ayant de fait pris un peu d'avance en termes de

maturité, on trouvera dans la bibliographie courante souvent des références au monde du

logiciel qui pourront s'appliquer au système.

2. Les étapes

On liste les différentes étapes pour ce type de cycle de vie :

Analyse des besoins et faisabilité

Spécification fonctionnelle

Conception architecturale

Conception détaillée

Codage

Test unitaire

Test d'intégration

Test Système : recette usine, validation usine, VAU

Test d'Acceptation : vérification d'aptitude au bon fonctionnement, VABF.

Une des différences entre la recette usine et la recette finale est essentiellement contractuelle.

Aussi, il n'est pas rare que le MOA (maître d'ouvrage) délègue la validation auprès d'un

organisme de validation, cet organisme étant bien souvent constitué d'experts afin de diminuer

les erreurs de validation.

3. Rôles

Page 94: Rapport Projet  de fin d'etude sur le parc informatique

84 Annexe 2 : Le cycle de vie en V

Dans le contexte des projets de grande envergure ont émergé des rôles pour partager et désigner

les responsabilités :

Maîtrise d'ouvrage (MOA) qui regroupe les fonctions suivantes :

o le maître d’ouvrage stratégique (MOAS) ;

o le maître d’ouvrage délégué (MOAD) ;

o le maître d’ouvrage opérationnel (MOAO) ;

o l’assistant à maîtrise d’ouvrage (AMOA ou AMO) ;

o l’expert métier ;

o enfin l’utilisateur, au service duquel se trouvent toutes les autres fonctions.

Maîtrise d'œuvre (MOE)

o Maîtrise d'œuvre déléguée (MOED)

o L’Équipe Architecturale

o L’Équipe de développement

o Titulaire de marché

Tableau 3 : Répartition des rôles en fonction des étapes

On retrouve dans ce découpage le V, d'où le nom de ce modèle.

4. Documents par phase

Page 95: Rapport Projet  de fin d'etude sur le parc informatique

85 Annexe 2 : Le cycle de vie en V

Tableau 4 : Documents en fonction des étapes

5. Risques inhérents au Cycle en V

Une fois l'ensemble des besoins capturés et les spécifications établies, il arrive que dès le niveau

de l'architecture, voire en phase de conception détaillée ou de codage, des difficultés d'ordre de

cohérence, technique et humain interviennent. C'est la fameuse différence entre la théorie et la

pratique : en théorie il n'y en a pas !

En pratique, il est difficile voire impossible de

totalement détacher la phase de conception d'un

projet de sa phase de réalisation. C'est souvent au

cours de l'implémentation qu'on se rend compte

que les spécifications initiales étaient

incomplètes, fausses, ou irréalisables, sans

compter les ajouts de nouvelles fonctionnalités

par les clients (scope creep). Lire à ce sujet Le

Mythe du mois-homme. C'est principalement

pour cette raison que le Cycle en V n'est pas

toujours adapté à un développement logiciel. La

problématique des projets

Longue durée qui sont adaptés sur ce mode

De gestion de projet est aussi souvent qu'ils risquent de ne plus « coller » aux besoins qui

évoluent dans le temps.

Figure 66 : Différence entre la théorie (les

spécifications) et la pratique (ce qui a été

produit)

Page 96: Rapport Projet  de fin d'etude sur le parc informatique

86 Annexe 2 : Le cycle de vie en V

D'autres modèles permettent plus facilement des modifications (parfois radicales) de la

conception initiale à la suite d'une première implémentation ou série d'implémentations. Voir

par exemple à ce sujet : Développement rapide d'applications ou Méthode agile de gestion de

projet.

6. Comité de pilotage

Pour améliorer le suivi du projet sur le plan de l'observation et des choix à effectuer, il se

constitue généralement une équipe transversale au projet : le comité de pilotage. Ce comité de

pilotage est généralement constitué d'un membre de chaque catégorie de rôle. Ce comité joue

en quelque sorte de rôle de gaine de protection autour du V. Ce comité analyse les métriques

issues des activités de chaque phase afin de réaliser la jonction entre la MOE et la MOA.


Recommended