Discussion :

[ego]

Pensez-vous que modéliser avant de coder est un signe de maturité d'une organisation ?

Est-ce une évolution inévitable pour s'abstraire de plus en plus des contingeances techniques ?

[chaplin]

La maturité, c'est de faire faire quand on ne sait pas faire, voir de réfléchir à plusieurs sur le problème. Pour ce dernier point, tant que ce n'est pas clair pour soi, il est difficile d'expliquer le problème aux autres, sauf si ces derniers font l'effort de comprendre.

[Kalach]

Question pas facile ?
maturité : observer, juger, agir ???
Est-ce que l'on construit un avion sans plan?
Est-ce que l'on construit de la même façon une cabane et l'Empire State Building?

Pour les très petites applications, je dirais non à condition d'avoir des personnes compétentes.

Pour de grosses applications, ça me paraît indispensable même avec des cracs.

[slim]

Bonjour,

A mon avis, oui. C'est l'un des signes de maturité d'une organisation mais pas seulement.

Wikipedia;
D'après la définition donnée dans le CMMI, la maturité d'une organisation est le degré auquel celle-ci a déployé explicitement et de façon cohérente des processus qui sont documentés, gérés, mesurés, contrôlés et continuellement améliorés.
Un niveau de maturité (Maturity Level) correspond à l'atteinte d'un niveau de capabilité uniforme pour un groupe de processus. Un niveau de capabilité (Capability Level) mesure l'atteinte des objectifs d'un processus pour le niveau donné.

[ego]

La maturité, c'est de faire faire quand on ne sait pas faire, voir de réfléchir à plusieurs sur le problème. Pour ce dernier point, tant que ce n'est pas clair pour soi, il est difficile d'expliquer le problème aux autres, sauf si ces derniers font l'effort de comprendre.

Pas bien compris ta réponse...

[chaplin]

Lorsque les spécifications fonctionnelles sont bien détaillées, la modélisation est possible. Logiquement, un chef de projet est le coordinateur du projet et s'il n'a pas la compétence de modéliser, il doit faire appel à un spécialiste en modélisation ou alors il fait travailler les développeurs au minimum en binôme pour faire la modélisation.

Quand je parle de maturité, je fait allusion au chef de projet. C'est à lui d'insuffler la nécessité d'une bonne modélisation dans l'équipe, aidée ou non par un spécialiste si nécessaire.

[el_slapper]

Lorsque les spécifications fonctionnelles sont bien détaillées, la modélisation est possible.

+1 juste pour ça. Le reste, je me tâte.

Mais ce point là est capital : les spécification fonctionnelles doivent être bien détaillées, et à peu près figées.

Dans mon univers, la logique métier est tout sauf logique. Les spécifications sont glissantes, incomplètes, et la MOA de mauvaise foi. En bref, dans mon univers à moi, modéliser, c'est juste mettre en place une architecture générale. Pour la structure des données ou le détail des programmes, on s'adapte en fonction des évenements, et on évite les choix sur lesquels on ne pourrait pas revenir.

Après, dans d'autres univers, il est fort possible que modéliser en détail soit une bonne chose. Je n'ai pas eu le plaisir de les fréquenter.

[rmaker]

Pensez-vous que modéliser avant de coder est un signe de maturité d'une organisation ?

Comme slim le dit très bien, CMMI le met en avant.
L'intérêt pour l'organisation, c'est aussi pouvoir refiler le projet aux développeurs qui vont arriver après, pour leur expliquer les choix techniques. Modéliser (et en laisser une trace dans un wiki ou un doc quelconque), c'est dire "bon, ben, on a vu tel problème, on l'a résolu comme ça. Si vous passez après, voilà ce qu'on vous lègue".

Est-ce une évolution inévitable pour s'abstraire de plus en plus des contingeances techniques ?

Alors là, en revanche, je ne vois pas ce dont tu parles. Sur une appli en JEE, très vite, tu auras dans ta modélisation technique ( = vue de l'architecture), la mention d'un serveur d'appli, les protocoles, etc.

Si au contraire, tu parles de modélisation fonctionnelle, et de son implémentation objet ou algorithmique, c'est un signe de maturité. C'est dire "ok, on est assez humbles pour ne pas foncer comme des abrutis et le regretter après. On pose bien le problème, on définit bien le vocabulaire et ce qu'on va faire".

Est ce s'affranchir des contingences techniques? Non, pas pour moi. Ceci car:

• si l'équipe reprend un projet, elle devra faire avec la modélisation précédente, et surtout, avec les choix techniques des prédécesseurs. Dans ce cas, c'est le code qui va guider l'analyse et la modélisation (hélas! alors que ça devrait être l'inverse)
• si l'équipe est la première à prendre un projet, tout dépend du niveau de la modélisation: générale, fonctionnelle, technique, détaillée, générale. Mais dans ce cas là, comme le but c'est quand même du code, et ben, on aura une tendance naturelle à inclure les "contingences techniques" comme tu dis, donc du bon diagramme UML bien bas niveau

[chaplin]

+1

Dans mon univers, la logique métier est tout sauf logique. Les spécifications sont glissantes, incomplètes, et la MOA de mauvaise foi.

Là, tu soulignes un point intéressant, on ne peut pas être tout le temps d'accord sur tout, et on s'exprime par rapport à ses expériences professionnelles. Lorsque l'organisation est stratifiée (MOA,MOE, etc), et que l'équipe de développeur n'est pas homogène en compétence, le fait de travailler en binôme constitue une forme d'entraide et d'homogénéisation. En plus, l'idée ne vient pas de moi, c'est le CP qui l'avait mis en place, et je l'a trouve très bonne. En plus, quand il y a des conventions de programmation, c'est mieux.

Conclusion: quand un développeur ne veut pas se soumettre aux contraintes d'une équipe, ça fou le bordel.

[Luckyluke34]

Modéliser... c'est un petit peu vague.

On peut modéliser un processus métier, modéliser l'utilisation d'une application, modéliser une architecture technique, modéliser des interactions entre modules de code, modéliser des données, modéliser des flux d'échange...

Un modèle au sens large, c'est

• Une vision de la réalité présente ou future qui peut servir de plan initial pour amorcer un chantier (mais il ne faut pas se leurrer, le plan s'avèrera faux tôt ou tard).
  
• Un support de communication entre les parties prenantes sur un sujet particulier, et un vecteur du résultat de ces échanges.

Dès lors on ne peut même pas dire que modéliser "est un signe de maturité d'une organisation" puisque sans modèle il n'y a pas de communication durable donc pas d'organisation.

Je ne vois guère que les projets monopersonnels où on pourrait se passer de modéliser avant de coder (tout se passe dans la tête de la personne en question).

[CinePhil]

Je ne vois guère que les projets monopersonnels où on pourrait se passer de modéliser avant de coder (tout se passe dans la tête de la personne en question).

Mais même dans ce cas là, ça peut vite devenir le bordel !

Qui n'a jamais développé un petit truc à partir de zéro et à l'intuition, puis, à force d'ajout de fonctionnalités, a fini par se dire un jour : "C'est la pagaille, je reprends tout à zéro !" ?

[souviron34]

Bon, je ne vais étonner personne, je sais, mais j'ai voté "non"..

J'ai déjà eu l'occasion de le dire, modéliser n'est qu'un artefact, quelque chose qui pourrait être utile, mais n'est ni nécessaire ni suffisant, contrairement à ce qu'a prôné une certaine mode depuis 10 ans...

Et là aussi comme j'ai déjà eu l'occasion de le répéter, la formalisation et le découpage que cela provoque/engendre par (extrêmement fréquemment) la construction du modèle avant d'avoir bien fait l'analyse et s'être tellement imprégné de la problématique globale fait, à mon avis, non seulement perdre du temps (et la vue de l'objectif réel en se perdant dans un dédale technique et/ou technocratique) , mais surtout a imprégné les esprits comme étant "hors de ça point de salut", alors qu'il suffit de voir sur ces forums le nombre d'architectures plus ou moins farfelues, complexes, pour se rendre compte qu'il y a un problème..

En fait, c'est à mon avis le chiffon rouge agité sous le nez au même titre que "80% d'une classe d'âge doit avoir le bac".. La "modélisation" est l'argument qui ferait que même le médiocre pourrait faire un super-truc..

Je regrette et ne peut que ré-itérer ce que j'ai déjà dit : quelqu'un de brillant fera quelque chose de brillant, et pourra (éventuellement) s'aider de modèles ou en tirer un modèle... si il en a besoin.... mais quelqu'un de médiocre non seulement fera quelque chose de médiocre, mais se justifiera - et fera donc accepter par sa hiérarchie - et éventuellement ses clients - par le fait qu'il a utlisé "la modélisation"....

En bref, la technique par rapport à l'esprit..

Je considère que dans nos métiers l'esprit a une place très nettement supérieure à la technique, et que les meilleurs n'ont pas besoin d'outils "prémâchés" car leur pensée est si claire que leur "modèle" se construit, se solidifie, et s'exprime facilement...

De plus, je pense (par expérience) que la "modélisation" avant tout relève du même état d'esprit que le cycle en V, c'est à dire la "certitude" qu'on peut modéliser "a priori", alors que la pratique nous apprend tous les jours qu'il y a toujours quelque chose qu'on a oublié, et qui peut éventuellemnt remttre en cause l'architecture. Si on est enfermé dans un modèle, on se retrouve avec es coûts de modification, du modèle, de son implémentation , ainsi que du schéma de pensée chez les acteurs (architectes, programmeurs, CP..) impliqués qui deviennent vite prohibitifs..

En bref, je crois que rien ne remplace une bonne analyse, cette analyse étant conçue dans un cycle "agile", et que ce n'est que lorsqu'il y a eu suffisamment de réflexion et d'implantation (le "suffisamment" étant relativement peu défini) que l'on va arriver à un vrai "modèle" qui tient la route..

Pour terminer je citerais un exemple : dans une grosse appli nationale, bien que déjà une équipe de plus de 100 personnes aient réfléchi à un sujet et fait un soft, en démarrant un projet parallèle à 3, mais avec un groupe de réflexion de 8 personnes, il nous a fallu plus de 3 ans pour arriver au vrai "modèle" solution de la vraie architecture des données et du protocoleBD/appli.. Et même ce "modèle" a encore été remis en cause (très partiellement) 3 ans plus tard, par l'apparition d'un problème totalement imprévisible - mais suffisamment réel pur devoir être pris en compte... En résumé, même sans tenir compte de ce dernier avatar, 24 ans (3*8) de réflexion pour arriver au "modèle".. Si nous avions commencé par ça on y serait encore...

[Luckyluke34]

De plus, je pense (par expérience) que la "modélisation" avant tout relève du même état d'esprit que le cycle en V, c'est à dire la "certitude" qu'on peut modéliser "a priori", alors que la pratique nous apprend tous les jours qu'il y a toujours quelque chose qu'on a oublié, et qui peut éventuellemnt remttre en cause l'architecture. Si on est enfermé dans un modèle, on se retrouve avec es coûts de modification, du modèle, de son implémentation , ainsi que du schéma de pensée chez les acteurs (architectes, programmeurs, CP..) impliqués qui deviennent vite prohibitifs..

+1 Il faudrait arriver à enlever cette connotation certifiante et péremptoire au terme "modèle". Ou le remplacer par "schéma", "vision", "dessin"...

[souviron34]

+1 Il faudrait arriver à enlever cette connotation certifiante et péremptoire au terme "modèle". Ou le remplacer par "schéma", "vision", "dessin"...

Je pense surtout que c'est un "buzz-word" qui s'accompagne d'un matraquage sur l'utilisation de (au choix) UML/XML/designs patterns .. dû en grande partie à l'ouverture des métiers à des gens "hyper-spécialisés" et non "généralistes", c'est à dire des "têtes bien remplies" plutôt que des "têtes bien faites".. et à l'importance grandissante (mais qui a explosé il y a environ 12-13 ans) du "marketing" des outils...

La vraie notion serait (à mon avis) "ce qui se conçoit clairement s'énonce aisément"... le but de toute cette manip est d'avoir effectivement une "vision" qui permet d'avoir un "schéma" à grande échelle afin d'exprimer sa pensée de manière claire, et par conséquent de savoir ce qu'on fait (ou doit faire).

C'est ce qui était dévolu au "Chef de Projet" dans le temps (je parle comme un vieux ), avant que ça ne devienne un "diplôme"....

Dans le fond, le but de tout ça est d'obtenir l'équivalent de la plaquette publicitaire du soft, mais pour l'équipe technique : une synthèse hiéarchisée de la fonctionalité et des stuctures...

Là, c'est comme si on disait "pour être un bon mathématicien il faut suivre cette règle", ce dont tout le monde sait que c'est totalement faux...



PS: ça rejoint le débat de société sur "le choc de simplification".. A force de vouloir encadrer par des normes et des règlements, on n'empêche pas les aberrations mais on complique pour l'écrasante majorité...

PPS: en relisant le sondage, je m'aperçois que j'ai zappé une partie de la question "avant le codage"... Bien entendu qu'il faut "modéliser" un peu avant le codage.. Sinon on se lance dans un truc "à l'arrache" ou (comme un autre thead) sur la "programmation spontanée"... Mais "modéliser" ne veut pas dire "utiliser un modèle", mais simplement réfléchir...

[CinePhil]

PPS: en relisant le sondage, je m'aperçois que j'ai zappé une partie de la question "avant le codage"... Bien entendu qu'il faut "modéliser" un peu avant le codage.. Sinon on se lance dans un truc "à l'arrache" ou (comme un autre thead) sur la "programmation spontanée"... Mais "modéliser" ne veut pas dire "utiliser un modèle", mais simplement réfléchir...

Ouf ! Je préfère ça !
J'étais très étonné par ta diatribe contre la modélisation mais en fait elle était donc contre les modèles ?

[souviron34]

J'étais très étonné par ta diatribe contre la modélisation mais en fait elle était donc contre les modèles ?

oui

Disons que quand j'ai vu "modélisation" j'ai pas été plus loin.. ça me donne des boutons...

Cette religion du UML/XML/patterns ou des normes me fait gerber...

Mais je pense que ego l'enivisageait bien sous cet angle et non pas sous l'angle "programmation spontanée"..

Pensez-vous que modéliser avant de coder est un signe de maturité d'une organisation ?

Est-ce une évolution inévitable pour s'abstraire de plus en plus des contingeances techniques ?

Il parle "d'organisation" et de "s'abstraire des contingences techniques"..

Je ne pense pas que cela vise de l'écriture "à l'arrache".. ni de la "réflexion" pour produire une analyse....

[dba01]

se dire un jour : "C'est la pagaille, je reprends tout à zéro !" ?

+1 !
Ca m'est arrivé, et sur un petit projet personnel insignifiant qui aurait dû tenir largement dans mes neurones.

La modélisation est une obligation à analyser et organiser ses idées avant d'envisager la construction. En ce sens elle est utile voir même indispensable. Mais elle devient trop facilement un carcan interdisant toute mise au point. Un modèle bien conçu doit rester adaptable. Il m'est arrivé que mon "modèle" donne des idées à mon client et amène bien d'autres développements.

Une modélisation est elle-même une forme de codage. Un codage des idées. Tout dépend ensuite de la taille du projet, de la précision du modèle et de l'instabilité des idées. Je me suis vu retoquer un projet entier quand j'ai voulu changer une borne limite, au motif que "on reprendra le dossier quand vous aurez des idées claires". J'ai trouvé ça abusif.

La modélisation est un outil, mais il peut être parfois nécessaire de passer outre. Ne pas en faire un dogme.

Réponse : oui et non, faut voir.