Coconode

2013-03-22T09:28:35Z

2013-03-21T10:08:18Z

Hmquan:

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

==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 modifier les paramètres facilement tout en contrôlant les dépenses liées au coût de développement.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé 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…

==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 ==

== 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

== Le produit ==

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

== 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:
** -

* A améliorer:
** -

* Moins:
** -
==== Burndown Chart ====

==== '''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:
** -

*A améliorer
** -

* Moins:
** -

==== 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:
** -

*A améliorer
** -

* Moins:
** -

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

=== 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>

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

Coconode

2013-03-21T10:06:57Z

Hmquan:

[[Image:Coconode_interface.png|500px|thumb|right|Interface Coconode]]
[[Image:Coconode_architecture.png|500px|thumb|right|Architecture Coconode]]

==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 modifier les paramètres facilement tout en contrôlant les dépenses liées au coût de développement.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé 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…

==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 ==

== 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

== Le produit ==

== 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 =====

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

* Plus:
** -

* A améliorer:
** -

* Moins:
** -
==== Burndown Chart ====

==== '''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:
** -

*A améliorer
** -

* Moins:
** -

==== 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:
** -

*A améliorer
** -

* Moins:
** -

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

=== 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>

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

File:Coconode architecture.png

2013-03-21T10:06:28Z

Hmquan:

Coconode

2013-03-21T10:05:38Z

Hmquan:

[[Image:Coconode_interface.png|500px|thumb|right|Interface Coconode]]
==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 modifier les paramètres facilement tout en contrôlant les dépenses liées au coût de développement.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé 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…

==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 ==

== 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

== Le produit ==

== 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 =====

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

* Plus:
** -

* A améliorer:
** -

* Moins:
** -
==== Burndown Chart ====

==== '''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:
** -

*A améliorer
** -

* Moins:
** -

==== 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:
** -

*A améliorer
** -

* Moins:
** -

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

=== 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>

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

Coconode

2013-03-21T10:05:26Z

Hmquan:

[[Image:Coconode_interface.png|500px|thumb|right|Configuration 1]]
==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 modifier les paramètres facilement tout en contrôlant les dépenses liées au coût de développement.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé 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…

==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 ==

== 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

== Le produit ==

== 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 =====

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

* Plus:
** -

* A améliorer:
** -

* Moins:
** -
==== Burndown Chart ====

==== '''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:
** -

*A améliorer
** -

* Moins:
** -

==== 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:
** -

*A améliorer
** -

* Moins:
** -

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

=== 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>

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

Coconode

2013-03-21T10:05:12Z

Hmquan:

[[Image:Coconode_interface.png|300px|thumb|right|Configuration 1]]
==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 modifier les paramètres facilement tout en contrôlant les dépenses liées au coût de développement.
C’est pourquoi, l’équipe Drakkar utilise un simulateur nommé 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…

==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 ==

== 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

== Le produit ==

== 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 =====

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

* Plus:
** -

* A améliorer:
** -

* Moins:
** -
==== Burndown Chart ====

==== '''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:
** -

*A améliorer
** -

* Moins:
** -

==== 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:
** -

*A améliorer
** -

* Moins:
** -

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

=== 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>

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

Lubyb

2012-10-23T14:20:27Z

Hmquan: /* Panier */

Lubyb

2012-10-23T14:19:12Z

Hmquan: /* Achat */