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 ?

[mohamine1989]

Pas seulement, mais on ne peut envisager un codage sans l’établissement d'un modèle bien structuré (UML ou autre).
Coder sans modélisation peut mener a une augmentation exponentielle de l'occupation en mémoire, et de la taille du code source.

[professeur shadoko]

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 ?

pouquoi ne pas modeliser par du code?
(qui évoluera ou qu'on jetera à la poubelle)
s'abstraire des contingences techniques est une vue de l'esprit (car elles enrichissent l'analyse).
Le rapport entre la stratégie et la tactique a parfaitement été exposé depuis le début du 19° siècle ("De la guerre" de Clausewitz) et est tout à fait valable pour des organisations modernes complexes.
Quand je fais des exposés sur UML je montre que les diagrammes du bouquin de référence sur les patterns sont indissociablement liés à C++ et qu'une conception "indépendante du langage" est une grosse blague.

[tchize_]

Oui et non. Modéliser, même en cycles courts avec du Scrum, on le fait, on décide comment va être l'architecture, quels seront les composants, comment il vont interagir.

Mais, contrairement à des développement de type waterfall, cette architecture évolue très vite, et elle reste souvent sommaire (pas besoin d'aller plus dans les détails que nécessaire). Elle peux prendre la forme d'un graphe dessiné au tableau blanc pendant un séance de brainstorming entre développeurs, d'un croquis au crayon sur le bureau de tartempion ou d'un shéma vite fait en visio qu'on change au fur et à mesure que l'on code et qui modélise comment un bloc des classes collaborent pour atteindre un but précis.

Le modèle et indispensable pour éviter de sortir une usine à gaz parce qu'on a la tête dans le guidon et qu'on ne vois pas l'ensemble. Ca doit aussi être vu comme un outils de communication, pas comme une contrainte. Au contraire, il dois pouvoir s'ajuster très vites aux contraintes techniques. Sinon, à trop modéliser dans le détail sans rien coder, on construit aussi une usine à gaz parce que les classes après on besoin de plein de petites bidouilles à gauche à droite pour arriver à s'approcher du modèle théorique.

[professeur shadoko]

bien entendu mon message était beaucoup trop étriqué
... tout à fait d'accord avec _tchize

[ego]

pouquoi ne pas modeliser par du code?
(qui évoluera ou qu'on jetera à la poubelle)
s'abstraire des contingences techniques est une vue de l'esprit (car elles enrichissent l'analyse).
Le rapport entre la stratégie et la tactique a parfaitement été exposé depuis le début du 19° siècle ("De la guerre" de Clausewitz) et est tout à fait valable pour des organisations modernes complexes.
Quand je fais des exposés sur UML je montre que les diagrammes du bouquin de référence sur les patterns sont indissociablement liés à C++ et qu'une conception "indépendante du langage" est une grosse blague.

Il ne s'agit pas d'être totalement indépendant du code mais dans un premier temps d'expliquer les choses et de partager avec des gens qui ne parlent pas "code".
Tu vas montrer ton code Java, C++ ou C# à ta MOA ?

Pour ce qui est des patterns, la modélisation qui décrit un métier n'a que faire de ces patterns. Il s'agit avant tout de représenter le domaine d'étude sans siouxerie aucune.

[tchize_]

Non, mais je ne vais certainement pas non plus lui montrer l'architecture prévue ou les modèles de données envisagés, il ne comprendra pas plus. Je me contenterais de revoir avec lui la liste des besoins et lui présenter les étapes intermédiaires du dev ^^ . Mais bon, on n'a pas tous les mêmes MOAs