软件工程:人月神话(学习软件工程必看的好书).pdf

发布时间：2022-06-09 发布人：admin 分类：说明书资料大小：2.54M 资料格式：pdf 举报版权申诉

IceKimi1988-1112204-4744302543351335436.pdf-第1页.png

第1页 / 共218页

IceKimi1988-1112204-4744302543351335436.pdf-第2页.png

第2页 / 共218页

IceKimi1988-1112204-4744302543351335436.pdf-第3页.png

第3页 / 共218页

IceKimi1988-1112204-4744302543351335436.pdf-第4页.png

第4页 / 共218页

IceKimi1988-1112204-4744302543351335436.pdf-第5页.png

第5页 / 共218页

IceKimi1988-1112204-4744302543351335436.pdf-第6页.png

第6页 / 共218页

IceKimi1988-1112204-4744302543351335436.pdf-第7页.png

第7页 / 共218页

IceKimi1988-1112204-4744302543351335436.pdf-第8页.png

第8页 / 共218页

二十周年纪念版序言（Preface to the 20th Anniversary Edition！

第一版序言（Preface to the First Edition）

目录（Contents）

焦油坑（The Tar Pit）

编程系统产品

职业的乐趣

职业的苦恼

人月神话（The Mythical Man-Month）

乐观主义

人月

系统测试

空泛的估算

重复产生的进度灾难

外科手术队伍（The Surgical Team）

问题

Mills的建议

如何运作

团队的扩建

贵族专制、民主政治和系统设计（Aristocracy, Democracy, and System

概念一致性

获得概念的完整性

贵族专制统治和民主政治

在等待时，实现人员应该做什么？

画蛇添足（The Second-System Effect）

结构师的交互准则和机制

自律——开发第二个系统所带来的后果

贯彻执行（Passing the Word）

文档化的规格说明——手册

形式化定义

直接整合

会议和大会

多重实现

电话日志

产品测试

为什么巴比伦塔会失败？（Why Did the Tower of Babel Fail?）

巴比伦塔的管理教训

大型编程项目中的交流

项目工作手册

大型编程项目的组织架构

胸有成竹（Calling the Shot）

Portman的数据

Aron的数据

Harr的数据

OS/360的数据

Corbato的数据

削足适履（Ten Pounds in a Five-Pound Sack）

作为成本的程序空间

规模控制

空间技能

数据的表现形式是编程的根本

提纲挈领（The Documentary Hypothesis）

计算机产品的文档

大学科系的文档

软件项目的文档

为什么要有正式的文档？

未雨绸缪（Plan to Throw One Away）

试验性工厂和增大规模

唯一不变的就是变化本身

为变更计划系统

为变更计划组织架构

前进两步，后退一步

前进一步，后退一步

干将莫邪（Sharp Tools）

目标机器

辅助机器和数据服务

高级语言和交互式编程

整体部分（The Whole and the Parts）

剔除bug的设计

构件单元调试

系统集成调试

祸起萧墙（Hatching a Catastrophe）

里程碑还是沉重的负担？

“其他的部分反正会落后”

地毯的下面

另外一面（The other face）

需要什么样的文档

流程图

自文档化（self-documenting）的程序

没有银弹－软件工程中的根本和次要问题（No Silver Bullet – Essence an�

摘要1

介绍

是否一定那么困难呢？——根本困难

以往解决次要困难的一些突破

银弹的希望

针对概念上根本问题的颇具前途的方法

再论《没有银弹》（“No Silver Bullet”Refired）

人狼和其他恐怖传说

存在着银弹－就在这里！

含糊的表达将会导致误解

Harel的分析

Jone的观点——质量带来生产率

那么，生产率的情形如何？

面向对象编程——这颗铜质子弹可以吗？

重用的情况怎样？

学习大量的词汇——对软件重用的一个可预见，但还没有被预言的问题

子弹的本质——形势没有发生改变

《人月神话》的观点：是或非？（Propositions of the Mythical Man�

第1章焦油坑

第2章人月神话

第3章外科手术队伍

第4章贵族专制、民主政治和系统设计

第5章画蛇添足

第6章贯彻执行

第7章为什么巴比伦塔会失败？

第8章胸有成竹

第9章削足适履

第10章提纲挈领

第11章未雨绸缪

第12章干将莫邪

第13章整体部分

第14章祸起萧墙

第15章另外一面

原著结束语

20年后的人月神话（The Mythical Man-Month after 20 Years）

为什么会出现二十周年纪念版本？

核心观点：概念完整性和结构师

开发第二个系统所引起的后果：盲目的功能和频率猜测

图形（WIMP）界面的成功

没有构建舍弃原型——瀑布模型是错误的！

增量开发模型更佳——渐进地精化

关于信息隐藏，Parnas是正确的，我是错误的

人月到底有多少神话色彩？Boehm的模型和数据

人就是一切（或者说，几乎是一切）

放弃权力的力量

最令人惊讶的新事物是什么？数百万的计算机

全新的软件产业——塑料薄膜包装的成品软件

买来开发——使用塑料包装的成品软件包作为构件

软件工程的状态和未来

结束语：令人向往、激动人心和充满乐趣的五十年（Epilogue Fifty Years of Wo�

注解和参考文献（Notes and References）

第1章

第2章

第3章

第4章

第5章

第6章

第7章

第8章

第9章

第10章

第11章

第12章

第13章

第14章

第15章

第16章

第17章

第18章

第19章

索引（Index）

TTHHEE MMYYTTHHIICCAALL MMAANN--MMOONNTTHH 人人月月神神话话 FREDERICK P. BROOKS, JR. 翻译：Adams Wang

关于作者 Frederick P. Brooks，Jr.是北卡罗来纳大学 Kenan-Flagler 商学院的计算机科学教授，北卡来罗来纳大学位于美国北卡来罗来纳州的查布尔希尔。Brooks 被认为是“IBM 360 系统之父”，他担任了 360 系统的项目经理，以及 360 操作系统项目设计阶段的经理。凭借在上述项目的杰出贡献，他、Bob Evans 和 Erich Bloch 在 1985 年荣获了美国国家技术奖（National Medal of Techology）。早期，Brooks 曾担任 IBM Stretch 和 Harvest 计算机的体系结构师。在查布尔希尔，Brooks 博士创立了计算机科学系，并在 1964 至 1984 年期间担任主席。他曾任职于美国国家科技局和国防科学技术委员会。Brooks 目前的教学和研究方向是计算机体系结构、分子模型绘图和虚拟环境。

1 9 7 5 年版献辞致两位特别丰富了我IBM岁月的人： Thomas J. Watson, Jr.，他对人们的关怀在他的公司依然无所不在和 Bob O. Evans，他大胆的领导使工作成为了探险。 1 9 9 5 年版献辞致Nancy，上帝赐给我的礼物。

二十周年纪念版序言（Preface to the 20th Anniversary Edition）令我惊奇和高兴的是，《人月神话》在 20 年后仍然继续流行，印数超过了 250,000。人们经常问，我在 1975 年提出的观点和建议，哪些是我仍然坚持的，哪些是已经改变观点的，是怎样改变的？尽管我在一些讲座上也分析过这个问题，我还是一直想把它写成文章。 Peter Gordon 现在是 Addison-Wesley 的出版伙伴，他从 1980 年开始和我共事。他非常耐心，对我帮助很大。他建议我们准备一个纪念版本。我们决定不对原版本做任何修订，只是原封不动地重印（除了一些细小的修正），并用更新的思想来扩充它。第 16 章重印了一篇在 1986 年 IFIPS 会议上的论文《没有银弹：软件工程的根本和次要问题》。这篇文章来自我在国防科学委员会主持军用软件方面研究时的经验。我当时的研究合作者，也是我的执行秘书，Robert L. Patrick 帮助我回想和感受那些做过的软件大项目。1987 年，IEEE 的《计算机》杂志重印了这篇论文，使它传播得更广了。《没有银弹》被证明是富有煽动性的，它预言十年内没有任何编程技巧能够给软件的生产率带来数量级上的提高。十年只剩下一年了，我的预言看来安全了。《没有银弹》激起了越来越多文字上的剧烈争论，比《人月神话》还要多。因此在第 17 章，我对一些公开的批评作了说明，并更新了在 1986 年提出的观点。在准备《人月神话》的回顾和更新时，一直进行的软件工程研究和经验已经批评、证实和否定了少数书中断言的观点，也影响了我。剥去辅助的争论和数据后，把那些观点粗略地分类，对我来说很有帮助。我在第 18 章列出这些观点的概要，希望这些单调的陈述能够引来争论和证据，然后得到证实、否定、更新或精炼。第 19 章是一篇更新的短文。读者应该注意的是，新观点并不象原来的书一样来自我的亲身经历。我在大学里工作，不是在工业界，做的是小规模的项目，不是大项目。自 1986 年以来，我就只是教授软件工程，不再做这方面的研究。我现在的研究领域是虚拟环境及其应用。在这次回顾的准备过程中，我找了一些正工作在软件工程领域的朋友，征求他们的当 - i -

前观点。他们很乐意和我共享他们的想法，并仔细地对草稿提出了意见，这些都使我重新受到启发。感谢 Barry Boehm、Ken Brooks、Dick Case、James Coggins、Tom Demarco、Jim McCarthy、David Parnas、Earl Wheeler 和 Edward Yourdon。感谢 Fay Eard 出色地对新的章节进行了技术加工。感谢我在国防科学委员会军事软件工作组的同事 Gordon Bell、Bruce Buchanan、Rick Hayes-Roth，特别是 David Parnas，感谢他们的洞察力和生动的想法。感谢 Rebekah Bierly 对 16 章的论文进行了技术加工。我把软件问题分成“根本的”和“次要的”，这是受 Nancy Greenwood Brooks 的启发，她在一篇 Suzuki 小提琴教育的论文中应用了这样的分析方法。在 1975 年版本的序言中，Addison-Wesleys 出版社按规定不允许我向它的一些扮演了关键角色的员工致谢。有两个人的贡献必须被特别提到：执行编辑 Norman Stanton 和美术指导 Herbert Boes。Boes 设计了优雅的风格，他在评注时特别提到：“页边的空白要宽，字体和版面要有想像力”。更重要的是，他提出了至关重要的建议：为每一章的开头配一幅图片（当时我只有“焦油坑”和“兰斯大教堂”的图片）。寻找这些图片使我多花了一年的时间，但我永远感激这个忠告。 Soli Deo gloria－愿神独得荣耀。查珀尔希尔，北卡罗来纳 F.P.B., Jr. 1995 年 3 月 - ii -

第一版序言（Preface to the First Edition）在很多方面，管理一个大型的计算机编程项目和其它行业的大型工程很相似——比大多数程序员所认为的还要相似；在很多另外的方面，它又有差别——比大多数职业经理所认为的差别还要大。这个领域的知识在累积。现在 AFIPS（美国信息处理学会联合会）已经有了一些讨论和会议，也出版了一些书籍和论文，但是还没有成型的方法来系统地进行阐述。提供这样一本主要反映个人观点的小书看来是合适的。虽然我原来从事计算机科学的编程方面的工作，但是在 1956-1963 年间自动控制程序和高级语言编译器开发出来的时候，我主要参加的是硬件构架方面的工作。在 1964 年，我成为操作系统 OS/360 的经理，发现前些年的进展使编程世界改变了很多。管理 OS/360 的开发是很有帮助的经历，虽然是失败的。那个团队，包括我的继任经理 F. M. Trapnell，有很多值得自豪的东西。那个系统包括了很多优秀的设计和实施，成功地应用在很多领域，特别是设备无关的输入输出和外部库管理，被很多技术革新广泛复制。它现在是十分可靠的，相当有效，和非常通用的。但是，并不是所有的努力都是成功的。所有 OS/360 的用户很快就能发现它应该做得更好。设计和实现上的缺陷在控制程序中特别普遍，相比之下，语言编译器就好得多。大多数这些缺陷发生在 1964-1965 年的设计阶段，所以这肯定是我的责任。此外，这个产品发布推迟了，需要的内存比计划中的要多，成本也是估计的好几倍，而且第一次发布时并不能很好地运行，直到发布了几次以后。就象当初接受 OS/360 的任务时协商好的，在 1965 年离开 IBM 后，我来到查珀尔希尔。我开始分析 OS/360 的经验，看能不能从中学到什么管理和技术上的教训。特别地，我要说明 System/360 硬件开发和 OS/360 软件开发中的管理经验是非常不同的。对 Tom Watson 关于为什么编程难以管理的探索性问题，这本书是一份迟来的答案。在这次探索中，我和 1964-65 年的经理助理 R.P.Case，还有 1965-68 年的经理 F.M.Trapnell，进行了长谈，从中受益良多。我对比了其他大型编程项目的经理的结论，包括 M.I.T.的 F.J.Corbato，Bell 电话实验室的 V.Vyssotsky，International Computers - iii -

Limited 的 Charles Portman，苏联科学院西伯利亚分部计算实验室的 A.P.Ershov，和 IBM 的 A.M.Pietrasanta。我自己的结论体现在下面的文字中，送给职业程序员、职业经理、特别是程序员的职业经理。虽然写出来的是分离的章节，还是有一个中心的论点，特别包含在第 2-7 章。简言之，我相信由于人员的分工，大型编程项目碰到的管理问题和小项目区别很大；我相信关键需要是维持产品自身的概念完整性。这些章节探讨了其中的困难和解决的方法。后续的章节探讨软件工程管理的其他方面。这个领域的文献并不多，但散布很广。因此我尝试给出参考资料，说明某个特定知识点和指引感兴趣的读者去看其他有用的工作。很多朋友读过了本书的手稿，其中一些朋友给出了很有帮助的意见。这些意见很有价值，但为了不打乱文字的通顺，我把它们作为注解包含在书中。因为这本书是随笔不是课本，所有的参考文献和注解都被放到书的末尾，建议读者在读第一遍时略去不看。深切感谢 Sara Elizabeth Moore 小姐，David Wagner 先生，和 Rebecca Burris 夫人，他们帮助我准备了手稿。感谢 Joseph C.Sloane 教授在图解方面的建议。查珀尔希尔，北卡罗来纳 F.P.B., Jr 1974 年 10 月 - iv -

目录（Contents）二十周年纪念版序言（PREFACE TO THE 20TH ANNIVERSARY EDITION） ...................... I 第一版序言（PREFACE TO THE FIRST EDITION） ............................................................ III 目录（CONTENTS）.....................................................................................................................V 焦油坑（THE TAR PIT） ..............................................................................................................1 编程系统产品...............................................................................................................................1 职业的乐趣...................................................................................................................................3 职业的苦恼...................................................................................................................................4 人月神话（THE MYTHICAL MAN-MONTH）...........................................................................6 乐观主义.......................................................................................................................................7 人月...............................................................................................................................................8 系统测试.....................................................................................................................................10 空泛的估算.................................................................................................................................11 重复产生的进度灾难.................................................................................................................12 外科手术队伍（THE SURGICAL TEAM） ...............................................................................16 问题.............................................................................................................................................16 MILLS 的建议 .............................................................................................................................17 如何运作.....................................................................................................................................20 团队的扩建.................................................................................................................................21 贵族专制、民主政治和系统设计（ARISTOCRACY, DEMOCRACY, AND SYSTEM DESIGN） ........................................................................................................................................................22 概念一致性.................................................................................................................................22 获得概念的完整性.....................................................................................................................23 贵族专制统治和民主政治.........................................................................................................24 在等待时，实现人员应该做什么？.........................................................................................26 画蛇添足（THE SECOND-SYSTEM EFFECT）......................................................................29 结构师的交互准则和机制.........................................................................................................29 自律——开发第二个系统所带来的后果.................................................................................30 贯彻执行（PASSING THE WORD） ..........................................................................................33 文档化的规格说明——手册.....................................................................................................33 形式化定义.................................................................................................................................34 直接整合.....................................................................................................................................36 会议和大会.................................................................................................................................36 多重实现.....................................................................................................................................38 - v -

分享到：

赞收藏

资料库

软件工程:人月神话(学习软件工程必看的好书).pdf

相关推荐

课程资源

热门标签

最新资料