Differences

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

--- 2010_2011:s1:omgl:mod-si:td:start [2010/08/26 16:42] – blay
+++ 2010_2011:s1:omgl:mod-si:td:start [2011/02/15 17:52] (current) – blay
@@ Line 1: / Line 1: @@
 ====== AF d'un SI simplifié de gestion d'une galerie d'art ======
-Le défi à relever pendant cette série de TD est la construction d'un cahier des charges pour une
+Le défi à relever pendant cette série de TDs est la construction d'un cahier des charges pour une galerie d'art qui désire modifier son système d’informations pour à la fois centraliser l’ensemble des informations et favoriser des ventes par correspondance.
-Voici la description donnée par une galerie d'art qui désire modifier son système d’informations pour à la fois centraliser l’ensemble des informations et favoriser des ventes par correspondance.
-La description est incomplète et peut contenir des incohérences. A vous de cerner les besoins de votre nouveau client et d’établir les bases du contrat que vous allez passer avec lui.
-L'énoncé distribué au format papier est disponible [[2010_2011:s1:omgl:mod-si:td:texteOriginal|ici]].
+===== Déroulement des TDs =====
 <note warning>
@@ Line 14: / Line 15: @@
 Il vous ai uniquement donné à titre indicatif.
 </note>
-Déroulement des TDs
 **//Phase A ://** Un des étudiants jouera le client, l'autre le fournisseur. Le cahier des charges partiel résultant de la 1ère phase est le contrat passé entre les deux.\\
@@ Line 30: / Line 28: @@
 **//Phase C ://** A partir des fiches d'inspections obtenues sur leur travail, les étudiants modifient et complètent leur cahier des charges et use-cases.\\
+   - [[2010_2011:s1:omgl:mod-si:td:td1|Lecture et Analyse de document]] : Phase A
+   - [[2010_2011:s1:omgl:mod-si:td:td2|Extraction des uses cases ]] : Phase A
+   - [[2010_2011:s1:omgl:mod-si:td:td3|Retour sur le cahier des charges et formalisation des rendus ]] : Phase A
+   - [[2010_2011:s1:omgl:mod-si:td:td4|Inspections ]] : Phase B
+   - [[2010_2011:s1:omgl:mod-si:td:td5|Confrontations ]] : Phase B
+   - [[2010_2011:s1:omgl:mod-si:td:td6|Livraisons ]] : Phase C
-===== Rendus =====
-Tous les rendus se feront par binôme.
-- Les rendus du cahier des charge seront rédigés dans le format électronique qui vous convient.
-- Les diagrammes de cas d'utilisation seront rendus dans un document à part. Il comprendra un minimum de **YY** cas d'utilisation détaillés.
-Format Papier ?
-Le planning de tous les rendus est visible sur la [[2010_2011:s1:omgl:mod-si:start#planification-notations|page du module]].
+===== Rendus =====
+Tous les rendus se feront par binôme.
+  - Les rendus du cahier des charge seront rédigés dans le format électronique qui vous convient.
+  - Les diagrammes de cas d'utilisation seront rendus dans un document à part.
-Pour les étudiants près à tenter une approche collaborative nous leur proposons d'utiliser l'outil googleDoc qui leur permettra de travailler à plusieurs sur un même document.
+!- Il comprendra un minimum de **YY** cas d'utilisation détaillés. -!
-===== 1) Lecture et Analyse de document =====
-  - Composer les binômes. Chaque binôme envoie par mail le jour même à son enseignant les noms et prénoms des protagonistes.
-  - A la fin de cette séance vous devrez avoir dégagé une première base de vocabulaire, avoir identifié les parties prenantes du projet, appréhendé les principales contraintes et certainement envisagés quelques fonctionnalités.
-[[2010_2011:s1:omgl:mod-si:td:PlanType|Plan type du cahier des charges]]
-<box round rgb(185,211,238) rgb(198,226,255) 75%|A rendre>
- - La constitution des binômes précisant le rôle de chacun envoyée par mail à votre responsable de TP en mettant Mme Blay-Fornarino en copie.
-</box>
-===== 2)  Extraction des uses cases   =====
-Pendant cette séance nous utiliserons l'outil "Visual Paradigm" qui vous permet de créer des diagrammes de use case.
-En vous basant sur le cours, suivez le procédé proposé pour identifier les acteurs, les principaux UC.
-Après avoir décidé de ceux qui vous semblaient les plus critiques //(Tous les groupes ne font pas forcément les mêmes choix, cela dépend des clients qui veulent mettre l'accent sur certains points en les justifiant ((on n'oublie pas le cahier des charges)))//, détaillez les.
-Voici un tutoriel d'utilisation de cet outil,  mais est-il vraiment nécessaire?
-{{:2010_2011:s1:omgl:mod-si:td:esquisse-de-use-case.swf|}}
-===== 3)  Retour sur le cahier des charges et formalisation des rendus  =====
-Pendant cette séance vous ciblez la livraison de votre cahier des charges et des use-case associés.
-Vous devrez les rendre le dimanche soir.
-<box round rgb(185,211,238) rgb(198,226,255) 75%|A rendre>
- - Dimanche soir, 24h dernier délai, vous devrez avoir envoyé par mail à votre responsable de TP votre cahier des charges et uses-cases (format textuel uniquement).
-</box>
-===== 4)  Inspections  =====
-Nous nous plaçons à cette étape dans un premier échange du CdCF.
-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 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.
-==== Fiche d'inspection ====
-Chacun des points abordés pendant cette inspection sera présenté dans la fiche en précisant :
-  - sa référence dans le document à relire (n. de pages, paragraphe, ...);
-  - (facultatif) la référence correspondante dans le document d'origine;
-  - valide ou non
-  - (facultatif) une description 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).
-      * Exemples :
-         * Oubli d'une fonction importante : erreur grave à corriger avant de
-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
-==== Déroulement de l'inspection ====
-<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.
-Ce n'est pas la qualité du cahier des charges qui sera évalué mais votre pertinence dans l'analyse.
+Le planning de tous les rendus est visible sur la [[2010_2011:s1:omgl:mod-si:start#planification-notations|page du module]] et au niveau de chacun des énoncés.
-Vos fiches seront évidemment remises à l'autre groupe (comme dans la vraie vie, on doit aussi savoir dire les choses...).
-</box>
+===== Outils =====
+   * Pour les étudiants près à tenter une approche collaborative nous leur proposons d'utiliser l'outil googleDoc qui leur permettra de travailler à plusieurs sur un même document.
-===== 5)  Confrontations  =====
+   * Pour les cas d'utilisation vous utiliserez l'outil Visual Paradigm
-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.