This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
2010_2011:s1:omgl:mod-si:td:td4 [2010/08/26 19:28] blay créée |
2010_2011:s1:omgl:mod-si:td:td4 [2010/10/07 13:48] (current) blay |
||
---|---|---|---|
Line 1: | Line 1: | ||
- | + | ====== 4) Inspections ====== | |
- | + | ||
- | ===== 4) Inspections ===== | + | |
Line 7: | Line 5: | ||
Après avoir lu avec attention le cahier des charges et les UC qui lui sont fournis : | 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 ==== | ==== Fiche d'inspection ==== | ||
Line 19: | Line 20: | ||
- valide ou non | - valide ou non | ||
- (facultatif) une description de l'anomalie | - (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 : | * 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!)) ) | * 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 | * Lourdeur dans l'analyse (trop de détails qui ne semblent pas opportuns voire imposer une solution) : bénin | ||
- | ==== Déroulement de l'inspection ==== | + | !-==== Déroulement de l'inspection ==== -! |
<box round rgb(185,211,238) rgb(198,226,255) 75%|A rendre> | <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...). | 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> | </box> | ||
- | ===== 5) Confrontations ===== | ||
- | |||
- | |||
- | |||
- | Cette séance est consacrée aux confrontations entre les binômes pour obtenir des compléments d'informations. | ||
- | |||
- | - Pendant les premières 30mn, une série de binôme répond aux questions de ceux qu'ils ont examinés.\\ | ||
- | - Pendant les 30 mn suivantes, ces binômes interrogent à leur tour leurs examinateurs. | ||
- | |||
- | Les 30 dernières minutes vous permettent de faire la synthèse des todo et faire des choix. | ||
- | |||
- | ===== 6) Livraisons ===== | ||
- | Cette séance est consacrée à la livraison. | ||
- | Vous devez justifier oralement vos choix et nous "vendre" votre travail. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | ====== Remarques ====== | ||
- | |||
- | <note> | ||
- | Cette série de TDs vise avec des étudiants débutants à aborder les premières notions de génie logiciel au travers d'une démarche outillée par la norme AFNOR relative au cahier des charges et l'utilisation du modèle des cas d'utilisation en respectant un processus précis pour extraire les fonctionnalités essentielles du système (CG1 du PPN). | ||
- | |||
- | Nous nous appuyons sur une étude de cas permettant l’acquisition d’un savoir-faire dans une optique de travail en équipe avec en perspective une mise en oeuvre dans le cadre d'un autre module (CG2 du PPN). | ||
- | </note> |