Le sens de la Mesure

J'interviens de temps en temps sur des mises à jour ou évolutions de programmes réalisés par d'autres, plusieurs années auparavant. Je tombe souvent sur des programmes bancals, au comportement mal maitrisé (surtout si on a changé de compilateur entretemps).

Voici d'après moi quelques principes fondamentaux, qui facilitent la mise au point du programme, et qui permettent d'obtenir un programme stable et évolutif :

• utiliser les machines d'état pour tous les séquentiels.
• séparer les grandes fonctionnalités dans des boucles spécialisées. Cette séparation découle de l'analyse et de la conception de l'application. On pourra par exemple avoir des boucles séparées pour : la gestion des évènements utilisateurs, la gestion de l'aspect de la face avant, le séquentiel de test, la gestion des erreurs, la communication avec un PC superviseur, etc.
• utiliser une programmation modulaire, avec pour chaque module un VI 'pilote'. On peut s'aider en créant des librairies dont les sous-vis sont
• limiter l'emploi des variables, et utiliser au maximum le flux de données. Personnellement je limite l'utilisation des variables globales à des données de paramétrage, fixées au lancement du programme.

Je reviendrai sans doute sur ces différents points par la suite.

lorsque je voyage, je préfère de loin le train à la voiture. Mais hier, ma fidélité a été mise à rude épreuve. Voici une petite liste de mes (mes)aventures :

• le train Annemasse-Lyon arrive avec 10 minutes de retard (j'avais 13 minutes pour la correspondance), en effet le train était bien plein (c'était un retour de week-end), et on perdait pas mal de temps à chaque arrêt pour laisser monter les nouveaux voyageurs.
• à la gare de Lyon Part-Dieu, impossible de changer de quai : les personnes qui voulaient monter dans mon train (qui repartait dans l'autre sens) empêchaient ceux qui en descendaient de quitter le quai.
• le TGV est parti avec 10 minutes de retard (heureusement pour moi !) car une des rames de TGV avait dû être changée in-extremis pour un problème de motrice. Ceux qui comptaient manger dans le train furent contraints à la diète, car la voiture restaurant n'avait pas pu être approvisionnée.
• A l'arrivée à Paris, on nous a annoncé un retard supplémentaire de dix minutes, pour des "problèmes de circulation"

Les retards étaient faibles, me direz-vous, et le problème rencontré pour la mise en place du TGV m'a permis de ne pas louper ma correspondance...Certes, mais ce sont autant de problèmes révélateurs de processus mal maitrisés... Si on veut vraiment développer les transports en commun (pour différentes raisons, comme les émission en carbone, ou parce que ce sont des emplois non délocalisables), il faut impérativement améliorer et maitriser les processus actuels.

Ce billet est le premier de la catégorie LabVIEW, dont voici l'objectif.

Il ne s'agit pas pour moi de faire un cours sur LabVIEW dans ce blog. Cependant, assez souvent lors des formations que j'anime, des stagiaires m'amènent des problèmes concrets qui les bloquent, et en guise d'illustration, je leur propose une solution possible à partir des concepts vus en cours.

Je me suis dit qu'il pourrait être intéressant de conserver ces exemples (lorsqu'ils ne sont pas confidentiels) et de les mettre à disposition des autres stagiaires. Cette rubrique sera donc destinée à partager des exemples de codes résolvant des problèmes concrets, ainsi que des trucs et astuces utiles. Le code sera disponible au format png, en version LabVIEW 2009 (en attendant la prochaine version...), par exemple :

Pour les lecteurs qui ne connaissement pas LabVIEW, voici une rapide présentation de ce langage de programmation graphique, orienté test et mesure ...

La roue de Deming, aussi appelée "cycle PDCA", est un outil à la fois simple et efficace pour améliorer les processus et les produits. Relativement ancien, il a connu un regain de popularité dans les pays occidentaux depuis la version 2000 de la norme ISO 9001, qui préconise son utilisation pour améliorer de manière continue les processus du Système de Management de la Qualité.

Cependant, la roue de Deming n'est pas que cela : c'est aussi une méthode simple et accessible à tous, pour mettre en œuvre la démarche scientifique,

Il y a quelques années, je travaillais au service qualité d'une usine de production. A l'issue d'un audit de certification, je discutais avec l'auditeur missionné par l'AFAQ. Celui-ci m'expliquait qu'il avait fait partie du comité de rédaction de la norme ISO 9001 version 2000, qui met l'approche processus en avant, mais avec le recul, il se demandait si cette approche processus était vraiment un gage de performance et de qualité pour les entreprises.

Après avoir muri la question quelques années, m'être beaucoup documenté, je peux enfin lui répondre (et je vais vous en faire profiter) .

L"ISO 9001 est une norme internationale qui a pour objectif général la maitrise de la qualité dans les entreprises (ou plus généralement tout organisme). On peut cependant constater qu'entre l'esprit (l'objectif) et la lettre (certaines applications), il peut se produire des dérives qui vont à l'encontre de l'objectif poursuivi.

Je prépare actuellement une série de cours sur la Qualité (j'aurai l'occasion d'y revenir). En faisant quelques recherches sur internet sur des cours existants, je suis frappé par le fait qu'on y aborde la Qualité sous un angle très 'technicien' .

Par exemple, on y aborde la norme ISO 9001 et ses différents aspects : approche processus, procédures obligatoires, engagement de la direction, planification des ressources, audits, etc. On y aborde aussi des techniques avec une forte coloration mathématique : Pareto, calcul de capabilités, de variabilité, etc.

Bref des approches très techniques, mais je ne suis pas sûr que cela donne envie au néophyte de s'intéresser à la Qualité. De plus tout ce jargon et ces outils laissent penser qu'il s'agit d'une affaire de spécialistes !

Pourtant, la Qualité intéresse tout le monde, mais il faut se rappeler à quoi sert elle sert, et pour quoi on la recherche...

(à suivre)