Cours, articles et tutoriels sur les outils de génie logiciel, d'architecture, de modélisation, pratiques de conception et méthodes de développement : Méthodes

Cet article présente le principe de programmation DRY (Do not Repeat Yourself - Ne vous Répétez pas), examine les principales causes de duplication de code ou plus généralement d'informations, et propose divers outils pour y remédier.

Introduction au développement en couches : mise en oeuvre en technologies .NET

Cet article explique comment aborder un développment en équipe pour la 3D. Il vous expliquera les mesures de base à mettre en place puis illustrera concrètement comment les mettre en place au travers d'un exemple concret.
Les gestionnaire de version utilisé est Subversion.

Non, non, il ne s'agit pas de faire un cours sur l'histoire de l'informatique ou de remonter le temps mais bien de voir comment une application écrite en Cobol peut avoir été modélisée en UML. Ce n'est pas non plus un article fumeux (heu, là c'est peut être à vous de juger) et commercial pour vous vendre un outil de modélisation UML, à vous les Cobolistes qui êtes persuadés que UML et Cobol c'est comme chien et chat. Je reconnais que parler d'UML et Cobol dans un même article, autrement que pour les opposer, n'est pas très classique. Mais j'espère que si vous prenez un peu de temps pour lire la suite, vous serez convaincu qu'il n'y a pas vraiment d'autre incompatibilité que celle que vous imaginez.

Cet article décrit la démarche d'écriture des documents de spécifications en s'appuyant sur la notation UML. Il part de la réponse au cahier des charges jusqu'à la rédaction du dossier de conception. Il ne prétend pas être une analyse ou un document méthodologique, simplement un exemple essayant de donner la réponse à une question que nous rencontrons souvent lors des formations « Quand dois-je utiliser tel ou tel schéma ? ».
Il ne s'agit pas d'un cours UML, ni d'un plan qualité mais seulement d'une approche vous permettant, nous l'espérons, de visualiser l'apport d'UML dans une rédaction.

La complexité d'un programme apparaît à un développeur dès que sa perception lui pose des problèmes de compréhension. La taille du projet est certainement un facteur important mais la complexité perçue dépend aussi de l'expérience et du savoir acquis par le programmeur.
La maîtrise de cette complexité a un caractère général et ne concerne pas uniquement la programmation. Le but de ce document est de s'intéresser à la manière dont on peut la gérer. Pour cela, on se propose de définir un modèle de comportement basé sur une Analyse Systémique que l'on définit à partir de quelques règles. Une section est consacrée au domaine de la programmation et une autre conclut ce document en présentant le concept d'informatique complexe.

De l'intérêt de l'analyse des besoins à travers les cas d'utilisation, et de leur modélisation via UML.

Essayons donc de voir quelle est la vraie nature de l'Objet et en quoi l'approche objet a apporté de la nouveauté dans nos pratiques d'informaticiens. Ou pourquoi ne pas modéliser lorsqu'on travaille dans le monde du procédural ?

Né de la fusion des méthodes objet dominantes (OMT, Booch et OOSE), puis normalisé par l'OMG en 1997, UML est rapidement devenu un standard incontournable. UML n'est pas à l'origine des concepts objet, mais il en en donne une définition plus formelle et apporte la dimension méthodologique qui faisait défaut à l'approche objet.
Le but de cette présentation n'est pas de faire l'apologie d'UML, ni de restreindre UML à sa notation graphique, car le véritable intérêt d'UML est ailleurs !
En effet, maîtriser la notation graphique d'UML n'est pas une fin en soi. Ce qui est primordial, c'est d'utiliser les concepts objet à bon escient et d'appliquer la démarche d'analyse correspondante.
Cette présentation a donc pour objectif, d'une part, de montrer en quoi l'approche objet et UML constituent un "plus" et d'autre part, d'exposer comment utiliser UML dans la pratique, c'est-à-dire comment intégrer UML dans un processus de développement et comment modéliser avec UML.

Ce livre fait partie de la collection de livres InfoQ "Enterprise Software Development".
Avec ce livre, vous apprendrez ce qu'est Kanban, ses forces et ses limites, et quand l'utiliser. Vous apprendrez également comment Kanban peut améliorer Scrum, ou tout autre outil que vous utilisez, et à quel moment c'est possible. Henrik montre clairement que le plus important n'est pas l'outil avec lequel on commence, mais la façon dont on améliore constamment son utilisation et comment on développe progressivement son ensemble d'outils.

Traduction par Claude Aubry, Frédéric Faure, Antoine Vernois, Fabrice Aimetti

Ce livre fait partie de la collection de livres InfoQ "Enterprise Software Development". L'apport du livre d'Henrik est que, si vous suivez les pratiques décrites, vous aurez un Directeur de produit, des estimations pour votre Backlog de produit, une Courbe du reste à faire, et vous connaîtrez la vélocité de votre équipe ainsi que de nombreuses autres pratiques essentielles pour un Scrum dangereusement opérationnel. Vous passerez le test Nokia pour Scrum et serez digne de l'investissement dans votre travail. Si vous êtes une startup, vous pouvez même bénéficier du financement d'une société capital-risque. Vous serez peut-être le futur du développement logiciel et le créateur d'une nouvelle génération d'éminents logiciels.

Traduction par Guillaume Mathias, Bruno Orsier, Emmanuel Etasse, Christophe Bunn

L'agilité se définit souvent comme la capacité à répondre aux changements, voire même à les favoriser. Par exemple, Scrum permet au client à travers son représentant (le Product Owner ou PO) d'incorporer des changements dans le périmètre fonctionnel à chaque fin de sprint. Pour beaucoup, c'est un progrès significatif. Maintenant Scrum se diffuse largement vers des équipes qui ne font pas que du développement de logiciel. Le paradoxe, c'est que nombreuses de ces équipes sont dans un mode de changements quasi-permanents, et le passage à Scrum peut représenter une transition rude en repoussant les changements au sprint suivant.
Cet article expose des pistes leur permettant une transition plus douce en introduisant une dose de Kanban dans un cadre Scrum.
Kanban est une pratique basée sur l'utilisation d'étiquettes (ou fiches) pour matérialiser des informations sur un processus, présentées sur un tableau, de façon similaire au tableau des tâches Scrum. Mais Kanban pousse à limiter le TAF (travail à finir), c'est-à-dire le nombre de travaux dans une étape du processus.

De nombreux projets offshore sont en difficulté et ceci pour de multiples raisons.
Quelle est donc la clef du succès dans un contexte ou l'offshore s'impose comme quasiment le seul modèle économique répondant à la loi du marché ?
L'offshore agit comme un verre grossissant, amplifiant tous les défauts de la fabrique logicielle.
Présentation de solutions.

Le retour d'expérience présenté ici illustre une combinaison ambitieuse de sous-traitance en offshore dans une unité captive (filiale de l'établissement bancaire), associée à la mise en place d'un processus de développement agile (essentiellement basé sur SCRUM et XP).

Les méthodes agiles sont de plus en plus utilisées au sein de tous types d'organisations pour les équipes de développement internes. Cela est beaucoup moins vrai pour les développements soustraités. Le premier obstacle et peut être le principal est l'impossibilité par nature de contractualiser un projet en méthodes agiles pour un coût prévisible.
Quelles alternatives à la pure régie peut-on proposer à nos acheteurs ? Comment rendre compatible un projet agile avec un appel d'offre public ? Doit-on choisir un sous-traitant uniquement sur des critères de prix ? Voici autant de questions auxquelles nous tenterons de trouver une réponse.

La gestion des exigences dirigée par les tests, ou Test-Driven Requirements (TDR), représente l'étape ultime dans l'adoption d'un processus de développement dit « lean ». L'article se propose de dresser un état de l'art du Test-Driven Requirements après avoir parcouru ses principes fondateurs que sont le Lean Software Development et le Test-Driven Development. Nous détaillerons différentes pratiques de TDR, telles que l'écriture de spécifications fonctionnelles testables avec des outils comme FIT, ou la génération de test basée sur l'interprétation de modèles comportementaux. La mise en oeuvre de ces pratiques sera illustrée par des retours d'expérience. Les impacts sur l'organisation et la redistribution des rôles seront également mis en lumière.

On entend beaucoup parler actuellement de deux approches ayant l'air fondamentalement opposées : l'approche Model-Driven, préconisée par l'OMG, s'appuyant sur une modélisation UML très poussée visant à une génération automatique de code quasi-complète, les méthodes agiles mettant plus l'accent sur la production rapide de code opérationnel que sur la documentation et minimisant donc la modélisation en amont. Qu'en est-il vraiment ? UML est-il utilisable dans un contexte agile ou réservé au Model-Driven ? La modélisation agile peut-elle exister ? Si oui, quels sont ses principes et ses meilleures pratiques ?

Le terme "objet simulacre" est devenu populaire pour décrire des objets spéciaux qui imitent de vrais objets dans le but de les tester. La plupart des environnements de développement ont maintenant des outils qui permettent de créer facilement des objets simulacres. Cependant, souvent on ne réalise pas que les objets simulacres sont un cas particulier d'objets de tests, qui permettent un style de test différent. Dans cet article j'explique comment les objets simulacres fonctionnent, comment ils encouragent le test basé sur la vérification du comportement, et comment la communauté autour d'eux les utilise pour développer un style de test différent.

Cette page propose une traduction des anti-patrons de tests unitaires recensés par James Carr sur son blog.

Cette page présente un tutoriel sur le développement dirigé par les tests (ou Test Driven Development en anglais). Le tutoriel présente les principes de cette méthode, et ensuite l'illustre pas à pas sur un exemple concret : la recherche de toutes les solutions du problème des pentaminos. Les principaux outils utilisés sont Visual C# Express et Nunit. Les notions de couverture de code, de complexité cyclomatique sont également abordées.

Présentation du processus de développement logiciel eXtreme Programming : ses principes, valeurs, le cycle de développement associé et les différentes pratiques.

Introduction à la pensée agile via l'eXtreme Programming : état des lieux des pratiques classiques de génie logiciel et présentation de la problématique de la gestion du changement.
L'article présente par la suite le Pair Programming et le cycle de développement de la méthode XP.

On entend beaucoup parler actuellement de deux approches ayant l'air fondamentalement opposées : l'approche Model-Driven, préconisée par l'OMG, s'appuyant sur une modélisation UML très poussée visant à une génération automatique de code quasi-complète, les méthodes agiles mettant plus l'accent sur la production rapide de code opérationnel que sur la documentation et minimisant donc la modélisation en amont. Qu'en est-il vraiment ? UML est-il utilisable dans un contexte agile ou réservé au Model-Driven ? La modélisation agile peut-elle exister ? Si oui, quels sont ses principes et ses meilleures pratiques ?

Introduction au développement orienté modèle (MDA - Model Driven Architecture) par la pratique. Le langage utilisé est Java.

Introduction générale au développement orienté modèle (MDA - Model Driven Architecture).

Ce document est une traduction aussi fidèle que possible du nouveau « Getting Started with AndroMDA for Java », disponible sur le site officiel d'AndroMDA.

Introduction à Model Driven Architecture

Présentation du Processus Unifié, de ses activités et phases.

Dans beaucoup d'applications informatiques, un module ou composant métier est régulièrement pollué par de multiples appels à des composants utilitaires externes. La programmation par aspect (AOP) va permettre d'extraire les dépendances entre modules concernant des aspects techniques entrecroisés et de les gérer depuis l'extérieur de ces modules en les spécifiant dans des composants du système à développer nommés aspects ; ils sont développés à un autre niveau d'abstraction.

Cet ouvrage a pour objectif la compréhension de Merise, méthode d'informatisation universelle. Toute méthode informatique doit répondre à quatre objectifs principaux : définir ce que l'utilisateur final veut informatiser (quitte à lui faire comprendre ce qu'il veut), et sa faisabilité ; vérifier la cohérence de sa demande ; structurer les données à informatiser. Cela est primordial en informatique de gestion ; rester simple. Ce point est largement battu en brèche quand une méthode est appliquée "pour la méthode". Elle doit rester un outil d'aide à la conception ou à la réalisation.

Vous tenez en main un guide de modélisation dans le cadre de Merise, un guide que Michel Diviné a voulu essentiellement pratique et qu'il a résolument placé sous le signe de la pédagogie de l'exemple.

Les questions les plus fréquentes sur la méthodologie MERISE.

Nous allons essayer, à travers ces écrits, de comprendre les mécanismes et les fonctionnalités fondamentales d'Access. L'objectif de cette partie n'est pas de maîtriser ce produit, mais d'en avoir une bonne vue d'ensemble.

Ce support de formation regroupe quelques notions concernant la modélisation conceptuelle de système d'information par schéma entités-association (via l'études des dépendances fonctionnelles), la traduction en schéma relationnel et la démarche inverse (rétro-conception). Il présente également les extensions majeures du modèle conceptuel (agrégation, identifiant relatif et héritage).

Les modèles par héritage possèdent de nombreux avantages. Parmis ceux-ci, l'économie en volume de données stocké, la standardisation des types et formats de données. Cet article fait le point sur la modélisation des entités par héritage afin de vous permettre de l'implémenter au sein de vos applications, et cela, en toute sérénité.

L'analyse des données constitue le point de passage obligé de toute conception d'application mettant en oeuvre un SGBDR (système de gestion de base de données relationnelle). La méthode MERISE, basée sur le modèle entité-association, est un outil simple et efficace, très répandue chez les développeurs français. La plupart des bases de données micro pour PC (dBase, Paradox, Foxpro, Access...) sont imprégnées de cette technique pour montrer les relations entre les tables au sein d'une base. Dans cet article, nous allons découvrir les bases et principes fondamentaux de MERISE à l'aide d'exemples et de cas concrets.

La technique des méta données est pertinente pour laisser toute liberté aux utilisateurs de rajouter autant de rubriques de données qu'ils le souhaitent sans jamais de crainte quand à leur volume ni leur facilité d'interrogation. Et tout cela sans jamais modifier l'architecture de la base de données...