air - User contributions [en]

Coconode

2013-03-23T01:31:56Z

Carameln: /* Partie Statistique */

[[Image:Coconode_interface.png|300px|thumb|right|Interface Coconode]]

==Git us !==

[https://bitbucket.org/noejean/coconode COCONODE on Git]

==Contexte==

Ce projet se place dans la continuité du travail de Malisa VUCINIC - thésard à l'équipe DRAKKA (LIG). Durant son projet de fin d'études, il a écrit un programme permettant de simuler le comportement de capteurs disposés dans une salle/un bâtiment. Le comportement étant basé sur deux protocoles de routage de données (RPL ou LOADng). Cependant, ce programme ne permet pas d'automatiser l'exécution d'un grand nombre de simulation, ce qui est nécessaire pour faire des statistiques. De plus, les données obtenues ne sont pas interprétées mais seulement regroupées de manière cohérente par un parseur. L’utilisateur est obligé de traiter lui-même ces données via un logiciel tiers d’analyse.

==Motivations==

Industrie, sécurité, transport, santé... Les capteurs sont de plus en plus utilisés dans notre quotidien. Organisé en réseau, ces capteurs permettent de récolter une multitude de données de toutes sortes. La majorité des applications impliquent le déploiement d'un grand nombre de nœuds (capteurs) dans une zone donnée. Cela implique un minimum de traitement pour communiquer entre eux et/ou avec une entité capable de les traiter. Cependant, une grande partie de ces équipements ne seront pas reliés à un réseau électrique ni à un réseau informatique à cause du coût d’installation et de raccordement. C’est pourquoi ils seront alimentés grâce à une batterie et devront communiquer via des transmissions radio. Le coût faible du déploiement et la durée de vie très longue des capteurs impliquent des contraintes matérielles liées à la mémoire, aux traitements et à la consommation d’énergie. La communication en est impactée car il faut consommer le moins possible tout en communiquant avec les autres. Il faut donc utiliser des protocoles de communications optimisés pour lui permettre d’être autonome tout en restant joignable via Internet. En effet, IPv6 est performant pour délivrer les données et router celle-ci, quel que soit le réseau, d’un émetteur vers un récepteur. De plus, au vu du nombre de capteurs déployés, il est nécessaire d’avoir une grande plage d’adresses disponible. Cependant, IP a été conçu pour des réseaux très puissants et possède, par exemple, des entêtes de tailles trop grandes pour un capteur. C’est pourquoi l’IETF a créé un standard nommé 6LowPAN qui définit des mécanismes d’encapsulation et de compression d’en-têtes permettant d’envoyer des paquets IPv6.
Afin de pouvoir tester et expérimenter de tels protocoles, plusieurs méthodes sont possibles : théorie, simulation, modélisation. La théorie permet d’avoir un résultat rapidement par rapport aux autres méthodes. La modélisation est la meilleure solution par rapport à la précision des résultats. Cependant, la première n’est pas assez représentative par rapport à des évènements censés être aléatoires sur les nœuds et la deuxième coûte cher et ne supporte pas les changements. La simulation est un bon compromis car il est possible de la reproduire dans le temps en modifiant les paramètres facilement tout en contrôlant les dépenses liées au coût de développement. Un des désavantages de la simulation est que certains phénomènes physiques sont très difficiles (voire impossible) à définir.

Aujourd'hui, plusieurs systèmes d'exploitation sont utilisés sur ces capteurs pour pouvoir faire des opérations liées aux communications, aux récupérations de données et aux agrégations de celles-ci. [http://fr.wikipedia.org/wiki/Contiki Contiki] est l'un des plus utilisés.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé [http://www.contiki-os.org/start.html#start-cooja Cooja] pour simuler le comportement d’un réseau de capteurs par rapport aux algorithmes de routages des paquets, de la disposition des capteurs dans le réseau, les propriétés de l’environnement… Ce simulateur est fourni par l'organisation qui développe Contiki pour pouvoir émuler cet OS au niveau hardware et ainsi pouvoir réutiliser les codes simulés sur des capteurs réels.

==Utilisateurs cibles==

Les utilisateurs cibles sont principalement des chercheurs, stagiaires utilisant le simulateur Cooja. Ensuite, les autres utilisateurs seront les personnes lambda voulant utiliser ce logiciel car il sera diffusé avec une licence libre.

==Description==

L'objectif est faire un logiciel permettant de configurer et de répéter une expérience, de suivre les différentes étapes de l'expérience lors de la simulation et d'interpréter les résultats obtenus. Le logiciel doit être « user friendly », avec une interface graphique. De plus, dans la mesure du possible, on essayera de le rendre générique, c'est à dire utilisable pour d'autres protocoles que les deux testés dans le cadre de ce projet. Il sera ainsi susceptible d'être réutilisé pour d'autres études.

Le travail à réaliser peut être présenté en trois modules :
*Partie configuration : Saisir des paramètres voulus pour la simulation, le nombre de simulations voulues pour pouvoir faire des statistiques associées, construction de fichier de configuration .xml (scénario). Cette partie pourra aussi afficher la configuration/répartition des capteurs dans la salle/du bâtiment : une carte de la salle affiche leur position.
*Partie suivi de la simulation (qui peut durer très longtemps, des semaines) : donne le statut de la simulation. Par exemple : Simulation avec COOJA à partir du scénario (répéter plusieurs fois pour augmenter la confiance)
*Partie résultat : elle peut être décomposée en 2 sous parties :
**Choisir les données que l'on veut afficher (choix des différents graphes avec différents paramètres, choix de l'échelle, observation d'une simulation particulière ou application d'une fonction statistique aux données particulière)
**Afficher les graphes et les données de sortie. Résultat + script pour analyser le résultat.

L'outil actuel se fait en plusieurs étapes séparées par des lignes de commande tapées manuellement. Ceci n'est pas automatisé et est destiné principalement à l'utilisateur expérimenté.
Le but de notre projet est de développer un outil qui automatise le processus de simulation comprenant la configuration, l'exécution et l'analyse de résultat sous forme d'une interface utilisateur interactive. Il sera important de concevoir une architecture flexible, modulable et facile à étendre pour le développement ultérieur.

== Fonctionnalités à développer ==

=== Product Backlog ===
<center>
{| class="wikitable centre" width="80%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Description
! scope=col | Complexité
! scope=col | Priorité
|-
| width="12%" |
Configuration
| width="54%" |
L'utilisateur veut choisir la configuration qu'il veut pour l'expérience (protocole, nombre de simulations, loi de probabilité des événements...)
| width="12%" |
12
| width="12%" |
30
|-
| width="12%" |
Monitoring
| width="38%" |
L'utilisateur surveille l'état de l'exécution de la simulation en temps réel.
| width="12%" |
10
| width="12%" |
5
|-
| width="12%" |
Interruption
| width="38%" |
L'utilisateur interrompt l’expérience.
| width="12" |
3
| width="12%" |
20
|-
| width="12%" |
Répétitions
| width="54%" |
L'utilisateur détermine le nombre de fois qu'une simulation est répétée durant une expérience (pour augmenter l'intervalle de confiance).
| width="12%" |
2
| width="12%" |
30
|-
| width="12%" |
Topologie
| width="54%" |
L'utilisateur voit la topologie du réseau (répartition des capteurs dans la salle / le bâtiment)
| width="12%" |
4
| width="12%" |
15
|-
| width="12%" |
Résultat
| width="54%" |
L'utilisateur observe en temps réel (unité de temps=une simulation) les graphes qu'il voulait lors de la configuration.
| width="12%" |
18
| width="12%" |
35
|-
| width="12%" |
Scheduler
| width="54%" |
L'utilisateur peut programmer des périodes d'exécution pour son expérience (le simulateur n'exécute l'expérience que la nuit, le PC a plus de ressources le journée)
| width="12%" |
30
| width="12%" |
20
|-
| width="12%" |
Format
| width="54%" |
Les fichiers d'entrées / sorties doivent être génériques
| width="12%" |
20
| width="12%" |
25
|}
</center>

=== Aspects Techniques ===

* Langage C et bibliothèque graphique GTK (et gestion des threads)
* Bibliothèques dynamiques
* Compilation du code utilisateur pour la topologie
* Basé sur le noyau Cooja avec Java Native Interface (JNI)
* Gnuplot
* Json-glib

== L'équipe ==

Ce projet s'inscrit dans un cadre pédagogique précis. Un encadrant joue le rôle de client, un autre de tuteur. Le projet s'effectue en groupe et met en place des méthodes de gestion de projet.

=== Encadrants ===
==== Clients ====
* Bernard Tourancheau
* Mališa Vučinić
==== Tuteur ====
* Didier Donsez

=== Etudiants ===
* Chef de projet : Noé-Jean Caramelli
* Minh Quan Ho
* Florian Lévêque

==== Répartitions des tâches ====
[[Image:Taches2.png|1000px|thumb|center|Répartition des tâches]]

== Le produit ==

=== Architecture logicielle ===
[[Image:Coconode_architecture.png|300px|thumb|right|Architecture Coconode]]

Coconode est composé de 4 parties différentes :
* Interface Graphique
* Architecture interne
** Configuration
** Exécution
** Statistique

L'architecture se base sur des modules existants (Générateur de topologie et noyau de simulation Cooja) utilisés dans l'outil existant. Ces modules ont du être intégré dans l'architecture pour pouvoir les réutiliser dans le nouvel outil.
La séparation des différentes parties a été faite pour isoler chaque partie réalisant les mêmes tâches. Cela facilite le développement et les modification future.
Cela permet aussi l'utilisation de threads pour paralléliser les différents traitement, pour ne pas bloquer la GUI lors d'un gros traitement dans l'exécution ou dans la partie statistique par exemple.

La GUI est liée à chaque partie car elle est utilisée en entrée pour que l'utilisateur puisse définir les données de simulation (voir partie Configuration) et en sortie pour que le contrôleur et l'affichage statistique puisse afficher des retours (voir Partie Exécution et Statistique).

==== Interface Graphique ====
Cette interface basée sur la librairie GTK permet à l'utilisateur d'interagir avec le noyau de simulation Cooja.

==== Architecture interne ====
L'architecture interne de Coconode comprend trois parties :

===== Partie Configuration =====
[[Image:Configurateur_coconode.png|250px|thumb|right|Configuration]]

* Personnalisation de la simulation :
# Durée de simulation
# Planification
# Nombre de simulations
# Choix du protocole de routage (Ici c'est load, un protocole de routage français)
Cette partie est lié au module Jsonner qui permet d'exporter ou importer ces paramètres au format JSON.
[[Image:Topologie_coconode.png|250px|thumb|right|Générateur de topologie]]

* Génération et visualisation de la topologie :
# Sélectionner les paramètres de la topologie :
## Nombre de noeuds
## Pourcentage de capteurs (qui récupèrent une donnée physique)
## Pourcentage d'actuateurs (qui réalisent une action)
## Sélectionner les fichiers utilisateurs qui génèrent une topologie selon un modèle précis (représentation d'une maison ...)
# Générer la topologie et visualiser le résultat

Après avoir entré toutes les informations précédentes et généré une topologie de réseaux de capteurs, ces informations seront passées au module d'exécution qui va la prendre en charge et l'exécuter en temps voulu.

===== Partie Exécution =====
[[Image:Coconode_scheduler.png |250px|thumb|right|Scheduler]]
L'exécution des simulations doit se faire dans un ordre précis défini grâce à l'interface. Cet ordre mélange un ordre temporel et un ordre de définition, en effet, l'utilisateur peut définir un délai de début de simulation en plus de l'ordre de définition de celle-ci. Il faut donc avoir une file d'attente des simulations.
La file d'attente est une file asynchrone accessible par l'interface et par le contrôleur. Le contrôleur va l'utiliser pour ordonnancer les simulations et gérer l'ordre de départ de chaque simulation.

Ensuite, le contrôle doit être fait en temps réel. L'interface doit être toujours disponible pour l'utilisateurs afin qu'il puisse contrôler les simulations. Comme Cooja est un outil Java, il a fallu utiliser une bibliothèque nommé [http://fr.wikipedia.org/wiki/Java_Native_Interface Java Native Interface] qui permet de faire l'interfaçage entre du code C et du code Java. Cela permet de créer une [http://fr.wikipedia.org/wiki/Machine_virtuelle_Java JVM] personnalisée pour exécuter le noyau Cooja. Il est donc possible d'avoir un contrôle total de Cooja en accédant aux différentes classes présentes.

[[Image:Monitor_coconode.png|250px|thumb|right|Monitor]]
L'utilisateur aura un retour d'avancement de la simulation en cours ainsi qu'une liste des simulations à venir dans l'ordre de départ.

===== Partie Statistique =====
[[Image:Pstat.png |250px|thumb|right|Afficheur de résultat et statistiques]]
Les fichiers d'entrée suivent le format d'entrée Gnuplot le plus fréquemment rencontré : des colonnes de valeur séparées par une tabulation. La première ligne est un commentaire (commence par un '#') qui décrit chaque colonne de valeur.
La capture ci-contre se base sur 9 fichiers d'exemple contenant une valeur de rayon par rapport à une valeur d'angle. Pour utiliser le programme avec le simulateur Cooja, un script qui parse la sortie de Cooja dans le bon format Gnuplot doit encore être développé.

Un fichier représente un individu de l'échantillon utilisé pour le graphe statistique de droite.
Un fichier sera généré pour chaque simulation. Une simulation de Cooja est donc un individu pour le programme de statistique.

Sur l'interface, le choix des axes x et y est possible parmis les description des colonnes trouvées dans le premier fichier affiché.

La liste des fichiers disponbles à l'affichage pour 'current individual' est triée selon l'ordre de la table ASCII. Les valeurs des axes sélectionnés sont affichés pour le fichier sélectionné lorsqu'on clique sur 'trace'. La liste des fichiers sélectionnés est dynamique. Si on ajoute ou retire des fichiers dans le dossier d'entrée (définit par le #define DATA_IN), la liste des 'current individual'est mise à jours lorsqu'on clique dessus.

Le graphe statistique est calculé avec les fichiers disponibles à ce moment dans le dossier d'entrée lorsqu'on clique sur 'compute'. À la fin du projet (22 mars 2013), deux fonctions statistiques sont disponibles : la moyenne et la fonction de densité de probabilité. Elles sont calculées en se basant sur l'axe des y sélectionné.

Chacun des deux graphes sont exportables au format EPS, PDF et PNG (avec choix de la taille du fichier png).

L'interface est vectorielle.

== Méthodes de gestion de projet ==

Nous utilisons d'une part une méthode de gestion de projets classique avec un Chef de projet, mais d'autre part, nous utilisons la méthode Agile/Scrum pour le développement du logiciel.

=== Scrum Master ===

Nous choisissions un scrum master fixe. En effet, nous avons un chef de projet qui a pour rôle d'être le point central de communication avec l'équipe. Or le scrum master est censé isoler l'équipe de l'extérieur. Si on prend un scrum master tournant, on aura un chef de projet, qui ne sera pas isolé de l'extérieur à cause de son rôle et qui ne sera pas scrum master. Ce n'est pas logique. Nous choisissons donc un scrum master fixe qui sera le chef de projet par soucis de cohérence.

=== Points avec les clients ===

Nous feront un point par semaine avec Bernard Tourancheau et Malisa Vucinic. Le rendez-vous hebdomadaire est fixé tous les jeudis à 15h. Ces rendez-vous serviront à faire le point sur l'avancement et à régler les éventuels problèmes qui pourraient nous bloquer. Un rendez-vous tous les 15 jours serait trop espacé en cas de problème.

=== Durée du stage ===

Le projet commence le 4 février et termine le 15 mars. Nous avons en réalité eu deux réunions avant le 4 février, mais nous n'avions que très peu de temps libre pour le projet la semaine d'avant. La semaine du 18 mars est celle de la soutenance du projet. Nous ne savons pas la date exacte de soutenance, nous ne plaçons donc pas de tâche

=== Sprints ===

Nous choisissons de faire des sprints de deux semaines. Cela nous semble un bon compromis entre un sprint trop long pendant lequel les tâches serait trop complexes et les problèmes s'accumuleraient, et un sprint trop court où nous n'aurions pas assez avancé pour que le sprint soit profitable, malgré le temps qu'il nous prend.

==== '''Sprint 3''' :11 Mars au 22 Mars ====
===== Sprint Backlog =====
<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Scheduler
| width="25%" |
20
| width="25%" |
15
|-
| width="50%" |
Monitoring
| width="25%" |
5
| width="25%" |
3
|-
| width="50%" |
Interruption d'une simulation
| width="25%" |
20
| width="25%" |
10
|-
| width="50%" |
Observation des résultats
| width="25%" |
35
| width="25%" |
8
|-
| width="50%" |
Contrôle d'une simulation
| width="25%" |
35
| width="25%" |
17
|-
| width="50%" |
Validation du logiciel
| width="25%" |
30
| width="25%" |
15
|-
| width="50%" |
Portabilité de l'outil
| width="25%" |
20
| width="25%" |
15
|}
</center>

===== Sprint retrospective =====

* Plus:
** Point de vue de conception et de technique avancé
** Connaissances de JNI
** Développement boosté
** Reprise de motivation

* A améliorer:
** Documentation
** Test de validation

* Moins:
** Bugs technique complexe
** Manque de réactivité aux bugs
** Deadline approché

==== Burndown Chart ====
[[Image:Burndownchart3_coconode.png|1000px|thumb|center|Burndown Chart Sprint 2]]

==== '''Sprint 2''' :18 Février au 8 Mars ====
===== Sprint Backlog =====

<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Générateur de topologie
| width="25%" |
15
| width="25%" |
15
|-
| width="50%" |
Configuration des simulations
| width="25%" |
30
| width="25%" |
10
|-
| width="50%" |
Importer/Exporter données
| width="25%" |
25
| width="25%" |
20
|-
| width="50%" |
Contrôle d'une simulation
| width="25%" |
35
| width="25%" |
25
|-
| width="50%" |
Observation des résultats
| width="25%" |
35
| width="25%" |
25
|}
</center>

===== Sprint retrospective =====

* Plus:
** Entraide lors de bugs
** Séparation des modules facilitant le développement

*A améliorer
** Compréhension de la hiérarchie et fonctionnement de Cooja

* Moins:
** Répartition du temps
** Bugs techniques et complexe.
** Perturbation du rythme de travail lié à:
*** Problème de santé
*** Manque de motivation
*** Problème de l'ordinateur

==== Burndown Chart ====
[[Image:BDCSprint2.jpg|1000px|thumb|center|Burndown Chart Sprint 2]]
==== '''Sprint 1''' : 29 Janvier au 15 Février ====
===== Sprint Backlog =====

<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Cahier des charges
| width="25%" |
13
| width="25%" |
15
|-
| width="50%" |
Architecture
| width="25%" |
13
| width="25%" |
25
|-
| width="50%" |
Prototype de l'IHM
| width="25%" |
8
| width="25%" |
25
|-
| width="50%" |
Prise en main de l'outil
| width="25%" |
10
| width="25%" |
10
|}
</center>

===== Sprint retrospective =====
* Plus:
** Rédaction du cahier des charges
** Utilisation de GIT

*A améliorer
** Répartition des tâches
** Mise à jours de Trello

* Moins:
** Prise en main de l'outil laborieuse
** Daily stand up oubliée

==== Burndown Chart ====
[[Image:BDCSprint1.jpg|1000px|thumb|center|Burndown Chart Sprint 1]]

=== Outils de suivi ===
Pour permettre de suivre l'avancement d'un sprint du projet, nous utilisons des outils de Scrum :
*Todo-List ;
*Burn down chart.

=== Tests et validation ===
Comme nous utilisons la méthode Scrum pour la gestion de projet, chaque développeur fera des tests « unitaires » sur les stories qu'il développera. Ils vont permettre d'assurer de l’intégrité du code pour certaines fonctionnalités, la bonne qualité du code. Ils ne permettent pas de vérifier si le code répond aux besoins du client.
Les tests permettant de garantir au product owner la fiabilité et le respect des spécifications sont les tests d'acceptation. Chaque test sera développé ou défini grâce aux conditions de satisfaction données par celui-ci.

== Choix non fonctionnels ==
===Licence ===
Le code sera placé sous la licence libre GNU GPL afin de permettre au projet d'être réutilisé et amélioré.
La documentation et autres ressources éventuellement créées pour le projet seront placées sous licence Creative Commons CC-BY-NC-SA afin de permettre également une réutilisation et une évolution libres.
=== Gestionnaire de version===
Nous choisissons GIT, un gestionnaire de version récent, évolué et de plus en plus répandu. C'est le gestionnaire de version déjà utilisé pour le projet.
===Documentation===
Nous prévoyons différents éléments de documentation pour permettre une bonne continuité du projet.
====Documents de conception====
*La documentation sera séparée en plusieurs fichiers :
**Conception IHM ;
**Conception système (architecture, librairies, technologies).

====Manuels====
*Manuel développeur ;
*Manuel utilisateur.

====Génération automatique de documentation sur le code====
Nous utiliserons un générateur de documentation capable de produire une documentation logicielle à partir du code source du programme, comme Doxygen.

====Convention de codage====

* Indentation obligatoire (utilisation du caractère tabulation) ;
* L'accolade ouvrante doit être placée à la ligne suivante ;
* Les commentaires doivent être écrits en anglais ;
* Tous les fichiers doivent être codés au format UTF-8 ;
* Les lignes ne doivent (dans la mesure du possible) pas dépassées 80 caractères ;
* Le nom des fonctions seront plutôt des verbes, les variables seront des noms (en anglais) ;
Exemples :
**Procédure : draw_something ;
**Variable : a_variable ;
**Constante : A_CONSTANT.
*Chaque fonction doit être commenté selon deux règles :
**Une explication détaillée de l'utilité de la fonction doit être placé au dessus du corps de la fonction ;
**Chaque ligne de code complexe doit être commentée .
*Chaque fonction ne doit (dans la mesure du possible) n'implémenter qu'une seule tâche.

==TODO==
* Script to parse [http://air.imag.fr/mediawiki/images/a/a8/Coconode_cooja_output.txt COOJA log] in to [http://air.imag.fr/mediawiki/images/8/8a/Coconode_gnuplot_input.txt GNUplot format].
* Validation test
* Integrate Statistic module into Coconode (or add callback to launch Statistic module from Coconode)

Coconode

2013-03-23T01:23:14Z

Carameln: /* Partie Statistique */

[[Image:Coconode_interface.png|300px|thumb|right|Interface Coconode]]

==Git us !==

[https://bitbucket.org/noejean/coconode COCONODE on Git]

==Contexte==

Ce projet se place dans la continuité du travail de Malisa VUCINIC - thésard à l'équipe DRAKKA (LIG). Durant son projet de fin d'études, il a écrit un programme permettant de simuler le comportement de capteurs disposés dans une salle/un bâtiment. Le comportement étant basé sur deux protocoles de routage de données (RPL ou LOADng). Cependant, ce programme ne permet pas d'automatiser l'exécution d'un grand nombre de simulation, ce qui est nécessaire pour faire des statistiques. De plus, les données obtenues ne sont pas interprétées mais seulement regroupées de manière cohérente par un parseur. L’utilisateur est obligé de traiter lui-même ces données via un logiciel tiers d’analyse.

==Motivations==

Industrie, sécurité, transport, santé... Les capteurs sont de plus en plus utilisés dans notre quotidien. Organisé en réseau, ces capteurs permettent de récolter une multitude de données de toutes sortes. La majorité des applications impliquent le déploiement d'un grand nombre de nœuds (capteurs) dans une zone donnée. Cela implique un minimum de traitement pour communiquer entre eux et/ou avec une entité capable de les traiter. Cependant, une grande partie de ces équipements ne seront pas reliés à un réseau électrique ni à un réseau informatique à cause du coût d’installation et de raccordement. C’est pourquoi ils seront alimentés grâce à une batterie et devront communiquer via des transmissions radio. Le coût faible du déploiement et la durée de vie très longue des capteurs impliquent des contraintes matérielles liées à la mémoire, aux traitements et à la consommation d’énergie. La communication en est impactée car il faut consommer le moins possible tout en communiquant avec les autres. Il faut donc utiliser des protocoles de communications optimisés pour lui permettre d’être autonome tout en restant joignable via Internet. En effet, IPv6 est performant pour délivrer les données et router celle-ci, quel que soit le réseau, d’un émetteur vers un récepteur. De plus, au vu du nombre de capteurs déployés, il est nécessaire d’avoir une grande plage d’adresses disponible. Cependant, IP a été conçu pour des réseaux très puissants et possède, par exemple, des entêtes de tailles trop grandes pour un capteur. C’est pourquoi l’IETF a créé un standard nommé 6LowPAN qui définit des mécanismes d’encapsulation et de compression d’en-têtes permettant d’envoyer des paquets IPv6.
Afin de pouvoir tester et expérimenter de tels protocoles, plusieurs méthodes sont possibles : théorie, simulation, modélisation. La théorie permet d’avoir un résultat rapidement par rapport aux autres méthodes. La modélisation est la meilleure solution par rapport à la précision des résultats. Cependant, la première n’est pas assez représentative par rapport à des évènements censés être aléatoires sur les nœuds et la deuxième coûte cher et ne supporte pas les changements. La simulation est un bon compromis car il est possible de la reproduire dans le temps en modifiant les paramètres facilement tout en contrôlant les dépenses liées au coût de développement. Un des désavantages de la simulation est que certains phénomènes physiques sont très difficiles (voire impossible) à définir.

Aujourd'hui, plusieurs systèmes d'exploitation sont utilisés sur ces capteurs pour pouvoir faire des opérations liées aux communications, aux récupérations de données et aux agrégations de celles-ci. [http://fr.wikipedia.org/wiki/Contiki Contiki] est l'un des plus utilisés.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé [http://www.contiki-os.org/start.html#start-cooja Cooja] pour simuler le comportement d’un réseau de capteurs par rapport aux algorithmes de routages des paquets, de la disposition des capteurs dans le réseau, les propriétés de l’environnement… Ce simulateur est fourni par l'organisation qui développe Contiki pour pouvoir émuler cet OS au niveau hardware et ainsi pouvoir réutiliser les codes simulés sur des capteurs réels.

==Utilisateurs cibles==

Les utilisateurs cibles sont principalement des chercheurs, stagiaires utilisant le simulateur Cooja. Ensuite, les autres utilisateurs seront les personnes lambda voulant utiliser ce logiciel car il sera diffusé avec une licence libre.

==Description==

L'objectif est faire un logiciel permettant de configurer et de répéter une expérience, de suivre les différentes étapes de l'expérience lors de la simulation et d'interpréter les résultats obtenus. Le logiciel doit être « user friendly », avec une interface graphique. De plus, dans la mesure du possible, on essayera de le rendre générique, c'est à dire utilisable pour d'autres protocoles que les deux testés dans le cadre de ce projet. Il sera ainsi susceptible d'être réutilisé pour d'autres études.

Le travail à réaliser peut être présenté en trois modules :
*Partie configuration : Saisir des paramètres voulus pour la simulation, le nombre de simulations voulues pour pouvoir faire des statistiques associées, construction de fichier de configuration .xml (scénario). Cette partie pourra aussi afficher la configuration/répartition des capteurs dans la salle/du bâtiment : une carte de la salle affiche leur position.
*Partie suivi de la simulation (qui peut durer très longtemps, des semaines) : donne le statut de la simulation. Par exemple : Simulation avec COOJA à partir du scénario (répéter plusieurs fois pour augmenter la confiance)
*Partie résultat : elle peut être décomposée en 2 sous parties :
**Choisir les données que l'on veut afficher (choix des différents graphes avec différents paramètres, choix de l'échelle, observation d'une simulation particulière ou application d'une fonction statistique aux données particulière)
**Afficher les graphes et les données de sortie. Résultat + script pour analyser le résultat.

L'outil actuel se fait en plusieurs étapes séparées par des lignes de commande tapées manuellement. Ceci n'est pas automatisé et est destiné principalement à l'utilisateur expérimenté.
Le but de notre projet est de développer un outil qui automatise le processus de simulation comprenant la configuration, l'exécution et l'analyse de résultat sous forme d'une interface utilisateur interactive. Il sera important de concevoir une architecture flexible, modulable et facile à étendre pour le développement ultérieur.

== Fonctionnalités à développer ==

=== Product Backlog ===
<center>
{| class="wikitable centre" width="80%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Description
! scope=col | Complexité
! scope=col | Priorité
|-
| width="12%" |
Configuration
| width="54%" |
L'utilisateur veut choisir la configuration qu'il veut pour l'expérience (protocole, nombre de simulations, loi de probabilité des événements...)
| width="12%" |
12
| width="12%" |
30
|-
| width="12%" |
Monitoring
| width="38%" |
L'utilisateur surveille l'état de l'exécution de la simulation en temps réel.
| width="12%" |
10
| width="12%" |
5
|-
| width="12%" |
Interruption
| width="38%" |
L'utilisateur interrompt l’expérience.
| width="12" |
3
| width="12%" |
20
|-
| width="12%" |
Répétitions
| width="54%" |
L'utilisateur détermine le nombre de fois qu'une simulation est répétée durant une expérience (pour augmenter l'intervalle de confiance).
| width="12%" |
2
| width="12%" |
30
|-
| width="12%" |
Topologie
| width="54%" |
L'utilisateur voit la topologie du réseau (répartition des capteurs dans la salle / le bâtiment)
| width="12%" |
4
| width="12%" |
15
|-
| width="12%" |
Résultat
| width="54%" |
L'utilisateur observe en temps réel (unité de temps=une simulation) les graphes qu'il voulait lors de la configuration.
| width="12%" |
18
| width="12%" |
35
|-
| width="12%" |
Scheduler
| width="54%" |
L'utilisateur peut programmer des périodes d'exécution pour son expérience (le simulateur n'exécute l'expérience que la nuit, le PC a plus de ressources le journée)
| width="12%" |
30
| width="12%" |
20
|-
| width="12%" |
Format
| width="54%" |
Les fichiers d'entrées / sorties doivent être génériques
| width="12%" |
20
| width="12%" |
25
|}
</center>

=== Aspects Techniques ===

* Langage C et bibliothèque graphique GTK (et gestion des threads)
* Bibliothèques dynamiques
* Compilation du code utilisateur pour la topologie
* Basé sur le noyau Cooja avec Java Native Interface (JNI)
* Gnuplot
* Json-glib

== L'équipe ==

Ce projet s'inscrit dans un cadre pédagogique précis. Un encadrant joue le rôle de client, un autre de tuteur. Le projet s'effectue en groupe et met en place des méthodes de gestion de projet.

=== Encadrants ===
==== Clients ====
* Bernard Tourancheau
* Mališa Vučinić
==== Tuteur ====
* Didier Donsez

=== Etudiants ===
* Chef de projet : Noé-Jean Caramelli
* Minh Quan Ho
* Florian Lévêque

==== Répartitions des tâches ====
[[Image:Taches2.png|1000px|thumb|center|Répartition des tâches]]

== Le produit ==

=== Architecture logicielle ===
[[Image:Coconode_architecture.png|300px|thumb|right|Architecture Coconode]]

Coconode est composé de 4 parties différentes :
* Interface Graphique
* Architecture interne
** Configuration
** Exécution
** Statistique

L'architecture se base sur des modules existants (Générateur de topologie et noyau de simulation Cooja) utilisés dans l'outil existant. Ces modules ont du être intégré dans l'architecture pour pouvoir les réutiliser dans le nouvel outil.
La séparation des différentes parties a été faite pour isoler chaque partie réalisant les mêmes tâches. Cela facilite le développement et les modification future.
Cela permet aussi l'utilisation de threads pour paralléliser les différents traitement, pour ne pas bloquer la GUI lors d'un gros traitement dans l'exécution ou dans la partie statistique par exemple.

La GUI est liée à chaque partie car elle est utilisée en entrée pour que l'utilisateur puisse définir les données de simulation (voir partie Configuration) et en sortie pour que le contrôleur et l'affichage statistique puisse afficher des retours (voir Partie Exécution et Statistique).

==== Interface Graphique ====
Cette interface basée sur la librairie GTK permet à l'utilisateur d'interagir avec le noyau de simulation Cooja.

==== Architecture interne ====
L'architecture interne de Coconode comprend trois parties :

===== Partie Configuration =====
[[Image:Configurateur_coconode.png|250px|thumb|right|Configuration]]

* Personnalisation de la simulation :
# Durée de simulation
# Planification
# Nombre de simulations
# Choix du protocole de routage (Ici c'est load, un protocole de routage français)
Cette partie est lié au module Jsonner qui permet d'exporter ou importer ces paramètres au format JSON.
[[Image:Topologie_coconode.png|250px|thumb|right|Générateur de topologie]]

* Génération et visualisation de la topologie :
# Sélectionner les paramètres de la topologie :
## Nombre de noeuds
## Pourcentage de capteurs (qui récupèrent une donnée physique)
## Pourcentage d'actuateurs (qui réalisent une action)
## Sélectionner les fichiers utilisateurs qui génèrent une topologie selon un modèle précis (représentation d'une maison ...)
# Générer la topologie et visualiser le résultat

Après avoir entré toutes les informations précédentes et généré une topologie de réseaux de capteurs, ces informations seront passées au module d'exécution qui va la prendre en charge et l'exécuter en temps voulu.

===== Partie Exécution =====
[[Image:Coconode_scheduler.png |250px|thumb|right|Scheduler]]
L'exécution des simulations doit se faire dans un ordre précis défini grâce à l'interface. Cet ordre mélange un ordre temporel et un ordre de définition, en effet, l'utilisateur peut définir un délai de début de simulation en plus de l'ordre de définition de celle-ci. Il faut donc avoir une file d'attente des simulations.
La file d'attente est une file asynchrone accessible par l'interface et par le contrôleur. Le contrôleur va l'utiliser pour ordonnancer les simulations et gérer l'ordre de départ de chaque simulation.

Ensuite, le contrôle doit être fait en temps réel. L'interface doit être toujours disponible pour l'utilisateurs afin qu'il puisse contrôler les simulations. Comme Cooja est un outil Java, il a fallu utiliser une bibliothèque nommé [http://fr.wikipedia.org/wiki/Java_Native_Interface Java Native Interface] qui permet de faire l'interfaçage entre du code C et du code Java. Cela permet de créer une [http://fr.wikipedia.org/wiki/Machine_virtuelle_Java JVM] personnalisée pour exécuter le noyau Cooja. Il est donc possible d'avoir un contrôle total de Cooja en accédant aux différentes classes présentes.

[[Image:Monitor_coconode.png|250px|thumb|right|Monitor]]
L'utilisateur aura un retour d'avancement de la simulation en cours ainsi qu'une liste des simulations à venir dans l'ordre de départ.

===== Partie Statistique =====
[[Image:Pstat.png |250px|thumb|right|Afficheur de résultat et statistiques]]
Les fichiers d'entrée suivent le format d'entrée Gnuplot le plus fréquemment rencontré : des colonnes de valeur séparées par une tabulation. La première ligne est un commentaire (commence par un '#') qui décrit chaque colonne de valeur.
La capture ci-contre se base sur 9 fichiers d'exemple contenant une valeur de rayon par rapport à une valeur d'angle. Pour utiliser le programme avec le simulateur Cooja, un script qui parse la sortie de Cooja dans le bon format Gnuplot doit encore être développé.

Un fichier représente un individu de l'échantillon utilisé pour le graphe statistique de droite.
Un fichier sera généré pour chaque simulation. Une simulation de Cooja est donc un individu pour le programme de statistique.

Sur l'interface, le choix des axes x et y est possible parmis les description des colonnes trouvées dans le premier fichier affiché.

La liste des fichiers disponble à l'affichage pour 'current induvudual' est triée selon l'ordre de la table ASCII. Les valeurs des axes sélectionnés sont affichés pour le fichier sélectionné lorsqu'on clique sur 'trace'

== Méthodes de gestion de projet ==

Nous utilisons d'une part une méthode de gestion de projets classique avec un Chef de projet, mais d'autre part, nous utilisons la méthode Agile/Scrum pour le développement du logiciel.

=== Scrum Master ===

Nous choisissions un scrum master fixe. En effet, nous avons un chef de projet qui a pour rôle d'être le point central de communication avec l'équipe. Or le scrum master est censé isoler l'équipe de l'extérieur. Si on prend un scrum master tournant, on aura un chef de projet, qui ne sera pas isolé de l'extérieur à cause de son rôle et qui ne sera pas scrum master. Ce n'est pas logique. Nous choisissons donc un scrum master fixe qui sera le chef de projet par soucis de cohérence.

=== Points avec les clients ===

Nous feront un point par semaine avec Bernard Tourancheau et Malisa Vucinic. Le rendez-vous hebdomadaire est fixé tous les jeudis à 15h. Ces rendez-vous serviront à faire le point sur l'avancement et à régler les éventuels problèmes qui pourraient nous bloquer. Un rendez-vous tous les 15 jours serait trop espacé en cas de problème.

=== Durée du stage ===

Le projet commence le 4 février et termine le 15 mars. Nous avons en réalité eu deux réunions avant le 4 février, mais nous n'avions que très peu de temps libre pour le projet la semaine d'avant. La semaine du 18 mars est celle de la soutenance du projet. Nous ne savons pas la date exacte de soutenance, nous ne plaçons donc pas de tâche

=== Sprints ===

Nous choisissons de faire des sprints de deux semaines. Cela nous semble un bon compromis entre un sprint trop long pendant lequel les tâches serait trop complexes et les problèmes s'accumuleraient, et un sprint trop court où nous n'aurions pas assez avancé pour que le sprint soit profitable, malgré le temps qu'il nous prend.

==== '''Sprint 3''' :11 Mars au 22 Mars ====
===== Sprint Backlog =====
<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Scheduler
| width="25%" |
20
| width="25%" |
15
|-
| width="50%" |
Monitoring
| width="25%" |
5
| width="25%" |
3
|-
| width="50%" |
Interruption d'une simulation
| width="25%" |
20
| width="25%" |
10
|-
| width="50%" |
Observation des résultats
| width="25%" |
35
| width="25%" |
8
|-
| width="50%" |
Contrôle d'une simulation
| width="25%" |
35
| width="25%" |
17
|-
| width="50%" |
Validation du logiciel
| width="25%" |
30
| width="25%" |
15
|-
| width="50%" |
Portabilité de l'outil
| width="25%" |
20
| width="25%" |
15
|}
</center>

===== Sprint retrospective =====

* Plus:
** Point de vue de conception et de technique avancé
** Connaissances de JNI
** Développement boosté
** Reprise de motivation

* A améliorer:
** Documentation
** Test de validation

* Moins:
** Bugs technique complexe
** Manque de réactivité aux bugs
** Deadline approché

==== Burndown Chart ====
[[Image:Burndownchart3_coconode.png|1000px|thumb|center|Burndown Chart Sprint 2]]

==== '''Sprint 2''' :18 Février au 8 Mars ====
===== Sprint Backlog =====

<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Générateur de topologie
| width="25%" |
15
| width="25%" |
15
|-
| width="50%" |
Configuration des simulations
| width="25%" |
30
| width="25%" |
10
|-
| width="50%" |
Importer/Exporter données
| width="25%" |
25
| width="25%" |
20
|-
| width="50%" |
Contrôle d'une simulation
| width="25%" |
35
| width="25%" |
25
|-
| width="50%" |
Observation des résultats
| width="25%" |
35
| width="25%" |
25
|}
</center>

===== Sprint retrospective =====

* Plus:
** Entraide lors de bugs
** Séparation des modules facilitant le développement

*A améliorer
** Compréhension de la hiérarchie et fonctionnement de Cooja

* Moins:
** Répartition du temps
** Bugs techniques et complexe.
** Perturbation du rythme de travail lié à:
*** Problème de santé
*** Manque de motivation
*** Problème de l'ordinateur

==== Burndown Chart ====
[[Image:BDCSprint2.jpg|1000px|thumb|center|Burndown Chart Sprint 2]]
==== '''Sprint 1''' : 29 Janvier au 15 Février ====
===== Sprint Backlog =====

<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Cahier des charges
| width="25%" |
13
| width="25%" |
15
|-
| width="50%" |
Architecture
| width="25%" |
13
| width="25%" |
25
|-
| width="50%" |
Prototype de l'IHM
| width="25%" |
8
| width="25%" |
25
|-
| width="50%" |
Prise en main de l'outil
| width="25%" |
10
| width="25%" |
10
|}
</center>

===== Sprint retrospective =====
* Plus:
** Rédaction du cahier des charges
** Utilisation de GIT

*A améliorer
** Répartition des tâches
** Mise à jours de Trello

* Moins:
** Prise en main de l'outil laborieuse
** Daily stand up oubliée

==== Burndown Chart ====
[[Image:BDCSprint1.jpg|1000px|thumb|center|Burndown Chart Sprint 1]]

=== Outils de suivi ===
Pour permettre de suivre l'avancement d'un sprint du projet, nous utilisons des outils de Scrum :
*Todo-List ;
*Burn down chart.

=== Tests et validation ===
Comme nous utilisons la méthode Scrum pour la gestion de projet, chaque développeur fera des tests « unitaires » sur les stories qu'il développera. Ils vont permettre d'assurer de l’intégrité du code pour certaines fonctionnalités, la bonne qualité du code. Ils ne permettent pas de vérifier si le code répond aux besoins du client.
Les tests permettant de garantir au product owner la fiabilité et le respect des spécifications sont les tests d'acceptation. Chaque test sera développé ou défini grâce aux conditions de satisfaction données par celui-ci.

== Choix non fonctionnels ==
===Licence ===
Le code sera placé sous la licence libre GNU GPL afin de permettre au projet d'être réutilisé et amélioré.
La documentation et autres ressources éventuellement créées pour le projet seront placées sous licence Creative Commons CC-BY-NC-SA afin de permettre également une réutilisation et une évolution libres.
=== Gestionnaire de version===
Nous choisissons GIT, un gestionnaire de version récent, évolué et de plus en plus répandu. C'est le gestionnaire de version déjà utilisé pour le projet.
===Documentation===
Nous prévoyons différents éléments de documentation pour permettre une bonne continuité du projet.
====Documents de conception====
*La documentation sera séparée en plusieurs fichiers :
**Conception IHM ;
**Conception système (architecture, librairies, technologies).

====Manuels====
*Manuel développeur ;
*Manuel utilisateur.

====Génération automatique de documentation sur le code====
Nous utiliserons un générateur de documentation capable de produire une documentation logicielle à partir du code source du programme, comme Doxygen.

====Convention de codage====

* Indentation obligatoire (utilisation du caractère tabulation) ;
* L'accolade ouvrante doit être placée à la ligne suivante ;
* Les commentaires doivent être écrits en anglais ;
* Tous les fichiers doivent être codés au format UTF-8 ;
* Les lignes ne doivent (dans la mesure du possible) pas dépassées 80 caractères ;
* Le nom des fonctions seront plutôt des verbes, les variables seront des noms (en anglais) ;
Exemples :
**Procédure : draw_something ;
**Variable : a_variable ;
**Constante : A_CONSTANT.
*Chaque fonction doit être commenté selon deux règles :
**Une explication détaillée de l'utilité de la fonction doit être placé au dessus du corps de la fonction ;
**Chaque ligne de code complexe doit être commentée .
*Chaque fonction ne doit (dans la mesure du possible) n'implémenter qu'une seule tâche.

==TODO==
* Script to parse [http://air.imag.fr/mediawiki/images/a/a8/Coconode_cooja_output.txt COOJA log] in to [http://air.imag.fr/mediawiki/images/8/8a/Coconode_gnuplot_input.txt GNUplot format].
* Validation test
* Integrate Statistic module into Coconode (or add callback to launch Statistic module from Coconode)

Coconode

2013-03-23T01:02:45Z

Carameln: /* Partie Statistique */

[[Image:Coconode_interface.png|300px|thumb|right|Interface Coconode]]

==Git us !==

[https://bitbucket.org/noejean/coconode COCONODE on Git]

==Contexte==

Ce projet se place dans la continuité du travail de Malisa VUCINIC - thésard à l'équipe DRAKKA (LIG). Durant son projet de fin d'études, il a écrit un programme permettant de simuler le comportement de capteurs disposés dans une salle/un bâtiment. Le comportement étant basé sur deux protocoles de routage de données (RPL ou LOADng). Cependant, ce programme ne permet pas d'automatiser l'exécution d'un grand nombre de simulation, ce qui est nécessaire pour faire des statistiques. De plus, les données obtenues ne sont pas interprétées mais seulement regroupées de manière cohérente par un parseur. L’utilisateur est obligé de traiter lui-même ces données via un logiciel tiers d’analyse.

==Motivations==

Industrie, sécurité, transport, santé... Les capteurs sont de plus en plus utilisés dans notre quotidien. Organisé en réseau, ces capteurs permettent de récolter une multitude de données de toutes sortes. La majorité des applications impliquent le déploiement d'un grand nombre de nœuds (capteurs) dans une zone donnée. Cela implique un minimum de traitement pour communiquer entre eux et/ou avec une entité capable de les traiter. Cependant, une grande partie de ces équipements ne seront pas reliés à un réseau électrique ni à un réseau informatique à cause du coût d’installation et de raccordement. C’est pourquoi ils seront alimentés grâce à une batterie et devront communiquer via des transmissions radio. Le coût faible du déploiement et la durée de vie très longue des capteurs impliquent des contraintes matérielles liées à la mémoire, aux traitements et à la consommation d’énergie. La communication en est impactée car il faut consommer le moins possible tout en communiquant avec les autres. Il faut donc utiliser des protocoles de communications optimisés pour lui permettre d’être autonome tout en restant joignable via Internet. En effet, IPv6 est performant pour délivrer les données et router celle-ci, quel que soit le réseau, d’un émetteur vers un récepteur. De plus, au vu du nombre de capteurs déployés, il est nécessaire d’avoir une grande plage d’adresses disponible. Cependant, IP a été conçu pour des réseaux très puissants et possède, par exemple, des entêtes de tailles trop grandes pour un capteur. C’est pourquoi l’IETF a créé un standard nommé 6LowPAN qui définit des mécanismes d’encapsulation et de compression d’en-têtes permettant d’envoyer des paquets IPv6.
Afin de pouvoir tester et expérimenter de tels protocoles, plusieurs méthodes sont possibles : théorie, simulation, modélisation. La théorie permet d’avoir un résultat rapidement par rapport aux autres méthodes. La modélisation est la meilleure solution par rapport à la précision des résultats. Cependant, la première n’est pas assez représentative par rapport à des évènements censés être aléatoires sur les nœuds et la deuxième coûte cher et ne supporte pas les changements. La simulation est un bon compromis car il est possible de la reproduire dans le temps en modifiant les paramètres facilement tout en contrôlant les dépenses liées au coût de développement. Un des désavantages de la simulation est que certains phénomènes physiques sont très difficiles (voire impossible) à définir.

Aujourd'hui, plusieurs systèmes d'exploitation sont utilisés sur ces capteurs pour pouvoir faire des opérations liées aux communications, aux récupérations de données et aux agrégations de celles-ci. [http://fr.wikipedia.org/wiki/Contiki Contiki] est l'un des plus utilisés.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé [http://www.contiki-os.org/start.html#start-cooja Cooja] pour simuler le comportement d’un réseau de capteurs par rapport aux algorithmes de routages des paquets, de la disposition des capteurs dans le réseau, les propriétés de l’environnement… Ce simulateur est fourni par l'organisation qui développe Contiki pour pouvoir émuler cet OS au niveau hardware et ainsi pouvoir réutiliser les codes simulés sur des capteurs réels.

==Utilisateurs cibles==

Les utilisateurs cibles sont principalement des chercheurs, stagiaires utilisant le simulateur Cooja. Ensuite, les autres utilisateurs seront les personnes lambda voulant utiliser ce logiciel car il sera diffusé avec une licence libre.

==Description==

L'objectif est faire un logiciel permettant de configurer et de répéter une expérience, de suivre les différentes étapes de l'expérience lors de la simulation et d'interpréter les résultats obtenus. Le logiciel doit être « user friendly », avec une interface graphique. De plus, dans la mesure du possible, on essayera de le rendre générique, c'est à dire utilisable pour d'autres protocoles que les deux testés dans le cadre de ce projet. Il sera ainsi susceptible d'être réutilisé pour d'autres études.

Le travail à réaliser peut être présenté en trois modules :
*Partie configuration : Saisir des paramètres voulus pour la simulation, le nombre de simulations voulues pour pouvoir faire des statistiques associées, construction de fichier de configuration .xml (scénario). Cette partie pourra aussi afficher la configuration/répartition des capteurs dans la salle/du bâtiment : une carte de la salle affiche leur position.
*Partie suivi de la simulation (qui peut durer très longtemps, des semaines) : donne le statut de la simulation. Par exemple : Simulation avec COOJA à partir du scénario (répéter plusieurs fois pour augmenter la confiance)
*Partie résultat : elle peut être décomposée en 2 sous parties :
**Choisir les données que l'on veut afficher (choix des différents graphes avec différents paramètres, choix de l'échelle, observation d'une simulation particulière ou application d'une fonction statistique aux données particulière)
**Afficher les graphes et les données de sortie. Résultat + script pour analyser le résultat.

L'outil actuel se fait en plusieurs étapes séparées par des lignes de commande tapées manuellement. Ceci n'est pas automatisé et est destiné principalement à l'utilisateur expérimenté.
Le but de notre projet est de développer un outil qui automatise le processus de simulation comprenant la configuration, l'exécution et l'analyse de résultat sous forme d'une interface utilisateur interactive. Il sera important de concevoir une architecture flexible, modulable et facile à étendre pour le développement ultérieur.

== Fonctionnalités à développer ==

=== Product Backlog ===
<center>
{| class="wikitable centre" width="80%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Description
! scope=col | Complexité
! scope=col | Priorité
|-
| width="12%" |
Configuration
| width="54%" |
L'utilisateur veut choisir la configuration qu'il veut pour l'expérience (protocole, nombre de simulations, loi de probabilité des événements...)
| width="12%" |
12
| width="12%" |
30
|-
| width="12%" |
Monitoring
| width="38%" |
L'utilisateur surveille l'état de l'exécution de la simulation en temps réel.
| width="12%" |
10
| width="12%" |
5
|-
| width="12%" |
Interruption
| width="38%" |
L'utilisateur interrompt l’expérience.
| width="12" |
3
| width="12%" |
20
|-
| width="12%" |
Répétitions
| width="54%" |
L'utilisateur détermine le nombre de fois qu'une simulation est répétée durant une expérience (pour augmenter l'intervalle de confiance).
| width="12%" |
2
| width="12%" |
30
|-
| width="12%" |
Topologie
| width="54%" |
L'utilisateur voit la topologie du réseau (répartition des capteurs dans la salle / le bâtiment)
| width="12%" |
4
| width="12%" |
15
|-
| width="12%" |
Résultat
| width="54%" |
L'utilisateur observe en temps réel (unité de temps=une simulation) les graphes qu'il voulait lors de la configuration.
| width="12%" |
18
| width="12%" |
35
|-
| width="12%" |
Scheduler
| width="54%" |
L'utilisateur peut programmer des périodes d'exécution pour son expérience (le simulateur n'exécute l'expérience que la nuit, le PC a plus de ressources le journée)
| width="12%" |
30
| width="12%" |
20
|-
| width="12%" |
Format
| width="54%" |
Les fichiers d'entrées / sorties doivent être génériques
| width="12%" |
20
| width="12%" |
25
|}
</center>

=== Aspects Techniques ===

* Langage C et bibliothèque graphique GTK (et gestion des threads)
* Bibliothèques dynamiques
* Compilation du code utilisateur pour la topologie
* Basé sur le noyau Cooja avec Java Native Interface (JNI)
* Gnuplot
* Json-glib

== L'équipe ==

Ce projet s'inscrit dans un cadre pédagogique précis. Un encadrant joue le rôle de client, un autre de tuteur. Le projet s'effectue en groupe et met en place des méthodes de gestion de projet.

=== Encadrants ===
==== Clients ====
* Bernard Tourancheau
* Mališa Vučinić
==== Tuteur ====
* Didier Donsez

=== Etudiants ===
* Chef de projet : Noé-Jean Caramelli
* Minh Quan Ho
* Florian Lévêque

==== Répartitions des tâches ====
[[Image:Taches2.png|1000px|thumb|center|Répartition des tâches]]

== Le produit ==

=== Architecture logicielle ===
[[Image:Coconode_architecture.png|300px|thumb|right|Architecture Coconode]]

Coconode est composé de 4 parties différentes :
* Interface Graphique
* Architecture interne
** Configuration
** Exécution
** Statistique

L'architecture se base sur des modules existants (Générateur de topologie et noyau de simulation Cooja) utilisés dans l'outil existant. Ces modules ont du être intégré dans l'architecture pour pouvoir les réutiliser dans le nouvel outil.
La séparation des différentes parties a été faite pour isoler chaque partie réalisant les mêmes tâches. Cela facilite le développement et les modification future.
Cela permet aussi l'utilisation de threads pour paralléliser les différents traitement, pour ne pas bloquer la GUI lors d'un gros traitement dans l'exécution ou dans la partie statistique par exemple.

La GUI est liée à chaque partie car elle est utilisée en entrée pour que l'utilisateur puisse définir les données de simulation (voir partie Configuration) et en sortie pour que le contrôleur et l'affichage statistique puisse afficher des retours (voir Partie Exécution et Statistique).

==== Interface Graphique ====
Cette interface basée sur la librairie GTK permet à l'utilisateur d'interagir avec le noyau de simulation Cooja.

==== Architecture interne ====
L'architecture interne de Coconode comprend trois parties :

===== Partie Configuration =====
[[Image:Configurateur_coconode.png|250px|thumb|right|Configuration]]

* Personnalisation de la simulation :
# Durée de simulation
# Planification
# Nombre de simulations
# Choix du protocole de routage (Ici c'est load, un protocole de routage français)
Cette partie est lié au module Jsonner qui permet d'exporter ou importer ces paramètres au format JSON.
[[Image:Topologie_coconode.png|250px|thumb|right|Générateur de topologie]]

* Génération et visualisation de la topologie :
# Sélectionner les paramètres de la topologie :
## Nombre de noeuds
## Pourcentage de capteurs (qui récupèrent une donnée physique)
## Pourcentage d'actuateurs (qui réalisent une action)
## Sélectionner les fichiers utilisateurs qui génèrent une topologie selon un modèle précis (représentation d'une maison ...)
# Générer la topologie et visualiser le résultat

Après avoir entré toutes les informations précédentes et généré une topologie de réseaux de capteurs, ces informations seront passées au module d'exécution qui va la prendre en charge et l'exécuter en temps voulu.

===== Partie Exécution =====
[[Image:Coconode_scheduler.png |250px|thumb|right|Scheduler]]
L'exécution des simulations doit se faire dans un ordre précis défini grâce à l'interface. Cet ordre mélange un ordre temporel et un ordre de définition, en effet, l'utilisateur peut définir un délai de début de simulation en plus de l'ordre de définition de celle-ci. Il faut donc avoir une file d'attente des simulations.
La file d'attente est une file asynchrone accessible par l'interface et par le contrôleur. Le contrôleur va l'utiliser pour ordonnancer les simulations et gérer l'ordre de départ de chaque simulation.

Ensuite, le contrôle doit être fait en temps réel. L'interface doit être toujours disponible pour l'utilisateurs afin qu'il puisse contrôler les simulations. Comme Cooja est un outil Java, il a fallu utiliser une bibliothèque nommé [http://fr.wikipedia.org/wiki/Java_Native_Interface Java Native Interface] qui permet de faire l'interfaçage entre du code C et du code Java. Cela permet de créer une [http://fr.wikipedia.org/wiki/Machine_virtuelle_Java JVM] personnalisée pour exécuter le noyau Cooja. Il est donc possible d'avoir un contrôle total de Cooja en accédant aux différentes classes présentes.

[[Image:Monitor_coconode.png|250px|thumb|right|Monitor]]
L'utilisateur aura un retour d'avancement de la simulation en cours ainsi qu'une liste des simulations à venir dans l'ordre de départ.

===== Partie Statistique =====
[[Image:Pstat.png |250px|thumb|right|Afficheur de résultat et statistiques]]

== Méthodes de gestion de projet ==

Nous utilisons d'une part une méthode de gestion de projets classique avec un Chef de projet, mais d'autre part, nous utilisons la méthode Agile/Scrum pour le développement du logiciel.

=== Scrum Master ===

Nous choisissions un scrum master fixe. En effet, nous avons un chef de projet qui a pour rôle d'être le point central de communication avec l'équipe. Or le scrum master est censé isoler l'équipe de l'extérieur. Si on prend un scrum master tournant, on aura un chef de projet, qui ne sera pas isolé de l'extérieur à cause de son rôle et qui ne sera pas scrum master. Ce n'est pas logique. Nous choisissons donc un scrum master fixe qui sera le chef de projet par soucis de cohérence.

=== Points avec les clients ===

Nous feront un point par semaine avec Bernard Tourancheau et Malisa Vucinic. Le rendez-vous hebdomadaire est fixé tous les jeudis à 15h. Ces rendez-vous serviront à faire le point sur l'avancement et à régler les éventuels problèmes qui pourraient nous bloquer. Un rendez-vous tous les 15 jours serait trop espacé en cas de problème.

=== Durée du stage ===

Le projet commence le 4 février et termine le 15 mars. Nous avons en réalité eu deux réunions avant le 4 février, mais nous n'avions que très peu de temps libre pour le projet la semaine d'avant. La semaine du 18 mars est celle de la soutenance du projet. Nous ne savons pas la date exacte de soutenance, nous ne plaçons donc pas de tâche

=== Sprints ===

Nous choisissons de faire des sprints de deux semaines. Cela nous semble un bon compromis entre un sprint trop long pendant lequel les tâches serait trop complexes et les problèmes s'accumuleraient, et un sprint trop court où nous n'aurions pas assez avancé pour que le sprint soit profitable, malgré le temps qu'il nous prend.

==== '''Sprint 3''' :11 Mars au 22 Mars ====
===== Sprint Backlog =====
<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Scheduler
| width="25%" |
20
| width="25%" |
15
|-
| width="50%" |
Monitoring
| width="25%" |
5
| width="25%" |
3
|-
| width="50%" |
Interruption d'une simulation
| width="25%" |
20
| width="25%" |
10
|-
| width="50%" |
Observation des résultats
| width="25%" |
35
| width="25%" |
8
|-
| width="50%" |
Contrôle d'une simulation
| width="25%" |
35
| width="25%" |
17
|-
| width="50%" |
Validation du logiciel
| width="25%" |
30
| width="25%" |
15
|-
| width="50%" |
Portabilité de l'outil
| width="25%" |
20
| width="25%" |
15
|}
</center>

===== Sprint retrospective =====

* Plus:
** Point de vue de conception et de technique avancé
** Connaissances de JNI
** Développement boosté
** Reprise de motivation

* A améliorer:
** Documentation
** Test de validation

* Moins:
** Bugs technique complexe
** Manque de réactivité aux bugs
** Deadline approché

==== Burndown Chart ====
[[Image:Burndownchart3_coconode.png|1000px|thumb|center|Burndown Chart Sprint 2]]

==== '''Sprint 2''' :18 Février au 8 Mars ====
===== Sprint Backlog =====

<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Générateur de topologie
| width="25%" |
15
| width="25%" |
15
|-
| width="50%" |
Configuration des simulations
| width="25%" |
30
| width="25%" |
10
|-
| width="50%" |
Importer/Exporter données
| width="25%" |
25
| width="25%" |
20
|-
| width="50%" |
Contrôle d'une simulation
| width="25%" |
35
| width="25%" |
25
|-
| width="50%" |
Observation des résultats
| width="25%" |
35
| width="25%" |
25
|}
</center>

===== Sprint retrospective =====

* Plus:
** Entraide lors de bugs
** Séparation des modules facilitant le développement

*A améliorer
** Compréhension de la hiérarchie et fonctionnement de Cooja

* Moins:
** Répartition du temps
** Bugs techniques et complexe.
** Perturbation du rythme de travail lié à:
*** Problème de santé
*** Manque de motivation
*** Problème de l'ordinateur

==== Burndown Chart ====
[[Image:BDCSprint2.jpg|1000px|thumb|center|Burndown Chart Sprint 2]]
==== '''Sprint 1''' : 29 Janvier au 15 Février ====
===== Sprint Backlog =====

<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Cahier des charges
| width="25%" |
13
| width="25%" |
15
|-
| width="50%" |
Architecture
| width="25%" |
13
| width="25%" |
25
|-
| width="50%" |
Prototype de l'IHM
| width="25%" |
8
| width="25%" |
25
|-
| width="50%" |
Prise en main de l'outil
| width="25%" |
10
| width="25%" |
10
|}
</center>

===== Sprint retrospective =====
* Plus:
** Rédaction du cahier des charges
** Utilisation de GIT

*A améliorer
** Répartition des tâches
** Mise à jours de Trello

* Moins:
** Prise en main de l'outil laborieuse
** Daily stand up oubliée

==== Burndown Chart ====
[[Image:BDCSprint1.jpg|1000px|thumb|center|Burndown Chart Sprint 1]]

=== Outils de suivi ===
Pour permettre de suivre l'avancement d'un sprint du projet, nous utilisons des outils de Scrum :
*Todo-List ;
*Burn down chart.

=== Tests et validation ===
Comme nous utilisons la méthode Scrum pour la gestion de projet, chaque développeur fera des tests « unitaires » sur les stories qu'il développera. Ils vont permettre d'assurer de l’intégrité du code pour certaines fonctionnalités, la bonne qualité du code. Ils ne permettent pas de vérifier si le code répond aux besoins du client.
Les tests permettant de garantir au product owner la fiabilité et le respect des spécifications sont les tests d'acceptation. Chaque test sera développé ou défini grâce aux conditions de satisfaction données par celui-ci.

== Choix non fonctionnels ==
===Licence ===
Le code sera placé sous la licence libre GNU GPL afin de permettre au projet d'être réutilisé et amélioré.
La documentation et autres ressources éventuellement créées pour le projet seront placées sous licence Creative Commons CC-BY-NC-SA afin de permettre également une réutilisation et une évolution libres.
=== Gestionnaire de version===
Nous choisissons GIT, un gestionnaire de version récent, évolué et de plus en plus répandu. C'est le gestionnaire de version déjà utilisé pour le projet.
===Documentation===
Nous prévoyons différents éléments de documentation pour permettre une bonne continuité du projet.
====Documents de conception====
*La documentation sera séparée en plusieurs fichiers :
**Conception IHM ;
**Conception système (architecture, librairies, technologies).

====Manuels====
*Manuel développeur ;
*Manuel utilisateur.

====Génération automatique de documentation sur le code====
Nous utiliserons un générateur de documentation capable de produire une documentation logicielle à partir du code source du programme, comme Doxygen.

====Convention de codage====

* Indentation obligatoire (utilisation du caractère tabulation) ;
* L'accolade ouvrante doit être placée à la ligne suivante ;
* Les commentaires doivent être écrits en anglais ;
* Tous les fichiers doivent être codés au format UTF-8 ;
* Les lignes ne doivent (dans la mesure du possible) pas dépassées 80 caractères ;
* Le nom des fonctions seront plutôt des verbes, les variables seront des noms (en anglais) ;
Exemples :
**Procédure : draw_something ;
**Variable : a_variable ;
**Constante : A_CONSTANT.
*Chaque fonction doit être commenté selon deux règles :
**Une explication détaillée de l'utilité de la fonction doit être placé au dessus du corps de la fonction ;
**Chaque ligne de code complexe doit être commentée .
*Chaque fonction ne doit (dans la mesure du possible) n'implémenter qu'une seule tâche.

==TODO==
* Script to parse [http://air.imag.fr/mediawiki/images/a/a8/Coconode_cooja_output.txt COOJA log] in to [http://air.imag.fr/mediawiki/images/8/8a/Coconode_gnuplot_input.txt GNUplot format].
* Validation test
* Integrate Statistic module into Coconode (or add callback to launch Statistic module from Coconode)

Coconode

2013-03-23T01:01:27Z

Carameln: /* Partie Statistique */

[[Image:Coconode_interface.png|300px|thumb|right|Interface Coconode]]

==Git us !==

[https://bitbucket.org/noejean/coconode COCONODE on Git]

==Contexte==

Ce projet se place dans la continuité du travail de Malisa VUCINIC - thésard à l'équipe DRAKKA (LIG). Durant son projet de fin d'études, il a écrit un programme permettant de simuler le comportement de capteurs disposés dans une salle/un bâtiment. Le comportement étant basé sur deux protocoles de routage de données (RPL ou LOADng). Cependant, ce programme ne permet pas d'automatiser l'exécution d'un grand nombre de simulation, ce qui est nécessaire pour faire des statistiques. De plus, les données obtenues ne sont pas interprétées mais seulement regroupées de manière cohérente par un parseur. L’utilisateur est obligé de traiter lui-même ces données via un logiciel tiers d’analyse.

==Motivations==

Industrie, sécurité, transport, santé... Les capteurs sont de plus en plus utilisés dans notre quotidien. Organisé en réseau, ces capteurs permettent de récolter une multitude de données de toutes sortes. La majorité des applications impliquent le déploiement d'un grand nombre de nœuds (capteurs) dans une zone donnée. Cela implique un minimum de traitement pour communiquer entre eux et/ou avec une entité capable de les traiter. Cependant, une grande partie de ces équipements ne seront pas reliés à un réseau électrique ni à un réseau informatique à cause du coût d’installation et de raccordement. C’est pourquoi ils seront alimentés grâce à une batterie et devront communiquer via des transmissions radio. Le coût faible du déploiement et la durée de vie très longue des capteurs impliquent des contraintes matérielles liées à la mémoire, aux traitements et à la consommation d’énergie. La communication en est impactée car il faut consommer le moins possible tout en communiquant avec les autres. Il faut donc utiliser des protocoles de communications optimisés pour lui permettre d’être autonome tout en restant joignable via Internet. En effet, IPv6 est performant pour délivrer les données et router celle-ci, quel que soit le réseau, d’un émetteur vers un récepteur. De plus, au vu du nombre de capteurs déployés, il est nécessaire d’avoir une grande plage d’adresses disponible. Cependant, IP a été conçu pour des réseaux très puissants et possède, par exemple, des entêtes de tailles trop grandes pour un capteur. C’est pourquoi l’IETF a créé un standard nommé 6LowPAN qui définit des mécanismes d’encapsulation et de compression d’en-têtes permettant d’envoyer des paquets IPv6.
Afin de pouvoir tester et expérimenter de tels protocoles, plusieurs méthodes sont possibles : théorie, simulation, modélisation. La théorie permet d’avoir un résultat rapidement par rapport aux autres méthodes. La modélisation est la meilleure solution par rapport à la précision des résultats. Cependant, la première n’est pas assez représentative par rapport à des évènements censés être aléatoires sur les nœuds et la deuxième coûte cher et ne supporte pas les changements. La simulation est un bon compromis car il est possible de la reproduire dans le temps en modifiant les paramètres facilement tout en contrôlant les dépenses liées au coût de développement. Un des désavantages de la simulation est que certains phénomènes physiques sont très difficiles (voire impossible) à définir.

Aujourd'hui, plusieurs systèmes d'exploitation sont utilisés sur ces capteurs pour pouvoir faire des opérations liées aux communications, aux récupérations de données et aux agrégations de celles-ci. [http://fr.wikipedia.org/wiki/Contiki Contiki] est l'un des plus utilisés.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé [http://www.contiki-os.org/start.html#start-cooja Cooja] pour simuler le comportement d’un réseau de capteurs par rapport aux algorithmes de routages des paquets, de la disposition des capteurs dans le réseau, les propriétés de l’environnement… Ce simulateur est fourni par l'organisation qui développe Contiki pour pouvoir émuler cet OS au niveau hardware et ainsi pouvoir réutiliser les codes simulés sur des capteurs réels.

==Utilisateurs cibles==

Les utilisateurs cibles sont principalement des chercheurs, stagiaires utilisant le simulateur Cooja. Ensuite, les autres utilisateurs seront les personnes lambda voulant utiliser ce logiciel car il sera diffusé avec une licence libre.

==Description==

L'objectif est faire un logiciel permettant de configurer et de répéter une expérience, de suivre les différentes étapes de l'expérience lors de la simulation et d'interpréter les résultats obtenus. Le logiciel doit être « user friendly », avec une interface graphique. De plus, dans la mesure du possible, on essayera de le rendre générique, c'est à dire utilisable pour d'autres protocoles que les deux testés dans le cadre de ce projet. Il sera ainsi susceptible d'être réutilisé pour d'autres études.

Le travail à réaliser peut être présenté en trois modules :
*Partie configuration : Saisir des paramètres voulus pour la simulation, le nombre de simulations voulues pour pouvoir faire des statistiques associées, construction de fichier de configuration .xml (scénario). Cette partie pourra aussi afficher la configuration/répartition des capteurs dans la salle/du bâtiment : une carte de la salle affiche leur position.
*Partie suivi de la simulation (qui peut durer très longtemps, des semaines) : donne le statut de la simulation. Par exemple : Simulation avec COOJA à partir du scénario (répéter plusieurs fois pour augmenter la confiance)
*Partie résultat : elle peut être décomposée en 2 sous parties :
**Choisir les données que l'on veut afficher (choix des différents graphes avec différents paramètres, choix de l'échelle, observation d'une simulation particulière ou application d'une fonction statistique aux données particulière)
**Afficher les graphes et les données de sortie. Résultat + script pour analyser le résultat.

L'outil actuel se fait en plusieurs étapes séparées par des lignes de commande tapées manuellement. Ceci n'est pas automatisé et est destiné principalement à l'utilisateur expérimenté.
Le but de notre projet est de développer un outil qui automatise le processus de simulation comprenant la configuration, l'exécution et l'analyse de résultat sous forme d'une interface utilisateur interactive. Il sera important de concevoir une architecture flexible, modulable et facile à étendre pour le développement ultérieur.

== Fonctionnalités à développer ==

=== Product Backlog ===
<center>
{| class="wikitable centre" width="80%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Description
! scope=col | Complexité
! scope=col | Priorité
|-
| width="12%" |
Configuration
| width="54%" |
L'utilisateur veut choisir la configuration qu'il veut pour l'expérience (protocole, nombre de simulations, loi de probabilité des événements...)
| width="12%" |
12
| width="12%" |
30
|-
| width="12%" |
Monitoring
| width="38%" |
L'utilisateur surveille l'état de l'exécution de la simulation en temps réel.
| width="12%" |
10
| width="12%" |
5
|-
| width="12%" |
Interruption
| width="38%" |
L'utilisateur interrompt l’expérience.
| width="12" |
3
| width="12%" |
20
|-
| width="12%" |
Répétitions
| width="54%" |
L'utilisateur détermine le nombre de fois qu'une simulation est répétée durant une expérience (pour augmenter l'intervalle de confiance).
| width="12%" |
2
| width="12%" |
30
|-
| width="12%" |
Topologie
| width="54%" |
L'utilisateur voit la topologie du réseau (répartition des capteurs dans la salle / le bâtiment)
| width="12%" |
4
| width="12%" |
15
|-
| width="12%" |
Résultat
| width="54%" |
L'utilisateur observe en temps réel (unité de temps=une simulation) les graphes qu'il voulait lors de la configuration.
| width="12%" |
18
| width="12%" |
35
|-
| width="12%" |
Scheduler
| width="54%" |
L'utilisateur peut programmer des périodes d'exécution pour son expérience (le simulateur n'exécute l'expérience que la nuit, le PC a plus de ressources le journée)
| width="12%" |
30
| width="12%" |
20
|-
| width="12%" |
Format
| width="54%" |
Les fichiers d'entrées / sorties doivent être génériques
| width="12%" |
20
| width="12%" |
25
|}
</center>

=== Aspects Techniques ===

* Langage C et bibliothèque graphique GTK (et gestion des threads)
* Bibliothèques dynamiques
* Compilation du code utilisateur pour la topologie
* Basé sur le noyau Cooja avec Java Native Interface (JNI)
* Gnuplot
* Json-glib

== L'équipe ==

Ce projet s'inscrit dans un cadre pédagogique précis. Un encadrant joue le rôle de client, un autre de tuteur. Le projet s'effectue en groupe et met en place des méthodes de gestion de projet.

=== Encadrants ===
==== Clients ====
* Bernard Tourancheau
* Mališa Vučinić
==== Tuteur ====
* Didier Donsez

=== Etudiants ===
* Chef de projet : Noé-Jean Caramelli
* Minh Quan Ho
* Florian Lévêque

==== Répartitions des tâches ====
[[Image:Taches2.png|1000px|thumb|center|Répartition des tâches]]

== Le produit ==

=== Architecture logicielle ===
[[Image:Coconode_architecture.png|300px|thumb|right|Architecture Coconode]]

Coconode est composé de 4 parties différentes :
* Interface Graphique
* Architecture interne
** Configuration
** Exécution
** Statistique

L'architecture se base sur des modules existants (Générateur de topologie et noyau de simulation Cooja) utilisés dans l'outil existant. Ces modules ont du être intégré dans l'architecture pour pouvoir les réutiliser dans le nouvel outil.
La séparation des différentes parties a été faite pour isoler chaque partie réalisant les mêmes tâches. Cela facilite le développement et les modification future.
Cela permet aussi l'utilisation de threads pour paralléliser les différents traitement, pour ne pas bloquer la GUI lors d'un gros traitement dans l'exécution ou dans la partie statistique par exemple.

La GUI est liée à chaque partie car elle est utilisée en entrée pour que l'utilisateur puisse définir les données de simulation (voir partie Configuration) et en sortie pour que le contrôleur et l'affichage statistique puisse afficher des retours (voir Partie Exécution et Statistique).

==== Interface Graphique ====
Cette interface basée sur la librairie GTK permet à l'utilisateur d'interagir avec le noyau de simulation Cooja.

==== Architecture interne ====
L'architecture interne de Coconode comprend trois parties :

===== Partie Configuration =====
[[Image:Configurateur_coconode.png|250px|thumb|right|Configuration]]

* Personnalisation de la simulation :
# Durée de simulation
# Planification
# Nombre de simulations
# Choix du protocole de routage (Ici c'est load, un protocole de routage français)
Cette partie est lié au module Jsonner qui permet d'exporter ou importer ces paramètres au format JSON.
[[Image:Topologie_coconode.png|250px|thumb|right|Générateur de topologie]]

* Génération et visualisation de la topologie :
# Sélectionner les paramètres de la topologie :
## Nombre de noeuds
## Pourcentage de capteurs (qui récupèrent une donnée physique)
## Pourcentage d'actuateurs (qui réalisent une action)
## Sélectionner les fichiers utilisateurs qui génèrent une topologie selon un modèle précis (représentation d'une maison ...)
# Générer la topologie et visualiser le résultat

Après avoir entré toutes les informations précédentes et généré une topologie de réseaux de capteurs, ces informations seront passées au module d'exécution qui va la prendre en charge et l'exécuter en temps voulu.

===== Partie Exécution =====
[[Image:Coconode_scheduler.png |250px|thumb|right|Scheduler]]
L'exécution des simulations doit se faire dans un ordre précis défini grâce à l'interface. Cet ordre mélange un ordre temporel et un ordre de définition, en effet, l'utilisateur peut définir un délai de début de simulation en plus de l'ordre de définition de celle-ci. Il faut donc avoir une file d'attente des simulations.
La file d'attente est une file asynchrone accessible par l'interface et par le contrôleur. Le contrôleur va l'utiliser pour ordonnancer les simulations et gérer l'ordre de départ de chaque simulation.

Ensuite, le contrôle doit être fait en temps réel. L'interface doit être toujours disponible pour l'utilisateurs afin qu'il puisse contrôler les simulations. Comme Cooja est un outil Java, il a fallu utiliser une bibliothèque nommé [http://fr.wikipedia.org/wiki/Java_Native_Interface Java Native Interface] qui permet de faire l'interfaçage entre du code C et du code Java. Cela permet de créer une [http://fr.wikipedia.org/wiki/Machine_virtuelle_Java JVM] personnalisée pour exécuter le noyau Cooja. Il est donc possible d'avoir un contrôle total de Cooja en accédant aux différentes classes présentes.

[[Image:Monitor_coconode.png|250px|thumb|right|Monitor]]
L'utilisateur aura un retour d'avancement de la simulation en cours ainsi qu'une liste des simulations à venir dans l'ordre de départ.

===== Partie Statistique =====
[[Image:Pstat.png |250px|thumb|right|Scheduler]]

== Méthodes de gestion de projet ==

Nous utilisons d'une part une méthode de gestion de projets classique avec un Chef de projet, mais d'autre part, nous utilisons la méthode Agile/Scrum pour le développement du logiciel.

=== Scrum Master ===

Nous choisissions un scrum master fixe. En effet, nous avons un chef de projet qui a pour rôle d'être le point central de communication avec l'équipe. Or le scrum master est censé isoler l'équipe de l'extérieur. Si on prend un scrum master tournant, on aura un chef de projet, qui ne sera pas isolé de l'extérieur à cause de son rôle et qui ne sera pas scrum master. Ce n'est pas logique. Nous choisissons donc un scrum master fixe qui sera le chef de projet par soucis de cohérence.

=== Points avec les clients ===

Nous feront un point par semaine avec Bernard Tourancheau et Malisa Vucinic. Le rendez-vous hebdomadaire est fixé tous les jeudis à 15h. Ces rendez-vous serviront à faire le point sur l'avancement et à régler les éventuels problèmes qui pourraient nous bloquer. Un rendez-vous tous les 15 jours serait trop espacé en cas de problème.

=== Durée du stage ===

Le projet commence le 4 février et termine le 15 mars. Nous avons en réalité eu deux réunions avant le 4 février, mais nous n'avions que très peu de temps libre pour le projet la semaine d'avant. La semaine du 18 mars est celle de la soutenance du projet. Nous ne savons pas la date exacte de soutenance, nous ne plaçons donc pas de tâche

=== Sprints ===

Nous choisissons de faire des sprints de deux semaines. Cela nous semble un bon compromis entre un sprint trop long pendant lequel les tâches serait trop complexes et les problèmes s'accumuleraient, et un sprint trop court où nous n'aurions pas assez avancé pour que le sprint soit profitable, malgré le temps qu'il nous prend.

==== '''Sprint 3''' :11 Mars au 22 Mars ====
===== Sprint Backlog =====
<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Scheduler
| width="25%" |
20
| width="25%" |
15
|-
| width="50%" |
Monitoring
| width="25%" |
5
| width="25%" |
3
|-
| width="50%" |
Interruption d'une simulation
| width="25%" |
20
| width="25%" |
10
|-
| width="50%" |
Observation des résultats
| width="25%" |
35
| width="25%" |
8
|-
| width="50%" |
Contrôle d'une simulation
| width="25%" |
35
| width="25%" |
17
|-
| width="50%" |
Validation du logiciel
| width="25%" |
30
| width="25%" |
15
|-
| width="50%" |
Portabilité de l'outil
| width="25%" |
20
| width="25%" |
15
|}
</center>

===== Sprint retrospective =====

* Plus:
** Point de vue de conception et de technique avancé
** Connaissances de JNI
** Développement boosté
** Reprise de motivation

* A améliorer:
** Documentation
** Test de validation

* Moins:
** Bugs technique complexe
** Manque de réactivité aux bugs
** Deadline approché

==== Burndown Chart ====
[[Image:Burndownchart3_coconode.png|1000px|thumb|center|Burndown Chart Sprint 2]]

==== '''Sprint 2''' :18 Février au 8 Mars ====
===== Sprint Backlog =====

<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Générateur de topologie
| width="25%" |
15
| width="25%" |
15
|-
| width="50%" |
Configuration des simulations
| width="25%" |
30
| width="25%" |
10
|-
| width="50%" |
Importer/Exporter données
| width="25%" |
25
| width="25%" |
20
|-
| width="50%" |
Contrôle d'une simulation
| width="25%" |
35
| width="25%" |
25
|-
| width="50%" |
Observation des résultats
| width="25%" |
35
| width="25%" |
25
|}
</center>

===== Sprint retrospective =====

* Plus:
** Entraide lors de bugs
** Séparation des modules facilitant le développement

*A améliorer
** Compréhension de la hiérarchie et fonctionnement de Cooja

* Moins:
** Répartition du temps
** Bugs techniques et complexe.
** Perturbation du rythme de travail lié à:
*** Problème de santé
*** Manque de motivation
*** Problème de l'ordinateur

==== Burndown Chart ====
[[Image:BDCSprint2.jpg|1000px|thumb|center|Burndown Chart Sprint 2]]
==== '''Sprint 1''' : 29 Janvier au 15 Février ====
===== Sprint Backlog =====

<center>
{| class="wikitable centre" width="30%"
|+ Product Backlog
|-
! scope=col | Nom
! scope=col | Valeurs/Importance
! scope=col | Estimation initiale
|-
| width="50%" |
Cahier des charges
| width="25%" |
13
| width="25%" |
15
|-
| width="50%" |
Architecture
| width="25%" |
13
| width="25%" |
25
|-
| width="50%" |
Prototype de l'IHM
| width="25%" |
8
| width="25%" |
25
|-
| width="50%" |
Prise en main de l'outil
| width="25%" |
10
| width="25%" |
10
|}
</center>

===== Sprint retrospective =====
* Plus:
** Rédaction du cahier des charges
** Utilisation de GIT

*A améliorer
** Répartition des tâches
** Mise à jours de Trello

* Moins:
** Prise en main de l'outil laborieuse
** Daily stand up oubliée

==== Burndown Chart ====
[[Image:BDCSprint1.jpg|1000px|thumb|center|Burndown Chart Sprint 1]]

=== Outils de suivi ===
Pour permettre de suivre l'avancement d'un sprint du projet, nous utilisons des outils de Scrum :
*Todo-List ;
*Burn down chart.

=== Tests et validation ===
Comme nous utilisons la méthode Scrum pour la gestion de projet, chaque développeur fera des tests « unitaires » sur les stories qu'il développera. Ils vont permettre d'assurer de l’intégrité du code pour certaines fonctionnalités, la bonne qualité du code. Ils ne permettent pas de vérifier si le code répond aux besoins du client.
Les tests permettant de garantir au product owner la fiabilité et le respect des spécifications sont les tests d'acceptation. Chaque test sera développé ou défini grâce aux conditions de satisfaction données par celui-ci.

== Choix non fonctionnels ==
===Licence ===
Le code sera placé sous la licence libre GNU GPL afin de permettre au projet d'être réutilisé et amélioré.
La documentation et autres ressources éventuellement créées pour le projet seront placées sous licence Creative Commons CC-BY-NC-SA afin de permettre également une réutilisation et une évolution libres.
=== Gestionnaire de version===
Nous choisissons GIT, un gestionnaire de version récent, évolué et de plus en plus répandu. C'est le gestionnaire de version déjà utilisé pour le projet.
===Documentation===
Nous prévoyons différents éléments de documentation pour permettre une bonne continuité du projet.
====Documents de conception====
*La documentation sera séparée en plusieurs fichiers :
**Conception IHM ;
**Conception système (architecture, librairies, technologies).

====Manuels====
*Manuel développeur ;
*Manuel utilisateur.

====Génération automatique de documentation sur le code====
Nous utiliserons un générateur de documentation capable de produire une documentation logicielle à partir du code source du programme, comme Doxygen.

====Convention de codage====

* Indentation obligatoire (utilisation du caractère tabulation) ;
* L'accolade ouvrante doit être placée à la ligne suivante ;
* Les commentaires doivent être écrits en anglais ;
* Tous les fichiers doivent être codés au format UTF-8 ;
* Les lignes ne doivent (dans la mesure du possible) pas dépassées 80 caractères ;
* Le nom des fonctions seront plutôt des verbes, les variables seront des noms (en anglais) ;
Exemples :
**Procédure : draw_something ;
**Variable : a_variable ;
**Constante : A_CONSTANT.
*Chaque fonction doit être commenté selon deux règles :
**Une explication détaillée de l'utilité de la fonction doit être placé au dessus du corps de la fonction ;
**Chaque ligne de code complexe doit être commentée .
*Chaque fonction ne doit (dans la mesure du possible) n'implémenter qu'une seule tâche.

==TODO==
* Script to parse [http://air.imag.fr/mediawiki/images/a/a8/Coconode_cooja_output.txt COOJA log] in to [http://air.imag.fr/mediawiki/images/8/8a/Coconode_gnuplot_input.txt GNUplot format].
* Validation test
* Integrate Statistic module into Coconode (or add callback to launch Statistic module from Coconode)

File:Pstat.png

2013-03-23T01:00:28Z

Carameln:

File:Presentation coconode.pdf

2013-03-21T17:36:18Z

Carameln: uploaded a new version of "File:Presentation coconode.pdf"

Soutenances Projet RICM 5 2012-2013

2013-03-21T10:13:48Z

Carameln: /* Planning */

==Planning==

{|class="wikitable alternance"
|+ Planning Jeudi 21/03 P257 ([[Polytech Grenoble]])
|-
|
!scope="col"| Horaire
!scope="col"| Projet
!scope="col"| Encadrant(s)
!scope="col"| Etudiant(s)
!scope="col"| Documents
|-
!scope="row"| 1
| 13H00-13H45
| [[RobAIR2013]]
| [[User:Donsez|Didier Donsez]]
| NICOLACCINI MICKAEL , ALEXANDRE ARTHUR, Salem HARRACHE , PAZ HERNANDEZ ELIZABETH
| [http://air.imag.fr/mediawiki/index.php/RobAIR2013-RICM5-Suivi Fiche suivi RobAIR] - [[Media:Projet_RobAIR2013_diapo.pdf |Transparents]] - [[Media:Flyer-RobAIR.pdf|Flyer]] - [[Media:Poster-RobAIR.pdf|Poster]] [http://youtu.be/-3mbR5M8lzw Video] - [http://robair.quicker.fr/ Site web]
|-
!scope="row"| 2
| 13H45-14H30
| Armind
| Renaud Blanch, Nicolas Glade, Nicolas Vuillerme, Didier Pradon (APHP Garches)
| CHEVALLIER MARIE (PL), FALL YACINE, LU XIAO
| [http://air.imag.fr/mediawiki/index.php/Armind Fiche de suivi Armind] & [[Media:presentationArmind.ppt|transparents]] & [[Media:flyersArmind.ppt|flyers]] & [[Media:posterArmind.jpg|poster]]
|-
!scope="row"| 3
| 14H30-14H45
| Pause
|-
!scope="row"| 4
| 14H45-15H15
| [[Fusion multi-capteurs pour table tactile]]
| Renaud Blanch, Renaud Collin
| RAOUX MAXENCE (PL), DAUVERGNE LEOPOLD
| [http://air.imag.fr/mediawiki/index.php/Fusion_multi-capteurs_pour_table_tactile fiche suivi] & [http://air.imag.fr/mediawiki/images/b/be/Sonar_TablePresentation.pdf Transparents] & [http://air.imag.fr/mediawiki/images/0/07/FliyerSonarTable.pdf Flyer] & [http://air.imag.fr/mediawiki/images/thumb/2/2f/PosterSonarTable.jpg/600px-PosterSonarTable.jpg Poster] & [http://www.youtube.com/watch?v=8VKd9UdPNmc Video]
|-
!scope="row"| 5
| 15H15-16H00
| [[Projet Réseaux de Capteurs]]
| Bernard Tourancheau
| CARAMELLI NOE-JEAN (PL), LEVEQUE FLORIAN, HO MINH QUAN
| [[fiche suivi ...]] & [[Media:Presentation_coconode.pdf | transparents]] & [[Media:Coconode_flyer.pdf | Flyer]] & [[Media:Coconode_poster.pdf | Poster]] & [[video ...]]
|-
!scope="row"| 6
| 16H00-16H30
| [[OAR Cloud Computing 2013]]
| Olivier Richard
| MERCIER MICHAEL (PL)
| [[Proj-2012-2013-OAR-Cloud | fiche suivi]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]
|}

{|class="wikitable alternance"
|+ Planning Vendredi 22/03 P249 ([[Polytech Grenoble]])
|-
|
!scope="col"| Horaire
!scope="col"| Projet
!scope="col"| Encadrant(s)
!scope="col"| Etudiant(s)
!scope="col"| Documents
|-
!scope="row"| 1
| 14H30-15H15
| [[Projet 2013 : Interactive Digital Signage]]
| [[User:Donsez|Didier Donsez]]
| FOURURE FLORIAN, BISCH SIMON (PL), CLAVELIN AURELIEN
| [[fiche suivi ...]] & [http://air.imag.fr/mediawiki/index.php/File:-BISCH-FOURURE-CLAVELIN--RICM5-IDS-Presentation.pdf transparents] & [[flyer ...]] & [[poster ...]] & [[video ...]]
|-
!scope="row"| 2
| 15H15-16H00
| [http://www.cervin.org/wiki/index.php?title=Prototype_SmartPhone Projet CERVIN de "Rehab Lab"]
| Renaud Blanch, Francois Letellier de l'association [http://www.aconit.org/ ACONIT], le [http://www.ccsti-grenoble.org/ CCSTI Grenoble]
| OSWALD CAMILLE, WIRTH CLÉMENT, PRAK SORIYA, GNATTO-BAHIE CHRISTOPHER
| [http://www.cervin.org/wiki/index.php?title=Prototype_SmartPhone Wiki projet Cervin] & [[Media:cervinPres.ppt]] & [[flyer ...]] & [[poster ...]] & [[video ...]]
|-
!scope="row"| 3
| 16H00-16H45
| [[Développement d'une appli mobile pour urgentistes en Afrique utilisant la synthèse vocale]]
| Laurent Besacier, F. Camara et la [http://voxygen.fr/ société Voxygen]
| ELOY FABIEN, NGOUALA ROLLY, VIGIER SYLVAIN, GU QIKAI, SEGALA JOACHIM
| [[fiche suivi ...]] & [[transparents ...]] & [[flyer ...]] & [[poster ...]] & [[video ...]]
|}

==Recommandations==
* Prévenez vos tuteurs de votre horaire de passage pour qu'ils assistent à votre soutenance (ainsi que des éventuels changements).
* La durée des soutenances est STRICTEMENT 45 minutes (et 30 minutes pour Michael Mercier)
* Chaque soutenance comporte 20 minutes de présentation, 15 minutes de démonstration suivi de 10 minutes de questions/réponse
* La présentation doit aborder l'ensemble des aspects du projet (contexte, technique, gestion, ...)
* Les transparents doivent être ajoutés à cette page avant le Jeudi matin
* Des ''flyers'' (3 volets d'un A4) et un poster (A4 ou 2*A4 ou A3) devront être apportés puis laissés dans la salle AIR.

==Conseils==
* Le chef de projet orchestre
* Répétez plusieurs fois et chronométrez vous !
* Répartissez vous la parole pendant la présentation et la démo
* Attention à l' ''effet démo'' : prévoyez une vidéo de secours

Jean Gabès, créateur de Shinken.

EA2012-Shinken

2012-12-24T14:42:13Z

Carameln:

Carameln: /* Description du projet */

== Équipe ==
Qikai Gu 
Xiao Lu 
Noé-Jean Caramelli 
 
'''Rôles : répartition des responsabilités''' 
Chef de projet : Noé-Jean 
Auteur : Noé-Jean 
Concepteur d'interaction : Noé-Jean, Xiao 
Développeur : Xiao 
Expert en utilisabilité : Qikai 
Graphiste : Qikai 

== Page de suivi ==
----
== Description du projet ==

Site web d'e-commerce pour la vente de sapins de Noël.

== Méthode Aglie et Scrum ==
=== Choix de fonctionnement et justification ===
Nous avons choisi de prendre le chef de projet pour ScrumMaster. 
''Justification : ''
Il faut noter que l'on nous a demandé de nous organiser à la fois de façon traditionnelle et selon la méthode Scrum.
Le rôle du ScrumMaster est "de la protéger des perturbations extérieures. Il est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de l'équipe." (Wikipedia). Le chef de projet a aussi pour rôle de gérer les perturbations extérieures, et en principe il a aussi un rôle hiérarchique. C'est toujours le chef de projet qui doit envoyer les livrables demandés par l'équipe pédaggique (constat). Pour concilier au mieux les deux méthodes d'organisation que nous devons appliquer, nous avons choisi de prendre le chef de projet pour ScrumMaster et de gommer l'aspect hiérarchie. Chaque membre de l'équipe a des responsablilités et un pouvoir d'arbitrage déterminé (voir les rôles définis ci-dessus), mais aucun n'a plus de pouvoir qu'un autre.

Nous avons choisi une durée de sprint de 15 jours. 
''Justification : ''
Plusieurs critères nous orientent vers différents choix pour la durée du sprint. Nous avons affectés un coefficient à chacun d'eux puis avons fait la moyenne pondérée de durée de sprint :

(coef pour le critère*nb semaines/sprints) 
(0.3*1) La courte durée du projet, de 2 mois (date de fin de la release fixée au 18 décembre 2012), nous insite à choisir des sprints d'1 semaine. 
(0.3*3) La faible disponibilité de l'équipe de développement sur une semaine, compte tenu du cadre scolaire, nous oriente vers des sprints de 3 semaines. 
(0.15*3) L'effectif réduit de l'équipe de développement, compte tenu du coût supplémentaire engendré par la préparation d'un produit partiel (démo+rétrospective), nous oriente vers des sprints de 3 semaines. 
(0.1*3) La stabilité de l'architecture (sujette à modifications sur conseils dans un cadre pédagogique, méconnaissance des technologies utilisées) nous insite à choisir un sprint de 3 semaines. 
(0.1*3) La durée maximum pour prendre en compte un changement (taille équipe, disponibilité, perturbations) nous oriente vsers des sprints de 3 semaines. 
(0.05*1) Le maintient de la motivation de l'équipe nous oriente vers un sprint d'1 semaine. 
(0) L'implication des clients et utilisateurs n'est pas comptabilisée. 
Si l'équipe pédagogique (PO) est disponible physiquement une fois par semaine, les utilisateurs réellement ciblés sont inaccessibles ! 
 
Nous obtenons une durée de sprint de 2.3 semaines, arrondie à 2 semaines. 
 

=== Rétrospectives ===
Pour les prévisions pour l'application de la méthode Agile, et par rapport aux informations qui nous ont été communiquées, nous retenons ces dates : 
Ce sont les dates de fin de chaque sprint, toutes les 2 semaines
==== mardi 9 octobre 2012 ====
Pas de développement 

==== mardi 23 octobre 2012 ====
Première 15e de développement 
*Rétrospective : 
**prévu : prototype de front-end, avec login et liste de produit (JSP) ; EJB basique pour login ; Mise en place d'un accès à une BD 
**réalisé : front end JSP OK, EJB ne fnctionnement pas, problèmes techniques ; donc, pas de temps pour la BD 
*Démo : démo fonctionnelle du front-end présentant le login/logout/inscription et une liste de deux produits. 

[mardi 30 octobre 2012 : vacances] 
==== mardi 13 novembre 2012 ====
*Rétrospective : 
**prévu : 
**réalisé : 
*Démo : 

==== mardi 27 novembre 2012 ====
*Rétrospective : 
**prévu : 
**réalisé : 
*Démo : 

==== mardi 11 décembre 2012 ====
*Rétrospective : 
**prévu : 
**réalisé : 
*Démo : 

Nombre d'itérations : 4 
'''Product backlog''' 
fonctionnalités 
N scprints backlog (bonnus : poker planning, estimation, complexité) 
N sprints planning 
N demo à la fin du sprint 
N rétrospectives (thérapie de groupe, ce qui s'est bien/mal passé, ce qui peut être amélioré) 

== [http://svn.code.sf.net/p/ecom2012sapins/code/trunk/ Dépôt SVN code] ==
''Ne contient que ce qui est nécessaire à l'application, le code.''

== [http://svn.code.sf.net/p/ecom2012sdn-doc/code/trunk Dépôt SVN documentation] ==
''Contient toute la documentation et les fichiers annexes.''

== Matériels - Quantité ==

* Item 1
* Item 2

Ecom-sapins de noel 2012

2012-11-06T08:43:27Z

Carameln:

== Équipe ==
Qikai Gu 
Xiao Lu 
Noé-Jean Caramelli 
 
'''Rôles : répartition des responsabilités''' 
Chef de projet : Noé-Jean 
Auteur : Noé-Jean 
Concepteur d'interaction : Noé-Jean, Xiao 
Développeur : Xiao 
Expert en utilisabilité : Qikai 
Graphiste : Qikai 

== Page de suivi ==
----
== Description du projet ==
Nous avons choisi d'avoir un scrum master tournant.
Justification :
Nous avons choisi une durée de sprint de 15 jours.

Product backlog
finctionnalités
N scprint backlog (bonnus : poker planning, estimation, complexité)
N sprint planning
N demo à la fin du sprint
N rétrospectives (thérapie de groupe, ce qui s'est bien/mal passé, ce qui peut être amélioré)

== Méthode Aglie et Scrum ==
=== Choix de fonctionnement et justification ===
Nous avons choisi de prendre le chef de projet pour ScrumMaster. 
''Justification : ''
Il faut noter que l'on nous a demandé de nous organiser à la fois de façon traditionnelle et selon la méthode Scrum.
Le rôle du ScrumMaster est "de la protéger des perturbations extérieures. Il est complètement transparent pour la communication entre l'équipe et les clients et n'a aucun pouvoir hiérarchique sur l'équipe. C'est en revanche un facilitateur pour les problèmes non techniques de l'équipe." (Wikipedia). Le chef de projet a aussi pour rôle de gérer les perturbations extérieures, et en principe il a aussi un rôle hiérarchique. C'est toujours le chef de projet qui doit envoyer les livrables demandés par l'équipe pédaggique (constat). Pour concilier au mieux les deux méthodes d'organisation que nous devons appliquer, nous avons choisi de prendre le chef de projet pour ScrumMaster et de gommer l'aspect hiérarchie. Chaque membre de l'équipe a des responsablilités et un pouvoir d'arbitrage déterminé (voir les rôles définis ci-dessus), mais aucun n'a plus de pouvoir qu'un autre.

Nous avons choisi une durée de sprint de 15 jours. 
''Justification : ''
Plusieurs critères nous orientent vers différents choix pour la durée du sprint. Nous avons affectés un coefficient à chacun d'eux puis avons fait la moyenne pondérée de durée de sprint :

(coef pour le critère*nb semaines/sprints) 
(0.3*1) La courte durée du projet, de 2 mois (date de fin de la release fixée au 18 décembre 2012), nous insite à choisir des sprints d'1 semaine. 
(0.3*3) La faible disponibilité de l'équipe de développement sur une semaine, compte tenu du cadre scolaire, nous oriente vers des sprints de 3 semaines. 
(0.15*3) L'effectif réduit de l'équipe de développement, compte tenu du coût supplémentaire engendré par la préparation d'un produit partiel (démo+rétrospective), nous oriente vers des sprints de 3 semaines. 
(0.1*3) La stabilité de l'architecture (sujette à modifications sur conseils dans un cadre pédagogique, méconnaissance des technologies utilisées) nous insite à choisir un sprint de 3 semaines. 
(0.1*3) La durée maximum pour prendre en compte un changement (taille équipe, disponibilité, perturbations) nous oriente vsers des sprints de 3 semaines. 
(0.05*1) Le maintient de la motivation de l'équipe nous oriente vers un sprint d'1 semaine. 
(0) L'implication des clients et utilisateurs n'est pas comptabilisée. 
Si l'équipe pédagogique (PO) est disponible physiquement une fois par semaine, les utilisateurs réellement ciblés sont inaccessibles ! 
 
Nous obtenons une durée de sprint de 2.3 semaines, arrondie à 2 semaines. 
 

=== Rétrospectives ===
Pour les prévisions pour l'application de la méthode Agile, et par rapport aux informations qui nous ont été communiquées, nous retenons ces dates : 
Ce sont les dates de fin de chaque sprint, toutes les 2 semaines
==== mardi 9 octobre 2012 ====
Pas de développement 

==== mardi 23 octobre 2012 ====
Première 15e de développement 
*Rétrospective : 
**prévu : prototype de front-end, avec login et liste de produit (JSP) ; EJB basique pour login ; Mise en place d'un accès à une BD 
**réalisé : front end JSP OK, EJB ne fnctionnement pas, problèmes techniques ; donc, pas de temps pour la BD 
*Démo : démo fonctionnelle du front-end présentant le login/logout/inscription et une liste de deux produits. 

[mardi 30 octobre 2012 : vacances] 
==== mardi 13 novembre 2012 ====
*Rétrospective : 
**prévu : 
**réalisé : 
*Démo : 

==== mardi 27 novembre 2012 ====
*Rétrospective : 
**prévu : 
**réalisé : 
*Démo : 

==== mardi 11 décembre 2012 ====
*Rétrospective : 
**prévu : 
**réalisé : 
*Démo : 

Nombre d'itérations : 4 
'''Product backlog''' 
fonctionnalités 
N scprints backlog (bonnus : poker planning, estimation, complexité) 
N sprints planning 
N demo à la fin du sprint 
N rétrospectives (thérapie de groupe, ce qui s'est bien/mal passé, ce qui peut être amélioré) 

== [http://svn.code.sf.net/p/ecom2012sapins/code/trunk/ Dépôt SVN code] ==
''Ne contient que ce qui est nécessaire à l'application, le code.''

== [http://svn.code.sf.net/p/ecom2012sdn-doc/code/trunk Dépôt SVN documentation] ==
''Contient toute la documentation et les fichiers annexes.''

== Matériels - Quantité ==

* Item 1
* Item 2