SlideShare une entreprise Scribd logo
Département: STIC
Référence:
Licence Appliquée en Science et Technologies
de l’Information et de la Communication
Option SR
Conception et Réalisation d’une
application de gestion des processus d'achat et de sous-traitance
Réalisé par : Ahmed MAKNI
Classe : L3SRC
Encadrant de l’Iset’COM : Dr Hafedh GAHA
Encadrant de l’entreprise : M. Mourad GALLES
Responsable : M. Riadh SHIL
Entreprise d’Accueil : Tunisair Technics
Année Universitaire : 2016-2017
Résumé
Ce travail s’inscrit dans le cadre du projet de fin d’études pour
l’obtention de diplôme de licence en science et technologies de l'information
et de la communication. Il vise à réaliser une application web pour
l’évaluation des fournisseurs tenant compte les chiffres d'affaires, la
condition des livraisons par rapport aux commandes ainsi que les non
conformités. Pour ce faire l'application associe des critères quantitatifs pour
calculer un taux de respect des engagements moyennant une extraction des
données du logiciel de gestion à des critères qualitatifs pour évaluer les
aspects affaire et technique des fournisseurs.
Mots clés : Evaluation fournisseur, web, JEE, SPRING, HIBERNATE.
Abstract
This work is part of the final project studies for the license in science and
information and communication technologies. It aims at creating a web
application for the evaluation of suppliers taking into account turnover, the
situation of deliveries in relation with the purchase and the reparation orders
and the non-conformities. To achieve this, the application combines
quantitative criteria to calculate a rate of compliance with commitments by
extracting the data from the management software with a qualitative one to
evaluate the business and technical aspects.
Keywords: Supplier evaluation, web, JEE, SPRING, HIBERNATE.
‫ص‬ّ‫خ‬‫مل‬
‫ّة‬‫ي‬‫طبيق‬ّ‫ت‬‫ال‬ ‫اإلجازة‬ ‫شهادة‬ ‫على‬ ‫للحصول‬ ‫ّروس‬‫د‬‫ال‬ ‫ختم‬ ‫مشروع‬ ‫إعداد‬ ‫إطار‬ ‫في‬ ‫العمل‬ ‫هذا‬ ‫يندرج‬
‫في‬‫المعلومات‬ ‫وتكنولوجيا‬ ‫العلوم‬‫ويهد‬ .‫واالتصاالت‬‫ف‬‫إلى‬‫تطبيق‬ ‫إنشاء‬‫واب‬ّ‫المور‬ ‫لتقييم‬‫دين‬‫أ‬‫خذا‬
‫في‬‫االعتبار‬‫حجم‬‫وحالة‬ ‫الدوران‬ّ‫ت‬‫ال‬‫سليم‬‫ب‬ ‫مقارنة‬‫أوامر‬‫راء‬ّ‫ش‬‫ال‬‫وعدم‬ ‫واإلصالح‬‫لتحقي‬ .‫المطابقة‬‫ق‬
ّ‫ت‬‫ال‬ ‫يجمع‬ ،‫ذلك‬ّ‫م‬‫ك‬ ‫معايير‬ ‫بين‬ ‫طبيق‬‫لحساب‬ ‫ية‬‫احتراما‬ ‫نسبة‬‫اللتزامات‬‫البيانات‬ ‫استخراج‬ ‫خالل‬ ‫من‬
‫بر‬ ‫من‬‫ن‬‫ال‬ ‫امج‬‫ف‬ّ‫صر‬ّ‫ت‬‫ّة‬‫ي‬‫نوع‬ ‫ومعايير‬ّ‫ت‬‫ال‬ ‫الجوانب‬ ‫لتقييم‬ّ‫ي‬‫جار‬ّ‫ت‬‫وال‬ ‫ة‬ّ‫ي‬‫قن‬.‫ة‬
‫الكلمات‬:‫المفاتيح‬‫تقييم‬‫المور‬،‫التجاري‬ ‫اإلصدار‬ ‫جافا‬ ،‫واب‬ ،‫د‬‫منصة‬‫ال‬‫عمل‬‫جافا‬‫سبرين‬‫غ‬،‫بيئة‬
‫الهايبرنت‬
Dédicaces
Au symbole de douceur,
Amour et affection pour le sens du devoir et aux sacrifices
qu’elle a consenti, maman Monia, grâce à qui j’ai pu
arriver à réaliser ce projet.
J’espère que ce travail sera une récompense suffisante.
Que Dieu te garde pour moi.
A mon père Fethi, 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.
A tous mes amis et camarades proches
Vous êtes les meilleurs, merci pour tout votre temps passé à
m’encourager et me motiver.
Remerciements
Avant de présenter mon travail, je voudrais rendre mérite et exprimer
ma gratitude à tous ceux qui m’ont aidé à mener à bien mon projet.
Mon encadrant académique Dr. Hafedh GAHA, pour ses conseils
précieux et qui s'est toujours montré à l'écoute et très disponible tout au
long de la réalisation de ce projet de fin d’études.
Le Directeur des Approvisionnements Aéronautiques de Tunisair
Technics M. Riadh SHIL pour son accueil chaleureux.
Mon encadrant d’entreprise M. Mourad GALLES pour ses précieux
conseils et la qualité de l'encadrement dont il m’a fait profiter tout au long
de ce projet.
Mademoiselle Yossra BEN AMOR, analyste IT à VERMEG Tunisie
pour tout l’apport dont j'ai pu bénéficier concernant le contexte de
développement avec le langage Java.
A tous les employés de Tunisair Technics qui ont déployé tous leurs
efforts pour me fournir les informations nécessaires.
A toutes les personnes qui ont participé, de près ou de loin, à la
réalisation de ce projet.
A tous mes amis qui m'ont apporté leur soutien moral pendant cette
année d'études, je les en remercie sincèrement.
Et finalement, aux respectueux membres du jury qui m’ont honoré
d’avoir accepté d’évaluer mon travail.
Table des matières
Introduction Générale _______________________________________________ 1
Chapitre 1. Présentation Générale __________________________________ 2
Introduction__________________________________________________________ 2
1.1. Cadre du stage_________________________________________________ 2
1.1.1. Organisme d’accueil __________________________________________________ 2
1.1.2. Direction d’accueil ___________________________________________________ 4
1.1.3. Cadre du travail______________________________________________________ 5
1.2. Présentation du projet __________________________________________ 5
1.2.1. Problématique _______________________________________________________ 5
1.2.2. Objectifs ____________________________________________________________ 8
1.2.3. Planification du projet ________________________________________________ 8
1.3. Technologies utilisées ___________________________________________ 8
1.3.1. Le formalisme UML __________________________________________________ 8
1.3.2. Le choix du cycle de développement _____________________________________ 9
Conclusion __________________________________________________________ 14
Chapitre 2. Etude préalable _______________________________________ 15
Introduction_________________________________________________________ 15
2.1. Etude de l’existant_____________________________________________ 15
2.1.1. Le logiciel de Gestion AMASIS_______________________________________ 15
2.1.2. Procédure actuelle _________________________________________________ 16
2.1.3. Critique de l’existant _______________________________________________ 17
2.2. Solution proposée _____________________________________________ 18
Conclusion __________________________________________________________ 18
Chapitre 3. Spécification des Besoins _______________________________ 19
Introduction_________________________________________________________ 19
3.1. Identification des besoins _______________________________________ 19
3.2. Spécification des besoins fonctionnels_____________________________ 19
3.3. Spécification des besoins non fonctionnels _________________________ 20
3.4. Planification des sprints ________________________________________ 21
Conclusion __________________________________________________________ 22
Chapitre 4. Conception Détaillée___________________________________ 23
Introduction_________________________________________________________ 23
4.1. Conception architecturale de la solution __________________________ 23
4.2. Architecture détaillée __________________________________________ 24
4.2.1. Diagramme de Classe ______________________________________________ 24
4.2.2. Diagramme de Cas d’utilisation Général _______________________________ 29
4.2.3. Raffinement Cas « Gérer les utilisateurs »______________________________ 30
4.2.4. Raffinement cas « Evaluer Tiers » ____________________________________ 32
4.2.5. Diagramme de Séquence cas « Authentification »________________________ 32
4.2.6. Raffinement cas « Gérer Litiges »_____________________________________ 33
4.2.7. Diagramme de Paquetage ___________________________________________ 34
Conclusion __________________________________________________________ 36
Chapitre 5. Réalisation___________________________________________ 37
Introduction_________________________________________________________ 37
1.1. Environnement de développement _______________________________ 37
1.1.1. Environnement matériel ____________________________________________ 37
1.1.2. Environnement Logiciel ____________________________________________ 38
1.2. Les langages de programmation _________________________________ 42
1.3. Phase d’implémentation ________________________________________ 44
1.3.1. Contraintes_______________________________________________________ 44
1.3.2. Pratiques adoptées_________________________________________________ 44
1.4. Diagramme de déploiement _____________________________________ 45
1.5. Les interfaces_________________________________________________ 46
Conclusion __________________________________________________________ 49
Conclusion générale _______________________________________________ 50
Nétographie ______________________________________________________ 51
Annexe 1 : Formulaire de pré évaluation des Fournisseurs et des Sous-traitants
____________________________________________________________________ 52
Annexe 2 : Fiche de suivi de la performance des Fournisseurs _____________ 54
Annexe 3 : Fiche de suivi de la performance des Sous-traitants_____________ 55
Table des figures
Figure 1: Organigramme actuel de Tunisair Technics...................................................... 3
Figure 2: Organigramme de la direction d'accueil (DAA) ............................................... 4
Figure 3: Diagramme de Gantt : Planning du stage.......................................................... 8
Figure 4: Processus de Scrum......................................................................................... 10
Figure 5: Le logiciel AMASIS........................................................................................ 16
Figure 6: Planification des Releases du Scrum............................................................... 21
Figure 7: Architecture matérielle de l'application........................................................... 24
Figure 8: Diagramme des Classes................................................................................... 28
Figure 9: Diagramme de cas d'utilisation Général.......................................................... 29
Figure 10: Diagramme de cas d'utilisation « Gérer les utilisateurs » ............................. 30
Figure 11: Diagramme de cas d'utilisation « Evaluer Tiers »......................................... 32
Figure 12: Diagramme de Séquence cas « Authentification »........................................ 33
Figure 13: Diagramme de cas « Gérer litiges » .............................................................. 33
Figure 14 : Diagramme de paquetage............................................................................. 35
Figure 15 : Diagramme de Déploiement......................................................................... 45
Figure 16 : Interface « Accueil » .................................................................................... 46
Figure 17 : Interface « Login »....................................................................................... 46
Figure 18 : Interface « Logout »..................................................................................... 47
Figure 19 : Interface « Gestion des Contrats » ............................................................... 47
Figure 20 : Interface « Ajout Contrat »........................................................................... 48
Figure 21 : Interface « Modifier Contrat » ..................................................................... 48
Table des tableaux
Table 1: Critères de sélection des fournisseurs de la norme ISO 9001 ............................ 7
Table 2: Méthode classique Vs Scrum ........................................................................... 12
Table 3: Description textuelle des Classes ..................................................................... 26
Table 4: Description textuelle du Diagramme de cas d'utilisation Général.................... 30
Table 5: Description textuelle du cas d'utilisation « Ajouter un utilisateur »................. 31
Table 6: Description textuelle du cas d'utilisation « Supprimer un utilisateur »............ 31
Table 7: Description textuelle du cas d'utilisation « Gérer Evènement Estimable »...... 32
Table 8: Description textuelle du cas d'utilisation « Ajouter Litige » ............................ 34
Table 9: Environnement Matériel................................................................................... 37
Table 10: Environnement Logiciel ................................................................................. 38
Glossaire
Abréviation Signification
AMASIS Aircraft Maintenance And Spares Information System
AOG Aircraft On Ground (Avion cloué au sol)
APRS Approbation pour Remise en Service
AS/400 Mini-Ordinateur d’IBM dont le système d’exploitation est l’OS/400
(Operating System 400)
DAA Direction des Achats Aéronautiques
DGAC Direction Générale de l'Aviation Civile
EASA European Aviation Safety Agency (Agence européenne de la sécurité
aérienne)
GMAO Logiciel de Gestion de la Maintenance Assistée par Ordinateur
ISO 9001 Fait partie de la série des normes ISO 9000. Elle définit des exigences
concernant l'organisation d'un système de gestion de la qualité.
Part 145 Certification de l'EASA qui prescrit les exigences des ateliers
d’entretien des aéronefs et éléments d'aéronefs destinés à être remis en
service en transport aérien public
Scrum Abréviation de scrummage = mêlée (Rugby) : schéma d'organisation
de développement de produits complexes
UML Unified Modeling Language
1
Introduction Générale
Le système de management de la qualité est très important pour une organisation
parce qu’il permet de mesurer la performance par rapport aux objectifs fixés, ainsi que
l’engagement dans une démarche d’amélioration continue.
Son application peut varier selon la structure du domaine appliqué. Dans un service
achat, qui est le cas de ce projet, il est difficile de réussir le virage qualité en l'absence
d'un système performant d'évaluation des fournisseurs. La qualité des produits et des
services étant intimement liée à celle des fournisseurs, il sera difficile de maîtriser la
chaîne d'approvisionnement si on ne connaît pas la performance de ces derniers. La
qualité n'arrive pas seule et ne s'achète pas. Il faut la bâtir et l'entretenir constamment.
Un tel « tableau de bord », particulièrement intéressant pour le Service des Achats,
l'est aussi pour la Direction de la Qualité, d'autant plus qu'il constitue la base des
programmes de certification et de partenariat avec les fournisseurs. En contrepartie, sa
mise en application pose des enjeux de taille aussi bien dans la conception, la collecte et
le traitement des données volumineuses et dans la présentation.
Encore une fois, les technologies de l'information et des communications ouvrent des
perspectives intéressantes en la matière. Dans le présent rapport, nous allons montrer
comment peut être si important l'apport de ces technologies pour une compagnie telle que
Tunisair Technics vues les exigences particulières en matière de qualité de son domaine
d'intervention à savoir la maintenance aéronautique. Il comporte cinq chapitres. Le
premier est consacré à une présentation générale du cadre du stage, du projet et des
technologies utilisées. Le deuxième chapitre décrit une étude préalable du projet. Le
troisième chapitre est dédié à la spécification et l’analyse du nouveau système. Le
quatrième chapitre expose la conception détaillée du système, une approche globale et
détaillée. Enfin, le dernier chapitre, présente l’étape de réalisation de l’application.
Chapitre 1. Présentation Générale
Introduction
Dans ce chapitre, nous présenterons une vue globale sur l’organisme d’accueil,
l’infrastructure, le fonctionnement et le domaine d’activité de Tunisair Technics au sein
duquel ce stage a été réalisé. Nous aborderons dans une première section une présentation
de la société, dans la deuxième section une présentation du projet et dans la troisième
section les technologies choisies pour mener à bien la phase d'analyse.
1.1. Cadre du stage
1.1.1. Organisme d’accueil
TUNISAIR :
TUNISAIR est la première compagnie aérienne en Tunisie, inaugurée le 21 octobre
1948. Elle avait transporté plus de 90 Millions de passagers en 65 ans d’existence.
Possédant une flotte de 28 avions en exploration dont 19 Airbus et 9 Boeing. TUNISAIR
organise environ 96 vols par jour vers 116 destinations dans 38 pays.
Tunisair Technics :
Tunisair Technics est un Organisme d’Entretien filial du groupe TUNISAIR
(transporteur aérien).Il réalise les travaux, de maintenance, de révision partielle ou
générale, d'inspection, de réparation, de modification sur les aéronefs et éléments
d'aéronef selon un tableau qui spécifie leurs types et le degré d'intervention allant du
simple test à la révision générale.
L’organisme assure ainsi le maintien des avions dans un état de navigabilité et de
sécurité permanente conformément à la réglementation aéronautique en vigueur. Le
programme d'entretien pour une navigabilité permanente associe les fonctions de
Maintenance, de Contrôle, d'Engineering et de l'Approvisionnement. Pour cela Tunisair
Technics a établi un Manuel des spécifications d'Organisme d’Entretien (MOE)
conformément aux exigences PART 145 qui contient toutes les procédures qui doivent
Chapitre 01. Présentation générale
3
être mises en place afin de se conformer aux exigences de la réglementation européenne
et d’obtenir l’agrément.
TUNISAIR à travers sa filiale Tunisair Technics a obtenu l’agrément PART-145
depuis Janvier 2003 sous le N° EASA .145.0135, qui lui permet aussi d'entretenir et
d'intervenir sur les avions européens et de déclarer leur remise en service à l'issue de tout
entretien en signant l'APRS.
L’organigramme de Tunisair Technics présenté dans la figure suivante montre les
différents directions et départements de l’organisme.
Figure 1: Organigramme actuel de Tunisair Technics
Chapitre 01. Présentation générale
4
1.1.2. Direction d’accueil
Ce stage a été effectué au sein de la Direction des Achats Aéronautiques (DAA). Elle
comporte quatre départements, gérés chacun par un chef de département qui est en contact
permanent avec le directeur responsable de la DAA. Chaque département est subdivisé à
des services comportant des entités, est présenté par la figure suivante :
Figure 2: Organigramme de la direction d'accueil (DAA)
La DAA assure les fonctions suivantes :
 Fonction Gestion et Achat de Services :
 Gestion des révisables et de la sous-traitance Airbus, Boeing et divers ;
 Planification de la matière : Gestion des consommables, gestion des ingrédients
et des divers, et gestion des chantiers de maintenance ;
 Analyse et optimisation des stocks.
 Fonction Achats à l'étranger et locaux :
 Prospection et étude de marchés ;
 Gestion des commandes Airbus, Boeing et divers : Lancement, suivi et traitement
des arrivées et des litiges.
 Fonction Contrôle de Gestion :
Direction
Achats
Aéronautiques
Département
Gestion &
Achat de Services
Département
Achats à l’Etranger
Département
Achats Locaux
Département
Contrôle de Gestion
Département
AOG Desk
Secrétariat de
Direction
Chapitre 01. Présentation générale
5
 Gestion du budget et analyse des coûts ;
 Gestion des contrats d'achat et de sous-traitance ;
 Paiement des achats et des services à l'étranger et locaux.
 Fonction AOG Desk :
 Résoudre les problèmes de pièces de rechange critiques conjointement avec le
personnel de contrôle de la maintenance.
1.1.3. Cadre du travail
Ce projet à Tunisair Technics, rentre dans le cadre d’un projet de fin d’études au
cours de notre formation de technicien supérieur en Science et technologies de
l’information et de la communication au sein de l’ISET’Com. Il a pour but de mettre en
place une application de gestion de processus dans le cadre de l’achat et de la sous-
traitance.
1.2. Présentation du projet
1.2.1. Problématique
Origine :
Afin de répondre à des exigences réglementaires DGAC et Part 145, Tunisair
Technics est appelée à mettre en place d'un système informatisé de gestion des processus
d'achat et de sous-traitance dont principalement le système d'évaluation des fournisseurs.
Ceci requiert de la DAA une gestion et un contrôle rigoureux et proactifs, qui une
fois mis en place permettront en plus, de répondre à des exigences des normes de qualité,
de maîtriser le processus d'achat et de sous-traitance, d'améliorer ses relations avec les
fournisseurs en vue d'éventuels partenariats victorieux, de satisfaire au mieux aux
exigences de ses clients à l’échelle mondiale, et même d’augmenter les gains de
productivité.
Chapitre 01. Présentation générale
6
Motivation :
Face à des marchés fortement compétitifs, caractérisés par une demande de produits
personnalisés, de bonne qualité, livrés dans des délais minimaux et le tout au moindre
coût, une gestion efficace des achats locaux et/ou internationaux peut constituer un
avantage concurrentiel substantiel. En effet, la part du poids des achats se situe
fréquemment entre 40% et 80% du coût total du produit. La sélection des fournisseurs
devient ainsi une décision stratégique qui a un impact crucial sur la performance globale
de toute entreprise.
Aspects de la sélection :
Le problème de la sélection des fournisseurs doit être étudié sous deux aspects :
 La détermination des fournisseurs qui vont rentrer en compétition. Dans notre cas
tous les fournisseurs agréés ; donc disposant d’une certification. L’ANNEXE 1
détaille le formulaire de pré évaluation des fournisseurs et des sous-traitants établi
par la Direction de la Qualité.
 La sélection des meilleurs fournisseurs parmi les alternatives existantes. C'est cet
aspect du problème du choix des fournisseurs qu'on considèrera dans notre travail.
Critères de sélection :
Les critères de sélections des fournisseurs et sous-traitant utilisés dans la norme ISO
9001 sont les suivants.
Rang Critère
1 Prix
2 Livraison
3 Qualité
4 Capacité de production
5 Localisation géographique
6 Capacité technique
7 Gestion et organisation
8 Réputation et position dans l'industrie
9 Situation financière
9 Performance Passée
Chapitre 01. Présentation générale
7
9 Services de réparation
10 Attitude
11 Habileté d'emballage
11 Contrôle des opérations
12 Formation et support
12 Conformité des processus
12 Relations sociales
12 Système de communication
12 Réciprocité de la relation
12 Impression
13 Désir de faire des affaires
13 Volume des achats dans le passé
14 Politique de garantie
Table 1: Critères de sélection des fournisseurs de la norme ISO 9001
On distingue deux types de critères : les critères quantitatifs et ceux qualitatifs. Ils
ont fait l'objet d'une procédure diffusée par la Direction de la Qualité. Les critères de
sélection des fournisseurs se trouvent en Annexe 2. Les critères de sélection des sous-
traitants se trouvent en Annexe 3.
Méthode d'évaluation :
Plusieurs méthodes d'évaluation sont utilisables. La Direction de la Qualité a spécifié
la méthode linéaire avec des pondérations spécifiques.
Mission :
Pour récapituler, la mission de ce sujet est de gérer des fournisseurs et des sous-
traitants en marge de leurs échanges commerciaux avec l’entreprise. Ceux qui disposent
de certificats de vente ou de réparation aéronautiques vont entrer en compétition. Toute
leur activité commerciale sera suivie depuis l’attribution des devis, passant par la
livraison et la facturation et terminant par la garantie. Un certain nombre de critères
d’évaluation devra être enregistré et évalué à chaque échange : respect des délais, des
prix, la qualité des services, les litiges, la garantie, … etc. Aux meilleurs de ces
fournisseurs et sous-traitants seront attribués des contrats.
Chapitre 01. Présentation générale
8
1.2.2. Objectifs
L'objectif de ce travail vise à créer et maintenir un réseau de fournisseurs fiables et
efficaces nécessaires à l'entreprise pour relever les défis concurrentiels croissants. La
capacité de cette dernière à produire un produit de qualité, à un coût raisonnable et de
manière opportune est fortement influencée par la performance des fournisseurs qui est
considérée comme l'un des facteurs déterminants pour le succès.
1.2.3. Planification du projet
A fin de mieux exploiter le temps alloué à la réalisation du projet de fin d’étude, une
bonne gestion de ce temps est nécessaire. La figure suivante vous montre les différentes
tâches et sous tâches qu’on exécutera pendant la période du stage.
Figure 3: Diagramme de Gantt : Planning du stage
1.3. Technologies utilisées
Le choix d’une méthodologie de développement devient une décision primordiale
puisqu’elle permet de guider un utilisateur tout au long du processus de développement
et de fournir un moyen de vérifier, valider et tester les fonctionnalités de l’application.
1.3.1. Le formalisme UML
Le recours à la modélisation est depuis longtemps une pratique indispensable au
développement, car un modèle est prévu pour arriver à anticiper les résultats du codage.
Chapitre 01. Présentation générale
9
Un modèle est en effet une représentation abstraite d’un système destiné à en faciliter
l’étude et à le documenter.
C’est un outil majeur de communication entre les différents intervenants au sein d’un
projet. Aujourd’hui, langage de modélisation UML est le standard industriel de la
modélisation objet N[1].
UML se définit comme un langage de modélisation graphique et textuel destiné à
comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des
architectures logicielles, concevoir des solutions et communiquer des points de vue. Nous
avons choisi UML pour ces deux points essentiels : UML n’impose pas de méthode de
travail particulière, il peut être intégré à n’importe quel processus de développement
logiciel de manière transparente N[2]. En plus UML est une sorte de boîte à outils, qui
permet d’améliorer progressivement les méthodes de travail, tout en préservant les modes
de fonctionnement.
Intégrer UML par étapes dans un processus, de manière pragmatique, est tout à fait
possible. La faculté d’UML de se fondre dans le processus courant, tout en véhiculant
une démarche méthodologique, facilite son intégration et limite de nombreux risques.
1.3.2. Le choix du cycle de développement
La méthodologie est une démarche à suivre pour obtenir un résultat quasi-certain.
Parmi ces différentes méthodologies, on peut citer le modèle en cascade (waterfall)
utilisée souvent pour des projets dont les besoins sont spécifiés dès le début et les
méthodologies agiles (Scrum) qui peuvent être utilisé avec divers types de projets. Pour
ce projet nous avons opté pour la méthode de gestion de projet Scrum N[3].
Le principe de base de Scrum:
 Consiste à dégager en un premier temps le maximum de fonctionnalités à réaliser
pour former le backlog du produit ;
 En second temps, le Scrum master, Product owner et l’équipe font une réunion « la
sprint planning » pour dégager les sprints backlog ;
Chapitre 01. Présentation générale
10
 Ensuite, nous décomposons les sprints backlog en sprint (itération) et durant chaque
sprint on fait une réunion « le Scrum master et l’équipe » pour inspecter l’avancement
du sprint.
 Ainsi et à la fin de chaque sprint on a un produit partiellement fonctionnel appelé
incrément, donc on fait deux réunions la « sprint review » et la « rétrospective » ;
 Et ainsi de suite jusqu’à ce que tous les sprints soient achevés.
Figure 4: Processus de Scrum
Le choix de la méthode Scrum pour le pilotage de notre projet est basé sur les
avantages que ce dernier apporte, vu que cette méthode offre plus de souplesse, plus de
réactivité et une meilleure adaptation au changement due à des itérations courtes.
 Pourquoi la méthodologie Scrum :
Dans cette section nous allons comparer la méthode classique avec la méthode Scrum
à l’aide du tableau suivant :
Chapitre 01. Présentation générale
11
Thème Approche Traditionnelle Approche Agile
Cycle de vie En cascade ou en V, sans
rétroaction possible, phases
séquentielles.
Itérative et Incrémentale
Planification Prédictive, caractérisé par des
plans plus ou moins détaillés sur la
base d’un périmètre et d’exigences
définies et stable au début du projet
Adaptative avec plusieurs niveaux de
planification avec ajustements si
nécessaires au fil de l’eau en fonction
des changements survenus
Documentation Produire en quantité importante
comme support de communication,
de validation
Réduite au strict nécessaire au profit
d’incréments fonctionnels pour
obtenir le feedback du client
Equipe Une équipe avec des ressources
spécialisées, dirigées par un chef
de projet
Une équipe responsabilisée ou
l’initiative et la communication sont
privilégiées, soutenue par le chef de
projet
Qualité Contrôle qualité à la fin du cycle
de développement. Le client
découvre le produit fini
Un contrôle qualité précoce et
permanent, au niveau du produit et
du processus. Le client visualise les
résultats tôt et fréquemment
Changement Résistance vire opposition au
changement. Processus lourds de
gestions des changements acceptés
Accueil favorable au changement
inéluctable intégré dans le processus
Suivi de
l’avancement
Mesure de la conformité aux plans
initiaux
Un seul indicateur d’avancement : le
nombre de fonctionnalités
implémentées et le travail restant à
faire
Chapitre 01. Présentation générale
12
Thème Approche Traditionnelle Approche Agile
Gestion des
risques
Processus district, rigoureux de
gestion des risques
Gestion de risque intégrée dans le
processus global, avec la
responsabilité de chacun dans
l’identification et la résolution des
risques.
Mesure du
succès
Respect des engagements initiaux
en termes de cout et niveau de
qualité
Satisfaction client par la livraison de
valeur ajoutée
Table 2: Méthode classique Vs Scrum
 Pilotage du projet avec la méthodologie Scrum
Scrum se base sur quatre concepts qui sont l’équipe avec les rôles bien définis, les
blocs de temps et les artefacts et les réunions.
Pour piloter un projet, les membres de l’équipe Scrum font recours à plusieurs
techniques. La technique la plus populaire et la plus répandue, consiste à créer des Post-
It note et de les faire coller sur un tableau. L’autre technique consiste à créer des fichiers
sur Excel contenant les informations sur les sprints et les user story, Ce fichier est partagé
entre les membres de l’équipe avec la possibilité de le consulter et de le modifier.
Pour cette raison, plusieurs outils sont apparus offrant des services qui facilitent le
suivi de la priorité, la traçabilité et la gestion du travail. Parmi les outils existant nous
avons choisi d’utiliser Ice Scrum.
o L’équipe et les rôles
Il existe 3 rôles qu’on décrira brièvement :
 Directeur de produit ou (Product owner en anglais) : Représente le client ou le
client lui-même et il est généralement expert dans le domaine. Et contrairement à ce que
son nom l’indique, ses responsabilités sont limitées à l'établissement des limites des
projets et de chaque itération.
Chapitre 01. Présentation générale
13
 Scrum master : gérant de l’application, assigner souvent comme le manager du
projet, veille à ce que chacun travaille en maximum de sa capacité et essaye d’éliminer
les obstacles.
 Equipe de Scrum (Scrum Team): formé par des personnes chargées d’implémenter
les besoins du client. Cette équipe est formée d’infographiste, développeurs, testeurs et
concepteurs.
o Les réunions
Scrum est dirigé par quatre types de réunion :
 Sprint planning (planification du sprint): pour planifier les itérations ou sprints
(soit pour présenter la liste du product owner ou pour décomposer le projet en tâches) et
discuter des user stories;
 Mêlée quotidienne ou Scrum quotidien (Daily Scrum) : cette réunion qui se fait
debout, quotidiennement et à une durée de 15 minutes. Le Scrum master inspecte l’état
de l’avancement du sprint et identifie les problèmes. Au cours de ce meeting ils doivent
répondre à trois questions (Qu’est-ce que j’ai fait hier? Qu’est-ce que je fais aujourd’hui?
Quels sont les problèmes?);
 Sprint review (Revue du sprint): bilan de l’itération et pour faire une présentation
au client afin d’avoir son feedback. L’objectif ici est de valider le logiciel qui a été produit
pendant ce sprint;
 Retrospective : Cette étape se fait à la fin de chaque sprint, on inspecte le processus
du travail et essaye de déduire ce qui a fonctionné ou pas. Cette réunion dure de 15 à 30
minutes. On applique un principe « Start/Stop/Continue »: ce qu’on aimerait " faire,
arrêter de faire et continuer à faire ".
Chapitre 01. Présentation générale
14
o Les artéfacts
 Burn down chart :
C’est un tableau d’analyse qui permet d’inspecter la progression du sprint.
 Le Backlog de sprint (sprint Backlog):Le backlog de sprint est une liste de tâches
identifiées par l'équipe de Scrum et qui doit être achevée au cours du sprint. Lors
de la réunion de planification du sprint, l'équipe sélectionne un certain nombre
d'éléments produits du carnet de commandes, généralement sous forme d'histoires
utilisateurs, et identifie les tâches nécessaires pour compléter chaque user story.
La plupart des équipes estiment également le nombre d'heures. Chaque tâche aura
quelqu'un de l'équipe pour l’achever.
 Le backlog du produit (product backlog) :C’est un artéfact important du Scrum
représenté sous forme de tableau contenant les caractéristiques fonctionnelles ou
techniques qui constituent le produit souhaité. Les caractéristiques fonctionnelles
(user story) et les caractéristiques techniques (technical story).
Conclusion
Dans ce chapitre nous avons présenté le contexte général du projet, ensuite nous
avons exposé la problématique et les objectifs de notre travail et terminé avec le
chronogramme de son acheminement. La définition des connaissances et les technologies
nécessaires à notre projet permettent de passer à la phase suivante qui consiste à la
spécification et l’analyse du nouveau système. Cette spécification détaillée permettra de
mieux comprendre la conception de notre projet et qui fera l’objet du chapitre suivant.
Chapitre 2. Etude préalable
Introduction
L'Etude de l’existant est une étape importante pour la mise en route d’un projet
informatique ou autre type de projet qui permet de définir le processus métier et de
dégager les imperfections du système existant afin de l’améliorer ou le corriger.
2.1. Etude de l’existant
2.1.1. Le logiciel de Gestion AMASIS
AMASIS (Aircraft Maintenance And Spares Information System) est le progiciel de
gestion technique intégré (GMAO) utilisé par les services de Tunisair Technics dans la
gestion de sa maintenance aéronautique. Il est commercialisé depuis 25 ans par la société
IFRSKEYES ; une filiale d’Airbus créée en 1987.
Il est installé sur un mini-ordinateur d’IBM : l’AS/400 appelé encore system i5. Il est
développé en Java/400 et utilise la base de données de l’AS/400 qu’est la db2.
Il présente une architecture modulaire composée de 14 modules distincts et
complémentaires :
 La Gestion de la chaine logistique : Permet de gérer et suivre les expressions de
besoins, les niveaux des stocks, les flux de matière et d’assurer les
approvisionnements et la facturation relative aux achats, réparations, locations ou
échanges standards réalisés. Il comporte aussi un module de gestion des contrats.
 La Gestion Financière ;
 Le suivi de navigabilité ;
 La maintenance corrective ;
 La maintenance planifiée ;
 La Gestion de la production ;
 La Gestion de la Main d’œuvre ;
Chapitre 02. Etude préalable
16
 La Gestion des documents de Référence. Etude préalable
Figure 5: Le logiciel AMASIS
2.1.2. Procédure actuelle
La majorité écrasante des processus d’achat et de sous-traitance sont dominés par un
traitement manuel. Ci-après la situation actuelle des différents processus :
 Evaluation des fournisseurs : le logiciel d’AMASIS ne comportant pas un tel outil
et en l’absence d’un outil approprié c’est du manuel pratiquement, si ce n’est
l’utilisation de quelques états récapitulatifs édités à partir d’AMASIS pour dresser le
tableau d’évaluation. Aucune gestion informatisée n’existe pour gérer les accusés de
réception et les notifications d’envois des fournisseurs qui ne sont pas pris en
considération jusque-là. Les dates de ces éléments étant calculées grossièrement à
partir de la date d’une pièce : Ajout de 3 jours pour un tiers local et 7 jours pour un
tiers étranger.
 Gestion des licences : Un outil performant assurant cette fonction, est contenu dans
AMASIS mais n’est pas exploité. La gestion des licences se fait aussi manuellement ;
Chapitre 02. Etude préalable
17
 Gestion des Contrats : Un outil novice assurant cette fonction est contenu dans
AMASIS et ne satisfait pas aux besoins car il n’intègre aucun prix ni remise dans les
lignes de contrats. La gestion des contrats se fait donc aussi manuellement.
 Gestion des Commandes d’Achat : Un outil performant assurant cette fonction, est
contenu dans AMASIS et utilisé. La gestion des Commandes d’Achat est donc
informatisée.
 Gestion des Commandes de Réparation : Un outil performant assurant cette
fonction, est contenu dans AMASIS mais n’est pas utilisé en sa totalité. En faite la
gestion des devis n’y est pas utilisée quoi que très performante, pour cause qu’il ne
s’adapte pas à une règle de gestion de la procédure actuelle à savoir le logiciel
AMASIS n’accepte pas d’avoir la date de la Commande de Réparation antérieure à
la date du Devis. La gestion des Commandes de Réparation se fait donc aussi
manuellement dans une partie importante qu’est la gestion des devis.
 Gestion des Price Catalogs : Ces informations sont importantes pour l’évaluation
car elles donnent des prix d’achat références. Leur gestion est aussi manuelle.
 Gestion des Capability Lists : Ces informations sont importantes pour l’évaluation
car elles donnent des prix de réparation références, pour les différents types
d’intervention. Leur gestion est aussi manuelle.
 Gestion des Litiges : AMASIS ne supporte pas cette fonction que très peu. En effet
une simple zone de texte libre est prévue dans les Bons de Livraison servant à cet
effet. Quoi qu’utilisée par le service, elle reste insuffisante pour détailler le litige. En
effet il faudrait qu’il y ait au moins une date de constat de l’anomalie, et une
codification détaillée des causes de litiges.
2.1.3. Critique de l’existant
La majorité écrasante des processus d’achat et de sous-traitance sont dominés par un
traitement manuel. Tout le processus d’évaluation des fournisseurs se fait manuellement
via des documents non maitrisés nécessitant l’intervention d’un effectif important
engendrant une perte de temps énorme.
Le travail manuel et non maitrisé qui caractérise cette tâche stratégique pour la
compagnie, altère considérablement son fonctionnement engendrant des retards énormes
Chapitre 02. Etude préalable
18
pour l’exécution de ses taches dont les délais fixés par la norme sont dépassés largement.
En plus, il n’a pas la main mise sur le Système de Gestion (AMASIS) ce qui représente
un écart majeur dans la réglementation qualité en vigueur.
2.2. Solution proposée
Tenant compte des critiques citées ci-dessus et des besoins d'informatiser la fonction
d’évaluation des fournisseurs pour la DAA, la solution est de :
 Remédier au problème majeur de gestion manuelle des devis des Commandes de
Réparation et faire le nécessaire pour utiliser le module Gestion des devis d’AMASIS.
 Assister les utilisateurs de la DAA à démarrer l’exploitation du module Gestion
des licences d’AMASIS.
Ces deux points ont été traités avec mon encadrant d’entreprise, et ne figureront pas dans
la suite de ce rapport
 Concevoir et développer une application permettant d’assurer les deux parties
constituantes du processus de l’évaluation des fournisseurs :
 Fonction de Gestion :
 Gérer les Contrats ;
 Gérer les Price Catalogs ;
 Gérer les Capability Lists ;
 Gérer les Litiges.
 Fonction Qualité :
 Récapituler activité Tiers ;
 Evaluer Tiers.
Conclusion
A la fin de ce chapitre nous avons détaillé, analysé et critiqué la procédure existante
ce qui nous permet d’avoir une idée claire sur les spécifications de notre future application
qui seront détaillées dans le chapitre suivant.
Chapitre 3. Spécification des Besoins
Introduction
Pour réussir un projet, il est obligatoire de mener à bien l’analyse et la spécification
des besoins. Etant la première étape primordiale du cycle de vie d’un logiciel, il est
fondamental de bien déterminer les exigences exprimées par l’utilisateur. Afin de
comprendre le contexte de l’application nous allons, au cours de cette étape, déterminer
les besoins fonctionnels, les besoins non fonctionnels ainsi que les acteurs qui interagiront
avec notre application.
3.1. Identification des besoins
Identification des acteurs
Les différents acteurs qui se présentent pour notre système se répartissent en trois
catégories principales à savoir :
 Administrateur : Il a pour rôle de gérer les comptes des utilisateurs, de gérer les
auditeurs, les audités, gérer les référentiels, les formations réglementaires et les
secteurs d’activité.
 Utilisateur de Gestion : Il a un rôle de gestion des litiges, des Contrat, prix.
 Gestion de Qualité : Il a un rôle de qualité qui lui permet d’évaluer Tiers
3.2. Spécification des besoins fonctionnels
Ce sont les fonctionnalités du système et les actions qu’un acteur peut effectuer afin
de répondre à la demande de l’utilisateur.
Nous allons dans cette partie identifier les besoins fonctionnels par acteurs, c’est-à-
dire l’action que peut effectuer chaque intervenants sur le système et ceci dans le but de
préciser le rôle de chaque acteur au sein du futur logiciel.
 Besoins fonctionnels pour l’administrateur:
 Gérer les Utilisateurs.
 Gérer les Logs.
Chapitre 03. Spécification des Besoins
l’outil
20
 Gérer les Paramètres.
 Besoins fonctionnels de l’Utilisateur de gestion:
 Gérer les Contrats.
 Gérer les Price Catalogs.
 Gérer les Capability Lists.
 Gérer les Litiges.
 Besoins fonctionnel de l’Utilisateur de qualité:
 Récapituler activité Tiers ;
 Evaluer Tiers.
 Besoins fonctionnel pour tous les utilisateurs :
 S’authentifier pour accéder à l’application : l’utilisateur doit être authentifié pour
accéder à l’interface le concernant selon son rôle dans le système.
3.3. Spécification des besoins non fonctionnels
Un besoin non fonctionnel aussi appelé besoin d’affaire, Ce sont les contraintes et
restrictions liés à l’environnement lors de l’implémentation de l’application.
Les besoins non fonctionnels sont :
 La disponibilité : Le système constitue le cœur de l’activité, il est obligatoire qu’il
soit toujours en service.
 La sécurité : C’est primordial pour l’application, étant donné qu’elle gère des
données confidentielles. Une authentification et un cryptage des données sensibles
est indispensable.
 La performance : Le fait que l’application est multiutilisateur et contient un nombre
de données important, le temps de traitement doit être réduit impérativement.
 L’ergonomie : L’utilisation d’une interface utilisateur simple et facile à comprendre,
pour qu’elle ne soit pas ambiguë à tous utilisateurs ignorant l’informatique.
 L’interopérabilité : On n’a pas besoin d’installer quoi ce soit pour pouvoir utiliser
cette application, juste un navigateur web, en plus elle est multiplateforme.
 La clarté des documents : Les documents et les rapports que le système imprimera
seront lisibles.
Chapitre 03. Spécification des Besoins
l’outil
21
3.4. Planification des sprints
La réunion de planification des sprints (sprint planning) 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.
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 deux releases:
Le premier sera gestion des ressources et des établissements et le deuxième sera la
gestion des processus.
Pour notre cas la durée de 10 jours pour un sprint semble adéquate.
La suivante résume notre planning de travail
Figure 6: Planification des Releases du Scrum
Plan de
Release
Sprint#1 Sprint#2 Sprint#3 Sprint#4
Gérer Personnel
Gérer Direction
Gérer Référentiels
Gérer Secteur
Gérer Personnel
Gérer Processus
de Gestion
Gérer Notification
Gérer Validation
Gérer Tiers
Gérer CR
Gérer CA
Authentification
Gérer Litiges
Chapitre 03. Spécification des Besoins
l’outil
22
Conclusion
Après avoir distingué les rôles de chaque utilisateur, spécifié les besoins fonctionnels
et non fonctionnels et planifié nos sprints, il est temps de commencer à concevoir et à
développer notre application. Dans le chapitre suivant, nous allons nous initier avec la
conception et le développement du premier release.
Chapitre 4. Conception Détaillée
Introduction
Une fois qu’on a déterminé le backlog du produit, nous le découpons en petites
parties qui s’appellent « release ». La release est constitué d’itération ou sprint. La durée
de la release est déterminée par le « product owner » en collaboration avec l’équipe. Au
niveau de ce chapitre, nous allons traiter les histoires utilisateurs de nos sprints afin de
produire les releases pour produire logiciel potentiellement livrable.
4.1. Conception architecturale de la solution
Architecture matérielle
Notre application est une application web qui se connecte à un serveur de base de
données distant, via Internet, afin de récupérer les données. Ceci nécessite aussi
l’intégration d’un serveur web entre l’application client et le serveur de base de données.
D’où l’architecture de notre application à 3 niveaux (architecture 3-tiers), partagée entre
les trois éléments suivants :
 L’utilisateur (Administrateur, Utilisateur de Gestion, Gestion de Qualité) ;
 Le serveur Web : Vu que les données seront communiquées entre deux
environnements hétérogènes, le rôle principal du serveur web est de gérer la
communication entre l’utilisateur et le serveur de base de données ;
 , Le serveur de base de données fournit les données au serveur web.
Chapitre 04. Conception Détaillée
24
Figure 7: Architecture matérielle de l'application
4.2. Architecture détaillée
Maintenant, nous détaillerons la conception de notre solution en présentant aussi bien
les diagrammes des classes, le diagramme association, les diagrammes de package, ainsi
que quelques diagrammes d’activités de notre système.
4.2.1. Diagramme de Classe
Notre base des données est une base regroupant plusieurs informations cohérentes
qui seront d’une utilité majeure. Afin de détailler l’architecture de cette base, Nous avons
développé le modèle Entité-Association. A partir de la figure 8, nous présentons le
diagramme de classes du paquet modèle qui comporte les différents objets permettant le
déroulement des scénarios de notre application.
Ces classes représentent les différentes tables de notre base mappées grâce au
« Framework Hibernate ». Le diagramme suivant illustre les différentes classes créées
pour notre système :
Entité Description
Applicabilité Elle représente l’applicabilité des pièces
BonDeReception Elle représente l’entête du Bon de Réception
Catalogue Elle représente la liste des prix d’achat des pièces
Certificat Elle représente les données Relatives à un certificat
Chapitre 04. Conception Détaillée
25
Entité Description
Commande Elle représente l’entête d'une Commande
Constructeur Elle représente un type de Tiers
ContactTiers Elle représente les données relatives à la personne de
contact de tiers
Contrat Elle représente l’entête du Contrat
CotationFournisseur Elle représente l’entête de la Cotation Fournisseur
DemandeDeCotation Elle représente l’entête de la Demande de Cotation
Devise Elle représente la devise utilisée
Evaluation Elle représente l’évaluation du Tiers
Facture Elle représente l’entête de Facture
Fournisseur Elle représente le type de Tiers
Indicateur Elle représente les champs d’évaluation
LigneDeFacture Elle représente les Factures passées par un Tiers
Litige Elle représente les types de litiges
Magasin Elle représente le magasin émetteur de la commande
ModeDePaiement Elle représente le Mode de Paiement
ModeDeReglement Elle représente le Mode de Règlement
MotifLitige Elle représente l’explication de litige
OrganismeDeCertificat
ion
Elle représente l’organisme de Certification
PartNumber Elle Représente les pièces d’un avion
PersonneContact Elle représente la personne de Contact
Piece Elle représente le numéro de la série de la pièce
PosteDeCommande Elle représente les commandes passées par la société.
PosteDeContrat Elle représente les Ligne de Contrat
PosteDeDemandeDeCo
tation
Elle représente les Cotations passées par la société.
PostesCotationFournis
seur
Elle représente les Cotations passées par les Fournisseurs
PostesDeReception Elle représente les Postes de Réceptions
Chapitre 04. Conception Détaillée
26
Entité Description
ReceptionRejetee Elle représente la Réception Annulée
RepresentantTiers Elle représente le Représentant du Tiers
Société Elle représente la Société (Tunisair, Tunisair Express, ….)
SousTraitant Elle représente le tiers Réparateur
Tiers Elle représente le tiers
Travail Elle représente le Type de Travail (Test, Repair,
Overhaul)
TypeContrat Elle représente le Type de contrat (contrat d’achat, contrat
de réparation)
TypeDePaiement Elle représente le type de paiement
Table 3: Description textuelle des Classes
Chapitre 04. Conception Détaillée
27
Chapitre 04. Conception Détaillée
28
Figure 8: Diagramme des Classes
Chapitre 04. Conception Détaillée
29
4.2.2. Diagramme de Cas d’utilisation Général
Un cas d'utilisation (en anglais use case) permet de mettre en évidence les relations
fonctionnelles entre les acteurs et le système étudié. Le format de représentation d'un cas
d'utilisation est complètement libre, mais UML propose un formalisme et des concepts
issus de bonnes pratiques.
Figure 9: Diagramme de cas d'utilisation Général
Acteur Cas d’utilisation
Administrateur  Gérer les Utilisateurs.
 Gérer les Logs.
 Gérer les Paramètres.
Chapitre 04. Conception Détaillée
30
Utilisateur Qualité  Gérer les Litiges.
 Gérer les Contrats.
 Gérer les Capability Lists
 Gérer les Price Catalogs
Utilisateur Gestion  Evaluer Cotation
 Consulter Tiers
 Evaluer Tiers
Table 4: Description textuelle du Diagramme de cas d'utilisation Général
4.2.3. Raffinement Cas « Gérer les utilisateurs »
Figure 10: Diagramme de cas d'utilisation « Gérer les utilisateurs »
Titre Ajouter un Utilisateur
Acteur initiateur Administrateur
But du cas Ajouter un nouvel utilisateur de l'application
Pré-condition Application, BD, Serveur d’application
Post-condition en
cas de succès
L'utilisateur peut accéder à l'application.
Chapitre 04. Conception Détaillée
31
Titre Ajouter un Utilisateur
Description du
scénario
1. Ce cas commence quand l'administrateur demande l’ajout d’un
nouvel utilisateur.
2. le système affiche un formulaire d'ajout.
3. Après le remplissage du formulaire, l'administrateur valide les
coordonnées.
4. Le système vérifie si tous les champs sont remplis.
5. Si les champs sont vides. Alors Exception(E1)
6. Sinon le système vérifie si l’utilisateur existe déjà. Alors
Exception (E2).
7. Si l’utilisateur n’existe pas alors il va être enregistré et le système
affiche un message de succès
Exception (E1): s’il y'a un champ non rempli ou il y'a une erreur à la
connexion à la base de données. Le système affiche un message
d'erreur
(E2): si l’utilisateur existe, Le système affiche un message
d’erreur.
Table 5: Description textuelle du cas d'utilisation « Ajouter un utilisateur »
Titre Supprimer un Utilisateur
Acteur
initiateur
Administrateur
But du cas Supprimer un utilisateur de l'application
Pré-condition Application, BD, Serveur d’application
Post-condition
en cas de
succès
L'utilisateur ne peut pas encore accéder à l'application.
Description du
scénario
1. Ce cas commence quand l'administrateur demande la
suppression d’un utilisateur.
2. Le système affiche une interface de suppression avec la liste des
utilisateurs déjà enregistrés.
3. L'administrateur choisit l’utilisateur voulu et demande sa
suppression.
4. Le système effectue la suppression et affiche un message de
succès de suppression.
Table 6: Description textuelle du cas d'utilisation « Supprimer un utilisateur »
Chapitre 04. Conception Détaillée
32
4.2.4. Raffinement cas « Evaluer Tiers »
Figure 11: Diagramme de cas d'utilisation « Evaluer Tiers »
Titre Gérer Evènement Estimable
Acteur
initiateur
Utilisateur Qualité
But du cas Evaluer un Tiers
Pré-condition Application, BD, Serveur d’application
Post-condition
en cas de
succès
L’évènement ajouté pour faciliter l’évaluation .
Description du
scénario
1. Ce cas commence quand l'utilisateur demande d’évaluer un tiers.
2. le système affiche un formulaire d’indication des Evaluations.
3. Après le remplissage du formulaire, l’utilisateur valide les
coordonnées.
4. Le système vérifie si tous les champs sont remplis.
5. l’utilisateur demande d’imprimer l’évaluation
Table 7: Description textuelle du cas d'utilisation « Gérer Evènement Estimable »
4.2.5. Diagramme de Séquence cas « Authentification »
Les diagrammes de séquences peuvent servir à illustrer chaque cas d’utilisation et
forment une représentation temporelle des objets et de leurs interactions.
Nous débutons par le diagramme d’authentification.
Chapitre 04. Conception Détaillée
33
A ce stade, nous commençons par l’élaboration des diagrammes de séquence
systèmes à partir des cas d’utilisation détaillés précédemment.
En se référant aux descriptions textuelles élaborées dans la section précédente, nous
présenterons les diagrammes de séquences système adéquats. Nous constatons que certain
de ces cas sont similaires, nous avons choisi donc de faire certains cas d’utilisation.
Figure 12: Diagramme de Séquence cas « Authentification »
4.2.6. Raffinement cas « Gérer Litiges »
Figure 13: Diagramme de cas « Gérer litiges »
Chapitre 04. Conception Détaillée
34
Titre Ajouter Litige
Acteur
initiateur
Utilisateur Qualité
But du cas Ajouter un nouvel Litige
Pré-condition Application, BD, Serveur d’application
Post-condition
en cas de
succès
L'utilisateur ajout un type de litige.
Description du
scénario
1. Ce cas commence quand l’utilisateur demande l’ajout d’un
nouveau litige.
2. Le système affiche un formulaire d'ajout.
3. Après le remplissage du formulaire l'utilisateur valide les
coordonnées.
4. Le système vérifie si tous les champs sont remplis.
5. Si les champs sont vides. Alors Exception
(E1)
6. Sinon le système vérifie si le litige
existe déjà. Alors Exception (E2).
7. Si le litige n’existe pas alors il va être
enregistré et le système affiche un message de succès
Exception (E1): s’il y'a un champ non rempli ou il y'a une erreur à la connexion
à la base de données. Le système affiche un message d'erreur
(E2): si litige existe, Le système affiche un message d’erreur.
Table 8: Description textuelle du cas d'utilisation « Ajouter Litige »
4.2.7. Diagramme de Paquetage
Afin de garantir l’extensibilité de l’application et de minimiser le temps de
développement, nous avons découpé les différentes classes en modules N[4]. En effet,
cette décomposition nous permet de mieux structurer notre système et faciliter la
compréhension de ses fonctionnalités.
L’organisation de l’ensemble des modules constitue l’architecture logicielle de notre
système.
En effet on peut, avant présenter le diagramme de paquetage, distribuer les différents
paquets de notre diagramme (la figure 8) sur les différentes couches du modèle MVC
comme suit :
 Le modèle : A ce niveau, nous trouvons le paquetage model qui contient les objets
de persistance. Ces objets sont des classes utilisées par tous les paquetages de
Chapitre 04. Conception Détaillée
35
l’application. Elles représentent les tables de notre base des données. La principale
propriété de ces classes est qu’elles ne contiennent aucune méthode de traitement.
Elles contiennent simplement les getters et les setters pour récupérer ou bien
retourner la valeur d’un attribut. Ces classes contiennent ainsi le mappage avec
notre base de données relationnelle en utilisant la méthode d’annotations. On veut
dire par mappage la liaison entre les classes java avec les tables de la base.
En effet le mappage englobe la correspondance des attributs avec les colonnes de
la table associée à cette classe ainsi que le mappage des relations existantes entre
les tables, par exemple la relation one-to-many ou many-to-many.
 Le contrôleur : A ce niveau, nous trouvons les Managed Beans plus le contrôleur
« faces servlet » du « Framework JSF » pour la partie web. Concernant la partie
desktop, le contrôleur implémente donc un Action Listée c’est à dire un « écouteur »
de boutons.
 La vue : A ce niveau, nous trouvons seulement les pages xhtml (facelet du
Framework JSF), JSP (Java Server Pages) uniquement sans actions avec une
référence sur le Modèle pour faire des changements (en lecture) sur la vue en cas
de changement du Modèle.
Figure 14 : Diagramme de paquetage
Chapitre 04. Conception Détaillée
36
Conclusion
A ce stade, nous avons achevé le développement de notre dernier release de notre
application pour produire un logiciel complet et fonctionnel. Il nous reste cependant une
dernière étape qui consiste à implémenter l’application auprès du client final.
Chapitre 5. Réalisation
Introduction
La phase de clôture ou de fermeture est la dernière phase dans le cycle de
développement d’un logiciel avec Scrum. Cette phase est souvent appelée sprint de
stabilisation ou durcissement. Les tâches effectuées pendant cette phase ne sont pas
claires, et elles dépendent fortement du type de déploiement du logiciel.
Pour notre projet, on consacrera ce chapitre pour la présentation des langages et outils
de programmation utilisés pour la réalisation de notre application ainsi que le
déploiement. Nous finissons par la suite avec quelques interfaces graphiques du logiciel
fourni.
1.1. Environnement de développement
L’environnement de développement est un terme qui désigne l’ensemble des outils
et de langages utilisés pour l’implémentation d’une solution informatique. Nous
commençons par l’environnement matériel.
1.1.1. Environnement matériel
Pour le développement de cette application, Nous avons utilisé un pc avec la
configuration suivante :
Model ASUS X556U
CPU Intel Core i5-6200U (up to 2.80 GHz, 3M mémoire cache)
RAM 8 Go DDR3
GPU NVIDIA® GeForce® GT 920M (2 Go dédiée DDR3)
HDD 1To
SE Windows 10 64Bits pro
Table 9: Environnement Matériel
Chapitre 05. Réalisation
38
1.1.2. Environnement Logiciel
Les outils utilisés pour le développement des projets concernent :
 Le kit de développement en Java (JRE).
 La mise en place d'un environnement de développement (Eclipse Néon 2.0).
 L'installation et la configuration du serveur Java (Apache Tomcat V8.0).
 le SGBD MySQL 5
Les logiciels qui ont été utilisés pour l’implémentation de notre solution sont les
suivants:
Version Apache Tomcat 8.0
Version Eclipse Néon 2.0
Version Spring IDE 3.6.3.201411271034-RELEASE
Version Hibernate Tools for Eclipse 3.5.1.v20130102-1835-H100-Final
Version du Framework Hibernate Hibernate-release-4.3.8.Final
Version du Framework Spring Spring-Framework-4.1.5.RELEASE-dist
Version jsf Primefaces 2.0
Table 10: Environnement Logiciel
Eclipse
Eclipse est un IDE (environnement de développement intégré) écrit en Java,
extensible par des greffons, multi-langages et multi-plates-formes. Il est d'abord conçu
pour le langage Java mais ses nombreux greffons en font un environnement de
développement pour de nombreux autres langages de programmation N[5].
JRE
JRE : Java SE Runtime Environment (couramment JRE) c’est l’environnement où le
code java va être compilé afin que la machine virtuelle puisse l’interpréter puis l’exécuter.
Nous utiliserons le JRE1.8u121
Chapitre 05. Réalisation
39
Apache Tomcat
Apache Tomcat: C’est un serveur Java EE obligatoire pour le développement des
pages web dynamiques. Pour combler le manque de serveurs http classique qui ne
comprennent pas les servlets et JSP celui-ci utilise un moteur de servlet
Hibernate
Hibernate est un (ORM) mapping objet-relationnel N[6], c’est un ensemble de
bibliothèques qui vont ajouter une surcouche au SGBD pour permettre aux développeurs
de manipuler seulement les objets et ne plus se soucier de la base de données et des
requêtes SQL.
Hibernate Tools
Hibernate Tools est un ensemble d'outils pour Hibernate3 mis en œuvre comme une
suite intégrée de plugins Eclipse. Hibernate Tools est un élément essentiel de JBoss Tools
et donc également partie de JBoss Développer Studio.
Intègre les fonctionnalités suivantes à éclipse : Lapping Editor, Console, Reverse
engineering, etc.
Springs IDE
Springs IDE est un projet open-source qui fournit un ensemble de plugins pour l'IDE
Eclipse. Après l'installation des plugins Springs IDE, votre IDE comprend vos projets de
point de vue du cadre de Springs et vous offre une grande variété de fonctionnalités
supplémentaires qui font qu'il est plus facile et plus commode de travailler avec des
projets Springs dans Eclipse.
Chapitre 05. Réalisation
40
Springs Framework
Springs est considéré comme un conteneur dit « léger ». La raison de ce nommage
est expliquée par Erik Gollot dans l’introduction du document Introduction au Framework
Spring4 N[7].
Springs est effectivement un conteneur dit « léger », c’est-à-dire une infrastructure
similaire à un serveur d'applications J2EE. Il prend donc en charge la création d’objets et
la mise en relation d’objets par l’intermédiaire d’un fichier de configuration qui décrit les
objets à fabriquer et les relations de dépendances entre ces objets. Le gros avantage par
rapport aux serveurs d’application est qu’avec SPRING, les classes n’ont pas besoin
d’implémenter une quelconque interface pour être prise en charge par le Framework (au
contraire des serveurs d’applications J2EE et des Embus). C’est en ce sens que SPRING
est qualifié de conteneur « léger ».
Le contexte le plus important qu’on a utilisé pour notre application c’est IOC :
l’inversion de contrôle est assurée de deux façons différentes : la recherche de
dépendances et l'injection de dépendances, la programmation orientée aspect, une couche
d’abstraction.
Power Designer
C’est un logiciel de modélisation. Il permet de modéliser les traitements
informatiques et leurs bases de données associées. Créé par SDP sous le nom
AMC*Designer, racheté par Powersoft, ce logiciel est produit par Sybase depuis le rachat
par cet éditeur en 1995. Hors de France, la version internationale est commercialisée par
Sybase sous la marque Power Designer N[8].
Power AMC permet de réaliser tous les types de modèles informatiques. Il reste un
des seuls qui permet de travailler avec la méthode Merise, cela permet d'améliorer la
modélisation, les processus, le coût et la production d'applications.
Chapitre 05. Réalisation
41
WampServer
J’ai utilisé WampServer puisque c’est une plate-forme de développement Web sous
Windows pour des applications Web dynamiques. Il m’a permis donc de pouvoir
concevoir le site web transactionnel en local sur mon ordinateur.
WampServer est très complet puisqu’il dispose du serveur Apache2, gère des fichiers
du langage de scripts PHP et d’une base de données MySQL. Il possède également PHP
MyAdmin qui permet de gérer les bases de données.
Adobe Dreamweaver
Si un simple éditeur de texte, comme Notepad ou Bloc-notes fait très bien l’affaire.
J’ai tout de même choisi d’utiliser Adobe Dreamweaver.
Tout d’abord pour son auto complétion HTML et CSS qui est très pratique, agréable
et rapide. Ainsi que par les différents modes de conception offerts, la transition entre les
différents modes de conception est très rapide ce que je trouve très agréable lors du
commencement de la structure du site web. Il me permet de voir instantanément si mes
éléments graphiques ont été correctement appelés, structurés et positionnés.
Microsoft Word
Microsoft Word est souvent appelé simplement Word ou MS Word. C’est un
traitement de texte commercial largement utilisé a été conçue par Microsoft. MS Word
est un composant de la suite MS Office de logiciels de productivité. Il a été initialement
lancé en 1983 et a depuis été révisée de nombreuses fois. Il est disponible sous Windows
et Macintosh.
Chapitre 05. Réalisation
42
Microsoft Project
Microsoft Project est un logiciel de gestion de projet le plus populaire au monde,
développé et vendu par Microsoft. MS Project est conçue pour aider les gestionnaires de
projets à élaborer des plans, l'affectation de ressources à des tâches, suivi des progrès, la
gestion des budgets et l'analyse des charges de travail, etc.
1.2. Les langages de programmation
Java
Java est un langage de programmation informatique d'usage général qui est
concurrente, sur la base de classe, orienté objet, et spécifiquement conçu pour avoir aussi
peu de dépendances de mise en œuvre possible. Il est destiné à permettre aux
développeurs d'application « écrire une fois, exécuté partout » (WORA : « write once,
run anywhere »), ce qui signifie que le code Java compilé peut fonctionner sur toutes les
plateformes qui supportent Java sans la nécessité d'une recompilation. Des applications
Java sont généralement compilées en byte code qui peut fonctionner sur n’importe quelle
machine virtuelle Java (JVM) indépendamment de l'architecture informatique. En 2015,
Java est l'un des langages de programmation les plus populaires dans l'utilisation, en
particulier pour les applications web client-serveur.
HTML5
Le HTML est un langage qui a pour rôle de gérer et organiser le contenu d'une page
web. C'est un langage de description de données, et non un langage de programmation.
J'ai utilisé le HTML 5 qui est la dernière version du HTML qui est actuellement toujours
en développement.
Chapitre 05. Réalisation
43
CSS3
Le rôle du CSS est de gérer l'apparence de la page web (agencement, positionnement,
décoration, couleurs, taille du texte…). Ce langage est le complément du langage HTML
pour obtenir une page web avec du style. Le navigateur parcourt le document HTML.
Lorsqu'il rencontre une balise, il demande à la CSS de quelle manière il doit l'afficher.
JavaScript
JavaScript est un langage interprété par le navigateur. Le JavaScript est un langage
« client », c'est-à-dire exécuté chez l'utilisateur lorsque la page Web est chargée. Il a pour
but de dynamiser les sites Internet.
UML
Le langage de modélisation unifié, de l'anglais Unifie Modeling Language (UML),
est un langage de modélisation graphique à base de pictogrammes conçu pour fournir une
méthode normalisée pour visualiser la conception d'un système. Il est couramment utilisé
en développement logiciel et en conception orientée objet.
HQL (Hibernate Query Language) :
Hibernate Query Language (HQL) est un langage de requête orientée objet, similaire
à SQL, mais au lieu d'opérer sur les tables et colonnes, HQL travaille avec des objets
persistants et leurs propriétés. Les requêtes HQL sont traduits par Hibernate en requêtes
SQL classiques qui effectuent à tour de rôle action sur la base de données.
Chapitre 05. Réalisation
44
Bootstrap
Bootstrap est une collection d'outils utile à la création du design (graphisme,
animation et interactions avec la page dans le navigateur ... etc. ...) de sites et
d'applications web. C'est un ensemble qui contient des codes HTML et CSS, des
formulaires, boutons, outils de navigation et autres éléments interactifs, ainsi que des
extensions JavaScript en option.
1.3. Phase d’implémentation
1.3.1. Contraintes
Pour garantir la fiabilité, l’optimalité et la sécurité du projet, il est indispensable
d’étudier les contraintes et les problèmes pouvant nous rencontrer.
Pour répondre aux exigences d’implémentation de notre application, nous avons
respecté les contraintes suivantes :
 La modularité : La décomposition du logiciel en petits modules facile à maintenir
et entretenir, qui, en les rassemblant donneront un logiciel.
 La maintenabilité : la facilité de maintenir le système afin de le mettre à jour, c’est-
à-dire un système simple et rapide à réparer.
 La sécurité : les informations critiques seront cryptées, tels que les mots de passe
par des algorithmes de hachages.
 La portabilité : La capacité de l’application à fonctionner dans sous différents
environnements d'exécution.
1.3.2. Pratiques adoptées
 Règles de nommage : Donner des noms significatifs et explicites qui seront faciles
à retenir pour les noms des tables, attributs, nom des méthodes.
 Règles de présentation : Commenter les lignes de codes des classes java
 Règles de syntaxe : Utiliser des structures simples à comprendre et éviter les
complexités dans le code afin de réduire les risques de dysfonctionnement.
Chapitre 05. Réalisation
45
1.4. Diagramme de déploiement
Le diagramme de déploiement est une vue statique qui sert à représenter l'utilisation
de l'infrastructure physique par le système et la manière dont les composants du système
sont répartis ainsi que la relation entre eux N[9]. Les éléments utilisés par un diagramme
de déploiement sont principalement les nœuds, les composants et les associations. Les
caractéristiques des ressources matérielles physiques et des supports de communication
peuvent être précisées par stéréotype.
Figure 15 : Diagramme de Déploiement
Chapitre 05. Réalisation
46
1.5. Les interfaces
Figure 16 : Interface « Accueil »
Figure 17 : Interface « Login »
Chapitre 05. Réalisation
47
Figure 18 : Interface « Logout »
Figure 19 : Interface « Gestion des Contrats »
Chapitre 05. Réalisation
48
Figure 20 : Interface « Ajout Contrat »
Figure 21 : Interface « Modifier Contrat »
Chapitre 05. Réalisation
49
Conclusion
Au cours de ce chapitre nous avons décrit la phase de réalisation de notre système
d’information dans lequel nous avons défini les outils de travail utilisés. Nous avons
donné un aperçu sur les contraintes et la pratique adopté. Et les interfaces utilisateurs.
50
Conclusion générale
Au terme de ce rapport, j’avance que ce stage a été très enrichissant pour moi car il
m’a permis de découvrir le milieu professionnel à travers une société de grande envergure
telle que Tunisair Technics. J'ai pu distinguer à cet occasion plusieurs détails du secteur
de la maintenance en aéronautique dont principalement le volet de l'approvisionnement
qui présente plusieurs contraintes dans sa gestion en général et dans son système de
gestion informatisée plus particulièrement.
Il m’a permis de participer concrètement à ses enjeux au travers de ma mission visant
à mettre en application les éléments nécessaires pour l'élaboration assistée d'un tableau
de bord pour l'évaluation des fournisseurs. J’ai particulièrement apprécié l'approche de
compléter un logiciel de gestion déjà existant; l'objectif étant de fournir une solution et
non uniquement de développer des applications.
Au cours de mon stage, et pour le mener à bien, j'ai suivi une bonne planification
pour chaque étape. J'ai tout d’abord exploré les lieux pour la collecte d’informations
moyennant des interviews avec les services concernés afin de définir le système étudié.
Pour la conception j'ai utilisé des formalismes et des méthodes simples qui facilitent le
travail. Pour la réalisation de l’application, j'ai eu l'occasion d'apprendre et d'utiliser un
langage riche et souple.
Cette expérience m'a permis aussi bien de concrétiser les connaissances qui m'ont été
transmises au cours de ma formation que d’apprendre de nouvelles techniques et
technologies. J'ai été appelé à surmonter plusieurs difficultés auxquelles j'ai fait face. Au
début c’était de comprendre le besoin du client, ensuite de collecter et mettre en ordre le
tas d’informations collectées. Enfin j'ai dû faire le nécessaire pour développer le nouvel
outil avec des techniques que j'ai apprises au cours de mon stage même.
Plusieurs améliorations peuvent être apportées au système étudié. En plus de
compléter l'application, il y a lieu de limiter la partie estimative du tableau de bord. Pour
cela je sollicite de développer une procédure pour saisir des évaluations normalisées au
niveau des commentaires des Devis, Commandes et Bons de Livraison et de développer
une routine pour les récapituler pour les insérer dans le tableau de bord.
51
Nétographie
N[1] https://www.projet-plume.org/ressource/uml
N[2] Roels, C. (2015). openclassrooms. Récupéré sur
http://openclassrooms.com/courses/debutez-l-analyse-logicielle-avec-uml/les-differents-types-
de-diagrammes.
N[3] Lothon, F. (2013, Juin). agiliste. Récupéré sur http://www.agiliste.fr/items/bien-demarrer-
avec-scrum/.
N[4] wikipedia. (2015). Récupéré sur
http://en.wikipedia.org/wiki/Java_(programming_language)
N[5] ubuntu-fr. (2013). Récupéré sur http://doc.ubuntu-fr.org/eclipse.
N[6] hibernate. (2015). Récupéré sur http://hibernate.org/tools/.
N[7] docs.spring.io (2015). Récupéré sur http://docs.spring.io/spring/docs/current/spring-
framework-reference/htmlsingle/
N[8] wikipedia. (2015). Récupéré sur http://fr.wikipedia.org/wiki/PowerAmc.
N[9] wikipédia. (2015) Récupéré sur http://fr.wikipedia.org/wiki/Diagramme_de_déploiement
52
Annexe 1 : Formulaire de pré évaluation des
Fournisseurs et des Sous-traitants
53
54
Annexe 2 : Fiche de suivi de la performance des
Fournisseurs
55
Annexe 3 : Fiche de suivi de la performance des
Sous-traitants

Contenu connexe

Tendances

Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Salma Gouia
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
Ayoub Mkharbach
 
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
 
présentation de soutenance PFE
présentation de soutenance PFEprésentation de soutenance PFE
présentation de soutenance PFE
Karim Labidi
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
Hosni Mansour
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site Web
Harrathi Mohamed
 
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 Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilel
Belwafi Bilel
 
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
 
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
Oussama Djerba
 
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
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
BadrElattaoui
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
fehmi arbi
 
Soutenance de Mon PFE - Interaction Homme Machine par geste avec Python - Jai...
Soutenance de Mon PFE - Interaction Homme Machine par geste avec Python - Jai...Soutenance de Mon PFE - Interaction Homme Machine par geste avec Python - Jai...
Soutenance de Mon PFE - Interaction Homme Machine par geste avec Python - Jai...
Mohammed JAITI
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'études
Majdi SAIBI
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
Nassim Bahri
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
Ben Abdelwahed Slim
 
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
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
Ahmed rebai
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Sofien Benrhouma
 

Tendances (20)

Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_webRapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
Rapport final pfe_systeme_de_gestion _de_cabinet_de_formation_mobile_web
 
Rapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbachRapport pfe-ayoub mkharbach
Rapport pfe-ayoub mkharbach
 
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
 
présentation de soutenance PFE
présentation de soutenance PFEprésentation de soutenance PFE
présentation de soutenance PFE
 
Rapport Projet de Fin d'Etudes
Rapport Projet de Fin d'EtudesRapport Projet de Fin d'Etudes
Rapport Projet de Fin d'Etudes
 
Ma présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site WebMa présentation PFE : Application Android & Site Web
Ma présentation PFE : Application Android & Site Web
 
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 Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilelRapport PFE Application Web Mobiles belwafi bilel
Rapport PFE Application Web Mobiles belwafi bilel
 
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
 
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
 
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...
 
Rapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application AndroidRapport de stage PFE - Mémoire master: Développement d'une application Android
Rapport de stage PFE - Mémoire master: Développement d'une application Android
 
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux Rapport pfe 2017 Système de gestion des rendez-vous médicaux
Rapport pfe 2017 Système de gestion des rendez-vous médicaux
 
Soutenance de Mon PFE - Interaction Homme Machine par geste avec Python - Jai...
Soutenance de Mon PFE - Interaction Homme Machine par geste avec Python - Jai...Soutenance de Mon PFE - Interaction Homme Machine par geste avec Python - Jai...
Soutenance de Mon PFE - Interaction Homme Machine par geste avec Python - Jai...
 
Plateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'étudesPlateforme de gestion des projets de fin d'études
Plateforme de gestion des projets de fin d'études
 
PFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignementPFE :: Application de gestion des dus d'enseignement
PFE :: Application de gestion des dus d'enseignement
 
Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2Rapport Pfe Application Web e-commerce Symfony2
Rapport Pfe Application Web e-commerce Symfony2
 
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 ...
 
Rapport pfe
Rapport pfeRapport pfe
Rapport pfe
 
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
Rapport Projet De Fin D'étude Développent d'une application web avec Symfony2
 

Similaire à Pfe conception et réalisation d'une application de gestion des processus d'achat et de sous traitance

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
 
Thèse - Mettre les utilisateurs et les métiers au coeur de leur système d'inf...
Thèse - Mettre les utilisateurs et les métiers au coeur de leur système d'inf...Thèse - Mettre les utilisateurs et les métiers au coeur de leur système d'inf...
Thèse - Mettre les utilisateurs et les métiers au coeur de leur système d'inf...
Patrick Faure
 
Rapport-PfA-ACHKAOU-SARA.pdf
Rapport-PfA-ACHKAOU-SARA.pdfRapport-PfA-ACHKAOU-SARA.pdf
Rapport-PfA-ACHKAOU-SARA.pdf
saraachkaou
 
Soubki projet
Soubki projetSoubki projet
Soubki projet
s1kor
 
Memoire d'ingénieur:Agrégation de plusieurs connexions réseaux à caractéristi...
Memoire d'ingénieur:Agrégation de plusieurs connexions réseaux à caractéristi...Memoire d'ingénieur:Agrégation de plusieurs connexions réseaux à caractéristi...
Memoire d'ingénieur:Agrégation de plusieurs connexions réseaux à caractéristi...
abdellatrach
 
EXemple 2.pptx
EXemple 2.pptxEXemple 2.pptx
EXemple 2.pptx
chesschess10
 
Mise à niveau d’un système de gestion de clientèle (CRM)
Mise à niveau d’un système de gestion de clientèle (CRM)Mise à niveau d’un système de gestion de clientèle (CRM)
Mise à niveau d’un système de gestion de clientèle (CRM)
Nawres Farhat
 
Dodi_MBUTA_Tests logiciels
Dodi_MBUTA_Tests logicielsDodi_MBUTA_Tests logiciels
Dodi_MBUTA_Tests logiciels
Daniella Mbuta
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
Nazih Heni
 
Conduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Conduite d'un projet informatique - Assurance Qualité et Aspects JuridiquesConduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Conduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Mohamed Sabra
 
Rapport PFE | Eolane | Amélioration de la productivité de l'atelier CMS
Rapport PFE | Eolane | Amélioration de la productivité de l'atelier CMSRapport PFE | Eolane | Amélioration de la productivité de l'atelier CMS
Rapport PFE | Eolane | Amélioration de la productivité de l'atelier CMS
Zouhair Boufakri
 
Rapport PFE2021.pdf
Rapport PFE2021.pdfRapport PFE2021.pdf
Rapport PFE2021.pdf
CoulibalyYoussoufngo
 
Présentation événement dette technologique micropole
Présentation événement dette technologique micropolePrésentation événement dette technologique micropole
Présentation événement dette technologique micropole
Micropole Group
 
PFE :Conception, développement et mise en ligne d’une plateforme Odoo destiné...
PFE :Conception, développement et mise en ligne d’une plateforme Odoo destiné...PFE :Conception, développement et mise en ligne d’une plateforme Odoo destiné...
PFE :Conception, développement et mise en ligne d’une plateforme Odoo destiné...
Nabil EL Moudden
 
Conception, développement et mise en ligne d’une plateforme Odoo destinée à l...
Conception, développement et mise en ligne d’une plateforme Odoo destinée à l...Conception, développement et mise en ligne d’une plateforme Odoo destinée à l...
Conception, développement et mise en ligne d’une plateforme Odoo destinée à l...
Nabil EL Moudden
 
Gp finale
Gp finaleGp finale
Gp finale
Salma Gouia
 
Rapport Projet Gestion des Etudiants avec C++
Rapport Projet Gestion des Etudiants avec C++Rapport Projet Gestion des Etudiants avec C++
Rapport Projet Gestion des Etudiants avec C++
Saâd Zerhouni
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
Erradi Mohamed
 
Catalogue PFE - Chifco 2019
Catalogue PFE - Chifco 2019Catalogue PFE - Chifco 2019
Catalogue PFE - Chifco 2019
Chifco iot
 

Similaire à Pfe conception et réalisation d'une application de gestion des processus d'achat et de sous traitance (20)

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
 
Thèse - Mettre les utilisateurs et les métiers au coeur de leur système d'inf...
Thèse - Mettre les utilisateurs et les métiers au coeur de leur système d'inf...Thèse - Mettre les utilisateurs et les métiers au coeur de leur système d'inf...
Thèse - Mettre les utilisateurs et les métiers au coeur de leur système d'inf...
 
Rapport-PfA-ACHKAOU-SARA.pdf
Rapport-PfA-ACHKAOU-SARA.pdfRapport-PfA-ACHKAOU-SARA.pdf
Rapport-PfA-ACHKAOU-SARA.pdf
 
Soubki projet
Soubki projetSoubki projet
Soubki projet
 
Memoire d'ingénieur:Agrégation de plusieurs connexions réseaux à caractéristi...
Memoire d'ingénieur:Agrégation de plusieurs connexions réseaux à caractéristi...Memoire d'ingénieur:Agrégation de plusieurs connexions réseaux à caractéristi...
Memoire d'ingénieur:Agrégation de plusieurs connexions réseaux à caractéristi...
 
EXemple 2.pptx
EXemple 2.pptxEXemple 2.pptx
EXemple 2.pptx
 
Mise à niveau d’un système de gestion de clientèle (CRM)
Mise à niveau d’un système de gestion de clientèle (CRM)Mise à niveau d’un système de gestion de clientèle (CRM)
Mise à niveau d’un système de gestion de clientèle (CRM)
 
Dodi_MBUTA_Tests logiciels
Dodi_MBUTA_Tests logicielsDodi_MBUTA_Tests logiciels
Dodi_MBUTA_Tests logiciels
 
Rapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédiaRapport de projet de fin d'étude licence informatique et multimédia
Rapport de projet de fin d'étude licence informatique et multimédia
 
Conduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Conduite d'un projet informatique - Assurance Qualité et Aspects JuridiquesConduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
Conduite d'un projet informatique - Assurance Qualité et Aspects Juridiques
 
Rapport PFE | Eolane | Amélioration de la productivité de l'atelier CMS
Rapport PFE | Eolane | Amélioration de la productivité de l'atelier CMSRapport PFE | Eolane | Amélioration de la productivité de l'atelier CMS
Rapport PFE | Eolane | Amélioration de la productivité de l'atelier CMS
 
Rapport PFE2021.pdf
Rapport PFE2021.pdfRapport PFE2021.pdf
Rapport PFE2021.pdf
 
rapport
rapportrapport
rapport
 
Présentation événement dette technologique micropole
Présentation événement dette technologique micropolePrésentation événement dette technologique micropole
Présentation événement dette technologique micropole
 
PFE :Conception, développement et mise en ligne d’une plateforme Odoo destiné...
PFE :Conception, développement et mise en ligne d’une plateforme Odoo destiné...PFE :Conception, développement et mise en ligne d’une plateforme Odoo destiné...
PFE :Conception, développement et mise en ligne d’une plateforme Odoo destiné...
 
Conception, développement et mise en ligne d’une plateforme Odoo destinée à l...
Conception, développement et mise en ligne d’une plateforme Odoo destinée à l...Conception, développement et mise en ligne d’une plateforme Odoo destinée à l...
Conception, développement et mise en ligne d’une plateforme Odoo destinée à l...
 
Gp finale
Gp finaleGp finale
Gp finale
 
Rapport Projet Gestion des Etudiants avec C++
Rapport Projet Gestion des Etudiants avec C++Rapport Projet Gestion des Etudiants avec C++
Rapport Projet Gestion des Etudiants avec C++
 
Cours Génie Logiciel 2016
Cours Génie Logiciel 2016Cours Génie Logiciel 2016
Cours Génie Logiciel 2016
 
Catalogue PFE - Chifco 2019
Catalogue PFE - Chifco 2019Catalogue PFE - Chifco 2019
Catalogue PFE - Chifco 2019
 

Pfe conception et réalisation d'une application de gestion des processus d'achat et de sous traitance

  • 1. Département: STIC Référence: Licence Appliquée en Science et Technologies de l’Information et de la Communication Option SR Conception et Réalisation d’une application de gestion des processus d'achat et de sous-traitance Réalisé par : Ahmed MAKNI Classe : L3SRC Encadrant de l’Iset’COM : Dr Hafedh GAHA Encadrant de l’entreprise : M. Mourad GALLES Responsable : M. Riadh SHIL Entreprise d’Accueil : Tunisair Technics Année Universitaire : 2016-2017
  • 2. Résumé Ce travail s’inscrit dans le cadre du projet de fin d’études pour l’obtention de diplôme de licence en science et technologies de l'information et de la communication. Il vise à réaliser une application web pour l’évaluation des fournisseurs tenant compte les chiffres d'affaires, la condition des livraisons par rapport aux commandes ainsi que les non conformités. Pour ce faire l'application associe des critères quantitatifs pour calculer un taux de respect des engagements moyennant une extraction des données du logiciel de gestion à des critères qualitatifs pour évaluer les aspects affaire et technique des fournisseurs. Mots clés : Evaluation fournisseur, web, JEE, SPRING, HIBERNATE.
  • 3. Abstract This work is part of the final project studies for the license in science and information and communication technologies. It aims at creating a web application for the evaluation of suppliers taking into account turnover, the situation of deliveries in relation with the purchase and the reparation orders and the non-conformities. To achieve this, the application combines quantitative criteria to calculate a rate of compliance with commitments by extracting the data from the management software with a qualitative one to evaluate the business and technical aspects. Keywords: Supplier evaluation, web, JEE, SPRING, HIBERNATE.
  • 4. ‫ص‬ّ‫خ‬‫مل‬ ‫ّة‬‫ي‬‫طبيق‬ّ‫ت‬‫ال‬ ‫اإلجازة‬ ‫شهادة‬ ‫على‬ ‫للحصول‬ ‫ّروس‬‫د‬‫ال‬ ‫ختم‬ ‫مشروع‬ ‫إعداد‬ ‫إطار‬ ‫في‬ ‫العمل‬ ‫هذا‬ ‫يندرج‬ ‫في‬‫المعلومات‬ ‫وتكنولوجيا‬ ‫العلوم‬‫ويهد‬ .‫واالتصاالت‬‫ف‬‫إلى‬‫تطبيق‬ ‫إنشاء‬‫واب‬ّ‫المور‬ ‫لتقييم‬‫دين‬‫أ‬‫خذا‬ ‫في‬‫االعتبار‬‫حجم‬‫وحالة‬ ‫الدوران‬ّ‫ت‬‫ال‬‫سليم‬‫ب‬ ‫مقارنة‬‫أوامر‬‫راء‬ّ‫ش‬‫ال‬‫وعدم‬ ‫واإلصالح‬‫لتحقي‬ .‫المطابقة‬‫ق‬ ّ‫ت‬‫ال‬ ‫يجمع‬ ،‫ذلك‬ّ‫م‬‫ك‬ ‫معايير‬ ‫بين‬ ‫طبيق‬‫لحساب‬ ‫ية‬‫احتراما‬ ‫نسبة‬‫اللتزامات‬‫البيانات‬ ‫استخراج‬ ‫خالل‬ ‫من‬ ‫بر‬ ‫من‬‫ن‬‫ال‬ ‫امج‬‫ف‬ّ‫صر‬ّ‫ت‬‫ّة‬‫ي‬‫نوع‬ ‫ومعايير‬ّ‫ت‬‫ال‬ ‫الجوانب‬ ‫لتقييم‬ّ‫ي‬‫جار‬ّ‫ت‬‫وال‬ ‫ة‬ّ‫ي‬‫قن‬.‫ة‬ ‫الكلمات‬:‫المفاتيح‬‫تقييم‬‫المور‬،‫التجاري‬ ‫اإلصدار‬ ‫جافا‬ ،‫واب‬ ،‫د‬‫منصة‬‫ال‬‫عمل‬‫جافا‬‫سبرين‬‫غ‬،‫بيئة‬ ‫الهايبرنت‬
  • 5. Dédicaces Au symbole de douceur, Amour et affection pour le sens du devoir et aux sacrifices qu’elle a consenti, maman Monia, grâce à qui j’ai pu arriver à réaliser ce projet. J’espère que ce travail sera une récompense suffisante. Que Dieu te garde pour moi. A mon père Fethi, 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. A tous mes amis et camarades proches Vous êtes les meilleurs, merci pour tout votre temps passé à m’encourager et me motiver.
  • 6. Remerciements Avant de présenter mon travail, je voudrais rendre mérite et exprimer ma gratitude à tous ceux qui m’ont aidé à mener à bien mon projet. Mon encadrant académique Dr. Hafedh GAHA, pour ses conseils précieux et qui s'est toujours montré à l'écoute et très disponible tout au long de la réalisation de ce projet de fin d’études. Le Directeur des Approvisionnements Aéronautiques de Tunisair Technics M. Riadh SHIL pour son accueil chaleureux. Mon encadrant d’entreprise M. Mourad GALLES pour ses précieux conseils et la qualité de l'encadrement dont il m’a fait profiter tout au long de ce projet. Mademoiselle Yossra BEN AMOR, analyste IT à VERMEG Tunisie pour tout l’apport dont j'ai pu bénéficier concernant le contexte de développement avec le langage Java. A tous les employés de Tunisair Technics qui ont déployé tous leurs efforts pour me fournir les informations nécessaires. A toutes les personnes qui ont participé, de près ou de loin, à la réalisation de ce projet. A tous mes amis qui m'ont apporté leur soutien moral pendant cette année d'études, je les en remercie sincèrement. Et finalement, aux respectueux membres du jury qui m’ont honoré d’avoir accepté d’évaluer mon travail.
  • 7. Table des matières Introduction Générale _______________________________________________ 1 Chapitre 1. Présentation Générale __________________________________ 2 Introduction__________________________________________________________ 2 1.1. Cadre du stage_________________________________________________ 2 1.1.1. Organisme d’accueil __________________________________________________ 2 1.1.2. Direction d’accueil ___________________________________________________ 4 1.1.3. Cadre du travail______________________________________________________ 5 1.2. Présentation du projet __________________________________________ 5 1.2.1. Problématique _______________________________________________________ 5 1.2.2. Objectifs ____________________________________________________________ 8 1.2.3. Planification du projet ________________________________________________ 8 1.3. Technologies utilisées ___________________________________________ 8 1.3.1. Le formalisme UML __________________________________________________ 8 1.3.2. Le choix du cycle de développement _____________________________________ 9 Conclusion __________________________________________________________ 14 Chapitre 2. Etude préalable _______________________________________ 15 Introduction_________________________________________________________ 15 2.1. Etude de l’existant_____________________________________________ 15 2.1.1. Le logiciel de Gestion AMASIS_______________________________________ 15 2.1.2. Procédure actuelle _________________________________________________ 16 2.1.3. Critique de l’existant _______________________________________________ 17 2.2. Solution proposée _____________________________________________ 18 Conclusion __________________________________________________________ 18 Chapitre 3. Spécification des Besoins _______________________________ 19 Introduction_________________________________________________________ 19 3.1. Identification des besoins _______________________________________ 19 3.2. Spécification des besoins fonctionnels_____________________________ 19
  • 8. 3.3. Spécification des besoins non fonctionnels _________________________ 20 3.4. Planification des sprints ________________________________________ 21 Conclusion __________________________________________________________ 22 Chapitre 4. Conception Détaillée___________________________________ 23 Introduction_________________________________________________________ 23 4.1. Conception architecturale de la solution __________________________ 23 4.2. Architecture détaillée __________________________________________ 24 4.2.1. Diagramme de Classe ______________________________________________ 24 4.2.2. Diagramme de Cas d’utilisation Général _______________________________ 29 4.2.3. Raffinement Cas « Gérer les utilisateurs »______________________________ 30 4.2.4. Raffinement cas « Evaluer Tiers » ____________________________________ 32 4.2.5. Diagramme de Séquence cas « Authentification »________________________ 32 4.2.6. Raffinement cas « Gérer Litiges »_____________________________________ 33 4.2.7. Diagramme de Paquetage ___________________________________________ 34 Conclusion __________________________________________________________ 36 Chapitre 5. Réalisation___________________________________________ 37 Introduction_________________________________________________________ 37 1.1. Environnement de développement _______________________________ 37 1.1.1. Environnement matériel ____________________________________________ 37 1.1.2. Environnement Logiciel ____________________________________________ 38 1.2. Les langages de programmation _________________________________ 42 1.3. Phase d’implémentation ________________________________________ 44 1.3.1. Contraintes_______________________________________________________ 44 1.3.2. Pratiques adoptées_________________________________________________ 44 1.4. Diagramme de déploiement _____________________________________ 45 1.5. Les interfaces_________________________________________________ 46 Conclusion __________________________________________________________ 49 Conclusion générale _______________________________________________ 50 Nétographie ______________________________________________________ 51 Annexe 1 : Formulaire de pré évaluation des Fournisseurs et des Sous-traitants ____________________________________________________________________ 52
  • 9. Annexe 2 : Fiche de suivi de la performance des Fournisseurs _____________ 54 Annexe 3 : Fiche de suivi de la performance des Sous-traitants_____________ 55
  • 10. Table des figures Figure 1: Organigramme actuel de Tunisair Technics...................................................... 3 Figure 2: Organigramme de la direction d'accueil (DAA) ............................................... 4 Figure 3: Diagramme de Gantt : Planning du stage.......................................................... 8 Figure 4: Processus de Scrum......................................................................................... 10 Figure 5: Le logiciel AMASIS........................................................................................ 16 Figure 6: Planification des Releases du Scrum............................................................... 21 Figure 7: Architecture matérielle de l'application........................................................... 24 Figure 8: Diagramme des Classes................................................................................... 28 Figure 9: Diagramme de cas d'utilisation Général.......................................................... 29 Figure 10: Diagramme de cas d'utilisation « Gérer les utilisateurs » ............................. 30 Figure 11: Diagramme de cas d'utilisation « Evaluer Tiers »......................................... 32 Figure 12: Diagramme de Séquence cas « Authentification »........................................ 33 Figure 13: Diagramme de cas « Gérer litiges » .............................................................. 33 Figure 14 : Diagramme de paquetage............................................................................. 35 Figure 15 : Diagramme de Déploiement......................................................................... 45 Figure 16 : Interface « Accueil » .................................................................................... 46 Figure 17 : Interface « Login »....................................................................................... 46 Figure 18 : Interface « Logout »..................................................................................... 47 Figure 19 : Interface « Gestion des Contrats » ............................................................... 47 Figure 20 : Interface « Ajout Contrat »........................................................................... 48 Figure 21 : Interface « Modifier Contrat » ..................................................................... 48
  • 11. Table des tableaux Table 1: Critères de sélection des fournisseurs de la norme ISO 9001 ............................ 7 Table 2: Méthode classique Vs Scrum ........................................................................... 12 Table 3: Description textuelle des Classes ..................................................................... 26 Table 4: Description textuelle du Diagramme de cas d'utilisation Général.................... 30 Table 5: Description textuelle du cas d'utilisation « Ajouter un utilisateur »................. 31 Table 6: Description textuelle du cas d'utilisation « Supprimer un utilisateur »............ 31 Table 7: Description textuelle du cas d'utilisation « Gérer Evènement Estimable »...... 32 Table 8: Description textuelle du cas d'utilisation « Ajouter Litige » ............................ 34 Table 9: Environnement Matériel................................................................................... 37 Table 10: Environnement Logiciel ................................................................................. 38
  • 12. Glossaire Abréviation Signification AMASIS Aircraft Maintenance And Spares Information System AOG Aircraft On Ground (Avion cloué au sol) APRS Approbation pour Remise en Service AS/400 Mini-Ordinateur d’IBM dont le système d’exploitation est l’OS/400 (Operating System 400) DAA Direction des Achats Aéronautiques DGAC Direction Générale de l'Aviation Civile EASA European Aviation Safety Agency (Agence européenne de la sécurité aérienne) GMAO Logiciel de Gestion de la Maintenance Assistée par Ordinateur ISO 9001 Fait partie de la série des normes ISO 9000. Elle définit des exigences concernant l'organisation d'un système de gestion de la qualité. Part 145 Certification de l'EASA qui prescrit les exigences des ateliers d’entretien des aéronefs et éléments d'aéronefs destinés à être remis en service en transport aérien public Scrum Abréviation de scrummage = mêlée (Rugby) : schéma d'organisation de développement de produits complexes UML Unified Modeling Language
  • 13. 1 Introduction Générale Le système de management de la qualité est très important pour une organisation parce qu’il permet de mesurer la performance par rapport aux objectifs fixés, ainsi que l’engagement dans une démarche d’amélioration continue. Son application peut varier selon la structure du domaine appliqué. Dans un service achat, qui est le cas de ce projet, il est difficile de réussir le virage qualité en l'absence d'un système performant d'évaluation des fournisseurs. La qualité des produits et des services étant intimement liée à celle des fournisseurs, il sera difficile de maîtriser la chaîne d'approvisionnement si on ne connaît pas la performance de ces derniers. La qualité n'arrive pas seule et ne s'achète pas. Il faut la bâtir et l'entretenir constamment. Un tel « tableau de bord », particulièrement intéressant pour le Service des Achats, l'est aussi pour la Direction de la Qualité, d'autant plus qu'il constitue la base des programmes de certification et de partenariat avec les fournisseurs. En contrepartie, sa mise en application pose des enjeux de taille aussi bien dans la conception, la collecte et le traitement des données volumineuses et dans la présentation. Encore une fois, les technologies de l'information et des communications ouvrent des perspectives intéressantes en la matière. Dans le présent rapport, nous allons montrer comment peut être si important l'apport de ces technologies pour une compagnie telle que Tunisair Technics vues les exigences particulières en matière de qualité de son domaine d'intervention à savoir la maintenance aéronautique. Il comporte cinq chapitres. Le premier est consacré à une présentation générale du cadre du stage, du projet et des technologies utilisées. Le deuxième chapitre décrit une étude préalable du projet. Le troisième chapitre est dédié à la spécification et l’analyse du nouveau système. Le quatrième chapitre expose la conception détaillée du système, une approche globale et détaillée. Enfin, le dernier chapitre, présente l’étape de réalisation de l’application.
  • 14. Chapitre 1. Présentation Générale Introduction Dans ce chapitre, nous présenterons une vue globale sur l’organisme d’accueil, l’infrastructure, le fonctionnement et le domaine d’activité de Tunisair Technics au sein duquel ce stage a été réalisé. Nous aborderons dans une première section une présentation de la société, dans la deuxième section une présentation du projet et dans la troisième section les technologies choisies pour mener à bien la phase d'analyse. 1.1. Cadre du stage 1.1.1. Organisme d’accueil TUNISAIR : TUNISAIR est la première compagnie aérienne en Tunisie, inaugurée le 21 octobre 1948. Elle avait transporté plus de 90 Millions de passagers en 65 ans d’existence. Possédant une flotte de 28 avions en exploration dont 19 Airbus et 9 Boeing. TUNISAIR organise environ 96 vols par jour vers 116 destinations dans 38 pays. Tunisair Technics : Tunisair Technics est un Organisme d’Entretien filial du groupe TUNISAIR (transporteur aérien).Il réalise les travaux, de maintenance, de révision partielle ou générale, d'inspection, de réparation, de modification sur les aéronefs et éléments d'aéronef selon un tableau qui spécifie leurs types et le degré d'intervention allant du simple test à la révision générale. L’organisme assure ainsi le maintien des avions dans un état de navigabilité et de sécurité permanente conformément à la réglementation aéronautique en vigueur. Le programme d'entretien pour une navigabilité permanente associe les fonctions de Maintenance, de Contrôle, d'Engineering et de l'Approvisionnement. Pour cela Tunisair Technics a établi un Manuel des spécifications d'Organisme d’Entretien (MOE) conformément aux exigences PART 145 qui contient toutes les procédures qui doivent
  • 15. Chapitre 01. Présentation générale 3 être mises en place afin de se conformer aux exigences de la réglementation européenne et d’obtenir l’agrément. TUNISAIR à travers sa filiale Tunisair Technics a obtenu l’agrément PART-145 depuis Janvier 2003 sous le N° EASA .145.0135, qui lui permet aussi d'entretenir et d'intervenir sur les avions européens et de déclarer leur remise en service à l'issue de tout entretien en signant l'APRS. L’organigramme de Tunisair Technics présenté dans la figure suivante montre les différents directions et départements de l’organisme. Figure 1: Organigramme actuel de Tunisair Technics
  • 16. Chapitre 01. Présentation générale 4 1.1.2. Direction d’accueil Ce stage a été effectué au sein de la Direction des Achats Aéronautiques (DAA). Elle comporte quatre départements, gérés chacun par un chef de département qui est en contact permanent avec le directeur responsable de la DAA. Chaque département est subdivisé à des services comportant des entités, est présenté par la figure suivante : Figure 2: Organigramme de la direction d'accueil (DAA) La DAA assure les fonctions suivantes :  Fonction Gestion et Achat de Services :  Gestion des révisables et de la sous-traitance Airbus, Boeing et divers ;  Planification de la matière : Gestion des consommables, gestion des ingrédients et des divers, et gestion des chantiers de maintenance ;  Analyse et optimisation des stocks.  Fonction Achats à l'étranger et locaux :  Prospection et étude de marchés ;  Gestion des commandes Airbus, Boeing et divers : Lancement, suivi et traitement des arrivées et des litiges.  Fonction Contrôle de Gestion : Direction Achats Aéronautiques Département Gestion & Achat de Services Département Achats à l’Etranger Département Achats Locaux Département Contrôle de Gestion Département AOG Desk Secrétariat de Direction
  • 17. Chapitre 01. Présentation générale 5  Gestion du budget et analyse des coûts ;  Gestion des contrats d'achat et de sous-traitance ;  Paiement des achats et des services à l'étranger et locaux.  Fonction AOG Desk :  Résoudre les problèmes de pièces de rechange critiques conjointement avec le personnel de contrôle de la maintenance. 1.1.3. Cadre du travail Ce projet à Tunisair Technics, rentre dans le cadre d’un projet de fin d’études au cours de notre formation de technicien supérieur en Science et technologies de l’information et de la communication au sein de l’ISET’Com. Il a pour but de mettre en place une application de gestion de processus dans le cadre de l’achat et de la sous- traitance. 1.2. Présentation du projet 1.2.1. Problématique Origine : Afin de répondre à des exigences réglementaires DGAC et Part 145, Tunisair Technics est appelée à mettre en place d'un système informatisé de gestion des processus d'achat et de sous-traitance dont principalement le système d'évaluation des fournisseurs. Ceci requiert de la DAA une gestion et un contrôle rigoureux et proactifs, qui une fois mis en place permettront en plus, de répondre à des exigences des normes de qualité, de maîtriser le processus d'achat et de sous-traitance, d'améliorer ses relations avec les fournisseurs en vue d'éventuels partenariats victorieux, de satisfaire au mieux aux exigences de ses clients à l’échelle mondiale, et même d’augmenter les gains de productivité.
  • 18. Chapitre 01. Présentation générale 6 Motivation : Face à des marchés fortement compétitifs, caractérisés par une demande de produits personnalisés, de bonne qualité, livrés dans des délais minimaux et le tout au moindre coût, une gestion efficace des achats locaux et/ou internationaux peut constituer un avantage concurrentiel substantiel. En effet, la part du poids des achats se situe fréquemment entre 40% et 80% du coût total du produit. La sélection des fournisseurs devient ainsi une décision stratégique qui a un impact crucial sur la performance globale de toute entreprise. Aspects de la sélection : Le problème de la sélection des fournisseurs doit être étudié sous deux aspects :  La détermination des fournisseurs qui vont rentrer en compétition. Dans notre cas tous les fournisseurs agréés ; donc disposant d’une certification. L’ANNEXE 1 détaille le formulaire de pré évaluation des fournisseurs et des sous-traitants établi par la Direction de la Qualité.  La sélection des meilleurs fournisseurs parmi les alternatives existantes. C'est cet aspect du problème du choix des fournisseurs qu'on considèrera dans notre travail. Critères de sélection : Les critères de sélections des fournisseurs et sous-traitant utilisés dans la norme ISO 9001 sont les suivants. Rang Critère 1 Prix 2 Livraison 3 Qualité 4 Capacité de production 5 Localisation géographique 6 Capacité technique 7 Gestion et organisation 8 Réputation et position dans l'industrie 9 Situation financière 9 Performance Passée
  • 19. Chapitre 01. Présentation générale 7 9 Services de réparation 10 Attitude 11 Habileté d'emballage 11 Contrôle des opérations 12 Formation et support 12 Conformité des processus 12 Relations sociales 12 Système de communication 12 Réciprocité de la relation 12 Impression 13 Désir de faire des affaires 13 Volume des achats dans le passé 14 Politique de garantie Table 1: Critères de sélection des fournisseurs de la norme ISO 9001 On distingue deux types de critères : les critères quantitatifs et ceux qualitatifs. Ils ont fait l'objet d'une procédure diffusée par la Direction de la Qualité. Les critères de sélection des fournisseurs se trouvent en Annexe 2. Les critères de sélection des sous- traitants se trouvent en Annexe 3. Méthode d'évaluation : Plusieurs méthodes d'évaluation sont utilisables. La Direction de la Qualité a spécifié la méthode linéaire avec des pondérations spécifiques. Mission : Pour récapituler, la mission de ce sujet est de gérer des fournisseurs et des sous- traitants en marge de leurs échanges commerciaux avec l’entreprise. Ceux qui disposent de certificats de vente ou de réparation aéronautiques vont entrer en compétition. Toute leur activité commerciale sera suivie depuis l’attribution des devis, passant par la livraison et la facturation et terminant par la garantie. Un certain nombre de critères d’évaluation devra être enregistré et évalué à chaque échange : respect des délais, des prix, la qualité des services, les litiges, la garantie, … etc. Aux meilleurs de ces fournisseurs et sous-traitants seront attribués des contrats.
  • 20. Chapitre 01. Présentation générale 8 1.2.2. Objectifs L'objectif de ce travail vise à créer et maintenir un réseau de fournisseurs fiables et efficaces nécessaires à l'entreprise pour relever les défis concurrentiels croissants. La capacité de cette dernière à produire un produit de qualité, à un coût raisonnable et de manière opportune est fortement influencée par la performance des fournisseurs qui est considérée comme l'un des facteurs déterminants pour le succès. 1.2.3. Planification du projet A fin de mieux exploiter le temps alloué à la réalisation du projet de fin d’étude, une bonne gestion de ce temps est nécessaire. La figure suivante vous montre les différentes tâches et sous tâches qu’on exécutera pendant la période du stage. Figure 3: Diagramme de Gantt : Planning du stage 1.3. Technologies utilisées Le choix d’une méthodologie de développement devient une décision primordiale puisqu’elle permet de guider un utilisateur tout au long du processus de développement et de fournir un moyen de vérifier, valider et tester les fonctionnalités de l’application. 1.3.1. Le formalisme UML Le recours à la modélisation est depuis longtemps une pratique indispensable au développement, car un modèle est prévu pour arriver à anticiper les résultats du codage.
  • 21. Chapitre 01. Présentation générale 9 Un modèle est en effet une représentation abstraite d’un système destiné à en faciliter l’étude et à le documenter. C’est un outil majeur de communication entre les différents intervenants au sein d’un projet. Aujourd’hui, langage de modélisation UML est le standard industriel de la modélisation objet N[1]. UML se définit comme un langage de modélisation graphique et textuel destiné à comprendre et décrire des besoins, spécifier et documenter des systèmes, esquisser des architectures logicielles, concevoir des solutions et communiquer des points de vue. Nous avons choisi UML pour ces deux points essentiels : UML n’impose pas de méthode de travail particulière, il peut être intégré à n’importe quel processus de développement logiciel de manière transparente N[2]. En plus UML est une sorte de boîte à outils, qui permet d’améliorer progressivement les méthodes de travail, tout en préservant les modes de fonctionnement. Intégrer UML par étapes dans un processus, de manière pragmatique, est tout à fait possible. La faculté d’UML de se fondre dans le processus courant, tout en véhiculant une démarche méthodologique, facilite son intégration et limite de nombreux risques. 1.3.2. Le choix du cycle de développement La méthodologie est une démarche à suivre pour obtenir un résultat quasi-certain. Parmi ces différentes méthodologies, on peut citer le modèle en cascade (waterfall) utilisée souvent pour des projets dont les besoins sont spécifiés dès le début et les méthodologies agiles (Scrum) qui peuvent être utilisé avec divers types de projets. Pour ce projet nous avons opté pour la méthode de gestion de projet Scrum N[3]. Le principe de base de Scrum:  Consiste à dégager en un premier temps le maximum de fonctionnalités à réaliser pour former le backlog du produit ;  En second temps, le Scrum master, Product owner et l’équipe font une réunion « la sprint planning » pour dégager les sprints backlog ;
  • 22. Chapitre 01. Présentation générale 10  Ensuite, nous décomposons les sprints backlog en sprint (itération) et durant chaque sprint on fait une réunion « le Scrum master et l’équipe » pour inspecter l’avancement du sprint.  Ainsi et à la fin de chaque sprint on a un produit partiellement fonctionnel appelé incrément, donc on fait deux réunions la « sprint review » et la « rétrospective » ;  Et ainsi de suite jusqu’à ce que tous les sprints soient achevés. Figure 4: Processus de Scrum Le choix de la méthode Scrum pour le pilotage de notre projet est basé sur les avantages que ce dernier apporte, vu que cette méthode offre plus de souplesse, plus de réactivité et une meilleure adaptation au changement due à des itérations courtes.  Pourquoi la méthodologie Scrum : Dans cette section nous allons comparer la méthode classique avec la méthode Scrum à l’aide du tableau suivant :
  • 23. Chapitre 01. Présentation générale 11 Thème Approche Traditionnelle Approche Agile Cycle de vie En cascade ou en V, sans rétroaction possible, phases séquentielles. Itérative et Incrémentale Planification Prédictive, caractérisé par des plans plus ou moins détaillés sur la base d’un périmètre et d’exigences définies et stable au début du projet Adaptative avec plusieurs niveaux de planification avec ajustements si nécessaires au fil de l’eau en fonction des changements survenus Documentation Produire en quantité importante comme support de communication, de validation Réduite au strict nécessaire au profit d’incréments fonctionnels pour obtenir le feedback du client Equipe Une équipe avec des ressources spécialisées, dirigées par un chef de projet Une équipe responsabilisée ou l’initiative et la communication sont privilégiées, soutenue par le chef de projet Qualité Contrôle qualité à la fin du cycle de développement. Le client découvre le produit fini Un contrôle qualité précoce et permanent, au niveau du produit et du processus. Le client visualise les résultats tôt et fréquemment Changement Résistance vire opposition au changement. Processus lourds de gestions des changements acceptés Accueil favorable au changement inéluctable intégré dans le processus Suivi de l’avancement Mesure de la conformité aux plans initiaux Un seul indicateur d’avancement : le nombre de fonctionnalités implémentées et le travail restant à faire
  • 24. Chapitre 01. Présentation générale 12 Thème Approche Traditionnelle Approche Agile Gestion des risques Processus district, rigoureux de gestion des risques Gestion de risque intégrée dans le processus global, avec la responsabilité de chacun dans l’identification et la résolution des risques. Mesure du succès Respect des engagements initiaux en termes de cout et niveau de qualité Satisfaction client par la livraison de valeur ajoutée Table 2: Méthode classique Vs Scrum  Pilotage du projet avec la méthodologie Scrum Scrum se base sur quatre concepts qui sont l’équipe avec les rôles bien définis, les blocs de temps et les artefacts et les réunions. Pour piloter un projet, les membres de l’équipe Scrum font recours à plusieurs techniques. La technique la plus populaire et la plus répandue, consiste à créer des Post- It note et de les faire coller sur un tableau. L’autre technique consiste à créer des fichiers sur Excel contenant les informations sur les sprints et les user story, Ce fichier est partagé entre les membres de l’équipe avec la possibilité de le consulter et de le modifier. Pour cette raison, plusieurs outils sont apparus offrant des services qui facilitent le suivi de la priorité, la traçabilité et la gestion du travail. Parmi les outils existant nous avons choisi d’utiliser Ice Scrum. o L’équipe et les rôles Il existe 3 rôles qu’on décrira brièvement :  Directeur de produit ou (Product owner en anglais) : Représente le client ou le client lui-même et il est généralement expert dans le domaine. Et contrairement à ce que son nom l’indique, ses responsabilités sont limitées à l'établissement des limites des projets et de chaque itération.
  • 25. Chapitre 01. Présentation générale 13  Scrum master : gérant de l’application, assigner souvent comme le manager du projet, veille à ce que chacun travaille en maximum de sa capacité et essaye d’éliminer les obstacles.  Equipe de Scrum (Scrum Team): formé par des personnes chargées d’implémenter les besoins du client. Cette équipe est formée d’infographiste, développeurs, testeurs et concepteurs. o Les réunions Scrum est dirigé par quatre types de réunion :  Sprint planning (planification du sprint): pour planifier les itérations ou sprints (soit pour présenter la liste du product owner ou pour décomposer le projet en tâches) et discuter des user stories;  Mêlée quotidienne ou Scrum quotidien (Daily Scrum) : cette réunion qui se fait debout, quotidiennement et à une durée de 15 minutes. Le Scrum master inspecte l’état de l’avancement du sprint et identifie les problèmes. Au cours de ce meeting ils doivent répondre à trois questions (Qu’est-ce que j’ai fait hier? Qu’est-ce que je fais aujourd’hui? Quels sont les problèmes?);  Sprint review (Revue du sprint): bilan de l’itération et pour faire une présentation au client afin d’avoir son feedback. L’objectif ici est de valider le logiciel qui a été produit pendant ce sprint;  Retrospective : Cette étape se fait à la fin de chaque sprint, on inspecte le processus du travail et essaye de déduire ce qui a fonctionné ou pas. Cette réunion dure de 15 à 30 minutes. On applique un principe « Start/Stop/Continue »: ce qu’on aimerait " faire, arrêter de faire et continuer à faire ".
  • 26. Chapitre 01. Présentation générale 14 o Les artéfacts  Burn down chart : C’est un tableau d’analyse qui permet d’inspecter la progression du sprint.  Le Backlog de sprint (sprint Backlog):Le backlog de sprint est une liste de tâches identifiées par l'équipe de Scrum et qui doit être achevée au cours du sprint. Lors de la réunion de planification du sprint, l'équipe sélectionne un certain nombre d'éléments produits du carnet de commandes, généralement sous forme d'histoires utilisateurs, et identifie les tâches nécessaires pour compléter chaque user story. La plupart des équipes estiment également le nombre d'heures. Chaque tâche aura quelqu'un de l'équipe pour l’achever.  Le backlog du produit (product backlog) :C’est un artéfact important du Scrum représenté sous forme de tableau contenant les caractéristiques fonctionnelles ou techniques qui constituent le produit souhaité. Les caractéristiques fonctionnelles (user story) et les caractéristiques techniques (technical story). Conclusion Dans ce chapitre nous avons présenté le contexte général du projet, ensuite nous avons exposé la problématique et les objectifs de notre travail et terminé avec le chronogramme de son acheminement. La définition des connaissances et les technologies nécessaires à notre projet permettent de passer à la phase suivante qui consiste à la spécification et l’analyse du nouveau système. Cette spécification détaillée permettra de mieux comprendre la conception de notre projet et qui fera l’objet du chapitre suivant.
  • 27. Chapitre 2. Etude préalable Introduction L'Etude de l’existant est une étape importante pour la mise en route d’un projet informatique ou autre type de projet qui permet de définir le processus métier et de dégager les imperfections du système existant afin de l’améliorer ou le corriger. 2.1. Etude de l’existant 2.1.1. Le logiciel de Gestion AMASIS AMASIS (Aircraft Maintenance And Spares Information System) est le progiciel de gestion technique intégré (GMAO) utilisé par les services de Tunisair Technics dans la gestion de sa maintenance aéronautique. Il est commercialisé depuis 25 ans par la société IFRSKEYES ; une filiale d’Airbus créée en 1987. Il est installé sur un mini-ordinateur d’IBM : l’AS/400 appelé encore system i5. Il est développé en Java/400 et utilise la base de données de l’AS/400 qu’est la db2. Il présente une architecture modulaire composée de 14 modules distincts et complémentaires :  La Gestion de la chaine logistique : Permet de gérer et suivre les expressions de besoins, les niveaux des stocks, les flux de matière et d’assurer les approvisionnements et la facturation relative aux achats, réparations, locations ou échanges standards réalisés. Il comporte aussi un module de gestion des contrats.  La Gestion Financière ;  Le suivi de navigabilité ;  La maintenance corrective ;  La maintenance planifiée ;  La Gestion de la production ;  La Gestion de la Main d’œuvre ;
  • 28. Chapitre 02. Etude préalable 16  La Gestion des documents de Référence. Etude préalable Figure 5: Le logiciel AMASIS 2.1.2. Procédure actuelle La majorité écrasante des processus d’achat et de sous-traitance sont dominés par un traitement manuel. Ci-après la situation actuelle des différents processus :  Evaluation des fournisseurs : le logiciel d’AMASIS ne comportant pas un tel outil et en l’absence d’un outil approprié c’est du manuel pratiquement, si ce n’est l’utilisation de quelques états récapitulatifs édités à partir d’AMASIS pour dresser le tableau d’évaluation. Aucune gestion informatisée n’existe pour gérer les accusés de réception et les notifications d’envois des fournisseurs qui ne sont pas pris en considération jusque-là. Les dates de ces éléments étant calculées grossièrement à partir de la date d’une pièce : Ajout de 3 jours pour un tiers local et 7 jours pour un tiers étranger.  Gestion des licences : Un outil performant assurant cette fonction, est contenu dans AMASIS mais n’est pas exploité. La gestion des licences se fait aussi manuellement ;
  • 29. Chapitre 02. Etude préalable 17  Gestion des Contrats : Un outil novice assurant cette fonction est contenu dans AMASIS et ne satisfait pas aux besoins car il n’intègre aucun prix ni remise dans les lignes de contrats. La gestion des contrats se fait donc aussi manuellement.  Gestion des Commandes d’Achat : Un outil performant assurant cette fonction, est contenu dans AMASIS et utilisé. La gestion des Commandes d’Achat est donc informatisée.  Gestion des Commandes de Réparation : Un outil performant assurant cette fonction, est contenu dans AMASIS mais n’est pas utilisé en sa totalité. En faite la gestion des devis n’y est pas utilisée quoi que très performante, pour cause qu’il ne s’adapte pas à une règle de gestion de la procédure actuelle à savoir le logiciel AMASIS n’accepte pas d’avoir la date de la Commande de Réparation antérieure à la date du Devis. La gestion des Commandes de Réparation se fait donc aussi manuellement dans une partie importante qu’est la gestion des devis.  Gestion des Price Catalogs : Ces informations sont importantes pour l’évaluation car elles donnent des prix d’achat références. Leur gestion est aussi manuelle.  Gestion des Capability Lists : Ces informations sont importantes pour l’évaluation car elles donnent des prix de réparation références, pour les différents types d’intervention. Leur gestion est aussi manuelle.  Gestion des Litiges : AMASIS ne supporte pas cette fonction que très peu. En effet une simple zone de texte libre est prévue dans les Bons de Livraison servant à cet effet. Quoi qu’utilisée par le service, elle reste insuffisante pour détailler le litige. En effet il faudrait qu’il y ait au moins une date de constat de l’anomalie, et une codification détaillée des causes de litiges. 2.1.3. Critique de l’existant La majorité écrasante des processus d’achat et de sous-traitance sont dominés par un traitement manuel. Tout le processus d’évaluation des fournisseurs se fait manuellement via des documents non maitrisés nécessitant l’intervention d’un effectif important engendrant une perte de temps énorme. Le travail manuel et non maitrisé qui caractérise cette tâche stratégique pour la compagnie, altère considérablement son fonctionnement engendrant des retards énormes
  • 30. Chapitre 02. Etude préalable 18 pour l’exécution de ses taches dont les délais fixés par la norme sont dépassés largement. En plus, il n’a pas la main mise sur le Système de Gestion (AMASIS) ce qui représente un écart majeur dans la réglementation qualité en vigueur. 2.2. Solution proposée Tenant compte des critiques citées ci-dessus et des besoins d'informatiser la fonction d’évaluation des fournisseurs pour la DAA, la solution est de :  Remédier au problème majeur de gestion manuelle des devis des Commandes de Réparation et faire le nécessaire pour utiliser le module Gestion des devis d’AMASIS.  Assister les utilisateurs de la DAA à démarrer l’exploitation du module Gestion des licences d’AMASIS. Ces deux points ont été traités avec mon encadrant d’entreprise, et ne figureront pas dans la suite de ce rapport  Concevoir et développer une application permettant d’assurer les deux parties constituantes du processus de l’évaluation des fournisseurs :  Fonction de Gestion :  Gérer les Contrats ;  Gérer les Price Catalogs ;  Gérer les Capability Lists ;  Gérer les Litiges.  Fonction Qualité :  Récapituler activité Tiers ;  Evaluer Tiers. Conclusion A la fin de ce chapitre nous avons détaillé, analysé et critiqué la procédure existante ce qui nous permet d’avoir une idée claire sur les spécifications de notre future application qui seront détaillées dans le chapitre suivant.
  • 31. Chapitre 3. Spécification des Besoins Introduction Pour réussir un projet, il est obligatoire de mener à bien l’analyse et la spécification des besoins. Etant la première étape primordiale du cycle de vie d’un logiciel, il est fondamental de bien déterminer les exigences exprimées par l’utilisateur. Afin de comprendre le contexte de l’application nous allons, au cours de cette étape, déterminer les besoins fonctionnels, les besoins non fonctionnels ainsi que les acteurs qui interagiront avec notre application. 3.1. Identification des besoins Identification des acteurs Les différents acteurs qui se présentent pour notre système se répartissent en trois catégories principales à savoir :  Administrateur : Il a pour rôle de gérer les comptes des utilisateurs, de gérer les auditeurs, les audités, gérer les référentiels, les formations réglementaires et les secteurs d’activité.  Utilisateur de Gestion : Il a un rôle de gestion des litiges, des Contrat, prix.  Gestion de Qualité : Il a un rôle de qualité qui lui permet d’évaluer Tiers 3.2. Spécification des besoins fonctionnels Ce sont les fonctionnalités du système et les actions qu’un acteur peut effectuer afin de répondre à la demande de l’utilisateur. Nous allons dans cette partie identifier les besoins fonctionnels par acteurs, c’est-à- dire l’action que peut effectuer chaque intervenants sur le système et ceci dans le but de préciser le rôle de chaque acteur au sein du futur logiciel.  Besoins fonctionnels pour l’administrateur:  Gérer les Utilisateurs.  Gérer les Logs.
  • 32. Chapitre 03. Spécification des Besoins l’outil 20  Gérer les Paramètres.  Besoins fonctionnels de l’Utilisateur de gestion:  Gérer les Contrats.  Gérer les Price Catalogs.  Gérer les Capability Lists.  Gérer les Litiges.  Besoins fonctionnel de l’Utilisateur de qualité:  Récapituler activité Tiers ;  Evaluer Tiers.  Besoins fonctionnel pour tous les utilisateurs :  S’authentifier pour accéder à l’application : l’utilisateur doit être authentifié pour accéder à l’interface le concernant selon son rôle dans le système. 3.3. Spécification des besoins non fonctionnels Un besoin non fonctionnel aussi appelé besoin d’affaire, Ce sont les contraintes et restrictions liés à l’environnement lors de l’implémentation de l’application. Les besoins non fonctionnels sont :  La disponibilité : Le système constitue le cœur de l’activité, il est obligatoire qu’il soit toujours en service.  La sécurité : C’est primordial pour l’application, étant donné qu’elle gère des données confidentielles. Une authentification et un cryptage des données sensibles est indispensable.  La performance : Le fait que l’application est multiutilisateur et contient un nombre de données important, le temps de traitement doit être réduit impérativement.  L’ergonomie : L’utilisation d’une interface utilisateur simple et facile à comprendre, pour qu’elle ne soit pas ambiguë à tous utilisateurs ignorant l’informatique.  L’interopérabilité : On n’a pas besoin d’installer quoi ce soit pour pouvoir utiliser cette application, juste un navigateur web, en plus elle est multiplateforme.  La clarté des documents : Les documents et les rapports que le système imprimera seront lisibles.
  • 33. Chapitre 03. Spécification des Besoins l’outil 21 3.4. Planification des sprints La réunion de planification des sprints (sprint planning) 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. 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 deux releases: Le premier sera gestion des ressources et des établissements et le deuxième sera la gestion des processus. Pour notre cas la durée de 10 jours pour un sprint semble adéquate. La suivante résume notre planning de travail Figure 6: Planification des Releases du Scrum Plan de Release Sprint#1 Sprint#2 Sprint#3 Sprint#4 Gérer Personnel Gérer Direction Gérer Référentiels Gérer Secteur Gérer Personnel Gérer Processus de Gestion Gérer Notification Gérer Validation Gérer Tiers Gérer CR Gérer CA Authentification Gérer Litiges
  • 34. Chapitre 03. Spécification des Besoins l’outil 22 Conclusion Après avoir distingué les rôles de chaque utilisateur, spécifié les besoins fonctionnels et non fonctionnels et planifié nos sprints, il est temps de commencer à concevoir et à développer notre application. Dans le chapitre suivant, nous allons nous initier avec la conception et le développement du premier release.
  • 35. Chapitre 4. Conception Détaillée Introduction Une fois qu’on a déterminé le backlog du produit, nous le découpons en petites parties qui s’appellent « release ». La release est constitué d’itération ou sprint. La durée de la release est déterminée par le « product owner » en collaboration avec l’équipe. Au niveau de ce chapitre, nous allons traiter les histoires utilisateurs de nos sprints afin de produire les releases pour produire logiciel potentiellement livrable. 4.1. Conception architecturale de la solution Architecture matérielle Notre application est une application web qui se connecte à un serveur de base de données distant, via Internet, afin de récupérer les données. Ceci nécessite aussi l’intégration d’un serveur web entre l’application client et le serveur de base de données. D’où l’architecture de notre application à 3 niveaux (architecture 3-tiers), partagée entre les trois éléments suivants :  L’utilisateur (Administrateur, Utilisateur de Gestion, Gestion de Qualité) ;  Le serveur Web : Vu que les données seront communiquées entre deux environnements hétérogènes, le rôle principal du serveur web est de gérer la communication entre l’utilisateur et le serveur de base de données ;  , Le serveur de base de données fournit les données au serveur web.
  • 36. Chapitre 04. Conception Détaillée 24 Figure 7: Architecture matérielle de l'application 4.2. Architecture détaillée Maintenant, nous détaillerons la conception de notre solution en présentant aussi bien les diagrammes des classes, le diagramme association, les diagrammes de package, ainsi que quelques diagrammes d’activités de notre système. 4.2.1. Diagramme de Classe Notre base des données est une base regroupant plusieurs informations cohérentes qui seront d’une utilité majeure. Afin de détailler l’architecture de cette base, Nous avons développé le modèle Entité-Association. A partir de la figure 8, nous présentons le diagramme de classes du paquet modèle qui comporte les différents objets permettant le déroulement des scénarios de notre application. Ces classes représentent les différentes tables de notre base mappées grâce au « Framework Hibernate ». Le diagramme suivant illustre les différentes classes créées pour notre système : Entité Description Applicabilité Elle représente l’applicabilité des pièces BonDeReception Elle représente l’entête du Bon de Réception Catalogue Elle représente la liste des prix d’achat des pièces Certificat Elle représente les données Relatives à un certificat
  • 37. Chapitre 04. Conception Détaillée 25 Entité Description Commande Elle représente l’entête d'une Commande Constructeur Elle représente un type de Tiers ContactTiers Elle représente les données relatives à la personne de contact de tiers Contrat Elle représente l’entête du Contrat CotationFournisseur Elle représente l’entête de la Cotation Fournisseur DemandeDeCotation Elle représente l’entête de la Demande de Cotation Devise Elle représente la devise utilisée Evaluation Elle représente l’évaluation du Tiers Facture Elle représente l’entête de Facture Fournisseur Elle représente le type de Tiers Indicateur Elle représente les champs d’évaluation LigneDeFacture Elle représente les Factures passées par un Tiers Litige Elle représente les types de litiges Magasin Elle représente le magasin émetteur de la commande ModeDePaiement Elle représente le Mode de Paiement ModeDeReglement Elle représente le Mode de Règlement MotifLitige Elle représente l’explication de litige OrganismeDeCertificat ion Elle représente l’organisme de Certification PartNumber Elle Représente les pièces d’un avion PersonneContact Elle représente la personne de Contact Piece Elle représente le numéro de la série de la pièce PosteDeCommande Elle représente les commandes passées par la société. PosteDeContrat Elle représente les Ligne de Contrat PosteDeDemandeDeCo tation Elle représente les Cotations passées par la société. PostesCotationFournis seur Elle représente les Cotations passées par les Fournisseurs PostesDeReception Elle représente les Postes de Réceptions
  • 38. Chapitre 04. Conception Détaillée 26 Entité Description ReceptionRejetee Elle représente la Réception Annulée RepresentantTiers Elle représente le Représentant du Tiers Société Elle représente la Société (Tunisair, Tunisair Express, ….) SousTraitant Elle représente le tiers Réparateur Tiers Elle représente le tiers Travail Elle représente le Type de Travail (Test, Repair, Overhaul) TypeContrat Elle représente le Type de contrat (contrat d’achat, contrat de réparation) TypeDePaiement Elle représente le type de paiement Table 3: Description textuelle des Classes
  • 39. Chapitre 04. Conception Détaillée 27
  • 40. Chapitre 04. Conception Détaillée 28 Figure 8: Diagramme des Classes
  • 41. Chapitre 04. Conception Détaillée 29 4.2.2. Diagramme de Cas d’utilisation Général Un cas d'utilisation (en anglais use case) permet de mettre en évidence les relations fonctionnelles entre les acteurs et le système étudié. Le format de représentation d'un cas d'utilisation est complètement libre, mais UML propose un formalisme et des concepts issus de bonnes pratiques. Figure 9: Diagramme de cas d'utilisation Général Acteur Cas d’utilisation Administrateur  Gérer les Utilisateurs.  Gérer les Logs.  Gérer les Paramètres.
  • 42. Chapitre 04. Conception Détaillée 30 Utilisateur Qualité  Gérer les Litiges.  Gérer les Contrats.  Gérer les Capability Lists  Gérer les Price Catalogs Utilisateur Gestion  Evaluer Cotation  Consulter Tiers  Evaluer Tiers Table 4: Description textuelle du Diagramme de cas d'utilisation Général 4.2.3. Raffinement Cas « Gérer les utilisateurs » Figure 10: Diagramme de cas d'utilisation « Gérer les utilisateurs » Titre Ajouter un Utilisateur Acteur initiateur Administrateur But du cas Ajouter un nouvel utilisateur de l'application Pré-condition Application, BD, Serveur d’application Post-condition en cas de succès L'utilisateur peut accéder à l'application.
  • 43. Chapitre 04. Conception Détaillée 31 Titre Ajouter un Utilisateur Description du scénario 1. Ce cas commence quand l'administrateur demande l’ajout d’un nouvel utilisateur. 2. le système affiche un formulaire d'ajout. 3. Après le remplissage du formulaire, l'administrateur valide les coordonnées. 4. Le système vérifie si tous les champs sont remplis. 5. Si les champs sont vides. Alors Exception(E1) 6. Sinon le système vérifie si l’utilisateur existe déjà. Alors Exception (E2). 7. Si l’utilisateur n’existe pas alors il va être enregistré et le système affiche un message de succès Exception (E1): s’il y'a un champ non rempli ou il y'a une erreur à la connexion à la base de données. Le système affiche un message d'erreur (E2): si l’utilisateur existe, Le système affiche un message d’erreur. Table 5: Description textuelle du cas d'utilisation « Ajouter un utilisateur » Titre Supprimer un Utilisateur Acteur initiateur Administrateur But du cas Supprimer un utilisateur de l'application Pré-condition Application, BD, Serveur d’application Post-condition en cas de succès L'utilisateur ne peut pas encore accéder à l'application. Description du scénario 1. Ce cas commence quand l'administrateur demande la suppression d’un utilisateur. 2. Le système affiche une interface de suppression avec la liste des utilisateurs déjà enregistrés. 3. L'administrateur choisit l’utilisateur voulu et demande sa suppression. 4. Le système effectue la suppression et affiche un message de succès de suppression. Table 6: Description textuelle du cas d'utilisation « Supprimer un utilisateur »
  • 44. Chapitre 04. Conception Détaillée 32 4.2.4. Raffinement cas « Evaluer Tiers » Figure 11: Diagramme de cas d'utilisation « Evaluer Tiers » Titre Gérer Evènement Estimable Acteur initiateur Utilisateur Qualité But du cas Evaluer un Tiers Pré-condition Application, BD, Serveur d’application Post-condition en cas de succès L’évènement ajouté pour faciliter l’évaluation . Description du scénario 1. Ce cas commence quand l'utilisateur demande d’évaluer un tiers. 2. le système affiche un formulaire d’indication des Evaluations. 3. Après le remplissage du formulaire, l’utilisateur valide les coordonnées. 4. Le système vérifie si tous les champs sont remplis. 5. l’utilisateur demande d’imprimer l’évaluation Table 7: Description textuelle du cas d'utilisation « Gérer Evènement Estimable » 4.2.5. Diagramme de Séquence cas « Authentification » Les diagrammes de séquences peuvent servir à illustrer chaque cas d’utilisation et forment une représentation temporelle des objets et de leurs interactions. Nous débutons par le diagramme d’authentification.
  • 45. Chapitre 04. Conception Détaillée 33 A ce stade, nous commençons par l’élaboration des diagrammes de séquence systèmes à partir des cas d’utilisation détaillés précédemment. En se référant aux descriptions textuelles élaborées dans la section précédente, nous présenterons les diagrammes de séquences système adéquats. Nous constatons que certain de ces cas sont similaires, nous avons choisi donc de faire certains cas d’utilisation. Figure 12: Diagramme de Séquence cas « Authentification » 4.2.6. Raffinement cas « Gérer Litiges » Figure 13: Diagramme de cas « Gérer litiges »
  • 46. Chapitre 04. Conception Détaillée 34 Titre Ajouter Litige Acteur initiateur Utilisateur Qualité But du cas Ajouter un nouvel Litige Pré-condition Application, BD, Serveur d’application Post-condition en cas de succès L'utilisateur ajout un type de litige. Description du scénario 1. Ce cas commence quand l’utilisateur demande l’ajout d’un nouveau litige. 2. Le système affiche un formulaire d'ajout. 3. Après le remplissage du formulaire l'utilisateur valide les coordonnées. 4. Le système vérifie si tous les champs sont remplis. 5. Si les champs sont vides. Alors Exception (E1) 6. Sinon le système vérifie si le litige existe déjà. Alors Exception (E2). 7. Si le litige n’existe pas alors il va être enregistré et le système affiche un message de succès Exception (E1): s’il y'a un champ non rempli ou il y'a une erreur à la connexion à la base de données. Le système affiche un message d'erreur (E2): si litige existe, Le système affiche un message d’erreur. Table 8: Description textuelle du cas d'utilisation « Ajouter Litige » 4.2.7. Diagramme de Paquetage Afin de garantir l’extensibilité de l’application et de minimiser le temps de développement, nous avons découpé les différentes classes en modules N[4]. En effet, cette décomposition nous permet de mieux structurer notre système et faciliter la compréhension de ses fonctionnalités. L’organisation de l’ensemble des modules constitue l’architecture logicielle de notre système. En effet on peut, avant présenter le diagramme de paquetage, distribuer les différents paquets de notre diagramme (la figure 8) sur les différentes couches du modèle MVC comme suit :  Le modèle : A ce niveau, nous trouvons le paquetage model qui contient les objets de persistance. Ces objets sont des classes utilisées par tous les paquetages de
  • 47. Chapitre 04. Conception Détaillée 35 l’application. Elles représentent les tables de notre base des données. La principale propriété de ces classes est qu’elles ne contiennent aucune méthode de traitement. Elles contiennent simplement les getters et les setters pour récupérer ou bien retourner la valeur d’un attribut. Ces classes contiennent ainsi le mappage avec notre base de données relationnelle en utilisant la méthode d’annotations. On veut dire par mappage la liaison entre les classes java avec les tables de la base. En effet le mappage englobe la correspondance des attributs avec les colonnes de la table associée à cette classe ainsi que le mappage des relations existantes entre les tables, par exemple la relation one-to-many ou many-to-many.  Le contrôleur : A ce niveau, nous trouvons les Managed Beans plus le contrôleur « faces servlet » du « Framework JSF » pour la partie web. Concernant la partie desktop, le contrôleur implémente donc un Action Listée c’est à dire un « écouteur » de boutons.  La vue : A ce niveau, nous trouvons seulement les pages xhtml (facelet du Framework JSF), JSP (Java Server Pages) uniquement sans actions avec une référence sur le Modèle pour faire des changements (en lecture) sur la vue en cas de changement du Modèle. Figure 14 : Diagramme de paquetage
  • 48. Chapitre 04. Conception Détaillée 36 Conclusion A ce stade, nous avons achevé le développement de notre dernier release de notre application pour produire un logiciel complet et fonctionnel. Il nous reste cependant une dernière étape qui consiste à implémenter l’application auprès du client final.
  • 49. Chapitre 5. Réalisation Introduction La phase de clôture ou de fermeture est la dernière phase dans le cycle de développement d’un logiciel avec Scrum. Cette phase est souvent appelée sprint de stabilisation ou durcissement. Les tâches effectuées pendant cette phase ne sont pas claires, et elles dépendent fortement du type de déploiement du logiciel. Pour notre projet, on consacrera ce chapitre pour la présentation des langages et outils de programmation utilisés pour la réalisation de notre application ainsi que le déploiement. Nous finissons par la suite avec quelques interfaces graphiques du logiciel fourni. 1.1. Environnement de développement L’environnement de développement est un terme qui désigne l’ensemble des outils et de langages utilisés pour l’implémentation d’une solution informatique. Nous commençons par l’environnement matériel. 1.1.1. Environnement matériel Pour le développement de cette application, Nous avons utilisé un pc avec la configuration suivante : Model ASUS X556U CPU Intel Core i5-6200U (up to 2.80 GHz, 3M mémoire cache) RAM 8 Go DDR3 GPU NVIDIA® GeForce® GT 920M (2 Go dédiée DDR3) HDD 1To SE Windows 10 64Bits pro Table 9: Environnement Matériel
  • 50. Chapitre 05. Réalisation 38 1.1.2. Environnement Logiciel Les outils utilisés pour le développement des projets concernent :  Le kit de développement en Java (JRE).  La mise en place d'un environnement de développement (Eclipse Néon 2.0).  L'installation et la configuration du serveur Java (Apache Tomcat V8.0).  le SGBD MySQL 5 Les logiciels qui ont été utilisés pour l’implémentation de notre solution sont les suivants: Version Apache Tomcat 8.0 Version Eclipse Néon 2.0 Version Spring IDE 3.6.3.201411271034-RELEASE Version Hibernate Tools for Eclipse 3.5.1.v20130102-1835-H100-Final Version du Framework Hibernate Hibernate-release-4.3.8.Final Version du Framework Spring Spring-Framework-4.1.5.RELEASE-dist Version jsf Primefaces 2.0 Table 10: Environnement Logiciel Eclipse Eclipse est un IDE (environnement de développement intégré) écrit en Java, extensible par des greffons, multi-langages et multi-plates-formes. Il est d'abord conçu pour le langage Java mais ses nombreux greffons en font un environnement de développement pour de nombreux autres langages de programmation N[5]. JRE JRE : Java SE Runtime Environment (couramment JRE) c’est l’environnement où le code java va être compilé afin que la machine virtuelle puisse l’interpréter puis l’exécuter. Nous utiliserons le JRE1.8u121
  • 51. Chapitre 05. Réalisation 39 Apache Tomcat Apache Tomcat: C’est un serveur Java EE obligatoire pour le développement des pages web dynamiques. Pour combler le manque de serveurs http classique qui ne comprennent pas les servlets et JSP celui-ci utilise un moteur de servlet Hibernate Hibernate est un (ORM) mapping objet-relationnel N[6], c’est un ensemble de bibliothèques qui vont ajouter une surcouche au SGBD pour permettre aux développeurs de manipuler seulement les objets et ne plus se soucier de la base de données et des requêtes SQL. Hibernate Tools Hibernate Tools est un ensemble d'outils pour Hibernate3 mis en œuvre comme une suite intégrée de plugins Eclipse. Hibernate Tools est un élément essentiel de JBoss Tools et donc également partie de JBoss Développer Studio. Intègre les fonctionnalités suivantes à éclipse : Lapping Editor, Console, Reverse engineering, etc. Springs IDE Springs IDE est un projet open-source qui fournit un ensemble de plugins pour l'IDE Eclipse. Après l'installation des plugins Springs IDE, votre IDE comprend vos projets de point de vue du cadre de Springs et vous offre une grande variété de fonctionnalités supplémentaires qui font qu'il est plus facile et plus commode de travailler avec des projets Springs dans Eclipse.
  • 52. Chapitre 05. Réalisation 40 Springs Framework Springs est considéré comme un conteneur dit « léger ». La raison de ce nommage est expliquée par Erik Gollot dans l’introduction du document Introduction au Framework Spring4 N[7]. Springs est effectivement un conteneur dit « léger », c’est-à-dire une infrastructure similaire à un serveur d'applications J2EE. Il prend donc en charge la création d’objets et la mise en relation d’objets par l’intermédiaire d’un fichier de configuration qui décrit les objets à fabriquer et les relations de dépendances entre ces objets. Le gros avantage par rapport aux serveurs d’application est qu’avec SPRING, les classes n’ont pas besoin d’implémenter une quelconque interface pour être prise en charge par le Framework (au contraire des serveurs d’applications J2EE et des Embus). C’est en ce sens que SPRING est qualifié de conteneur « léger ». Le contexte le plus important qu’on a utilisé pour notre application c’est IOC : l’inversion de contrôle est assurée de deux façons différentes : la recherche de dépendances et l'injection de dépendances, la programmation orientée aspect, une couche d’abstraction. Power Designer C’est un logiciel de modélisation. Il permet de modéliser les traitements informatiques et leurs bases de données associées. Créé par SDP sous le nom AMC*Designer, racheté par Powersoft, ce logiciel est produit par Sybase depuis le rachat par cet éditeur en 1995. Hors de France, la version internationale est commercialisée par Sybase sous la marque Power Designer N[8]. Power AMC permet de réaliser tous les types de modèles informatiques. Il reste un des seuls qui permet de travailler avec la méthode Merise, cela permet d'améliorer la modélisation, les processus, le coût et la production d'applications.
  • 53. Chapitre 05. Réalisation 41 WampServer J’ai utilisé WampServer puisque c’est une plate-forme de développement Web sous Windows pour des applications Web dynamiques. Il m’a permis donc de pouvoir concevoir le site web transactionnel en local sur mon ordinateur. WampServer est très complet puisqu’il dispose du serveur Apache2, gère des fichiers du langage de scripts PHP et d’une base de données MySQL. Il possède également PHP MyAdmin qui permet de gérer les bases de données. Adobe Dreamweaver Si un simple éditeur de texte, comme Notepad ou Bloc-notes fait très bien l’affaire. J’ai tout de même choisi d’utiliser Adobe Dreamweaver. Tout d’abord pour son auto complétion HTML et CSS qui est très pratique, agréable et rapide. Ainsi que par les différents modes de conception offerts, la transition entre les différents modes de conception est très rapide ce que je trouve très agréable lors du commencement de la structure du site web. Il me permet de voir instantanément si mes éléments graphiques ont été correctement appelés, structurés et positionnés. Microsoft Word Microsoft Word est souvent appelé simplement Word ou MS Word. C’est un traitement de texte commercial largement utilisé a été conçue par Microsoft. MS Word est un composant de la suite MS Office de logiciels de productivité. Il a été initialement lancé en 1983 et a depuis été révisée de nombreuses fois. Il est disponible sous Windows et Macintosh.
  • 54. Chapitre 05. Réalisation 42 Microsoft Project Microsoft Project est un logiciel de gestion de projet le plus populaire au monde, développé et vendu par Microsoft. MS Project est conçue pour aider les gestionnaires de projets à élaborer des plans, l'affectation de ressources à des tâches, suivi des progrès, la gestion des budgets et l'analyse des charges de travail, etc. 1.2. Les langages de programmation Java Java est un langage de programmation informatique d'usage général qui est concurrente, sur la base de classe, orienté objet, et spécifiquement conçu pour avoir aussi peu de dépendances de mise en œuvre possible. Il est destiné à permettre aux développeurs d'application « écrire une fois, exécuté partout » (WORA : « write once, run anywhere »), ce qui signifie que le code Java compilé peut fonctionner sur toutes les plateformes qui supportent Java sans la nécessité d'une recompilation. Des applications Java sont généralement compilées en byte code qui peut fonctionner sur n’importe quelle machine virtuelle Java (JVM) indépendamment de l'architecture informatique. En 2015, Java est l'un des langages de programmation les plus populaires dans l'utilisation, en particulier pour les applications web client-serveur. HTML5 Le HTML est un langage qui a pour rôle de gérer et organiser le contenu d'une page web. C'est un langage de description de données, et non un langage de programmation. J'ai utilisé le HTML 5 qui est la dernière version du HTML qui est actuellement toujours en développement.
  • 55. Chapitre 05. Réalisation 43 CSS3 Le rôle du CSS est de gérer l'apparence de la page web (agencement, positionnement, décoration, couleurs, taille du texte…). Ce langage est le complément du langage HTML pour obtenir une page web avec du style. Le navigateur parcourt le document HTML. Lorsqu'il rencontre une balise, il demande à la CSS de quelle manière il doit l'afficher. JavaScript JavaScript est un langage interprété par le navigateur. Le JavaScript est un langage « client », c'est-à-dire exécuté chez l'utilisateur lorsque la page Web est chargée. Il a pour but de dynamiser les sites Internet. UML Le langage de modélisation unifié, de l'anglais Unifie Modeling Language (UML), est un langage de modélisation graphique à base de pictogrammes conçu pour fournir une méthode normalisée pour visualiser la conception d'un système. Il est couramment utilisé en développement logiciel et en conception orientée objet. HQL (Hibernate Query Language) : Hibernate Query Language (HQL) est un langage de requête orientée objet, similaire à SQL, mais au lieu d'opérer sur les tables et colonnes, HQL travaille avec des objets persistants et leurs propriétés. Les requêtes HQL sont traduits par Hibernate en requêtes SQL classiques qui effectuent à tour de rôle action sur la base de données.
  • 56. Chapitre 05. Réalisation 44 Bootstrap Bootstrap est une collection d'outils utile à la création du design (graphisme, animation et interactions avec la page dans le navigateur ... etc. ...) de sites et d'applications web. C'est un ensemble qui contient des codes HTML et CSS, des formulaires, boutons, outils de navigation et autres éléments interactifs, ainsi que des extensions JavaScript en option. 1.3. Phase d’implémentation 1.3.1. Contraintes Pour garantir la fiabilité, l’optimalité et la sécurité du projet, il est indispensable d’étudier les contraintes et les problèmes pouvant nous rencontrer. Pour répondre aux exigences d’implémentation de notre application, nous avons respecté les contraintes suivantes :  La modularité : La décomposition du logiciel en petits modules facile à maintenir et entretenir, qui, en les rassemblant donneront un logiciel.  La maintenabilité : la facilité de maintenir le système afin de le mettre à jour, c’est- à-dire un système simple et rapide à réparer.  La sécurité : les informations critiques seront cryptées, tels que les mots de passe par des algorithmes de hachages.  La portabilité : La capacité de l’application à fonctionner dans sous différents environnements d'exécution. 1.3.2. Pratiques adoptées  Règles de nommage : Donner des noms significatifs et explicites qui seront faciles à retenir pour les noms des tables, attributs, nom des méthodes.  Règles de présentation : Commenter les lignes de codes des classes java  Règles de syntaxe : Utiliser des structures simples à comprendre et éviter les complexités dans le code afin de réduire les risques de dysfonctionnement.
  • 57. Chapitre 05. Réalisation 45 1.4. Diagramme de déploiement Le diagramme de déploiement est une vue statique qui sert à représenter l'utilisation de l'infrastructure physique par le système et la manière dont les composants du système sont répartis ainsi que la relation entre eux N[9]. Les éléments utilisés par un diagramme de déploiement sont principalement les nœuds, les composants et les associations. Les caractéristiques des ressources matérielles physiques et des supports de communication peuvent être précisées par stéréotype. Figure 15 : Diagramme de Déploiement
  • 58. Chapitre 05. Réalisation 46 1.5. Les interfaces Figure 16 : Interface « Accueil » Figure 17 : Interface « Login »
  • 59. Chapitre 05. Réalisation 47 Figure 18 : Interface « Logout » Figure 19 : Interface « Gestion des Contrats »
  • 60. Chapitre 05. Réalisation 48 Figure 20 : Interface « Ajout Contrat » Figure 21 : Interface « Modifier Contrat »
  • 61. Chapitre 05. Réalisation 49 Conclusion Au cours de ce chapitre nous avons décrit la phase de réalisation de notre système d’information dans lequel nous avons défini les outils de travail utilisés. Nous avons donné un aperçu sur les contraintes et la pratique adopté. Et les interfaces utilisateurs.
  • 62. 50 Conclusion générale Au terme de ce rapport, j’avance que ce stage a été très enrichissant pour moi car il m’a permis de découvrir le milieu professionnel à travers une société de grande envergure telle que Tunisair Technics. J'ai pu distinguer à cet occasion plusieurs détails du secteur de la maintenance en aéronautique dont principalement le volet de l'approvisionnement qui présente plusieurs contraintes dans sa gestion en général et dans son système de gestion informatisée plus particulièrement. Il m’a permis de participer concrètement à ses enjeux au travers de ma mission visant à mettre en application les éléments nécessaires pour l'élaboration assistée d'un tableau de bord pour l'évaluation des fournisseurs. J’ai particulièrement apprécié l'approche de compléter un logiciel de gestion déjà existant; l'objectif étant de fournir une solution et non uniquement de développer des applications. Au cours de mon stage, et pour le mener à bien, j'ai suivi une bonne planification pour chaque étape. J'ai tout d’abord exploré les lieux pour la collecte d’informations moyennant des interviews avec les services concernés afin de définir le système étudié. Pour la conception j'ai utilisé des formalismes et des méthodes simples qui facilitent le travail. Pour la réalisation de l’application, j'ai eu l'occasion d'apprendre et d'utiliser un langage riche et souple. Cette expérience m'a permis aussi bien de concrétiser les connaissances qui m'ont été transmises au cours de ma formation que d’apprendre de nouvelles techniques et technologies. J'ai été appelé à surmonter plusieurs difficultés auxquelles j'ai fait face. Au début c’était de comprendre le besoin du client, ensuite de collecter et mettre en ordre le tas d’informations collectées. Enfin j'ai dû faire le nécessaire pour développer le nouvel outil avec des techniques que j'ai apprises au cours de mon stage même. Plusieurs améliorations peuvent être apportées au système étudié. En plus de compléter l'application, il y a lieu de limiter la partie estimative du tableau de bord. Pour cela je sollicite de développer une procédure pour saisir des évaluations normalisées au niveau des commentaires des Devis, Commandes et Bons de Livraison et de développer une routine pour les récapituler pour les insérer dans le tableau de bord.
  • 63. 51 Nétographie N[1] https://www.projet-plume.org/ressource/uml N[2] Roels, C. (2015). openclassrooms. Récupéré sur http://openclassrooms.com/courses/debutez-l-analyse-logicielle-avec-uml/les-differents-types- de-diagrammes. N[3] Lothon, F. (2013, Juin). agiliste. Récupéré sur http://www.agiliste.fr/items/bien-demarrer- avec-scrum/. N[4] wikipedia. (2015). Récupéré sur http://en.wikipedia.org/wiki/Java_(programming_language) N[5] ubuntu-fr. (2013). Récupéré sur http://doc.ubuntu-fr.org/eclipse. N[6] hibernate. (2015). Récupéré sur http://hibernate.org/tools/. N[7] docs.spring.io (2015). Récupéré sur http://docs.spring.io/spring/docs/current/spring- framework-reference/htmlsingle/ N[8] wikipedia. (2015). Récupéré sur http://fr.wikipedia.org/wiki/PowerAmc. N[9] wikipédia. (2015) Récupéré sur http://fr.wikipedia.org/wiki/Diagramme_de_déploiement
  • 64. 52 Annexe 1 : Formulaire de pré évaluation des Fournisseurs et des Sous-traitants
  • 65. 53
  • 66. 54 Annexe 2 : Fiche de suivi de la performance des Fournisseurs
  • 67. 55 Annexe 3 : Fiche de suivi de la performance des Sous-traitants