Modélisation de la base de données d’une application

Conception et réalisation de l’application

 Description, résultats attendus et état d’avancement

La phase de conception de l’application est la plus importante du projet. Elle consiste à recueillir les besoins des agents, comprendre l’outil déjà en place, modéliser l’application et préparer son développement, de manière à ce qu’elle s’intègre correctement dans le système informatique de Veolia. A l’issue de cette phase de conception, nous devrons avoir un cahier des charges fonctionnel. Nous devrons également avoir des documents de comparatifs concernant les langages et les frameworks disponibles et expliquant les critères de choix d’une technologie par rapport aux autres. Nous pourrons également prévoir plusieurs autres documents qui expliqueront le fonctionnement de l’application, les technologies utilisées ainsi qu’un document résumant la phase de modélisation de la base de données. La phase de réalisation quant à elle, sera essentiellement centrée sur l’implémentation des versions de l’application, les difficultés rencontrées pour chacune d’entre elles et les solutions trouvées aux problèmes posés.

Étude du besoin

Les agents du service approvisionnement de Veolia utilisent un outil obsolète et réalisé par un agent non-spécialiste de l’informatique. Cet outil est en fait une application réalisée grace au logiciel Microsoft Access 2003.
L’application fonctionne mais la logique qui est utilisée dans l’interface est assez complexe.
De même, la modélisation de la base de données est clairement à revoir, car elle ne permet pas de stocker les commandes et les informations qui leurs sont relatives de manière optimisée. En effet, il s’agit d’une solution provisoire qui a été développée dans le but de faciliter le travail de l’ancien responsable approvisionnement. Cependant, après le départ de l’ancien responsable, l’application est restée dans le service car étant le seul outil informatique disponible pour gérer les commandes.

Processus de commande

Dans le but de mieux appréhender le besoin, j’ai dû me pencher sur l’application déjà présente dans le service. En effet, pour remplacer celle-ci de manière efficace et faire gagner du temps aux personnel du service approvisionnement, les premières versions de mon application devront implémenter les mêmes fonctionnalités que l’outil déjà utilisé. Ainsi donc, dès le premier jour, les agents du service approvisionnement m’ont montré l’interface de l’application et m’ont expliqué comment celle-ci fonctionne dans les détails. Pour cela, ils m’ont expliqué toute la démarche de saisie des commandes, de génération des bons de commande et d’envoi de mails de relances aux fournisseurs et aux transitaires.

Ci-dessus, une capture d’écran de l’interface principale de l’application. Celle-ci va à l’encontre de nombreux critères d’ergonomie évidents (comme par exemple éviter surcharge cognitive), rendant encore plus difficile la prise en main et la compréhension de la logique générale.
De plus, cette application étant spécifique au service, elle comporte de nombreux termes techniques. Ainsi, pour une personne n’étant pas habituée à la logique, au vocabulaire et autres abréviations (telles que MAD pour Mise à Disposition), la compréhension ainsi que la prise en main de l’outil relèvent de la première vraie difficulté du projet. J’ai donc dû me familiariser avec ce fonctionnement pour pouvoir proposer une alternative plus intuitive et efficace.

Entretien avec le responsable approvisionnement

Dans le but de comprendre un peu mieux le fonctionnement de l’application ainsi que les besoins du service, je me suis entretenu avec le responsable approvisionnement. Il fait partie des principaux utilisateurs de l’outil. Celui-ci m’a expliqué ses attentes concernant les résultats du projet, à savoir un outil fonctionnel, qui implémente, à minima, les mêmes fonctionnalités que celui déjà en place, et qui automatise les tâches telles que les relances par mails, pour ainsi permettre d’être plus efficace et d’éviter les oublis. En effet, ces oublis entrainent par la suite des retards dans les commandes et peuvent avoir un enjeu crucial en terme d’efficacité pour l’entreprise. Les personnes faisant partie du service approvisionnement sont les principaux utilisateurs de l’application Access, il est donc nécessaire de dialoguer au maximum avec le responsable ainsi que les autres personnes du service pour comprendre comment s’organise leur outil, comment il doit être utilisé et dans quel contexte. De plus il est intéressant de repérer des points d’éventuelles anomalies pour ensuite pouvoir proposer des améliorations. Cela permettra également de repérer les idées éventuelles qui pourraient permettre d’améliorer le produit final.

Étude d’une copie de l’application

Dans un troisième temps, j’ai étudié une copie de l’application réalisée sous Microsoft Access. La prise en main du logiciel aide à la compréhension détaillée de son fonctionnement. De plus, l’application n’étant pas totalement verrouillée, il est possible de regarder à l’intérieur pour analyser le contenu des tables ainsi que les requêtes et avoir une idée plus précise de son fonctionnement. A noter également que le fait que cette application ne puisse pas être totalement verrouillée relève d’un problème important, notamment pour l’intégrité des données, la sécurité et la stabilité du logiciel. De plus, un des premiers constats lors de l’analyse en détail du contenu de l’application est que celle-ci est composée de nombreuses tables non utilisées qui viennent l’encombrer et l’alourdir.

Entretien avec la responsable Qualité Sécurité et Environnement

Il s’agit ici d’une démarche personnelle. J’ai demandé un entretien avec la responsable Qualité Sécurité Environnement (QSE) de Veolia. En effet, Veolia est une entreprise qui a une forte implication au niveau de la qualité et de l’environnement. Le but de cet entretien était donc de rassembler le maximum d’informations sur les exigences et initiatives potentielles de Veolia en matière de qualité et de développement durable. Par la suite, ces informations seront analysées pour me permettre de proposer des axes et d’orienter mon développement de  manière à respecter ces exigences et de m’inscrire dans la logique de ces initiatives. Suite à mon entretien avec la responsable QSE, j’ai réussi à mieux cerner les initiatives de Veolia Eau Réunion en matière d’environnement. En effet, Veolia possède une politique qualité axée sur 4 points clés : le management de la qualité de service, la protection de l’environnement, la réduction de la consommation d’énergie et la sécurité. Une application développée au sein de cette entreprise devrait, dans l’idéal, s’inscrire dans les mêmes initiatives pour l’aider à atteindre les objectifs fixés. Cependant, il faut trouver les points sur lesquels axer le développement pour que celui-ci entre dans la logique qualité de Veolia.

Choix de développement

Toutes les initiatives prises pour le développement de l’application sont issues de la notion de Green IT. Ainsi donc, pour intégrer l’application dans la démarche de qualité et de protection de l’environnement de Veolia, j’ai choisi de développer l’application en respectant plusieurs règles ayant attrait au Green IT à savoir :
• L’utilisation de bonnes pratiques de programmation usuelles
• L’utilisation d’un langage de programmation adapté
• L’optimisation de la quantité de données envoyée sur le réseau
• L’optimisation du serveur et du moteur MySQL
L’enjeu essentiel ici se situera au niveau de l’optimisation de l’application et la réduction du temps d’utilisation de celle-ci par les agents. Ces bonnes pratiques permettront de réduire la charge CPU des équipements en la répartissant du côté client et serveur. Le temps d’utilisation de équipements sera également réduit pour les préserver plus longtemps. En effet, la production de matériel informatique étant plus polluante que leur utilisation, les préserver, dans le but de les garder plus longtemps, réduit l’empreinte carbone des entreprises. Il faut tout de même garder à l’esprit que
l’application restera un outil parmi de nombreux autres au sein de l’entreprise. Ainsi son impact, pour peu qu’il puisse être mesuré, ne fera pas faire d’économie importante à Veolia en matière d’utilisation d’énergie à court terme. L’impact que cette application pourra avoir se verra sur le long terme.

 Choix des technologies

 Choix du langage de programmation :Le langage de programmation utilisé va beaucoup influer sur le projet et la manière dont celuici sera développé, en fonction des avantages et des inconvénients du langage. Il convient de le choisir en considérant les besoins de l’entreprise, pour éviter de devoir changer de langage en cours de projet, ce qui constituerai une perte de temps considérable. De plus, un langage optimisé et facile à apprendre permettra d’avoir une meilleure optimisation de la charge du CPU, ce qui aura pour conséquence de préserver le matériel et de faciliter la maintenance, ce qui est en cohérence avec l’approche Green IT du projet.
Pour choisir un langage de programmation adéquat, il convient de comparer les langages disponibles entre eux. Il existe cependant une grande quantité de langages avec lesquels il est possible de réaliser une application. Il convient donc de limiter le nombre de langages pris en compte dans le cadre d’une comparaison.

Choix des langages à étudier

Un des critères limitant les choix des langages est lié au fait que l’application doive être accessible dans un navigateur, via l’intranet de Veolia, comme expliqué dans la partie concernant les contraintes particulières de développement. Cependant il existe encore beaucoup de technologies web à comparer. Au vu de la grande quantité de langages disponibles, il nous faut choisir les principales technologies à comparer. Les langages choisis compteront parmi les plus connus et les plus utilisés. Pour cela, nous nous baserons sur les statistiques du site w3techs.com.
Ainsi donc, après analyse de l’histogramme ci-dessus, nous avons retenu uniquement les langages les plus répandus et les plus connus sur le web en général. Ceux-ci sont au nombre de 5 : PHP, JavaScript, Java, C# (ASP.NET) et Ruby (on Rails). Choisir des langages très utilisés permet de bénéficier d’un meilleur support au moment du codage de l’application, et donc de développer une application plus rapidement. Cela permet également d’obtenir un outil plus robuste en suivant les conseils de développeurs plus expérimentés et de faciliter la maintenance ou l’évolution du produit par des personnes extérieures au projet. En effet, plus ces personnes auront accès à des ressources variées, plus il leur sera facile de trouver des réponses à leurs problèmes.
De plus, JavaScript a été préféré à Perl dans notre classement. En effet, JavaScript côté serveur est une technologie montante et qui s’avère très efficace, de par la nature même du langage. Une grande communauté se construit autour de JavaScript ainsi que de nombreux projets Open Source orientés web, par rapport à Python et Perl. De plus, grace à certaines technologies comme Apache Cordova, il est possible d’étendre le site web réalisé à une application mobile. Il est donc possible par la suite de voir notre application fonctionner nativement sur tablette ou smartphone en ne la codant qu’une seule fois en JavaScript, ce qui offre de grandes perspectives en terme d’évolution de l’application.

Table des matières

1. Introduction
2. Environnement 
1. L’entreprise
2. L’équipe projet
3. Communication au sein de l’équipe projet
4. Communication hors équipe projet
5. Ressources fournies et/ou à utiliser
6. Contraintes particulières
3. Conception et réalisation de l’application 
1. Description, résultats attendus et état d’avancement
2. Étude du besoin
1. Contexte
2.Processus de commande
3. Entretien avec le responsable approvisionnement
4. Étude d’une copie de l’application
5. Entretien avec la responsable Qualité Sécurité et Environnement
6. Choix de développement
3. Choix des technologies
1. Choix du langage de programmation
2. Choix du framework PHP
3. Choix du système de gestion de bases de données (SGBD)
4. Choix du framework CSS
5. Développement et déploiement de l’application
5. Rédaction du cahier des charges
1. Modélisation de l’application
1. Diagramme de cas d’utilisations
2. Modélisation de la base de données de l’application
3. Modélisation des classes de l’application
6. Réalisation des maquettes
1. Tableau de bord
2. Commandes
3. Destinataires
3. Etablissement des versions
1. Version 0.1 (prototype)
2. Version 0.2 (version alpha)
3. Version 0.3 (version beta)
4. Version 1.0
5. Version 1.1
6. Version 1.2
4. Phase de réalisation 
1. Prototype (version 0.1)
2. Version Alpha (0.2)
3. Version Bêta (0.3)
4. Version 1.0
5. Version 1.1
6. Version 1.2
5. Décomposition des tâches et sous-tâches
6. Conclusion
7. Sources
8. Table des figures
9. Lexique

Télécharger le rapport complet