现实中的软件工程 是思考还是思想
从最早的软件工具开始到现在，软件行业中的巨头们已经在层出不穷的思想中涅槃了一回又一回。Rational被IBM并购，Borland平衡与IBM与Mircosoft之间，各个大公司互相制衡，可以说现在的软件业界的局面就是这些大公司互相制衡的结果。大公司们在标准、理论、语言上的争来夺取，未必全然出自于“软件实现”的考虑。因而，除了软件本质力量的推动外，商业因素也推动着软件工程体系的发展。大公司之间的竞争已经将软件工程由原始的“自然演进”状态逐渐推进到“他激发展”的状态上了。
项目管理要不要考虑成本？答案是显然的，需要。在一个项目中，项目真正成功的关键并不是你把你的团队组织的有多好，比如在蚂蚁的团队中，总是有条不紊的，但是如果这个蚂蚁群体有了流行疾病，而新生蚂蚁不能跟上死亡的速度，那么很快，这个群体就溃散了。因为蚂蚁群体的资本在流失，如果资本没了，团队就不在运作，项目就死亡了。永远记住，如果你的一个项目跟愚公一样需要300年，你的客户在你做成之前就已经选择了放弃。所以，不计成本的项目计划不会得到经营者的支持，毫无目的的消耗成本是项目中的慢性毒药，最致命的风险是成本的枯竭。
思考问题的方法是可以由点及面，也是可以统揽全局的。由于方法在过程环节以及过程总体层面上具有贯通性，因此保证“方法(或其行为)”的实施的“工具”也会出现在过程的各个环节和层面上。 我们应该将各个环节层面总和，然后回归到软件工程的本质上来考虑问题，，而不是仅关注于每一个局部的要素。工程的整体问题仍旧是“实现”。RUP是对前人在软件过程思想方面高度包容，他向一个杂物箱一样包含了全部的已知理论。你可以把RUP定制成其它任何模型所表述的过程形态。RUP能否被用起来，取决于你是否能够很好地进行挑挑拣拣，如果你有很好的辨识与组织能力，那么你就可以将其转化为生产力。UML与甲骨文的异同。UML与甲骨文都是符号文字，都具有象形含义。然而这并不表明UML符号本身能表达多么丰富的含义。出于沟通的必要，这种语言的象征意义在一个图中应当被表述得足够准确和详细，乃至于针对于不同的阅读者来说都能提供了充足的信息，然而UML作为一门语言不能在某个硬件平台中被语法检错，也没有提供一个标准来衡量UML图怎样才是描述最充分的。所以在工程中使用UML图应该有相应的文字来描述它。经营者离开发者很远，反之亦然，于是项目经理这种中间角色就有了一种使命，协调经营者与开发者的沟通。而造成这种根源的原因也很简单：各个角色的关注层面不同。