Table des matières

1 Cadre du projet 2

Introduction 2
1.1 Présentation de l’organisme d’accueil . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 Si concepts à définir . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4.1 ........... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.5 Méthodologie de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Conclusion 3

2 Phase de planification 4

Introduction 4
2.1 Spécification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Analyse des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.2 Besoins non fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.1 Répartition des rôles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4.2 Backlog du produit de l’application . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Choix technologique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.1 Architecture Logique globale . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.2 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.5.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 LE PREMIER RELEASE 7

i
Introduction 7
3.1 Conception Release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1 Diagramme de classe release 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Sprint 1 : .................. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1 Analyse fonctionnelle du sprint 1 . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Sprint 2 : ............... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3.1 Sprint Backlog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 Réalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

Conclusion 8

4 LE DEUXIEME RELEASE 9

Introduction 9

Conclusion 9

5 LE TROISIEME RELEASE 10

Introduction 10

Conclusion générale et perspectives 11

ii
Table des figures

iii
Liste des tableaux

1.1 Tableau comparatif des plate-formes similaires . . . . . . . . . . . . . . . . . . . . . . 2

iv
Introduction Générale

...............

1
 Chapitre 1

Cadre du projet

Introduction
......

1.1 Présentation de l’organisme d’accueil

............

1.2 Problématique

.......................

IotAsia The Thethings network

Aspect fonctionnel Pas du tout Un peu Assez Tout à fait Pas du tout Un peu Assez Tout à fait

Inscription pour client X X

Recherche des capteurs X X

Gestion des produits X X

Gestion des commandes et livraison X X

Contact administrateur X X

Aspect ergonomique Pas du tout Un peu Assez Tout à fait Pas du tout Un peu Assez Tout à fait

Incitation X X

Lisibilité X X

Densité informationnelle X X

Tableau 1.1: Tableau comparatif des plate-formes similaires

1.3 Solution proposée

............. ...............

2
Chapitre 1. Cadre du projet

1.4 Si concepts à définir

1.4.1 ...........

1.5 Méthodologie de développement

.................
Si vous considérez SCRUM comme méthode, suivez le plan sur la base des Releases/Sprints
(ci-dessous).
Sinon, considérez les chapitres Spécification des besoins, Conception et réalisation. Si
IA : CRISP : chapitre préparation des données, modélisation et déploiement

Conclusion
......................

3
 Chapitre 2

Phase de planification

Introduction
.....................

2.1 Spécification des besoins

La spécification des besoins représente la première phase du cycle de développement d’un

logiciel. Elle sert à identifier les acteurs réactifs du système et leur associer chacun l’ensemble
d’actions avec lesquelles il intervient dans l’objectif de donner un résultat optimal et satisfaisant
au client.

2.1.1 Identification des acteurs

Pour bien connaître l’environnement étudié, il est nécessaire de décrire les acteurs qui communiquent
avec le système. Nous avons identifié trois acteurs qui interagissent avec l’application :
.................

2.2 Analyse des besoins

Cette phase et responsable de l’ensemble des fonctionnalités offertes par le système. Les
besoins ont été répartis en deux catégories, les besoins fonctionnels et les besoins non fonctionnels.

2.2.1 Besoins fonctionnels

....................................
Administrateur :

— Authentification : S’authentifier pour accéder à son espace.

— Gérer les comptes utilisateurs : lister, supprimer, et chercher un utilisateurs.

— Gérer les catégories : Ajouter , modifier , lister, chercher et supprimer une catégorie .

4
Chapitre 2. Phase de planification

...............................

2.2.2 Besoins non fonctionnels

Les besoins non fonctionnels sont les besoins qui caractérisent le système. Dans le cadre de
notre application, notre solution doit contenir certaines contraintes vitales pour son bon fonctionnement.
Scalabilité : le code développé doit être lisible, compréhensible et extensible pour que d’autres
développeurs peuvent assurer l’évolution.
Confidentialité : L’application fournit une protection contre la divulgation de données,accidentelle
ou délibérée.
Ergonomie des interfaces : Il faut assurer la clarté du contenu de toutes les interfaces...................................

2.3 Diagramme de cas d’utilisation général

.............................. ...............

2.4 Pilotage du projet avec Scrum

L’équipe Scrum est constituée d’un propriétaire de produit, de l’équipe de développement et

d’un Scrum Master. Le modèle d’équipe de Scrum est conçu pour optimiser la flexibilité, la créativité
et la productivité. Nous allons tout d’abord tenter de cerner notre équipe Scrum .

2.4.1 Répartition des rôles

Scrum consiste en la définition des rôles, artefacts et réunions. Il définit trois rôles qui sont :
Product owner : ...................
Scrum Master : ....................
L’équipe de développement : .....................

2.4.2 Backlog du produit de l’application

Pour spécifier d’une façon formelle les besoins requis par l’application, nous avons préparé le
Backlog produit. Le Backlog est la liste des macro-fonctionnalités (User Stories), à exécuter durant
le projet. La complexité est selon un ordre croissant, priorisés selon la méthode MoSCoW qui est une
technique possédant un objectif qui s’articule autour d’un accord entre le maître d’œuvre (MOE) et
le maître d’ouvrage (MOA) sur l’importance des tâches que l’on va réaliser par rapport aux délais

5
Chapitre 2. Phase de planification

prévus. MoSCoW a pour signification :

— M : Must

— S : Should

— C : Could

— W : Won’t

A partir des besoins fixés avec le client, nous avons pu élaborer le Backlog de notre produit (exemple
de backlog) :

2.5 Choix technologique

Après avoir annoncé le planification des sprints et releases de notre projet,nous allons présenter
l’architecture logique de notre application.

2.5.1 Architecture Logique globale

Dans cette partie, nous allons détailler et expliquer l’architecture logique de notre application.

2.5.2 Architecture physique

.....................

[Link] Environnement matériel

................

2.5.3 Environnement logiciel

..................

[Link] Technologies utilisées

...................

Conclusion
......................... ;

6
 Chapitre 3

LE PREMIER RELEASE

Introduction
Le terme release peut être défini comme une période de temps qui permet de produire une version
distribuée d’une application. Un release est constitué d’une suite d’itérations (sprint) qui se terminent
quand les incréments de ces derniers construisent un produit. Dans ce chapitre, nous allons présenter
le travail réalisé lors des deux premiers sprints comportant le diagramme de classe du premier release
suitée par une phase de planification et les différentes tâches tout en spécifiant à chaque sprint les
différentes parties : Backlog sprint et réalisation.

3.1 Conception Release 1

Dans cette section, nous visons à détailler le contenu des différents composants du release
1 et les relations entre eux. Pour ce faire, plusieurs diagrammes UML sont utilisés pour mettre en
relief les aspects statique et dynamique présentés par le diagramme de classes et séquences système.

3.1.1 Diagramme de classe release 1

................

3.2 Sprint 1 : ..................

.................

3.2.1 Analyse fonctionnelle du sprint 1

[Link] les besoins fonctionnels

................

7
Chapitre 3. LE PREMIER RELEASE

[Link] Diagrammes de cas d’utilisation du sprint 1

................................

[Link] Diagrammes de séquences du sprint 1

....................

3.2.2 Sprint Backlog

....................

3.3 Sprint 2 : ...............

.................

3.3.1 Sprint Backlog

....................

3.4 Réalisation

Dans cette partie, nous allons détailler les scénarios d’exécution du release

Conclusion
Dans ce chapitre, nous sommes arrivés à l’objectif désiré qui est le fait de pouvoir gérer la recherche
des capteurs convenables pour répondre aux besoins fixés pour cette release.

8
 Chapitre 4

LE DEUXIEME RELEASE

Introduction
.................... même structure du chapitre Release 1

Conclusion

9
 Chapitre 5

LE TROISIEME RELEASE

Introduction
................................

Conclusion

10
Conclusion générale et perspectives

11
Bibliographie

[1] Web Scraping , [Accès ........Adresse : https ://[Link]/digitalguide/sites-internet/developpement-web/qu

[2] Scrum , Adresse :https ://[Link]/.

[3] Django , Adresse :https ://[Link].

[4] Angular, adresse : https ://[Link]/guide/architecture.

[5] API Rest, adresse : https ://[Link]/gerald/blog/qu-est-ceque-rest/447/.

[6] Bootsrap, adresse : http ://[Link]/.

[7] Gantt-Diagram, adresse : https ://[Link]/glossary/diagramme-de-gantt-definition/.

diagramme-de-classes-uml.

[8] beautifulsoup4, adresse :https ://[Link]/project/beautifulsoup4/.

[9] Comparative, adressehttps ://[Link]/stackups/beautifulsoup-vs-scrapy.

12