软件开发对于我们来说仅仅是学习课程，但等我们踏入社会，走向公司，这将会成为我们的饭碗。就有了竞争。软件开发中的竞争无疑是在于软件的质量，语言的简便，这种东西容易被人借鉴。每个公司都有自己的优势及突出产品，有的可能是语言，有的可能是软件，而对手就会打压这种优势，一群人争来争去，有联合也有打压。当然也有比较突出的产业，这就会收到联合攻击。
从最早仅仅关注于软件开发工具到现在，软件行业中的巨头们已经在层出不穷的思想中涅槃了一回。把握力量总之比创造力量来得经济。
软件业界如今的局面，不是一些人(例如程序员或者评论家们)争争吵吵的结果，而是大公司们相互制衡的结果。他们一面打压对手的优势，一面又借助对手和同盟的力量来削弱自己的劣势或者补充实力。除了软件本质力量的推动之外，商业因素也推动着软件工程体系的发展。这种它激发展可能会影响到软件工程发展的速度，然而在各个工程层面上的关注点并不会发生变化。
抛开实现的技术细节不论，在工程中，“以什么驱动开发”其实是一个过程问题。过程的选择(或制定)取决于你的工程需要，以及它在相关应用领域的适用性、过程工具的充备性和这个过程理论的完善程度，而不是大公司们的鼓吹。
虽然书中对软件工程的各个要素孤立来分析，但是其实所有这些要素之间是相互关联的，是一个有机的整体。所以，对软件工程的把握，我们不能将这些要素割裂开来，需要整体来思考。我觉得，作者发明的EHM就是一个很好的架构图，秉着这个秘笈，就算有些弯路，也不会差得太大。
思考问题的方法可以是由点及面的，也可以是统揽全局的。换成业界最常用的词汇，就是“自上而下”还是“自下而上”的区别。
为一个重量级的软件开发过程模型，他体现了巨大的“包容性”，所以作者把他比喻成一个杂物箱。那杂物箱和专业工具箱的差别是什么呢？其实，专业的工具也都可以放入杂物箱，只是没用的多余的东西也可能混杂其中，所以，需要做的就是定制！。“枝节与细节”，再次提醒软件工程管理人员，很多时候确实需要关注一些细节问题，以保证产品质量。但是做决策的时候又必须学会忽略细枝末节的问题，只有把握整体才是关键，才能做出正确的决策。软件工程是一系列严谨的过程，但又需要灵活的掌控。不要拘泥于软件工程各个过程的形式，不同的角色，他们的关注层面是非常不同的。不要期望BOSS理解某种设计显得多么优美，也不要期望Programer多么考虑为项目节省成本，要铺就这个天堑中的桥梁，正是项目经理这个角色的职责之一。意识到自己角色的定位、职责，是做对、做好事情的前提！目标（产品的功能和交互的时间）和产品的质量总是一对难以调和的矛盾。不过，没有谁能告诉你彻底解决的办法。就类似于无论硬件性能的如何提升，都无法满足软件无止境的需求一样。或许，这对矛盾将是永远困扰软件工程的问题。
在需求阶段我们就会面临“目标”的问题。然而(在大多数时候)，与此相反的是我们会在项目交付和试用时才会碰到客户在质量上的投诉。如果原定的目标(的整体)本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保障不了质量。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
