User Tools
2013_2014:s3:tp:deroulements
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
2013_2014:s3:tp:deroulements [2013/10/19 08:38] blay [Déroulement] |
2013_2014:s3:tp:deroulements [2013/10/24 08:52] (current) blay [Notation] |
||
|---|---|---|---|
| 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 étudiants qui ont réalisé l'IHM au maximum 2 étudiants | ||
| * 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? | ||
| - | * Une IHM ne peut pas être livrée plusieurs fois. | + | * 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. Si une IHM déjà livrée est étendue pour prendre en compte une autre US, elle ne sera pas évaluée sur la précédente US... | ||
| + | |||
| + | ==== Une livraison par Intégration ==== | ||
| + | |||
| + | * la liste des US intégrées | ||
| + | * liste des étudiants ayant contribué à l'intégration (pas de limite, si ce n'est les membres des équipes mises en jeux | ||
| + | * 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 codes correspondant à l'application intégrée | ||
| + | * 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> | ||
| - | |||
| - | * A minima un niveau de 6 points métiers est attendu pour les US, donc tout est étudiant sera noté a priori sur 60 pour les US | ||
| - | * A minima 3 points métiers pour les IHMs : donc tout est étudiant est noté a priori sur 30 pour les IHMs | ||
| - | * A minima un niveau de 8 points métiers pour les intégrations est attendu par l'équipe, donc 80 points pour l'intégration | ||
| Chaque étudiant obtient une note individuelle basée sur : | Chaque étudiant obtient une note individuelle basée sur : | ||
| * la note obtenue par chacune des US auxquelles il a participé, pondérée par la valeur métier de la US; //exemple : Note à la US 5/10, valeur métier 2 => 10 points// | * la note obtenue par chacune des US auxquelles il a participé, pondérée par la valeur métier de la US; //exemple : Note à la US 5/10, valeur métier 2 => 10 points// | ||
| * la note obtenue par chacune des IHMs, autres que textuelles, fournie avec une US pondérée sur la base d'un point métier. Si une IHM, non textuelle, couvre plusieurs US elle est évaluée sur la base d'un point par US //exemple : Note à l'IHM 7/10, elle couvre 3 US => 21 points// | * la note obtenue par chacune des IHMs, autres que textuelles, fournie avec une US pondérée sur la base d'un point métier. Si une IHM, non textuelle, couvre plusieurs US elle est évaluée sur la base d'un point par US //exemple : Note à l'IHM 7/10, elle couvre 3 US => 21 points// | ||
| - | * l'utilisation de la forge : gestion des tickets, gestion du SVN, ... | + | * l'utilisation de la forge : gestion des tickets, gestion du SVN, ... notée sur 20 |
| + | * la note obtenue dans les intégrations | ||
| + | * l'intégration des US au sein de l'équipe et éventuellement avec d'autres équipes : | ||
| + | * l'intégration de 2 US correspond à une note pondérée par la valeur métier qui est de 2 : elle est évaluée sur la pertinence de l'intégration, objets partagés, interfaces, sa complexité... | ||
| + | * l'intégration de 2 US issues de groupes différents suit les mêmes principes que précédemment, mais elle sera ajustée par un coefficient de complexité de 1,5 en fonction de la pertinence de l'intégration et du découpage : //exemple : Note à l'intégration entre deux groupes 6/10, valeur métier 2 => 12 points, découpage justifié entre les deux équipes, pertinence de l'assemblage coefficient s'applique : 18 points// | ||
| Chaque étudiant doit avoir participer pour au moins 9 points de US et/ou d'IHM. | Chaque étudiant doit avoir participer pour au moins 9 points de US et/ou d'IHM. | ||
| Dans le cas contraire, un malus s'appliquera en plus, proportionnel au nombre de points métier non couverts. | Dans le cas contraire, un malus s'appliquera en plus, proportionnel au nombre de points métier non couverts. | ||
| Cette note individuelle sera composée avec la note obtenue par son équipe. | Cette note individuelle sera composée avec la note obtenue par son équipe. | ||
| + | |||
| + | * **A minima un niveau de 6 points métiers** est attendu pour les US, donc tout est étudiant sera noté a priori sur 60 pour les US | ||
| + | * A minima 3 points métiers pour les IHMs : donc tout est étudiant est noté a priori sur 30 pour les IHMs | ||
| + | * A minima un niveau de 8 points métiers pour les intégrations (4 intégrations) est attendu par l'équipe "individualisée", donc 80 points pour l'intégration | ||
| + | * Donc un étudiant est noté sur la base de 170 points + 20 points sur l'utilisation de la forge. | ||
| Chaque équipe est notée sur : | Chaque équipe est notée sur : | ||
| * Le premier rendu sur la planification | * Le premier rendu sur la planification | ||
| - | * l'intégration des US au sein de l'équipe et éventuellement avec d'autres équipes : | ||
| - | * l'intégration de 2 US correspond à une note pondérée par la valeur métier qui est de 2 : elle est évaluée sur la pertinence de l'intégration, objets partagés, interfaces, sa complexité... | ||
| - | * l'intégration de 2 US issues de groupes différents suit les mêmes principes que précédemment, mais elle sera ajustée par un coefficient de complexité de 1,5 en fonction de la pertinence de l'intégration et du découpage : //exemple : Note à l'intégration entre deux groupes 6/10, valeur métier 2 => 12 points, découpage justifié entre les deux équipes, pertinence de l'assemblage coefficient s'applique : 18 points// | ||
| * Le suivi du projet et la concordance entre les prévisions et le réalisé | * Le suivi du projet et la concordance entre les prévisions et le réalisé | ||
| * le produit final évalué sur | * le produit final évalué sur | ||
| * les documents et codes terminaux livrés | * les documents et codes terminaux livrés | ||
| - | * la présentation faite en TD | + | * la présentation faite en TD (si elle a lieu) |
| * notation par les enseignants | * notation par les enseignants | ||
| * notation par les camarades | * notation par les camarades | ||
| ===== Déroulement ===== | ===== Déroulement ===== | ||
| + | |||
| + | <note warning> | ||
| + | Vous avez 21h de TP prévus pour cette étude en tout! | ||
| + | Vous devez utiliser cette base pour répartir le travail. | ||
| + | </note> | ||
| + | |||
| + | ==== Consignes ==== | ||
| * Le "product owner" est joué par votre encadreur de TP. | * Le "product owner" est joué par votre encadreur de TP. | ||
| - | * Chaque équipe peut s'attribuer un "scrum master"((encore que nous ne faisons pas vraiment du scrum)). | + | * Chaque équipe peut s'attribuer un "scrum master"((encore que nous ne faisons pas vraiment du scrum)), pas plus de 5 membres par équipe pas moins de deux ((c'est trop peu)) et si possible les mêmes qu'en TD. |
| * Il n'est pas possible de mélanger les membres des différentes équipes. Il est par contre possible, voir encouragé, d'intégrer les travaux de plusieurs équipes. | * Il n'est pas possible de mélanger les membres des différentes équipes. Il est par contre possible, voir encouragé, d'intégrer les travaux de plusieurs équipes. | ||
| - | * Certaines US sont trop grosses et peuvent faire l'objet d'un redécoupage. Ce redécoupage est discuté avec le "product owner" qui attribue les points métiers aux US. | + | * Fonctionnement basé sur des US ([[2013_2014:s3:tp:sujet|voir ici)]] |
| - | * Certaines US sont incomplètes. Avec le "product owner" vous devez les compléter. Sans son accord, vous ne pouvez pas ajouter de nouvelles fonctionnalités. La valeur métier d'une US ainsi redéfinie peut être modifiée par le "product owner". | + | * aucun travail n'est commencé sans correspondre à une tâche dans la forge* |
| + | * Certaines US sont trop grosses et peuvent faire l'objet d'un redécoupage. Ce redécoupage est discuté avec le "product owner" qui attribue les points métiers aux US. | ||
| + | * Certaines US sont incomplètes. Avec le "product owner" vous devez les compléter. Sans son accord, vous ne pouvez pas ajouter de nouvelles fonctionnalités. La valeur métier d'une US ainsi redéfinie peut être modifiée par le "product owner". | ||
| + | * Les rendus se font au fur et à mesure que les US sont terminées | ||
| + | * Evaluation des US: pour qu'une US passe en "livraison", elle doit faire l'objet d'une "évaluation" par l'équipe complète qui valide le rendu. | ||
| + | * 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 même étudiant ne peut pas livrer plus de deux US en une fois. | ||
| + | * l'intégration des différentes US fait l'objet de discussions au sein de l'équipe. | ||
| - | * Evaluation des US: pour qu'une US passe en "livraison", elle doit faire l'objet d'une "évaluation" par l'équipe complète qui valide le rendu. | ||
| - | * 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. | ||
| - | * Intégration des différentes US fait l'objet de discussions au sein de l'équipe. | ||
| + | ==== Première séance ==== | ||
| - | Première séance, **tout ce qui suit doit être rendu ** : | + | |
| - | * 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). | ||
| - | * Chaque équipe planifie les US qu'elle va prendre en compte, | + | * A placer dans la forge dans le dossier document ou sous SVN au choix |
| - | * Qui fait quoi? Pas plus de deux personnes par US, les paires doivent changer; | + | - 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**; | ||
| * 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 | ||
| + | * **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'', | ||
| + | * un délai de 15 jours est accordé pour ce point | ||
| + | |||
| + | <note warning>C'est une planification qui est demandée. Vous pourrez en changer. Mais elle doit vous aider à évaluer vos justesse dans l'évaluation des tâches. </note> | ||
| + | |||
| + | ==== 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** | ||
| Une livraison induit : | Une livraison induit : | ||
| * 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 avec un sujet bien formé : //[S3T] Livraison US-Identifiant Nom des étudiants// ou bien IHM etc... |
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
| - | + | ||
2013_2014/s3/tp/deroulements.1382164707.txt.gz · Last modified: 2013/10/19 08:38 by blay
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International
