Différences

Ci-dessous, les différences entre deux révisions de la page.

--- ap3:slam:description_de_l_application [2024/11/06 21:40] – [Gestion de projet spécifique] dthevenot
+++ ap3:slam:description_de_l_application [2024/11/07 08:33] (Version actuelle) – [Gestion de projet spécifique] dthevenot
@@ Ligne 1: / Ligne 1: @@
+~~SLIDESHOW~~
 ====== Description de l'application  ======
+Projet AP3-2025 SDIS29
 ===== Gestion de projet spécifique =====
+<label type="default">Idéalement jeudi 7/11 à 10h</label> : Afin de bien s’entendre sur les termes de la première mission, il vous est demandé de fournir le plus rapidement possible la liste des fonctionnalités à développer, un diagramme des cas d'utilisation, des maquettes et le planning prévisionnel.
-Afin de bien s’entendre sur les termes de la première mission, il vous est demandé de fournir le plus rapidement possible la liste des fonctionnalités à développer, un diagramme des cas d'utilisation et des maquettes.
+=====  =====
+  * **documentation du projet** (1 fichier)
-Documentation attendue :
+    - planning prévu/réalisé
-  - diagramme des cas d'utilisation
+    - __Description fonctionnelle__ :
-  - maquettes
+      * le parcours de navigation(scénario d'utilisation) avec les maquettes des écrans
-  - planning prévu/réalisé
+      * le diagramme des cas d'utilisation
-  - architecture applicative (outils utilisés avec leur rôle et lien entre les outils)
+    - __Structure des données__ : évolution de la base de données (avant/après)
-  - évolution de la base de données
+    - __Structure du projet__
-  - arborescence des fichiers de l'application et rôle des fonctions et méthodes
+      * architecture applicative (outils utilisés avec leur rôle et lien entre les outils)
+      * le code doit être écrit et commenté conformément à la JavaDoc (la javadoc doit au minimlum indiquer le rôle des fonctions et des méthodes)
+      * structure(arborescence) des répertoires et fichiers
+===== Ressources initiales =====
+[[https://drive.google.com/drive/folders/10e1TG69x5ztfmrpHPBIaGFv2MrGaI_aD?usp=drive_link|lien drive]]
 ===== Rôle de chacun des acteurs =====
 Au niveau de l'application, le **chef de la caserne** peut créer et modifier les fiches des pompiers volontaires dont il a la responsabilité. Il peut voir leurs disponibilités et de façon hebdomadaire,  il doit leur affecter des gardes.
 Les **pompiers volontaires** ont la possibilité de visualiser et de modifier leur profil. Chaque  semaine, ils doivent indiquer leurs disponibilités.
+=====  =====
 Les **responsables des alertes** ont la responsabilité de mobiliser les pompiers volontaires nécessaires pour une intervention. Au niveau de l'application, après avoir enregistrer un  sinistre, ils sélectionnent une ou plusieurs casernes et indique le nombre de pompiers  volontaires dont ils ont besoin. Le système désigne et affiche les volontaires à bipper parmi  ceux qui sont de garde (d'abord les pompiers disponibles et si besoin ceux qui sont au travail).
 ===== Première mission : gestion du profil des pompiers  =====
 In fine, l'application doit permettre aux responsables des alertes de mobiliser les pompiers volontaires nécessaires pour une intervention le plus rapidement possible. Pour cela, chaque  semaine :
    * les pompiers volontaires devront renseigner leurs disponibilités
    * les chefs de centre devront établir un calendrier des gardes
+=====  =====
 Ces fonctionnalités ne pourront être opérationnelles que si les profils des pompiers sont renseignés correctement. On entend par "profil", les caractéristiques d'un pompier volontaires, c’est-à-dire sa caserne d'appartenance, son identité, son adresse, son grade, ainsi que sa  photo, et son employeur (raison sociale et adresse). Une zone commentaire permet au  pompier comme au chef de centre d'apporter des précisions non prévues (Exemple : non  disponible un week-end sur deux pour cause de garde d’enfants)
 **C'est la mission qui vous est confiée dans un premier temps.**
+=====  =====
 ==== Base de données ====
 À partir d'une ancienne application, un script de création de base de données MySQL vous est fourni (Cf script sdis29.sql disponible sur le Drive). Il sera à compléter, mais il vous permet  de disposer d'un jeu d'essai réaliste.
+=====  =====
 La base de données proposée est constituée :
-  * d'une table pompier
+  * d'une table **pompier**
-  * d'une table caserne
+  * d'une table **caserne**
-  * et de deux tables permettant de gérer les paramètres : parametre et typeparametre
+  * et de deux tables permettant de gérer les paramètres : **parametre** et **typeparametre**
-<alert type="info">Bien vous familiariser avec l'usage des tables parametre et typeparametre  </alert>
+<alert type="info">Conseils :
+  - Bien vous familiariser avec l'usage des tables parametre et typeparametre
+  - bien lire le script de la bd jusqu'au bout, il y a la création de l'utilisateur
+</alert>
+=====  =====
 ==== Accès à l'application  ====
 Une authentification est à prévoir pour accéder à l'application. L'authentification permettra de  déterminer si l'utilisateur est chef de centre, pompier volontaire ou responsable des alertes.
 **__Que peut faire un Chef de centre ? __**
-Il peut gérer tous les pompiers volontaires de son centre. C’est-à-dire visualiser les profils des pompiers volontaires de son centre, les modifier, et créer un pompier volontaire. Dans une deuxième mission, il devra pouvoir visualiser les disponibilités et saisir les périodes de garde.
+Il peut gérer tous les pompiers volontaires de son centre. C’est-à-dire visualiser les profils des pompiers volontaires de son centre, les modifier, et créer un pompier volontaire. Dans une deuxième mission, il devra pouvoir visualiser les disponibilités et saisir les périodes de garde. Les chefs de centre sont également habilités à gérer les paramètres de l'application. Cette fonctionnalité est incluse dans cette première mission.
+=====  =====
-Les chefs de centre sont également habilités à gérer les paramètres de l'application. Cette fonctionnalité est incluse dans cette première mission.
 **__Que peut faire un pompier volontaire ? __**
@@ Ligne 59: / Ligne 62: @@
 ===== Principes généraux de l'application  =====
 ==== Efficacité  ====
 L'application doit permettre à l'utilisateur authentifié d'accéder rapidement à la fonctionnalité  désirée. Ainsi, un chef de centre authentifié accède directement au profil du premier pompier  volontaire de sa caserne. Il peut en choisir un autre (liste déroulante ou bouton Suivant,  Précédent, …). Un bouton doit permettre de modifier les informations du profil, un autre  permettra de créer un nouveau profil…
+=====  =====
 ==== Non répudiation  ====
 Afin d'assurer la traçabilité des mises à jour, toute modification doit faire l'objet d'un talon de  mise à jour, de façon à savoir quand un profil a été créé, par qui, et quand il a été modifié la  dernière fois et par qui.
 Respect de la législation
 L'application devra être conforme à la législation actuelle en termes de gestion des données  personnelles (aspect sécurité, droit à l'information des utilisateurs, …). Elle devra notamment  intégrer les préconisations du règlement européen (GDPR General Data Protection  Regulation), voir le site de la CNIL : https://www.cnil.fr/fr/rgpd-par-ou-commencer .
+=====  =====
 ==== Charte graphique ====
 Dans la mesure du possible, l'application utilisera la même charte graphique que celle du site Internet (www.sdis29.fr)
 ==== Environnement logiciel  ====
 L'application sera développée en **JakartaEE**. Elle sera déployée sur un serveur **Tomcat** et MariaDB sera utilisé pour la base de données. Le codage devra respecter les règles de bonnes pratiques de développement en Java (Cf document JavaStyle). Le modèle MVC sera mis en  œuvre.
-Afin de faciliter le développement en équipe, le logiciel de gestion de version Gitea sera utilisé dans les mêmes conditions que l’an passé.
+Afin de faciliter le développement en équipe, le logiciel de gestion de version Gitea sera utilisé(gestion des tag pour les versions).
+=====  =====
 ==== Infrastructure technique  ====
 Voir la partie système-réseau