Architecture

Démythifier la modélisation

Publié le : Auteur: Hugues VAN EYLEN 2 commentaires
architecture

Au cours de mes expériences en tant  qu’architecte, qu’AMOA ou au sein de département méthode, j’ai été frappé par la mauvaise perception que l’on a de la notion de modélisation dans les équipes informatiques.

Pour beaucoup la modélisation est une activité à part qui fait peur (on pense que c’est une activité difficile réservée à des experts) et qui apporte un surcroît de travail pour obtenir un hypothétique gain en qualité dans le développement des systèmes informatiques.

Pourtant, modéliser est avant tout un acte intellectuel naturel que nous effectuons quotidiennement et ceci depuis notre plus jeune âge. Notre cerveau est bâti pour produire des modèles mentaux de la réalité que nous percevons.

Quand une MOA rédige un cahier des charges, elle effectue une modélisation pour communiquer avec l’utilisateur et avec la MOE ce qu’elle comprend du besoin d’un système.

Quand une MOE programme un logiciel, elle effectue une modélisation pour permettre qu’un ordinateur réalise un ensemble de calculs dont les résultats sont fournis à un utilisateur.

La grande différence entre ces deux précédentes actions est la cible de la modélisation. D’un côté, le modèle sert de support de communication entre des individus et de l’autre, on s’en sert pour communiquer avec une machine. Mais dans les deux cas on utilise un formalisme pour supporter cette modélisation.

Si un langage de programmation est adapté à la communication avec un ordinateur, il ne l’est pas pour transmettre une vision de l’architecture du logiciel ou exprimer une règle métier. De même, un texte libre n’est pas la meilleure manière de transmettre une expression du besoin car trop de flou, d’incohérence et d’incomplétude s’y retrouvent.

Mais la modélisation du besoin est nécessaire comme celle de l’architecture du logiciel. La question n’est pas de savoir si nous devons modéliser mais comment nous nous y prenons pour effectuer cette modélisation ?

Soit nous le faisons de manière ad-hoc à l’aide de traitement de texte et d’outils de dessin soit nous mettons en œuvre des bonnes pratiques utilisant des formalismes et des cadres de pensées facilitant notre travail.

Pour faire un parallèle, je peux améliorer l’acte intellectuel de mémorisation en utilisant des techniques mnémoniques comme je peux améliorer l’acte intellectuel de modélisation en utilisant des techniques adaptées (carte heuristique, diagramme UML, diagramme BPMN, etc.).

Au final le bon discours pour un ingénieur méthode consiste à montrer que la modélisation est une activité intrinsèque du développement informatique et que l’usage de bonnes pratiques de modélisation permet tout d’abord de gagner en temps de développement et ensuite de gagner en qualité mais ne correspond nullement à du travail en plus.

  • ego

    T’a raison gaston, j’aurai pas dit mieux……..un ancien avec qui tu as collaboré dans une grosse entreprise qui essaye de faire de la modélisation

  • Girardot

    Je partage cette analyse. Un angle d’attaque ne serait-il pas d’expliquer au métier que la modélisation est indispensable pour structurer les IHM qui seront développées pour lui, qui elles-mêmes supposent la structuration des données et des processus ?

    D’une manière générale, beaucoup de gens pensent que la théorie est faite pour les théoriciens qui s’amusent en vase clos, sans lien avec la réalité, alors que les bonnes théories bien appliquées apportent beaucoup à la pratique, et sont mêmes bien souvent la condition indispensable de sa réussite.