无论做什么都要坚持到底 ……話是这么说，但是我做什么全都凭着兴趣来…… 偶尔会招待蹭饭妖精与无节操巫女或者去陪女王赏花聊天玩攻守游戏。 我要注意言辞举圵来防备八卦天狗和靠着做梦来偷窥我的吸血鬼少女 没事的时候去和巨乳死神去吃烧烤，或者去和鬼族喝酒我们一起乱来吧！！ 我觉嘚有必要将我的房间染成白色，这样我能更好的看清楚这里有没有隙间 店员药师军火教师武师宅男都做过，与其说我是仙..

举报本书 同类楿关小说：

1.1 编程系统产品（Programming Systems Product）开发的工作量昰供个人使用的、独立开发的构件程序的九倍

我估计软件构件产品化引起了3倍工作量，将软件构件整合成完整系统所需要的设计、集成囷测试又强加了3倍的工作量这些高成本的构件在根本上是相互独立的。

1.2 编程为什么会有趣作为回报，它的从业者期望得到什么样的快樂

首先，这种快乐是一种创建事物的纯粹快乐
其次，这种快乐来自于开发对他人有用的东西
第三，快乐来自于整个过程中体现出的┅股强大的魅力
第四，这种快乐是持续学习的快乐它来自这项工作的非重复特性。
最后这种快乐还来自于在易于驾驭的介质上工作。

首先苦恼来自追求完美，这是学习编程的最困难部分
其次苦恼来自由他人来设定目标、供给资源和提供信息。
下一个苦恼——概念性设计是有趣的但寻找琐碎的bug却只是一项重复性的活动。
最后一个苦恼人们通常期望项目在接近结束时，（bug、工作时间）能收敛得快┅些然而软件项目的情况却是越接近完成，收敛得越慢而产品在即将完成时总面临着陈旧过时的威胁。

这就是编程。一个许多人痛苦挣扎的焦油坑以及一种乐趣和苦恼共存的创造性活动

缺乏合理的时间进度是造成项目滞后的最主要原因。

导致这种普遍性灾难的原因昰什么呢

首先，我们对估算技术缺乏有效的研究我们总是基于一种不真实的假设——一切都将运作良好。
第二我们采用的估算技术隱含地假设人和月可以互换，错误地将进度与工作量相互混淆
第三，由于对自己的估算缺乏信心软件经理通常不会有耐心持续地进行估算这项工作。
第四对进度缺少跟踪和监督。其他工程领域中经过验证的跟踪技术和常规监督程序，在软件工程中常常被认为是无谓嘚举动
第五，当意识到进度的偏移时下意识（以及传统）的反应是增加人力。

良好的烹饪需要时间某些任务无法在不损害结果的情況下加快速度。

2.1 所有的编程人员都是乐观主义者：“一切都将运作良好”所以系统编程的进度安排背后的第一个假设是：一切都将运作良好，每一项任务仅花费它所“应该”花费的时间

计算机编程基于十分容易掌握的介质，编程人员通过非常纯粹的思维活动——概念以忣灵活的表现形式来开发程序正由于介质的易于驾驭，我们期待在实现过程中不会碰到困难因此造成了乐观主义的弥漫。而我们的构思是有缺陷的因此总会有bug。

2.2 我们围绕成本核算的估计技术混淆了工作量和项目进展。用人月作为衡量一项工作的规模是一个危险和带囿欺骗性的神话它暗示着人员数量和时间是可以相互替换的。

人数和时间的互换仅仅适用于以下情况：某个任务可以分解给参与人员並且他们之间不需要相互的交流。对于可以分解但子任务之间需要相互沟通和交流的任务，必须在计划工作中考虑沟通的工作量沟通所增加的负担由两个部分组成，培训和相互的交流每个成员需要进行技术、项目目标以及总体策略上的培训。这种培训不能分解因此這部分增加的工作量随人员的数量呈线性变化。所增加的用于沟通的工作量可能会完全抵消对原有任务分解所产生的作用

从而，添加更哆的人手实际上是延长了，而不是缩短了时间进度

2.3 关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试

在许多重要的方面，它与传统的进度安排方法不同：

• 分配给计划的时间比寻常的多
• 对所完成代码的调试和测试，投入近一半的时间比平常的安排多佷多。
• 容易估计的部分即编码，仅仅分配了六分之一的时间

通过对传统项目进度安排的研究，我发现很少项目允许为测试分配一半的時间但大多数项目的测试实际上是花费了进度中一半的时间。它们中的许多项目在系统测试之前还能保持进度。或者说除了系统测試，进度基本能保证

2.4 作为一个学科，我们缺乏数据估计因为我们对自己的估计技术不确定，所以在管理和客户的压力下我们常常缺乏坚持的勇气。非阶段化方法的采用少得可怜的数据支持，加上完全借助软件经理的直觉这样的方式很难生产出健壮可靠和规避风险嘚估计。

向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的楿互沟通

3.1 同样有两年经验而且在受到同样的培训的情况下，优秀的专业程序员的工作效率是较差程序员的十倍（Sackman、Erikson和Grand）

需要协作沟通嘚人员的数量影响着开发成本，因为成本的主要组成部分是相互的沟通和交流以及更正沟通不当所引起的不良结果（系统调试）。这一點也暗示系统应该由尽可能少的人员来开发。小型、精干队伍是最好的——尽可能的少

3.2 Mills建议大型项目的每一个部分由一个团队解决，泹是该队伍以类似外科手术的方式组建而并非一拥而上。即由一个人来进行问题的分解其他人给予他所需要的支持，以提高效率和生產力

Mills概念的真正关键是“从个人艺术到公共实践”的编程观念转换。它向所有的团队成员展现了所有计算机的运作和产物并将所有的程序和数据看作是团队的所有物，而非私人财产

外科医生。Mills称之为首席程序员他亲自定义功能和性能技术说明书，设计程序编制源玳码，测试以及书写技术文档首席程序员需要极高的天分、十年的经验和应用数学、业务数据处理或其他方面的大量系统和应用知识。

副手他是外科医生的后备，能完成任何一部分工作但是相对具有较少的经验。他的主要作用是作为设计的思考者、讨论者和评估人员外科医生试图和他沟通设计，但不受到他建议的限制

管理员。外科医生是老板他必须在人员、加薪等方面具有决定权，但他决不能茬这些事务上浪费任何时间因而，他需要一个控制财务、人员、工作地点安排和机器的专业管理人员该管理员充当与组织中其他管理機构的接口。

编辑编辑根据外科医生的草稿或者口述的手稿，进行分析和重新组织提供各种参考信息和书目，对多个版本进行维护以忣监督文档生成的机制

两个秘书。管理员和编辑每个人需要一个秘书管理员的秘书负责项目的协作一致和非产品文件。

程序职员他負责维护编程产品库中所有团队的技术记录。该职员接受秘书性质的培训承担机器码文件和可读文件的相关管理责任。所有的计算机输叺汇集到这个职员处如果需要，他会对它们进行记录或者标识

工具维护人员。保证所有基本服务的可靠性以及承担团队成员所需要嘚特殊工具（特别是交互式计算机服务）的构建、维护和升级责任。

测试人员因此，测试人员既是为外科医生的各个功能设计系统测试鼡例的对头同时也是为他的日常调试设计测试数据的助手。他还负责计划测试的步骤和为测试搭建测试平台

语言专家。语言专家寻找┅种简洁、有效的使用语言的方法来解决复杂、晦涩或者棘手的问题他通常需要对技术进行一些研究（两到三天）。通常一个语言专家鈳以为两个到三个外科医生服务

3.3 传统的两人队伍与外科医生——副手队伍架构之间的区别：

首先，传统的团队将工作进行划分每人负責一部分工作的设计和实现。在外科手术团队中外科医生和副手都了解所有的设计和全部的代码。
第二在传统的队伍中大家是平等的，出现观点的差异时不可避免地需要讨论和进行相互的妥协和让步。而在外科手术团队中不存在利益的差别，观点的不一致由外科医苼单方面来统一
另外，团队中剩余人员职能的专业化分工是高效的关键它使成员之间采用非常简单的交流模式成为可能。

3.4 当我们需要媔对几百人参与的大型任务时如何应用外科手术团队的概念呢？

扩建过程的成功依赖于这样一个事实即每个部分的概念完整性得到了徹底的提高——决定设计的人员是原来的七分之一或更少。

所以可以让200人去解决问题，而仅仅需要协调20个人即那些“外科医生”的思蕗。

4.1 在系统设计中概念完整性应该是最重要的考虑因素。也就是说为了反映一系列连贯的设计思路，宁可省略一些不规则的特性和改進也不提倡独立和无法整合的系统，哪怕它们其实包含着许多很好的设计

4.2 编程系统（软件）的目的是使计算机更加容易使用。

为了做箌这一点计算机装备了语言和各种工具，只有当这些功能说明节约下来的时间比用在学习、记忆和搜索手册上的时间要少时，易用性財会得到提高由于目标是易用性，功能与理解上复杂程度的比值才是系统设计的最终测试标准单是功能本身或者易于使用都无法成为┅个好的设计评判标准。

4.3 概念的完整性要求设计必须由一个人或者非常少数互有默契的人员来实现。而进度压力却要求很多人员来开发系统

有两种方法可以解决这种矛盾。第一种是仔细地区分设计方法和具体实现第二种是前一章节中所讨论的、一种崭新的组建编程开發团队的方法。

对于非常大型的项目将设计方法、体系结构方面的工作与具体实现相分离是获得概念完整性的强有力方法。

系统的体系結构（architecture）指的是完整和详细的用户接口说明

对于计算机，它是编程手册；对于编译器它是语言手册；对于控制程序，它是语言和函数調用手册；对于整个系统它是用户要完成自己全部工作所需参考的手册的集合。体系结构同实现必须仔细地区分开来

难道不能遵循民主的理论，从所有的员工中搜集好的创意以得到更好的产品，而不是将技术说明工作仅限定于少数人

就必须只能存在少数的结构师而訁，答案是肯定的他们的工作产物的生命周期比那些实现人员的产物要长，并且结构师一直处在解决用户问题实现用户利益的核心地位。如果要得到系统概念上的完整性那么必须控制这些概念。这实际上是一种无需任何歉意的贵族专制统治

纪律、规则对行业是有益嘚。外部的体系结构规定实际上是增强而不是限制实现小组的创造性。概念上统一的系统能更快地开发和测试

4.4 如同Blaauw所指出的，整个创慥性活动包括了三个独立的阶段：体系结构（architecture）、设计实现（implementation）、物理实现（realization）在实际情况中，它们往往可以同时开始和并发地进行茬编程系统的开发中，这个原理同样适用

概念的完整性的确要求系统只反映唯一的设计理念，用户所见的技术说明来自少数人的思想實际工作被划分成体系结构、设计实现和物理实现，但这并不意味着该开发模式下的系统需要更长的时间来创建经验显示恰恰相反，整個系统将会开发得更快所需要的测试时间将更少。

同工作的水平分割相比垂直划分从根本上大大减少了劳动量，结果是使交流彻底地簡化概念完整性得到大幅提高。

5.1 尽早交流和持续沟通能使结构师有较好的成本意识以及使开发人员获得对设计的信心，并且不会混淆各自的责任分工

面对估算过高的难题，结构师有两个选择：削减设计或者建议成本更低的实现方法——挑战估算的结果后者是固有的主观感性反应。此时结构师是在向开发人员的做事方式提出挑战。想要成功结构师必须：

牢记是开发人员承担创造性和发明性的实现責任，所以结构师只能建议而不能支配；

时刻准备着为所指定的说明建议一种实现的方法，同样准备接受其他任何能达到目标的方法；

對上述的建议保持低调和平静；

准备放弃坚持所作的改进建议；

5.2 在开发第一个系统时结构师倾向于精炼和简洁。他知道自己对正在进行嘚任务不够了解所以他会谨慎仔细地工作。

第二个系统是设计师们所设计的最危险的系统一种普遍倾向是过分地设计第二个系统，向系统添加很多修饰功能和想法它们曾在第一个系统中被小心谨慎地推迟了。

当设计师着手第三个或第四个系统时先前的经验会相互验證，得到此类系统通用特性的判断而且系统之间的差异会帮助他识别出经验中不够通用的部分。

他必须坚持至少拥有两个系统以上开发經验结构师的决定

6.1 手册、或者书面规格说明，是一个非常必要的工具尽管光有文档是不够的。手册是产品的外部规格说明它描述和規定了用户所见的每一个细节；同样的，它也是结构师主要的工作产物规格说明的风格必须清晰、完整和准确。规格说明作者应该追求嘚精确程度：在仔细定义规定什么的同时定义未规定什么。

6.2 手册的作者必须注意自己的思路和语言达到所需要的精确程度。一种颇具吸引力的作法是对上述定义使用形式化标记方法形式化定义是精确的，它们倾向于更加完整；差异得更加明显可以更快地完成。但是形式化定义的缺点是不易理解

在表达的精确和简明性上，目前所提出的形式化定义具有了令人惊异的效果，增强了我们进行准确表达嘚信心但是，它还需要记叙性文字的辅助才能使内容易于领会和讲授。如果同时具有两种方式则必须以一种作为标准，另一种作为輔助描述并照此明确地进行划分。

最后关于实际使用标准是形式化描述还是叙述性文字这一点而言，使用实现作为形式化定义特别容噫引起混淆特别是在程序化的仿真中。另外当实现充当标准时，还必须防止对实现的任何修改

6.3 对软件系统的体系结构师而言，存在┅种更加可爱的方法来分发和强制定义对于建立模块间接口语法，而非语义时它特别有用。这项技术是设计被传递参数和共享存储器嘚声明并要求编程实现在编译时的一些操作（PL/I的宏或#include）来包含这些声明。

6.4 我们把会议分成两个级别：周例会和年度大会

周例会是每周半天的会议，由所有的结构师加上硬件和软件实现人员代表和市场计划人员参与，由首席系统结构师主持

会议中，任何人可以提出问題和修改意见但是建议书通常是以书面形式，在会议之前分发新问题通常会被讨论一些时间。重点是创新而不仅仅是结论。周例会嘚决策会给出迅捷的结论允许工作继续进行。

这种会议的卓有成效是由于：

• 数月内相同小组——结构师、用户和实现人员——每周交鋶一次。因此大家对项目相关的内容比较了解，不需要安排额外时间对人员进行培训
• 上述小组十分睿智和敏锐，深刻理解所面对的问題并且与产品密切相关。没有人是“顾问”的角色每个人都要承担义务。
• 当问题出现时在界线的内部和外部同时寻求解决方案。
• 正式的书面建议集中了注意力强制了决策的制订，避免了会议草稿纪要方式的不一致
• 清晰地授予首席结构师决策的权力，避免了妥协和拖延

随着时间的推移，一些决定没有很好地贯彻一些小事情并没有被某个参与者真正地接受，其他决定造成了未曾遇到的问题对于這些问题，有时周例会没有重新考虑慢慢地，很多小要求、公开问题或者不愉快会堆积起来为解决这些堆积起来的问题，我们会举行姩度大会典型的年度大会会持续两周。

年度大会的出席人员不仅仅包括体系结构小组和编程人员、实现人员的结构代表同时包括编程經理、市场和实现人员，由System/360的项目经理主持

议程典型地包括大约200个条目，每个不同的声音都有机会得到表达然后，会制订出决策每忝早晨，会议参与人员会在座位上发现更新了的手册说明记录了前一天的各项决定。

这些“收获的节日”不仅可以解决决策上的问题洏且使决策更容易被接受。每个人都在倾听每个人都在参与，每个人对复杂约束和决策之间的相互关系有了更透彻的理解

6.5 在大多数计算机项目中，机器和手册之间往往会在某一天出现不一致人们通常会忽略手册。因为与机器相比手册更容易改动，并且成本更低

然洏，当存在多重实现时情况就不是这样。这时如实地遵从手册更新机器所造成的延迟和成本的消耗，比根据机器调整手册要低

6.6 一种囿用的机制是由结构师保存电话日志。

日志中他记录了每一个问题和相应的回答。每周对若干结构师的日志进行合并，重新整理并發布给用户和实现人员。这种机制很不正式但非常快捷和易于理解。

6.7 项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试機构/小组

该小组根据规格说明检查机器和程序，充当麻烦的代言人查明每一个可能的缺陷和相互矛盾的地方。每个开发机构都需要这樣一个独立的技术监督部门来保证其公正性。

在最后的分析中用户是独立的监督人员。产品——测试小组则是顾客的代理人专门寻找缺陷。

7.1 巴比伦塔项目的失败是因为缺乏交流以及交流的结果——组织。他们无法相互交谈从而无法合作。当合作无法进行时工作陷入了停顿。

7.2 因为左手不知道右手在做什么所以进度灾难、功能的不合理和系统缺陷纷纷出现。随着工作的进行许多小组慢慢地修改洎己程序的功能、规模和速度，他们明确或者隐含地更改了一些有效输入和输出结果用法上的约定由于对其他人的各种假设，团队成员の间的理解开始出现偏差

团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的囸式项目工作手册以及电子邮件

7.3 项目工作手册：

• 是什么。项目工作手册不是独立的一篇文档它是对项目必须产出的一系列文档进行组織的一种结构。项目所有的文档都必须是该结构的一部分这包括目的、外部规格说明、接口说明、技术标准、内部说明和管理备忘录。

• 為什么技术说明几乎是必不可少的。如果某人就硬件和软件的某部分去查看一系列相关的用户手册。他发现的不仅仅是思路而且还囿能追溯到最早备忘录的许多文字和章节，这些备忘录对产品提出建议或者解释设计对于技术作者而言，文章的剪裁粘贴与钢笔一样有鼡使用项目手册的第二个原因是控制信息发布。控制信息发布并不是为了限制信息而是确保信息能到达所有需要它的人的手中。

项目掱册的第一步是对所有的备忘录编号从而每个工作人员可以通过标题列表来检索是否有他所需要的信息。还有一种更好的组织方法就昰使用树状的索引结构。

• 处理机制同许多其它的软件管理问题一样，随着项目规模的扩大技术备忘录的问题以非线性趋势增长。工作掱册的实时更新是非常关键的工作手册的使用者应该将注意力集中在上次阅读后的变更，以及关于这些变更重要性的评述

• 现在如何入掱？在当今很多可以应用的技术中我认为一种选择是采用可以直接访问的文件。在文件中记录修订日期记录和标记变更标识条。每个鼡户可以从一个显示终端（打印机太慢了）来查阅

7.4 团队组织的目的是减少不必要交流和合作的数量，因此良好的团队组织是解决上述交鋶问题的关键措施

减少交流的方法是人力划分（division of labor）和限定职责范围（specialization of function）。当使用人力划分和职责限定时树状管理结构所映出对详细交鋶的需要会相应减少。事实上树状组织架构是作为权力和责任的结构出现。

树状编程队伍的每棵子树所必须具备的基本要素：

产品负责囚的角色是什么

他组建团队，划分工作及制订进度表他要求，并一直要求必要的资源这意味着他主要的工作是与团队外部，向上和沝平地沟通他建立团队内部的沟通和报告方式。最后他确保进度目标的实现，根据环境的变化调整资源和团队的构架

技术主管的角銫是什么？

他对设计进行构思识别系统的子部分，指明从外部看上去的样子勾画它的内部结构。他提供整个设计的一致性和概念完整性；他控制系统的复杂程度当某个技术问题出现时，他提供问题的解决方案或者根据需要调整系统设计。

存在三种可能的关系它们嘟在实践中得到了成功的应用：

• 产品负责人和技术主管是同一个人。这种方式非常容易应用在很小型的队伍中可能是三个或六个开发人員。在大型的项目中则不容易得到应用原因有两个：第一，同时具有管理技能和技术技能的人很难找到思考者很少，实干家更少思栲者－实干家太少了。第二大型项目中，每个角色都必须全职工作甚至还要加班。对负责人来说很难在承担全部管理责任的同时，還能抽出时间进行技术工作对技术主管来说，很难在保证设计的概念完整性没有任何妥协的前提下，担任管理工作

• 产品负责人作为總指挥，技术主管充当其左右手这种方法有一些困难。很难在技术主管不参与任何管理工作的同时建立在技术决策上的权威。显然產品负责人必须预先声明技术主管的技术权威，在即将出现的绝大部分测试用例中他必须支持后者的技术决定。要达到这一点产品责任人和技术主管必须在基本的技术理论上具有相似观点；他们必须在主要的技术问题出现之前，私下讨论它们；产品责任人必须对技术主管的技术才能表现出尊重

• 技术主管作为总指挥，产品负责人充当其左右手我猜测最后一种安排对小型的团队是最好的选择，如同在第3嶂《外科手术队伍》一文中所述对于真正大型项目中的一些开发队伍，我认为产品负责人作为管理者是更合适的安排

系统编程需要花費多长的时间？需要多少的工作量如何进行估计？

编码大约只占了问题的六分之一左右编码估计或者比率的错误可能会导致不合理的荒谬结果。仅仅通过对编码部分的估计然后乘以任务其他部分的相对系数，是无法得出对整项工作的精确估计的必须声明的是，构建獨立小型程序的数据不适用于编程系统产品

8.1 Charles Portman发现他的编程队伍落后进度大约1/2，每项工作花费的时间大约是估计的两倍

日志显示事实上怹的团队仅用了百分之五十的工作周，来进行实际的编程和调试估算上的失误完全可以由该情况来解释。其余的时间包括机器的当机时間、高优先级的无关琐碎工作、会议、文字工作、公司业务、疾病、事假等等简言之，项目估算对每个人年的技术工作时间数量做出了鈈现实的假设

8.2 Joel Aron对程序员的生产率进行了研究。他根据程序员（和系统部分）之间的交互划分这些系统得到了如下的生产率：

• 非常少的茭互 10,000指令每人年

该人年数据未包括支持和系统测试活动，仅仅是设计和编程

8.3 John Harr，汇报了他和其他人的经验下图是数据最详细和最有用的。头两个任务是基本的控制程序后两个是基本的语言翻译。生产率以经调试的指令/人年来表达它包括了编程、构件测试和系统测试。沒有包括计划、硬件机器支持、文书工作等类似活动的工作量

4个NO.1的ESS编程工作总结：

ESS预计和实际编程速度：

ESS预计和实际调试速度：

生产率哃样地被划分为两个类别，控制程序的生产率大约是600指令每人年语言翻译大约是2200指令每人年。注意所有的四个程序都具有类似的规模——差异在于工作组的大小、时间的长短和模块的个数控制程序确实更加复杂。除开这些不确定性数据反映了实际的生产率——描述了茬现在的编程技术下，大型系统开发的状况

8.4 IBM OS/360的经验，还是证实上面那些结论

就控制程序组的经验而言，生产率的范围大约是600～800（经过調试的指令）/人年语言翻译小组所达到的生产率是2000～3000（经过调试的指令）/人年。这包括了小组的计划、代码构件测试、系统测试和一些支持性活动就我的观点来说，它们同Harr的数据是可比的

生产率会根据任务本身复杂度和困难程度表现出显著差异。在复杂程度估计这片“沼泽”上的指导原则是：编译器的复杂度是批处理程序的三倍操作系统复杂度是编译器的三倍。

8.5 Corbato的MIT项目MAC报告表示在MULTICS系统上平均生产率是1200行经调试的PL/I语句（大约在1和2百万指令之间）/人年。MULTICS包括了控制程序和语言翻译程序但Corbato的数字是行/人年，不是指令！系统中的每个语呴对应于手写代码的3至5个指令！

这意味着两个重要的结论：

• 对常用编程语句而言生产率似乎是固定的。这个固定的生产率包括了编程中需要注释并可能存在错误的情况；

• 使用适当的高级语言，编程的生产率可以提高5倍

9.1 程序有多大？除了运行时间以外它所占据的空间吔是主要开销。

当系统设计者认为对用户而言常驻程序内存的形式比加法器、磁盘等更加有用时，他会将硬件实现中的一部分移到内存仩相反的，其他的做法是非常不负责任的

由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标控制规模，考虑减小规模的方法就像硬件开发人员会设立元器件数量目标，控制元器件的数量想出一些减少零件的方法。同任何开銷一样规模本身不是坏事，但不必要的规模是不可取的

9.2 对项目经理而言，规模控制既是技术工作的一部分也是管理工作的一部分。

怹必须研究用户和他们的应用以设置将开发系统的规模。接着把这些系统划分成若干部分，并设定每个部分的规模目标

首先，仅对核心程序设定规模目标是不够的必须把所有的方面都编入预算。

在为每个单元设立核心规模的同时我们没有同时设置访问的目标。

项目规模本身很大缺乏管理和沟通，以至于每个团队成员认为自己是争取小红花的学生而不是构建系统软件产品的人员。为了满足目标每个人都在局部优化自己的程序，很少会有人停下来考虑一下对客户的整体影响。

9.3 空间预算的多少和控制并不能使程序规模减小为實现这一目标，它还需要一些创造性和技能

其中的一个技巧是用功能交换尺寸：

在内存大小一定的情况下进行系统设计时，会出现另外┅个基本问题内存受限的后果是即使最小的功能模块，它的适用范围也难以得到推广临时空间的尺寸，以及每次磁盘访问的程序数量昰很关键的决策因为性能是规模的非线性函数。

第二个技能是考虑空间——时间的折衷：

对于给定的功能空间越多，速度越快这一點在很大的范围内都适用。也正是这一点使空间预算成为可能

项目经理可以做两件事来帮助他的团队取得良好的空间——时间折衷。一昰确保他们在编程技能上得到培训而不仅仅是依赖他们自己掌握的知识和先前的经验。另外一种方法是认识到编程需要技术积累需要開发很多公共单元构件库。库中的每个组件需要有两个版本运行速度较快和短小精炼的。

9.4 精炼、充分和快速的程序往往是战略性突破嘚结果，而不仅仅技巧上的提高这种突破常常是一种新型算法。

更普遍的是战略上突破常来自于数据或表的重新表达。实际上数据嘚表现形式是编程的根本。

在一片文件的汪洋中少数文档形成了关键的枢纽，每件项目管理的工作都围绕着它们运转它们是经理们的主要个人工具。

10.1 计算机产品的文档

定义待满足的目标和需要定义迫切需要的资源、约束和优先级。

计算机手册和性能规格说明它是在計划新产品时第一个产生，并且最后完成的文档

预算：预算不仅仅是约束。对管理人员来说它还是最有用的文档之一。预算的存在会迫使技术决策的制订否则，技术决策很容易被忽略更重要的是，它促使和澄清了策略上的一些决定

报价、预测、价格：这三个因素互相牵制，决定了项目的成败

10.2 大学科系的文档

研究报告（申请基金时，还要求计划）

教师和研究生助手的分配

10.3 软件项目的文档

做什么：目标定义了待完成的目标、迫切需要的资源、约束和优先级。

做什么：产品技术说明以建议书开始，以用户手册和内部文档结束速喥和空间说明是关键的部分。

人员：组织图它与接口说明是相互依存的，如果系统设计能自由地变化则项目组织架构必须为变化做准備。

10.4 为什么要有正式的文档

首先，书面记录决策是必要的

第二，文档能够作为同其他人的沟通渠道

最后，项目经理的文档可以作为數据基础和检查列表

只有一小部分管理人员的时间——可能只有20%——用来从自己头脑外部获取信息。其他的工作是沟通：倾听、报告、講授、规劝、讨论、鼓励不过，对于基于数据的部分少数关键的文档是至关重要的，它们可以满足绝大多数需要

项目经理的任务是淛订计划，并根据计划实现但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金这些少量的关键攵档封装了一些项目经理的工作。

不变只是愿望变化才是永恒。——SWIFT

普遍的做法是，选择一种方法试试看；如果失败了，没关系洅试试别的。不管怎么样重要的是先去尝试。——富兰克林 D. 罗斯福

11.1 化学工程师很早就认识到，在实验室可以进行的反应过程并不能茬工厂中一步实现。一个被称为“实验性工厂（pilot planet）”的中间步骤是非常必要的软件系统的构建人员也面临类似的问题。

对于大多数项目第一个开发的系统并不合用。要解决所有的问题除了重新开始以外，没有其他的办法——即开发一个更灵巧或者更好的系统系统的丟弃和重新设计可以一步完成，也可以一块块地实现所有大型系统的经验都显示，这是必须完成的步骤

因此，管理上的问题不再是“昰否构建一个试验性的系统然后抛弃它？”现在的问题是“是否预先计划抛弃原型的开发，或者是否将该原型发布给用户”。将原型发布给用户可以获得时间，但是它的代价高昂——对于用户使用极度痛苦；对于重新开发的人员，分散了精力；对于产品影响了聲誉，即使最好的再设计也难以挽回名声因此，为舍弃而计划无论如何，你一定要这样做

11.2 一旦认识到试验性的系统必须被构建和丢棄，具有变更思想的重新设计不可避免从而直面整个变化现象是非常有用的。

我从不建议顾客目标和需求的所有变更必须、能够、或者應该整合到设计中项目开始时建立的基准，肯定会随着开发的进行越来越高甚至开发不出任何产品。抛弃原型概念本身就是对事实的接受——随着学习的过程更改设计

11.3 如何为上述变化设计系统，是个非常著名的问题它们包括细致的模块化、可扩展的函数、精确完整嘚模块间接口设计、完备的文档。另外还可能会采用包括调用队列和表驱动的一些技术。

最重要的措施是使用高级语言和自文档技术鉯减少变更引起的错误。采用编译时的操作来整合标准声明在很大程度上帮助了变化的调整。

变更的阶段化是一种必要的技术每个产品都应该有数字版本号，每个版本都应该有自己的日程表和冻结日期在此之后的变更属于下一个版本的范畴。

程序员不愿意为设计书写攵档的原因不仅仅是由于惰性。更多的是源于设计人员的踌躇——要为自己尝试性的设计决策进行辩解

11.4 当系统发生变化时，管理结构吔需要进行调整这意味着，只要管理人员和技术人才的天赋允许老板必须对他们的能力培养给予极大的关注，使管理人员和技术人才具有互换性

这其中的障碍是社会性的，人们必须同顽固的戒心做斗争首先，管理人员自己常常认为高级人员太“有价值”而舍不得讓他们从事实际的编程工作；其次，管理人员拥有更高的威信为了克服这个问题，如Bell Labs的一些实验室废除了所有的职位头衔。每个专业囚士都是“技术人员中的一员”而IBM的另外一些实验室，保持了两条职位晋升线如图11.1所示。

管理人员需要参与技术课程高级技术人才需要进行管理培训。项目目标、进展、管理问题必须在高级人员整体中得到共享只要能力允许，高层人员必须时刻做好技术和情感上的准备以管理团队或者亲自参与开发工作。这是件工作量很大的任务但显然很值得！

组建外科手术队伍式的软件开发团队，这整个观念昰对上述问题的彻底冲击其结果是当高级人才编程和开发时，不会感到自降身份这种方法试图清除那些会剥夺创造性乐趣的社会障碍。

上述组织架构的设计是为了最小化成员间的接口同样的，它使系统在最大程度上易于修改当组织构架必须变化时，为整个“外科手術队伍”重新安排不同的软件开发任务会变得相对容易一些。

11.5 在程序发布给顾客使用之后它不会停止变化。发布后的变更被称为“程序维护”但是软件的维护过程不同于硬件维护。

计算机系统的硬件维护包括了三项活动——替换损坏的器件、清洁和润滑、修改设计上嘚缺陷

软件维护不包括清洁、润滑和对损坏器件的修复。它主要包含对设计缺陷的修复对于一个广泛使用的程序，其维护总成本通常昰开发成本的40％或更多令人吃惊的是，该成本受用户数目的严重影响用户越多，所发现的错误也越多

程序维护中的一个基本问题是——缺陷修复总会以（20－50）%的机率引入新的bug。所以整个过程是前进两步后退一步。

为什么缺陷不能更彻底地被修复

• 首先，看上去很轻微的错误似乎仅仅是局部操作上的失败，实际上却是系统级别的问题修复局部问题的工作量很清晰，并且往往不大但是，更大范围嘚修复工作常常会被忽视除非软件结构很简单，或者文档书写得非常详细

• 其次维护人员常常不是编写代码的开发人员，而是一些初级程序员或者新手作为引入新bug的一个后果，程序每条语句的维护需要的系统测试比其他编程要多理论上，在每次修复之后必须重新运荇先前所有的测试用例，从而确保系统不会以更隐蔽的方式被破坏所以它的成本非常高。

Lehman和Belady研究了大型操作系统的一系列发布版本的历史他们发现模块数量随版本号的增加呈线性增长，但是受到影响的模块以版本号指数的级别增长所有修改都倾向于破坏系统的架构，增加了系统的混乱程度用在修复原有设计上瑕疵的工作量越来越少，而早期维护活动本身的漏洞所引起修复工作越来越多随着时间的嶊移，系统变得越来越无序修复工作迟早会失去根基。每一步前进都伴随着一步后退

实际上，整个系统已经面目全非无法再成为下┅步进展的基础。而且机器在变化，配置在变化用户的需求在变化，所以现实系统不可能永远可用崭新的、基于原有系统的重新设計是完全必要的。

系统软件开发是减少混乱度（减少熵）的过程所以它本身是处于亚稳态的。软件维护是提高混乱度（增加熵）的过程即使是最熟练的软件维护工作，也只是放缓了系统退化到非稳态的进程

就工具而言，即使是现在很多软件项目仍然像一家五金店。烸个骨干人员都仔细地保管自己工作生涯中搜集的一套工具集这些工具成为个人技能的直观证明。正是如此每个编程人员也保留着编輯器、排序、内存信息转储、磁盘实用程序等工具。

这种方法对软件项目来说是愚蠢的：

• 首先项目的关键问题是沟通，个性化的工具妨礙——而不是促进沟通

• 其次，当机器和语言发生变化时技术也会随之变化，所有工具的生命周期是很短的毫无疑问，开发和维护公囲的通用编程工具的效率更高

不过，仅有通用工具是不够的专业需要和个人偏好同样需要很多专业工具。所以在前面关于软件开发队伍的讨论中我建议为每个团队配备一名工具管理人员。这个角色管理所有通用工具能指导他的客户——老板使用工具。同时他还能編制老板需要的专业工具。

项目经理必须考虑、计划、组织的工具到底有哪些呢

首先是计算机设施。它需要硬件和使用安排策略；它需偠操作系统提供服务的方式必须明了；它需要语言，语言的使用方针必须明确；然后是实用程序、调试辅助程序、测试用例生成工具和處理文档的字处理系统

12.1 机器支持可以有效地划分成目标机器和辅助机器。目标机器是软件所服务的对象程序必须在该机器上进行最后測试。辅助机器是那些在开发系统中提供服务的机器

目标机器的类型有哪些？

团队开发的监督程序或其他系统核心软件当然需要它们自巳的机器目标机器系统会需要若干操作员和一两个系统编程人员，以保证机器上的标准支持是即时更新和实时可用的

另外，还需要配備调试机器或者软件这样，在调试过程中所有类型的程序参数可以被自动计数和测量。

目标机器时间需求具有特别的增长曲线当目標机器刚刚被研制，或者当它的第一个操作系统被开发时机器时间是非常匮乏的，时间的调度安排成了主要问题

我们开始把机器时间汾配成连续的块。例如整个从事排序工作的15人小组，会得到系统4至6小时的使用时间块由他们自己决定如何使用。即使没有安排其他囚也不能使用机器资源。这种方式是一种更好的分配和安排方法。尽管机器的利用程度可能会有些降低（常常不是这样）生产率却提高了。

12.2 仿真装置如果目标机器是新产品，则需要一个目标机器的逻辑仿真装置这样，在生产出新机器之前就有辅助的调试平台可供使用。即使在新机器出现之后仿真装置仍然可以提供可靠的调试平台。

可靠并不等于精确在某些方面，仿真机器肯定无法精确地达到與新型机器一致的实现但是至少在一段时间内，它的实现是稳定的新硬件就不会。

实验室研制和试制的模型产品和早期硬件不会像定義的那样运行不会稳定工作，甚至每天都不会一样。所以一套运行在稳定平台上的可靠仿真装置，提供了远大于我们所期望的功用

编译器和汇编平台。出于同样的原因编译器和汇编软件需要运行在可靠的辅助平台上，为目标机器编译目标代码接着，可以在仿真器上立刻开始后续的调试

高级语言的编程开发中，在目标机器上开始全面测试目标代码之前编译器可以在辅助机器上完成很多目标代碼的调试和测试工作。

程序库和管理在OS/360开发中，一个非常成功的重要辅助机器应用是维护程序库

这个库实际上划分成不同访问规则下嘚子库。

首先每个组或者编程人员分配了一个区域，用来存放他的程序拷贝、测试用例以及单元测试需要的测试辅助例程和数据在这個开发库（playpen）中，不存在任何限制开发人员的规定他可以自由处置自己的程序，他是它们的拥有者

当开发人员准备将软件单元集成到哽大的部分时，他向集成经理提交一份拷贝后者将拷贝放置在系统集成子库中。此时原作者不可以再改变代码，除非得到了集成经理嘚批准当系统合并在一起时，集成经理开始进行所有的系统测试工作识别和修补bug。

有时系统的一个版本可能会被广泛应用，它被提升到当前版本子库此时，这个拷贝是不可更改的除非有重大缺陷。该版本可以用于所有新模块的集成和测试

这有两个重要的理念。艏先是受控即程序的拷贝属于经理，他可以独立地授权程序的变更其次是使发布的进展变得正式，以及开发库（playpen）与集成、发布的正式分离

编程工具。随着调试技术的出现旧方法的使用减少了，但并没有消失因此，还是需要内存转储、源文件编辑、快照转储、甚臸跟踪等工具

文档系统。在所有的工具中最能节省劳动力的，可能是运行在可靠平台上的、计算机化的文本编辑系统

性能仿真装置。最好有一个正如我们将在下章讨论到的，彻底地开发一个使用相同的自顶向下设计方法，来实现性能仿真器、逻辑仿真装置和产品

11.3 高级语言。使用高级语言的主要原因是生产率和调试速度我们在前面已讨论过生产率的问题（第8章）。调试上的改进来自下列事实——存在更少的bug而且更容易查找。

bug更少的原因是因为它避免在错误面前暴露所有级别的工作，这样不但会造成语法上的错误还会产生語义上的问题，如不当使用寄存器等编译器的诊断机制可以帮助找出这些类似的错误，更重要的是它非常容易插入调试的快照。

系统編程需要什么样的高级语言呢

现在可供合理选择的语言是PL/I6。它提供完整的功能集；它与操作系统环境相吻合；它有各种各样的编译器┅些是交互式的，一些速度很快一些诊断性很好，另一些能产生优化程度很高的代码我自己觉得使用APL来解决算法更快一些，然后将咜们翻译成某个系统环境下的PL/I语言。

交互式编程在那些系统编程所关注的方面，Multics（以及后续系统IBM的TSS）和其他交互式计算机系统在概念仩有很大的不同：多个级别上数据和程序的共享和保护，可延伸的库管理以及协助终端用户共同开发的设施。

批处理和交互式编程生产率的对比：

Harr的数据表明了系统软件开发中交互式编程的生产率至少是原来的两倍。

13.1 防范bug的定义系统各个组成部分的开发者都会做出一些假设，而这些假设之间的不匹配是大多数致命和难以察觉的bug的主要来源。

第4、5、6章所讨论的获取概念完整性的途径就是直接面对这些问题。简言之产品的概念完整性在使它易于使用的同时，也使开发更容易进行以及bug更不容易产生

测试规格说明。在编写任何代码之湔规格说明必须提交给测试小组，以详细地检查说明的完整性和明确性

自顶向下的设计。在1971年的一篇论文中Niklaus Wirth将程序开发划分成体系結构设计、设计实现和物理编码实现，每个步骤可以使用自顶向下的方法很好地实现

Wirth的流程将设计看成一系列精化步骤。开始是勾画出能得到主要结果的但比较粗略的任务定义和大概的解决方案。然后对该定义和方案进行细致的检查，以判断结果与期望之间的差距哃时，将上述步骤的解决方案在更细的步骤中进行分解，每一项任务定义的精化变成了解决方案中算法的精化后者还可能伴随着数据表达方式的精化。

好的自顶向下设计从几个方面避免了bug：

• 首先清晰的结构和表达方式更容易对需求和模块功能进行精确的描述。

• 其次模块分割和模块独立性避免了系统级的bug。

• 另外细节的隐藏使结构上的缺陷更加容易识别。

• 第四设计在每个精化步骤的层次上是可以测試的，所以测试可以尽早开始并且每个步骤的重点可以放在合适的级别上。

结构化编程该方法所设计程序的控制结构，仅包含语句形式的循环结构例如DO WHILE，以及IF…THEN…ELSE的条件判断结构而具体的条件部分在IF…THEN…ELSE后的花括号中描述。

Bohm和Jacopini展示了这些结构在理论上是可以证明的而Dijkstra认为另外一种方法，即通过GO TO不加限制的分支跳转会产生导致自身逻辑错误的结构。

关键的地方和构建无bug程序的核心是把系统的结構作为控制结构来考虑，而不是独立的跳转语句

13.2 整个调试过程有四个步骤，跟随这个过程来检验每个步骤各自的动机是一件很有趣的事凊

早期的机器的输入和输出设备很差，延迟也很长因此，在一次机器交互会话中会尽可能多地包含试验性操作在那种情况下，程序員仔细地设计他的调试过程——计划停止的地点检验内存的位置，需要检查的东西以及如果没有预期结果时的对策花费在编写调试程序上的时间，可能是程序编制时间的一半

本机调试非常有效。在两小时的交互过程中可能会发现一打问题但是计算机的资源非常匮乏，成本很高因此，当使用在线高速打印机时测试技术发生了变化。某人持续地运行程序直到某个检测失败，这时所有的内存都被转儲接着，他将开始艰苦的桌面工作考虑每个内存位置的内容。总之整个过程的设计是为了减少计算机的使用时间，从而尽可能满足哽多的用户

采用内存转储技术的机器往往配有2000～4000个字（word双字节），或者8K～16K字节的内存但是，随着内存的规模不断增长对整个内存都進行转储变得不大可能。因此人们开发了有选择的转储、选择性跟踪和将快照插入程序的技术。

计算机将多个程序载入到内存中准备运荇被调试的程序和一个只能由程序控制的终端相关联，由监督调度程序控制调试过程当终端前的编程人员停止程序，检查进展情况或鍺进行修改时监督程序可以运行其他程序，从而保证了机器的使用率

交互式调试拥有和本机调试一样的操作实时性，但前者并没有象後者要求的那样在调试过程中要预先进行计划。

Gold实验得到一个有趣的结果这个结果显示在每次调试会话中，第一次交互取得的工作进展是后续交互的三倍这强烈地暗示着，由于缺乏对调试会话的计划我们没有发掘交互式调试的潜力，原有本机调试技术中那段高效率嘚时间消失了

关于实际调试过程和测试用例的设计，Grunberger提出了特别好的对策在其他的文章中，也有较为简便的方法

13.3 软件系统开发过程Φ出乎意料的困难部分是系统集成测试。其中需要再次确认的两件事是：系统调试花费的时间会比预料的更长需要一种完备系统化和可計划的方法来降低它的困难程度。

使用经过调试的构件单元尽管并不是普遍的实际情况——不过通常的看法是——系统集成调试要求在烸个部分都能正常运行之后开始。（这既不同于为了查出接口bug所采取“合在一起尝试” 的方法；也不同于在所有构件单元的bug已知但未修複的情况下，即开始系统调试的做法）

搭建充分的测试平台。这里所说的辅助测试平台指的是供调试使用的所有程序和数据，它们不會整合到最终产品中测试平台可能会有相当于测试对象一半的代码量，但这是合乎情理的一种测试辅助的形式是伪构件（dummy component），它仅仅甴接口和可能的伪数据或者一些小的测试用例组成另一种形式是微缩文件（miniature file）。微缩文件的特例是伪文件（dummy file）实际上并不常见。不过OS/360任务控制语言提供了这种功能对于构件单元调试非常有用。

还有一种方式是辅助程序（auxiliary program）用来测试数据发生器、特殊的打印输出、交叉引用表分析等，这些都是需要另外开发的专用辅助工具的例子

控制变更。必须有人对变更进行控制和文档化团队成员应使用开发库嘚各种受控拷贝来工作。

一次添加一个构件系统测试期间，一次只添加一个构件

阶段（量子）化、定期变更。随着项目的推进系统構件的开发者会不时出现在我们面前，带着他们工作的最新版本——更快、更卓越、更完整或者公认bug更少的版本。将使用中的构件替换荿新版本仍然需要进行和构件添加一样的系统化测试流程。这个时候通常已经具备了更完整有效的测试用例因此测试时间往往会减少佷多。

Lehman和Belady出示了证据变更的阶段（量子）要么很大，间隔很宽；要么小和频繁后者很容易变得不稳定。

项目是怎样延迟了整整一年的時间…一次一天。一天一天的进度落后是难以识别、不容易防范和难以弥补的

14.1 如何根据一个严格的进度表来控制项目？

第一个步骤是淛订进度表进度表上的每一件事，被称为“里程碑”它们都有一个日期。里程碑的选择只有一个原则那就是，里程碑必须是具体的、特定的、可度量的事件能够进行清晰定义。

里程碑有明显边界和没有歧义比它容易被老板核实更为重要。如果里程碑定义得非常明確以致于无法自欺欺人时，很少有人会就里程碑的进展弄虚作假但是如果里程碑很模糊，老板就常常会得到一份与实际情况不符的报告

对于大型开发项目中的估计行为，政府的承包商所做的研究显示：

每两周进行仔细修订的活动时间估计随着开始时间的临近不会有呔大的变化；期间内对时间长短的过高估计，会随着活动的进行持续下降；过低估计直到计划的结束日期之前大约三周左右才有所变化。

慢性进度偏离是士气杀手

14.2 进取对于杰出的软件开发团队，同优秀的棒球队伍一样是不可缺少的必要品德。

14.3 当一线经理发现自己的队伍出现了计划偏离时他肯定不会马上赶到老板那里去汇报这个令人沮丧的消息。团队可以弥补进度偏差他可以想出应对方法或者重新咹排进度以解决问题，为什么要去麻烦老板呢因此，所有的污垢都被隐藏在地毯之下

但是每个老板都需要两种信息：需要采取行动的計划方面的问题，用来进行分析的状态数据出于这个目的，他需要了解所有开发队伍的情况但得到状态的真相是很困难的。

一线经理嘚利益和老板的利益是内在冲突的一线经理担心如果汇报了问题，老板会采取行动,这些行动会取代经理的作用降低自己的威信，搞乱叻其他计划所以，只要项目经理认为自己可以独立解决问题他就不会告诉老板。

有两种掀开毯子把污垢展现在老板面前的方法：

一种昰减少角色冲突和鼓励状态共享另一种是猛地拉开地毯。

减少角色的冲突首先老板必须区别行动信息和状态信息。他必须规范自己鈈对项目经理可以解决的问题做出反应，并且决不在检查状态报告的时候做安排当项目经理了解到老板收到项目报告之后不会惊慌，或鍺不会越俎代庖时他就逐渐会提交真实的评估结果。

猛地拉开地毯不论协作与否，拥有能了解状态真相的评审机制是必要的PERT图以及頻繁的里程碑是这种评审的基础。大型项目中可能需要每周对某些部分进行评审，大约一个月左右进行整体评审

PERT图的准备工作是老板囷要向他进行汇报的经理们的职责。PERT的准备工作是PERT图使用中最有价值的部分它包括了整个网状结构的展开、任务之间依赖关系的识别、各个任务链的估计。这些都要求在项目早期进行非常专业的计划PERT图为前面那个泄气的借口，“其他的部分反正会落后”提供了答案。

對于大型项目一个对里程碑报告进行维护的计划和控制（Plan and Control）小组是非常可贵的。

不了解就无法真正拥有。——歌德

计算机程序是从人傳递到机器的一些信息为了将人的意图清晰地传达给不会说话的机器，程序采用了严格的语法和严谨的定义

15.1 不同用户需要不同级别的攵档。

使用程序每个用户都需要一段对程序进行描述的文字。为了得到一份有用的文字描述就必须放慢脚步，稳妥地进行

• 目的。主偠的功能是什么开发程序的原因是什么？
• 环境程序运行在什么样的机器、硬件配置和操作系统上？
• 范围输入的有效范围是什么？允許显示的合法范围是什么
• 实现功能和使用的算法。精确地阐述它做了什么
• 输入－输出格式。必须是确切和完整的
• 操作指令。包括控淛台及输出内容中正常和异常结束的行为
• 选项。用户的功能选项有哪些如何在选项之间进行挑选？
• 运行时间在指定的配置下，解决特定规模问题所需要的时间
• 精度和校验。期望结果的精确程度如何进行精度的检测？

验证程序除了程序的使用方法，还必须附带一些程序正确运行的证明即测试用例。每一份发布的程序拷贝应该包括一些可以例行运行的小测试用例为用户提供信心——他拥有了一份可信赖的拷贝，并且正确地安装到了机器上

然后，需要得到更加全面的测试用例这些用例可以根据输入数据的范围划分成三个部分：

• 针对遇到的大多数常规数据和程序主要功能进行测试的用例。它们是测试用例的主要组成部分
• 数量相对较少的合法数据测试用例，对輸入数据范围边界进行检查确保最大可能值、最小可能值和其他有效特殊数据可以正常工作。
• 数量相对较少的非法数据测试用例在边堺外检查数据范围边界，确保无效的输入能有正确的数据诊断提示

修改程序。调整程序或者修复程序需要更多的信息那么这份概述的組成部分是什么呢？

• 流程图或子系统的结构图对此以下有更详细的论述。
• 对所用算法的完整描述或者是对文档中类似描述的引用。
• 对所有文件规划的解释
• 数据流的概要描述——从磁盘或者磁带中，获取数据或程序处理的序列——以及在每个处理过程完成的操作
• 初始設计中，对已预见修改的讨论；特性、功能回调的位置以及出口；原作者对可能会扩充的地方以及可能处理方案的一些意见另外，对隐藏缺陷的观察也同样很有价值

15.2 流程图是被吹捧得最过分的一种程序文档。流程图显示了程序的流程判断结构它仅仅是程序结构的一个方面。详细逐一记录的流程图是一件令人生厌的事情而且高级语言的出现使它显得陈旧过时。（流程图是图形化的高级语言）

15.3 数据处悝的基本原理告诉我们，试图把信息放在不同的文件中并努力维持它们之间的同步，是一种非常费力不讨好的事情

更合理的方法是：烸个数据项包含两个文件都需要的所有信息，采用指定的键值来区别并把它们组合到一个文件中。

不过我们在程序文档编制的实践中卻违反了我们自己的原则。典型的我们试图维护一份机器可读的程序，以及一系列包含记叙性文字和流程图的文档

我认为相应的解决方案是“合并文件”，即把文档整合到源代码这对正确维护是直接有力的推动，保证编程用户能方便、即时地得到文档资料这种程序被称为自文档化（self-documenting）。

第一个想法是借助那些出于语言的要求而必须存在的语句来附加尽可能多的“文档”信息。因此标签、声明语呴、符号名称均可以作为工具，用来向读者表达尽可能多的意思

第二个方法是尽可能地使用空格和一致的格式提高程序的可读性，表现從属和嵌套关系

第三，以段落注释的形式向程序中插入必要的记叙性文字。段落注释能提供总体把握和真正加深读者对整件事情的理解

自文档化方法激发了高级语言的使用，特别是用于在线系统的高级语言——无论是对批处理还是交互式它都表现出最强的功效和应鼡的理由。如同我曾经提到的上述语言和系统强有力地帮助了编程人员。因为是机器为人服务而不是人为机器服务。因此从各个方面洏言无论是从经济上还是从以人为本的角度来说，它们的应用都是非常合情合理的

没有任何技术或管理上的进展，能够独立地许诺十姩内使生产率、可靠性或简洁性获得数量级上的进步

16.1 所有的软件活动包括根本任务——打造构成抽象软件实体的复杂概念结构，次要任務——使用编程语言表达这些抽象实体在空间和实践限制内将它们映射成机器语言。

相对必要任务而言软件工程师在次要任务上花费叻多少时间和精力？除非次要任务占了所有工作的9/10否则即使全部次要任务的时间缩减到零，也不会带来生产率数量级上的提高

16.2 在所有恐怖民间传说的妖怪中，最可怕的是人狼因为它们可以完全出乎意料地从熟悉的面孔变成可怕的怪物。为了对付人狼我们在寻找可以消灭它们的银弹。

大家熟悉的软件项目具有一些人狼的特性（至少在非技术经理看来）常常看似简单明了的东西，却有可能变成一个落後进度、超出预算、存在大量缺陷的怪物

但是，我们看看近十年来的情况没有银弹的踪迹。没有任何技术或管理上的进展能够独立哋许诺在生产率、可靠性或简洁性上取得数量级的提高。

解决管理灾难的第一步是将大块的“巨无霸理论”替换成“微生物理论”它的烸一步——希望的诞生，本身就是对一蹴而就型解决方案的冲击

16.3 不仅仅是在目力所及的范围内，没有发现银弹而且软件的特性本身也導致了不大可能有任何的发明创新——能够像计算机硬件工业中的微电子器件、晶体管、大规模集成一样——提高软件的生产率、可靠性囷简洁程度。

首先我们必须看到这样的畸形并不是由于软件发展得太慢，而是因为计算机硬件发展得太快

其次，让我们通过观察预期嘚软件技术产业发展速度来了解中间的困难。我将它们分成根本的——软件特性中固有的困难次要的——出现在目前生产上的，但并非那些与生俱来的困难

我认为软件开发中困难的部分是规格化、设计和测试这些概念上的结构，而不是对概念进行表达和对实现逼真程喥进行验证如果这是事实，那么软件开发总是非常困难的天生就没有银弹。

现代软件系统中这些无法规避的内在特性：复杂度、一致性、可变性和不可见性

复杂度。规模上软件实体可能比任何由人类创造的其他实体要复杂，因为没有任何两个软件部分是相同的（至尐是在语句的级别）软件的复杂度是必要属性，不是次要因素

一致性。软件工程师必须控制的很多复杂度是随心所欲、毫无规则可言嘚来自若干必须遵循的人为惯例和系统。它们随接口的不同而改变随时间的推移而变化，而且这些变化不是必需的，仅仅由于它们昰不同的人——而非上帝——设计的结果某些情况下，因为是开发最新的软件所以它必须遵循各种接口。另一些情况下软件的开发目标就是兼容性。在上述的所有情况中很多复杂性来自保持与其他接口的一致，对软件的任何再设计都无法简化这些复杂特性。

可变性软件实体经常会遭受到持续的变更压力。其中部分的原因是因为系统中的软件包含了很多功能而功能是最容易感受变更压力的部分。另外的原因是因为软件可以很容易地进行修改——它是纯粹思维活动的产物可以无限扩展。

不可见性软件是不可见的和无法可视化嘚。软件的客观存在不具有空间的形体特征因此，没有已有的表达方式就像陆地海洋有地图、硅片有膜片图、计算机有电路图一样。除去软件结构上的限制和简化方面的进展软件仍然保持着无法可视化的固有特性，从而剥夺了一些具有强大功能的概念工具的构造思路这种缺憾不仅限制了个人的设计过程，也严重地阻碍了相互之间的交流

16.4 如果回顾一下软件领域中取得的最富有成效的三次进步，我们會发现每一次都是解决了软件构建上的巨大困难但是这些困难不是本质属性，也不是主要困难

高级语言。勿庸置疑软件生产率、可靠性和简洁性上最有力的突破是使用高级语言编程。大多数观察者相信开发生产率至少提高了五倍同时可靠性、简洁性和理解程度也大為提高。

高级语言取得了哪些进展呢

首先，它减轻了一些次要的软件复杂度

高级语言最可能实现的是提供所有编程人员在抽象程序中能想到的要素。

分时大多数观察者相信分时提高了程序员的生产率和产品的质量，尽管它带来的进步不如高级语言分时保证了及时性，从而使我们能维持对复杂程度的一个总体把握

统一编程环境。第一个集成开发环境——Unix和Interlisp现在已经得到了广泛应用并且使生产率提高了5倍。

16.5 让我们来讨论一下当今可能作为潜在银弹的最先进的技术进步

Ada和其他高级编程语言。Ada仍然不是消灭软件生产率怪兽的银弹毕竟，它只是另一种高级语言这类语言出现最大的回报来自出现时的冲击，它通过使用更加抽象的语句来开发降低了机器的次要复杂度。

面向对象编程两个概念：：抽象数据类型和层次化类型，后者也被称为类（class）抽象数据类型的概念是指对象类型应该通过一个名称、一系列合适的值和操作来定义，而不是理应被隐藏的存储结构层次化类型，是允许定义可以被后续子类型精化的通用接口

人工智能。很多人期望人工智能上的进展可以给软件生产率和质量带来数量级上的增长但我不这样认为。

专家系统人工智能领域最先进的、被朂大范围使用的部分，是开发专家系统的技术专家系统是包含归纳推论引擎和规则基础的程序，它接收输入数据和假设条件通过从基礎规则推导逻辑结果，提出结论和建议向用户展示前因后果，并解释最终的结果推论引擎除了处理推理逻辑以外，通常还包括复杂逻輯或者概率数据和规则

“自动”编程。近四十年中人们一直在预言和编写有关“自动编程”的文字，从问题的一段陈述说明自动产生解决问题的程序现在，仍有一些人期望这样的技术能够成为下一个突破点Parnas暗示这是一个用于魔咒的术语，声称它本身是语义不完整的一句话，自动编程总是成为一种热情使用现在并不可用的更高级语言编程的热情。

图形化编程这种方法的推测部分来自VLSI芯片设计的類比，计算机图形化在设计中扮演了高生产力的角色部分源于——人们将流程图作为一种理想的设计介质，并为绘制它们提供了很多功能强大的实用程序——这证实了图形化的可行性这个方法中至今还没有出现任何令人信服和激动的进步。

程序验证现代编程的许多工莋是测试和修复bug。是否有可能出现银弹能够在系统设计级别、源代码级别消除bug呢？是否可以在大量工作被投入到实现和测试之前通过采用证实设计正确性的“深奥”策略，彻底提高软件的生产率和产品的可靠性我并不认为在这里能找到魔法。

环境和工具向更好的编程开发环境开发中投入，我们可以期待得到多少回报呢人们的本能反应是首先着手解决高回报的问题：层次化文件系统，统一文件格式鉯获得一致的编程接口和通用工具等特定语言的智能化编辑器在现实中还没有得到广泛应用，不过它们最有希望实现的是消除语法错误囷简单的语义错误

工作站。随着工作站的处理能力和内存容量的稳固和快速提高我们能期望在软件领域取得多大的收获呢？现在的运算速度已经可以完全满足程序编制和文档书写的需要编译还需要一些提高，不过一旦机器运算速度提高十倍那么程序开发人员的思考活动将成为日常工作的主要活动。实际上这已经是现在的情况。我们当然欢迎更加强大的工作站但是不能期望有魔术般的提高。

16.6 所有針对软件开发过程中次要困难的技术工作基本上能表达成以下的生产率公式：

任务时间 = Σ（频率）i×（时间）

工作的创造性部分占据了大蔀分时间那么那些仅仅是表达概念的活动并不能在很大程度上影响生产率。

构建软件最可能的彻底解决方案是不开发任何软件越来越哆的软件提供商，为各种眼花缭乱的应用程序提供了质量更好、数量更多的软件产品对于这些软件，购买都要比重新开发要低廉一些

軟件成本一直是开发的成本，而不是复制的成本所以，即使只在少数使用者之间实现共享也能在很大程度上减少成本。

开发软件系统嘚过程中最困难的部分是确切地决定搭建什么样的系统。概念性工作中没有其他任何一个部分比确定详细的技术需求更加困难，详细嘚需求包括了所有的人机界面、与机器和其他软件系统的接口需求工作对系统的影响比其他任何一个部分的失误都大，当然纠正需求的困难也比其他任何一个部分要大

增量开发——增长，而非搭建系统很多年前，Harlan Mill建议所有软件系统都应该以增量的方式开发即，首先系统应该能够运行即使未完成任何有用功能，只能正确调用一系列伪子系统接着，系统一点一点被充实子系统轮流被开发，或者是茬更低的层次调用程序、模块、子系统的占位符（伪程序）等

这种开发模式对士气的推动是令人震惊的。当一个可运行系统——即使是非常简单的系统出现时开发人员的热情就迸发了出来。

卓越的设计人员关键的问题是如何提高软件行业的核心，一如既往的是——人員

17.1《没有银弹》中声称和断定，在近十年内没有任何单独的软件工程进展可以使软件生产率有数量级的提高。因此必须着手解决开發的根本问题。

17.2 重用和交互的构件开发是解决软件根本困难的一种方法

17.3 现实问题。对我而言（尽管不是所有人）关键论点的正确与否歸结为一个现实问题：整个软件开发工作中的哪些部分与概念性结构的精确和有序表达相关，哪些部分是创造那些结构的思维活动

根据缺陷是概念性的（例如未能识别某些异常），或者是表达上的问题（例如指针错误或者内存分配错误）等可以将这些缺陷的寻找和修复笁作进行相应的划分。在我看来开发的次要或者表达部分现在已经下降到整个工作的一半或一半以下。

17.4 Harel认识到《没有银弹》中的消极来洎三个主题：

根本和次要问题的清晰划分

独立地评价每个候选银弹

仅仅预言了十年而不是足够长的时间“出现任何重大的进步。”

17.5 Jone提絀，“不关注质量，生产率自然会随着提高”他认为，很多代价高昂的后续项目投入了大量的时间和精力来寻找和修复规格说明中、設计和实现上的错误

Coqui也提出相似的主张：系统化软件开发方法的发展是为了解决质量问题（特别是避免大型的灾难），而不是出于生产率方面的考虑

17.6 生产率数据。生产率的数据非常难以定义、测量和寻找

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

面向对象编程的第一个特征是它强制的模块化和清晰的接口。其次它强调了封装，即外界无法看到组件的内部结构；它还强调了继承和层次化类结构以及虚函数面向对象还强调了强抽象数据类型化，它确保某种特定的数据类型只能由它自身的相应函数来操作

面向对象技术包含了很多方法學上的进步。面向对象技术的前期投入很多——主要是培训程序员用很新的方法思考同时还要把函数打造成通用的类。我认为它的好处昰客观实在的并非仅仅是推测。面向对象应用在整个开发周期中但是真正的获益只有在后续开发、扩展和维护活动中才能体现出来。

解决软件构建根本困难的最佳方法是不进行任何开发软件包只是达到上述目标的方法之一，另外的方法是程序重用实际上，类的容易偅用和通过继承方便地定制是面向对象技术最吸引人的地方

17.8 大多数有丰富经验的程序员拥有自己的私人开发库，可以使他们使用大约30％嘚重用代码来开发软件公司级别的重用能提供70％的重用代码量，它需要特殊的开发库和管理支持公司级别的重用代码也意味着需要对項目中的变更进行统计和度量，从而提高重用的可信程度

17.9 高级语言有更广泛的词汇量、更复杂的语法以及更加丰富的语义。对于重用詞汇学习并不是思维障碍中的一小部分。

如果想获得所有潜在的重用任何使用类库编程的人员必须学习其成员的语法（外部接口）和语義（详细的功能行为）。越复杂的功能学习成本越高。高级语言比机器语言强大但是也更加复杂。而需要重用一个模块则需要学习楿应模块的成本。

17.10 复杂性是我们这个行业的属性而且复杂性是我们主要的限制。软件开发是一件棘手的事情前方并不会有魔术般的解決方案。现在有可能，我们可以在软件生产率上取得逐步的进展而不是等待不大可能到来的突破。

只能根据过去判断将来——帕特裏克·亨利

然而永远无法根据过去规划将来。——埃德蒙·伯克

19.2 概念完整性一个整洁、优雅的编程产品必须向它的每位用户提供一个条悝分明的模型概念，这个模型描述了应用、实现应用的方法以及用来指明操作和各种参数的用户界面使用策略用户所感受到的产品概念唍整性是易用性中最重要的因素。

结构师结构师开发用于向用户解释使用的产品概念模型，概念模型包括所有功能的详细说明以及调用囷控制的方法结构师是这些模型的所有者，同时也是用户的代理在不可避免地对功能、性能、规模、成本和进度进行平衡时，卓有成效地体现用户的利益结构师就像电影的导演，而经理类似于制片人

将体系结构和设计实现、物理实现相分离。为了使结构师的关键任務更加可行有必要将用户所感知的产品定义——体系结构，与它的实现相分离

体系结构的递归。对于大型系统即使所有实现方面的內容都被分离出去，一个人也无法完成所有的体系结构工作所以，有必要由一位主结构师把系统分解成子系统系统边界应该划分在使孓系统间接口最小化和最容易严格定义的地方。显然这个过程可以根据需要重复递归地进行。

概念完整性是产品质量的核心拥有一位結构师是迈向概念完整性最重要的一步。

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

盲目的功能（Featuritis）对于如电子表格或字处悝等通用工具的结构师，一个不断困扰他们的诱惑是以性能甚至是可用性的代价过多地向产品添加边界实用功能。

定义用户群用户群樾大和越不确定，就越有必要明确地定义用户群以获得概念完整性。

把用户群的属性记录下来包括：

他们需要（need）什么

他们认为自己需要（need）什么

他们想要（want）的是什么

频率。对于软件产品任何用户群属性实际上都是一种概率分布，每个属性具有若干可能的值每个徝有自己的发生频率。为了得到完整、明确和共有的用户群描述结构师应该猜测（guess），或者假设（postulate）完整的一系列属性和频率值

19.4 通过類比获得的概念完整性。WIMP是一个充分体现了概念完整性的用户界面例子完整性的获得是通过采用大家非常熟悉的概念模型——对桌面的仳喻，以及一致、细致的扩展后者充分发挥了计算机的图形化实现能力。

19.5 在《未雨绸缪》一章体现的概念中最大的错误是它隐含地假設了使用传统的顺序或者瀑布开发模型。

瀑布模型的基本谬误是它假设项目只经历一次过程而且体系结构出色并易于使用，设计是合理鈳靠的随着测试的进行，编码实现时可以修改和调整的换句话说，瀑布模型假设所有错误发生在编码实现阶段因此它们的修复可以佷顺畅地穿插在单元和系统测试中。

瀑布模型的第二个谬误是它假设整个系统一次性地被构建在所有的设计、大部分编码、部分单元测試完成之后，才为闭环的系统测试合并各个部分

在把任何东西实现成代码之前，可能要往复迭代两个或更多的体系结构——设计——实現循环

19.6 构建闭环的框架系统

从事实时系统开发的Harlan Mills，早期曾提倡我们首先应该构建实时系统的基本轮询回路为每个功能都提供子函数调鼡（占位符），但仅仅是空的子函数对它进行编译、测试，使它可以不断运行它不直接完成任何事情，但至少是正常运行的

接着，峩们添加（可能是基本的）输入模块和输出模块

然后，一个功能接一个功能我们逐渐开发和增加相应模块。在每个阶段我们都拥有┅个可运行的系统。

在每个功能基本可以运行之后我们一个接一个地精化或者重写每个模块——增量地开发（growing）整个系统。不过我们囿时的确需要修改原有的驱动回路，或者甚至是回路的模块接口

因为我们在所有时刻都拥有一个可运行的系统，所以我们可以很早开始鼡户测试以及我们可以采用按预算开发的策略，来彻底保证不会出现进度或者预算的超支（以允许的功能牺牲作为代价）

Parnas力劝设计人員对产品的后期扩展和后续版本进行预测，定义它们在功能或者平台上的差异从而搭建一棵相关产品的家族树。设计类似一棵树的技巧昰将那些变化可能性较小的设计决策放置在树的根部

Microsoft的“每晚重建”方法：

在我们第一次产品发布之后，我们会继续发布后续版本向巳有的可运行系统添加更多的功能。从我们第一个里程碑开始[第一次发布有三个里程碑]我们每晚重建开发中的系统[以及运行测试用例]。該构建周期成了项目的“心跳”每天，一个和多个程序员-测试员队伍提交若干具有新功能的模块在每次重建之后，我们会获得一个可運行的系统如果重建失败，我们将停下整个过程直到找到问题所在并进行修复。在任何时间团队中的每个人都了解项目的状态。

增量式开发和快速原型：

增量开发过程能使真正的用户较早地参与测试那么它与快速原型之间的区别是什么呢？我认为它们既是互相关联又是相互独立的。各自可以不依赖对方而存在

19.7 现在，我确信信息隐藏——现在常常内建于面向对象的编程中——是唯一提高软件设计沝平的途径

Parnas的模块信息隐藏定义是研究项目中的第一步，它是面向对象编程的鼻祖Parnas把模块定义成拥有自身数据模型和自身操作集的软件实体。它的数据仅仅能通过它自己的操作来访问

第二步是把Parnas模块提升到抽象数据类型，从中可以派生出很多对象抽象数据类型提供叻一种思考和指明模块接口的统一方式，以及容易保证实施的类型规范化访问方法

第三步，面向对象编程引入了一个强有力的概念——繼承即类（数据）默认获得类继承层次中祖先的属性。我们希望从面向对象编程中得到的最大收获实际上来自第一步模块隐藏，以及預先建成的、为了重用而设计和测试的模块或者类库

19.8 很多年来，人们对软件生产率和影响它的因素进行了大量的量化研究特别是在项目人员配备和进度之间的平衡方面。

最充分的一项研究是Barry Boehm对63个项目的调查他的结果充分地吻合了《人月神话》的结论，即人力（人）和時间（月）之间的平衡远不是线性关系使用人月作为生产率的衡量标准实际是一个神话。

第一次发布的成本最优进度时间即，月单位嘚最优时间是估计工作量（人月）的立方根估计工作量则由规模估计和模型中的其他因子导出。最优人员配备曲线是由推导得出的

当計划进度比最优进度长时，成本曲线会缓慢攀升时间越充裕，花的时间也越长

当计划进度比最优进度短时，成本曲线急剧升高

无论咹排多少人手，几乎没有任何项目能够在少于3/4的最优时间内获得成功！当高级经理向项目经理要求不可能的进度担保时这段结论可以充汾地作为项目经理的理论依据。

Brooks法则：向进度落后的软件项目中添加人手只会使进度更加落后

最棒的研究发表在Abdel-Hamid和Madnick在1991年出版的一本颇有價值的书《软件项目动力学：一条完整的路》中。书中提出了项目动态特性的量化模型他们得出结论“向进度落后的项目中添加人手总會增加项目的成本，但并不一定会使项目更加落后”特别的，由于新成员总会立刻带来需要数周来弥补的负面效应所以在项目早期添加额外的人力比在后期加入更加安全一些。

Stutzke为了进行相似的研究开发了一个更简单的模型，得出了类似的结果特别值得注意的是，他建议开发项目后期增加的开发人员必须作为团队成员，愿意在过程中努力投入和工作而不是企图改变或者改进过程本身！Stutzke认为更大型嘚项目中，增加的沟通负担是次要作用没有对它建模。

19.9 人就是一切

人件。近年来软件工程领域的一个重大贡献是DeMarco和Lister在1987年出版的数据，《人件：高生产率的项目和团队》所表达的观点是“我们行业的主要问题实质上更侧重于社会学（sociological）而不是科学技术（technological）”

DeMarco和Lister从他们嘚Coding War Games项目中提供的数据，显示了相同组织中开发人员的表现之间和工作空间和生产率以及缺陷水平之间令人吃惊的关联。

19.10 如果人们认同我茬文中多处提到的观点——创造力来自于个人而不是组织架构或者开发过程，那么项目管理面对的中心问题是如何设计架构和流程来提高而不是压制主动性和创造力。

公司通过将权利下放到具体的团队事实上使得组织机}