6·
第十一章，这里作者首先讨论了实验性工厂的重要性；一个产品制作出来，通得过开发过程中的测试不代表就能经得住实际环境的使用，需要一个中继站式的实验性工厂，一个介于开发环境和实际使用环境的中间环境来测试软件；变化是始终存在的，机器在变化，配置在变化，重要的是用户需求也在变化；一开始设计的产品会随着时间的推移慢慢的变得不合时宜，而且在长期的维护和修改过程中，它一开始的设计被破坏，它的体系结构变得混乱，修改变得越来越缺乏根基，这个时候继续这种修补式的维护已经没有了意义，给予原有系统的重新设计是完全必要的。
7·
第十二章和第十三章；
第十二章，作者主要是在讨论工具的重要性，这里不赞成单个的参与者储备自己的个性化工具，因为这些工具的出现不一定符合最终系统的需求，有可能会让系统的风格完整性丢失；一个工程需要有单独的一个或几个人来管理整个团队的工具，这几个人需要有使用工具，编写工具和教别人使用工具的能力。
第十三章作者主要是在阐述bug处理的工作。对于bug，我们要做的当然是尽可能的避免它出现，但是软件制作当中，bug又避无可避。源于此，一方面，我们需要一个良好的设计来尽可能的避免bug的出现，另一方面，我们还需要有在bug出现时良好的处理bug的能力。一个良好的设计应该具备以下几点：
1·清晰的结构和表达方式更容易对需求和模块功能进行精确的描述；
2·模块分割和模块独立性避免了系统级的bug；
3·细节的抑制使结构上的缺点更容易识别；
4·设计在每个精化步骤上都是可以测试的，所以测试可以尽早开始，并且每个步骤的重点可以放在合适的级别上；
8·
第十四章
这里阐述的是关于计划实施的监督和预警的方式。由于各种各样的原因，我们的计划总是会被推迟，一点一点的小的延迟的积累最终造成的是进度的巨大延迟，而每天一点的延迟又是很难察觉的。为了解决这个问题，首先我们需要设置一个又一个的阶段目标来给开发的时间订立限制，这个目标必须是一个100%的事件，越清晰越好；另外还要设置计划和控制小组，他们要实时的了解计划的完成情况，做好记录和回报工作。
当开发陷于延迟的时候，一线人员一般不愿意向boss回报这个情况，因为没人愿意汇报坏的消息，一线人员更倾向于自己解决进度问题，但是boss需要实时了解进度情况和状态，在这一点上boss和一线人员的利益是冲突的。解决这个问题，不仅仅需要上述的阶段目标和计划控制小组及时的记录和上报，boss处理这件事的方式也至关重要，在事情变得无法控制之前，boss最好不要有所动作，一线人员不愿看到boss得知进度落后的消息之后惊慌失措或者越主代庖，boss应该做的是开好定期的交流会议，及时了解开发的进度和状态，在必要的时候再去开问题-行动会议。
9·
第十六章
没有银弹，在这一章中，作者首先表述了软件开发过程中的固有困难，软件本身的复杂度，软件本身的复杂度比任何已经存在的人类工程都要高，这是软件的根本属性，不是次要属性。而对于这个问题，当前却没有一个很好的解决问题的“银弹”出现，虽然，高级语言、面向对象、以及人工智能可以看做是“银弹”的希望，但是至少暂时并不能真正解决软件的根本困难。
对于解决根本问题，作者提出了几个方法，
第一个是购买软件，而不是自主开发，当然这对于开发者本身而言，好像没什么意义；
另外是 需求精炼和快速原型，作者认为，概念性工作中，没有任何一个部分比确定详细的技术需求更加困难，详细的需求包括所有的人机界面，与机器和其他软件系统的接口。如果需求失误了，将比其他任何一部分的影响都严重。软件开发人员为客户承担最重要的职能是不断重复和抽取和细化产品的需求，因为客户并不知道自己的需求是什么。现在的技术中最有希望能解决软件开发的根本问题的是 开发作为迭代需求过程的一部分---快速原型化系统和工具。
快速原型化系统和工具，对重要的系统界面进行模拟，并演示待开发系统的主要功能，同时，原型不必受到硬件速度、规模后者成本的限制。原型的目的是明确实际的概念结构，是客户测试一致性和可用性；
最后，作者介绍了关于 增量开发 的概念，从上而下的搭建软件，像人脑的成长一样，逐步发育的软件，而不是一次性搭建成功。
另外，关于如何提高软件行业的核心，最重要的还是 人员 。卓越的人员和一般的人员之间的差异往往不是一点半点。对于有着卓越的设计潜质的人员，要重要加以培养。在各个方面给予特殊待遇。关于如何培养设计人员，作者简单的提出了一些观点：
1·尽可能早地、有系统地识别顶级的设计人员，最好的通常不是最有经验的；
2·为设计人员指派一位职业导师，负责他们的技术方面的成长，仔细地为他们规划职业生涯；
3·为每一个方面制定和维护一份职业计划，包括与设计大师的、经过仔细挑选过程的学习过程，正式的高级教育和短期的课程-----所有这些都穿插再设计和技术领导能力的培养过程中；
4·为成长中的设计人员提供互相交流和激励的机会；