Differences

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

--- 2010_2011:s1:omgl:mod-si:td:start [2010/08/26 16:22] – 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 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 15: / Line 16: @@
 </note>
-===== Rendus =====
+**//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.\\
+Par exemple : \\
+- //B1// : Pierre représente un client & Marie représente une entreprise d'informatique.\\
+- //B2// : Roméo représente un client & Julierre représente une entreprise d'informatique.\\
-Tous les rendus se feront par binôme.
+**//Phase B ://** Les cahiers des charges sont distribués au hasard à un autre groupe. Le client devient le fournisseur et le fournisseur le client. La revue d'inspection doit faire état des problèmes vus par le client et par le fournisseur.\\
-- Les rendus du cahier des charge seront rédigés dans le format électronique qui vous convient.
+Par exemple : \\
-- Les diagrammes de cas d'utilisation seront rendus dans un document à part. Il comprendra un minimum de **YY** cas d'utilisation détaillés.
+- //B1 analyse le document de B2, mais : // : Pierre représente une entreprise d'informatique et Marie représente le client.\\
+- //Le document de B1 pourra être analysé par B3 etc.//
-Format Papier ?
+**//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.\\
-Le planning de tous les rendus est visible sur la [[2010_2011:s1:omgl:mod-si:start#planification-notations|page du module]].
+   - [[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
-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.
-===== 1) Lecture et Analyse de document =====
+===== Rendus =====
-  - Composer les binômes. Chaque binôme envoie par mail le jour même à son enseignant les noms et prénoms des protagonistes.
+Tous les rendus se feront par binôme.
-  - 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.
+  - 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.
-[[2010_2011:s1:omgl:mod-si:td:PlanType|Plan type du cahier des charges]]
-===== 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.
-Voici un tutoriel d'utilisation de cet outil.
-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.
-===== 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.
-===== 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 ====
-Pendant cette séance,
+!- Il comprendra un minimum de **YY** cas d'utilisation détaillés. -!
-<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.