Bonjour les Habitants! Peu de livres sur la gestion de projet sont aussi importants que The Mythical Man-Month. Un mélange d'exemples réels de développement de logiciels, d'opinions et de réflexions crée une image vivante de la gestion de projets complexes. Ces essais s'appuient sur les cinquante années d'expérience de Brooks en tant que chef de projet pour IBM System / 360 puis OS / 360. La première édition du livre a été publiée il y a 45 ans, la seconde il y a 25 ans. De nouvelles méthodologies émergent, de nouveaux langages de programmation émergent, le nombre de processeurs augmente, mais ce livre reste d'actualité. Pourquoi? Un demi-siècle plus tard, nous continuons à répéter les erreurs décrites par Brooks. Certains des sujets abordés dans le livre semblent dépassés, mais ce n'est qu'une apparence. Les problèmes fondamentaux qui les sous-tendent sont toujours d'actualité. Il est important de connaître votre passé pour comprendreoù se développe l'industrie du développement de logiciels. Par conséquent, après 45 ans, nous lisons Brooks, beaucoup de choses ont changé dans le monde, mais neuf femmes ne peuvent toujours pas avoir de bébé en un mois.
. ,
. , , , …
, , , , .
, ', , , . .
La plupart des cathédrales européennes ont été construites progressivement et les pièces construites par des constructeurs de différentes générations diffèrent en termes de style architectural. Les constructeurs ultérieurs ont été tentés de «raffiner» la conception des modèles précédents, en se concentrant sur les changements de «mode» architecturale et de goût personnel. Par conséquent, le paisible transept normand * bute et contredit la nef gothique en flèche, et le résultat est autant de louange à la gloire de Dieu qu'à l'orgueil des bâtisseurs.
Dans leur contexte, l'unité architecturale de Reims est en grand contraste. Le plaisir qui excite le spectateur vient à la fois de l'intégrité de la conception et de tous les mérites individuels. Comme indiqué dans le guide, cette intégrité a été obtenue grâce à l'abnégation de huit générations de constructeurs, dont chacun a sacrifié certaines de ses idées au nom de la pureté de la conception globale. Le résultat proclame non seulement la gloire du Seigneur, mais aussi son pouvoir de sauver les pécheurs de leur orgueil.
Bien que la plupart des systèmes de programmation n'aient pas pris des siècles à se construire, ils présentent une désunion conceptuelle bien pire que les cathédrales. Cela ne se produit généralement pas en raison d'un changement de concepteur, mais en raison de la division du projet en de nombreuses tâches effectuées par de nombreuses personnes.
J'insiste sur le fait que l'intégrité conceptuelle est la considération la plus importante dans la conception d'un système. Il est préférable d'avoir un système qui manque de certaines fonctionnalités et améliorations, mais qui reflète un ensemble d'idées de conception, que d'avoir un système qui contient de nombreuses idées bonnes mais indépendantes et incohérentes. Dans ce chapitre et dans les deux suivants, nous examinerons les implications de ce thème pour la conception des systèmes de programmation:
- Comment atteindre l'intégrité conceptuelle?
Cet argument n'est-il pas une excuse pour l'élitisme ou l'aristocratie des architectes face à une horde de réalisateurs plébéiens, dont les talents créatifs et les idées sont supprimés?
- Comment empêcher les architectes de sombrer dans le bleu avec des spécifications non mises en œuvre ou coûteuses?
- Comment s'assurer que chaque détail mineur de la spécification architecturale est porté à l'attention de l'exécutant, compris correctement et intégré avec précision dans le produit?
Atteindre l'intégrité conceptuelle
Le but du système de programmation est de rendre l'ordinateur facile à utiliser. Pour ce faire, il fournit des langages et divers outils de support, qui sont en fait des programmes appelés et pilotés par des capacités linguistiques. Mais ces outils ont un prix: la description externe du système de programmation est 10 à 20 fois plus grande que la description externe du système informatique lui-même. Il est beaucoup plus facile pour l'utilisateur de définir une seule fonction, mais son choix est vaste et il y a beaucoup plus d'options et de formats à garder à l'esprit.
L'utilisation n'est simplifiée que si le temps gagné dans la spécification fonctionnelle est supérieur au temps perdu dans l'assimilation, la mémorisation et la recherche du manuel de référence. Dans les systèmes de programmation modernes, ce gain dépasse le coût, mais ces dernières années, le rapport gain / coût semble avoir baissé à mesure que des fonctionnalités de plus en plus complexes sont ajoutées. Je suis hanté par la mémoire de la facilité d'utilisation de l'IBM 650, même sans langage d'assemblage ni aucun autre logiciel du tout.
Puisque la facilité d'utilisation est l'objectif, cette relation entre la fonctionnalité et l'intégrité conceptuelle est le test ultime de la conception du système. La fonctionnalité et la simplicité ne définissent pas à elles seules une bonne conception.
Cette thèse est largement mal comprise. OS / 360 est salué par ses créateurs comme le plus beau système d'exploitation jamais conçu car il est incontestablement le plus fonctionnel. C'est la fonctionnalité, pas la simplicité, qui a toujours été la mesure de l'excellence pour ses designers. D'autre part, le système de partage de temps PDP-10 est salué par ses créateurs comme le meilleur en raison de la simplicité et de la retenue des concepts. Cependant, à tous égards, ses fonctionnalités n'appartiennent même pas à la même classe que celle d'OS / 360. Une fois que la facilité d'utilisation est prise comme critère, chacune de ces approches devient déséquilibrée, seulement à mi-chemin de l'objectif.
Cependant, pour un niveau de fonctionnalité donné, le meilleur système est celui dans lequel les choses peuvent être spécifiées avec la plus grande simplicité et simplicité. La simplicité seule ne suffit pas. Les langages TRAC Mooers et Algol 68 atteignent la simplicité, mesurée par le nombre de concepts élémentaires distincts. Cependant, l'immédiateté ne les caractérise pas. Exprimer vos intentions nécessite souvent de combiner des outils de base de manière complexe et inattendue. Il ne suffit pas d'étudier les éléments et les règles de leur combinaison; il faut aussi étudier l'usage idiomatique, assimiler tout un corpus de connaissances sur la manière dont les éléments sont combinés dans la réalité. La simplicité et la franchise viennent de l'intégrité conceptuelle. Chaque pièce doit refléter la même philosophie et le même équilibre.Chaque partie doit utiliser même la même technique en syntaxe et des concepts similaires en sémantique. Ainsi, la facilité d'utilisation dicte l'unité de conception, l'intégrité conceptuelle.
Aristocratie et démocratie
L'intégrité conceptuelle, à son tour, exige que le projet provienne d'un seul développeur, ou d'un petit nombre d'entre eux, agissant de concert et à l'unisson.
La pression du calendrier, à son tour, nécessite la participation d'un plus grand nombre de travailleurs. Il existe deux méthodes pour résoudre ce problème. Le premier est la division prudente du travail entre l'architecture et la mise en œuvre. La seconde est une nouvelle façon de structurer les instructions d'implémentation de la programmation, abordée dans le chapitre précédent.
Séparer l'effort architectural de la mise en œuvre est un moyen efficace d'atteindre l'intégrité conceptuelle dans les grands projets. Je l'ai moi-même vu utilisé avec succès sur la gamme d'ordinateurs IBM Stretch et System / 360. Et j'ai vu comment cela ne fonctionnait pas dans le développement du système d'exploitation / 360 car il n'était pas suffisamment utilisé.
Par architecture système, j'entends une spécification complète et détaillée de l'interface utilisateur. Pour l'ordinateur, il est incorporé dans le manuel de référence de programmation. Pour le compilateur - dans le manuel de référence du langage. Pour un programme de contrôle, le manuel de référence de la ou des langues utilisées pour appeler ses fonctions. Pour l'ensemble du système, il s'agit d'un ensemble de guides de référence pour aider l'utilisateur à atteindre son objectif.
L'architecte du système, comme l'architecte du bâtiment, est l'agent utilisateur. Ses responsabilités incluent l'utilisation de connaissances professionnelles et techniques dans l'intérêt du consommateur, et non dans l'intérêt du vendeur, du fabricant, etc. L'
architecture doit être clairement distinguée de la mise en œuvre. Comme l'a noté Blaauw, «là où l'architecture parle de ce qui se passe, la mise en œuvre explique comment cela se fait pour y arriver». A titre d'exemple simple, il cite une montre dont l'architecture se compose d'un cadran, d'aiguilles et d'une couronne. Lorsqu'un enfant apprend cette architecture, il pourra lire l'heure avec la même facilité tant par sa montre-bracelet que par l'horloge du clocher de l'église. La mise en œuvre et sa mise en œuvre décrivent ce qui se passe en interne: le transfert d'effort et le contrôle de la précision par chacun des nombreux mécanismes.
Par exemple, dans System / 360, une architecture informatique distincte est implémentée très différemment dans chacun des neuf modèles. À leur tour, la mise en œuvre, le flux de données, la mémoire et le microcode séparés du système Model 30 à des moments différents servent quatre architectures différentes: l'ordinateur System / 360, le canal multiplexé avec 224 sous-canaux logiquement indépendants, le canal de sélection et l'ordinateur 1401.
La même distinction s'applique également aux systèmes de programmation. Les États-Unis ont adopté la norme Fortran IV. C'est l'architecture de nombreux compilateurs. Au sein de cette architecture, différentes implémentations sont possibles: texte en mémoire ou compilateur, rapide ou optimisant, syntaxique ou ad hoc. De même, tout langage d'assemblage ou de contrôle de travaux autorise de nombreuses implémentations d'assemblage ou de planificateur. Nous pouvons maintenant nous attaquer à la question profondément émouvante de l'aristocratie et de la démocratie. Les architectes ne sont-ils pas la nouvelle aristocratie, l'élite intellectuelle, mise en place pour dire à des exécutants pauvres et sans cervelle quoi faire? Cette élite n'a-t-elle pas repris toute activité créative, faisant des interprètes uniquement des rouages dans le mécanisme? Ne peux-tu pas obtenir un meilleur produitmettre en œuvre les bonnes idées de toute l'équipe, suivant une philosophie démocratique, au lieu de limiter le développement des spécifications à quelques privilégiés?
Quant à la dernière question, c'est la plus simple. Je ne dis pas que seuls les architectes ont de bonnes idées architecturales. Souvent, un nouveau concept vient de l'implémenteur ou de l'utilisateur. Cependant, toute mon expérience me convainc, et j'ai essayé de le montrer, que l'intégrité conceptuelle d'un système détermine sa facilité d'utilisation. Il vaut mieux laisser de côté les bonnes fonctionnalités et idées qui ne s'intègrent pas aux concepts sous-jacents du système. S'il y a beaucoup d'idées aussi importantes mais incompatibles, alors tout le système est rejeté dans son ensemble et le travail recommence sur un système intégré avec d'autres concepts de base.
Quant à l'accusation d'aristocratie, la réponse doit être «oui» et «non». Oui, dans le sens où il devrait y avoir peu d'architectes, leur produit devrait durer plus longtemps que le produit de l'implémenteur, et l'architecte est au centre des forces qu'il doit finalement diriger dans l'intérêt de l'utilisateur. Si le système doit avoir une intégrité conceptuelle, une seule personne doit prendre les devants. C'est l'aristocratie qui n'a pas besoin d'excuses.
L'élaboration de spécifications externes est un travail aussi créatif que la conception d'implémentations. C'est de la créativité, juste un genre différent. La conception d'implémentation tenant compte de l'architecture nécessite et permet autant de créativité de conception, autant de nouvelles idées et autant de brillance technique que la conception pour des spécifications externes. En effet, le rapport coût / performance d'un produit dépendra le plus de l'implémenteur, tout comme la facilité d'utilisation dépendra le plus de l'architecte.
Il existe de nombreux exemples de l'art et de l'artisanat qui conduisent à croire que la discipline améliore le savoir-faire. En effet, l'aphorisme de l'artiste déclare: «la forme libère». Les pires structures sont celles dont le budget était trop important pour que le service soit servi. L'activité créatrice de Bach n'a guère été supprimée par la nécessité de publier une cantate hebdomadaire de forme limitée. Je suis sûr que l'ordinateur Stretch aurait une meilleure architecture s'il était plus restrictif; les contraintes budgétaires du System / 360 Model 30 ont, à mon avis, été bénéfiques à l'architecture du Model 75 à tous égards.
De même, je trouve que l'externalisation de l'architecture améliore, plutôt qu'elle ne nie, le style créatif de l'équipe de mise en œuvre. Ils se concentrent immédiatement sur la partie de la tâche que personne n'a résolue, et les inventions commencent à couler comme une rivière. Dans un groupe de mise en œuvre sans restriction, l'essentiel de la réflexion et de la discussion porte sur les solutions architecturales, avec des délais de mise en œuvre courts.
Cet effet, que j'ai vu à plusieurs reprises, est confirmé par RW Conway, dont le groupe de Cornell a construit un compilateur PL / C pour PL / 1. Il note ce qui suit: «En fin de compte, nous avons décidé de mettre en œuvre le langage sans changements ni améliorations, car la discussion sur le langage prendrait toute notre énergie.
Que doit faire l'exécutant en attendant?
C’est humiliant de faire une erreur d’un million de dollars, mais c’est tellement mémorable. Je me souviens très bien de la nuit où nous avons décidé comment organiser la rédaction réelle des spécifications externes pour OS / 360. Le responsable de l'architecture et le responsable du programme de contrôle et moi avons élaboré le plan, le calendrier et l'attribution des responsabilités.
Le responsable de l'architecture comptait 10 personnes talentueuses. Il a fait valoir qu'ils pouvaient rédiger des spécifications et le faire correctement. Cela prendra 10 mois, trois de plus que le calendrier ne le permet.
Le responsable de la mise en œuvre du programme de contrôle comptait 150 personnes. Il a fait valoir qu'ils pouvaient préparer des spécifications en coordination avec l'équipe d'architecture; ce serait bien fait et pratique, et cela s'inscrirait dans le calendrier. De plus, si l'équipe d'architecture faisait cela, ses 150 personnes resteraient les bras croisés pendant 10 mois.
A cela, le responsable de l'architecture a répondu que si je transfère la responsabilité à l'équipe du programme de contrôle, alors en fait le résultat sera reçu 3 mois plus tard et de bien moindre qualité. J'ai transféré la responsabilité à l'équipe de mise en œuvre du programme de contrôle, et cela s'est avéré comme il l'a dit. Il avait raison dans les deux cas. De plus, le manque d'intégrité conceptuelle a rendu le système beaucoup plus coûteux à construire et à modifier, et j'estime qu'il a retardé le débogage d'un an.
Bien entendu, de nombreux facteurs ont influencé cette décision erronée; mais les plus accablants étaient les contraintes de temps sur le calendrier et un appel pour amener tous ces 150 exécutants au travail. C'est ce chant de sirènes, chargé de dangers mortels, que je vais maintenant rendre visible.
A la proposition qu'une petite équipe d'architecture rédigera effectivement toutes les spécifications externes d'un ordinateur ou d'un système de programmation, les réalisateurs soulèvent trois objections:
- Les spécifications seront trop riches en fonctionnalités et ne refléteront pas le coût pratique.
- Les architectes auront tout le plaisir créatif et renonceront à l'ingéniosité des exécutants.
- De nombreux artistes devront rester les bras croisés pendant que les spécifications passent par le goulot d'étranglement de l'équipe d'architecture.
Le premier est un réel danger, et nous l'examinerons dans le prochain chapitre. Les deux autres sont des illusions, pures et simples. Comme nous l'avons vu ci-dessus, la mise en œuvre est également une activité créative de premier ordre. La capacité d'être créatif et inventif dans la conception est légèrement limitée par la nécessité de travailler selon des spécifications externes données, et cette discipline peut même améliorer la créativité. Ceci est sans aucun doute vrai pour le projet dans son ensemble.
La dernière objection concerne le calendrier et les phases. La réponse rapide est de ne pas embaucher des exécutants tant que les spécifications ne sont pas complètes. Dans la construction, ils fonctionnent sur le même principe.
Dans le secteur des systèmes informatiques, cependant, le rythme est plus rapide, et tout le monde veut réduire le plus possible le calendrier. Dans quelle mesure la spécification et le développement peuvent-ils se chevaucher?
Comme le souligne Blaau, l'effort créatif global comprend trois phases distinctes: l'architecture, la mise en œuvre et la mise en œuvre. Il s'avère qu'ils peuvent effectivement démarrer en parallèle et continuer en même temps.
Par exemple, dans la conception informatique, un exécutant peut se lancer dès qu'il a des hypothèses relativement vagues sur le manuel de référence, des idées plus ou moins claires sur la technologie et des objectifs de coût et de performance bien définis. Il peut concevoir des flux de données, des séquences de contrôle, des concepts de conditionnement brut, etc. Il développe ou adapte les outils dont il a besoin, notamment un système comptable, dont un système d'automatisation de conception.
Parallèlement, au niveau de la mise en œuvre, les conceptions des circuits, des cartes, des câbles, des châssis, des alimentations et de la mémoire doivent être élaborées, améliorées et documentées. Ce travail va en parallèle avec l'architecture et la mise en œuvre.
Il en va de même pour la conception des systèmes de programmation. Bien avant que les spécifications externes ne soient finalisées, l'implémenteur a beaucoup à faire. Avec quelques simplifications grossières de la fonctionnalité du système, qui seront éventuellement incorporées dans des spécifications externes, il peut continuer à travailler. Il doit avoir des critères de ciblage spatial et temporel clairement définis. Il doit connaître la configuration du système sur lequel son produit doit fonctionner. Ensuite, il peut commencer à concevoir des limites de module, des structures de table, des répartitions de passes et de phases, des algorithmes et toutes sortes d'outils. Il faut également passer du temps à communiquer avec l'architecte.
Il reste encore beaucoup de travail à faire au niveau de la mise en œuvre. La programmation a également la technologie. Si la machine est nouvelle, il y a beaucoup à faire sur les conventions d'appel des sous-programmes, la technologie de supervision, les algorithmes de recherche et de tri.
L'intégrité conceptuelle exige que le système reflète une philosophie unique et qu'une spécification visible par l'utilisateur soit rédigée par plusieurs personnes. Cependant, en raison de la réelle division du travail en architecture, mise en œuvre et mise en œuvre, il ne s'ensuit pas du tout de là que le montage d'un système ainsi planifié prendra plus de temps. L'expérience montre le contraire: l'ensemble du système converge de plus en plus vite et prend moins de temps à tester. En fait, la division horizontale généralisée du travail a été fortement réduite par la division verticale du travail, et le résultat a été une simplification radicale de la communication et une amélioration de l'intégrité conceptuelle.
»Plus de détails sur le livre peuvent être trouvés sur le site de la maison d'édition
» Table des matières
» Extrait
Pour Habitants un rabais de 25% sur le coupon - Brooks
Lors du paiement de la version papier du livre, un e-book est envoyé par e-mail.