Tag Archives: methodologie

DNG 2005: Outiller et industrialiser ses développements

Intervenants : Eric Groise et Jean-Louis Bénard

Avec en toile de fond la présentation de Visual Studio Team System Eric et Jean-Louis nous ont présenté le concept d’usine de dev.
Importance du concept d’intégration continue (avec une présentation de cruise control qui existe aussi bien pour java que .net) qui repose sur le build automatique et sur des référentiels de code source, d’artifact de documentation… Ces outils sont essentiels pour réussir des développements “agile” ou tirer pleinement parti d’une démarche itérative est impossible sans build automatique.
Il est important que l’usine de dev couvre l’ensemble du cycle de vie du projet depuis le recueil des besoin jusqu’à la recette (c’est ce que propose VSTS)
Concernant les outils java est en avance sur .net notamment grâce à maven qui vient de sortir en version 2.0.

Dans la démo de VSTS la présentation des diagrammes applicatifs m’a bien impressionné. Ces diagrammes sont une sorte de visio “on stéroid” dédié à l’architecture. Ils permettent de décrire l’architecture logique (les composants logiciels) puis l’architecture technique (les machines) de définir des contraintes (protocole, sécurité, bande passante…) d’indiquer la manière dont on déploie les composants logiciels sur l’architecture technique et de valider que toutes les contraintes sont bien respecté. Le tout avec du drag & drop et une interface graphique très agréable.

Pour conclure les speakers ont insisté sur l’importance des test unitaires et donc d’une architecture testable. Il n’existe pas de formule magique pour calculer le ROI des tests mais il n’y a pas à se poser la question il faut les faire on ne le regrettera pas.

Si vous n’avez pas encore mis en place d’usine de développement il faut s’y mettre.

DNG 2005: Mise en oeuvre de DSL – Domain Specific Language

Intervenant: Jean-Marc Prieur

Tout d’abord un grand bravo à Jean-Marc Prieur à qui revient sans conteste la palme de la meilleure présentation et ce n’est pas rien car le niveau était très relevé et le sujet loin d’être évident.
Après cette présentation je pense qu’il faut mettre les DSL en perspective avec la démarche MDA.
En schématisant beaucoup
MDA: modélisation UML => plateform independant model => plateform specific model => code generation
DSL: modélisation avec des outils très proche de l’UML => diagramme de classe => diagramme objet => code generation

Je vois les DSL comme proche de la démarche MDA mais en plus pragmatique plus efficace.

Un point sur lequel Jean Marc a bien insister les DSL prennent tout leur sens si vous vous appuyer sur un framework: le framework fourni les services techniques et les DSL s’occupent des 5% de code métier de Sami.

Le travail des développeurs c’est comme le gaz

Entendu à un coin de table à midi:

“Le travail des développeurs c’est comme le gaz: ça prend toute la place qu’on lui donne”

Je trouve l’image très bonne. En fonction de la pression les propriétés d’un gaz change. C’est la même chose pour un développeur: peu ou pas de pression il n’avancera pas très vite, un peu de pression il est productif, trop de pression il fait du mauvais boulot avant de finir par exploser !
Tous les gaz ne réagissent pas de la même manière à la pression, certain gaz rares ont des propriétés particulières il en est de même des développeurs.

Cette image illustre bien l’un des rôles du chef de projet: un régulateur de pression. Il doit trouver le bon niveau de pression à appliquer à chacun de ses gaz, enfin développeurs.

UML n’est pas une méthodologie

Je profite de ce billet de Bruce Eckel: UML vs OO design pour rappeler qu’UML n’est pas une méthodologie. Ce n’est sans doute pas inutile de le rappeler car énormément de cv associe Uml et méthodologie. Uml est tout juste un outil, un simple language, une collection de diagrammes qui facilitent la communication entre les différents acteurs d’un projet informatique. Bref UML est un outil très utile mais loin d’être suffisant pour garantir de bien modéliser un problème donné.

La preuve qu’Uml n’est pas une méthodologie on peut l’utiliser de différentes manières comme l’indique Martin Fowler:
Uml en tant que croquis:
On modélise rapidement une partie d’un problème pour en discuter avec d’autres personnes et avancer dans la compréhension du système. Dans ce mode l’outil essentiel reste la feuille de papier et le crayon de papier avec une bonne gomme. Si vous été fortuné un paperBoard et un marqueur seront les bienvenus 😉
Uml en tant que plan:
Le concepteur va modéliser le système à l’aide de diagrammes uml (principalement des diagrammes de classe et de séquence). Le développeur s’appuie sur ces diagrammes (des plans) pour implémenter le système. Dans ce mode un bon logiciel de modélisation est indispensable.
Uml en tan que plan peut aussi servir à faire du reverse engineering (omondo est particulièrement fort à ce petit jeu).
Uml en tant que language:
MDD.. Model driven développement. L’ensemble du système est décrit en uml. On appuie sur un bouton et l’implémentation qui va bien est généré automatiquement (c’est un peu plus compliqué que ça mais c’est l’idée). L’un des buts d’UML 2.0 est de mieux supporter MDD et MDA (model driven architecture)

On peut aussi se servir d’Uml pour la capture des besoins (c’est proche d’uml en tan que croquis): les diagrammes de cas utilisation. Mais attention l’important dans un cas d’utilisation ce n’est pas le dessin avec les petits bonhommes mais la description qui va avec. Les diagrammes de classes et/ou d’objets sont aussi de bons supports si les fonctionnels ne les rejettent pas. Modéliser un problème avec un diagramme de classe Uml force à la rigueur en laissant peu de place pour les incertitudes (à moins de tracer des relation n,n dans tous les sens).

Et vous, vous en servez comment d’uml?

Pourquoi les projets J2EE échouent

C’est le titre d’une présentation en anglais de Rod Johnson: “Why J2EE projets fails”. A voir sur theServerSide si vous avez une heure devant vous, ça vaut le coup.

En vrac les points que j’ai retenus:
– Problème de communication: échec dans la capture du besoin.
– Manque d’attention concernant les problèmes de performance
– Considérer les développeurs comme des singes et imposer un framework qui ne leur laisse aucune initiative => ils coderont effectivement comme des singes et les meilleurs quitterons le projet en premier.
– Idéologie : J2EE est le saint graal, utiliser des EJB partout…
– Mauvais travail d’équipe:
– déconnexion entre l’équipe d’architecture et les développeurs
– équipe trop grosse
– trop d’heure supplémentaires
– Pas de stratégie de test approprié
– Faible productivité: mauvais outils, machine lente, cycle de développement non adapté
Les architectures J2EE traditionnelles (les blueprint de sun) ne permettent pas d’être productif.
–    Réinventer la roue.

Pour éviter ces problèmes:
–    Méthodes agiles
–    Test driven developpement
–    Toujours commencer par un proof of concept  qui implémente verticalement une fonction de l’application pour valider l’architecture.
–    Choisir les frameworks adaptés au problème à traiter
–    Tout Automatiser
–    Faire le plus de chose possible en dehors du serveur d’application (pour faciliter les tests et accélérer le cycle de développement)
–    Déterminer avec des valeurs précises les objectifs de performance et régulièrement vérifier qu’on les atteint.

Alors vous en êtes où sur vos projets??