Proj-2014-2015-Mini datacenter portail scrum
Product backlog
Product description
Ce projet est basé sur les ressources fournies par OARdocker.
OARdocker est une simulation de noeuds et de coeurs. Ceux-ci peuvent être gérés par des utilisateurs qui les créent, les suppriment et leur allouent des travaux.
Notre projet a pour but de créer un portail web permettant d'interagir facilement avec ces ressources. Il doit être simple de compréhension et d'utilisation, et permettre d'exécuter un maximum d'instructions tout en vérifiant le bon fonctionnement des ressources.
User stories
1- En tant qu'utilisateur (non identifié), je veux une interface simple afin de pouvoir connaitre l'état des ressources de ma simulation.
2- En tant qu'utilisateur "docker" , je veux une interface simple afin de pouvoir soumettre des tâches à mes ressources disponibles.
3- En tant qu'utilisateur "oar", je veux une interface simple afin de pouvoir ajouter des ressources rapidement à ma simulation.
4- En tant qu'utilisateur "docker" , je veux une interface simple afin de pouvoir annuler/tuer une tâche donnée à une ressource.
5- En tant qu'utilisateur "oar" , je veux une interface simple afin de pouvoir détruire une ressource instanciée.
Tasks
| Tâche | Priorité | Jours/homme | User storie | |
|---|---|---|---|---|
| 1 | Prise en main des technologies (Github, OARdocker, Bootstrap, API rest...) | Haute | 3 | --- |
| 2 | Affichage de l'état général des ressources | Haute | 3 | 1 |
| 3 | Mise en place d'une authentification pour interagir avec les ressources | Haute | 2 | 2, 3, 4, 5 |
| 4 | Ajouter une ressource à un noeud | Moyenne | 4 | 3 |
| 5 | Supprimer une ressource | Moyenne | 4 | 5 |
| 6 | Soumettre une tâche à un noeud | Haute | 5 | 2 |
| 7 | Supprimer une tâche affectée | Moyenne | 4 | 4 |
| 8 | Offrir une interface facile à comprendre | Haute | 4 | 1 |
| 9 | Offrir une interface facile à utiliser | Haute | 5 | 2, 3, 4, 5 |
Sprints
- Sprint 0 ( semaines 1 -> 4 )
* Définition des users stories
* Etude des outils/technologie à disposition
* Expérimentations pour définir la durée des futurs sprints
- Sprint 1 ( semaines 5 -> 8 )
* Etat général des ressources
* Soumettre une tache à des ressources
* Instancier des resources supplémentaires
* Gestion de l'authentification pour les task et l’instanciation de ressources sup. (2&3&4&5)
- Sprint 2 ( semaines 9 -> 11 )
* Annuler/tuer un job donné à une ressource
* Détruire une resource instanciée
* Adaptabilité de l'interface à un grand nombre de ressources
* Paramétrage plus fin des requêtes vers l'API