SYNTHLAB. Marie CHESNEAU Yves DEMIRDJIAN Yorick PERRET Adrien ROUSSEAU Charles SALIFOU. Groupe 1

Transcription

1 SYNTHLAB Marie CHESNEAU Yves DEMIRDJIAN Yorick PERRET Adrien ROUSSEAU Charles SALIFOU Groupe 1

2 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

3 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

4 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

5 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,...)

6 I- 2. Répartition et gestion du temps Burndown chart Sprint 2

7 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

8 II - Conception 1. Couche métier : Port Câble Extension Module Architecture globale 2. Couche IHM 3. Bilan conception

9 II - 1. Architecture globale

10 II - 1. Architecture globale

11 II - 1. Architecture globale

12 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

13 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

14 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

15 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)

16 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 OK

17 II - 2. Les modules Un module contient : Un nom Un circuit (pattern adapter) Des paramètres Des ports Des composants JSyn ou des extensions

18 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

19 II - 2. Les modules

20 II - 2. Couche IHM PAC + PROXY + HERITAGE

21 II - 2. Couche IHM

22 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

23 II - 2. Couche IHM

24 II - 2. Couche IHM Retours sémantiques :

25 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,...)

26 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?

27 III - Tests => Contact avec le product-owner pour l'interprétation des résultats

28 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

29 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,...)

30 Démo