Soutenance mémoire
Toutes les entreprises ont besoin de centraliser certaines informations quel que soit leur domaine d’activité. Il existe une multitude d’outils sur le marché et il arrive même que certaines sociétés en fassent développer sur mesure. J’avais été approché, il y a trois ans, par une entreprise Sédunoise pour cette raison. Cette entreprise avait finalement décidé de travailler avec un prestataire de service ayant suffisamment ressources disponible dans le temps. Mais entre-temps, mes recherches m’ont montré que certains systèmes deviennent rapidement des « usines à gaz » lorsqu’ils se veulent trop généraliste. A l’époque, je n’avais certainement pas toutes les compétences pour prendre en mains un projet de cette taille. Lorsque j’ai commencé à chercher un sujet pour mon travail de Bachelor, le cas de Newsat me semblait tout à fait intéressant. Ils avaient déjà une base technique à exploiter mais un intranet à revoir entièrement. C’était l’occasion pour moi de voir jusqu’où je pourrais aller en deux mois de développement dans le domaine. L’une des contraintes de ce développement est de garder la base de données de l’ancien projet. Cette contrainte est intéressante car elle va me permettre d’expérimenter un cas réel de génération de code source à partir de la structure de son système et me permettre de voir à quel point le Framework que je vais utiliser se montrera flexible aux contraintes qu’on peut lui imposer. Après tout, la majorité des entreprises sont dépendantes d’anciens système interconnectés.
Dans un premier temps, j’ai tenté une approche Scrum mais en étant seul développeur, cela n’avait pas de sens et demandait trop d’investissement administratif. J’ai donc gardé la méthodologie Agile comme base de travail et prévu mon organisation en huit Sprints. Les directions de développement ont été prises avec le client, les éléments qui suivent ne reflètent donc pas nécessairement le Product Backlog du cahier des charges initial.
Sprint 0. Le Sprint 0 a été consacré à un état de l’art de trois des principaux Frameworks du marché afin de savoir lequel convenait le mieux au projet. Il a aussi permis d’établir un premier contact technique et de connaître les compétences en développement déjà présentes dans l’entreprise.
Sprint 1. Le premier Sprint a permis de mettre en place les éléments de gestion de code et d’intégration continue chez le développeur. Il a aussi permis d’analyser le code et la base de données déjà existante et enfin de récupérer le schéma réseau du bureau de Sion pour la mise en place de la machine de production .
Sprint 2. La première connexion avec la base de données du client a pu être établie. Les importations des modèles métiers se sont faites tant bien que mal. Une démonstration des premiers développements a été faite avec le client. L’installation de la machine en production dans le réseau va se faire durant le Sprint suivant afin de résoudre des problèmes d’intégration continue.
Sprint 3. La machine de production a été installée chez le client qui peut tester la plate-forme. Les outils de base de gestion des Devices et des Site ont déjà été implémentés et ont pu être présentés au client.
Sprint 4. Implémentation des deux menus latéraux terminée. Plusieurs tentatives de configurations de Docker avec Gitlab ont échoué au niveau du déploiement automatisé. Une installation standard d’Apache et de PHP sera fournie à la place, la priorité étant de montrer le projet.
Sprint 5. La gestion des utilisateurs est mise en place avec sa gestion des rôles. Le menu « Data-Link » est presque terminé et la notion de VSat et TLink y sont revues. Un menu « Documentation » est ajouté. Une « Toolbox » écrite en Node.js R fait son apparition. Une première implémentation des Contact est prête.
Sprint 6. La « Toolbox » est désormais déployable avec un logiciel d’installation, la maintenance est donc simplifiée. L’outil WUG a été ajouté à la « Toolbox » ce qui a tout de même demandé la connexion à deux bases de données distantes. La notion de « Terrestrial Link » fait son apparition. Les Contact sont désormais récupérés de trois emplacements différents.
Sprint 7. L’outil « Spectrum » à été mis en place dans la « Toolbox ». Tous les formulaires nécessaires pour gérer les Satellite, Tranponder, Lease, Carrier sont prêts.
Sprint 8. L’outil Spectrum a bénéficié d’une importante correction dans ses calculs et d’une optimisation conséquente. Un outil d’activation des Modem et Demod par Short Message Service (SMS) a été mis en place. Le menu de gestion des Devices non-attribués a gagné un champ de recherche dynamique et s’est vu complété de toutes les autres entités apparentées.
L’intranet
Le serveur Web a été installé grâce à la suite EasyPHP. La racine publique fournie est une instance de Joomla mais l’intranet réel se trouve dans un sous dossier nommé MsSQL/test/. Le système communique avec un service de monitorage réseau nommé WUG.
Après réception des sources, j’ai tenté de monter un serveur local afin d’en étudier le fonctionnement. Quelques constats sont très vite arrivés :
— L’installation du serveur SQL dans une machine virtuelle demande quelques configurations spécifiques pour communiquer avec l’hôte (Naved, 2013) (WebECS Hosting, 2012).
— Le connecteur SQL Server fourni par Microsoft n’est pas compatible GNU is Not Unix (GNU)/Linux. Son alternative n’est malheureusement pas identique à l’utilisation et a rendu l’analyse plus difficile.
— L’intranet est dépendant d’une connexion à la BDD de WUG pour afficher des pages importantes mais cette dernière est trop volumineuse pour m’être transmise.
La base de données
La base de données sous Microsoft SQL Server contient 86 tables dont la structure n’est pas nécessairement aussi logique que ce qu’on attendrait d’une modélisation efficace. Toutes les tables ne sont par contre pas nécessaires au projet, il convient donc d’isoler celles traitant du matériel, des sites, des clients et des employés.
Ancienne interface
Une partie des éléments comme l’affichage en arbre sur le côté et les boutons d’outils seront gardés car ils permettront aux techniciens de se retrouver dans le nouvel environnement. Par contre des pages comme « Manage Devices for » ou des éléments tel que « Databse Transaction Status » disparaîtront au profit d’une ergonomie repensée.
Architecture
Environnement
La machine de production est un Personal Computer (PC) dédié au projet. Celui-ci intégrera une distribution GNU/Linux, accueillera le projet et le Source Code Management (SCM) qui assurera la pérennité du code et son déploiement. Si nécessaire ce dernier contiendra aussi une copie de la base de données de production afin de permettre à l’entreprise d’effectuer ses tests sans risques .
Gestion du code source
L’utilisation de git a l’avantage, par rapport aux autres SCM d’être décentralisé. Cela signifie que je peux préparer les « commits » de mes développements sans être connecté au serveur de réception. Ce paramètre est particulièrement important dans le cadre de ce projet, car il va me permettre de transmettre mon travail sur un réseau privé et de ne pas avoir recours à un Virtual Private Network (VPN). Du moment que je pars sur des outils libres, on peut travailler avec Gitlab Community Edition (CE) qui à l’avantage d’être auto-hébergeable, ainsi les outils de gestion du projet et le projet pourront tourner sur une même machine au sein même de l’entreprise.
|
Table des matières
1 Résumé
Mots-clés
2 Avant-propos
2.1 Contexte
2.2 Démarche
2.3 Convention typographique
3 Remerciements IV
4 Table des matières V
5 Liste des abréviations XII
6 Définitions XIV
7 Introduction
8 Organisation
8.1 Méthodologie
Sprint 0
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5
Sprint 6
Sprint 7
Sprint 8
8.2 Journal de travail
9 Recherche
9.1 Résumé
9.2 ASP.NET
Connexion à SQL Server
Génération des modèles
Coût de la licence
9.3 Django
Connexion à MS SQL Server
Génération des modèles
Avantages
Désavantages
9.4 Symfony
Connexion à Microsoft (MS) SQL Server
Génération des modèles
Avantages
Désavantages
9.5 Proposition finale
10 Analyse
10.1 L’intranet
10.2 La base de données
10.3 Ancienne interface
11 Architecture
11.1 Environnement
11.2 Gestion du code source
11.3 Intégration Continue
12 Modélisation
12.1 Use Case
12.2 Diagramme de Classes
12.3 Diagramme réseau
13 Environnement de développement
13.1 Conventions de codage
13.2 Installation de SQL Server 2012
13.3 Configuration de SQL Server 2012
14 Environnement de déploiement
14.1 Docker
14.2 Doctrine
14.3 Symfony
14.4 Bootstrap
15 Importation des Entités
15.1 Notes
15.2 Génération
15.3 Liaisons non définies
15.4 Nommage des colonnes
15.5 Entité Demod
16 Formulaires
16.1 Génération automatisée
16.2 Chargement dynamique
16.3 Contrôle des champs
17 Create, Read, Update, Delete (CRUD)
18 Gestion des utilisateurs
18.1 Friends Of Symfony (FOS) User Bundle
18.2 Module de Securité
19 Toolbox
19.1 Node.js R
19.2 Whatsup
19.3 Installation
20 Optimisations
21 Héritage
22 Openweathermap
23 Méthodes généralisées
23.1 Classes abstraites
23.2 Automator
23.3 Twig
24 Ajax
25 Déploiement
25.1 Choix du système
Avantages
26 Documentation
27 Conclusion
Télécharger le rapport complet
