SlideShare une entreprise Scribd logo
MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA
RECHERCHE SCIENTIFIQUE
UNIVERSITE TUNIS EL MANAR
INSTITUT SUPERIEUR D’INFORMATIQUE
RAPPORT DE STAGE DE FIN D’ETUDES
Présenté en vue de l’obtention du
Diplôme National de Master Professionnel en Sciences et Technologies
Mention : Informatique
Spécialité : Sécurité des Systèmes Informatiques Communicants et Embarqués
Par
Mr.Mohamed Ridha BEN SASSI Mr.Wissem KHITMI
Encadrant professionnel Mr.Abderrazek CHINE
Encadrant académique M.Lobna HSAIRI
Réalisé au sein de (Horizon Ingénierie Informatique)
Année Universitaire 2015/2016
CONCEPTION ET REALISTION D’UNE Front Office
& BackOffice De « GESTION DES POINTS DE VENTES »
Encadrant Entreprise
Encadrant ISI
Signature et cachet :
Signature :
Dédicaces
On dédie ce modeste travail à :
Mes chers parents en guise de reconnaissance et de gratitude pour les sacrifices
qu’ils ont faits.
Mon cher frère pour leur grand amour, avec tous mes vœux de les voir réussir
dans leur vie.
Nos chers amis à qui nous souhaitons le succès, pour l’amitié qui nous a toujours
unis.
A tous ceux qui nous sont chers et toujours dans mon pensée.
Wissem
Dédicaces
A ma mère,
Tu m'as donné la vie, la tendresse et le courage pour réussir. Tout ce
que je peux t'offrir ne pourra exprimer l’amour et la reconnaissance que
je porte.
En témoigne, je t'offre ce modeste travail pour te remercier pour tes
sacrifices et pour l'affectation dont tu m'a toujours entourée
A mon père,
L'épaule solide, l'œil attentif compréhensif et la personne la plus
digne de mon estime et de mon respect.
Aucune dédicace ne saurait exprimer mes sentiments, que Dieu te
préserve et te procure santé et longue vie
Ridha
Remerciements
Comme l’a dit SIR ISAAC NEWTON :
« Si j’ai pu voir plus loin, c’est en montant sur les épaules des géants »
Nous tenons à adresser mon sincère remerciement :
A Mr. Chine ABDERRAZAK et M. Lobna HSAIRI pour avoir bien
voulu nous encadrer, pour tout le temps qu’ils me ont octroyés et pour
Tous les conseils qu’ils me ont prodigués.
Qu’ils trouvent ici l’expression de notre profonde gratitude.
A tous les membres du jury.
A tous ceux qui, directement ou indirectement, ont aidé à la
Finalisation de ce travail.
Sommaire
Introduction Générale …………...……………………………………………………...1
Chapitre 1. Etude Préalable………................................................................................. 3
I. Présentation de l’organisme d’accueil .................................................................... .................. 3
I.1. L’entreprise ........................................................................................................................ 3
I.2. Activités d’Horizon Informatique ...................................................................................... 3
I.3. L’organigramme ................................................................................................................. 4
II. Etude de l’existant…………......................................................................................................... 4
II.1. Analyse de logiciel XL POS................................................................................................ 5
II.2. Analyse de logiciel Ebp Caisse…………............................................................................... 6
II.3. Solution proposée ....................................................................................... ...................... 8
III. Contexte et motivation du projet ............................................................................................. 9
III.1. Contexte ............................................................................................................................ 9
III.2. But de projet ..................................................................................................................... 9
III.3. Travail demandé ............................................................................................................. 10
IV. Langage et méthodologie de conception................................................................................. 10
IV.1. Pourquoi Scrum .................................................................................... .......................... 11
Chapitre 2. Planification et spécification des besoins……...…...................................... 13
I. Capture des besoins.....................................................................................................................13
I.1. Identification des acteurs.................................................................................................... . 13
I.2. Les besoins fonctionnels....................................................................................................... 15
I.3. Les besoins non fonctionnels................................................................................................15
II. Planning du traitement des cas d’utilisation ............................................................................. 17
II.1. Priorités………………………......................................................................................................17
III. Prototypage des interfaces.........................................................................................................17
IV. Pilotage du projet avec Scrum................................................................................................ . 20
IV.1. Outils Scrum..................................................................................................……………......20
IV.2. Equipe et rôles................................................................................................................... 20
IV.3. Le backlog du produit......................................................................................................... 21
IV.4. Diagramme des cas d’utilisation global............................................................................. 25
IV.5. Architecture logique………..................................................................................................26
IV.6. Planification des sprints.................................................................................................... 26
Chapitre 3. Release 1 - Gestion Des Articles.................................................................... 29
I. Le premier sprint.........................................................................................................................29
I.1. Spécification fonctionnelle.................................................................................................. 30
I.1.1. Diagramme des cas d’utilisation.................................................................................. 30
I.1.2. Description textuelle des cas d’utilisation.................................................................... 30
I.2. Conception…………………………..............................................................................................36
I.2.1. Diagramme de séquence système............................................................................... 36
I.2.2. Diagramme des classes................................................................................……………. 38
I.3. Codage………………………….....................................................................................................39
I.4. Test…………………………..........................................................................................................41
I.4.1. Les Test unitaires ……………………................................................................................ 41
II. Le deuxième sprint.....................................................................................................................43
II.1. Spécification fonctionnelle................................................................................................. 44
II.1.1. Diagramme des cas d’utilisation................................................................................. 44
II.1.2. Description textuelle des cas d’utilisation................................................................... 45
II.2. Conception………………………….............................................................................................49
II.2.1. Diagramme de séquence système.............................................................................. 49
II.2.2. Diagramme des classes...............................................................................……………. 51
II.3. Codage…………………………....................................................................................................51
II.4. Test…………………..……..........................................................................................................53
II.4.1. Les Test unitaires …………………….............................................................................. 53
Chapitre 4. Release 2 - Gestion de magasin & Faire des traitements............................ 55
I. Le premier sprint.........................................................................................................................55
I.1. Spécification fonctionnelle.................................................................................................. 56
I.1.1. Diagramme des cas d’utilisation.................................................................................. 56
I.1.2. Description textuelle des cas d’utilisation..................................................................... 57
I.2. Conception…………………………..............................................................................................60
I.2.1. Diagramme de séquence système................................................................................ 60
I.2.2. Diagramme des classes................................................................................……………. 61
I.3. Codage………………………….....................................................................................................62
I.4. Test…………………………..........................................................................................................64
I.4.1. Les Test unitaires ……………………................................................................................ 64
II. Le deuxième sprint.....................................................................................................................65
II.1. Spécification fonctionnelle................................................................................................. 66
II.1.1. Diagramme des cas d’utilisation................................................................................. 66
II.1.2. Description textuelle des cas d’utilisation................................................................... 67
II.2. Conception………………………….............................................................................................69
II.2.1. Diagramme de séquence système.............................................................................. 69
II.2.2. Diagramme des classes...............................................................................……………. 70
II.3. Codage…………………………....................................................................................................71
II.4. Test…………………..……..........................................................................................................72
II.4.1. Les Test unitaires ……………………............................................................................... 72
Chapitre 5. Release 3 – Administration……................................................................... 75
I. Le premier sprint...............................................................................................z.........................75
I.1. Spécification fonctionnelle.................................................................................................. 76
I.1.1. Diagramme des cas d’utilisation.................................................................................. 76
I.1.2. Description textuelle des cas d’utilisation..................................................................... 77
I.2. Conception…………………………..............................................................................................78
I.2.1. Diagramme de séquence système............................................................................... 78
I.2.2. Diagramme des classes................................................................................……………. 80
I.3. Codage………………………….....................................................................................................81
I.4. Test…………………………..........................................................................................................83
I.4.1. Les Test unitaires ……………………................................................................................ 83
II. Le deuxième sprint.....................................................................................................................84
II.1. Spécification fonctionnelle................................................................................................. 85
II.1.1. Diagramme des cas d’utilisation................................................................................. 85
II.1.2. Description textuelle des cas d’utilisation................................................................... 86
II.2. Conception………………………….............................................................................................87
II.2.1. Diagramme de séquence système.............................................................................. 87
II.2.2. Diagramme des classes..............................................................................……………. 88
Chapitre 6. La phase de closure………………………………………............................ 90
I. Environnement de développement ............................................................................................90
I.1. Environnement matériel………............................................................................................ 90
I.1.1. Environnement de développement.............................................................................. 90
I.1.2. Environnement de test.................................................................................................. 91
I.1.3. Environnement de production...................................................................................... 91
I.2. Environnement logiciel………………………..............................................................................91
I.2.1. Eclipse……………………………………................................................................................. 91
I.2.2. Sybase POWER AMC...................................................................................……………. 92
I.2.3. Oracle Database 10g.....................................................................................……………. 92
I.3. Langage de programmation…...............................................................................................93
I.3.1. java EE……………………………………................................................................................ 93
I.3.2. UML………………………..................................................................................……………. 94
I.3.3. Le langage SQL……............................................................................................………. 93
I.4. Les Framework….……….........................................................................................................95
I.4.1. JSF2.0……………………………………….............................................................................. 95
I.4.2. Spring…………………….................................................................................................... 95
I.4.3. Hibernate……………………………......................................................................................95
II. Déploiement………......................................................................................................................96
II.1. Diagramme de déploiement............................................................................................... 96
II.2. Les interfaces de l’application……………..............................................................................98
Conclusion et perspectives…….………………………...………….............................. 102
Annexe A……………………….………………………...………….............................. 103
I. Règle 1 : transformation des entités/classes…………................................................................. 103
II. Règle 1 : transformation des associations…..............................................................................103
II.1. Association un à plusieurs................................................................................................ 103
II.2. Association plusieurs à plusieurs……………….…................................................................104
II.3. Association un à un.......................................................................................................... 105
II.4. Transformation de l’héritage………………...........................................................................105
II.5. Transformation de la composition................................................................................... 106
Bibliographie.………………….…………………………………….............................. 107
Liste des Figures
Figure 1.1 : L’organigramme de la société ………………………………………………….4
Figure 1.2: FrontOffice & BackOffice XL POS ………………………………………….5
Figure1.3 : FrontOffice & BackOffice Ebp Caisse ……………………………………………...7
Figure 1.3 : Le processus de Scrum ……………………………………………………………..11
Figure 2.1 : Diagramme de contexte statique…………………………………………………… 14
Figure 2.2 : Page d’authentification (BackOffice)………………………………………………. 18
Figure 2.3 : Tableau de bord (BackOffice) ………………………………………………………18
Figure 2.4 : Fenêtre principale (FrontOffice) ……………………………………………………19
Figure 2.5 : Gestion des articles (BackOffice) ………………………………………………….19
Figure 2.6 : Equipe Scrum ………………………………………………………………………. 21
Figure 2.7 : Diagramme des cas d’utilisation global…………………………………………….. 25
Figure 2.8 : Diagramme de package …………………………………………………………….26
Figure 2.9 : Plan de release ………………………………………………………………………27
Figure 3.1 : Diagramme des cas d’utilisation de premier sprint (release 1) ……………………..31
Figure 3.2 : Exemple d’une histoire utilisateur ………………………………………………… 32
Figure 3.3 : Diagramme de séquence «consulter la liste des sous catégorie» …………………...37
Figure 3.4 : Diagramme de séquence «chercher une famille»…………………………………... 38
Figure 3.5 : Diagramme de classe du premier sprint (release 1) …………………………………39
Figure 3.6 : Code source de la classe de test pour l’histoire «supprimer une famille» …………..42
Figure 3.7 : Cas de succès pour la suppression d’une famille ……………………………………42
Figure 3.8 : Cas d’échec pour la suppression d’une famille ………………………………………43
Figure 3.9 : Diagramme des cas d’utilisation du second sprint (release 1)……………………… 45
Figure 3.10 : Diagramme de séquence système du cas d’utilisation «consulter la liste des articles»
……………………………………………………………………………………………………..49
Figure 3.11 : Diagramme de séquence système du cas d’utilisation «ajouter un article» ………50
Figure 3.12 : Diagramme des classe du second sprint (release 1)………………………………..51
Figure 3.13 : Code source de la classe de test pour l’histoire «ajouter un article»……………… 53
Figure 3.14 : Cas du succès de la classe de test pour l’histoire «ajouter un article» …………….54
Figure 4.1 : Diagramme des cas d’utilisation du premier sprint (release 2) ……………………..57
Figure 4.2 : Diagramme de séquence «supprimer une caisse» …………………………………..60
Figure 4.3 : Diagramme de séquence «chercher un client» ………………………………………61
Figure 4.4 : Diagramme de classe du premier sprint (release 2) …………………………………62
Figure 4.5 : Code source de la classe de test pour l’histoire «modifier un vendeur»…………… 64
Figure 4.6 : Cas de succès pour la modification d’un vendeur …………………………………..65
Figure 4.7 : Diagramme des cas d’utilisation du second sprint (release 2) ………………………66
Figure 4.8 : Diagramme de séquence système du cas d’utilisation «Annuler ticket» …………..69
Figure 4.9 : Diagramme de séquence système du cas d’utilisation «Clôturer service»………… 70
Figure 4.10 : Diagramme des classes du second sprint (release 2)…………………………….. 71
Figure 4.11 : Code source de la classe de test pour l’histoire «supprimer un service»…………. 73
Figure 4.12 : Cas de succès pour la suppression d’un service …………………………………..73
Figure 5.1 : Diagramme des cas d’utilisation du premier sprint (release 3) ……………………..76
Figure 5.2 : Diagramme de séquence «modifier un utilisateur» …………………………………79
Figure 5.3 : Diagramme de séquence «supprimer une fonction»………………………………… 80
Figure 5.4 : Diagramme de classe du premier sprint (release3) ………………………………….81
Figure 5.5 : Code source de la classe de test pour l’histoire «ajouter un utilisateur»…………… 83
Figure 5.6 : Cas de succès pour l’ajout d’un utilisateur…………………………………………. 84
Figure 5.7 : Diagramme des cas d’utilisation du second sprint (release 3)……………………… 85
Figure 5.8 : Diagramme de séquence système du cas d’utilisation «consulter tableau de bord» ..87
Figure 5.9 : Diagramme de séquence système du cas d’utilisation «Authentification» …………88
Figure 5.10 : Diagramme de classe du premier sprint (release3) …………………………………89
Figure 6.1 : Eclipse ……………………………………………………………………………….91
Figure 6.2 : Power AMC ………………………………………………………………………… 92
Figure 6.3 : Oracle Data Base……………………………………………………………………. 92
Figure 6.4 : java EE ………………………………………………………………………………93
Figure 6.5 : UML………………………………………………………………………………… 94
Figure 6.6 : Langage SQL……………………………………………………………………….. 94
Figure 6.7 : JSF …………………………………………………………………………………..95
Figure 6.8 : Spring ……………………………………………………………………………….95
Figure 6.9 : Hibernate…………………………………………………………………………… 96
Figure 6.10 : Diagramme de déploiement de FrontOffice ………………………………………...97
Figure 6.11 : Diagramme de déploiement BackOffice …………………………………………...97
Figure 6.12 : Page d’authentification (BackOffice) …………………………………….………..98
Figure 6.13 : Tableau de Bord (BackOffice) ………………………………………………….….98
Figure 6.14 : Gestion Des Vendeurs (BackOffice) ………………………………………….…..99
Figure 6.15 : Fenêtre d’accueil (FrontOffice) ……………………………………………………99
Figure 6.16 : Fenêtre Principale (FrontOffice)………………………………………………….. 100
Figure 6.17 : Fenêtre d’ajout d’article (FrontOffice) …………………………………………...100
Figure A.1 : Les règles de transformation des associations dépendent de leur cardinalités maximale
………………………………………………………………………………………………….103
Figure A.2 : Règle 2 du passage du modèle conceptuel vers le modèle logique ………………104
Figure A.3 : Règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas) ..104
Figure A.4 : Règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième cas)
……………………………………………………………………………………………….……105
Figure A.5: Règle 3 du passage du modèle conceptuel vers le modèle logique (troisième cas)
…………………………………………………………………………………………………….106
Figure A.6: Règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième cas)..106
Liste des tableaux
Tableau 2.1 : Backlog de produit ………………………………………………………………….21
Tableau 3.1 : Backlog de premier sprint (release 1) ………………………………………………30
Tableau 3.2 : Description textuelle du cas d’utilisation «consulter la liste des types articles»…... 32
Tableau 3.3 : Description textuelle du cas d’utilisation «chercher un type article» …………….. 33
Tableau 3.4 : Description textuelle du cas d’utilisation «ajouter une famille» …………………...33
Tableau 3.5 : Description textuelle du cas d’utilisation «supprimer une catégorie»……………... 34
Tableau 3.6 : Description textuelle du cas d’utilisation «modifier un sous catégorie» …………...35
Tableau 3.7 : Table «Type_Article» ………………………………………………………………40
Tableau 3.8 : Table «Catégorie» …………………………………………………………………..40
Tableau 3.9 : Table «Sous_Catégorie»……………………………………………………….........40
Tableau 3.10 : Table «Famille»……………………………………………………………………40
Tableau 3.11 : Backlog de second sprint (release 1) ……………………………………………... 44
Tableau 3.12 : Description textuelle du cas d’utilisation «ajouter un article»…………………….. 45
Tableau 3.13 : Description textuelle du cas d’utilisation «supprimer une taille»………………… 46
Tableau 3.14 : Description textuelle du cas d’utilisation «modifier une marque» ………………..47
Tableau 3.15 : Description textuelle du cas d’utilisation «chercher un couleur» …………………48
Tableau 3.16 : Table «Article» …………………………………………………………………… 52
Tableau 3.17 : Table «Taille»……………………………………………………………………… 52
Tableau 3.18 : Table «Couleur» ……………………………………………………………………52
Tableau 3.19 : Table «Marque»…………………………………………………………………….52
Tableau 4.1 : Backlog du premier sprint (release 2) ………………………………………………55
Tableau 4.2 : Description textuelle du cas d’utilisation «consulter la liste des vendeurs» ………..58
Tableau 4.3 : Description textuelle du cas d’utilisation «supprimer une caisse» …………………58
Tableau 4.4 : Description textuelle du cas d’utilisation «ajouter un client»……………………… 59
Tableau 4.5 : Table «Vendeur» …………………………………………………………………….63
Tableau 4.6 : Table «Caisse»……………………………………………………………………… 63
Tableau 4.7 : Table «Client» ……………………………………………………………………… 63
Tableau 4.8 : Backlog de second sprint (release 2) ………………………………………………66
Tableau 4.9 : Description textuelle du cas d’utilisation «Annuler un ticket»…………………… 67
Tableau 4.10 : Description textuelle du cas d’utilisation «Clôturer un service»………………... 68
Tableau 4.11 : Table «Service» ………………………………………………………………….72
Tableau 4.12 : Table «Ticket» ……………………………………………………………………72
Tableau 5.1 : Backlog du premier sprint (release3)………………………………………………. 75
Tableau 5.2 : Description textuelle du cas d’utilisation «consulter la liste des utilisateurs»……..77
Tableau 5.3 : Description textuelle du cas d’utilisation «ajouter un utilisateur»………………... 77
Tableau 5.4 : Table «Utilisateur» …………………………………………………………………82
Tableau 5.5 : Table «Groupe»……………………………………………………………………. 82
Tableau 5.6 : Table «Fonction»…………………………………………………………………... 82
Tableau 5.7 : Table «Privilège»………………………………………………………………….. 82
Tableau 5.8 : Backlog de second sprint (release3) ………………………………………………..85
Tableau 5.9 : Description textuelle du cas d’utilisation «Authentification» ……………………..86
1
Introduction Générale
De l’âge de la pierre à nos jours, l’esprit perfectionniste de l’Homme n’a cessé de lui
permettre d’améliorer sa vie quotidienne. Le passage de la mécanique aux domaines
d’informatique, d’électronique, d’automatique et de domotique a révolutionné la vie journalière
de l’être humain. Les nouvelles technologies de l’information et de communication illustrent ce
phénomène.
Aujourd’hui, vu l’intérêt de vouloir gagner en temps, de conserver les données, de limiter le
nombre d’employés et pas mal d’autres raisons, ont poussé petites, moyennes et grandes
entreprises à chercher des solutions informatique capables de répondre à leurs besoins.
Dans ce cadre s’inscrit notre projet de fin d’études qui consiste à réaliser un BackOffice
et un FrontOffice sur mesure de gestion des points de ventes pour n’importe quelle surface
de vente.
Notre Objectif consiste donc à développer un logiciel FrontOffice qui aide les vendeurs de
point de vente à automatiser la tache de la vente, de mode de règlement et de la gestion de
commande et une application web qui représente BackOffice qui aide le responsable du
magasin à automatiser les tâches de la gestion des vendeurs, la gestion des clés et la gestion
des caisses .
Outre l’originalité de l’application à développer, nous essayerons en plus d’utiliser une
méthodologie, issue des méthodes agile, à savoir la méthode SCRUM. Nous essayerons à
travers ce rapport de mettre en évidence les étapes effectuées, dans lesquelles nous avons usé
des avantages de ladite méthode, surtout le plan de productivité et l’efficacité.
Notre rapport se compose de cinq chapitres répartis comme suit :
2
 Le premier chapitre «étude préalable» permet de placer le projet dans son contexte
général. Dans ce premier chapitre introductif nous présentons l’organisme d’accueil
ainsi qu’une brève description du projet.
 Le second chapitre «planning et spécification des besoins» qui consiste en la première
phase dans le cycle Scrum. Dans ce chapitre nous dévoilons les principales exigences de
notre application, nous préparons quelques interfaces graphiques pour mettre notre
application dans son contexte et nous le clôturons par un planning de travail.
 Le troisième chapitre «gestion des articles», le quatrième chapitre «gestion de magasin
et faire traitement» et le cinquième chapitre «administration & états et statistique»
constituent le corps de notre rapport. Ces trois chapitres seront consacrés pour le
développement des trois releases de notre système en respectant les principes
fondamentaux de Scrum.
 Le dernier chapitre « la phase de closue » détaille tous les outils utilisés pour la
conception et le développement de notre application ainsi que quelques captures
écran de la version finale de notre système.
En conclusion, nous mentionnons les différents atouts de ce projet et les perspectives
d’améliorations possibles
.
3
Chapitre I. Etude Préalable
Introduction :
L’étude du projet est une démarche stratégique visant à organiser le bon déroulement d’un
projet et d’assurer la conduite de toutes les phases qui le constituent.
Une étude complète et efficace conduit généralement à la réussite d’un projet. Cette étude fera
donc l’objet de notre premier chapitre qui sera consacré à la présentation de l’organisme
d’accueil, et la présentation du projet ainsi que la définition de notre langage et méthodologie
de développement.
I. Présentation de l’organisme d’accueil :
I.1. L’entreprise :
Horizon Ingénierie Informatique (HII) est une équipe d’informaticiens expérimentés à
l’écoute des nouvelles technologies dont l’objectif est de répondre aux besoins des
professionnels et des particuliers et de résoudre leurs problèmes en informatique.
I.2. Activités d’Horizon Informatique :
Les activités d’Horizon Ingénierie Informatique sont très variées, nous puissions mentionner
quelques-unes :
 Conception et développement des logiciels sur mesure.
 Vente, Achats et maintenance des matériels informatique
 Installation et maintenance des réseaux locaux.
 Développement d’applications.
 Rédaction des cahiers de charges.
4
I.3. L’organigramme :
La figure 1.1 montre l’organigramme de la société Horizon Informatique :
II. Etude de l’existant :
L’étude de l’existant permet de déterminer les points faibles et les points forts d’un produit
actuel pour pouvoir déterminer les besoins du client, en vue d’en prendre en considération lors
de la conception et de la réalisation du système de la gestion du point de vente. Dans cette
section, nous présentons une analyse de quelques exemples d’application marchands. Ensuit,
nous formulerons une solution de la problématique.
Figure 2.1 : L’organigramme de la société
5
II.1. Analyse de Logicielle XL POS :
 Aperçu :
La figure 1.2 montre un aperçu sur le logiciel
 URL:
http://www.xlsoft.fr/logiciel-gestion/caisse-gestion/xlpos-caisse-gestion.html
 Description :
XL Pos est un logiciel de caisse et de gestion complète de point de vente. De la caisse, à la
gestion des clients et des stocks en passant par la fidélité, XL Pos est une solution qui
prendre en charge l’ensemble de l’activité du magasin. XL Pos est une solution capable
d’apporter une réponse à la plupart des exigences du client.
 Les points forts :
Figure 1.2: FrontOffice & BackOffice XL POS
6
 Fiable et simple, le client peut utiliser XL Pos en toute sécurité.
 Paramétrable, la personnalisation du clavier de caisse, des documents et des
statistiques en ferrant un outil adapté aux méthodes de travail du client.
 Evolutif, les modules complémentaires permettront d’évoluer tant en superficie
ou nombre de points de ventes, qu’en richesse fonctionnelle. Chaque année
l’équipe XL pos propose un ensemble de nouveautés pour garantir la
performance de son solution.
 Les points faibles
 Partie front Office n’est pas portable.
 Format de ticket n’est pas modifiable
 Oblige une seule thème (thème bleu)
 La documentation en ligne n’est pas la plus complète. Pour avoir accès à toutes
les directives de configuration, il faut télécharger le logiciel pour consulter les
pages de manuels. éventuellement, certaines pages de la FAQ peuvent se
révéler d’un grand secours.
 Cout relativement élevé.
II.2. Analyse de logiciel Ebp Caisse :
 Aperçu :
7
Figure 1.3 : FrontOffice & BackOffice Ebp Caisse
 URL:
http://boutique.ebp.com/
 Description :
Très complet, cet outil 2 en 1 allie dans un seul logiciel : la rapidité d’une caisse enregistreuse
et la puissance d’une gestion commerciale. Il est alors très simple d’encaisser, de gérer les
ventes, de fidéliser les clients et de transférer les données en comptabilité sans aucune
ressaisie.
8
 Les points forts :
 Facilité d’encaissement quotidien
 Un écran de caisse intuitif, personnalisable selon les préférences de travail.
 Réalisation des opérations commerciales
 Epb logiciel permet d’éditer un coupon supplémentaire lors de l’impression du ticket
de caisse. Idéal pour mettre en avant une offre promotionnelle ou communiquer sur un
produit en particulier !
 Simplifiez tous les aspects de la gestion,
 Suivi des stocks, réapprovisionnement, commandes fournisseurs, inventaire … tout
est centralisé dans le logiciel pour une gestion optimale
 Visualisez en un coup d’œil les chiffres clés
 Analyse efficace des activités avec des statistiques détaillées sur les articles, les
clients, le CA...
 Les points faibles :
 Format de ticket n’est pas modifiable
 Ne gère pas la mise en attente d’un ticket
 Oblige une seule thème (thème bleu)
 La documentation en ligne n’est pas la plus complète. Pour avoir accès à toutes les
directives de configuration, il faut télécharger le logiciel pour consulter les pages de
manuels. éventuellement, certaines pages de la FAQ peuvent se révéler d’un grand
secours.
II.3. Solution proposée :
Suite aux inconvénients cités dans la section précédente, nous proposons la mise en place d’un
logiciel de gestion du point de vente qui automatise les différentes activités du magasin tel que
la gestion de la vente (règlement, remise, commentaire) et la gestion de magasin (caisse,
vendeur, etc.) de point de vente ainsi que la gestion du stock.
9
III. Contexte et motivation du projet :
Le présent projet intitulé «Développement d’une Back Office et Front Office de gestion des
points de ventes (GPVhorizon).
III.1. Contexte :
Comme on l’a cité précédemment, Horizon Ingénierie Informatique n’est pas une société
consommatrice, elle est plutôt productrice. Toutes les applications développées sont
destinées alors à la vente. L’application en question s’agit d’une commande d’une
surface de vente (magasin). Il s’agit donc d’une application de gestion de point de
vente composée par deux partie (Back Office et Front Office ) , cette solution doit être
capable d’automatiser les taches et d’améliorer la productivité de point de vente tout en
respectant les exigences de client .
III.2. But de projet :
La gestion de points de vente est souvent compliquée. Gestion de stocks multiples, personnels
aux horaires variables, gestion des caisses ou encore du service après-vente sont autant de défis
qu’il faut relever au quotidien.
Dans cette situation, il est primordial de bien organiser afin de répondre à ces exigences tout en
garantissant la rentabilité de magasin.
Il faut pouvoir évaluer rapidement les disponibilités de stocks, les entrées et sorties prévues afin
de répondre dans les meilleurs délais aux demandes des clients.
Pour faire face à toutes ces exigences, vous devez posséder un système d’information
souple, adapté et évolutif. Un système qui vous permettra de suivre en quelques clics
l’activité et de gérer un magasin.
Une réaction rapide aux problèmes sera un atout de plus pour garantir la satisfaction de
des clientèles.
L’objet de ce projet est la conception et la réalisation d’une application web (Back Office) et une
10
application Desktop (front Office) fiable, agréable et simple d’utilisation, pour la gestion des
stocks, la gestion du magasin et la gestion de vente.
III .3. Travail demandé :
Notre travail consiste à concevoir et à développer une application informatique qui permettra la
gestion des clients, des vendeurs, des clés, des caisses, du stock, de cartes de fidélité, génération
des rapports et statistiques, génération des journaux tickets, gérer les promotions, faire des
traitements (annulation ticket, clôturer service…) , gestion de Vente( appliquer remise , règlement
... ).
IV. Langage et méthodologie de conception :
La méthodologie est une démarche organisée rationnellement pour aboutir à un résultat. Parmi les
différentes méthodologies existantes, nous pouvons citer le modèle en cascade utilisée souvent
dans les simples projets dont les besoins sont clairs et bien définis dès le début, le modèle en Y
utiliser pour le développement des applications mobiles, ainsi que le processus unifié et les
méthodologies agiles (Scrum & extrême programming) caractérisées par leurs souplesses et
utilisées dans des grands projets.
Pour bien conduire notre projet et nous assurer du bon déroulement des différentes phases, nous
avons opté Scrum comme une méthodologie de conception et de développement. Après le choix
de la méthodologie, nous avons besoins d’un langage de modélisation unifiée pour la
modélisation de notre projet. Pour concevoir notre système, nous avons choisi UML comme un
langage de modélisation.
Notre choix s’est basé sur les points forts de ce langage notamment sa standardisation et les divers
diagrammes qu’il propose. Aussi UML présente le meilleur outil pour schématiser des systèmes
complexes sous un format graphique et textuel simplifié et normalisé.
En effet UML n’est ni un processus ni une démarche, d’où il fallait choisir une méthodologie
11
De conception et de développement que nous devons l’adopter
IV.1. Pourquoi SCRUM :
Le principe de base de Scrum est le suivant :
 Dégager dans un premier lieu le maximum des fonctionnalités à réaliser pour former le
backlog du produit,
 En second lieu définir les priorités des fonctionnalités et choisir lesquelles seront réalisé
dans chaque itération,
 Par la suite focaliser l’équipe de façon itérative sur l’ensemble de fonctionnalités à réaliser,
dans des itérations appelées Sprints,
 Un Sprint aboutit toujours sur la livraison d’un produit partiel fonctionnel appelé
incrément.
La figure 1.4 illustre le principe de Scrum.
Figure 1.4 : Le processus de Scrum
12
Le choix de Scrum comme une méthodologie de pilotage pour notre projet s’est basé sur les atouts
de ce dernier. Il se résumé comme suit:
 Plus de souplesse et de réactivité,
 La grande capacité d’adaptation au changement grâce à des itérations courtes,
 Et la chose plus importante, c’est que Scrum rassemble les deux cotés théorique et
pratique et se rapproche beaucoup de la réalité.
Vu que Scrum ne couvrant que les aspects de gestion de projet, et pour compléter le vide laissé en
matière de pratiques de développement, nous avons pris la décision de coupler Scrum avec une
autre méthodologie agile qui est l’extrême prograrnrning ( XP ) et qui couvre les bonnes pratiques
d’ingénierie logicielle notamment le développement dirigé par le test, qui sera détaillé dans les
chapitres qui suivent, et la programmation en binôme, etc.
Conclusion :
Dans ce chapitre, nous avons présenté le cadre générale de notre projet en déterminant la
problématique et en proposant une solution envisagé pour faire face à la situation courante. Nous
avons dévoilé le langage et la méthodologie de conception qui seront utilisés dans les prochains
chapitres de ce rapport et nous avons argumenté notre choix.
13
Chapitre II. Planification et
Spécification des besoins
Introduction
Dans le chapitre précédent, nous avons choisi d’adopter la méthodologie Scrum pour la
conception de notre futur système. En fait, Scrum est organisé suivant trois phases dont la
première est la phase de planification et architecture (appelé aussi sprint 0 dans quelques
ouvrages).Cette phase est la plus importante dans le cycle de développement Scrum puisqu’elle
qui influence directement la réussite des Sprints et en particulier le premier.
Les travaux réalisés dans cette période de temps conduit à construire une bonne vision du
produit. Identifier les rôles des utilisateurs et dégager les fonctionnalités principales afin de
produire le backlog initial ainsi qu’une première planification des Sprints.
Cette phase fera donc l’objet de ce chapitre où nous commençons par la capture des différents
besoins, identifier les rôles des utilisateurs et préparer notre plan de release.
I. Capture des besoins
I.1. Identification des acteurs
a. Les acteurs
Tout simplement un acteur est une entité physique (personne) ou abstraite (logiciel) capable
14
d’utilisée le système afin de répondre à un besoin bien définit. Les acteurs de notre application
sont:
 Administrateur Système : Peut-être le Gérant ou le responsable du magasin, c’est la
personne possédant le privilège du plus haut niveau. Cet acteur est capable de manipuler
toutes les fonctionnalités proposées par l’application notamment l’ajout des articles,
attribution des droits d’accès aux autres acteurs, etc. II s’agit principalement le
responsable de point de vente.
 Agent comptable : Peut-être un comptable ou responsable financier.
 Vendeur : Il s’agit du vendeur du point de vente.
b. Diagramme de contexte statique
Ce diagramme d’UML, illustré par la figure 2.1, permet simplement de montrer la relation des
différents acteurs avec le système. Il spécifie le nombre d’instances de chaque acteur relié au
système à un moment donné.
Figure 2.1 : Diagramme de contexte statique
15
Pour expliquer le diagramme présenté par la figure 2.1, nous pouvons dire qu’à un instant donné
nous pouvons avoir zéro ou deux administrateurs qui manipule l’application, et zéro ou
plusieurs agent comptable et vendeur qui sont en train d’utiliser l’application.
I.2. Les besoins fonctionnels :
Les besoins fonctionnels ou les cas d’utilisations en terme d’UML peuvent être définis comme
suit: « Un cas d’utilisation (use case) représente un ensemble de séquences d’actions réalisées
par le système et produisant un résultat observable intéressant pour un acteur particulier» [1]
Un cas d’utilisation est une suite d’actions effectuées par le système afin de répondre à une
demande d’un utilisateur (acteur). Dans ce qui suit, nous décrivons les différents besoins
fonctionnels de notre système:
 Gestion de Vente : Consiste à gérer toutes les processus de vente (lecture article
via son code barre, faire de remise, mode de règlement …)
 Gestion des Tickets : Consiste à gérer les tickets (annulation ticket, mettre un
ticket en attente …)
 Gestion de magasin : Consiste à gérer les caisses, les vendeurs, les clients.
 Gestion des Articles : Consiste à gérer les catégories, les sous catégories, les
familles, les types article, les couleurs et les tailles
 Consulter des statistiques : Consiste à consulter le tableau de bord, les états x
services, le meilleur vendeur, chiffre d’affaire pour une période de temps
 Gestion de sécurité : Attribution des droits d’accès (clés) aux vendeurs
I.3. Les besoins non fonctionnels :
Ces besoins sont les contraintes techniques exigées et les fonctionnalités nécessaires pour
rendre le logiciel plus performant et qui se résument généralement en :
 La simplicité : plus une application de gestion des points de ventes est simple dans
l’apprentissage et dans l’utilisation, plus ses fonctionnalités sont utilisées.
 L’accessibilité de l’application et la facilité d’administration : Une application de
gestion des points de ventes permet de gérer trois principales fonctions vitales
d’administration de magasin :
16
 La gestion du stock : répartir et organiser les articles dans des catégories,
sous-catégories, familles, types articles, marques.
 La gestion les éléments du magasin : qui permet la gestion des vendeurs, des
clés et des caisses.
 La gestion des statistiques, des rapports et des journaux : c’est à dire
fournisse des statistiques sur les ventes, des rapports services et des journaux de
tickets et de paiements.
 Le paramétrage et l’ergonomie : une application de gestion des points de ventes doit
avoir plusieurs fenêtres adaptables aux types d’utilisateurs. En effet, les interfaces,
les fonctionnalités et les profils doivent être modifiables et ajustables aux besoins.
 L’économie : il est important que l’application soit plus concurrent économiquement
de point de vue ressources utilisés (connexion à la base de données…).
 L’évolutivité : il est intéressant que l’application assure un pouvoir d’évolution, de
développement et d’amélioration au cours du temps et ce selon les besoins des
utilisateurs. Le code doit être clair pour permettre des futures évolutions.
 La sécurité : il est nécessaire que l’application gère :
 La confidentialité : l’information échangée entre deux correspondants ne peut
pas être consultée par un tiers
 L’authentification : les personnes utilisant une ressource correspondent aux
groupes d’utilisateurs.
 La disponibilité : les données ainsi que les ressources du système
d’information sont accessibles par ceux qui ont besoin à chaque fois qu’ils ont
l’utilité.
 L’intégrité : l’information n’est modifiée que par les personnes ayant le
droit et de façon volontaire.
 Le contrôle d’accès : une ressource n’est accessible que par les personnes
autorisées.
17
II. Planning du traitement des cas d’utilisation
Après tout le travail d’identification des cas d’utilisation, nous devons maintenant les
classifier. La classification des cas d’utilisation doit tenir compte de deux facteurs principaux
qui sont la priorité et les risques. Cette technique est utilisée généralement lors de la conception
des applications se basant sur le processus unifié, mais elle reste valable et intéressante pour
notre cas.
II.1. Priorités :
Généralement, nous disons qu’un cas d’utilisation A est plus prioritaire que B, si sa réalisation
accélère la stabilisation du système. Le choix des priorités dans cette section s’est basé sur la
dépendance entre les fonctionnalités de l’application. Par exemple, nous ne pouvons pas
affecter des remises sur des articles tant que nous n’avons pas encore terminé la gestion des
articles et celles des catégories. Par conséquent, nous pouvons dégager trois niveaux de priorité
qui sont: priorité haute, moyenne et faible.
III. Prototypage des interfaces :
Dans le domaine du web, une technique est apparue et prend une place très importante dans le
développement des applications Web; il s’agit du prototypage. Cette technique consiste à
préparer quelques interfaces graphiques de l’application en utilisant un outil de conception de
prototypes afin de mesurer le degré de satisfaction du client par rapport à la compréhension du
projet par le développeur. L’interaction qui se produit entre l’utilisateur final et le
développeur, à la suite de la discussion sur ces interfaces, permet d’ajuster les besoins et de les
concevoir de manière précise et exacte. En effet, les interfaces graphiques font que l’utilisateur
final soit plus interactif, précis et le poussent à mieux s’exprimer quant à ses attentes.
Quelques interfaces réalisées avec l’outil MokFlow4
sont illustrées par les figures : Figure 2.2,
Figure 2.3, Figure 2.4, Figure 2.5, Figure 2.5.
18
Figure 2.2 : Page d’authentification (BackOffice)
Figure 2.3 : Tableau de bord (BackOffice)
19
Figure 2.4 : Fenêtre principale (FrontOffice)
Figure 2.5 : Gestion des articles (BackOffice)
20
IV. Pilotage du projet avec Scrum :
Le cadre Scrum est constitué de trois éléments qui sont l’équipe avec des rôles bien définis, les
blocs de temps et les artefacts.
IV.I. Les outils Scrum :
Pour le pilotage de leurs projets Scrum, les membres de l’équipe font recours à plusieurs
techniques. Une de ces techniques, qui est la plus répondue, consiste à créer des fiches (post It)
et de les coller sur un mur ou sur un tableau visible pour tous les membres de l’équipe. Une
autre technique consiste à utiliser un fichier Excel contenant toutes les informations nécessaires
pour les sprints, les user story leurs estimations, etc. Ce fichier devra être partagé en lecture et
en écriture (pour que tous les membres de l’équipe puissent le modifier à tout moment).
Par conséquent, plusieurs outils sont apparus en offrant la possibilité de suivre la priorité, la
traçabilité et la gestion de tout le travail associé. Parmi les outils existants, nous avons choisi
d’utiliser iceScrum.
IV.2. Equipe et rôles :
«L’équipe a un rôle capital dans Scrum : elle est constituée avec le but d’optimiser la flexibilité et
la productivité; pour cela, elle s’organise elle-même et doit avoir toutes les compétences
nécessaires au développement du produit. Elle est investie avec le pouvoir et l’autorité pour faire
ce qu’elle a à faire ». [2] Bref, Scrum définit trois rôles qui sont:
 Le Product Owner(le propriétaire du produit) : c’est une personne qui porte la vision du
produit à réaliser, généralement c’est un expert dans le domaine.
 Le Scrum Master(le directeur de produit) : c’est la personne qui doit assurer le bon
déroulement des différents sprints du release, et qui doit impérativement maîtriser
Scrum.
 Le Scrum Team (l’équipe de Scrum) : constitué des personnes qui seront chargées
d’implémenter les différents besoins du client. Bien évidemment, cette équipe sera
constituée des développeurs, des infographistes, des testeurs, etc.
Dans le contexte de notre projet, Abderazek Chine sera à la fois le propriétaire et le directeur
de produit puisqu’il satisfait les différents prés requis de ces deux rôles et nous formons
21
nous-mêmes les deux membres de l’équipe Scrum (voir Figure 2.6).
Figure 2.6 : Equipe Scrum
IV.3. Le backlog du produit :
Le backlog du produit est l’artefact le plus important de Scrum, c’est l’ensemble des
caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité. Les
caractéristiques fonctionnelles sont appelées des histoires utilisateur (user story) et les
caractéristiques techniques sont appelées des histoires techniques (technical story).
Le Tableau 2.1 résume le backlog produit de notre application. Il est à noter que nous n’avons
pas cité les histoires techniques comme la préparation de la maquette graphique, les travaux de
conception et les jeux de tests, etc. Dans ce tableau chaque histoire utilisateur est caractérisée
par un rang déduit à partir de ses risques et sa priorité expliqués dans la section il de ce même
chapitre. Pour le traitement de nos histoires utilisateur nous choisissons de commencer avec les
cas d’utilisation les plus prioritaires et ayant le risque le moins élevé,
En plus du rang, chaque histoire utilisateur possède un effort (vélocité) qui est l’estimation
initiale sur la quantité de travail nécessaire pour implémenter cette exigence. Cet effort est
calculé en point d’histoire qui correspond aux jours hommes idéaux. Généralement, un point
d’histoire vaut un jour/homme.
Tableau 2.1 : Backlog de produit
22
Nom Effort Rang Description Thème Risque Priorité
Ajouter un
article
1 30 En tant qu’administrateur
je peux ajouter un article
afin de renforcer mes
ventes
Gestion
des articles
Faible Élevé
Mettre à jour les
articles
1 31 En tant qu’administrateur
je peux mettre à jour un
article afin de garder
l’intégrité de mes
données
Gestion
des articles
Faible Élevé
Ajouter un
administrateur
2 2 En tant qu’administrateur
je peux ajouter un admin
afin de renforcer mes
ressources humaines du
point de vente
Gestion
des
utilisateurs
Faible Moyen
Mettre à jour un
administrateur
2 3 En tant qu’administrateur
je peux mettre à jour un
admin afin de garder
l’intégrité de mes
données
Gestion
des
utilisateurs
Faible Moyen
Ajouter une
catégorie
1 8 En tant qu’administrateur
je peux ajouter une
catégorie afin d’organiser
mes articles
Gestion
des
catégories
Faible Élevé
Mettre à jour
une catégorie
1 9 En tant qu’administrateur
je peux mettre à jour une
catégorie afin de garder
l’intégrité de mes
données
Gestion
des
catégories
Faible Élevé
23
Nom Effort Rang Description Théme Risque Priorité
Ajouter un
vendeur
1 5 En tant qu’administrateur
je peux ajouter un
vendeur afin de renforcer
les ressources humaines
du point de vente
Gestion
des
vendeurs
Faible Élevé
Mettre à jour un
vendeur
2 6 En tant qu’administrateur
je peux mettre à jour un
vendeur afin de garder
l’intégrité de mes
données
Gestion
des
vendeurs
Faible Élevé
Ajouter une
caisse
1 17 En tant qu’administrateur
je peux ajouter une caisse
afin de renforcer les
ressources matérielles de
point de vente
Gestion
des caisses
Faible Élevé
Mettre à jour
une caisse
2 18 En tant qu’administrateur
je peux mettre à jour une
caisse afin de garder
l’intégrité de mes
données
Gestion
des caisses
Faible Élevé
Ajouter un
client
1 11 En tant qu’administrateur
je peux ajouter un client
afin de contrôler les
achats et les points de
fidélités
Gestion
des clients
Moyen Élevé
Mettre à jour un
client
2 12 En tant qu’administrateur
je peux mettre à jour une
caisse afin de garder
l’intégrité de mes données
Gestion
des clients
Moyen Élevé
24
Nom Effort Rang Description Théme Risque Priorité
Ajouter une
famille
1 14 En tant qu’administrateur
je peux ajouter une
famille afin d’organiser
mes articles
Gestion
des
familles
Faible Élevé
Mettre à jour
une famille
2 15 En tant qu’administrateur
je peux mettre à jour une
famille afin de garder
l’intégrité de mes
données
Gestion
des
familles
Faible Élevé
Authentification 3 1 En tant qu’administrateur
je peux faire une
authentification afin
d’accéder à mon espace
de travail
-------- Faible Faible
Lister les
articles
2 32 En tant qu’administrateur
je peux lister les articles
afin de sélectionner un
article
Gestion
des articles
Faible Élevé
Consulter
tableau de bord
3 21 En tant qu’administrateur
je peux consulter le
tableau de bord afin
d’assurer une meilleur
gestion des ressources
Statistique
et états
Moyen Faible
Annuler un
ticket
2 22 En tant qu’administrateur
je peux annuler un ticket
afin de prendre le
contrôle sur les tickets
Faire des
traitements
Moyen Faible
25
IV.4. Diagramme des cas d’utilisation global :
Dans cette section nous présentons les besoins de notre système de manière formelle. C’est à
dire nous utilisons le diagramme des cas d’utilisation du langage de modélisation UML.
Dans la Figure 13, tous les cas d’utilisation nécessitent une authentification préalable.
Figure 2.7 : Diagramme des cas d’utilisation global
26
IV.5. Architecture logique :
Avant de se lancer dans la conception et le développement de tout système informatisé, il est
important de préparer l’architecture de ce dernier. Le terme architecture est vaste puisqu’il y
peut désigner : Architecture logique, l’architecture physique, architecture logicielle, etc. Dans
ce paragraphe nous nous intéressons à l’architecture logique traduite par le diagramme de
package en terme d’UML qui est illustré par la figure 2.8.
Figure 2.8 : Diagramme de package
IV .6. Planification des sprints
La réunion de planification des sprints est l’événement le plus important dans Scrum. Le but
de cette réunion est de préparer le planning de travail et d’identifier le backlog des Sprints[7]
L’un des produits de cette réunion est le choix de la durée des sprints et qui diffère selon la
complexité du projet et la taille de l’équipe. Pour notre projet nous avons choisi de développer
trois releases :
27
 Le premier sprint sera nommé gestion des articles (catégorie, sous catégorie, famille,
marque, couleur, taille).
 Le second sprint sera pour la gestion de magasin (vendeur, caisse, client ...) et pour faire
des traitements (clôturer caisse, annuler ticket, consulter états stock ...),
 Le troisième sera intitulé administration (groupe, utilisateur, droit d’accès ...) et états et
statistique (tableau de bord, recap de vente, journal de ticket annulé ...),
Pour notre cas la durée de 20 jours pour un sprint semble adéquate.
La Figure 14 résume notre planning de travail.
Figure 2.9 : Plan de release
28
Conclusion :
Dans ce chapitre nous avons préparé notre plan de travail. Nous avons capturé les besoins
fonctionnels de notre application, les rôles des utilisateurs, par la suite nous avons préparé
l’architecture logique ainsi que le plan de release de notre projet.
29
Chapitre 3. Release 1-
Gestion Des Articles
Introduction :
Le terme release peut être défini comme une version distribuée d’une application ou une
période de temps qui permet de la produire. Peu importe quelle définition nous utilisons, une
release est constituée d’une suite d’itérations (sprint) qui se terminent quand les incréments de
ces derniers construisent un produit présentant suffisamment de valeur aux utilisateurs finaux.
La durée des releases est définie par le Product Owner en collaboration avec son équipe
Scrum.
Notre premier release sera composé de deux sprints, chacun ayant une vélocité de 20 jours.
Tout au long de ce chapitre, nous allons traiter les histoires utilisateurs de nos sprints pour
produire un incrément potentiellement livrable.
I. Le premier sprint :
Le sprint est le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel un incrément du
produit sera réalisé. Tous les sprints d’une release ont une durée constante et ne se
chevauchent jamais, c’est-à-dire qu’un sprint ne peut pas démarrer tant que le précédent n’est
pas encore terminé.
Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but de ce
dernier. Ce but doit être défini en terme métier et non pas en terme technique pour qu’il soit
compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une question
fondamentale «pourquoi faisons-nous ce sprint?». Suite à une conversation entre le Product
Owner et l’équipe Scrum, nous avons décidé le but suivant: «terminer la partie qui concerne la
gestion des articles du point de vente».
30
Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires
inclure dans ce dernier. Plus précisément, quelles histoires de notre backlog du produit seront
incluses dans le backlog du sprint.
Le Tableau 2 résume donc le backlog de notre premier sprint:
Tableau 3.1 : Backlog de premier sprint (release 1)
Passons maintenant au vif de notre sujet : Les activités et le cycle de développement. Dans un
sprint nous pouvons dégager quatre activités principales qui sont la spécification fonctionnelle,
la conception, le codage et le test. Tout au long de ce sprint, nous respectons ces activités pour
construire le plan de notre travail.
I.1. Spécification fonctionnelle :
La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas d’utilisation
d’UML et la description textuelle de ces derniers.
I.1.1. Diagramme des cas d’utilisation :
Dans la Figure 3.1 nous illustrons le diagramme des cas d’utilisation globaux pour ce premier
sprint
Histoire utilisateur Estimation
Lister les types des articles 2
Ajouter un type d’article 2
Modifier un type d’article 1
Lister les familles 1
Ajouter une famille 2
Modifier une famille 2
Lister les catégories 2
Ajouter un catégorie 2
Modifier un catégorie 2
Lister les sous catégorie 1
Ajouter un sous catégorie 1
Modifier un sous catégorie 2
31
Figure 3.1 : Diagramme des cas d’utilisation de premier sprint (release 1)
Dans ce diagramme, certains cas d’utilisation à l’instar « chercher une famille », « chercher une
catégorie », etc. ne figurent pas dans le backlog de notre sprint pour une simple raison, avec
Scrum, une des pratiques intéressante consiste à découper une histoire en un ensemble de
tâches. La différence entre une histoire et une tâche c’est que l’histoire est sous-produit livrable
qui intéresse le directeur de produit. La figure 3.2 illustre un exemple :
Lister les catégories
32
Figure 3.2 : Exemple d’une histoire utilisateur
I.1.2. Description textuelle des cas d’utilisation :
Pour rendre notre diagramme des cas d’utilisation plus lisible et afin de décrire le
comportement de notre système, nous présentons la description textuelle des principaux cas
d’utilisation.
A. Cas d’utilisation : Gestion des types articles
 Description textuelle du cas d’utilisation « consulter la liste des types article »
(voir tableau 3.2)
Tableau 3.2 : Description textuelle du cas d’utilisation «consulter la liste des types articles»
Cas d’utilisation Consulter la liste des types articles
Acteurs Administrateur, Agent comptable, Vendeur
Pré - condition Une authentification préalable
Post - condition La liste des types article est affichée sur l’écran
Scénario nominal 1-l’acteur demande l’affichage de la liste des
types articles
2-le système affiche la liste des types articles
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de type
« aucun résultat trouvé »
 Description textuelle du cas d’utilisation « chercher un type article » (voir
tableau 3.3)
33
Tableau 3.3 : Description textuelle du cas d’utilisation «chercher un type article»
B. Cas d’utilisation : Gestion des Familles
 Description textuelle du cas d’utilisation « ajouter une famille » (voir Tableau
3.4)
Tableau 3.4 : Description textuelle du cas d’utilisation «ajouter une famille»
Cas d’utilisation Ajouter une famille
Acteurs Administrateur
Pré-condition Une authentification préalable
Formulaire d’ajout disponible
Post-condition La liste des familles est affichée sur l’écran
Scénario nominal 1-l’administrateur demande le formulaire
d’ajout
2-le système affiche les formulaires
3-l’administrateur rempli les champs
nécessaire et valide
Cas d’utilisation Chercher un type article
Acteurs Administrateur, Agent comptable, Vendeur
Pré - condition Une authentification préalable
Formulaire de recherche disponible
Post-condition La liste des types articles est affichée sur l’écran
Scénario nominal 1-l’acteur saisi les critères de recherche
2-le système cherche les types article aux critère
répondant aux critères mentionnés
3-le système affiche la liste des types articles
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de type «
aucun résultat correspondant à vos critères,
essayer de nouveau »
2-a-2-reprise de l’étape 1 du scénario nominal
34
4-le système enregistre la nouvelle famille et
affiche un message de succès
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de type
« aucun résultat trouvé »
4-a-l’administrateur saisie des données
manquantes
4-a-1- le système affiche un message d’erreur
4-a-2-reprise de l’étape 1 du scénario
nominal
4-b-la famille existe déjà
4-b-1-le système demande à l’administrateur
de Modifier les données saisies
4-b-2-reprise de l’étape 3 du scénario
nominal
C. Cas d’utilisation : Gestion des catégories
 Description textuelle du cas d’utilisation «supprimer une catégorie» (voir
Tableau 3.5)
Tableau 3.5 : Description textuelle du cas d’utilisation «supprimer une catégorie»
Cas d’utilisation Supprimer une catégorie
Acteurs Administrateur
Pré - condition Une authentification préalable
La catégorie existant
Post - condition La liste des catégories est affichée sur l’écran
Scénario nominal 1-l’administrateur choisi la catégorie à
supprimer
2- le système affiche un message de
confirmation
3-l’administrateur valide son choix
35
4-le système supprime la catégorie
5-le système affiche un message de succès
Scénario alternatif 3-a-l’administrateur annule son choix
3-a-1-le système annule la suppression
C. Cas d’utilisation : Gestion des sous catégories
 Description textuelle du cas d’utilisation «modifier un sous catégories » (voir le
Tableau 3.6)
Tableau 3.6 : Description textuelle du cas d’utilisation «modifier un sous catégorie»
Cas d’utilisation Modifier un sous catégorie
Acteurs Administrateur
Pré-condition Une authentification préalable
Le sous catégorie existant
Post-condition Les informations ont bien été mises à jour
Scénario nominal 1-l’administrateur choisi le sous catégorie à
modifier
2-le système affiche le formulaire de
modification
3-l’administrateur modifie les informations et
valide
4-le système vérifie les données saisies
5-le système enregistre les données et affiche
un message de succès
Scénario alternatif 4-a-l’administrateur saisie des données
manquantes
4-a-1-le système affiche un message
d’erreur
4-a-2-reprise de l’étape 3 du scénario
nominal
4-b- le libellé de sous catégorie existe déjà
4-b-1-le système demande à
l’administrateur de modifier les données
saisies
36
4-b-2-reprise de l’étape 3 du scénario
nominal
I.2. Conception :
La conception est la deuxième activité dans un sprint. Elle se traduit par le diagramme de classe
et le diagramme de séquence d’UML.
1.2.1. Diagramme de séquence système
Pour schématiser la vue comportementale de notre système informatique, nous faisons recours
au diagramme de séquence d’UML. Ce diagramme permet de présenter les interactions entre
l’acteur et le système avec des messages présentés dans un ordre chronologique .Le digramme
de séquence système traite le système informatique comme étant une boite noire. Le
comportement du système est décrit vu de l’extérieur sans avoir d’idée sur comment il le
réalisera.
En nous référant aux descriptions textuelles dans la section précédente, nous présentons les
diagrammes de séquences systèmes adéquats. Sur la base de ces descriptions, nous pouvons
constater que certains cas d’utilisations sont similaires à l’instar de la consultation des types
articles, la consultation des familles, etc. c’est pour cette raison que nous avons choisi de
sélectionner quelques exemples pour les traiter.
A. Diagramme de séquence système du cas d’utilisation « consulter la liste des catégorie»
Le cas d’utilisation consulter la liste des catégorie est similaire au cas d’utilisation suivant :
consulter la liste des familles, consulter la liste des sous catégorie, consulter la liste des types
articles.
La figure 3.3 illustre le diagramme de séquence «consulter la liste des catégorie»
37
Figure 3.3 : Diagramme de séquence «consulter la liste des sous catégorie»
B. Diagramme de séquence système du cas d’utilisation « chercher une famille»
Pour chercher une famille, l’administrateur doit s’authentifier dans un premier lieu en utilisant
son login et son mot de passe. Par la suite, il choisit les critères de recherche correspondant à
ces besoins (voir figure 3.4).
38
Figure 3.4 : Diagramme de séquence «chercher une famille»
1.2.2. Le diagramme des classes :
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. (Voir
Figure 3.5)
39
Figure 3.5 : Diagramme de classe du premier sprint (release 1)
I.3. Codage :
Les travaux menés dans cette activité se résument tout simplement dans l’implémentation et la
réalisation des histoires utilisateurs analysés lors des étapes précédentes. Pour notre cas, nous
nous intéresserons seulement au schéma de la base de données.
Pour construire le schéma de base de données de notre application, nous devons appliquer
certaines règles pour passer vers un schéma relationnel. Ces règles sont bien définies dans
l’annexe A.
Dans ce qui suit, nous présentons les tables de notre base de données (voir Tableau 3.7,
Tableau 3.8 Tableau 3.9 et le Tableau 3.10) tout en tenant compte du type et des contraintes de
leurs champs.
40
Champs Types Contraintes
TA_CODE VARCHAR(20) PRIMARY KEY
TA_LIBELLE VARCHAR(20) ---
TA_IMP VARCHAR(20) ---
Tableau 3.7 : Table «Type_Article»
Champs Types Contraintes
CAT_CODE VARCHAR(20) PRIMARY KEY
CAT_LIBELLE VARCHAR(20) ---
Tableau 3.8 : Table «Catégorie»
Champs Types Contraintes
SCAT_CODE VARCHAR(20) PRIMARY KEY
CAT_CODE VARCHAR(20) PRIMARY KEY
SCAT_LIBELLE VARCHAR(20) NOT NULL
Tableau 3.9 : Table «Sous_Catégorie»
Champs Types Contraintes
FAM_CODE VARCHAR(20) PRIMARY KEY
FAM_LIBELLE VARCHAR(20) ---
Tableau 3.10 : Table «Famille»
41
I.4. Test :
Les activités de test constituent un axe très important dans le cycle de développement d’un
logiciel. Ils permettent de détecter les erreurs afin de les corriger et d’assurer la qualité du
logiciel fourni.
Contrairement aux cycles de développement séquentiel, avec la méthodologie agile, le test
n’est pas une phase qui se déroule après la fin de développement. En effet, les tests seront
intégrés dès le début du premier sprint jusqu’à la livraison du produit final. En outre, la qualité du
logiciel n’est pas négligeable, c’est dans ce cadre que Scrum doit être complété par les bonnes
pratiques d’ingénierie techniques du logiciel. Parmi ces pratiques, les tests unitaires.
1.4.1. Les tests unitaires
Le principe de cette pratique est d’écrire les tests avant même d’écrire le code et de profiter par
la suite de l’existence des tests automatiques pour l’amélioration et le remaniement du code.
Cette technique permet aux programmeurs de rester simples au niveau du code et de s’assurer
de son bon fonctionnement après des changements.
Dans ce paragraphe, nous avons choisi de tester deux histoires utilisateurs qui sont: l’ajout
d’une catégorie et la suppression d’une famille. Pour la création des tests unitaires de ces
histoires, nous avons eu recours à la bibliothèque JUnit.
 Test unitaire pour l’histoire «supprimer une famille»
Pour tester la suppression d’une famille, nous avons choisi de suivre la démarche suivante :
1. Compter le nombre de familles existantes et vérifier que c’est égal à 3
2. Supprimer une famille
3. Compter de nouveau le nombre de famille et vérifier que c’est égal à 2
La première capture écran (Figure 3.6) illustre le code de la classe de test.
42
Figure 3.6 : Code source de la classe de test pour l’histoire «supprimer une famille»
La deuxième capture écran (Figure 3.7) illustre le cas de succès de notre test. Cette figure nous
montre que notre méthode est bien fonctionnelle.
Figure 3.7 : Cas de succès pour la suppression d’une famille
43
La dernière capture écran (Figure 3.8) illustre le cas d’échec. Dans cette figure l’oracle13
était 2
lors que la méthode nous renvoie 3.
Figure 3.8 : Cas d’échec pour la suppression d’une famille
II. Le deuxième sprint
En partant sur le même principe que le sprint précédent, nous commençons par définir le but de
notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum, nous
avons décidé le but suivant: « terminer la partie qui concerne la gestion des articles de point de
vente ». Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles
histoires inclure dans ce dernier.
Le Tableau 3.11 résume donc le backlog de notre second sprint :
44
Tableau 3.11 : Backlog de second sprint (release 1)
Dans le Tableau 3.11, nous pouvons constater que les histoires utilisateur «lister les couleur »,
«ajouter un couleur» et « modifier une marque » ne figurent pas dans le backlog de produit. En
effet, notre backlog de produit initial ne couvre pas toutes les fonctionnalités requises et c’est
pour cette raison que nous aurons des nouvelles fonctionnalités au fur et mesure de notre
avancement. En plus, nous pouvons constater que les vélocités de nos histoires ont changé par
rapport à l’estimation initiale tout en gardant la même durée que le sprint précédent.
II.1. Spécification fonctionnelle :
Pour la spécification fonctionnelle de ce sprint, nous commençons par le diagramme des cas
d’utilisation.
II.1.1. Diagramme des cas d’utilisation
Dans la Figure 3.9 nous illustrons le diagramme des cas d’utilisation global pour ce second
sprint. En respectant toujours le même principe que le sprint précédent, nous avons découpé
certaines histoires utilisateurs en un ensemble de tâches.
Histoire utilisateur Estimation
Lister les articles 1
Ajouter un article 2
Modifier un article 1
Lister les couleurs 1
Ajouter un couleur 1
Modifier un couleur 2
Lister les marques 1
Ajouter une marque 2
Modifier une marque 2
Lister les tailles 2
Ajouter une taille 2
Modifier une taille 3
45
Figure 3.9 : Diagramme des cas d’utilisation du second sprint (release 1)
II.1.2. Description textuelle des cas d’utilisation
Nous allons maintenant décrire chacun des cas d’utilisation énuméré dans le paragraphe
précédent en identifiants les acteurs et les différents scénarios possible.
A. Cas d’utilisation : Gestion des articles
 Description textuelle du cas d’utilisation« Ajouter un article » (voir Tableau 3.12)
Tableau 3.12 : Description textuelle du cas d’utilisation «ajouter un article»
Cas d’utilisation Ajouter un article
Acteurs Administrateur
Pré-condition Une authentification préalable
Formulaire d’ajout disponible
Post-condition La liste des articles est affichée sur l’écran
Scénario nominal 1-l’administrateur demande le formulaire
d’ajout
46
2-le système affiche les formulaires
3-l’administrateur rempli les champs
nécessaire et valide
4-le système enregistre le nouvel article et
affiche un message de succès
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de type
« aucun résultat trouvé »
4-a-l’administrateur saisie des données
manquantes
4-a-1- le système affiche un message d’erreur
4-a-2-reprise de l’étape 1 du scénario
nominal
4-b-l’article existe déjà
4-b-1-le système demande à l’administrateur
de Modifier les données saisies
4-b-2-reprise de l’étape 3 du scénario
nominal
B. Cas d’utilisation : Gestion des Tailles
 Description textuelle du cas d’utilisation «supprimer une taille » (voir Tableau 3.13)
Tableau 3.13 : Description textuelle du cas d’utilisation «supprimer une taille»
Cas d’utilisation Supprimer une taille
Acteurs Administrateur
Pré - condition Une authentification préalable
La taille existant
Post - condition La liste des tailles est affichée sur l’écran
Scénario nominal 1-l’administrateur choisi la taille à supprimer
2- le système affiche un message de
47
confirmation
3-l’administrateur valide son choix
4-le système supprime la taille
5-le système affiche un message de succès
Scénario alternatif 3-a-l’administrateur annule son choix
3-a-1-le système annule la suppression
C. Cas d’utilisation : Gestion des marques
 Description textuelle du cas d’utilisation «modifier une marque» (voir le
Tableau 3.14)
Tableau 3.14 : Description textuelle du cas d’utilisation «modifier une marque»
Cas d’utilisation Modifier une marque
Acteurs Administrateur
Pré-condition Une authentification préalable
La marque existant
Post-condition Les informations ont bien été mises à jour
Scénario nominal 1-l’administrateur choisi la marque à modifier
2-le système affiche le formulaire de
modification
3-l’administrateur modifie les informations et
valide
4-le système vérifie les données saisies
5-le système enregistre les données et affiche
un message de succès
Scénario alternatif 4-a-l’administrateur saisie des données
manquantes
4-a-1-le système affiche un message
d’erreur
4-a-2-reprise de l’étape 3 du scénario
nominal
48
4-b- le libellé d’une marque existe déjà
4-b-1-le système demande à
l’administrateur de modifier les données
saisies
4-b-2-reprise de l’étape 3 du scénario
nominal
C. Cas d’utilisation : Gestion des Couleurs
 Description textuelle du cas d’utilisation «chercher un couleur » (voir Tableau 3.15)
Tableau 3.15 : Description textuelle du cas d’utilisation «chercher un couleur»
Cas d’utilisation Chercher un couleur
Acteurs Administrateur, Agent comptable, Vendeur
Pré-condition Une authentification préalable
Formulaire de recherche disponible
Post-condition La liste des couleurs est affichée sur l’écran
Scénario nominal 1-l’acteur saisi les critères de recherche
2-le système cherche les couleurs répondants
aux critères mentionnés
3-le système affiche la liste des couleurs
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de
type « aucun résultat correspondant à vos
critères, essayer de nouveau »
2-a-2-reprise de l’étape 1 du scénario
nominal
II.2. Conception
A ce niveau, nous commençons par le diagramme de séquence système des différents cas
d’utilisation déjà détaillés dans la section précédente.
49
II.2.1. Diagramme de séquence système
En nous référant aux descriptions textuelles dans la section précédente, nous présentons les
diagrammes de séquences systèmes adéquats. Sur la base de ces descriptions, nous pouvons
constater que certains cas d’utilisations sont similaires à l’instar de la consultation des couleurs,
la consultation des taille, etc. c’est pour cette raison que nous avons choisir de sélectionner
quelques exemples.
A. Diagramme de séquence système du cas d’utilisation «consulter la liste des
articles»
Le cas d’utilisation consulter la liste des articles (voir figure 3.10) est similaire au cas
d’utilisation suivant: consulter la liste des couleurs, consulter la liste des taille, consulter la liste
des marques.
Figure 3.10 : Diagramme de séquence système du cas d’utilisation «consulter la liste des articles»
B. Diagramme de séquence système du cas d’utilisation « ajouter un article» :
L’ajout d’un article (voir Figure 3.11) est similaire au cas d’utilisation suivant: ajouter un
couleur, ajouter une marque et ajouter une taille.
50
Figure 3.11 : Diagramme de séquence système du cas d’utilisation «ajouter un article»
51
II.2.2. Diagramme des classes
Après tout le travail de spécification et de conception, nous pouvons maintenant construire le
nouvel incrément de notre diagramme des classes en ajoutant les différents éléments (classes,
associations, attributs, etc.) déduits à partir des activités précédentes (voir figure 3.12)
Figure 3.12 : Diagramme des classe du second sprint (release 1)
II.3.Codage
Après avoir construit le nouveau diagramme de classe pour ce sprint et en appliquant les règles
de passage vers le schéma logique de l’application, nous obtenons le schéma de la base de
données illustré par les Tableaux (Tableau 3.16, Tableau 3.17, Tableau 3.18, Tableau 3.19)
52
Champs Types Contraintes
ART_CODE VARCHAR(20) PRIMARY KEY
ART_LIBELLE VARCHAR(20) ---
ART_BARRE VARCHAR(20) ---
CAT_CODE VARCHAR(20) NOT NUL
SCAT_CODE VARCHAR(20) FOREIGN KEY
FAM_CODE VARCHAR(20) FOREIGN KEY
TAILLE_CODE VARCHAR(20) FOREIGN KEY
MARQ_CODE VARCHAR(20) FOREIGN KEY
STK_ALRT NUMBER(10) ---
Tableau 3.16 : Table «Article»
Champs Types Contraintes
TA_CODE VARCHAR(20) PRIMARY KEY
TA_LIBELLE VARCHAR(20) ---
Tableau 3.17 : Table «Taille»
Champs Types Contraintes
COU_CODE VARCHAR(20) PRIMARY KEY
COU_LIBELLE VARCHAR(20) UNIQUE
Tableau 3.18 : Table «Couleur»
Champs Types Contraintes
MRQ_CODE VARCHAR(20) PRIMARY KEY
MRQ_LIBELLE VARCHAR(20) UNIQUE
Tableau 3.19 : Table «Marque»
53
II.4. Test :
En partant toujours du même principe que le sprint précédent, et en appliquant les bonnes
pratiques d'ingénierie logicielle inspirée de la méthodologie extrême programming (XP), nous
commençons par les tests unitaires de l'histoire utilisateur « ajouter un article »
II.4.1. Tests unitaires :
Dans ce paragraphe, nous testons toujours nos histoires utilisateur en utilisant la bibliothèque
JUnit.
 Test unitaire pur l’histoire « ajouter un article»
Pour tester l’ajout d’un article, nous avons choisi de respecter la démarche suivante :
1. Ajouter un article
2. Récupérer le dernier article ajouté
3. Comparer les attributs de l’article ajouté et celles de l’article récupéré.
La première capture écran (Figure 3.13) illustre le code source de la classe de test.
Figure 3.13 : Code source de la classe de test pour l’histoire «ajouter un article»
54
La figure 3.14 illustre le cas de succès pour l’ajout d’un nouvel article .Cette figure nous montre
que notre méthode est bien fonctionnelle.
Figure 3.14 : Cas du succès de la classe de test pour l’histoire «ajouter un article»
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 et pourra être utilisé dans un environnement de production.
Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau release
couvrant les fonctionnalités de gestion de magasin et de faire des traitements .
55
Chapitre 4. Release 2 -
Gestion de magasin
&
Faire des traitements
Introduction
Après avoir entamé le premier release de notre système informatique, nous pouvons
maintenant nous lancer dans les travaux nécessaires pour produire le second release. En effet
les méthodologies agiles, et Scrum en particulier, sont caractérisées par un rythme régulier.
Tout au long de chapitre nous aurons deux sprints ayant la même vélocité que les sprints
précédents, et nous allons traiter les histoires utilisateurs de ces derniers pour avoir à la fin de ce
release une partie de logiciel, livrable et fonctionnel.
I. Le premier sprint :
En partant sur le même principe que les sprints précédents, nous commençons par définir le but
de notre premier sprint pour ce release. Suite à une conversation entre le Product Owner et
l’équipe Scrum, nous avons décidé le but suivant: « terminer la partie qui concerne la gestion de
magasin. Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles
histoires inclure dans ce dernier.
Le Tableau 4.1 résume donc le backlog de notre second sprint:
Tableau 4.1 : Backlog du premier sprint (release 2)
Histoire utilisateur Estimation
Lister les vendeurs 1
Ajouter un vendeur 2
Modifier un vendeur 3
56
Lister les caisses 2
Ajouter une caisse 2
Modifier une caisse 3
Lister les clients 2
Ajouter un client 3
Modifier un client 2
Dans le Tableau 4.1, nous pouvons constater que les histoires utilisateur «supprimer un
vendeur», «chercher une caisse» et « modifier un client » ne figurent pas dans le backlog de
produit. En effet, notre backlog de produit initial ne couvre pas toutes les fonctionnalités
requises et c’est pour cette raison que nous aurons des nouvelles fonctionnalités au fur et
mesure de notre avancement. En plus, nous pouvons constater que les vélocités de nos histoires
ont changé par rapport à l’estimation initiale tout en gardant la même durée que le sprint
précédent.
I.1. Spécification fonctionnelle :
La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas d’utilisation
d’UML et la description textuelle de ces derniers.
I.1.1. Diagramme des cas d’utilisation
Dans la Figure 4.1 nous illustrons le diagramme des cas d’utilisation global pour ce second
sprint. En respectant toujours le même principe que le sprint précédent, nous avons découpé
certaines histoires utilisateurs en un ensemble de tâches.
57
Figure 4.1 : Diagramme des cas d’utilisation du premier sprint (release 2)
I.1.2. Description textuelle des cas d’utilisation :
Pour rendre notre diagramme des cas d’utilisation plus lisible et afin de décrire le
comportement de notre système, nous présentons la description textuelle des principaux cas
d’utilisation.
A. Cas d’utilisation : Gestion des vendeurs
 Description textuelle du cas d’utilisation « consulter la liste des vendeurs»
(voir tableau 4.2)
58
Tableau 4.2 : Description textuelle du cas d’utilisation «consulter la liste des vendeurs»
Cas d’utilisation Consulter la liste des vendeurs
Acteurs Administrateur, Agent comptable, Vendeur
Pré - condition Une authentification préalable
Post - condition La liste des vendeurs est affichée sur l’écran
Scénario nominal 1-l’acteur demande l’affichage de la liste des
vendeurs
2-le système affiche la liste des vendeurs
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de type
« aucun résultat trouvé »
B. Cas d’utilisation : Gestion des Caisses
 Description textuelle du cas d’utilisation « supprimer une caisse » (voir
Tableau 4.3)
Tableau 4.3 : Description textuelle du cas d’utilisation «supprimer une caisse»
Cas d’utilisation Supprimer une caisse
Acteurs Administrateur
Pré - condition Une authentification préalable
La caisse existant
Post - condition La liste des caisse est affichée sur l’écran
Scénario nominal 1-l’administrateur choisi la caisse à supprimer
2- le système affiche un message de
confirmation
3-l’administrateur valide son choix
4-le système supprime la caisse
5-le système affiche un message de succès
Scénario alternatif 3-a-l’administrateur annule son choix
3-a-1-le système annule la suppression
59
C. Cas d’utilisation : Gestion des Clients
 Description textuelle du cas d’utilisation « ajouter un client»(voir Tableau 4.4)
Tableau 4.4 : Description textuelle du cas d’utilisation «ajouter un client»
Cas d’utilisation Ajouter un client
Acteurs Administrateur
Pré-condition Une authentification préalable
Formulaire d’ajout disponible
Post-condition La liste des clients est affichée sur l’écran
Scénario nominal 1-l’administrateur demande le formulaire
d’ajout
2-le système affiche les formulaires
3-l’administrateur rempli les champs
nécessaire et valide
4-le système enregistre le nouveau client et
affiche un message de succès
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de type
« aucun résultat trouvé »
4-a-l’administrateur saisie des données
manquantes
4-a-1- le système affiche un message d’erreur
4-a-2-reprise de l’étape 1 du scénario
nominal
4-b- le client existe déjà
4-b-1-le système demande à l’administrateur
de Modifier les données saisies
4-b-2-reprise de l’étape 3 du scénario
nominal
60
I.2. Conception :
Dans cette section nous commençons par le diagramme de séquence système des différents cas
d’utilisation déjà détaillés dans la section précédente.
I.2.1. Diagramme de séquence système
En nous référant aux descriptions textuelles dans la section précédente, nous présentons les
diagrammes de séquences systèmes adéquats. Sur la base de ces descriptions, nous pouvons
constater que certains cas d’utilisations sont similaires à l’instar de la consultation des
vendeurs, la consultation des caisses, etc. c’est pour cette raison que nous avons choisir de
sélectionner quelques exemples.
A. Diagramme de séquence système du cas d’utilisation « supprimer une
caisse»
Le cas d’utilisation supprimer une caisse est similaire au cas d’utilisation supprimer un vendeur.
(Voir Figure 4.2)
Figure 4.2 : Diagramme de séquence «supprimer une caisse»
61
B. Diagramme de séquence système du cas d’utilisation « chercher un client»
Pour chercher un client, l’administrateur doit s’authentifier dans un premier lieu en utilisant son
login et son mot de passe. Par la suite, il choisit les critères de recherche correspondant à ces
besoins (voir figure 4.3).
Figure 4.3 : Diagramme de séquence «chercher un client»
I.2.2. Le diagramme des classes :
Après tous le travail de spécification et de conception, nous pouvons maintenant construire le
nouvel incrément de notre diagramme des classes en ajoutant les différents éléments (classes,
associations, attributs, etc.) déduits à partir des activités précédente. (voir Figure 4.4).
62
Figure 4.4 : Diagramme de classe du premier sprint (release 2)
I.3. Codage :
Après avoir construit le nouveau diagramme de classe pour ce sprint et en appliquant les règles
de passage vers le schéma logique de l’application, nous obtenons le schéma de la base de
données suivant (voir Tableau 4.5, Tableau 4.6, Tableau 4.7).
63
Champs Types Contraintes
VND_CODE VARCHAR(20) PRIMARY KEY
VND_NAME VARCHAR(20) ---
VND_QUALITE VARCHAR(20) ---
CODE_CLES VARCHAR(20) FOREIGN KEY
VND_EMAIL VARCHAR(20) UNIQUE
VND_CIN VARCHAR(20) NOT NULL
Tableau 4.5 : Table «Vendeur»
Champs Types Contraintes
CA_CODE VARCHAR(20) PRIMARY KEY
TA_LIBELLE VARCHAR(20) ---
CA_PRIX NUMBER(10) NOT_NULL
CA_TVA NUMBER(10)
Tableau 4.6 : Table «Caisse»
Champs Types Contraintes
CLT_CODE VARCHAR(20) PRIMARY KEY
CLT_NAME VARCHAR(20) NOT NULL
CLT_EMAIL VARCHAR(20) UNIQUE
CLT_CIN NOT NULL
Tableau 4.7 : Table «Client»
64
I.4. Test :
En partant toujours du même principe que les sprints précédents, et en appliquant les bonnes
pratiques d’ingénierie logicielle inspirée de la méthodologie extrême programming (XP), nous
commençons par les tests unitaires de l‘histoire utilisateur «modifier une caisse»
I.4.1. Test unitaire
Dans ce paragraphe, nous testons toujours nos histoires utilisateur en utilisant la bibliothèque
JUnit.
 Test unitaire pour l’histoire «modifier un vendeur»
Pour tester la modification d’une caisse, nous avons choisi de respecter la démarche suivante:
1. Modifier le vendeur
2. Récupérer le vendeur modifié
3. Vérifier que les champs ont bien été changés
La capture d’écran (Figure 4.5) suivante illustre le code source de notre classe de test
Figure 4.5 : Code source de la classe de test pour l’histoire «modifier un vendeur»
65
La capture écran suivante illustre le cas de succès pour la modification d’une caisse. La figure
(4.6) nous montre que notre méthode est bien fonctionnelle.
Figure 4.6 : Cas de succès pour la modification d’un vendeur
II. Le deuxième sprint :
En partant sur le même principe que les sprints précédents, nous commençons par définir le but
de notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum, nous
avons décidé le but suivant: « terminer la partie qui concerne Faire traitement ». Une fois, nous
avons défini le but de notre sprint, il est temps de décider quelles histoires inclure dans ce
dernier.
Le Tableau 4.8 résume donc le backlog de notre second sprint:
66
Tableau 4.8 : Backlog de second sprint (release 2)
II.1. Spécification fonctionnelle :
Pour la spécification fonctionnelle de ce sprint, nous commençons par le diagramme des cas
d’utilisation.
II.1.1. Diagramme des cas d’utilisation
Dans la Figure 4.7 nous illustrons le diagramme des cas d’utilisation global pour ce second
sprint. En respectant toujours le même principe que le sprint précédent, nous avons découpé
certaines histoires utilisateurs en un ensemble de tâches.
Figure 4.7 : Diagramme des cas d’utilisation du second sprint (release 2)
Histoire utilisateur Estimation
Lister les services 1
Modifier un service 2
Clôturer un service 2
Chercher un service 2
Lister les ticket 2
Modifier un ticket 3
Chercher un ticket 2
Annuler un ticket 3
Consulter état stock 2
67
II.1.2. Description textuelle des cas d’utilisation
Nous allons maintenant décrire chacun des cas d’utilisation énuméré dans le paragraphe
précédent en identifiants les acteurs et les différents scénarios possible.
A. Cas d’utilisation : Gestion des Tickets
 Description textuelle du cas d’utilisation« Annuler un ticket » (voir Tableau 4.9)
Tableau 4.9 : Description textuelle du cas d’utilisation «Annuler un ticket»
Cas d’utilisation Annuler un ticket
Acteurs Administrateur
Pré-condition Une authentification préalable
Formulaire de recherche disponible
Post-condition La liste des tickets est affichée sur l’écran
Scénario nominal 1-l’administrateur demande d’annuler un ou
plusieurs tickets(s).
2-le système affiche la liste complète de ticket
(par défaut de jour actuelle)
3-l’administrateur sélectionne les tickets et
valider.
4 – Le système annule les tickets et affiche un
message de réussite.
Scénario alternatif 2-a-aucun résultat
2-a-1- le système affiche un message de type
« aucun résultat trouvé »
4-a-l’administrateur saisie des données
manquantes
4-a-1- le système affiche un message d’erreur
4-a-2-reprise de l’étape 1 du scénario
nominal
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse
Front office back office caisse

Contenu connexe

Tendances

Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
Mohamed Boubaya
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIA
Ahmed BEN JEMIA
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
Anouar Kacem
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEOussama Djerba
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
Donia Hammami
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Raoua Bennasr
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
Yahyaoui Mohamed Yosri
 
Rapport PFE
Rapport PFERapport PFE
Rapport PFE
IbtissemSlimeni
 
Application mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme AndroidApplication mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme Android
Khaled Fayala
 
Rapport de sprint finale (All Project part)
Rapport de sprint finale (All Project part)Rapport de sprint finale (All Project part)
Rapport de sprint finale (All Project part)
Ghodbane Heni
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
Mohamed Aziz Chetoui
 
PFE::Conception et développement du Back Office d'une application mobile de g...
PFE::Conception et développement du Back Office d'une application mobile de g...PFE::Conception et développement du Back Office d'une application mobile de g...
PFE::Conception et développement du Back Office d'une application mobile de g...
Rami Raddaoui
 
Rapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueRapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc Informatique
Eric Maxime
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
Amine MEGDICHE
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Mohammed JAITI
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
Karim Ben Alaya
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
ALALSYSE
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
Madjid Meddah
 
Conception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRConception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIR
Skander Driss
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
Ayoub Mkharbach
 

Tendances (20)

Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...Conception et developpement d'un site web pour la suggestion et notification ...
Conception et developpement d'un site web pour la suggestion et notification ...
 
Rapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIARapport PFE Ahmed BEN JEMIA
Rapport PFE Ahmed BEN JEMIA
 
Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015Rapport de stage de fin d'études ISI 2015
Rapport de stage de fin d'études ISI 2015
 
Pfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEEPfe conception et développement d'une application web GMAO JEE
Pfe conception et développement d'une application web GMAO JEE
 
Rapport de projet de conception et de développement
Rapport de projet de conception et de développementRapport de projet de conception et de développement
Rapport de projet de conception et de développement
 
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
Rapport pfe Conceptionet Developpement d'une Application web et  Mobile Rapport pfe Conceptionet Developpement d'une Application web et  Mobile
Rapport pfe Conceptionet Developpement d'une Application web et Mobile
 
Rapport de stage du fin d'étude
Rapport de stage du fin d'étudeRapport de stage du fin d'étude
Rapport de stage du fin d'étude
 
Rapport PFE
Rapport PFERapport PFE
Rapport PFE
 
Application mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme AndroidApplication mobile bancaire sous la plateforme Android
Application mobile bancaire sous la plateforme Android
 
Rapport de sprint finale (All Project part)
Rapport de sprint finale (All Project part)Rapport de sprint finale (All Project part)
Rapport de sprint finale (All Project part)
 
Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...Conception et développement d'une application de gestion de production et de ...
Conception et développement d'une application de gestion de production et de ...
 
PFE::Conception et développement du Back Office d'une application mobile de g...
PFE::Conception et développement du Back Office d'une application mobile de g...PFE::Conception et développement du Back Office d'une application mobile de g...
PFE::Conception et développement du Back Office d'une application mobile de g...
 
Rapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc InformatiqueRapport PFE: Gestion de Parc Informatique
Rapport PFE: Gestion de Parc Informatique
 
Rapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework KinectRapport PFE réalisation d’un Framework Kinect
Rapport PFE réalisation d’un Framework Kinect
 
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti MohammedRapport de stage PFE ( DUT) chez Synthèse Conseil  - Jaiti Mohammed
Rapport de stage PFE ( DUT) chez Synthèse Conseil - Jaiti Mohammed
 
Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...Conception et développement d’une plateforme d'import-export avec paiement en...
Conception et développement d’une plateforme d'import-export avec paiement en...
 
Conception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-locationConception et developpement d'une application mobile Android e-location
Conception et developpement d'une application mobile Android e-location
 
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
CONCEPTION ET REALISATION D ’ UNE APPLICATION WEB POUR GESTION DE P ROJETS DE...
 
Conception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIRConception et développement d'une application Android pour TUNISAIR
Conception et développement d'une application Android pour TUNISAIR
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 

Similaire à Front office back office caisse

RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
TombariAhmed
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
MahmoudiOussama
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
MahmoudiOussama
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
Nader Somrani
 
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
Bader Nassiri
 
projet fin d'étude IWAN
projet fin d'étude IWANprojet fin d'étude IWAN
projet fin d'étude IWAN
Med Amine El Abed
 
Rapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdfRapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdf
RihabBenSalem5
 
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
ElAzzabAbdeSsamad
 
Rapport de stage: mastère ISIC (Business Intelligence)
Rapport de stage: mastère ISIC (Business Intelligence)Rapport de stage: mastère ISIC (Business Intelligence)
Rapport de stage: mastère ISIC (Business Intelligence)
Ines Ben Kahla
 
Rapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdfRapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdf
AhmedDhib6
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Ramzi Noumairi
 
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data WarehouseConception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data WarehouseAbderrahmane Filali
 
rapport final Conception d’un système d’aide à la décision aux compagne ma...
rapport final Conception d’un système d’aide à la décision aux compagne ma...rapport final Conception d’un système d’aide à la décision aux compagne ma...
rapport final Conception d’un système d’aide à la décision aux compagne ma...
HICHAMLATRECHE1
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
marwenbencheikhali
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etude
sihem-med
 
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Rim ENNOUR
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
Rouâa Ben Hammouda
 
La pratique de l'audit interne dans les entreprises d'assurances copie (2)
La pratique de l'audit interne dans les entreprises d'assurances   copie (2)La pratique de l'audit interne dans les entreprises d'assurances   copie (2)
La pratique de l'audit interne dans les entreprises d'assurances copie (2)dodoooooo
 
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Karima Torkhani
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
karimatorkhani
 

Similaire à Front office back office caisse (20)

RAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDESRAPPORT DE PROJET DE FIN D’ETUDES
RAPPORT DE PROJET DE FIN D’ETUDES
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
 
rapport-170608045227 (1).pdf
rapport-170608045227 (1).pdfrapport-170608045227 (1).pdf
rapport-170608045227 (1).pdf
 
Rapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobileRapport PFE Développent d'une application bancaire mobile
Rapport PFE Développent d'une application bancaire mobile
 
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
467720159-rapport-final-bouguerra-khadijaesseghaier-lina-pdf.pdf
 
projet fin d'étude IWAN
projet fin d'étude IWANprojet fin d'étude IWAN
projet fin d'étude IWAN
 
Rapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdfRapport_PFE_analyse_de_données_BI_2021.pdf
Rapport_PFE_analyse_de_données_BI_2021.pdf
 
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
392327755-Conception-Et-Realisation-d-Un-Site-Web-Et-Une-Application-Mobile-d...
 
Rapport de stage: mastère ISIC (Business Intelligence)
Rapport de stage: mastère ISIC (Business Intelligence)Rapport de stage: mastère ISIC (Business Intelligence)
Rapport de stage: mastère ISIC (Business Intelligence)
 
Rapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdfRapport_PFE_Securite (1).pdf
Rapport_PFE_Securite (1).pdf
 
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
Projet de fin étude  ( LFIG : Conception et Développement d'une application W...Projet de fin étude  ( LFIG : Conception et Développement d'une application W...
Projet de fin étude ( LFIG : Conception et Développement d'une application W...
 
Conception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data WarehouseConception et Réalisation d'un Data Warehouse
Conception et Réalisation d'un Data Warehouse
 
rapport final Conception d’un système d’aide à la décision aux compagne ma...
rapport final Conception d’un système d’aide à la décision aux compagne ma...rapport final Conception d’un système d’aide à la décision aux compagne ma...
rapport final Conception d’un système d’aide à la décision aux compagne ma...
 
Rapport finiale
Rapport finialeRapport finiale
Rapport finiale
 
rapport fin d'etude
rapport fin d'etuderapport fin d'etude
rapport fin d'etude
 
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.Concéption et réalisation d'un processus décisionnel, tableau de bord social.
Concéption et réalisation d'un processus décisionnel, tableau de bord social.
 
Rapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learningRapport- Conception et réalisation d'une plateforme social learning
Rapport- Conception et réalisation d'une plateforme social learning
 
La pratique de l'audit interne dans les entreprises d'assurances copie (2)
La pratique de l'audit interne dans les entreprises d'assurances   copie (2)La pratique de l'audit interne dans les entreprises d'assurances   copie (2)
La pratique de l'audit interne dans les entreprises d'assurances copie (2)
 
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
Torkhanikarima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitorin...
 
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
Torkhani karima-MémoireMastereProRx&telecom-FST2015-, Supervision et Monitori...
 

Front office back office caisse

  • 1. MINISTERE DE L’ENSEIGNEMENT SUPERIEUR ET DE LA RECHERCHE SCIENTIFIQUE UNIVERSITE TUNIS EL MANAR INSTITUT SUPERIEUR D’INFORMATIQUE RAPPORT DE STAGE DE FIN D’ETUDES Présenté en vue de l’obtention du Diplôme National de Master Professionnel en Sciences et Technologies Mention : Informatique Spécialité : Sécurité des Systèmes Informatiques Communicants et Embarqués Par Mr.Mohamed Ridha BEN SASSI Mr.Wissem KHITMI Encadrant professionnel Mr.Abderrazek CHINE Encadrant académique M.Lobna HSAIRI Réalisé au sein de (Horizon Ingénierie Informatique) Année Universitaire 2015/2016 CONCEPTION ET REALISTION D’UNE Front Office & BackOffice De « GESTION DES POINTS DE VENTES »
  • 2.
  • 4. Dédicaces On dédie ce modeste travail à : Mes chers parents en guise de reconnaissance et de gratitude pour les sacrifices qu’ils ont faits. Mon cher frère pour leur grand amour, avec tous mes vœux de les voir réussir dans leur vie. Nos chers amis à qui nous souhaitons le succès, pour l’amitié qui nous a toujours unis. A tous ceux qui nous sont chers et toujours dans mon pensée. Wissem
  • 5. Dédicaces A ma mère, Tu m'as donné la vie, la tendresse et le courage pour réussir. Tout ce que je peux t'offrir ne pourra exprimer l’amour et la reconnaissance que je porte. En témoigne, je t'offre ce modeste travail pour te remercier pour tes sacrifices et pour l'affectation dont tu m'a toujours entourée A mon père, L'épaule solide, l'œil attentif compréhensif et la personne la plus digne de mon estime et de mon respect. Aucune dédicace ne saurait exprimer mes sentiments, que Dieu te préserve et te procure santé et longue vie Ridha
  • 6. Remerciements Comme l’a dit SIR ISAAC NEWTON : « Si j’ai pu voir plus loin, c’est en montant sur les épaules des géants » Nous tenons à adresser mon sincère remerciement : A Mr. Chine ABDERRAZAK et M. Lobna HSAIRI pour avoir bien voulu nous encadrer, pour tout le temps qu’ils me ont octroyés et pour Tous les conseils qu’ils me ont prodigués. Qu’ils trouvent ici l’expression de notre profonde gratitude. A tous les membres du jury. A tous ceux qui, directement ou indirectement, ont aidé à la Finalisation de ce travail.
  • 7. Sommaire Introduction Générale …………...……………………………………………………...1 Chapitre 1. Etude Préalable………................................................................................. 3 I. Présentation de l’organisme d’accueil .................................................................... .................. 3 I.1. L’entreprise ........................................................................................................................ 3 I.2. Activités d’Horizon Informatique ...................................................................................... 3 I.3. L’organigramme ................................................................................................................. 4 II. Etude de l’existant…………......................................................................................................... 4 II.1. Analyse de logiciel XL POS................................................................................................ 5 II.2. Analyse de logiciel Ebp Caisse…………............................................................................... 6 II.3. Solution proposée ....................................................................................... ...................... 8 III. Contexte et motivation du projet ............................................................................................. 9 III.1. Contexte ............................................................................................................................ 9 III.2. But de projet ..................................................................................................................... 9 III.3. Travail demandé ............................................................................................................. 10 IV. Langage et méthodologie de conception................................................................................. 10 IV.1. Pourquoi Scrum .................................................................................... .......................... 11 Chapitre 2. Planification et spécification des besoins……...…...................................... 13 I. Capture des besoins.....................................................................................................................13 I.1. Identification des acteurs.................................................................................................... . 13 I.2. Les besoins fonctionnels....................................................................................................... 15 I.3. Les besoins non fonctionnels................................................................................................15 II. Planning du traitement des cas d’utilisation ............................................................................. 17 II.1. Priorités………………………......................................................................................................17 III. Prototypage des interfaces.........................................................................................................17 IV. Pilotage du projet avec Scrum................................................................................................ . 20 IV.1. Outils Scrum..................................................................................................……………......20 IV.2. Equipe et rôles................................................................................................................... 20 IV.3. Le backlog du produit......................................................................................................... 21 IV.4. Diagramme des cas d’utilisation global............................................................................. 25 IV.5. Architecture logique………..................................................................................................26 IV.6. Planification des sprints.................................................................................................... 26 Chapitre 3. Release 1 - Gestion Des Articles.................................................................... 29 I. Le premier sprint.........................................................................................................................29 I.1. Spécification fonctionnelle.................................................................................................. 30 I.1.1. Diagramme des cas d’utilisation.................................................................................. 30
  • 8. I.1.2. Description textuelle des cas d’utilisation.................................................................... 30 I.2. Conception…………………………..............................................................................................36 I.2.1. Diagramme de séquence système............................................................................... 36 I.2.2. Diagramme des classes................................................................................……………. 38 I.3. Codage………………………….....................................................................................................39 I.4. Test…………………………..........................................................................................................41 I.4.1. Les Test unitaires ……………………................................................................................ 41 II. Le deuxième sprint.....................................................................................................................43 II.1. Spécification fonctionnelle................................................................................................. 44 II.1.1. Diagramme des cas d’utilisation................................................................................. 44 II.1.2. Description textuelle des cas d’utilisation................................................................... 45 II.2. Conception………………………….............................................................................................49 II.2.1. Diagramme de séquence système.............................................................................. 49 II.2.2. Diagramme des classes...............................................................................……………. 51 II.3. Codage…………………………....................................................................................................51 II.4. Test…………………..……..........................................................................................................53 II.4.1. Les Test unitaires …………………….............................................................................. 53 Chapitre 4. Release 2 - Gestion de magasin & Faire des traitements............................ 55 I. Le premier sprint.........................................................................................................................55 I.1. Spécification fonctionnelle.................................................................................................. 56 I.1.1. Diagramme des cas d’utilisation.................................................................................. 56 I.1.2. Description textuelle des cas d’utilisation..................................................................... 57 I.2. Conception…………………………..............................................................................................60 I.2.1. Diagramme de séquence système................................................................................ 60 I.2.2. Diagramme des classes................................................................................……………. 61 I.3. Codage………………………….....................................................................................................62 I.4. Test…………………………..........................................................................................................64 I.4.1. Les Test unitaires ……………………................................................................................ 64 II. Le deuxième sprint.....................................................................................................................65 II.1. Spécification fonctionnelle................................................................................................. 66 II.1.1. Diagramme des cas d’utilisation................................................................................. 66 II.1.2. Description textuelle des cas d’utilisation................................................................... 67 II.2. Conception………………………….............................................................................................69 II.2.1. Diagramme de séquence système.............................................................................. 69 II.2.2. Diagramme des classes...............................................................................……………. 70 II.3. Codage…………………………....................................................................................................71 II.4. Test…………………..……..........................................................................................................72 II.4.1. Les Test unitaires ……………………............................................................................... 72 Chapitre 5. Release 3 – Administration……................................................................... 75
  • 9. I. Le premier sprint...............................................................................................z.........................75 I.1. Spécification fonctionnelle.................................................................................................. 76 I.1.1. Diagramme des cas d’utilisation.................................................................................. 76 I.1.2. Description textuelle des cas d’utilisation..................................................................... 77 I.2. Conception…………………………..............................................................................................78 I.2.1. Diagramme de séquence système............................................................................... 78 I.2.2. Diagramme des classes................................................................................……………. 80 I.3. Codage………………………….....................................................................................................81 I.4. Test…………………………..........................................................................................................83 I.4.1. Les Test unitaires ……………………................................................................................ 83 II. Le deuxième sprint.....................................................................................................................84 II.1. Spécification fonctionnelle................................................................................................. 85 II.1.1. Diagramme des cas d’utilisation................................................................................. 85 II.1.2. Description textuelle des cas d’utilisation................................................................... 86 II.2. Conception………………………….............................................................................................87 II.2.1. Diagramme de séquence système.............................................................................. 87 II.2.2. Diagramme des classes..............................................................................……………. 88 Chapitre 6. La phase de closure………………………………………............................ 90 I. Environnement de développement ............................................................................................90 I.1. Environnement matériel………............................................................................................ 90 I.1.1. Environnement de développement.............................................................................. 90 I.1.2. Environnement de test.................................................................................................. 91 I.1.3. Environnement de production...................................................................................... 91 I.2. Environnement logiciel………………………..............................................................................91 I.2.1. Eclipse……………………………………................................................................................. 91 I.2.2. Sybase POWER AMC...................................................................................……………. 92 I.2.3. Oracle Database 10g.....................................................................................……………. 92 I.3. Langage de programmation…...............................................................................................93 I.3.1. java EE……………………………………................................................................................ 93 I.3.2. UML………………………..................................................................................……………. 94 I.3.3. Le langage SQL……............................................................................................………. 93 I.4. Les Framework….……….........................................................................................................95 I.4.1. JSF2.0……………………………………….............................................................................. 95 I.4.2. Spring…………………….................................................................................................... 95 I.4.3. Hibernate……………………………......................................................................................95 II. Déploiement………......................................................................................................................96 II.1. Diagramme de déploiement............................................................................................... 96 II.2. Les interfaces de l’application……………..............................................................................98 Conclusion et perspectives…….………………………...………….............................. 102 Annexe A……………………….………………………...………….............................. 103
  • 10. I. Règle 1 : transformation des entités/classes…………................................................................. 103 II. Règle 1 : transformation des associations…..............................................................................103 II.1. Association un à plusieurs................................................................................................ 103 II.2. Association plusieurs à plusieurs……………….…................................................................104 II.3. Association un à un.......................................................................................................... 105 II.4. Transformation de l’héritage………………...........................................................................105 II.5. Transformation de la composition................................................................................... 106 Bibliographie.………………….…………………………………….............................. 107
  • 11. Liste des Figures Figure 1.1 : L’organigramme de la société ………………………………………………….4 Figure 1.2: FrontOffice & BackOffice XL POS ………………………………………….5 Figure1.3 : FrontOffice & BackOffice Ebp Caisse ……………………………………………...7 Figure 1.3 : Le processus de Scrum ……………………………………………………………..11 Figure 2.1 : Diagramme de contexte statique…………………………………………………… 14 Figure 2.2 : Page d’authentification (BackOffice)………………………………………………. 18 Figure 2.3 : Tableau de bord (BackOffice) ………………………………………………………18 Figure 2.4 : Fenêtre principale (FrontOffice) ……………………………………………………19 Figure 2.5 : Gestion des articles (BackOffice) ………………………………………………….19 Figure 2.6 : Equipe Scrum ………………………………………………………………………. 21 Figure 2.7 : Diagramme des cas d’utilisation global…………………………………………….. 25 Figure 2.8 : Diagramme de package …………………………………………………………….26 Figure 2.9 : Plan de release ………………………………………………………………………27 Figure 3.1 : Diagramme des cas d’utilisation de premier sprint (release 1) ……………………..31 Figure 3.2 : Exemple d’une histoire utilisateur ………………………………………………… 32 Figure 3.3 : Diagramme de séquence «consulter la liste des sous catégorie» …………………...37 Figure 3.4 : Diagramme de séquence «chercher une famille»…………………………………... 38 Figure 3.5 : Diagramme de classe du premier sprint (release 1) …………………………………39 Figure 3.6 : Code source de la classe de test pour l’histoire «supprimer une famille» …………..42 Figure 3.7 : Cas de succès pour la suppression d’une famille ……………………………………42 Figure 3.8 : Cas d’échec pour la suppression d’une famille ………………………………………43 Figure 3.9 : Diagramme des cas d’utilisation du second sprint (release 1)……………………… 45 Figure 3.10 : Diagramme de séquence système du cas d’utilisation «consulter la liste des articles» ……………………………………………………………………………………………………..49 Figure 3.11 : Diagramme de séquence système du cas d’utilisation «ajouter un article» ………50 Figure 3.12 : Diagramme des classe du second sprint (release 1)………………………………..51
  • 12. Figure 3.13 : Code source de la classe de test pour l’histoire «ajouter un article»……………… 53 Figure 3.14 : Cas du succès de la classe de test pour l’histoire «ajouter un article» …………….54 Figure 4.1 : Diagramme des cas d’utilisation du premier sprint (release 2) ……………………..57 Figure 4.2 : Diagramme de séquence «supprimer une caisse» …………………………………..60 Figure 4.3 : Diagramme de séquence «chercher un client» ………………………………………61 Figure 4.4 : Diagramme de classe du premier sprint (release 2) …………………………………62 Figure 4.5 : Code source de la classe de test pour l’histoire «modifier un vendeur»…………… 64 Figure 4.6 : Cas de succès pour la modification d’un vendeur …………………………………..65 Figure 4.7 : Diagramme des cas d’utilisation du second sprint (release 2) ………………………66 Figure 4.8 : Diagramme de séquence système du cas d’utilisation «Annuler ticket» …………..69 Figure 4.9 : Diagramme de séquence système du cas d’utilisation «Clôturer service»………… 70 Figure 4.10 : Diagramme des classes du second sprint (release 2)…………………………….. 71 Figure 4.11 : Code source de la classe de test pour l’histoire «supprimer un service»…………. 73 Figure 4.12 : Cas de succès pour la suppression d’un service …………………………………..73 Figure 5.1 : Diagramme des cas d’utilisation du premier sprint (release 3) ……………………..76 Figure 5.2 : Diagramme de séquence «modifier un utilisateur» …………………………………79 Figure 5.3 : Diagramme de séquence «supprimer une fonction»………………………………… 80 Figure 5.4 : Diagramme de classe du premier sprint (release3) ………………………………….81 Figure 5.5 : Code source de la classe de test pour l’histoire «ajouter un utilisateur»…………… 83 Figure 5.6 : Cas de succès pour l’ajout d’un utilisateur…………………………………………. 84 Figure 5.7 : Diagramme des cas d’utilisation du second sprint (release 3)……………………… 85 Figure 5.8 : Diagramme de séquence système du cas d’utilisation «consulter tableau de bord» ..87 Figure 5.9 : Diagramme de séquence système du cas d’utilisation «Authentification» …………88 Figure 5.10 : Diagramme de classe du premier sprint (release3) …………………………………89 Figure 6.1 : Eclipse ……………………………………………………………………………….91 Figure 6.2 : Power AMC ………………………………………………………………………… 92 Figure 6.3 : Oracle Data Base……………………………………………………………………. 92 Figure 6.4 : java EE ………………………………………………………………………………93 Figure 6.5 : UML………………………………………………………………………………… 94 Figure 6.6 : Langage SQL……………………………………………………………………….. 94 Figure 6.7 : JSF …………………………………………………………………………………..95 Figure 6.8 : Spring ……………………………………………………………………………….95 Figure 6.9 : Hibernate…………………………………………………………………………… 96
  • 13. Figure 6.10 : Diagramme de déploiement de FrontOffice ………………………………………...97 Figure 6.11 : Diagramme de déploiement BackOffice …………………………………………...97 Figure 6.12 : Page d’authentification (BackOffice) …………………………………….………..98 Figure 6.13 : Tableau de Bord (BackOffice) ………………………………………………….….98 Figure 6.14 : Gestion Des Vendeurs (BackOffice) ………………………………………….…..99 Figure 6.15 : Fenêtre d’accueil (FrontOffice) ……………………………………………………99 Figure 6.16 : Fenêtre Principale (FrontOffice)………………………………………………….. 100 Figure 6.17 : Fenêtre d’ajout d’article (FrontOffice) …………………………………………...100 Figure A.1 : Les règles de transformation des associations dépendent de leur cardinalités maximale ………………………………………………………………………………………………….103 Figure A.2 : Règle 2 du passage du modèle conceptuel vers le modèle logique ………………104 Figure A.3 : Règle 3 du passage du modèle conceptuel vers le modèle logique (premier cas) ..104 Figure A.4 : Règle 3 du passage du modèle conceptuel vers le modèle logique (deuxième cas) ……………………………………………………………………………………………….……105 Figure A.5: Règle 3 du passage du modèle conceptuel vers le modèle logique (troisième cas) …………………………………………………………………………………………………….106 Figure A.6: Règle 3 du passage du modèle conceptuel vers le modèle logique (quatrième cas)..106
  • 14. Liste des tableaux Tableau 2.1 : Backlog de produit ………………………………………………………………….21 Tableau 3.1 : Backlog de premier sprint (release 1) ………………………………………………30 Tableau 3.2 : Description textuelle du cas d’utilisation «consulter la liste des types articles»…... 32 Tableau 3.3 : Description textuelle du cas d’utilisation «chercher un type article» …………….. 33 Tableau 3.4 : Description textuelle du cas d’utilisation «ajouter une famille» …………………...33 Tableau 3.5 : Description textuelle du cas d’utilisation «supprimer une catégorie»……………... 34 Tableau 3.6 : Description textuelle du cas d’utilisation «modifier un sous catégorie» …………...35 Tableau 3.7 : Table «Type_Article» ………………………………………………………………40 Tableau 3.8 : Table «Catégorie» …………………………………………………………………..40 Tableau 3.9 : Table «Sous_Catégorie»……………………………………………………….........40 Tableau 3.10 : Table «Famille»……………………………………………………………………40 Tableau 3.11 : Backlog de second sprint (release 1) ……………………………………………... 44 Tableau 3.12 : Description textuelle du cas d’utilisation «ajouter un article»…………………….. 45 Tableau 3.13 : Description textuelle du cas d’utilisation «supprimer une taille»………………… 46 Tableau 3.14 : Description textuelle du cas d’utilisation «modifier une marque» ………………..47 Tableau 3.15 : Description textuelle du cas d’utilisation «chercher un couleur» …………………48 Tableau 3.16 : Table «Article» …………………………………………………………………… 52 Tableau 3.17 : Table «Taille»……………………………………………………………………… 52 Tableau 3.18 : Table «Couleur» ……………………………………………………………………52 Tableau 3.19 : Table «Marque»…………………………………………………………………….52 Tableau 4.1 : Backlog du premier sprint (release 2) ………………………………………………55 Tableau 4.2 : Description textuelle du cas d’utilisation «consulter la liste des vendeurs» ………..58 Tableau 4.3 : Description textuelle du cas d’utilisation «supprimer une caisse» …………………58 Tableau 4.4 : Description textuelle du cas d’utilisation «ajouter un client»……………………… 59 Tableau 4.5 : Table «Vendeur» …………………………………………………………………….63 Tableau 4.6 : Table «Caisse»……………………………………………………………………… 63 Tableau 4.7 : Table «Client» ……………………………………………………………………… 63
  • 15. Tableau 4.8 : Backlog de second sprint (release 2) ………………………………………………66 Tableau 4.9 : Description textuelle du cas d’utilisation «Annuler un ticket»…………………… 67 Tableau 4.10 : Description textuelle du cas d’utilisation «Clôturer un service»………………... 68 Tableau 4.11 : Table «Service» ………………………………………………………………….72 Tableau 4.12 : Table «Ticket» ……………………………………………………………………72 Tableau 5.1 : Backlog du premier sprint (release3)………………………………………………. 75 Tableau 5.2 : Description textuelle du cas d’utilisation «consulter la liste des utilisateurs»……..77 Tableau 5.3 : Description textuelle du cas d’utilisation «ajouter un utilisateur»………………... 77 Tableau 5.4 : Table «Utilisateur» …………………………………………………………………82 Tableau 5.5 : Table «Groupe»……………………………………………………………………. 82 Tableau 5.6 : Table «Fonction»…………………………………………………………………... 82 Tableau 5.7 : Table «Privilège»………………………………………………………………….. 82 Tableau 5.8 : Backlog de second sprint (release3) ………………………………………………..85 Tableau 5.9 : Description textuelle du cas d’utilisation «Authentification» ……………………..86
  • 16.
  • 17. 1 Introduction Générale De l’âge de la pierre à nos jours, l’esprit perfectionniste de l’Homme n’a cessé de lui permettre d’améliorer sa vie quotidienne. Le passage de la mécanique aux domaines d’informatique, d’électronique, d’automatique et de domotique a révolutionné la vie journalière de l’être humain. Les nouvelles technologies de l’information et de communication illustrent ce phénomène. Aujourd’hui, vu l’intérêt de vouloir gagner en temps, de conserver les données, de limiter le nombre d’employés et pas mal d’autres raisons, ont poussé petites, moyennes et grandes entreprises à chercher des solutions informatique capables de répondre à leurs besoins. Dans ce cadre s’inscrit notre projet de fin d’études qui consiste à réaliser un BackOffice et un FrontOffice sur mesure de gestion des points de ventes pour n’importe quelle surface de vente. Notre Objectif consiste donc à développer un logiciel FrontOffice qui aide les vendeurs de point de vente à automatiser la tache de la vente, de mode de règlement et de la gestion de commande et une application web qui représente BackOffice qui aide le responsable du magasin à automatiser les tâches de la gestion des vendeurs, la gestion des clés et la gestion des caisses . Outre l’originalité de l’application à développer, nous essayerons en plus d’utiliser une méthodologie, issue des méthodes agile, à savoir la méthode SCRUM. Nous essayerons à travers ce rapport de mettre en évidence les étapes effectuées, dans lesquelles nous avons usé des avantages de ladite méthode, surtout le plan de productivité et l’efficacité. Notre rapport se compose de cinq chapitres répartis comme suit :
  • 18. 2  Le premier chapitre «étude préalable» permet de placer le projet dans son contexte général. Dans ce premier chapitre introductif nous présentons l’organisme d’accueil ainsi qu’une brève description du projet.  Le second chapitre «planning et spécification des besoins» qui consiste en la première phase dans le cycle Scrum. Dans ce chapitre nous dévoilons les principales exigences de notre application, nous préparons quelques interfaces graphiques pour mettre notre application dans son contexte et nous le clôturons par un planning de travail.  Le troisième chapitre «gestion des articles», le quatrième chapitre «gestion de magasin et faire traitement» et le cinquième chapitre «administration & états et statistique» constituent le corps de notre rapport. Ces trois chapitres seront consacrés pour le développement des trois releases de notre système en respectant les principes fondamentaux de Scrum.  Le dernier chapitre « la phase de closue » détaille tous les outils utilisés pour la conception et le développement de notre application ainsi que quelques captures écran de la version finale de notre système. En conclusion, nous mentionnons les différents atouts de ce projet et les perspectives d’améliorations possibles .
  • 19. 3 Chapitre I. Etude Préalable Introduction : L’étude du projet est une démarche stratégique visant à organiser le bon déroulement d’un projet et d’assurer la conduite de toutes les phases qui le constituent. Une étude complète et efficace conduit généralement à la réussite d’un projet. Cette étude fera donc l’objet de notre premier chapitre qui sera consacré à la présentation de l’organisme d’accueil, et la présentation du projet ainsi que la définition de notre langage et méthodologie de développement. I. Présentation de l’organisme d’accueil : I.1. L’entreprise : Horizon Ingénierie Informatique (HII) est une équipe d’informaticiens expérimentés à l’écoute des nouvelles technologies dont l’objectif est de répondre aux besoins des professionnels et des particuliers et de résoudre leurs problèmes en informatique. I.2. Activités d’Horizon Informatique : Les activités d’Horizon Ingénierie Informatique sont très variées, nous puissions mentionner quelques-unes :  Conception et développement des logiciels sur mesure.  Vente, Achats et maintenance des matériels informatique  Installation et maintenance des réseaux locaux.  Développement d’applications.  Rédaction des cahiers de charges.
  • 20. 4 I.3. L’organigramme : La figure 1.1 montre l’organigramme de la société Horizon Informatique : II. Etude de l’existant : L’étude de l’existant permet de déterminer les points faibles et les points forts d’un produit actuel pour pouvoir déterminer les besoins du client, en vue d’en prendre en considération lors de la conception et de la réalisation du système de la gestion du point de vente. Dans cette section, nous présentons une analyse de quelques exemples d’application marchands. Ensuit, nous formulerons une solution de la problématique. Figure 2.1 : L’organigramme de la société
  • 21. 5 II.1. Analyse de Logicielle XL POS :  Aperçu : La figure 1.2 montre un aperçu sur le logiciel  URL: http://www.xlsoft.fr/logiciel-gestion/caisse-gestion/xlpos-caisse-gestion.html  Description : XL Pos est un logiciel de caisse et de gestion complète de point de vente. De la caisse, à la gestion des clients et des stocks en passant par la fidélité, XL Pos est une solution qui prendre en charge l’ensemble de l’activité du magasin. XL Pos est une solution capable d’apporter une réponse à la plupart des exigences du client.  Les points forts : Figure 1.2: FrontOffice & BackOffice XL POS
  • 22. 6  Fiable et simple, le client peut utiliser XL Pos en toute sécurité.  Paramétrable, la personnalisation du clavier de caisse, des documents et des statistiques en ferrant un outil adapté aux méthodes de travail du client.  Evolutif, les modules complémentaires permettront d’évoluer tant en superficie ou nombre de points de ventes, qu’en richesse fonctionnelle. Chaque année l’équipe XL pos propose un ensemble de nouveautés pour garantir la performance de son solution.  Les points faibles  Partie front Office n’est pas portable.  Format de ticket n’est pas modifiable  Oblige une seule thème (thème bleu)  La documentation en ligne n’est pas la plus complète. Pour avoir accès à toutes les directives de configuration, il faut télécharger le logiciel pour consulter les pages de manuels. éventuellement, certaines pages de la FAQ peuvent se révéler d’un grand secours.  Cout relativement élevé. II.2. Analyse de logiciel Ebp Caisse :  Aperçu :
  • 23. 7 Figure 1.3 : FrontOffice & BackOffice Ebp Caisse  URL: http://boutique.ebp.com/  Description : Très complet, cet outil 2 en 1 allie dans un seul logiciel : la rapidité d’une caisse enregistreuse et la puissance d’une gestion commerciale. Il est alors très simple d’encaisser, de gérer les ventes, de fidéliser les clients et de transférer les données en comptabilité sans aucune ressaisie.
  • 24. 8  Les points forts :  Facilité d’encaissement quotidien  Un écran de caisse intuitif, personnalisable selon les préférences de travail.  Réalisation des opérations commerciales  Epb logiciel permet d’éditer un coupon supplémentaire lors de l’impression du ticket de caisse. Idéal pour mettre en avant une offre promotionnelle ou communiquer sur un produit en particulier !  Simplifiez tous les aspects de la gestion,  Suivi des stocks, réapprovisionnement, commandes fournisseurs, inventaire … tout est centralisé dans le logiciel pour une gestion optimale  Visualisez en un coup d’œil les chiffres clés  Analyse efficace des activités avec des statistiques détaillées sur les articles, les clients, le CA...  Les points faibles :  Format de ticket n’est pas modifiable  Ne gère pas la mise en attente d’un ticket  Oblige une seule thème (thème bleu)  La documentation en ligne n’est pas la plus complète. Pour avoir accès à toutes les directives de configuration, il faut télécharger le logiciel pour consulter les pages de manuels. éventuellement, certaines pages de la FAQ peuvent se révéler d’un grand secours. II.3. Solution proposée : Suite aux inconvénients cités dans la section précédente, nous proposons la mise en place d’un logiciel de gestion du point de vente qui automatise les différentes activités du magasin tel que la gestion de la vente (règlement, remise, commentaire) et la gestion de magasin (caisse, vendeur, etc.) de point de vente ainsi que la gestion du stock.
  • 25. 9 III. Contexte et motivation du projet : Le présent projet intitulé «Développement d’une Back Office et Front Office de gestion des points de ventes (GPVhorizon). III.1. Contexte : Comme on l’a cité précédemment, Horizon Ingénierie Informatique n’est pas une société consommatrice, elle est plutôt productrice. Toutes les applications développées sont destinées alors à la vente. L’application en question s’agit d’une commande d’une surface de vente (magasin). Il s’agit donc d’une application de gestion de point de vente composée par deux partie (Back Office et Front Office ) , cette solution doit être capable d’automatiser les taches et d’améliorer la productivité de point de vente tout en respectant les exigences de client . III.2. But de projet : La gestion de points de vente est souvent compliquée. Gestion de stocks multiples, personnels aux horaires variables, gestion des caisses ou encore du service après-vente sont autant de défis qu’il faut relever au quotidien. Dans cette situation, il est primordial de bien organiser afin de répondre à ces exigences tout en garantissant la rentabilité de magasin. Il faut pouvoir évaluer rapidement les disponibilités de stocks, les entrées et sorties prévues afin de répondre dans les meilleurs délais aux demandes des clients. Pour faire face à toutes ces exigences, vous devez posséder un système d’information souple, adapté et évolutif. Un système qui vous permettra de suivre en quelques clics l’activité et de gérer un magasin. Une réaction rapide aux problèmes sera un atout de plus pour garantir la satisfaction de des clientèles. L’objet de ce projet est la conception et la réalisation d’une application web (Back Office) et une
  • 26. 10 application Desktop (front Office) fiable, agréable et simple d’utilisation, pour la gestion des stocks, la gestion du magasin et la gestion de vente. III .3. Travail demandé : Notre travail consiste à concevoir et à développer une application informatique qui permettra la gestion des clients, des vendeurs, des clés, des caisses, du stock, de cartes de fidélité, génération des rapports et statistiques, génération des journaux tickets, gérer les promotions, faire des traitements (annulation ticket, clôturer service…) , gestion de Vente( appliquer remise , règlement ... ). IV. Langage et méthodologie de conception : La méthodologie est une démarche organisée rationnellement pour aboutir à un résultat. Parmi les différentes méthodologies existantes, nous pouvons citer le modèle en cascade utilisée souvent dans les simples projets dont les besoins sont clairs et bien définis dès le début, le modèle en Y utiliser pour le développement des applications mobiles, ainsi que le processus unifié et les méthodologies agiles (Scrum & extrême programming) caractérisées par leurs souplesses et utilisées dans des grands projets. Pour bien conduire notre projet et nous assurer du bon déroulement des différentes phases, nous avons opté Scrum comme une méthodologie de conception et de développement. Après le choix de la méthodologie, nous avons besoins d’un langage de modélisation unifiée pour la modélisation de notre projet. Pour concevoir notre système, nous avons choisi UML comme un langage de modélisation. Notre choix s’est basé sur les points forts de ce langage notamment sa standardisation et les divers diagrammes qu’il propose. Aussi UML présente le meilleur outil pour schématiser des systèmes complexes sous un format graphique et textuel simplifié et normalisé. En effet UML n’est ni un processus ni une démarche, d’où il fallait choisir une méthodologie
  • 27. 11 De conception et de développement que nous devons l’adopter IV.1. Pourquoi SCRUM : Le principe de base de Scrum est le suivant :  Dégager dans un premier lieu le maximum des fonctionnalités à réaliser pour former le backlog du produit,  En second lieu définir les priorités des fonctionnalités et choisir lesquelles seront réalisé dans chaque itération,  Par la suite focaliser l’équipe de façon itérative sur l’ensemble de fonctionnalités à réaliser, dans des itérations appelées Sprints,  Un Sprint aboutit toujours sur la livraison d’un produit partiel fonctionnel appelé incrément. La figure 1.4 illustre le principe de Scrum. Figure 1.4 : Le processus de Scrum
  • 28. 12 Le choix de Scrum comme une méthodologie de pilotage pour notre projet s’est basé sur les atouts de ce dernier. Il se résumé comme suit:  Plus de souplesse et de réactivité,  La grande capacité d’adaptation au changement grâce à des itérations courtes,  Et la chose plus importante, c’est que Scrum rassemble les deux cotés théorique et pratique et se rapproche beaucoup de la réalité. Vu que Scrum ne couvrant que les aspects de gestion de projet, et pour compléter le vide laissé en matière de pratiques de développement, nous avons pris la décision de coupler Scrum avec une autre méthodologie agile qui est l’extrême prograrnrning ( XP ) et qui couvre les bonnes pratiques d’ingénierie logicielle notamment le développement dirigé par le test, qui sera détaillé dans les chapitres qui suivent, et la programmation en binôme, etc. Conclusion : Dans ce chapitre, nous avons présenté le cadre générale de notre projet en déterminant la problématique et en proposant une solution envisagé pour faire face à la situation courante. Nous avons dévoilé le langage et la méthodologie de conception qui seront utilisés dans les prochains chapitres de ce rapport et nous avons argumenté notre choix.
  • 29. 13 Chapitre II. Planification et Spécification des besoins Introduction Dans le chapitre précédent, nous avons choisi d’adopter la méthodologie Scrum pour la conception de notre futur système. En fait, Scrum est organisé suivant trois phases dont la première est la phase de planification et architecture (appelé aussi sprint 0 dans quelques ouvrages).Cette phase est la plus importante dans le cycle de développement Scrum puisqu’elle qui influence directement la réussite des Sprints et en particulier le premier. Les travaux réalisés dans cette période de temps conduit à construire une bonne vision du produit. Identifier les rôles des utilisateurs et dégager les fonctionnalités principales afin de produire le backlog initial ainsi qu’une première planification des Sprints. Cette phase fera donc l’objet de ce chapitre où nous commençons par la capture des différents besoins, identifier les rôles des utilisateurs et préparer notre plan de release. I. Capture des besoins I.1. Identification des acteurs a. Les acteurs Tout simplement un acteur est une entité physique (personne) ou abstraite (logiciel) capable
  • 30. 14 d’utilisée le système afin de répondre à un besoin bien définit. Les acteurs de notre application sont:  Administrateur Système : Peut-être le Gérant ou le responsable du magasin, c’est la personne possédant le privilège du plus haut niveau. Cet acteur est capable de manipuler toutes les fonctionnalités proposées par l’application notamment l’ajout des articles, attribution des droits d’accès aux autres acteurs, etc. II s’agit principalement le responsable de point de vente.  Agent comptable : Peut-être un comptable ou responsable financier.  Vendeur : Il s’agit du vendeur du point de vente. b. Diagramme de contexte statique Ce diagramme d’UML, illustré par la figure 2.1, permet simplement de montrer la relation des différents acteurs avec le système. Il spécifie le nombre d’instances de chaque acteur relié au système à un moment donné. Figure 2.1 : Diagramme de contexte statique
  • 31. 15 Pour expliquer le diagramme présenté par la figure 2.1, nous pouvons dire qu’à un instant donné nous pouvons avoir zéro ou deux administrateurs qui manipule l’application, et zéro ou plusieurs agent comptable et vendeur qui sont en train d’utiliser l’application. I.2. Les besoins fonctionnels : Les besoins fonctionnels ou les cas d’utilisations en terme d’UML peuvent être définis comme suit: « Un cas d’utilisation (use case) représente un ensemble de séquences d’actions réalisées par le système et produisant un résultat observable intéressant pour un acteur particulier» [1] Un cas d’utilisation est une suite d’actions effectuées par le système afin de répondre à une demande d’un utilisateur (acteur). Dans ce qui suit, nous décrivons les différents besoins fonctionnels de notre système:  Gestion de Vente : Consiste à gérer toutes les processus de vente (lecture article via son code barre, faire de remise, mode de règlement …)  Gestion des Tickets : Consiste à gérer les tickets (annulation ticket, mettre un ticket en attente …)  Gestion de magasin : Consiste à gérer les caisses, les vendeurs, les clients.  Gestion des Articles : Consiste à gérer les catégories, les sous catégories, les familles, les types article, les couleurs et les tailles  Consulter des statistiques : Consiste à consulter le tableau de bord, les états x services, le meilleur vendeur, chiffre d’affaire pour une période de temps  Gestion de sécurité : Attribution des droits d’accès (clés) aux vendeurs I.3. Les besoins non fonctionnels : Ces besoins sont les contraintes techniques exigées et les fonctionnalités nécessaires pour rendre le logiciel plus performant et qui se résument généralement en :  La simplicité : plus une application de gestion des points de ventes est simple dans l’apprentissage et dans l’utilisation, plus ses fonctionnalités sont utilisées.  L’accessibilité de l’application et la facilité d’administration : Une application de gestion des points de ventes permet de gérer trois principales fonctions vitales d’administration de magasin :
  • 32. 16  La gestion du stock : répartir et organiser les articles dans des catégories, sous-catégories, familles, types articles, marques.  La gestion les éléments du magasin : qui permet la gestion des vendeurs, des clés et des caisses.  La gestion des statistiques, des rapports et des journaux : c’est à dire fournisse des statistiques sur les ventes, des rapports services et des journaux de tickets et de paiements.  Le paramétrage et l’ergonomie : une application de gestion des points de ventes doit avoir plusieurs fenêtres adaptables aux types d’utilisateurs. En effet, les interfaces, les fonctionnalités et les profils doivent être modifiables et ajustables aux besoins.  L’économie : il est important que l’application soit plus concurrent économiquement de point de vue ressources utilisés (connexion à la base de données…).  L’évolutivité : il est intéressant que l’application assure un pouvoir d’évolution, de développement et d’amélioration au cours du temps et ce selon les besoins des utilisateurs. Le code doit être clair pour permettre des futures évolutions.  La sécurité : il est nécessaire que l’application gère :  La confidentialité : l’information échangée entre deux correspondants ne peut pas être consultée par un tiers  L’authentification : les personnes utilisant une ressource correspondent aux groupes d’utilisateurs.  La disponibilité : les données ainsi que les ressources du système d’information sont accessibles par ceux qui ont besoin à chaque fois qu’ils ont l’utilité.  L’intégrité : l’information n’est modifiée que par les personnes ayant le droit et de façon volontaire.  Le contrôle d’accès : une ressource n’est accessible que par les personnes autorisées.
  • 33. 17 II. Planning du traitement des cas d’utilisation Après tout le travail d’identification des cas d’utilisation, nous devons maintenant les classifier. La classification des cas d’utilisation doit tenir compte de deux facteurs principaux qui sont la priorité et les risques. Cette technique est utilisée généralement lors de la conception des applications se basant sur le processus unifié, mais elle reste valable et intéressante pour notre cas. II.1. Priorités : Généralement, nous disons qu’un cas d’utilisation A est plus prioritaire que B, si sa réalisation accélère la stabilisation du système. Le choix des priorités dans cette section s’est basé sur la dépendance entre les fonctionnalités de l’application. Par exemple, nous ne pouvons pas affecter des remises sur des articles tant que nous n’avons pas encore terminé la gestion des articles et celles des catégories. Par conséquent, nous pouvons dégager trois niveaux de priorité qui sont: priorité haute, moyenne et faible. III. Prototypage des interfaces : Dans le domaine du web, une technique est apparue et prend une place très importante dans le développement des applications Web; il s’agit du prototypage. Cette technique consiste à préparer quelques interfaces graphiques de l’application en utilisant un outil de conception de prototypes afin de mesurer le degré de satisfaction du client par rapport à la compréhension du projet par le développeur. L’interaction qui se produit entre l’utilisateur final et le développeur, à la suite de la discussion sur ces interfaces, permet d’ajuster les besoins et de les concevoir de manière précise et exacte. En effet, les interfaces graphiques font que l’utilisateur final soit plus interactif, précis et le poussent à mieux s’exprimer quant à ses attentes. Quelques interfaces réalisées avec l’outil MokFlow4 sont illustrées par les figures : Figure 2.2, Figure 2.3, Figure 2.4, Figure 2.5, Figure 2.5.
  • 34. 18 Figure 2.2 : Page d’authentification (BackOffice) Figure 2.3 : Tableau de bord (BackOffice)
  • 35. 19 Figure 2.4 : Fenêtre principale (FrontOffice) Figure 2.5 : Gestion des articles (BackOffice)
  • 36. 20 IV. Pilotage du projet avec Scrum : Le cadre Scrum est constitué de trois éléments qui sont l’équipe avec des rôles bien définis, les blocs de temps et les artefacts. IV.I. Les outils Scrum : Pour le pilotage de leurs projets Scrum, les membres de l’équipe font recours à plusieurs techniques. Une de ces techniques, qui est la plus répondue, consiste à créer des fiches (post It) et de les coller sur un mur ou sur un tableau visible pour tous les membres de l’équipe. Une autre technique consiste à utiliser un fichier Excel contenant toutes les informations nécessaires pour les sprints, les user story leurs estimations, etc. Ce fichier devra être partagé en lecture et en écriture (pour que tous les membres de l’équipe puissent le modifier à tout moment). Par conséquent, plusieurs outils sont apparus en offrant la possibilité de suivre la priorité, la traçabilité et la gestion de tout le travail associé. Parmi les outils existants, nous avons choisi d’utiliser iceScrum. IV.2. Equipe et rôles : «L’équipe a un rôle capital dans Scrum : elle est constituée avec le but d’optimiser la flexibilité et la productivité; pour cela, elle s’organise elle-même et doit avoir toutes les compétences nécessaires au développement du produit. Elle est investie avec le pouvoir et l’autorité pour faire ce qu’elle a à faire ». [2] Bref, Scrum définit trois rôles qui sont:  Le Product Owner(le propriétaire du produit) : c’est une personne qui porte la vision du produit à réaliser, généralement c’est un expert dans le domaine.  Le Scrum Master(le directeur de produit) : c’est la personne qui doit assurer le bon déroulement des différents sprints du release, et qui doit impérativement maîtriser Scrum.  Le Scrum Team (l’équipe de Scrum) : constitué des personnes qui seront chargées d’implémenter les différents besoins du client. Bien évidemment, cette équipe sera constituée des développeurs, des infographistes, des testeurs, etc. Dans le contexte de notre projet, Abderazek Chine sera à la fois le propriétaire et le directeur de produit puisqu’il satisfait les différents prés requis de ces deux rôles et nous formons
  • 37. 21 nous-mêmes les deux membres de l’équipe Scrum (voir Figure 2.6). Figure 2.6 : Equipe Scrum IV.3. Le backlog du produit : Le backlog du produit est l’artefact le plus important de Scrum, c’est l’ensemble des caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité. Les caractéristiques fonctionnelles sont appelées des histoires utilisateur (user story) et les caractéristiques techniques sont appelées des histoires techniques (technical story). Le Tableau 2.1 résume le backlog produit de notre application. Il est à noter que nous n’avons pas cité les histoires techniques comme la préparation de la maquette graphique, les travaux de conception et les jeux de tests, etc. Dans ce tableau chaque histoire utilisateur est caractérisée par un rang déduit à partir de ses risques et sa priorité expliqués dans la section il de ce même chapitre. Pour le traitement de nos histoires utilisateur nous choisissons de commencer avec les cas d’utilisation les plus prioritaires et ayant le risque le moins élevé, En plus du rang, chaque histoire utilisateur possède un effort (vélocité) qui est l’estimation initiale sur la quantité de travail nécessaire pour implémenter cette exigence. Cet effort est calculé en point d’histoire qui correspond aux jours hommes idéaux. Généralement, un point d’histoire vaut un jour/homme. Tableau 2.1 : Backlog de produit
  • 38. 22 Nom Effort Rang Description Thème Risque Priorité Ajouter un article 1 30 En tant qu’administrateur je peux ajouter un article afin de renforcer mes ventes Gestion des articles Faible Élevé Mettre à jour les articles 1 31 En tant qu’administrateur je peux mettre à jour un article afin de garder l’intégrité de mes données Gestion des articles Faible Élevé Ajouter un administrateur 2 2 En tant qu’administrateur je peux ajouter un admin afin de renforcer mes ressources humaines du point de vente Gestion des utilisateurs Faible Moyen Mettre à jour un administrateur 2 3 En tant qu’administrateur je peux mettre à jour un admin afin de garder l’intégrité de mes données Gestion des utilisateurs Faible Moyen Ajouter une catégorie 1 8 En tant qu’administrateur je peux ajouter une catégorie afin d’organiser mes articles Gestion des catégories Faible Élevé Mettre à jour une catégorie 1 9 En tant qu’administrateur je peux mettre à jour une catégorie afin de garder l’intégrité de mes données Gestion des catégories Faible Élevé
  • 39. 23 Nom Effort Rang Description Théme Risque Priorité Ajouter un vendeur 1 5 En tant qu’administrateur je peux ajouter un vendeur afin de renforcer les ressources humaines du point de vente Gestion des vendeurs Faible Élevé Mettre à jour un vendeur 2 6 En tant qu’administrateur je peux mettre à jour un vendeur afin de garder l’intégrité de mes données Gestion des vendeurs Faible Élevé Ajouter une caisse 1 17 En tant qu’administrateur je peux ajouter une caisse afin de renforcer les ressources matérielles de point de vente Gestion des caisses Faible Élevé Mettre à jour une caisse 2 18 En tant qu’administrateur je peux mettre à jour une caisse afin de garder l’intégrité de mes données Gestion des caisses Faible Élevé Ajouter un client 1 11 En tant qu’administrateur je peux ajouter un client afin de contrôler les achats et les points de fidélités Gestion des clients Moyen Élevé Mettre à jour un client 2 12 En tant qu’administrateur je peux mettre à jour une caisse afin de garder l’intégrité de mes données Gestion des clients Moyen Élevé
  • 40. 24 Nom Effort Rang Description Théme Risque Priorité Ajouter une famille 1 14 En tant qu’administrateur je peux ajouter une famille afin d’organiser mes articles Gestion des familles Faible Élevé Mettre à jour une famille 2 15 En tant qu’administrateur je peux mettre à jour une famille afin de garder l’intégrité de mes données Gestion des familles Faible Élevé Authentification 3 1 En tant qu’administrateur je peux faire une authentification afin d’accéder à mon espace de travail -------- Faible Faible Lister les articles 2 32 En tant qu’administrateur je peux lister les articles afin de sélectionner un article Gestion des articles Faible Élevé Consulter tableau de bord 3 21 En tant qu’administrateur je peux consulter le tableau de bord afin d’assurer une meilleur gestion des ressources Statistique et états Moyen Faible Annuler un ticket 2 22 En tant qu’administrateur je peux annuler un ticket afin de prendre le contrôle sur les tickets Faire des traitements Moyen Faible
  • 41. 25 IV.4. Diagramme des cas d’utilisation global : Dans cette section nous présentons les besoins de notre système de manière formelle. C’est à dire nous utilisons le diagramme des cas d’utilisation du langage de modélisation UML. Dans la Figure 13, tous les cas d’utilisation nécessitent une authentification préalable. Figure 2.7 : Diagramme des cas d’utilisation global
  • 42. 26 IV.5. Architecture logique : Avant de se lancer dans la conception et le développement de tout système informatisé, il est important de préparer l’architecture de ce dernier. Le terme architecture est vaste puisqu’il y peut désigner : Architecture logique, l’architecture physique, architecture logicielle, etc. Dans ce paragraphe nous nous intéressons à l’architecture logique traduite par le diagramme de package en terme d’UML qui est illustré par la figure 2.8. Figure 2.8 : Diagramme de package IV .6. Planification des sprints La réunion de planification des sprints est l’événement le plus important dans Scrum. Le but de cette réunion est de préparer le planning de travail et d’identifier le backlog des Sprints[7] L’un des produits de cette réunion est le choix de la durée des sprints et qui diffère selon la complexité du projet et la taille de l’équipe. Pour notre projet nous avons choisi de développer trois releases :
  • 43. 27  Le premier sprint sera nommé gestion des articles (catégorie, sous catégorie, famille, marque, couleur, taille).  Le second sprint sera pour la gestion de magasin (vendeur, caisse, client ...) et pour faire des traitements (clôturer caisse, annuler ticket, consulter états stock ...),  Le troisième sera intitulé administration (groupe, utilisateur, droit d’accès ...) et états et statistique (tableau de bord, recap de vente, journal de ticket annulé ...), Pour notre cas la durée de 20 jours pour un sprint semble adéquate. La Figure 14 résume notre planning de travail. Figure 2.9 : Plan de release
  • 44. 28 Conclusion : Dans ce chapitre nous avons préparé notre plan de travail. Nous avons capturé les besoins fonctionnels de notre application, les rôles des utilisateurs, par la suite nous avons préparé l’architecture logique ainsi que le plan de release de notre projet.
  • 45. 29 Chapitre 3. Release 1- Gestion Des Articles Introduction : Le terme release peut être défini comme une version distribuée d’une application ou une période de temps qui permet de la produire. Peu importe quelle définition nous utilisons, une release est constituée d’une suite d’itérations (sprint) qui se terminent quand les incréments de ces derniers construisent un produit présentant suffisamment de valeur aux utilisateurs finaux. La durée des releases est définie par le Product Owner en collaboration avec son équipe Scrum. Notre premier release sera composé de deux sprints, chacun ayant une vélocité de 20 jours. Tout au long de ce chapitre, nous allons traiter les histoires utilisateurs de nos sprints pour produire un incrément potentiellement livrable. I. Le premier sprint : Le sprint est le cœur de Scrum. Il s’agit d’un bloc de temps durant lequel un incrément du produit sera réalisé. Tous les sprints d’une release ont une durée constante et ne se chevauchent jamais, c’est-à-dire qu’un sprint ne peut pas démarrer tant que le précédent n’est pas encore terminé. Avant de se lancer dans un sprint, l’équipe Scrum doit obligatoirement définir le but de ce dernier. Ce but doit être défini en terme métier et non pas en terme technique pour qu’il soit compréhensible par les membres en dehors de l’équipe. Il s’agit de répondre à une question fondamentale «pourquoi faisons-nous ce sprint?». Suite à une conversation entre le Product Owner et l’équipe Scrum, nous avons décidé le but suivant: «terminer la partie qui concerne la gestion des articles du point de vente».
  • 46. 30 Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires inclure dans ce dernier. Plus précisément, quelles histoires de notre backlog du produit seront incluses dans le backlog du sprint. Le Tableau 2 résume donc le backlog de notre premier sprint: Tableau 3.1 : Backlog de premier sprint (release 1) Passons maintenant au vif de notre sujet : Les activités et le cycle de développement. Dans un sprint nous pouvons dégager quatre activités principales qui sont la spécification fonctionnelle, la conception, le codage et le test. Tout au long de ce sprint, nous respectons ces activités pour construire le plan de notre travail. I.1. Spécification fonctionnelle : La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas d’utilisation d’UML et la description textuelle de ces derniers. I.1.1. Diagramme des cas d’utilisation : Dans la Figure 3.1 nous illustrons le diagramme des cas d’utilisation globaux pour ce premier sprint Histoire utilisateur Estimation Lister les types des articles 2 Ajouter un type d’article 2 Modifier un type d’article 1 Lister les familles 1 Ajouter une famille 2 Modifier une famille 2 Lister les catégories 2 Ajouter un catégorie 2 Modifier un catégorie 2 Lister les sous catégorie 1 Ajouter un sous catégorie 1 Modifier un sous catégorie 2
  • 47. 31 Figure 3.1 : Diagramme des cas d’utilisation de premier sprint (release 1) Dans ce diagramme, certains cas d’utilisation à l’instar « chercher une famille », « chercher une catégorie », etc. ne figurent pas dans le backlog de notre sprint pour une simple raison, avec Scrum, une des pratiques intéressante consiste à découper une histoire en un ensemble de tâches. La différence entre une histoire et une tâche c’est que l’histoire est sous-produit livrable qui intéresse le directeur de produit. La figure 3.2 illustre un exemple : Lister les catégories
  • 48. 32 Figure 3.2 : Exemple d’une histoire utilisateur I.1.2. Description textuelle des cas d’utilisation : Pour rendre notre diagramme des cas d’utilisation plus lisible et afin de décrire le comportement de notre système, nous présentons la description textuelle des principaux cas d’utilisation. A. Cas d’utilisation : Gestion des types articles  Description textuelle du cas d’utilisation « consulter la liste des types article » (voir tableau 3.2) Tableau 3.2 : Description textuelle du cas d’utilisation «consulter la liste des types articles» Cas d’utilisation Consulter la liste des types articles Acteurs Administrateur, Agent comptable, Vendeur Pré - condition Une authentification préalable Post - condition La liste des types article est affichée sur l’écran Scénario nominal 1-l’acteur demande l’affichage de la liste des types articles 2-le système affiche la liste des types articles Scénario alternatif 2-a-aucun résultat 2-a-1- le système affiche un message de type « aucun résultat trouvé »  Description textuelle du cas d’utilisation « chercher un type article » (voir tableau 3.3)
  • 49. 33 Tableau 3.3 : Description textuelle du cas d’utilisation «chercher un type article» B. Cas d’utilisation : Gestion des Familles  Description textuelle du cas d’utilisation « ajouter une famille » (voir Tableau 3.4) Tableau 3.4 : Description textuelle du cas d’utilisation «ajouter une famille» Cas d’utilisation Ajouter une famille Acteurs Administrateur Pré-condition Une authentification préalable Formulaire d’ajout disponible Post-condition La liste des familles est affichée sur l’écran Scénario nominal 1-l’administrateur demande le formulaire d’ajout 2-le système affiche les formulaires 3-l’administrateur rempli les champs nécessaire et valide Cas d’utilisation Chercher un type article Acteurs Administrateur, Agent comptable, Vendeur Pré - condition Une authentification préalable Formulaire de recherche disponible Post-condition La liste des types articles est affichée sur l’écran Scénario nominal 1-l’acteur saisi les critères de recherche 2-le système cherche les types article aux critère répondant aux critères mentionnés 3-le système affiche la liste des types articles Scénario alternatif 2-a-aucun résultat 2-a-1- le système affiche un message de type « aucun résultat correspondant à vos critères, essayer de nouveau » 2-a-2-reprise de l’étape 1 du scénario nominal
  • 50. 34 4-le système enregistre la nouvelle famille et affiche un message de succès Scénario alternatif 2-a-aucun résultat 2-a-1- le système affiche un message de type « aucun résultat trouvé » 4-a-l’administrateur saisie des données manquantes 4-a-1- le système affiche un message d’erreur 4-a-2-reprise de l’étape 1 du scénario nominal 4-b-la famille existe déjà 4-b-1-le système demande à l’administrateur de Modifier les données saisies 4-b-2-reprise de l’étape 3 du scénario nominal C. Cas d’utilisation : Gestion des catégories  Description textuelle du cas d’utilisation «supprimer une catégorie» (voir Tableau 3.5) Tableau 3.5 : Description textuelle du cas d’utilisation «supprimer une catégorie» Cas d’utilisation Supprimer une catégorie Acteurs Administrateur Pré - condition Une authentification préalable La catégorie existant Post - condition La liste des catégories est affichée sur l’écran Scénario nominal 1-l’administrateur choisi la catégorie à supprimer 2- le système affiche un message de confirmation 3-l’administrateur valide son choix
  • 51. 35 4-le système supprime la catégorie 5-le système affiche un message de succès Scénario alternatif 3-a-l’administrateur annule son choix 3-a-1-le système annule la suppression C. Cas d’utilisation : Gestion des sous catégories  Description textuelle du cas d’utilisation «modifier un sous catégories » (voir le Tableau 3.6) Tableau 3.6 : Description textuelle du cas d’utilisation «modifier un sous catégorie» Cas d’utilisation Modifier un sous catégorie Acteurs Administrateur Pré-condition Une authentification préalable Le sous catégorie existant Post-condition Les informations ont bien été mises à jour Scénario nominal 1-l’administrateur choisi le sous catégorie à modifier 2-le système affiche le formulaire de modification 3-l’administrateur modifie les informations et valide 4-le système vérifie les données saisies 5-le système enregistre les données et affiche un message de succès Scénario alternatif 4-a-l’administrateur saisie des données manquantes 4-a-1-le système affiche un message d’erreur 4-a-2-reprise de l’étape 3 du scénario nominal 4-b- le libellé de sous catégorie existe déjà 4-b-1-le système demande à l’administrateur de modifier les données saisies
  • 52. 36 4-b-2-reprise de l’étape 3 du scénario nominal I.2. Conception : La conception est la deuxième activité dans un sprint. Elle se traduit par le diagramme de classe et le diagramme de séquence d’UML. 1.2.1. Diagramme de séquence système Pour schématiser la vue comportementale de notre système informatique, nous faisons recours au diagramme de séquence d’UML. Ce diagramme permet de présenter les interactions entre l’acteur et le système avec des messages présentés dans un ordre chronologique .Le digramme de séquence système traite le système informatique comme étant une boite noire. Le comportement du système est décrit vu de l’extérieur sans avoir d’idée sur comment il le réalisera. En nous référant aux descriptions textuelles dans la section précédente, nous présentons les diagrammes de séquences systèmes adéquats. Sur la base de ces descriptions, nous pouvons constater que certains cas d’utilisations sont similaires à l’instar de la consultation des types articles, la consultation des familles, etc. c’est pour cette raison que nous avons choisi de sélectionner quelques exemples pour les traiter. A. Diagramme de séquence système du cas d’utilisation « consulter la liste des catégorie» Le cas d’utilisation consulter la liste des catégorie est similaire au cas d’utilisation suivant : consulter la liste des familles, consulter la liste des sous catégorie, consulter la liste des types articles. La figure 3.3 illustre le diagramme de séquence «consulter la liste des catégorie»
  • 53. 37 Figure 3.3 : Diagramme de séquence «consulter la liste des sous catégorie» B. Diagramme de séquence système du cas d’utilisation « chercher une famille» Pour chercher une famille, l’administrateur doit s’authentifier dans un premier lieu en utilisant son login et son mot de passe. Par la suite, il choisit les critères de recherche correspondant à ces besoins (voir figure 3.4).
  • 54. 38 Figure 3.4 : Diagramme de séquence «chercher une famille» 1.2.2. Le diagramme des classes : 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. (Voir Figure 3.5)
  • 55. 39 Figure 3.5 : Diagramme de classe du premier sprint (release 1) I.3. Codage : Les travaux menés dans cette activité se résument tout simplement dans l’implémentation et la réalisation des histoires utilisateurs analysés lors des étapes précédentes. Pour notre cas, nous nous intéresserons seulement au schéma de la base de données. Pour construire le schéma de base de données de notre application, nous devons appliquer certaines règles pour passer vers un schéma relationnel. Ces règles sont bien définies dans l’annexe A. Dans ce qui suit, nous présentons les tables de notre base de données (voir Tableau 3.7, Tableau 3.8 Tableau 3.9 et le Tableau 3.10) tout en tenant compte du type et des contraintes de leurs champs.
  • 56. 40 Champs Types Contraintes TA_CODE VARCHAR(20) PRIMARY KEY TA_LIBELLE VARCHAR(20) --- TA_IMP VARCHAR(20) --- Tableau 3.7 : Table «Type_Article» Champs Types Contraintes CAT_CODE VARCHAR(20) PRIMARY KEY CAT_LIBELLE VARCHAR(20) --- Tableau 3.8 : Table «Catégorie» Champs Types Contraintes SCAT_CODE VARCHAR(20) PRIMARY KEY CAT_CODE VARCHAR(20) PRIMARY KEY SCAT_LIBELLE VARCHAR(20) NOT NULL Tableau 3.9 : Table «Sous_Catégorie» Champs Types Contraintes FAM_CODE VARCHAR(20) PRIMARY KEY FAM_LIBELLE VARCHAR(20) --- Tableau 3.10 : Table «Famille»
  • 57. 41 I.4. Test : Les activités de test constituent un axe très important dans le cycle de développement d’un logiciel. Ils permettent de détecter les erreurs afin de les corriger et d’assurer la qualité du logiciel fourni. Contrairement aux cycles de développement séquentiel, avec la méthodologie agile, le test n’est pas une phase qui se déroule après la fin de développement. En effet, les tests seront intégrés dès le début du premier sprint jusqu’à la livraison du produit final. En outre, la qualité du logiciel n’est pas négligeable, c’est dans ce cadre que Scrum doit être complété par les bonnes pratiques d’ingénierie techniques du logiciel. Parmi ces pratiques, les tests unitaires. 1.4.1. Les tests unitaires Le principe de cette pratique est d’écrire les tests avant même d’écrire le code et de profiter par la suite de l’existence des tests automatiques pour l’amélioration et le remaniement du code. Cette technique permet aux programmeurs de rester simples au niveau du code et de s’assurer de son bon fonctionnement après des changements. Dans ce paragraphe, nous avons choisi de tester deux histoires utilisateurs qui sont: l’ajout d’une catégorie et la suppression d’une famille. Pour la création des tests unitaires de ces histoires, nous avons eu recours à la bibliothèque JUnit.  Test unitaire pour l’histoire «supprimer une famille» Pour tester la suppression d’une famille, nous avons choisi de suivre la démarche suivante : 1. Compter le nombre de familles existantes et vérifier que c’est égal à 3 2. Supprimer une famille 3. Compter de nouveau le nombre de famille et vérifier que c’est égal à 2 La première capture écran (Figure 3.6) illustre le code de la classe de test.
  • 58. 42 Figure 3.6 : Code source de la classe de test pour l’histoire «supprimer une famille» La deuxième capture écran (Figure 3.7) illustre le cas de succès de notre test. Cette figure nous montre que notre méthode est bien fonctionnelle. Figure 3.7 : Cas de succès pour la suppression d’une famille
  • 59. 43 La dernière capture écran (Figure 3.8) illustre le cas d’échec. Dans cette figure l’oracle13 était 2 lors que la méthode nous renvoie 3. Figure 3.8 : Cas d’échec pour la suppression d’une famille II. Le deuxième sprint En partant sur le même principe que le sprint précédent, nous commençons par définir le but de notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum, nous avons décidé le but suivant: « terminer la partie qui concerne la gestion des articles de point de vente ». Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires inclure dans ce dernier. Le Tableau 3.11 résume donc le backlog de notre second sprint :
  • 60. 44 Tableau 3.11 : Backlog de second sprint (release 1) Dans le Tableau 3.11, nous pouvons constater que les histoires utilisateur «lister les couleur », «ajouter un couleur» et « modifier une marque » ne figurent pas dans le backlog de produit. En effet, notre backlog de produit initial ne couvre pas toutes les fonctionnalités requises et c’est pour cette raison que nous aurons des nouvelles fonctionnalités au fur et mesure de notre avancement. En plus, nous pouvons constater que les vélocités de nos histoires ont changé par rapport à l’estimation initiale tout en gardant la même durée que le sprint précédent. II.1. Spécification fonctionnelle : Pour la spécification fonctionnelle de ce sprint, nous commençons par le diagramme des cas d’utilisation. II.1.1. Diagramme des cas d’utilisation Dans la Figure 3.9 nous illustrons le diagramme des cas d’utilisation global pour ce second sprint. En respectant toujours le même principe que le sprint précédent, nous avons découpé certaines histoires utilisateurs en un ensemble de tâches. Histoire utilisateur Estimation Lister les articles 1 Ajouter un article 2 Modifier un article 1 Lister les couleurs 1 Ajouter un couleur 1 Modifier un couleur 2 Lister les marques 1 Ajouter une marque 2 Modifier une marque 2 Lister les tailles 2 Ajouter une taille 2 Modifier une taille 3
  • 61. 45 Figure 3.9 : Diagramme des cas d’utilisation du second sprint (release 1) II.1.2. Description textuelle des cas d’utilisation Nous allons maintenant décrire chacun des cas d’utilisation énuméré dans le paragraphe précédent en identifiants les acteurs et les différents scénarios possible. A. Cas d’utilisation : Gestion des articles  Description textuelle du cas d’utilisation« Ajouter un article » (voir Tableau 3.12) Tableau 3.12 : Description textuelle du cas d’utilisation «ajouter un article» Cas d’utilisation Ajouter un article Acteurs Administrateur Pré-condition Une authentification préalable Formulaire d’ajout disponible Post-condition La liste des articles est affichée sur l’écran Scénario nominal 1-l’administrateur demande le formulaire d’ajout
  • 62. 46 2-le système affiche les formulaires 3-l’administrateur rempli les champs nécessaire et valide 4-le système enregistre le nouvel article et affiche un message de succès Scénario alternatif 2-a-aucun résultat 2-a-1- le système affiche un message de type « aucun résultat trouvé » 4-a-l’administrateur saisie des données manquantes 4-a-1- le système affiche un message d’erreur 4-a-2-reprise de l’étape 1 du scénario nominal 4-b-l’article existe déjà 4-b-1-le système demande à l’administrateur de Modifier les données saisies 4-b-2-reprise de l’étape 3 du scénario nominal B. Cas d’utilisation : Gestion des Tailles  Description textuelle du cas d’utilisation «supprimer une taille » (voir Tableau 3.13) Tableau 3.13 : Description textuelle du cas d’utilisation «supprimer une taille» Cas d’utilisation Supprimer une taille Acteurs Administrateur Pré - condition Une authentification préalable La taille existant Post - condition La liste des tailles est affichée sur l’écran Scénario nominal 1-l’administrateur choisi la taille à supprimer 2- le système affiche un message de
  • 63. 47 confirmation 3-l’administrateur valide son choix 4-le système supprime la taille 5-le système affiche un message de succès Scénario alternatif 3-a-l’administrateur annule son choix 3-a-1-le système annule la suppression C. Cas d’utilisation : Gestion des marques  Description textuelle du cas d’utilisation «modifier une marque» (voir le Tableau 3.14) Tableau 3.14 : Description textuelle du cas d’utilisation «modifier une marque» Cas d’utilisation Modifier une marque Acteurs Administrateur Pré-condition Une authentification préalable La marque existant Post-condition Les informations ont bien été mises à jour Scénario nominal 1-l’administrateur choisi la marque à modifier 2-le système affiche le formulaire de modification 3-l’administrateur modifie les informations et valide 4-le système vérifie les données saisies 5-le système enregistre les données et affiche un message de succès Scénario alternatif 4-a-l’administrateur saisie des données manquantes 4-a-1-le système affiche un message d’erreur 4-a-2-reprise de l’étape 3 du scénario nominal
  • 64. 48 4-b- le libellé d’une marque existe déjà 4-b-1-le système demande à l’administrateur de modifier les données saisies 4-b-2-reprise de l’étape 3 du scénario nominal C. Cas d’utilisation : Gestion des Couleurs  Description textuelle du cas d’utilisation «chercher un couleur » (voir Tableau 3.15) Tableau 3.15 : Description textuelle du cas d’utilisation «chercher un couleur» Cas d’utilisation Chercher un couleur Acteurs Administrateur, Agent comptable, Vendeur Pré-condition Une authentification préalable Formulaire de recherche disponible Post-condition La liste des couleurs est affichée sur l’écran Scénario nominal 1-l’acteur saisi les critères de recherche 2-le système cherche les couleurs répondants aux critères mentionnés 3-le système affiche la liste des couleurs Scénario alternatif 2-a-aucun résultat 2-a-1- le système affiche un message de type « aucun résultat correspondant à vos critères, essayer de nouveau » 2-a-2-reprise de l’étape 1 du scénario nominal II.2. Conception A ce niveau, nous commençons par le diagramme de séquence système des différents cas d’utilisation déjà détaillés dans la section précédente.
  • 65. 49 II.2.1. Diagramme de séquence système En nous référant aux descriptions textuelles dans la section précédente, nous présentons les diagrammes de séquences systèmes adéquats. Sur la base de ces descriptions, nous pouvons constater que certains cas d’utilisations sont similaires à l’instar de la consultation des couleurs, la consultation des taille, etc. c’est pour cette raison que nous avons choisir de sélectionner quelques exemples. A. Diagramme de séquence système du cas d’utilisation «consulter la liste des articles» Le cas d’utilisation consulter la liste des articles (voir figure 3.10) est similaire au cas d’utilisation suivant: consulter la liste des couleurs, consulter la liste des taille, consulter la liste des marques. Figure 3.10 : Diagramme de séquence système du cas d’utilisation «consulter la liste des articles» B. Diagramme de séquence système du cas d’utilisation « ajouter un article» : L’ajout d’un article (voir Figure 3.11) est similaire au cas d’utilisation suivant: ajouter un couleur, ajouter une marque et ajouter une taille.
  • 66. 50 Figure 3.11 : Diagramme de séquence système du cas d’utilisation «ajouter un article»
  • 67. 51 II.2.2. Diagramme des classes Après tout le travail de spécification et de conception, nous pouvons maintenant construire le nouvel incrément de notre diagramme des classes en ajoutant les différents éléments (classes, associations, attributs, etc.) déduits à partir des activités précédentes (voir figure 3.12) Figure 3.12 : Diagramme des classe du second sprint (release 1) II.3.Codage Après avoir construit le nouveau diagramme de classe pour ce sprint et en appliquant les règles de passage vers le schéma logique de l’application, nous obtenons le schéma de la base de données illustré par les Tableaux (Tableau 3.16, Tableau 3.17, Tableau 3.18, Tableau 3.19)
  • 68. 52 Champs Types Contraintes ART_CODE VARCHAR(20) PRIMARY KEY ART_LIBELLE VARCHAR(20) --- ART_BARRE VARCHAR(20) --- CAT_CODE VARCHAR(20) NOT NUL SCAT_CODE VARCHAR(20) FOREIGN KEY FAM_CODE VARCHAR(20) FOREIGN KEY TAILLE_CODE VARCHAR(20) FOREIGN KEY MARQ_CODE VARCHAR(20) FOREIGN KEY STK_ALRT NUMBER(10) --- Tableau 3.16 : Table «Article» Champs Types Contraintes TA_CODE VARCHAR(20) PRIMARY KEY TA_LIBELLE VARCHAR(20) --- Tableau 3.17 : Table «Taille» Champs Types Contraintes COU_CODE VARCHAR(20) PRIMARY KEY COU_LIBELLE VARCHAR(20) UNIQUE Tableau 3.18 : Table «Couleur» Champs Types Contraintes MRQ_CODE VARCHAR(20) PRIMARY KEY MRQ_LIBELLE VARCHAR(20) UNIQUE Tableau 3.19 : Table «Marque»
  • 69. 53 II.4. Test : En partant toujours du même principe que le sprint précédent, et en appliquant les bonnes pratiques d'ingénierie logicielle inspirée de la méthodologie extrême programming (XP), nous commençons par les tests unitaires de l'histoire utilisateur « ajouter un article » II.4.1. Tests unitaires : Dans ce paragraphe, nous testons toujours nos histoires utilisateur en utilisant la bibliothèque JUnit.  Test unitaire pur l’histoire « ajouter un article» Pour tester l’ajout d’un article, nous avons choisi de respecter la démarche suivante : 1. Ajouter un article 2. Récupérer le dernier article ajouté 3. Comparer les attributs de l’article ajouté et celles de l’article récupéré. La première capture écran (Figure 3.13) illustre le code source de la classe de test. Figure 3.13 : Code source de la classe de test pour l’histoire «ajouter un article»
  • 70. 54 La figure 3.14 illustre le cas de succès pour l’ajout d’un nouvel article .Cette figure nous montre que notre méthode est bien fonctionnelle. Figure 3.14 : Cas du succès de la classe de test pour l’histoire «ajouter un article» 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 et pourra être utilisé dans un environnement de production. Dans le chapitre qui suit, notre effort sera consacré pour produire un nouveau release couvrant les fonctionnalités de gestion de magasin et de faire des traitements .
  • 71. 55 Chapitre 4. Release 2 - Gestion de magasin & Faire des traitements Introduction Après avoir entamé le premier release de notre système informatique, nous pouvons maintenant nous lancer dans les travaux nécessaires pour produire le second release. En effet les méthodologies agiles, et Scrum en particulier, sont caractérisées par un rythme régulier. Tout au long de chapitre nous aurons deux sprints ayant la même vélocité que les sprints précédents, et nous allons traiter les histoires utilisateurs de ces derniers pour avoir à la fin de ce release une partie de logiciel, livrable et fonctionnel. I. Le premier sprint : En partant sur le même principe que les sprints précédents, nous commençons par définir le but de notre premier sprint pour ce release. Suite à une conversation entre le Product Owner et l’équipe Scrum, nous avons décidé le but suivant: « terminer la partie qui concerne la gestion de magasin. Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires inclure dans ce dernier. Le Tableau 4.1 résume donc le backlog de notre second sprint: Tableau 4.1 : Backlog du premier sprint (release 2) Histoire utilisateur Estimation Lister les vendeurs 1 Ajouter un vendeur 2 Modifier un vendeur 3
  • 72. 56 Lister les caisses 2 Ajouter une caisse 2 Modifier une caisse 3 Lister les clients 2 Ajouter un client 3 Modifier un client 2 Dans le Tableau 4.1, nous pouvons constater que les histoires utilisateur «supprimer un vendeur», «chercher une caisse» et « modifier un client » ne figurent pas dans le backlog de produit. En effet, notre backlog de produit initial ne couvre pas toutes les fonctionnalités requises et c’est pour cette raison que nous aurons des nouvelles fonctionnalités au fur et mesure de notre avancement. En plus, nous pouvons constater que les vélocités de nos histoires ont changé par rapport à l’estimation initiale tout en gardant la même durée que le sprint précédent. I.1. Spécification fonctionnelle : La spécification fonctionnelle dans notre cas se traduit par le diagramme des cas d’utilisation d’UML et la description textuelle de ces derniers. I.1.1. Diagramme des cas d’utilisation Dans la Figure 4.1 nous illustrons le diagramme des cas d’utilisation global pour ce second sprint. En respectant toujours le même principe que le sprint précédent, nous avons découpé certaines histoires utilisateurs en un ensemble de tâches.
  • 73. 57 Figure 4.1 : Diagramme des cas d’utilisation du premier sprint (release 2) I.1.2. Description textuelle des cas d’utilisation : Pour rendre notre diagramme des cas d’utilisation plus lisible et afin de décrire le comportement de notre système, nous présentons la description textuelle des principaux cas d’utilisation. A. Cas d’utilisation : Gestion des vendeurs  Description textuelle du cas d’utilisation « consulter la liste des vendeurs» (voir tableau 4.2)
  • 74. 58 Tableau 4.2 : Description textuelle du cas d’utilisation «consulter la liste des vendeurs» Cas d’utilisation Consulter la liste des vendeurs Acteurs Administrateur, Agent comptable, Vendeur Pré - condition Une authentification préalable Post - condition La liste des vendeurs est affichée sur l’écran Scénario nominal 1-l’acteur demande l’affichage de la liste des vendeurs 2-le système affiche la liste des vendeurs Scénario alternatif 2-a-aucun résultat 2-a-1- le système affiche un message de type « aucun résultat trouvé » B. Cas d’utilisation : Gestion des Caisses  Description textuelle du cas d’utilisation « supprimer une caisse » (voir Tableau 4.3) Tableau 4.3 : Description textuelle du cas d’utilisation «supprimer une caisse» Cas d’utilisation Supprimer une caisse Acteurs Administrateur Pré - condition Une authentification préalable La caisse existant Post - condition La liste des caisse est affichée sur l’écran Scénario nominal 1-l’administrateur choisi la caisse à supprimer 2- le système affiche un message de confirmation 3-l’administrateur valide son choix 4-le système supprime la caisse 5-le système affiche un message de succès Scénario alternatif 3-a-l’administrateur annule son choix 3-a-1-le système annule la suppression
  • 75. 59 C. Cas d’utilisation : Gestion des Clients  Description textuelle du cas d’utilisation « ajouter un client»(voir Tableau 4.4) Tableau 4.4 : Description textuelle du cas d’utilisation «ajouter un client» Cas d’utilisation Ajouter un client Acteurs Administrateur Pré-condition Une authentification préalable Formulaire d’ajout disponible Post-condition La liste des clients est affichée sur l’écran Scénario nominal 1-l’administrateur demande le formulaire d’ajout 2-le système affiche les formulaires 3-l’administrateur rempli les champs nécessaire et valide 4-le système enregistre le nouveau client et affiche un message de succès Scénario alternatif 2-a-aucun résultat 2-a-1- le système affiche un message de type « aucun résultat trouvé » 4-a-l’administrateur saisie des données manquantes 4-a-1- le système affiche un message d’erreur 4-a-2-reprise de l’étape 1 du scénario nominal 4-b- le client existe déjà 4-b-1-le système demande à l’administrateur de Modifier les données saisies 4-b-2-reprise de l’étape 3 du scénario nominal
  • 76. 60 I.2. Conception : Dans cette section nous commençons par le diagramme de séquence système des différents cas d’utilisation déjà détaillés dans la section précédente. I.2.1. Diagramme de séquence système En nous référant aux descriptions textuelles dans la section précédente, nous présentons les diagrammes de séquences systèmes adéquats. Sur la base de ces descriptions, nous pouvons constater que certains cas d’utilisations sont similaires à l’instar de la consultation des vendeurs, la consultation des caisses, etc. c’est pour cette raison que nous avons choisir de sélectionner quelques exemples. A. Diagramme de séquence système du cas d’utilisation « supprimer une caisse» Le cas d’utilisation supprimer une caisse est similaire au cas d’utilisation supprimer un vendeur. (Voir Figure 4.2) Figure 4.2 : Diagramme de séquence «supprimer une caisse»
  • 77. 61 B. Diagramme de séquence système du cas d’utilisation « chercher un client» Pour chercher un client, l’administrateur doit s’authentifier dans un premier lieu en utilisant son login et son mot de passe. Par la suite, il choisit les critères de recherche correspondant à ces besoins (voir figure 4.3). Figure 4.3 : Diagramme de séquence «chercher un client» I.2.2. Le diagramme des classes : Après tous le travail de spécification et de conception, nous pouvons maintenant construire le nouvel incrément de notre diagramme des classes en ajoutant les différents éléments (classes, associations, attributs, etc.) déduits à partir des activités précédente. (voir Figure 4.4).
  • 78. 62 Figure 4.4 : Diagramme de classe du premier sprint (release 2) I.3. Codage : Après avoir construit le nouveau diagramme de classe pour ce sprint et en appliquant les règles de passage vers le schéma logique de l’application, nous obtenons le schéma de la base de données suivant (voir Tableau 4.5, Tableau 4.6, Tableau 4.7).
  • 79. 63 Champs Types Contraintes VND_CODE VARCHAR(20) PRIMARY KEY VND_NAME VARCHAR(20) --- VND_QUALITE VARCHAR(20) --- CODE_CLES VARCHAR(20) FOREIGN KEY VND_EMAIL VARCHAR(20) UNIQUE VND_CIN VARCHAR(20) NOT NULL Tableau 4.5 : Table «Vendeur» Champs Types Contraintes CA_CODE VARCHAR(20) PRIMARY KEY TA_LIBELLE VARCHAR(20) --- CA_PRIX NUMBER(10) NOT_NULL CA_TVA NUMBER(10) Tableau 4.6 : Table «Caisse» Champs Types Contraintes CLT_CODE VARCHAR(20) PRIMARY KEY CLT_NAME VARCHAR(20) NOT NULL CLT_EMAIL VARCHAR(20) UNIQUE CLT_CIN NOT NULL Tableau 4.7 : Table «Client»
  • 80. 64 I.4. Test : En partant toujours du même principe que les sprints précédents, et en appliquant les bonnes pratiques d’ingénierie logicielle inspirée de la méthodologie extrême programming (XP), nous commençons par les tests unitaires de l‘histoire utilisateur «modifier une caisse» I.4.1. Test unitaire Dans ce paragraphe, nous testons toujours nos histoires utilisateur en utilisant la bibliothèque JUnit.  Test unitaire pour l’histoire «modifier un vendeur» Pour tester la modification d’une caisse, nous avons choisi de respecter la démarche suivante: 1. Modifier le vendeur 2. Récupérer le vendeur modifié 3. Vérifier que les champs ont bien été changés La capture d’écran (Figure 4.5) suivante illustre le code source de notre classe de test Figure 4.5 : Code source de la classe de test pour l’histoire «modifier un vendeur»
  • 81. 65 La capture écran suivante illustre le cas de succès pour la modification d’une caisse. La figure (4.6) nous montre que notre méthode est bien fonctionnelle. Figure 4.6 : Cas de succès pour la modification d’un vendeur II. Le deuxième sprint : En partant sur le même principe que les sprints précédents, nous commençons par définir le but de notre second sprint. Suite à une conversation entre le Product Owner et l’équipe Scrum, nous avons décidé le but suivant: « terminer la partie qui concerne Faire traitement ». Une fois, nous avons défini le but de notre sprint, il est temps de décider quelles histoires inclure dans ce dernier. Le Tableau 4.8 résume donc le backlog de notre second sprint:
  • 82. 66 Tableau 4.8 : Backlog de second sprint (release 2) II.1. Spécification fonctionnelle : Pour la spécification fonctionnelle de ce sprint, nous commençons par le diagramme des cas d’utilisation. II.1.1. Diagramme des cas d’utilisation Dans la Figure 4.7 nous illustrons le diagramme des cas d’utilisation global pour ce second sprint. En respectant toujours le même principe que le sprint précédent, nous avons découpé certaines histoires utilisateurs en un ensemble de tâches. Figure 4.7 : Diagramme des cas d’utilisation du second sprint (release 2) Histoire utilisateur Estimation Lister les services 1 Modifier un service 2 Clôturer un service 2 Chercher un service 2 Lister les ticket 2 Modifier un ticket 3 Chercher un ticket 2 Annuler un ticket 3 Consulter état stock 2
  • 83. 67 II.1.2. Description textuelle des cas d’utilisation Nous allons maintenant décrire chacun des cas d’utilisation énuméré dans le paragraphe précédent en identifiants les acteurs et les différents scénarios possible. A. Cas d’utilisation : Gestion des Tickets  Description textuelle du cas d’utilisation« Annuler un ticket » (voir Tableau 4.9) Tableau 4.9 : Description textuelle du cas d’utilisation «Annuler un ticket» Cas d’utilisation Annuler un ticket Acteurs Administrateur Pré-condition Une authentification préalable Formulaire de recherche disponible Post-condition La liste des tickets est affichée sur l’écran Scénario nominal 1-l’administrateur demande d’annuler un ou plusieurs tickets(s). 2-le système affiche la liste complète de ticket (par défaut de jour actuelle) 3-l’administrateur sélectionne les tickets et valider. 4 – Le système annule les tickets et affiche un message de réussite. Scénario alternatif 2-a-aucun résultat 2-a-1- le système affiche un message de type « aucun résultat trouvé » 4-a-l’administrateur saisie des données manquantes 4-a-1- le système affiche un message d’erreur 4-a-2-reprise de l’étape 1 du scénario nominal