This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
2013_2014:s3:tp:deroulements [2013/10/19 08:44] blay |
2013_2014:s3:tp:deroulements [2013/10/19 11:04] blay [Une livraison par US] |
||
---|---|---|---|
Line 6: | Line 6: | ||
- | Une livraison par US | + | ==== Une livraison par US ==== |
- | * la US : elle a dû être complétée pour | + | |
+ | * la US complétée pour | ||
* expliciter sa complexité du point de vue de l'équipe | * expliciter sa complexité du point de vue de l'équipe | ||
* clarifier ou enrichir les critères d'acception | * clarifier ou enrichir les critères d'acception | ||
Line 15: | Line 16: | ||
* les tests de validation prévus (sous la forme d'une description de flot d'évènement) ou de tests automatiques. | * les tests de validation prévus (sous la forme d'une description de flot d'évènement) ou de tests automatiques. | ||
* un diagramme de classes((il peut être obtenu par reverse engineering)) comprenant multiplicité, navigation, ...; | * un diagramme de classes((il peut être obtenu par reverse engineering)) comprenant multiplicité, navigation, ...; | ||
- | * des codes avec leurs tests unitaires et d'intégration s'il y a lieu : la qualité des codes sera considérée. | + | * des codes avec leurs tests unitaires et d'intégration s'il y a lieu : la qualité des codes sera considérée. |
+ | * Une US au sein d'une équipe ne peut pas être livrée plusieurs fois, même s'il y a changement de contributeurs | ||
* Evidemment une US est livrée que lorsqu'elle répond à tous les critères. | * Evidemment une US est livrée que lorsqu'elle répond à tous les critères. | ||
Nous considérons alors la US comme "**complète**". Nous ne la considérons comme "validée" que lorsque le "product owner" l'a validée. | Nous considérons alors la US comme "**complète**". Nous ne la considérons comme "validée" que lorsque le "product owner" l'a validée. | ||
- | * Une US ne peut pas être livrée plusieurs fois. | ||
- | + | {{ :2013_2014:s3:tp:capture_d_e_cran_2013-10-19_a_11.03.13.png?nolink&300 | Prévision d'évaluation des US}} | |
- | Une livraison par IHM : | + | ==== Une livraison par IHM ==== |
+ | |||
* le code de l'IHM | * le code de l'IHM | ||
* les tests réalisés : soit en utilisant un outil sélénium ou autre; soit une vidéo ; soit un compte-rendu textuel | * les tests réalisés : soit en utilisant un outil sélénium ou autre; soit une vidéo ; soit un compte-rendu textuel | ||
* les évaluations obtenues : qui a testé? Combien? que lui avez-vous demandé? qu'en déduisez-vous? | * les évaluations obtenues : qui a testé? Combien? que lui avez-vous demandé? qu'en déduisez-vous? | ||
+ | * les documents que vous jugez utiles : arbre de tâche, modèle de l'IHM, ... | ||
* Une IHM ne peut pas être livrée plusieurs fois. | * Une IHM ne peut pas être livrée plusieurs fois. | ||
+ | |||
+ | ==== Une livraison par Intégration ==== | ||
+ | |||
+ | * la liste des US intégrées | ||
+ | * un diagramme "UML" explicitant l'intégration avec éventuellement un texte d'explications | ||
+ | * les tests d'intégration ayant permis d'anticiper l'intégration | ||
+ | * les tests automatiques réalisés | ||
+ | * les documents qui vous semblent utiles. | ||
===== Notation ===== | ===== Notation ===== | ||
<note warning>Cette notation pourra être ajustée en fonction de votre travail</note> | <note warning>Cette notation pourra être ajustée en fonction de votre travail</note> | ||
Line 60: | Line 71: | ||
Vous devez utiliser cette base pour répartir le travail. | Vous devez utiliser cette base pour répartir le travail. | ||
</note> | </note> | ||
+ | |||
+ | ==== Consignes ==== | ||
* Le "product owner" est joué par votre encadreur de TP. | * Le "product owner" est joué par votre encadreur de TP. | ||
Line 70: | Line 83: | ||
* Une US livrée peut être modifiée ultérieurement, par exemple pour tenir compte des remarques ou pouvoir être intégrée. Elle ne pourra cependant pas être livrée plusieurs fois. | * Une US livrée peut être modifiée ultérieurement, par exemple pour tenir compte des remarques ou pouvoir être intégrée. Elle ne pourra cependant pas être livrée plusieurs fois. | ||
* Un étudiant ne peut pas livrer plus de deux US en une fois. | * Un étudiant ne peut pas livrer plus de deux US en une fois. | ||
- | * Intégration des différentes US fait l'objet de discussions au sein de l'équipe. | + | * l'intégration des différentes US fait l'objet de discussions au sein de l'équipe. |
- | Première séance, **tout ce qui suit doit être rendu ** : | + | ==== Première séance ==== |
- | * Chaque équipe décrit l'ensemble des use cases sans les décrire sous la forme de flots d'événements | + | |
+ | |||
+ | <note warning> **tout ce qui suit doit être rendu ** au plus tard le **lundi 18h** suivant la séance</note> | ||
+ | |||
+ | * Chaque équipe fournit un diagramme de cas d'utilisation (UC) sans les décrire sous la forme de flots d'événements | ||
* Objectifs : visualiser l'ensemble des UC répondant à l'appel d'offre (limitez-vous à ceux déduits à partir des histoires utilisateurs). | * Objectifs : visualiser l'ensemble des UC répondant à l'appel d'offre (limitez-vous à ceux déduits à partir des histoires utilisateurs). | ||
+ | * A placer dans la forge dans le dossier document ou sous SVN au choix | ||
* Chaque équipe planifie les US qu'elle va prendre en compte, | * Chaque équipe planifie les US qu'elle va prendre en compte, | ||
- | * Qui fait quoi? Pas plus de deux personnes par US, les paires doivent changer; | + | * Qui fait quoi? Pas plus de deux personnes par US, **les paires doivent changer**; |
* Evalue la complexité des US (des cartes de planning pocker seront fournies aux équipes qui le désirent) | * Evalue la complexité des US (des cartes de planning pocker seront fournies aux équipes qui le désirent) | ||
- | * les dates de rendus des US prévus (rappel pas plus de 2US par étudiant en une fois) | + | * les dates de rendus des US prévus (rappel pas plus de 2 US par étudiant en une fois, les paires doivent bouger, une US peut etre réalisée par un étudiant seul) |
- | * Cette planification est faite dans la forge | + | * **Cette planification est faite dans la forge** |
- | * Chaque équipe planifie les IHMs évoluées qu'elle va rendre ou non | + | * Chaque équipe planifie les IHMs évoluées qu'elle va rendre ou non, |
- | * Chaque équipe planifie les intégrations qui seront réalisées et les dates de livraison; | + | * **Cette planification est faite dans la forge** |
- | * Une équipe peut décider de l'intégration avec les travaux d'une autre équipe. | + | * Chaque équipe planifie les intégrations qui seront réalisées et les dates de livraison |
- | * Chaque équipe précise les technologies de développement qui seront utilisées, des approches "objets" sont exigées (pas de php sans objet). | + | * **Cette planification est faite dans la forge** |
+ | * Une équipe peut décider de l'intégration avec les travaux d'une autre équipe **dans la forge** | ||
+ | * **Cette planification est faite dans la forge** | ||
+ | * Chaque équipe précise les technologies de développement qui seront utilisées, des approches "objets" sont exigées (pas de php sans objet), | ||
+ | * un document est placé dans le dossier ''document'' | ||
+ | |||
+ | ==== Autre séance ==== | ||
- | Dans les séances suivantes vous travaillerez en respectant les règles suivantes: | + | Vous travaillerez en respectant les règles suivantes: |
- | * Toute séance doit commencer par une discussion breve : où j'en suis, ce qui reste à faire, les problèmes rencontrés | + | * Toute séance doit commencer par une discussion brève, 1/4 d'heure maximum: |
+ | * où j'en suis, ce qui reste à faire, les problèmes rencontrés | ||
* Toujours prendre le temps avant de commencer à concevoir seul ou en paire sur une nouvelle US, d'en discuter avec l'équipe (au moins pour validation) | * Toujours prendre le temps avant de commencer à concevoir seul ou en paire sur une nouvelle US, d'en discuter avec l'équipe (au moins pour validation) | ||
- | * Prévoir les tests de validation dès le début | + | * Prévoir les tests de validation dès le début des US |
* Une US est livrée que lorsque elle est complète au sens défini dans la partie **Rendu** | * Une US est livrée que lorsque elle est complète au sens défini dans la partie **Rendu** | ||
Line 95: | Line 120: | ||
* une présentation au product owner avec l'équipe présente | * une présentation au product owner avec l'équipe présente | ||
* un mail précisant où se trouvent les éléments de la livraison dans la forge | * un mail précisant où se trouvent les éléments de la livraison dans la forge | ||
- | |||
- | |||
- | |||
- | |||