第6章贯彻执行
6.1 即使是大型的设计团队，设计结果也必须由一个或两个人来完成，以确保这些决定是一致的。
6.2 必须明确定义体系结构中与先前定义不同的地方，重新定义的详细程度应该与原先的说明一致。
6.3 出于精确性的考虑，我们需要形式化的设计定义，同样，我们需要记叙性定义来加深理解。
6.4 必须采用形式化定义和记叙性定义中的一种作为标准，另一种作为辅助措施；它们都可以作为表达的标准。
6.5 设计实现，包括模拟仿真，可以充当一种形式化定义的方法；这种方法有一些严重的缺点。
6.6 直接整合是一种强制推行软件的结构性标准的方法。[硬件上也是如此——考虑内建在ROM中的Mac WIMP接口。]
6.7 “如果起初至少有两种以上的实现，那么（体系结构）定义会更加整洁，会更加规范。”
6.8 允许体系结构师对实现人员的询问做出电话应答解释是非常重要的，并且必须进行日志记录和整理发布。[电子邮件是一种可选的介质。]
6.9 “项目经理最好的朋友就是他每天要面对的敌人——独立的产品测试机构/小组。”
第7章为什么巴比伦塔会失败？
7.1 巴比伦塔项目的失败是因为缺乏交流，以及交流的结果——组织。
交流
7.2 “因为左手不知道右手在做什么，从而进度灾难、功能的不合理和系统缺陷纷纷出现。”由于对其他人的各种假设，团队成员之间的理解开始出现偏差。
7.3 团队应该以尽可能多的方式进行相互之间的交流：非正式、常规项目会议，会上进行简要的技术陈述、共享的正式项目工作手册。[以及电子邮件。]
项目工作手册
7.4 项目工作手册“不是独立的一篇文档，它是对项目必须产生的一系列文档进行组织的一种结构。”
7.5 “项目所有的文档都必须是该（工作手册）结构的一部分。”
7.6 需要尽早和仔细地设计工作手册结构。
7.7 事先制订了良好结构的工作手册“可以将后来书写的文字放置在合适的章节中”，并且可以提高产品手册的质量。
7.8 “每一个团队成员应该了解所有的材料（工作手册）。”[我想说的是，每个团队成员应该能够看到所有材料，网页即可满足要求。]
7.9 实时更新是至关重要的。
7.10 工作手册的使用者应该将注意力集中在上次阅读后的变更，以及关于这些变更重要性的评述。
7.11 OS/360项目工作手册开始采用的是纸介质，后来换成了微缩胶片。
7.12 今天[即使在1975年]，共享的电子手册是能更好达到所有这些目标、更加低廉、更加简单的机制。
7.13 仍然需要用变更条和修订日期[或具备同等功能的方法]来标记文字；仍然需要后进先出（LIFO）的电子化变更小结。
7.14 Parnas强烈地认为使每个人看到每件事的目标是完全错误的；各个部分应该被封装，从而没有人需要或者允许看到其他部分的内部结构，只需要了解接口。
7.15 Parnas的建议的确是灾难的处方。[Parnas让我认可了该观点，使我彻底地改变了想法。]
组织架构
7.16 团队组织的目标是为了减少必要的交流和协作量。
7.17 为了减少交流，组织结构包括了人力划分（division of labor）和限定职责范围（specialization of function）。
7.18 传统的树状组织结构反映了权力的结构原理——不允许双重领导。
7.19 组织中的交流是网状，而不是树状结构，因而所有的特殊组织机制（往往体现成组织结构图中的虚线部分）都是为了进行调整，以克服树状组织结构中交流缺乏的困难。
7.20 每个子项目具有两个领导角色——产品负责人、技术主管或结构师。这两个角色的职能有着很大的区别，需要不同的技能。
7.21 两种角色中的任意组合可以是非常有效的：