外观
04.削足适履、提纲挈领、未雨绸缪
第8章 胸有成竹
系统编程需要花费多长的时间？需要多少的工作量？如何进行估计？
① 先前，我推荐了用于计划进度、编码、构件测试和系统测试的比率。
(1) 需要指出的是，仅仅通过对编码部分的估计，然后应用上述比率，是无法得到对整个任务的估计的。
(2) 必须声明的是，构建独立小型程序的数据不适用于编程系统产品。计划、编制文档、测试、系统集成和培训的时间必须被考虑在内。
② 在将上述观点抛开之前，尽管不是为了进行严格的比较，即使在不考虑相互交流沟通，开发人员仅仅回顾自己以前工作的情况下， 这些数字仍然显示出工作量是规模的幂函数。
Part 1 Portman的数据
项目估算对每个人年的技术工作时间数量做出了不现实的假设
日志显示事实上他的团队仅用了50%的工作周，来进行实际的编程和调试，估算上的失误完全可以由该情况来解释。其余的时间包括机器的当机时间、 高优先级的无关琐碎工作、会议、文字工作、公司业务、疾病、事假等等。
Part 2 Aron的数据
大型项目（简要地说，大型意味着程序员的数目超过 25 人，将近 30,000 行的指令）
Part 3 Harr的数据
Part 4 OS/360的数据
① 控制程序组的经验而言，生产率的范围大约是 600～800（经过调试的指令）/人年。语言翻译小组所达到的生产率是2000～3000（经过调试的指令）/人年。这包括了小组的计划、代码构件测试、系统测试和一些支持性活动。
② 生产率会根据任务本身复杂度和困难程度表现出显著差异。 在复杂程度估计这片“沼泽” 上的指导原则是： 编译器的复杂度是批处理程序的三倍，操作系统复杂度是编译器的三倍
Part 5 Corbato的数据
① 高级语言系统编程，平均生产率是 1200 行经调试的 PL/I 语句（大约在 1 和 2 百万指令之间）/人年。
② 意味着两个重要的结论 ：
（1）对常用编程语句而言。生产率似乎是固定的。这个固定的生产率包括了编程中需要注释，并可能存在错误的情况。
（2）使用适当的高级语言，编程的生产率可以提高 5 倍。
作者总结
8.1 仅仅通过对编码部分的估计， 然后乘以任务其他部分的相对系数， 是无法得出对整项工作的精确估计的。
8.2 构建独立小型程序的数据不适用于编程系统项目。
8.3 程序开发呈程序规模的指数增长。
8.4 一些发表的研究报告显示指数约为 1.5。 [Boehm 的数据并不完全一致，在 1.05 和1.2 之间变化。 1 ]
8.5 Portman 的 ICL 数据显示相对于其他活动开销， 全职程序员仅将 50％的时间用于编程和调试。
8.6 IBM 的 Aron 数据显示，生产率是系统各个部分交互的函数，在 1.5K 千代码行/人年至 10K 千代码行/人年的范围内变化。
8.7 Harr 的 Bell 实验室数据显示对于已完成的产品，操作系统类的生产率大约是0.6KLOC/人年，编译类工作的生产率大约为 2.2KLOC/人年。
8.8 Brooks 的 OS/360S 数据与 Harr 的数据一致：操作系统 0.6～0.8KLOC/人年，编译器 2～3 KLOC/人年。
8.9 Corbato 的 MIT 项目 MULTICS 数据显示， 在操作系统和编译器混合类型上的生产率是 1.2KLOC/人年，但这些是 PL/I 的代码行，而其他所有的数据是汇编代码行。
8.10 在基本语句级别，生产率看上去是个常数。
8.11 当使用适当的高级语言时，程序编制的生产率可以提高 5 倍。
第9章 削足适履
Part 1 作为成本的程序空间
由于规模是软件系统产品用户成本中如此大的一个组成部分，开发人员必须设置规模的目标，控制规模，考虑减小规模的方法，（就像硬件开发人员会设立元器件数量目标， 控制元器件的数量， 想出一些减少零件的方法。）同任何开销一样，规模本身不是坏事，但不必要的规模是不可取的。
Part 2 规模控制
一些痛苦的教训：
① 仅对核心程序设定规模目标是不够的，必须把所有的方面都编入预算。
第一个道理很清楚：和制订驻留空间预算一样，应该制订总体规模的预算；和制订规模预算一样，应该制订后台存储访问的预算。
② 在每个模块分配功能之前，已编制了空间的预算。使得任何在规模上碰到问题的程序员，会检查自己的代码，看是否能将其中一部分扔给其他人。
第二个道理也很清晰：在指明模块有多大的同时，确切定义模块的功能。
③ 项目规模本身很大，缺乏管理和沟通，以至于每个团队成员认为自己是争取小红花的学生，而不是构建系统软件产品的人员。（为了满足目标，每个人都在局部优化自己的程序，很少会有人停下来，考虑一下对客户的整体影响。）
在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。
培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
Part 3 空间技能
（1）技巧：用功能交换尺寸：
① 设计人员必须决定用户可选项目的粗细程度。
在内存大小一定的情况下进行系统设计时，会出现另外一个基本问题。内存受限的后果是即使最小的功能模块，它的适用范围也难以得到推广。在最小规模的系统中，大多数模块被覆盖（overlaid），系统的主干占用的空间，会被用作其他部分的交换页面。它的尺寸决定了所有模块的尺寸。而且将功能分解到很小的模块会耗费空间和降低性能。
（2）技巧：用考虑空间－时间的折中
项目经理可以做两件事来帮助团队取得良好的空间－时间折中
① 确保在编程技能上得到培训，而不仅仅是依赖他们自己掌握的知识和先前的经验。特别是使用新语言或者新机器时，培训显得尤其重要。熟练使用往往需要快速的学习和经验的广泛共享，也许它应该伴随特别的新技术奖励或者表扬。
② 认识到编程需要技术积累，需要开发很多公共单元构件。每个项目要有能用于队列、搜索和排序的例程或者宏库。对于每项功能，库至少应该有两个程序实现：运行速度较快和短小精炼的。
Part 4 数据的表现形式是编程的根本
由于缺乏空间而绞尽脑汁的编程人员，常常能通过从自己的代码中挣脱出来，回顾、分析实际情况，仔细思考程序的数据，最终获得非常好的结果。实际上，数据的表现形式是编程的根本。
作者总结
9.1 除了运行时间以外，所占据的内存空间也是主要开销。特别是对于操作系统，它的很多程序是永久驻留在内存中。
9.2 即便如此，花费在驻留程序所占据内存上的金钱仍是物有所值的，比其他任何在配置上投资的效果要好。规模本身不是坏事，但不必要的规模是不可取的。
9.3 软件开发人员必须设立规模目标，控制规模，发明一些减少规模的方法—就如同硬件开发人员为减少元器件所做的一样。
9.4 规模预算不仅仅在占据内存方面是明确的，同时还应该指明程序对磁盘的访问次数。
9.5 规模预算必须与分配的功能相关联；在指明模块大小的同时，确切定义模块的功能。
9.6 在大型的团队中，各个小组倾向于不断地局部优化，以满足自己的目标，而较少考虑队用户的整体影响。这种方向性的问题是大型项目的主要危险。
9.7 在整个实现的过程期间，系统结构师必须保持持续的警觉，确保连贯的系统完整性。
9.8 培养开发人员从系统整体出发、面向用户的态度是软件编程管理人员最重要的职能。
9.9 在早期应该制订策略，以决定用户可选项目的粗细程度，因为将它们作为整体大包能够节省内存空间。 [常常还可以节约市场成本]
9.10 临时空间的尺寸，以及每次磁盘访问的程序数量是很关键的决策，因为性能是规模的非线性函数。[这个整体决策已显得过时—起初是由于虚拟内存，后来则是成本低廉的内存。现在的用户通常会购买能容纳主要应用程序所有代码的内存。]
9.11 为了取得良好的空间－时间折中，开发队伍需要得到特定与某种语言或者机型的编程技能培训，特别是在使用新语言或者新机器时。
9.12 编程需要技术积累，每个项目需要自己的标准组件库。
9.13 库中的每个组件需要有两个版本，运行速度较快和短小精炼的。
9.14 精炼、充分和快速的程序。往往是战略性突破的结果，而不仅仅技巧上的提高。
9.15 这种突破常常是一种新型算法。
9.16 更普遍的是，战略上突破常来自于数据或表的重新表达。数据的表现形式是编程的根本。
第10章 提纲挈领
技术、周边组织机构、行业传统等若干因素凑在一起，定义了项目必须准备的一些文书工作。
某些部分包含和表达了一些管理方面的工作：
① 每份文档的准备工作是集中考虑，并使各种讨论意见明朗化的主要时刻。
② 文档的跟踪维护是项目监督和预警的机制。
③ 文档本身可以作为检查列表、状态控制，也可以作为汇报的数据基础。
Part 1 计算机产品文档
如果要制造一台机器，哪些是关键的文档呢？
目标：定义待满足的目标和需要，定义迫切需要的资源、约束和优先级。
技术说明：计算机手册和性能规格说明。它是在计划新产品时第一个产生，并且最后完成的文档。
进度、时间表
预算：预算不仅仅是约束。对管理人员来说，它还是最有用的文档之一。预算的存在会迫使技术决策的制订，否则，技术决策很容易被忽略。更重要的是，它促使和澄清了策略上的一些决定。
组织机构图
工作空间的分配
报价、预测、价格：这三个因素互相牵制，决定了项目的成败。
为了进行市场预测，首先需要制订产品性能说明和确定假设的价格。从市场预测得出的数值，连同从设计得出的组件单元的数量，决定了生产的估计成本，进而可以得到每个单元的开发工作量和固定的成本。固定成本又决定了价格。
Part 2 大学科系的文档
目标
课程描述
学位要求
研究报告（申请基金时，还要求计划）
课程表和课程的安排
预算
教室分配
教师和研究生助手的分配
注意这些文档的组成与计算机项目非常相似：目标、产品说明、时间安排、资金分配、空间分派和人员的划分。只有价格文档是不需要的，学校的决策机构完成了这项任务。这种相似性不是偶然的—任何管理任务的关注焦点都是时间、地点、人物、做什么、资金。
Part 3 软件项目的文档
在许多软件项目，不论项目的规模如何小，项目经理聪明的做法都是：立刻正式生成若干文档作为自己的数据基础。接着，会和其他管理人员一样要求各种文档。
内容：目标。定义了待完成的目标、迫切需要的资源、约束和优先级。
内容：产品技术说明。以建议书开始，以用户手册和内部文档结束。速度和空间说明是关键的部分。
时间：进度
资金：预算
地点：工作空间分配
人员：组织图。它与接口说明是相互依存的，一开始反映系统设计的组织架构图，肯定不会是正确的。如果系统设计能自由地变化，则项目组织架构必须为变化做准备。
Part 4 为什么要有正式文档？
首先，书面记录决策是必要的。只有记录下来，分歧才会明朗，矛盾才会突出。书写这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到清晰、确定的策略。
第二，文档能够作为同其他人的沟通渠道。项目经理常常会不断发现，许多理应被普遍认同的策略，完全不为团队的一些成员所知。正因为项目经理的基本职责是使每个人都向着相同的方向前进，所以他的主要工作是沟通，而不是做出决定。这些文档能极大地减轻他的负担。
最后，项目经理的文档可以作为数据基础和检查列表。通过周期性的回顾，他能清楚项目所处的状态，以及哪些需要重点进行更改和调整。
项目经理的任务是制订计划，并根据计划实现。但是只有书面计划是精确和可以沟通的。计划中包括了时间、地点、人物、做什么、资金。这些少量的关键文档封装了一些项目经理的工作。如果一开始就认识到它们的普遍性和重要性，那么就可以将文档作为工具友好地利用起来，而不会让它成为令人厌烦的繁重任务。通过遵循文档开展工作，项目经理能更清晰和快速地设定自己的方向。
作者总结
10.1 前提：在一片文件的汪洋中，少数文档形成了关键的枢纽，每个项目管理的工作都围绕着它们运转。它们是经理们的主要个人工具。
10.2 对于计算机硬件开发项目，关键文档是目标、手册、进度、预算、组织机构图、空间分配、以及机器本身的报价、预测和价格。
10.3 对于大学科系，关键文档类似：目标、课程描述、学位要求、研究报告、课程表和课程的安排、预算、教室分配、教师和研究生助手的分配。
10.4 对于软件项目，要求是相同的：目标、用户手册、内部文档、进度、预算、组织机构图和工作空间分配。
10.5 因此，即使是小型项目，项目经理也应该在项目早期规范化上述的一系列文档。
10.6 以上集合中每一个文档的准备工作都将注意力集中在对讨论的思索和提炼，而书写这项活动需要上百次的细小决定，正是由于它们的存在，人们才能从令人迷惑的现象中得到清晰、确定的策略。
10.7 对每个关键文档的维护提供了状态监督和预警机制。
10.8 每个文档本身就可以作为检查列表或者数据库。
10.9 项目经理的基本职责是使每个人都向着相同的方向前进。
10.10 项目经理的主要日常工作是沟通，而不是做出决定；文档使各项计划和决策在整个团队范围内得到交流。
10.11 只有一小部分管理人员的时间—可能只有 20%—用来从自己头脑外部获取信息。
10.12 出于这个原因，广受吹捧的市场概念—支持管理人员的“完备信息管理系统”并不基于反映管理人员行为的有效模型。