Rapport Projet de fin d'etude sur le parc informatique

28 725 vues

Publié le

C'est mon rapport du mon projet de fin d’études qu'il s’agit du développement d'une application de gestion du parc informatique
autant qu'un étudiant 5 eme année du l’école nationale des sciences appliquées de tetouan (ENSAT) au maroc

Publié dans : Logiciels
3 commentaires
25 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
28 725
Sur SlideShare
0
Issues des intégrations
0
Intégrations
46
Actions
Partages
0
Téléchargements
1 899
Commentaires
3
J’aime
25
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Rapport Projet de fin d'etude sur le parc informatique

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

×