Differences

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

--- 2010_2011:s3d:omgl:mod-si:tp:start [2011/03/29 12:26] – blay
+++ 2010_2011:s3d:omgl:mod-si:tp:start [2011/05/26 08:49] (current) – blay
@@ Line 1: / Line 1: @@
 ====== Informatisation globale du café ======
 Le café est à présent équipé de tables tactiles.
+//Dans le cadre de cet enseignement, vous construirez la partie interface graphique sur les tables avec les outils que vous voulez, donc sans tenir compte des interactions particulières possibles sur ce type de table. //
 Nous construisons plusieurs systèmes pour exploiter ces tables au travers de différents services rendus.
@@ Line 19: / Line 22: @@
 Utilisez les jalons pour enchaîner les tâches!
+===== Rendus Attendus =====
+Les **rendus sont échelonnés**.
+  * Vous pourrez modifier les rendus intermédiaires (livrables) pour les améliorer.
+  * Par contre le planning prévisionnel, donné avec la première version du cahier des charges, n'est évidemment pas modifiable.
+  * Les fonctionnalités proposées dans le cahier des charges peuvent évoluer (être précisée) mais pas disparaître. \\
+Les **jalons** correspondent à des **dates limites non modifiables**.
+  * Les jalons sont posés en nombre de semaines de cours. Pour vous aider des dates ont été ajoutées.\\
+  * Vous pouvez vous organiser comme bon vous semble tant que vous respectez les délais.
+  * Par contre, vous devez préciser exactement la manière dont vous avez travaillé dans votre planning réel.\\
+==== Planification des livrables ====
+<note important>Plusieurs livrables peuvent être demandés à une même date </note>
+[[https://www.google.com/calendar/embed?src=65qv95uo3cgn203iuqdk8qa85k%40group.calendar.google.com&ctz=Europe/Paris |Planning ici...]]
+   - Rédaction d'un **//cahier des charges fonctionnel// limité à la partie Description Fonctionnelle (relation au profil de vie exclue mais en mettant en avant les limites** (voir plan [[omgl:acsi:plantype|ici]]).
+      * Ce cahier des charges sera élaboré en interrogeant éventuellement des représentants des parties prenantes extérieures au groupe. Elles seront référencées dans le document final. Une d'entre elles pourra être invitée à la démonstration finale.
+      * L'accent devra être mis sur les exigences fonctionnelles et non fonctionnelles.
+      * Ce document est susceptible d'évoluer au fil de l'analyse modulo les restrictions données ci-dessus
+      * //jalon +/-2sem : **11/04/11**//
+   - Validation de votre cahier des charges par votre encadreur //(jalon + 2,5sem)//
+   - Production des **//cas d'utilisation, diagrammes d'activité,  scenarii de niveau analyse, modèle du domaine (diagramme de classes)//**
+      * //jalon +4sem : **16/05/11**//
+      * //**Attention** ce livrable sera noté.// Les critères sont entre autres:
+            *  la spécification détaillée des cas d'utilisation (brève description, flots, priorité)
+            * des scenarii de haut niveau mais propres et cohérents. En particulier, la direction des flots à de l'importance.
+   - Évolution des diagrammes pour un passage en conception : **//scenarii clefs détaillés, diagrammes de classes comprenant les classes systèmes, modèle de données persistantes//**
+      * // jalon +6sm :  **30/05/11**//
+      * [[http://anubis.polytech.unice.fr/iut/2010_2011/s3/omgl/mod-si/tp/elements-d-architecture|Éléments d'architecture]]
+   - **//Explication des choix technologiques//**
+      * Vous pouvez faire des choix pour une version en "production" et justifier d'autres choix dans le cadre du projet
+      * // jalon +6sm : ****30/05/11****//
+   - Codes dont //(jalon +9sem)//((Attention, le jalon correspond au rendu final, vous ne pourrez pas tout faire en une semaine!!)):
+       * **//Maquette pour les interfaces graphiques//** : diffusion (prototype : html & css) & administration (au choix, une maquette simple éventuellement non connectée (applet, servlet, autres...))
+       * **//Schéma de bases de données//**, la cohérence de vos schémas en fonction des traitements prévus sera démontrée
+       * Code d'implémentation de certains **//éléments du serveur//**
+       * Mise en place de **//tests unitaires//** (et, pour les plus avancés, d'intégration ( optionnel))
+       * // jalon +9sm : Le rendu des codes et des tests réalisés se fera avec le rendu final. Ils doivent néanmoins être opérationnels pour la démonstration. //
+   - <del>**//Démonstration//** des différents points du projet : nous pourrons inviter des parties prenantes à cette démonstration
+       * // jalon +9sm : **9/6/11** //</del>
+   - **//Livraison de l'ensemble//** : Vous pouvez revenir sur tous les rendus intermédiaires pour les rendre cohérents avec le résultat final.
+En résumé :
+       *   Le cahier des charges comprenant aussi :
+           * le planning réel de votre projet dans la partie //suivi// du cahier des charges
+           * un bilan des retours d'évaluation utilisateurs.
+           * les choix technologiques
+       *  Les diagrammes UML
+       *  Le code y compris un README
+       *  <del>Optionnellement,</del> un film de la démonstration
+       * // jalon +10sm : <del>**14/6/11**</del> **20/6/11**//
+<note>Le 9/6/11 : Chaque groupe aura 15mn de présentation de sa démonstration suivie de 10mn de questions par les personnes présentes.
+Vous devrez mettre en avant dans votre démonstration :
+   * le fonctionnement de votre proposition (même partiel) ((quelles sont les principaux éléments de votre système visibles par les utilisateurs finaux: comment sont saisies/gérées les informations; quelles informations sont diffusées?; Quelle gestion de la BD? ...))
+   * l'architecture proposée
+   * les retours utilisateurs que vous avez eu (bon ou mauvais) ((ce qu'ont pensé les personnes qui ont testé votre site)).
+Voici des critères que nous utiliserons pour la notation a priori mais ils peuvent encore varier : Qualité de la démonstration; Fonctionnement global; Architecture; Retours Utilisateurs; qualité de l’exposé
+Vous n'êtes pas obligé d'avoir un support sous la forme de slides étant donnée la durée très courte de l'exposé.
+Les groupes souhaitant inviter une partie prenante à assister à la démonstration devront également nous prévenir.
+Des notations croisées des camarades seront proposées.
+</note>
+<box round rgb(185,211,238) rgb(198,226,255) 95%|Format des rendus>
+  * Le sujet du mail sera :
+       * [IUT]-S3D- : //<noms des membres>// : //<Objet du rendu>//
+       * Il sera //adressé à// votre responsable de TP
+       * Tous les documents sont demandés pour un mardi 9h au plus tard.
+       * Le format de chaque rendu sera précisé au fur et à mesure.
+       * Tout manquement à un des points précédents empêchera l'évaluation du rendu.
+</box>
 ====== Fonctionnalités ======
@@ Line 100: / Line 182: @@
 !-===== Paris en ligne ===== -!
+====== Eléments de Notation ======
+Ces élements sont donnés à titre informatif mais ne sont pas contractuels et peuvent évoluer.
+    * Cahier des charges et rendu **(7)**
+Dictionnaire, organisation du rendu, Presence d’un readme, Fonctionnalités, Respect de la Norme, Complétude, 	Planning Prev & reel,
+Choix technologiques, 	Retours Utilisateur, video
+    * Diagrammes UML **(11)**
+          * Use case : 2,5 (context, System, description)
+          * Scenarii : 2,5 (Scenario  : prise en compte des erreurs ; Scenario en conception : architectures, retour utilisateur, ...)
+          * Diagr activités : 1 enchainement de use cases
+          * Diagramme de classes : 4 (Justesse, complétude (cardinalité, nom des associations, ...); positionnement des méthodes ; classes système; prise en compte de la persistence, package,
+    * Code relativement aux modèles **(4)**
+          * gestion de la persistence (cohérence)
+          * code décomposition
+          * style, codage, ect.