Differences

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

--- 2016_2017:s3:methodo:td:livrable1 [2016/09/06 16:00] – blay
+++ 2016_2017:s3:methodo:td:livrable1 [2016/09/27 09:20] (current) – [Le chef de projet pour les S3T] blay
@@ Line 1: / Line 1: @@
 ====== Livrable 1.1 : Analyse de l'étude de cas ======
-<note>Le document est à livrer sous jalon en respectant pour le nom du document :
+<note>Le document est à livrer sous [[http://jalon.unice.fr/cours/blay/Cours-blay-20150827001314/BoiteDepot-blay-20150827001433355111/cours_boite_view?menu=depots|jalon]] en respectant pour le nom du document :
 **NomRespTD_NumeroGroupe_NomsDesEtudiants**
 Si vous ne respectez pas la consigne, nous ne corrigerons pas.
@@ Line 27: / Line 27: @@
 **Date de livraison** :
-  * S3T  : 30 septembre 23h59
+  *  <color blue/lightgrey> S3T  : 30 septembre 23h59</color>
   * S3A :  x octobre 23h59
@@ Line 39: / Line 39: @@
         - Ne racontez pas votre vie ou celle de vos acteurs (par exemple, il choisit les "gros mots" en parlant avec ces collègues... bah... vous êtes sûrs?... Ca apporte quelle information intéressante?)
   - "Nous essayerons de respecter les dates de livraison prévues. " NON NON ... Même pas la peine de le dire, vous les respecterez c'est tout!
-  - La valeur métier d'une US ne s'estime pas en heure !  C'est une valeur relative qui exprime "la valeur que lui accorde le métier" une tâche très rapide à réaliser peut avoir une très forte valeur métier, et inversement...
+  - La valeur métier d'une US ne s'estime pas en heure !  C'est une valeur relative qui exprime "la valeur que lui accorde le métier" une tâche très rapide à réaliser peut avoir une très forte valeur métier, et inversement... Ces valeurs vous ont été données dans l'étude de cas sous la forme de ++, +  ou ==. Vous avez peut-être ajouté des histoires, ou vous en avez modifié. Pour ces histoires "nouvelles" vous devez voir avec votre encadreur leur valeur métier.
-  - Une tâche "développement" n'est pas vraiment informative... On s'attendait davantage à des tâches plus précises liées aux US.
+  - Une tâche "développement" n'est pas vraiment informative... On s'attendait davantage à des tâches plus précises liées aux US, par exemple, construction des composants graphiques, intégration de le lecture de fichiers, etc.
 ===== Le chef de projet pour les S3T =====
 Il peut se faire aider par ses camarades.
+<note tip>
+A priori un chef de projet bien noté est un groupe dans lequel les équipes fonctionnent bien.
+</note>
 **Artefacts de livraison** :\\
      - Un **//document//** contenant :
@@ Line 51: / Line 53: @@
               * Uniquement pour les termes qui seraient propres à une vision globale; Il peut aussi choisir de le partager avec l'ensemble du groupe qui dans ce cas peut contribuer à sa construction et y faire simplement référence dans son propre rendu;
                        *  Evaluation en fonction de la pertinence et de la complétude des termes explicités (et pas le nombre);
-         -  Les grands cas d'utilisation et surtout pas les vues détaillées de chacun des équipes.
+         -  Les grands cas d'utilisation et surtout pas les vues détaillées de chacune des équipes.
               * Il doit donner une vision globale du projet.
+              * L'utilisation de "extends" ou "include" peut permettre d'aborder la question difficile de l'intégration.
                      * Evaluation en fonction de la pertinence, de la complétude et de la justesse des notations : les erreurs de notation induisent des points négatifs,
          - Un ou des diagrammes de classes de niveau analyse,
@@ Line 59: / Line 62: @@
          - Facultatif : des diagrammes de séquence pour représenter quelques exemples identifiés d'interactions entre les projets.
               * Evaluation en fonction de la pertinence, de la complétude et de la justesse des notations : les erreurs de notation induisent des points négatifs,
-         - les propriétés qu'il vous semble essentiel de traiter telles que : sécurité, persistance, robustesse, en expliquant pourquoi. Vous pouvez vous appuyer sur le [[http://en.wikipedia.org/wiki/FURPS. |classement FURPS]], nous reviendrons dans le cours plus tard sur ce point.
+         - les propriétés qu'il vous semble essentiel de traiter telles que : sécurité, persistance, robustesse, en expliquant pourquoi. Vous pouvez vous appuyer sur le [[http://en.wikipedia.org/wiki/FURPS|classement FURPS]], nous reviendrons dans le cours plus tard sur ce point.
+         - une explication sur sa vision du projet et la manière de travailler, un retour critique sur le kanban des équipes en soulignant les points forts et faibles.
 /*     -  un //Kanban// contenant les US détaillées du premier sprint, celles auxquelles votre équipe pense pour le 2nd Sprint (intégration)  moins détaillées;
          * pour chaque US nous avons :