Discussion :

[hegros]

Je suis pas d'accord avec Hegros, désolé
Pourquoi RUP doit-il encadré Scrum ?
C'est un non sens et laissons nos amis scrumiens la liberté de faire comme ils veulent tout en faisant de l'UML sans RUP et MDD (sans Model Driven qui implique génération de code en top down du model vers le code, et aussi uniqument une itération au niveau modèle et non pas comme c'est le cas au niveau des projets Scrum au niveau code) s'ils le considèrent important

RUP est compatible et prévoit la possibilité d'utiliser Scrum ou autre chose, ce n'est pas un non sens c'est le process de développement qui est fait comme cela.

[Jack Sparrow]

Exemple typique d'une erreur de conduite de projet et rejeté sur UML. Si tes diagrammes sont trop grands pour rentrer dans une page c'est que le découpage de ton application et/ou de ton plan de doc est foireux.

Niveau découpage de l'application, on ne pouvait pas faire mieux car on était tributaire du framework que l'on utilise et qui est imposé par l'éditeur de notre GED (je dis "on", mais j'ai repris quelque chose qui existait depuis longtemps et que je n'ai pas fait à l'origine).

Niveau doc : Oui, c'est foireux car il y avait des schémas trop précis. A imposer systèmatiquement UML, je constate que l'on oublie de rester simple.

UML est complexe et est trop souvent mal utilisé (ce que je constate fréquemment). A vouloir l'imposer, ça devient n'importe quoi car peu de personnes l'utilise à bon escient.

Je ne rejette par la faute sur UML, je rejette la faute aux personnes qui imposent UML.

[hegros]

UML est complexe et est trop souvent mal utilisé (ce que je constate fréquemment). A vouloir l'imposer, ça devient n'importe quoi car peu de personnes l'utilise à bon escient.

Je ne rejette par la faute sur UML, je rejette la faute aux personnes qui imposent UML.

Beh c'est comme dans les autres langages informatiques. En général on t'impose le choix du langage en te disant cela se fera avec x ou y langage.

Le C ou le C++ aussi sont des langages complexes et souvent mal utilisés et alors on devrait arrêter de les utiliser et mettre de côté tous leurs potentiels ?


Pour ma part je recommanderais plutôt de travailler avec UML pour faire des modèles jetables si on n'a pas les moyens d'executer un process comme RUP qui d'un point de vue UML est la référence parce que visio c'est un outil de bricolage pour faire un artifice de ce qu'on ne sait pas faire autrement pour la présentation dans ce cas je préfére encore le crayon papier là je retrouve un brouillon authentique pas un artificiel

[Vlade]

Pour ma part je recommanderais plutôt de travailler avec UML pour faire des modèles jetables

Pourquoi dire qu'on fait des modèles jetables ? Parlez-vous de diagramme graphique UML ? dans ce cas c'est des diagrammes jetables, mais attention à ce veux dire jetable. Sinon le modèle UML graphique doit être une vue du metamodel UML qui lui regroupe toutes les informations du projet. Et là le process de modélisation agile directement lié au metamodel via des view graphique UML prend toutes sont importance

Afin de ne pas faire de confusion je pense qu'il ne faut parler de modèle jetable, cela pousse à la confusion. Je pense même que le modèle jetable à pas beaucoup plus de valeur que le dessin à la main de script !!
Désolé mais faire de l'UML avec juste des beaux dessin jetable c'est pour moi un peu limité.
Allez mettez moi RUP à la poubelle et vive l'agile et la modélisation UML

[souviron34]

Allez mettez moi RUP à la poubelle et vive l'agile et la modélisation UML

allez, mettez-moi tout ça à la poubelle, et vive la pensée claire et un papier et un crayon (ou Word ou autre)

[Vlade]

Monsieur Souviron il faut trouver le juste millieu car la vérité n'est pas dans un sens ou un autre.
Un UML minimaliste intégré aux processes de type agile me semble déjà une avancé sérieuse. Pas UML du tout est une régréssion car le papier crayon et la pensé commune ne sont pas mesurable et tracable sans règle bien défini. Or il a fallu 10 ans pour faire UML avec plusieurs millions d'utilisateurs dans plusieurs centaines de milliers de projets. L'UML n'est pas juste une pensé mais s'est du concret qui doit aujourd'hui évolué mais certainment pas disparaître !!

[souviron34]

Je peux éventuellement être d'accord, mais j'avais mis un smiley, hein ?

Cependant, que cela soit un outil, certes, pourquoi pas..

• Plus ? Certainement pas..
  
  
• Qu'on puisse faire sans ? Bien évidemment.
  
  
• Que cela améliore les choses ? dans certains cas, pour certaines personnes..

C'est le fond de ma pensée et de mon expérience..

[hegros]

Vlade dans RUP tout est option (donc même les schémas UML et autres artefacts) si on part du principe que tout ce que préconise le process est obligatoire ce n'est plus effectivement un process agile mais lourd vu tout les artefacts optionnels proposés ! L'idée des artefacts jetables redonne un peu d'agilité à cela.

Un lien sur la modélisation agile

[lepinekong]

RUP et Scrum sont tous les deux itératifs. Il ne faut pas croire que RUP c'est du waterfall sauf que malheureusement les gens qui se contentent de supercialités n'ont pas pris la peine d'étudier RUP dans les détails.
Tout ça m'a l'air bien compliqué quand on voit qu'UML est souvent utilisé plutôt comme un outil de communication (et dans ce cas, on ferait mieux d'utiliser des choses plus simples non formalisées).

A quand le user group des anti-UML ?
Tout ça m'a l'air bien compliqué quand on voit qu'UML est souvent utilisé plutôt comme un outil de communication (et dans ce cas, on ferait mieux d'utiliser des choses plus simples non formalisées).

A quand le user group des anti-UML ?

Personnellement j'aime bien UML mais je conviens que les technocrates l'ont transformé en un outil élitiste où tout est prétexte à jargon. Et UML n'est pas la panacée pour tout. Il ne favorise pas le process créatif et d'ailleurs des outils d'UML innovants essayent de mixer UML avec par exemple le Mindmapping.

Les Managers aiment bien UML parce qu'ils ont lu dans 01 Informatique qu'il suffit de modéliser toute l'application dans UML et pouf en appuyant sur un bouton, l'application est déjà finie. Rarement quelqu'un ose les contredire et leur expliquer que c'est encore loin d'être le cas et qu'il faut encore des programmeurs talentueux. Les outils UML sont en effet aujourd'hui très primitifs et ils sont en passe d'être supplantés par des outils de workflow qui permettent effectivement à un Business Analyst de quasiment modéliser et concrétiser son application.

UML souffre de l'habituel "Design by Comitee" surtout aux mains d'IBM.

[Jack Sparrow]

Beh c'est comme dans les autres langages informatiques. En général on t'impose le choix du langage en te disant cela se fera avec x ou y langage.

Le C ou le C++ aussi sont des langages complexes et souvent mal utilisés et alors on devrait arrêter de les utiliser et mettre de côté tous leurs potentiels ?

Enfin, on peut faire un projet sans connaître UML alors qu'il est difficile de faire un projet sans connaître le langage utilisé pour le développement.
Connaître UML n'est pas essentiel dans la réalisation d'un projet informatique. Je constate juste selon mon expérience, qu'avant d'améliorer quoi que ce soit, ça met surtout des barrières entre ceux qui connaissent, ceux qui pensent connaître et ceux qui ne connaissent pas. Cela ne reste qu'un outil.

Alors oui, il y a d'autres outils imposés dans les projets, mais les gens font en général moins n'importe quoi avec.

[hegros]

Enfin, on peut faire un projet sans connaître UML alors qu'il est difficile de faire un projet sans connaître le langage utilisé pour le développement.
Connaître UML n'est pas essentiel dans la réalisation d'un projet informatique. Je constate juste selon mon expérience, qu'avant d'améliorer quoi que ce soit, ça met surtout des barrières entre ceux qui connaissent, ceux qui pensent connaître et ceux qui ne connaissent pas. Cela ne reste qu'un outil.

Alors oui, il y a d'autres outils imposés dans les projets, mais les gens font en général moins n'importe quoi avec.

Oui puis tu as ceux qui voient visio ou word comme leur UML sauf que la différence est qu'une personne utilise un langage informatique pour faire un travail d'informatique et l'autre utilise un logiciel de dessin qui ne connaît rien à l'ingénierie logicielle laissant place à tout le flou artistique technique post-moderne.

Non UML n'est pas essentiel pour la réalisation d'un projet informatique mais a t'écouter mise à part le langage d'implémentation (le php le c ou machin) rien d'autre n'est essentiel.


pour moi un développeur doit avoir une base en uml comme il l'a pour le sql ou le C ou le java même s'il ne comprends pas tout dans le détail et les raisons du pourquoi ceci ou pourquoi cela

[Jack Sparrow]

Non UML n'est pas essentiel pour la réalisation d'un projet informatique mais a t'écouter mise à part le langage d'implémentation (le php le c ou machin) rien d'autre n'est essentiel.

Il y a plein de choses peu essentiels dans la réalisation d'un projet informatique, mais je suis contre les outils qui apportent plus de problèmes qu'ils n'en résolvent)

pour moi un développeur doit avoir une base en uml comme il l'a pour le sql ou le C ou le java même s'il ne comprends pas tout dans le détail et les raisons du pourquoi ceci ou pourquoi cela

C'est également pour ça que j'ai fait la distinction entre ceux qui ne connaissent pas UML et ceux qui pensent connaître. Car oui, il y en a plein qui ont appris UML durant leurs études, cela ne les empêche pas de faire n'importe quoi avec.
Alors, tu as peut être de la chance de travailler sur des projets où tout le monde maîtrise UML, malheureusement ce n'est pas mon cas

[Vlade]

Envoyé par Jack l'éventreur d'UML Il y a plein de choses peu essentiels dans la réalisation d'un projet informatique, mais je suis contre les outils qui apportent plus de problèmes qu'ils n'en résolvent

Si un outil UML apporte plus de problème que de solutions alors il faut changer d'outil. Ce n'est pas un problème d'UML mais de qualité des outils utilisés. Si par exemple on veut faire du java alors la grande majorité des outils sont pénibles et génère un code java pourri et non utlisable ensuite. Dans ce cas je suis d'accord pour dire que c'est peu productif.

C'est également pour ça que j'ai fait la distinction entre ceux qui ne connaissent pas UML et ceux qui pensent connaître. Car oui, il y en a plein qui ont appris UML durant leurs études, cela ne les empêche pas de faire n'importe quoi avec.

Idem à ce que j'ai dit précédement. Si un modeleur prend un outil non dédié à Java et génère du code, alors il fait n'importe quoi c'est certains !! idem si un modeleur car il est le seul à savoir UML passe sont temps a faire des dessins compliqués juste pour mettre de la poudre au yeux des autres qui comprennent pas, alors ca sert à rien. il faut trouver le juste millieu. Le classe, séquence et usecase diagrammes sont vraiment facile à comprendre pour tout développeur ayant une approche objet. C'est un minimum de se former et cela prend moins de 3 heures à faire. Ca sert à rien de rentré dans les profondeurs UML pour cela mais juste utiliser le diagramme de classe pour y mettre le squellettes de l'application, les commentaires, les contraintes et définir les classes métiers. Le séquence diagramme surtout dans un esprit d'utilisation pour développer les méthodes et pas tout le reste. Le usecase pour definir le scope.
On peut allez plus loin mais cela nécessite une formation UML de plusieurs jours et dans ce cas je suis d'accord avec Jack Sparrow. Ma recommendation est de faire un choix au début du projet du dégré d'UML qu'on veut utliser. Se former 3 heures et ensuite parlé métier afin de faire ces diagrammes ne sera jamais du temps de perdu car de toute façon cette découverte UML permettra une meilleur communication interne en se posant des questions qu'on ne serait pas poser sans UML. Oui, un story board ne donne pas de règle de notation graphique et de diagramme, donc rien qu'en faisant 3 types de diagrammes de façon simple on aura donner plus d'information au projet que l'utlisation de story boards. D'alleurs pour moi ces story boards sont des commentaires à mettre dans les diagrammes eux-même et non pas la définition du process lui-même qui lui à besoin d'une dose d'UML pour couvrir l'approche objet. On ne peut faire du belle objet sans UML, or le développement java est une approche objet si je me trompe ?

Désolé Monsieur Jack Sparrow pour mon humour sur l'eventreur mais vu la gravité des échanges entre vous et hegros, je me suis dit qu'un peu d'humour pourrait détendre le débat

[hegros]

Il y a plein de choses peu essentiels dans la réalisation d'un projet informatique, mais je suis contre les outils qui apportent plus de problèmes qu'ils n'en résolvent)

Cela se mord la queue ton histoire. Un outil O est utilisé par une personne P. Pour P1/P11/P111 O1 atténue les problèmes mais pas pour P2/P22/P222 bien au contraire c'est ce que tu es en train de dire en fait

Ce n'est pas un problème d'outil mais d'outils ET de personnes puisque par définition c'est celui qui se trouve entre l'ordinateur et la chaise qui utilise l'outil...

C'est également pour ça que j'ai fait la distinction entre ceux qui ne connaissent pas UML et ceux qui pensent connaître. Car oui, il y en a plein qui ont appris UML durant leurs études, cela ne les empêche pas de faire n'importe quoi avec.

Oui comme pour le C++, B, Delphi etc.... Alors pourquoi avoir plus peur de l'uml puisque les débutants et même expérimentés sont condamnés à faire des erreurs.

Alors, tu as peut être de la chance de travailler sur des projets où tout le monde maîtrise UML, malheureusement ce n'est pas mon cas

Manque de bol là où je bosse en France personne n'utilise ou ne connaît pourtant d'Allemagne on reçoit des spécifications systèmes de machine en UML (pas dans le détails, pas exact, pas parfait et pas qu'en UML mais de toute façon ce n'est pas ce qu'on attends) sans que personne ne dédaigne à faire la grimace ou à discuter que c'est trop difficile.

[Jack Sparrow]

Cela se mord la queue ton histoire. Un outil O est utilisé par une personne P. Pour P1/P11/P111 O1 atténue les problèmes mais pas pour P2/P22/P222 bien au contraire c'est ce que tu es en train de dire en faite

Si mon histoire se mord la queue. Je n'ai rien compris à la tienne, désolé

[hegros]

En d'autres termes, tu disais que les outils qui apportent des problèmes il faut les éviter (et je te rejoins totalement)cependant ce n'est pas l'outil qui pose problème à lui seul puisque certains cela ne leur apporte pas de problèmes mais que des solutions.

Je disais simplement que c'est un problème d'outil ET de personnes, ni l'un ni l'autre de manière exclusif en somme.