User Tools

Site Tools


2010_2011:s1:omgl:mod-si:td:start

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
2010_2011:s1:omgl:mod-si:td:start [2010/08/26 19:10]
blay
2010_2011:s1:omgl:mod-si:td:start [2011/02/15 18:52] (current)
blay
Line 33: Line 33:
    - [[2010_2011:​s1:​omgl:​mod-si:​td:​td4|Inspections ]] : Phase B    - [[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:​td5|Confrontations ]] : Phase B
-   - [[2010_2011:​s1:​omgl:​mod-si:​td:​td5|Livraisons ]] : Phase C+   - [[2010_2011:​s1:​omgl:​mod-si:​td:​td6|Livraisons ]] : Phase C
  
  
Line 42: Line 42:
 Tous les rendus se feront par binôme. 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 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.+  - 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]] et au niveau de chacun des énoncés. 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.
Line 54: Line 55:
    * Pour les cas d'​utilisation vous utiliserez l'​outil Visual Paradigm    * Pour les cas d'​utilisation vous utiliserez l'​outil Visual Paradigm
  
-===== 1) Lecture et Analyse de document ===== 
- 
- 
- 
-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]]. 
- 
-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]]. 
- 
- 
- 
-  - 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. 
- 
- 
-Vos fiches seront évidemment remises à l'​autre groupe (comme dans la vraie vie, on doit aussi savoir dire les choses...). 
-</​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. 
  
  
2010_2011/s1/omgl/mod-si/td/start.1282842642.txt.gz · Last modified: 2010/08/26 19:10 by blay