User Tools

Site Tools


2010_2011:s3d:omgl:mod-si:tp: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:s3d:omgl:mod-si:tp:start [2011/03/03 12:26]
blay
2010_2011:s3d:omgl:mod-si:tp:start [2011/05/26 10:49] (current)
blay
Line 1: Line 1:
 +
 ====== Informatisation globale du café ====== ====== Informatisation globale du café ======
  
 Le café est à présent équipé de tables tactiles. 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. ​ Nous construisons plusieurs systèmes pour exploiter ces tables au travers de différents services rendus. ​
Line 9: Line 12:
 Pour des raisons de temps, nous les développerons tous séparément. Néanmoins, il vous est demandé en utilisant une décomposition en package d'​expliciter comment vous envisageriez de vos connecter à d'​autres systèmes. Pour des raisons de temps, nous les développerons tous séparément. Néanmoins, il vous est demandé en utilisant une décomposition en package d'​expliciter comment vous envisageriez de vos connecter à d'​autres systèmes.
  
 +
 +===== Objectifs =====
 +
 +Chaque binôme choisit une des //​fonctionnalités//​ [[2010_2011:​s3d:​omgl:​mod-si:​tp:​start|ci-dessous]]. ​
 +Il doit alors mener la construction de cette fonctionnalité de l'​analyse à la mise en oeuvre en passant par la conception, la construction d'une BD, la mise en place d'une IHM, quelques bribes du serveur pour démontrer la cohérence de l'​ensemble et l'​explicitation des tests réalisés.
 +
 +Les séances ne sont pas balisées au sens où vous vous organisez comme bon vous semble en fonction des livrables demandés et des jalons qui ont été posés. ​
 +Nous ne voulons jamais entendre : <​del>"​qu'​est-ce qu'il faut faire?"</​del>​\\
 +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 88: Line 182:
  
 !-===== Paris en ligne ===== -! !-===== 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.
 +
 +
  
2010_2011/s3d/omgl/mod-si/tp/start.1299151618.txt.gz · Last modified: 2011/03/03 12:26 by blay