ReSA : Resource Scheduling Application Cahier des charges fonctionnel

Transcription

1 ReSA : Resource Scheduling Application Cahier des charges fonctionnel Eric Ramat ramat@lil.univ-littoral.fr 12 octobre 2010 Durée : 35 heures 1 Préambule L objectif du projet est de mettre en oeuvre une méthode de développement collaboratif pour une application sur un client lourd ou léger (c est au choix de l équipe de développement) et de mettre en concurrence trois groupes développant avec trois langages différents. Il est indispensable que la version publique du projet soit toujours opérationnelle afin que le client puisse tester et faire remonter les rapports de bugs. Chaque participant au projet doit déclarer son activité pour la journée au membre du groupe (cette activité sera déclarée sur le wiki du projet). Le travail s effectuera par binôme et la constitution des binômes sera remise en cause chaque jour. Le manager du groupe doit être unique. Le groupe ne travaillera sur le projet que dans les heures programmées à cet effet. Cette règle est importante car il est fondamental que le groupe communique en direct pour la réussite du projet. Le rôle du manager est aussi fondamental. Un outil de gestion de projets va vous être proposé. L objectif de ce projet n est pas d écrire des milliers de lignes de code. La priorité est de développer l essentiel et au plus simple. La recherche d API, de frameworks, de librairies existantes sera un gage de réussite. Chaque participant sera évalué suivant les critères suivants : qualité du code ; qualité de la documentation du code et des patchs ; qualité de l organisation du projet ; qualité de la définition des tâches ; respect des délais ; satisfaction du client (ou respect du cahier des charges) ; nombre d interactions avec le client (nombre de demandes de validation, de tests,...) nombre de patchs acceptés ; Certains de ces critères seront vus globalement pour le groupe par l évaluateur. 1

2 2 Introduction L application que l on désire développer a pour objectif la gestion de ressources au sens large. Une ressource peut être une salle, un véhicule, une chambre d hôtel,...dans une première version, nous allons nous intéresser à l aspect planification de l utilisation de ces ressources. Pour faire simple, nous allons proposer : des modules de réservations en fonction du type de la ressource ; des outils de visualisation des réservations. Ce document est divisé en quatre parties : les définitions : tout le vocabulaire utilisé dans l application ; les besoins fonctionnels des différents acteurs ; la méthode de développement ; les contraintes techniques et l environnement technique de développement. Attention le cachier des charges est probablement incomplet! Le client est là pour apporter des précisions et valider vos choix. 3 Définitions 3.1 Utilisateurs L application doit être multi-utilisateurs et multi-profils. Ce que l on entend par multi-profils, c est que chaque utilisateur possède un ou plusieurs types d utilisateur et que chaque type d utilisateur possède des besoins fonctionnels différents. Les besoins des différents types peuvent se recouvrir dans certains cas. Trois types d utilisateur sont actuellement identifiés : l administrateur ; les gestionnaires de ressources ; les invités (guest). L administrateur est comme dans toute application l utilisateur de l application qui a la main sur le paramétrage de l application. Les gestionnaires de ressources seront au coeur de la gestion des ressources. Les invités auront le droit de consulter les informations liées à une ou plusieurs ressources. 3.2 Ressources Une ressource est un objet que l on peut utiliser pendant une certaine période. En général, une ressource est utilisée par une ou plusieurs personnes. Une ressource peut aussi être utilisé sans indication de l utilisateur. Comme l application n est pas spécifique à un type de ressources, nous allons donner quelques exemples Salle Dans le cadre de la gestion de salles d enseignement, de conférences ou même d un hôtel, l objet central est une salle que nous allons nommés ici room. Une salle se caractérise par un identifiant, une capacité (nombre de places) et un type. Le type peut être : amphithéatre, salle informatique,..., ou chambre de base, chambre de luxe,... 2

3 3.2.2 Vidéoprojecteur Lors d une conférence, d un cours,..., du matériel peut être utilisé conjointement ou non à l utilisation d une salle Véhicule Un véhicule peut être utilisé pour un déplacement d une ou plusieurs personnes. 3.3 Utilisateur d une ressource Une ressource est utilisée par des personnes que l on nomme utilisateur (user). Dans le cas de l hôtel, ces personnes sont des clients qui occupent une chambre. Dans le cas d un organisme de formation, une salle de cours est utilisée par un formateur. Les utilisateurs se caractérise par un identifiant (leur nom et prénom, par exemple) et doivent être typés. 3.4 Planning Un planning est un ensemble de périodes où une ressource est réservée pour être utilisée. Toute ressource possède un unique planning et un planning est relatif à une et une seule ressource. Attention, il semble intéressant que certaines ressources soient utilisées de manière conjointe. 3.5 Calendrier Un calendrier est l ensemble des dates valides globalement. Une date invalide est par exemple, la période de fermeture annuelle de l hôtel ou les vacances universitaires. Ce calendrier est unique pour l application. 3.6 Indisponibilité Une ressource peut être indisponible : soit parce que l on est dans une période définie dans le calendrier global ; soit parce qu il n est pas disponible pour une raison quelconque (maintenance, par exemple) 3.7 Réservation Une réservation est le fait qu une ressource soit utilisée sur une période par quelqu un. Chaque réservation peut être complétée par un commentaire. Dans le cadre de l organisme de formation, ça peut être le nom du module qui sera dispensé. Dans le cas de la réservation d un véhicule, on peut y mentionner le trajet et le nombre de kilomètres à réaliser. 3.8 Gestionnaire Seuls les gestionnaires ont le droit de créer une réservation. Les réservations d un gestionnaire ne sont possibles que sur les ressources qu il gére. Néanmoins, un gestionnaire peut faire une demande de réservation à un autre gestionnaire. Ce dernier peut la valider ou non. Une demande de réservation peut se fait : soit sur le type de ressource ( je réserve un vidéoprojecteur ) ; 3

4 soit sur la ressource ( je réserve la salle A121 ). 4 Besoins fonctionnels Nous allons maintenant énumérer les besoins fonctionnels généraux et de chaque type d utilisateurs. 4.1 Lancement et fermeture de l application Au lancement de l application, l utilisateur doit s identifier et s il possède plusieurs rôles (administrateur, gestionnaire ou guest), il doit choisir son rôle. Lors de la connexion à l application, on doit garder en mémoire la date de la connexion. Comme message de bienvenu, l application doit nous dire quelle a été notre dernière date de connexion. Lors de la fermeture de l application, la date est aussi sauvegardée. Seules les dates de la denière connexion sont sauvegardées. Lors de la demande de connexion, si la précédente connexion n a pas été fermée alors la connexion est refusée. Un message s affiche et l application est lancée en mode publique. Le mode publique est un mode limitée à la visualisation des ressources publiques. Une ressource peut être publique ou privée. Si elle est privée alors on ne peut pas visualiser son planning. 4.2 Administration Calendrier La gestion du calendrier global n est possible qu en mode administrateur. Le paramétrage du calendrier consiste à définir les périodes invalides : une simple liste suffira. L ajout d une nouvelle période passe par un petit calendrier (une page par mois) pour définir la date de début et de fin en sélectionnant une date. La modification de ce calendrier est possible seulement en ajoutant une nouvelle période ou en supprimant une période existante Ajout d un nouveau type de ressources L ajout d un type de ressource est complexe (selon le langage de programmation). En effet, les opérations liées à une ressource doivent être intégrées à des plugins. Lors de l ajout, le nouveau type doit être déclaré dans la base de données et le plugin doit être installé. Ce plugin a en charge les opérations : de création du type dans la base : une table spécifique au type de ressource doit être définie avec les attributs liés au type ; de création/modification/suppression de la ressource ; de visualisation de la ressource. Revenons un instant sur la structuration de la base de données liée au ressource. Un type de ressource doit être caractérisé par un identifiant et par le nom du module qui gère ce type. Une ressource possède des caractéristiques génériques (identifiant, capacité, type, publique/privée) et des caractéristiques spécifiques. Ces deux catégories doivent être séparées dans la base de données et le plugin doit prendre en charge les caractéristiques spécifiques. Dans la partie spécifique, on peut avoir envie de définir, pour la ressource de type salle, l organisation de la salle (plan de la salle,...). L opération de visualisation est aussi liée aux caractéristiques spécifiques. 4

5 4.2.3 Ajout d une ressource L ajout est dépendant du type mis à part les informations génériques comme son identifiant, sa capacité, son type et son mode de gestion. Le mode de gestion permet de définir si la ressource peut être gérée par plusieurs personnes. La partie spécifique doit être accessible dans le même écran Les gestionnaires L administrateur est le seul à possèder le droit de gestion des gestionnaires de ressources : création, modification et suppression. La création d un gestionnaire se limite à la définition de son nom et son prénom. L administrateur peut ensuite lui ajouter la liste des ressources qu il gère. Cet ajout se fait via la liste des types. L administrateur choisit le gestionnaire, puis le type de ressources et ensuite la ou les ressources. Attention, la liste des ressources doit être consituée de toutes les ressources du type choisi avec une mention spéciale si la ressource est déjà gérée par quelqu un. On doit pouvoir accèder facilement aux gestionnaires d une ressource depuis cette fonctionnalités. Attention certaines ressources ne sont gérées que par un gestionnaire par définition, elles ne doivent pas apparaître dans la liste. Lors de la création d un gestionnaire, on veut pouvoir dire que ce nouveau gestionnaire gère les mêmes ressources qu un autre gestionnaire. L ajout d une ressource à un gestionnaire doit être accessible tout le temps (pas seulement lors de sa création). Dans le cas de gestionnaires ayant les mêmes ressources à gérer, il serait intéressant que lorsque l on ajoute une ressource à l un, elle soit automatiquement ajouté aux autres. La notion de groupe de gestionnaires serait intéressante. Dès qu un gestionnaire sort d un groupe alors les ressources gérées par le groupe peuvent lui être associés. Dans le cas inverse, si un gestionnaire intégre un groupe alors les ressources qu il gérait peuvent être intégrées à l ensemble des ressources gérées par le groupe. 4.3 Utilisateurs La gestion des utilisateurs est très simple. On doit pouvoir créer, modifier et supprimer un utilisateur. L accès à la liste des utilisateurs est multiple : par la première lettre de son nom ; par son type et par la première lettre de son nom ; La création d un utilisateur (comme celle d un gestionnaire) conduit à créer un login et un mot de passe pour l accès à l application. Le login est créé à l aide du nom et prénom de l utilisateur (première lettre du prénom + nom). Attention aux homonymes! Le mot de passe est généré aléatoirement. L administrateur communique le mot de passe à l utilisateur comme il veut, ce n est pas l application qui le fait. Les utilisateurs peuvent être aussi créés par les gestionnaires. Un utilisateur ne peut que visualiser les plannings des ressources publiques. 4.4 Visualisation du planning La visualisation du planning d une ressource est accessible après sélection de la ressource (quelque soit le type d utilisateur). Par défaut, la visualisation se fait par semaine et sur la semaine courante (sauf si l administrateur a paramétré l application autrement). L utilisateur peut 5

6 choisir le mode journalier, hebdomadaire ou mensuel. Pour l interface, on pourra s inspirer de Calendar de Google. Une journée est représentée en colonne avec des créneaux horaires d une demie-heure. L administrateur pourra fixer la taille des créneaux horaires à un quart d heure. On représentera l ensemble des heures de la journée (de 0h à 24h). Pour plus de clareté, on ne visualisera qu une partie de l ensemble des heures avec 12h comme heure centrale. On pourra voir par exemple de 6h à 18h et pour les autres heures, un scrolling sera à mettre en place. Pour le mode mensuel, on ne fera apparaître seulement les plages horaires de réservation par jour. Des éléments de navigation doivent permettre de passer à la semaine suivante ou précédente (ou mois suivant ou précédent, ou au jour suivant ou précédent selon le mode de visualisation). 4.5 Réservation Les réservations sont réalisées par les gestionnaires. Après sélection d une des ressources gérées par le gestionnaire, son planning apparaît en mode hebdomadaire. Il suffit alors de sélectionner le créneau horaire ou la journée. On peut alors saisir les informations complémentaires de la réservation : les personnes liées à la réservation ; un commentaire. Si les personnes liées à la réservation ne sont pas connus alors il est possible de les créer à la volée. Plusieurs personnes peuvent être en train de manipuler (en modification ou en visualisation ) le planning de la ressource. Si c est le cas alors dès que la réservation est validée, tous les plannings doivent être mise à jour. Si un gestionnaire accède à une ressource en modification alors les autres gestionnaires ne peuvent pas y accèder. Un message d alerte leur signale qui y accède. La modification et la suppression d une réservation se fait via le planning. Une suppression provoque une confirmation. Une réservation est faire l objet d une répétition. Si c est le cas alors de la création, le gestionnaire va spécifier le nombre de répétitions, le mode de répétition (chaque jour, chaque semaine ou chaque mois). La réservation n est créée qu une seule fois dans la base de données. On peut modifier cette réservation via n importe quelle occurrence de la répétition. 4.6 Demande de réservation Un gestionnaire peut faire la demande d une réservation sur une ressource qu il ne gère pas. Cette fonction doit donner accès à l ensemble des ressources gérées par l application. Néanmoins, certaines ressources ne sont pas accessibles par les autres gestionnaires (attention, ce n est pas la même notion que publique/privé qui ne s adresse que la visualisation du planning). Le gestionnaire choisit une ressource dans la liste puis définit la période de la réservation (on peut réutiliser la fonction de définition du période invalide du calendrier global). Le gestionnaire valide sa demande. Lors de la connexion à l application, les gestionnaires ont un message d avertissement si des demandes de réservation leur sont adressées. De même si le gestionnaires est déjà connecté, le même message d avertissement s affiche. Le gestionnaire doit alors sélectionner le menu des demandes afin de les visualiser (nom de la ressource + période + demandeur). Le gestionnaire peut alors : soit valider une ou certaines demandes ; 6

7 soit valider l ensemble des demandes ; soit refuser une ou certaines demandes ; soit refuser l ensemble des demandes ; Les demandes de réservation peuvent aussi être faire l autre de la création d une réservation. Juste après la validation d une réservation, un gestionnaire peut demander à joindre une autre réservation soit sur une ressource gérée par le gestionnaire ou non. Dans les deux cas, cela permet de définir automatiquement la période de réservation. Cette fonction permet d accélérer la réservation des ressources. 4.7 Impression Un des aspects essentiels de l application est l impression des plannings. Deux solutions sont possibles selon les API disponibles : soit par génération de documents PDF et impression par une application tierce ; soit par impression directe. La priorité est l impression des plannings hebdomadaires. 4.8 Multilingues L application doit être accessible en plusieurs langues : français, anglais, allemand et espagnol. Tous les menus, tous les éléments des boîtes de dialogue, tous les messages doivent être multilingues. Le choix de la langue se fait via le menu Options. Tous les types d utilisateurs peuvent le faire. 4.9 Installation Comme les utilisateurs ne sont pas obligatoirement des informaticiens, une procédure automatique d installation doit être proposée. Lors de l installation, il faut indiquer l adresse du serveur de bases de données. Si la base de données n existe pas sur ce serveur alors la base de données doit être créée. Dans ce cas, on fera aussi définir le mot de passe administrateur de l application et tous les paramètres pour la création de la base de données. Si la base de données existe, seule l application est installée en local. Un fichier de paramétrage en XML sera créé pour stocker les paramètres du serveur de base de données ainsi que la liste des paramètres de l application. L ensemble des paramètres doivent être défini lors de l installation. 5 Méthode L objectif de ce projet est de développer de manière collaborative une application en adoptant la démarche extrem Programming. En voici les grandes lignes. 5.1 Les pratiques de développement produire du code simple à modifier coder et concevoir avec simplicité répondre aux besoins du client (et rien d autre!) 7

8 concevoir peu (l essentiel) avant de coder pratiquer le refactoring restructurer régulièrement le code faire le ménage dans le code (nommage de variables bizarres, fonctions obscures,...) diviser les longues fonctions en fonctions plus petites décomposer la fonctionnalités en sous-fonctionnalités (de plus en plus simple) factoriser le code commun tendre vers des pattern designs attention, les tests ne doivent pas être touchés et valider la restructuration par les tests. développer des standards de développement adopter un coding style et rendre public au groupe les règles présenter les règles sous forme d exemples adopter un système de gestion des sources qui permet de vérifier la conformité du code au style développer un vocabulaire commun définir un vocabulaire imagé pour parler des composants du logiciel penser à réviser aussi votre vocabulaire 5.2 Les pratiques du développeur adopter le développement par les tests écrire des tests qui échouent (pour le code non écrit) avant d écrire le code! Ecrire les entêtes des fonctions à tester avant écrire le code pour que les tests passent lancer les tests et automatiser le important : une fonctionnalité est terminée lorsque tous les tests passent! choisir un framework de tests (boost : :test en C++ et unittest en Python) avant la correction d un bug, écrire un test qui teste le bug écrire des tests d acceptation avec le client (si tous ces tests passent alors le travail est fini) programmer en binôme les binômes sont définis pour une tâche ou une courte période : un pilote, celui qui réalise la tâche, un navigateur, celui qui s assure que la tâche est accomplie dans le respect des règles du projet (vérification du code,...) les rôles peuvent changer collaborer pour trouver la meilleure solution diffuser vos connaissances dans l équipe et apprendre des autres adopter la propriété collective du code tout développeur a le droit de modifier toute partie du code si une partie du code peut être amélioré, améliorer le le code doit être lisible pour tous intégrer continuellement maintenir un dépôt du logiciel stable (toutes les parties ont passés les test avec succès) mettre à jour fréquemment votre version locale du code intégrer souvent votre code (à chaque petite modification, ajout,..., liés à une et une seule fonctionnalité) 8

9 attention à la gestion de l intégration, dédier une machine pour cela le code inachevé (non testé) doit être jeté en fin de scéance 6 Contraintes techniques Un serveur local est à votre disposition. Il a été installé sous une Debian Testing. Son accès se fera uniquement par ssh. L environnement de gestion de projets est trac (/urlhttp ://trac.edgewall.org/). Toutes les fonctionnalités seront reprises sous forme de Roadmap et toutes les tâches (mêmes élementaires) sont identifiés, détaillées, assignées (Timeline). La documentation technique sera rédigée sous trac à l aide de la fonction Wiki. Le versionning de code sera assuré par git. Le plugin GitPlugin (/urlhttp ://trac-hacks.org/wiki/gitplugin) doit être installé. git va être central dans le développement. La stratégie de gestion sera la suivante : la version sur le serveur git est la version publique ; chaque participant possède sa version locale ; un seul participant joue le rôle d intégrateur par journée de travail ; les mises à jour se feront par patchs envoyés par mail à l intégrateur ; l intégrateur doit être le garant de la qualité du code, si le code ne respecte pas le coding style établi par le groupe, le patch est rejecté ; si le patch est incorrect, le patch est rejeté (ce n est pas à l intégrateur de corriger les patchs) ; si le commentaire lié au patch est insuffisant, le patch est rejeté (attention de faire des patchs le plus petit possible!). Toutes les fonctions élementaires ne mettant pas en oeuvre l interface graphique devront être instrumentées par des tests unitaires. Ces tests unitaires ont pour rôle de vérifier les contraintes exprimées dans le cahier des charges non fonctionnel et de vérifier la validité des fonctions de base niveau. Les design patterns seront à utiliser au maximum. Pour cela, le projet est à développer à l aide d un des trois langages suivants : Java et Swing Python et PyGTK C++ et GTKmm Le système de base de données est laissé libre mais doit être indépendant du langage de programmation et doit être séparé de l application. Quelques exemples de systèmes de bases de données : mysql ou postgresql. L accès à la base de données sera donc distante. 7 Proposition pour la première journée lecture et analyse du cahier des charges ; construction d un premier modèle UML pour la base de données ; construction d un premier modèle UML de l architecture de l application ; définition de l organisation du code (répertoire, extension des fichiers,...) ; établissement d un coding style (celui-ci sera publié sur le wiki du projet) ; définition des premières tâches ; installation et paramètrage de trac et git ; initialisation du dépôt git. 9

10 8 Constitution des groupes Groupe Java/Swing (5/6 participants) :... Groupe Python/PyGTK (5/6 participants) :... Groupe C++/GTKmm (5/6 participants) :... 10