Artefacts de livraison par sous-équipe :

1. Un document contenant :
   1. le thème de la pièce scenario @todo 1 à 2 pages maximum
   2. les technologies utilisées (réduites à cette partie du projet) : vous expliquez votre choix e.g. facilité, intégration, apprentissage, etc.

- un glossaire * Evaluation en fonction de la pertinence et de la complétude des termes explicités (et pas le nombre); - les cas d'utilisation (il doit y en avoir peu, c'est les grandes lignes, en particulier ne pas hésiter à limiter l'étude à certains grands cas d'utilisation en explicitant que les autres, bien que utiles, ne seront pas traités) * Evaluation en fonction de la pertinence, de la complétude et de la justesse des notations : les erreurs de notation induisent des points négatifs,

1. Un ou des diagrammes de classes de niveau analyse,
   • Evaluation en fonction de la pertinence, de la complétude et de la justesse des notations : les erreurs de notation induisent des points négatifs,
2. Facultatif : des diagrammes de séquence
   • Evaluation en fonction de la pertinence, de la complétude et de la justesse des notations : les erreurs de notation induisent des points négatifs,
3. les propriétés qu'il vous semble essentiel de traiter telles que : sécurité, persistance, robustesse, en expliquant pourquoi. Vous pouvez vous appuyer sur le classement FURPS, nous reviendrons dans le cours plus tard sur ce point.
4. un Kanban contenant les US détaillées du premier sprint, celles auxquelles votre équipe pense pour le 2nd Sprint (intégration) moins détaillées;

• pour chaque US nous avons :
  • sa valeur métier attribuée par le PO (cf. sujet), éventuellement modifiée et validée par le responsable de TD
  • sa valeur du point de vue développement (Story Points) élaborée par le groupe qui peut différée de celle donnée par le sujet;

1. un répertoire de projet dans la forge bien organisé avec tous les documents demandés. Si pour l'instant, vous n'avez pas encore utilisé le dépôt GIT, placez vos documents sous Documents.

Date de livraison :

• S3T : 30 septembre 23h59
• S3A : x octobre 23h59

Quelques erreurs relevées dans les rendus

1. La première page du document doit “évidemment”
   1. donner le cas d'étude (et pas Analyse du cas d'étude mais Analyse pour la gestion des membres par exemple)
   2. préciser votre formation
2. Le glossaire
   1. Ne racontez pas votre vie ou celle de vos acteurs (par exemple, il choisit les “gros mots” en parlant avec ces collègues… bah… vous êtes sûrs?… Ca apporte quelle information intéressante?)
3. “Nous essayerons de respecter les dates de livraison prévues. ” NON NON … Même pas la peine de le dire, vous les respecterez c'est tout!
4. La valeur métier d'une US ne s'estime pas en heure ! C'est une valeur relative qui exprime “la valeur que lui accorde le métier” une tâche très rapide à réaliser peut avoir une très forte valeur métier, et inversement… Ces valeurs vous ont été données dans l'étude de cas sous la forme de ++, + ou ==. Vous avez peut-être ajouté des histoires, ou vous en avez modifié. Pour ces histoires “nouvelles” vous devez voir avec votre encadreur leur valeur métier.
5. Une tâche “développement” n'est pas vraiment informative… On s'attendait davantage à des tâches plus précises liées aux US, par exemple, construction des composants graphiques, intégration de le lecture de fichiers, etc.

Il peut se faire aider par ses camarades.

Artefacts de livraison :

1. Un document contenant :
   1. La vision globale du projet : 1 page max
   2. L'organisation globale du projet : comment l'équipe s'organise, 1 page max
   3. Synthèse des choix technologiques : 1 page max
   4. un glossaire
      • Uniquement pour les termes qui seraient propres à une vision globale; Il peut aussi choisir de le partager avec l'ensemble du groupe qui dans ce cas peut contribuer à sa construction et y faire simplement référence dans son propre rendu;
        • Evaluation en fonction de la pertinence et de la complétude des termes explicités (et pas le nombre);
   5. Les grands cas d'utilisation et surtout pas les vues détaillées de chacune des équipes.
      • Il doit donner une vision globale du projet.
      • L'utilisation de “extends” ou “include” peut permettre d'aborder la question difficile de l'intégration.
        • Evaluation en fonction de la pertinence, de la complétude et de la justesse des notations : les erreurs de notation induisent des points négatifs,
   6. Un ou des diagrammes de classes de niveau analyse,
      • Il s'agit essentiellement de représenter les classes qui seront probablement partagées par tous; Il ne les détaille pas à moins que le groupe ou le sujet ne les ai fixées.
        • Evaluation en fonction de la pertinence, de la complétude et de la justesse des notations : les erreurs de notation induisent des points négatifs,
   7. Facultatif : des diagrammes de séquence pour représenter quelques exemples identifiés d'interactions entre les projets.
      • Evaluation en fonction de la pertinence, de la complétude et de la justesse des notations : les erreurs de notation induisent des points négatifs,
   8. les propriétés qu'il vous semble essentiel de traiter telles que : sécurité, persistance, robustesse, en expliquant pourquoi. Vous pouvez vous appuyer sur le classement FURPS, nous reviendrons dans le cours plus tard sur ce point.
   9. une explication sur sa vision du projet et la manière de travailler, un retour critique sur le kanban des équipes en soulignant les points forts et faibles.
2. un répertoire de projet dans la forge bien organisé avec tous les documents demandés. Si pour l'instant, vous n'avez pas encore utilisé le dépôt GIT, placez vos documents sous Documents.