大道至简第七、八章读后感
IBM为构建一个完整的软件工程体系而并购Rationaal，并在语言方面选择Java，而且亲近开源界，以把握力量，在潮流中稳如磐石。
Borland也从开发工具厂商的位置跳出来，在保持在语言上的中立的基础上，积极推动UML的标准化。
与Borland 和IBM 通购并来达到目的的方式并不相同，Microsoft有足够的力量全方位出击，提出.NET Framework以挑战UML的地位，Mono解决了Microsoft产品的跨平台问题，进而削弱了 SUN这样的语言的跨平台优势。 接下来Microsoft开始向模型语言发难，提出领域专用语言（Domain-Specific Language，DSL ）
大公司们在标准、理论、语言上的争来夺去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企图，其最终目的是在整个软件工程体系中的全面胜出。
因而，除了软件本质力量的推动之外，商业因素也推动着软件工程体系的发展。大公司们的争夺战的最终结果，已经开始把软件工程，从原始的“自生演进”状态，逐渐推进到“它激发展”的状态上了。 这种它激发展可能会影响到软件工程发展的速度，然而在各个工程层面上的关注点并不会发生变化。
在项目开发过程中成本问题是至关重要的， 不计成本的项目计划不会得到经营者的支持；毫无目的地消耗成本是项目中的慢性毒药； 最致命的风险是成本的枯竭。
工具、方法与过程是软件工程的三个要素，在这本书中他们被分解开来思考，但这并不是要孤立这三个层面——它们实际上是相互作用的。我们应该回归到软件工程的本体上来思考问题，而不仅仅是关注于每一个局部的要素，工程的整体问题仍旧是“实现”。
不管是用什么语言来写项目文档，
其最终的目标都是沟通，无论是UML还是甲骨文，它们都是符号文字，都具有象征意义。出于沟通的必要，这种语言的象征意义在一个图中应当被表述得足够准确和详细，乃至于针对于不同的阅读者都能提供充足的信息。在工程中使用UML图，应该有相应的文字来描述它。而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的，将是无异于甲骨文出土时的困境。
经营者离开发者很远，反之亦然。项目经理则是其中间角色，需要协调经营者与开发者之间的沟通，因为角色的关注层面完全不同。
在项目的平衡三角( 时间、资源和功能) 中讨论的是目标问题，但并不讨论质量问题。也就是说，经典教材中总是关注：如何更快的完成项目，并减少资源占用，以及实现更多的功能。然而，即使平衡了这种关系，项目的结果仍可能产生一个天生的残障。 因为目标可能在平衡中确立，但质量却要在过程中控制。即使在时间、资源和功能三者中取得了平衡，即使客户、项目组和公司同样满意于这个平衡“目标”，它仍然有可能是“不能实施”的。
在需求阶段我们就会面临“目标”的问题。然而( 在大多数时候) ，与此相反的是我们会在项目交付和试用时才会碰到客户在质量上的投诉。关键在于解决实现目标与保障质量的矛盾，寻求两者之间的平衡。
软件工程是灵活多变的，并不局限于某些技巧或方法之中，只要我们理解了软件工程的规律和原理，才会做真正的软件工程。