软件工程体系的发展一方面是软件本质力量的推动，另一方面则是商业因素的推动。大公司们的争夺战把软件工程，从原始的“自生演进”状态，逐渐推进到“它激发展”的状态上了。从软件行业的巨头们的争夺战开始说起。
为了构建一个完整的软件工程体系，Rational被IBM并购。IBM得到了Rational,就迅速拥有了一套成熟的理论体系和实作工具。丰富的UML语言的实践经验，和RUP作为理论框架的创业者和领导者地位，提升了软件工程商的形象。IBM把握住了开源界，在潮流中占据了稳如磐石的力量。对于Borland积极推动UML的标准化，并购与实现了ALM体系相关的公司，优化实务部，强化模型构建能力等一系列重大举措，迅速补齐了AML作为工程体系在理论上的不足。以及后来的Mono造成的强大影响力。巨头们在打着算盘不断优化发展自己的同时，也在借助对手和同盟的力量来削弱着自己的劣势或者补充实力。各公司之间相互制衡发展。
工程层状模型程序和方法层面上是关注与实现的。而在过程和工程层面上则首先要考虑团队问题。开发经理思考的是项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。项目要注意成本。团队需要资本，有了资本才能运作，项目的存在才有了必要性与可能性。项目要考虑时间成本。要在适当的时间内完成客户的要求。项目完成需要方法。方法的好坏标准只有一个那就是：节约成本。毫无目的的消耗成本甚至造成成本的枯竭最终都会导致项目的枯竭。不计成本的项目计划也不会得到经营者的支持。Acept思想了解以后，语言只是工具，那样你就可以来实现它了。MDA作为软件开发方法的架构，即使在技术研究，底层协议，软件实现方面经过了持续的完善且逐渐成熟，若没有同样成熟的软件过程理论支持，使用价值也就有限。
本书从软件工程的从各个要素孤立的层面来审视问题。而实质上你应该回归到软件工程的本体上来思考问题。把各个要素拼在一起，才有可能窥见工程的面目。RUP就像一个杂物箱，是各种东西的包容体。转换一下思维，就可能实现它的妙用。RUP能否被用起来取决于你的挑选能力以及拿到以后的辨识利用能力。语言的作用在于沟通。出于沟通的必要，需要被表达的足够的准确和详细。UML图是否充分需要提供一个充足的信息。另外基于UML语言它的无法在平台上检错和调试，因此需要相应的文字描述UML图，描述他与图之间的关系。角色关注层面的不同，沟通对于项目经理协调经营者与开发者的关系就显得尤为重要。目标需要在平衡中确立，但质量却要在过程中控制。即使时间，资源，功能实现了平衡，客户，项目，公司同样满足于平衡目标，它仍可能不能实施。实现目标与保障质量之间好像总是存在着矛盾。管理人员在做事件决策的时候，要学会忽略枝节的问题。死读书的人不会真正明白软件工程，我们在使用方法和技巧的时候如果能明白他的原理，就能变通的回避错误了。学而不思则罔，指的就是这个道理。