Introduction :

Une entreprise a commandé à la société XEFI une nouvelle application web. Nous avons réalisé l’analyse du cahier des charges, réunion téléphonique afin de répondre à nos interrogations, modélisation de la base de données ainsi que la création du code de l’application et de la base de données. Chaque développeur de l’équipe a été chargé d’une fonctionnalité.

Contexte :

Lors de ma période en entreprise j’ai rejoint l’équipe en charge du développement de cette application. L’application est une CRM d’après-vente. Nous avons répartie les modules. (c1.4.1.1), L’application est divisé en 5 modules (Visualisation de fiche client, saisie ou modification fiche client, une partie statistique, une carte pour visualiser le client d’une autre manière et pour finir une partie prime). J’ai développé un module, le premier permet la visualisation des client et prospect sur une carte avec des informations au « clic », le 2éme permet la saisie des informations sur le client, j’ai travaillé principalement sur la saisie d’un parc de véhicule et la modification des informations, j’ai aussi effectuer des améliorations sur les modules attribuer aux autres développeurs. L’application a été rajouté dans notre portail d’applications (Le bureau virtuel).

Outils utilisé :


PHP Storm : a été le logiciel nécessaire à la création du code PHP

Framework : Nous avons utilisé Cake PHP

MySQL / Navicat: a permis de créer la base de données

Git : a été l’outil de versionning du code, à chaque fonctionnalité crée une branche été crée.

Réalisation :

Analyse du cahier des charges :

Dans un premier temps nous avons analyser chacun de notre côté le cahier des charges, noter nos interrogations. Après une heure d’étude, nous avons mis en commun nos interrogations afin de comprendre le besoin (C1.1.1.1, C1.1.1.2, c1.1.1.3). Plusieurs réunions téléphoniques ont été nécessaires pour être sure du fonctionnement souhaité de la part du client. Nous avons étudié les niveaux d’habilitation nécessaire par module que nous vu avec le client (c1.2.5.1, c1.2.5.2, c1.2.5.3), afin de réaliser la base de données et commencer un prototype.

Il a fallu s’accorder sur la base de données, la modélisation, réalisation (C4.1.3.1, C4.1.3.2), validation de notre manageur et création de données (C4.1.3.4) tout ceci nous a pris une demi-journée.


Réalisation de la base de données :

Une fois un accord trouvé sur les éléments de la base de données et la validation par notre manageur, nous l’avons modélisé sur le logiciel navicat, il nous a fallut lui demander de générer la base de donnée (C4.1.3.3) puis vérifier la présence, la validité des clé primaires/ étrangères dans les tables qui aurait pu être mal généré du a une mauvaise modélisation.


Planification du développement :

Une fois le cahier des charges et la base de donnée créés, il faut commencer le développement du code. Il faut alors que l’on planifie des deadlines pour chaque module, on établit alors son planning en fonction des taches à réaliser (c1.4.1.1, c4.1.1.2). On fait des points sur l’avancement du projet tous les matins afin de connaitre les problèmes rencontrés ainsi que les écarts sur les délais prévues (C1.4.1.2, C1.4.2.1, C1.4.2.2). Si un développeur est bloqué sur une partie, on modifie alors son planning afin de l’aider et éviter de rester bloquer indéfiniment (C1.4.3.2).


Réalisation de l’application / prototype :

Nous avons listé les composants logiciels nécessaires pour la conception du logiciel (C4.1.1.1). Je me suis documenté sur les technologies à mettre en place pour le développement des fonctionnalités (C5.2.4.1). Un prototype a été développé puis validé avec le client, afin d’avoir un premier retour et de mieux cibler ce que le client souhaite (C4.1.5.2, C4.1.5.3). Nous avons réalisé le code avec les interactions des données interface utilisateur (C4.1.7.1, C4.1.7.4). Lors du développement nous avons eu des disfonctionnements dû à une incompatibilité entre des plugins, il a fallu les remplacer (c3.2.2.2).


Réalisation des tests :

Une fois le développement d’un module terminer il faut que l’on tests le bon fonctionnement avec des jeu d’essais (c1.2.4.2), nous avons alors noté toutes les options possibles et nous avons vérifié que cela fonctionne comme prévus et que cela n’impacte pas une autre partie du logiciel (C1.2.4.1). Nous testons également le service sur un serveur de preprod afin d’éliminer tous problèmes (C1.3.1.2), si des erreurs surviennent on recherche la source du problème puis on corrige (C4.1.8.2).


Pousser la code / Déploiement Automatique :

Une fois un le développement terminer on commit sur la plateforme gitlabs, afin de visionner notre code (C5.1.3.2), nous mettons à jours notre base de connaissance sur des traitements spécifiques (C5.1.2.2). Une fois commit sur le serveur de production un CI/CD (tache automatique) déploie le code (c1.3.4.2). Il faut par la suite réaliser des requêtes pour que le Framework cake PHP prenne en compte les modifications (c1.3.4.3).


Supervision :

Une fois l’application déployée, nous réalisons une supervision des performance serveur (serveur web/sql) afin de maintenir une qualité service, connaitre des requêtes SQL qui peuvent poser problème « temps exécution » (C2.1.2.4) ou même du code qui mais plus longtemps à s'exécuté du a un afflux important de donnée a traité


Conclusion :

Le suivi intégral d’un projet m’a permis de constater les écarts de temps entre l’estimation faite et le temps réellement passé pour réaliser une fonctionnalité. J’ai été plus en difficulté sur cette partie du fait que l’on n’a pas de base de code pour réaliser le code. Il ma fallut beaucoup d’auto formation, lecture de documentation de plugin jQuery/PHP pour réaliser certaines fonctionnalités. Cela m’a fait progresser dans la lecture de l’anglais. Il faut aussi être rigoureux dans la création des requête SQL du fait que nous n’avons pas beaucoup de donnée, cela peut fonctionner d’apparence mais avec beaucoup de donnée cela n’est pas optimum et lent.

Activités et compétences mises en œuvre :

  1. A1.1.1 Analyse du cahier des charges d’un service à produire
    • C1.1.1.1 Recenser et caractériser les contextes d’utilisation, les processus et les acteurs sur lesquels le service à produire aura un impact
    • C1.1.1.2 Identifier les fonctionnalités attendues du service à produire
    • C1.1.1.3 Préparer sa participation à une réunion Rédiger un compte-rendu d’entretien, de réunion

  2. A1.2.4 Détermination des tests nécessaires à la validation d’un service
    • C1.2.4.1 Recenser les tests d’acceptation nécessaires à la validation du service et les résultats attendus
    • C1.2.4.2 Préparer les jeux d’essai et les procédures pour la réalisation des tests

  3. A1.2.5 Définition des niveaux d’habilitation associés à un service
    • C1.2.5.1 Recenser les utilisateurs du service, leurs rôles et leur niveau de responsabilité
    • C1.2.5.2 Recenser les ressources liées à l’utilisation du service
    • C1.2.5.3 Proposer les niveaux d’habilitation associés au service

  4. A1.3.1 Test d’intégration et d’acceptation d’un service
    • C1.3.1.2 Tester le service

  5. A1.3.4 Déploiement d’un service
    • C1.3.4.2 Automatiser l’installation de la solution
    • C1.3.4.3 Mettre en exploitation le service

  6. A1.4.1 Participation à un projet
    • C1.4.1.1 Établir son planning personnel en fonction des exigences et du déroulement du projet
    • C1.4.1.2 Rendre compte de son activité

  7. A1.4.2 , Évaluation des indicateurs de suivi d'un projet et justification des écarts
    • C1.4.2.1 Suivre l’exécution du projet
    • C1.4.2.2 Analyser les écarts entre temps prévu et temps consommé

  8. A1.4.3 Gestion des ressources
    • C1.4.3.2 Adapter son planning personnel en fonction des ressources disponibles

  9. A2.1.2 Évaluation et maintien de la qualité d’un service
    • C2.1.2.4 Superviser les services et leur utilisation

  10. A3.2.2 Remplacement ou mise à jour d’éléments défectueux ou obsolètes
    • C3.2.2.2 Mettre en œuvre une procédure de remplacement ou de migration

  11. A4.1.1 Proposition d’une solution applicative
    • C4.1.1.1 Identifier les composants logiciels nécessaires à la conception de la solution
    • C4.1.1.2 Estimer les éléments de coût et le délai de mise en œuvre de la solution

  12. A4.1.3 Conception ou adaptation d’une base de données
    • C4.1.3.1 Modéliser le schéma de données nécessaire à la mise en place de la solution applicative
    • C4.1.3.2 Implémenter le schéma de données dans un SGBD
    • C4.1.3.3 Programmer des éléments de la solution applicative dans le langage d’un SGBD
    • C4.1.3.4 Manipuler les données liées à la solution applicative à travers un langage de requête

  13. A4.1.5 Prototypage de composants logiciels
    • C4.1.5.2 Développer un prototype
    • C4.1.5.3 Valider un prototype

  14. A4.1.7 Développement, utilisation ou adaptation de composants logiciels
    • C4.1.7.1 Développer les éléments d’une solution
    • C4.1.7.4 Utiliser des composants d’accès aux données

  15. A4.1.8 Réalisation des tests nécessaires à la validation d’éléments adaptés ou développés
    • C4.1.8.2 Mettre en évidence et corriger les écarts

  16. A5.1.2 Recueil d’informations sur une configuration et ses éléments
    • C5.1.2.2 Actualiser les caractéristiques des éléments de la configuration

  17. A5.1.3 Suivi d’une configuration et de ses éléments
    • C5.1.3.2 Reconstituer un historique des modifications effectuées sur les éléments de la configuration

  18. A5.2.4 Étude d‘une technologie, d’un composant, d’un outil ou d’une méthode
    • C5.2.4.1 Se documenter à propos d‘une technologie, d’un composant, d’un outil ou d’une méthode