Sunteți pe pagina 1din 44

Département Génie Industriel

Projet de Fin d’Année

Développement d’une application de


contrôle de réception

Réalisé par :

Adel Lajil Saleh Nabil

Classe :
2GSIL C

Encadré par :

M.Zied Achour

Année universitaire 2018/2019


Remerciements

Nous voudrions tout d’abord témoigner nos sincères remerciements et notre profonde
reconnaissance à Monsieur Zied Achour professeur à l’école nationale d’ingénieurs de Car-
thage (ENICAR) pour son encadrement lors de la réalisation de ce projet.
Les directives de Monsieur Zied ont fait la partie majeure du succès de ce projet. Nous
tenons à le remercier pour la qualité de son encadrement, ses conseils et son soutien moral.
Nos remerciements s’adressent également aux membres du jury pour l’intérêt qu’ils ont
porté en acceptant d’examiner notre travail et de l’enrichir avec leurs propositions.
Liste des abréviations

NQA : Niveau de qualite


WCF : Windows Communication Foundation
IIS : Internet Information Services
ASP : Active Server Pages
SGBD : Système de gestion de base de données
WEB : World Wide Web
BD : Base de données
Table des matières

Table des tableaux vii

Table des figures viii

Introduction générale 1

1 Le contrôle de réception 2
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1 Les notion de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Risque client et risque fournisseur . . . . . . . . . . . . . . . . . . . 2
1.2 Niveau de qualité acceptable . . . . . . . . . . . . . . . . . . . . . . 3
2 Contrôle de réception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.2 But . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Différents types de contrôle . . . . . . . . . . . . . . . . . . . . . . 6
2.2.1 Contrôle par attribut . . . . . . . . . . . . . . . . . . . . . 6
2.2.2 Contrôle par mesures . . . . . . . . . . . . . . . . . . . . . 6
2.2.3 Contrôle par décompte du nombre des défauts . . . . . . . 6
2.3 Stade de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.4 Classement des défauts . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.5 Modes de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.1 Contrôle à 100 % . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.2 Contrôle par échantillonnage . . . . . . . . . . . . . . . . 8
3 Plans de contrôle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1 Plan simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Plan double . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
iv
TABLE DES MATIÈRES v

3.3 Plan multiple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13


3.4 Les règles de prélèvement . . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1 Passage du contrôle normal au contrôle renforcé . . . . . . 14
3.4.2 Passage du contrôle renforcé au contrôle normal . . . . . . 14
3.4.3 Passage du contrôle normal au contrôle réduit . . . . . . . 14
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2 Conception générale 16
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1 Critique de l’existant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2 Présentation du travail demandé . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Analyse des besoins et spécification . . . . . . . . . . . . . . . . . . . . . . 17
3.1 Besoins fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.2 Besoins non-fonctionnels . . . . . . . . . . . . . . . . . . . . . . . . 17
4 Conception UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Identification des acteurs . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Les cas d’utilisations . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Diagramme de classes . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . 21
5 Schéma relationnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3 Réalisation 23
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1 Environnement de travail . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1 Environnement Matériel . . . . . . . . . . . . . . . . . . . . . . . . 23
1.2 Environnement Logiciel . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Choix techniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.1 Choix du langage de programmation . . . . . . . . . . . . . . . . . 24
2.2 Choix du système de gestion de bases de données (SGBD) . . . . . 24
3 Interfaces graphiques de l’application . . . . . . . . . . . . . . . . . . . . . 24
3.1 Interface Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.1 Interface SCAN . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Interface de contrôle normal . . . . . . . . . . . . . . . . . 26
3.1.3 Interface de control double . . . . . . . . . . . . . . . . . . 27
3.2 Interface Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
vi TABLE DES MATIÈRES

3.2.1 Interface authentification . . . . . . . . . . . . . . . . . . 27


3.2.2 Interface consulter les fournisseurs . . . . . . . . . . . . . 28
3.2.3 Interface consulter ajoute de fournisseur . . . . . . . . . . 28
3.2.4 Interface consulter l’historique de fournisseur . . . . . . . 29
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

Conclusion générale 30

Bibliographie 30
Liste des tableaux

1.1 Tableau de correspondance . . . . . . . . . . . . . . . . . . . . . . . . . . . 3


1.2 Tableau générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Table de taille d’échantillon . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Choix en le contrôle destructif et le contrôle non destructif . . . . . . . . . 9
1.5 Table de plan simple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Table de plan double[2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.1 Dictionnaire de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

vii
Table des figures

1.1 schéma général du contrôle de réception avec risque α et β [4] . . . . . . . 3


1.2 Schéma de principe du plan simple[2] . . . . . . . . . . . . . . . . . . . . . 11
1.3 Schéma de principe du plan double[2] . . . . . . . . . . . . . . . . . . . . . 12
1.4 Schéma qui résume les règles de passage[2] . . . . . . . . . . . . . . . . . . 15

2.1 Diagramme de cas d’utilisation général . . . . . . . . . . . . . . . . . . . . 19


2.2 Diagramme de classe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Diagramme de séquence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Schéma entité association . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.1 classement des langages de programmation ,Source ; spectrum.ieee.org . . . 24


3.2 Classement de popularité des SGBDs,Source ; db-engines.com . . . . . . . 24
3.3 Interface SCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Interface de contrôle normal . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.5 Interface de contrôle double . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6 Interface authentification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.7 interface consulter les fournisseurs . . . . . . . . . . . . . . . . . . . . . . . 28
3.8 Interface consulter :ajoute de fournisseur . . . . . . . . . . . . . . . . . . . 29
3.9 Interface consulter l’historique . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.10 Les méthodes de service WEB . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.11 Méthode de connexion avec BD . . . . . . . . . . . . . . . . . . . . . . . . 33
3.12 Appel de service web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.13 modèle de reçu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

viii
Introduction générale

De nos jours, chaque entreprise cherche le meilleur moyen pour augmenter sa production
et de confronter les différents conflits qui peuvent être engendrés par le manque de coor-
dination et d’organisation au sein de ses différentes équipes. En effet, vu l’augmentation
de la concurrence, les différentes entreprise cherchent à assurer la qualité  totale pour
être leader du marché et surmonter les concurrents.
Pour assurer la conformité de ces produits, de nombreux processus de contrôle sont à la
disposition. Le contrôle de réception présente l’un de ces processus, qui permet à l’entre-
prise de n’accepter que des produits de qualité afin d’engendrer des produits fiables.
Pour cela, nous proposons d’élaborer une plateforme web et mobile qui informatise et
facilite cette tâche afin de gagne en temps et en fiabilité pour générer des gains financier.

Ce document comporte trois parties, le premier sera consacré à l’exploration de tous


les aspects du contrôle de réception. Dans le deuxième, on s’intéresse à la conception
de l’application développée. Le dernier chapitre présente la phase de réalisation de notre
application.

1
Chapitre 1
Le contrôle de réception

Introduction
Dans ce chapitre, nous allons présenter quelques notions de base du contrôle de récep-
tion en détaillant le but, les types et les différents modes de contrôle. Nous terminons par
présenter les différents plans d’échantillonnage en indiquant les règles de passages entre
ces derniers.

1 Les notion de base

1.1 Risque client et risque fournisseur

Lorsqu’on effectue un prélèvement statistique, il y a toujours un risque de trouver un


résultat sur le prélèvement qui ne soit pas l’image de la réalité du lot. Sachant qu’on peut
faire deux types d’erreur(Risque) :[4]
- Trouver mauvais, un lot qui en fait était bon (Risque α) : Le risque fournisseur (appelé
aussi risque α) est la probabilité, pour un plan d’échantillonnage donné, de se voir refuser
un lot considéré comme mauvais alors qu’il est bon.

- Trouver bon, un lot qui en fait était mauvais (Risque β) : Le risque client (appelé
aussi risque β) est la probabilité, pour un plan d’échantillonnage donné, d’accepter un lot
mauvais alors qu’il est bon.

2
Le lot est conforme Le lot n’est pas conforme
Refus Risque a Décision correcte
Acceptation Décision correcte Risque B

Table 1.1 – Tableau de correspondance

Il est délicat de déterminer facilement le plan qui convient aux deux risques.Alors
l’utilisation des tables standard qui permet de définir le plan d’échantillonnage.

Figure 1.1 – schéma général du contrôle de réception avec risque α et β [4]

1.2 Niveau de qualité acceptable


C’est le pourcentage maximal de non conforme qui peut être considéré comme satisfai-
sant en tant que caractéristique moyenne de la qualité de fabrication. Le NQA n’est pas
le résultat d’une étude statistique ; Il est choisi par le fournisseur en accord avec le client.
Dans la pratique lorsque la taille des lots, le niveau de contrôle et le NQA sont définis, on
3
peut déterminer à l’aide des tables la taille des échantillons, et le nombre de défectueux
dans l’échantillon pour qu’on puisse accepter le lot et celui pour qu’on puisse refuser le
lot. La détermination de la taille de l’échantillon à prélever du lot s’effectue en utilisant
les deux tables 1.2 et 1.3 :[4]

Contrôle spéciaux Usages généraux


Effectif du lot
S1 S2 S3 S4 I II III
2 à 8 A A A A A A B
9 à 15 A A A A A B C
16 à 25 A A B B B C D
26 à 50 A B B C C D E
51 à 90 B B C C C E F
91 à 150 B B C D D F G
151 à 280 B C D E E G H
281 à 500 B C D E F H J
501 à 1200 C C E F G J K
1201 à 3200 C D E G H K L
3201 à 10000 C D F G J L M
10001 à 35000 C D F H K M N
35000 à 150000 D E G J L N P

Table 1.2 – Tableau générale

Dans le premier pas, on détermine le niveau de contrôle adéquat.


• Niveaux généraux I II ou III.
• Niveaux spéciaux S1, S2, S3 ou S4 : Coût augmentant avec l’indice. Le niveau II est
le plus employé (niveau normal) d’autre part le niveau I est coûteux dont le niveau
III est de faible cout.
On s’intéresse uniquement au niveau II.
La deuxième pas consiste à déterminer la taille de l’échantillon en fonction du taille de lot
et lettre code prélevé dans le table précèdent, comme le montre le table 1.3 (niveau II)

4
Normale
Lettre Code Échantillon
Plan simple Plan double Plan multiple
A 2
B 3
C 5 3
D 8 5 2
E 13 8 3
F 20 13 5
G 32 20 8
H 50 32 13
J 80 50 20
K 125 80 32
L 200 125 50
M 315 200 80
N 500 315 125
P 800 500 200
Q 1250 800 315

Table 1.3 – Table de taille d’échantillon

2 Contrôle de réception

2.1 Présentation

2.1.1 Définition

Le contrôle de réception et la phase durant laquelle l’entreprise vérifie la conformité de


la matière première ou des produits semi-finis reçus depuis ses fournisseurs. Cette étape
permet de garantire le respect des spécifications établies dans le cahier des charges avant
son intégration dans le processus de l’entreprise. Le contrôle de réception s’applique à des
lots dont une opération de production est terminée :[4]
- Livraison par un fournisseur ;
- Passage d’une opération de production à la suivante ;
- Avant la livraison à un client.
5
2.1.2 But

Mise à part l’acceptation ou le refus d’un lot, le contrôle de réception a pour objectifs :
- Vérifier la conformité de la marchandise reçue.
- D’éviter l’utilisation d’un lot de matières défectueuses.
- D’évaluer et de suivre le niveau de qualité des produits reçus.
- Evaluer la performance et la qualité des produits du fournisseur.

2.2 Différents types de contrôle


Selon la nature des caractères contrôlés on pourra adopter l’un des trois types d’ins-
pections suivants

2.2.1 Contrôle par attribut

Ce type de contrôle s’applique aux caractères qualitatifs (aspect, couleurs...). Les in-
dividus (les pièces contrôlé) sont classés en bon ou défectueux selon qu’ils sont, ou non,
conformes aux spécifications qui ont fait l’objet d’un accord avec le fournisseur. La dé-
cision d’accepter au refuser un lot est basée sur le nombre de défectueux trouvé lors du
contrôle, si le contrôle ne prendre que un échantillon de lot.

2.2.2 Contrôle par mesures

Ce contrôle s’applique aux caractères quantitatifs (longueur des pièces, résistance...).


La décision sera basée sur la valeur moyenne trouvée et sur la dispersion des différents
résultats par rapport à cette moyenne.

2.2.3 Contrôle par décompte du nombre des défauts

Dans ce type, on énumère le nombre des défauts de chaque individu contrôlé et on


calcule le nombre moyen de défauts par individu. Le lot est alors accepté ou refusé en
fonction de ce résultat.

2.3 Stade de contrôle


Les contrôles peuvent être faits chez le fournisseur ou chez le client.

Contrôle effectue en totalité par le client


Si le fournisseur ne peut offrir aucune garantie, le client peut être conduit à examiner
6
tout le lot, on peut toutefois demander au fournisseur de présenter ses produits en classes
de qualité qu’il devra justifier. Alors la vérification peut se faire :
• chez le client : Si le lot n’est pas totalement accepté, (la vérification) entraı̂ne des
frais de main d’œuvre et de transport supplémentaires. En cas de litige le magasin
du client est encombré et il doit procéder à des manutentions pénibles.
• chez le fournisseur : Ce mode n’envisageable que lorsqu’il s’agit de commandes
importantes. Le client déplace chez le fournisseur et faire le contrôle.

Contrôle préalable fait par le fournisseur


• Les pièces non conformes sont signalées dans un procès-verbal adressé au client
avant expédition. Avant d’en accepter l’envoi celui-ci pourra envoyer un contrôleur
pour les examiner.
• Le fournisseur présente au contrôleur du client les produits qu’il a examinés, le
contrôleur ne procédera qu’à une vérification sommaire.

2.4 Classement des défauts


Le fournisseur doit respecter les besoins de son client pour assurer l’acceptation des
produits au cours de contrôle d’un lot, il faudra cependant juger les défauts en fonction
de leur gravité.
Les défauts peuvent être classés en trois catégories :

Défauts rédhibitoires : empêchant l’utilisation du produit ;

Défauts majeurs : nuisant à l’utilisation prévue ;

Défauts mineurs : diminuant la valeur commerciale du produit.

7
2.5 Modes de contrôle
2.5.1 Contrôle à 100 %

Dans ce mode de contrôle, chaque produit est contrôlé et c’est ce qui augmente le temps
de processus et augmenter le cout de contrôle.
Ce mode est nécessaire lorsqu’il y a un risque pour la vie des personnes.

2.5.2 Contrôle par échantillonnage

Dans ce mode de contrôle, on prendre au hasard un échantillon pour le contrôler, et


selon le nombre de défectueux trouvés, on prendre la décision d’accepter ou de refuser le
lot.[3]

Avantages :

• Plus économique que le contrôle à 100

• Gain de temps important .

• Économie de produit si l’essai est destructif .

• Donne une information plus complète sur la qualité du lot.

Inconvénients :
L’acceptation ou le refus du lot tout entier basant sur les résultats obtenus en exami-
nant quelques individus, laisse une incertitude. En effet, le pourcentage des défectueux
trouvés dans l’échantillon peut-être différent de celui que l’on aurait trouvé en examinant
la totalité de lot. La certitude comporte donc le risque du fournisseur et le risque du
client.[2]

Condition pour contrôler par échantillonnage


Ce mode de contrôle ne peut s’appliquer qu’à des lots homogènes d’individus, ces dernier
doivent être semblables tant par leur nature que par leur cycle de fabrication.

Efficacité du contrôle par échantillonnage


L’efficacité de ce contrôle augmente en proportion avec la taille de l’échantillon. Elle
dépend, du type d’inspection :

• Pour des risques égaux, l’échantillon est nécessaire pour le contrôle par mesure et
il est plus réduit que celui requis pour un contrôle par attributs, mais les calculs
8
à effectuer sont plus longs. Il ne peut être utilisé d’autre part, que si le caractère
contrôlé suit une loi normale.
• En cas du contrôle par attributs, pour une taille d’échantillon donnée, l’efficacité
augmente lorsque l’on réduit le nombre de défectueux au-delà duquel l’ensemble du
lot reçu est refusé.
Des variantes du contrôle par attributs :
• Échantillonnage double.
• Échantillonnage multiple .
• Échantillonnage progressif .
Ces types d’échantillonnage sont plus économiques que l’échantillonnage simple, quant au
nombre d’individus à contrôler.

Choix de contrôle
Le contrôle par échantillonnage devra être utilisé pour tous les contrôles destructifs et
contrôle non destructif dans le cas au les produits n’ayant aucun risque humaine. Aussi la
taille de séries, la valeur ajoutée des produits et le cout du contrôle sont prendre en compte
pour déterminer le type de contrôle convenable. Il est possible de résumer grossièrement
l’utilisation des deux types de contrôle sous forme de tableau 1.4 :

Produit avec risque Produit sans risque


Contrôle destructif Contrôle par échantillonnage Contrôle par échantillonnage
Contrôle non destructif Contrôle à 100% Contrôle par échantillonnage[2]

Table 1.4 – Choix en le contrôle destructif et le contrôle non destructif

3 Plans de contrôle
Il existe quatre types principaux de plans d’échantillonnage, dont on s’intéresse uni-
quement à 3 plans majeurs.

3.1 Plan simple


C’est le plan le plus simple, il nécessite qu’un seul prélèvement. Il consiste à préle-
ver un échantillon de taille  n  d’un lot de taille  N ( n déterminé en fonction de
9
 N comme montre la partie 1.2 et le contrôler .Selon la valeur de  NQA ,  n et grâce
à table 1.5 on déterminer le critère d’acceptation A et celui de rejet R=A+1 .

n\NQA% 0.025 0.04 0.065 0.1 0.15 0.25 0.4 0.65 1 1.5 2.5 4 6.5 10
2 0
3 0
5 0 1
8 0 1 2
13 0 1 2 3
20 0 1 2 3 5
32 0 1 2 3 5 7
50 0 1 2 3 5 7 10
80 0 1 2 3 5 7 10 14
125 0 1 2 3 5 7 10 14 21
200 0 1 2 3 5 7 10 14 21
315 0 1 2 3 5 7 10 14 21
500 0 1 2 3 5 7 10 14 21

Table 1.5 – Table de plan simple

10
Le schéma 1.2 ci-dessous traduit le principe de ce type de contrôle :

Figure 1.2 – Schéma de principe du plan simple[2]

3.2 Plan double


Ce type est de même principe qui est le plan simple, généralement plus économique
mais un peu plus complexe car il peut avoir un deuxième prélèvement.[2]

Principe :

• On détermine la taille de l’échantillon et les différents critères.


• On prélève et on contrôle un premier échantillon de taille n.
• Si le nombre de non-conforme est inférieur à A1, on l’accepte
• Si le nombre de non-conforme est supérieur à R1, on le refuse.
• Si le nombre de non-conforme entre A1 et R1, on prélève un deuxième échantillon
de même taille, et le compare le nombre de non-conforme total avec A2, R2 on
appliquant le même principe pour prendre la décision.[2]

11
Le schéma 1.3 ci-dessous traduit le principe de ce type de contrôle :

Figure 1.3 – Schéma de principe du plan double[2]

12
Dans ce plan on déterminer nos critères à l’aide de tableau suivant :

Plan simple Plans doubles


contrôle normal Contrôle normal Contrôle renforcé Contrôle reduit
A1 R1 A1 R1 A1 R1
A-R
A2 R2 A2 R2 A2 R2
0 2 0 2 0 2
1-2
1 2 1 2 0 2
0 3 0 2 0 3
2-3
3 4 1 2 0 4
1 4 0 3 0 4
3-4
4 5 3 4 1 5
2 5 1 4 0 4
5-6
6 7 4 5 3 6
3 7 2 5 1 5
7-8
8 9 6 7 4 7
5 9 3 7 2 7
10-11
12 13 11 12 6 9
7 11 6 10 3 8
14-15
18 19 15 16 8 12
11 16 9 14 5 10
21-22
26 27 23 27 12 16

Table 1.6 – Table de plan double[2]

3.3 Plan multiple


Le principe est le même que pour l’échantillonnage double, sauf que dans le cas de
l’échantillonnage multiple, les prélèvements peuvent aller jusqu’à sept prélèvements consé-
cutifs. Généralement, les échantillons ont le même effectif pour les différents prélèvements.

3.4 Les règles de prélèvement


Les interprétations des résultats des contrôles de réception permettent une classification
des fournisseurs. Si un fournisseur est douteux quant à la qualité de ses produits, le client
pratiquera un contrôle renforcé, dans le cas contraire on utilisera un plan réduit. La norme
définit trois types de contrôle : [2]
13
• le contrôle normal ;
• le contrôle renforcé ;
• le contrôle réduit.

3.4.1 Passage du contrôle normal au contrôle renforcé

Si une forte proportion de lots est refusée, cela signifie que la qualité des lots est
moins bonne que celle définie par le NQA. En règle générale, si deux lots parmi cinq lots
successifs ont été refusés, on passe au contrôle renforcé. On doit bien évidemment prendre
des mesures pour mettre en œuvre des actions correctives.

3.4.2 Passage du contrôle renforcé au contrôle normal

Le passage au contrôle normal suppose que la qualité des lots est en moyenne meilleure
que le NQA. Si cinq lots successifs ont été acceptés, on repasse au contrôle normal.

3.4.3 Passage du contrôle normal au contrôle réduit

Si au cours des contrôles, il apparaı̂t que la qualité des lots est notablement meilleure
que le NQA et que ce niveau de qualité a toutes les chances de se maintenir, il est alors
possible de diminuer les coûts de contrôle en passant au contrôle réduit. On retourne
au contrôle normal en cas de refus d’un lot ou en cas d’augmentation de la proportion
d’individus non conformes. En contrôle réduit, lorsque le critère d’acceptation est dépassé,
mais que le critère de rejet n’est pas atteint, le lot est accepté, mais le contrôle normal
est rétabli.

14
Figure 1.4 – Schéma qui résume les règles de passage[2]

Conclusion
Dans ce qui a précédé, nous avons présenté le contrôle de réception, ses différents types
et stades ainsi que le plan échantillonnage représenté par la taille de l’échantillon et les
différents critères.
Vu la difficulté du protocole et le risque élevé d’effectuer des erreurs en appliquant manuel-
lement les différents opérations, il vaut mieux d’informatiser et automatiser ce mécanisme.
La partie suivant va couvrir la conception d’une plateforme dédiée à simplifier le contrôle.
En s’intéressera uniquement aux plans de contrôle simple et double.

15
Chapitre 2
Conception générale

Introduction
Dans ce qui suit, nous allons présenter notre solution proposée, les objectifs de notre
application et sa conception générale que nous présentons par un ensemble de diagrammes.

1 Critique de l’existant
Le contrôle réception est un enjeu prioritaire au sein de l’industrie. L’opérateur est
en effet ammenés a traité au quotidien des volumes importants de lot reçu, consulter,
contrôler, remplir des rapports etc.
Toute une organisation qui entraı̂ne bien souvent :
• Des pertes ou des oublis provoquant des retards ;
• Des erreurs de calcul des critères ou passage entre les différents plans ;
• Perte du temps dut aux opérations manuelles de traitement ;
• Risque de perte de la traçabilité du rapport.

2 Présentation du travail demandé


Ce projet consiste à concevoir et mettre en place une plateforme web mobile qui prend
en charge toutes ces taches et renvoie à l’utilisateur une décision finale et faire le passage
nécessaire entre les différents plans après chaque contrôle, aussi à travers l’application web
le responsable a la possibilités de mieux gérer et évaluer les fournisseurs, voir l’historique
de réception pour chacun d’entre eux et imprime le reçu pour chaque réception.
16
Application Android
• Lire un QR code contenant l’identifiant de fournisseur, taille de lot et leur numéro.
• Renvoyer à partir des données reçues le critère d’acceptation A.
• Comparer A avec le nombre de non conformes donné par l’utilisateur.
• Afficher le résultat.
• Mise à jour de plan d’échantillonnage pour le fournisseur.

Application WEB
• Gérer les fournisseurs.
• Imprimé les reçu.

3 Analyse des besoins et spécification


Toute application doit répondre à plusieurs besoins attendus par l’utilisateur. Ces be-
soins peuvent être classés en deux catégories : Besoins fonctionnels et non-fonctionnels.

3.1 Besoins fonctionnels


Les besoins fonctionnelles expriment une action que doit effectuer le système en réponse
à une demande (sorties qui sont produits pour un ensemble donnée d’entré).
Le système proposé doit permettre de :
- Lecture d’un QR code.
- Affichage de la décision finale à propos du lot considéré.
- Gérer les fournisseurs.

3.2 Besoins non-fonctionnels


Les besoins non fonctionnels sont importants car ils agissent de façon indirecte sur le
résultat et sur le rendement de l’utilisateur. Notre application doit répondre à ces besoins
qui sont nécessaires pour atteindre la perfection et la bonne qualité du logiciel :
• Fiabilité : l’application doit fonctionner de façon cohérente sans erreurs.
• Efficacité : l’application doit permettre l’accomplissement des tâches avec le mini-
mum de manipulations.
• Performance : l’application doit être performante c’est-à-dire qu’elle doit répondre
à travers ses fonctionnalités à toutes les exigences des utilisateurs d’une manière
optimale.
17
4 Conception UML
La phase de conception UML consiste à comprendre le contexte du système. Il s’agit
de déterminer les acteurs et les fonctionnalités les plus pertinentes.

4.1 Identification des acteurs


Un acteur représente une personne, un matériel ou un logiciel qui interagit directement
avec le système en question.nous avons défini dans ce travail deux types d’acteurs :

L’ouvrier : C’est une personne responsable du processus de contrôle de réception. Cet


acteur est chargé de scanner les QR code de chaque lot et de procéder au contrôle des
échantillons ;

Le responsable qualité : C’est une personne dont le rôle est de superviser le déroule-
ment du processus de contrôle qualité.

4.2 Les cas d’utilisations


Les acteurs interagissent avec le système en effectuant les tâches suivantes :

L’ouvrier :
• Scanner les QR code : L’ouvrier a pour tâche de scanner les QR code relatifs à
chaque lot en utilisant l’application conçue.
• Déterminer la taille des échantillons et le critère d’acceptation : L’application facilite
la tâche de calcul de la taille de l’échantillon pour l’ouvrier.
• Contrôler les échantillons : Après avoir déterminer la taille de l’échantillon, l’ouvrier
doit procéder au contrôle qualité. Il doit fournir à l’application le nombre de non-
conforme qu’il vient de trouver dans l’échantillon et finalement prendre une décision
finale vis-à-vis le lot.

Le responsable qualité :
• Gérer les fournisseurs : le responsable a pour tâche d’ajouter, modifier ou supprimer
un fournisseur.
• Imprimer les reçus des contrôlers.
18
Figure 2.1 – Diagramme de cas d’utilisation général

4.3 Diagramme de classes


Le diagramme de classe est une description statique du système focalisé sur le concept
de classe et d’association. Une classe représente un ensemble d’objets. Une association
consiste à présenter les liens entre les instances des classes.

19
Ci-dessous est représenté le diagramme de classe de notre application :

Figure 2.2 – Diagramme de classe

20
4.4 Diagramme de séquence
Le diagramme de séquence permet une représentation graphique des interactions entre
les acteurs et le système selon un ordre chronologique. Il permet de montrer les interactions
d’objets dans le cadre d’un scénario de cas d’utilisation. Les principales informations
contenues dans un diagramme de séquence sont les messages échangés entre les lignes de
vie. Il décrit comment les éléments du système interagissent entre eux et avec les acteurs. Il
expose en détail la façon dont les opérations sont effectuées : quels messages sont envoyés
et quand ils le sont. Les diagrammes de séquence sont organisés en fonction du temps.
Le temps s’écoule au fur et à mesure qu’on parcoure la page. Les objets impliqués dans
l’opération sont répertoriés de gauche à droite en fonction du moment où ils prennent part
dans la séquence des messages.
Le diagramme de séquence de notre application mobile pour un contrôle normal et simple
est le suivante :

Figure 2.3 – Diagramme de séquence

21
5 Schéma relationnel
fournisseur ( Id Four ,NQA,echantillonnage,PlanC,Email )
LotRecu (id cntrl,#userid,NumLot,TailleLot,Pdef,PlanC,echantillonnage,date,etat)
Responsable(UserID,UserPass)

Attributs Désignations
Id Four Identifiant du fournisseur
NQA Niveau de qualité du fournisseur
Echantillonnage Type de contrôle du fournisseur
PlanC Plan de contrôle du fournisseur
Id cntrl Identifiant du contrôle
Userid Fournisseur de lot contrôlé
NumLot Numéro de lot
TailleLot Taille de Lot
Pdef Nombre de pièce non conformes
Date Date de contrôle
Etat Décision vis-à-vis lot contrôlé
UserID Identifiant de responsable
UserPass Mot de passe de responsable

Table 2.1 – Dictionnaire de données

Figure 2.4 – Schéma entité association

22
Conclusion
Dans ce chapitre, nous avons élaboré la conception de l’application. Ce qui nous permet
de faciliter sa réalisation. Le chapitre suivant décrit cette phase en se basent sur l’étude
et les diagrammes élaborés dans la phase de conception.

23
Chapitre 3
Réalisation

Introduction
Après avoir effectué l’étude et la conception de l’application, on va passer à la phase
d’implantation. Ce chapitre présente le résultat du travail effectué durant ce projet.
Ce chapitre sera clôturé par quelques captures d’écran démontrant les fonctionnalités de
notre application.

1 Environnement de travail
Pour la réalisation de ce travail, nous avons eu recours aux environnements suivants

1.1 Environnement Matériel


L’équipement utilisé pour la réalisation de ce projet se compose on un ordinateurs
portables dont la configuration est la suivante :

* Processeur : Intel core i7 ;


* 8 GO de mémoire vive ;
* 1TO d’espace disque.

1.2 Environnement Logiciel


* Système d’exploitation : Windows 10
* SGBD : Microsoft SQL server
* IDE de développement : Microsoft Visual Studio
* Outil pour la conception : draw.io
24
* Serveur : IIS

2 Choix techniques

2.1 Choix du langage de programmation


Le langage de programmation utilisé va beaucoup influencer le projet et la manière
dont celui-ci sera développé, en fonction des avantages et des inconvénients du langage. Il
convient de le choisir en considérant les besoins de projet, pour éviter de devoir changer
de langage en cours de projet, ce qui déclenche une perte de temps considérable.
Ils existent plusieurs solutions afin de procéder à un développement multiplateforme.
Beaucoup d’outils sont disponibles. Le choix s’est porter sur la solution la plus adaptable
avec notre programme d’étude de Framework .NET(C#) qui est devenu l’une de plus part
les langages utilisés. On opte pour Xamarin pour le développement mobile, ASP.NET pour
développement web et le service WCF comme un service web pour notre plateforme.
Dans le cadre de notre développement, l’utilisation du C# peut être très avantageuse par
son couplage fort avec Microsoft et ses outils en général. IIS le serveur utilisé durant notre
développement étant principalement équipé de Microsoft OS.

Figure 3.1 – classement des langages de programmation ,Source ; spectrum.ieee.org

2.2 Choix du système de gestion de bases de données (SGBD)


Une fois le langage choisis, on passera au choix de la SGBD .Toujours les critères
adoptés sont les performances et son conformité avec choix de programmation.
Dans le même cadre d’utilisation des outils de Microsoft, on adéquat a Microsoft SQL
Server.
25
Figure 3.2 – Classement de popularité des SGBDs,Source ; db-engines.com

3 Interfaces graphiques de l’application


L’interface graphique constitue le moyen via lequel l’utilisateur communique avec l’ap-
plication. Donc il est indispensable de créer des interfaces faciles à comprendre et surtout
facilement accessible afin d’aboutir à un résultat fiable.
Nous exposerons quelques interfaces de notre application, en essayant à chaque fois de
décrire les différents objets interactifs mis à la disposition de l’utilisateur.

3.1 Interface Mobile


3.1.1 Interface SCAN

Cette interface représente l’interface d’accueil. C’est une interface simple contenant un
bloc pour charger le camera directement, un label pour charger et afficher le contenu de
QR code et un bouton qui permettra à vérifier l’existence de fournisseur, la comptabilité
entre taille de lot et le niveau de qualité et le passage vers l’interface de contrôle.

26
Figure 3.3 – Interface SCAN

3.1.2 Interface de contrôle normal

Cette interface sert à afficher à l’utilisateur la taille de l’échantillon, le critère d’accep-


tation en fonction de NQL du fournisseur. Dans cette interface, l’utilisateur doit, après
avoir effectué le contrôle de l’échantillon, entrer le nombre de non-conforme trouvé dans
l’échantillon. L’application a pour rôle de comparer ce nombre avec le critère d’accepta-
tion et le critère de rejet et d’afficher un message la décision finale vis-à-vis le lot.

Figure 3.4 – Interface de contrôle normal

27
Après avoir cliqué sur le bouton résultat, l’application fait les mises à jour sur le plan
de contrôle pour le fournisseur sélectionné à base de son historique de réception, après il
faut cliquer sur le bouton  ok  pour que l’application revienne à l’interface scan pour
scan un autre QR code.

3.1.3 Interface de control double

Cette interface permet de contrôler suivant l’échantillonnage double, il est du même


principe que l’interface précédent.

Figure 3.5 – Interface de contrôle double

3.2 Interface Web


3.2.1 Interface authentification

La figure 3.6 représente l’interface d’authentification, que permet à la responsable l’ac-


cès aux pages de modération

28
Figure 3.6 – Interface authentification

3.2.2 Interface consulter les fournisseurs

Ci-dessous, l’interface que permet de consulter et gérer les fournisseurs .


A partir de cette interface le responsable peut choisir l’un de fonctionnalité suivante :ajou-
ter,modifier ou supprimer un fournisseur.

Figure 3.7 – interface consulter les fournisseurs

3.2.3 Interface consulter ajoute de fournisseur

La figure 3.8 permet la création d’un nouveau fournisseur.

29
Figure 3.8 – Interface consulter :ajoute de fournisseur

3.2.4 Interface consulter l’historique de fournisseur

L’interface qui permet de consulter l’historique des lots reçus .


A partir de cette interface le système a pour rôle de génère un reçu en format PDF, pour
un lot choisir en cliquant sur imprimer.

Figure 3.9 – Interface consulter l’historique

Conclusion
Dans ce chapitre, nous avons traité les détails de la réalisation de notre projet pour
aboutir enfin à l’application dont nous avons présenté certaines interfaces pour quelques
fonctionnalités.

30
À la fin de cette phase, on a obtenu une version finale de l’application  Contrôle de
réception prête à être utilisée.

31
Conclusion générale

Ce travail a été présenté en deux parties essentielles, la première a été consacrée au


cadre général du projet par la présentation du contrôle de réception et ses différentes
perspectives. Puis la deuxième partie a été réservé au développement d’une application de
contrôle de réception. Cette dernière est constituée de deux grandes sections. La première
section évoque la conception détaillée de l’application, et le second est dédié à la réalisation
de l’application.
Ce rapport se situe en effet, dans le cadre du projet de fin de la deuxième année du cycle
ingénieur. Ce projet était une véritable expérience de travail en collaboration, qui nous
a permis de bien gérer la répartition des tâches et de renforcer l’esprit de partage de
connaissances ainsi que la synchronisation de notre travail.

32
Bibliographie

[1] Casanova, G. Leçon 12 :Qualite.


[2] Casanova, G. TECHNIQUES STATISTIQUES.
[3] FERIGNA, P. Revue de Statistique Appliquee.
[4] IGNATIO, G. INDUSTRIALISATION :Le controle de reception. 2008.

33
Annexe

La figure ci-dissous présente les méthodes livre par notre service web :

Figure 3.10 – Les méthodes de service WEB

34
Ci-dessous est représenté le les chemine de connexion avec la base de données :

Figure 3.11 – Méthode de connexion avec BD

Ci-dessous une example de connexion de l’application mobile avec le service web et qui
montre l’appel d’une fonction :

Figure 3.12 – Appel de service web

35
La figure 3.13 ci-dessous présente le modèle de reçu généré par l’application :

Figure 3.13 – modèle de reçu

36

S-ar putea să vă placă și