+
+ |
+
+ Cette étude de cas donne lieu à une évaluation. Appliquez-vous! |
+
1. Contexte
+1.1. Organisation
+Ce projet Agile d’ACSI est prévu pour durer 4 semaines, à raison de 3h par semaine +de séances en TD avec machines.
Le déroulement des 4 semaines est approximativement le suivant :
+1.2. Environnement logiciel
+-
+
- +Identification + +
-
+
+Vous pouvez en profiter pour changer de groupe par rapport au 1er projet. +
+
+ - +Gestion de projet + +
-
+
+Chaque groupe continuera à utiliser le gestionnaire de projet Redmine : http://algec.iut-blagnac.fr/redmine/. +De nouveaux projets vous seront affectés au 1er TD de la semaine 50. +Dans ces nouveaux projets, le plug-in "Scrum" sera activé pour vous permettre de mettre en oeuvre +les principes ailes vus en cours avec M. Inglebert. +
+
+ - +Gestion de version + +
-
+
+Chaque groupe est libre d’utiliser un dépôt qui lui est propre, mais il devra +être accessible par l’enseignant. Pour ceux qui n’ont pas de dépôt l’enseignant +vous en fournira un. En faire la demande via Redmine. Vous pouvez utiliser le même +dépôt que le 1er projet mais en ayant un répertoire différent. +
+
+ - +Outils de modélisation + +
-
+
+Les outils de modélisation sont libres, mais devront être utilisés (plantuml, starUML, etc.). +Pour chaque étape demandées il vous faudra remettre vos diagrammes en respectant une nomenclature +bien précise. +
+
+
|
+
+ |
+
+ Le respect de la nomenclature des fichiers à remettre est indispensable. Faites des tests et +vérifiez. Ces fichiers seront récupérés par des scripts… |
+
1.3. Divers
+Quelques règles et informations concernant le sujet :
-
+
-
+
+Chaque groupe de TD de 2ème année traite un sujet différent. +
+
+ -
+
+Dans un même groupe, vous pouvez vous aider entre équipes! +
+
+ -
+
+Les commentaires sur vos modèles intermédiaires seront donnés à chaque groupe au fur et à mesure. +
+
+
2. Exposé du CCU pour le projet du Groupe3
+Vous devez réaliser un logiciel pour le client John Doe, appelé CURLING (Check if my URL LINks are Good).
+
+
2.1. Objectifs et contexte
+John Doe écrit de nombreux documents et supports de cours qui incluent des références à des documents +web (URLs). Il n’a pas le temps de vérifier systématiquement si ces URLs sont toujours valides (si le +document web est toujours accessible). Ils vous embauche pour lui réaliser une moulinette qui réalise +cette vérification pour lui.
2.2. Besoins élémentaires
+A minima, l’application demandera à John Doe le nom d’un fichier (texte) et fournit en retour +la liste des URLs défectueuses. John Doe a découvert dans une revue le paradigme MVC et vous demande +de l’appliquer.
Dans l’idéal, l’application maintiendra une liste de documents avec des informations du type : dernière +fois que le fichier a été vérifié, type (e.g., .html, .txt, .docx.), nome (e.g., /Users/JohnDoe/docs/test.txt).
2.3. Besoins optionnels
+On pourra imaginer qu’au lieu de fournir un nom de fichier, John Doe fournit un répertoire +(et que l’application CURLING vérifie toutes les URLs de tous les fichiers texte de ce répertoire).
On pourra aussi imaginer que John Doe puisse sélectionner un fichier, ou un type de fichier dans une liste +de documents (déjà checkés par exemple).
2.4. Exemples et cas de test
+Voici un exemple de fichier que John Doe veut pouvoir vérifier: definition.txt.
2.5. Glossaire
+-
+
- +MVC + +
-
+
+ Model View Controler +
+
+ - +URL + +
-
+
+ Universal Ressource Locator +
+
+
3. Planning
+Le principe du projet ACSI est que vous ne devriez pas à avoir à travailler (trop) en plus +des 2 séances de TD hebdomadaires. +Vous allez travailler par groupe de 3 ou 4.
+
+ |
+
+ Dans cette version "Agile" du projet, "déposer" régulièrement vos productions +est obligatoire car intégré à la démarche itérative. |
+
Calendrier prévisionnel des "sprints"
-
+
-
+
+Semaine 50 (9 au 13 décembre 2013) - Sprint 0 +
++-
+
-
+
+Choix de l’infrastructure finale (langage de programmation, bases, etc.) +
+
+ -
+
+Analyse des besoins du client (backlog de produit) +
+
+ -
+
+Découpage en tâches des premières stories +
+
+ -
+
+Appropriation du plug-in Scrum de Redmine +
+
+ -
+
+Validation par le product owner (le client, votre prof bien aimé) +
+
+
+ -
+
-
+
+Semaine 51 (16 au 20 décembre 2013) - Sprint 1 +
++-
+
-
+
+Choix des fonctionnalités à traiter dans le sprint +
+
+ -
+
+Découpage en tâches et affectation aux membres du groupe +
+
+ -
+
+Réalisation des tâches (test, code, et documentation) +
+
+ -
+
+Bilan avec le client (montrer l’appli au client + rétrospective équipe) +
+
+
+ -
+
|
+
+ |
+
+ Ce sprint important sera en "séances libres", votre client bien aimé étant absent +toute la semaine. Bilan client vendredi. |
+
-
+
-
+
+Semaine 2 (6 au 10 janvier 2014) - Sprint 2 (étapes idem) +
+
+ -
+
+Semaine 3 (13 au 17 janvier 2014) - Sprint 3 (étapes idem) +
+
+ -
+
+Fin de la 2ème séance de TD de la semaine 3 (13 au 17 janvier 2014) : +
++-
+
-
+
+Démo de l’application au client +
+
+ -
+
+Code java/ruby documenté (commentaires styles javadoc/rdoc) sur votre dépot +
+
+ -
+
+Captures d'écran réelles (dans les documents redmine) +
+
+ -
+
+Rapport = Wiki de votre projet (redmine) +
+
+
+ -
+
4. Dossier final à remettre
+Seul le Wiki servira de "dossier final". L’ensemble des activités +(sprint, tâches, etc.) tracées dans Redmine fera aussi partie du +"dossier". Vous n’avez rien à rédiger de particulier sur ces aspects +de gestion de projet, mais vous avez à sérieusement renseigner chaque activité +de chaque membre à chaque TD.
5. Evaluation et critères
+L'évaluation portera principalement sur les critères suivants :
| Critère | +Type de critère | +Poids approximatif | +
|---|---|---|
WiKi |
+Clarté, pertinence |
+10% |
+
Respect des sprints et principes agiles |
+Correction, pertinence |
+20% |
+
Diagramme des UC |
+Correction, pertinence |
+5% |
+
Diagramme des Classes Métier |
+Correction, pertinence |
+5% |
+
SNI |
+Correction, pertinence |
+10% |
+
Diagramme de Séquence Système (2 UC au moins) |
+Correction, pertinence |
+5% |
+
Diagramme de Séquence « normal » (au moins 1 UC) |
+Correction, pertinence |
+10% |
+
Cohérence inter-modèles (SNI/UC/DC, UC/DSS/DS/DCP) |
+Correction, pertinence |
+5% |
+
Respect des nomenclatures, dépots SVN, Wiki, etc~ |
+Correction, pertinence |
+10% |
+
Code exécutable, documentation et tests |
+Correction, documentation |
+20% |
+
|
+
+ |
+
+ Vous pouvez insérer une section "auto-évaluation" dans votre rapport, qui reprend cette grille et +vous permet de vous auto-évaluer. |
+
6. Annexes
+6.1. Acronymes
+-
+
- +DC + +
-
+
+Diagramme de Classe +
+
+ - +DS + +
-
+
+Diagramme de Séquence +
+
+ - +DSS + +
-
+
+Diagramme de Séquence Système +
+
+ - +MVC + +
-
+
+Model View Controler +
+
+ - +SNI + +
-
+
+Schéma de Navigation d'Interface +
+
+ - +UC + +
-
+
+Diagramme des Cas Utilisateurs +
+
+
Pour l’instant ce document est libre d’utilisation et géré par la Licence Creative Commons.
+
+
+
+
+
+licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.