Projet de Fin dEtudes [308025]

Projet de Fin d’Etudes

En vue de l’obtention du Diplôme National d’Ingénieur en génie Informatique

Elaboré par :

Aouili Nizar 140900

Mbarek Sabrine 160009

Réalisé au sein de

Carthage Technologies and training

Encadré par

Dé[anonimizat]é à élaborer votre rapport ou encore qui vous ont assisté tout au long de votre parcours universitaire.

SUPPRIMEZ LES EXPLICATIONS EN GRIS APRES LECTURE

Table des matières

Dédicaces i

Remerciements ii

Table des matières iii

Liste des figures vi

Liste des tableaux viii

Liste des abréviations ix

Introduction générale 2

Chapitre I. ETUDE PREALABLE 3

I.1 Introduction 3

I.2 Présentation du cadre de stage : 3

I.2.1 Présentation de l’organisme d’accueil : 3

I.2.2 Cadre du sujet 5

I.2.3 Impact du sujet 5

I.3 Etude de l’existant : 5

I.3.1 Présentation d’Amadeus : 5

I.3.1.1 Structure d’Entreprise : 6

I.3.1.2 Segmentation clients : 7

I.3.1.2.1 Fournisseurs de voyages : 7

I.3.1.2.2 Vendeurs de voyages : 7

I.3.1.2.3 Acheteurs de voyages : 7

I.3.1.3 Solutions clients : 7

I.3.1.3.1 Distribution & Contenus : 8

I.3.1.3.2 Ventes & e-commerce : 8

I.3.1.3.3 Business Management : 8

I.3.1.3.4 Services & Consulting : 8

I.3.1.4 Solutions phares : 8

I.3.1.4.1 Amadeus Sales Management Solution : 8

I.3.1.4.2 Solutions Amadeus pour les entreprises : 9

I.3.1.4.3 Amadeus SIYAHA : 9

I.3.2 Présentation de CYBERESA : 10

I.3.2.1 Ses valeurs : 10

I.3.2.2 Ses services : 11

I.4 Etude Comparative 12

I.4.1 Pour quoi ? 12

I.4.2 Qu’est ce Qu‘on mesure et comment : 12

I.4.3 Analyse des données : 12

I.4.4 SWAT Diagramme : 15

I.4.5 Conclusions : 15

I.5 Choix stratégiques : 16

I.5.1 Introduction : 16

I.5.2 Exigence Technique : 16

I.5.2.1 Pourquoi Odoo ? 16

I.5.2.2 Présentation : 16

I.5.2.2.1 Microsoft Dynamics NAV : 16

I.5.2.2.2 Sage 100 Entreprise : 17

I.5.2.2.3 Odoo : 18

I.5.2.3 Comparaison des fonctionnalités : 18

I.5.2.4 Conclusions : 21

I.5.3 Méthodologie de travail : 21

I.5.3.1 Pourquoi Scrum 21

I.5.3.1.1 planification d’un projet par Scrum 22

I.5.3.1.2 L’équipe et rôles 23

I.6 Conclusion 25

Chapitre II. Planification et Architecture 26

II.1 Introduction 26

II.2 Analyse des Besoins 26

II.2.1 Identification des acteurs 26

II.2.2 Les Besoin Fonctionnels 27

II.2.3 Les Besoin Non Fonctionnels : 30

II.3 Planning du traitement des cas d’utilisation 32

II.3.1 Priorités 32

II.3.2 Risque 33

II.4 Prototypage des Interfaces 33

II.5 Le Back log du Produit 37

II.5.1 Planification des sprints : 38

II.6 Conclusion 41

Chapitre III. Release 1 : Gestion des contrats 43

III.1 Introduction 43

III.2 Premier Sprint 43

III.2.1 Spécification fonctionnelle 44

III.2.1.1 Scénario et cas d’utilisation 44

III.2.1.1.1 Description du cas d’utilisation gérer contacts 44

III.2.1.1.2 Description du cas d’utilisation gérer hôtels 46

III.2.2 Conception 48

III.2.2.1 Diagramme de séquence détaillé 48

III.2.2.1.1 Diagramme de séquence détaillé du cas d’utilisation : gérer contacts 48

III.2.2.2 Diagramme des classes de conception : 51

III.2.2.3 Conclusion 52

Chapitre IV. Release 2 : module d’achat 53

IV.1 Introduction 53

IV.2 Premier sprint 53

IV.2.1 Spécifications fonctionnelle 54

IV.2.1.1 Scenario et cas d’utilisation 54

IV.2.1.1.1 Description du Cas d’utilisation gérer hôtels 55

IV.2.1.1.2 Description du Cas d’utilisation gérer packages 57

IV.2.2 Conception 58

IV.2.2.1 Diagramme de séquence détaillé 58

IV.2.2.2 Diagramme d’activité (workflow) 65

IV.2.2.2.1 Diagramme d’activité : ajouter hotel 65

IV.2.2.3 Diagramme de classe 66

IV.3 Réalisation 67

IV.4 Conclusion 71

Chapitre V. Release 3 : gestion des réservations : partie devis 72

V.1 Introduction 72

V.2 Premier sprint 72

V.2.1 Spécification fonctionnelle 73

V.2.1.1 Scenarios et cas d’utilisation 73

V.2.1.1.1 Description du cas d’utilisation gérer devis 73

V.2.2 Conception 75

V.2.2.1 Diagramme de séquence 75

V.2.2.1.1 Diagramme de séquence rechercher réservation 76

V.2.2.1.2 Diagramme de séquence nouvelle devis 77

V.2.2.1.3 Diagramme de séquence supprimer devis 78

V.2.2.2 Diagramme d’activité 78

V.2.2.2.1 Diagramme d’activité rechercher réservation 79

V.2.2.2.2 Diagramme d’activité nouvelle devis 79

V.2.2.3 Diagramme de classe 79

V.3 Réalisation 80

V.4 Conclusion 83

Chapitre VI. La Phase de Clôture 85

VI.1 Introduction 85

VI.2 Environnement de travail 85

VI.2.1 Choix de l’architecture de l’application 85

VI.2.2 Elaboration du diagramme de déploiement 86

VI.2.3 Environnent matériel 86

VI.2.4 Technologie utilisées 87

VI.2.4.1 Python 87

VI.2.4.2 XML 87

VI.2.4.3 CSS 88

VI.2.4.4 Html 88

VI.2.4.5 JavaScript 88

VI.2.4.6 ANGULARJS 88

VI.2.4.7 LESS 88

VI.2.5 Environnement logiciel 88

VI.3 Protocole et format de donnée 89

VI.3.1 Protocole de communication 89

VI.3.2 Forma de donnée communiquée 89

VI.3.3 Conclusion 89

Conclusion générale 90

Bibliographie 91

Annexes 92

Annexe 1 Journal du stage 92

Annexe 2 Titre 97

Annexe 3 Titre 98

Liste des figures

Figure 1 : Logo Carthage Technology & Training 4

Figure 2 Logo d’Amadeus 5

Figure 3 : Logo Amadeus 5

Figure 4 Structure d'Amadeus 5

Figure 5 : Logo CYBERESA 9

Figure 6 : Microsoft Dynamics NAV 16

Figure 7 : Logo Microsoft Dynamics NAV 16

Figure 8 : Logo Odoo 17

Figure 9 : Processus Scrum 21

Figure 10 : diagramme de contexte statique 26

Figure 11 : interface d'accueil du back office 33

Figure 12 : interface de gestion des hotels 33

Figure 13 : interface d'affichage d'un hotel 34

Figure 14 : interface de modification d'un type de chambre 34

Figure 15 : interface de chargement du espace client 35

Figure 16 : interface d'acceuil de l'espce client 35

Figure 17 : interface de recharche les hotels 36

Figure 18 : planification des sprints 38

Figure 19 : diagramme de cas d'utilisation générale de Ziara 39

Figure 20 : description des cas d'utilisation du sprint 1 46

Figure 21 : diagramme de séquence détaillé de cas d'utilisation ajouter contrat 47

Figure 22 : diagramme de séquence détaillé du cas d’utilisation consulter contrat 47

Figure 23 : diagramme de séquence détaillé du cas d'utilisation modifier contrat 48

Figure 24 : diagramme de cas d'utilisation détaillé du cas d'utilisation supprimer contrat 49

Figure 25 : diagramme des classes de sprint 1 50

Figure 26 : description des cas d’utilisation du sprint 1 – release 2 56

Figure 27 : diagramme de séquence ajouter hotel 57

Figure 28 : diagramme de séquence de cas d’utilisation ajouter tarif 58

Figure 29 : digramme de cas d’utilisation modifier hotel 59

Figure 30 : diagramme de séquence du cas d’utilisation supprimer hotel 60

Figure 31 : diagramme de séquence du cas d’utilisation ajouter package 61

Figure 32 : diagramme de séquence modifier package 62

Figure 33 : diagramme de séquence supprimer package 63

Figure 34 : diagramme d’activité ajouter hotel 63

Figure 35 : diagramme de classe sprint 1 – release 2 : module d’achat 64

Figure 36 : interface d’accueil gérer hôtels 66

Figure 37 : interface d’ajout d’un hotel (section donnée générale) 66

Figure 38 : interface d’ajout d’un hotel (section localisation) 67

Figure 39 : interface d’ajout d’un tarif 67

Figure 40 : interface d’ajout d’un type de chambre 68

Figure 41 : interface de gestion des types des chambres 68

Figure 42 : diagramme de cas d’utilisation du sprint 1 release 3 73

Figure 43 : diagramme de séquence rechercher réservation 74

Figure 44 : diagramme de cas d’utilisation de sous cas d’utilisation nouvelle devis 75

Figure 45 : diagramme de séquence de sous cas d’utilisation supprimer devis 76

Figure 46 : diagramme d’activité rechercher réservation 77

Figure 47 : diagramme d’activité du cas d’utilisation nouvelle devis 77

Figure 48 : diagramme de classe du sprint 1 release 3 78

Figure 49 : écran d’accueil du système 79

Figure 50 : résultat de la recherche d’une réservation 79

Figure 51 : interface de sélection des devis 80

Figure 52 : interface recherche d’une réservation 80

Figure 53 : liste des devis pour un hotel 81

Figure 54 : interface de la création d’un devis 81

Figure 55 : diagramme de déploiement de ZIARA 84

Liste des tableaux

Tableau 1 : Cyberesa vs Ziara (Ventes) 11

Tableau 2 : Cyberesa vs Ziara (CRM) 12

Tableau 3 : Cyberesa vs Ziara (Achats) 12

Tableau 4 : Cyberesa vs Ziara (Services & Projets) 13

Tableau 5 : Cyberesa vs Ziara (Ressources humaines) 13

Tableau 6 : Benchmarking fonctionnel (Ventes) 17

Tableau 7 : Benchmarking fonctionnel (CRM) 18

Tableau 8 : Benchmarking fonctionnel (Achats) 18

Tableau 9 : Benchmarking fonctionnel (Services & Projets) 19

Tableau 10 : Benchmarking fonctionnel (Ressources Humaines) 19

Tableau 11 : Evaluations 20

Tableau 12 : cas d'utilisation et priorités 31

Tableau 13 : back log du produit 37

Tableau 14 : back log du premier sprint ( relese 1 ) 41

Tableau 15 : description de sous cas d'utilisation : consulter contrat 42

Tableau 16 : description du sous cas d'utilisation : ajouter contrat 43

Tableau 17 : description de sous cas d'utilisation : modifier contrat 43

Tableau 18 : description de sous cas d'utilisation : supprimer contrat 44

Tableau 19 : description de sous cas d'utilisation : consulter hotel 44

Tableau 20 : description de sous cas d'utilisation : ajouter hotel 44

Tableau 21 : description de sous cas d'utilisation : modifier hotel 45

Tableau 23 : back log du sprint 1 release 2 51

Tableau 24 : description de sous cas d’utilisation ajouter hotel 53

Tableau 25 : description de sous cas d’utilisation modifier hotel 53

Tableau 26 : description de cas d’utilisation ajouter tarif 54

Tableau 27 : description de cas d’utilisation supprimer hotel 54

Tableau 28 : description de sous cas d’utilisation consulter package 55

Tableau 29 : description de sous cas d’utilisation ajouter package 55

Tableau 30 : back log du sprint 1 release 3 70

Tableau 31 : description de sous cas d’utilisation nouvelle devis 71

Tableau 32 : description de sous cas d’utilisation rechercher réservation 72

Tableau 33 : description de cas d’utilisation lister devis 72

Tableau 34 : description de cas d’utilisation supprimer devis 73

Liste des abréviations

Si vous venez d’utiliser dans votre rapport des abréviations du style ERP, UML, XML, etc, vous pouvez les mettre associés à l’expression complète, comme par exemples.

ERP Enterprise Resource Planning

UML Unified Modeling Language

XML eXtensible Markup Language

Si, par contre, vous n’avez pas utilisé ce genre d’abréviations, vous pouvez éliminer cette section de votre rapport.

SUPPRIMEZ LES EXPLICATIONS EN GRIS APRES LECTURE

Introduction générale

Dans nos jours, n’en a aucun doute que l’informatique présente la révolution la plus innovante qui a améliorée la vie de l’humanité en ce siècle passé. En effet, loin d’être un éphémère phénoménale mode, l’informatique viens nous apporter plusieurs conforts a notre style de vie .tous les domaines n’est resté étranger a la stratégie qui offre tant de service aussi bien pour l’entreprise que pour les hommes.

Cependant, il est tes évident d’essayer d’utiliser cette technologie dans tout domaine de marché, comme le tourisme qui présente l’un tiers de revenue du marché tunisien, et ainsi i ‘émergence du terme l’e-tourisme, ce dernier présente la nouvelle technologie qui cers comme objectif finale d’améliorer la rentabilité de tout business dans le domaine de tourisme.

Donc vue à ces circonstance en a décidé de lancer une start-up, une société qui s’appelle Carthage training and technologies qui serait responsable a l’invention de notre nouvelle logiciel : ZIARA pour viser l’excellence dans le domaine de l’e-tourisme.

L’objet d’étude de ce projet vise à développer un ERP. Ce travail vient dans le cadre d’un stage de fin d’étude .Il est realisé au sein de nore strart-up « CTT », en utilisant la méthodologie SCRUM, ce rapport est organisé comme suit :

Un chapitre d’etude prealable pour la presentation de l’entreprise et l’etude de marché

Un chapitre de specification de besoin pour deffinir le cadre fonctionnel de notre projet

Les iteration des release

Une phase de cloture pour spécifier la technologie utilisée et l’environnement de travail

Enfin on termine par une conclusion générale présentant la synthèse du projet et les perspectives futures pour améliorer notre application.

Et ainsi en commence …

ETUDE PREALABLE

________________________________________________________

Ce premier chapitre est consacré à une étude préalable contenant une présentation générale du cadre du stage dans laquelle nous allons présenter l’organisme d’accueil, notre Startup Carthage Technology & Training, le cadre du stage et l’impact de notre solution sur la réalisation de notre Startup. Ensuite, nous allons procéder à une étudie du marché en présentant les sociétés existantes à savoir Amadoues et CYBERESA. En se basant sur cette étude nous allons réaliser le Benchmarking où nous allons comparer la solution CYBERESA avec notre solution « ZIARA » et un SWAT pour traiter les forces ainsi que les faiblesses de la solution « ZIARA ». Enfin, une partie qui traitera les exigences techniques et la méthodologie adoptée pour la réalisation de ce projet.

Présentation du cadre de stage :

Présentation de l’organisme d’accueil :

Dans le cadre de projet de fin d’étude nous allons créer une Startup spécialisé aux développements des solutions au secteur du tourisme. Nous allons définir toute la structure et les stratégies au moyen et long terme de Carthage Technology & Training(CTT).

Présentation de Carthage Technology & Training :

Carthage technologies and training est une start-up lancé en 2014 qui a pour but de faire l’Edition des logiciels informatiques, CTT appartient au groupe Carthage travel and events du Mr mohammed saadaoui,

Nom de la société : Carthage travel and technologies

Adresse :tour bleux av de koweit etg 4 hammamet

Format juridique : SARL

Année de création : 2014

Code postale : 8050

Téléphone : 72263695

Gérant : Mr Saadaoui Mohammed

Responsable produit : Mr fejji khallil

Equipe : Aouili Nizar, Mbarek Sabrine, Bedhiafi anis, Sghaier Mohammed

Figure 1 : Logo Carthage Technology & Training

Cadre du sujet

Le tourisme électronique ou bien le "e-tourisme" englobe toutes les activités liées au tourisme via internet. Du côté de l'utilisateur, l'e-tourisme offre le moyen de collecter non seulement des informations sur une destination de voyage, mais aussi d’organiser et de réserver un séjour en ligne. Le e tourisme permet également aux internautes d’élaborer un itinéraire ainsi que les échanges avec d'autres internautes à propos d'un hôtel. Aujourd’hui, l’e-tourisme se manifeste comme un mode de réservation et de promotion nécessaire dans le secteur du tourisme.

Etude de l’existant :

L’étude de l’existant nous aider de faire une analyse générale de marches et de mieux connaitre nos concurrents et leurs produits pour améliorer notre solution.

Présentation d’Amadeus :

Amadeus est une société internationale spécialisée dans les systèmes informatisés de distribution et de réservation de produits autour du voyage (avion, train, croisière, hôtel, location de voiture, assurance…).

Les solutions et les services d’Amadeus sont utilisés par ses clients de diverses façons. Près de 84 000 agences de voyages et plus de 27 170 bureaux de vente de compagnies aériennes ont accès au Système Amadeus. De nombreux autres acteurs majeurs de l’industrie du voyage adoptent également la technologie modulaire Amadeus pour optimiser leur distribution ainsi que la gestion de leurs besoins internes

Structure d’Entreprise :

Figure 4 Structure d'Amadeus

Segmentation clients :

Amadeus fournit une offre exhaustive à l’industrie du tourisme et du voyage. Cette offre allie la technologie dans la distribution, l’informatique, les solutions point de vente et plus encore. Elle permet aux clients d’Amadeus de bénéficier de sa technologie pour assurer leur succès.

Fournisseurs de voyages :

Les compagnies aériennes – compagnies aériennes en réseau, régionales et les transporteurs low-cost/loisirs

Les hôtels – chaînes hôtelières, sociétés de représentation et hôtels indépendants

Les compagnies terrestres et maritimes– sociétés de location de voitures, compagnies ferroviaires, de ferry, de croisière et d’assurance

Les tour-opérateurs – spécialisés, grand public et intégrés verticalement

Vendeurs de voyages :

Les agences de voyage – dont des TMC (travel managements companies), des agences de voyages d’affaires et loisirs, des agences de voyages en ligne et des consolidateurs

Acheteurs de voyages :

Les entreprises – solutions de self-booking pour les entreprises qui veulent mieux maîtriser leurs dépenses « voyages »

Les voyageurs – grâce à des entreprises d’Amadeus telles qu’Opodo

Solutions clients :

Amadeus est le partenaire technologique leader des fournisseurs, vendeurs et acheteurs de l’industrie du voyage et du tourisme.

Ses divers produits et services sont répartis en 4 familles distinctes de solutions :

Distribution & Contenus :

Ces solutions permettent l’agrégation et la distribution de contenu complet et les moyens d’optimiser la distribution grâce à un large réseau de points de vente .

Ventes & e-commerce :

Offrant la capacité d’accéder, de commercialiser et de vendre le contenu à travers tous les canaux, ces solutions permettent également d’améliorer le flux d’activité, la profitabilité et le service client à travers l’intégralité du processus de ventes.

Business Management :

Grâce à ces solutions, Amadeus optimise les opérations de ses clients, leurs processus commerciaux et leur gestion et renforce leurs relations clients.

Services & Consulting :

Les clients peuvent exercer un effet de levier sur leurs processus commerciaux et leurs investissements technologiques par le biais des solutions Services & Consulting d’Amadeus. Amadeus offre plusieurs centaines de produits et services et son portefeuille évolue sans cesse afin d’aider ses clients à améliorer leur business.

Solutions phares :

Amadeus Sales Management Solution :

Une solution de point de vente intégrée qui combine toutes les fonctions d’un front et mid-office. Cette solution vise à augmenter la productivité, à améliorer le service client et à redynamiser les revenus.

Cela inclut :

Amadeus Selling Platform – la première plate-forme de navigation de vente créée pour les professionnels du voyage.

Amadeus Agency Manager – l’application de gestion de voyage (mid et back office) la plus largement déployée.

Solutions Amadeus pour les entreprises :

Ces solutions en ligne totalement personnalisées répondent aux besoins des entreprises internationales en termes de voyages d’affaires

Amadeus e-Travel Management – Cette solution de réservation en ligne a été conçue pour aider les entreprises à gérer plus efficacement leur politique de voyage. Elle donne aux voyageurs d’affaires la capacité de planifier, réserver et acheter des itinéraires conformes aux directives de l’entreprise.

SAP Travel Management avec Amadeus – Cette solution de gestion des voyages d’affaires unique au monde est intégrée à SAP. Elle combine la politique voyages avec les systèmes comptables et financiers et la gestion de la paie et des ressources humaines.

Amadeus SIYAHA :

Amadeus Tunisia Hotels « SIYAHA » est une plateforme de réservation hôtelière en Tunisie fiable et sécurisée pour une réservation rapide et facile.

Cela inclut :

Module B2B – Ce module est affiché chez l’agence de voyages sous deux Onglets :

Amadeus Selling Plateforme.

Page web : www.siyaha.biz

Module B2B2C : www.siyaha.tn

Une page web qui Facilite aux internautes la consultation des offres affichés sur notre plateforme et lui permet de concrétiser une réservation par l’intermédiaire de son agence de voyage.

Module Marque Blanche: moteur de recherche qui permet aux agences de voyages d’intégrer la plateforme SIYAHA directement sur leur site web.

Présentation de CYBERESA :

Figure 5 : Logo CYBERESA

CYBERESA appartient au groupe 3S Global Net. C’est une société anonyme au capital de 3.000.000 DT .

Son activité est entièrement dédiée au développement des solutions utilisant les technologies de l'Internet dans le secteur du tourisme .

CYBERESA, spécialiste en solutions e-tourisme, met à la disposition de tous les professionnels du tourisme une plate-forme de réservation qui leur permet de proposer sur leurs sites Web la réservation en ligne en temps réel pour le grand public (individuels) et les professionnels (TO, agences de voyages, entreprises…) avec paiement sécurisé par cartes de crédits bancaires (Visa, Mastercard, CIB) nationales (marché local) et internationales (étrangers).

L'expertise de son management dans les métiers du tourisme et de la distribution sur Internet lui permet d'assurer le déploiement de solutions sur mesure et de proposer un suivi de la maîtrise par le client de la technologie que nous mettons à sa disposition .

Sa démarche consiste à travailler avec les équipes de nos clients en nous fixant des objectifs à la fois technologiques et économiques.

Ses valeurs :

CYBERESA assure trois valeurs pour garantir sa réussite :

En choisissant la réactivité

Une connaissance du tourisme indiscutable : CYBERESA se positionne comme la première solution e-tourisme professionnelle. C’est la solide alliance de compétences « métiers » et de garanties « technologiques » afin de gagner du temps.

En privilégiant la qualité

Une méthodologie éprouvée : CYBERESA a fait le choix d’exploiter les toutes dernières technologies en s’appuyant sur une démarche stricte de gestion de projet. Fini les retards, les bugs récurrents, les pannes inexpliquées, les cahiers de charges incohérents et incomplets,  CYBERESA  appuie ses développements sur des outils puissants et des méthodes éprouvées par les plus grandes réussites du web.

Pour garantir la rentabilité

Le fruit de l’expertise : CYBERESA active tous les leviers de la réussite pour amener les produits sur le net. Acquisition de trafic qualifié, ergonomie des solutions, formation des équipes, intégration à toutes les composantes de l’entreprise…sont les réponses à partager avec les clients.

Ses services :

En tant que guide de Tourisme, CYBERSESA offre la possibilité aux internautes de trouver des centaines de milliers de produits et services en vente sur Internet chez les meilleurs fournisseurs référencés, de comparer les prix et les services, d'accéder directement aux meilleures offres… L'offre CYBERSESA proposée aux internautes couvre plusieurs types de produits tels les produits touristiques, les produits culturels, les voyages, et aussi l'auto …

En tant que fournisseur, référencer les offres sur Cyberesa.info, c'est la possibilité de doper divers ventes ! Il est possible ainsi de toucher un maximum de clients potentiels qui viennent tous les jours sur CYBERESA.info pour trouver un produit ou comparer les prix.

Etude Comparative

Pour quoi ?

Cette analyse comparative est nécessaire pour aider à inventer un nouveau produit qui peut rivaliser avec la solution existante sur le marché, donc nous allons utiliser le Benchmarking pour faire une comparaison de notre solution ZIARA et la solution du CYBERSESA.

Qu’est ce Qu‘on mesure et comment :

Dans cette analyse comparative, nous allons pour mesurer différents aspects du produit et de le comparer avec un leader du marché tunisien dans le domaine de l’e-tourisme, comprendre l’aspect, les fonctionnalités techniques, le coût du produit, les ressources humaines nécessaires pour gérer, puis service de vente, après-vente service, le service marketing, les données externe figurent déjà dans le site officiel et le produit déjà existent dans la société pour l’utiliser dans la comparaison.

Analyse des données :

D’après Les données collectées précédentes, que nous pouvons voir que les deux produits ont des lacunes, mais en général Cyberesa ont prouvé son efficacité sur le marché par l’intermédiaire de haute performance, un temps de réponse très court et une capacité de loyer très bon même si son prix semble être un peu plus évalué mais c’est tout à fait normal car il utilise des technologies qui ont coûtent si cher au cours du processus de développement.

Tableau 1 : Cyberesa vs Ziara (Ventes)

Tableau 2 : Cyberesa vs Ziara (CRM)

Tableau 3 : Cyberesa vs Ziara (Achats)

Tableau 4 : Cyberesa vs Ziara (Services & Projets)

Tableau 5 : Cyberesa vs Ziara (Ressources humaines)

SWAT Diagramme :

Conclusions :

Pour résumé on dit que parmi les point de force de ce produit c’est qu’il est facilement extensible à tout moment en plus il supporte complétement les technologie du temps réelle , le faite qu’il utilise des langue open source il luis donne une possibilité du maintenance très facile selon la situation grâce à une large communauté qui ajoute à chaque jours de nouvelle contenue , son architecture modulaire nous permet de fait un développement très claire est amélioré le temps nécessaire pour développer cet application.

L’opportunité de ce projet figure très bien dans le nombre des clients dans le marché et au même temps le ratio d’amélioration du marché (presque 10 client par année d’après la fédération tunisienne des agences de voyages FTAV) mais au même temps malgré que la compétition est très faible dans ce domaine(e-tourisme) les concurrents ont de trop fort réputation et presque domine le marché et voilà la plus grande menace de ce projet.

Choix stratégiques :

Introduction :

Ensemble des choix à moyen et long terme que fait l'entreprise au vu de l'appréciation de son environnement et du potentiel qu'il présente. Ces choix ou décisions stratégiques portent sur la nature et l'ampleur des moyens qu'elle envisage d'utiliser pour mener une action coordonnée sur le marché. Une stratégie se présente d'abord comme le choix des moyens les plus appropriés pour atteindre un objectif fixé.

Pour cette raison nous allons faire des études sur les exigences techniques ainsi que le choix de méthodologie de travail.

Exigence Technique :

Pourquoi Odoo ?

Depuis une quinzaine d’années, les nouvelles technologies ont poussées les petites et les grandes entreprises à repenser leurs processus de gestion tout en respectant les nouvelles dynamiques créées suite à ces changements. Implémenter un ERP est un pas que beaucoup d’entreprises franchissent pour mieux s’organiser et optimiser leur manière de travailler.

Le but de cette comparaison est de nous donner une idée des fonctionnalités offertes par les principales solutions ERP.

Présentation :

Avec plusieurs solutions ERP disponibles sur le marché aujourd'hui, choisir le bon doit tenir compte de nombreux facteurs et pour cela nous allons focaliser sur les principales solutions ERP.

Microsoft Dynamics NAV :

Figure 6 : Microsoft Dynamics NAV

Microsoft Dynamics NAV est un progiciel de gestion intégré, composant de Microsoft Dynamics, conçu pour les PME-PMI internationales et les filiales de grands groupes. Il permet de gérer l’ensemble des processus de l’entreprise : commerce & marketing, achats, production, logistique et distribution, gestion de projets, services client, gestion financière. Il y a aujourd'hui plus de cent mille installations de Microsoft Dynamics NAV et plus d'un million d'utilisateurs dans le monde.

Sage 100 Entreprise :

Figure 7 : Logo Microsoft Dynamics NAV

Sage se positionne sur le marché des ERP pour PME avec sa solution Sage 100 Entreprise i7. Cette solution est disponible en ligne (avec un coût supplémentaire) ou localement.  Il y a aujourd'hui plus de cent mille entreprises clientes  de Sage 100 Entreprise i7 et trois mille cinq cent partenaires revendeurs

Odoo :

Figure 8 : Logo Odoo

Odoo, anciennement OpenERP et Tiny ERP, est initialement une progicielle open source de gestion intégré comprenant de très nombreux modules permettant de simplifier la gestion d’entreprise .

Le logiciel est utilisé par plus de deux millions d’utilisateurs pour gérer leurs entreprises à travers le monde, plus de cinq mille quatre cent développeurs et trois cent douze nouvelles applications par mois. Odoo est le système ERP open-source le plus populaire.

Comparaison des fonctionnalités :

Afin de comparer les logiciels à leur plus juste valeur, nous avons choisi de créer un tableau avec les fonctionnalités les plus importantes, classées en six catégories: les ventes, la gestion de clients, la gestion des achats, la gestion de projets et de services, les ressources humaines et l’évaluation.

Tableau 6 : Benchmarking fonctionnel (Ventes)

Tableau 7 : Benchmarking fonctionnel (CRM)

Tableau 8 : Benchmarking fonctionnel (Achats)

Tableau 9 : Benchmarking fonctionnel (Services & Projets)

Tableau 10 : Benchmarking fonctionnel (Ressources Humaines)

Tableau 11 : Evaluations

Conclusions :

Le bon choix de l’ERP est une étape cruciale pour notre Startup et d’après les résultats des tableaux comparatifs (ventes, gestion de clients, gestion des achats, gestion de projets et de services, ressources humaines et l’évaluation) sur Microsoft Dynamics NAV, Sage 100 Entreprises i7 et Odoo.

Ce dernier a un avantage par rapport aux autre c’est pour cela nous avons convergé vers Odoo.

Méthodologie de travail :

Le choix de la méthode de travail est une étape fatidique pour le déroulement du projet, pour ca nous avons choisir la méthode agile qui est un garant pour converger vers les attente du client.

Cette méthode facilite l’expression des besoins et aide à l’acceptation du changement, elle est une approche itérative, qui est conduite dans un esprit collaboratif elle peut intégrer le client. Elle génère un produit de haute qualité tout en prenant en compte l'évolution des besoins des clients, pour monte en surface les besoins non prévisibles de notre projet nous avons choisi la méthode Scrum.

Pourquoi Scrum

Figure 9 : Processus Scrum

planification d’un projet par Scrum

Planification du sprint : il s’agit d’une réunion chaque début de sprint elle a comme objectif de réussir le sprint toute en respectant les 6 étapes suivantes :

Définir le but du sprint

Définition du périmètre du sprint

Identification les tâches à partir des éléments sélectionnés

Estimation des tâches

Attribution des tâches

Obtenir l'engagement de l'équipe

Revue du sprint : une revue permet un feedback concret sur le produit du développement effectué au cours du sprint, et pour la réaliser il faut garantir les 6 étapes suivantes :

Préparer la démonstration

Rappeler les objectifs du sprint

Effectuer la démonstration

Evaluer les résultats du sprint

Calculer la vélocité réelle

Rétrospective : cette réunion se faite en interne avec le Scrum Master, elle a comme objectif est d'améliorer le processus du prochain sprint, et pour la réaliser il faut suivre les 5 étapes suivantes :

Créer un environnement propice à l'expression

Collecter les informations relatives au processus

Consolider

Définir les priorités

Planifier des actions d'amélioration

Le Scrum quotidien : il s’agit d’une réunion de quelque minutes avec de l’équipe développement au cours de laquelle l’équipe doit parler principalement sur 4 axes :

Présenter qu'est ce qu'on a fait.

Prévoir qu'est ce qu'on va faire.

identifier les obstacles.

Statuer sur l'atteinte.

L’équipe et rôles

Scrum est un Framework de gestion de projet . Ce cadre est constituée dans le but d’optimiser la flexibilité et la productivité; elle s’organise elle-même et doit avoir toutes les compétences nécessaires au développement du produit. Pour cela, cette méthodologie définit trois rôles qui sont le Product Owner, le Scrum et l’équipe du développement

Le Product Owner qui porte la vision du produit à réaliser et travaille en interaction avec l’équipe de développement. Il s’agit généralement d’un expert du domaine métier du projet . Il doit assurer :

Définit les spécifications fonctionnelles

Etablit la priorité à développer ou corriger

Valide les fonctionnalités développées

Joue le rôle du client

Dans le cadre de notre projet, Mr. Nizar Aouili sera le Product Owner de notre projet.

Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de développement. Il doit donc faire preuve de pédagogie. Il est également chargé de s’assurer que l’équipe de développement est pleinement productive. Généralement le candidat tout trouvé au rôle de Scrum Master est le chef de projet. Celui-ci devra cependant renoncer au style de management « commander et contrôler » pour adopter un mode de management participatif. Il doit assurer :

S’assure que les principes et les valeurs de Scrum sont respectés

Facilite la communication au sein de l’équipe

Cherche à améliorer la productivité et le savoir-faire de son équipe

Dans le cadre de notre projet, Mr. Yassine Hassan sera le Scrum Master de notre projet.

L’Equipe de Développement qui est chargée de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et peut donc encapsuler d’autres rôles tels que développeur, architecte logiciel, DBA, analyste fonctionnel, graphiste/ergonome, ingénieur système. [1]

Dans le contexte de notre projet, Mr. Nizar Aouili sera à la fois le Product Owner et un membre de l’équipe du développement de produit et nous formons Mohamed Sghaier, Sabrine Mbarek et Anis Bedhiafi les membres de l’équipe Scrum.

Conclusion

Ce chapitre nous a permis de présente le cadre général de noter projet et de dégager les limites des solutions déployées actuellement. Ce que nous aidée de prépare nos choix stratégiques de notre Startup qui seront modélises dans le chapitre suivait.

Planification et Architecture

________________________________________________________

Introduction

Dans cette période les travaux du Product owner avec le Scrum master fait conduit à construire une bonne identification des diffèrent aspect du produit, identifier les utilisateurs et ses rôles, et dégager les principale fonctionnalités afin de construire un back log initial ainsi qu’une première organisation et planification des sprints de notre produit ZIARA.

Analyse des Besoins

Pendant la partie d’initialisation, l’analyse de besoins représente une phase critique pour faciliter la compréhension de notre produit ZIARA ainsi nous démontrons les différents besoins fonctionnels et les besoins non fonctionnels identifiés après la spécification des besoins.

Identification des acteurs

Un acteur est l’idéalisation d’un rôle joué par une personne externe, un processus ou une chose qui interagit avec un système. Dans le cas de notre projet nous présentons les acteurs suivants :

Le client : c’est l’utilisateur qui va accéder a l’interface client de projet et fait la recherche, la réservation des différente produits (hôtels, packages) à distance.

L’agent de vente : c’est l’utilisateur de qui va accéder à l’interface « back-end » pour faire une réservation dans le cas où le client veut faire une réservation directe dans le point de vente (agence) ou par appel téléphonique.

L’administrateur Système : c’est l’utilisateur qui va faire la gestion des utilisateurs, la gestion des droit d’accès, le base de donnée, la maintenance de système, la gestion du site web et tous les tâche qui a une relation avec la stabilité du système.

L’agent de saisie : c’est l’utilisateur qui est responsable a la gestion de la liste des produits, les maintenir à jour, la gestion des tarifs, tout simplement la gestion des achats de l’entreprise (gestion du stock).

Diagramme de contexte statique

Ce diagramme d’UML Permet simplement de montrer la relation des différentes acteurs avec le système. Il spécifie le nombre d’instances de chaque acteur relié au système à moment donné :

Figure 10 : diagramme de contexte statique

Les Besoin Fonctionnels

Au cours de cette étape, nous allons extraire les différente fonctionnalités que notre projet va les offrir :

L’application permet au client de :

S’authentifier :

Se connecter à travers un login et un mot de passe à son espace personnel.

Consulter Liste des Hôtels :

Consulter la liste des hotel ou bien recherche des hotel selon des filtres différents.

Consulter historique des réservations et les hôtels favoris :

Consulter la liste des anciennes réservations effectuées et la liste des produits favoris.

L’application permet à l’agent de vente de :

Consulter liste des hôtels :

Avoir une liste des produits dont en peut chercher, voir les diffèrent hôtels dans la base de données.

Gérer devis pour :

Consulter, extraire, supprimer des devis de réservation pour les clients.

Réserver chambre :

Rechercher et réserver une ou plusieurs chambres pour un client.

Facturer réservation :

Apres la génération du facture facturer cette réservation ver un payement électronique ou cash.

Gérer factures :

Consulter la liste des factures enregistrées dans le système.

Consulter statistique :

Consulter une liste des différentes statistiques et rapports des ventes (charte graphique, diagrammes, etc.).

L’application permet au agent de saisie de :

Gérer les hôtels :

Consulter, modifier, mettre à jour et supprimer les différents hôtels dans le système.

Gérer les packages :

Consulter, modifier, mettre à jour ou supprimer les différentes package dans le système.

Gérer les types des chambres :

Consulter, modifier, mettre à jour ou supprimer les différents types des chambres dans le système.

Gérer les suppléments :

Consulter, modifier, mettre à jour ou supprimer les différents suppléments dans le système.

Gérer les réductions :

Consulter, modifier, mettre à jour ou supprimer les différentes réductions dans le système.

Gérer les options :

Consulter, modifier, mettre à jour ou supprimer les différentes options dans le système.

Gérer les thèmes :

Consulter, modifier, mettre à jour ou supprimer les différents thèmes dans le système.

Gérer les paramètres supplémentaires :

Consulter, modifier, mettre à jour ou supprimer les différents paramètres supplémentaires tel que les pays, les régions les villes dans le système.

L’application permet à l’administration de système de :

Gérer les utilisateurs :

Gérer les liste des utilisateurs tels que la suppression (désactivation des comptes), ajout, etc.

Gérer les droits d’accès :

Controller les accès des utilisateurs avec la possibilité de modification tous moment via une interface ACL.

Gérer le site web :

Gérer le contenue de l’interface client.

Mettre à jour l’interface du client.

Consulter nombre de vue du site web.

Consulter la liste analytique des visiteurs du site (via Google analytiques).

Gérer le système de mailing :

Consulter liste des emails enregistrés dans le système.

Gérer liste des contacts.

Envoyer des compagnes de mailing (mailing intensive).

Envoyer des campagnes des SMS.

Editer, ajouter, supprimer des Template des emails et des SMS.

Gérer la sécurité :

Gérer les certificats de serveurs, les protocoles, les abonnements (nom de domaine).

Maintenir et participer à la mise à jour le système.

Les Besoin Non Fonctionnels :

Ces dernier présente des lois à suivre, juste avant le développement pour être sur de la bonne manipulation et utilisation de logiciel

L’ergonomie : représente la facilité de la manipulation de l’interface par l’agent. En doit avoir un passage fluide entre les interfaces avec la présence des alertes et des notifications pour aider l’utilisateur.

La Fiabilité : l’application doit respecter la persistance et la qualité des données et des informations et aussi la vitesse durant les interfaces se charge, aussi l’application doit être responsive pour s’adapter au appareil mobile.

L’Efficacité : le logiciel doit avoir la qualité d’accompli cément des taches ave le minimum des clicks. ce dernier doit être garanti pour que notre logiciel puisse s’intégrer avec plus de facilité dans le marché.

La Sécurité : l’utilisateur ont des compte qui peut être sécurisé et vérifier pour éviter les fausse compte.

Intégration de l’api Amadeus XML pour les réservations internationales des billets d’avions.

Bon vouchers : messages automatiques : envoi quotidien des bons vouchers des réservations effectués dans la journée pour consolider la notification envoyée au moment de la confirmation et éviter que l’hôtel ne déclare n’avoir pas reçu l’email de confirmation.

Intégration dans le site Web du module « Amadeus E-Power » : Vol

Intégration du « Kit de paiement sécurisé SPS » :

Visa / Mastercard / CIB : cartes bancaires Tunisiennes (marché local).

Visa / Mastercard : cartes bancaires Internationales (étrangers).

Crédit immédiat de votre compte bancaire au moment de la réservation (aucun intermédiaire).

Tarification en 20 devises.

possibilité de gérer facilement une galerie photos.

une galerie Visites virtuelles en 360°.

Planning et traitement des histoires utilisateur

Suite à l’identification des cas d’utilisation, il est indispensable de les classifier pendant cette opération, on doit tenir compte de la priorité des cas, cette méthode est appliqué généralement pendant la conception des logiciels suivent l’approche des processus unifier .mais cela reste intéressant pour notre cas.

Priorités

Pour résumer les niveaux de priorités de quelque cas d’utilisation dans notre système nous avons élaboré le tableau ci-dessous :

Tableau 12 : cas d'utilisation et priorités

Risque

Pendant un projet, il est très important d’identifier le risque pour la réussite de cette étape. Pour notre application, le risque qui est le plus critique c’est la difficulté d’implémentation de quelque taches, aussi l’un des risque les plus important c’est la relation entre le module de payement électronique et la gestion des tarifs car ici présente les choses critique pour l’entreprise.

Prototypage des Interfaces

Ci-dessous on présente le prototype de l’interface :

Figure 11 : interface d'accueil du back office

Figure 12 : interface de gestion des hotels

Figure 13 : interface d'affichage d'un hotel

Figure 14 : interface de modification d'un type de chambre

Figure 15 : interface de chargement du espace client

Figure 16 : interface d'acceuil de l'espce client

Figure 17 : interface de recherche les hôtels

Le Back log du Produit

Ce dernier est l’élément qui a la plus grande valeur du Scrum .c’est l’ensemble des caractéristiques qui définit le produit souhaiter. Ces caractéristique sont appelé : histoire utilisateur ou bien des histoires technique, Le tableau ci-dessous résume le back log de notre logiciel.

Le tableau suivant présent chaque histoire utilisateur est caractérisée par sa priorité expliquée dans la section 2 de ce même chapitre. Pour le traitement de nos « histoires utilisateur » nous faisons le choix des taches les plus importantes pour commencer avec.

Tableau 13 : back log du produit

Planification des sprints :

La planification des sprints est ainsi schématisée dans le graphique suivant :

Figure 18 : planification des sprints

Figure 19 : diagramme de cas d'utilisation générale de Ziara

Conclusion

Dans ce chapitre , on a consacré tout le temps à la préparation du plan de travail tout en spécifiant les besoins fonctionnels et les rôles des utilisateurs avant de passer à l’architecture logique et le plans des release de projet , Une description détaillé du premier release a été réserver au chapitre suivant.

Release 1 : Gestion des contrats

________________________________________________________

Introduction

On définit un release comme une version d’une application ou une période de temps qui permet de la produire. De toute façon, un release est constitué d’une suite d’itération (sprint) qui se termine quand les incréments de ces derniers construisent un produit qui peut répondre au besoin de l’utilisateur final.

Dans ce chapitre, nous allons traiter les histoires utilisateurs des sprints de notre release pour construire un incrément potentiellement livrable

Premier Sprint

Le sprint est considérer parmi les composants les plus importants de SCRUM. En parle d’un bloc de temps durant lequel un incrément du projet sera réalisé. Les sprints d’une seul release ont une durée constante et ne se chevauchent jamais, on peut dire qu’un sprint ne peut pas commencer tant que le sprint avant n’est pas terminer.

Avant de commencer un sprint, l’équipe SCRUM doit obligatoirement mettre en claire le but de ce dernier. Il s’agit de répondre à la question basique : pourquoi en va faire ce sprint ? Suite à une étude sur le projet, nous avons décidé que le but est le suivant : faire les fonctionnalités de la gestion des contrats de l’agence avec les hôtels.

Avec ce but du sprint actuel, maintenant en décide quelle est les fonctionnalités et leurs degrés d’importance incluent dans ce dernier. Plus précisément , parmi les noms qui figurent dans notre back log de produit, lesquelles sont inclus dans le back log du sprint. Ce qui résume donc le tableau ci-dessous, le back log de notre premier sprint :

Tableau 14 : back log du premier sprint ( relese 1 )

Spécification fonctionnelle

La spécification fonctionnelle se traduit par le diagramme de cas d’utilisation d’UML et la description textuelle de ces derniers.

Scénario et cas d’utilisation

Apres notre back log, on peut l’expliciter sous forme de tableaux :

Chaque tableau présente la description du fonctionnement des cas d’utilisation.

Dans ce sprint nous allons s’intéresser sur les 2 cas d’utilisations suivantes :

Scrum nous permet de ne pas figurer quelque cas d’utilisation dans le back log du sprint, comme l’inscription et l’authentification et tous les autres fonctionnalisées de sécurité sont déjà gérer par ODOO, les en ignore pour le moment. Donc s’en intéresse aux diagrammes les plus importants du projet. Près, nous illustrons le diagramme de cas d’utilisation raffiné pour ce premier sprint.

Description du cas d’utilisation gérer contacts

Description textuelle du cas d’utilisation : consulter contrat

Tableau 15 : description de sous cas d'utilisation : consulter contrat

Description textuelle du cas d’utilisation : ajouter contrat

Tableau 16 : description du sous cas d'utilisation : ajouter contrat

Description textuelle du cas d’utilisation : modifier contrat

Tableau 17 : description de sous cas d'utilisation : modifier contrat

Description textuelle du cas d’utilisation : supprimer contrat

Tableau 18 : description de sous cas d'utilisation : supprimer contrat

Description du cas d’utilisation gérer hôtels

Description textuelle du cas d’utilisation : consulter hotel

Tableau 19 : description de sous cas d'utilisation : consulter hotel

Description textuelle du cas d’utilisation : ajouter hotel

Tableau 20 : description de sous cas d'utilisation : ajouter hotel

Description textuelle du cas d’utilisation : modifier hotel

Tableau 21 : description de sous cas d'utilisation : modifier hotel

Description textuelle du cas d’utilisation : supprimer hotel

Tableau 22 : description de sous cas d'utilisation supprimer hotel

Le schéma suivant synthétise les cas d’utilisations du sprint 1 :

Figure 20 : description des cas d'utilisation du sprint 1

Conception

La conception est la deuxième activité du sprint. Elle se traduit par des digrammes de séquence, des diagrammes de classes participantes et le diagramme de classe d’UML.

Diagramme de séquence détaillé

Le diagramme de séquence détaillé permet de schématiser la communication entre les différents composants du système.

Diagramme de séquence détaillé du cas d’utilisation : gérer contacts

Diagramme de séquence détaillé du sous cas d’utilisation : ajouter contrat

Figure 21 : diagramme de séquence détaillé de cas d'utilisation ajouter contrat

Diagramme de séquence détaillé du sous cas d’utilisation : consulter contrat

Figure 22 : diagramme de séquence détaillé du cas d’utilisation consulter contrat

Diagramme de séquence détaillé du sous cas d’utilisation : modifier contrat

Figure 23 : diagramme de séquence détaillé du cas d'utilisation modifier contrat

Diagramme de séquence détaillé du sous cas d’utilisation : supprimer contrat

Figure 24 : diagramme de cas d'utilisation détaillé du cas d'utilisation supprimer contrat

Diagramme des classes de conception :

Le diagramme de classe est l’un des diagrammes statiques d'UML. Il permet de décrire la structure d'un système informatique tout en montrant les différentes classes, leurs attributs, leurs méthodes ainsi que les relations entre eux. Tout au long de nos sprints, nous essayerons de construire ce diagramme au fur et mesure en ajoutant les différentes classes déduites.

La figure ci-dessous illustre le diagramme de classe de conception de ce premier sprint :

Figure 25 : diagramme des classes de sprint 1

Conclusion

Cette release a été vite clôturé vue qu’après 3 réunion avec le client, il a choisie de modifier les type des produits à vendre en ajoutant des packages, des produits spéciale, en plus il a volue fusionner les prix dans l’entité hotel en les choisissant par date et par saison Alor, dans la release suivant en va voir comment en va faire la conception du module d’achat dans deux sprints.

Release 2 : module d’achat

________________________________________________________

Introduction

Le deuxième release a été planifié avec le Product owner pour assurer que toute la fonctionnalité implémentée répond exactement à ses besoins. Donc en eu un accès directe au système courant pour collecter les donnée nécessaire pour avoir nos entités de la façon correcte, et les intégrer à nos système à inventer.

Donc dans ce chapitre nous allons traiter les histoires utilisateur des sprints de notre release en couvrant quelque cas d’utilisation, des diagrammes de séquence, des diagrammes d’activités pour présenter le workflow de ces cas d’utilisation et en fin un diagramme de séquence du release.

Premier sprint

Pour cette sprint , l’équipe SCRUM avec le Product owner a décider de compléter le module d’achat pour permettre la deuxième équipe d’avoir les donnée nécessaire de tester l’espace client.

Le module d’achat est la présentation des produit à vendre par la société client, les produit sont, des réservations dans des hôtels, des packages qui se compose des produit qui peut être des voyages, des excursions, des billets d’avions, etc.

Comme dans le chapitre précèdent, maintenant en décide quelle est les fonctionnalités et leurs degrés d’importance incluent dans ce dernier. Plus précisément , parmi les noms qui figurent dans notre back log de produit, lesquelles sont inclus dans le back log du sprint. Ce qui résume donc le tableau ci-dessous, le back log de notre premier sprint :

Tableau 23 : back log du sprint 1 release 2

Spécifications fonctionnelle

Comme dans le chapitre précèdent, en vas poursuivre le traitement textuelle de quelque cas d’utilisation de notre sprint actuelle.

Scenario et cas d’utilisation

Apres notre back log, on peut l’expliciter sous forme de tableaux :

Chaque tableau présente la description du fonctionnement des cas d’utilisation. Dans ce sprint nous allons s’intéresser sur les 2 cas d’utilisations suivantes :

Vu que les autres tâches (gestion des villes, pays, régions etc.) Contient presque que les taches habituelle du développement, c’est-à-dire une CRUD simple et que les deux cas d’utilisation qu’on va expliquer contient déjà ces opérations donc on ne va pas les expliquer dans ce chapitre.

Description du Cas d’utilisation gérer hôtels

Description de sous cas d’utilisation ajouter hotel

Tableau 24 : description de sous cas d’utilisation ajouter hotel

Description de sous cas d’utilisation modifier hotel

Tableau 25 : description de sous cas d’utilisation modifier hotel

Description de sous cas d’utilisation ajouter tarif

Tableau 26 : description de cas d’utilisation ajouter tarif

Description de sous cas d’utilisation supprimer hotel

Tableau 27 : description de cas d’utilisation supprimer hotel

Description du Cas d’utilisation gérer packages

Description de sous cas d’utilisation consulter packages

Tableau 28 : description de sous cas d’utilisation consulter package

Description de sous cas d’utilisation ajouter package

Tableau 29 : description de sous cas d’utilisation ajouter package

Le schéma suivant synthétise tous les cas d’utilisations principale du sprint 1 :

Figure 26 : description des cas d’utilisation du sprint 1 – release 2

Conception

Pendant cette deuxième activité de notre sprint en vas faire les diagrammes de séquence détaillée du quelque cas d’utilisation importante avec ces diagramme d’activité correspondant pour présenter le déroulement de flux de travaille

Diagramme de séquence détaillé

Diagramme de séquence détaillée du cas d’utilisation ajouter hotel

Figure 27 : diagramme de séquence ajouter hotel

Diagramme de séquence détaillée du cas d’utilisation ajouter tarif

Figure 28 : diagramme de séquence de cas d’utilisation ajouter tarif

Diagramme de séquence détaillée du cas d’utilisation modifier hotel

Figure 29 : digramme de cas d’utilisation modifier hotel

Diagramme de séquence détaillée du cas d’utilisation supprimer hotel

Figure 30 : diagramme de séquence du cas d’utilisation supprimer hotel

Diagramme de séquence détaillée du cas d’utilisation ajouter package

Figure 31 : diagramme de séquence du cas d’utilisation ajouter package

Diagramme de séquence détaillée du cas d’utilisation modifier package

Figure 32 : diagramme de séquence modifier package

Diagramme de séquence détaillée du cas d’utilisation supprimer package

Figure 33 : diagramme de séquence supprimer package

Diagramme d’activité (workflow)

Diagramme d’activité : ajouter hotel

Figure 34 : diagramme d’activité ajouter hotel

Diagramme de classe

Figure 35 : diagramme de classe sprint 1 – release 2 : module d’achat

Réalisation

Cette phase représente la partie développement de notre sprint, donc après la vérification avec le Product owner en a implémenter le module d’achat et si suit des imprimés écran des interfaces de ce module :

Figure 36 : interface d’accueil gérer hôtels

Figure 37 : interface d’ajout d’un hotel (section donnée générale)

Figure 38 : interface d’ajout d’un hotel (section localisation)

Figure 39 : interface d’ajout d’un tarif

Figure 40 : interface d’ajout d’un type de chambre

Figure 41 : interface de gestion des types des chambres

Conclusion

Le résultat d’un release est un produit livrable au client contrairement au résultat d’un sprint qui est un produit potentiellement livrable. A la fin de ce chapitre, nous avons réussi à produire un incrément ayant suffisamment de valeur pour le client.

Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau release couvrant les fonctionnalités de l’extraction des devis et la gestion des réservations.

Release 3 : gestion des réservations : partie devis

________________________________________________________

Introduction

Pendant ce release nous avons pour objectif de concevoir et d’implémenter la partie réservation de notre projet. Pour cette partie elle se compose de deux sous module : la gestion des devis et la gestion des factures, pour ce chapitre nous allons concentrer sur la gestion des devis.

Donc notre démarche sera l’habituelle : faire des descriptions détaillé de quelque cas d’utilisation puis en vas procéder ver les scenarios et les diagrammes de séquence et les diagrammes d’activités et en fin le diagramme de classe du release.

Premier sprint

Comme en a cité avant, pour ce sprint l’équipe SCRUM a pour objectif d’implémenter la gestion de devis. Cette histoire d’utilisateur va donner à l’agent la possibilité de rechercher une réservation pour un client, ou bien accéder à des listes de réservation prêt puis configure et remplir un formulaire de devis pour récupérer un prix d’une réservation et le donner au client.

Et maintenant comme d’habitude en décide quelle est les fonctionnalités et leurs degrés d’importance incluent dans ce dernier. Plus précisément , parmi les noms qui figurent dans notre back log de produit, lesquelles sont inclus dans le back log du sprint. Ce qui résume donc le tableau ci-dessous, le back log de notre premier sprint du release 3 :

Tableau 30 : back log du sprint 1 release 3

Spécification fonctionnelle

Maintenant en va entamer notre description détaillé des cas d’utilisation de notre sprint si dessous.

Scenarios et cas d’utilisation

Notre back log va être divisé sous forme des tableaux de description détaillé des cas d’utilisation dont en peut récupérer deux importants :

Donc maintenant en vas traiter et décrire les cas d’utilisation les plus important dans cette sprint

Description du cas d’utilisation gérer devis

Description détaillé de sous cas d’utilisation nouveaux devis

Tableau 31 : description de sous cas d’utilisation nouvelle devis

Description détaillé de sous cas d’utilisation rechercher devis

Tableau 32 : description de sous cas d’utilisation rechercher réservation

Description détaillé de sous cas d’utilisation consulter liste des devis

Tableau 33 : description de cas d’utilisation lister devis

Description détaillé de sous cas d’utilisation supprimer devis

Tableau 34 : description de cas d’utilisation supprimer devis

Ainsi le diagramme de cas d’utilisation du sprint actuelle :

Figure 42 : diagramme de cas d’utilisation du sprint 1 release 3

Conception

Diagramme de séquence

Diagramme de séquence rechercher réservation

Figure 43 : diagramme de séquence rechercher réservation

Diagramme de séquence nouvelle devis

Figure 44 : diagramme de cas d’utilisation de sous cas d’utilisation nouvelle devis

Diagramme de séquence supprimer devis

Figure 45 : diagramme de séquence de sous cas d’utilisation supprimer devis

Diagramme d’activité

Le diagramme d'activité est un diagramme comportemental d'UML, permettant de représenter le déclenchement d'événements en fonction des états du système et de modéliser des comportements parallélisables (multithreads ou multiprocessus) [2].

Et donc si dessous des diagrammes d’activités de quelque cas d’utilisation :

Diagramme d’activité rechercher réservation

Figure 46 : diagramme d’activité rechercher réservation

Diagramme d’activité nouvelle devis

Figure 47 : diagramme d’activité du cas d’utilisation nouvelle devis

Diagramme de classe

Figure 48 : diagramme de classe du sprint 1 release 3

Réalisation

Apres l’implémentation de notre sprint en a obtenu les résultats affichés dans les imprimés écran si dessous :

Figure 49 : écran d’accueil du système

Figure 50 : résultat de la recherche d’une réservation

Figure 51 : interface de sélection des devis

Figure 52 : interface recherche d’une réservation

Figure 53 : liste des devis pour un hotel

Figure 54 : interface de la création d’un devis

Conclusion

Pour conclure, dans ce chapitre en a concentrer à implémenter une fonctionnalité très important qui cers à aider l’agent de fournir un meilleur service au client a des temps courte et après le deuxième équipe a pris le relève pour compléter la deuxième partie de la réservation : gestion des factures et l’espace client.

La Phase de Clôture

________________________________________________________

Introduction

La phase de clôture présente la dernière phase dans le cycle de développement d’un logiciel avec Scrum. Cette phase est souvent appelé sprint de stabilisation. Cette phase varie du projet ver un autre projet car elle dépend fortement du type de déploiement du logiciel (mise en production à chaud, packaging de produit, mise à disposition par téléchargent en ligne, etc.).

Dans cette partie nous décriront l’environnement du travail qui nous a permis d’achever et de réaliser la conception abordée dans le chapitre précèdent.

Environnement de travail

Choix de l’architecture de l’application

Dans notre Projet en est censé de développer un ERP avec un espace client, donc c’est très évident de choir d’abord une architecture web servie entre l’espace client et l’ERP, et comme en a choisis ODOO comme noyaux pour notre ERP, en a choisis d’implémenter l’espace client avec python et la framework Django vue que déjà python a connu une révolution ces année comme une langage serveur web très important et qui a des performance trop puissante . Donc python utilisa le protocole https pour envoyer des web service JSON-RPC a l’ERP ZIARA qui les traite et envoie la réponse souhaiter. Notre base de données et bien sûr PostgreSQL.

En fin, notre projet sera diviser en 2 partie, la première c’est l’ERP : l’utilisation du noyau d’odoo et le développement spécifique des module totalement indépendante qui fait le travail souhaite pour l’entreprise (gestion des activités d’agence touristique) en utilisant python/XML, et l’utilisation de Django pour développer l’espace client et le site web en utilisant python/djinger/html/css/js.et si dessous une figure qui explique la relation entre les différentes technologies du projet :

Elaboration du diagramme de déploiement

Figure 55 : diagramme de déploiement de ZIARA

Environnent matériel

Dans notre Projet en a utiliser l’environnement matériel suivant :

Un pc portable acer avec la configuration suivant :

Processeur i3 4éme génération

Ram 6go

Carte graphique nvidia gt 840

1TO disque dur

Un pc portable Toshiba

Un pc portable dell avec la configuration suivant :

Processeur i7 4éme génération

Carte graphique nvidia gt 840

6gb ram

1TO disque dur

Un pc portable Asus

Un pc fixe dell

Technologie utilisées

Python

XML

CSS

Html

JavaScript

ANGULARJS

LESS

Environnement logiciel

Pendant la phase de développement en a utiliser les logicielle suivante pour achever notre tâche :

ATOM

Notepad++

Sublime Txt

Microsoft Excel

PostgreSQL

Workzeug server

Protocole et format de donnée

Protocole de communication

Le protocole de communication utilisée est le https entre Django et odoo et le http dans l’intranet utilisant odoo ; l’implémentation sécurisée de cet ERP consiste à utiliser un proxy de redirection qui utilise une connexion SSL entre les données qui veulent communiquer avec odoo et odoo.

Forma de donnée communiquée

Pour la format de donnée communiquée entre le back-office er le front-end en a utiliser deux type : le JSON-RPC qui est un outil qui sert à faire des appel des procédures dans odoo via l’interface odoo-rpc , cet api est très utile car le json est maintenant la format la plus rapide dans la communication entre les Framework , le deuxième type et bien évidement le JSON pour la communication semi REST entre angularjs et odoo-rpc

Conclusion

Tout au long de ce chapitre nous avons essayé de présenter les différents travaux qui se déroulent à la fin du cycle de développement Scrum. Nous avons présenté le diagramme de déploiement de notre application et nous avons préparé la documentation nécessaire pour les futurs développeurs.

Conclusion générale

Ce projet était d’une part une occasion d’exploiter sur le plan pratique nos connaissances universitaires et d’autre part, d’améliorer non compétence de la programmation.

Durant ce projet nous avons suivie une démarche méthodiques en passant par la définition de besoin, l’élaboration du back log, après en a commencer à produire des livrable en passant par plusieurs release durant lesquelles en a fait des conceptions, des traitements des histoires utilisateur pour arriver à les implémenter.

Cet ERP développé présente en réalité un produit initial d’un grand projet qu’on va continuer à l’améliorer, comme l’intégration d’Amadeus dans le projet, l’amélioration de la partie b2b n b2c, etc…

Ce stage nous a permis de faire la connaissance des autres logiciels de développement, des autres langages.

Annexe 2
Titre

Annexe 3
Titre

Titre du sujet.

Rapport de Stage PFE

_________________________________________________________________

RESUME

Vous devez mettre un résumé de votre rapport en langue française, en indiquant les mots clés. Si l’on prend l’exemple d’un projet qui traite du commerce électronique, un des mots clés peut être le commerce électronique.

Le résumé ne doit pas dépasser les 10 lignes.

Mots clés : commerce électronique, … .

_________________________________________________________________

SUMMARY

You should give an English abstract for your report. You have to indicate your key-words. For example, if your project is interesting on the e-commerce, this word can be a key-word.

The abstract should not exceed 10 lines.

Key words : e-commerce, ….