jeudi 17 décembre 2009

Six ways to make people like you

Become genuinely interested in other people.

Smile.

Remember that a person's name is to that person the sweetest and most important sound in any language.

Be a good listener. Encourage others to talk about themselves.

Talk in terms of the other person's interests.

Make the other person feel important ... and do it sincerely.

Quoted from "How to win friends and influence people" by Dale Carnegie.

How to keep a disagreement from becoming an argument

Welcome the disagreement.

Remember the slogan, "When two partners always agree, one of them is not necessary". If there is some point you haven't thought about, be thankful if it is brought to your attention. Perhaps, this disagreement is your opportunity to be corrected before you make a serious mistake.

Distrust your first instinctive impression.
Our first natural reaction in a disagreeable situation is to be defensive. Be careful. Keep calm and watch out for your first reaction. It may be you at your worst, not your best.

Control your temper.
Remember, you can measure the size of a person by what makes him or her angry.

Listen first.
Give your opponent a chance to talk. Let them finish. Do not resist, defend or debate. This only raises barriers. Try to build bridges of understanding.

Look for areas of agreement.
When you have heard your opponents out, dwell first on the points and areas on which you agree.

Be honest.
Look for areas where you can admit error and say so. Apologize for your mistakes. It will help disarm your opponents and reduce defensiveness.

Promise to think over your opponent's ideas and study them carefully.
And mean it. Your opponent may be right. It is a lot easier at this stage to agree to think about their points than to move rapidly ahead and find yourself in the position where your opponents can say: "We tried to tell you, but you wouldn't listen".

Thank your opponents sincerely for their interest.
Anyone who takes the time to disagree with you is interested in the same thing you are. Think of them as people who really want to help you and you may turn your opponents into friends.

Postpone action to give both sides time to think through the problem.
Suggest that a new meeting be held later that day or the next day, when all the facts may be brought to bear. In preparation for this meeting, ask yourself some hard questions : Could my opponents be right ? partly right ? is there truth or merit in their position or argument ? Will my reaction drive my opponents further away or draw them closer to me ? Will my reaction drive elevate the estimation good people have of me ? will I win or lose ? What price will I have to pay if I win ? Is this difficult situation an opportunity for me ?

Quoted from "Bits and Pieces published by The Economic Press, Fairfield.

lundi 14 décembre 2009

Retour Model Driven Day 2009

Le 26 novembre 2009 avait lieu la journée du Model Driven organisé notamment par Objet Direct qui m'avait invité.
Je n'ai malheureusement pu assister à toutes les présentations mais le bilan fut plutôt positif et m'a permis de me remettre au gout du jour sur MDA.

Je vais présenter rapidement les présentations qui ont retenu mon attention mais vous pouvez voir les présentations 2009 sur www.mdday.fr dans la rubrique téléchargement.

1ere présentation générale sur le Model Driven Engineering par Jean Bézivin.

Présentation de l’écosysteme « Model Driven » de la génération de code à l'interopérabilité des modèles en passant par la découverte de modèle (e.g. a partir du code).
Pour rappel, Le MDA est basé sur un modèle, un méta modele et des transformations. Dans un cadre encore plus général et haut niveau, on a un système qui est représenté par un modèle lui même conforme à un méta modèle (lui même conforme à un méta méta modèle...).
Le mieux est d'aller voir la présentation vu la complexité de celle-ci il est difficile de la résumer en quelques lignes. De plus personnellement je l'ai trouvé trop éloigné de la pratique.

2ème présentation par Object Direct : moderniser son SI avec MDA

La présentation a porté sur un projet de refonte d'un projet existant fondé sur un Atelier de Génie Logiciel.
Le socle technique de destination choisi se base sur des technos éprouvés : Java, Seam, JSF, Hibernate (@JPA).
Il a fallu construire une Usine de Transformation MDA dont un des principaux objectifs fut de minimiser les risques.
Cette usine de transformation MDA a été divisée en 4 étapes :
  • Rétromodéliser à partir de l'existant
  • Renormaliser le PSM source en PIM
  • Transformer le PIM en PSM cible
  • Génerer le code source.
Très positif mais il y a des points difficiles :
  • limite à la standardisation du code
  • énormément de code à appréhender en une seule fois
  • améliorer le caractère itératif du code.

Petit tour dans l'univers dans l'univers .Net avec la 4ème présentation : CodeFluent

L'idée de CodeFluent est :
  • de modéliser n'importe quelle application manipulant des données
  • de ne pas avoir à gérer les améliorations de l'architecture .Net
  • cohérence des couches
  • utilisation de briques logicielles
Les cycles de développement sont définis dans l'ordre suivant :
  • Phase de conception du modèle ou import
  • Phase d'inférence et de génération de code
  • Phase de développement et de production
Les fonctionnalités sont nombreuses :
  • Modélisation du diagramme de classe
  • Intrégration de règle
  • fonctionnalité unique de « modélisation dynamique » par des « patterns »
  • Vocabulaire de base riche permettant de personnaliser le code généré
  • Génération de code performant et propre
  • Possibilité de modifier la génération en agissant sur le moteur de template
CodeFluent permet donc de développer n'importe quel type d'application aux normes Microsoft en prenant en construisant un Business Object Modele qui fait office d'interface forteresse avec les parties exterieurs (de l'IHM aux autres produits).
Une présentation démo montre l'intégration puissante avec l'univers Microsoft : génération d'écran sharepoint, synchronisation avec Access ou Excel.

Retour dans le monde Java avec la 5ème présentation : Celerio de la société Jaxio

L'idée est d'exploiter au maximum le modèle métier avec une génération à partir du modèle de données et une configuration de code sur lequel va s'appuyer la couche métier. Il ne reste plus qu’a traiter les cas transverse complexe.
On est dans le domaine des « Opinionated Software » tel Grails, SpringROO qui mette en avant les conventions de structure du projet sur la configuration. Jaxio met aussi une version gratuite de leur outil en ligne avec SpringFuse qui a permis d'avoir un retour sur des milliers de projet.

Enfin la dernière présentation qui fut à mon avis la plus révélatrice à propos de MDA :Model for maintenability, par Andrew Watson, OMG Technical Director

Après une courte présentation des domaines de travail de l'Object Management Group, Andrew Watson s'est lancé dans une argumentation en faveur du MDA que j'ai trouvé plutôt convaincante.
Il a commencé par un historique du métier d'ingénieur dans le cadre du design et de la réalisation des gros projets aéronautiques en prenant l'exemple du Concorde et l'Airbus.
L'utilisation de dessins (alias blue print) qui étaient ensuite retraduits en objet physique était source d'erreurs et nécessitait de nombreuses itérations.
L'utilisation de l'informatique et plus précisément des outils de CAD/CAM a révolutionné ce travail en facilitant la modélisation mais aussi les corrections.

Le constat est qu'actuellement le design logiciel ressemble plus à l'activité historique de l'ingénieurie aéronautique.
MDA prendrait alors la fonction du CAD en introduisant l'informatique pour aider à la réalisation de logiciel (MDA : computer aided manufacturing for IT).
MDA fournit une syntaxe de diagrammes et les outils pour faire ces diagrammes. Cependant la plupart des développements traduisent ces diagrammes en code à la main.

Mais c'est surtout dans la suite où il met en place les arguments principaux en faveur du MDA.
Il se base sur le cout de la maintenance qui représenterait environ 80% du cout du produit.
La maintenance étant définie selon par les standard ISO/IEC 14764 par :
  • la correction des problèmes de design
  • l'intégration des nouveaux besoins
  • l'amélioration des performances
Il en profite pour critiquer les méthodes agiles car, à son avis, elle traite uniquement la création du logiciel pas de sa maintenance (Note pour soi-même : comprendre cette guerre entre prêcheur des méthodes agiles et ceux du MDA).
Il s'appui aussi sur le fait que les technologies changent tout le temps et les systèmes deviennent bloqués dans leur cadre historique, impossible à faire évoluer (cf les nombreux systèmes bancaires en COBOL).
Enfin il nous présente des chiffres liés à des exemples de projets tests réalisés en parallèle avec et sans MDA qui mettent en valeur MDA avec moins de défauts et un temps de développement plus court. Par contre même si Disney fait parti des projets cités en exemple, je resterais prudent vu qu'il est facile de prouver tout et n'importe quoi avec l'utilisation des chiffres de quelques projets :)

Sa conclusion met en avant que les bénéfices du MDA viennent sur le long terme et qu'on ne peut plus prétendre que la technologie actuelle utilisée pour un projet ne sera pas amené à évoluer.

Pour avoir connu de nombreux travaux de maintenance sur différents projets, il est clair que sa démonstration m'attire. Cependant je reste encore prudent face à MDA qui reste, à mon avis, difficile d'utilisation. Je me pose aussi cette question : est-on sur que MDA répond bien à ce besoin de maintenance et d'évolution ?

Voila pour ma journée rapidement résumé et en espérant découvrir mieux les avantages et très certainement aussi les défauts de MDA.