Cahier des charges d’un site Web pour une communauté partageant un inventaire d’objets

1. Introduction

Ce document présente les spécifications du projet.

Nous vous indiquons les attendus, mais précisons aussi ce qui est contre-indiqué.

Ce cadrage laisse une certaine liberté dans la réalisation, sans pour autant vous faire prendre le risque de développements trop complexes ou trop longs. Le but est de rester dans le nombre d’heures affiché au début du module.

Essayez de coller aux entités du modèle de données décrites dans ce cahier des charges, sans en ajouter. Dans le doute, consultez les encadrants.

1.1. Nomenclature à adapter

Dans ce document et dans le guide de réalisation, les éléments de nomenclature sont exprimés avec la syntaxe « [mot] », qui correpond alors à un élément à adapter en fonction du contexte fonctionnel particulier.

Par exemple, si on choisit de réaliser une application pour les passionnés de guitare, on remplacera chaque mention de « [objet] » par « guitare », et « [inventaire] » par « stand ».

1.2. Simplifications

Certaines simplifications sont spécifiées afin de rendre la mise en œuvre raisonable dans notre cadre pédagogique, tout en gardant un niveau de réalisme suffisant.

Veuillez les respecter pour ne pas risquer de faire déraper votre projet d’application.

1.3. Éléments optionnels

Nous décrivons certains éléments comme étant optionnels. Ils sont indiqués uniquement pour donner des idées d’améliorations éventuelles, mais ne sont pas à réaliser dans le cadre de la charge de travail attendue sur le projet.

1.4. Guide de réalisation

Les opérations à effectuer, pour mettre en œuvre le projet, seront décrites en séances de Travaux Pratiques, ainsi que dans le Guide de réalisation du projet.

2. Fonctions principales de l’application

L’application permet d’héberger une communauté de personnes souhaitant partager en ligne, et dans le monde physique, un ensemble d’[objets] en leur possession.

Le site permet de gérer pour soi-même un [inventaire] d’[objets], et de rendre publique, sous forme de [galerie], une partie de cet inventaire, qui devient donc accessible aux autres membres.

Les caractéristiques des [objets] contenus dans cet inventaire sont particulières, spécifiques aux caractéristiques des [objets] choisis (une guitare ne se décrit pas forcément de la même façon qu’une carte Pokemon).

Le site permet de rédiger des fiches détaillées pour les [objets] de l’inventaire, et de de commenter les fiches publiées par d’autres membres de la communauté.

Le site héberge, sur la même instance de l’application (dans la même base de données), l’ensemble des inventaires des différents membres (chaque [objet] appartient à un seul membre; on ne gère pas de « co-propriété »).

Cela permet à la fois de garder des informations :

privées pour chaque membre (fiches non-publiques pour tous ses [objet], mais qui sont accessibles depuis partout, quelque soit l’ordiphone ou l’ordinateur qu’il utilise, à tout moment)
publiques, donc partagées avec les autres membres de la communauté, pour commenter, échanger, partager (ou vendre, qui sait… mais en dehors de l’application, pour simplifier).

Par communauté, on entend l’ensemble des participants membres de la même instance du site (membres d’une association, par exemple). Pour simplifier, on ne gère pas des fonctions de type « réseau social » (liste d’amis, profil à réputation, etc.).

3. Structure du site

L’application est organisée en plusieurs ensembles de pages Web :

une section « front-office » contenant :
- les pages d’accueil destinées au public (visibles même si on n’est pas membre du site):
  - affichent des informations générales : les objectifs du site, son fonctionnement, une rubrique « Actualités » (nouveautés) et un lien contact pour joindre l’administrateur. Vous pouvez ajouter toute autre information que vous jugez utile (pas besoin d’un réalisme total).
  - permettent aux membres de se connecter à l’application (authentification avec un login et un mot de passe)
- le cœur du site accessible aux membres de la « communauté » une fois connectés, permettant d’utiliser la plupart des fonctionnalités :
  - consultation des fiches d’[objet] publiées par les autres membres dans leurs [galeries], et leurs commentaires (/optionnel), etc.;
  - un tableau de bord « Mon compte » permettant aux membres d’accéder à la gestion de l’ensemble de leur [inventaire] personnel, notamment les fiches d’[objet] qu’ils n’ont pas encore rendues publiques.
une section « back-office » pour les administrateurs du site : elle permet de deboguer des problèmes, assister les membres, gérer les conflits et autres demandes particulières (fermeture de compte, récupération, enquêtes judiciaires, etc.).

Pour simplifier la réalisation, on se limite à une version « minimaliste » de cette section back-office, sous forme d’un habillage Web de la base de données, fait avec l’utilitaire EasyAdmin pour Symfony.

Vous pouvez ajouter tous les éléments nécessaires pour faire fonctionner le site au mieux, et de façon classique par rapport à la gestion d’un tel site Web… à condition de rester dans la mesure du temps imparti.

Attention à ne pas vous lancer dans des choses intéressantes mais trop complexes ou trop longues.

L’objectif est de montrer que vous savez réaliser une application avec Symfony pour renforcer, par la pratique, votre compréhension des concepts et techniques. Il ne s’agit pas de rendre un résultat « professionnel » prêt pour la mise en production.

4. Gestion des accès

Le site Web de l’application doit :

distinguer les visiteurs anonymes (passionnés d’[objet] intéressés pour rejoindre la communauté) et les membres authentifiés;
disposer d’un accès privilégié pour l’administration du site. Les administrateurs sont des membres de la communauté ayant une vision supplémentaire de l’application : le back-office.

5. Modèle de données

Voici les contraintes et les attentes pour le modèle de données de l’application.

Attention à respecter les contraintes méthodologiques ci-dessous.

5.1. Mise en œuvre d’un modèle spécifique

Une fois la nomenclature du contexte particulier de votre application choisie, vous allez concevoir les classes spécifiques à votre modèle de données.

Ces classes doivent être mises en œuvre en objet, avec le composant ORM Doctrine de Symfony, de façon « basique », sans relations d’héritage entre les classes que vous définissez. Si par exemple, vous avez choisi que votre application gère des « guitares », alors codez une classe Guitare (ou au pire Instrument).

Contrainte pédagogique : On ne souhaite pas mettre en place une démarche de généralisation dans le cadre de ce projet : ne codez pas d’héritage et encore moins un modèle de données générique avec méta-modèle, etc.

On ne cherche pas à réutiliser une application existante pour ce faire. L’objectif n’est pas non-plus d’éditer un progiciel de gestion de collections génériques.

La réutilisation et la généricité sont des concepts intéressants à étudier, mais qui ne font pas partie des objectifs pédagogiques du présent projet.

Attention : on ne souhaite pas voir de classes nommées littéralement « Inventaire » ou « Objet » dans votre modèle. Soyez plus spécifiques pour coller au domaine fonctionnel choisi.

5.2. Entités attendues

Votre objectif est d’avoir réalisé, en fin de projet, un modèle de données contenant :

les premières entités spécifiées ci-dessous,
ainsi que celles qui seront indiquées dans le guide de réalisation du projet, pour monter progressivement en difficulté.

La mise en œuvre sera donc progressive, selon les indications données au fur et à mesure des séances, en partant d’un noyau initial et en itérant au fur et à mesure de l’ajout de nouvelles fonctionnalités.

Rappel : A chaque fois qu’elle est utilisée, remplacez la syntaxe « [mot] » par les entités spécifiques du contexte fonctionnel que vous avez choisi.

Adaptez en fonction de vos goûts, afin de faire « coller » la nomenclature des éléments affichés à l’écran aux membres avec celle des classes du modèle de données dans le code.

Exemple : si vous affichez une page de consultation de la liste des guitares dans le stand d’un guitariste, appelez alors la classe Guitar dans votre modèle de données (ou Guitare si votre équipe de codeurs n’est pas anglophone, au choix).

5.2.1. Les [inventaires]

L’ensemble des [objets] de chaque membre est rangé dans un [inventaire].

Le site gérant différents membres, on gère plusieurs [inventaires] dans la base de données.

Le contenu de chaque inventaire est personnel, et accessible seulement à son membre propriétaire. Seuls les administrateurs ont accès aux inventaires des tous les membres.

La présentation des [inventaires] dans les pages de l’application est sommaire, en terme de look, permettant principalement les fonction de gestion et de mise à jour de façon efficace.

5.2.2. Les [objets]

Les caractéristiques de chaque [objet] sont propres au domaine choisi (couleur, marque, référence, description, etc.).

On peut associer une ou plusieurs photos à chaque objet (optionnel).

L’objectif étant de réaliser un projet à vocation pédagogique, il n’est pas nécessaire de coller à la réalité : n’hésitez pas à simplifier pour ne réaliser qu’un ensemble de caractéristiques minimales.

Si vous avez une liste très détaillées des caractéristiques que vous aimeriez gérer, nous vous suggérons de commencer seulement avec les identifiants uniques et un petit nombre de propriétés, pour valider le fonctionnement du cœur du modèle de données, et des pages et formulaires.

Ainsi votre quantité de code à écrire, modifier et retoucher sera plus limité, pour des choses qui ne sont pas essentielles à la validation des acquis pédagogiques.

Plus tard, lorsque tout commencera à bien fonctionner, vous « fignolerez » en ajoutant d’autres attributs moins essentiels.

Gardez des commentaires « TODO » dans le code ou des notes dans votre liste de tâches du projet pour penser à les ajouter plus tard.

Par défaut, les fiches des [objet] sont privées, accessibles uniquement par le membre propriétaire de l’objet, depuis l’[inventaire].

Quand un [objet] apparaît dans une [galerie] de son membre propriétaire, la fiche de cet [objet] devient publique, accessible aux autres membres.

5.2.3. Les [galeries]

Les [galeries] des membres constituent la partie visible des [inventaires], et affichent les [objets] rendus visibles par leurs membres propriétaires.

La mise en page des [galeries] est plus soignée que celle des [inventaires] pour refléter les goûts des membres de la communauté.

Pour simplifier, votre application gère un affichage commun à toutes les galeries. Ce n’est pas une application réelle, donc pas de gestion de thèmes ou de mise en forme customisable par chaque membre, ce qui demanderait trop de travail.

Si le domaine fonctionnel s’y prête, vous pouvez ne gérer qu’une seule [galerie] publiée, pour chaque membre. Mais vous pouvez aussi choisir de gérer plusieurs [galeries] par membre, ce qui permet ainsi d’afficher éventuellement un même [objet] dans différentes [galeries] simultanément.

Une [galerie] peut être préparée de façon privée, dans un premier temps, puis rendue visible aux autres membres par son propriétaire, lorsqu’elle est prête.

5.2.4. Les membres

Chaque membre peut gérer un [inventaire] (pour simplifier, mais vous pouvez décider d’offrir la possibilité de gérer plusieurs inventaires, si vous préférez gérer une association 1-N plutôt qu’une association 1-1).

Les membres ont un rôle qui permet de distinguer les administrateurs (approche RBAC qui sera étudiée en cours).

Un membre a un nom de profil (public) visible par les autres membres de sa communauté (selon la communauté, privilégiez nom, prénom, ou bien un nickname, ou bien une icône… attention à faire le plus simple à mettre en œuvre, dans un premier temps)..

Chaque membre peut consulter les [galeries] publiques des autres membre, et (optionnel) y déposer des commentairesliés à des [objets] présents.

Chaque membre peut gérer des marque-pages sur les objets présents dans les [galeries] des autres utilisateurs, pour les retrouver rapidement ultérieurement.

Chaque membre voit, une fois connecté, son tableau de bord « mon compte », qui lui présente une vue synthétique de ses [inventaires] et [galeries].

Ne réalisez pas de gestion d’un profil réaliste pour simplifier (pas de gestion d’adresse, moyens de contacts, etc.)

Contrainte : ne pas nommer cette classe User. En effet, vous réutiliserez plus tard une classe User existante pour la rattacher à la classe Membre afin de gérer l’authentification des utilisateurs sur l’application.

5.2.5. Les marque-pages (optionnels)

Les marque-pages sont personnels à chaque membre, et ne sont pas partagés avec les autres membres.

5.2.6. Optionnel : Les commentaires

Les commentaires peuvent être ajoutés par d’autres membres à un [objet], depuis la visite de la galerie publique d’un membre.

On ne gère pas la modération des commentaires, par souci de simplification, au niveau des membres normaux. Les administrateurs pourront toujours les supprimer à loisir depuis le back-office.

L’historique des commentaires de tous les [objets] d’un membre est affiché dans la page de tableau de bord « mon compte » de cet membre.

6. Rappels méthodologiques

L’objectif du projet est de valider les apprentissages avec un temps de travail limité, et pas d’en faire un site déployable pour une utilisation réelle.

Si certaines ou certains souhaitent aller au-delà, ils sont évidamment libres de le faire, sur leur temps libre, mais n’auront pas un bonus pour la quantité de travail additionnelle.

Attention à la complexité de réalisation, et au temps passé en codage et mise au point, qu’il est difficile d’estimer lors d’un premier projet avec un framework encore méconnu. Il est préférable de rester dans le cadre pédagogique que nous avons décrit, pour connaître votre « productivité ». Dans un deuxième projet (après ce module), vous pourrez mieux estimer la faisabilité, le temps et l’effort requis, et vous lancer dans des projets ambitieux.

Bon courage pour la réalisation.