Académique Documents
Professionnel Documents
Culture Documents
D’Ingénieur d’Etat
Génie Informatique
Promotion 2013 – 2014
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é
BENMOUSSA Hicham
Résumé
Dans le cadre de mon projet de fin d’études à l’Ecole Nationale des Sciences Appliquées de
Tétouan (ENSAT) et en vue de l’obtention du titre d’ingénieur d’état en informatique, j’ai
effectué un stage de quatre mois à ADDLOG.
Durant mon séjour dans ladite société, j’avais pour mission dans un premier temps de concevoir
et de réaliser une application de gestion d’un parc informatique en suivant un cycle de vie qui
commence à l’étape de la conception/production/création jusqu'à la publication finale dans le
parc informatique en passant par les étapes de la vérification, de la validation et de
l’approbation. Dans un deuxième temps, j’étais amené à intégrer mon application dans le portail
interne de la société et assurer son opérabilité avec les différentes applications de son système
d’information.
Mon projet suit le model de cycle de vie en V, l’utilisation du formalisme UML pour la
réalisation de l’ensemble de diagrammes et enfin la modélisation MERISE puisqu’on nécessite
une base de données robuste, vise à détourner le problème. Ainsi, au terme de ce projet, j’ai pu
:
• Etablir une étude fonctionnelle et technique globale qui servira par la suite à continuer la
réalisation du système de gestion de parc informatique.
• Intégrer l’application dans le système d’information de la société
Liste des figures
3. Scénarios ..................................................................................................................... 15
4.2. Cas d’utilisation ‘Afficher les matériels achetés dans une période ’ ..................... 21
1. Présentation ................................................................................................................. 62
2. Réalisation de la solution ............................................................................................. 63
3. Développement : ......................................................................................................... 63
Bibliographie ........................................................................................................................ 78
Webographie ........................................................................................................................ 79
2. Avantages et inconvénients.......................................................................................... 81
1. Définition .................................................................................................................... 83
3. Rôles ........................................................................................................................... 83
6. Comité de pilotage....................................................................................................... 86
1 Développement d’une application de gestion d’un parc informatique
Introduction
du portail résultant d’une étude comparative passant au crible un ensemble de portails répondant
aux exigences de la société. Enfin, le cinquième chapitre est consacré à la phase de la réalisation
et la mise en œuvre du système. Il est constitué de deux parties, à savoir la partie réalisation
dans laquelle on a décrit les outils que j’ai manipulés et la partie de la mise en marche de
l’application qui présente quelques interfaces.
Ce rapport se termine par une conclusion contenant quelques perspectives pour le système de
gestion d’un parc informatique.
En complément, on présente les différentes annexes qui serviront pour élargir la portée du projet
tout en restant dans son environnement, à savoir la suite des spécifications du système, ainsi
que quelques annexes traitant l’aspect technique et organisationnel du projet.
3 Chapitre 1 : Contexte général du projet
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.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.
Et au niveau réseaux :
Dans cette partie, je présente le projet, les objectifs s’inscrivant dans le cadre de ce dernier et le
champ d’application.
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.
UML définit 9 diagrammes pour donner à l’utilisateur les moyens de visualiser et de manipuler
des éléments de modélisation : diagrammes d’activités, diagrammes de cas d’utilisation,
diagrammes de classes, diagrammes de collaboration, diagrammes de composants, diagrammes
de déploiement, diagrammes d’états transitions, diagrammes d’objets et diagrammes de
séquences.
Le choix d’UML, comme outil de modélisation des flux et les différentes actions de
l’application, peut être justifié par plusieurs raisons :
• UML facilite la compréhension et la communication d’une modélisation objet,
• La notation UML s'impose comme un standard de fait à l'heure actuelle sur le marché,
• Il est adopté par les grands constructeurs de logiciel du marché,
• L’utilisation d’UML offre l’avantage de disposer de vues de haut niveau d'abstraction,
• Pour favoriser la communication entre utilisateurs, spécialistes et informaticiens.
Conclusion
Dans ce chapitre j’ai décrit le contexte général dans lequel s’inscrit le projet. Au début, j’ai
présenté l’entreprise d’accueil à savoir ADDLOG. Ensuite, j’ai déterminé la problématique et
les objectifs du projet qui se résument en la réalisation d’un système de gestion du parc
informatique. Après, j’ai présenté la démarche que j’ai suivie pour arriver à mon but et cela
par la présentation du processus de développement ou cycle de vie du projet que j’ai adopté en
l’occurrence le model en V. Puis, le formalisme merise pour la conception de la base de
données et aussi UML qui m’a servi de standard dans la réalisation des diagrammes de
modélisation relatifs à notre projet et ce, afin d’illustrer son fonctionnement.
Dans le chapitre suivant je présentera les spécifications du système.
13 Chapitre 2 : Etude et spécification des besoins
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.
Tableau 2 : Acteurs du système
3. Scénarios
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
22 Chapitre 2 : Etude et spécification des besoins
Figure 11 : fenêtre du cas d’utilisation ‘Afficher les matériels achetés dans une période’
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.
Conclusion
Ce chapitre a donné une première vision sur les fonctionnalités de l’application de la gestion
du parc informatique. Dans ce chapitre, j’ai choisi de décrire 6 cas d’utilisation primaires
dans l’application.
Le chapitre suivant donnera la vision conceptuelle de l’application.
32 Chapitre 3 : Conception
Chapitre 3 : Conception
Ce chapitre définit les éléments résultant de l’analyse des spécifications de l’application de la
Gestion de parc informatique. Les contraintes et les choix de conception seront présentés dans
ce chapitre.
1. Stratégie de développement
L’application à développer sera sous forme d’une application et un petit portail web qui sert à
faire la communication entre l’application et le serveur d’application, Un portail traite les
requêtes d'une tâche ou d'un service donné et génère dynamiquement le contenu web affiché à
l’utilisateur, aussi l’application permet de faire la configuration complète du parc informatique
on se basant sur le serveur qui va faire les traitements qui concerne le parc , aussi elle va me
permettre de me fournir toutes sortes de services généralistes ou spécialisés ( interface de
consultation des informations sur la société, panneau d'information, La gestion des licences, la
gestion des contrats fournisseurs, …)
De point de vue de l’interface de l’application j’ai préféré de travailler avec des fenêtres
modales qui sont , dans une interface graphique, des fenêtres qui prennent le contrôle total du
clavier et de l'écran. Elles sont en général associées à une question à laquelle il est impératif
que l'utilisateur réponde avant de poursuivre, ou de modifier quoi que ce soit, c.à.d. pour
l'application : seule cette application est bloquée jusqu'à la réponse ou l’attente de la valeur de
retour de cette fenêtre ;
Et finalement l’application utilise un seul gabarit (style de l’interface) pour toutes ses
composantes (fenêtres, boutons, Listes déroulantes,…) afin d’être ergonomique et facile à
utiliser.
Cette partie présente les activités (diagrammes d’activités) majeures du système de l’application
de la gestion du parc informatique.
Le champ Rédacteur nous permet de savoir qui est l’utilisateur qui a ajouté un enregistrement
dans une table.
Cette table contient les champs comme il est indiqué sur la figure ci-dessous.
Conclusion
1. L’environnement WinDev
• 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.
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.
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.
2. Architecture et outils
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 :
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.
Durant cette phase, l’équipe RAD (SWAT) doit construire l’application module par module.
L’utilisateur participe toujours activement aux spécifications détaillées et à la validation des
prototypes. Plusieurs sessions itératives sont nécessaires. Cette phase représente environ 50%
du projet. A partir de la phase de Construction, à la parallélisassions du travail peut s’ajouter la
sérialisation.
Finalisation :
Recette et déploiement.
Des recettes partielles ayant été obtenues à l’étape précédente, il s’agit dans cette phase
d’officialiser une livraison globale et de transférer le système en exploitation et maintenance.
Cette phase représente environ 12% du projet.
Outils RAD :
La méthode, sans être liée aux outils, recommande l'utilisation d'outils de programmation à
interface graphique (CASE), qui permet d'obtenir rapidement des prototypes. A ce sujet, il ne
faut pas confondre la méthode RAD (d'où sont issues les approches Agiles actuelles) qui
recherche la qualité applicative fonctionnelle et technique avec les outils RAD, dont la
production automatique de code est souvent qualifiée de "sale".
• Powerbuilder
• uniPaaS (anciennement connu sous le nom de Magic eDeveloper) est une plateforme
RAD qui accélère le développement d'applications Métier en associant un paradigme de
développement unique de bout en bout à un moteur de règles fondé sur les métadonnées.
Le développement est accéléré de par le fait que le code est précompilé dans le système.
• Delphi (Lazarus ou ainsi que le Visual Basic) est un outil RAD en ce sens qu'il permet
assez facilement de créer des programmes à l'aide d'une interface graphique dotée de
nombreux outils et de modules prêts à l'emploi.
• WinDev (ainsi que WebDev) est un outil RAD plus avancé car il permet à partir d'une
analyse Merise ou UML de produire un applicatif final et opérationnel.
WinDev Mobile permet lui de créer rapidement des applications pour les matériels
mobiles.
• Authorware crée lui-aussi un applicatif final en dessinant un diagramme à l'aide
d'icônes.
• JBuilder
• C++ Builder
• C# Builder
• Leonardi est un outil RAD adapté au développement des IHM.
58 Chapitre 4 : Etude technique du projet
• Limbas est un outil RAD 100% web (développement et application cible) sous licence
GNU GPL 2 incluant notamment des fonctionnalités GED et Groupware.
2.2.2 WLangage
Le WLangage est un langage de programmation de 5éme génération inclus dans les outils de
développement WinDev, WebDev et WinDev Mobile. Il est propriétaire et ne peut être
manipulé qu'avec les outils PC SOFT. Le WLangage est né en 1992 avec la première version
de WinDev.
Même s'il y a explicitement une première phase précoce de compilation, le byte code WLangage
est exécuté par une machine virtuelle ou converti en code natif lors de l'exécution par un
compilateur à la volée (Just in time, JIT). Le Framework est disponible sous Windows (32 bits,
64 bits et CE) et partiellement sous Linux (sans interface graphique).
Le WLangage peut également s'appuyer sur le Framework Java pour une partie de ses
fonctionnalités, ce qui permet une indépendance relative et limitée du fichier exécutable par
rapport au système d'exploitation cible. Il en va de même dans WebDev, où le WLangage peut
s'appuyer sur le Framework PHP, sans toutefois permettre d'utiliser toutes les possibilités de ce
dernier.
Initialement prévu pour Windows, une partie des fonctions du WLangage est basée sur l'API
Microsoft Windows.
Le WLangage est un langage de programmation procédurale qui permet la programmation
impérative et la programmation orientée objet. C'est en fait un langage de programmation multi-
paradigme.
Le WLangage contient des fonctions de haut niveau, telle que la fonction EcranVersFichier,
qui effectue les affectations du contenu des champs d'une fenêtre vers des tables stockées dans
un fichier ou des variables, auxquelles les champs ont été préalablement reliés (databinding).
Le WLangage autorise une utilisation souple du typage. Les variables doivent être typées mais
les paramètres formels des procédures ou les itérateurs de boucles peuvent ne pas l'être. Il est
ainsi possible dans un même projet de combiner des procédures avec typage strict pour profiter
de la rigueur du typage statique et des procédures sans typage pour profiter de la souplesse du
typage dynamique et du duck typing.
2.3.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.
• Sécurité d’accès : la protection contre l’injection SQL est assurée via la création
automatique d’IHM sécurisées.
Figure 46 : HyperFileSQL
61 Chapitre 4 : Etude technique du projet
Conclusion
Ce chapitre avait comme but de présenter l’ensemble de mes recherches au niveau des
technologies et de l’environnement dans lequel s’inscrit mon projet, aussi j’ai introduit les
outils et les langages que j’ai utilisés pour la réalisation de mon application le chapitre suivant
présente la réalisation et la mise en marche de l’application
62 Chapitre 5 : mise en œuvre du projet
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
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.
3. Développement :
Développement : WinDev.
Conception de la base de données : WinDev.
Modélisation (diagrammes) : Edraw max
Partie Superviseur
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 ’.
69 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
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.
72 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.
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…
78 Développement d’une application de gestion d’un parc informatique
Bibliographie
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
[17] http://fr.wikipedia.org/wiki/Cycle_en_V
80 Annexe 1 : Le Design Pattern MVC
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
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.
83 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
3. Rôles
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é
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.