Rapport 1

Table des Matières
Table des Matières
1. Introduction.................................................................................................................................15
2. Présentation de l’entreprise........................................................................................................15
2.1. Présentation de SAGEMCOM...............................................................................................15
2.2. Présentation de SAGEMCOM Tunisie..................................................................................17
2.2.1. Statut...........................................................................................................................17
2.2.2. Organisation générale..................................................................................................17
2.2.3. Effectif..........................................................................................................................17
2.2.4. Agréments Qualité.......................................................................................................18
2.2.5. Domaines d’activités et principaux clients...................................................................18
2.2.6. Spécificités...................................................................................................................19
3. Atelier décodeur et fonction Test................................................................................................19
3.1. Atelier Décodeur..................................................................................................................19
3.2. Fonction Test.......................................................................................................................20
3.2.1. Modélisation de la fonction Test..................................................................................20
3.2.2. Test In-Situ...................................................................................................................22
4. Approche matérielle du test In-Situ.............................................................................................22
4.1. Interface..............................................................................................................................22
4.2. Testeur In-Situ.....................................................................................................................23
5. Environnement logiciel du test In-Situ.........................................................................................25
5.1. Programme principal...........................................................................................................25
5.2. Langages de programmation...............................................................................................28
5.2.1. BT-Basic........................................................................................................................28
5.2.2. VCL (Vector Control Language)....................................................................................29
6. Présentation du projet.................................................................................................................29
6.1. Problématique.....................................................................................................................29
6.2. Etude empirique..................................................................................................................30
6.2.1. Temps d’arrêt de production.......................................................................................30
6.2.2. Coût d’arrêt de production..........................................................................................31
6.3. Travail demandé..................................................................................................................31
7. Conclusion...................................................................................................................................31
Page 4
Table des Matières
1. Introduction.................................................................................................................................33
2. Méthodologie du travail..............................................................................................................33
2.1. Choix du processus de développement..............................................................................34
2.2. Présentation 2TUP[3]...........................................................................................................35
2.3. Présentation du language UML...........................................................................................37
3. Capture des besoins et cas d’utilisation.......................................................................................37
3.1. Capture des besoins.............................................................................................................37
3.1.1. Les besoins fonctionnels..............................................................................................38
3.1.2. Besoins opérationnels..................................................................................................38
3.1.3. Spécifications et contraintes........................................................................................38
3.2. Cas d’utilisation....................................................................................................................38
3.2.1. Identification des acteurs.............................................................................................39
3.2.2. Diagramme de cas d’utilisation....................................................................................39
3.2.3. Diagramme d’activités.................................................................................................41
4. Scénarios d’utilisation..................................................................................................................41
4.1. Diagramme de séquences du scénario nominal..................................................................42
4.1.1. Diagramme de séquence relatif aux administrateurs..................................................43
5. Capture des besoins techniques..................................................................................................47
5.1. Spécification d’architecture.................................................................................................47
5.2. Spécification matérielle.......................................................................................................48
5.2.1. Côté serveur.................................................................................................................48
5.2.2. Côté Client...................................................................................................................48
6. Conclusion...................................................................................................................................48
1. Introduction.................................................................................................................................50
2. Environnement de travail de l’application...................................................................................50
2.1. Présentation de la plate-forme .NET....................................................................................51
2.2. Présentation du Visual Studio..............................................................................................52
2.3. Applications Windows.........................................................................................................52
3. Implémentation...........................................................................................................................54
3.1. Conduite de processus de développement..........................................................................54
3.2. Etapes de réalisation............................................................................................................55
3.2.1. Développement de l’application de contrôle des modifications des fichiers de test . .55
3.2.2. Développement de l’application d’envoi d’email.........................................................56
3.2.3. Création de la base de données...................................................................................56
Page 5
Table des Matières
3.3. Développement de l’interface graphique............................................................................58

3.3.1. Fenêtre d’authentification...........................................................................................58
3.3.2. Fenêtre de saisi de nouveau mot de passe..................................................................59
3.3.3. Fenêtre de choix..........................................................................................................60
3.3.4. Fenêtre choix des produits...........................................................................................60
3.3.5. Fenêtre de mise à jour de la base de données.............................................................61
4. Test de performance...................................................................................................................62
4.1. Test préliminaires................................................................................................................62
4.1.1. Test de performance de l’application de contrôle des modifications des fichiers.......62
4.1.2. Problèmes de traitement des fichiers volumineux.......................................................64
4.1.3. Solution adoptée..........................................................................................................64
4.2. Test de conformité...............................................................................................................66
4.2.1. Scénario nominal.........................................................................................................66
5. Conclusion...................................................................................................................................69
Page 6
Liste des Figures
Liste des Figures

Figure 1.1 : Organisation du Groupe SAGEMCOM septembre 2011……………………………….15
Figure 1.2 : Répartition des activités de SAGEMCOM……………………………………...………16
Figure 1.3 : Principales Filiales en dehors de l’Europe de l’Ouest …………………...………… .. 16
Figure 1.4 : Organisation de SAGEMCOM Tunisie…………………………………………………17
Figure 1.5 : Evolution de l’effectif 2003-2011 ……………………………………………………...17
Figure 1.6 : Principaux clients de SAGEMCOM Tunisie……………………………………………18
Figure 1.7 : Ligne de production décodeur…………………………………………………………..19
Figure 1.8 : Fonction Test Niveau A-0………………………………………………………………20
Figure 1.9 : Fonction Test Niveau A0………………………………………………………………..21
Figure 1.10 : Interface du Test In-Situ……………………………………………………………….22
Figure 1.11 : Testeur Agilent
3070…………………………………………………………………….23
Figure 1.12 : Schéma fonctionnel pour le test des composants analogiques………………………..24
Figure 1.13 : Schéma fonctionnel pour le test des composants digitaux……………………………24
Figure 1.14 :Organigramme du test In-Situ………………………………………………………...25
Figure 1.15 : L’arborescence du programme du test………………………………………………27
Figure 1.16 : Fenêtre BT-Basic ……………………………………………………………………..29
Figure 2.1 : Phase de spécification et de conception ……………………………………………….33
Figure 2.2 : 17 : Processus 2TUP…………………………………………………………………..35
Figure 2.3 : Cas d’utilisation globaux ……………………………………………………………...39
Figure 2.4 : cas d’utilisation relatifs aux utilisateurs non administrateurs…………………………..40
Figure 2.5: Cas d’utilisation relatifs aux administrateurs …………………………………………..40
Figure 2.6 : Diagramme d’activité …………………………………………………………………………..41
Figure 2.7 : Diagramme de séquence du scénario nominal ………………………………………………..42
Figure 2.8 :Diagramme de séquence relatif au changement de MDP .……………………………..43
Figure 2.9 :Accès à la base de données ……………………………………………………………44
Figure 2.10 :Diagramme de séquence relatif à la mise à jour de la table utilisateurs……….........45
Figure 2.11 :Diagramme de séquence relatif à la mise à jour de la table des produits ……………46
Figure 2.12 :Diagramme de déploiement d’une application d’architecture 2-tiers......................47
Figure 2.13 : Serveur de données HP DL 380...………………………………………………..…..48
Figure 3.1 :Environnement de l’application………………………………………………………...50
Figure 3.2 : Architecture de la plate-forme .NET …………………………………………………..51
Figure 3.3: Boîte à outils, surface de conception et liste des propriétés …………………………...53
Figure 3.4: Exemple de code que peut comporter un éditeur de code source ……………………...54
Figure 3.5 : Conduite de processus de développement ……………………………………………..55
Figure 3.6:Organigramme simplifié de l’application ………………………………………………..56
Figure 3.7 : Fenêtre d’authentification utilisateur ……………………………………………………
58
Figure 3.8: Fenêtre de saisi de nouveau mot de passe ………………………………………………..59
Figure 3.9: Fenêtre intermédiaire…………………………………………………………………....60
Figure 3.10 : Choix des produits………………………………………………………………….…61
Figure 3.11: Fenêtre de mise à jour de la BDD……………………………………………………..61
Figure 3.12 : Méthode de lecture……………………………………………………………………63
Page 7
Liste des Figures
Figure 3.13 : Contenu du fichier « test-ref »………………………………………………………..63

Figure 3.14 : Résultat de contrôle de modifications avec la méthode lecture ligne par ligne………...64
Figure 3.15 : Méthode de lecture de fichier en entier……………………………………………….65
Figure 3.16 : Modifications du fichier « testplan »………………………………………………….65
Figure 3.17 : Résultat de contrôle de modifications avec la méthode de fichier en entier………….66
Figure 3.18 :Fenêtre d’authentification…………………………………………………………….67
Figure 3.19 : Fenêtre intermédiaire…………………………………………………………………67
Figure 3.20 : Choix desproduits……………………………………………………………………68
Figure3.21: Exemple de mail de notification ………………………………………………68
Page 8
Liste des Tableaux
Liste des Tableaux

Tableau 2.1 : Etude comparative entre les différentes méthodes de développement……………..34
Tableau 3.1 :Etude comparative entre quelques SGBD…………………………………………....57
Page 9
Liste des Abréviations
2TUP : 2 Tracks Unified Process
ADT : Activité Decodeur TV
ATR : Activité Terminaux Résidentiels
BAV : Banc Audio Video
BDD : Base de Donnés
BFE : Banc Front End
BS : Boundary Scan
BU : Business Unit
CA : Chiffre d’Affaire
CLR : Common Language Runtime
CMS :Composant Monté en Surface
CUF : Chef Unité de Fabrication
IDE :Integrated Development Environment
IHM : Interface Homme Machine
IPTV :Internet Protocol Telivision
ISO :International Standards Organization.
LAN : Local Area Network
LED :Light Emetting Diode
M2M : Machine-to-Machine
MDP : Mot de Passe
OHSAS : Occupational Health & Safety Advisory Services
RUP : Rational Unified Process
SADT : Systems Analysis and Design Technique
SARL : Société à Responsabilité Limitée
Page 10
SAS : Société Anonyme Simplifiée
SAT : Satellite
SGBD : Système de Gestion de Base de Données
SMTP :Simple Mail Transfer Protocol
STB :Set Top Box
TER :Terre
TF :Test Fonctionnel
TI :Test In-Situ
TNT :Turner Network Television
TT :Terminal Technicien
UML :Unified Modeling Language
VCL : Vector Control Language
Page 11
Introduction Générale
La maîtrise du système de production en termes d’utilisation et de coût reste l’atout de toute

entreprise désireused’affronter sereinement les marchés concurrentiels.Pour cette raison,
l’entreprise peut s’engager dans la voie de l’amélioration de ses structures en cherchant à
supprimer les coûts de non conformités, à réduire les délais et à augmenter la qualité de ses
produits.
Dans des secteurs compétitifs, à savoir, l’industrie électronique, les gains en qualité et en
temps pèsent pour l’entreprise. Ils lui permettent de préserver son image de marque parmi les
différents éditeurs sur le marché et de s’imposer surtout que le secteur, grâce à la tendance
vers la maîtrise des technologies de fabrication et de test des cartes électroniques, est en
pleine expansion.
Notre entreprise d’accueil SAGEMCOM TUNISIE, est l’un des leaders dans le domaine
de haute technologie, qui a fait du développement de la démarche d’auto-qualité et de la
réduction du nombre de réclamations clients le cœur de ses objectifs.
Notre projet de fin d’études s’intègre dans cette politique globale et consiste à développer un
logiciel de surveillance et de suivi des programmes de test In-Situ des cartes électroniques
des décodeurs TV, réalisé au sein de SAGEMCOM TUNISIE. Il permet l’amélioration de la
qualité de test et la réduction de nombre de réclamations clients qui en résultent. Il réalise
aussi un gain en temps et en coût d’intervention suite aux modifications non-souhaitées des
programmes de test.
Ce mémoire s’articule autour de trois chapitres.Le premier chapitre est dédié à présentation
de l’environnement du travail et de la problématique. Le deuxième chapitre présente le choix
de la méthodologie et la démarche de conception utilisées pour étudier les besoins de ce
projet. Le troisième chapitre est consacré à la réalisation et au test de l’application
développée.
Page 12
Page 13
Chapitre 1 : Environnement de Travail et Problématique
Chapitre
1
Environnement de Travail et Problématique
1. Introduction
2. Présentation de l’entreprise
2.1. Présentation de SAGEMCOM
2.2. Présentation de SAGEMCOM Tunisie
3. Atelier décodeur et fonction Test
3.1. Atelier Décodeur
3.2. Fonction Test
4. Approche matérielle du test In-Situ
4.1. Interface
4.2. Testeur In-Situ
5. Environnement logiciel du test In-Situ
5.1. Programme principal
5.2. Langages de programmation
6. Présentation du projet
6.1. Problématique
6.2. Etude empirique
6.2.1. Temps d’arrêt de production
6.2.2. Coût d’arrêt de production
6.3. Travail demandé
7. Conclusion
Page 14
1. Introduction
La maîtrise des technologies de Test In-Situ et la réduction de nombre de réclamations

clients est au cœur des objectifs de SAGEMCOM Tunisie pour l’année 2011. Il serait
nécessaire d’en réduire dans la mesure de possible les coûts et le temps de non-conformités.
Sur les questions relatives aux méthodes de réduction de ces pertes, nous nous proposons
de développer un logiciel pour la surveillance et le suivi des programmes des Test In-Situ des
cartes électroniques.
Pour mieux procéder, nous nous intéressons au cours de ce chapitre à la présentation de la
société d’accueil SAGEMCOM Tunisie etnotammentl’atelier décodeur et le service TEST, au
sein duquel s’est déroulé notre projet de fin d’études.
2. Présentation de l’entreprise
2.1. Présentation de SAGEMCOM
SAGEMCOM est un groupe français spécialisé dans le domaine de haute technologie à
dimension internationale issu de la branche Communications de l’ex SAGEM. C’est
aujourd’hui un groupe privé indépendant détenu principalement par The Carlyle Group et ses
salariés.
Figure1.1 : Organisation du Groupe SAGEMCOM septembre 2011
Ayant acquis des positions de premier plan grâce à son fort potentiel d’innovation,
SAGEMCOM affirme son ambition de devenir un des leaders mondiaux des terminaux Haut
Page 15
débit, de la convergence et de l’Energie. La figure suivante illustre la répartition des activités

de SAGEMCOM en termes de CA.
BU Documents
20,12%
BU Décodeurs TV
numériques 31,43%
Figure1.2 : Répartition des activités de SAGEMCOM
Le group SAGEMCOM est présent dans plus de 40 pays au travers d’une soixantaine d’entités [1].
Figure 1.3 : Principales Filiales en dehors de l’Europe de l’Ouest
SAGEMCOM affirme son ambition de devenir un des leaders mondiaux des terminaux
communicants à forte valeur ajoutée. Elle opère sur les marchés du haut-débit, des télécoms et
de l’énergie, et de la gestion de documents : terminaux d’impression grand public
etprofessionnels, décodeurs de TV numérique, terminaux haut-débit et résidentiels,
communication M2M, maîtrise de l'énergie et systèmes, partenariats télécom et convergence.
Page 16
2.2. Présentation de SAGEMCOM Tunisie

2.2.1. Statut
C’est une Filiale de SAGEMCOM à 100%. C’est une société Anonyme à responsabilité
Limitée (SARL), au capital de 50 000 Dinars, créée en décembre 2002 et inscrite au Registre
du commerce de TUNIS sous le numéro : B158742 002.
C’est une société totalement exportatrice non résidente qui opère dans le domaine de la
communication, de partenariat industriel, de l’énergie, de l’audiovisuel de l’impression, du
traitement et de la transmission numérique de l’information.
2.2.2. Organisation générale

Directeur
des
Opération
Bruno
Directeur s
COSNIER Directeur
du Pole du Pole
Industriel
Gerard Industriel
Frederic
ADT
CANTIN Assistant ATR
THIEBAUD
e de
Direction
SamehHmani
Resp
Resp Resp Resp Resp Resp
CUF CUF Resp .
Indu . Main
. de CUF .
STB STB ADT: Test
ADT:* Indu ATR:
Mour s Proc ten- ATR
Abdelk Test
Wajih
1 2 Roma Erwa
ADT Salah ance Nuit ATR:
s Franci
ad ADT ess Frank Fethi ader ATR
BACC in n GHRI Adem
ATR s
MAST VERY Dziri BOUSS
ARI FORN CORN BI ETTA ABIDI DUPU
OUR
*Lieu de stage ELLI EC Y
Figure 1.4 : Organisation de SAGEMCOM Tunisie
2.2.3. Effectif
L’évolution du nombre de personnel de SAGEMCOM Tunisie pendant toute la durée de
son activité est illustrée par l’histogramme suivant :
2011 4605
2010 3652
2009 3084
2008 3540
2007 3050
2006 1550
2005 800
2004 550
55% 45%
2003 80
Fem Ho
Figure 1.5 : Evolution de l’effectif 2003-2011
mes mm
es
Page 17
L’extension des activités a été accompagnée par une évolution du nombre du personnel
qui s’est multiplié fois 60 dans une période de 8 ans avec un taux d’encadrement de 20% et
une moyenne d’âge de 26 ans.
2.2.4. Agréments Qualité

Dans le cadre de la démarche globale de management de l’entreprise, SAGEMCOM
Tunisie a réussi en 2008 avec succès la triple certification ISO 9001 pour la Qualité, ISO
14001 pour l’Environnement et OHSAS18001 pour la Sécurité et la Santé au Travail.
2.2.5. Domaines d’activités et principaux clients

SAGEMCOM Tunisie est une société totalement exportatrice qui fabrique une large gamme
de produits en grande et moyenne série qui sont essentiellement :
- Cartes électroniques pour applications électroménager (Fagor, Bosch,

Brandt…)
- Pièces électroniques pour sécurité énergie nucléaire (Alstom, Areva)
- Pièces électroniques pour applications industrielles (Schneider, Alstom…)
- Equipements pour maîtrise de l’énergie électriques (EDF, STEG, ENEL…)
- Consommables pour terminaux d’impressions
- Modems et Routeurs ADSL (France Télecom, Bouygues Télecom, Denmark
Télécom, Plant, Top net, Britsh télécom …)
- Décodeurs TV (Canal Digital, France télécom, Canal+...)
Figure 1.6 : Principaux clients de SAGEMCOM Tunisie
Page 18
2.2.6. Spécificités
L’Activité Décodeurs de TV numériques ADT de SAGEMCOM représente le plus grand
chiffre d’affaire dans le groupe (442 millions d’euros en 2010 environ 33.43% de l’ensemble
des CA) et actuellement le leader européen des décodeurs pour l’IPTV et la TNT[1].
Pour l’assurance de la production en très grandes séries des décodeurs de TV
numériques (350 000 pièces/mois), SAGEMCOM Tunisie dispose d’un service de Test ADT
au sein duquel s’est déroulé notre stage de fin d’études et dont la fonction sera détaillée dans
la partie qui suit.
3. Atelier décodeur et fonction Test

3.1. Atelier Décodeur
L’atelier Décodeur est composé de 6 lignes de production suivies de 6 lignes d’intégration
organisées de la manière suivante :
Figure 1.7 : Ligne de production décodeur
A l'arrivée du circuit imprimé nu, celui-ci est déballé et inséré dans un rack antistatique.
Le rack rempli, est déposé sur un désempileur qui va faire sortir automatiquement les circuits
un à un et les envoyer dans la première machine, la sérigraphie. Cette dernière étale une pâte
à braser à base d'étain permettant, après avoir été chauffée, de souder les composants sur le
circuit imprimé. Les machines de pose des CMS placent les composants sur le circuit et le
four de refusion fait chauffer l'étain pour assurer le contact.
Page 19
Nous avons donc un circuit équipé de composants. Il est temps maintenant d'insérer les
composants traversants manuellement (prise USB, Tuner, blindages,…). Ensuite, le circuit
passe à la vague pour la soudure. Une fois refroidis et nettoyés les circuits passent à
l’assemblage et au conditionnement. Il ne reste plus qu’à emballer et expédier au client.
3.2. Fonction Test

Le service test dans Sagem Tunisie assure la maintenance et l’amélioration des
performances des moyens de test. La fonction test permet de mesurer la qualité et la fiabilité
des produits et donc de valider l'ensemble de la chaîne de production.
Compte-tenu de la complexité et des performances croissantes des systèmes, Le test doit
être réalisé à chaque étape de fabrication du produit (du composant intégré au système fini).
3.2.1. Modélisation de la fonction Test

Pour modéliser la fonction Test des cartes électroniques sur les lignes de production des
décodeurs, nous nous proposons d’utiliser la méthode d’analyse fonctionnelle SADT
(StructuredAnalysus and Technic Design). Ce principe est décrit par la figure8.
Commande Opérateur Energie
Programme
Cartes non Cartes testées

testées Tester les cartes bonnes
électroniques A Rejet cartes
0
Postes de
test
A-0
Figure1.8 : Fonction Test Niveau A-0
La fonction est décrite en détail par la figure 1.9.
Page 20
Figure1. 9 : Fonction Test Niveau A0
Page 21
Le service test ADT de SAGEMCOM Tunisie est composé de deux pôles :
- Pôle Test In-Situ (TI)

- Pôle Test Fonctionnel (TF)
Dans notre cas nous nous intéressons au Test In-Situ, le pôle au sein duquel s’est déroulé
notre projet de fin d’études.
3.2.2. Test In-Situ

Test in-situ, destiné au test des cartes électroniques CMS, consiste à tester individuellement,
les uns après les autres, les différents composants que comporte la carte. L’accès aux
composants se fait via un lit à clous ou, si celle-ci comporte des composants boundary scan
(BS), via le connecteur de la carte. Le test in situ permet de :
- Tester les circuits ouverts et les courts-circuits ;

- Vérifier que les bons composants sont aux bonnes places ;
- Contrôler les valeurs des composants passifs (résistances, condensateurs, selfs, etc..) ;
- Vérifier le bon fonctionnement des circuits intégrés numériques. Si un composant est
défectueux, il est immédiatement localisé.
4. Approche matérielle du test In-Situ
L’outil de test in-situ se compose de deux parties principales :

- une interface de test spécifique à chaque carte,
- un testeur.
4.1. Interface
L’interface se partage en deux parties aussi, une partie supérieure qui est composée de la
cloche, les sondes et les switchers et une partie inférieure qui contient les points test. La
figure suivante montre un exemple d’interface (voir annexe).
Figure 1.10 : Interface du Test In-Situ
Page 22
Pour effectuer le test in situ d’une carte, il faut appliquer celle-ci sur un lit à clous. Et pour
cela, la grande majorité des interfaces utilise un système de dépression. La carte est « aspirée
» contre le lit à clous. Les sondes sont fixées dans une planche immobile solidaire du testeur.
Au-dessus de cette planche, une planche mobile (montée sur ressort ou sur joint souple) peut
monter ou descendre sous l’effet de dépression. Cette plaque mobile est percée de sorte que
les sondes puissent la traverser lorsqu’elle descend. C’est sur cette plaque que l’on place la
carte à tester (un point de test en regard de chaque trou). La dépression assure le maintient de
la carte contre la plaque mobile qui descend jusqu’à ce que les sondes entrent en contact avec
les points de test.
4.2. Testeur In-Situ

Les testeurs utilisés par Sagem Tunisie sont des Agilent 3070 illustré dans la figure
suivante[2].
Interface test Ecran
Imprimante
Clavier + Souris
Calculateur
Testhead
Figure1.11 :Testeur Agilent 3070
Nous détaillons dans les deux figures 1.12 et 1.13 les principes de test des composants
digitaux et analogiques.
Page 23
Figure 1.12 : Schéma fonctionnel pour le test des composants analogiques
Le composant à tester est représenté dans la figure 1.12 par la résistance Rx. Le programme
de test commande la carte CONTROL pour contrôler la carte de PIN et la carte des relais
ASRU. Afin de connecter le composant au circuit MOA, la source de tension Vs est
appliquée, et la sortie de MOA est mesurée par un détecteur qui détermine la valeur du
composant.
Rref
V MAO= V (éq.1)
Rref + Rx S
Avec VMOA est la tension de la sortie de MOA.
La figure 1.13 décrit le schéma fonctionnel d’un exemple du test digital. Le composant à
tester comporte des portes NAND. Nous appliquons des signaux logiques à partir des drivers
(de D1 à D4). Les récepteurs (portes OU exclusive R1 et R2) comparent la sortie du
composant à des références imposées par le programme du test. Deux cas sont possibles :
- Si la sortie est identique à celle imposée, le test est bon (Pass),

- Si la sortie est différente à celle imposée, le test est mauvais (Fail).
-
Figure 1.13 : Schéma fonctionnel pour le test des composants digitaux
Page 24
Dans le programme du test, les états attendus et les signaux envoyés au composant sont
déclarés comme des vecteurs. Par exemple, pour notre cas (le composant à tester comporte
des portes NAND) quand nous envoyons le vecteur 1010 les récepteurs compare le vecteur de
sortie de ce composant au vecteur attendu être reçu 11 si les deux vecteurs sont identiques le
composant est bon sinon il est mauvais.
5. Environnement logiciel du test In-Situ

5.1. Programme principal
L’analyse faite sur le programme du test a montré que le test d’une carte se fait selon les
différentes étapes suivantes. La figure 1.14 décrit ces différentes étapes.
Début
Initialis
ation
Déclaration
des options
hardware Programmation du flash
de chaque au niveau test_fonctionnel
Choix
type
Test type du
Pré- NON produit
Téléchar
short ger
OUI
Boot
Test Choix
short/ NON type du
open produit
Téléchar
OUI ger
Test Nomenc
testj NON Choix
lature
et type du
OUI produit
Téléchar
Test
ger
anal NON
Loader
og Choix
OUI type du
Test produit
degit NON Téléchar
ger TT
al Choix
OUI
Test type du
foncti NON produit
Téléchar
onnel
OUI ger CRC
Test
Test
mauv
bon
ais
Figure 1.14 :Organigramme du test In-Situ
Page 25
Description
Test pré-short :
- Mesure les impédances de faible valeur,
- Vérification de la position des cavaliers et switchers.
Test short et open :
- Détecte la présence des courts-circuits attendus, ainsi que l’absence de tous autres
courts-circuits dit non attendus.
Test Analogique :
- Vérifier les valeurs des composants analogiques (résistances, condensateurs, jumper,
transformateurs, transistors, LED, Zener).
Test jet :
Ce test permet de détecter les problèmes de soudures sur les broches des composants.
- Si mesure < seuil bas : pin du composant en l’air (mal soudée ou composant absent),
- Si mesure > seuil haut : court-circuit entre les broches.
Test Polarity Check :
- Vérifier le bon positionnement des capacités polarisées ;
- Mesurer de la capacité dans les deux sens avec un rapport qui doit être < 1.
Test Connect Check :
- Permet de vérifier la présence des diodes internes de clamping des composants
numériques.
Test Digital :
- Ce test est dédié aux circuits intégrés.
Test Mixed :
- Regroupe le test analogique et le test digital.
Le test d’un produit quelconque nécessite différents fichiers. La figure 1.15 explique
l’arborescence de programme du test.
Page 26
Agile
nt30
70
boar diagno
auto
ds stics
file
21 37 ……
60 00 ……
mip mcp3 mcp …….
x _tnt 2 .
analog digi mi 1%sh 2%sh 1%te 2% Tes Tes Wir bo ……

fixt
ue tal xed ort(. ort(. stjet( tes t t elis ard ……
ure
o) o) .o) tjet pla ord t
(.o) n er (.0)
Figure 1.15 : L’arborescence du programme du test
Sous le répertoire boards nous trouvons les programmes du test de chaque interface de
produit comme mcp2, mipx…etc. Nous disposons de :
- testplan: programme en BT-Basic contenant tous les appels aux tests des composants.
Il est exécuté à chaque test de carte;
- Répertoire analog contenant les fichiers de programmes de test écrits en BT-Basic de
chaque composant analogique testé ;
- Répertoire digital contenant les fichiers de programmes de test écrits en VCL de
chaque composant digital testé ;
- testorder: ce programme contient tous les composants de la carte électronique. Il
spécifie si le composant est testé ou il n’a pas d’accès donc il n’est pas testé (nulltest)
et il spécifie aussi si ce composant est commun pour tous les types de produit (voir
annexe) ;
- wirelist: ce fichier contient une liste de connections (wire) entre l’interface module
pin dans la carte de pin et les sondes dans l’interface. Chaque connexion listée dans le
wirelist spécifie la carte de pin nécessaire.
Page 27
Remarque:
- Le testeur fait le test de deux cartes en même temps. Nous trouvons par exemple, un
fichier pour la résistance R1 de la première carte nommé 1%r1 et un fichier pour la
résistance R1 de la deuxième carte nommé 2%r1. Ces fichiers sont ''linkés'' c’est à
dire que si nous modifions 1%r1 la modification sera automatiquement répercutée
dans 2%r1 ;
- Le testeur exécute seulement les objets pour cela, dans les répertoires analog et
digital nous trouvons les fichiers objets .o de chaque composant (1%r1.o, 2%r1.o).
- Dans des cas bien déterminés, le technicien test peut éviter de passer par toutes ses
étapes de test en précisant dans les fichiers testplan ou testorder les étapes de test à
abandonner. Mais toute modification non souhaitée peut aboutir à un produit non
conforme.
5.2. Langages de programmation

Les langages de programmation utilisés pour les tests sont le BT-Basic et le VCL.
5.2.1. BT-Basic
Le BT-Basic est le langage de programmation qui permet d’écrire des commandes dans le
système Agilentboard test. Les possibilités de programmation de BT-Basic incluent:
- Opération de virgule flottante,
- Modification de configuration binaire (jusqu'à 32 bits),
- Opérations (arithmétique et logiques),
- Variables (local et global),
- Sous-programmes,
- Étiquettes,
- Fonctions (arithmétique, logarithmique, exponentiel et trigonométrique),
- La modification de chaîne de caractères,
- L'image I/O,
- Les boucles (if-then-else, goto, et for-next),
- Manipulation et édition des répertoires et des fichiers.
Page 28
Le langage BT-Basic permettant à des commandes d'être exécutées immédiatement à

partir de l’éditeur ou d'un programme de test. La figure suivante décrit la fenêtre de BT-
Basic.
Figure 1.16 : Fenêtre BT-Basic
5.2.2. VCL (Vector Control Language)

VCL est un langage de programmation pour écrire des programmes de test pour:
- Différents composants digitales (test in-situ),
- Groupes de composants digitales.
Un test VCL se compose des fonctions de déclaration, des définitions de modèle de driver et
de récepteur (vecteurs) et d'exécution de vecteur.
6. Présentation du projet
6.1. Problématique
L’un des principaux objectifs que SAGEMCOM Tunisie s’est fixée pour l’année 2011 est
de réduire de 25% le nombre de réclamations clients.C’est dans ce cadre que notre projet de
fin d’études a été proposé et dans le but d’assurer la qualité des Test In-Situ et diminuer le
nombre de réclamations clients qui en résultent.
Page 29
Dans la phase de Test In-Situ de l’ADT, les interfaces aussi bien que les fichiers de test
changent en fonction des produits à tester. Les techniciens sont alors autorisés à apporter des
modifications sur quelques fichiers de test pour les adapter aux nouveaux produits et dans
d’autres cas et abandonner quelques étapes de test.
Une modification non souhaitée de ces fichiers peut entrainer des défauts de
programmation des micros contrôleurs PIC, donc des défauts produits qui ne peuvent être
détectés qu’à la réception du produit chez les clients.
Notre projet consiste alors à développer une application qui permet de contrôler les
fichiers de test et d’alerter les responsables de Test In-Situ en temps réel en cas de
modification et précisant les types de modifications si nécessaire.
6.2. Etude empirique

Les erreurs de programmation des micros contrôleurs PIC constituent l’un des problèmes les
plus pertinents dans l’atelier décodeur. L’étude des pertes qu’il peut engendrer est détaillée
dans la partie suivante en se basant sur un cas rencontré en septembre 2011 suite auquel le
client a déclaré des problèmes de mises à jour des décodeurs.
6.2.1. Temps d’arrêt de production

Le calcul de ce temps est effectué par le service qualité de SAGEMCOM Tunisie qui a
déclaré que suite à ce défaut il y a eu un arrêt de production de 15 jours pour les trois équipes
CMS.
Le temps de production non conforme est alors calculé comme suit :
TpNC= ∑ N jrA × N heq (eq.2)

N eqA
Avec :
- TpNC :Temps de production non conforme.
- NeqA: Nombre d’équipes en arrêt.
- NjrA : Nombre de jour d’arrêt pour chaque équipe.
- Nheq : Nombre d’heures d’arrêt par équipe
360 Heures
Page 30
6.2.2. Coût d’arrêt de production

Le coût d’arrêt de production au sein de l’atelier CMS est 15 euros/heure. Et en prenant en
considération le coût de rétrofit des décodeurs estimé à 10 000 euros, le coût global se calcule
comme suit :
Cg=TpNC ×Ch+Cr (eq.3)
Avec:
- Cg: Coût global.
- Ch: Coût d’arrêt par heure.
- Cr : Coût de retrofit
15 400 Euros
6.3. Travail demandé

A l’issue de cette étude, nous sommes appelés à développer une application avec VB.NET,
qui permet la surveillance d’états de modification des fichiers de test In-Situ de type
« testplan », « testorder » et d’extension « .objet » relatifs aux produits qui existent sous le
répertoire « new_tester ».
Cette application doit couvrir les points suivants :
- Alerter les utilisateurs par emails contenant l’emplacement et les dates de
modifications pour les fichiers de type objet ;
- Alerter les utilisateurs par email contenant l’emplacement, les dates de modifications
ainsi que les lignes modifiés dans le cas des fichiers de type « testplan » et
« testorder ».
- Répondre à l’architecture logicielle client serveur.
7. Conclusion
Les défauts de programmation des micros contrôleurs PIC constituent l’une des sources
de non-conformité des produits au sein de l’atelier décodeur. L’impact de ce défaut a été
évalué, dans ce chapitre, en termes de temps et de coût.
Pour la réduction de ces pertes, nous avons opté pour une application qui permet le suivie
et la surveillance des programmes de test In-Situ des cartes électronique du produit
décodeur.
Page 31
Dans le chapitre suivant, nous avons à présenter les phases de spécifications et de conception
de notre application.
Page 32
Chapitre2 : Spécification et analyse conceptuelle
Chapitre
2
Spécification et analyse conceptuelle
1. Introduction
2. Méthodologie du travail
2.1. Choix du processus de développement
2.2. Présentation 2TUP[3]
2.3. Présentation du language UML
3. Capture des besoins et cas d’utilisation
3.1. Capture des besoins
3.1.1. Les besoins fonctionnels
3.1.2. Besoins opérationnels
3.1.3. Spécifications et contraintes
3.2. Cas d’utilisation
3.2.1. Identification des acteurs
3.2.2. Diagramme de cas d’utilisation
3.2.3. Diagramme d’activités
4. Scénarios d’utilisation
4.1. Diagramme de séquences du scénario nominal
4.1.1. Diagramme de séquence relatif aux administrateurs
5. Capture des besoins techniques
5.1. Spécification d’architecture
5.2. Spécification matérielle
5.2.1. Côté serveur
5.2.2. Côté Client
6. Conclusion
Page 33
1. Introduction
Les phases de la spécification et la conception sont des déterminantes de notre projet. Nous
allons commencer tout d’abord par expliquer notre choix du processus de développement et
la méthode de conception. Ensuite, nous allons passer à l’analyse des besoins fonctionnels et
non fonctionnels de notre projet. Enfin, nous allons finir avec les diagrammes de cas
d’utilisation et de séquence.
Phase de
Phase de Phase de
spécificatio
conception réalisation
n
Chef de Spécificateur
Projet Analyste
Rédactio
Utilisateur -
n des
Concept
spécificat
eur
Analyse ions
Ko Analys
des Validati
générales e-
besoins on Concep
O tion
k
Spécification
Cahier des
s
charges
Figure 2.1 : Phase de spécification et de conception
La figure 2.1 montre le cycle de vie d’une application informatique et détaille les phases
de spécification et de conception auxquelles nous allons nous intéresser tout au long de ce
chapitre.
2. Méthodologie du travail
L’importance de la méthodologie de développement d’un projet provient du fait qu’elle est

indispensable pour le bon déroulement du projet et surtout pour la maintenance et l’évolution
possible de ce projet.
Page 34
2.1. Choix du processus de développement

Un processus de développement définit une séquence d’étapes, en partie ordonnée, qui
concoure à l’obtention d’un système logiciel de qualité qui répond aux besoins des
utilisateurs dans des temps et des coûts prévisibles.
Il existe plusieurs méthodes de développements tels que le processus en cascade, RUP,

2TUP…etc. Pour pouvoir choisir parmi ces méthodes nous avons besoin d’une petite étude
comparative illustrée dans le tableau 2.1.
Méthodologie Description Avantages Inconvénients

-Propose de dérouler -Distingue clairement les -Non itératif
Processus en les phases projet de phases projet
cascade façon séquentielle
-Cité pour les raisons - Ne propose pas de

historiques modèles de
documents
Promu par Rational -Itératif -Coûteux à
personnaliser :
-Le RUP est à la fois -Spécifie le dialogue entre les batterie de
une méthodologie et différents intervenants du consultants
un outil prêt à projet : les livrables, les
RUP l’emploi (documents plannings, les prototypes… -Très axé processus,
types partagés dans au détriment du
un référentiel Web) -Propose des modèles de développement :
documents, et des canevas peu de place pour le
-Cible des projets de pour des projets types code et la
plus de 10 personnes technologie
-S’articule autour de -Itératif -Plutôt superficiel

l’architecture sur les phases
-Fait une large place à la situées en amont et
-Propose un cycle de technologie et à la gestion du en aval du
développement en Y risque développement :
2TUP capture des besoins,
-Détaillé dans -Définit les profils des support,
« UML en action » intervenants, les livrables, les maintenance,
plannings, les prototypes gestion du
-Cible des projets de changement…
toutes tailles -Ne propose pas de
documents types
Tableau 2.1 : Etude comparative entre les différentes méthodes de développement
Page 35
Nous allons opter pour la méthode 2TUP parce qu’elle se distingue des autres méthodes
par son cycle en Y qui permet de paralléliser et de dissocier les besoins fonctionnels des
besoins techniques et donc de mieux répartir les contraintes initiales en amont du projet.
2.2. Présentation2TUP[3]
La méthode 2TUP sépare les aspects techniques des aspects fonctionnels avant de les
regrouper dans la phase de réalisation.
Figure 2.2 :Processus 2TUP
La méthode 2TUP est basée sur l’itération et l’incrémental. 2TUP permet de séparer les
contraintes fonctionnelles des contraintes techniques, sous la forme de deux branches :
– Branche Fonctionnelle
– Branche Technique
– Branche Conception-Réalisation
La branche fonctionnelle comporte :
Capture des besoins fonctionnels : produit le modèle des besoins focalisé sur le métier des
utilisateurs. Elle qualifie, au plus tôt possible le risque de produire un système inadapté aux
utilisateurs. Cette phase a pour objectif de définir :
– La frontière fonctionnelle entre le système considéré comme une boîte noire et son
environnement, c’est le niveau contexte.
Page 36
– Les activités attendues des différents utilisateurs par rapport au système toujours
envisagé comme une boîte noire, c’est le niveau cas d’utilisation
Analyse : consiste à étudier précisément les spécifications fonctionnelles de manière à

obtenir une idée de ce que va réaliser le système à produire en terme métier
La branche architecture technique comporte :
Capture des besoins techniques : recense toutes les contraintes sur les choix de
dimensionnement et la conception du système. Les outils et le matériel sélectionnés ainsi que
la prise en compte des contraintes d’intégration avec l’existant. Cette étape permet de définir
le modèle d’analyse technique. Le rôle de ce dernier est d’établir les couches logicielles et y
spécifier les activités techniques attendues.
Conception générique : définit ensuite les composants nécessaires à la construction de

l’architecture technique. Cette conception est complètement indépendante des aspects
fonctionnels. Elle permet de générer le modèle de conception technique ou design pattern qui
définissent les Frameworks. Ces derniers, délivrant les services techniques, assurent la
réponse aux exigences opérationnelles du système.
La branche conception-réalisation
Les principales étapes de cette branche se présentent comme suit :
Conception préliminaire : est une étape délicate, car elle intègre le modèle d’analyse
fonctionnelle dans l’architecture technique de manière à tracer la cartographie des
composants du système à développer. Cette étape permet de produire le modèle de
conception système. Ce dernier organise le système en composants, délivrant les services
techniques et fonctionnels. Ce modèle regroupe les informations des branches technique et
fonctionnelle.
Conception détaillée : permet d’étudier comment réaliserchaque composant. Cette étape

produit le modèle de conception des composants. Ce modèle fournit l’image prête à fabriquer
du système complet.
Codage et Test: C’est dans l’étape de codage que s’effectue la production des composants et
les testes des unités de code au fur et à mesure de leur réalisation.
Recette : consiste à valider les fonctionnalités du système développé.
Page 37
2.3. Présentation du languageUML

UML est un langage standard conçu pour l’écriture de plans d’élaboration de logiciels. Il peut
être utilisé pour visualiser, spécifier, construire et documenter les artefacts d’un système à
forte composante logicielle.
Bien que UML soit essentiellement utilisé pour une modélisation orienté objet le choix de ce
langage se justifie par le fait que :
- UML est un langage de modélisation unifié c'est-à-dire qu’il est sensé être une synthèse
des principales méthodes orientées objet ;
- UML propose un ensemble de diagrammes permettant d’avoir différentes vues pour
l’analyse et la description de la solution du problème. UML comprend l’expression des
besoins à partir de l’interaction entre l’utilisateur et le système, la présentation de la
structure statique du modèle et la partition du système en sous système ;
- Avec UML nous sommes libres de se reposer essentiellement sur des modèles ne faisant
pas nécessairement intervenir les objets.
Les avantages d’UML sont nombreux. Toutefois, il reste un formalisme dédie à la

méthodologie orientée objet [3].
UML définit des différents niveaux pour représenter les points de vue de modélisation, nous
pouvons citer :
Le diagramme de cas d’utilisation, c’est une représentation des fonctions du système du
point de vue de l’utilisateur.
Le diagramme de séquence, c’est une représentation graphique des interactions entre les
acteurs et le système dans un ordre chronologique.
Le diagramme d’activité, permet de représenter les aspects dynamiques du système à un
niveau assez général.
Le diagramme de déploiement,Le diagrammes de déploiement montrent la disposition
physique des matériels quicomposent le système.
3. Capture des besoins et cas d’utilisation

3.1. Capture des besoins
Pour mettre en œuvre notre application et donner une vue globale de son fonctionnement,
il est nécessaire de procéder au préalable à une analyse des besoins et à une
introductionformelle des exigences fonctionnelles et non fonctionnelles auxquelles le système
doit répondre.
Page 38
3.1.1. Les besoins fonctionnels

Notre application doit assurer un certain nombre de fonctionnalités de base qui sont :
- Informer les acteurs des modifications apportés sur les programmes de test. Ainsi,
l'information se fait par l'envoi des e-mails suivant un modèle bien déterminé ;
- Permettre aux acteurs de choisir les produits dont les fichiers de test vont être
contrôlés.
3.1.2. Besoins opérationnels

L’accès à l’application doit être sécurisé :
- Tous les utilisateurs doivent s’authentifier par un identifiant et un mot de passe ;

- Seuls les administrateurs peuvent gérer l’application.
Certaines données du système doivent être traitées en temps réel :
- Enregistrement des identifiants, des mots de passe, des droits d’accès, des nouveaux
produits dans une base de données.
3.1.3. Spécifications et contraintes

Notre application exige plusieurs contraintes de manipulation, ces contraintes peuvent être
exprimées par les besoins non fonctionnels suivants :
- L'application doit être intégrée dans le domaine de l'entreprise ;

- L'utilisateur qui veut manipuler l'application doit être un membre du groupe de
l'entreprise et peut gérer cette application selon son profil et ses permissions ;
- Temps de réponse : chargement de l’application, les délais de rafraichissement, etc,
- Temps de traitement : exportation et importation des données ;
- Les standards d’ergonomie et la facilité d’utilisation.
3.2. Cas d’utilisation

Afin de consolider et formaliser les différents besoins spécifiés dans ce qui précède nous
allons modéliser les différentes fonctions métiers apportées par notre future application au
moyen des cas d'utilisation. Pour cela nous allons utiliser le diagramme de cas d’utilisation
qui décrit, sous la forme d’action et réaction, le comportement du système étudié de point de
vue des utilisateurs.
Page 39
3.2.1. Identification des acteurs

Nous allons énumérer dans cette partie les acteurs susceptibles d'interagir avec notre
application.
Acteur 1:
Utilisateur: Tout employé appartenant au service Test In Situ ayant le droit d’utiliser
l’application.
Acteur 2:
Administrateur: Utilisateur ayant le privilège de gérer et manipuler les fonctionnalités de

l’application.
3.2.2. Diagramme de casd’utilisation
3.2.2.1. Cas d’utilisation globaux

Les cas d’utilisation présents à la figure 2.3 montrent les services communs aux utilisateurs et
aux administrateurs.
Figure 2.3 : Cas d’utilisation globaux
3.2.2.2. Cas d’utilisation relatifs aux utilisateurs ordinaires

La figure 2.4 montre les différents comportements qu’un utilisateur peut avoir vis-à-vis de
notre application.
Page 40
Figure 2.4 : Cas d’utilisation relatifs aux utilisateurs non administrateurs
3.2.2.3. Cas d’utilisation relatifs aux administrateurs

En plus de son droit d’utilisateur, l’administrateur a le privilège de :
– Ajouter des utilisateurs ;

– Modifier la base de données ;
– Donner les droits d’accès aux utilisateurs.
Le diagramme des cas d’utilisation exclusifs à l’administrateur du système est illustré par la
figure 2.5.
Figure 2.5 : Cas d’utilisation relatifs aux administrateurs
Page 41
3.2.3. Diagramme d’activités

Afin de bien modéliser et décrire la logique et l'enchaînement des activités qui concourent à
notre application, nous présentons le diagramme d'activités qui est utile pourreprésenter les
aspects dynamiques du système à un niveau assez général.
Début
Applicatio
n
Afficher la
fenêtre
d’authentificati
Saisir login et
on
MP
Vérifier les
attributs
ou Valid Non
i e?
Non
Admi MP No
n? oubl n
Ou Accéder aux ié? O
i Accéde No choix des
ui
Saisir nouveau
r à la n produits
MP
OuBDD? Sélectionner les
i
Mettre à jour la produits Stocker dans
BDD BDD
Enregistrer les Contrôler l’état
modif de modification
No No
Quitt Modif No
n n Quit
er ié? n
ter
O O Oui
ui Fin ui email
Envoi Fin
Figure 2.6 : Diagramme d’activités
4. Scénarios d’utilisation
Le diagramme de séquences permet de représenter graphiquement les interactions entre les

acteurs et le système. Il sert à clarifier, analyser et expliquer le comportement complexe du
système.
Page 42
4.1. Diagramme de séquencesdu scénario nominal

Le diagramme de séquences du scénario nominal présente, dans un enchaînement
chronologique nominal, les différentes étapes par lesquelles l’utilisateur doit passer pour
exécuter l’application.
Figure 2.7 :Diagramme de séquences du scénario nominal
1. L'utilisateur ouvre l'application en mode exécution. Le système affiche sur l'interface

vue par l'utilisateur une fenêtre d'authentification.
2. L'utilisateur s'authentifie tout en précisant un login et un mot de passe.
3. Se référer à la base de données pour vérifier si le login et mot de passe saisis par
l’utilisateur sont valides.
4. Login et mot de passe vérifiés.
5. Afficher la fenêtre suivante.
6. L’utilisateur choisit d’accéder à la liste des produits.
Page 43
7. Se référer à la base de données pour extraire la liste des produits valides.

8. Afficher la liste des produits valides.
9. L’utilisateur choisit de la liste des produits affichés.
10. Exécution de l’application
Enchaînement alternatif :
Dans le cas où le login et le mot de passe saisis par l’utilisateur sont invalides, le système
lui affiche un message d’erreur et la fenêtre d’authentification sera de nouveau affichée.
Dans le cas où l’utilisateur oublie son mot de passe, l’application lui offre la possibilité de
le changer comme le montre le diagramme de séquence suivant.
Figure 2.8 : Diagramme de séquence relatif au changement de MDP
4.1.1. Diagramme de séquence relatif aux administrateurs

En plus de son droit d’utilisateur ordinaire, l’administrateur jouit d’autres droits d’utilisations
qui lui sont exclusifs. Les scénarios possibles pour les administrateurs portent sur la mise à
jour de la base de données.
Page 44
Figure 2.9 :Accès à la base de données
1. L'utilisateur ouvre l'application en mode exécution. Le système affiche sur l'interface

2. L'utilisateur s'authentifie toute en précisant un login et un mot de passe.
6. L’utilisateur choisit d’accéder à la liste des produits.
7. Se référer à la base de données pour extraire la liste des produits valides.
8. Afficher la liste des produits valides.
La figure 2.9 montre bien que les cinq premières étapes sont identiques au scénario
nominal. Au moment où l’administrateur choisit de mettre à jour la base de données il sera
Page 45
appelé à choisir la table à laquelle il va apporter des modifications. Au niveau de la huitième

étape, trois scénarios peuvent avoir lieu comme le montrent les figures 2.10 et 2.11.
Mise à jour de la table utilisateurs et Administrateurs :
Figure 2.10: Diagramme de séquence relatif à la mise à jour de la table utilisateurs
1. L'utilisateur ouvre l'application en mode exécution.Le système affiche sur l'interface

6. L’utilisateur choisi l’option mise à jour de la base de données.
7. Le système affiche la fenêtre de mise à jour de la base de données.
8. L’administrateur sélectionne le bouton relatif à la table des utilisateurs.
Page 46
9. L’administrateur ajoute de nouveaux utilisateurs.

10. Le système stocke les nouvelles informations dans la base de données.
L’ajout de nouveaux utilisateurs par l’administrateur se fait en leur accordant des droits
d’accès en lecture et en écriture à la base de données. Seuls les administrateurs ont le droit
d’accès en écriture.
Mise à jour de la table des produits :
Figure 2.11 : Diagramme de séquence relatif à la mise à jour de la table des produits
1. L'utilisateur ouvre l'application en mode exécution.Le système affiche sur l'interface

6. L’utilisateur choisi l’option mise à jour de la base de données.
Page 47
7. Le système affiche la fenêtre de mise à jour de la base de données.

8. L’administrateur sélectionne le bouton relatif à la table des produits.
9. L’administrateur ajoute des nouveaux produits.
10. Le système stocke les nouvelles informations dans la base de données.
Mise à jour de la table des testeurs :

La mise à jour de la table des testeurs se fait exactement comme la mise à jour de la table de
produit.
5. Capture des besoins techniques
La capture des besoins techniques couvre avec celle des besoins fonctionnels, toutes les
contraintes qui ne traitent ni de la description du métier des utilisateurs, ni de la description
applicative. Cette étape nécessite une connaissance des pré-requis techniques. Le modèle s'y
exprime suivant les deux points de vue qui sont la spécification logicielle et la structure du
matériel à exploiter.
5.1. Spécification d’architecture

L’expression des pré-requis techniques implique également le choix d’un système
client/serveur. Ce choix conditionne la façon dont sont organisés et déployées les composants
d’exploitation du système. Notre système présente une architecture 2-tiers.
Figure 2.12 :Diagramme de déploiement d’une application d’architecture 2-tiers
Page 48
5.2. Spécificationmatérielle
Les choix techniques sont de nature géographique, organisationnelle, et technique. Elles
concernent les performances d'accès aux données, la sécurité du système, l'interopérabilité, la
volumétrie et le mode d'utilisation du système. Ils impliquent des contraintes relatives à la
configuration du réseau matériel et informatique.
Pour mieux procéder, nous commençons par présenter la configuration du réseau

informatique de SAGEMCOM TUNISIE.
Les locaux de SAGEMCOM TUNISIE sont répartis sur deux usines U1 et U2 reliées
entre elles par un câble de fibre optique monomode. Le réseau privé de l’entreprise est de
type LAN (Local Area Network) de topologie en étoile (voir annexe).
5.2.1. Côté serveur

Le serveur de données contenant les fichiers de test In-Situ à contrôler, est de type HP DL
380. Il se situe réellement à l’usine U1 sous le nom de « bnsrv05 » (voir annexe).
Figure 2.13 : Serveur de données HP DL 380
5.2.2. Côté Client

Un client peut être positionné à n'importe quel endroit du réseau local, à partir du
moment où il a un PC doté de l’IHM et connecté au serveur de données contenant les fichiers
de test.
6. Conclusion
Ce chapitre a permis de présenter et de définir d'une manière formelle les différentes
fonctionnalités de base de notre application tout en se basant sur les besoins fonctionnels et
non fonctionnels.
Nous avons détaillé, tout au long de ce chapitre, la conception de notre application à

travers les diagrammes de cas d’utilisation, de séquence, d’activité et de déploiement. Ainsi,
s'achève l'étape conception détaillée du processus de développement 2TUP.
L'étape suivante prend la relève et consiste à la mise en œuvre de la phase de codage et de

test tout en présentant les outils utilisés pour réaliser notre application.
Page 49
Chapitre 3 : Implémentation Test et Validation
Chapitre
3
Implémentation Test et Validation
1. Introduction.................................................................................................................................50
2. Environnement de travail de l’application...................................................................................50
2.1. Présentation de la plate-forme .NET....................................................................................51
2.2. Présentation du Visual Studio..............................................................................................52
2.3. Applications Windows.........................................................................................................52
3. Implémentation...........................................................................................................................54
3.1. Conduite de processus de développement..........................................................................54
3.2. Etapes de réalisation............................................................................................................55
3.3. Développement de l’interface graphique............................................................................58
4. Test de performance...................................................................................................................62
4.1. Test préliminaires................................................................................................................62
4.2. Test de conformité...............................................................................................................66
5. Conclusion...................................................................................................................................69
Page 50
1. Introduction
Après avoir achevé les deux premières phases du cycle de vie de notre application, qui
sont les phases de spécification et de conception, nous nous intéressons au cours de ce présent
chapitre à la phase de réalisation et mise en œuvre de notre travail. Cette phase est suivie
d’un test de performance dans le butd’évaluer notre produit final.
Pour cela, nous présentons, en premier lieu, l’environnement de travail de l’application, et

les outils de développement utilisés. En second lieu, nous présentons les étapes de réalisation
de notre projet. Enfin, nous décrirons la partie test de performance.
2. Environnement de travail de l’application
Le travail a été réalisé sur un environnement de Microsoft Windows XP et développé en

VB.net sous le Microsoft Visual Studio. Ce choix a été exigé par l’entreprise.
Figure 3.1 : Environnement de l’application
Comme le montre la figure 3.1, le développement de notre application sera fait sur une
plateforme.Net. Nous commençons alors par présenter la plateforme .Net et ses principales
composantes.
Page 51
2.1. Présentation de la plate-forme .NET

La plate-forme .NETa été crée par la société Microsoft, pour le développement d'applications
d'entreprises multi-niveaux[4]. Elle comporte deux composants principaux : un moteur
d'exécution virtuel appelé "Common Language Runtime" CLR et et la bibliothèque de
classes comme le montre la figure suivante.
Figure 3.2 : Architecture de la plate-forme .NET
Le CLR est une machine virtuelle spécifique à la plate-forme. NET de Microsoft. Elle
gère l’exécution des programmes écrits en langages .Net tels que VB.NET, C#, C++ et autres.
Elle fournit des servicesqui simplifient le processus de développement. Elle assure
l'interopérabilité entre les différents codes écrits en différents langages de
programmation .NET en les convertissant en un langage intermédiaire commun baptisé MSIL
(Microsoft IntermediateLanguage). Le CLRélimine un grand nombre de problèmes logiciels
courants relatifs aux mémoires tels que le manque de mémoire et les références mémoires
non valides. Ces problèmes sont résolus grâce à la gestion automatique de la disposition des
objets assurée par le CLR [4].
Page 52
La bibliothèque des classes .NET est une collection de types réutilisables qui s'intègrent
parfaitement au Common Language Runtime. Elle permet, avec le CLR, d’accélérer la
productivité du développeur en lui offrant la possibilité de tirer profits d’autres programmes
écrits par d’autres développeurs en langages différents.
La plate-forme.NET est destinée à être utilisée par la majorité des nouvelles applications
de Microsoft Windows.
2.2. Présentation du VisualStudio

Microsoft a également publié, dans le cadre de la stratégie de standardisation qu’elle a
adopté, un environnement de développement intégré (IDE), en grande partie pour le .NET qui
est le Microsoft Visual Studio.
Visual Studio est un ensemble complet d'outils de développement permettant de générer des
applications Web ASP.NET, des Services Web XML, des applications bureautiques et des
applications mobiles. Visual Basic, Visual C#et Visual C++ utilisent tous le même
environnement de développement intégré (IDE), qui permet le partage d'outils et facilite la
création de solutions à plusieurs langages. Par ailleurs, ces langages utilisent les
fonctionnalités de la plate-forme .NET , qui fournit un accès à des technologies clés
simplifiant le développement des applications[5].
Visual Studio a été entièrement remanié de manière à standardiser les méthodes de

développement à destination de ces deux environnements qui cohabitent de plus en plus
étroitement aujourd'hui :
- Les applications Windows.

- Les applications Internet.
Dans les deux cas, une application se compose de fenêtres nommées Forms. Pour les
applications Windows, il s'agit de WinForms tandis qu'il s'agit de WebForms pour les
applications dédiées au Web[6].
2.3. Applications Windows

Dans notre cas nous nous intéressons aux applications Windows. Ce sont des applications
bureautiques qui utilisent des fenêtres haut-niveau et des outils communs de développement
Page 53
d’interfaces (Common User Interface Controls) tels que les boutons, les pointeurs, les boîtes
de dialogues. Quelques exemples de ces outils dont présentés dans la figure suivante [7].
L’application WinForms fournit une surface de conception, où l'utilisateur dépose et

organise les outils afin de construire l’interface utilisateur. Chaque outil dispose d’une liste de
propriétés modifiables par le développeur qui permettent de personnaliser les IHM.
Surface de conception
Figure 3.3: Boîte à outils, surface de conception et liste des propriétés
Les applications Windows, sont aussi dotées d’un éditeur de codes sources qui aide le
développeur à écrire rapidement son code tout en évitant les erreurs. Il lui permet aussi de
créer des codes réutilisables et de bénéficier des fonctions prédéfinies dans le but de réduire
la quantité de travail à faire.
La figure suivante montre un exemple de code source écrit en Visual Basic.NET.
Page 54
Figure 3.4: Exemple de code que peut comporter un éditeur de code source
3. Implémentation
L’implémentation est la dernière étape avant de passer au test et validation du produit
final. Au cours de cette partie nous avons à définir la démarche de réalisation de notre
application en abordant les étapes de réalisation une par une. Nous allons aussi justifier le
choix technique des outils utilisés à chaque étape
3.1. Conduite de processus de développement

Notre application est composée essentiellement de quatre grandes parties qui sont :
– La base de données
– L’application de contrôle de modification des fichiers de test In-Situ
– L’application d’envoi d’emails aux utilisateurs
– L’interface homme machine
Le diagramme suivant montre ces différentes étapes dans l’ordre chronologique de

développement.
Page 55
Figure 3.5 : Conduite de processus de développement
3.2. Etapes de réalisation

Comme nous l’avons déjà montré les étapes principales de réalisation de notre projet sont
quatre. Nous allons les aborder une par une en respectant leur ordres chronologiques.
3.2.1. Développement de l’application de contrôle des modifications des

fichiers de test In-Situ
Cette application développée en VB.NET, est au cœur de notre projet. Elle permet à
utilisateur distant de choisir les fichiers de test dont il veut surveiller l’état de modifications.
Ce contrôle d’état de modifications est exclusif aux fichiers d’extension « .objet » et aux
fichiers de types « tesplan » et « testorder », jugés les plus importants lors de la phase de test
In-Situ, comme on l’a déjà précisé dans le premier chapitre.
Cette application peut contrôler les dates de dernière modification seulement, dans le cas des
fichiers « .objet », ou contrôler la date et le type de modification, dans le cas des fichiers de
type « testplan » ou « testorder ».
Le diagramme suivant donne une vue globale sur cette application.
Page 56
Figure 3.6: Organigramme simplifié de l’application
3.2.2. Développement de l’application d’envoi d’email

Dans le but d’alerter les utilisateurs en temps réel, suite aux modifications des fichiers de test,
nous avons choisi de leur envoyer des emails de notifications. Mais pour ne pas surcharger
leurs boîtes de réception nous avons fixé la cadence d’envoi d’email à 30 minutes, ce qui leur
permettra aussi d’agir rapidement en cas de modification non souhaitée.
Notre application développée en VB.NET, permet d’envoyer des emails pour des
destinataires dans et hors du domaine de l’entreprise via le serveur SMTP.
Associée à l’application de contrôle de modification, décrite précédemment, elle va nous

permettre de transférer les modifications apportées aux fichiers de test par émail aux
différents utilisateurs.
3.2.3. Création de la base de données

Cette partie s’est avérée primordiale pour satisfaire les besoins de notre application en termes
d’administration, de stockage et de gestion de données.
Nous allons commencer par choisir le Système de Gestion de Base de Données adéquat.
Page 57
3.2.3.1. Choix du SGBD

La décision du SGBD avec lequel notre base de données sera créée et gérée doit être doté de
fonctionnalités satisfaisantes pour notre application.
Il existe plusieurs SGBD tels que SQL Server, MySQL et Access. Pour pouvoir choisir parmi
cessystèmes, nous avons besoin d’une petite étude comparative illustrée dans le tableau 3.1.
SQL Server MySQL Access

- administration aisée - gestionnaire de base de -fournit une des solutions
données libre les plus simples et plus
- gère de très grandes flexibles sur le marché [n4]
bases de données - gère les très grandes - Assez performant en tant
bases de données (plus que que SGBD allié à un outil
Avantages
- configuration 50 millions de lignes) de développement intégré

client/serveur - Access est livréavec
- fonctionne sur de Microsoft Office
nombreuses plateformes Professionel [n4]
- Facile à utiliser grâce à de
nombreux assistants
- a été conçu pour
fonctionner sur un réseau
[n4]
-Monoplateforme -n’offre pas de support -Les performances chutent
Inconvénients
Microsoft windows complet pour les clés lorsque le nombre

étrangères d’utilisateurs simultanés
dépasse 20[n4]
- les performances chutent
lorsque la base dépasse
100000 lignes
Tableau 3.1 : Etude comparative entre quelques SGBD
Dans notre cas le volume des tables et le nombre des utilisateurs simultanés ne constituent
pas une priorité. Notre choix doit dépendre essentiellement de la disponibilité, de la
portabilité et de la faciliter de l’installation et de l’utilisation. Pour ces raisons nous avons
opté pour le SGBD Access.
3.2.3.2. Utilité
Le besoin de stoker des données (produits, utilisateurs, mot de passe …) d’une façon
structurée et la moins redondante possible, nous a amené à créer une base de données.
Cette base de données a permis aussi aux administrateurs et aux programmes de

consulter, de saisir ou de mettre à jour ces données, tout en s’assurant des droits d’accès qui
leur sont accordés.
Page 58
3.3. Développement de l’interface graphique

L’interface graphique est celle qui va assurer l’interconnexion entre les différentes
applications, la base de données et l’utilisateur. Elle va permettre aussi à ce dernier de gérer
l’application et la base de données en tant qu’administrateur. Cette interface doit répondre à
différents critères fonctionnels et d’ergonomie.
Notre Interface se compose de différentes fenêtres que nous allons décrire dans la suite.
3.3.1. Fenêtre d’authentification

Lafenêtre illustrée par la figure 3.7, est à la fois d’accueil et d’authentification.
Figure 3.7 : Fenêtre d’authentification utilisateur
Elle comporte :
- 1 : champ de saisie d’identifiant

- 2 : champ de saisie de mot de passe
- 3 : bouton de validation qui permet, si l’identifiant et le mot de passe sont correctes,
d’afficher la fenêtre suivante
- 4 : bouton qui permet de vider la zone 1 et 2 si l’identifiant et/ou le mot de passe sont
incorrectes ce qui permet à l’utilisateur d’essayer de nouveau
- 5 : bouton qui permet à l’utilisateur, en cas d’oubli de mot de passe, d’accéder à une
fenêtre conçue spécialement pour lui permettre de changer son mot de passe
Page 59
- 6 : bouton qui permet de fermer l’application.
Au cours de la phase d’authentification, l’application se connecte à la base de données

pour vérifier si l’identifiant et le mot de passe saisis existent dans la base.
Un utilisateur non identifié ne peut pas accéder à l’application. Donc dans le cas où
l’utilisateur oubli son mot de passe, le bouton numéro 5, que nous venons de décrire va lui
permettre à accéder à une fenêtre où il peut saisir un nouveau mot de passe.
3.3.2. Fenêtre de saisi de nouveau mot de passe

A l’appui sur le bouton « mot de passe oublié » de la fenêtre d’authentification, la fenêtre
illustrée dans la figure 3.8 s’affiche.
Figure 3.8: Fenêtre de saisi de nouveau mot de passe
Elle comporte :
- 1 : champ de saisie de l’identifiant

- 2 : champ de saisie de nouveau mot de passe
- 3 : bouton de validation qui permet de stocker le nouveau mot de passe
- 4 : bouton d’annulation de l’opération
- 5 : bouton qui permet de retourner à la fenêtre précédente
- 6 : bouton qui permet de quitter la fenêtre
Page 60
3.3.3. Fenêtre de choix

Une fois l’utilisateur identifié, l’application charge la fenêtre présentée dans la figure 3.9.
Figure 3.9: FenêtreIntermédiaire
Cette fenêtre comporte :
- 1 : bouton qui permet d’accéder à la liste des produits

- 2 : bouton qui permet d’accéder à la fenêtre de mise à jour de la base de données
- 3 : bouton qui permet de retourner à la page précédente
- 4 : bouton qui permet de quitter l’application
3.3.4. Fenêtre choix des produits

A l’appui sur le bouton « choix des produits » de la fenêtre précédente, la fenêtre présentée
dans la figure suivante s’affiche.
Page 61
Figure 3.10 : Choix des produits
Cette fenêtre est composée des éléments suivants :
- 1 : bouton d’actualisation de la liste des produits en consultant la base de données

- 2 : zone de sélection des produits
- 4 : bouton qui permet d’accéder à la base de données
- 5 : bouton qui permet de quitter la fenêtre
- 6 : bouton qui permet de valider les choix de l’utilisateur
3.3.5. Fenêtre de mise à jour de la base de données

La fenêtre de mise à jour de la base de données s’affiche en appuyant soit sur « Mettre à
jour la BDD » de l’une des deux fenêtres précédentes.
Figure 3.11: Fenêtre de mise à jour de la BDD
Cette fenêtre est composée de :
- 1 : bouton qui permet d’activer la liste des tables qui se trouvent à la zone 2
Page 62
- 2 : zone de sélection des tables à modifier

- 4 : bouton qui permet d’ajouter un nouvel utilisateur
- 5 : champs de saisie des identifiants
- 6 : bouton qui permet d’ajouter un nouveau produit
- 7 : champ de saisie du nouveau produit
- 8 : bouton qui permet d’ajouter un nouveau testeur
- 9 : champ de saisie du nouveau testeur
- 10 : bouton qui permet de quitter l’application
4. Test de performance
Dans cette partie, nous allons représenter les tests que nous avons effectué pour valider
notre travail et s'assurer que notre application répond bien aux spécifications préétablies.
Et comme nous l’avons déjà décrit dans la figure 3.5 notre projet se compose d’une base
de données, d’une interface graphique, d’une application d’envoi d’emails et d’une
application de contrôle de modifications. Donc nous étions amenés à faire des tests
préliminaires de chaque application, indépendamment de l’autre, avant de passer au test de
l’application finale.
4.1. Test préliminaires

Les tests préliminaires de chaque application portent sur l’élimination des bugs et
l’optimisation des codes dans la mesure de possible dans le but de réduire le temps de
traitement du programme et obtenir un niveau de rapidité satisfaisant.
4.1.1. Test de performance de l’application de contrôle des modifications des

fichiers de test.
Comme toute application informatique, le développement de notre application a été fait
autour d’un noyau de fonctionnalité simple, qui dans notre cas était la lecture du contenu d’un
fichier texte de petite taille, pour arriver à la fin au contrôle des modifications des fichiers de
test In-Situ.
Pour la lecture et le contrôle des modifications des fichiers, nous avons utilisé comme
première méthode, la lecture ligne par ligne de ces fichiers en les comparant au fur et à
mesure avec un autre fichier de référence.
Page 63
Dans la figure 3.12 nous présentons un extrait du code source de notre application basée
sur la méthode de lecture ligne par ligne.
Figure 3.12: Méthode de lecture
Cette méthode fonctionne convenablement avec les fichiers de petites tailles.
Dans la figure 3.14 nous présentons un petit exemple de comparaison faite sur deux
fichiers. Le premier fichier a été déclaré dans le code source que nous venons de présenter
dans la figure 3.12 sous le nom de « test.txt ».
Pour le deuxième fichier dont le nom est « test-ref.txt », nous avons déclaré son chemin
d’accès à l’exécution de l’application dans la figure 3.14.
Le texte contenu dans le fichier « test-ref.txt » est celui affiché dans la figure suivante.
Figure 3.13 : Contenu du fichier « test-ref »
A son tour, le fichier « test.txt » contient le même texte à une différence près car nous avons
juste changé l’année 2010 par 2011.
Page 64
Figure 3.14 : Résultat de contrôle de modifications avec la méthode lecture ligne par ligne
La figure précédente montre bien que l’application détecte la modification apportée au

deuxième fichier. Elle montre le contenu des lignes où il ya eu des changements ainsi que
leurs numéros.
4.1.2. Problèmes de traitement des fichiers volumineux

Lors du traitement des fichiers de type « testplan » et « testorder » avec la méthode que
nous venons de décrire, nous avons rencontré des problèmes en termes de temps de
traitement et de réponse vu le volume très important de ces fichiers qui pouvaient atteindre
plus que 10 000 lignes par fichier.
Ces problèmes causaient le plus souvent le plantage de l’application.
4.1.3. Solution adoptée

Pour résoudre ce problème, nous avons crée une nouvelle fonction qui repose sur la méthode
de lecture de fichier en entier. Cette fonction ouvre le fichier, le lit en entier et le stocke dans
une variable locale de type chaine de caractères, ensuite elle le ferme.
Tout le traitement qui suit est fait sur la variable locale. La lecture de cette variable se fait
d’une façon continue ce qui garantie un temps de réponse très court. A titre d’exemple le
traitement d’un fichier de 9589 lignes prend se déroule en une seconde. Ce qui était
impossible avec la méthode de lecture ligne par ligne.
Page 65
Figure 3.15 : Méthode de lecture de fichier en entier
La figure suivante montre les modifications que nous avons apporté au fichier « testplan »
au niveau des lignes 3, 536, 2921 et 9588.
Figure 3.16 : Modifications du fichier « testplan »
Page 66
Après avoir modifié le fichier « testplan » qui comporte 9589 lignes, nous passons au
contrôle de modification avec la méthode de lecture en entier de ce fichier.
Figure 3.17 :Résultat de contrôle de modifications avec la méthode de fichier en entier
4.2. Test de conformité

La procédure de test inclut le test des principales fonctionnalités de l’application. A ce
titre plusieurs scénarios peuvent être envisagés.
Comme nous l’avons déjà montré dans le précédent chapitre, les scénarios diffèrent d’un
utilisateur à un autre, suivant ses droits d’accès.
Pour le test de conformité, nous allons nous limiter au scénario nominal, qui présente le
cas d’utilisation le plus fréquent de notre application.
4.2.1. Scénarionominal
Lors de ce scénario, l’utilisateur se connecte à l’application pour choisir un produit de la liste
des produits disponibles dans la base de données. Il exécute l’application et attend un mail de
notification s’il ya des modifications apportées aux fichiers de test associés au produit choisi.
Les figures suivantes montrent les étapes par les quelles l’utilisateur doit passer.
Page 67
Figure 3.18 : Fenêtre d’authentification
Après l’authentification, le système affiche la fenêtre présente dans la figure 3.19
Figure 3.19: Fenêtre intermédiaire
A chaque identification, l’application prend en considération les droits d’accès de

l’utilisateur. Dans notre cas l’utilisateur identifié n’est pas un administrateur, donc il ne
possède pas le droit d’accès à la base de données ce qui explique le désactivation du bouton
« Mettre à jour la BDD ».
En appuyant sur le bouton « choisir les produits » de la fenêtre précédente, le système

affiche la liste des produits illustrée dans la figure 3.20.
Page 68
Figure 3.20 : Choix des produits
La liste des produits est actualisée à chaque ouverture de la fenêtre, en se référant à la

table de produits de la base de données, ce qui permet d’activer ou désactiver les produits.
Dans notre cas les produits m91 et m91v et m89p sont désactivés.
L’utilisateur limite son choix au produit m78.
La figure suivante montre un exemple de mail de notification qui précise l’état de

modification des fichiers « 1%z2100.o » et « testplan » associés au produit m78.
Le mail ne précise que le chemin d’accès et la date de modification du fichier objet. Mais
il précise en plus la ligne modifiée dans le cas de fichier « testplan » comme le montre la
figure 3.21.
Figure 3.21 : Exemple de mail de notification
Page 69
5. Conclusion
Dans ce chapitre nous avons commencé par la présentation de l'environnement logiciel

utilisés. Par la suite, nous avons développé une description plus concrète desdifférentes
phases de l'application et enfn, nous avons présenté les test de performance effectués afin
d'évaluer notre projet.
Dans notre cas nous disposons d’une application informatique capable de :
- Alerter les utilisateurs par emails contenant l’emplacement et les dates de
modifications pour les fichiers de type objet ;
- Alerter les utilisateurs par email contenant l’emplacement, les dates de modifications
ainsi que les lignes modifiés dans le cas des fichiers de type « testplan » et
« testorder ».
- Répondre à l’architecture logicielle client serveur.
Page 70
Conclusion Générale
Conclusion Générale
Dans une démarche de réduction des coûts et de temps induits par les non-conformités
des produits de l’activité décodeur de TV de SAGEMCOM, et dans l’objectif d’assurer la
qualité de test de ces produits, nous avons développé une application de suivi et de
surveillance des programmes de test In-Situ des cartes électroniques.
La mise en œuvre de ce système s’intègre dans le cadre de développement d’un produit

informatique ayant un cycle de vie bien déterminé, à savoir la phase de spécification, la phase
de conception et la phase de réalisation.
Les besoins exprimés par les spécifications élaborées à la base des besoins des
utilisateurs, ont été modélisés par des cas et des scénarios d’utilisations explicitant les
interactions des différents acteurs avec le système.
L’apport de cette modélisation est qu’elle nous a permis de saisir, plus aisément, les
différents modules de l’application lors de la phase de conception.
Une fois répertoriés, ces modules ont été codés puis intégrés ensemble pour être testés
dans l’environnement In-Situ.
Les tests de performance visent la validité du produit final. Dans notre cas, l’application
de suivi des programmes de test In-Situ répond bien aux spécifications préétablies et permet
un gain en temps et en coûts considérables. A titre d’exemple les problèmes de non-
conformité détectés en septembre 2011 qui ont coûté une perte qui s’élève à 15400 euros et
un arrêt de production de 15 jours pour les trois équipes CMS, suite aux modifications non-
souhaitées des programmes de test In-Situ.
Page 71
Références
Références
Ouvrages
[2] Agilent Technologies, « Agilent Medalist 3070. Documentation », Mars 2006.
[3] Pierre-Alain Muller, Nathalie Gaertner,Modelisation Objet avec UML, Editions

Eyrolles, 2001.
Adresses Web
[1] www.sagemcom.com consulte le 7/12/2011
[4] http://msdn.microsoft.com/fr-fr/library/zw4w595w(v=VS.100).aspx consulté

le 12/12/2012
[5]http://msdn.microsoft.com/fr-fr/library/fx6bk1f4.aspx consulté le 12/12/2011
[6]http://www.labo-microsoft.org/articles/dev/vsnet_intro consulté le
12/12/2011
[7] http://tripous-net.com/CSharp_WindowsForms.html consulté le 12/12/2011
[8] http://www.galleryimage.com.au/Why-Access-Database.html consulté le

12/12/2011
Page 72
Annexes
Annexes
Page 73

Rapport 1

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport 1

Transféré par

Droits d'auteur :

Formats disponibles

Table des Matières

Table des Matières

3.3. Développement de l’interface graphique............................................................................58

Liste des Figures

Figure 3.13 : Contenu du fichier « test-ref »………………………………………………………..63

Liste des Tableaux

Tableau 3.1 :Etude comparative entre quelques SGBD…………………………………………....57

Liste des Abréviations

2TUP : 2 Tracks Unified Process

ADT : Activité Decodeur TV

ATR : Activité Terminaux Résidentiels

BAV : Banc Audio Video

BDD : Base de Donnés

BFE : Banc Front End

CLR : Common Language Runtime

CMS :Composant Monté en Surface

CUF : Chef Unité de Fabrication

IDE :Integrated Development Environment

IHM : Interface Homme Machine

IPTV :Internet Protocol Telivision

ISO :International Standards Organization.

LAN : Local Area Network

LED :Light Emetting Diode

MDP : Mot de Passe

OHSAS : Occupational Health & Safety Advisory Services

RUP : Rational Unified Process

SADT : Systems Analysis and Design Technique

SARL : Société à Responsabilité Limitée

SAS : Société Anonyme Simplifiée

SGBD : Système de Gestion de Base de Données

SMTP :Simple Mail Transfer Protocol

STB :Set Top Box

TNT :Turner Network Television

UML :Unified Modeling Language

VCL : Vector Control Language

La maîtrise du système de production en termes d’utilisation et de coût reste l’atout de toute

La maîtrise des technologies de Test In-Situ et la réduction de nombre de réclamations

Figure1.1 : Organisation du Groupe SAGEMCOM septembre 2011

débit, de la convergence et de l’Energie. La figure suivante illustre la répartition des activités

Figure 1.3 : Principales Filiales en dehors de l’Europe de l’Ouest

2.2. Présentation de SAGEMCOM Tunisie

2.2.2. Organisation générale

2.2.4. Agréments Qualité

2.2.5. Domaines d’activités et principaux clients

- Cartes électroniques pour applications électroménager (Fagor, Bosch,

Figure 1.6 : Principaux clients de SAGEMCOM Tunisie

3. Atelier décodeur et fonction Test

Figure 1.7 : Ligne de production décodeur

3.2. Fonction Test

3.2.1. Modélisation de la fonction Test

Cartes non Cartes testées

Figure1.8 : Fonction Test Niveau A-0

La fonction est décrite en détail par la figure 1.9.

Figure1. 9 : Fonction Test Niveau A0

Le service test ADT de SAGEMCOM Tunisie est composé de deux pôles :

- Pôle Test In-Situ (TI)

3.2.2. Test In-Situ

- Tester les circuits ouverts et les courts-circuits ;

4. Approche matérielle du test In-Situ

L’outil de test in-situ se compose de deux parties principales :

Figure 1.10 : Interface du Test In-Situ

4.2. Testeur In-Situ

Figure1.11 :Testeur Agilent 3070

Figure 1.12 : Schéma fonctionnel pour le test des composants analogiques