eric.lemerdy

Aller au contenu | Aller au menu | Aller à la recherche

dimanche 12 octobre 2008

Un tour à l'exposition des 100 ans d'industrie aérospatiale française

  • Eurocopter (civil)
  • Stand Thales (avec des bonbons): simulation et satellites de Thales Alenia Space
  • Session de simulateur de vol ATR sur un simulateur de vol certifié FAA (X-plane). Sans doute après avoir répondu à la question toute la semaine, l'instructeur précise à plusieurs reprises que Flight Simulator n'est pas un simulateur de vol mais un simulateur de navigation. Dans ce genre de simulateur grand public, il n'y a pas de simulation physique poussée des paramètres. Pour le démontrer, il affiche en direct les vecteurs de force représentant la portance de l'avion.
  • Avions de chasse réels avec armement Thales
  • Le très violent Tigre d'Eurocopter
  • Le tout nouveau radar de Thales, le Ground Master 400: un radar mis à jour par internet...
  • On finit en douceur avec un drone avec une propulsion à hélice en bois. Normal, la durée de vie d'un drone sur le champ de bataille: 3 mois seulement.
Jouant sur la fibre patriotique des visiteurs, l'exposition permet de réaliser un tour d'horizon des produits phares de grandes entreprises impliquées dans l'industrie de la défense et de l'aéronautique. On sent leur volonté de présenter sous leur meilleur jour au public les activités de leurs groupes. Un immense pavillon était dédié au recrutement. Leurs besoins sont en croissance.
En tant que visiteur du dimanche, j'ai particulièrement apprécié la séance de simulation d'ATR et les bonbons Thales, l'écran géant avec des images du lancement Ariane 5 était un beau défi technique avec un gros contre jour et une qualité d'image impeccable grâce à des matrices de led tricolores comme notre bon vieux tube cathodique.

slider flash parAlsacréations. Dewslider

dimanche 21 septembre 2008

Se rencontrer pour apprendre et partager

Logo-Valtech-Days-2008-web.gif Les Valtech Days 2008 se dérouleront les mardi 21 et mercredi 22 octobre 2008 à La Défense, soit dans un mois jour pour jour.
C'est un évènement qui permet de se tenir au courant des dernières avancées en matière d'agilité, d'industrialisation, d'architecture et de technos web.
Ce que je conseille, c'est de jeter un œil aux présentations et "white papers" de l'année dernière. Je l'ai fait moi même et j'ai été ravi de mes lectures. Les sujets sont pointus et ceux de fond sont toujours pertinents un an après ! Notamment sur la Gestion du Cycle de vie des Applications...
Je conseille notamment: Voir aussi le compte-rendu d'un bloggeur de developpez.com.

mardi 9 septembre 2008

Aperçu sur IBM Rational Team Concert

jazz.net: l'indispensable site d'information sur la plate-forme.
jazz.net/blog : le blog de l'équipe dont le leader est actuellement Erich Gamma (l'un des co-inventeurs des Designs Patterns, excusez du peu)
L'équipe à l'origine de jazz est aussi celle qui a vécu le développement d'eclipse. L'IDE étant un succès et quasiment un sujet clos, l'idée du repository central était le dernier sujet à implémenter chez Rational. Ce fut pour cette équipe l'occasion de faire persister la même ambiance d'équipe ainsi que la collaboration avec des entités extérieures. Au sein d'IBM, les équipes qui testaient les premières version de jazz sont longtemps restées isolées pour maintenir le "secret" autour du projet, une façon de protéger les équipes de développement afin qu'elles puissent donner le meilleur d'elles mêmes.
Côté bonnes nouvelles, RTC est une application eclipse RCP mais basée sur les bundles eclipse.org et non pas ibm.com.
RTCabout.png
Ce qui permet d'utiliser dans RTC des plugins compatibles Eclipse.
Pour l'auditoire orienté 'management' ou les clients finaux, l'application web a beaucoup séduit. En effet, l'organisation de l'application lourde sera réservée aux développeurs habitués à eclipse tandis que l'application web assez soignée permet de bien visualiser les métriques et les indicateurs. A noter que les dashboards ne sont pas inclus dans la version express.
blog-dashboard1.png
Au niveau du scope, la solution est clairement adressée aux PME et aux petites équipes. RTC adresse la phase de développement : la gestion des changements, la gestion de configuration, la collaboration et la gestion du build continu. L'outil est fonctionnellement déjà puissant. Mais comment fournir de si nombreuses fonctionnalités sans tomber dans les travers de l'usine à gaz ? IBM avait en effet du mal à recruter des consultants capables d'installer et de configurer ses produits ! La lourdeur des produits était un handicap à leur adoption. L'idée derrière RTC est que si l'on ne peut pas convaincre avec des produits certes puissants mais trop lourds, il faut alors simplifier et rendre accessible sa technologie en repoussant les limites de l'utilisabilité. Les "early adopters" semblent conquis mais il s'agit déjà d'aficionados d'eclipse et autres experts des plug-ins. Etant moi-même développeur d'application RCP, j'avoue avoir trouvé le produit assez affuté.
Tout l'enjeu de RTC sera de poser des concepts suffisamment simples et consensuels (work items, stream, etc.) afin que leur implémentation dans l'outil ne reproduise pas les lourdeurs des produits maison dont il est l'héritier.

vendredi 22 août 2008

TDR Applied

Last week, we used TDR[1] to help us understand a problem and the solution finally emerges.

The problem

This is an eclipse RCP application that uses the well known MVC pattern. The data model is hierarchic and several editors can be opened at different levels. The problem is that we have some transversal data that can be viewed along the tree structure. How can a view be always updated against users editions ?
Considering the following structure:
  • root
    • node1 - use transverse data X, Y
    • node2 - use transverse data X, Z
Description of the scenario:
  1. Editor on node 1 is opened
  2. Editor on node 2 is opened
  3. Some changes are made in editor 1 on transverse data X
    The editor is "dirty".
  4. Some changes are made in editor 2 on transverse data X
    The editor is "dirty".
  5. Editor 1 is saved.
How can the changes on transverse data X made in the first editor be reflected in the second one ?

Solving the problem

We shortly came to the fact that an event should be fired when the data model is changed. Editors are registered to listen for those events to make them aware that they should reflect changes. This is not the complicated part of the problem.
The "reconciliation" algorithm that the editor should implement is not trivial.
This was the time to stop trying to code it, step up the team in front of a blank white board and use TDR[1] to help us specify with some examples.

The white board

After a short discussion, we found a notation to represent data attached to an editor:
Saved
saved data before any edition
Modified
modified data during edition. This is typically a bean that is tied on UI components
Data model
the new data model that is embedded in the event to alert editor that data changed
Output
the output of the algorithm: the reconciliated data
(Our data are indexed list of objects.)
Then we started to scratch on white board. The white board has been "saved" on this sheet:
TDR_applied.png
Then we set up test cases from simple to complex (1.). For each of them, we specify data (2.) as couples: CA, DA (Clé (key), Data) and CA', DA' for modified data.
The final algorithm emerges in the box (3.). The result is simple:
  • if the "Saved data" is the same than "Modified data"
    • "Output" should be set to "Data model"
  • otherwise
    • "Output" should be set to "Modified data"
Big letters in output column learns us that algorithm applied for list comparison can be also be applied for list elements themselves when the case become more complex.

Lesson learned

  • TDR[1] is helping emerging conception
  • Examples from a TDR[1] session are capitalized in unit tests (in our case)
  • This TDR[1] session became the technical documentation (because the client want a technical documentation)
  • Our examples remains generic because we found it useless to represent real data (a collection of objects
  • TDR[1] is helping to make the implementation of a solution simpler
  • The client were intrigued to see programmers out of their usual 'behind-the-screen' position ! It helps our team to show what we were working on.


[1]: Test Driven Requirements ou spécifications dirigées par les tests.

mardi 29 juillet 2008

Overview of Eclipse RCP UI testing tools

-All datas collected during Summer 2008-
Product Type Licence Source Status
Abbot framework (AWT/SWT) open source Sourceforge alpha for SWT (but seems pretty stable)
Costello recorder (AWT) open source Sourceforge not ready for SWT
GUI Dancer recorder commercial Bredex GmbH new version in july 2008
JDemo framework open source Sourceforge 2008
Mercury WinRunner recorder commercial Mercury End of support (feb 2008)
QF-Test recorder (XML/Jython) commercial Quality First Software GmbH - Kapitec (FR) 2008
Rational Functional Tester recorder commercial IBM
SWTBot framework (SWT) open source ThoughtWorks not fully SWT compatible but ThoughtWorks can be considered as trustable.
TPTP Automated GUI Recorder (AGR) recorder (XML/Java) open source Eclipse.org maintained ? but "as-is" component
WindowTester hybrid (java) commercial / free for opensource commiters Instanciations high quality product
This matrix is based on this article from the WindowTester architects ; this product list is enforced with the following post comments where people chat about their uses.
Feel free to visit the del.ico.us links where I store framework's related ressources on the fly. I am working on this subject until a satisfying product can be identified, so I will add some new links soon (screencasts and tutorials are the forthcomming waited material). I am glad that the Eclipse community is doing a substantial effort in 2008. For exemple, there was less submissions on this subject for EclipseCon2007 last year.

lundi 28 juillet 2008

De retour de la session TDR

En avant première, Gilles Mantel a réuni les praticiens de Paris ce soir pour nous faire partager sa session "Test-Driven Requirements: beyond tools" qu'il donnera le 5 août 2008 à Toronto à l'occasion de la conférence Agile 2008.
A travers deux expériences ludiques et leurs rétrospectives, il nous montre en quoi les exigences dirigées par les tests peuvent aider les clients à obtenir avec moins d'efforts ce qu'ils veulent vraiment.

TDR - Le jeu

Le premier jeu montre la distorsion du besoin initial exprimé par le client lorsqu'il passe par un cycle de développement d'un produit:
TDR.png (src)made with the lego tag in openclipart.org
Le produit est ici un parcours de billes et de dominos que seuls les utilisateurs vont pouvoir bâtir. Le 'product owner' (ou client) fait alors son apparition et doit étudier le modèle. Le développeur entre à son tour et doit reproduire le modèle sur les seules indications orales du product owner qui ne voit bien sûr pas le travail en cours du développeur. Le testeur doit quant à lui écouter les informations et c'est lui qui qualifie la livraison finale du développeur aux utilisateurs.

TDR - Expérimentations

Le second jeu permet au public d'expérimenter l'expression de besoins et les spécifications par les tests:
Un memo vient de tomber: une idée géniale a germée dans le service R&D et il faut recueillir ce besoin et le spécifier le plus efficacement possible afin d'intégrer cette idée au système d'information de la société ! Une réunion est donc organisée entre le porteur du message et l'équipe d'analystes et de développeurs réunie pour l'occasion.

Par l'expérimentation sur ce cas concret, on adopte intuitivement une démarche ou chacun est poussé à griffonner sur son papier pour comprendre le problème. Une fois le problème mieux cerné, on cherche à trouver un accord sur le formalisme à employer pour la spécification et les tests associés (les exemples de cette spécification). C'est un exercice enrichissant qui laisse le formalisme émerger à la différence des tests fonctionnels actuels où un outil en impose souvent la forme (par exemple des tableaux pour FIT ou du texte illustré d'exemples pour Concordion).

Je suis toujours enthousiaste après les réunions des praticiens. C'est un groupe où l'on découvre toujours énormément de choses par la pratique, une expérience toujours unique. Merci à Gilles qui va pouvoir assurer une animation au top niveau à Toronto.

dimanche 29 juin 2008

Bilan du SI de notre asso d'anciens

Que pensez-vous des discours mettant en avant la débrouillardise et les talents de bricolage des réalisateurs de SI? Cela amène l'industrie à admirer les héros de l'artisanat et des heures supplémentaires... Que répondre alors à la question ouverte: "Comment bâtir un système d'information industrialisé qui réponde aux besoins de ses utilisateurs en minimisant la composition anarchique de développements spécifiques ?". Cela passe sans doute par une plate-forme standard, robuste, ouverte et extensible, bref, le Graal du Système d'Information.
Je vais prendre de cas du système que nous avons mis en place avec des collègue>s étudiants pour construire le système d'information de notre association d'anciens du Master GLR.

L'Amglr, une association de gestion d'anciens étudiants.

Créée en 1987 pour promouvoir le DESS IF (Informatique Fondamentale), l'association s'appelait alors ADESIF (Association des Diplômés d'Etudes Supérieures d'Informatique Fondamentale). L'existant pour nous en 2005 était donc un listing d'anciens adhérents qui allait constituer notre base initiale d'adhérents. Après avoir pris la décision de remonter l'association, le besoin d'un système d'information s'est fait naturellement sentir à la fois pour la gérer et pour fournir les services aux étudiants.

Des besoins...

  • Une Association loi 901: des adhérents, des statuts "classiques", un bureau pour animer tout ça et une trésorerie : un système d'information dont les données métier sont centrées sur les adhérents (attention à la loi sur les fichiers de personnes physiques, déclaration à la CNIL conseillée), pas de comptabilité compliquée dans notre cas.
  • Des anciens étudiants: but d'insertion professionnelle, maintient de relations, évolutions de carrière, mise en relation de personnes : réseau social.
Les besoins tournent donc autour de ces concepts:
amglr_needs.png

...et des contraintes

Contraintes du SI
coût global gratuit si possible (sauf nom de domaine)
licence les licences libres ont plus de chance d'être gratuites...
serveur linux, php, MySql (hébergement amical par un membre du bureau)
coût de main d'oeuvregratuit (bénévolat des membres du bureau)
type de système distribué et accès web (ou en tous cas très ouvert)
sécurité assez forte pour ne pas dévoiler les informations personnelles des membres

Cartographie actuelle de la solution

amglr-archi.png
  • Utilisation de produits:

    Le choix du CMS s'est porté sur le produit phpbb couplé à un "mod" Gf-portal permettant de définir en plus du forum, une arborescence de pages statiques ou dynamiques. La qualité des produits phpbb est parfois inégale. Cependant, nous n'avons pas rencontré de problèmes notables en utilisant ce couplage.

    Par la suite, un planet a été installé pour fédérer les blogs des adhérents volontaires.

  • Personnalisations du produit:

    Style: Par installation et modification d'un thème additionnel.

    Contenu statique: Autant de temps que de rédiger des pages HTML standard, l'intégration dans le portail demandant un temps négligeable.

  • Développements spécifiques:

    Contenu dynamique: La fiche adhérent a été un peu laborieuse (php basique), la géo localisation fut l'occasion pour l'auteur de cette partie de reprendre un code qu'il avait déjà écrit pour un autre site. Tandis que l'annuaire en ligne est l'intégration au portail de l'export XML de la base adhérent mise en forme avec un template XSLT.

    Génération dynamique de l'annuaire: Un "wizard" est mis à la disposition du bureau par Java Web Start pour générer l'annuaire pdf complet. Les technos sous-jacentes sont: Swing, FOP (donc XML et XSL-FO) et XSLT. Pourquoi un choix si atypique dans cette architecture full php/MySql? Pour des raisons de compétences (ça n'arrive pas en entreprise, on aurait loué a ressource compétente ;-) ) et Java Web Start car java n'était pas installé côté serveur.

    Outils fournis par l'hébergeur: une adresse mail pour le bureau (avec antispam), des statistiques (WebDruid)

Retrospective

"What went well?""What did not go so well?"
  • Couverture fonctionnelle assez étendue
  • Taux d'utilisation des services par les adhérents
  • Continuité de service (grâce à notre hébergeur)
  • Coût (grâce à notre hébergeur)
  • Hétérogénéité des technologies
  • Multiplication des produits installés, peut rendre la maintenance difficile
  • Un SI sur internet génère beaucoup de SPAMs (mail et ouvertures de compte...) contre lesquels il faut apprendre à se défendre.
  • Une fois que le système est en place, changer les choses devient plus compliqué : inertie du système...
  • Séparation des données entre le référentiel d'adhérent (données métier) et les comptes forum (dans l'applicatif): cela aboutit à une fiche adhérent pour éditer les données métier et un profil pour le forum...
Le meilleur jugement sera celui de nos successeurs car ce sont eux qui vont assurer la suite, je suis finalement curieux de voir les bonnes idées qui nous ont échappé. Il faut peut-être chercher à utiliser une plate-forme de service en ligne de communautés de type web2.0. Ce business model est déjà déployé par certains sites comme ning par exemple. De plus, je constate un certain éloignement du bureau actuel par rapport à la dernières promotions qui n'utilise presque pas les services. C'est réellement le moment de changer pour conserver cette proximité nécessaire entre les animateurs de l'association et les promotions courantes.
En tous cas, ce fut pour moi un bon moyen de me rendre compte de la difficulté de fédérer des gens sur un si petit dénominateur commun (une année de Master pro.). C'est une expérience qui m'a donné confiance. En prenant les choses en mains avec des collègues, nous avons été capables d'aller plus loin qu'on aurait pu l'imaginer au départ. On se surprend alors du temps qu'on peut passer sur le sujet. Ca a permis de mieux me connaître et de comprendre ma relation au travail. J'ai alors compris que j'avais une forte capacité de travail aussi longtemps que la motivation de l'atteinte de d'objectif était présente (Génération Y?). J'ai aussi pris conscience de la valorisation mais aussi du risque associé à la charge d'une responsabilité.

Quels objectifs pour l'avenir?

A l'heure où la tendance du recrutement (en apparence du moins) cherche moins les profils "formatés" des écoles que les expériences personnelles des candidats, la valorisation des filières de Masters Pro. passe sans doute par une meilleure visibilité de la formation au niveau national voire international. Un réseau d'anciens à la fac peut être cet outil qui démarque un Master pour son attraction des étudiants entrant ainsi que pour la qualité des débouchés professionnels. Cette période très favorable aux candidats sur le marché actuel ne permet pas de tester la facilitation de l'insertion professionnelle mais l'ADESIF a déjà montré par le passé son efficacité pour l'insertion professionnelle.

vendredi 20 juin 2008

Technology Readiness Levels

A l’extérieur de votre organisation est le chaos, les technologies naissent et meurent en fonctions de facteurs incontrôlés et incontrôlables (les effets de mode, la réglementation en vigueur, la volatilité des marchés, etc.).
A l’intérieur de votre organisation règne l’ordre, la maîtrise technologique, mais c’est aussi le royaume du « legacy-qui-marche-bien-pourquoi-on-le-changerait ». L’obsolescence des applicatifs vous guette, vous êtes fan des nouvelles technologies mais l’entropie de votre organisation ressemble à des sables mouvants qui ensevelissent toute action pour tenter d’y échapper. Comment alors stabiliser la technologie alien qui serait propre à sauver votre organisation de la décrépitude numérique ?
Il existe pour cela la méthode des Technology Readiness Levels (TRLs) pour vous sauver. C’est une méthode qui permet d’évaluer une technologie nouvelle pour la qualifier apte à supporter le développement de vos nouveaux produits. Voici les degrés d’avancement de la méthode (Origine: DOD (2006), Defense Acquisition Guidebook) :
  • TRL 1: Principes de base observés et signalés
  • TRL 2: Concepts et/ou applications de la technologie formulés
  • TRL 3: Fonction critique analysée et expérimentée et/ou « proof-of-concept » la caractérisant
  • TRL 4: Validation de l’artefact produit en conditions expérimentales
  • TRL 5: Validation de l’artefact produit en conditions de pré-production
  • TRL 6: Démonstration du modèle du système/sous-système ou du prototype en conditions de pré-production ou de production
  • TRL 7: Démonstration du prototype du système en conditions de production.
  • TRL 8: Complément du système résultant et « qualification » pour la production à travers des tests et des démonstrations (environnement de pré-production ou production)
  • TRL 9: Exécution du système résultant « prouvée » à travers le succès de la version en production
NASA_TRL_Meter.jpg Plus on avance dans la méthode et moins on doit avoir de technos candidates qui passent les conditions nécessaires. C’est un peu comme cela que fonctionnent les organismes de recherche qui ne font pas aboutir toutes leurs recherches avec une application fonctionnelle et encore moins industrialisable.
Cette méthode a été développée par la NASA. J’ai adapté les termes à un produit logiciel. Par exemple, citons cette analogie : leur environnement de pré-production est le sol et celui de production de l’espace. Je pense que si c’était le cas en informatique, il y aurait sûrement plus de candidats à aimer la prod…
Ce processus est « outillé ». Un calculateur d’avancement réalisé avec Excel permet de suivre l’avancement au sein de la méthode. Attention, les couleurs piquent un peu les yeux… On peut décider de s’évaluer au choix avec le TRL, le Manufacturing Readiness Level et les Programmatic Readiness Level. Cela ajoute plus ou moins de questions au formulaire pour calculer l’avancement.
Voici la fiche de ce programme excel à télécharger (et sa documentation pdf - 16 pages)
TRL_Calculator.png
Cette méthode est utilisée dans la société de ma mission actuelle comme base au processus de travail de l’équipe R&D. Ils ont des jalons à chaque degré avec des documents types à produire. Cette méthode qui a fait ses preuves aide effectivement à atteindre l'objectif qu'elle se fixe. On ne peut malheuresement pas tout rendre agile. Par contre l'agilité peut permettre de gagner en rapidité sur les "proof-of-concept" ce qui peut augmenter la taille de l'échantillon des technologies candidates et ainsi renforcer la fiabilité et la pertinence du choix final.

mercredi 28 mai 2008

Travaillez-vous mieux sous pression ?

La pression exercée sur une équipe permet parfois de la stimuler ou de garder un bon niveau de motivation. Mais quand cette pression devient trop grande, la contre-productivité augmente... Voici un graphique issu de la pensée "lean" qui m'est apparu très clair lorsque Bent Jensen nous l'a exposé il y a quelques semaines.
agile_team_pressurepressure.png(src)
Ce que je remarque surtout, ce sont les gaspillages engendrés par des délais de livraison trop long. La pression en début de phase est insuffisante, on risque de pas assez bien utiliser un temps pourtant précieux. Avec des livraisons plus rapprochées, on conserve une pression quasi constante proche d'un niveau toujours acceptable.
Je pense qu'avec des arguments simples mais percutants comme celui-ci, on peut débattre sans choquer avec son équipe trop habituée au rythme "industriel à la française".

My brother is back

I am very pleased to announce my twin's first post since 2006 ! Visit now his blog : sebastian.lemerdy.free.fr !

- page 2 de 10 -