软件工程：人月神话

近期要读的书

软件工程：人月神话
无忧书籍网 www.51shuji.com

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

         
   在很多方面，管理一个大型的计算机编程项目和其它行业的大型工程很相似——比大多数程序员所认为的还要相似；在很多另外的方面，它又有差别——比大多数职业经理所认为的差别还要大。
这个领域的知识在累积。现在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 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月