|
|
## 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
|
|
|
- www.assembla.com (30 jours) : trac + svn or git
|
|
|
- bitbucket.org (-> 5 users) : hg + git / issues / wiki
|
|
|
- github.com : git / 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
|
|
|
- expliquer comment faire la mise en production |
|
|
\ No newline at end of file |