Vous êtes sur la page 1sur 86

Table des matières

Introduction générale 1

1 Cadre général de projet 2


1.1 Présentation de l’organisme d’accueil.......................................................................3
1.2 Présentation de projet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3 Étude de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.1 Présentation de l’étude de l’éxistant . . . . . . . . . . . . . . . . . . . . . . .
4
1.3.2 Critiques de l’éxistant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
1.4 Solution proposée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.5 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.6 Méthodologie adoptée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.6.1 Choix de la méthodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
1.6.2 Présentation de SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
1.6.3 Les rôles SCRUM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9

2 Sprint 0 1
1
2.1 Capture des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. 1
2
2.1.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2.1.2 Identification des besoins . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
2.2 Pilotage du projet avec Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
4
2.2.1 Les fonctionnalités du backlog . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
4
2.2.2 Diagramme des cas d’utilisation global . . . . . . . . . . . . . . . . . . . . . .
1
7
2.2.3 Planification des sprints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
8
2.2.4 Prototypage des interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
9
2.3 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1
2.3.1 Environnement matériel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1
2.3.2 Environnement de développement . . . . . . . . . . . . . . . . . . . . . . . .
2
1
2.3.3 Environnement logiciel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1
2.4 Architecture générale de l’application . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3

iii
2.4.1 Architecture physique...................................................................................24
2.4.2 Fonctionnement de l’architecture...................................................................25
2.4.3 Spécification logicielle du système................................................................25
2.5 Diagramme de déploiement......................................................................................25

3 Étude et réalisation du Sprint 1 27


3.1 Backlog du sprint......................................................................................................28
3.2 Spécification fonctionnelle.........................................................................................28
3.2.1 Diagramme de cas d’utilisation......................................................................29
3.2.2 Description textuelle des cas d’utilisations....................................................29
3.3 Conception............................................................................................................... 32
3.3.1 Diagrammes des séquences détaillés..........................................................32
3.3.2 Diagramme de Classes.................................................................................35
3.4 Réalisation................................................................................................................36
3.4.1 Interface d’authentification.............................................................................36
3.4.2 Interface de Création d’un modèle de cycle de vie d’un colis........................37
3.5 Test........................................................................................................................... 38

4 Étude et réalisation du Sprint 2 40


4.1 Backlog du sprint......................................................................................................41
4.2 Spécification fonctionnelle.........................................................................................41
4.2.1 Diagramme de cas d’utilisation......................................................................41
4.2.2 Description textuelle des cas d’utilisations....................................................42
4.3 Conception................................................................................................................ 45
4.3.1 Diagrammes des séquences détaillés...........................................................45
4.3.2 Diagramme de Classes.................................................................................47
4.4 Réalisation................................................................................................................49
4.4.1 Interface d’affichage de la liste des colis.......................................................49
4.4.2 Interface de recherche d’un colis...................................................................50
4.5 Test........................................................................................................................... 51

5 Étude et réalisation du Sprint 3 53


5.1 Backlog du sprint......................................................................................................54
iv
5.2 Spécification fonctionnelle.........................................................................................54
5.2.1 Diagramme de cas d’utilisation.....................................................................54
5.2.2 Description textuelle de cas d’utilisation........................................................55
5.3 Conception................................................................................................................ 58
5.3.1 Diagrammes des séquences détaillés...........................................................58
5.3.2 Diagramme de Classes.................................................................................63
5.4 Réalisation............................................................................................................... 64
5.4.1 Interface de Consultation des détails de colis avec son état courant.............64
5.4.2 Interface de Consultation les événements et les états...................................65
5.4.3 Interface d’ajout une action...........................................................................65
5.4.4 Interface d’envoi un mail au client.................................................................65
5.5 Test........................................................................................................................... 66

Conclusion générale 68

Bibliographie 69
Table des figures

1.1 Cycle de vie SCRUM.................................................................................................8

2.1 Diagramme des cas d’utilisation global......................................................................18


2.2 Planning des sprints..................................................................................................19
2.3 Maquette d’affichage liste colis..................................................................................19
2.4 Maquette de recherche Colis.....................................................................................20
2.5 Maquette de consultation le Cycle de colis................................................................20
2.6 Code First Approach [14]...........................................................................................23
2.7 Architecture globale de l’application..........................................................................24
2.8 Architecture asp.net MVC 5 de l’application..............................................................25
2.9 Diagramme de déploiement.......................................................................................26

3.1 Diagramme de cas d’utilisation global de sprint1.......................................................29


3.2 Diagramme de séquence de l’opération « Créer un modèle»....................................33
3.3 Diagramme de séquence de l’opération « Ajouter des états et des événements».....34
3.4 Diagramme de séquence de l’opération « Consulter les états et les événements du
modèle»
35
3.5 Diagramme de classe du Sprint 1..............................................................................35
3.6 Interface d’authentification.........................................................................................36
3.7 Interfaces de modélisation de l’état retrait.................................................................37
3.8 Interfaces de modélisation de l’état Dépôt.................................................................37
3.9 Interfaces de Consultation des états et des événements du modèle »......................38
3.10 Interfaces de Confirmation de l’enregistrement des états..........................................38

4.1 Diagramme de cas d’utilisation global de sprint2.......................................................42


4.2 Raffinement du cas d’utilisation «Modifier l’état de colis»..........................................43
4.3 Diagramme de séquence de l’opération « Afficher liste colis»...................................45
4.4 Diagramme de séquence de l’opération « Afficher liste colis par état»......................46
4.5 Diagramme de séquence détaillé « Rechercher colis ».............................................47
4.6 Diagramme de classe du Sprint 1..............................................................................48

vi
4.7 Interface d’affichage de la liste des colis..................................................................49
4.8 Interface Filter liste des colis par état.......................................................................49
4.9 Interface Sélectionner un état existant......................................................................50
4.10 Interface de recherche de colis.................................................................................50
4.11 Interface d’affichage de détails de colis....................................................................51

5.1 Diagramme de cas d’utilisation globale de sprint 3...................................................55


5.2 Diagramme de séquence de l’opération «Consulter l’état courant du colis».............59
5.3 Diagramme de séquence de l’opération «Consulter les événements du colis».........60
5.4 Diagramme de séquence de l’opération «Consulter les états du colis»....................61
5.5 Diagramme de séquence de l’opération «Ajouter une action»..................................62
5.6 Diagramme de séquence de l’opération «Envoyer un mail au client».......................63
5.7 Diagramme de classe du Sprint 3.............................................................................64
5.8 Interface de Consultation des détails de colis avec son état courant........................64
5.9 Interface de Consultation des états et des événements...........................................65
5.10 Interface d’ajout une action.......................................................................................65
5.11 Interface d’envoi un mail au client............................................................................66

vii
Liste des tableaux

1.1 Domaines de l’entreprise...........................................................................................3


1.2 Comparaison entre méthodes agiles et méthodes classiques...........................................7
1.3 Rôles SCRUM........................................................................................................... 9

2.1 Acteurs et rôles de l’application.................................................................................12


2.2 Besoin fonctionnels...................................................................................................13
2.3 Acteurs du projet.......................................................................................................14
2.4 Backlog du produit....................................................................................................15

3.1 Backlog du sprint 1....................................................................................................28


3.2 Description textuelle du cas d’utilisation « Créer un modèle»....................................29
3.3 Description textuelle du cas d’utilisation « Ajouter des états et des événements».....30
3.4 Description textuelle du cas d’utilisation « Consulter les états et les événements»...31
3.5 Description des classes participantes dans la première Sprint..................................36
3.6 Tests du sprint 1........................................................................................................38

4.1 Backlog du produit....................................................................................................41


4.2 Description textuelle du cas d’utilisation « Afficher la liste des colis»........................42
4.3 Description textuelle du cas d’utilisation «Afficher liste des colis par état»................43
4.4 Description du cas d’utilisation «Choisir un état existant».........................................44
4.5 Description textuelle du cas d’utilisation «Rechercher colis »....................................44
4.6 Description de classes participantes dans le Sprint 2................................................48
4.7 Tests du sprint 2........................................................................................................51

5.1 Backlog du sprint3.....................................................................................................54


5.2 Description textuelle du cas d’utilisation « Consulter l’état en cours du colis »..........55
5.3 Description textuelle du cas d’utilisation «Consulter les événements»......................56
5.4 Description textuelle du cas d’utilisation «Consulter les états»..................................56
5.5 Description du cas d’utilisation «Ajouter une action»................................................57
5.6 Description du cas d’utilisation «Envoyer un mail au client»......................................57
5.7 Tests du sprint 3........................................................................................................66

viii
Introduction générale

L’amélioration de la qualité de services est un challenge que toute entreprise dans le


domaine professionnel cherche à atteindre. Afin d’y parvenir, il est primordial d’utiliser de
nouvelles technologies d’informations et de communications afin d’améliorer, d’une part, le
fonctionnement et la visibilité des entreprises, et d’autre part, garantir la fidélité des clients.
Pour ces raisons, les entreprises de transport et de logistique visent à s’investir pour utiliser les
nouvelles technologies afin d’améliorer leurs services notamment le service de transport de colis
(Envoi et livraison du colis).Ceci permet d’améliorer efficacement leurs travails avec les partenaires.
Dans ce contexte, la société SMIRI engineering, nous a confié de mettre en place un système pour
les sociétés de transport de colis qui a comme principe fondateur de construire une application
informatique de gestion de cycle de vie d’un colis de manière modulaire (module applicatifs
indépendants entre eux généralement) tout en partageant une base de données unique afin
d’automatiser les différents états du colis et de gérer ses événements.
Le présent rapport se focalise à la description des différentes phases de la réalisation de
notre projet. Il a pour but de situer le cadre générale du projet, de décrire son sujet, de présenter
les méthodes, outils et technologies ainsi que les résultats obtenus. En effet, il est organisé en
cinq chapitres.
Le premier chapitre, intitulé cadre générale du projet sera consacré à la description du
l’organisme d’accueil et du projet, avec une étude des problématiques avec les solutions
proposées, ensuite nous présenterons une comparaison entre quelques méthodologies de
conception.
Le deuxième chapitre, intitulé Sprint 0, nous nous intéressons à définir le backlog produit, et à
présenter une vue architecturale et conceptuelle globale de notre application. C’est également à
ce niveau que nous présenterons les outils et technologies utilisés pour le développement.
Les trois derniers chapitres, se concentreront sur l’étude et la réalisation des sprints de notre
projet. Dans chaque sprint, nous commencerons, par le « Backlog du Sprint » qui décrit les
tâches à faire et ensuite nous présenterons le diagramme de classe et les diagrammes de
séquence. Enfin, nous illustrerons l’exécution de notre application par des captures écrans.
Finalement, nous clôturerons ce rapport par une conclusion générale dans laquelle nous
évaluerons notre travail ainsi que les objectifs atteints, et nous présenterons les perspectives
éventuelles de notre projet.

1
Chapitre 1

CADRE GÉNÉRAL DE PROJET

Pla
n
1 Présentation de l’organisme d’accueil....................................3
2 Présentation de projet...........................................................4
3 Étude de l’existant................................................................4
4 Solution proposée.................................................................6
5 Objectifs...............................................................................6
6 Méthodologie adoptée...........................................................7
Chapitre 1. Cadre général de projet

Introduction

Dans ce chapitre, nous commençons par présenter l’organisme d’accueil de notre projet.
Ensuite, nous décrivons l’étude de l’existant ainsi que ses limites afin de déduire la solution
proposée. A la fin de ce chapitre, nous exposons la méthodologie qui a conduit à la réalisation
de notre projet.

1.1 Présentation de l’organisme d’accueil

SMIRI Engineering est une société à responsabilité limitée, crée en Janvier 2011 par des
ingénieurs et de gestionnaires qui ont une expérience qualifié en moyenne de 19 ans.
SMIRI Engineering est un bureau d’étude Technique Tunisien qui met le savoir-faire de ses ingénieurs
à la disposition de tout client pour la recherche des solutions Techniques dans les domaines
Informatique, Design, Electronique et Environnement [1].
Ces domaines sont illustrés dans le tableau 1.1.

Tableau 1.1: Domaines de l’entreprise

Domaine Description Services


Domaines Praxis C’est le domaine de - Ingénierie logicielle : Intégration
développement software inter-application, solution web
et solution web statique, site web dynamique,
solution mobile, système
complexe...
- Consulting : Pilotage des projets,
augmentation de performance, audit
software.
- Infogérance : Mise en place,
exploitation et évolution de votre
système d’information
Domaine C’est le domaine Design Graphique, Traitement
SEDesign
de l’infographie D’image, Conception Impression,
et l’art de Animation 3D,
l’animation. Media, Edition de contenu.

3
Domaine ISI C’est le domaine de Conception des cartes électroniques
l’électronique et des (analogique, acquisition, numérique
solutions industrielles. ou combiné), Réalisation de PCB
échantillons, Conception système
embarqué, Conception de machine
industrielle spécifique sur mesure,
Programmation automates.

1.2Présentation de projet

La distribution de colis entre les partenaires d’une entreprise nécessite une chaine
logistique complexe.Dans ce cadre,notre projet consiste à développer une application web de
gestion de cycle de vie d’un colis. Cette application permet de faciliter le service d’envoi et de
livraison du produit et de suivi les états clés de l’acheminement du colis à tout moment pour les
destinataires et les expéditeurs.

1.3Étude de l’existant

1.3.1 Présentation de l’étude de l’éxistant

L’étude de l’existant est une phase importante pour bien comprendre le système actuel,
définir ses objectifs et dégager les problématiques et les vrais besoins de l’entreprise.
Dans le système actuel, le cycle de vie d’un colis est constitué de plusieurs étapes qui sont gérés
manuellement.Ces étapes sont distingués en deux états globaux :

A) Etat 1 : retrait

1.le client commande sur internet et choisi de retirer son colis en point relais.

2.Le chargeur prépare le colis dans son entrepôt et créé son étiquette. Il est pris en

charge par le transporteur.

3.Le transporteur dépose le colis en centre de tri. Le lendemain un transporteur le

prendra en charge.

4.Le colis arrive en agence au plus près de son point de livraison finale et le

transporteur prend en charge le colis.


5.Le transporteur va livrer le colis en point relais

6.Le transporteur livre les colis au PUDO (PickUp DropOff). Il scanne en livraison et le

PUDO scanne en réception.

7.Lors du scan de réception du colis, un SMS et un mail sont envoyés au client pour le

prévenir de l’arrivée du colis en relais.

8.Le client vient récupérer son colis en point relais : Le PUDO scanne le colis en retrait

et le client signe sur le Smartphone.

B) Etat 2 : dépôt

1.Le client imprime une étiquette retour (ou colle celle fournie par l’expéditeur).

2.Le client vient déposer son colis avec son étiquette en point relais. Le PUDO le

scanne en dépôt.

3.Le PUDO place le colis en zone retour en attendant que le livreur vienne l’enlever.

4.Le transporteur vient enlever les colis placés en zone Retour. Le PUDO scanne tous

les colis en enlèvement. Le transporteur les scanne également en collecte.

5.Le transporteur dépose les colis en agence. Ils repartiront chez l’expéditeur en

passant par des centres de tri et des agences de distribution.

1.3.2 Critiques de l’éxistant

Le processus de gestion de cycle de vie d’un colis pose un grand problème que ce soit
pour les partenaires ou pour les clients surtout durant une période où le service est
particulièrement surchargé.
Les principaux problèmes relevés sont :
• Cycle de vie d’un colis non modélisé.
• Le système ne contient un service pour suivi l’acheminement des colis.
• Il n’existe pas un moyen d’envoyer des notifications au email pour communique avec les
clients.

• risque de colis perdus, ouverts, très en retard.


• Le processus de suivi le colis n’est pas automatisé.
• Il n’existe pas un moyen de notifier le transporteur et les agences de distributions à chaque
nouvel évènement effectué.
Pour accomplir ces points et satisfaire les nouvelles fonctionnalités, nous avons réalisé
un système informatique qui doit être mis en place pour optimiser et automatiser le processus.

1.4 Solution proposée

Pour remédier aux problèmes déjà mentionnés, l’entreprise doit utiliser des outils
optimisés et adaptés facilitant les tâches et offrant des fonctionnalités riches et utiles. Parmi ces
outils nous proposons un système de gestion de cycle de vie des produits qui permet de :
• Création d’un workflow (Cycle de vie) du colis
Cette fonctionnalité permet de modéliser le cycle de vie d’un colis, graphiquement (Drag and
Drop).Chaque étape du cycle de vie déclenche un ou plusieurs événements.Un évènement peut
être :
- une notification par mail,
- un appel à un service Web,
- une communication avec le MOM (Middleware Orienté Message) RabbitMQ,
- création de formulaire pour traiter un événement,
• Affichage de la liste des colis
Cette fonctionnalité permet d’afficher la liste des colis et de les filtrer par leurs Etats. Cette liste
permet aussi de modifier directement l’état d’un colis en tenant compte la sauvegarde de
l’historique des états du colis.
• Recherche de colis
Cette fonctionnalité nous aide à rechercher un colis et d’afficher tous ses détails : Encours et tracing.
- Encours : Fichier envoyé par l’expéditeur qui contient toutes les informations sur le colis.
- Tracing : Fichier qui contient les informations sur le cycle de vie du colis.

1.5Objectifs

Notre application a pour objectifs :


• d’éviter les pertes de temps dans la gestion et le suivi de l’acheminement de colis,
• d’informer le transporteur et les agences de distribution à chaque nouvel évènement,
• d’automatiser le suivi de colis au sein de l’entreprise,
• de modéliser le cycle de vie d’un colis graphiquement,
• de gérer les colis,
• de faciliter la recherche des détails de chaque colis,
• de consulter le changement d’état d’un colis à tout moment,
• de notifier le client par mail ou SMS pour la réception de son colis,

1.6 Méthodologie adoptée

Avant la réalisation d’un projet informatique, il est nécessaire de choisir une méthodologie
de travail et un procès de suivi afin d’aboutir à la fin à un logiciel fiable. Cette méthodologie
présente un procédé qui a pour objectif de permettre de formaliser les étapes préliminaires du
développement d’un système afin de rendre ce développement plus fidèle aux besoins du client.

1.6.1 Choix de la méthodologie

Afin de fixer une méthode particulière, nous avons effectué une étude comparative entre
les méthodes classiques et la méthode agile. Nous présentons dans le tableau 1.2 un
comparatif entre l’approche classique et l’approche agile [2].

Tableau 1.2: Comparaison entre méthodes agiles et méthodes classiques

Approche classique Approche Agile


Cycle de vie Phases séquentielles Itératif et incrémentale
Planification Prédictive Adaptative
Changement Résistance au changement. Accueil favora a
Processus
changem ble u
lourds de gestion des changements
ent le inté da
acceptés.
processus gré ns
Gestion des Processus e rigoure d Gestion des risques
t ux e intégrée
risques district
dans le processus global.
gestion des
risques.
Mesure des Respect des engagements initiaux Satisfaction du client par la
succès en termes de couts, de budget et de livraison de valeur
niveau souhaitée.
de qualité.
Equipe Equipe avec ressources Equipe
spécialisés
responsabilisée,
dirigées par un chef de projet
soutenue par le chef de
projet
Qualité Contrôle qualité à la fin de cycle de Contrôle qualité permanant
développement. au niveau du produit et du
processus.
D’après la comparaison faite à la sous-section précédente, nous pouvons remarquer que
si le domaine du projet est maîtrisé, un cycle de vie en cascade suffit. En cas où, nous ne
pouvons pas tout prévoir dès le début ou si les besoins sont incomplets comme dans notre cas,
il faut utiliser les méthodes itératives et incrémentales telles que les méthodes agiles.
Une méthode Agile garantit une meilleure qualité de communication avec l’utilisateur, une
meilleure visibilité du client sur l’avancement des travaux, un meilleur contrôle de qualité par le
fait que les tests sont effectués en continu, ce qui permet de détecter rapidement les problèmes.
Elle intègre aussi la notion de travail en équipe.
Parmi les méthodes Agiles, nous pouvons citer « SCRUM » qui sera utilisé dans la réalisation
de notre projet.

1.6.2 Présentation de SCRUM

Le principe de la méthode agile SCRUM est de concentrer l’équipe de développement


sur un ensemble de fonctionnalités à réaliser de façon itératif, dans des itérations d’une durée
de deux à quatre semaines, appelées des Sprints. Chaque Sprint doit aboutir à la livraison d’un
produit partiel [3].
La figure 1.1 illustre le cycle de vie SCRUM.

Figure 1.1: Cycle de vie SCRUM

Comme indiqué dans la figure ci-dessus, pour mettre en place la méthode SCRUM, il faut
dégager dans un premier lieu le maximum de 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ées dans chaque itération.
Par la suite, focaliser l’équipe de façon itérative sur l’ensemble des fonctionnalités à réaliser
dans des itérations appelées Sprints. Un sprint aboutit toujours à la livraison d’un produit partiel
fonctionnel appelé incrément. Ainsi, vers la fin de chaque Sprint, une réunion aura lieu pour
effectuer la revue de l’itération.
L’objectif de cette réunion consiste à valider l’incrément qui été produit pendant l’itération.

1.6.3 Les rôles SCRUM

SCRUM définit trois rôles principaux. Ces rôles seront expliqués dans le tableau 1.3

Tableau 1.3: Rôles SCRUM

Product Owner (Directeur du produit) il s’agit du représentant officiel du client au


sein d’un projet Scrum. Il est l’interlocuteur
principal du Scrum Master et des membres de
l’équipe. Il définit les besoins du produit et
rédige les spécifications. Il peut se faire aider
de responsables fonctionnels pour la rédaction
des spécifications. Il est également chargé de
définir et prioriser les
users stories pour chaque sprint.
Scrum (Mene d l’équip Il s’agit d’une personne chargée de veiller à la
ur e e,
Master mise en application de la méthode et au
facilitateur) respect de ses objectifs. Il ne s’agit pas d’un
chef de projet, mais d’une personne chargée
de lever les obstacles éventuels qui
empêcherait l’avancement de l’équipe et du
projet pendant les différents
sprints.
Développement Team (L’équipe) Ce sont les personnes chargées de la
réalisation du sprint et d’un produit utilisable
en fin de sprint. Il peut s’agir de développeurs,
architectes, personnes chargées de faire des
tests fonctionnels. L’équipe
s’adresse directement au client

Conclusion

Tout au long de ce chapitre, nous avons présenté l’organisme d’accueil et une brève
description du projet à réaliser, en déterminant la problématique et en proposant la solution
envisagée pour faire face à la situation actuelle. Par la suite nous avons présenté une étude de
quelques méthodologies de développement existants pour effectuer le choix de la méthodologie
qui sera adoptée pour le développement de notre système.
Le chapitre suivant sera consacré à l’étude des besoins fonctionnels et non
fonctionnels,la spécification du Backlog de produit et la préparation du planning de travail.
Chapitre 2

SPRINT 0

Pla
n
1 Capture des besoins..............................................................12
2 Pilotage du projet avec Scrum...............................................14
3 Environnement de travail.......................................................21
4 Architecture générale de l’application....................................23
5 Diagramme de déploiement...................................................25
Chapitre 2. Sprint 0

Introduction

Ce chapitre présente le sprint zéro qui représente le premier pas de réalisation de notre
projet.Tout d’abord, nous identifions les acteurs de notre application. Puis, nous listons les
besoins fonctionnelles et non fonctionnelles de notre système et nous détaillons le travail par la
méthodologie choisie dans le chapitre précédent En fin,nous donnons un bref aperçu sur le
matériel de base , les technologies et les langages de programmation utilisés pour la mise en
place de l’environnement de travail.

2.1 Capture des besoins

2.1.1 Identification des acteurs

Un acteur représente une entité externe qui interagit avec le système. En réponse à
l’action d’un acteur, le système fournit un service qui répond à ses besoins. Notre application
présente 5 acteurs identifiés dans le tableau 2.1.

Tableau 2.1: Acteurs et rôles de l’application

Acteur Rôle
Expéditeur Personne chargée de créer un nouvel envoi
Transporteur Il a pour mission d’acheminer chaque colis qui
lui
est confié au bon endroit, et effectuer les
scans de livraison.
Agent Point relais(PUDO) Il a pour mission de récupérer les mêmes
informations initialement fournis par l’appel de
création d’envoi
Client Il reçu un mail en livrasion de son colis
Administrateur Personne qui s’occupe de la modélisation de
cycle
de vie de vie d’un colis et de modifier son état

2.1.2 Identification des besoins

Notre application doit satisfaire les exigences de la totalité des utilisateurs. Nous
exposons dans ce qui suit leurs besoins fonctionnels ainsi que les besoins non fonctionnels
communs à tous les
12
acteurs.

2.1.2.1 Besoins fonctionnels

Les besoins fonctionnels doivent expliciter ceux du client. Dans notre cas, des besoins
exprimés par l’entreprise ont permis d’établir le cahier des charges suivant :

Tableau 2.2: Besoin fonctionnels

Objectif Description
Module de création d’un workflow du colis - Modéliser le cycle de vie d’un colis
- Mettre en place les événements en les
associant avec les étapes de workflow

Module de recherche d’un colis - rechercher un colis selon des critères


- Afficher le résultat de recherche : liste des
colis avec ses détails
Module de suivre le cycle du colis - Consulter l’état courant du colis
- Consulter les états du colis
- Consulter les événements du colis
- Ajouter une action
- Informer le client par mail
Module d’affichage de la liste des colis - Afficher la liste des colis
- Filtrer l’affichage par le libellé de l’état de
colis
- Modifier l’état de colis

2.1.2.2 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 :
• ergonomie : les interfaces utilisateur conviviales et faciles à utiliser par les novices.
• fiabilité : le fonctionnement de l’application doit être correct et ne contient pas des bugs.
• extensibilité : l’application doit faciliter l’ajout de nouvelles fonctionnalités au moindre
coût.
2.2 Pilotage du projet avec Scrum

Nous présentons dans cette sous-section l’ensemble des acteurs participants au déroulement
des différentes phases du projet et d’élaboration du rapport du stage. L’équipe de
développement est constituée, dans notre cas, d’une seule personne chargée de la réalisation
de projet de la conception au développement. Le Product Owner, qui est le représentant des
clients et des utilisateurs, définit les besoins, les priorités et les fonctionnalités et dirige l’activité
de l’équipe de développement. Le Scrum Master est l’orchestrateur ; il veille au bon déroulement
et la bonne ambiance de l’équipe projet.
Dans le tableau 2.3, nous présentons les rôles, les acteurs associés et leurs missions.

Tableau 2.3: Acteurs du projet

Role Mission Acteur


Scrum team - Conception Amira Ben hammouda
- Développement
- Tests et Validation
- Déploiement

Product - Définition du besoin et Nizar SMIRI


Owner des fonctionnalités à
Scrum développer,
Master - Approbation du projet

2.2.1 Les fonctionnalités du backlog

Le Backlog est un artéfact très important dans Scrum. C’est l’ensemble des
caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité [4].
Le tableau 2.4 présente le backlog de notre produit.
• ID qui représente l’identifiant de la use story,
• Catégorie pour diviser les user stories en deux catégories principales FrontOffice et Back-
office,
• Thème pour mieux ordonner les user stories comme exemple Gestion des clients,
• Scenario ou User Story comporte la description des user story suivant le forme « En
tant que . . . Je veux . . . »,
• La complexité de la réalisation de chaque user story est ceci selon la suite de
Fibonacci. Cette dernière est une suite d’entries, dont chaque terme est la somme de deux
précédents, en considérants les deux termes initiaux 0 et 1. Le début de cette suite est : 0, 1, 2,
3, 5, 8, 13 et l’infini [5].
• La priorité de la user story selon la valeur métier et l’ordre de réalisation.

Tableau 2.4: Backlog du produit

ID Thème User Story Priorité Compléxité


1 Authentification En 1 2

tant
qu’utilisateur, je
dois
m’authentifier
pour accéder à
l’application.
2 Modéliser Cycle En 2 5
de vie d’un colis tant
qu’administrateu
r je veux
modéliser le
cycle de
vie en
ajoutant
des
évènements
3 Modéliser Cycle En 1 5
de vie d’un colis tant
qu’administrateu
r je veux
ajouter des
états dans le
modèle
4 Modéliser Cycle En 3 8
de vie d’un colis
tant
qu’administrateu
r je veux
enregistrer les
états et
les
évènements dans
la base sql
5 Affichage liste En tant que 4 5
Colis
partenaire je
veux afficher la
liste des
Colis
6 Affichage liste En 6 5
Colis
tant
qu’administrateu
r je veux
modifier
l’état de colis
7 Affichage liste En tant que 5 4
Colis
partenaire je
veux afficher la
liste des
colis par état
8 Rechercher un En tant que 8 4
colis
partenaire je
veux chercher un
colis
selon des critères
9 Rechercher un En tant que 9 4
colis
partenaire je
veux afficher les
détails
de chaque colis
10 Suivre le cycle du En tant 13 4
colis que
partenaire je
veux
ajouter une action
11 Suivre le cycle du En tant que 12 8
colis partenaire je
veux envoyer un
message
au point relais
12 Suivre le cycle du En tant que 10 4
colis partenaire je
veux consulter
l’état
courant d’un colis
13 Informer le client En tant que 14 8
partenaire je
veux envoyer un
mail ou
SMS au client
14 Suivre le cycle du En tant que 11 4
colis partenaire je
veux consulter
les états
de colis
15 Suivre le cycle du En tant que 12 8
colis partenaire je
consulter les
événements d’un
colis

2.2.2 Diagramme des cas d’utilisation global

Nous présentons par la figure 2.1 une vue globale concernant le comportement
fonctionnel du système. Ce diagramme permet aussi de représenter les interactions entre les
acteurs et les cas d’utilisation du système.
La figure 2.1 représente le diagramme de cas d’utilisation global de notre système.
Figure 2.1: Diagramme des cas d’utilisation global

2.2.3 Planification des sprints

Une fois nous avons terminé le backlog du produit, nous avons établi la réunion de
planification. Le but de cette réunion est de construire le backlog de sprint en se basant sur le
backlog de produit réalisé par le product owner. A la fin, nous avons identifié, les durées
prévisionnelles du travail à effectuer durant chaque sprint. Pour notre projet nous avons devisé le
travail sur deux releases. Pour la premier contient un seul sprint d’une durée de 2 semaine alors
que le deuxième release contient deux sprints caractérisés chacun d’entre eux par une durée de
3 semaine.
La figure 2.2 montre la répartition des sprints relative à notre système.
Figure 2.2: Planning des sprints

2.2.4 Prototypage des interfaces

Le maquettage/prototypage est une étape nécessaire, il consiste à préparer des


interfaces du futur produit à l’aide de l’outil de maquettage Balsamiq. L’objectif principal de cette
technique c’est d’obtenir des informations sur l’interaction des utilisateurs avec le futur produit.
La figure 2.3 montre la maquette de la page qui permet d’afficher la liste des colis.

Figure 2.3: Maquette d’affichage liste colis


La figure 2.4 illustre la maquette de la page de recherche d’un colis.

Figure 2.4: Maquette de recherche Colis

La figure 2.5 représente la maquette de la page de consulter les états et les événements du
colis.

Figure 2.5: Maquette de consultation le Cycle de colis


2.3 Environnement de travail

2.3.1 Environnement matériel

Tout au long de notre projet, nous avons eu à notre disposition un ordinateur portable qui
dispose de la configuration suivante :
• Dell : Core i3 @ 1.80GHz, Ram : 4, 00 Go,
IntelⓍR
• Système d’exploitation : Windows 10,

2.3.2 Environnement de développement

Visual Studio 2015 : Visual Studio est un ensemble complet d’outil de développement
permettant de générer plusieurs types des applications Windows [6].

SQL SERVER 2016 : SQL Server est un système de gestion de base de données et
commercialisé par la société Microsoft .

SQL Server Management Studio 2012 : est un environnement intégré qui permet
d’avoir accès, de configurer, de gérer, d’administrer et de développer tous les composants de
SQL Server [7].

2.3.3 Environnement logiciel

ASP.NET MVC 5 [8] : est un ensemble de technologies de programmation Web


propriétaire créé par l’entreprise Microsoft. Les programmeurs peuvent utiliser ASP.NET pour
créer des sites Web dynamiques, des applications Web ou des Web services XML.ASP.NET fait
partie de la plateforme Microsoft .NET et est le successeur de la technologie Active Server
Pages (ASP) du même éditeur.
HTML5 [9] : définit deux syntaxes de DOM : HTML5 et XHTML5. Cette version apporte
de nouvelles possibilités en termes de création d’ « applications Web riches » bénéficiant de
l’intégration d’éléments multimédias et d’interactivité.

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

CSS3(Cascading StyleSheet) [11] :est un langage de style permettant d’améliore le


contenu des pages Web.
JQUERY [12] :C’est un Framework JavaScript. Parmi ces technologies du Web, on
retrouve les standards HTML5 et CSS3 mais aussi des langages plus évolués qui permettent de
dynamiser les pages Web. L’un d’eux, le plus connu et le plus utilisé, est JavaScript.
AJAX : ce n’est pas un langage, mais une nouvelle manière, une nouvelle technologie
permettant d’utiliser les standards déjà existants. Ajax permet de modifier partiellement une
page affichée sans avoir à la recharger entièrement.

Entity Framework : est un outil permettant de créer une couche d’accès aux données
DAL pour Data Access Layer) liée à une base de données relationnelle. Il propose la création
d’un schéma conceptuel composé d’entités qui permettent la manipulation d’une source de
données, sans écrire une seule ligne de SQL, grâce LinQ To Entities.
Le but de cette solution de mapping est d’offrir une couche d’interfaçage qui sera l’intermédiaire
entre la base de données et le développeur [13].
Dans notre application, nous avons utilisé l’approche Code First.
Code first : Cette approche permet de générer la base de données à partir des classes.
Cette méthode à un impact positif lors des mises à jour, contrairement à l’approche Database
first (Génération des classes à partir des tables de la base de données), puisqu’on a l’obligation
de régénérer à chaque fois le modèle, après avoir effectué un changement sur le modèle.

Figure 2.6: Code First Approach [14]

2.4 Architecture générale de l’application

Avant de se lancer dans la conception et le développement, nous allons préparer notre


architecture. Dans cette partie, nous nous intéressons à l’architecture opérationnelle et logicielle
de notre application.

2.4.1 Architecture physique

Généralement l’architecture d’un système décrit d’une manière schématique les différents
composants, ainsi que leurs interrelations et leur interaction.Notre application interagit avec
d’autres applications via un middleware orienté messages(MOM).
Cette architecture permet de développer des applications avec un couplage faible entre elles, les
données n’étant échangées que par envoi ou lecture des messages qui transitent dans la
couche middleware.
La figure 2.7 présente l’architecture physique de notre application.

Figure 2.7: Architecture globale de l’application

EDI : Echange Informatique de Données (Basées essentiellement sur un ETL pour


l’intégration des données)
2.4.2 Fonctionnement de l’architecture

1Le site web E-commerce envoi à notre système d’information un fichier « Encours » qui
contient les informations sur le nouveau colis.

2Le fichier Encours est consommé et transformer par l’EDI.

3L’EDI envoie un message MOM pour notre application ADARO pour insérer les nouvelles
données dans la BD.

4ADARO note qu’un nouveau colis est arrivé, il faut donc gérer ses états.

2.4.3 Spécification logicielle du système

La combinaison entre l’architecture MVC et l’architecture en couches peut donner


plusieurs résultat. L’un de ces résultats est l’architecture de notre application Asp.Net MVC5
décomposé en trois couches « «DataAcessLayer », « BusinessLayer » et «PresentationLayer ».
Le figure 2.8 présente l’architecture asp.net MVC 5.

Figure 2.8: Architecture asp.net MVC 5 de l’application

2.5Diagramme de déploiement

La figure 2.9 présente le diagramme de déploiement de notre application.Il montre la


disposition physique des matériels qui composent le système. Les ressources matérielles sont
représentées sous forme de nœuds. Notre application est hébergée sur l’espace clode de
Microsoft Azure et les postes clients peuvent y accéder. Ceci est illustré dans la figure 2.9 :
Figure 2.9: Diagramme de déploiement

Conclusion

Dans ce chapitre nous avons identifié les besoins fonctionnels et non fonctionnels de
notre système ainsi que les acteurs. Ensuite, nous avons détaillé la première étape de la
méthodologie que nous avons choisie à savoir l’identification de l’équipe de travail et la
réalisation de backlog du produit et des sprints.Puis nous avons présenté l’environnement
matériel et logiciel que nous utiliserons pour développer notre plateforme.
Dans le chapitre suivant nous entamons le développement du premier release.
Chapitre 3

ÉTUDE ET RÉALISATION DU SPRINT 1

Pla
n
1 Backlog du sprint..................................................................28
2 Spécification fonctionnelle....................................................28
3 Conception..........................................................................32
4 Réalisation...........................................................................36
5 Test......................................................................................38
Chapitre 3. Étude et réalisation du Sprint 1

Introduction

Dans ce chapitre, nous présentons la réalisation du premier sprint, en organisant le travail


sur trois phases principales qui sont l’analyse, la conception, et la réalisation.

3.1 Backlog du sprint

Le sprint est le coeur 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 qui doit être un tableau descriptif qui précise la charge du travail pour
chaque tâche en nombre de jours.
Le tableau 3.1 décrit les histoires de notre backlog du sprint

Tableau 3.1: Backlog du sprint 1

ID Histoire Estimation
1 S’authentifier 2
2 Modéliser le cycle de vie 4
d’un
colis
3 Ajouter des états dans le 2
modèle
4 Ajouter des événements 2
dans
le modèle
5 Enregistrer les états et les 4
évènements dans la bas sql
6 Consulter les états et les 2
événements du modèle

3.2 Spécification fonctionnelle

Dans cette partie nous présentons la phase d’analyse qui répond à la question « que fait
le système ».La réponse de cette question se traduit par la présentation du diagramme des cas

28
d’utilisation puis la description textuelle de chacun d’entre eux.

3.2.1 Diagramme de cas d’utilisation

La figure 3.1 décrit le diagramme de cas d’utilisation global du premier sprint.

Figure 3.1: Diagramme de cas d’utilisation global de sprint1

3.2.2 Description textuelle des cas d’utilisations

• Description textuelle du cas d’utilisation « Créer un modèle»


Le tableau 3.2 décrit la description textuelle du cas d’utilisation« Créer un modèle»

Tableau 3.2: Description textuelle du cas d’utilisation « Créer un modèle»

Titre Créer un modèle


Acteur Principal Administrateur
Résumé A travers ce cas, l’administrateur peut
modéliser
le cycle de vie d’un colis graphiquement
Pré-condition Administrateur authentifié
Scénario Principal 1. L’administrateur choisit l’état à modéliser
(retrait ou dépôt).
2. L’administrateur accède à la page de
modélisation de cycle de vie.
3. L’administrateur crée le modèle
graphiquement.
4. L’administrateur sauvegarde le modèle
dans la base des données.
5. Le système effectue la sauvegarde et il
affiche un message indiquant que
l’enregistrement s’est déroulée avec succès.

Post-condition Le modèle sera enregistré dans la base

• Description textuelle du cas d’utilisation « Ajouter des états et des événements»


Le tableau 3.3 décrit la description textuelle du cas d’utilisation« Ajouter des états et des
événements»

Tableau 3.3: Description textuelle du cas d’utilisation « Ajouter des états et des événements»

Titre Ajouter des états des événements


Acteur Principal Administrateur
Résumé A travers ce cas, l’administrateur peut ajouter
des
états et des événements dans le modèle de
colis
Pré-condition Administrateur authentifié
Scénario Principal 1. L’administrateur choisit l’état à modéliser
(retrait ou dépôt).
2. L’administrateur accède à la page
de modélisation de cycle de vie.
3. L’administrateur ajoute des états et/ou des
événements dans le modèle.
4. l’administrateur sauvegarde les états et/ou
des événements dans la base des données.
5. Le système enregistre les données et affiche
un
message de succès.
Post-condition Les états et/ou des événements seront
enregistré
dans la base

• Description textuelle du cas d’utilisation « Consulter les états et les événements»


Le tableau 3.4 décrit la description textuelle du cas d’utilisation« Consulter les états et les
événements».

Tableau 3.4: Description textuelle du cas d’utilisation « Consulter les états et les événements»

Titre Consulter les états et les événements


Acteur Principal Administrateur
Résumé A travers ce cas, l’administrateur peut afficher
la
liste des états et des événements dans le
modèle de colis
Pré-condition Administrateur authentifié
Scénario Principal 1. L’administrateur choisit l’état à modéliser
(retrait ou dépôt).
2. L’administrateur accède à la page
de modélisation de cycle de vie.
3. L’administrateur demande de consulter les
états et les événements.
4. Le système affiche la liste des états et
des
événements du modèle de colis.
Post-condition La liste des états et la liste des événements
seront
affiché

3.3 Conception

Dans cette section, nous présentons les différents diagrammes de séquence détaillés ainsi
que le diagramme de classe pour ce sprint.

3.3.1 Diagrammes des séquences détaillés

Un diagramme de séquence détaillée permet une représentation détaillée des


interactions entre les objets métiers de notre système selon un ordre chronologique. Nous
présentons dans ce qui suit les diagrammes des séquences détaillés des histoires du premier
sprint.
• Diagramme de séquence de l’opération « Créer un modèle»
La vue« Créer modèle » demande à l’administrateur de choisir l’état de modèle à réaliser
(état dépôt ou retrait).Une fois l’administrateur choisit le type de modèle, il aura une interface de
création de modèle où il peut créer des états et des évènements dans un modèle
graphiquement.
Si l’administrateur termine le modèle,les données seront transférées vers le contrôle «
ModèleController». Une fois les données sont bien vérifiées le modèle sera ajouté et un message
de confirmation s’affiche.
La figure 3.2 illustre le diagramme de séquence « Créer un modèle».
Figure 3.2: Diagramme de séquence de l’opération « Créer un modèle»

• Diagramme de séquence de l’opération « Ajouter des états et des événements»


La vue « Dépôt » permet à l’administrateur d’ajouter un ou plusieurs états et/ou
événements dans le modèle Dépôt et de même pour le modèle Retrait. Lorsque
l’administrateur ajoute des états et des événements les données seront envoyés au Controller pour
enregistrer dans la base sql.Si les données sont enregistrés un message de confirmation sera
affiché.
La figure 3.3 présente le scénario du diagramme de séquence «Ajouter un état et événement».
Figure 3.3: Diagramme de séquence de l’opération « Ajouter des états et des événements»

• Diagramme de séquence de l’opération « Consulter les états et les


événements du modèle »
En arrivant à la vue de modèle de colis, l’administrateur peut avoir les états et les
événements.La liste des états et la liste des événements sont affichées dans la vue
«Retrait»(respectivement la vue
«Dépôt»).
La figure 3.4 présente le scénario du diagramme de séquence de l’opération « Consulter les
états et les événements du modèle »
Figure 3.4: Diagramme de séquence de l’opération « Consulter les états et les
événements du modèle»

3.3.2 Diagramme de Classes

La figure 3.5 représente le diagramme de classe utilisé pour le développement du premier


Sprint.

Figure 3.5: Diagramme de classe du Sprint 1


Le tableau 3.5 décrit la description des classes participantes dans la première Sprint.

Tableau 3.5: Description des classes participantes dans la première Sprint

ID Description
Modèle Cette classe permet de sauvegarder les états
et
événements de modèles
État Cette classe est dédiée à la sauvegarde des
états
Événement Cette e dédi à l sauvegar d
classe s ée a de e
t s
événement
s

3.4 Réalisation

Cette partie est consacrée à l’exposition du travail achevé à travers des captures d’écrans
de différentes interfaces développées pendant ce sprint.

3.4.1 Interface d’authentification

L’interface 3.6 permet à l’utilisateur d’accéder au système après une validation de son
login et son mot de passe.

Figure 3.6: Interface d’authentification


3.4.2 Interface de Création d’un modèle de cycle de vie d’un colis

L’interface 3.7 présente l’interface qui permet à l’administrateur de modèliser l’état retrait
en clisquant sur le menu Retrait.

Figure 3.7: Interfaces de modélisation de l’état retrait

L’interface 3.8 présente l’interface qui permet à l’administrateur de modèliser l’état Dépôt
en clisquant sur le menu Dépôt.

Figure 3.8: Interfaces de modélisation de l’état Dépôt

Afin de modéliser l’état retrait l’administrateur clique sur le bouton « Voir les états » pour
consulter les états du modèle et le bouton « Voir les événement » pour consulter les événements.
La figure 3.9 présente la liste des états et des événements du modèle créé
Figure 3.9: Interfaces de Consultation des états et des événements du modèle »

L’interface 3.10 présente le message de confirmation de la sauvegarde des états à la

base sql

Figure 3.10: Interfaces de Confirmation de l’enregistrement des états

3.5Test

Le test d’un produit logiciel est un processus consistant qui vise à garantir le bon
fonctionnement du système à travers une comparaison des comportements attendu et des
résultats obtenus. Avant la fin de chaque Sprint nous avons testé les fonctionnalités du module.
Ensuite nous avons validé toutes les fonctionnalités avec le Product Owner. Pour ce fait, nous
avons élaboré dans le tableau

3.6 un ensemble de cas de scénario de tests relatif au sprint 1.

Tableau 3.6: Tests du sprint 1

Cas de test Démarche Comportement Résultats


attendu
Test d’ajout des Créer des états un modèle est Conforme
créé
événements et et des
des états dans événements
un graphiquement
modèle graphique
Test d’enregistrer Sauvegarder Les états et les Conforme
les états et les les états et événements sont
événements les enregistrés dans
du événements la
modèle dans la base
base
Test Afficher la liste La liste des états Conforme
d’afficher les des états et des et des
états et les événements événements est
événements du affichée
modèle

Conclusion

Au cours de ce chapitre, nous avons présenté le premier sprint. Pour ce faire, nous avons
passé par l’analyse, la conception et la réalisation. Dans le chapitre suivant nous entamons le
deuxième sprint.
Chapitre 4

ÉTUDE ET RÉALISATION DU SPRINT 2

Pla
n
1 Backlog du sprint..................................................................41
2 Spécification fonctionnelle....................................................41
3 Conception...........................................................................45
4 Réalisation...........................................................................49
5 Test......................................................................................51
Chapitre 4. Étude et réalisation du Sprint 2

Introduction

Après avoir entamé le premier release de notre système, nous pouvons maintenant
passer au deuxième 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 allons détailler l’application
dédié au partenaire, en présentant les différents cas d’utilisation proposé dans le backlog présenté
dans le deuxième chapitre, ensuite nous abordons la conception et nous terminons par la partie la
réalisation.

4.1 Backlog du sprint

Le tableau 4.1 décrit les histoires de notre backlog du sprint.

Tableau 4.1: Backlog du produit

ID Histoire Estimation
7 Afficher liste des colis 3
8 Fileter l’affichage de la liste 1
des colis par état
9 Modifier l’état de colis 2
10 Rechercher un colis 3
11 Afficher détails d’un colis 2

4.2 Spécification fonctionnelle

Dans cette partie, nous présentons les diagrammes de cas d’utilisation et la description
textuelle de chacun d’entre eux.

4.2.1 Diagramme de cas d’utilisation

La figure 4.1 représente le diagramme de cas d’utilisation globale du sprint 2.

41
Figure 4.1: Diagramme de cas d’utilisation global de sprint2

4.2.2 Description textuelle des cas d’utilisations

• Description textuelle du cas d’utilisation « Afficher la liste des colis»


Le tableau 4.2 décrit la description textuelle du cas d’utilisation «Afficher la liste des colis».

Tableau 4.2: Description textuelle du cas d’utilisation « Afficher la liste des colis»

Titre Afficher la liste des colis


Acteur Principal Partenaire
Résumé A travers ce cas, le partenaire doit récupérer la liste des
colis
Pré-condition partenaire authentifié
Scénario Principal 1. Le partenaire demande de consulter la liste des colis.
2. Le système affiche la liste des colis.
Post-condition Le partenaire aura la liste des colis avec ses détails
• Description textuelle du cas d’utilisation «Afficher liste des colis par état»
Le tableau 4.3 décrit la description textuelle du cas «Afficher liste des colis par état».

Tableau 4.3: Description textuelle du cas d’utilisation «Afficher liste des colis par état»

Titre Afficher liste des colis par état


Acteur Principal Partenaire
Résumé A travers ce cas, le partenaire peut afficher la liste des
colis
par la libellé d’état
Pré-condition Partenaire authentifié
Scénario Principal 1. Le partenaire accède à la page d’affichage de la liste
des colis.
2. Le partenaire sélectionne un état.
3. le partenaire choisit l’option Filter l’affichage.
4. Le système affiche la liste des colis par l’état
selectionné.
Post-condition le partenaire aura la liste des colis filtrés par leurs états

4.2.2.1 Raffinement du cas d’utilisation «Modifier l’état de colis»

La figure 4.2 présente le raffinement du cas d’utilisation «Modifier l’état de colis».

Figure 4.2: Raffinement du cas d’utilisation «Modifier l’état de colis»

• Description textuelle du cas d’utilisation «Choisir un état existant»


Le tableau 4.4 décrit la description textuelle du cas «Choisir un état existant».
Tableau 4.4: Description du cas d’utilisation «Choisir un état existant»

Titre Choisir un état existant


Acteur Principal Administrateur
Résumé A travers ce cas, l’administrateur peut modifier l’état de
colis
Pré-condition administrateur authentifié.
Scénario Principal 1. L’administrateur accède à la page d’affichage de la
liste des colis.
2. L’administrateur modifie l’état de colis en
sélectionner un état existant.
3. L’administrateur sauvegarde les modifications dans
la base.
4. Le système effectue la modification dans la base

Post-condition la base de données sera mis à jour.

• Description textuelle du cas d’utilisation «Rechercher colis »


Le tableau 4.5 décrit la description textuelle du cas «Rechercher colis ».

Tableau 4.5: Description textuelle du cas d’utilisation «Rechercher colis »

Titre rechercher un colis


Acteur Principal Partenaire
Résumé A travers ce cas, le partenaire peut rechercher un colis
et
afficher tous ses détails
Pré-condition Partenaire authentifié.
Scénario Principal 1. Le partenaire accède à la page de recherche.
2. Le partenaire doit remplir les formulaires de critères
de recherche.
3. Le système affiche les détails de colis correspondant.
Scénario 2.1. Le partenaire saisit des données manquantes.
Alternatif
- Le système affiche un message d’erreur pour
demander à l’utilisateur de remplir les données
manquantes.
- Reprise de l’étape 2 du scénario principal
Post-condition Détails d’un colis seront affichée
4.3 Conception

4.3.1 Diagrammes des séquences détaillés

Après avoir terminé les descriptions textuelles du diagramme de cas d’utilisation du


deuxième sprint. Nous passons à présenter les diagrammes de séquence de cette partie.
• Diagramme de séquence de l’opération« Afficher liste des colis »
En cliquant sur le menu « Liste des Colis » le partenaire demande d’afficher la liste des
colis, le contrôleur « ListeColisController » sera chargé de récupérer l’ensemble des colis
existants dans l’entité «Colis » et les afficher via l’interface « ListeColis». Si aucun client trouvé,
une vue de liste vide est affichée.
La figure 4.3 présente le scénario de diagramme de séquence de l’opération « Afficher liste colis »

Figure 4.3: Diagramme de séquence de l’opération « Afficher liste colis»

• Diagramme de séquence « Afficher liste Colis par état »


En cliquant sur l’option de filtre le partenaire demande d’afficher les états, le contrôleur
«ListeColisController » sera chargé de récupérer l’ensemble des états existants dans l’entité «
état» et les afficher via l’interface « ListeColis».Lorsque le partenaire sélectionne un état, « la
liste des colis sera affiché par l’état selectionné.
La figure 4.4 présente le scénario de diagramme de séquence de l’opération « Afficher liste colis
par état»

Figure 4.4: Diagramme de séquence de l’opération « Afficher liste colis par état»

• Diagramme de séquence «Rechercher colis»


En cliquant sur le menu «Rechercher» l’utilisateur peut avoir les détails d’un colis. il saisit
les critères de recherche(référence,Expéditeur,Destinatire,prestation,type de préstation,état,periode
d’expédition, période d’état,staut de colis)les données seront envoyées au contrôleur de recherche
qui par la suite il cherche le colis dans l’entité «Colis». Le système affiche les détails de colis
trouvés si non affiche une page vide.
La figure 4.5 décrit le scénario de recherche d’un colis que nous avons détaillé ci-dessus
Figure 4.5: Diagramme de séquence détaillé « Rechercher colis »

4.3.2 Diagramme de Classes

Le diagramme de cas d’utilisation décrit le système du point de vue acteurs. Le


diagramme de classe permet de décrire la structure interne tout en montrant les différentes
classes, leurs attributs leurs méthodes ainsi que les différentes relations structurelles entre ces
classes.
La figure 4.6 décrit le diagramme de classes que nous avons utilisé pour développer le
deuxième sprint.
Figure 4.6: Diagramme de classe du Sprint 1

Le dernier sprint ajoute au diagramme de classe déjà obtenu dans le premier sprint les
classes dans le tableau 4.6.

Tableau 4.6: Description de classes participantes dans le Sprint 2

Classe Description
Colis Cette classe est dédiée à l’affichage
de la
liste des colis
HistoEtat Cette classe est dédiée à l’affichage
de
l’historique des états pour un colis
PointRelais Contient les informations du points
relais de chaque colis.
Transporteur Contient les informations
du
transporteur de chaque colis.
4.4 Réalisation

Dans cette partie nous présentons les interfaces de notre application. Nous présentons
alors les différentes interfaces réalisés dans le sprinte2.

4.4.1 Interface d’affichage de la liste des colis

Le partenaire peut consulter la liste des colis en cliquant sur le menu« Liste des Colis». La
figure 4.7 présente la liste des colis.

Figure 4.7: Interface d’affichage de la liste des

colis La figure 4.8 présente la liste des colis par leur état

Figure 4.8: Interface Filter liste des colis par état


La figure 4.9 permet à l’administrateur d’éditer l’état de colis par séléctionne d’un état
éxistant

Figure 4.9: Interface Sélectionner un état existant

4.4.2 Interface de recherche d’un colis

La figure 4.10 permet au partenaire de rechercher un colis selon des critères de rechercher.

Figure 4.10: Interface de recherche de colis


La figure 4.11 permet au partenaire d’afficher les détails d’un colis à rechercher

Figure 4.11: Interface d’affichage de détails de colis

4.5 Test

Le tableau 4.7 présente un ensemble de cas de tests relatif au sprint 2.

Tableau 4.7: Tests du sprint 2

Cas de test Démarche Comportemen Résultats


t
attendu
Test l Demand l list La de co Conforme
a er a e liste s lis
d’afficher
des s’affich
liste des colis colis e
Test de Choisir un état et La liste des colis Conforme
filter
cliquer sur filtrer s’affiche selon
l’affichage des
l’état séléctionné
colis par état
Test de Choisir un colis et l’état c es Conforme
modifier de ol t
cliquer sur éditer is
l’état de colis modifié
Test de Remplir l Le colis à Conforme
rechercher un formulair e rechercher est
colis e affiché avec ses
recherch d détails
er
e
Conclusion

Dans ce chapitre nous avons décrit les étapes faites durant le deuxième sprint qui a été
consacrée pour la gestion des colis. Nous avons commencé ce chapitre par la spécification et
l’analyse des exigences. Ensuite, nous avons effectué une étude conceptuelle. Enfin, nous
avons clôturé par la description des étapes de réalisation. Nous passons maintenant au sprint
suivant à réaliser.
Chapitre 5

ÉTUDE ET RÉALISATION DU SPRINT 3

Pla
n
1 Backlog du sprint..................................................................54
2 Spécification fonctionnelle....................................................54
3 Conception...........................................................................58
4 Réalisation..........................................................................64
5 Test......................................................................................66
Chapitre 5. Étude et réalisation du Sprint 3

Introduction

Nous allons entamer dans ce chapitre le dernier Sprint. Pour cela, Nous commençons
par présenter le Backlog du sprint, ensuite nous passons à l’analyse et la conception .Nous
clôturons par la partie la réalisation et test.

5.1 Backlog du sprint

Le tableau 5.1 décrit les histoires du dernier sprint de notre application.

Tableau 5.1: Backlog du sprint3

Id Histoire Estimation
12 Consulter l’état courant du colis 2
13 Consulter la liste des événements 2
des
colis
14 Consulter la liste des états des colis 2
15 Ajouter une action 4
16 Envoyer un mail au client 4

5.2Spécification fonctionnelle

Dans cette partie, nous présentons les diagrammes de cas d’utilisation et la description
textuelle de chacun d’entre eux.

5.2.1 Diagramme de cas d’utilisation

La figure 5.1 représente le diagramme de cas d’utilisation global du sprint 3.

54
Figure 5.1: Diagramme de cas d’utilisation globale de sprint 3

5.2.2 Description textuelle de cas d’utilisation

• Description textuelle du cas d’utilisation «Consulter l’état en cours du


colis» Le tableau 5.2 représente la description textuelle de cas d’utilisation «Consulter l’état en
cours du colis »

Tableau 5.2: Description textuelle du cas d’utilisation « Consulter l’état en cours du colis »

Titre Consulter l’état en cours du colis


Acteur Partenaire
Pré-condition Partenaire déjà authentifié
Colis est déjà crée
Scénario nominal 1 .Le partenaire choisit de consulter l’état courant d’un
colis.
2. Le système renvoie le formulaire de recherche d’un
colis.
3. Le partenaire saisit la référence de colis.
2. Le système renvoie les détails du colis avec son état
courant.
Scénario alternatifs 3.1. Le partenaire saisit une fausse référence.
- Le système affiche un message d’erreur.
- Reprise de l’étape 3 du scénario principal.
Post-condition Détails et état courant du colis s’affiche

• Description textuelle du cas d’utilisation «Consulter les événements»


Le tableau 5.3 représente la description textuelle de cas d’utilisation «Consulter les événements»

Tableau 5.3: Description textuelle du cas d’utilisation «Consulter les événements»

Titre Consulter les événements


Acteur Partenaire
Pré-condition Partenaire déjà authentifié
Scénario nominal 1 .Le partenaire choisit de consulter les événements du
colis.
2. Le système renvoie le formulaire de recherche d’un
colis.
3. Le partenaire saisit la référence de colis.
2. Le système renvoie les événements du colis.
Scénario alternatifs 3.1. Le partenaire saisit une fausse référence.
- Le système affiche un message d’erreur.
- Reprise de l’étape 3 du scénario principal.
Post-condition Liste des événements s’affiche.

• Description textuelle du cas d’utilisation «Consulter les états»


Le tableau 5.4 représente la description textuelle de cas d’utilisation «Consulter les états»

Tableau 5.4: Description textuelle du cas d’utilisation «Consulter les états»

Titre Consulter les états


Acteur Partenaire
Pré-condition Partenaire déjà authentifié
Scénario nominal 1 .Le partenaire choisit de consulter les états du colis
2. Le système renvoie le formulaire de recherche d’un
colis.
3. Le partenaire saisit la référence de colis.
2. Le système renvoie les états du colis.
Scénario alternatifs 3.1. Le partenaire saisit une fausse référence.
- Le système affiche un message d’erreur.
- Reprise de l’étape 3 du scénario principal.
Post-condition Liste des états s’affiche

• Description textuelle du cas d’utilisation «Ajouter une action»


Le tableau 5.5 représente la description textuelle de cas d’utilisation «Ajouter une action»

Tableau 5.5: Description du cas d’utilisation «Ajouter une action»

Titre Ajouter une action


Acteur Partenaire
Pré-condition Le partenaire est déjà authentifié
Scénario nominal 1. Le partenaire choisit d’ajouter une action.
2. Le système affiche le formulaire d’ajout une action.
3. Le partenaire remplit les champs nécessaires et
valide l’ajout.
4. Le système enregistre les données et affiche un
message
de succès
Post-condition Une action sera créée

• Description textuelle du cas d’utilisation «Envoyer un mail au client»


Le tableau 5.6 représente la description textuelle de cas d’utilisation «Envoyer un mail au client»

Tableau 5.6: Description du cas d’utilisation «Envoyer un mail au client»

Titre Envoyer un mail au client


Acteur Partenaire
Pré-condition Le partenaire est déjà authentifié
Scénario nominal 1. Le partenaire clique sur le menu «Envoyer un mail».
2. Le système affiche l’interface d’envoi du mail.
3. Le partenaire remplit les champs nécessaires et
valide l’envoi.
4. Le système traite la requête d’envoi du mail au client.
Scénario alternatifs 3.1. Le partenaire saisit des données manquantes.
- Le système affiche un message d’erreur.
- Reprise de l’étape 3 du scénario principal.
Post-condition le client recevra le mail.

5.3Conception

5.3.1 Diagrammes des séquences détaillés

Après avoir terminé les descriptions textuelles du diagramme de cas d’utilisation du


troisième sprint. Nous passons à présenter les diagrammes de séquence de cette partie.
• Diagramme de séquence « Consulter l’état courant du colis»
En cliquant sur le menu «Fiche Colis » le partenaire entre la référence du colis. Le contrôleur
« C :FicheColis » sera chargé de récupérer les détails du colis avec son état courant existant
dans l’entité «Etat » et les afficher via l’interface «DétailsFicheColis». Si aucun colis trouvé, une
vue vide est affichée.
La figure 5.2 présente le scénario de diagramme de séquence «Consulter l’état courant du colis ».
Figure 5.2: Diagramme de séquence de l’opération «Consulter l’état courant du colis»

• Diagramme de séquence « Consulter les événements du colis»


En cliquant sur le menu «Fiche Colis » le partenaire entre la référence du colis. Le contrôleur
« C :FicheColis » sera chargé de récupérer l’ensemble des événements existant dans l’entité
«Event» et les afficher via l’interface «DétailsFicheColis». Si aucun colis trouvé, une vue de liste
vide est affichée.
La figure 5.3 présente le scénario de diagramme de séquence de l’opération «Consulter
les événements du colis »
Figure 5.3: Diagramme de séquence de l’opération «Consulter les événements du colis»

• Diagramme de séquence de l’opération « Consulter les états du colis»


En cliquant sur le menu «Fiche Colis » le partenaire entre la référence du colis.Le contrôleur
« C :FicheColis » sera chargé de récupérer l’ensemble des états existant dans l’entité
«HistoEtat» et les afficher via l’interface «DétailsFicheColis». Si aucun colis trouvé, une vue de
liste vide est affichée.
La figure 5.4 présente le scénario de diagramme de séquence de l’opération «Consulter
les états du colis »
Figure 5.4: Diagramme de séquence de l’opération «Consulter les états du colis»

• Diagramme de séquence de l’opération « Ajouter une action »


Le formulaire d’ajout une action demande au partenaire de saisir les informations
nécessaires (type action,IdPointRelais). Lorsqu’il envoi les données, ils seront transférées vers
le contrôleur
«C :FicheColis» Une fois les données sont bien vérifiées, l’action sera enregistrer et un message
de confirmation s’affiche si non un message d’erreur s’affiche.
La figure 5.5 présente le scénario de diagramme de séquence de l’opération «Ajouter une
action »
Figure 5.5: Diagramme de séquence de l’opération «Ajouter une action»

• Diagramme de séquence de l’opération « Envoyer un mail au client »


La vue« Email » demande au partenaire de saisir : l’adresse mail du client,l’objet et le
message à envoyer. Lorsque le partenaire envoi les données, un premier contrôle se fait au
niveau de la vue « Email » pour vérifier la validité des données transmises. Si tout va bien, les
données seront transférées vers le contrôle « EmailController ». Une fois les données sont bien
vérifiées le mail sera envoyé au client et un message de confirmation s’affiche si non un
message d’erreur s’affiche au partenaire.
La figure 5.6 illustre le diagramme de séquence «Envoyer un mail au client ».
Figure 5.6: Diagramme de séquence de l’opération «Envoyer un mail au client»

5.3.2 Diagramme de Classes

La figure 5.7 représente le diagramme de classe utilisé pour le développement du dernie Sprint.
Figure 5.7: Diagramme de classe du Sprint 3

Le dernier sprint ajoute au diagramme de classe déjà obtenu dans le premier et deuxième
sprint une classe :
• Point Relais, Transporteur : Utilisée pour ajouter une action
• Anomalie : Utilisée pour sauvegarder une anomalie
• Action : Utilisée pour créer une action

5.4 Réalisation

Dans cette partie nous présentons les interfaces que nous avons réalisées dans le dernier
sprint.

5.4.1 Interface de Consultation des détails de colis avec son état


courant

La figure 5.8 présente les détails du colis avec son état courant.

Figure 5.8: Interface de Consultation des détails de colis avec son état courant
5.4.2 Interface de Consultation les événements et les états

Pour suivre le cycle de colis le partenaire doit saisir la référence de colis pour obtenir la
liste des états et des événements.
La figure 5.9 présente la liste des états et des événements du colis.

Figure 5.9: Interface de Consultation des états et des événements

5.4.3 Interface d’ajout une action

Pour Ajouter une action le partenaire doit cliquer sur le bouton « Ajouter une action» pour
obtenir la fenêtre d’ajout une action.
L’interface de la figure 5.10 permet de présenter la fenêtre d’ajout une action.

Figure 5.10: Interface d’ajout une action

5.4.4 Interface d’envoi un mail au client

Pour envoyer un mail, le partenaire choisit le menu « Envoyer mail». La figure 5.11 illustre
l‘interface qui permet de faire ceci.
Figure 5.11: Interface d’envoi un mail au client

5.5 Test

Le tableau 5.7 présente un ensemble de cas de tests relatif au sprint 3.

Tableau 5.7: Tests du sprint 3

Cas de test Démarche Comporteme Résultats


nt
attendu
Test de suivi l’état Demande les détails du Conforme
courant d’un colis d’afficher les colis avec l’état
détails du colis courant sont
avec son état affichés
courant
Test de suivi Demande Liste des états et Conforme
le d’afficher
liste des
cycle en état et la liste des états
événements sont
événements et des
affcihés
événements
Test d’ajouter une Demander le L’action est Conforme
ajoutée
action formulaire
d’ajouter
une action
Test d’envoi un Demanderle Le Conforme
mail
formulaire
formulaire
d’envoi un mail d’envoi un mail
au client s’affiche
Le mail est
envoyé
Conclusion

A ce stade, nous avons réussi donc à développer le dernier release de notre application
pour arriver à un produit complet et fonctionnel. Notre application Web et est donc prête à être
exploiter en offrant aux partenaires la possibilité de gérer convenablement toutes les
fonctionnalités de la platforme.
Conclusion générale

Les sociétés de transport et de logistique des colis essayent toujours à améliorer le


processus d’acheminement de colis afin de satisfaire les besoins des partenaires et des clients.
C’est dans ce contexte que notre projet s’intègre.Il consiste à concevoir et à implémenter
une application de gestion de cycle de vie d’un colis afin d’améliorer les services d’une société
aux partenaires.Cette application permet de modéliser le cycle de vie d’un colis et de les gérer. Il
permet également le suivi des états et des événements déclenchés au cours du cycle de vie de
colis.
Pour réaliser ce travail, nous avons commencé par une analyse qui consiste à définir le contexte
général ainsi que la méthodologie et le formalise du travail adoptés. Ensuite nous avons effectué
une étude théorique sur les concepts d’envoi et de livraison et les logiciels existants sur le
marché afin de proposer une solution qui répond au besoin de l’entreprise. Après, nous avons
analysé et spécifié les besoins fonctionnels et non fonctionnels, après avoir étudier l’existant,
auxquels devra répondre notre solution. Dans une étape suivante, nous avons présenté
l’environnement de travail, les outils et les technologies utilisés tout au long de notre stage. Puis,
nous avons détaillé notre conception à travers les diagrammes de séquences, et le diagramme de
classe. Finalement, nous avons décrit notre application à travers des captures d’écran.

Ce stage nous a permis d’approfondir nos connaissances théoriques, acquises tous le


long de notre formation, par la pratique des nouvelles technologies et de maîtriser le langage de
modélisation UML, les outils de développement Asp.net MVC 5 et le système de gestion de
base de données sql server.
Comme perspectives, plusieurs fonctionnalités peuvent être ajoutées à notre application
notamment l’ajout d’une partie mobile sera très importante dans notre cas pour le suivi d’envoi
et de livraison des colis.

68
Bibliographie

[1]W. SMIRI, Présentation des Services TIC de l’entreprise, SMIRI Engeneering, 17/10/ 2016.

[2]J. TABAKA., La gestion de projet : methodes classiques vs methodes agiles. ACCESS-


DEV. [Accès le 5-Mars-2017], Fev.2013. adresse : http://www.access-dev.com/access-
dev/la- gestion-de-projet-methodesclassiques-vs-methodes-agiles/.

[3]F. LOTHON, Guide de démarrage scrum. L’Agiliste. [Accès le 7-Mars-2017], Jan. 2010. adresse :
http://www.agiliste.fr/guide-de-demarrage-scrum/.

[4]Y. QUENEC’HDU, Unofficial Scrum Guide.slideshare, [Accès le 10-Mars-2017], Jan. 2013.

[5]J.-P. DAVALAN., Suite de fibonacci mise en évidence. jm.davalan. [Accès le 12-Mars-2017],

Jan.
2002. adresse : http://jm.davalan.org/divers/fibonacci/f03.html.

[6] Welcome to Visual Studio 2015, [Accès le 15-Mars-2017], Jan. 2017. adresse : https://msdn.
microsoft.com/en-us/library/dd831853.aspx.

[7] Télécharger SQL Server Management Studio (SSMS). [Accès le 15-Mars-2017], Jan. 2017.
adresse : https://msdn.microsoft.com/fr-fr/library/mt238290.aspx.

[8]J.-P. ., Un nouvel environnement de programmation pour android. cellenza. [Accès le 12-Mars-


2017], 2-janvier-2014.. adresse : http:// blog.cellenza.com/evenements/asp- net- mvc-
from- zero-to-hero/.

[9] W3. Html5. w3. 28-October-2014. [Accès le 12-Mars-2017], 2010. adresse : https://www.w3.
org/TR/html5/.

[10] getbootstrap. Bootstrap. getbootstrap. [Accès le 23-Mars-2017], 2015. adresse :


https://www. w3.org/TR/html5/.

[11] w3schools. Css3. w3schools. 28-Janvier-2016, [Accès le 26-Mars-2017], 28/01/2016. adresse :


http://www.w3schools.com/css/.

[12] jquery. w3schools, [Accès le 26-Mars-2017], jan 2016. adresse : http://www.w3schools.com/


jquery/default.asp.

[13] Microsoft. Entity framework (ef ) documentation. Microsoft. [Accès le 26-Mai-2017], jan
2016. adresse : https://msdn.microsoft.com/en-us/data/ee712907.

69
Bibliographie

[14] Entity Framework Tutorial, [Accès le 26-Mai-2017]. adresse : http://www.entityframework.


tutorial.net/code-first/what-is-code-first.aspx.

70
9’SŁA
➢ZGR2.ÀŞAYZAI YA ,zsga ÕZ2GU .2z Ç9A22R ,9,zrı @sz ç9.ua ,2AI YA $Q2RI ızœ
¿,zsş QŞŞAZ .2UZA 2ri9 ¿z.şsşzı Y.ŞQM À2.U YA ñş.şs ys2rı àşşş,zsrı õ,9zrı ozgr
YM2MÃI 2SQÀ Ç9.UQRI ızœ Z2ŞZA . z9.a2r UIZTÃI9 $TI.QRI zα.r9 ¿SSQRI Õ2ŞT õ,9z
õ,ıza nş9 õ,ıza SCRUM àşşgsa9 Ù2Z2ŞŞRI ÕZZ2À õ,ıza SQL server c àşa.ş ÀZ22 C# c
Asp.netÇ2Q2SMIŞ
.2SZ9.UA

SQL servercc#cAsp.netC¿SSQRI Õ2ŞT õ,9z õ,ızic nş9 QŞŞAZ : 7ŞSŁÁA iłqłF

Résumé
Ce présent travail s’inscrit dans le cadre de projet de fin d’étude pour l’obtention
du diplôme d’ingénieur en informatique. Ce stage effectué au sein de l’entreprise
Smiri Engineering , consiste à développer une application Web de Gestion de cycle
de vie d’un produit permettant le suivi des états et événements de colis.Pour réaliser
ce travail, nous avons utilisé le framework Asp.net et le C# comme un langage de
programmation, SQL server pour la gestion de la base de données et la
méthodologie Scrum comme un cycle de vie pour notre projet.

Mots clés : Application Web, Gestion de cycle de vie d’un produit, framework
Asp.net, C#, SQL server.

Abstract
The present work is part of the final project to obtain the engineering degree in
computer science. This training period within the company Smiri Engineering, a
web application Life cycle management of a product . To make this work, we used
the framework Asp.net and C# as a programming language, SQL Server to manage
the database and methodology Scrum as a life cycle for our project.

Keywords : Web Application,life cycle management of a product, Asp.net frame-


work, C#, SQL server.

isi@isim.rnu.tn : yz9.szraı zş.şrı 71 706 698 :,22ARI 71 706 164 :AZ2GRI ÀZ2Ş,S 2080 YZ9,2ŞRI Y22Ş.RI 9şs ¿gz 2
2 Abou Raihane Bayrouni 2080 l’Ariana Tél: 71 706 164 Fax: 71 706 698 Email: isi@isim.rnu.tn