Discussion :

[damien.cuvillier]

Bonjour

J'aimerais connaitre l'avis de la communauté sur un sujet dont on parle de plus en plus : les outils de développement rapide, la modélisation et l'avenir de la programmation.

Aujourd'hui, de plus en plus d'entreprises externalisent et délocalisent la production de code. Les métiers purement techniques sont de moins en moins recherchés, du moins sous la forme du développement pur.

Je suis très intéressé par cette thématique, c'est pourquoi je me suis informé et j'ai découvert tout type d'outils, allant de la modélisation UML simple (diagramme de classe et génération de POJOs) à de la programmation avec l'approche MDA (Model Driven Architecture) et de la génération de code avec JET, en passant par la génération de code à partir d'interfaces graphiques à la VB (Drag & Drop).

Ce topic a plusieurs objectifs. D'une part connaitre la "température" générale du secteur (a la fois les grands comptes et également les petits éditeurs et SSII), et également connaitre les trouvailles de chacun et l'avis de chacun quant à l'avenir de la programmation.

Bien sûr, certains pourront dire qu'il est abominable de délocaliser tout le développement d'application, mais je pense qu'au contraire nous devons nous adapter et évoluer dans le sens de la modélisation. J'ai notamment pu observer les solutions proposées par plusieurs éditeurs tels que IBM et son IDE RSA. Cela semble se développer dans le bon sens et associé avec des produits OpenSource tels que JET, il semble à portée de main, à partir d'une bonne modélisation, de générer des applications complètes.

Ce qui manque de façon évidente, c'est d'une part des distributions fiables et globales et également les ponts pour aller de la modélisation à l'implémentation de frameworks aussi divers et variés que Struts, JSF, Velocity, Behive, mais également pouvoir en changeant de "transformateurs" réaliser une application lourde avec Swing ou AWT ou encore RCP...

Que se passe-t-il dans les autres mondes (autres que la nébuleuse J2EE) dans ce domaine ?

Enfin, quels outils utilisez vous pour modéliser vos application ? Utilisez vous du retro engeneering pour que la modélisation suive l'évolution du développement au cours d'un projet? Utilisez vous la génération de code ? Quelles référence utilisez vous pour vous former à la modélisation (UML, MDA...) ?

Damien

[Mat.M]

Le message est un peu confus je ne vois pas ou tu veux en venir

Aujourd'hui, de plus en plus d'entreprises externalisent et délocalisent la production de code. Les métiers purement techniques sont de moins en moins recherchés, du moins sous la forme du développement pur.
Damien

De plus en plus j'en doute...délocaliser un projet n'est pas forcément la panacée.
C'est valable pour les gros projets par exemple bancaires mais pas pour des petits qui ne mobilisent qu'une poignée de programmeurs.
En plus il y a des problèmes culturels inhérents.

Ceci dit oui si tu veux délocaliser un projet il faut un cahier des charges et analyse bétons et surtout des responsables de projet capable d'encadrer une équipe.

Et tu parles de RAD c'est une bonne allusion car des outils qui permettent de batir des projets en théorie rapidement et générer du code n'ont pas besoin de grand apprentissage d'ou le risque de délocalisation de projets vers des pays à cout de main d'oeuvre moindre.
Pour Java j'avais fait la remarque dans le débat C++/Java : c'est le langage par excellence de délocalisation de projet mais on m'avait reproché de faire du hors-sujet

[Hephaistos007]

Tes questions sont très interessantes mais cela me demanderai un véritable travail de répondre point par point à tes questions , alors je préfère résumer ma vision ainsi :

"Une nouvelle ère dans le développement des logiciels a été amorcée. Il s'agit de recentrer les efforts sur la modélisation plutôt que la programmation. La raison est que la modélisation est bien plus proche du mode de raisonnement humain que ne l'est la programmation ou en d'autres termes, c'est à la machine de se mettre à la portée de l'homme, et non l'inverse."

[tigunn]

Bonjour damien.cuvillier,
je vais te donner mon avis qui n'engage que moi, pour moi et mon équipe.

L'externalisation c'est bien (Attendez tirez pas tout de suite) pour les gros projets, gros comptes. Ca demande beaucoup de préparation avant l'exploitation. Ce n'est pas à l'avantage direct des développeurs français.

Ensuite, il est bien heureux que de plus en plus l'approche du travail de développeur passe par une phase de modélisation. Ca évite de voir des codes imbuvables, plein de bugs, et non-upgradable (tu veux une autre version = tu recommence tout).

Enfin, l'avantage des RAD maintenant c'est que l'on y trouve des produits performants et simple d'utilisation. Je sais que certain de mes collègues utilisent des outils comme PowerAMC ou Rose mais cela uniquement dans le but de générer une doc claire et facilement modifiable en 2 clicks. Personnellement, j'ai "découvert" récemment FileMaker Pro Advanced 8.5 et c'est très agréable.

[nbodin78]

Dans la catégorie des outils MDA orientés RAD il y a aussi Leonardi de la société Lyria qaui peut etré téléchargé gratuitement http://www.lyria.com , mais c'est dans le monde Java J2EE. En dehors (.NET par ex; je ne sais pas ce qu'il existe)

[fabien-b]

Hey, dites les gens, il faudrait voir à pas foncer tête baissée vers tous les mirages marketings que vous voyez dans 01 informatique ou SVM.

Ca fait bien 2 ans que les bloggeurs anglophones (autant dire, en IT, le reste du monde) s'accordent à dire que MDA ça n'est que du vent, et malgré tout, les legendes de "grands comptes" générant du code automatiquement persistent sur les forums. Pour le fun j'aimerai bien voir des "faits" et non des vagues rumeurs. Ou des affirmations gratuites comme "Aujourd'hui, de plus en plus...". Hein damien ?

Ensuite :

- "MDA is not a silver bullet". Pourquoi ? Toute abstraction finit par faillir à un moment ou un autre. Il est impossible de complètement de capturer toute la complexité d'un programme par la modélisation, quel que soit l'outil ou la méthode. Et cela restera vrai probablement à jamais, faut se le rentrer dans la tête une bonne fois pour toutes.

- Les projets d'externalisation qui fonctionnent sont ceux qui concernent la maintenance d'un produit "fini" uniquement. Et encore. L'idée que l'ont puisse découpler l'activité de modélisation de l'activité de programmation, activités inextricablement liées et iteratives, est un pur fantasme de DSI issu d'un milieu non technique qui ne comprends rien à l'informatique et qui croit qu'on construit un logiciel comme on construit un pont.

- La vérité est dans les livres. Malheureusement, beaucoup de conneries sont aussi dans les livres. Ceci dit, sachez qu'une grande partie des problemes qui semblent nouveaux sont décrits depuis environ 20 ou 30 ans.

- Désolé de vous décevoir, mais l'ingénerie logicielle est grosso dans le même état de performance depuis des années et des années. Ni la programmation objet, ni les IDE, les RAD, les framework ou autre plateformes n'ont fait diminuer le taux d'échec des projets ou les surcouts.

Il n'y a pas de "nouvelle ère". Il n'y en aura pas de sitot. En attendant, la situation n'est pas désespérée. Mais un peu de sagesse et de recul est nécessaire.

[souviron34]

Il est EVIDENT qu'il n'y aura jamais de solution miracle.

Je n'ai JAMAIS vu au cours de ma carrière une modélisation qui marche. Oh bien sûr, ça permet de faire de belles présentations, d'être dans le vent, de se dire qu'on ne peut pas échouer, qu'on a tout sous contrôle, qu'on est sûr des délais..... Et c'est une ILLUSION.....

Quant aux RAD et autres EDI, ils peuvent faciliter la programmation (et encore, je pense que ça n'est utilisé réellement que parce qu'on utilise du personnel qu'on a formé à ça, et pas à la réflexion dans l'absolu (ou là là je sens venir les flammes .... )), mais ils ne garantissent en rien ni l'écriture d'un code propre, ni l'absence de bug, ni la maintenabilité....

[epsilon68]

ce que je pourrais juste ajouter encore d'apres mon experience,
c'est que ce sont les hommes dans le projet qui font la difference, pas les outils qu'ils utilisent.

Beaucoup de gens autour de moi pensent que le framework abc va resoudre tous leur probleme, en partie c'est vrai ils corrigent certains problemes, et en generent souvent pas mal d'autres.

Pareil pour la modelisation, c'est bien pour une vue d'ensemble, maintenant il faut des programmers qui tiennent la route derriere sinon c'est voué a l'echec.

C'est justement la tendance du moment de croire qu'on peut avoir des programmers moyens voire debutants si on a de bons architectes.

d'autre part, si l'architecte et les programmers ne sont pas ensemble, alors l'architecte perdra en experience inevitablement.

a+

[Hephaistos007]

J'ai précisé qu'une nouvelle ère avait été amorcée avec une ébauche de reflexion collective autour du développement centré-modèles. (le MDA n'est qu'une vision parmis d'autres). Je n'ai pas dis que l'on était dans une nouvelle ère. D'ailleurs, comme tu le fais remarquer ces technologies sont encore immatures et n'interessent évidemment pas l'industrie.

Simplement moi je réponds à la question du topic : "l'avenir de la programmation".

[souviron34]

Qui a dèjà vu dans sa vie une analyse ou spec système qui tienne la route jusqu'à la livraison ???????

Et de plus , comme le dit Epsilon, et comme j'avais mentionné en filigrane, tout dépend des HOMMES...

tu peux prendre la meilleure technologie possible, si les mecs qui l'utilise sont pas au top, eh ben ça marche pas....

Je me souviens d'avoir été consultant sur un très gros projet (16 ans de projet. équipe de 60 personnes. 2 millions de ligne de code. 75 millions d'euros de budget. Normes de gestion, Normes de programmation, Normes de documentation). Appelé à l'aide car finalement utilisateurs voulaient même pas tester l'appli. car trop compliquée. En 8 mois à 6 on refait 75% de l'appli (sans normes de gestion,et avec normes "élastiques" pour le reste). Satisfaction des utilisateurs (qui veulent nous acheter ce qu'on a fait). 8 mois restent avant la date de sortie du logiciel. Là le Directeur nous dit "oui, mais vous, vous coûtez trop cher". Ce à quoi on lui répond : "On est 6. On demande 4 personnes de plus, mais des comme nous et on vous GARANTI que le programme sera prêt". Décision du Directeur : il prend 20 jeunes débutants (moins cher) de plus (donc équipe de 80 personnes), et met fin à notre contrat. Résultat : 8 mois plus tard, date de livraison dépassée, et faillite. La boîte a fermé. )

C'est une constante du développement et des DSI ou autres dirigeants. Croire que, dans la production de logiciels, tout le monde est remplaçable, comme dans une chaîne d'usine. c'est FAUX.

Et donc croire qu'il exsterait une solution miracle due aux outils est une absurdité en soi... C'est comme dire (et ça se passe d'ailleurs parallèlement aujourdhui dans notre société), que parce que tu fumes pas, tu bois pas, tu fais du sport, tu mourras pas....

[epsilon68]

Je suis d'accord, meme constat de mon côté.

[fabien-b]

Simplement moi je réponds à la question du topic : "l'avenir de la programmation". Toi tu parles du présent alors forcement...

Pas vraiment, je disais qu'en terme d'efficacite et de productivite, l'avenir est essentiellement equivalent au present, modulo les abbreviations a la mode. Il faut, ceci dit, beaucoup temps et d'introspection de pour arriver a cette conclusion douloureuse mais ineluctable.

Un ou deux rites de purification peuvent aider a retrouver le chemin de la sagesse.

Et si vous voulez mon avis, la programmation, c'est trop complique pour la plupart des programmeurs. Ca, ca n'est pas moi qui le dit:

Good programming is probably beyond the intellectual abilities of today's "average programmer".

Et ca va aller en empirant, grace aux futurs processeurs multicoeurs et a la programmation parrallele. Voila ce qui vous attend veritablement, et ca sera aussi bordelique que les jours presents.

Les bugs et le code pourri ont encore de magnifiques decennies devant eux.

[Marc Lussac]

D'après mes informations, il y à quand meme plus de 50% des grandes entreprise qui ont standardisé sur UML, c'est quand même pas rien.

Et sur UML il faut aussi faire attention, les outils ne sont pas équivalents les uns des autres. Certains outils (chers) pour UML sont extrémement efficaces, et permettent non seulement la génération de code à partir d'UML mais surtout avec le même outil le réverse enginering qui permet à partir du code de mettre à jour la partie UML, bref ce qu'on appelle un outil bi-directionnel.

C'est façile d'avoir une mauvaise opinion d'une technologie qu'on ne maitrise pas bien, et en utilisant un mauvais outil de surcrois (ou un outil incomplet ou bas de gamme).

Mais quand on maitrise une technologie, et qu'on utilise un outil à la pointe, il y à des résultats.

De toute façon si aussi bien un développeur tout seul peu faire n'importe quoi dans son coin, et c'est en effet très courant (et alors la bonjour pour la pérénité de l'application si elle doit etre reprise), dans la mesure ou on est sur un grand projet, des méthodes sont indispensables, aussi bien pour l'écriture de code, que pour la gestion du travail en équipe.

Bon maintenant comme il à été écrit plus haut, dans la profession il y à des "bons" et des "moins bons", et c'est possible d'avoir une équipe qui rate avec des méthodes, et des équipes qui réussissent sans, parce que des méthodes ou des outils ne peuvent pas remplacer le talent.

Ressources :

UML (et MDA). Le Forum UML.

SCM / gestion de projets. La F.A.Q SCM. Le Forum SCM.

[Hephaistos007]

Et si vous voulez mon avis, la programmation, c'est trop complique pour la plupart des programmeurs. Ca, ca n'est pas moi qui le dit:
Et ca va aller en empirant, grace aux futurs processeurs multicoeurs et a la programmation parrallele. Voila ce qui vous attend veritablement, et ca sera aussi bordelique que les jours presents.

En gros tu dis la même chose que moi. L'informatique va se compexifier de plus en plus et il importe de pouvoir maitriser cette complexité par des abstractions. Il n'est pas envisageable d'appliquer les méthodes actuelles sur les projets de demain. Heureusement que les chercheurs se bougent le cul à votre place ...

[epsilon68]

L'informatique va se compexifier de plus en plus et il importe de pouvoir maitriser cette complexité par des abstractions. Il n'est pas envisageable d'appliquer les méthodes actuelles sur les projets de demain. Heureusement que les chercheurs se bougent le cul à votre place ...

C'est ce qu'on arrete pas de dire que ca se complexifie, alors on mets des frameworks pour abstraire ... des fois c'est bien des fois c'est beaucoup moins drole. A la fin ce qu'on sait c'est qu'il y a plein de fichier XML partout, et qu'a la fin je ne sais pas ce qu'ils apportent tellement ces frameworks.

Maintenant pour les multi coeurs, he bien je ne vois que OpenMP dans l'immediat et bien sur les threads, mais la c'est bien le talent des programmers qui vont faire la difference. J'en connais beaucoup qui disent qu'une boucle for c'est de l'algorithme alors ....

et puis les projets de demain, bien malin qui pourra nous dire a quoi ils ressembleront... certainement a ceux d'hier vu qu'on n'invente strictement rien ....

La modelisation UML et Shema de classe oui, un grand oui.
les diagrammes de sequence, oui oui oui.

... mais destinés à une doc d'architecture, pour donner les lignes a suivre et decrire un probleme et quelques lignes d'implementation.

Par contre generer du code a travers ces shemas UML, non un grand non.
Tout d'abord parce qu'il y a toujours des problemes d'implementation, et qu'il faudra toujours des vrais programmers pour y repondre, enfin plutot des vrais developers, ceux qui n'ecrivent pas betement des lignes d'ecritures ...

Je trouve ce débat intéressant parce qu'il montre bien une tendance qui est de tout vouloir modeliser et que le code soit fait "automatiquement"

Derriere cette volonté de tout modeliser a l'extreme, il y a l'offshore en demi-teinte, puis le desir obsessionel de documentation pour ne plus etre dependant de aucun programmer, ou tout du moins pouvoir les rendre interchangeable.

Par experience, je sais que cela ne marche pas, et que je reserve cette modelisation pour des documents d'architecture. Maintenant modelisation represente pour moi une vision plus reducteur (UML) que pour d'autre.

Je repondais franchement simplement d'une personne donnant son avis sur le sujet avec un peu d'experience (je pense) la autour.

[limon]

Bien sûr que les projets basés sur la modélisation marchent ! (Dans l'aéronautique, il n'y a pratiquement que ça).
Et s'il y a de plus en plus d'outils dits Model-Driven, c'est parce que le marché devient mature.
Quand à croire que c'est une tactique pour faire de l'offshore, c'est justement l'inverse !
Si nous n'utilisons pas des outils de développement plus rapides et exigeant des compétences métiers, quel intérêt y-a-t-il pour un gestionnaire moyen de ne pas externaliser ces projets la où la main d'oeuvre coute dix fois moin cher ?

[bafman]

Quand à croire que c'est une tactique pour faire de l'offshore, c'est justement l'inverse !

100% d'accord
a coté de chez moi, on a une boite qui reussi a faire certains projet pour 2 fois moins cher que ce qu'ils faisait chez les indiens il y a de cela quelques années grace a un developpement très fortement basé sur les modèles, mais surtout, sur les transformations de modèles.
En gros, ils on une grosse base de donnée de connaissances pré-programmée du genre (exemple a la con) transformer automatiquement tel classe en singleton (ca c'est simple), ou encore transformer ces 15 methode en pattern Command etc.
grace a ca, et a des outils bidirectionnels, il arrive a produire une très grosse majorité de leur code directement depuis les modèles, et quand ca ne va pas, il vont dans le code, le modifient et reviennent sur le modèle.
bref, dans leur cas, ils ne capitalisent pas sur le fait de pouvoir créer de beau modèles UML, mais sur leur experience en terme de transformation de modèles

[souviron34]

Je ne crois pas que ce soit pour faire de l'offshore, mais je pense que c'est très très très politique, dans le mauvais sens du terme (comme la fracture sociale, les délocalisations, la précarité... Dans les années 70 c'était le choc pétrolier. Dans les annes 80 c'était "on sort du tunnel"....)

Je crois que comme toute incantation de ce type, ça ne peut amener qu'à l'échec, car appliquée partout sans discernement.

Tout chose est bonne, SI ELLE EST APPLIQUEE A CE POURQUOI ELLE A ETE FAITE AU DEPART, et éventuellement à quelques retombées non prévues.. Ce n'est pas la solution miracle des problèmes de conception, de maintenance, etc..


Mais c'est comme les 35h, comme la supression des 35h, etc.. Quand ça devient un dogme et pas la solution à un problème, c'est rigide et donc inadaptable, et donc à une durée de vie finie.

[epsilon68]

100% d'accord
a coté de chez moi, on a une boite qui reussi a faire certains projet pour 2 fois moins cher que ce qu'ils faisait chez les indiens il y a de cela quelques années grace a un developpement très fortement basé sur les modèles, mais surtout, sur les transformations de modèles.

... j'espere que vous avez / aurez raison !
ce n'est malheureusement pas l'experience que j'en ai

a+

[damien.cuvillier]

Je n'avais pas vu que mon sujet avait suscité autant d'émoi. Je continue à mener mon étude. Je constate, comme on peut d'ailleurs le constater sur ce post, que les avis s'accumulent et ne se ressemblent pas toujours.

Pour les détracteurs de l'approche MDA (ou de la modélisation dans un sens plus restrictif), je confirme que j'évolue dans une société où l'approche MDA commence à se pérenniser et à faire ses preuves. Les outils deviennent matures et on commence à parler de reverse engeneering permettant ainsi de lier très fortement la modélisation et son implémentation. Ils arrivent à atteindre un taux de génération supérieur à la moitié du code total.

Sans parler d'offshore chez nos amis indiens, l'externalisation des équipes au sein des SSII a forcé de nombreux grands comptes à structurer leurs applications. Ainsi, la modélisation avancée et la génération de code associée peuvent être un outil puissant. Elles peuvent permettre de réaliser un squelette avancé des logiciels et de mettre en place des architectures normées afin de cadrer les équipes de développement. (Cependant, il est forcé de constater qu'elle prend tout son sens dans des projets de taille importante.)

Nous ne parlons pas ici autant de réduction budgetaire que de perennisation des solutions. L'approche MDA est ici une méthode d'abstraction parmi d'autres pour pouvoir cacher la complexité des solutions actuelles.

Evidemment, l'utilisation d'outils de modélisation et de génération de code ne doit pas faire croire que la maitrise technique n'est plus requise. La plupart des solutions s'orientent de plus en plus vers le schéma : une équipe de développeurs "moyens" avec dans le groupe plusieurs experts techniques très pointus.

La modélisation est une expertise très précise pour laquelle il est encore difficile de trouver une bibliographie et des références stables.

Une bonne partie du marché se cantonne à réaliser des diagrammes de classes et n'exploitent donc pas les capacités de la modélisation. De plus, la MDA a apporté une adaptabilité en instaurant les transformations de modèle à modèle.

Les nouvelles technologies et approches ont nécessairement besoin de maturation mais je pense que nous allons dans le bon sens. Il devient de plus en plus obsolète d'écrire from scratch l'ensemble d'une application

Il reste évident qu'une application écrite entièrement à la main par un spécialiste sera toujours plus performante qu'une application générée en partie. Mais je vous pose la question : que vaut-il mieux ?

• un projet cadré et maintenable, mais techniquement pas à la pointe de la technologie
• ou un projet où la qualité de rendu final et la maitrise dependra uniquement de la qualité aléatoire des réalisateurs.

Il y a d'un côté les défis techniques qui sont très intéressants mais en général réservés aux passionnés, aux étudiants et aux universitaire (laissons la recherche aux chercheurs qui la font très bien) et de l'autre côté les défis économiques et la nécessité pour les DSI de s'adapter à un marché concurrentiel ouvert de plus en plus à l'international. Ceci force les décisionnaires à chercher des solutions pour limiter les coûts de formation et améliorer la productivité de leurs équipes.