Differences

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

--- 2010_2011:s1:omgl:mod-si:td:td4 [2010/08/26 17:31] – blay
+++ 2010_2011:s1:omgl:mod-si:td:td4 [2010/10/07 11:48] (current) – blay
@@ Line 5: / Line 5: @@
 Après avoir lu avec attention le cahier des charges et les UC qui lui sont fournis :
-   * Le client va devoir relever tous les éléments qui lui semblent incohérents ( non valides, incohérences des fonctionnalités, choix qui semblent non pertinents, absence de vocabulaire, ...), oubliés (des contraintes, des normes, ...) ou au contraire vous "bifferez" les points qui vous paraissent bien définis.
+   * Le client va devoir relever tous les éléments qui lui semblent incohérents (définitions imprécises, éléments non valides, incohérences des fonctionnalités, choix qui semblent non pertinents, absence de vocabulaire, ...), oubliés (des contraintes, des normes, ...) ou au contraire vous "bifferez" les points qui vous paraissent bien définis et/ou originaux.
-   * Le fournisseur informatique doit relever les points d'ombre qui ne lui permettent pas de clairement comprendre ce que doit faire le système à implémenter, l'absence de certaines limite, ...  ou au contraire vous "bifferez" les points qui vous paraissent bien définis.
+   * Le fournisseur informatique doit relever les points d'ombre qui ne lui permettent pas de clairement comprendre ce que doit faire le système à implémenter, l'absence de certaines limites, ...  ou au contraire vous "bifferez" les points qui vous paraissent bien définis.
+<note important>
+Vous devez respecter le client du groupe qui vous a donné son CdCF. Cependant, vous pouvez trouver des manques entre les besoins énoncés, le sujet initial et les fonctionnalités proposées.
+</note>
 ==== Fiche d'inspection ====
@@ Line 17: / Line 20: @@
   - valide ou non
   - (facultatif) une description de l'anomalie
-  - (facultatif) le degré de sévérité de l'anomalie :
+  - (facultatif) le degré de sévérité de l'anomalie : //grave// (à corriger absolument avant de continuer), //passable// (à corriger mais à un moment qui conviendra à l'équipe), //bénin// (à ne pas corriger forcément).
-//grave// (à corriger absolument avant de continuer), //passable// (à corriger mais
-à un moment qui conviendra à l'équipe), //bénin// (à ne pas corriger
-forcément).
       * Exemples :
-         * Oubli d'une fonction importante : erreur grave à corriger avant de
+         * Oubli d'une fonction importante : erreur grave à corriger avant de continuer (car cette erreur grave peut rejaillir sur le reste du système)
-continuer (car cette erreur grave peut rejaillir sur le reste du système)
          * Fonction mal spécifiée : passable (il faut corriger mais à son rythme((avant de rendre le devoir quand même!)) )
          * Lourdeur dans l'analyse (trop de détails qui ne semblent pas opportuns voire imposer une solution) : bénin
@@ Line 31: / Line 30: @@
 <box round rgb(185,211,238) rgb(198,226,255) 75%|A rendre>
-Vous rendrez en fin de séance la fiche d'inspection pour chacun des membres.
+Vous rendrez en fin de séance UNE fiche d'inspection par groupe intégrant les points de vues : client et concepteur.
-Ce n'est pas la qualité du cahier des charges qui sera évalué mais votre pertinence dans l'analyse.
+Ce n'est pas la qualité du cahier des charges qui sera évalué dans cette fiche mais votre pertinence dans l'analyse.
+N'oubliez pas de mettre vos noms dans la fiche et de préciser le cahier des charges que vous évaluez.
 Vos fiches seront évidemment remises à l'autre groupe (comme dans la vraie vie, on doit aussi savoir dire les choses...).
+  * Le sujet du mail sera : **
+S1-//<Numéro de votre groupe de TD>// : fiche //<noms des membres>//**
 </box>