Get Started for FREE
Sign up with Facebook Sign up with X
I don't have a Facebook or a X account
 Your new post is loading...
Your new post is loading...
Scoop.it!
C'est une question qui a été posée dans un concours: Quelle est la différence entre une méthodologie, une méthode et un modèle? 
No comment yet.
Sign up to comment
Scoop.it!
A common, perhaps dominant, practice of agile methods is to develop a list of features (often called stories) for the software that's being built. These features are tracked with index cards, work queues, burndown charts, backlogs, or whatever your tool of choice is. (...) The problem comes when this list suddenly grows horns and fangs and becomes a Fixed-Price Fixed-Scope Big Up-Front Project Plan.
Mickael Ruau's insight:
Craig Larman once joked that the waterfall process has strong antibodies that reject iterative processes by warping them into some form of waterfall. RUP has been a common victim of these antibodies, seeing its phases turn into some variant of the analysis-design-build-test conveyor. (...) Feature lists have another problem - you easily lose sight of the context that makes the feature valuable.
Scoop.it!
From
dzone
Outlines the key elements of Unified Modeling Language (UML) to provide you with a useful reference when designing software.
Scoop.it!
Afin de faire du modèle UML / SysML un véritable outil de travail et ainsi dépasser le simple stade du rapport, il faut le rendre interactif et permettre aux collaborateurs qui travaillent sur le projet d'échanger autour de ce document et de le faire évoluer au fur et à mesure de l'avancement du projet.
Mickael Ruau's insight:
Exemple de rapport UML :Partie I – Description du projet
Partie II – Analyse
Exemple de rapport SysML :Partie I – Description du projet
Partie II – Analyse
Scoop.it!
Histoires d'utilisateur et cas d'utilisation, ce n'est pas la même chose. jc de QualityStreet présente les différences entre les cas d'utilisation et les histoires d'utilisateur.
Mickael Ruau's insight:
La définition d'une histoire d'utilisateur : Un petit morceau fonctionnel qui a de la valeur pour le “métier” et qui peut être fourni en une itération montre aussi leur autre facette, que n'ont pas les cas d'utilisation : la gestion de projet par l'intermédiaire du backlog de produit. C'est pourquoi la question du choix entre cas d'utilisation et histoires d'utilisateur ne pose pas dans un développement agile : un cas d'utilisation ne remplit pas[2] les conditions pour devenir un élément du backlog sélectionné pour une itération. Attention, je ne dis pas qu'il ne faut pas utiliser les cas d'utilisation. Si, sur les derniers projets pour lesquels j'étais directeur de projet je n'en ai pas eu besoin, un de mes clients utilise, sur mes conseils, ces 2 techniques :
Scoop.it!
Que de choses ont été dites, pour les définir, les comparer, les opposer, les réunifier ! Avant de trancher, commençons d’abord par examiner les deux bestioles.
Mickael Ruau's insight:
D’abord un peu d’histoire : les Use Cases ont été définis par un des pères d’UP (Unified Process), donc d’UML (Unified Modeling Language) : monsieur Ivar Jacobson. Il l’a fait de manière formelle et précise : « Un Use Case est une activité ou une série d’activités, initiées par un acteur, et qui apportent une valeur du point de vue de l’acteur. » Première remarque : un Use Case n’est donc pas une « chose » que je détourne à ma guise et que je vais représenter par une « patate » liée à un bonhomme « fil de fer ». Pour prendre un exemple, « se connecter au système » ne peut pas être un Use Case, car il n’apporte pas de valeur du point de vue de l’acteur (vous arrive-t-il de vous connecter au système et de vous dire juste après : « Ah ! super ! Ma tâche est terminée ! »). 95% des Uses Cases que j’ai rencontrés dans les projets sur lesquels je suis intervenu… n’en étaient pas. Le Use Case est une notion aussi connue que mal comprise.
Scoop.it!
A common problem that I run into again and again is the idea that a data model should drive the development of your objects. This idea comes in two flavors: your physical data schema should drive the development of your objects and that a conceptual/logical data model should be (almost) completely developed up front before you begin to design your objects. Both of these views are inappropriate for non-agile projects and clearly wrong for agile projects.
Scoop.it!
Je souhaite ici vous faire découvrir une technique d'estimation simple, basée sur les cas d'utilisation.
Scoop.it!
Test Engineering covers a large gamut of activities to ensure that the final product achieves some quality goal. These activities must be planned well in advance to ensure that these objectives are met. Plans are based on estimations.
Scoop.it!
Index
Mickael Ruau's insight:
Scoop.it!
Cet article présente UMLGraph. Cet outil est un programme Doclet pour Javadoc permettant de générer des diagrammes UML à partir du code Java et d'annotations ajoutées au code.
Scoop.it!
Modernisation d'application patrimoniales par les modèles
Scoop.it!
Warning: this is my own experience with Class-Responsibilities-Collaborators cards and you may have different opinions about how they should be used for object-oriented design, or have followed a different school of though altogether.
Mickael Ruau's insight:
The goal of the cards (at least in how I have seen it in use today, and used myself) is to produce an abstract object-oriented design before diving into code. The coach that introduced them to me for real,Matteo Vaccari , says they give you an alternative to emergent design because you have to know both how to do upfront design and emergent design to consciously choose the latter. It's like saying you have to know both the procedural and object-oriented style to consciously choose to write code in the former, and not just writing long procedures because it's the only way you know to structure code. No judgment of up front and emergent design is intended in this article. CRC cards are a product of the former, but can be used in many approaches; for example, the last time after not being satisfied with the tests for several objects, I turned to cards for modifying the design and experiment with solutions without having to move dozens of lines of code at the time.
|
Scoop.it!
Apprenez-en davantage sur les diagrammes d'activités UML: définition, composants, symboles, etc. Ouvrez un compte Lucidchart gratuit et utilisez nos modèles !
Mickael Ruau's insight:
Les diagrammes d'activités présentent plusieurs avantages pour les utilisateurs. Songez à créer un diagramme d’activités pour :
Scoop.it!
Les diagrammes d'architecture peuvent être des outils utiles pour documenter et communiquer la conception d'un système. Ils doivent être autodescriptifs, cohérents, suffisamment précis et liés au code. L'application de certaines directives peut garantir que les diagrammes sont utiles à diverses parties prenantes.
Mickael Ruau's insight:
Le langage de description architecturale (e.g. UML, ArchiMate, etc.) fait-il une différence ?Il y a beaucoup d'avis sur la question de savoir quel est le bon langage de description à adopter dans le projet. Certaines personnes pourraient faire valoir que l'UML est rigide et pas assez flexible pour modéliser la conception architecturale, un point de vue auquel je souscris. Néanmoins, dans certains cas, il peut être plus que suffisant pour documenter les principes fondamentaux d'une architecture sans s'appuyer sur des caractéristiques d'extensibilité de l'UML comme les profils et les stéréotypes. En examinant d'autres langages de description, nous pouvons constater que ArchiMate est plus puissant et plus adapté à la modélisation des systèmes d'entreprise par rapport à UML ; il existe également BPMN qui est particulièrement ciblé sur les processus d'entreprise, etc. Les comparaisons pourraient se poursuivre, mais je n'ai pas l'intention de les passer en revue de manière approfondie, car ce n'est pas le but de cet article.
Scoop.it!
File UML 2.1.2 Infrastructure 1.7Mo
Scoop.it!
Scoop.it!
Un use-case, des user stories ? L'autre jour à Marseille dans sa présentation, pour parler des user stories, Thierry a dit des histoires d'utilisation. Tiens, un mélange entre cas
Mickael Ruau's insight:
En fait quand j'étais consultant en cas d'utilisation (dans les années 90), je constatais une pratique très variée des cas d'utilisation. Certains correspondaient d'ailleurs à ce qu'on appelle story maintenant, quelques uns avaient du sens (essential) et la plupart c'était de l'IHM. Si je trouve que la pratique des user stories apporte généralement plus de valeur, il y manque la notion de contexte. Quand on manipule des dizaines de stories, il est difficile de savoir dans quel système plus large se situe une story particulière. Avec une approche agile du produit, la vision et l'identification des features fournissent une partie de ce contexte. Une user story est le résultat de la décomposition d'une feature[1]. Mais ce qu'il manque toujours, à mon avis, c'est le contexte temporel. Il serait intéressant de connaitre les enchaînements possibles lors de l'exécution des stories. Quelque chose qu'apporte le cas d'utilisation en montrant les différents scénarios qui le composent.
Scoop.it!
XML est un méta-langage, c'est-à-dire qu'il permet de construire des langages spécialisés, des dialectes XML. Ces dialectes sont nombreux. Ils permettent de décrire des notions très variées et d'aborder des concepts complexes. Nous allons donc faire ici un petit tour d'horizon des principales catégories de dialectes XML :
Scoop.it!
Note: This is a summary of a recent discussion on the chat_rup forum. My thanks to the main discussion contributors: Davyd Norris, Pan-Wei Ng, and John Smith.
Scoop.it!
Use Case Points is a simple and fast tool for help you to estimate de effort of software project development. The user interface is simple, fast and does the job of estimating the effort much easier.
Scoop.it!
'injection de dépendances demande des compétences confirmées dans la programmation orientée objet. Dans la mesure du possible, les bases seront expliquées mais certaines notions seront considérées comme acquises, notamment l'utilisation des interfaces. Les prérequis pour ce tutoriel sont :
Tous les codes sources de ce tutoriel sont disponibles sur ce projet GitHub afin que vous puissiez consulter des exemples fonctionnels directement exécutables dans un terminal.
Scoop.it!
Cet article a pour objectif de présenter les Design Patterns du "Gang of Four" avec des exemples concis appliqués à Java.
Scoop.it!
Le paquet pear php_uml permet le reverse engineering en ligne de commande. Il ne s'agit pas d'un outil de modélisation mais simplement d'un utilitaire de reverse engineering. En traitant un code source existant avec cet outil, on obtient un fichier xmi que l'on peut ensuite visualiser et modifier, en théorie, avec n'importe quelle éditeur. Dans la pratique, seul BoUML exploite ce fichier.
|
Un modèle est ce qui a servi de base à l'établissement d'une méthodologie.
Exemple :
modèle : développement au plus proche de l'utilisateur
méthodologie : agile
méthodes : RUP, XUP, Scrum, ..., ...