书籍详情
人月神话（注释版）
作者：（美）布鲁克斯（Brooks，F.P.） 著，李琦 注释
出版社：人民邮电出版社
出版时间：2007-11-01
ISBN：9787115156174
定价：¥49.00
购买这本书可以去
内容简介
本书内容来自于作者在IBM公司任System/360计算机系列以及其庞大的软件系统OS/360项目经理时的实践经验。在本书中，作者将软件工程的实践和发人深思的观点融于一炉，为每个复杂项目的管理者奉上了自己的真知灼见。大型编程项目与小项目不同，深受由于人力划分产生的管理问题的困扰，保持产品本身的概念完整性是一个至关重要的需求。本书探索了达成一致性的困难和解决的方法，并探讨了软件工程管理的其他方面。在本书的初版发表20周年之际，作者重新修订了他最初的观点，并为已经熟悉他作品和刚刚接触本书的广大新老读者添加了新的观点和建议。 本书的注释内容结合软件工程领域近年来的发展趋势，重访30年前的经典，通过精辟的点评、典雅的词句、人文精神辉映下的技术理性，深刻诠释了大师的深邃思想，引导读者共同参悟名家的金玉良言，领会人月的精髓。
作者简介
Frederick P.Brooks，Jr.，1999年美国计算机协会（ACM）图灵奖得主，图灵奖是计算机领域最负盛名的技术奖项。ACM协会特别盛誉他“在计算机体系结构、操作系统和软件工程领域中里程碑式的贡献”。
目录
Chapter 1 The Tar Pit 3
Chapter 2 The Mythical Man-Month 13
Chapter 3 The Surgical Team 29
Chapter 4 Aristocracy, Democracy, and System Design 41
Chapter 5 The Second-System Effect 53
Chapter 6 Passing the Word 61
Chapter 7 Why Did the Tower of Babel Fail? 73
Chapter 8 Calling the Shot 87
Chapter 9 Ten Pounds in a Five-Pound Sack 97
Chapter 10 The Documentary Hypothesis 107
Chapter 11 Plan to Throw One Away 115
Chapter 12 Sharp Tools 127
Chapter 13 The Whole and the Parts 141
Chapter 14 Hatching a Catastrophe 153
Chapter 15 The Other Face 163
Chapter 16 No Silver Bullet——Essence and Accident 179
Chapter 17 “No Silver Bullet” Refired 207
Chapter 18 Propositions of The Mythical Man-Month: True or False? 229
Chapter 19 The Mythical Man-Month after 20 Years 253
Epilogue 291
Notes and References 293
Index 309
中文目录
第1章 焦油坑 3
史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序依其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开发这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。
第2章 人月神话 13
软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，Brooks法则：向滞后的软件项目追加人手会使得进度更迟缓。自本书第1版出版以来，这一法则在软件业广为传诵。
第3章 外科手术团队 29
虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。
第4章 元老制、民主制和系统设计 41
概念完整性是系统设计中最重要的因素，尤其对于大型软件系统来说，概念完整性是项目顺利完成的必要保障。为获得概念完整性，架构设计由精简的架构设计小组负责，具体实现则围绕核心概念展开。架构设计和具体实现既相分离，又相辅相成。
第5章 第二个系统效应 53
人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。
第6章 沟通顺畅 61
架构设计通常由核心设计小组完成，将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。以System 360的开发经验为例，要贯彻概念完整性，需要在团队中保持良好顺畅的沟通和交流，采用形式化定义等技术可以确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。
第7章 巴别塔为何失败 73
如果缺乏良好有效的沟通和协作，成员间难以有效地配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。
第8章 掌控之中 87
对大型软件系统产品的开发所需的时间和资源进行准确地估测，能让我们对项目进度和前景胸有成竹。软件代码的开发效率和代码模块之间所需的交互相关。界面交互复杂的程序需要更多的测试和调试时间，单纯地增加人手并不能有助于开发效率的提高。
第9章 袖里乾坤 97
最大化资源利用率，减少不必要的资源占用，合理规划，使软件系统在资源有限的情况下依然保证良好的性能，从而实现良好的可伸缩性和健壮性，这能体现软件开发人员精湛的设计技巧。巧妙的数据结构往往能大幅度地俭省资源耗费，提高系统运行的性能。
第10章 文档先行 107
在软件项目开发过程中，文档是不可或缺的，文档为整个团队规范了概念，以便于团队中的沟通协作以及进度校验。本章阐述了软件系统项目中至关重要的几类文档，这些关键文档应及时地更新，始终作为项目进展的有效指南。
第11章 准备抛弃 115
变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。
第12章 良工利器 127
软件开发项目所选择的技术和工具对保障项目能否令人满意地如期完成至关重要。合适的开发工具、评测技术能有事半功倍之效果，切于实用的工具和技术是项目团队的重要财富。本章提供了当年软件开发项目选择技术和工具的重要原则和建议。
第13章 整体和局部 141
大而无当的笼统见地并不能表现你真正地理解了一个软件系统，应该具体而系统地深入了解各个局部的技术。良好的自顶向下的设计，不仅能保证概念完整性，也能及早消灭许多隐患。应及早在软件项目中引入测试，错误发现得越早，修复错误的代价就越小。
第14章 潜伏的祸患 153
项目进度的滞后经常源自不易察觉的点滴延误的累积。软件项目的经理应该尽量建立可以明确量化的阶段性目标，定期进行严谨而规范的项目阶段性验收，了解项目的进展状况，并及时进行计划、资源和人力的调整。关键路径图等技术有助于观察项目的进度。
第15章 另一面 163
虽然用户直接使用软件系统，但在许多应用领域中，用户不可能仅仅凭借与软件的直接交互就迅速掌握其所有功能。故而提供给用户的使用说明等文档是软件呈现给用户的另外一面，它也能直接影响用户对软件的满意度和可用性评价。文档的用途决定它的形式和内容。
第16章 没有银弹——软件工程的必然和偶然 179
本文最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》初版发行已有10年，其间计算机技术领域的变化令人振奋。但作者在此提出，由于软件的复杂性、一致性、变化性和不可见性，解决软件危机的银弹并不存在。作者点评了20世纪80年代前期被业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。作者预言在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高。
第17章 再议“没有银弹” 207
相比《人月神话》初版而言，1986年发表的“没有银弹”(第16章)发表后引发了热烈的争论，本章结合20世纪80年代后期到90年代前期之间软件复用、面向对象程序开发等新技术的发展状况，回应了对《没有银弹》一文的各种主要异议，认为由于《没有银弹》一文归纳的软件的几大特性，人们期待中的重大突破不可能在近期内到来。
第18章 人月神话中的提议：是耶非耶 229
在撰写《人月神话》的回顾和更新过程中，作者发现初版中断言的观点甚少被软件工程研究和实践所抨击、证实或证伪，因此在本章中作者提炼了初版中15个章节中的概要，结合近年来软件技术的发展状况，对这些观点进行强调、修正和反思。
第19章 人月神话二十年 253
在《人月神话》初版发布二十周年后，计算机技术领域已有很大变化，《人月神话》体现出深远的影响力，初版中的许多观点依然经常被人们谈论和引用，其中有些断言至今仍被软件开发人员奉为圭臬。作者结合当前软件工程领域的发展现状重新梳理了初版中的各核心观点，强调了概念完整性，重新评议了第二个系统效应，反省了瀑布模型的局限性。结合初版中的观点，作者评述了图形桌面系统、信息隐藏、面向对象高级语言等技术的发展，以及近年来软件工程领域的重要成果。
跋 291
注解与参考文献 293
索引 309
Chapter 2 The Mythical Man-Month 13
Chapter 3 The Surgical Team 29
Chapter 4 Aristocracy, Democracy, and System Design 41
Chapter 5 The Second-System Effect 53
Chapter 6 Passing the Word 61
Chapter 7 Why Did the Tower of Babel Fail? 73
Chapter 8 Calling the Shot 87
Chapter 9 Ten Pounds in a Five-Pound Sack 97
Chapter 10 The Documentary Hypothesis 107
Chapter 11 Plan to Throw One Away 115
Chapter 12 Sharp Tools 127
Chapter 13 The Whole and the Parts 141
Chapter 14 Hatching a Catastrophe 153
Chapter 15 The Other Face 163
Chapter 16 No Silver Bullet——Essence and Accident 179
Chapter 17 “No Silver Bullet” Refired 207
Chapter 18 Propositions of The Mythical Man-Month: True or False? 229
Chapter 19 The Mythical Man-Month after 20 Years 253
Epilogue 291
Notes and References 293
Index 309
中文目录
第1章 焦油坑 3
史前时代的焦油坑吞噬了成千上万个力大无穷的巨兽，今天的大型软件项目则令无数庞大的开发团队陷入无从逃脱的窘境。软件程序依其规模和目标的不同，对开放过程的要求也有极大的不同，这给软件开发这一职业带来无穷乐趣，同时也是这一行业苦恼的根源。
第2章 人月神话 13
软件开发项目常以人月来衡量工作量，这种度量暗示着人手和时间是可以互换的。这种“人多力量大”的想法是一种一厢情愿的虚妄神话，Brooks法则：向滞后的软件项目追加人手会使得进度更迟缓。自本书第1版出版以来，这一法则在软件业广为传诵。
第3章 外科手术团队 29
虽然优秀的程序员的工作效率往往数倍于平庸的程序员，但若是缺乏合理的配置，优秀的成员未必能构成优秀的团队。大型软件开发项目的团队需要和外科手术组一样妥善分工，各司其职协调配合。
第4章 元老制、民主制和系统设计 41
概念完整性是系统设计中最重要的因素，尤其对于大型软件系统来说，概念完整性是项目顺利完成的必要保障。为获得概念完整性，架构设计由精简的架构设计小组负责，具体实现则围绕核心概念展开。架构设计和具体实现既相分离，又相辅相成。
第5章 第二个系统效应 53
人们在第一个系统成功完成后，往往会在开发后续的第二个系统时犯冒进的错误。第二个系统经常成为过度设计或画蛇添足的牺牲品。要避免这种错误，必须在第二个系统开发时审慎地考查技术环境的变化，广泛进行交流和沟通，聆听各方面的建议，确立严谨的估算和规划。
第6章 沟通顺畅 61
架构设计通常由核心设计小组完成，将设计概念传达到整个开发团队是贯彻概念完整性的必然要求。以System 360的开发经验为例，要贯彻概念完整性，需要在团队中保持良好顺畅的沟通和交流，采用形式化定义等技术可以确保概念被精确地定义和传达。独立的测试小组是系统质量的良好保证。
第7章 巴别塔为何失败 73
如果缺乏良好有效的沟通和协作，成员间难以有效地配合，团队项目的目标就无法实现。清晰的工作文档，明确的组织结构，合理的职责分配，都是大型软件项目最终成功的保证。
第8章 掌控之中 87
对大型软件系统产品的开发所需的时间和资源进行准确地估测，能让我们对项目进度和前景胸有成竹。软件代码的开发效率和代码模块之间所需的交互相关。界面交互复杂的程序需要更多的测试和调试时间，单纯地增加人手并不能有助于开发效率的提高。
第9章 袖里乾坤 97
最大化资源利用率，减少不必要的资源占用，合理规划，使软件系统在资源有限的情况下依然保证良好的性能，从而实现良好的可伸缩性和健壮性，这能体现软件开发人员精湛的设计技巧。巧妙的数据结构往往能大幅度地俭省资源耗费，提高系统运行的性能。
第10章 文档先行 107
在软件项目开发过程中，文档是不可或缺的，文档为整个团队规范了概念，以便于团队中的沟通协作以及进度校验。本章阐述了软件系统项目中至关重要的几类文档，这些关键文档应及时地更新，始终作为项目进展的有效指南。
第11章 准备抛弃 115
变化是永恒的，用户的需求和期望在变化，开发者对用户需求的理解在变化，适用的技术也在变化，故而最佳的解决策略也可随之变化。软件开发团队应灵活地配置人力和资源，适应开发过程中的种种问题。程序的复杂性、用户需求的不确定性、软硬件技术环境的发展等因素导致了软件维护工作并非总是能够百分之百地获得回报。
第12章 良工利器 127
软件开发项目所选择的技术和工具对保障项目能否令人满意地如期完成至关重要。合适的开发工具、评测技术能有事半功倍之效果，切于实用的工具和技术是项目团队的重要财富。本章提供了当年软件开发项目选择技术和工具的重要原则和建议。
第13章 整体和局部 141
大而无当的笼统见地并不能表现你真正地理解了一个软件系统，应该具体而系统地深入了解各个局部的技术。良好的自顶向下的设计，不仅能保证概念完整性，也能及早消灭许多隐患。应及早在软件项目中引入测试，错误发现得越早，修复错误的代价就越小。
第14章 潜伏的祸患 153
项目进度的滞后经常源自不易察觉的点滴延误的累积。软件项目的经理应该尽量建立可以明确量化的阶段性目标，定期进行严谨而规范的项目阶段性验收，了解项目的进展状况，并及时进行计划、资源和人力的调整。关键路径图等技术有助于观察项目的进度。
第15章 另一面 163
虽然用户直接使用软件系统，但在许多应用领域中，用户不可能仅仅凭借与软件的直接交互就迅速掌握其所有功能。故而提供给用户的使用说明等文档是软件呈现给用户的另外一面，它也能直接影响用户对软件的满意度和可用性评价。文档的用途决定它的形式和内容。
第16章 没有银弹——软件工程的必然和偶然 179
本文最初发表于1985年的IFIP第十届世界计算机大会上，此时距《人月神话》初版发行已有10年，其间计算机技术领域的变化令人振奋。但作者在此提出，由于软件的复杂性、一致性、变化性和不可见性，解决软件危机的银弹并不存在。作者点评了20世纪80年代前期被业界寄予厚望的一些新技术，讨论了它们在克服软件危机中所具备的优势和缺憾。作者预言在近十年内，没有任何单独的软件工程进展可以使软件生产率有数量级的提高。
第17章 再议“没有银弹” 207
相比《人月神话》初版而言，1986年发表的“没有银弹”(第16章)发表后引发了热烈的争论，本章结合20世纪80年代后期到90年代前期之间软件复用、面向对象程序开发等新技术的发展状况，回应了对《没有银弹》一文的各种主要异议，认为由于《没有银弹》一文归纳的软件的几大特性，人们期待中的重大突破不可能在近期内到来。
第18章 人月神话中的提议：是耶非耶 229
在撰写《人月神话》的回顾和更新过程中，作者发现初版中断言的观点甚少被软件工程研究和实践所抨击、证实或证伪，因此在本章中作者提炼了初版中15个章节中的概要，结合近年来软件技术的发展状况，对这些观点进行强调、修正和反思。
第19章 人月神话二十年 253
在《人月神话》初版发布二十周年后，计算机技术领域已有很大变化，《人月神话》体现出深远的影响力，初版中的许多观点依然经常被人们谈论和引用，其中有些断言至今仍被软件开发人员奉为圭臬。作者结合当前软件工程领域的发展现状重新梳理了初版中的各核心观点，强调了概念完整性，重新评议了第二个系统效应，反省了瀑布模型的局限性。结合初版中的观点，作者评述了图形桌面系统、信息隐藏、面向对象高级语言等技术的发展，以及近年来软件工程领域的重要成果。
跋 291
注解与参考文献 293
索引 309
猜您喜欢
