现实中的软件工程
大公司的算盘：从最早仅仅关注于软件开发工具到现在，软件行业中的巨头们已经在层出不穷的思想中涅槃了一回又一回。软件业界如今的局面，不是一些人(例如程序员或者评论家们)争争吵吵的结果，而是大公司们相互制衡的结果。每一个不同的大公司都在做着相同的事，又都有各自的算盘。例如最近双11节时候，阿里巴巴集团和京东都是在搞活动，但是他们一面打压对手的优势，一面又借助对手和同盟的力量来削弱自己的劣势或者补充实力。 而只是这个地位，无论谁成就了这个地位，都将承受相同的风险与压力。 当然也包括机会。 大公司们在标准、理论、语言上的争来夺去，未必全然出于“软件实现”的考虑。对统一理论、统一工具、统一过程的企图，其最终目的是在整个软件工程体系中的全面胜出。 所以在大公司要有计谋，
回到工程的关键点 ：因而，除了软件本质力量的推动之外，商业因素也推动着软件工程体系的发展。大公司们的争夺战的最终结果，已经开始把软件工程，从原始的“自生演进”状态，逐渐推进到“它激发展”的状态上了所以在每一个程序前面我们必须要知道工程的出发点，要让他完成怎样的目标：
思考项目成本的经理 ：
项目的管理到底是组织管理还是成本管理？
u 项目的计划到底是组织规划还是成本计划？
简单的说：简单来说每一个项目每一个工作都会需要考虑到成本，资本。如果这里没有了资本，没了价值那他就失去了存在的意义。
是思考还是思想
软件工程三个要素：工具、方法与过程也被称为软件工程的三个要素的价值由于方法在过程环节以及过程总体层面上具有贯通性，因此保证“方法(或其行为)”的实施的“工具”也会是思考还是思想出现在过程的各个环节和层面上。因此这样得到的软件工程模型将不是经典的、层状的“牛屎图”，而可能象太极图一样由阴阳交汇而生万物。你能把每一个“管见”拼合起来，你得到的才能是“豹”，而不是“斑”。所以尽管本书割裂了软件工程的各个要素，并从每个孤立的层面来审视。然而实质上，你应该回归到软件工程的本体上来思考问题，而不是仅关注于每一个局部的要素。所以要把，一个程序，一个工程弄好那么久的注重这三个要素。
其实RUP是一个杂物箱：不得不承认它是对前人在软件过程思想方面高度包容，可以把RUP定制成其它任何模型所表述的过程形态。——RUP 本身的特质决定了这一点。——因而它也如同一个杂物箱一样放满了各种希奇古怪的东西。你可能从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，可以这么说RUP是一种很好用的工具。
UML与甲骨文之间的异同 ：在你真的打算用甲骨文来写项目文档之前，请先明确UML与甲骨文之间的异同。所以在工程中使用UML图，应该有相应的文字来描述它。而且这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的，将是无异于甲骨文出土时的困境。
经营者离开发者很远，反之亦然：
枝节与细节 ：所以我们通常所说的细节，其实是对实施方法的一些有限量的描绘。比如“软件工艺”这个概念本身的提出，就是考究“细节问题”的。从这个角度上来说，我并不反对“细节决定成败”这样的观点。但请注意一个前提：这是技术或方法的细部。事实证明我们要完一个好程序那就必须做好主干。