Site web de gestion de location et colocation dans le domaine de l'immobilier.

REPUBLIQUE TUNISIENNE

Ministère de l'Enseignement Supérieur et de la Recherche Scientifique Université de Jendouba



Faculté des Sciences Juridiques, Economiques et de Gestion de Jendouba

Projet de Fin d'Etudes

Présenté en vue de l'obtention du diplôme de

Mastère Professionnel en Informatique

Spécialité : e-commerce

Titre



Développement d'un nouveau site Web de gestion de location et de colocation dans le domaine de l'immobilier

Réalisé par : Chafik Ahmadi

Sous la direction de : Mme. Neila Rjaibi

Année universitaire : 2019/2020



Au terme de ce travail, j'adresse mes vifs remerciements à Madame Neila

Rjaibi, mon encadrant pédagogique, pour son suivi, sa disponibilité, son aide précieuse et ses conseils _qui m'ont été d'une utilité indéniable.

J'exprime également toute ma gratitude à tous mes enseignants de l'fsjegj pour la formation _qu'ils m'ont donnée.

Je témoigne ici à tous les membres du jury, toute ma reconnaissance et mon respect _que j'ai pour eux d'avoir accepter d'évaluer mon travail.

Enfin, je remercie ceux et celles _qui ont participé de près ou de loin à l'élaboration du présent travail et principalement pour leur service et pour leur soutien moral tout au long de la préparation de cette mémoire.



Table des matières

Introduction générale 1

Chapitre I : Présentation du cadre du projet 2

1 Introduction 3

2 Présentation du projet 3

2.1 Etude de l'existant 3

2.2 Tableau comparatif des différentes solutions existantes 3

2.3 Critique de l'existant 6

2.4 Solution proposée 7

3 Choix du modèle de développement 8

4 Langage de modélisation 11

5 Analyse et spécification des Besoins 11

5.1 Acteurs et fonctionnalités 11

5.2 Définition des Besoins fonctionnels 12

5.3 Définition des Besoins non fonctionnels 12

5.4 Cas d'utilisation globale 13

6 Pilotage du projet avec SCRUM 14

6.1 Les outils scrum utilisés 14

6.2 Equipe et rôle 14

6.3 Le backlog du produit 15

7 Initiation du projet : sprint 0 17

7.1 Architecture de la solution 17

7.1.1 Architecture logique 17

7.1.2 Architecture logicielle 18

8 Conception détaillée 19

8.1 Le diagramme de déploiement 19

8.2 Le diagramme de composants 20

8.3 Environnement de travail 21

Conclusion 23

CHAPITRE II : Mise en OEuvre du Release 1 24

INTRODUCTION 25

1 Backlog du sprint 1 25

2 Spécification des besoins 25

2.1 Raffiner les modèles des cas d'utilisation 25

2.2 Prototypes des interfaces utilisateurs 28 3 Analyse des cas d'utilisation de priorité 1 29 3.1 Diagramme de collaboration 30 4 Conception des cas d'utilisation de priorité 1 31 4.1 La conception des cas d'utilisation du sprint 1 32 4.1.1 Diagramme de classes de conception 32 4.1.2 Diagramme d'interaction (diagramme de séquence) 33 4.1.3 La conception des classes du sprint 1 (diagramme de classe entités) 34 4.2 Schéma de la base de données 35 5 Implémentation des cas d'utilisation prioritaires 36 5.1 Les captures d'écran 36 1 Backlog du Sprint 2 38 2 Spécification des besoins 38 2.1 Raffiner les modèles des cas d'utilisation de priorité « 2 » 38 2.2 Elaboration des Prototypes 41 3 Analyse des cas d'utilisation du priorité 2 44 3.1 Diagramme de classe d'analyse 44 3.2 diagramme de collaboration du cas gérer annonces « ajout logement » 45 4 Conception des cas d'utilisation de priorité 1 et 2 47 4.1 La conception des cas d'utilisation du release 1 47 4.1.1 Diagramme de classes de conception 47 4.1.2 Diagramme de séquences du cas « ajouter annonce » 49 4.2 Le diagramme de classe entités du sprint 2 53 5 Schéma de la base de données : 54 6 Implémentation du cas d'utilisation du release 1 57 6.1 Les captures d'écran 57 Conclusion 60 Chapitre 3 : Mise en oeuvre de la release 2 61 Introduction 62 1 Backlog du sprint 3 62 2 spécification des besoins 62 2.1 Raffiner les modèles des cas d'utilisation de priorité « 3 » 62 2.2 Elaboration des prototypes des interfaces utilisateurs 63 3 Analyse des cas d'utilisation de priorité 64 3.1 Diagramme des classes d'analyse du sprint « 3 » 64
3.2 Diagramme de collaboration 4 Conception des cas d'utilisation de priorité 3 4.1 La conception de cas d'utilisation prioritaire		65 66 66
4.1.1 Diagramme de classe de conception		66
4.1.2 Diagramme d'interaction (diagramme de séquence)		67
4.2 Diagramme de classe entités		68
5 Implémentation des cas d'utilisation prioritaires		71
5.1 Les captures d'écran		71
Sprint 4 « gestion avis, gestion contact»		73
1 Backlog du sprint 4		73
2 Spécification des besoins		73
2.1 Raffiner les modèles des cas d'utilisation de priorité 4		73
2.2 Elaboration des prototypes des interfaces utilisateurs		74
3 Analyse des cas d'utilisation de priorité 4		75
3.1 Diagramme de classe d'analyse		75
3.2 Diagramme de collaboration		75
4 Conception des cas d'utilisation de priorité 4		76
4.1 La conception des cas d'utilisation prioritaires		76
4.1.1 Diagramme de classe de conception		76
4.1.2 Diagramme d'interaction (diagramme de séquence)		78
4.2 Diagramme de classe entités de sprint « 4 »		80
4.3 Diagramme d'activités		81
5 Implémentation des cas d'utilisation prioritaires		82
Conclusion		83
Chapitre 4 : Mise en oeuvre de la release 3		84
Introduction		85
1 Backlog du sprint 5		85
2 Spécification des besoins		85
2.1 Raffiner les modèles des cas d'utilisation de priorité « 5	»	85
2.2 Elaboration des prototypes des interfaces utilisateurs		86
3 Analyse des cas d'utilisation de priorité 5		88
3.1 Diagramme des classes d'analyse		89
3.2 Le diagramme de collaboration		90
4 Conception des cas d'utilisation de priorité 5		90
4.1 La conception des cas d'utilisation du release 3		90
4.1.1 Diagramme de classes de conception 91 4.1.2 Diagramme d'interaction (diagramme de séquence) 91 4.2 La conception des classes du sprint 5 93 5 Implémentation des cas d'utilisation prioritaires 94 5.1 Les captures d'écran 94 5.2 Diagramme de classe globale 96 5.3 Règles de passage du diagramme de classe en modèle relationnel 96 5.4 Schéma de la base de données complet 97 Conclusion 102 Chapitre V : Hébergement et Référencement 103 Hébergement concret et référencement 104 1 Introduction 104 2 Choix d'hébergeur 104 2.1 Hébergeur 104 2.2 Espace d'hébergement 106 3 CPanel 106 3.1 Gestionnaire de fichiers 107 3.2 La base de données 107 4 Référencement gratuit(SEO) 108 4.1 Statistique 109 4.2 Réseaux sociaux 110 4.3 Action sociale 111 5 Référencement payant (SEA) 111 Conclusion 112 Conclusion et perspectives 113

Liste des figures

Figure 1: Capture d'écran du site Tunisieimmob.tn 4

Figure 2 Capture d'écran du site"zitounaimmobilier" 4

Figure 3 Capture d'écran de l'interface du site « Agence-immobiliere-tunisie.net » 5

Figure 4 Capture d'écran de l'interface du site « tayara.tn » 5

Figure 5: Méthode scrum 9

Figure 6: Déroulement d'un release 10

Figure 7:Diagramme de cas d'utilisation globale 14

Figure 8: Diagramme de gantt 17

Figure 9:Architecture 3 tiers 18

Figure 10:Présentation modèle MVC 19

Figure 11: Diagramme de composants 21

Figure 12:Diagramme de cas d'utilisation "s'authentifier" 26

Figure 13:Diagramme du cas d'utilisation : s'inscrire 27

Figure 14: Interface s'inscrire 29

Figure 15: Interface inscription 29

Figure 16:Diagramme des classes d'analyse de cas s'authentifier 30

Figure 17: Diagramme des classes d'analyse de cas « s'inscrire » 30

Figure 18:Diagramme de collaboration du cas s'authentifier 31

Figure 19:Diagramme de collaboration du cas « s'inscrire » 31

Figure 20 : Diagramme de classe des cas d'utilisation « s'authentifier » 32

Figure 21:Digramme de classe du cas « s'inscrire » 32

Figure 22 : Diagramme de séquence "s'authentifier" 33

Figure 23 : Diagramme de séquence du cas "s'inscrire" 34

Figure 24:La conception des classes du sprint 1 34

Figure 25 : Diagramme d'activité authentification 35

Figure 26:Diagramme d'activité « inscription » 36

Figure 27:Capture d'écran du cas « s'authentifier » 37

Figure 28:Capture d'écran «inscription » 37

Figure 29:Diagramme de cas d'utilisation du sprint 2 39

Figure 30:Prototype de l'Interface : proposer logement 42

Figure 31:Prototype de l'Interface rechercher logement 43

Figure 32: prototype du cas d'utilisation réservation 43

Figure 33:Diagramme des classes d'analyse du cas « gérer annonces » 44

Figure 34:Diagramme des classes d'analyse du cas « gérer offres » 44

Figure 35:Diagramme des classes d'analyse du cas « gérer réservation » 45

Figure 36:Diagramme de collaboration du cas gérer annonces « ajout logement » 45

Figure 37:Diagramme de collaboration du cas gérer annonces « chercher logement » 46

Figure 38:Diagramme de collaboration gérer offre « chercher offres » 46

Figure 39:Diagramme de collaboration gérer offre « gérer réservations » 47

Figure 40:Diagramme de classe du release 1 48

Figure 41:Diagramme de séquences du cas « ajouter annonce » 49

Figure 42:Diagramme de séquence du cas « modifier annonce » 50

Figure 43:Diagramme de séquence du cas « consulter offres » 51

Figure 44:Diagramme de séquence du cas « gérer réservations » 52

Figure 45: Le diagramme de classe entités du sprint 2 53

Figure 46:Diagramme d'activité du cas « ajouter annonces » 56

Figure 47: Diagramme d'activité du cas « gérer réservation » 56

Figure 48 : Capture d'écran du cas «ajouter annonces » 57

Figure 49:Capture d'écran du cas «consulter offres » 58

Figure 50:Capture d'écran du cas «modifier annonce» 58

Figure 51: Capture écran "gérer réservation" 59

Figure 52:Diagramme de cas d'utilisation de release 3 63

Figure 53:Prototype du cas d'utilisation « ajouter demande » 63

Figure 54:Prototype du cas d'utilisation « ajouter dépannage gratuit » 64

Figure 55:Diagramme de classe d'analyse du cas « formuler demande » 64

Figure 56: Diagramme de classe d'analyse du cas « dépannage » 65

Figure 57: Diagramme de collaboration (déposer demande) 65

Figure 58: Diagramme de collaboration « déposer dépannage » 66

Figure 59 : Diagramme des classes de conception du release 2 67

Figure 60:Diagramme de séquence du cas d'utilisation « déposer demandes » 68

Figure 61: Schéma relationnel de la release 2 69

Figure 62:Diagramme d'activités « déposer demande » 70

Figure 63: Interface demande 71

Figure 64:Interface déposer demande de logement 71

Figure 65:Interface consulter demande 72

Figure 66:Interface ajouter dépannage 72

Figure 67:Cas d'utilisation de sprint 4 73

Figure 68: Prototype de l'interface gérer avis 74

Figure 69:Prototype de l'interface gérer contact 74

Figure 70:Diagramme de classe d'analyse du cas d'utilisation « gérer avis » 75

Figure 71: Diagramme de classe d'analyse du cas d'utilisation « gérer contact » 75

Figure 72: Diagramme de collaboration du cas d'utilisation « gérer avis » 76

Figure 73:Diagramme de collaboration du cas d'utilisation « gérer contact » 76

Figure 74: Diagramme de classe de conception de sprint 4 77

Figure 75:Diagramme de séquence du cas d'utilisation « gérer avis » 78

Figure 76:Diagramme de séquence du cas d'utilisation « gérer contact » 79

Figure 77:Diagramme de classe entités de sprint « 4 » 80

Figure 78:Diagramme d'activités du cas d'utilisation « gérer avis » 81

Figure 79:Diagramme d'activités du cas d'utilisation « gérer avis » 81

Figure 80:Interface du cas d'utilisation «gérer avis » 82

Figure 81:Interface du cas d'utilisation «gérer contact » 82

Figure 82:Diagramme de cas d'utilisation du release « 3 » 86

Figure 83:Interface du cas d'utilisation « gérer utilisateurs » 86

Figure 84:Interface du cas d'utilisation « gérer logements » 87

Figure 85:Diagramme de classe d'analyse du cas d'utilisation « gérer utilisateur » 89

Figure 86:Diagramme de classe d'analyse du cas d'utilisation « gérer logements » 89

Figure 87:Diagramme de collaboration du cas « gérer utilisateurs » 90

Figure 88:Diagramme de collaboration du cas « gérer logements » 90

Figure 89: Diagramme de classe de conception du release 3 91

Figure 90:Diagramme de séquence du cas d'utilisation « gérer utilisateur » 92

Figure 91:Diagramme de séquence du cas d'utilisation « gérer logement » 92

Figure 92:Diagramme de classe entités du release « 3 » 93

Figure 93:Capture d'écran espace administrateur 94

Figure 94:Site www.oxahost.tn 105

Figure 95:Email de confirmation de payement 106

Figure 96:CPanel 107

Figure 97:Gestionnaire de fichiers 107

Figure 98:Base de données 108

Figure 99:Référencement 109

Figure 100:espace AWAstat 110

Figure 101: Footer du site 110

Figure 102:Page accueil du site 111

Liste des tableaux

Tableau 1: Tableau comparatif des sites 6

Tableau 2: Backlog du produit 15

Tableau 3: Diagramme de déploiement 20

Tableau 4: Backlog du sprint 1 25

Tableau 5: Product backlog du sprint 1 26

Tableau 6: Description textuelle du cas d'utilisation « S'authentifier » 27

Tableau 7: Description textuelle du cas d'utilisation « s'inscrire » 28

Tableau 8:Table utilisateur 35

Tableau 9: Backlog du sprint 2 38

Tableau 10:Descriptif du cas d'utilisation "gérer annonces" 39

Tableau 11: Tableau descriptif du sous cas « gérer offres » 40

Tableau 12: Tableau descriptif du sous cas « gérer réservation » 41

Tableau 13: Table logement 54

Tableau 14: Table réservation 55

Tableau 15:Table photos 55

Tableau 16: Backlog du produit 62

Tableau 17: Tableau des taches du release 2 62

Tableau 18: Table demande 70

Tableau 19: Table dépannage 70

Tableau 20:Backlog du sprint 4 73

Tableau 21: Table avis 80

Tableau 22: Backlog du sprint 5 85

Tableau 23: Product backlog du sprint 5 85

Tableau 24: Description du cas "supprimer utilisateur" 87

Tableau 25: Descriptif du cas "gérer logements" 88

Tableau 26: Table administrateur 94

Tableau 27: Capture d'écran espace gérer utilisateur 95

Tableau 28: Capture d'écran espace gérer logement 95

Tableau 29:Diagramme de classe globale 96

Tableau 30:Table utilisateur 97

Tableau 31:Table logement 98

Tableau 32:Table photos 99

Tableau 33:Table type logement 99

Tableau 34:Table réservation 99

Tableau 35:Table demande 100

Tableau 36:Table dépannage 100

Tableau 37:Table avis 101

Tableau 38:Table administrateur 101

Introduction générale

Introduction générale

L'immobilier est un domaine à forte demande. Et avec l'apparition du e-commerce, les marchands de ce secteur cherchent à exploiter ces nouvelles technologies affin de mieux s'adapter aux nouvelles exigences pour mieux se positionner sur le marcher.

Nous pouvons trouvez des milliers d'annonces immobilières que ce soit à l'achat ou à la location.

En tunisie, ces annonces immobilières sont généralement postées soit par des particuliers dans des sites de petites annonces gratuites notamment nous citons le célèbre tayara.tn, soit par des agences immobilières dans leurs sites web (exemple tunisieimmob.com).

De plus ces sites n'offrent pas le service de la colocation entre particuliers qui est devenu un besoin important pour les jeunes travailleurs ou les étudiants.

C'est dans ce contexte qu'on a décidé de mettre en place notre projet de nouveau site web spécialisé dans le domaine de location et de colocation immobilière entre particuliers.

Le rapport est composé de cinq chapitres :

Le premier chapitre est intitulé « Présentation du Cadre de projet » on va présenter le cadre du projet et le choix de la méthodologie à suivre.

Le deuxième chapitre sera consacré au premier release et on va Raffiner les modèles des cas d'utilisation de priorité 1, élaborer des prototypes des interfaces utilisateurs et analyser des cas d'utilisation de ces priorités (Cas par cas).

Dans le troisième chapitre on va identifier de nouveaux besoins et de nouvelles exigences. Analyser, concevoir et implémenter les cas d'utilisation de la release 2

Le quatrième chapitre sera pour identifier, analyser, concevoir et implémenter les cas d'utilisation de release 3.

Le dernier chapitre sera consacré à la phase de l'hébergement du site

Enfin, nous présentons une synthèse ainsi que les perspectives en raison d'améliorer

les performances de l'application.

1

Chapitre I : Présentation du cadre du projet

2

CHAPITRE I : Présentation du cadre du projet

1 Introduction

Dans ce chapitre nous allons présenter l'étude de l'existant suivie d'une étude

comparative entre quatre exemples de site web dans le domaine de l'immobilier en Tunisie pour pouvoir extraire les défaillances a résoudre au cour de la réalisation de notre projet.

2 Présentation du projet

2.1 Etude de l'existant

Description de l'existant

Dans cette partie, nous allons étudier l'existant dans le domaine de l'immobilier en présentant les solutions les plus connus.

2.2 Tableau comparatif des différentes solutions existantes

Ces solutions sont les plus connues et les plus utilisées. Nous citons : Tunisieimmob.net, Zitounaimmobilier.com, Agence-immobilière-Tunisie et Tayara.tn.

Les applications :

Le site Tunisieimmob.net

Tunisie Immobilier est l'ambition d'un jeune tunisien de formation architecte résidant dans la région de Sousse, qui a donné naissance au journal à Le Réflex Immobilier. [1]

C'est la première revue gratuite d'annonces immobilières en Tunisie, avec un contenu

100% composé d'offres immobilières de vente et location de biens immobiliers (maisons, appartements et fonds de commerce).

Depuis janvier 2005, « Le Réflex Immobilier» vient combler un vide informationnel dans le secteur pour les professionnels du produit immobilier ainsi qu'aux promoteurs

immobiliers qui désirent communiquer avec des conditions plus favorables. [2]

3



CHAPITRE I : Présentation du cadre du projet

Figure 1: Capture d'écran du site Tunisieimmob.tn

Zitounaimmobilier.com

Zitounaimmobilier.com est un site créé par l'agence immobilière zitouna qui offre un service de vente et de location des biens immobiliers, il offre aussi un service d'annonce gratuit. [3]

Figure 2 Capture d'écran du site"zitounaimmobilier"

4



CHAPITRE I : Présentation du cadre du projet

Agence-immobiliere-tunisie.net

La figure si dessous représente le site agence-immobiliere-tunisie.net. ce dernier représente un espace de vente et location des biens immobiliers.[4]

Figure 3 Capture d'écran de l'interface du site « Agence-immobiliere-tunisie.net »

tayara.tn

Tayara.tn est un site web dédié à tous types d'annonces dont les annonces immobilière, il permet la recherche par catégorie.la vente, la location et la colocation des biens.[5]

Figure 4 Capture d'écran de l'interface du site « tayara.tn »

5

CHAPITRE I : Présentation du cadre du projet

2.3 Critique de l'existant Tableau comparatif
fonctionnalités Tunisieimmob.		Zitounaimmobilier.c	Agence-immobiliere-	Tayara.tn
net		om	tunisie.net
La vente des biens	x	x	x	x
La location des biens	x	x	x	x
La recherche des biens	x	x	x	x
Gestion de colocations
L'insertion des annonces		x		x
paiement	x	x	x
La géo-localisation
L'insertion des images		x		x

Tableau 1: Tableau comparatif des sites

De nos jours, les demandes et les offres des biens immobiliers ne cessent d'augmenter sur le marché, et cela est très visible surtout sur les sites d'annonces et les réseaux sociaux, citons :

Le cas des gens qui sont en déménagement et cherchent un loyer selon leurs besoins et leurs budgets ou ceux qui ont un logement et souhaitent le rentabilisé en le proposant à la location.

Le cas des étudiants ou les jeunes fonctionnaires ou travailleurs qui n'ont pas les moyens de s'offrir un logement individuel faute du budget et souhaitent partager un loyer entre eux

Les gens qui cherchent un séjour de vacances pour quelques jours sans passer par les hôtels ou les agences de voyages

6

CHAPITRE I : Présentation du cadre du projet

Dans ces cas les services proposés par ces entreprises facilitent la vie et permettent entre autre d'assouplir la tâche.

Mais La majorité des solutions citées précédemment ne permettent pas : Aux particuliers de proposer leurs biens immobiliers

· la gestion des colocations.

· La géo-localisation

· La recherche multicritères

2.4 Solution proposée

Notre projet de distingue par rapport aux autre sites existants par leur capacité à :

· Proposer un logement pour la location

· Chercher un logement

· Proposer une colocation

· Chercher une colocation

· Chercher / proposer un séjour de vacances

· Chercher / offrir un dépannage gratuit

· Demander une location /colocation /séjour de vacances

· Visualiser les locations/colocations/séjours/dépannage et les demandes

· La notification par email

· La géo-localisation des biens immobiliers

Le but est de fournir un site reflétant une bonne ergonomie, de nouvelles fonctionnalités tel que le service de colocation, la géo-localisation , la notification par email et la recherche multicritères

7

CHAPITRE I : Présentation du cadre du projet

3 Choix du modèle de développement

Méthode Agile scrum

Afin de réaliser notre projet, une étude performante s'avère nécessaire dans la démarche pour la réalisation de mon futur système

Les méthodes agiles sont des pratiques de gestion de projets pour le développement des applications informatiques, pour satisfaire le client. Pour cela, un dialogue constant avec le client est mis en place afin de réaliser un logiciel complètement fonctionnel. [6]

Les méthodes agiles partent du principe que spécifier et planifier dans les détails l'intégralité d'un produit avant de le développer (approche prédictive) est contre productif.

Dans le cadre d'un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l'équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global.

Scrum est de très loin la méthodologie la plus utilisée parmi les méthodes agiles existantes. Elle est donc la plus éprouvée, documentée et supportée. Livres, blogs, formations, vidéos, associations, conférences traitant de Scrum ne manquent pas et bon nombre de ces ressources sont accessibles gratuitement. On pourrait pratiquement parler d'un standard Agile. Un autre atout important : Scrum est simple à comprendre. Sa maîtrise est en revanche difficile.

8

CHAPITRE I : Présentation du cadre du projet



Figure 5: Méthode scrum

Equipe et rôle

La méthode Agile Scrum est une méthode qui répartie les rôles entre 3 principaux intervenants qui sont :

Product owner : Dans la plupart des cas, le responsable produit (product owner) est le chef de l'équipe du projet. Il définit, planifie, organise et priorise des fonctionnalités du produit et fixe la date et le contenu de chaque sprint en se basant sur les valeurs fournis par son équipe.

Dans notre cas le product owner c'est « ahmadi chafik »

ScrumMaster : c'est lui qui assure la fluidité de coopération entre les membres de l'équipe en surpassant les obstacles et les perturbations extérieures éventuelles. Il veille également au respect des phases de SCRUM.

Dans notre cas le scrumMaster c'est « Mm Neila Rjaibi »

Equipe : Il regroupe tous les rôles nécessaires à un projet.il est formé de taille variant selon l'ampleur du projet il est formé généralement de (l'architecte, le concepteur, le développeur, le testeur, etc.)

9

CHAPITRE I : Présentation du cadre du projet

AVANTAGES DE LA MÉTHODE AGILE SCRUM

Scrum se différencie des autres méthodes de développement par ses avantages qui font de ce procédé une réponse pragmatique aux contraintes actuelles des chefs de produits Méthode itérative et incrémentielle : elle permet de vérifier et tester constamment l'avancement de projet et cela évite les mauvaises surprises.

La méthode agile est très adaptée pour le développement des applications, car elle permet de composer le contenu des sprints afin de pouvoir appliquer des modifications sur les fonctionnalités.

Méthode participative : elle permet aux différents membres de l'équipe à participer dans la prise des décisions sur le projet.

La communication et coopération: l'élaboration du projet exige un travail d'équipe qui doit être en communication permanente afin de surpasser les obstacles et de coopérer.

Augmentation de la productivité : l'organisation des taches, la coopération, et la communication constante entre les membres de l'équipe fournit un environnement du travail qui va assurer forcément une productivité élevée.



Figure 6: Déroulement d'un release

10

CHAPITRE I : Présentation du cadre du projet

4 Langage de modélisation

Pour exprimer les différents modèles, on a choisi d'utiliser l'UML comme un langage de modélisation. UML (Unified Modeling Language), en Français langage unifié de modélisation développé en 1996 et qui permet d'utiliser toute méthode orientée objet.

L'UML est un moyen qui permet d'exprimer des modèles objet en faisant abstraction de leur implémentation, c'est-à-dire que le modèle fourni par UML est valable pour n'importe quel langage de programmation.

Nous avons adopté aussi pour ce langage pour les raisons suivantes :

· Un langage sans ambiguïtés.

· Un langage universel pouvant servir de support pour tout langage orienté objet.

· Un moyen de définir la structure d'un programme.

· Une représentation visuelle permettant la communication entre les acteurs d'un même projet.

· Une notion graphique simple, compréhensible même par des non-informaticiens.

5 Analyse et spécification des Besoins

5.1 Acteurs et fonctionnalités

Le futur système comportera les acteurs suivants ;

· Le propriétaire de logement

· Le locataire

· L'administrateur

· L'utilisateur

11

CHAPITRE I : Présentation du cadre du projet

5.2 Définition des Besoins fonctionnels

La spécification des besoins est une phase indispensable dans le cycle de vie d'un logiciel. En outre l'adéquation de l'application à réaliser, aux besoins des utilisateurs et aux traitements envisagés au niveau de ses opérations assurera la réussite de l'application et sa future utilité. Pour assurer ces objectifs, il est essentiel de

déterminer les fonctionnalités attendues.

Les besoins fonctionnels permettent d'identifier les cas d'utilisation du système par ses acteurs, décrire les cas d'utilisation et de les organiser

L'application doit fournir un ensemble de fonctionnalités aux utilisateurs. En effet, l'application Permettra aux utilisateurs de proposer leurs logements à la location ,la colocation , le séjour de vacances et le dépannage gratuit, cela implique l'insertion de l'annonce, les images , les caractéristiques de leurs biens immobilier

? la géo localisation et le prix. ? L'enregistrement dans le site ? la création de session

Elle doit permettre aussi de chercher un logement pour la location ,la colocation et / ou un séjour de vacances/un dépannage gratuit selon les préférences des utilisateurs.

Elle doit permettre la création de session utilisateur

Le visiteur de site doit être capable de naviguer et visionner les annonces

L'application doit permettre aux chercheurs d'annonces de contacter le locataire ou l'administrateur du site et de fixer un rendez-vous

5.3 Définition des Besoins non fonctionnels

Il s'agit des besoins qui caractérisent le système. Ce sont des besoins en matière de performance, de type de matériel ou le type de conception. Ces besoins peuvent

12

CHAPITRE I : Présentation du cadre du projet

concerner les contraintes d'implémentation (langage de programmation, type SGBD, de système d'Exploitation...)

Dans le cadre de ce travail, l'application devra être extensible, c'est-à-dire qu'il pourra y avoir une possibilité d'ajouter ou de modifier de nouvelles fonctionnalités.

L'application devra être capable de :

· Tourner en réseau ;

· Etre compatible avec n'importe quel navigateur

· Etre compatible avec n'importe quel appareil

· Traiter les erreurs d'entrées sorties

Elle doit être :

· Fiable

· Disponible

· Ergonomique

IL faudra aussi noter que l'application devra être sécurisée car les informations privées ne devront pas être accessibles à tout le monde.

5.4 Cas d'utilisation globale

Le cas d'utilisation globale permet de visualiser et organiser les fonctionnalités du projet

Ce sont les principales actions que les acteurs vont appliquer sur notre futur système

13



CHAPITRE I : Présentation du cadre du projet

Figure 7:Diagramme de cas d'utilisation globale

6 Pilotage du projet avec SCRUM

6.1 Les outils scrum utilisés

Pour suivre la progression de notre travail et assurer une bonne organisation nous avons utilisé les stickers pour assurer une bonne coordination des taches.

6.2 Equipe et rôle

Nous présentons dans cette sous-section l'ensemble des acteurs participants au déroulement des différentes phases du site

Le propriétaire de logement : c'est la personne qui offre son logement pour la location ou la colocation.

14

CHAPITRE I : Présentation du cadre du projet

L'utilisateur : c'est la personne qui accède au site et qui cherche un logement pour la location / la colocation /un séjour de vacances ou dépannage gratuit selon ses préférences.

L'administrateur : c'est le responsable qui s'occupe de la base de données de l'application.

Le visiteur : c'est la personne qui a le droit de visualiser les offres.

6.3 Le backlog du produit							Release Sprint
id		Cas d'utilisation	Acteur	Priorité
	1	S'inscrire	Utilisateur\ Locataire \ propriétaire\	1
1			administrateur
	2	S'authentifier	Utilisateur\ Locataire \ propriétaire\	1
1			administrateur			1
2	3	Gérer annonces	propriétaire	2
2	4	Gérer offres	locataire	2
2	5	Gérer réservation	propriétaire	2
3	6	Gérer demandes	Locataire \ propriétaire	3
3	7	Gérer dépannages	Locataire \ propriétaire	3		2
4	8	Gérer avis	Locataire \ propriétaire	4
4	9	Gérer contact	Locataire \Propriétaire	4
5	10	Gérer utilisateurs	administrateur	5		3
5	11	Gérer logements	administrateur	5

Tableau 2: Backlog du produit

15

CHAPITRE I : Présentation du cadre du projet



· S'inscrire

· S'authentifier



Release 2

Sprint 3

· Gérer demandes

· Gérer dépannages

Sprint 2

Sprint 4



Release 1

Sprint 1



Release 3



Sprint 5

Planification des sprints :

· Gérer logements

· Gérer utilisateur

· Gérer annonces

· Gérer offres

· Gérer avis

· Gérer contact



· Gérer réservations

Gestion du projet Diagramme de gant

Le diagramme de Gantt, couramment utilisé en gestion de projet, est l'un des outils les plus efficaces pour représenter visuellement l'état d'avancement des différentes activités (tâches) qui constituent un projet. La colonne de gauche du diagramme énumère toutes les tâches à effectuer, tandis que la ligne d'en-tête représente les unités de temps les plus adaptées au projet (jours, semaines, mois etc.). Chaque tâche est matérialisée par une barre horizontale, dont la position et la longueur représentent la date de début, la durée et la date de fin. [7]

16

CHAPITRE I : Présentation du cadre du projet



Figure 8: Diagramme de gantt

7 Initiation du projet : sprint 0

7.1 Architecture de la solution

7.1.1 Architecture logique

L'application doit fonctionner dans un réseau. L'accès doit être possible à partir de

n'importe quel poste par le biais d'un navigateur web. Mais, l'importance d'avoir un système d'archivage de donnée (parmi le besoins fonctionnels) et de gestion de logs nous oblige de créer une base de données permettant de stocker les différents évènements.

Ainsi l'architecture à trois niveaux s'avère la mieux à adopter (aussi appelée architecture 3-tiers) caractérise les systèmes clients/serveurs dans lesquels le client demande une ressource et le serveur la lui fournit directement. Cela signifie que le serveur ne fait pas appel à une autre application afin de fournir le service.

En effet, l'architecture 3-tiers, ou encore architecture à trois niveaux ou couches est l'extension du modèle client -serveur. L'architecture logique du système est divisée en trois niveaux ou couches :

? couche présentation.

? couche métier.

? couche accès aux données.

17

CHAPITRE I : Présentation du cadre du projet



Figure 9:Architecture 3 tiers

7.1.2 Architecture logicielle

L'architecture MVC est l'une des architectures logicielles les plus utilisées pour les applications Web, elle se compose de 3 modules :

Modèle : noyau de l'application qui gère les données, permet de récupérer les informations dans la base de données, de les organiser pour qu'elles puissent ensuite être traitées par le contrôleur.

Vue : composant graphique de l'interface qui permet de présenter les données du modèle à l'utilisateur.

Contrôleur : composant responsable des prises de décision, gère la logique du code qui prend des décisions, il est l'intermédiaire entre le modèle et la vue.

Fonctionnement

Le contrôleur va demander au modèle les données, les analyser, prendre des décisions et renvoyer le texte à afficher à la vue.

Quelques avantages

? Meilleure organisation du code;

? Diminution de la complexité lors de la conception;

18

CHAPITRE I : Présentation du cadre du projet

? Conception claire et efficace grâce à la séparation des données de la vue et du

contrôleur;

? Possibilité de réutilisation de code dans d'autres applications;

? Un gain de temps de maintenance et d'évolution du site;

? Une plus grande souplesse pour organiser le développement du site entre

différents développeurs;

? Plus de facilité pour les tests unitaires. [8]



Figure 10:Présentation modèle MVC

8 Conception détaillée

8.1 Le diagramme de déploiement

En UML, un diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que leurs relations entre eux

19

CHAPITRE I : Présentation du cadre du projet



Tableau 3: Diagramme de déploiement

8.2 Le diagramme de composants

Les diagrammes de composants et les diagrammes de déploiement sont les deux derniers types de vues statiques en UML. Les premiers décrivent le système modélisé sous forme de composants réutilisables et mettent en évidence leurs relations de dépendance. Les seconds se rapprochent encore plus de la réalité physique, puisqu'ils identifient les éléments matériels (PC, Modem, Station de travail, Serveur, etc.), leur disposition physique (connexions) et la disposition des exécutables (représentés par des composants) sur ces éléments matériels.

20



CHAPITRE I : Présentation du cadre du projet

Figure 11: Diagramme de composants

8.3 Environnement de travail Environnement matériel :

Tout au long de notre projet, nous avons eu à notre disposition un ordinateur portable qui dispose de la configuration suivante :

· Dell : Intel pentium (R) @ 2.30GHz, Ram : 4, 00 Go

· Système d'exploitation : Windows 7, Environnement technique

Php 7.0 : est un langage de scripts généraliste et Open Source, spécialement conçu pour le développement d'applications web. Il peut être intégré facilement au HTML.

21

CHAPITRE I : Présentation du cadre du projet

Wamp server : est un serveur local pour tester l'application



MySql 5.6.17 :est le SGBD utilisé dans la gestion de la base de données



Bootstrap (4): est un Framework CSS3, HTML5 et JavaScript, créé par les développeurs de Twitter .Il comporte un système de grille de 12 colonnes efficace, permettant de mettre en ordre l'aspect visuel d'une page web. Il apporte du style pour les boutons, les formulaires, la navigation et permet ainsi de concevoir un site Web rapidement et avec peu de lignes de code ajoutées.



HTML5 : définit deux syntaxes de DOM : HTML5 et XHTML5. Cette version apporte de nouvelles possibilités en termes de création d' « applications Web riches » bénéficiant de l'intégration d'éléments multimédias et d'interactivité



JQUERY [12] :C'est un Framework JavaScript. Parmi ces technologies du Web, on retrouve les standards HTML5 et CSS3 mais aussi des langages plus évolués qui permettent de dynamiser les pages Web. L'un d'eux, le plus connu et le plus utilisé, est JavaScript.

Visual Paradigm for UML : Est, comme son nom le laisse supposer, un logiciel permettant aux programmeurs de mettre en place des diagrammes UML. Disposant

22

CHAPITRE I : Présentation du cadre du projet

d'un outil créant des rapports personnalisables aux formats PDF, Word ou HTML afin de les partager et les publier sur Internet



Conclusion

Tout au long de ce chapitre, nous avons présenté une brève description du projet à réaliser, en déterminant la problématique et en proposant la solution envisagée pour faire face à la situation actuelle. Par la suite nous avons présenté une étude de méthodologies de développement choisit qui sera adoptée pour le développement de notre système.

On a définit par la suite les besoins fonctionnels et non fonctionnels, la Spécification du Backlog de produit et la préparation du planning de travail.

Les releases et les sprints qu'on va élaborer dans les chapitres suivants

Le deuxième chapitre sera consacré à la spécification des besoins, l'analyse, la conception et la réalisation des cas d'utilisation du premier release qui englobe les cas d'utilisation de la priorité 1 et 2

23

CHAPITRE II : Mise en OEuvre du Release 1

CHAPITRE II : Mise en OEuvre du Release 1

24

CHAPITRE II : Mise en OEuvre du Release 1

INTRODUCTION

Les besoins fonctionnels et non fonctionnels que nous avons élaboré précédemment ont montrés globalement le fonctionnement de notre futur système, nous allons a présent entamer la présentation du premier release qui comporte 2 sprints, chaque sprint englobe la spécification des besoins, l'analyse et l'implémentation.

Les deux principales fonctionnalités (l'inscription et l'authentification) feront l'objectif de notre travail.

Les deux derniers sprints de la release seront consacrés à la gestion des annonces et les offres qui représentent le coeur de notre futur système

1 Backlog du sprint 1

Nous allons présenter le backlog de produit de notre futur système et ceci en se basant sur les besoins fonctionnels et non fonctionnels

Cas d'utilisation Acteur Priorité

S'inscrire	Le propriétaire, le locataire
		1
S'Authentifier	Le propriétaire, le locataire et l'administrateur

Tableau 4: Backlog du sprint 1

2 Spécification des besoins

2.1 Raffiner les modèles des cas d'utilisation

Tableau des tâches

Dans le tableau ci-dessous nous allons présenter les tâches de premier sprint

25

CHAPITRE II : Mise en OEuvre du Release 1

Fonctionnalités	User story	priorité
Authentification	En tant qu'utilisateur.je peux m'authentifier pour accéder au site	1
S'inscrire	En tant qu'utilisateur, je peux m'inscrire au site	1

Tableau 5: Product backlog du sprint 1

Dans cette partie, nous allons détailler les cas d'utilisation des fonctionnalités du premier sprint .pour cela nous allons présenter pour chaque fonctionnalité son diagramme détaillé

Diagramme de cas d'utilisation « s'authentifier »

La figure suivante représente le diagramme de cas utilisation : s'authentifier



Figure 12:Diagramme de cas d'utilisation "s'authentifier"

La description détaillée de l'user story 1 « s'authentifier » est donnée par le tableau suivant :

Cas d'utilisation	S'authentifier
acteur	Utilisateur du système
précondition	l'utilisateur doit être activé.
Post-condition	Utilisateur Authentifié
Scénario Nominal	1. L'utilisateur saisit son login et son

26

CHAPITRE II : Mise en OEuvre du Release 1

	mot de passe
	2. L'utilisateur confirme la saisie de ses données d'identification
3. Le système vérifie les données d'identification
4. Le système affiche l'interface d'accueil l'utilisateur.
	E1. Si le login et/ou le mot de passe sont incorrects L'enchaînement démarre au point
Scénario D'exception	3. Le système affiche un message d'erreur informant l'utilisateur que son login ou mot de passe sont incorrects et le scénario reprend à l'action1.

Tableau 6: Description textuelle du cas d'utilisation « S'authentifier » Diagramme du cas d'utilisation : s'inscrire :



Figure 13:Diagramme du cas d'utilisation : s'inscrire

La description détaillée de l'user story 1 « s'inscrire » est donnée par le tableau suivant :

Cas d'utilisation

S'inscrire

27

CHAPITRE II : Mise en OEuvre du Release 1

acteur	Utilisateur du système
précondition	l'utilisateur doit être préparer.
Post-condition	Utilisateur est inscrit
Scénario Nominal	1. L'utilisateur demande le formulaire d'inscription 2. Le système affiche le formulaire d'inscription 3. L'utilisateur confirme la saisit de ses données d'identification 4. Le système vérifie les données saisies 5.Le système affiche un message de confirmation.
Scénario D'exception	E1. Si l'email existe le scénario reprend au point 1 E2.si il ya erreur le scénario repend au point 1

Tableau 7: Description textuelle du cas d'utilisation « s'inscrire »

2.2 Prototypes des interfaces utilisateurs

Interface authentification :

Prototype de l'interface Authentification qui comporte 2 champs : nom d'utilisateur et mot de passe et un bouton login pour accéder aux services du site

28

CHAPITRE II : Mise en OEuvre du Release 1



Figure 14: Interface s'inscrire

Prototype de l'Interface « s'inscrire » permet aux utilisateurs de s'enregistrer dans le site ,il comporte les champs nécessaires à l'inscription pour bénéficier des services du site.



Figure 15: Interface inscription

3 Analyse des cas d'utilisation de priorité 1

Nous allons analyser les cas d'utilisation du premier sprint Diagramme des classes d'analyse

Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter les classes et les interfaces des systèmes ainsi que les différentes relations entre celles-ci.

29

CHAPITRE II : Mise en OEuvre du Release 1

Ce diagramme fait partie de la partie statique d'UML car il fait abstraction des aspects temporels et dynamiques

Diagramme des classes d'analyse de cas s'authentifier



Figure 16:Diagramme des classes d'analyse de cas s'authentifier

Diagramme des classes d'analyse de cas « s'inscrire » :



Figure 17: Diagramme des classes d'analyse de cas « s'inscrire »

3.1 Diagramme de collaboration

Diagramme de collaboration du cas s'authentifier

30

CHAPITRE II : Mise en OEuvre du Release 1



Figure 18:Diagramme de collaboration du cas s'authentifier Diagramme de collaboration du cas « s'inscrire »



Figure 19:Diagramme de collaboration du cas « s'inscrire »

4 Conception des cas d'utilisation de priorité 1

Dans cette partie nous allons procéder à la conception des cas d'utilisation de priorité1

31

CHAPITRE II : Mise en OEuvre du Release 1

4.1 La conception des cas d'utilisation du sprint 1

4.1.1 Diagramme de classes de conception

Nous allons établir le diagramme de classe du premier sprint qui englobe les cas

d'utilisation : s'authentifier et s'inscrire

Diagramme de classe « authentification »



Figure 20 : Diagramme de classe des cas d'utilisation « s'authentifier » Diagramme de classe du cas d'utilisation « s'inscrire »



Figure 21:Digramme de classe du cas « s'inscrire »

32

CHAPITRE II : Mise en OEuvre du Release 1

4.1.2 Diagramme d'interaction (diagramme de séquence) Diagramme de séquence du cas d'utilisation « s'authentifier »

Pour bénéficier des services de notre futur système l'utilisateur doit s'authentifier par la saisit de login et mot de passe, le système vérifie l'existence de ces paramètres dans la base de données et en cas d'erreur il envoie un message incitant l'utilisateur à corriger ces erreurs ou à s'inscrire.



Figure 22 : Diagramme de séquence "s'authentifier"

33



CHAPITRE II : Mise en OEuvre du Release 1

Diagramme de séquences du cas « s'inscrire »

Figure 23 : Diagramme de séquence du cas "s'inscrire"

4.1.3 La conception des classes du sprint 1 (diagramme de classe entités)

Figure 24:La conception des classes du sprint 1

34

CHAPITRE II : Mise en OEuvre du Release 1

4.2 Schéma de la base de données Table : Utilisateur
Nom du colonne Type de données		obligatoire	Unique	clé
Id_user	Int(11)	oui	Oui	Clé primaire
Pseudo	Varchar(100)	oui	Nom
Email	Varchar(100)	oui	Oui
status	Varchar(50)	oui	Non
Téléphone	Int(8)	oui	Oui
Password	Varchar(100)	oui	Non
photos	Varchar(200)	non	Non

Tableau 8:Table utilisateur

Diagrammes d'activité

Le diagramme d'activité représente les activités que réalisent un ou plusieurs objets. Il peut correspondre à la description en détail d'une activité du diagramme d'états transitions, à la description d'une méthode. Il peut également décrire l'activité d'un système ou d'un sous système en assignant les responsabilités à chaque acteur. Le diagramme d'activités constitue aussi un bon choix pour décrire un cas d'utilisation.

Diagramme d'activité du cas « authentification »



Figure 25 : Diagramme d'activité authentification

35

CHAPITRE II : Mise en OEuvre du Release 1

Diagramme d'activité du cas « s'inscrire »



Figure 26:Diagramme d'activité « inscription »

5 Implémentation des cas d'utilisation prioritaires

Après l'analyse et la conception des cas d'utilisation s'inscrire et s'authentifier nous allons procéder à l'implémentation de ces cas.

5.1 Les captures d'écran

Capture d'écran du cas « s'authentifier »

36



CHAPITRE II : Mise en OEuvre du Release 1

Figure 27:Capture d'écran du cas « s'authentifier »

Capture d'écran du cas «inscription »

Figure 28:Capture d'écran «inscription »

SPRINT 2 : « Gestion des annonces, Gestion des offres, gestion des réservations »

37

CHAPITRE II : Mise en OEuvre du Release 1

1 Backlog du Sprint 2

Dans le tableau ci-dessous nous allons présenter les tâches du sprint « 2 »

Fonctionnalités	User story	priorité
Gérer annonces	En tant que propriétaire je peux ajouter, modifier et supprimer une annonce de location/colocation/séjour ou dépannage gratuit	2
Gérer offres	En tant que locataire ou colocataire je peux consulter les offres, contacter le propriétaire et fixer un rendez-vous	2
Gérer réservations	En tant que locataire je peux demander une réservation En tant que propriétaire je peux visualiser et répondre a une réservation et fixer un rendez-vous	2

Tableau 9: Backlog du sprint 2

2 Spécification des besoins

2.1 Raffiner les modèles des cas d'utilisation de priorité « 2 » Les cas d'utilisation de sprint 2 font le coeur de l'application là ou l'utilisateur peut ajouter une annonce de location, colocation, séjour de vacances et ou un dépannage gratuit .

L'utilisateur peut en tant que locataire visualiser ces offres et faire une réservation de bien immobilier.

Diagramme de cas d'utilisation du sprint « 2 »

38

CHAPITRE II : Mise en OEuvre du Release 1



Figure 29:Diagramme de cas d'utilisation du sprint 2

Fiche descriptif du cas d'utilisation « gérer annonces »

Acteur	proprietaire
Objectif	Cette fonctionnalité permet au proprietaire de bien immobilier d'ajouter/modifier /supprimer un logement de location,collocation et séjour de vacances,de confirmer un rendez-vous et louer un logement
Pré-condition	Le logement n'est pas ajouté
Post-condition	Logement ajouté
Scénario principal	Accéder à l'espace utilisateur après authentification Le système affiche l'interface de remplissage info logement Le proprietaire remplit le formulaire.et clique sur ajouter Le système vérifie les champs. Le système fait les mises à jour.
Scénario D'exception	Si L'administrateur ne s'authentifie pas correctement. le systeme demarre au point 1

Tableau 10:Descriptif du cas d'utilisation "gérer annonces"

39

CHAPITRE II : Mise en OEuvre du Release 1

Tableau descriptif du sous cas « gérer offres »

Cas d'utilisation	gérer offres
acteur	Le locataire /colocataire
précondition	Annonce existante
Post-condition	Réservation réussit
Scénario Nominal	1. L'utilisateur clique sur l'annonce choisit 2. l'utilisateur clique sur le bouton réserver 3. le système affiche formulaire de réservation 4. L'utilisateur remplit le formulaire et clique sur envoyer 5.Le système enregistre le formulaire et envoie un email au propriétaire
Scénario D'exception	E1. Si le formulaire n'ai pas remplit correctement le système affiche un message d'erreur et démarre au point 4.

Tableau 11: Tableau descriptif du sous cas « gérer offres »

Tableau descriptif du sous cas « gérer réservation »

Acteur	Proprietaire \ locataire
Objectif	Cette fonctionnalité permet au: proprietaire de bien immobilier de visualiser les reservation et fixer un rendez-vous locataire de visualiser les offers et faire une réservation
Pré-condition	La reservation n'est pas fait
Post-condition	La réservation est effectué et le rendez vous est fixé

40

CHAPITRE II : Mise en OEuvre du Release 1

	Accéder à l'espace utilisateur après authentification
	L'utilisateur affiche les offres
	Le locataire clique sur le bouton résevation
Scenario principal	Le système affiche le formulaire de demande de réservation
	Le locataire remplit le formulaire
	Le proprietaire affiche les réservations demandées et fixe un rendez-vous
Scenario	E1:Si le locataire ne s'authentifie pas
D'exception	le système demarre au point 1

Tableau 12: Tableau descriptif du sous cas « gérer réservation »

2.2 Elaboration des Prototypes

Prototype de l'interface « ajouter annonces »

Le prototype de l'interface « ajouter annonces » est composé de plusieurs champs qui permettent de saisir le maximum de critères de bien immobilier

41



CHAPITRE II : Mise en OEuvre du Release 1

Figure 30:Prototype de l'Interface : proposer logement

42



CHAPITRE II : Mise en OEuvre du Release 1

Prototype de l'Interface rechercher logement :

Cette interface permet à travers des listes de choisir les critères du logement souhaité

Figure 31:Prototype de l'Interface rechercher logement

Prototype de l'interface « faire une réservation

Cette interface permet la réservation de bien immobilier

Figure 32: prototype du cas d'utilisation réservation

43



CHAPITRE II : Mise en OEuvre du Release 1

3 Analyse des cas d'utilisation du priorité 2

3.1 Diagramme de classe d'analyse

Diagramme des classes d'analyse du cas « gérer annonces »

Figure 33:Diagramme des classes d'analyse du cas « gérer annonces »

Diagramme des classes d'analyse du cas « gérer offres »

Figure 34:Diagramme des classes d'analyse du cas « gérer offres »

44



CHAPITRE II : Mise en OEuvre du Release 1

iagramme des classes d'analyse du cas « gérer réservation »

Figure 35:Diagramme des classes d'analyse du cas « gérer réservation »

3.2 diagramme de collaboration du cas gérer annonces « ajout logement »

Figure 36:Diagramme de collaboration du cas gérer annonces « ajout logement »

Diagramme de collaboration du cas gérer annonces « chercher logement »

45



CHAPITRE II : Mise en OEuvre du Release 1

Figure 37:Diagramme de collaboration du cas gérer annonces « chercher logement ))

Diagramme de collaboration gérer offre « chercher offres »

Figure 38:Diagramme de collaboration gérer offre « chercher offres ))

46

CHAPITRE II : Mise en OEuvre du Release 1

Diagramme de collaboration gérer offre « gérer réservations »



Figure 39:Diagramme de collaboration gérer offre « gérer réservations »

4 Conception des cas d'utilisation de priorité 1 et 2

Dans cette partie nous allons procéder à la conception des cas d'utilisation de priorité 1 et 2.Nous allons élaborer les diagrammes de classes, de séquences et d'activités.

4.1 La conception des cas d'utilisation du release 1

4.1.1 Diagramme de classes de conception

Nous allons établir le diagramme de classe du premier release qui englobe les cas d'utilisation : s'authentifier, s'enregistrer, gérer annonces et gérer offres

47

CHAPITRE II : Mise en OEuvre du Release 1

Diagramme de classe du release 1 :



Figure 40:Diagramme de classe du release 1

48



CHAPITRE II : Mise en OEuvre du Release 1

4.1.2 Diagramme de séquences du cas « ajouter annonce »

Le diagramme de séquences présente l'interaction entre les constituants du système : l'acteur, l'interface, le contrôleur et la base de données.

Figure 41:Diagramme de séquences du cas « ajouter annonce »

49



CHAPITRE II : Mise en OEuvre du Release 1

Diagramme de séquence du cas « modifier annonce »

Figure 42:Diagramme de séquence du cas « modifier annonce »

50

CHAPITRE II : Mise en OEuvre du Release 1

Diagramme de séquence du cas « consulter offres »



Figure 43:Diagramme de séquence du cas « consulter offres »

51



CHAPITRE II : Mise en OEuvre du Release 1

Diagramme de séquence du cas « gérer réservations »

Figure 44:Diagramme de séquence du cas « gérer réservations »

52



CHAPITRE II : Mise en OEuvre du Release 1

4.2 Le diagramme de classe entités du sprint 2

Figure 45: Le diagramme de classe entités du sprint 2

53

CHAPITRE II : Mise en OEuvre du Release 1

5 Schéma de la base de données :

Table logement :
Nom du Type de colonne données		obligatoire	unique	clé
id	Int(20)	oui	oui	Clé primaire
Id_user	Int(11)	oui	oui	Clé étrangère
type	Varchar(30)	oui	non
ville	Varchar(30)	oui	non
Superficie	int(8)	oui	non
Status	varchar(100)	oui	non
prix	float	oui	non
adresse	Varchar(300)	oui	non
pieces	int(100)	non	non
Nbr_coloc	Int(8)	oui	non
Motif	Varchar(20)	oui	non
Image	Varchar(300)	oui	non
Etat	Varchar(100)	oui	non
Equipement	Varchar(100)	oui	non
diponibilite	date	oui	non
Description	longtext	non	non
Date_debut	date	oui	non
Date_fin	date	oui	non
adresse	Varchar(255)	oui	non

Tableau 13: Table logement

54

CHAPITRE II : Mise en OEuvre du Release 1

Table réservation :
Nom du Type de données colonne		obligatoire	unique	clé
Id	Int(20)	oui	oui	Clé primaire
Id_log	Int(11)	oui	oui	Clé étrangère
Id_user	Int(11)	oui	oui	Clé étrangère
Telephone	Int(11)	oui	oui
Date_debut	date	oui	oui
Date fin	date	oui	non
Reponse	Varchar(500)	oui	oui

Tableau 14: Table réservation

Table : photos
Nom du Type de données colonne		obligatoire	unique	clé
Id_log	Int(11)	oui	oui	Clé étrangère
Vue1	Varchar(500)	non	non
Vue2	Varchar(500)	non	non
Vue3	Varchar(500)	non	non
Vue4	Varchar(500)	non	non

Tableau 15:Table photos

55

CHAPITRE II : Mise en OEuvre du Release 1

Diagrammes d'activité

Le diagramme d'activités représente les activités que réalisent un ou plusieurs objets. Il peut correspondre à la description en détail d'une activité du diagramme d'états transitions, à la description d'une méthode. Il peut également décrire l'activité d'un système ou d'un sous système en assignant les responsabilités à chaque acteur. Le diagramme d'activités constitue aussi un bon choix pour décrire un cas d'utilisation.

Diagramme d'activité du cas « ajouter annonces »



Figure 46:Diagramme d'activité du cas « ajouter annonces » Diagramme d'activité du cas « gérer réservation »



Figure 47: Diagramme d'activité du cas « gérer réservation »

56

CHAPITRE II : Mise en OEuvre du Release 1

6 Implémentation du cas d'utilisation du release 1

6.1 Les captures d'écran

Capture d'écran du cas « ajouter annonces »



Figure 48 : Capture d'écran du cas «ajouter annonces »

57



CHAPITRE II : Mise en OEuvre du Release 1

Capture d'écran du cas «consulter offres »

Figure 49:Capture d'écran du cas «consulter offres »

Capture d'écran du cas «modifier annonces»

Figure 50:Capture d'écran du cas «modifier annonce»

58

CHAPITRE II : Mise en OEuvre du Release 1

Capture d'écran du cas «gérer réservation»





Figure 51: Capture écran "gérer réservation"

59

CHAPITRE II : Mise en OEuvre du Release 1

Conclusion

Au cours de ce chapitre nous avons élaboré la spécification des besoins passant par l'analyse, la conception et l'implémentation des cas d'utilisation de priorité majeure. Dont l'authentification, la gestion des annonces et la gestion des offres.

Dans le chapitre suivant nous entamons le deuxième sprint de notre application qui portera sur la gestion des demandes et la gestion des contacts

60

Chapitre III : Mise en OEuvre du Release 2

Chapitre 3 : Mise en oeuvre de la release 2

61

Chapitre III : Mise en OEuvre du Release 2

Introduction

Après la réalisation des fonctionnalités du release 1 ,nous allons passer a l'analyse, la conception et la réalisation des cas de sprint 3 et 4 :la gestion des demandes et la gestion des dépannages

1 Backlog du sprint 3

Nous allons présenter le backlog de produit de release 2 ou on va détailler les sprints de priorité 3

Cas d'utilisation Acteur Priorité

			le locataire 3
Gérer demandes
			Le propriétaire et le locataire 3
Gérer dépannages

Tableau 16: Backlog du produit

2 spécification des besoins

2.1 Raffiner les modèles des cas d'utilisation de priorité « 3 »

Tableau des tâches

Dans le tableau ci-dessous nous allons présenter les tâches de premier sprint

Fonctionnalités	User story	priorité
Gérer demandes	En tant qu'administrateur.je peux déposer une demande de location \colocation ou séjour de vacances	3
Gérer dépannages	En tant que propriétaire je peux ajouter ,modifier et supprimer une annonces de dépannage gratuit En tant que locataire je peux chercher un dépannage gratuit	3

Tableau 17: Tableau des taches du release 2

62



Chapitre III : Mise en OEuvre du Release 2

Diagramme de cas d'utilisation du release 3

La figure si dessous représente le diagramme de cas d'utilisation de 3eme release qui englobe les cas gestion de demandes de logement et la gestion de dépannages

Figure 52:Diagramme de cas d'utilisation de release 3

2.2 Elaboration des prototypes des interfaces utilisateurs Prototype du cas d'utilisation « ajouter demande »

Figure 53:Prototype du cas d'utilisation « ajouter demande »

63



Chapitre III : Mise en OEuvre du Release 2

Prototype du cas d'utilisation « ajouter dépannage gratuit »

Figure 54:Prototype du cas d'utilisation « ajouter dépannage gratuit ))

3 Analyse des cas d'utilisation de priorité

3.1 Diagramme des classes d'analyse du sprint « 3 » Diagramme de classe d'analyse du cas « formuler demande »

Figure 55:Diagramme de classe d'analyse du cas « formuler demande ))

64



Chapitre III : Mise en OEuvre du Release 2

diagramme de classe d'analyse du cas « formuler dépannage »

Figure 56: Diagramme de classe d'analyse du cas « dépannage »

3.2 Diagramme de collaboration Diagramme de collaboration « déposer demande »

Figure 57: Diagramme de collaboration (déposer demande)

65

Chapitre III : Mise en OEuvre du Release 2

diagramme de collaboration « déposer dépannage »

nous n'allons pas élaborer ce cas car ce sont les mêmes procédures pour le cas d'utilisation déposer demande.





Figure 58: Diagramme de collaboration « déposer dépannage »

4 Conception des cas d'utilisation de priorité 3

4.1 La conception de cas d'utilisation prioritaire

4.1.1 Diagramme de classe de conception

Dans la partie suivante nous allons passer à la conception du diagramme de classe de conception de la release 3

66

Chapitre III : Mise en OEuvre du Release 2



Figure 59 : Diagramme des classes de conception du release 2

4.1.2 Diagramme d'interaction (diagramme de séquence) Diagramme de séquence du cas d'utilisation « déposer demandes »

67



Chapitre III : Mise en OEuvre du Release 2

Figure 60:Diagramme de séquence du cas d'utilisation « déposer demandes »

4.2 Diagramme de classe entités

Nous allons si dessous présenter le schéma relationnel du release 2

68

Chapitre III : Mise en OEuvre du Release 2



Figure 61: Schéma relationnel de la release 2 Diagramme de la base de données

Table : demande

Nom du Type de colonne données		obligatoire	unique	clé
Id	Int(11)	oui	oui	Clé primaire
Id_user	Int(11)	oui	oui	Clé étrangère
Region	Varchar(100)	oui	non
Genre	Varchar(100)	oui	non
Type	Varchar(100)	oui	non
Status	Varchar(100)	oui	non
superficie	Int(11)	oui	non
etat	Varchar(100)	oui	non
budget	Int(11)	oui	non

69

Chapitre III : Mise en OEuvre du Release 2

	Nbr-piece			Int(11) oui non
				text non non
	preference
Table :dépannage						Tableau 18: Table demande
Nom du colonne Type de données						obligatoire	unique	clé
Id					Int(11)	oui	oui	Clé primaire
Id_user					Int(11)	oui	oui	Clé étrangère
distination					Varchar(100)	oui	non
provenance					Varchar(100)	oui	non
Nbr-jours					Int(11)	oui	non
identite					Varchar(100)	oui	non
motif					varchar(100)	oui	non

Tableau 19: Table dépannage

Diagramme d'activités

Diagramme d'activités « déposer demande »



Figure 62:Diagramme d'activités « déposer demande »

70



Chapitre III : Mise en OEuvre du Release 2

5 Implémentation des cas d'utilisation prioritaires

5.1 Les captures d'écran Interface demande

Figure 63: Interface demande

Interface déposer demande de logement

Figure 64:Interface déposer demande de logement

71



Chapitre III : Mise en OEuvre du Release 2

Interface consulter demande

Figure 65:Interface consulter demande

Interface ajouter dépannage

Figure 66:Interface ajouter dépannage

72

Chapitre III : Mise en OEuvre du Release 2

Sprint 4 « gestion avis, gestion contact»

1 Backlog du sprint 4

Cas d'utilisation Acteur Priorité

Le propriétaire, le locataire et
l'administrateur

4

Gérer avis

Gérer contact	Le propriétaire et le locataire 4

Tableau 20:Backlog du sprint 4

2 Spécification des besoins

Après la réalisation des cas d'utilisation gérer demandes et gérer dépannages nous allons entamer les cas d'utilisation de sprint 4 : gestion des avis et la gestion contact.

2.1 Raffiner les modèles des cas d'utilisation de priorité 4

Cas d'utilisation de sprint 4



Figure 67:Cas d'utilisation de sprint 4

73



Chapitre III : Mise en OEuvre du Release 2

2.2 Elaboration des prototypes des interfaces utilisateurs Prototype de l'interface gérer avis

Figure 68: Prototype de l'interface gérer avis

Prototype de l'interface gérer contact

Figure 69:Prototype de l'interface gérer contact

74

Chapitre III : Mise en OEuvre du Release 2

3 Analyse des cas d'utilisation de priorité 4

3.1 Diagramme de classe d'analyse

Diagramme de classe d'analyse du cas d'utilisation « gérer avis »



Figure 70:Diagramme de classe d'analyse du cas d'utilisation « gérer avis »

Diagramme de classe d'analyse du cas d'utilisation « gérer contact »



Figure 71: Diagramme de classe d'analyse du cas d'utilisation « gérer contact »

3.2 Diagramme de collaboration

Diagramme de collaboration du cas d'utilisation « gérer avis »

75

Chapitre III : Mise en OEuvre du Release 2



Figure 72: Diagramme de collaboration du cas d'utilisation « gérer avis ))

Diagramme de collaboration du cas d'utilisation « gérer contact »



Figure 73:Diagramme de collaboration du cas d'utilisation « gérer contact ))

4 Conception des cas d'utilisation de priorité 4

4.1 La conception des cas d'utilisation prioritaires

4.1.1 Diagramme de classe de conception

Diagramme de classe de conception de sprint 4

76

Chapitre III : Mise en OEuvre du Release 2



Figure 74: Diagramme de classe de conception de sprint 4

77



Chapitre III : Mise en OEuvre du Release 2

4.1.2 Diagramme d'interaction (diagramme de séquence) Diagramme de séquence du cas d'utilisation « gérer avis »

Figure 75:Diagramme de séquence du cas d'utilisation « gérer avis »

78



Chapitre III : Mise en OEuvre du Release 2

Diagramme de séquence du cas d'utilisation « gérer contact »

Figure 76:Diagramme de séquence du cas d'utilisation « gérer contact »

79

Chapitre III : Mise en OEuvre du Release 2

4.2 Diagramme de classe entités de sprint « 4 »



Figure 77:Diagramme de classe entités de sprint « 4 »

Diagramme de la base de données Table : avis
Nom du colonne type		obligatoire	unique	Clé primaire
Id	Int(10)	oui	oui	Clé primaire
Id_user	Int(11)	oui	oui	Clé étrangère
Id_log	Int(11)	oui	oui	Clé étrangère
Text	longtext	non	oui
Rating	Int(10)	non	oui
date	date	non	oui

Tableau 21: Table avis

80

Chapitre III : Mise en OEuvre du Release 2

4.3 Diagramme d'activités

Diagramme d'activités du cas d'utilisation « gérer avis »



Figure 78:Diagramme d'activités du cas d'utilisation « gérer avis » Diagramme d'activités du cas d'utilisation « gérer contact »



Figure 79:Diagramme d'activités du cas d'utilisation « gérer avis »

81



Chapitre III : Mise en OEuvre du Release 2

5 Implémentation des cas d'utilisation prioritaires

Les capture d'écran

Interface du cas d'utilisation « gérer avis »

Figure 80:Interface du cas d'utilisation «gérer avis »

Interface du cas d'utilisation «gérer contact »

Figure 81:Interface du cas d'utilisation «gérer contact »

82

Chapitre III : Mise en OEuvre du Release 2

Conclusion

Ce chapitre, présente une phase primordiale pour l'étude et l'analyse de notre futur système. Nous avons défini les différents besoins fonctionnels et non fonctionnels ainsi Nous avons élaboré les phases d'analyse et de conception de la release. Et nous avons raffiné les cas d'utilisations et les différents scénarios possibles. Dans le chapitre suivant, nous allons passer à l'étude, l'analyse, la conception et la réalisation de la release « 3 » qui englobent les cas d'utilisation de priorité 5.

83

Chapitre IV : Mise en OEuvre du Release 3

Chapitre 4 : Mise en oeuvre de la release 3

84

Chapitre IV : Mise en OEuvre du Release 3

Introduction

Dans ce dernier chapitre nous allons définir les besoins et réaliser les fonctionnalités du release « 3 » .Nous allons dans cette dernière phase étudier, analyser, concevoir et raffiner les cas d'utilisation du sprint 5

La gestion des utilisateurs et la gestion des logements ferons l'objet de sprint de priorité 5

1 Backlog du sprint 5

Nous allons à présent présenter le backlog de produit de sprint 5 de notre futur

système nous allons analyser, et concevoir la dernière partie gérer par l'administrateur du système qui va gérer les utilisateurs et les logements.

Cas d'utilisation Acteur Priorité

			L'administrateur 5
Gérer les utilisateurs
Gérer les logements			L'administrateur 5

Tableau 22: Backlog du sprint 5

2 Spécification des besoins

2.1 Raffiner les modèles des cas d'utilisation de priorité « 5 »

Tableau des taches :

Fonctionnalités	User story	priorité
Gérer utilisateurs	En tant qu'administrateur je peux visualiser et supprimer un utilisateur	5
Gérer logements	En tant qu'administrateur je peux consulter les offres, et supprimer un logement	5

Tableau 23: Product backlog du sprint 5

85



Chapitre IV : Mise en OEuvre du Release 3

Diagramme de cas d'utilisation du release « 3 »

Figure 82:Diagramme de cas d'utilisation du release « 3 »

2.2 Elaboration des prototypes des interfaces utilisateurs

Interface du cas d'utilisation « gérer utilisateurs »

Figure 83:Interface du cas d'utilisation « gérer utilisateurs »

86

Chapitre IV : Mise en OEuvre du Release 3

Interface du cas d'utilisation « gérer logements »



Figure 84:Interface du cas d'utilisation « gérer logements »

La description détaillée de l'user story « gérer utilisateurs » est donnée par le tableau suivant :

Cas d'utilisation	gérer utilisateurs
acteur	administrateur
précondition	L'administrateur doit être activé.
Post-condition	L'utilisateur est supprimer
Scénario Nominal	1. l'administrateur choisit l'utilisateur a supprimer 2. l'administrateur clique sur supprimer 3. Le système demande une confirmation. 4. l'administrateur clique sur confirmer.
Scénario D'exception	E1. Si l'administrateur ne confirme pas le scénario reprend à l'action 2

Tableau 24: Description du cas "supprimer utilisateur"

87

Chapitre IV : Mise en OEuvre du Release 3

Fiche descriptif du cas d'utilisation « gérer logements »

Cas d'utilisation	gérer logements
acteur	administrateur
précondition	L'administrateur doit être activé.
Post-condition	Le logement est supprimer
Scénario Nominal	1. l'administrateur choisit le logement a supprimer 2. l'administrateur clique sur supprimer 3. Le système demande une confirmation. 4. l'administrateur clique sur confirmer.
Scénario D'exception	E1. Si l'administrateur ne confirme pas le scénario reprend à l'action 2

Tableau 25: Descriptif du cas "gérer logements"

3 Analyse des cas d'utilisation de priorité 5

Nous allons à présent entamer la phase d'analyse et ceci par le traçage des diagrammes appropriés.

88

Chapitre IV : Mise en OEuvre du Release 3 3.1 Diagramme des classes d'analyse

Diagramme de classe d'analyse du cas d'utilisation « gérer utilisateur »



Figure 85:Diagramme de classe d'analyse du cas d'utilisation « gérer utilisateur ))

Diagramme de classe d'analyse du cas d'utilisation « gérer logements »



Figure 86:Diagramme de classe d'analyse du cas d'utilisation « gérer logements ))

89

Chapitre IV : Mise en OEuvre du Release 3

3.2 Le diagramme de collaboration

Diagramme de collaboration du cas « gérer utilisateurs »



Figure 87:Diagramme de collaboration du cas « gérer utilisateurs )) Diagramme de collaboration du cas « gérer logements »



Figure 88:Diagramme de collaboration du cas « gérer logements ))

4 Conception des cas d'utilisation de priorité 5

4.1 La conception des cas d'utilisation du release 3

La phase de conception et la plus importante dans la réalisation de la release car elle

permet de spécifier les classes et les relations entre les différentes intervenant.

90



Chapitre IV : Mise en OEuvre du Release 3

4.1.1 Diagramme de classes de conception

Diagramme de classe de conception du release 3

Figure 89: Diagramme de classe de conception du release 3

4.1.2 Diagramme d'interaction (diagramme de séquence)

Diagramme de séquence du cas d'utilisation « gérer utilisateur »

91

Chapitre IV : Mise en OEuvre du Release 3



Figure 90:Diagramme de séquence du cas d'utilisation « gérer utilisateur » Diagramme de séquence du cas d'utilisation « gérer logement »



Figure 91:Diagramme de séquence du cas d'utilisation « gérer logement »

92



Chapitre IV : Mise en OEuvre du Release 3

4.2 La conception des classes du sprint 5

Diagramme de classe entités du release « 3 »

Figure 92:Diagramme de classe entités du release « 3 »

Table administrateur

Nom colonne type obligatoire null Clé primaire

id

Int (11) oui non Clé primaire

username

Varchar(16) oui non

Mot de passe

Varchar(50) oui non

Nom_prenom

Varchar(100) oui non

email

Varchar(50) oui non

adresse

text oui non

93

Chapitre IV : Mise en OEuvre du Release 3

telephone

Int (12) oui non

Tableau 26: Table administrateur

5 Implémentation des cas d'utilisation prioritaires

5.1 Les captures d'écran

Capture d'écran espace administrateur



Figure 93:Capture d'écran espace administrateur

94



Chapitre IV : Mise en OEuvre du Release 3

Capture d'écran espace gérer utilisateur

Tableau 27: Capture d'écran espace gérer utilisateur

Capture d'écran espace gérer logement

Tableau 28: Capture d'écran espace gérer logement

95



Chapitre IV : Mise en OEuvre du Release 3

5.2 Diagramme de classe globale

Tableau 29:Diagramme de classe globale

5.3 Règles de passage du diagramme de classe en modèle relationnel

A partir de la description conceptuelle que nous avons effectuée, on peut réaliser le modèle relationnel; vu que le système d'information ne peut pas le manipulé directement; et ça en utilisons des règles de passages de l'UML vers le relationnel.

Règle1: présence de la cardinalité (1..1) d'un côté de l'association

Chaque classe se transforme en une table Chaque attribut de classe se transforme en un champ de table L'identifiant de la classe qui est associée à la cardinalité (0..1) devient le clé étrangère de l'autre

Règle2: présence de (N..N) des deux côtés de l'association

Chaque classe se transforme en une table .Chaque attribut de classe se transforme en un champ de table. L'association se transforme en une table. Cette table a comme champs l'identifiant de chacune des deux classes, plus d'éventuels autres attributs.

96

Chapitre IV : Mise en OEuvre du Release 3

Règle3: présence d'une généralisation

Méthode 1:Créer une table avec tous les attributs des classes. Ajouter un attribut pour distinguer les types des objets.

Méthode 2:Créer une table pour chaque sous type, chaque table se compose des attributs génériques et d'attributs spécifiques.

Méthode 3:Créer une table par classe et des associations. [9]

5.4 Schéma de la base de données complet Table utilisateur
Nom du colonne Type de données		obligatoire	unique	clé
Id_user	Int(11)	oui	oui	Clé primaire
Pseudo	Varchar(100)	oui	non
Email	Varchar(100)	oui	oui
Téléphone	Int(8)	oui	oui
Password	Varchar(100)	oui	non
status	Varchar(50)	oui	non
photos	Varchar(200)	non	non

Tableau 30:Table utilisateur

97

Table logement		Chapitre IV : Mise en OEuvre du Release 3
Nom du colonne Type de données		obligatoire	unique	clé
id	Int(20)	oui	oui	Clé primaire
Id_user	Int(20)	oui	oui	Clé étrangère
type	Varchar(30)	oui	oui
ville	Varchar(30)	oui	non
Superficie	int(8)	oui	non
Status	Varchar(100)	oui	non
prix	float	oui	non
pieces	int(10)	non	non
Nbr_coloc	Int(8)	oui	non
Motif	Varchar(20)	oui	non
Image	Varchar(300)	oui	non
Etat	Varchar(100)	oui	non
Equipement	Varchar(100)	oui	non
diponibilite	date	oui	non
Description	longtext	non	non
Date_debut	date	oui	non
Date_fin	date	oui	non
adresse	Varchar(300)	oui	non

Tableau 31:Table logement

98

Table photos		Chapitre IV : Mise en OEuvre du Release 3
Nom du colonne Type de données		obligatoire	unique	clé
Id_log Vue1 Vue2 Vue3 Vue4	Int(11) Varchar(500) Varchar(500) Varchar(500) Varchar(500)	oui non non non non	oui non non non non	Clé étrangère

Tableau 32:Table photos

Table type logement

Nom du colonne Type de données obligatoire unique clé

Id

Int(11) oui oui Clé étrangère

libelle	Varchar(200) non non

Tableau 33:Table type logement

Table réservation
Nom du colonne Type de données		obligatoire	unique	clé
Id	Int(11)	oui	oui	Clé primaire
Id_log	Int(11)	oui	oui	Clé étrangère
Id_user	Int(11)	oui	oui	Clé étrangère
Telephone	Int(11)	oui	oui
Date_debut	date	oui	oui
Date fin	date	oui	non
Reponse	Varchar(500)	oui	oui

Tableau 34:Table réservation

99

Table demande		Chapitre IV : Mise en OEuvre du Release 3
Nom du colonne Type de données		obligatoire	unique	clé
Id	Int(11)	oui	oui	Clé primaire
Id_user	Int(11)	oui	oui	Clé étrangère
Region	Varchar(100)	oui	non
Genre	Varchar(100)	oui	non
Type	Varchar(100)	oui	non
Status	Varchar(100)	oui	non
superficie	Int(11)	oui	non
etat	Varchar(100)	oui	non
budget	Int(11)	oui	non
Nbr-piece	Int(11)	oui	non
preference	text	non	non

Tableau 35:Table demande

Table dépannage
Nom du colonne Type de données		obligatoire	unique	clé
Id	Int(11)	oui	oui	Clé primaire
Id_user	Int(11)	oui	oui	Clé étrangère
distination	Varchar(255)	oui	non
provenance	Varchar(255)	oui	non
Nbr-jours	Int(11)	oui	non
identite	Varchar(100)	oui	non
motif	Varchar(100)	oui	non

Tableau 36:Table dépannage

100

Chapitre IV : Mise en OEuvre du Release 3

Table avis
Nom du colonne type		obligatoire	unique	Clé primaire
Id	Int(11)	oui	oui	Clé primaire
Id_user	Int(11)	oui	oui	Clé étrangère
Id_log	Int(11)	oui	oui	Clé étrangère
Text	longtext	non	oui
Rating	Int(10)	non	oui
date	date	non	oui

Tableau 37:Table avis

Table administrateur
Nom colonne type		obligatoire	nullable	Clé primaire
id	Int (11)	oui	non	Clé primaire
username	Varchar(16)	oui	non
Mot de passe	Varchar(59)	oui	non
adresse	text	oui	non
telephone	Int (20)	oui	non
Nom prenom	Varchar(100)	oui	non

Tableau 38:Table administrateur

101

Chapitre IV : Mise en OEuvre du Release 3

Conclusion

A la fin de ce chapitre, nous avons aboutit à produire notre troisième et dernier Release, nous avons réussit a réaliser notre application passant par l'analyse, la conception, l'implémentation des cas d'utilisation gérer utilisateur et gérer logement ce qui nous a permit de finaliser notre application et aboutir à une application complète et fonctionnelle.

102

Chapitre V : Hébergement et Référencement

Chapitre V : Hébergement et Référencement

103

Chapitre V : Hébergement et Référencement

Hébergement concret et référencement

1 Introduction

L'hébergement web est une phase primordiale dans l'élaboration d'un projet web car

c'est la concrétisation du projet en le mettant sur le réseau qui le rend accessible 24/24 et 7jours /7 via un navigateur web.

Après l'étude qu'on a fait sur le domaine de location et colocation immobilière en Tunisie Nous avons constaté que les sites déjà existant sont généralement des sites de d'annonces, ils ne sont pas spécialisé dans le domaine ( tayara .tn , tunisie-annonce.com , affare.tn) , même les sites dites spécialisés corresponds à des agences immobilières qui n'offrent que des annonces entre agence et particuliers (zitouna immobiler.com , sokna.tn) .

C'est dans ce contexte que nous avons décidé d'héberger notre site puisqu'il offre une

panoplie de services importants et manquants dans les autres sites. (service de colocation et la géolocalisation )

2 Choix d'hébergeur

Le choix d'hébergeur était basé sur deux critères : ? Le prix et le payement

Nous avons opté pour un hébergeur tunisien car on ne peut pas choisir un hébergeur étranger malgré les prix attractifs faute de méthodes de payement.

? L'espace disque et la sécurité

Nous avons cherché à sécuriser notre site et cela pour la protection de nos

utilisateurs et nous avons cherché un hébergeur qui nous offre un espace disque illimité

2.1 Hébergeur

Nous avons choisit l'hébergeur OXAHOST [10]

OXAHOST fournit toujours les critères non fonctionnels suivant : la performance, la sécurité et l'efficacité du support technique afin de développer une véritable relation avec

104



Chapitre V : Hébergement et Référencement

leurs clients. Nous associons l'expertise des collaborateurs et les dernières technologies dans un produit unique.

OXAHOST est une société d'hébergement web, d'enregistrement de noms de domaine, de vente de certificats SSL et de solutions Internet. Elle fournit à ses clients la fonction hébergement à l'aide de son infrastructure cloud hybride. Les DNS Anycast et Anti-DDoS de OXAHOST servent tout son réseau. L'équipe expérimentée de professionnels en hébergement web s'engage à offrir un service haut de gamme à ses clients.

Le siège social d' OXAHOST se situe à Ennasr II (ARIANA). OXAHOST assure la gestion entière de ses opérations. Grâce à ses accréditations, OXAHOST est le bureau d'enregistrement immédiat du client. Elle représente celui-ci devant les autorités Internet en cas de litige. Par la suite, OXAHOST sert le client grâce à ses infrastructures de dernières générations dont la gestion se fait entièrement à l'interne. Finalement, le support technique est assuré par les techniciens qualifiés et expérimentés d'OXAHOST. La société peut ainsi offrir un service de qualité du début jusqu'à la fin.[11]

Figure 94:Site www.oxahost.tn

Nous avons payé un service smart qui a coûté 114 ,840 dinars le 04/08/2019

105

Chapitre V : Hébergement et Référencement



Figure 95:Email de confirmation de payement

2.2 Espace d'hébergement

Après le payement, l'hébergeur nous a ouvert un panneau de configuration avec les paramètres de connexion

3 CPanel

cPanel est un panneau de configuration fondé sur Linux conçu pour les hébergeurs web. Constitué d'une interface graphique permettant l'automatisation des paramètres, l'hébergement de site web est ainsi simplifié. cPanel est doté de trois principales fonctions qui permettent d'accéder à différents niveaux d'utilisation tels que l'administration et la revente d'un hébergement, ou la simple configuration de site web. Ainsi, tous ces aspects sont contrôlés à partir d'un simple navigateur web. [12]

106



Chapitre V : Hébergement et Référencement

Figure 96:CPanel

3.1 Gestionnaire de fichiers

C'est la partie de chargement de fichiers .cette section permet de charger les fichiers

du site sauf la base de données.les fichiers serons transférer dans un dossier nommer

public_html

Figure 97:Gestionnaire de fichiers

3.2 La base de données

La base de données est enregistrée dans la section base de données à partir de phpmyadmin

Qui nous a permit d'importer le fichier de la base de données.

107

Chapitre V : Hébergement et Référencement



Figure 98:Base de données

Cpanel offre de multitudes de services que nous allons citer si dessous

· Jetbackup

· Billing &support

· Seo & marketing tools

· Domaines

· Email

· Mesures

· Sécurité

· Logiciels

· Avancé

· Préférences

· Softaculous Apps installer

4 Référencement gratuit(SEO)

Pour augmenter l'audience de notre site nous avons utilisé le service SEO de cPanel la ou on a référencé le site dans

? Google

108



Chapitre V : Hébergement et Référencement

? Yahoo ? Being ? ask

Figure 99:Référencement

4.1 Statistique

cPanel offre aussi un service d'analyse AWstat qui présente un espace très complet d'analyse

109



Chapitre V : Hébergement et Référencement

Figure 100:espace AWAstat

4.2 Réseaux sociaux

Pour un référencement plus efficace nous avons crée des pages dans les réseaux sociaux les plus utilisés en Tunisie.

Figure 101: Footer du site

? facebook ? twitter

? google plus ? linked in ? intagram

Nous avons utilisé des photos et des vidéos pour augmenter la visibilité du site.

110



Chapitre V : Hébergement et Référencement

4.3 Action sociale

Nous avons pensé de faire une action sociale surtout dans la période de la pandémie

de covid-19 et cela par l'insertion d'un message dans la page d'accueil incitant les gent de respecter le confinement sanitaire

Figure 102:Page accueil du site

5 Référencement payant (SEA)

Nous n'avons pas pu pour le moment opter pour le référencement payant et cela suite à l'absence des moyens de payement en devise en Tunisie.

111

Chapitre V : Hébergement et Référencement

Conclusion

L'hébergement et le référencement représente la plus importante étape de la mise en oeuvre d'un site web, c'est la phase de concrétisation du projet puisque le projet va être publié sur la toile et sera visible pas tous .nous avons aussi pris conscience de l'importance de la phase de référencement, c'est une véritable opportunité qui nous a permit de connaitre les étapes d'hébergement et les éventuels problèmes liés.

112

Conclusion et perspectives

Conclusion et perspectives

Notre travail est réalisé dans le cadre du projet de fin d'études pour obtenir le du diplôme de mastère professionnel en commerce électronique à la Faculté des sciences Juridiques Economique et de Gestion de Jendouba

C'est dans ce cadre qu'on a choisit de réaliser un site web de location et colocation des biens immobilier permettant aux propriétaires de mettre en ligne leurs biens immobiliers a la location ou la colocation ou pour un séjour de vacances ainsi que le dépannage gratuit pour une petite période. Il permet aussi aux chercheurs de logement de trouver leurs biens immobiliers adéquats.

Nous avons commencé notre travail par une étude approfondit des sites tunisiens présent sur le net et nous avons fait une comparaison qui nous a mener a détecter des insuffisances qu'un utilisateur peut avoir besoin. Comme le service de colocation entre particuliers et la géo localisation des logements.

Pour élaborer notre rapport nous avons eu recours aux méthodes agiles pour assurer le bon déroulement du projet et choisi la méthode Scrum qui est basée sur l'élaboration des sprints, ainsi que UML comme langage de modélisation, Après la définition des besoins ,nous avons subdivisé notre travail en trois releases ,la première release contient (2 sprints),la deuxième (2sprints) et la troisième (un seul sprint ) et on a bien réaliser une application qui répond aux exigences de départ.

Cependant, notre travail reste évolutif et ouverte à des perspectives que nous allons cité :

Améliorer la qualité graphique du site

Ajouter la notification par sms

Elaborer une application android de notre site (version mobile) Elargir le public cible (mondiale)

113

Conclusion et perspectives

Nous somme très heureux de réaliser ce travail qui a été une véritable opportunité d'améliorer nos connaissances et d'élargir nos expériences en conception et développement des applications web

Nous espérons que notre travail soit à la hauteur de vos attentent et que ce site aie la réussite que nous attendant sur le net et après l'hébergement.

114

Bibliographie

Bibliographie

[1]. tunisieimmob. presentation. 2008. https://www.tunisieimmob.net (accès le 01 25, 2019).

[2]. tunisieimmob. presentation. 2008. https://www.tunisieimmob.net (accès le 01 25, 2019).

[3]. zitounaimmobilier. zitounaimmobilier.com. www.zitounaimmobilier.com (accès le 01 25, 2019).

[4]. Agence-immobiliere-tunisie. Agence-immobiliere-tunisie.net . www.Agence-immobiliere-tunisie.net (accès le 01 26, 2019).

[5]. tayara.tn. tayara. www.tayara.tn (accès le 02 20, 2019).

[6]. gantt.com. 3 03 2020. www.gantt.com (accès le 3 2, 2020).

[7]. https://slideplayer.fr/slide/1301199/. https://slideplayer.fr/slide/1301199/ (accès le 03 10, 2020).

[8]. https://medium.com/@belcaid.mehdi/larchitecture-logicielle-mvc-1a8bbb5cf6dc. 13 05 2018. https://medium.com (accès le 03 10, 2020).

[9]. wikipedia. wikipedia. https://www.wikipedia.com (accès le 8 4, 2020).

[10]. https://www.oxahost.tn. https://www.oxahost.tn. 2020. https://www.oxahost.tn (accès le 3 3, 2020).

[11]. oxahost. https://www.oxahost.tn (accès le 08 14, 2019). [12] .www.Cpanel.com (accès le 12 14, 2019)

115