Differences

This shows you the differences between two versions of the page.

--- 2014_2015:s3:concprogobjet:td:td2 [2014/08/28 15:35]
blay [SMARTIE Party ! Savoir décomposer un problème]
+++ 2014_2015:s3:concprogobjet:td:td2 [2014/08/28 17:58] (current)
blay [SMARTIE Party !]
@@ Line 1: / Line 1: @@
-====== TD2 : Soyons Pragmatique ! ======
+====== TD2 : Savoir décomposer un problème ======
-**Objectifs :** Travailler sur de petits exemples différents points d'un développement pragmatic.
-<note warning>DRAFT de DRAFT</note>
+===== SMARTIE Party ! =====
-===== SMARTIE Party ! Savoir décomposer un problème =====
@@ Line 12: / Line 9: @@
 **L'implication de tous et en particulier des étudiants** est indispensable pour que cette séance soit constructive et amusante!</note>
+[[http://www.occitech.fr/blog/2014/05/decoupez-vos-stories-en-carpaccio/|Description en français de l'exercice]] vu par Frank Taillandier.
 **Nos objectifs sont :**
@@ Line 19: / Line 17: @@
   - Auto-Evaluer vos capacités de production.
+**Ce que nous allons faire**
+//
+Construire une application simple en 40 minutes de développement, divisées en 5 itérations de 8 minutes.
+Beaucoup développeraient cette application en découpant en 2-3 tranches, nous la découperons en 15-20 tranches.
+Elephant Carpaccio = tranches très fines, chacune a quand même la forme de l’éléphant, ensemble elles constituent l’éléphant entier.//
 **Déroulement** ([[2014_2015:s3:concprogobjet:td:corrections:smartyPartyInstructions|Voir recommandation pour le professeur ici]])
-  - (10mn) Explication sur l'activité, les objectifs
+  - (15mn) Explications
+          * sur l'activité, les objectifs
+          * Présenter l'étude de cas.
+          * Discuter le principe des user-stories.
+          * Tous les ordinateurs sont "éteints".
   - (5mn) Choisir 4 étudiants (PO) qui auront la charge de valider les US
           * leur distribuer les fiches de suivi
@@ Line 30: / Line 39: @@
         * Environnement et langage de développement libre.
         * Entre les 2 équipes d'un PO, et encore moins entre les groupes, il ne doit pas y avoir d'échanges.
-  - (10mn) Présenter l'étude de cas.
+  - (20 mn)
-  - (15 mn)
+      * Les équipes découpent l'étude en "user stories" **écrites sur Papier**.
-      * Les équipes découpent l'étude en "user stories"
+         * Il faut au moins 10 US.
-         * estimées programmables dans un temps de 3 à 8 minutes chacune,
+         * Elles sont estimées programmables dans un temps de 2 à 6 minutes chacune,
-         * chacune est potentiellement "démontrable" et surtout estimable, i.e. pas de XXXX
+         * Chacune est potentiellement "démontrable" et surtout estimable.
+         * Une US n’est valide que si elle comprend UI, entrée sortie et est visuellement distincte d'une autre US. Une UI peut être une simple console.
+         * Aucune US n’est composée que d’une maquette ou d’une interface, d’un jeu de données ou d’un test.
          * On n'attend pas de bases de donnée, d'IHM, ...
       * Les PO vérifient qu'ils comprennent bien les US, qu'ils sauront les estimer, etc.
       * Les équipes décident des US qu'elles sont capables de délivrer dans les 5 Sprints de 7 mn qui suivent. Elles pourront créer de nouvelles US en cours de cycle mais attention de bien les valider avec le PO.
-  - (5 mn) Chaque PO enregistre sur sa fiche ou au tableau
+  - (5 mn) Chaque PO enregistre (ou fait enregistré) sur sa fiche les prévisions des équipes.
   - (40 mn) Exécutez **5 sprints** de programmation de **7 min**.
-      * Pendant le Sprint de programmation, dès qu'une US est prête à être livrée, elle est présentée au PO.
+      * Pendant le Sprint de programmation, dès qu'une US est prête à être livrée,
+           * Crier "Livraison" mais pas trop fort quand même (( juste pour mettre la pression sur les autres équipes ;-) ))
+           * Vous la présentez au PO.
            * Il peut la rejeter si elle ne correspond pas à ce qui a été défini avec lui.
            * S'il l'accepte, l'équipe  reçoit dans le verre placée devant-elle 3 smarties.
-           * Le PO note la US livrée et le temps par exemple 3eme minute du Sprint.
+           * Le PO note la US livrée et le temps par exemple //3eme minute du Sprint//.
-           * Evidemment vous avez compris qu'une livraison "coûte du temps de programmation".
+           * Evidemment vous avez compris qu'une livraison "coûte du temps de programmation", donc il vaut mieux tester vos US avant de les livrer.
+           * En mémorisant les tests, vous vous assurez de ne rien casser!
       *  À la fin de chaque sprint, le chrono retentit pour signaler que l'on passe au Sprint suivant. Le Chrono ne s'arrête pas et repart aussitôt.
            * Une US livrée correspond à 3 smarties, mais que si le PO décide qu'elle correspond bien à ce qui était annoncé.
-  - (15 mn) Partages entre équipes
+  - (7 mn) Partages entre équipes
       * Chaque équipe d'un PO fait une démonstration à une équipe d'un autre PO et inversement.
-           * Aviez-vous les mêmes US?
+      * Pendant ce temps les PO et le professeur font le point pour préparer l'étape suivante.
-           * Avez-vous développer les mêmes US?
+  - (20 mn) Débriefing
-  - (15 mn) Débriefing
+      * Qui passe le test donné au tableau par le professeur?
-      * Visualiser la différence entre les prévisions et la réalité
+           * Pour tous ceux qui passent le test, écrire le résultat au tableau....
-      * Constatez vous une évolution du nombre de US traitées?
+           * Tout le monde trouve pareil?
+      * Jusqu'où êtes-vous allé ? Indiquez la position approximative de chaque équipe relativement
+           * au nombre de US réalisées puis
-<html>
+           * relativement à la valeur, en particulier
-<!--
+               * qui a géré au moins un état?
-===== Distinguer Classe et Instances =====
+               * qui a géré tous les états état?
+               * qui a géré les remises?
+      * Visualiser  au tableau, la différence entre les prévisions et la réalité des US prévues et traitées
-TROP COMPEXE... je pense que on a un pattern commande ou strategie dans ma modelisation on oublie.
+            * Savez-vous mieux vous estimer ?
+      * Constatez-vous une évolution du nombre de US traitées au fil du temps ?
-Une consommation est caractérisée par une valeur et une unité de consommation qui peut être litre/km ou Galon/mile.
+      * Les PO comment avez-vous vécu la séance?
-Une vitesse est caractérisée par une valeur et une unité de vitesse qui peut être km/heure ou mile/heure.
+      * Pour les développeurs : comment ça a été ?
+             * Quelle est la qualité de votre code ? êtes vous fier de de votre code ? (chaque développeur lève entre 1 et 5 doigts)
-On veut fournir un convertisseur de ces mesures.
+      * Tour de salle : Qu’avez-vous appris ? Qu’allez-vous faire ? Nommez une idée avec laquelle vous repartez aujourd’hui, et une chose que vous ferez différemment à l’avenir.
+      * D’autres questions ou réflexions ?
-  - Proposer un modèle.
-  - Est-il extensible? Puis-je ajouter une nouvelle unité de vitesse telle que //Noeud//(( [[http://fr.wikipedia.org/wiki/N%C5%93ud_(unit%C3%A9)|Un nœud correspond à un mille marin par heure, soit 1,852 km⋅h-1 ou 0,514 m⋅s-1]])) par exemple)?
-  - Est-ce que les comportements précédents sont modifiés ?
---!>
-</html>
-===== Responsabilités et Couplages =====
-On distingue deux formes de consommation pour un même modèle de voiture :
-  * la consommation moyenne sur route ou urbaine [[http://www.fiches-auto.fr/articles-auto/chiffres-consommation/peugeot.php|exemples]]
-  * la consommation en fonction de la vitesse  qui suit la règle suivante ((extraite d'un [[http://www.ilemaths.net/forum-sujet-219647.html|forum de mathématiques]])), elle ne prétend pas être vraie
-<code> C(v) = 2(d/v) + K v^2 avec t en heures, d en km et k un coefficient variable en fonction des voitures. </code>
-Si une voiture roule à ''150 km/h'' sa consommation est donc en ''litre au 100km'' de :
-<code> C(150) = 2(100/150) + K * 150^2 pour la Cl </code>
-Avec un coefficient de ''3,85*10^-4'', ''C(150) = 9.99583333333; C(64) = 4,7 litres au 100km''
-<note warning>Essayez de ne pas tricher, répondez aux questions une par une. </note>
-  - Pour certains modèles de voitures, nous disposons de ces informations. Quelle modélisation proposez-vous pour répondre à des questions comme :
-      * quelle est la consommation moyenne du modèle Clio sur Route (rep. 6,3)? urbaine(rep. 8,1)?
-      * quelle est la consommation moyenne d'une Clio à 150km/h? (mettons 3,85*10^-4 et donc une réponse de quasi 10, ... ce qui n'est pas du tout la réalité!!! ).
-  - Réfléchissez à l'implémentation sur papier au moins.
-  - On intègre à présent la consommation "Mixte", qu'est-ce qui change dans votre modèle? dans votre code?
-  - On vient d'établir une formule ((C'est possible, mais je ne l'ai pas trouvé...)) qui, **pour certains modèles de voitures**, à partir des données connues en circulation urbaine ou sur route permet de déterminer le coefficient K, selon la formule suivante : Au dessus de 100 on prend en compte la consommation sur route que l'on multiplie par 10^-4, entre 100 et 50, la consommation mixte et en dessous urbaine. Quelle modèlisation proposez-vous ?  Quel est le couplage entre vos classes? Avez-vous bien supporté l'extension?
-  - Comment est-il possible de créer un modèle de voiture? Quel est le diagramme de séquence associé (sur papier a minima)? Quel est le code?
-  - En fait, pour certains modèles de voiture (par exemple, les Renaults), les consommations moyennes sont obtenues par des requêtes à un service externe qui, en fonction des informations sur le modèle (on se limite au nom et à l'année, par exemple // Clio 2// et  //2000//), nous renvoie une chaine de caractères au format JSON, par exemple ''{"consommation": {"route" : "6.3", "urbaine" : "8.1" } }'', Intégrer ce type de "calcul" de la consommation dans votre modélisation, quel est l'impact?
-  - Que retenez-vous?
-<box round rgb(150,290,190) rgb(198,226,150) 75%|A la fin de cette séance (au plus tard en fin de semaine) >
-  * Dans votre répertoire de projet, sous TD2, se trouvent:
-       - Un document contenant
-             * votre modèle final (Tout le monde n'aboutit pas au même modèle, c'est certain)
-             * des explications sur les raisons de ce modèle (dont vous êtes très fiers) et les leçons apprises.
-       - Les codes et les tests. Pensez bien que le service externe ne doit pas être implémenté. Une fonction qui pour l'instant retourne à chaque fois la même chaine de caractère convient très bien, et vous considérerez aussi la transformation d'une chaine de caractère JSON en "autre chose" comme donnée.
-</box>
-===== Refactoring et Duplication =====
-Le bus est maintenant composée de boîtes à messages.
-Plusieurs producteurs peuvent émettre des messages vers une même boîte, plusieurs consommateurs peuvent lire les messages dans une boite.
-//Exemples de scénario ://
-   - La voiture A a choisi d'émettre son message vers la boîte "Etat Des Routes".
-   - La voiture B demande combien il y a de messages dans la boite "Etat Des Routes"
-   - La voiture B demande les messages qui se trouvent dans la boite "Etat des Routes" et récupère le message émis par la voiture A.
-   - La voiture A efface le message qui se trouve dans la boite "Etat Des Routes".
-   - L'agence "X" demande tous les messages courants.
-**A FAIRE :**
-  - Proposer un modèle de classes en conception
-  - Vérifier que tous les scénarios sont "faisables". Pour cela vous pouvez construire des diagrammes de séquence.
-  - Vérifier les propriétés vues en cours : orthogonalité?
-  - Implémenter et tester votre code sur les scénarios donnés.
-  - On sait que l'on a très souvent besoin de connaître le nombre de messages dans une boîte que proposez-vous?
-===== Donnez-nous des exemples =====
-Prenez le cours et vos codes passés un peu "conséquent" et donner des exemples de codes STUPID (au moins Deux exemples différents) et ce que vous feriez maintenant pour ne plus faire les mêmes erreurs.
-Rendu noté sur la pertinence des réponses.
-===== Polymorphisme =====
-Le bus supporte à présent différents types de messages : Rémanent, Ephemere, Fondamental, Protegé, Intelligent ...
-A INTEGRER : Rearmamble : il s'etint au bout d'un temps donné, il doit etre réactivé et si il n'est pas rearma u bout d'un certain temps il est détuit.. cela peut servir pour la gestion des pannes.
-Chacun de ces types de messages répond aux exigences suivantes concernant leur cycle de vie
-^  ^ Création ^ Lecture ^ MiseAJour ^ Destruction^
-^ Rémanent| Il connait son créateur | | Peut être mis à jour par son créateur| Ne peut être détruit que pas son créateur|
-^ Ephemere| | Est automatiquement retiré de sa boîte dès qu'il est lu| Ne peut pas être mis à jour| Ne peut être détruit que s'il n'est plus dans une boite|
-^Temporel|Il connait la date où il a été créé et sa durée |Il ne peut être lu que s'il n'est pas périmé. S'il est périmé, il est détruit lorsque l'on demande à le lire|Peut être mis à jour| Est automatiquement détruit quand il est périmé|
-^ Intelligent|Il connait son créateur|N'est proposé qu'à ceux qui ne l'ont pas encore lu| Ne peut pas être mis à jour|Ne peut être détruit que si il a été lu au moins une fois||
-**A FAIRE**
-  - Proposer un modèle de classes en conception
-  - Vérifier que tous les scénarios sont "faisables"...
-  - Vérifier les propriétés vues en cours
-  - Implémenter et tester votre code sur les scénarios donnés.
-  - Vérifier que tous vos scénarios précédents sont toujours fonctionnels, en utilisant les tests. Si ce n'est pas le cas, mettez vos codes à jour pour satisfaire les tests.
-  - Quel impact sur le calcul du nombre de messages dans une boîte ?
-===== Responsabilités =====
-En fonction des mots clefs qui constituent le contenu des messages, ils sont automatiquement associés à une boîte de message. Si aucune correspondance n'est détectée une boîte "Divers" est utilisée.
-Exemples :
-     - "Accident " conduit à poster le message dans la boite "URGENCE"
-     - "Danger " conduit à poster le message dans la boite "URGENCE"
-     - "photo " conduit à poster le message dans la boite "SNAPCHAT"
-**A FAIRE**
-    - Qui crée les messages?
-    - Qui est responsable de filtrer les mots clefs?
-    - Quel est la complexité du filtrage?
-    - Déterminer le couplage de vos classes
-===== Abstraction =====
-Si maintenant, on veut créer une nouvelle boîte qui reçoit les messages contenant contenant "photo", que faut-il faire pour que votre système le prenne en compte?
-Si maintenant on veut que tout message dans la boite SNAPCHAT soit ephemere ?
-===== Estimation de performance =====
-Une route est définie par des Tronçons. Un tronçon est défini par deux Positions et une longueur. Une Position est définie par un nom.
-Calculer le plus cours chemin entre deux positions.
-Déterminer la complexité de votre algorithme.
-=> Outils de recherche de code dupliqué?
-===== Suites prévues pour ce projet =====
-  * //Objectifs  : refactoring, incrémentalité et agilité// : Le bus est maintenant composée de boîtes à messages :
-Le bus gère des "boîtes à message". Plusieurs producteurs peuvent émettre des messages vers une même boîte, plusieurs consommateurs peuvent lire les messages dans une boite.
-Dans le scénario de base, la voiture A a choisi d'émettre son message vers la queue "Etat Des Routes". Les consommateurs déclarent les boîtes qui les intéressent. Ils peuvent lire les messages qui les intéressent sur une boîte donnée ou obtenir tous les messages qui les intéressent indépendamment des boîtes.  Plusieurs types de messages? Qui est responsable de créer les messages? Qui connait les boîtes de messages ?
-  * //Objectifs : Apprentissage d'une famille courante de patterns (fabrique, builder) mais uniquement par l'usage, la formalisation se fera en S4//: Les messages pouvant être de différentes natures, un bus devient "porteur" d'une fabrique à messages.
-  * //Objectifs : Prise en compte des IHMs et mise en place du pattern MVC à tous les niveaux// : Définir les interfaces graphiques qui nous permettraient d'accéder "simplement" à un bus pour émettre, lire et effacer des messages uniquement.
-  * //Objectifs : Prise en considération des responsabilités uniques// : Routage en fonction des messages : La voiture A emet un message et le bus décide de la ou des boîtes à messages concernées.
-  * //Objectifs : mise en oeuvre du pattern DAO + différents modèles de persistance + intégration par les interfaces + travail en équipe// : Les messages seront rendus persistants. Pour certaines boîtes les messages sont persistants, pour d'autres non :
-  * Il est assez surprenant d'effacer les messages au bout d'un certain temps alors que certains consommateurs ne les ont pas lu et de redonner le même message au même consommateur qui l'a déjà lu. Que feriez-vous pour : a) ne pas redonner le même message au même consommateur; b) donner les messages aux consommateurs qui ne les ont pas encore lu? quel écueil( le bus ne connait pas ses consommateurs!) ? quelle solution envisageriez-vous (un consommateur se déclare, une file d'attente par consommateur, et le message est détuit lorsque plus aucune file n'y fait référence)?
-- Il sera possible de définir différentes formes de souscription.
-Nous n'aborderons, hélas, pas les aspects distribués.

Cours au département INFO - IUT - UNS

User Tools

Site Tools

Differences

Page Tools