Warning

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 :

graphviz/agile.dot.png
Figure 1. Déroulement du projet agile sur 4 semaines

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.

Warning

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).

images/curling.png

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.

Tip

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)

Warning

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 :

Table 1. Critères
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%
Tip

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 licence Creative Commons Paternité - Partage à l'Identique 3.0 non transposé.