PPE

CONTEXTE FORMARMOR

PPE – FormArmor

I. Contexte

L'organisme de formation FormArmor, spécialisé dans le domaine tertiaire et industriel, est implanté en Bretagne. Il dispose d’antennes dans les 4 départements bretons.

L’antenne des Côtes d’Armor, FormArmor 22, basée à Saint Brieuc couvre uniquement le secteur tertiaire.

La coordonnatrice de ce centre aimerait moderniser son mode de fonctionnement, notamment concernant l'inscription des clients sur les formations dispensées.

Fonctionnement actuel du centre de formation

Le centre de formation dispose d'un panel de formations bien établies pour lesquelles sont notées le libellé de la formation, le niveau de celle-ci (initiation, perfectionnement), le type de formation (compta ou bureautique), la durée (en heures) et le coût de revient.

Tous les clients font l'objet d'un entretien préalable auprès de Mme LEROUX, coordonnatrice du centre. Celle-ci note leurs coordonnées, leurs statuts (CIF, SIFE, 1%...) et un plan de formation personnalisé est défini. Sur celui-ci figurent les formations proposées mais pas encore de date.

Le prix de la formation dépend du statut.

Régulièrement, des sessions de formations sont définies (libellé de la formation, dates, niveau, nombre de places disponibles…).

Madame LEROUX se doit donc, au fur et à mesure de l'apparition des sessions, de positionner les clients sur celles-ci. Ce travail génère des inscriptions.

II. Description des applications existantes

FormArmor 22 dispose d’un site Internet. Celui-ci présente l'organisme de formation :

Et liste les formations dispensées :

Madame LEROUX (admin) peut, via "le panneau administration" de ce site et après authentification, créer et mettre à jour les clients, les formations, les plans de formations, les sessions et les statuts :

Cette application web a été conçue avec la méthode MVC et par l'intermédiaire du framework Symfony.

Exemple "lister les formations" :

url : http://localhost:8000/formation

Contrôleur "FormationsController .php" :

<?php

namespace App\Controller;

useSymfony\Bundle\FrameworkBundle\Controller\AbstractController;

useSymfony\Component\HttpFoundation\Response;

useSymfony\Component\Routing\Annotation\Route;

useDoctrine\Persistence\ManagerRegistry;

// Nécessaire pour la pagination

useSymfony\Component\HttpFoundation\Request; // Nous avons besoin d'accéder à la requête pour obtenir le numéro de page

useKnp\Component\Pager\PaginatorInterface; // Nous appelons le bundle KNP Paginator

use App\Entity\Formation;

class FormationController extends AbstractController

{

#[Route('/formation', name: 'formation')]

public function liste(Request $request, PaginatorInterface $paginator, ManagerRegistry $doctrine)

{

$em = $doctrine->getManager();

$rep = $em->getRepository(Formation::class);

$lesFormations = $rep->findAll();

$lesFormationsPagines = $paginator->paginate(

$lesFormations, // Requête contenant les données à paginer (ici nos formations)

$request->query->getInt('page', 1), // Numéro de la page en cours, passé dans l'URL, 1 si aucune page

4 // Nombre de résultats par page

);

return $this->render('formation/index.html.twig', Array('lesFormations' => $lesFormationsPagines));

}

Modèle :"FormationRepository.php" :

<?php

namespace App\Repository;

use App\Entity\Formation;

useDoctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;

useDoctrine\Persistence\ManagerRegistry;

/**

* @method Formation|null find($id, $lockMode = null, $lockVersion = null)

* @method Formation|null findOneBy(array $criteria, array $orderBy = null)

* @method Formation[] findAll()

* @method Formation[] findBy(array $criteria, array $orderBy = null, $limit = null, $offset = null)

class FormationRepository extends ServiceEntityRepository

{

public function __construct(ManagerRegistry $registry)

{

parent::__construct($registry, Formation::class);

}

public function listeFormations()

{

// En passant par le raccourci (c'est préférable)

$queryBuilder = $this->createQueryBuilder('f');

// On n'ajoute pas de critère ou tri particulier ici car on veut toutes les formations, la construction de notre requête est donc finie

// On récupère la Query à partir du QueryBuilder

$query = $queryBuilder->getQuery();

return $query->getResult();

}

public function suppFormation($id) // Suppression de la formation d'identifiant $id

{

$qb = $this->createQueryBuilder('f');

$query = $qb->delete('App\Entity\Formation', 'f')

->where('f.id = :id')

->setParameter('id', $id);

return $qb->getQuery()->getResult();

}

Vue :"templates/formation/index.html.twig" :

{% extends 'layout.html.twig' %}

{% block FormArmor_body %}

<h2>TABLEAU DES FORMATIONS</h2>

<thead>

<tr>

<th>Libellé</th>

<th>Niveau</th>

<th>Description</th>

<th>Diplomante</th>

<th>Durée</th>

</tr>

</thead>

<tbody>

{% for formation in lesFormations %}

<td>{{formation.libelle}}</td>

<td>{{formation.niveau}}</td>

<td>{{formation.typeform}}</td>

<td>{{formation.description}}</td>

{% if formation.diplomante == 0 %}

{% else %}

{% endif %}

<td>{{formation.duree}}</td>

<td>{{formation.coutrevient}}</td>

</tr>

{% endfor %}

</tbody>

</table>

$(function() {

$('#menu2').attr('class', 'active');

});

</script>

{% endblock %}

Les données sont stockées sous Mysql :

Base formarmor :

Les inscriptions des clients aux différentes sessions sont exclusivement réalisées par Madame LEROUX. Ces inscriptions sont faites par l'intermédiaire de l'application Java intitulée "gestion des inscriptions". Cette application est en liaison avec la base de données symfony5_formarmor.

Les limites de ce mode de fonctionnement :

La procédure d'inscription est longue et fastidieuse et donc source d'erreurs fréquentes.

Ces inscriptions sont faites sans connaître la disponibilité du client.

Le coût des formations est mal maîtrisé et des formations déficitaires sont régulièrement dispensées.

III. Evolutions souhaitées

Sur l'application web :

Ajout au site internet d'un espace client :

Cet espace devra être uniquement accessible aux clients reconnus (ROLE_CLIENT), une page de connexion devra être utilisée.

Cet espace clients devra se présenter sous cette forme :

La page devra présenter la liste complète des sessions de formation prévues pour les deux mois en cours (libellé de la formation, niveau, description, dates...), mais seules les sessions suivantes proposeront une inscription en ligne (bouton ou lien hypertexte...) :

· Sessions non totalement pourvues (nombre de places>nombre d'inscrits),

· Sessions pour lesquelles le client n'est pas encore inscrit,

· Sessions figurant dans son plan de formation,

· Sessions non closes;

Les inscriptions seront impossibles pour les clients n'ayant pas fourni d'e-mail et pour ceux qui ont déjà effectué l'ensemble de leur formation.

Un clic sur le bouton inscription ou sur le lien hypertexte de la session permettra après confirmation une inscription provisoire et donc une mise à jour des inscriptions, des sessions (nombre d'inscrits), des plans de formations (effectué(o/n)).

L'inscription ne sera définitive qu'après l'envoi d'un e-mail d'acceptation de la part de l'administrateur (environ une semaine avant la date début de la formation).

Modification de l'espace administrateur :

Opération de validation des inscriptions provisoires :

La page devra, pour ce client particulier (madame LEROUX, admin), également lister, avec la même présentation, l'ensemble des sessions prévues en mettant tout de même en évidence les sessions "à valider" c'est à dire les sessions totalement pourvues ou dont la date de début est prévue avant 8 jours.

Un clic sur le bouton validation ou sur le lien hypertexte de la session entraînera l'affichage détaillée des inscriptions (matricule, nom, prénom, statut...) et devra mettre en évidence d'une façon claire la marge dégagée sur cette formation.
Un bouton <Validation> et un bouton <Annulation> seront affichés.
Un clic sur le 1^er bouton devra provoquer l'envoi d'un e-mail d'acceptation à chaque client inscrit et rendra close cette session.

Un clic sur le second bouton provoquera la saisie d'un motif, et l'envoi, à chaque client inscrit, d'un e-mail d'annulation et donc la mise à jour des inscriptions, des plans de formations et la suppression de la session.

Opération de saisie/modification d'un plan de formation :

L'ajout d'une ligne dans le plan de formation pose actuellement problème. Lors du choix du matricule du client aucune vérification n'est effectuée et le nombre d'heures de formation prévues pour le client choisi, aussi bien en comptabilité qu'en bureautique, n'apparaît pas. Cette absence nuit grandement à l'efficacité de l'opération.

Modification de l'application Java "gestion des inscriptions" :

(Ces applications seront en liaison avec la base de données formarmor sous Mysql)

Ajout d'un module "gestion rentabilité" :

Ce module devra lister, sous forme de tableau par exemple, les sessions achevées.

Un clic sur une session devra permettre

§ l'affichage du détail de celle-ci : libellé, date, nombre d'inscrits, taux de remplissage, nombre d'absents...,

§ l'affichage de la liste des participants avec leur taux horaire.

La marge (positive ou négative) dégagée devra être apparente.

Chaque session donnera la possibilité d'une notification des absences.

Ajout d'un module "gestion des sessions" :

Ce module devra lister, sous forme de tableau par exemple, les sessions futures (de la plus proche à la plus éloignée).

Pour chacune de ces sessions la génération au format pdf d'une liste d'émargement devra être proposée (voir librairie itext en java).

Modification sur la base de données formarmor :

Les ajouts et modifications précédentes devraient impacter la base de données formarmor. En outre, une procédure stockée "sessions_autorisees" pourra être envisagée. Elle sera utilisée pour les inscriptions via l'application Java (Mme LEROUX) ou le site Internet (clients autorisés). Cette procédure devrait permettre de connaître, à partir d'un matricule client, les sessions qui lui sont "permises", c'est à dire :

§ non totalement pourvues,

§ figurant dans son plan de formation,

§ non closes.

Création d'une application Java android :

Envoi d'un texto (le lundi), pour rappel, aux clients inscrits sur la session de la semaine suivante. L'application devra lister les clients concernés et permettre l'envoi d'un texto groupé.

IV. Architecture applicative

Environnement de production :

Le site Internet est hébergé sur un serveur Web (apache) sous linux.

La base de données (formarmor) sous Mysql est implantée sur ce même serveur.

L'application Java "gestion des inscriptions" est sur un poste sous Windows.

Environnement de développement :

Poste sous Windows disposant de Wamp ou Xamp.

Un serveur GIT est installé sur un poste Linux.

Développement web avec méthode MVC et Symfony. "Dépôt" des versions sur le serveur GIT.

Développement Java sous l'IDE NetBeans.

V. Missions envisageables

Développement Web (les missions en italique ne sont pas "présentables")

Mission 1 :

Sécuriser l'application pour les clients (ROLE_ADMIN).

Mission 2 :

Création de "l'espace clients"

Mission 3 :

Création de la procédure stockée (cf page11) et modification des inscriptions via l'espace clients (mission 2)

Mission 4 :

Modification de l'espace administrateur (Opération de validation des inscriptions provisoires)

Mission 5 (Ajax) :

Modification de l'espace administrateur (Opération de saisie/modification d'un plan de formation) : Prévoir dès le choix du matricule client effectué, l'apparition d'un tableau (en Ajax) faisant apparaître le nom, prénom du client, son nombre d'heures de compta et son nombre d'heures de bureautique attribuées. Ce tableau se mettra à jour sur le choix du matricule mais aussi sur le choix de la formation.

Mission 6 :

Tests unitaires

Client lourd (Java)

Mission 7 :

Création du module "gestion rentabilité"

Mission 8 :

Création du module "gestion des sessions"

Mission 9 :

Modification du module d'inscription en utilisant la procédure stockée (cf page 11)

Mission 10 :

Tests unitaires

Mission 11 :

Application Android