Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #21
    Membre Expert
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 506
    Points : 5 493
    Points
    5 493

    Par défaut

    Citation Envoyé par Vlade Voir le message
    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.
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  2. #22
    Membre actif
    Inscrit en
    juin 2008
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 189
    Points : 241
    Points
    241

    Par défaut

    Citation Envoyé par hegros Voir le message
    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.

  3. #23
    Membre Expert
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 506
    Points : 5 493
    Points
    5 493

    Par défaut

    Citation Envoyé par Jack Sparrow Voir le message

    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
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  4. #24
    Inactif
    Inscrit en
    février 2003
    Messages
    238
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : février 2003
    Messages : 238
    Points : 301
    Points
    301

    Par défaut Modèle UML pourquoi jettable ?

    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

  5. #25
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 592
    Détails du profil
    Informations personnelles :
    Âge : 61
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 592
    Points : 17 247
    Points
    17 247
    Billets dans le blog
    2

    Par défaut

    Citation Envoyé par Vlade Voir le message
    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)
    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  6. #26
    Inactif
    Inscrit en
    février 2003
    Messages
    238
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : février 2003
    Messages : 238
    Points : 301
    Points
    301

    Par défaut Le juste millieu UML

    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 !!

  7. #27
    Expert éminent sénior

    Profil pro
    Inscrit en
    janvier 2007
    Messages
    10 592
    Détails du profil
    Informations personnelles :
    Âge : 61
    Localisation : France

    Informations forums :
    Inscription : janvier 2007
    Messages : 10 592
    Points : 17 247
    Points
    17 247
    Billets dans le blog
    2

    Par défaut

    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..

    "Un homme sage ne croit que la moitié de ce qu’il lit. Plus sage encore, il sait laquelle".

    Consultant indépendant.
    Architecture systèmes complexes. Programmation grosses applications critiques. Ergonomie.
    C, Fortran, XWindow/Motif, Java

    Je ne réponds pas aux MP techniques

  8. #28
    Membre Expert
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 506
    Points : 5 493
    Points
    5 493

    Par défaut

    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
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  9. #29
    Membre actif
    Profil pro
    Inscrit en
    janvier 2010
    Messages
    206
    Détails du profil
    Informations personnelles :
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : janvier 2010
    Messages : 206
    Points : 271
    Points
    271

    Par défaut

    Citation Envoyé par Jack Sparrow Voir le message
    Citation Envoyé par 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.

  10. #30
    Membre actif
    Inscrit en
    juin 2008
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 189
    Points : 241
    Points
    241

    Par défaut

    Citation Envoyé par hegros Voir le message
    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.

  11. #31
    Membre Expert
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 506
    Points : 5 493
    Points
    5 493

    Par défaut

    Citation Envoyé par Jack Sparrow Voir le message
    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
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  12. #32
    Membre actif
    Inscrit en
    juin 2008
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 189
    Points : 241
    Points
    241

    Par défaut

    Citation Envoyé par hegros Voir le message
    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)

    Citation Envoyé par hegros Voir le message
    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

  13. #33
    Inactif
    Inscrit en
    février 2003
    Messages
    238
    Détails du profil
    Informations personnelles :
    Âge : 52

    Informations forums :
    Inscription : février 2003
    Messages : 238
    Points : 301
    Points
    301

    Par défaut

    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

  14. #34
    Membre Expert
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 506
    Points : 5 493
    Points
    5 493

    Par défaut

    Citation Envoyé par Jack Sparrow Voir le message
    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.
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

  15. #35
    Membre actif
    Inscrit en
    juin 2008
    Messages
    189
    Détails du profil
    Informations forums :
    Inscription : juin 2008
    Messages : 189
    Points : 241
    Points
    241

    Par défaut

    Citation Envoyé par hegros Voir le message
    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é

  16. #36
    Membre Expert
    Homme Profil pro
    Ingénieur R&D
    Inscrit en
    juin 2003
    Messages
    4 506
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Essonne (Île de France)

    Informations professionnelles :
    Activité : Ingénieur R&D
    Secteur : Industrie

    Informations forums :
    Inscription : juin 2003
    Messages : 4 506
    Points : 5 493
    Points
    5 493

    Par défaut

    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.
    " Dis ce que tu veux qui insulte mon honneur car mon silence sera la réponse au mesquin.
    Je ne manque pas de réponse mais : il ne convient pas aux lions de répondre aux chiens ! " [Ash-Shafi'i ]

Discussions similaires

  1. Quels sont les meilleurs livres pour UML ?
    Par Matthieu Brucher dans le forum Livres
    Réponses: 33
    Dernier message: 31/01/2014, 10h36
  2. [VB.NET]Aide sur les process
    Par Dnx dans le forum Windows Forms
    Réponses: 2
    Dernier message: 19/10/2005, 15h13
  3. Réponses: 6
    Dernier message: 03/10/2005, 18h42
  4. Lister les process avec leurs arguments
    Par jamfr73 dans le forum MFC
    Réponses: 5
    Dernier message: 23/12/2004, 10h54
  5. Débat sur les outils de développement RAD.
    Par PsychicStorm dans le forum Débats sur le développement - Le Best Of
    Réponses: 20
    Dernier message: 20/08/2003, 11h29

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo