The Mythical Man-Month

The Mythical Man-Month

Le Mythe du mois-homme

Le Mythe du mois-homme (The Mythical Man-Month: Essays on Software Engineering) est un livre de Frederick Brooks considéré comme un classique dans le domaine du génie logiciel.

Le titre de l'ouvrage fait référence à une unité de coût de développement : le mois-homme, c'est-à-dire le travail d'un homme pendant un mois. Le mythe, c'est l'équivalence suggérée par l'usage de cette unité entre un travail de 1 personne pendant n mois et un travail de n personnes pendant 1 mois ; selon cette idée, on pourrait diviser les temps de développement par deux en mettant deux fois plus de personnel. Or, expérimentalement, cela est faux. Le proverbe cité par Brooks pour exprimer cette idée est : « Neuf femmes ne font pas un enfant en un mois »[1].

Bien que certaines remarques proprement techniques de l'ouvrage soient très datées (car portant sur des types de systèmes depuis longtemps dépassés), de nombreux problèmes soulevés par Brooks sont toujours d'actualité au XXIe siècle.

Le livre a été publié une première fois en 1975, et réédité en 1995[2]. La réédition contient l'essai No Silver Bullet (Pas de balle en argent) et des commentaires de l'auteur.

Sommaire

Résumé

Brooks y expose son expérience du développement informatique et notamment du développement d'OS/360 chez IBM. Bien qu'il mentionne parfois des outils ou des problèmes algorithmiques, il s'attache plutôt à l'organisation et aux méthodes de travail des équipes de développement : hiérarchie des responsables, documentation et prévision des délais de développement.

La loi de Brooks

Ajouter des ressources humaines à un projet en retard sur les prévisions ne fait qu'accentuer ce retard : c'est la loi de Brooks. En effet, le personnel ajouté devra être formé au nouveau système, ce qui prend un temps non négligeable qui ne peut compenser la productivité ajoutée par le personnel en question. Les nouveaux ont souvent besoin d'entraînement et de formation. De plus, leur présence alourdit les canaux de communications. Si n personnes doivent échanger entre elles (sans hiérarchie), quand n augmente, leur extrant M décroît et peut même devenir négatif (c'est-à-dire que le travail total à réaliser à la fin d'une journée est plus grand qu'au début de cette journée).

Formule des canaux de communication : n * (n − 1) / 2 (pour 50 informaticiens, on a ainsi 50 * (50 − 1) / 2, soit 1 225 canaux de communication).

L'effet du deuxième système

Tout informaticien ayant réalisé un premier système a tendance à créer un deuxième système incorporant toutes les fonctions qu'il n'a pas pu ajouter au premier système par faute de temps. Un informaticien développant un deuxième système devrait donc être conscient du risque de dépassement des spécifications exigées.

Le suivi de projet

Comment un gros projet peut-il être en retard d'un an sur l'horaire prévu ? Un jour à la fois.

Des retards à différentes étapes du projet ont un effet cumulatif et retardent globalement le projet. Pour prévenir ce retard, il faut que les gestionnaires agissent pour faire respecter l'horaire de livraison de chacune des étapes du projet.

L'unité conceptuelle

Tout système convivial possède nécessairement une unité conceptuelle, laquelle est possible si l'architecture logicielle est séparée de son implémentation. Une « super idée » peut être rejetée si elle ne s'insère pas naturellement dans le programme. Pour assurer la convivialité, un architecte logiciel peut décider que le programme offrira moins de fonctions que ce qu'il peut offrir. La raison en est simple : si une fonction est trop longue à comprendre, elle ne sera pas utilisée.

Le mode d'emploi

L'architecte rédige au complet le mode d'emploi du programme, c'est-à-dire ce que l'utilisateur final verra. Le mode d'emploi devrait être modifié au fur et à mesure que l'architecte reçoit des commentaires de la part des informaticiens et des utilisateurs.

Le prototype

Tout nouveau programme conçu par un architecte logiciel et créé par un groupe d'informaticiens sera jeté par après, peu importe la qualité du travail. Ce prototype expose des techniques qui serviront subséquemment à la conception d'un nouveau programme. Ce deuxième programme, plus « intelligent », est celui livré aux clients. Livrer le prototype suffit souvent à ruiner la réputation du programme, parfois même celle de l'entreprise.

Les documents de base

Tout gestionnaire de projet devrait rédiger des documents de base servant à établir le plan de travail : quels sont les objectifs, comment les atteindre, qui est responsable de quoi, quand doivent-ils être atteints et combien chacun d'eux coûtera ? Ces documents peuvent révéler des incohérences difficilement visibles autrement.

La planification

Lorsqu'un architecte logiciel planifie un projet, il doit se souvenir qu'un compilateur est trois fois plus difficile à créer qu'une application logicielle. Et qu'un système d'exploitation est trois fois plus difficile à créer qu'un compilateur. L'usage d'un langage de haut niveau adapté peut substantiellement améliorer la productivité d'un informaticien. Il doit également tenir compte du temps pris par les tâches qui ne sont pas de nature technique (réunions, rapports, congés maladie, etc.)

La communication

Dans le but de prévenir les désastres, toutes les équipes affectées à un projet doivent maintenir le contact entre elles à l'aide du plus grand nombre de moyens possibles (courriel, téléphone, réunions, mémos, etc.). Plutôt que de faire des hypothèses sur une fonction, l'informaticien se réfère à l'architecte logiciel pour clarifier la nature de la fonction. Sinon, il risque d'implémenter une fonction qui sera jetée.

Le « chirurgien en chef »

Toute équipe de chirurgie est menée par un chirurgien en chef, qui s'occupe en personne des tâches essentielles de l'opération tout en dirigeant son équipe, qui l'appuie et réalise des tâches moins essentielles. Il est raisonnable de voir une équipe logicielle de la même façon : le meilleur informaticien s'occupe des parties essentielles du composant à créer, alors que les autres s'occupent des autres tâches.

Brooks spécule que les meilleurs informaticiens ont une production de 5 à 10 fois supérieure aux pires.

La gestion de versions et le gel du code

Tout changement au code source doit être connu via un système de gestion de versions. Par contre, le logiciel est invisible. Pour cette raison, plusieurs fonctions ne deviennent visibles qu'après un certain temps de développement. À ce moment, les utilisateurs peuvent commencer à utiliser une partie du programme final. Leur expérience apporte des points de vue nouveaux, qui changent la perception de l'utilisateur ou la perception de ses besoins. À ce moment, le système doit aussi changer pour combler leurs besoins.

Ces modifications sont permises à l'intérieur d'une certaine fenêtre de temps, sinon le produit final change continuellement, en attente d'être livré aux clients. À une certaine date, seuls les bogues doivent être réparés : le code source est gelé. Tous les changements conceptuels en attente d'implémentation se retrouveront dans une version future.

Les outils sur commande

Plutôt que chaque informaticien utilise un coffre à outils composé par ses soins, chaque équipe devrait avoir un membre qui se spécialise dans la création d'outils pour les autres membres de l'équipe. De plus, des outils utilisés pour l'ensemble du projet devraient être créés par une équipe dédiée à cette tâche, laquelle est supervisée par le gestionnaire de projets.

La diminution du coût de développement logiciel

Selon Brooks, il existe deux techniques pour diminuer le coût de développement :

  • engager les informaticiens qui implémentent le système une fois les spécifications complètement établies par les architectes (une étape qui peut prendre plusieurs mois, période durant laquelle les informaticiens employés trop tôt n'ont rien à faire) ;
  • acheter des logiciels déjà fonctionnels (off the shelf), tout simplement.

Notes et références

  1. quoiqu'elle figure dans le livre (p. 17 de la version anglaise) il est difficile de donner l'origine exacte de cette phrase (une citation proche est attribuée à Wernher von Braun)
  2. ISBN 0-201-83595-9

Traduction

Traduction française: "Le mythe du mois-homme", 1996, ITP/Vuibert, traduit par Frédéric Mora, ISBN 978-2-84180-081-0. Le livre est indisponible, mais s'il y a une demande suffisante, un nouveau tirage pourrait être envisagé. Envoyer email à l'auteur, F. P. Brooks, si intéressé.

Voir aussi

Articles connexes

Liens externes

  • Portail de l’informatique Portail de l’informatique
Ce document provient de « Le Mythe du mois-homme ».

Wikimedia Foundation. 2010.

Contenu soumis à la licence CC-BY-SA. Source : Article The Mythical Man-Month de Wikipédia en français (auteurs)

Игры ⚽ Нужен реферат?

Regardez d'autres dictionnaires:

  • The Mythical Man-Month —   …   Wikipedia

  • The Mythical Man-Month — Saltar a navegación, búsqueda El Mítico Hombre Mes: Ensayos de ingeniería de Software (en inglés The Mythical Man Month : Essays on Software Engineering) es un libro de administración de proyectos de Software de Fred Brooks, cuyo tema… …   Wikipedia Español

  • The mythical man-month — Le Mythe du mois homme Le Mythe du mois homme (The Mythical Man Month: Essays on Software Engineering) est un livre de Frederick Brooks considéré comme un classique dans le domaine du génie logiciel. Le titre de l ouvrage fait référence à une… …   Wikipédia en Français

  • The Mind of the Maker — (1941) is a Christian theological book, written by Dorothy L. Sayers (who was better known for her crime and mystery novels and other fiction, particularly for the character Lord Peter Wimsey). It treated the subject of creativity in the light of …   Wikipedia

  • Man-hour — Contents 1 Real world applications 2 Similar units 3 See also 4 …   Wikipedia

  • The Man Who Sold the Moon — Cover of Shasta edition collection The Man Who Sold the Moon is a science fiction novella by Robert A. Heinlein written in 1949 and published in 1950. A part of his Future History and prequel to Requiem , it covers events around a fictional first …   Wikipedia

  • The Vision of Escaflowne — Vision of Escaflowne Limited Edition DVD box set 天空のエスカフローネ (Tenkū no Esukafurōne) …   Wikipedia

  • The Lion Sleeps Tonight — by The Tokens Single by The Tokens B side …   Wikipedia

  • Programming in the large and programming in the small — Programming paradigms Agent oriented Automata based Component based Flow based Pipelined Concatenative Concurrent computin …   Wikipedia

  • The Beatles — This article is about the band. For other uses, see The Beatles (disambiguation). Fab Four redirects here. For other uses, see Fab Four (disambiguation) …   Wikipedia

Share the article and excerpts

Direct link
Do a right-click on the link above
and select “Copy Link”