## Application Web pour gérer les portes monnaies virtuels =
Un porte monnaie contiendra un certain nombre de "monnaies virtuelles" de différents devises. Lorsque l'on met côte à côte dans le porte monnaie différentes devises suivant la version les monnaies fusionnent ou alors gardent leur identité.
Nous ne travaillerons pas avec de sous-divisions (cents, centimes), lors des opérations on fera toujours un arrondi en la défaveur du porte monnaie.
Le porte monnaie sera décliné en plusieurs versions :
- mon **1er porte monnaie** ne contenant qu' **un type de devise** (des EURs) - les **opérations** sont **mono-devises**.
- mon **2eme porte monnaie** contient **un nombre prédéfini de devises** (des EURs, des CHFs ou tout autre devise de votre choix) - les **opérations** restent **mono-devises**
- Lorsque l'on ajoute une devise absente auparavant dans le porte monnaie elle est gardée à part.
- mon **3eme porte monnaie** peut s'enrichir des devises au fur et à mesure - les **opérations** sont **multi-devises**.
- On peut demander de transformer une partie de vos devises vers un autre type suivant le taux de change : convertir une partie de CHF vers les EUR (on tolère le fait de saisir à chaque fois manuellement le taux de change... mais bon)
- Vous pouvez également payer directement un montant exprimé dans une devise avec un devise différente. Le reste est dû dans la devise du montant à payer.
- mon **4eme porte monnaie** s'adresse aux "très riches" pour lesquels une représentation Long n'est pas suffisante. N'hésitez pas d'utiliser des librairies disponibles sur le Web.
Les opérations à implémenter selon les versions sont :
- ajout de pièces/billets au porte monnaie
- paiement en divers devises : retrait de pièces du porte monnaie (selon la devise)
- échanger devises
- définir/modifier les taux de change
- ...
Le porte monnaie doit générer des exceptions lorsque les opérations ne sont pas supportés par la version courante (opérations multi-devises en itération 1 et 2), ou lorsqu'un dépassement quelconque est observé (découvert par exemple, ou impossibilité de représenter les montants totaux du porte-monnaie).
Proposez **une interface Web, de préférence mono-page et minimaliste**, permettant de réaliser les opérations retenues pour chaque itération toute en présentant **l'état de l'opération précédente**, ainsi qu' **une situation à jour du porte-monnaie** après chaque opération.
Bien que l'ensemble des opérations peut être fait en JS, je vous prie de séparer entre la partie serveur (mis à jour du porte-monnaie) et la partie client (afficher l'état du porte-monnaie et des opérations). Néanmoins, ne vous gênez pas d'utiliser AJAX.
Essayer d'uniformiser les versions de la page Web entre les itérations, afin de réutiliser autant que possible les scripts Selenium.
## Organisation
### Configuration forge
* a) Mettez en place une forge
- Redmine (créez un sous-projet de 13-odeva-fa)
- Trac sur forge.fil.univ-lille1.fr -> m'indiquer dans un mail le nom du groupe
- code.google.com : svn+git+hg / issues + milestones / wiki
* b) prenez le temps de la personnaliser si possible, par exemple, les types de tickets souhaités (tâche de développements, tâche de tests client/serveur/intégration) n'existent pas
- dans le cas où la forge choisie ne comporte pas ce type de fonctionnalités, adoptez une convention de nommage pour les tickets afin de pouvoir se retrouver facilement
* c) créez autant de composantes/catégories que vous jugez nécessaires pour couvrir
- les tests unitaires serveur
- les tests unitaires client (JS)
- les tests d'intégration Selenium
- les tâches de développements client
- les tâches de développements serveur
* d) créez les versions en décrivant pour chacune les grands objectifs
- vous détaillerez sur le wiki
- les rôles de chaque membre de l'équipe pour l'itération courante
- les fonctionnalités spécifiques attendues de chaque version
### SCV
* e) adoptez un SCV de votre choix
- organisation et protocole de communication (définis sur le Wiki)
- structuration : séparer src/tests
- intégré à la forge
### Tâches
* f) créez des tâches de développement/tests au niveau de chaque itération/sprint et pas avant... (c'est à la charge du chef de l'itération)
- pour assurer la synchronisation avec vos collègues
- pour avoir une idée de l'ordonnancement
- pour planifier sur des courtes durées l'activité des personnes
- indiquer si pour cette tâche les tests unitaires sont à réaliser avant le partage du code ou par la suite par un autre développeur
* g) cycle de vie d'un ticket
- lorsqu'une tâche de développement est réalisée, pensez à fermer le ticket afin que ceux qui réaliseront les tests d'intégration ou autres tâches dépendantes en soient informé
- lorsque pendant la réalisation d'une tâche de test des bugs sont identifiés, l'information doit être remontée en re-ouvrant par exemple la tâche d'implémentation en amont, ou alors créer un nouveau ticket
- une tâche de test on la considère close une fois que les tests ont été implémentés et lancés, indépendamment du résultat. On procédera éventuellement à la re-ouverture de la tâche, ou de la création d'une nouvelle pour re-tester le nouveau code.
### Tests
* h) Vous écrirez les tests dans trois contextes différents :
- des tests unitaires **in situ** seront écrits par le développeur/testeur avant de faire les commits du son code source.
- chaque commit src sera accompagné d'un commit test
- des tests unitaires **a posteriori** seront écrits par une autre personne que le développeur après que le développeur ait envoyé son code
- à distinguer entre un envoi qui se fera sur la branche principale, et un éventuel envoi qui se fera soit sur un branche dédiée (en SVN), soit de pair à pair (en GIT/HG)
- des tests unitaire **a priori**, seront écrits par une personne autre que le développeur avant l'implémentation effective du code. Le code écrit devra se conformer.
* i) Vos tests unitaires essayeront de couvrir au mieux l'ensemble du code produit (autant côté serveur que côté client).
### Fin d'itération / sprint
* j) simulez une mise en production après chaque itération au moyen de Selenium
- automatisez quelques scénarios types permettant de montrer le bon fonctionnement de l'application
- ajoutez les scripts ainsi produits au SVC
* k) créer un tag (à partager ensuite avec l'ensemble de développeurs) de l'itération qui vient de se finir
## Rendu par mail
- Identifiants pour accéder à la forge + SCV
- Tout est sur le wiki et la forge et tout est dans l'historique du SCV
- choix de la forge et du SCV - justifiez
- fonctionnalités implémentées
- rôles des membres au niveau de chaque itération (qui a fait quoi? qui a eu quel rôle?)
- architecture globale
- tickets
- Gantt par itération (avant/après) - si modifications entre les deux les expliquer
