第七章一开头就引用了《战国策。秦策》里的话：“王不如远交而近攻，得寸，则王之寸；得尺，亦王之尺也”。
在第一部分给我们讲述了大公司IBM的故事，在它们这些公司的手中，都有一个算盘，它们都是为了获利而存在。大公司们在标准、理论、语言上的争来夺去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企图， 其最终目的是在整个软件工程体系中的全面胜出。因而，除了软件本质力量的推动之外，商业因素也推动着软件工程体系的发展。大公司们的争夺战的最终结果，已经开始把软件工程，从原始的“自生演进”状态，逐渐推进到“它激发展”的状态上了。然而工程实现的关键还是程序和算法。
在理想状态下，软件工程=方法+工具+过程，但是工程真正成功的关键并不在于你把你的团队“组织”得有多好。即便在团队中他们都显示有条不紊，一样会面临失败。在这里作者给我们三点建议：1、不计成本的项目计划不会得到经营者的支持。2、毫无目的地消耗成本是项目中的慢性毒药。3、最致命的风险是成本的枯竭。
最后一章的标题是“是思考还是思想”。开头引用实例，“此郎亦管中窥豹，时见一斑。 ”——《晋书·王献之传》
思考问题的方法可以是由点及面的，也可以是统揽全局的，换成业界最常用的词汇，就是“自上而下”还是“自下而上”区别。
工程的整体问题依旧是“实现”，我们要做的就是把每一个细节拼和起来，得到的才能是一个整体。所以在以前在读这本书的过程中，我们发现它割裂了软件工程的各个要素，并从每个孤立的层面来审视。本质上我们都应该回归到软件工程的本体上来思考问题，而不是仅仅关注与每一个局部的要素。
作者还说了让我们比较难懂的UML的问题，UML和甲骨文都是符号文字，都具有象形意义。在工程中使用UML图，应该有相应的文字来描述它。这种描述与图之间的对应关系要持续地维护下去。如果这关系松散断裂了，那么UML和甲骨文出土的时候没什么区别。
工具、方法与过程被称为软件工程的三个要素。这三个要素各自为一个整体，但是他们之间又互有联系。他们共同组成了一个工程。实际上，在软件开发的过程中，存在一个问题：开发者的目的是在保障质量的前提下实现目标。但是最后的结果就是：我们会在项目交付和试用时才会碰到客户在质量上的投诉。然后就是那个成员相互推卸责任，需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚或者变更的没完没了。我们看到，在项目的平衡三角(时间、资源和功能)中讨论的是目标问题。现在绝大部分的公司只追求实现目标，而忽略了质量的问题。往往这个质量出现的问题，都源自于细节。细节处理不好就很容易出现一些我们意想不到的错误。
最后，想用书结尾的一句话来给我的最后一篇读后感结尾：“未蕴而变，自欺也。知律而变，智者之道也。变向不变求。不变者，万变之所源，亦万变之所归。”大多数人不知道究竟使用着什么技巧和方法，一旦出了什么问题就归咎于所使用的方法不好。真正的问题在于，因为不知道变通，也不知道回避错误。
