LE TITRE D’INGENIEUR IPLOME PAR L’ETAT (IDPE) ENtur.denis.free.fr/images/Memoire_Denis_Tur.pdf · 2010-09-29 · page 2 denis tur outil de gestion de la maintenance twim - idpe

INSA TOULOUSE

MEMOIRE

PRESENTE EN VUE D’OBTENIR

LE TITRE D’INGENIEUR DIPLOME PAR L’ETAT (IDPE)

EN

AUTOMATIQUE ET INFORMATIQUE INDUSTRIELLE

PAR

DENIS TUR

OUTIL DE GESTION DE LA MAINTENANCE VIA

L’INTRANET DE FREESCALE

LE TLS-TWIM

Soutenu le 22 septembre 2009

Présidente du Jury :

Madame Colette MERCE, Directrice DGEI INSA Toulouse

Membres :

Monsieur Michel CASTAN, Responsable de la Formation Continue, spécialité Informatique Monsieur Christian GANIBAL, Ingénieur CNRS, LAAS, Ingénieur de recherche en Electronique

Monsieur Vincent MAHOUT, Enseignant DGEI, spécialité Automatique Informatique Industrielle Monsieur Pierre PINEL, Enseignant DGEI, spécialité Informatique

Monsieur Jean-Louis VIDAL, Ingénieur DPE, Responsable du Service Informatique de la Mairie de Toulouse

Page 2 Denis TUR

OUTIL DE GESTION DE LA MAINTENANCE TWIM - IDPE AUTOMATISME ET INFORMATIQUE INDUSTRIELLE INSA TOULOUSE 2009

INSA TOULOUSE

MEMOIRE

PRESENTE EN VUE D’OBTENIR

LE TITRE D’INGENIEUR DIPLOME PAR L’ETAT (IDPE)

EN

AUTOMATIQUE ET INFORMATIQUE INDUSTRIELLE

PAR

DENIS TUR

OUTIL DE GESTION DE LA MAINTENANCE VIA

L’INTRANET DE FREESCALE

LE TLS-TWIM

Soutenu le 22 septembre 2009

Présidente du Jury :

Madame Colette MERCE, Directrice DGEI INSA Toulouse

Membres :

Monsieur Michel CASTAN, Responsable de la Formation Continue, spécialité Informatique Monsieur Christian GANIBAL, Ingénieur CNRS, LAAS, Ingénieur de recherche en Electronique

Monsieur Vincent MAHOUT, Enseignant DGEI, spécialité Automatique Informatique Industrielle Monsieur Pierre PINEL, Enseignant DGEI, spécialité Informatique

Monsieur Jean-Louis VIDAL, Ingénieur DPE, Responsable du Service Informatique de la Mairie de Toulouse

Page 3 Denis TUR


Remerciements

Avant de commencer la présentation du projet, je tiens à exprimer mes sincères

remerciements à Monsieur Philippe MAZILIER, responsable du service de la maintenance à Freescale Toulouse, pour m’avoir fait confiance et pour avoir su orienter mes travaux.

Je souhaite aussi remercier Monsieur Vincent MAHOUT, Enseignant DGEI, spécialité

Automatique Informatique Industrielle, pour ses relectures et corrections de ce mémoire. Je tiens aussi à exprimer ma reconnaissance et mes remerciements à Monsieur Philippe

SIMOES, Ingénieur informaticien et responsable du groupe maintenance en weekend, pour son support, ses conseils et pour notre étroite collaboration tout au long du projet.

Je tiens à remercier également Monsieur Simon TRESSIERES et Monsieur Fabrice JACQUEMIN,

informaticiens au service support informatique, pour l’aide qu’ils m’ont apportée pour la mise en production du site FSL-TWIM sur le serveur de Freescale.

Je suis également très reconnaissant envers les responsables des groupes de maintenance,

Messieurs Patrice LORENDEAUX, Michel CASON, Francis DUPRE, Philippe MANGEOLE, Bernard DOUILHAC, Pierre ANDRIEU, Philippe FLAMENT et Eric BRU, pour l’aide au déploiement des outils dans leurs unités respectives.

Je tiens de même à remercier Mademoiselle Frédérique GUILLON, Ingénieur procédé en

implantation ionique à Freescale, pour ses relectures et corrections de ce mémoire. Enfin je veux également saluer la patience, la compréhension et le soutien dont a fait preuve

mon épouse, Sandrine, lors de ces deux dernières années. Je tiens aussi à remercier mes enfants, Héléana et Florian, qui m’ont souvent demandé pourquoi je travaillais au lieu de jouer avec eux.

Page 4 Denis TUR


Résumé Ce mémoire décrit la mise en place d’un système de gestion de la maintenance via l’intranet de

l’usine Freescale à Toulouse : le TLS-TWIM. Après la constitution d’une équipe projet, j’ai élaboré un cahier des charges avec les futurs

utilisateurs. Une fois les objectifs clairement définis j’ai découpé les différents modules du système en diagrammes fonctionnels. Ce découpage m’a permis d’élaborer un planning prévisionnel pour ce projet.

Les trois choix possibles pour le développement de cette interface étaient les suivants : la solution interne Freescale, l’achat de logiciel externe ou le langage PHP. Ce dernier a été retenu sur des critères de coût, d’évolution future et d’entretien.

En ce qui concerne le stockage des informations j’ai utilisé la méthode Merise pour la conception des structures des bases de données. 52 tables ont été nécessaires pour le système TLS-TWIM.

Pour le développement des codes source je me suis appuyé sur la culture du Lean Manufacturing présente dans l’entreprise. Les notions de 5S, d’amélioration continue et l’outil Smed ont permis de structurer, de standardiser et d’optimiser le codage.

Le module, planification dynamique des préventives compteurs est détaillé en fin de mémoire. Cet outil permet de planifier dynamiquement les interventions de maintenance préventive en fonction des divers compteurs présents sur les équipements de production.

L’interface TLS-TWIM est en fonctionnement depuis juin 2009 et les utilisateurs en apprécient la convivialité, la rapidité et l’accessibilité. Les temps de recherche d’informations et d’analyse de pannes ont diminués, soit 50% à 60% de gain. Ce système est le point d’entrée unique de toutes les équipes de maintenance et centralise les informations nécessaires pour les équipes supports de la production de l’usine de Toulouse.

Mots clé : Standardisation, intranet, GMAO, PHP, convivialité, rapidité, accessibilité, LEAN

MANUFACTURING.

Summary This report describes the development and installation of maintenance software through the

Toulouse Freescale network: the TLS-TWIM. After the constitution of team project, I elaborated the requirements with the future users. Once the

objectives clearly defined, the various modules of the system were broken down into to build a functional diagram and estimated planning for this project.

The three possible choices for the development of this interface were the following: the Freescale internal solution, external software or the PHP language. This last one was chosen on criteria of cost, evolution and maintenance.

Concerning the data storage the Merise method was used to build the structural design of the databases. 52 tables were necessary for system TLS-TWIM.

The development of source lines of code was based on Lean Manufacturing culture deployed in the company. Some tools like 5S continuous improvement or Smed were used to improve the structure, to standardize and to optimize the code.

A specific module is described at the end of the report. This tool allows the planning of preventive maintenance according to the various meters retrieved from production equipments.

TLS-TWIM interface is under operation since June 2009. People using the software particularly appreciate user-friendliness, speed and accessibility. The search and breakdowns analysis times have decreased, from 50% to 60% improvement. All data and inputs were now only gathered through this system. All sustaining teams were used this interface.

Keywords: Standardization, Intranet, GMAO, PHP, friendly interface, response time, accessibility, LEAN MANUFACTURING.

Page 5 Denis TUR


Je me suis souvent repenti d'avoir parlé, mais jamais de m'être tu.

(Philippe de Commines)

Page 6 Denis TUR


Sommaire Remerciements ......................................................................................................................... 3Résumé .................................................................................. Erreur ! Signet non défini.Summary ............................................................................... Erreur ! Signet non défini.Sommaire ..................................................................................................................................... 6Introduction ................................................................................................................................ 7Abréviations ............................................................................................................................... 8Listes des Figures ..................................................................................................................... 9Listes des Tableaux ................................................................................................................. 9Chapitre I : Présentation générale du projet FSL-TWIM ...................................... 10

I.1- Le cahier des charges ....................................................................................................................................................................... 10 La problématique ....................................................................................................................................................................... 10 Le plan de travail ........................................................................................................................................................................ 11 Les ressources nécessaires .................................................................................................................................................... 13

I.2- Déroulement du projet ................................................................................................................................................................... 13 Etat des lieux ................................................................................................................................................................................ 13 La collecte des besoins clients .............................................................................................................................................. 14 Recherche des solutions de développement .................................................................................................................. 20 Architecture du système FLS-TWIM ................................................................................................................................. 22 Etude du stockage des données ........................................................................................................................................... 22 Estimation des ressources nécessaires ............................................................................................................................ 28 Le codage ....................................................................................................................................................................................... 29 Cycle de vie d’un projet ........................................................................................................................................................... 34 Tests des programmes ............................................................................................................................................................. 35 Validation des modules avec les clients ........................................................................................................................... 35 Livraison finale ............................................................................................................................................................................ 36 Maintenance ................................................................................................................................................................................. 36

I.3- Conclusion chapitre I ....................................................................................................................................................................... 36Chapitre II : Planification Dynamique des Préventives Compteurs (PDPC) 37

II.1- Introduction ........................................................................................................................................................................................ 37II.2- Présentation de Machine Manager ........................................................................................................................................... 37II.3- Présentation de PROMIS ............................................................................................................................................................... 38II.4- Acquisition des relevés compteurs équipements .............................................................................................................. 39 Les compteurs TWIM ................................................................................................................................................................ 40

II.5- La planification dynamique des interventions préventives .......................................................................................... 41II.6- Conclusion chapitre II .................................................................................................................................................................... 42

Conclusion ................................................................................................................................ 43Les possibilités d’évolution ............................................................................................... 44Bilan personnel ...................................................................................................................... 45Bibliographie/Web graphie .............................................................................................. 46

Documents de référence ......................................................................................................................................................... 46 Liens WEB ..................................................................................................................................................................................... 46

Annexes ..................................................................................................................................... 47Annexe I : Planning prévisionnel ........................................................................................................................................................ 47Annexe II : Les organigrammes de TLS-FAB .................................................................................................................................. 48 Organigramme de Freescale Toulouse FAB ................................................................................................................... 48 Organigramme de la maintenance Toulouse FAB ....................................................................................................... 48

Page 7 Denis TUR


Introduction

La transparence, la réactivité et la communication sont les maîtres mots d’une équipe, qu’elle soit composée de techniciens de maintenance, d’ingénieurs procédé ou d’opérateurs de production. Les clients et les auditeurs externes sont très attentifs à ces différents termes, que l’on peut définir d’ailleurs comme mots-clés, tant l’importance qu’ils apportent à la qualité du produit final est primordiale.

C’est d’autant plus vrai aujourd’hui avec la situation économique mondiale sur le marché de

l’automobile. En effet Freescale, leader sur ce secteur, subit cette crise. Nous devons par notre savoir faire et notre expérience surmonter dans les meilleures conditions cette étape difficile.

En tenant compte de cette situation, ce mémoire décrit le développement et la mise en place

des outils informatiques pour répondre aux besoins des équipes supports de la production (maintenance et procédé).

Cette évolution informatique permet de mettre sous chaque mot clé, présenté en début de

cette introduction, une multitude de sujets et de références. C’est une avancée notoire pour Freescale Toulouse.

Ce mémoire est composé de deux parties. Le premier chapitre aborde le projet FSL-TWIM dans sa globalité. Ce chapitre reste général et

ne s'attache pas à décrire, par souci de concision, les nombreux aspects techniques. Le deuxième chapitre traite d’une sous-partie du projet : Planification Dynamique des

Préventives Compteurs. En effet, ce module tient une place importante et nécessite des explications plus détaillées.

En fin de mémoire, vous trouverez la conclusion et le bilan personnel de ce projet.

Page 8 Denis TUR


Abréviations

Acronyme Désignation 5S Méthode d’origine japonaise qui permet de trier, mettre en ordre,

nettoyer, standardiser, et de suivre tous lieux, travaux, etc. BIA Business Impact Assement = Document interne pour connaître

l’importance d’un système ou d’un logiciel sur les clients. CAB Change Access Board (système gérant les changements à Freescale)

COCOMO Méthode pour quantifier les ressources sur un projet informatique (acronyme de l'anglais COnstructive COst Model)

Console VT220 Emulateur de terminal utilisé pour PROMIS DRP Disaster Recovery Plan : document interne pour réparer un système ou

un logiciel. Equipment Engineering

Ingénieur équipement, responsable d’une famille d’équipement.

GMAO Outil pour la gestion de la maintenance assistée par ordinateur IT SUPPORT Service support pour l’informatique de l’usine Freescale

KARDEX Endroit de stockage des pièces de rechanges pour la maintenance LEAN

MANUFACTURING Philosophie qui propose d’utiliser les outils comme le 5S, le SMED ou les groupes « KAIZENS » pour l’amélioration continue des procédés.

MM Machine Manager (software utilisé pour communiquer avec les équipements)

PDPC Planification Dynamique des Préventives Compteurs PM Préventive Maintenance

PROMIS Système de gestion centralisé de la production SERVEUR Système informatique destiné à fournir des services à des utilisateurs

connectés et, par extension, organisme qui exploite un tel système. SMED “Single Minute Exchange of Die” permet le changement d’un outil en

moins de 10 minutes TLS-FAB Abréviation interne de l’usine de Toulouse

TWIM Toulouse Web Interface Maintenance

NB : Quelques abréviations font parties du langage interne à Freescale Toulouse

http://www.dicofr.com/cgi-bin/n.pl/dicofr/definition/20010101002821�

http://www.dicofr.com/cgi-bin/n.pl/dicofr/definition/20010101001756�

Page 9 Denis TUR


Listes des Figures FIGURE 1 : EXTRAIT DU PLANNING PRÉVISIONNEL DU PROJET FSL-TWIM .............................................................................................. 12FIGURE 2 : DIAGRAMME FONCTIONNEL GLOBAL DU PROJET FSL-TWIM .................................................................................................. 15FIGURE 3 : DIAGRAMME FONCTIONNEL POUR LE CAHIER DE CONSIGNES .................................................................................................... 16FIGURE 4 : DIAGRAMME FONCTIONNEL POUR LA PLANIFICATION DES MAINTENANCES PRÉVENTIVES SUR LES ÉQUIPEMENTS ........ 17FIGURE 5 : DIAGRAMME FONCTIONNEL POUR LE STOCK DES PIÈCES (KARDEX) ..................................................................................... 18FIGURE 6 : DIAGRAMME FONCTIONNEL DE LA DOCUMENTATION TECHNIQUE ........................................................................................... 18FIGURE 7 : DIAGRAMME FONCTIONNEL DE L’OUTIL D’ANALYSE DE LA DISPONIBILITÉ DES ÉQUIPEMENTS ........................................... 19FIGURE 8 : DIAGRAMME FONCTIONNEL DES CONFIGURATIONS ÉQUIPEMENTS .......................................................................................... 19FIGURE 9 : DIAGRAMME DÉCISIONNEL DES SOLUTIONS TECHNIQUES .......................................................................................................... 21FIGURE 10 : ARCHITECTURE DU SYSTÈME FSL-TWIM ................................................................................................................................ 22FIGURE 11 : EXEMPLE D’ENTITÉS DANS LES BASES DE DONNÉES MYSQL ................................................................................................. 23FIGURE 12 : EXEMPLE D’ATTRIBUTS DANS LES ENTITÉS DES BASES DE DONNÉES MYSQL .................................................................... 24FIGURE 13 : EXEMPLE DE RELATION OU D’ASSOCIATION ENTRE ENTITÉS DANS LA BASE MYSQL ........................................................ 24FIGURE 14 : EXEMPLE DE CARDINALITÉ DANS DES RELATIONS D’UNE BASE MYSQL .............................................................................. 25FIGURE 15 : EXEMPLE DE CLEF DANS UNE ENTITÉ ......................................................................................................................................... 25FIGURE 16 : EXEMPLE DE MCD, MODÈLE CONCEPTUEL DE DONNÉES, POUR L’OUTIL DE GESTION DES MAINTENANCES

PRÉVENTIVES .............................................................................................................................................................................................. 26FIGURE 17 : EXEMPLE DE STRUCTURE DE TABLE DANS LES BASES MYSQL .............................................................................................. 27FIGURE 18 : ARBORESCENCE DES CODES SOURCE SUR LE SERVEUR DE FSL-TWIM ................................................................................ 30FIGURE 19 : EXEMPLE DE CODE SOURCE .......................................................................................................................................................... 32FIGURE 20 : EXTRAIT DE WIKIPÉDIA SUR LE FONCTIONNEMENT DU PHP ................................................................................................ 33FIGURE 21 : CYCLE DE VIE EN V ......................................................................................................................................................................... 34FIGURE 22 : SYNOPTIQUE DU FONCTIONNEMENT DE MACHINE MANAGER .............................................................................................. 38FIGURE 23 : SYNOPTIQUE DU FONCTIONNEMENT DE PROMIS-MACHINE MANAGER-EQUIPEMENTS. ................................................ 38FIGURE 24 : SYNOPTIQUE DE L’ACQUISITION DES RELEVÉS COMPTEURS .................................................................................................... 40FIGURE 25 : EXEMPLE DE CALCUL D’UNE DATE D’INTERVENTION DE MAINTENANCE PRÉVENTIVE AVEC DES COMPTEURS. .............. 41FIGURE 26 : EXTRAIT DU PLANNING DE FSL-TWIM .................................................................................................................................... 42

Listes des Tableaux TABLEAU 1 : CRITÈRES DE SÉLECTION DES SOLUTIONS DE DÉVELOPPEMENT ........................................................................................... 21TABLEAU 2 : MÉTHODE COCOMO, EFFORT ET TEMPS DE DÉVELOPPEMENT ........................................................................................... 28TABLEAU 3 : BESOIN EN HOMMES ET DURÉE DES PHASES DANS LA MÉTHODE COCOMO ...................................................................... 28TABLEAU 4 : MÉTHODE COCOMO, POURCENTAGE D’EFFORT ..................................................................................................................... 29TABLEAU 5 : MÉTHODE COCOMO, POURCENTAGE DE TEMPS DU DÉVELOPPEMENT .............................................................................. 29TABLEAU 6 : EXEMPLE DE TESTS POUR LE MODULE GESTION DES PRÉVENTIVES ..................................................................................... 35

Page 10 Denis TUR


Chapitre I : Présentation générale du projet FSL-TWIM

Le FSL-TWIM (Freescale Toulouse Web Interface Maintenance) est l’outil de GMAO incontournable sur le site de Toulouse. Son utilisation permet de centraliser les données pour la maintenance dans un environnement convivial et avec une grande accessibilité. Ce chapitre décrit la méthodologie et le déroulement de ce projet.

I.1- Le cahier des charges

La problématique

Le sujet retenu

Nous avons, depuis début 2007, un premier module fonctionnel « Cahier de Consignes

Informatiques ». La nécessité de cette partie, testée et validée par les différents clients du groupe maintenance, ne faisait plus aucun doute. Ce module fonctionnait sur un ordinateur transformé en serveur local.

Dans le but d’améliorer cet outil et de créer de nouvelles fonctionnalités, une réunion de travail a permis de mettre à jour deux besoins supplémentaires :

La nécessité de mettre en place un serveur dédié et soutenu par le service IT (service

informatique) L’ajout d’outils complémentaires répondant aux besoins des clients :

- Gérer les interventions préventives - Afficher les pièces du stock - Centraliser les documentations techniques - Connaître la disponibilité des machines - Stocker les configurations des équipements

La création du site FSL-TWIM prenait alors réellement forme.

Enjeux

Les enjeux de ce projet peuvent se décomposer selon quatre axes : technique, économique, humain et organisationnel. Les enjeux humains : Ce projet est avant tout un projet humain. En effet, avant d’être un outil de gestion de la maintenance via l’intranet de Freescale, c’est une aventure humaine jalonnée de rencontres et d’expériences. Tous les acteurs de la maintenance ont participé à cette réalisation. Cet apport inestimable donne à ce projet une dimension humaine, de plus il correspond à une véritable réalité industrielle. Les enjeux techniques : Comment faire pour réaliser un outil de gestion de la maintenance ? Quel langage informatique choisir ? Comment gérer le serveur ? Quelles bases de données utiliser et comment les organiser ? Ce mémoire présente tous ces aspects techniques.

Page 11 Denis TUR


Les enjeux économiques : Ce projet doit permettre d’améliorer le travail quotidien des techniciens et ingénieurs. Il doit réduire considérablement les temps de recherche dans le stock de l’usine. Il doit faciliter les analyses de pannes machines et doit centraliser les documentations et les interventions de maintenance préventives. L’amélioration de ces outils s’inscrit donc dans une réduction des coûts. Les enjeux organisationnels : L’utilisation de FSL-TWIM ne se limite pas à un service au profit de quelques personnes, il touche des secteurs très différents, de la maintenance, de la production, de l’engineering ou du service « device ». L’aspect formation et management doit être challengé pour avoir une utilisation optimale des différents modules du programme.

Objectifs visés

Plusieurs objectifs se dégagent de ce projet. Le plus important est la centralisation de toutes les informations nécessaires aux équipes support, qu’elles soient de maintenance, du « process engineering » ou du support « device ». (Voir en annexe IV l’organigramme des groupes supports)

Le deuxième objectif est l’amélioration de l’efficacité et de la rapidité des interventions de

maintenance. Le troisième objectif a pour but l’analyse technique et la mise en place des interventions

adéquates. Cet outil permet aux différents services de mieux déceler des problèmes et de mettre des actions en place.

Enfin, le FSL-TWIM est la référence technique de la maintenance pour l’ensemble des

utilisateurs et permet une traçabilité et une transparence des interventions lors des audits qualité.

Le plan de travail

La démarche

Chaque phase de collecte, des besoins initiaux puis spécifiques des clients, est articulée de la

façon suivante :

- Mise en place de réunion avec les clients - Formalisation des besoins (journal de bord) - Identification des différentes tâches - Réalisation du planning

Une fois cette étape terminée, la phase de codification permet de réaliser un prototype. Les

tests unitaires finis, une mise en situation avec les clients valide le projet. Au final, les clients valident les différents modules et la livraison de l’outil complet peut avoir

lieu.

Page 12 Denis TUR


Les fonctionnalités envisagées pour les sous projets

L’outil FSL-TWIM comporte plusieurs sous-projets. Le premier qui est fonctionnel et utilisé depuis janvier 2007, s’intitule « Cahier de Consignes

Informatiques ». Pour le module « Recherche de pièces dans le stock de l’usine », les listings de pièces sont

récupérés quotidiennement par transfert de fichiers sur un serveur. Ces informations permettent la mise en place d’un support avec une recherche plus rapide et plus conviviale.

Concernant le module « Documentation technique », une interface utilisateur est créée pour la

mise en ligne des documents et la mise à jour si nécessaire. Avec l’outil « Plans d’actions », un système innovant et centralisé est proposé pour gérer et

organiser le suivi des travaux des techniciens et ingénieurs. Le module de « Gestion des maintenances préventives » centralise les différentes interventions

de maintenance. Il permet l’affichage des plannings, gère les « compteurs équipements1

La planification

» et assure la traçabilité des interventions.

Le planning prévisionnel de ce projet est difficile à établir. En effet, ma fonction d’Equipment

Engineering m’amène à gérer un parc équipement, aussi bien au niveau des budgets que des interventions de maintenance. Mon premier rôle est de maintenir les équipements de production en état de fonctionnement optimum. Le projet FSL-TWIM rentre à terme dans ce cadre-là. Ce planning est donc juste un indicateur et permet d’estimer le délai de réalisation du projet.

Voici ci-après un aperçu du planning prévisionnel.

Figure 1 : Extrait du planning prévisionnel du projet FSL-TWIM

1 Valeurs disponibles sur les équipements pour connaître les heures de fonctionnement, la quantité de produit passé sur les équipements, les nombres de cycles, etc.

Page 13 Denis TUR


Les ressources nécessaires

Les ressources humaines

Pour mener à bien ce projet, la communication avec plusieurs métiers est nécessaire. Que ce

soit avec des managers de groupe, des opérateurs, des techniciens ou ingénieurs. Tous sont acteurs dans le projet.

L’équipe de pilotage du projet est la suivante : Sponsor : Philippe Mazilier : Manager du groupe maintenance Toulouse FAB Support technique : Philippe Simoés : Manager weekend maintenance et informaticien Support technique IT : Simon Tressières : Informaticien Support technique IT : Fabrice Jacquemin : Informaticien Support technique : Catherine Saccoccini : Informaticienne Maître d’œuvre: Denis TUR : Equipment Engineering Implantation

Les ressources budgétaires

Les budgets maintenance sont soumis à beaucoup de contraintes. Dans une situation économique difficile, les sommes allouées à la maintenance sont sans cesse modifiées. Dans ces conditions, les ressources budgétaires pour un tel projet sont minimales. La mise en place d’un serveur et le support technique à l’année de celui-ci sont de l’ordre de 2000€. Le codage et la mise en production de ce projet sont effectués sur mon temps de travail et avec un investissement personnel important.

I.2- Déroulement du projet

La partie suivante montre la réalisation du projet.

Etat des lieux

L’équipe de maintenance à Freescale est sectorisée en sept groupes. Au fil du temps, les méthodologies de chaque secteur ont divergé et il existe aujourd’hui autant de façons de travailler qu’il existe de groupes.

• Les passages de consignes entre les techniciens de maintenance sont soient orales, soient écrites, parfois les deux. L’archivage des cahiers de consignes est inexistant. Bien que les évènements majeurs soient répertoriés dans PROMIS (logiciel de gestion de la production), la recherche de consignes importantes est difficile, voire impossible.

• Les interventions de maintenance préventives sont gérées par plusieurs systèmes. Pour le groupe implantation ionique, il existe un outil informatique depuis 1996. Cet outil développé sous Visual Basic atteint aujourd’hui ses limites ; il exploite une base de données ACCESS et il n’est plus maintenu. Les autres labos travaillent avec un système de planification sous LabView.

Page 14 Denis TUR


Là encore, le logiciel utilisé n’est plus adapté pour faire de la planification et surtout les performances sont en-dessous des besoins. L’historique des détails des interventions de maintenance est présenté sous format papier, avec tous les inconvénients que cela comporte ; pertes de papier, check-lists mal remplies, etc.

• Les compteurs présents sur les machines sont relevés manuellement ou par

système informatique. La planification des interventions se fait à l’aide d’un fichier Excel. On retrouve autant de fichiers qu’il existe de type d’équipements avec compteurs.

• La recherche de pièces de rechange se fait sur une console VT220 grâce à un

logiciel, qui n’est pas du tout intuitif et manque énormément de convivialité. Avec un affichage d’une dizaine de pièces par écran, il faut faire défiler les différentes pages pour trouver la pièce souhaitée. Cela engendre une perte de temps conséquente pour les techniciens et ingénieurs, (de 5 à 10 minutes minimum par recherche).

• Concernant la gestion des documentations techniques, les avis et les méthodes

divergent. Certains conservent leur classeur personnel qui fait office d’aide-mémoire. D’autres partagent leur savoir et mettent en place des documentations communes. Aucun standard n’existe pour la documentation dite « d’aide au dépannage et documentation technique ».

• Pour les projets des techniciens ou pour les suivis particuliers lors d’événements

sur les équipements, chaque groupe utilise sa méthode, son fichier de suivi, ses critères de priorités. Là encore rien de commun, impossible de s’y retrouver.

La collecte des besoins clients

Le besoin exprimé par les futurs utilisateurs est très clair : ils demandent une

STANDARDISATION des méthodes de travail. La norme ISOTS [B1] demande de plus en plus de standards pour garantir au client final un

produit avec des caractéristiques techniques reproductibles. De ce fait, les services internes (maintenance/procédé/device) sont très attentifs au concept

de standardisation. Lors des différentes réunions avec les futurs utilisateurs du système de gestion de la

maintenance, les besoins se focalisent à chaque fois sur un système centralisé et commun. Les grandes lignes des besoins sont :

• Mettre en place un système informatisé. • Disposer d’un point d’accès unifié. • Standardiser des outils pour les groupes supports (maintenance/procédé) • Communiquer avec les bases de données existantes • Assurer la maintenance et permettre l’évolution vers de nouvelles fonctions

Page 15 Denis TUR


Diagramme fonctionnel du projet FSL-TWIM:

Le diagramme fonctionnel du projet FSL-TWIM, présenté ci-après, permet de visualiser les

différentes fonctionnalités du système.

Figure 2 : Diagramme fonctionnel Global du projet FSL-TWIM

Ce diagramme fonctionnel permet de mieux cerner l’ampleur du projet. Les paragraphes suivants détaillent chaque module et permettent de mieux comprendre les différentes fonctionnalités.

FSL-TWIM

Fonctionnalités :

Consignes informatiques

Gestion des préventives

Affichage des pièces du stock

Documentation technique

Disponibilité des machines

Configuration des équipements

Données brutes Informations :

- CONVIVIALES - RAPIDES - COMMUNES - CENTRALISEES

Trier Visualiser Organiser Rechercher Administrer Partager

Communication équipements

Données utilisateurs

Page 16 Denis TUR


Les diagrammes fonctionnels du système FSL-TWIM :

Cahier de consignes informatisé :

- Ce module permet la saisie de consignes, dédiées par groupe de maintenance. L’utilisateur doit indiquer son nom, choisir l’équipement parmi une liste prédéterminée correspondant à son unité.

- Il offre la possibilité de noter une remarque si l’intervention doit être poursuivie lors du changement d’équipe de maintenance.

- Il permet de faire des recherches dans les historiques, soit par machine, par mots-clés ou par période calendaire.

- La page d’accueil présente les consignes de la veille et de la journée, ainsi que l’état actuel du parc machine.

- Ce module offre la possibilité de modifier ou de supprimer des consignes (restriction aux consignes personnelles uniquement : accès par mot de passe)

Cahier de consignes informatisé

Figure 3 : Diagramme fonctionnel pour le cahier de consignes

Maintenance préventive équipement (PM):

- Ce module doit afficher le planning des interventions de maintenance préventive par unité. Chaque utilisateur peut choisir dans ce planning les équipements qui le concernent. Une vision générale des dates d’intervention de maintenance est nécessaire afin de connaître les retards ou les oublis. Le planning de la période en cours doit être toujours affiché. Le choix d’une période calendaire spécifique doit être possible par l’intermédiaire d’un menu.

- Pour remplacer le bilan hebdomadaire manuel des interventions de maintenances préventives, un suivi (sous forme graphique) ainsi qu’une alerte en cas de retard doivent être réalisés.

- La centralisation des relevés présents sur les équipements, appelés « compteurs », doit permettre une vision rapide et globale de tous les systèmes compteur de l’unité de fabrication (ex : compteurs Machine Manager, PROMIS ou compteurs manuels). Ce système permet d’effectuer une planification dynamique en fonction des relevés récoltés.

- La fonction « Compteur » doit également répondre aux besoins spécifiques de certaines unités, par exemple pour des calculs cumulatifs.

Information et analyse Noter les consignes

Consigne saisie

Rechercher Visualiser Trier machine/jour

Page 17 Denis TUR


- Une fonction de ce module doit permettre de connaître à l’année la quantité de pièces nécessaires à l’exécution des interventions de maintenance préventives. Cet outil prévisionnel sera une aide non négligeable pour la gestion des coûts de maintenance.

- Pour répondre aux différents audits, un menu doit permettre la traçabilité des interventions au travers de l’historique dans une base de données.

- Une fois que le système préventif est en place, les préventives suivantes se génèreront automatiquement lors des saisies de fin d’intervention précédentes par les utilisateurs. Le système sera auto-alimenté.

- Enfin, le fonctionnement et l’administration doivent être partagés par plusieurs utilisateurs. Les managers de services et Equipment Engineering doivent avoir les droits d’accès pour créer, modifier, ou supprimer des interventions de maintenance préventives. Un menu convivial et complet permet, selon les niveaux d’accès, l’administration de cet outil.

Maintenance préventive équipement

Figure 4 : Diagramme fonctionnel pour la planification des maintenances préventives sur les équipements

Stock de pièces « KARDEX » :

- Ce module doit permettre d’optimiser la recherche des pièces de rechange pour

les interventions de maintenance préventives ou curatives de l’ensemble de l’usine.

- Un fichier « CSV (Comma Separated Value) » doit être récupéré tous les jours, pour alimenter une base de données.

- Une page doit permettre, à l’aide de requêtes, d’effectuer un tri par référence fournisseur, par référence Freescale ou par famille d’équipements.

Planifier les préventives

COMPTEURS ou PM classique : Nécessite de saisir la 1ère date de l’intervention de maintenance et la fréquence.

Planning complet, convivial et rapide.

Fonction Rechercher Administrer Visualiser Trier historique

Analyse et informations

Régénération

Page 18 Denis TUR


Stock pièces KARDEX

Figure 5 : Diagramme fonctionnel pour le stock des pièces (KARDEX)

Documentation technique :

- Il faut centraliser les documentations techniques et les aides aux dépannages sous

un format unique. - Il faut créer un menu d’administration pour la mise en ligne des documents. Les

utilisateurs pourront ainsi partager leur savoir et leurs expériences de maintenance, après validation de ces informations auprès d’un Equipment Engineering.

Documentation technique

Figure 6 : Diagramme fonctionnel de la documentation technique

Outil d’analyse de la disponibilité des équipements :

- Ce module doit permettre de visualiser la disponibilité des équipements de

production et de connaître les principales causes d’arrêt. - La page d’accueil doit guider l’utilisateur, selon des choix multicritères. Il faut

pouvoir sélectionner son unité, son équipement type, sa période d’analyse, les différents groupes de pannes (appelés buckets) et les commentaires des intervenants par type de panne.

- Il faut utiliser les bases de données (Oracles & TERADATA) pour déterminer la disponibilité des équipements.

Partager le savoir Données utilisateurs

Le savoir est partagé.

Les documents sont accessibles

Rechercher document Mettre en ligne les documents

Afficher les pièces du stock

Données brutes Stock pièces

Tri convivial et rapide

Trier par références Freescale, Fournisseur et famille d’équipements

Page 19 Denis TUR


-

Disponibilité équipements

Figure 7 : Diagramme fonctionnel de l’outil d’analyse de la disponibilité des équipements

Configuration des équipements :

- La centralisation des configurations machine doit permettre de garder la

traçabilité des softwares, des paramètres, etc. Les données peuvent contenir par exemple, les versions de logiciels présents sur les équipements, les valeurs critiques de réglages ou les sous-ensembles mécaniques. Toutes les informations utiles et nécessaires sont stockées pour reconfigurer un équipement en cas de pannes importantes.

- L’utilité de cet outil sera sans aucun doute appréciée lors des audits de qualité. En effet, les auditeurs souhaitent connaître les configurations et les différences notables entre équipements du même type.

Configuration équipements

Figure 8 : Diagramme fonctionnel des configurations équipements

L’ensemble de ces diagrammes fonctionnels permet de mieux cerner les besoins des clients et oriente les solutions de développement.

Stocker les configurations

Données brutes des configurations

Affichage rapide des

configurations

Fonction Chercher par groupe d’équipement type

Connaître la disponibilité

Deux bases de données Oracle et

une base de données de

type TERADATA

Affichage de la performance en

temps réel

Visualisation des détracteurs de

panne

Sélection Multicritères

Page 20 Denis TUR


Recherche des solutions de développement

La validation du cahier des charges et des différentes fonctionnalités du système est réalisée.

Nous pouvons aborder la phase de recherche de solutions, une des plus discutées et discutable au vue de la diversité des choix.

La variété des sous-projets, la centralisation des informations, le besoin de rapidité et surtout l’accessibilité du système sont des points très importants. Pour les satisfaire, deux phases sont nécessaires à l’élaboration des solutions de développement : la phase de recherche et la phase de tri.

La phase de recherche

De prime abord, un logiciel de maintenance sous-entend GMAO (Gestion de Maintenance

Assisté par Ordinateur). Aujourd’hui sur le marché plusieurs outils existent : lequel choisir ? Les principaux sont : CARL (software), CLARISSE, OPTIMAINT, COSWIN 7i, etc. Tous proposent des solutions innovantes dédiées par secteurs d’activités. En effet, ces logiciels

intègrent la gestion de stock, la planification d’interventions préventives, la gestion des ressources humaines, le suivi d’interventions, etc.

Ils sont vraiment complets et répondent à certains besoins du projet avec précision. Autre axe de recherche : les solutions présentes en interne. Que possède Freescale pour la

gestion de la maintenance ? L’outil PROMIS, déjà utilisé pour gérer la production du site de Toulouse, propose quelques solutions. Il intègre entre autres des fonctions de gestion d’équipements (affichage des pannes curatives et des interventions préventive), des notifications de consignes après les différentes interventions (de maintenance bien sûr, mais aussi de production ou de d’engineering) et des planifications de tâches.

Enfin, la dernière solution possible est le développement d’un système complet de A à Z en

utilisant un langage, une plateforme ou un environnement dédié. La communication avec des bases de données internes à Freescale, l’accessibilité sur toute

l’usine, la rapidité et l’aspect convivial sont des critères décisifs. Autre point important, la mise en œuvre doit être simple.

En prenant en compte toutes ces informations, une plateforme de type PHP [B2] peut correspondre à ces besoins.

La phase de tri Ce « brainstorming » avec l’équipe projet (présenté au paragraphe I.1) a permis de dégager

plusieurs solutions potentiellement adaptables au projet. Pour faire un choix constructif, trois critères permettent de juger la faculté de chaque solution

à répondre aux exigences des clients. Ces critères sont : le coût, la faisabilité et l’évolution du système.

Les notes varient de 0 à 10.

- 0 : pas de coût, réalisable et évolution interne possible. - 10 : coût maximum, faisabilité nulle et pas d’évolution interne possible.

En utilisant un système à trois axes, le report de ces notes permet de connaître la meilleure

solution : celle-là même qui occupe la surface la plus petite possible.

Page 21 Denis TUR


La figure suivante montre ces trois critères et leurs notations.

Figure 9 : Diagramme décisionnel des solutions techniques

Récapitulatif avec les avantages et les inconvénients. Choix Avantage Inconvénient Coût Faisabilité Evolution Classement

Logiciel GMAO du marché

Complet, dédié à un secteur d’activité.

Coût à prévoir, pas d’amélioration possible

en interne. Pas forcement applicable aux différents besoins

des clients.

5 4 8 3ème

PROMIS Logiciel puissant pour la gestion de

production.

Pas du tout convivial, interface graphique

inexistante. Pas de base de données.

2 3 5 2ème

PHP Bien adapté au développement WEB, simple à

mettre en place. Maintenance facile. Economique à long

terme. Communication avec les bases de données

simplifiée.

Formation personnelle nécessaire. Aucune connaissance de ce

langage.

1 1 1 1er

Tableau 1 : Critères de sélection des solutions de développement

Avec tous ces critères, une proposition se dégage. La solution PHP est la mieux adaptée aux

besoins exprimés. Reste un inconvénient à cette solution : la nouveauté d’un tel système ! L’auto formation sera nécessaire. Sur le site de Freescale Toulouse je pourrai m’appuyer sur le support technique de l’équipe projet, et plus particulièrement sur Philippe Simoès, Ingénieur informaticien, et également sur la multitude d’informations disponibles sur les forums et sites dédiés au PHP.

Coût

Faisabilité

Evolution

1 2 5

4 3 1

1

5

8

Solution GMAO du marché

Solution PROMIS

Solution PHP

Page 22 Denis TUR


Architecture du système FLS-TWIM

Le cahier des charges impose une communication avec des bases de données multiples, une

accessibilité via tous les ordinateurs de l’usine. Il n’y a pas de code résidant, pas d’installation de logiciel ou de bibliothèque sur les postes clients. Tout est stocké et interprété par le serveur dans la partie applicative de l’architecture. Concernant les bases de données MYSQL [B3], elles sont stockées sur le serveur, par contre d’autres bases ORACLE et TERADATA/DIAMOND2 sont stockées sur un serveur dédié. Ce dernier est complètement géré par le service informatique. Ces bases ne sont pas locales, elles sont communes à toutes les entités Freescale dans le monde. A l’inverse des bases MYSQL, l’applicatif communique avec celles-ci uniquement en lecture. Ces bases sont principalement utilisées pour créer des rapports et faire des analyses.

Figure 10 : Architecture du système FSL-TWIM

Etude du stockage des données

Le projet FSL-TWIM est construit sur la manipulation de données. Les bases utilisées sont

MYSQL, ORACLE et TERADATA/DIAMOND : sur ces deux dernières aucun changement n’est possible. En effet, elles ont été définies par le groupe informatique principal (Freescale Etats-Unis), et les changements de structure sont impossibles.

Par contre, pour les bases de données MYSQL, les structures sont à réaliser. Une recherche sur

la construction des bases de données permet d’identifier une méthode : la méthode MERISE3

2 Nouvelle base de données dans l’entreprise Freescale 3 Technique d’origine française pour l’analyse des bases de données

[B4].

Page 23 Denis TUR


Cette méthode est basée sur le modèle entité-association. C’est une technique permettant de construire des schémas théoriques de raisonnement sur des applications utilisant des bases de données relationnelles.

La connaissance des règles simples des schémas entités-associations (aussi appelé entités-

relations) permet d'affiner le projet, sans avoir besoin de programmer. Par conséquent, on réalise une économie de temps de conception tout en obtenant une plus grande souplesse au niveau de l'analyse.

Le modèle entité-association est apparu dans les travaux des chercheurs, entre 1972 et 1975

lors des travaux de Messieurs MOULIN, TARDIEU et TEBOUL. Il est devenu célèbre dans le monde entier grâce à l’américain Peter CHEN.

Avec cette technique, la construction des différentes bases de données MYSQL du projet est la

suivante.

Définition des entités

La méthode MERISE nécessite l’existence d’entités, en fait nous pourrions parler aussi de tables. C’est le terme le plus souvent utilisé dans le secteur industriel ou privé, sur des bases comme ACCESS, par exemple.

Le cahier des charges stipule que l’outil final doit servir à plusieurs unités. Une centaine de techniciens et ingénieurs doivent s’identifier. Il faut gérer plus de 1000 équipements de production. Le projet doit aussi intégrer un planning, des pièces de rechange, des interventions de maintenance préventives, des archives, des consignes, etc. Autant d’entités à créer.

Sur l’ensemble du projet pas moins de 52 entités sont nécessaires au fonctionnement du système FSL-TWIM.

Voici quelques exemples d’entités utilisées dans le projet.

Figure 11 : Exemple d’entités dans les bases de données MYSQL

Définition des attributs

Les attributs dans la méthode MERISE sont les caractéristiques décrivant les entités. Ils sont représentés par une liste de mots, la plus simple possible pour chacune d’elle. Il faut également préciser le type des données attendues pour chaque attribut. Là aussi, nous pouvons utiliser le terme de champs à la place d’attributs. En reprenant les exemples ci-dessus pour chaque entité, nous avons une liste d’attributs. Dans le cas de l’entité PERSONNELS il faut les attributs : NOM, PRENOM, CCID, USER_ID, ADMIN et LABO (unité d’appartenance). Pour chacun d’entre eux, les types de données ont des caractères d’une longueur bien déterminée.

Pour illustrer les attributs, la figure 12 reprend les exemples ci-dessus.

Personnels Equipements Planning

Page 24 Denis TUR


Figure 12 : Exemple d’attributs dans les entités des bases de données MYSQL

Définition des associations ou relations

Ce sont les liaisons entre entités. Dans le projet FSL-TWIM, un utilisateur du logiciel appartient à une unité bien définie. Il travaille sur des équipements qui appartiennent à cette même unité. La visualisation du planning des interventions de maintenance préventives est aussi liée à cette unité.

L’illustration suivante montre ce type de liaisons.

Figure 13 : Exemple de relation ou d’association entre entités dans la base MYSQL

On peut aussi résumer cette illustration par cette phrase : « Un technicien à la charge de maintenir des équipements, et les équipements peuvent avoir ou

non des interventions de maintenance préventives planifiées »

Définition des cardinalités

La notion de cardinalité permet de dénombrer les éléments de l'entité d'arrivée en relation avec les éléments de l'entité de départ, et vice versa.

L’exemple ci-dessus et surtout la phrase qui décrit l’illustration sont des exemples de cardinalité. En effet, un technicien a la charge de plusieurs équipements et chaque équipement peut être maintenu par plusieurs techniciens. Autre exemple, un équipement peut avoir ou non une maintenance préventive planifiée, par contre chaque intervention de maintenance préventive a un et un seul équipement associé.

Personnels

NOM CHAR(20) PRENOM CHAR(20) CCID CHAR(8) USER_ID CHAR(7) ADMIN CHAR(2) LABO CHAR(15)

Equipements

EQT_ID CHAR(20) EQT_TYPE CHAR(20) LABO CHAR(15) DESCRIP CHAR(255)

Planning

LABO CHAR(15) EQT_ID CHAR(20) DATE DATETIME NOM_PM CHAR(50) FAITE CHAR(2)

FAITE_HORS_D CHAR(2)

PM_COMPTEUR CHAR(2)

COMPTEUR_NAME CHAR(20)

Maintien Possède une PM

Personnels Equipements Planning NOM CHAR(20) PRENOM CHAR(20) CCID CHAR(8) USER_ID CHAR(7) ADMIN CHAR(2) LABO CHAR(15)




PM_COMPTEUR CHAR(2)


Page 25 Denis TUR


Figure 14 : Exemple de cardinalité dans des relations d’une base MYSQL

Définition des clefs d’une entité

Une clef permet de distinguer sans ambigüité un élément dans une entité par rapport aux

autres éléments de cette entité. Par souci de rapidité dans les recherches et pour éviter toute confusion, une clef purement

informatique est créée dans chaque entité. Cette clef sert d’index primaire et elle est dissociée des attributs de l’entité.

Prenons un exemple sur l’entité PERSONNELS, un nouvel attribut est ajouté en tout début de l’entité, il est complètement transparent pour l’utilisateur. Cet attribut porte le nom « ID » quelles que soient les différentes entités dans les bases de données, le type de donnée est un « INT(10) », avec une clé primaire et une auto-incrémentation. Le fait qu’il soit unique permet une manipulation des données sans aucune confusion possible. L’attribut « ID » devient donc la clef des différentes entités.

Figure 15 : Exemple de clef dans une entité

Le modèle conceptuel des données

La méthode MERISE va plus loin dans la conception des structures des tables. Cependant, pour ce projet, seules les notions décrites précédemment sont nécessaires.

Concernant le MCD (modèle conceptuel de données), voyons pour un cas bien précis la structure de celui-ci.

La figure 13 montre l’exemple de MCD pour l’outil de gestion des maintenances préventives.

Personnels

ID INT(10)


Maintien Personnels


Equipements


Planning



PM_COMPTEUR CHAR(2)


Possède une PM

1,n 1,n 0,n 1,1

Maintien

Page 26 Denis TUR


Figure 16 : Exemple de MCD (Modèle Conceptuel de Données), pour l’outil de gestion des maintenances préventives

Cet exemple montre la structure pour le module « gestion des maintenances préventives ». Le

projet dans sa globalité comporte 10 bases de données MYSQL avec 52 entités différentes. Les modèles conceptuels de données pour les 9 modules présents dans « FSL-TWIM » sont détaillés en annexes.

A l’issue des différents « MCD » de chaque module, les tables nécessaires au fonctionnement du

système « FSL-TWIM » peuvent être construites.

Correspondre

Personnels

ID INT(10)


Equipements

ID INT(10)


Différentes PM

ID INT(10)

LABO CHAR(15) EQT_TYPE CHAR(20) NOM_PM CHAR(50) PERIODE CHAR(10) FREQUENCE CHAR(10)

NB_JOURS FLOAT

DESCRIP CHAR(255)

RETARD FLOAT

SPEC CHAR(100)

Spécifications

ID INT(10)

SPEC CHAR(255) LIEN CHAR(255)

Intervenir 1,n

1,n

Planifier 0,n

1,n

0,1

1,n

Associer

1,n

1,n

Associer

1,n

1,n

Planning PM

ID INT(10)



PM_COMPTEUR CHAR(2)


Page 27 Denis TUR


Exemple de construction de tables : Table PERSONNELS :

Table DIFFERENTES_PM :

Figure 17 : Exemple de structure de table dans les bases MYSQL

La méthode MERISE m’a permis de construire et structurer au mieux les tables nécessaires au système FSL-TWIM.

Page 28 Denis TUR


Estimation des ressources nécessaires

Le critère de coût dans la recherche des solutions techniques impose à ce projet un coût

minimum voir nul. En fait, il faut prendre en compte la mise en place d’un serveur avec un budget pour le maintien de celui-ci.

Pour évaluer les ressources nécessaires, j’ai utilisé la méthode COCOMO4[W1], qui estime à

partir du nombre de lignes de code source le besoin en mois-homme et un temps de développement. En utilisant cette méthode, voici une estimation qui ne fait pas office de référence, mais permet

de voir l’ampleur du projet. Le développement du site est estimé environ à 25000 lignes de code source. Cette estimation

détermine que c’est un projet de complexité simple. De ce fait, en prenant la formule ci-dessous : ... (suite ci-dessous)

Complexité Effort (en mois homme) Temps de développement (en mois)

S Effort = 2,4 * KLS1,05 TDev = 2,5 * Effort0,38

Effort = 2,4 * 251,05 = 70,5 TDev = 2,5 * 70,50,38 = 12.5 Tableau 2 : Méthode COCOMO, effort et temps de développement

(suite) … on aboutit à :

- 70 mois-homme pour ce projet. - Temps de développement de 12.5 mois pour finaliser le projet (à pondérer).

Le graphique ci-après montre la répartition du besoin en hommes sur les différentes phases du

projet et la durée de chacune.

23

54

1

4

8

1

0123456789

Expression du besoin Conception générale Programmation Test et intégration

Besoin en hommes et durée des phases

Tableau 3 : Besoin en hommes et durée des phases dans la méthode COCOMO

4 Méthode statistique basée sur les résultats de 63 projets de développements informatiques.

Durée en mois

Besoin en hommes

Page 29 Denis TUR


La méthode COCOMO permet également de distribuer la phase d’effort selon les différentes

phases du projet. En effet, pour un projet de complexité simple, des statistiques permettent de déterminer l’effort nécessaire par phase. L’expression du besoin est séparée de l’effort total, la somme des trois autres phases faisant 100%.

Phase du projet Pourcentage d’effort

Expression des besoins et planification 6 % (séparé de l’effort total)

Conception générale 16 %

Programmation 62 %

- Conception détaillée 4 %

- Programmation et tests unitaires 38 %

Tests et intégration 22 % Tableau 4 : Méthode COCOMO, pourcentage d’effort

Ainsi, on peut également par cette méthode calculer le temps de développement d’un projet

simple. Là aussi, le temps consacré à l’expression du besoin et à la planification ne fait pas partie du temps total.

Phase du projet Temps de développement

Expression des besoins et planification 12% (séparé de temps total)

Conception générale 19 %

Programmation 55 %

Tests et intégration 26 % Tableau 5 : Méthode COCOMO, pourcentage de temps du développement

Pour conclure sur cette méthode statistique, il faut comprendre que c’est juste un indicateur

qui permet d’évaluer la charge de travail d’un projet et de connaître l’ampleur de l’effort et du temps de développement.

Le codage

Comme le montrent les tableaux 3, 4 et 5, le codage est l’étape la plus importante de ce projet

en temps et en effort. Dans ce paragraphe, la description des codes sources et des bibliothèques développées n’est

pas détaillée. Par contre, il décrit les règles de codage utilisées. Les feuilles de styles (mise en forme des pages web) de l’entreprise sont réutilisées pour la

présentation générale des pages du système FSL-TWIM. Elles définissent l’aspect visuel des tableaux, des menus déroulants, des polices, etc. L’arborescence des codes sources est séparée par module. La maintenance et l’évolution future seront plus rapides et plus simples.

Page 30 Denis TUR


Arborescence des codes sources

Figure 18 : Arborescence des codes sources sur le serveur de FSL-TWIM

Règles de codage et architecture du logiciel

A Freescale, il n’existe pas de normes ou de règles de codage clairement définies. Pour

retrouver rapidement les différentes fonctions et simplifier l’entretien du site, tous les codes sources sont commentés et indentés.

Le développement du code se rapproche des missions transversales du métier d’Equipment Engineering. En effet, étant leader du groupe 5S sur la zone implantation ionique, je participe à la mise en place de la philosophie Lean Manufacturing qui prône l’utilisation du 5S, du SMED et prévoit l’amélioration continue des procédés ou des interventions de maintenance au travers des KAIZEN. Le codage rentre complètement dans cette approche de structure, de notification, d’indentation du code et d’optimisation.

Chaque code source se décompose de la façon suivante :

- L’en-tête, regroupant les liens des feuilles de styles, les liens javascripts, le menu déroulant de gauche, les variables d’entrées en PHP avec les méthodes « GET 5

- La partie formulaire, regroupant les tableaux, les boutons, les affichages divers et les scripts PHP.

»

- La partie de POST, avec toutes les actions demandées après une méthode POST 5 dans le formulaire.

- La partie pied de page, regroupant les informations de fin de page, liens, etc.

La figure 19 montre un exemple des différentes parties d’un code source.

5 Les méthodes GET ou POST sont utilisées pour faire passer des variables d’une page à l’autre.

Page 31 Denis TUR


En-tête d’un code source

Formulaire

Page 32 Denis TUR


Figure 19 : Exemple de code source

Pied de page

Partie POST

Page 33 Denis TUR


Notions sur la programmation en PHP

Le langage PHP [W2] ou HYPERTEXT est un script qui est interprété sur le serveur (machine hébergeant les différentes pages WEB). Celui-ci va interpréter le code PHP et générer un autre code qui est envoyé sur le navigateur (Internet Explorer, Firefox, etc.). Le code généré est constitué généralement de langage XHTML ou HTML, de feuilles de style « CSS », de JavaScript et parfois de documents « PDF ».

Conçu pour permettre la création d'applications dynamiques, le plus souvent dédiées aux

pages Web, le PHP est généralement installé sur un serveur Apache. Le point fort, c’est la possibilité de communiquer très facilement avec des bases de données. Une fois l’installation réalisée des modules correspondant aux bases de données sur le serveur, l’accès est rapide et aisé.

La figure ci-dessous, extraite de WIKIPEDIA, illustre parfaitement le fonctionnement du

langage PHP. Le client ouvre une page WEB, lance une requête ou une demande d’informations. Ces

demandes sont envoyées au serveur via Internet ou pour ce projet via l’intranet de Freescale. Le serveur prend en compte la page, exécute le script PHP, puis génère du code HTML qui est interprété par le navigateur du client.

Figure 20 : Extrait de Wikipédia sur le fonctionnement du PHP

Concrètement pour que le serveur exécute le script PHP, la page doit avoir une extension en « .php ». Cette page peut bien sûr, comporter du code HTML, du JAVASCRIPT et du script PHP. Le script PHP est alors encadré par des tags :

pour le PHP les tags sont : < ? code script php placé ici ?>

La page WEB ainsi créée satisfait à la demande du client et en aucun cas il ne peut voir le code

source d’origine de sa page, seul le code HTML est visible. En effet, le retour est principalement composé de code HTML. C’est un avantage important d’un point de vue sécurité.

Le risque pendant le développement du code est l’effet tunnel. L’effort et le temps consacré au code occultent un peu la réalité et le besoin final du client. Pour rester en ligne avec le cahier des charges, la recherche d’une méthode de tests et de validation est indispensable.

La question est : comment faire pour finaliser ce projet ?

http://upload.wikimedia.org/wikipedia/commons/d/d2/Php_arch_shema.png�

Page 34 Denis TUR


Cycle de vie d’un projet

Après plusieurs recherches, la méthode la plus fréquemment utilisée est le « cycle de vie ».

Celle-ci permet de manière logique de suivre un projet dans sa totalité et surtout de n’oublier aucune étape. Il existe des cycles en V ou en cascades, le plus courant est le cycle de vie en V.

La figure ci-dessous décrit le cycle de vie en V d’un projet informatique.

Figure 21 : Cycle de vie en V

Les premières étapes du début du projet FSL-TWIM suivent ce cycle de vie en V. Toutefois, ne

connaissant pas cette méthode lors de l’élaboration du projet, certaines étapes ou transitions n’ont pas été présentées dans ce mémoire.

En intégrant cette méthode à la suite (et fin) du projet, la deuxième partie du cycle : « Tests et

intégration du projet » a permis de répondre à la question posée en fin page précédente : « Comment faire pour finaliser ce projet ? »

Vérification et validation

Définition du projet

Tests et intégration du

projet

Codage

Analyse des besoins et faisabilité

Spécifications

Conception architecturale

Conception détaillée Tests unitaires

Tests d’intégration

Tests de validation

Recette et maintenance

Temps

Page 35 Denis TUR


Tests des programmes

Cette étape est étroitement liée au codage. En effet, les tests des modules et des fonctionnalités se font pendant le développement du code. La relation « codage tests » ou « tests codage » est très fréquente.

Ces tests se déroulent en deux phases bien distinctes. Tests des sous programmes et des fonctionnalités particulières. Cette étape, appelée « Tests

Unitaires », permet la vérification de chacun des codes sources. Le tableau ci-dessous montre un exemple de test unitaire sur un module.

Numéro du test: A1 Type de test Unitaire Description Module de récupération des valeurs compteurs et traitement des données Description du test et Instructions

Résultat attendu Test réussi

Valeur compteur non disponible sur le serveur ‘tlscim03’ Notification erreur, pas de fichier disponible

OK

Commentaire du défaut

RAS

Description du test et Instructions


Récupération des valeurs compteurs. Valeur compteur de chaque compteur affichée à l’écran.

OK


RAS

Description du test et Instructions


Calcul de la vitesse d’avancement des valeurs des compteurs et archivage dans la base de données

Vitesse affichée à l’écran, et base de données ‘compteur_pm’ mise à jour.

OK


RAS

…….. …….. Tableau 6 : Exemple de tests pour le module Gestion des préventives

Tests imbriquant tous les sous programmes. Cette phase permet de tester les interactions

des différents modules entre eux. Elle correspond à la phase de « Tests d’intégration » du cycle de vie en V.

Validation des modules avec les clients

Les clients attendent des réponses aux besoins exprimés dans le cahier des charges. La livraison des modules au fur et à mesure de leur construction permet de satisfaire rapidement les besoins exprimés par les clients.

L’information aux différents managers de groupe et aux utilisateurs sur l'avancement du projet contribue au déploiement du système FSL-TWIM.

Page 36 Denis TUR


Livraison finale

En fin de validation des outils, j’ai installé tous les codes sources sur le serveur de production,

dans leur environnement réel. J’ai mis en service le système FSL-TWIM. Ma mission consiste aussi à informer, préparer et encadrer les différents utilisateurs. La

programmation de formation permet aussi une meilleure appropriation des différents menus et fonctionnalités du système FSL-TWIM. C’est une nouvelle méthode de travail.

J’ai aussi documenté le fonctionnement de ce nouveau système dans un document de référence, (GUIDE UTILISATEUR). Là, je fais apparaître toutes les subtilités des différents menus et des différentes pages.

Maintenance

A Freescale, la mise en production d’un logiciel et sa maintenance nécessite de documenter toutes les étapes du processus d’installation et l’architecture logicielle. Cette documentation technique détaillée est normalisée, son contenu doit permettre de comprendre le fonctionnement de l’ensemble du système.

Elle doit comporter les structures des codes sources, les structures des différentes bases de données et l’architecture globale du logiciel.

Concernant la maintenance curative d’un tel système, un document de référence existe : le « DRP » (Disaster Recovery Plan). Il permet de remonter un serveur à l’identique, avec la dernière sauvegarde des données utilisateurs. Ce document est très complet, il fait même apparaître le temps nécessaire pour revenir à une configuration standard après un crash complet du serveur.

I.3- Conclusion chapitre I

Ce premier chapitre décrit le système FSL-TWIM dans sa globalité, il expose la méthodologie appliquée à ce projet. Avec l’aide des diagrammes fonctionnels, le cahier des charges est précis et permet une meilleure compréhension des différents modules du système.

Le point commun de tous les modules est la communication avec des bases de données. La

méthode MERISE permet la création des structures des tables et les MCD (Modèle Conceptuel de Données) permettent d’identifier, à partir d’une description exprimée en langage naturel ou parlé, les entités et les associations en appliquant des règles précises : les noms deviennent des entités et les verbes, des associations. Dès lors la construction physique peut voir lieu.

Après une recherche des différentes solutions de développement, le PHP correspond aux

critères coût et évolution. La programmation avec ce langage aborde la standardisation des codes sources avec les notions du LEAN MANUFACTURING. L’utilisation de cette philosophie permet d’avoir une architecture structurée, indentée et organisée en modules.

Enfin pour finaliser ce projet, l’explication du cycle de vie d’un logiciel permet d’utiliser en

cours de route la deuxième partie du V. Les tests et validations sont appliqués pour la fin du projet.

Page 37 Denis TUR


Chapitre II : Planification Dynamique des Préventives Compteurs (PDPC)

II.1- Introduction

Ce deuxième chapitre décrit le fonctionnement d’un des sous-projets de FSL-TWIM. Il fait partie du système de gestion des maintenances préventives et il occupe une place importante.

Pourquoi ce module a-t-il besoin d’être approfondi ? La situation économique impose une rigueur et une diminution des coûts de maintenance. La

gestion des interventions de maintenance préventive, sans prendre en compte le rythme de la production, ne permet plus de satisfaire les exigences en termes de coût. Il faut généraliser la planification des maintenances préventives en fonction de l’utilisation des équipements.

Pour cela, il existe sur la majorité des équipements des compteurs. Ils permettent de connaître

le nombre d’heures de fonctionnement, de produits passés, d’heures de radio fréquence sur les modules RF, etc.

La nouveauté du système FSL-TWIM est la centralisation de ces relevés de compteurs et la

planification dynamique des interventions de maintenance préventives en fonction de leur valeur. Pour centraliser et automatiser ces relevés compteurs deux outils existent dans l’entreprise :

- MACHINE MANAGER - PROMIS.

II.2- Présentation de Machine Manager

Machine Manager (ou MM) est un logiciel qui permet, grâce à un serveur, de communiquer avec certains équipements de l’usine. La liaison est possible uniquement si l’équipement en question possède un moyen de communication (liaison série, parallèle ou carte réseau)

Le protocole de communication généralement utilisé est SECSII6

- de lancer des recettes de production stockées dans une base de données (RMS)

. Le dialogue entre MM et les équipements permet :

- de vérifier la conformité des recettes - de remonter les alarmes lors du fonctionnement - de verrouiller des états équipements sur PROMIS (logiciel de gestion de

production) - de suivre des paramètres équipements - de remonter des relevés compteurs

6 Protocole de communication via une liaison série entre un équipement et un superviseur.

Page 38 Denis TUR


Ci-dessous le synoptique des liaisons entre Machine Manager et les équipements sur le réseau

intranet de l’usine.

Figure 22 : Synoptique du fonctionnement de Machine Manager

II.3- Présentation de PROMIS

Promis est un puissant logiciel de gestion de production. Il gère tous les produits de la première étape de fabrication jusqu’au test final. Ce logiciel est utilisé par toutes les entités Freescale. Sur Toulouse, la version primaire est utilisée, l’interface est peu conviviale, les utilisateurs exécutent des scripts ou des instructions sur des consoles VT220.

Promis n’est pas en relation directe avec les équipements de TLS-FAB7

. L’interface est réalisée par Machine Manager. L’illustration ci-dessous décrit le principe de communication entre PROMIS, MM et les équipements.

Figure 23 : Synoptique du fonctionnement de PROMIS-Machine Manager-Equipements.

7 TLS-FAB est l’abréviation de l’Unité de Fabrication de TOULOUSE

PROMIS

Machine Manager

Base de données

RMS

Equipements de

production

Communication (Commande/retour)

(Upload/Download) des informations

Contrôle et upload des versions actives de

recettes de production

Bases de données

ORACLE et TERADATA

Download des données dans les différentes bases

Rgergergerghghgheghergerhgkjvherererjerbvenbenmbqetbmnetmnetbmnetbmtbtntntnbtrnblmtnsbstjbmsblnstlmbnsdtmbjqtmbgtqejghmet ;hetjhemejmghet,jqhmej ;bgejqtbjet ;mbgetj ;qbvgjqet ;bje ;et



Documents PROMIS

Utilise

Page 39 Denis TUR


Cet outil de gestion de la production n’utilise pas les bases de données. Il travaille avec des

documents (les documents PROMIS). En revanche, les données sont chargées sur des bases ORACLES ou TERADATA pour permettre les analyses et pour réaliser des suivis, soit en temps réel soit à fréquence déterminée.

En m’appuyant sur cette structure existante, la récupération des relevés des compteurs des équipements de production permet de planifier les interventions de maintenance préventives.

II.4- Acquisition des relevés compteurs équipements

Il existe trois possibilités pour relever les compteurs équipements et permettre ainsi de créer des plannings.

La première est MM (Machine Manager). Ce principe permet de récupérer la valeur des

compteurs sur les équipements grâce aux liaisons séries. Les données de ces compteurs sont alors stockées et utilisées pour prévoir les interventions de maintenance préventive. Le point faible à cette solution est que dans certains cas les équipements ne possèdent pas de moyen de communication.

La deuxième possibilité est de compter le nombre de produits ou le nombre cycles de

production. Dans ce cas, l’outil PROMIS permet (via des tâches appelées TASK) de générer des compteurs. En effet, un document PROMIS répertorie tous les équipements physiques ou virtuels de l’usine. Le système assure donc une traçabilité pour les produits et connaît exactement la quantité passée sur chaque machine. Cette solution ne dépend pas des outils de communication des équipements.

Enfin, dans une minorité de cas, les valeurs recueillies sur les équipements sont enregistrées

manuellement dans le système FSL-TWIM. Ces trois possibilités de relevé des compteurs sont utilisées dans le module PDPC

(Planification Dynamique des Préventives Compteurs) Pour être réactif sur la planification des interventions de maintenance préventives, il faut une

mise à jour des valeurs compteurs régulière et fréquente. Pour cela, MM envoie par l’intermédiaire d’un script sur le serveur de FSL-TWIM, deux fois par vingt quatre heures les données. Concernant l’outil PROMIS, le système FSL-TWIM interroge par une requête SQL, la base de données et récupère les valeurs compteurs une fois par jour.

Le schéma de la figure 25, présente le principe d’acquisition des relevés compteurs.

Page 40 Denis TUR


Figure 24 : Synoptique de l’acquisition des relevés compteurs

Les compteurs TWIM

La souplesse du système FSL-TWIM permet de faire des accumulations de valeur compteur et répond à une demande utilisateur, qui aujourd’hui est traitée manuellement.

La mise en place de compteurs virtuels appelés « Compteur TWIM » complète cet outil. Le fonctionnement est le suivant : l’utilisateur a la possibilité de choisir un compteur de

référence dans une liste prédéterminée (compteurs stockés dans la base de données MYSQL du système FSL-TWIM). Un nouveau compteur est alors créé, sous le nom de « TWIM_(nouveau nom de compteur) »

Ce nouveau compteur TWIM est mis à jour et la date d’intervention de maintenance préventive

est recalculée à chaque évolution du compteur de référence. Le tableau ci-après permet de visualiser le compteur de référence et le compteur TWIM :

PROMIS

Machine Manager

Base de données

RMS

Equipements de

production

Communication (Commande/retour)

(Upload/Download) des informations

Contrôle et upload des versions actives de

recettes de production

Base de données

ORACLE et TERADATA

Download des données dans les différentes bases




Documents PROMIS

Travaille

Système FSL-TWIM Envoi des relevés sur le serveur FSL-TWIM Récupération des

valeurs PROMIS depuis les bases de

données

Enregistrement manuel des valeurs

Page 41 Denis TUR


Exemple de compteur de référence :

Exemple de compteur TWIM :

II.5- La planification dynamique des interventions préventives

La planification dynamique est l’ajustement des interventions de maintenance préventives en fonction des relevés effectués sur les équipements.

Cette prévision doit automatiquement être réévaluée à chaque relevé. C’est l’effet DYNAMIQUE

du planning. Lors de l’acquisition des valeurs, le système FSL-TWIM doit estimer une vitesse moyenne

d’avancement. Cette vitesse est calculée à partir des trois derniers relevés des compteurs et permet de déterminer une date théorique d’intervention.

Dans l’exemple d’un compteur sur le nombre de produits passés sur un équipement, le

déclenchement d’une intervention de maintenance préventive doit être réalisé avant la valeur maximale autorisée (exemple : 2500).

Valeur maximale : 2500

Fréquence : Relevé 1 Relevé 2 Relevé 3 Relevé 4

Valeurs : 400 650 926 1200 Vitesse : 250 276 274 Vitesse moyenne 266.66 produits entre chaque relevé Calcul de la date d’intervention :

Figure 25 : Exemple de calcul d’une date d’intervention de maintenance préventive avec des compteurs.

Cette date est recalculée à chaque relevé de compteurs et le planning est modifié

dynamiquement. C’est une avancée importante dans la planification des interventions de maintenance

préventive. Il y a environ 1000 équipements de production à gérer et cette solution permet la simplification des plannings.

Page 42 Denis TUR


Exemple de planning sur le système FSL-TWIM La figure 27 présente un extrait du planning tel qu’il est sur FSL-TWIM. Les utilisateurs voient

immédiatement les actions qui doivent être exécutées dans la journée.

Figure 26 : Extrait du planning de FSL-TWIM

II.6- Conclusion chapitre II

Ce sous-projet est le cœur du système FSL-TWIM. La maintenance préventive occupe une part majeure dans le travail des techniciens et

ingénieurs. Les coûts associés à ces interventions sont également importants. La planification dynamique des interventions de maintenance préventives rentre pleinement

dans cette politique d’optimisation des coûts engagée depuis plusieurs années à Freescale Toulouse. Cet outil améliore le travail quotidien des techniciens et ingénieurs, il permet des gains de

temps et facilite les saisies. Il allie innovation et rapidité.

Page 43 Denis TUR


Conclusion

Pour conclure ce mémoire, je dirai tout d’abord : le projet est réalisé et fonctionnel. En effet, les objectifs du cahier des charges de départ sont complètement remplis. Les clients

utilisent les différents modules. Ils voient au quotidien les bienfaits du système de GMAO. Les aspects accessibilité, rapidité et convivialité sont au rendez-vous. La solution d’utiliser le

langage PHP satisfait pleinement les utilisateurs. Elle est de ce fait la meilleure pour ce projet. Concernant plus particulièrement le déroulement du projet, j’ai, dans le chapitre I, parlé de

« cycle de vie en V ». J’ai expliqué alors que je n’avais pas utilisé cette méthode pour le début du projet. Je ne connaissais pas alors ce suivi. Par contre, la logique de construction du projet que j’ai utilisée est quasiment identique au cycle de vie en V. N’ayant pas utilisé cette technique dès le départ, je m’en suis inspiré en cours de route pour finaliser ce projet.

Il est certain que le processus de cycle de vie en V permet de travailler avec de la rigueur. Chaque étape doit être validée pour passer à la suivante. Il permet d’éviter de faire du ré-engineering qui génère des surcoûts.

La connaissance de ce processus me permettra, lors de futurs projets, de mettre en application

toutes les étapes liées au cycle de vie. Ce sera sans aucun doute un apport supplémentaire pour mener à bien mes futurs projets.

Page 44 Denis TUR


Les possibilités d’évolution

L’outil « FSL-TWIM » est orienté vers les utilisateurs et il répond parfaitement à leurs besoins actuels. Cependant la partie administration du système reste un point sombre. En effet, il existe bien des menus : pour gérer les bases de données, pour modifier les comptes utilisateurs, pour vérifier certaines fonctionnalités, mais ces pages méritent d’être remaniées avec plus de simplicité.

Autre point, chaque module du système FSL-TWIM peut être modifié pour évoluer avec les

besoins des utilisateurs. Effectivement, le métier de maintenance demande une remise en question permanente pour répondre aux exigences de coût, de performance et de qualité. Les menus disponibles permettent aujourd’hui de satisfaire les exigences des techniciens et Ingénieurs, mais demain les besoins vont encore évolués.

Enfin ce projet est dédié pour Freescale et le semi-conducteur, pourquoi ne pas rendre cet

outil universel, quelque soit le corps de métier. (Un choix par domaine par exemple : Aéronautique, Semi-conducteur, Transport, Automobile, etc.).

Page 45 Denis TUR


Bilan personnel

La réalisation de ce projet m’a permis de mettre en œuvre mes compétences techniques. J’ai réalisé un outil de GMAO complet qui répond parfaitement aux besoins des utilisateurs. J’ai appris à mettre en avant mes capacités de communication, d’écoute et de diplomatie pour que ce projet soit une parfaite réussite.

Il s’avère également que mon esprit d’initiative et ma créativité ont permis aux utilisateurs de

travailler plus facilement. L’aspect convivial était le leitmotiv de cette aventure. Etant moi-même utilisateur, je devais déployer toutes mes compétences pour atteindre cet objectif final.

C’est pour moi une formidable aventure technique. En effet, j’ai amplement alimenté mon désir

d’apprendre, désir qui m’anime sans cesse. L’aspect auto formation n’est pas nouveau pour moi. Effectivement, du contexte familial, pour construire une maison, en passant au domaine professionnel, pour connaître un équipement ou créer un logiciel, je recherche et j’apprends tout seul. J’ai aussi partagé et appris les techniques informatiques avec mon équipe projet, présentée en début de mémoire. La communication et le partage ont également occupé une place primordiale.

L’aboutissement de ce projet m’a fait prendre conscience de l’ampleur du métier d’ingénieur.

En effet, la structure d’un tel projet, l’utilisation des méthodes adéquates, le suivi, la prise de décision et les validations avec le client sont des actions très importantes et nécessaires. L’évolution de toutes ces notions s’est faite progressivement depuis 2002, date à laquelle j’ai commencé dans le poste d’Equipment Engineering. Je connais maintenant les outils nécessaires pour l’exécution d’un projet, aussi bien humainement que techniquement. Je sais proposer des solutions pour dynamiser la motivation de mes collaborateurs. Je sais générer un cadre de travail favorable pour une meilleure collaboration entre tous les intervenants. Enfin, je sais anticiper et je surveille toutes les dérives possibles. Le métier de technicien s’est éloigné jour après jour pour faire place à celui de l’Ingénieur.

Enfin, plus personnellement, je suis très heureux et très fier d’être arrivé à ce stade. Il n’est pas

si simple à trente huit ans de bouleverser sa vie familiale, ses week-ends et soirées pour se replonger dans la formation, la rédaction d’un mémoire, le stress d’un examen. Quoi qu’il arrive pour la suite de ma vie professionnelle, j’en sors grandi et je suis prêt à diriger et encadrer d’autres projets.

Page 46 Denis TUR


Bibliographie/Web graphie

Documents de référence

[B1] David Hoyle, « Automotive quality systems handbook: ISO/TS 16949: 2002 edition », Publié

par Butterworth-Heinemann, 2005. [B2] - Rasmus Lerdorf, Kevin Tatroe, Peter MacIntyre, « Programming PHP », éditions O’Reilly - Olivier Heurtel, « Développer un site WEB dynamique et interactif », édition ENI [B3] Cyril Thibaud, « MYSQL5 Installation, Mise en œuvre, Administration Programmation »,

éditions ENI [B4] - Jean-Patrick Matheron, « Comprendre merise », éditions EYROLLES - Di GALLO Frédéric, « Méthodologie des systèmes d’information - MERISE », cours du cycle B

du CNAM

Liens WEB

[W1] - Méthode COCOMO,

http://csse.usc.edu/csse/research/COCOMOII/cocomo_downloads.htm, juin 2009 [W2] - PHP, http://www.php.net/manual/fr/index.php, juin 2009

http://csse.usc.edu/csse/research/COCOMOII/cocomo_downloads.htm�

http://www.php.net/manual/fr/index.php�

Page 47 Denis TUR


Annexes

Annexe I : Planning prévisionnel

Page 48 Denis TUR


Annexe II : Les organigrammes de TLS-FAB

Organigramme de Freescale Toulouse FAB

Organigramme de la maintenance Toulouse FAB