====== Livrable 1.1 : Analyse de l'étude de cas ====== Le document est à livrer sous [[http://jalon.unice.fr/cours/blay/Cours-blay-20150827001314/BoiteDepot-blay-20150827001433355111/cours_boite_view?menu=depots|jalon]] en respectant pour le nom du document : **NomRespTD_NumeroGroupe_NomsDesEtudiants** Si vous ne respectez pas la consigne, nous ne corrigerons pas. Pour NomRespTD mettre MBF pour M. Blay-Fornarino; NF pour N. Feneon; MAP pour M. Peraldi **Artefacts de livraison** :\\ - Un **//document//** contenant : - 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, - 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, - 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, - 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 [[http://en.wikipedia.org/wiki/FURPS. |classement FURPS]], nous reviendrons dans le cours plus tard sur ce point. - 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; - 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 - La première page du document doit "évidemment" - donner le cas d'étude (et pas Analyse du cas d'étude mais Analyse pour la gestion des membres par exemple) - préciser votre formation - Le glossaire - 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?) - "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! - 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. - 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. ===== Le chef de projet pour les S3T ===== Il peut se faire aider par ses camarades. A priori un chef de projet bien noté est un groupe dans lequel les équipes fonctionnent bien. **Artefacts de livraison** :\\ - Un **//document//** contenant : - 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); - 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, - 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, - 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, - 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 [[http://en.wikipedia.org/wiki/FURPS|classement FURPS]], nous reviendrons dans le cours plus tard sur ce point. - 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. /* - 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; */ - 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//.