Discussion :

[grunk]

Bonjour à tous,

Après quelques années en milieu professionel et quelques sociétés visitées , je me demande si la conception pure et dure existe ailleurs que dans la théorie.

A l'école , il était hors de question de toucher un clavier avant d'avoir modélisé les use case , les diagrammes de classe et j'en passe. Comme beaucoup de développeur je n'était pas vraiment fan mais je me pliait à la règle du jeu.

Sortie de l'école j'ai l'impression que la conception disparaît complètement. EN 5 ans je n'ai pas vu l'ombre d'un diagramme quel qu’il soit et quelque soit la complexité du programme.
Quand je commence un développement je me gribouille toujours un petit quelques chose pour avoir les idées directrices , mais je serait bien incapable de faire un diagramme UML aux normes. La seule fois ou je me suis imposé une étude complète :
1- les spécifications changeaient tellement souvent que la plus part du travail en amont n'avait plus aucune valeur.
2- Le temps passé en conception n'était pas perçu comme productif par les supérieurs non technique , qui ne jurent que par les interfaces qui brillent ...

D'où ma question , comment cela se passe t'il pour vous ?

[souviron34]

Dans le Web chsaipas..

Ailleurs (dans l'industrie et la recherche industrielle),la conception a une très grande place

[ego]

Ben disons que là où je travaille, on essaye de faire de la conception UML.
Est-ce mieux ou pas mieux que de faire du code tout de suite ? Les "Agiles" ou tout au moins certains d'entre eux ont probablement une opinion.
Personnellement, je puis te dire que sur certains sujets complexes, je ne vois pas comment faire sans modéliser un minimum, surtout la partie "Entités métier" (~MCD du monde Merise)
Le problème est aussi lié à ton organisation. Chez nous, on a beaucoup de sous-traitance et on doit donner des documents expliquant ce qu'il faut faire (ce qu'il faut coder). C'est donc plus simple et plus homogène de faire de la conception UML. Si on avait les développeurs en direct, je ne dis pas que ça serait la bonne solution (tout en gardant à l'esprit ce que j'ai dis sur les problèmes complexes).
Pour terminer, même si on a pas réalisé le truc ultime, nous avons beaucoup développé de générateurs à partir d'UML, tout ça pour dire que UML tout seul ou plutôt les outils UML ne fournissent pas toujours en standard ce qu'il faut pour être utilisés efficacement dans une entreprise; ceci explique donc peut être cela ( = il faut de l'investissement)

[wiztricks]

Salut,

Les outils de conception (UML ou autre) permettent de traduire le travail qui devra être réalisé et de l'organiser en amont du développement proprement dit. En gros, çà produit "des plans" de construction.

S'il est clair qu'ils sont nécessaires dès que le projet est long/difficile/devant couvrir différents aspects non fonctionnels comme on le rencontre dans les process industriels ou informatique embarquée...
=> traçabilité des exigences, encadrement des sous-traitants, couverture fonctionnelle des plans de tests voilà des domaines qui nécessiteront souvent une étape de conception "classique".

Nombre de projets se résument souvent à intégrer/adapter quelques fonctionnalités métiers dans un framework. J'exagère mais les "frameworks" obligent à une certaine organisation et, avec de l'expérience, vous savez ce que vont coûter a réalisation de vos fonctionnalités en s'appuyant sur eux.
A partir de là, l'utilité d'une phase de conception "classique" devient "discutable".

Quand je commence un développement je me gribouille toujours un petit quelques chose pour avoir les idées directrices , mais je serait bien incapable de faire un diagramme UML aux normes. La seule fois ou je me suis imposé une étude complète:
1- les spécifications changeaient tellement souvent que la plus part du travail en amont n'avait plus aucune valeur.
2- Le temps passé en conception n'était pas perçu comme productif par les supérieurs non technique , qui ne jurent que par les interfaces qui brillent ...

Les réalités sont que les "métiers" qui poussent les développements n'ont pas toujours une idée très précise de ce qu'ils souhaitent: il n'y a qu'à partir du moment ou vous allez être capable de leur montrer des choses qu'ils vont constater que ce n'est pas ce qu'ils attendaient ou mieux, cela pourra leur ouvrir de nouvelles perspectives qui risquent de foutre en l'air les options initiales.
Les méthodes "agiles" essaient de mettre en place des structures projets qui puissent répondre à ce genre de "contexte". Un des principes d'une conception agile est la procrastination: ne jamais fermer une option avant d'en avoir besoin... Au lieu d'anticiper ce qu'on va devoir réaliser et fermer les options, on part de l'hypothèse qu'au plus on ferme au plus les changements seront douloureux...
- W