Soutenance 1 [PDF]

Zitiervorschau

Université de la Manouba

École Supérieure d’Économie Numérique

Rapport De projet de fin d'études Présenté en vue de l'obtention du diplôme de Licence appliqué en Informatique appliquée à la gestion Sujet

Conception et développement d’une plateforme d’analyse de log Élaboré par: Agha Mohamed Mehdi Boubaker Allaedine

Organisme d’accueil : VERMEG

Encadré par Encadrante Académique Mme. Inès Thabet Encadrant professionnel M. Tarek Guermazi Encadrante pédagogique Mme. Inès Gam Année universitaire : 2017-2018

Remerciements A l’éternel, DIEU le tout puissant, qui nous ‘a donné la force et la patience de réaliser ce modeste travail. Je tiens à remercier très chaleureusement notre encadrant Madame le professeur INES THABET pour la confiance qu’il nous ’a donné en acceptant de nous ’encadrer, ainsi pour ses précieux conseils, son aide et sa patience du début à la fin de ce travail. C’est un grand honneur pour nous, le fait que vous avez accepté d'encadrer notre projet de fin d’études. Je tiens aussi à remercier mon encadrant à la société VERMEG, Monsieur Tarek Guermazi pour son aimable accueil au sein de son équipe. Qu’il trouve ici notre profonde gratitude pour son encadrement sérieux et son soutien inlassable.

Nos remerciements s’étendent également à Monsieur MOHAMED BEN BRAHIM le chef de projet de l’équipe. Nous lui remercions pour ses conseils et son encouragement.

J’exprime toute ma reconnaissance et gratitude aux membres du jury pour l’intérêt qu’ils ont appuyé à notre travail en acceptant d’analyser mon travail. Un grand merci pour toutes les personnes qui ont contribué de près ou de loin à la réussite de ce travail.

Qu’il nous soit enfin permis d’adresser une pensée spéciale à nos familles pour leurs amours, leur soutiens et leur encouragements.

DEDICACES Je dédie ce travail A la source de tendresse, d’amour et de générosité, A ma très chère mère AMEL, A mon père parfait MUSTAPHA, Qui ont été toujours présents par leurs sacrifices inoubliables, aucune dédicace ne pourrait exprimer mon amour que j’ai toujours eu pour vous, les prunelles de mes yeux, A ma sœur Imen, Pour son partage sans égal,

A mes grands-parents, mes tantes et oncles, Et en particulier ma tante AWATEF pour son encouragement continu Veuillez apprécier dans ce travail tout mon respect,

A mes amies et sœurs AZIZ, OMAR, FARES, YOUSSEF, OURSOUENE, EMNA, KENZA, GHOFRANE et FATMA Pour leur appui moral durant cette période, je présente mon profond attachement avec tous mes souhaits de réussite

Mehdi

A mon père Hedi, L’homme de référence, le géant dans l’ombre de qui j’ai fait mes premiers pas, celui qui m’a appris patiemment tant de choses, qui m’a donné l’éducation et les armes pour affronter sereinement la vie, toujours positif et débordant d’optimisme, toujours à l’écoute, avec qui j’ai partagé tant de joies, qui m’a soutenu dans tant d’épreuves. Adieu Papa et merci pour tout. A ma mère Mounira Pour tout leur soutien, pour tout leur sacrifice, pour leur amour et pour tout l’enseignement qu’ils m’ont transmis.

A mon frère Sirajeddine et ma sœur Dorra, Avec tous les souhaits d’un grand succès dans leur vie.

A mes amis et mes collègues, Qui ont contribué à mon épanouissement.Mercid’être toujours près de moi, merci de m’avoir aidé chaque jour à avancer.

Allaedine

Table des matières Introduction générale ..............................................................................................................1 Chapitre 1 : Contexte Général .................................................................................................3 1. Introduction .....................................................................................................................3 2. Entreprise d’accueil .........................................................................................................3 2.1. Produits de VERMEG ................................................................................................4 2.2. Unité d’accueil ...........................................................................................................5 3. Présentation de projet ......................................................................................................6 3.1. Cadre du stage ..........................................................................................................6 3.2. Problématique ...........................................................................................................6 3.3. Objectifs ....................................................................................................................6 3.4. Travail demandé........................................................................................................6 4. Etude de l’existant ...........................................................................................................7 4.1. Log ............................................................................................................................7 4.2. Analyseurs de log existants .......................................................................................7 4.3. Notion du fichier Log ..................................................................................................8 5. Etude d’analyseurs de log existants .................................................................................8 5.1. ELK ..................................................................................................................................... 8 5.2. Graylog .....................................................................................................................9 5.3. Log Surfer ...............................................................................................................10 6. Critique de l’existant ......................................................................................................10 7. Solution Proposée .........................................................................................................11 8. Méthodologies de travail ................................................................................................11 8.1. Méthodologie agiles.................................................................................................11 8.2. Méthodologie agile adoptée : Scrum ........................................................................12 8.2.1. Justification du choix de la méthodologie ...........................................................13 8.2.2. Les rôles de la méthode Scrum ..........................................................................13 8.2.3. Équipe du projet ................................................................................................14 9. Langage de modélisation UML (Unified Modeling Language)..........................................15 10. Conclusion ..................................................................................................................16 Chapitre 2 : Analyse du projet................................................................................................17

1. Introduction ...................................................................................................................17 2. Recensement des besoins .............................................................................................17 2.1. Identification des acteurs .........................................................................................17 2.2. Besoins fonctionnels................................................................................................17 3. Structure et découpage de projet...................................................................................18 3.1. Identification de l’équipe SCRUM.............................................................................18 3.2. Backlog de produit ...................................................................................................18 3.3. Planification des sprints du projet .............................................................................19 4. Diagramme de cas d’utilisation général ..........................................................................20 4. Conclusion ....................................................................................................................21 Chapitre 3 Sprint I «Demande d’une analyse d’un fichier log» ................................................22 1. Introduction ...................................................................................................................22 2. Spécification fonctionnelle .............................................................................................22 2.1. Sprint backlog .........................................................................................................22 2.2. Prototypage des interfaces ......................................................................................24 3. Diagramme des cas d’utilisation du premier sprint ..........................................................25 4. Analyse des cas d’utilisation ..........................................................................................25 4.1. Analyse de cas « S’authentifier » .............................................................................25 4.2. Analyse de cas « Demande une analyse » ...............................................................27 5. Conception ....................................................................................................................30 6. codage ..........................................................................................................................31 7. Test ...............................................................................................................................32 8. Revue du sprint .............................................................................................................34 9. Conclusion ....................................................................................................................35 Chapitre 4 Sprint 2 «Gestion des utilisateurs» .......................................................................36 1. Introduction ...................................................................................................................36 2. Sprint fonctionnelle ........................................................................................................36 2.1. Sprint backlog .........................................................................................................36 2.2. Prototypages des interfaces ....................................................................................37 3. Spécification fonctionnelle .............................................................................................39 4. Analyse des cas d’utilisations .........................................................................................39 4.1. Analyse du cas « Consulter les statistiques » ...........................................................39 4.2. Analyse du cas « Gérer des utilisateurs » .................................................................41 5. Diagramme de classe globale ........................................................................................45

6. codage ..........................................................................................................................46 7. Test ...............................................................................................................................48 8. Conclusion ....................................................................................................................50 Chapitre 5: Phase de clôture .................................................................................................51 1. Introduction ...................................................................................................................51 2. Environnement logiciel...................................................................................................51 3. Conception Architecturale ..............................................................................................54 3.1. Choix de l’architecture de l’application .....................................................................54 3.2. Architecture MVC ....................................................................................................54 4. Diagramme de déploiement ...........................................................................................56 5. Conclusion ....................................................................................................................56 Conclusion générale .............................................................................................................58 Références bibliographiques ................................................................................................60

Table des illustrations Figure 1.1: Vermeg Logo ........................................................................................................................ 4 Figure 1.2 : Palmyra Logo ....................................................................................................................... 4 Figure 1.3:Organisation de VERMEG .................................................................................................... 5 Figure 4:Equipe et rôles......................................................................................................................... 18 Figure 5:Plannification des sprints ........................................................................................................ 20 Figure 6:Diagramme de cas d'utilisation générale ................................................................................. 21 Figure 7:Prototype de l'interface « S'authentifier » ............................................................................... 24 Figure 8:Prototype de l'interface demande une analyse ........................................................................ 24 Figure 9: Raffinement du cas d'utilisation du premier sprint................................................................. 25 Figure 10:Diagramme de séquence système du cas « S'authentifier » .................................................. 26 Figure 11:Diagramme de séquence détaillé du cas « S'authentifier » .................................................. 27 Figure 12:Diagramme de classes participantes du cas « S'authentifier » .............................................. 27 Figure 13:Diagramme de séquence système du cas « Demande une analyse »..................................... 29 Figure 14:Diagramme de séquence détaillé du cas « Demande une analyse » ...................................... 29 Figure 15:Diagramme de classe globale du premier sprint ................................................................... 30 Figure 16:Interface d'authentification.................................................................................................... 32 Figure 17:Interface de contrôle d'authentification ................................................................................. 33 Figure 18:Interface demande d’une analyse .......................................................................................... 33 Figure 19:Interface de résultat d'une analyse ........................................................................................ 34 Figure 20:Prototype de l'interface « consulter les statistiques » ............................................................ 37 Figure 21:Prototype de l'interface « consulter les utilisateurs » ............................................................ 38 Figure 22:Prototype de l'interface « modifier un utilisateur » ............................................................... 38 Figure 23:Prototype de l'interface ajouter un utilisateur........................................................................ 38 Figure 24:Diagramme de cas d'utilisation du deuxième sprint .............................................................. 39 Figure 25:Diagramme de séquence système du cas « Consulter les statistiques » ................................ 40 Figure 26:Diagramme de séquence détaillé du cas Consulter les statistiques ....................................... 40 Figure 27:Diagramme de classes participantes du cas Consulter les statistiques .................................. 41 Figure 28:Diagramme de séquence système du cas « Gérer des utilisateurs »...................................... 43 Figure 29:Diagramme de séquence détaillé du cas « Gérer les utilisateurs » ........................................ 44 Figure 30:Digramme de classes participantes du cas « Gérer les utilisateurs » .................................... 45 Figure 31:Diagramme de classe globale du deuxième sprint ......................................................................46 Figure 32:Interface de consultation des utilisateurs .............................................................................. 48 Figure 33:Interface d'ajout d'un nouvel utilisateur ................................................................................ 49 Figure 34:Interface de modification d'un utilisateur existant ................................................................ 49 Figure 41: Architecture MVC ............................................................................................................... 55 Figure 42: Architecture MVC ............................................................................................................... 55 Figure 43:Daigramme de déploiement .................................................................................................. 56

Liste des tableaux

Introduction générale

Introduction générale Avec l’avancement fulminant d’internet, la sécurité informatique augmente de plus en plus dans les entreprises qui n’abandonnent à immortaliser et transvaser un bloc extraordinaire de données critiques à travers leurs réseaux locaux ou étendus.

La perpétuité de l’entreprise gratte par une disponibilité indéfrisable de son système d’information. Cette réalité influe de nos jours le comportement des entreprises qui devient de plus en plus mature dans les apports de la sécurité du système d’information qui est un élément assurément essentiel. Les efforts de sécurisation ne peuvent pas être efficaces que si ces investissements sont correctement étudiés et ciblés, en mettant en place les moyens de protection qui apportent un niveau de sécurité favorable adapté aux enjeux de l’entreprise. Dans le cadre de projet de fin d’étude nous sommes menés à développer une plateforme d’analyse log au sein de la société VERMEG. Cette plateforme a pour but de faciliter la compréhension de fichier log et pour détecter les applications contenant plus d’erreurs. Ce rapport présente l’ensemble des étapes suivies pour développer la solution. Il contient cinq chapitres organisés. Le premier chapitre est consacré à la présentation de contexte général. Nous commençons par la présentation de l’organisme d’accueil et le projet en présentant les problématiques et les objectifs. Ensuite, nous passons à l’étude et à la critique de l’existant pour enfin proposer une solution adéquate. La méthodologie utilisée sera également définie à la fin de ce chapitre pour nous permettre de réaliser convenablement notre travail. Le second chapitre est intitulé sur l’analyse des besoins fonctionnels, non fonctionnels et architecturaux. Ensuite nous identifions les acteurs participants et nous modélisons les besoins des utilisateurs via les diagrammes de cas d’utilisation. Le troisième chapitre est réservé à la conception et à l’architecture du projet ; nous commençons dans un premier temps par une étude préliminaire en présentant les packages de systèmes puis le contenu de chacun de ces derniers, en second temps on présente les diagrammes de séquences de conception détaillés, les diagrammes d’activités correspondants aux workflow et le déploiement de l’application. Le quatrième chapitre quant à lui est dédié à la réalisation. Celui-ci, passe par la présentation de l’environnement matériels, logiciels et les interfaces de l’application. 1

Introduction générale

Pour finir, un chapitre qui contient une conclusion générale de tout le rapport est nécessaire où nous rappelons de contexte et des besoins puis on décrit le bilan de réalisations nous proposons les futures améliorations qui peuvent être ajoutées ultérieurement.

2

Chapitre 1 Contexte général

Chapitre 1 : Contexte Général 1. Introduction L’idée d’un projet vient généralement d’un besoin exprimé par la société. Dans ce premier chapitre, nous commençons par la présentation de l’organisme d’accueil. Ensuite, nous passons à la présentation de projet en décrivant la problématique et les objectifs de notre projet, et pour terminer, nous spécifions la méthodologie de gestion de projet et la didactique du développement

2. Entreprise d’accueil Notre projet a été réalisé au sein de l’entreprise VERMEG qui a été créé en 1994, initialement au sein sous le nom BFI et a été séparé de BFI en 2002. Groupe international basé en France, Belgique, Luxembourg et Tunisie, composé de plus de 700 collaborateurs et disposant de clients dans plus de 20 pays, Vermeg est spécialisé dans l'édition de logiciels financiers. Depuis plus de 20 ans, Vermeg propose des solutions logicielles innovantes adaptées aux problématiques de ses clients, qu'ils

soient

assureurs

de

personnes

avec

les

solutions Solife et Soliam for Asset Owners, sociétés de gestion ou banques privées avec la solution Soliam for Wealth Managers, spécialistes des infrastructures de marché et des métiers titres avec la suite Megara. Vermeg est également partenaire de la transformation digitale en finance et assurance, avec l'offre digital financier services, appuyée sur des composants financiers, des méthodes agiles 'Time-to-Market', ainsi que des composants digitaux, articulés autour du Framework de Vermeg, Palmyra. Passionnés par les Technologies autant que par l'humain, les collaborateurs de Vermeg sont engagés dans un programme RSE d'entreprise, 'Empowered by Vermeg', visant aux actions de développement personnel, sociétal et environnemental.

3

Chapitre 1 Contexte général

VERMEG a participé pleinement à la création de l’association TACT, qui regroupe des acteurs clés du marché tunisien, afin de former près de 1.000 diplômes par an dans les métiers de l’ITO (Information Technology Outsourching). Enfin le groupe est un champion de la diversité en Tunisie : 40% de son effectif est composé de femmes, ce qui place VERMEG première entreprise en diversité dans le marché des TIC.

Figure 1.1: Vermeg Logo

2.1. Produits de VERMEG 1. Palmyra : Palmyra est un Framework J2EE (Java Enterprise Edition) compatible SOA (Architecture Orienté Service) qui incorpore des composants ainsi que des services web réutilisables. Etant basé principalement sur l’ingénierie dirigée par les modules, Palmyra génère des applications entières à partir de modèles UML préalablement définis. L’idée est d’automatiser la projection des modèles métier d’une application sur n’importe quelle plateforme. L’automatisation de la génération de code constitue donc un atout essentiel pour l’équipe de développement.

Figure 1.2 : Palmyra Logo 2. La suite MEGARA (FMSS) : C’est une plate-forme modulaire pour le traitement des titres, destinée essentiellement aux institutions financières. Elle propose un nombre de modules pouvant être implémentés séparément. MEGARA comporte ces composants :  MEGACOR : C’est un logiciel qui automatise la plupart des opérations sur titres et est compatible ISO 15022. Le label SwiftReady Corporate Action Gold lui a été décerné.

4

Chapitre 1 Contexte général

 MEGACUSTODY : C’est un logiciel de livraison, lui aussi récompensé par le label SWIFTTRADY Securities Settlement Gold.  MEGALEND : C’est un logiciel pour le suivi des prêt/emprunt de titres.  MEGATRADE : Il consiste à un système de centralisation et de gestion des ordres de ventes/achats 3. Soliam (WAM) : C’est une solution de gestion de portefeuilles pour les gestionnaires d’actifs institutionnels de fortune. 4. SoLife (PI) : Une solution d’administration de polices d’assurance vie et un portail web à destination des clients finaux/brokers. Ayant une présence internationale en Belgique, France, Irlande, Luxembourg, Pays-Bas, Suisse, Royaume-Uni, Tunisie et des clients dans plus de 23 pays 

SoLife et Soliam sont considérés comme les deux produits phares de Vermeg.

2.2. Unité d’accueil L’entreprise se compose de quatre départements représentés par la figure1.3:  Marketing et Sales :Ce département est responsable de tout ce qui est marketing, la gestion des ventes et de la prospection.  Customer Services : Cette branche gère les relations avec le client et comprend également une cellule de veille technologique.  Recherche et Développement : Ce secteur gère le développement et effectue les tests et la validation des applications.  Support : Responsable du support IT, de l’assistance à l’installation et l’utilisation des produits livrés et des mises à jour. Dans l’entreprise VERMEG on est situé dans le département Recherche et Développement

Figure 1.3:Organisation de VERMEG

5

Chapitre 1 Contexte général

Organisation de l’entreprise VERMEG Groupe compte 4 principales unités à savoir : 

Pension and Insurance (PI).



Wealth and Assest Management (WAM).



Financial Markets and Securities Services (FMSS).



Digital Financial Services (DFS).

3. Présentation de projet 3.1. Cadre du stage Ce stage effectué au sein de l’entreprise Vermeg Tunis, s’inscrit dans le cadre du projet de fin d’études pour l’obtention du diplôme de licence en informatique de gestion de l’ESEN. Le stage est effectué de 12/02/2018 au 11/05/2018.

3.2. Problématique Parfois les clients de Vermeg souffrent des crushs et des bugs des applications lors des opérations financières, donc il est difficile de trouver les bugs. De plus Vermeg, utilise des Outils de surveillance et d’analyse payants .Ces couts d’installation et de maintenance sont énorme, de plus les utilisateurs dans l’équipe

de

Palmyra trouve des difficultés au niveau d’utilisation de ces outils de surveillance de logs. D’où l’idée est de créer une plateforme d’analyse des fichiers de log dédié à la société et l’équipe.

3.3. Objectifs L’objectif principal est le développement d’une plateforme d’analyse de log qui facilite aux utilisateurs et les analystes d’analyser ces fichiers en se basant sur des filtres bien déterminer au niveau d’application et de filtrer leur résultat avec des autres filtres et de gérer des statistiques .

3.4. Travail demandé Le projet sur lequel nous allons travailler consiste à avoir une plateforme d’analyse de log de Framework Palmyra dans Vermeg. Il s’agit de mettre en place une solution web qui se charge d’analyser des fichiers logs.

6

Chapitre 1 Contexte général

Cette analyse va être programmée en se basant sur des filtres (les niveaux, date adresse IP, adresse MAC, description et les requêtes SQL). Afin d’atteindre ces objectifs, nous avons suivi un processus de développement itératif et incrémental. D’ailleurs, comme l’évolution rapide et incrémentale est l’enjeu principal de notre projet, nous avons adopté une méthodologie agile.

4. Etude de l’existant 4.1. Log Dans le domaine informatique, le terme log désigne un type de fichier dont son rôle principal consiste à stocker un historique des événements. Le log s’apparente ainsi à un journal de bord horodaté, qui ordonne les différents événements qui se sont produits sur un ordinateur, un serveur, il permet ainsi d’analyser heure par heure, voire minute par minute l’activité interne d’un processus. Ainsi, il est principalement utilisé pour tenter d’identifier les raisons et/ou l’origine d’une panne informatique. https://www.journaldunet.fr/web-tech/dictionnaire-du-webmastering/1203463-logdefinition-traduction/

4.2. Analyseurs de log existants Afin d’atteindre les objectifs de notre projet, l’étude du système existant et des différents moyens mis à notre disposition est une étape inévitable. En effet, il faut d’abord décortiquer les fonctionnalités déjà développés. Ensuite, nous pouvons dégager les solutions qui peuvent faire face aux problèmes liées aux solutions existantes. De ce fait, nous allons, d’une part, présenter les notions de fichier log. D’autre part ,nous allons étudier les solutions d’analyse des fichiers de logs existants ,comprendre leurs mode de fonctionnement et dégager les faiblesses et les limites qui ont motivé le lancement de ce projet pour détailler, finalement, les solutions possibles et celle retenue.

7

Chapitre 1 Contexte général

4.3. Notion du fichier Log Dans le domaine informatique, le terme log désigne un type de fichier dont son rôle principal consiste à stocker un historique des événements. Le log s’apparente ainsi à un journal de bord horodaté, qui ordonne les différents événements qui se sont produits sur un ordinateur, un serveur, il permet ainsi d’analyser heure par heure, voire minute par minute l’activité interne d’un processus. Ainsi, il est principalement utilisé pour tenter d’identifier les raisons et/ou l’origine d’une panne informatique.

5. Etude d’analyseurs de log existants Sur le marché plusieurs logiciels pour l’analyse des fichiers log payants ou open source. Parmi ces logiciels nous retrouvons :

5.1. ELK La stack ELK est une solution open source, de la société elastic,composée de trois produits que sont Elasticsearch, Logstash et Kibana, qui permettent de parser, indexer et présenter de gros volumes de données issues de vos logs sous forme de dashbords et de faire des recherches au sein de vos logs comme vous pourriez le faire avec un moteur de recherche. La figure 2.1 montre un aperçu de l’interface de Kibana après avoir passé les logs par Logstash et Elasticsearch. https://blog.netapsys.fr/vos-logs-passent-la-seconde-avec-elk-elasticsearch-logstashkibana/comment-page-1/

Figure 2.1 : Aperçu de l’interface Kibana

8

Chapitre 1 Contexte général

Après avoir stocké les fichiers logs, il faut les envoyer vers Elasticsearch, ce dernier est un moteur de recherche libre et open source, il permet d’indexer les données à partir des requêtes HTTP en utilisons une interface de type API web. Nous expliquons l’utilisation d’ELK par la figure 2.2 :

Figure 2.2 : Utilisation d’ELK

5.2. Graylog https://korben.info/graylog-un-outil-de-centralisation-et-danalyse-de-logs.html Graylog est un outil open sourcebaptisé, il est capable de collecter, indexer et analyser des données structurées et non structurées en provenance de diverse sources. Ce logiciel offre plusieurs avantages comme : 

L’accès à l’interface web nécessite un login et un mot de passe.



Il permet d’analyser les logs en temps réel.

Figure 2.3: Aperçu de l’interface Graylog

9

Chapitre 1 Contexte général

5.3. Log Surfer Log surfer est un programme simple et efficace qui permet de surveiller les fichiers logs en temps réel et envoyer des alertes lorsque des anomalies se produisent. Contrairement à d’autres systèmes de supervision, Log surfer peut être modifié et réglé afin d’envoyer uniquement des alertes simples contenant toutes les informations pertinentes et non pas un déluge de courriels à l’opérateur. Log surfer peut être utilisé pour déceler les défauts et les événements de sécurité avant qu’ils ne deviennent des problèmes graves.

6. Critique de l’existant Nous résumons dans le tableau 3.1 les différences entre les outils citées dans la section précédente : Critères fonctionnels

ELK

Graylog

Log Surfer

Analyse des fichiers Logs

Oui

Oui

Oui

Notification par mail

Oui

Non

Oui

Complexité

Oui

Non

Non

Gratuit

Oui

Oui

Oui

Temps réel

Oui

Oui

Oui

Tableau 1 : Etude Comparative Chacun de ces applications ont des malaises qui ne peuvent pas l’oublier, nous citons par exemple pour la première solution KIBANA elle est complexe et elle nécessite une formation pour pouvoir la comprendre. Graylog, elle est utilisable sauf sur le système d’exploitation Linux. Concernant Log surfer, il est très difficile à configurer, il ne permet que l’envoie des alertes en temps réel. En effet, cet outil nécessite des collaborateurs dédiés à des taches plus complexes.

10

Chapitre 1 Contexte général

7. Solution Proposée Dans le but de rendre la lecture des fichiers logs génères par le Framework Palmyra plus lisible, simple et plus Compréhensible. Vermeg et l’équipe Palmyra a décidé de mettre en place une application web qui permet d’analyser les fichiers logs en temps réel. Notre application offres aux analystes de Vermeg et l’équipe Palmyra la possibilité d’avoir plusieurs interfaces sur le fichier log via un filtre sur les niveaux et des recherches par certain critères.

8. Méthodologies de travail 8.1. Méthodologie agiles Une méthode Agile est une approche itérative et collaborative, capable de prendre en compte les besoins initiaux du client et ceux liés aux évolutions. La méthode Agile se base sur un cycle de développement qui porte le client au centre. Le client est impliqué dans la réalisation du début à la fin du projet. Grâce à la méthode agile le demandeur obtient une meilleure visibilité de la gestion des travaux qu’avec une méthode classique. L’implication du client dans le processus permet à l’équipe d’obtenir un feedback régulier afin

d’appliquer

directement

les

changements

nécessaires.

Cette méthode vise à accélérer le développement d’un logiciel. De plus, elle assure la réalisation d’un logiciel fonctionnel tout au long de la durée de sa création. Le principe de base consiste à proposer une version minimale du logiciel puis à intégrer des fonctionnalités supplémentaires à cette base, par processus itératif. Le processus itératif regroupe une séquence d’instructions à répéter autant de fois que possible, selon le besoin. En ce qui concerne la réalisation d’un logiciel, les instructions à répéter sont les suivantes : 

Les tests unitaires à la fin de chaque itération



Le développement



L’intégration



La relecture et amélioration des codes

https://www.ideematic.com/actualites/2015/01/methodes-agiles-definition/

11

Chapitre 1 Contexte général

a. Les quatre valeurs fondamentales Agiles Individus et interactions au lieu de processus et outils. Logiciel fonctionnel au lieu de documentation massive. 

Collaboration du client au lieu de négociation de contrats.



Réagir au changement au lieu de suivre le plan.

b. Les principales méthodes agiles Parmi les méthodes agiles nous citons :  SCRUM  Extreme Programming (XP)  Crystal Clear  Adaptive Software Développement (ASD) c. Les principes de méthodes agiles

           

Satisfaire le client est la priorité Accueillir les demandes de changement « à bras ouverts » Livrer le plus souvent possible des versions opérationnelles de l’application Assurer une coopération permanente entre Client et Equipe projet Construire des projets autour d’individus motivés Privilégier la conversation en face à face Mesurer l’avancement du projet en termes de fonctionnalités de l’application Faire avancer le projet à un rythme soutenable et constant Porter une attention continue à l’excellence technique et à la conception Favoriser la simplicité Responsabiliser les équipes: les meilleures architectures, spécifications et conceptions émergent d’équipes auto organisées. Ajuster, à intervalles réguliers, son comportement, ses processus pour être plus efficace

8.2. Méthodologie agile adoptée : Scrum ineumann.developpez.com/tutoriels/alm/agile_scrum/

Pour bien conduire notre projet est nous assurer du bon déroulement des différents phases, nous avons opté SCRUM comme une méthodologie de conception et de développement pour les raisons suivantes. La méthode Scrum est une méthode agile, créée en 2002, dont le nom est un terme Emprunté au rugby qui signifie « la mêlée ». Elle s’appuie sur le découpage des projets en itérations

12

Chapitre 1 Contexte général

encore nommées « sprints ». Un sprint peut avoir une durée qui varie généralement entre deux semaines et un mois. Avant chaque sprint, les tâches sont estimées en temps et en complexité à l’aide de Certaines pratiques comme le « planning poker ». Ces estimations permettent à la fois de planifier les livraisons, mais aussi d’estimer le coût de ces tâches auprès du client. Cette méthodologie est basée sur des itérations qu’on appelle sprint.

Figure1.5 Méthode Scrum https://www.pentalog.fr/notre-demarche/methode-agile-scrum.htm

8.2.1. Justification du choix de la méthodologie Dans le cas de notre projet,après avoir étudié les différentes méthodes, nous avons choisi pour SCRUM comme méthode de gestion de projet car elle est la mieux adaptée et la mieux qui dispose une organisation adaptée et d’un état d’esprit Agile, il se base sur une démarche itérative et incrémentale et permet de créer rapidement des incréments de produit fonctionnels et de qualité en mettant l’accent sur un objectif clair à chaque itération. Le choix de Scrum comme une méthode de pilotage pour notre projet s’est basé sur les atouts de ce dernier. Il est léger et simple à comprendre, ce qui permet de démarrer rapidement en Agilité. Il se caractérise par une capacité d’adaptation au changement grâce à des itérations courtes, une transparence, une souplesse et une capacité de réagir. En effet cette méthode est entièrement développée et testée pour de courtes itérations et des besoins évolutifs. 8.2.2. Les rôles de la méthode Scrum La méthode Scrum définit trois rôles pour un projet.

13

Chapitre 1 Contexte général



Le Product Owner : Il s’agit du représentant officiel du client au sein d’un projet Scrum. Il est l’interlocuteur principal du Scrum Master et des membres de l’équipe. Il définit les besoins du produit et rédige les spécifications. Il peut se faire aider de responsables fonctionnels pour la rédaction des spécifications. Il est également chargé de définir et prioriser les users stories pour chaque sprint.



Le scrum master : Il s’agit d’une personne chargée de veiller à la mise en application de la méthode et au respect de ses objectifs. Il ne s’agit pas d’un chef de Projet, mais d’une personne chargée de lever les obstacles éventuels qui empêcherait l’avancement de l’équipe et du projet pendant les différents sprints.



L’équipe : Ce sont les personnes chargées de la réalisation du sprint et d’un produit utilisable en fin de sprint. Il peut s’agir de développeurs, architectes, personnes chargées de faire des tests fonctionnels.

8.2.3. Équipe du projet L’équipe de notre projet se compose de : 

Product Owner : Equipe Palmyra



Scrum Master : Tarek Guermazi



Scrum Team:Agha Mohamed Mehdi&Boubaker Allaedine

a. Les artéfacts dans Scrum Les principaux artéfacts dans SCRUM sont :

Le « Product Backlog » : (Carnet de produits) : C’est un outil de collecte des fonctionnalités attendues ou exigées par le client (User Story), et qui évolue à chaque Sprint. http://geekandmore.fr/tag/scrum

Le « Sprint Backlog » : (Carnet d'itération) Il contient la liste des tâches qui doit être accomplie pour mettre en œuvre les fonctionnalités prévues pour un Sprint particulier. Idéalement, chaque tâche dans un

14

Chapitre 1 Contexte général

sprint est relativement courte et peut-être captée par un membre de l'équipe plutôt que d'être affecté. https://confluence.atlassian.com/agile/glossary/sprint-backlog.

« Burndown charts » : (Graphique d’avancement) C’est un diagramme qui permet de visualiser l’avancement des sprints et du projet dans sa globalité, c’est l’indicateur temporel de l’évolution des tâches en cours dans le Sprint. L’axe vertical présente la quantité de travail à faire et l’axe horizontal les jours de travail. http://geekandmore.fr/tag/scrum

9. Langage de modélisation UML (Unified Modeling Language) UML est avant tout un support de communication performant, qui facilite la représentation et la compréhension de solutions objet - sa notation graphique permet d'exprimer visuellement une solution objet, ce qui facilite la comparaison et l'évaluation de solutions - l'aspect formel de sa notation, limite les ambiguïtés et les incompréhensions ; - son indépendance par rapport aux langages de programmation, aux domaines d'application et aux processus, en font un langage universel. La notation graphique d'UML n'est que le support du langage. La véritable force d'UML, c'est qu'il repose sur un métamodèle. En d'autres termes : la puissance et l'intérêt d'UML reposent sur

le

fait

qu'il

normalise

la

sémantique

des

concepts

qu'il

véhicule.

UML permet de représenter un système selon différentes vues complémentaires : les diagrammes. Un diagramme UML est une représentation graphique, qui s'intéresse à un aspect précis du modèle ; c'est une perspective du modèle.

https://www.memoireonline.com/10/10/3952/m_Gestion-des-unitesdenseignement-dans-le-cadre-de-la-reforme-LMD--luniversite-deLome8.html

15

Chapitre 1 Contexte général

10. Conclusion Pendant ce chapitre, nous avons introduit l’organisme d’accueil VERMEG, ses services et son organisation. Par ailleurs, nous avons pu retirer le contexte général du projet et présenter le choix de la méthodologie de développement et le langage de modélisation. Le chapitre suivant sera consacré à la phase de l’analyse de projet mettant l’accent sur l’étude préliminaire des besoins, identification des besoins ainsi que la représentation des besoins et la planification des sprints.

16

Chapitre 2 Analyse du projet

Chapitre 2 : Analyse du projet 1. Introduction Pour ce chapitre, nous décrivons les besoins fonctionnels, non fonctionnels et architecturaux, ensuite nous joignons la modélisation des besoins de l’application ainsi que les diagrammes de cas d’utilisation.

2. Recensement des besoins 2.1. Identification des acteurs Un acteur est une personne qui a une tâche essentielle et déterminante dans une action. Dans le cadre de ce projet, nous avons identifié

les

3

acteurs

suivants L’administrateur, le référent projet et l’analyste sont les figurants interagissant dans notre système. Tous ces derniers doivent s’authentifier pour consulter les statistiques, sélectionner un modèle d’analyse ainsi qu’une demande d’analyse. Pour le référent projet et l’administrateur, ils ont l’autorisation de faire une configuration. Ainsi l’administrateur est le seul acteur qui a la possibilité de gérer l’utilisateur en modifiant un utilisateur existant ou d’ajouter un nouvel utilisateur.

2.2. Besoins fonctionnels Les besoins fonctionnels doivent répondre aux exigences de notre future application en termes de fonctionnalités, et comme notre projet consiste à développer une application de conception et développement d’une plateforme qui est capable d’analyser les fichiers log. Cette application doit couvrir les besoins fonctionnels suivants: 

Authentification : L’utilisateur de cette plateforme doit s’authentifier pour accéder à la plateforme.



Consulter les statistiques : L’utilisateur a l’autorisation de consulter les statistiques de ses dernières analyses après avoir s’être authentifié.



Sélectionner un modèle : Tous les acteurs doivent sélectionner un modèle d’analyse pour analyser un fichier désiré

17

Chapitre 2 Analyse du projet



Demande d’analyse : L’acteur peut faire une analyse d’un fichier log



Configuration : L’utilisateur a l’autorisation de faire la configuration



Gestion des utilisateurs : L’administrateur est le seul acteur qui a l’autorisation de gérer les utilisateurs en ajoutant un nouvel utilisateur ou de modifier un utilisateur existant.

3. Structure et découpage de projet 3.1. Identification de l’équipe SCRUM L’un des participants les plus impressionnants dans SCRUM, c’est l’effectif de SCRUM. Cette équipe, bien constituée, assure l’efficacité et la flexibilité d’une équipeprécieuse toute en sauvegardant la collaboration, la clarté et l’inspiration dans le but d’atteindre tous les objectifs du projet.

Figure 4:Equipe et rôles

3.2. Backlog de produit Le backlog de produit est l’un des plus importantes artéfacts de Scrum que nous l’avons présenté dans le premier chapitre. Comme nous avons dit que c’est une représentation des occurrences et de fonctionnalités aspirées, nous allons présenter ci-dessous le backlog produit de notre plateforme :

18

Chapitre 2 Analyse du projet

Tableau 2 : Backlog produit Thème

ID

User Stories

Description

1

S’authentifier

En tant que utilisateur je dois 5 s’authentifier afin d’accéder à mon espace personnel en sécurité.

Demande une analyse d’un 2 fichier Log

3

Priorité Complexité

++

Demande analyse

une En tant que utilisateur je veux 1 pouvoir demander une analyse de fichier log.

Consulter utilisateurs

les En tant que administrateur je 4 peux consulter tous les utilisateurs.

+

Ajouter

un En tant que administrateur je 2 peux ajouter un utilisateur.

+++

un En tant que administrateur je 3 peux modifier un utilisateur.

+++

+++++

Gestion des utilisateurs

4

utilisateur

Modifier 5

utilisateur existant

Consulter les statistiques 6

Consulter statistiques

En tant qu’utilisateur je 6 peux consulter les statistiques

+

3.3. Planification des sprints du projet La partie de planification des sprints reste primordiale pour la bonne gestion d’un projet, elle autorise d’avoir un cheminement optimisé pour le dépeçage et l’affectation des fonctions selon les priorités, le temps et l’effectif pour que le produit tente bien les besoins citées par le Product Owner.

19

Chapitre 2 Analyse du projet

« Le sprint est une période d’un mois au maximum, au bout de laquelle l’équipe délivre un incrément du produit, potentiellement livrable. Une fois la durée choisie, elle reste constante pendant toute la durée du développement. Un nouveau sprint démarre dès la fin du précédent. » https://www.oriade.net/?page_id=250

La planification des sprints de notre projet est établie dans la figure suivante :

Figure 5:Plannification des sprints

4. Diagramme de cas d’utilisation général La figure 6 présente le diagramme de cas d’utilisation générale de notre plateforme d’analyse de log. Nous y retrouvons comme contenu les acteurs principaux et leurs rôles.

20

Chapitre 2 Analyse du projet

Figure 6:Diagramme de cas d'utilisation générale

4. Conclusion Pendant ce chapitre, nous avons pu dans un premier lieu déterminé les acteurs, les besoins fonctionnels et non fonctionnels de notre projet. Nous sommes ainsi avancés vers Scrum par l’identification de l’équipe, du backlog produit et des sprints.

21

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

Chapitre 3 Sprint I «Demande d’une analyse d’un fichier log» 1. Introduction Comme déjà énoncer dans la section organisation des sprints du chapitre précédent, le projet se disperse en unités de temps nommées sprints au bout desquelles l’équipe est obligé de transporter un produit éventuellement livrable. Ce chapitre s’intéresse au premier sprint de notre projet «Demande une analyse log ».

2. Spécification fonctionnelle Lors de la première phase de chaque sprint, la spécification fonctionnelle s’exprime par un diagramme de cas d’utilisation .Celui-ci donne une vue extérieure du système et définit les liens entre les utilisateurs et les fonctionnalités que propose celui-ci.

2.1. Sprint backlog Le backlog de sprint est une liste de tâches identifiées par l'équipe Scrum à compléter lors du sprint Scrum . Au cours de la réunion de planification du sprint, l'équipe sélectionne un certain nombre d'éléments de backlog de produit, généralement sous la forme d'user stories, et identifie les tâches nécessaires pour compléter chaque histoire d'utilisateur.

https://translate.google.tn/translate?hl=fr&sl=en&u=https://www.mountai ngoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog&prev=search Le tableau suivant présente le backlog de notre premier sprint :

22

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

Tableau 3 : Backlog du premier sprint ID USER Story

1

Nom de user

User story

ID

Authentification En tant que 1.1 utilisateur je dois m’authentifier

Demande analyse

Affectation

Tache

Story

afin de pénétrer à mon compte en sécurité

2

Tache

Réaliser les AllaEddine Boubaker diagrammes de cas d’utilisation, de classe, de séquence système et de séquences détaillées du cas « s’authentifier »

1.2

Développer le « s’authentifier »

cas Mohamed Agha

1.3

Examiner le « s’authentifier »

cas AllaEddine Boubaker

une En tant que 2.1 utilisateur je peux analyser un fichier log

Réaliser les Mohamed diagrammes de cas Agha d’utilisation, de classe, de séquence système et de séquences détaillées du cas « Demande une analyse »

2.2

Développer « demande analyse »

2.3

Tester le cas « demande Mohamed une analyse» Agha

23

le

Mehdi

Mehdi

cas AllaEddine Boubaker une

Mehdi

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

2.2. Prototypage des interfaces Ce paragraphe est dédié à l’illustration de quelques prototypes des interfaces de ce sprint comportant les fonctionnalités nécessaires.

 Prototype de l’interface "s’authentifier"

Figure 7:Prototype de l'interface « S'authentifier »  Prototype de l’interface "Demande une analyse "

Figure 8:Prototype de l'interface demande une analyse

24

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

3. Diagramme des cas d’utilisation du premier sprint

Le diagramme de cas d’utilisation est une représentation UML d’une façon statique et globale le comportement fonctionnel d’un système. La figure ci-dessous schématise le raffinement du diagramme de cas d’utilisation du premier sprint

Figure 9: Raffinement du cas d'utilisation du premier sprint

4. Analyse des cas d’utilisation 4.1. Analyse de cas « S’authentifier » Description textuelle du cas « S’authentifier » Le tableau 3 représente une description textuelle du cas d’utilisation « S’authentifier » Tableau 3 : Description de cas d’utilisation « S’authentifier »

Etapes

Description

Résumé Acteur : Analyste Titre : s’authentifier. Description : le système identifie à ce niveau l’administrateur, analyste et référent projet qui veulent utiliser la plateforme.

Pré-conditions

L’analyste n’est pas authentifié Le système est opérationnel.

25

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

Scénario nominal

L’analyste entre ses paramètres de connexion mail et mot de passe. Le système vérifie les informations saisies. Le système affiche l’espace de travail de chaque utilisateur.

Scénario alternatif

Les données sont erronées. Le système affiche un message d’erreur que l’analyste n’existe pas.

Post-conditions

L’analyste est sur son espace de travail. Le système attend désormais qu’il exécute une nouvelle action.

Diagramme de séquence système du cas « S’authentifier » La figure 10 nous présenté le diagramme de séquence système du cas de l’authentification

Figure 10:Diagramme de séquence système du cas « S'authentifier »

Diagramme de séquence système du cas « S’authentifier »

26

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

La figure 11 nous a présenté le diagramme de séquence détaillé du cas s’authentifier

Figure 11:Diagramme de séquence détaillé du cas « S'authentifier » Digramme de classes participantes La figure ci –dessous présente le diagramme de classes participantes du cas s’authentifier

Figure 12:Diagramme de classes participantes du cas « S'authentifier »

4.2. Analyse de cas « Demande une analyse »

27

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

Description textuelle du cas « Demande une analyse » Le tableau 4 représente une description textuelle du cas d’utilisation « S’authentifier » Tableau 4 : Description de cas d’utilisation « Demande une analyse »

Etapes

Description

Résumé Acteur : Analyste Titre : demande une analyse Description : le système permet à ce niveau l’administrateur, utilisateur et référent projet qui veulent analyser un fichier log.

Pré-conditions L’analyste veut analyser les fichiers log. L’utilisateur s’est connecté à la plateforme. La plateforme est opérationnelle. Scénario nominal L’analyste s’authentifie. Le système affiche l’espace de travail de chaque utilisateur.

L’acteur entre dans l’interface « Request analyses » L’administrateur, l’analyste et le référent projet donne le chemin de fichier log à analyser. Ensuite, il choisit le modèle de configuration. L’administrateur, l’analyste et le référent de projet clique sur le bouton « analyser ». Scénario alternatif

Le système affiche un espace de travail vide puisque l’utilisateur n’jamais

Post-conditions

Le système affiche le résultat de l’analyse.

analysé un fichier log.

Le système attend désormais qu’il exécute une nouvelle action.

Diagramme de séquence système du cas Demande une analyse La figure 13 présente le diagramme de séquence système du cas « Demande une analyse »

28

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

Figure 13:Diagramme de séquence système du cas « Demande une analyse » Diagramme de séquence détaillée du cas « Demande une analyse » La figure ci-dessous présente le diagramme de séquence détaillé cas « Demande une analyse

Figure 14:Diagramme de séquence détaillé du cas « Demande une analyse » Diagramme de classes participantes du cas « Demande une analyse » Ce diagramme nous présente le diagramme de classes participantes du cas « demander une analyse »

29

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

5. Conception Dans la figure ci-après, nous présentons alors le diagramme de classe décrivant la structure statique du premier sprint.

Figure 15:Diagramme de classe globale du premier sprint

30

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

6. codage Dans le schéma ci-dessous nous présentons les tables de notre base de données. Cette transformation au schéma relationnel se fait en tenant compte aux règles de passages suivantes : 

Régle1 : Une entité est traduite en relation.



Régle2 : Une association «un à plusieurs » engendre la migration de la clé primaire de la relation mère à la relation fille en clé étrangère.



Régle3 : Une association «plusieurs à plusieurs » est représentée par une relation dont la clé primaire est composé par les clés primaires des relations associées.

Med. Bach Tobji. Cours Bases des données. Ecole Supérieure d’Economie Numérique Manouba. 2015.  Schéma de la base de données «Analyste»

Attribut

Type

Contrainte

idAnalyste

Long

Primary Key

lastName

String

Not null

firstName

String

Not null

Password

String

Not null

Mail

String

Not null

 Schéma de la base de données « Group »

Attribut

Type

Contrainte

idGroup

Long

PrimaryKey

nameGroup

String

Not null

 Schéma de la base de données « Groupes_users »

Attribut

Type

Contrainte

idAnalyst

Long

Foreign Key

idGroup

Long

Foreign Key

31

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

 Schéma de la base de données « Log »

Attribut idLog pathFile

Type Long String

Contrainte Primary Key Not null

 Schéma de la base de données « Record »

Attribut idRecord date&time Ipsource Level Description Ipmac

Type Long String String String String String

Contrainte Pimary Key Not null Not null Not null Not null Not null

7. Test 

Interface d’authentification

Figure 16:Interface d'authentification

32

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»



Interface de contrôle dans la phase d’authentification Cette interface présente le contrôle appliqué sur la phase de l’authentification

Figure 17:Interface de contrôle d'authentification



Interface demande d’une analyse

Cette interface présente l’interface de demande d’une analyse

Figure 18:Interface demande d’une analyse

33

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»



Interface de résultat d’une analyse Cette figure présente l’interface du résultat d’une analyse

Figure 19:Interface de résultat d'une analyse

8. Revue du sprint

La revue de sprint est une réunion réalisée à la fin de chaque sprint, dont la durée maximale est d’une heure par semaine de sprint donc deux heures dans notre projet. La motivation de la revue de sprint est d’inspecter l’incrément du logiciel réalisé au courant du sprint passé et réajuster le backlog du produit si nécessaire. Au cours de la revue du premier sprint, nous avons partagé le travail développé au cours du sprint écoulé avec product owner avec qui on a traité les user stories du sprint backlog une par une pour vérifier la validité de ce qui a été fait. Tous les user stories de ce sprint ont été validés et testés, et le « product owner » a accepté les fonctionnalités présentées.

34

Chapitre 3 Sprint 1 « demande d’une analyse d’un fichier log »»

9. Conclusion Durant ce chapitre, nous avons manifesté clairement les items du Backlog du premier sprint afin d’améliorer l’achèvement des objectifs de notre projet en franchissant de la phase d’analyse jusqu’à la phase de test. Dans le chapitre suivant, vous allez détecter comment nous allons concrétiser le second sprint de notre projet.

35

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Chapitre 4 Sprint 2 «Gestion des utilisateurs» 1. Introduction Après avoir réalisé le premier sprint, cette partie sera consacrée à la réalisation du second, nous analysons les « user stories » en donnant une description détaillée de chaque cas d’utilisation « user story », présentons la gestion des utilisateurs qui fait une grande partie de ce sprint et même de l’application entière et aussi nous allons décortiquer le user story de consultation des statistiques. Nous y présentons également la conception globale du sprint. Enfin, nous abandonnons par la phase de codage et de test.

2. Sprint fonctionnelle C’est au niveau de ce sprint que nous allons réaliser la tache de gestion des utilisateurs et de consultation des statistiques

2.1. Sprint backlog ID USER Story

1

Nom de user

User story

ID

Affectation

Tache

Story

Consulter statistiques

Tache

les En

tant

que 1.1

utilisateur peux

je

consulter

les statistiques après analysé fichier

avoir un 1.2

36

Réaliser les AllaEddine diagrammes de cas Boubaker d’utilisation, de classe, de séquence système et de séquences détaillées du cas « Consulter les statistiques » Développer le « Consulter statistiques »

cas Mohamed les Agha

Mehdi

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

1.3

2

Gestion des En tant 2.1 utilisateurs qu’administrateur je peux gérer les utilisateurs

en

consultant

les

données

des

utilisateurs,

en

modifiant

un

ou

d’ajouter

un

cas AllaEddine les Boubaker

Réaliser les Mohamed diagrammes de cas Agha d’utilisation, de classe, de séquence système et de séquences détaillées du cas « Gestion des utilisateurs »

2.2

Développer le « Gestion utilisateurs »

2.3

Tester le cas « Gestion Mohamed des utilisateurs » Agha

utilisateur existant

Examiner le « Consulter statistiques »

nouvel utilisateur

cas AllaEddine des Boubaker

2.2. Prototypages des interfaces  Interface de consultation des statistiques

Figure 20:Prototype de l'interface « consulter les statistiques »  Interface de consultation des utilisateurs

37

Mehdi

Mehdi

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Figure 21:Prototype de l'interface « consulter les utilisateurs »  Interface de modification des utilisateurs

Figure 22:Prototype de l'interface « modifier un utilisateur »  Interface de création d’un nouvel utilisateur

Figure 23:Prototype de l'interface ajouter un utilisateur

38

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

3. Spécification fonctionnelle La figure 24 présente le diagramme de cas d’utilisation du sprint 2.

Figure 24:Diagramme de cas d'utilisation du deuxième sprint

4. Analyse des cas d’utilisations 4.1. Analyse du cas « Consulter les statistiques » Description textuelle du cas « Consulter les statistiques » Tableau 4 : Description de cas d’utilisation « Consulter les statistiques »

Etapes

Description

Résumé

Pré-conditions

Acteurs : analyste Titre : Consulter les statistiques. Description : le système permet à ce niveau l’administrateur, analyste et référent projet qui veulent consulter leurs statistiques. L’analyste s’est connecté à la plateforme. La plateforme est opérationnelle.

Scénario nominal L’utilisateur s’authentifie. L’administrateur, l’analyste et le référent projet consulte leurs statistiques

39

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Scénario alternatif

Le système affiche un espace de travail vide puisque l’utilisateur n’jamais analysé un fichier log.

Post-conditions

L’acteur consulte les statiques. Le système attend désormais qu’il exécute une nouvelle action.

Diagramme de séquence système du cas « Consulter les statistiques » La figure ci-dessous présente le diagramme de séquence système du cas de consultation des statistiques.

Figure 25:Diagramme de séquence système du cas « Consulter les statistiques » Diagramme de séquence détaillé du cas « Consulter les statistiques » Cette figure présente le diagramme de statistiques

séquence détaillé du cas de consultation des

Figure 26:Diagramme de séquence détaillé du cas Consulter les statistiques

40

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Diagramme de classes participantes du cas « Consulter les statistiques »

Figure 27:Diagramme de classes participantes du cas Consulter les statistiques

4.2. Analyse du cas « Gérer des utilisateurs » Description textuelle du cas « Gestion des utilisateurs » Tableau 6 : Description de cas d’utilisation « Gérer des utilisateurs »

41

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Résumé

Pré-conditions

Scénario nominal

Scénario alternatif Post-conditions

Acteur : administrateur Titre : gérer des utilisateurs. Description : le système permet à ce niveau l’administrateur de gérer les utilisateurs. L’administrateur veut modifier ou ajouter un utilisateur. L’administrateur s’est connecté à la plateforme. La plateforme est opérationnelle. L’administrateur s’authentifie. Le système affiche l’espace de travail de l’administrateur. L’administrateur clique sur le bouton « manage analystes ». Le système affiche l’interface de gestion des utilisateurs. Si l’administrateur veut modifier un utilisateur existant. L’administrateur choisit l’utilisateur à modifier. L’administrateur clique sur le bouton « update ». Le système affiche les informations de l’utilisateur choisi. L’administrateur modifie les informations. Finalement, il clique sur le bouton « Save » Sinon, l’administrateur ajoute un nouvel utilisateur. L’administrateur clique sur le bouton « Create ». L’administrateur remplit le formulaire. L’administrateur clique sur le bouton « Save ». Le système affiche l’interface « manage analystes » vide puisque l’utilisateur n’a pas d’utilisateurs. L’administrateur ajoute un utilisateur. Ou modifie un utilisateur existant Le système attend désormais qu’il exécute une nouvelle action.

42

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Figure 28:Diagramme de séquence système du cas « Gérer des utilisateurs »

Diagramme de séquence système détaillé du cas « gérer les utilisateurs »

43

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Figure 29:Diagramme de séquence détaillé du cas « Gérer les utilisateurs » Diagramme de classes participantes du cas « Gérer les utilisateurs »

44

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Figure 30:Digramme de classes participantes du cas « Gérer les utilisateurs »

5. Diagramme de classe globale La figure 31 présente le diagramme de classe globale du deuxième sprint

45

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

Figure 31:Diagramme de classe globale du deuxième sprint

6. codage Dans le schéma ci-dessous nous présentons les tables de notre base de données

 Schéma de la base de données «Analyste»

Attribut

Type

Contrainte

idAnalyste

Long

Primary Key

lastName

String

Not null

firstName

String

Not null

Password

String

Not null

Mail

String

Not null

46

Chapitre 4 Sprint 2 « Gestion des utilisateurs »  Schéma de la base de données «Administrateur»

Attribut

Type

Contrainte

idAdministrateur

Long

Primary Key

lastName

String

Not null

firstName

String

Not null

Password

String

Not null

Mail

String

Not null

 Schéma de la base de données « Group »

Attribut

Type

Contrainte

idGroup

Long

Primary Key

nameGroup

String

Not null

 Schéma de la base de données « Groupes_users »

Attribut

Type

Contrainte

idAnalyst

Long

Foreign Key

idGroup

Long

Foreign Key

 Schéma de la base de données « Log »

Attribut idLog pathFile

Type Long String

Contrainte Primary Key Not null

47

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

 Schéma de la base de données « Record »

Attribut idRecord date&time Ipsource Level Description Ipmac

Type Long String String String String String

Contrainte Pimary Key Not null Not null Not null Not null Not null

7. Test Cette interface présente la phase consultation des utilisateurs Interface de consultation des utilisateurs

Figure 32:Interface de consultation des utilisateurs

48

Chapitre 4 Sprint 2 « Gestion des utilisateurs » Cette figure présente la phase d’ajout d’un utilisateur



Interface d’ajout d’un nouvel utilisateur

Figure 33:Interface d'ajout d'un nouvel utilisateur Cette figure présente la phase de modification d’un utilisateur



Interface de modification d’un utilisateur existant

Figure 34:Interface de modification d'un utilisateur existant

49

Chapitre 4 Sprint 2 « Gestion des utilisateurs »

8. Conclusion Dans ce chapitre, nous nous sommes intéressés à la réalisation des fonctionnalités de notre solution et les déroulements de chacun de nos sprints. Nous avons décelé cette réalisation à travers un ensemble d’interfaces accompagnées de descriptions et interprétations.

50

Chapitre 5 : Phase de clôture

Chapitre 5: Phase de clôture 1. Introduction Dans ce dernier chapitre notre objectif est de présenter la phase ultime d’un cycle de

développement avec scrum. Au début nous commençons par la citation des différents outils bureautiques, technologiques et environnement de développement que nous avons adopté dans la création de notre plateforme. On fermera par la présentation du déploiement de l’application.

I. Environnement de développement 1. Environnement matériel Le tableau ci-dessous présente les matériels utilisés Tableau 7 : Environnement matériel

Caractéristique Ordinateur Propriétaire Processeur Ram Disque dur Système d’exploitation

1 HP Agha Mohamed Mehdi Core i3 4Go 500 Go Windows 7 Professional 64 bits

2 HP Boubaker Allaedine Core i3 4 G0 1TO Windows 10 Professional 64 bits

2. Environnement logiciel  Eclipse est un projet de la Fondation Eclipse visant à développer tout un environnement de développement libre, extensible, universel et polyvalent. Son objectif est de produire et fournir divers outils gravitant autour de la réalisation de logiciel, englobant les activités de codage logiciel proprement dites (avec notamment un environnement de développement intégré) mais aussi de modélisation, de conception, de test, de reporting, etc. Son environnementde développement notamment vise à la généricité pour lui permettre de supporter n'importe quel langage de programmation.

51

Chapitre 5 : Phase de clôture

Le projet Eclipse est pour cela organisé en un ensemble cohérent de projets logiciels distincts, sa spécificité tenant à son architecture totalement développée autour de la notion de plugin (en conformité avec la norme OSGi) : toutes les fonctionnalités de l'atelier logicieldoivent être développées en tant que plug-in bâti autour de l'IDE Eclipse Platform.

http://dictionnaire.sensagent.leparisien.fr/Eclipse%20(logiciel)/fr-fr/ Visual code studio est un nouveau type d'outil qui combine la simplicité d'un éditeur de code avec ce dont les développeurs ont besoin pour leur cycle principal d'éditionconstruction-débogage. Le code fournit une prise en charge complète de l'édition et du débogage, un modèle d'extensibilité et une intégration légère avec les outils existants. VS Code est mis à jour tous les mois avec de nouvelles fonctionnalités et corrections de bugs. Vous pouvez le télécharger pour Windows, macOS et Linux sur le site Webde VS Code . Pour obtenir les dernières versions chaque jour, vous pouvez installer la version Insiders de VS Code . Cela construit à partir de la branche principale et est mis à jour au moins tous les jours. https://translate.googleusercontent.com/translate_c?depth=1&hl=fr&prev=search&rurl=transl ate.google.tn&sl=en&sp=nmt4&u=https://github.com/Microsoft/vscode&xid=17259,1570002 1,15700124,15700149,15700168,15700173,15700186,15700189,15700201&usg=ALkJrhj2r G-P QfAITvH2r5yux1YtZm46IA

 Wampest une plate-forme de développement Web sous Windows pour des applications Web dynamiques à l’aide du serveur Apache2, du langage de scripts PHP et d’une base de données MySQL. Il possède également PHPMyAdmin pour gérer plus facilement vos bases de données.

http://www.wampserver.com/

 PhpMyAdminUn des outils permettant de manipuler une base de données MySQL. Il est livré avec WAMP.

52

Chapitre 5 : Phase de clôture

 PostmanL'application Postman est un outil pratique pour tester une API dans API Gateway. Les instructions suivantes vous guident dans les principales étapes d'utilisation de l'application Postman pour appeler une API.  Word est le logiciel phare de la suite Bureautique Microsoft Office. C'est l'un des logiciels les plus utilisés dans le monde et permet de rédiger des lettres, CV, rapports et tous types de documents texte. Word permet de mettre en page vos documents, de générer des sommaires, de numéroter automatiquement des pages, corriger automatiquement la grammaire et l'orthographe, de créer des schémas, de faire du publipostage. Word est plutôt bien conçu et facile à prendre en main, il vous permettra de rédiger lettres et courriers, ou encore de mettre en forme votre CV. https://cours-informatique-gratuit.fr/dictionnaire/microsoft-office-word/

3. Choix technologiques 

Spring est un socle pour le développement d'applications, principalement d'entreprises mais pas obligatoirement. Il fournit de nombreuses fonctionnalités parfois redondantes ou qui peuvent être configurées ou utilisées de plusieurs manières : ceci laisse le choix au développeur d'utiliser la solution qui lui convient le mieux et/ou qui répond aux besoins. Spring est ainsi un des Framework les plus répandus dans le monde Java, sa

popularité a grandie au profit de la complexité de Java EE notamment pour ses versions antérieures à la version 5 Spring s’appuie sur un concept important des quels nous avons tiré profit dans notre solution. 

Angular 5 Après une sortie au mois de mars 2017 d’Angular 4, il est déjà temps d’accueillir Angular 5 en attendant Angular 6 prévu pour mars 2018. Pour ceux qui l’ignorent, Angular c'est le nom d’un outil mis à disposition par Google qui sert à donner du bonheur aux développeurs d’application javascript. Du bonheur car l’outil est complet, la communauté nombreuse et qu’il nous permet de nous concentrer avec plaisir sur les problématiques client.

53

Chapitre 5 : Phase de clôture

4. Conception Architecturale 4.1. Choix de l’architecture de l’application Egalement pour tout projet difficulteux, l’architecture nous conserve une bonne manipulation des ressources pour avoir une bonne réponse qui répond bien aux besoins prématurément définis. Ainsi, nous avons fixé notre choix d’architecture logicielle de notre application ce qui implique le choix des technologies, des produits et des serveurs utilisés. Cela fait de notre application une application à architecture Client/serveur 3 tiers.

4.2. Architecture MVC //http://www.memoireonline.com/04/15/9014/m_Mise-en-place-dun-systeme-dinformationgeographique-pour-la-propriete-fonciere-au-Camerou8.html L’architecture MVC (modèle, vue et contrôleur) est un concept très puissant qui intervient dans la réalisation d’une application. Son principal intérêt est la séparation des données (modèle), de l’affichage (vue) et des actions (contrôleur). Ce concept peut très bien être appliqué à un site internet. De nombreux sites internet disposent d’une plateforme d’administration pour modifier facilement les contenus. Il est bien évident que l’utilisateur qui va utiliser ce système pour créer des pages ne doit pas modifier la structure complète du site, ni les actions ni l’affichage. Pour qu’il ne modifie que les données, celles-ci doivent alors être isolées. C’est sur ce constat que se base le système MVC. Chaque partie est bien distincte. Les données peuvent provenir d’une source quelconque et la vue peut être conçue par des webdesigners n’ayant pas de connaissance en programmation. L’approche MVC apporte de réels avantages :  Une conception claire et efficace grâce à la séparation des données de la vue et du contrôleur  Un gain de temps de maintenance et d’évolution du site

54

Chapitre 5 : Phase de clôture

Figure 35: Architecture MVC https://mouradev.wordpress.com/tag/patron-darchitecture-logicielle/

Nous avons appliqué cette architecture à notre travail parce qu’elle nous offre de réels avantages notamment la bonne organisation des données, la conception claire composée par la vue et le contrôleur et le gain de temps voire la maintenabilité de l’application.

Cette architecture est représentée par la figure suivante :

Figure 36: Architecture MVC

https://www.google.tn/search?q=architecture+mvc&rlz=1C1AVNG_frTN7 17TN717&source=lnms&tbm=isch&sa=X&ved=0ahUKEwj60MuesILbAh XNZlAKHQDTCgUQ_AUICigB&biw=1366&bih=637#imgrc=dUWHY3eA g2IHxM:

55

Chapitre 5 : Phase de clôture

5. Diagramme de déploiement Dans le contexte du langage de modélisation unifié (UML), un diagramme de déploiement fait partie de la catégorie des diagrammes structurels et décrit un aspect du système lui-même. Dans le cas présent, le diagramme de déploiement décrit le déploiement physique sur des composants matériels des informations générées par le logiciel. L'information qui est générée par le logiciel est appelée artefact. À ne pas confondre avec l'utilisation qui est faite du terme dans d'autres approches de modélisation comme le BPMN. Les diagrammes de déploiement sont constitués de plusieurs formes UML. Les boîtes en trois dimensions, appelées nœuds, représentent les composants du système, qu'ils soient logiciels ou matériels. Les lignes entre les nœuds indiquent les relations et les petites formes à l'intérieur des boîtes représentent les artefacts logiciels qui sont déployés. https://www.lucidchart.com/pages/fr/tutoriel-sur-les-diagrammes-ded%C3%A9ploiement

La figurer 43 présente le diagramme de déploiement de notre plateforme

Figure 37:Diagramme de déploiement

6. Conclusion Ce chapitre nous a permis de mettre en avant les phases nécessaires à la réalisation de notre application à savoir les outils de développement matériels et logiciels l’architecture du système et nous avons présente le diagramme de déploiement.

56

Chapitre 5 : Phase de clôture

57

Conclusion Générale

Conclusion générale Notre stage au sein de l’entreprise VERMEG a été non seulement une opportunité pour nous d’explorer et mettre en pratique nos connaissances acquises de notre cursus universitaire à l’ESEN, mais aussi, un atout pour s’intégrer au sein du milieu professionnelle du développement informatique qui joue un rôle primordiale dans notre formation. Pendant ce stage, nous nous sommes gavés comment planifier, diriger notre temps et mettre en pratique nos connaissances pour décrocher nos objectifs et c’est également grâce à la présence et au support de nos encadrants. L’objectif de ce projet de fin d’étude était de faire la conception et le développement d’une plateforme qui permet d’analyser un fichier log. Nous avons contraintes dans la phase de développement. En effet nous avons passé beaucoup de temps pour comprendre et maitriser les langages utilisés puisqu’nous n’avons pas eu la chance à étudier ces derniers. Nous avons commencé dans ce rapport par la description du contexte général de notre stage qui a eu lieu au sein de l’entreprise VERMEG suivie d’un deuxième chapitre d’analyse du projet dans lequel nous avons le cadre de projet et établi le choix de la méthodologie Agile « SCRUM ». Les deux chapitres suivants : « Sprint1 : Demande d’une analyse d’un fichier log » et « Sprint2 : Gestion utilisateurs », étaient le cœur de notre travail. Ils se distribuent en une spécification des user stories, une schématisation des diagrammes des cas d’utilisations et la conception de ces derniers, le codage, les tests, le rétrospective et le revue du sprint Ensuite, le dernier chapitre de ce rapport était une phase de clôture au cours de laquelle nous avons présenté les langages les outils de programmations utilisés pour la réalisation de notre application et le diagramme de déploiement. Cependant, nous pouvons toujours y apporter quelques améliorations qui feront de cette application. En ce qui concerne la côté ergonomique de l’application. En effet nous pourrons

58

Conclusion Générale

aussi ajouter la partie de demande automatique qui oblige la plateforme de faire une analyse synchronisé dès que les lignes d’un fichier log dépassent une limite bien déterminée. Enfin, nous pouvons même développer une plateforme qui permet d’analyser les fichiers log spécifiques à l’ESEN.

59

Références bibliographiques

Références bibliographiques

60