SYNTHLAB Marie CHESNEAU Yves DEMIRDJIAN Yorick PERRET Adrien ROUSSEAU Charles SALIFOU Groupe 1
PLAN I- Organisation 1. Méthode de travail 2. Répartition et gestion du temps 3. Bilan II- Conception / Architecture III- Tests 1. Couche métier 2. Couche IHM 3. Bilan conception 1. Tests unitaires 2. Tests fonctionnels 3. Tests d'acceptation 4. Tests d'ihm Conclusion Démo
I - 1. Méthode de travail Organisation globale : Méthode agile SCRUM Travail en présentiel chaque jour Outils de travail : Google Group Google Drive Github
I - 1. Méthode de travail SCRUM Daily meeting Sprint board et burndown chart Definition of Done Tâche : - code commenté - relecture effectuée par l'équipe User Story : - toutes les tâches terminées - JavaDoc rédigée - tests validés Rétrospective
I- 2. Répartition et gestion du temps Travail en binôme sur chaque user story Une des 2 travaille en plus sur l'ihm L'autre sur les tests 2 personnes sur la conception et l'implémentation Gestion du temps Mise-à-jour du burndown chart Ajout de User Stories Développement "d'extras" (ex : piano, égaliseur,...)
I- 2. Répartition et gestion du temps Burndown chart Sprint 2
I- 3. Bilan Points négatifs : Problèmes d'emplois du temps sur le sprint 1 PC de la fac User Stories peu détaillées Difficulté pour peser les User Stories en points de complexité et estimer un nombre de jours de réalisation Points positifs Méthode SCRUM efficace Travail en présentiel chaque jour Bonne gestion du temps Bonne cohésion dans l'équipe
II - Conception 1. Couche métier : Port Câble Extension Module Architecture globale 2. Couche IHM 3. Bilan conception
II - 1. Architecture globale
II - 1. Architecture globale
II - 1. Architecture globale
II - 1. Port out Module Superviseur port JSyn Câble Un port contient : observateur Une référence sur un câble Un port Jsyn Un label (qui peut être affiché sur une interface) Une référence sur le module qui contient le port Un filtre superviseur qui surveille le signal Une liste d observateurs
II - 1. Port Le superviseur sert à : Détecter si le signal qui le traverse est en surtension Détecter si un signal circule ou non Produire un signal nul (d amplitude 0) lors de l'arrêt du module
II - 1. Câble Composant passif Possède deux références : - un port d'entrée - un port de sortie Connecte les ports JSyn entre eux lorsque les deux références sont valables
II - 1. Extensions Les extensions permettent : De combler un manque à JSyn De corriger certains composants de JSyn Elles sont composées de : Un flux d'entrée Un traitement Un flux de sortie (Des observateurs)
II - 1. Extensions On retrouve comme extension dans notre projet : Des générateurs Des filtres atténuant le son Des enveloppes Des filtres d interception Des filtres modulant le signal Des filtres de supervision 0.1 0.7 0.3-0.12 OK
II - 2. Les modules Un module contient : Un nom Un circuit (pattern adapter) Des paramètres Des ports Des composants JSyn ou des extensions
II - 2. Les modules Un état général on/off Des traitements (conversions d'unités, gestion des observateurs,...) Des méthodes pour récupérer les valeurs spécifiques aux modules Une liste d observateurs pour connaître l état du module
II - 2. Les modules
II - 2. Couche IHM PAC + PROXY + HERITAGE
II - 2. Couche IHM
II - 2. Couche IHM Ports d'entrées et de sorties : même logique que les modules Les câbles et Workspace : modèle PAC Une factory pour les composants graphiques
II - 2. Couche IHM
II - 2. Couche IHM Retours sémantiques :
II - 3. Bilan de conception Problèmes rencontrés : JSyn : signal déformé après utilisation partielle des circuits avec d'autres composants VCF : problème de résonance EG : détection de fronts descendants Bon découpage => implémentation des modules rapide Reprise de code facile (découpage, doc,...)
III - Tests 1 - Tests Unitaires JUnit 3 Uniquement les modules DOD + Non-régression 2 - Tests Fonctionnels Méthode main pour chaque module (indépendants) DOD + Non-régression Sons, affichage de valeurs, de courbes... Critères d'acceptance parfois difficile à définir => Problème de User Story?
III - Tests => Contact avec le product-owner pour l'interprétation des résultats
III - Tests 3 - Tests d'acceptation Scénarios de tests pour la validation du Sprint Critères d'acceptance très difficiles à déterminer => problème de connaissance du domaine métier 4 - Tests d'ihm tout au long du Projet
Conclusion Domaine métier non familier Bonne équipe Méthode SCRUM Séparation des préoccupations = réutilisabilité Perspectives : Adapter le projet pour une autre platforme Ajout de modules par plugin Ajout de modules (effets sonores, instruments, enregistrement et lecture du son en plusieurs formats,...)
Démo