第七章标题为现实中的软件工程，共分为四小节，标题分别为：1、大公司手中的算盘；2、回到工程的关键点；3、思考项目成本的经理；4、审视AOP；5、审视MDA/MDD。第八章分为七小节分别是：1、软件工程的三个要素的价值；2、其实RUP是一个杂物箱；3、UML与甲骨文之间的异同；4、 经营者离开发者很远，反之亦然；5、 矛盾：实现目标与保障质量；6、枝节与细节；7、灵活的软件工程。
在第七章第一小节中作者向我们介绍了IBM公司的发展状况，并由此讲到其他的大型软件公司，揭示了他们一面打压对手的优势，一面又借助对手和同盟的力量来削弱自己的劣势或者补充实力的现实内幕。并下了软件业界如今的局面，不是一些人( 例如程序员或者评论家们) 争争吵吵的结果，而是大公司们相互制衡的结果这一结论。
第七章第二节讲述了软件开发的模式，并指出在“程序”与“方法”层面，是关注于“( 具体的) 实现”的；而在“过程”和“工程”层面，更首要考虑的是团队问题。从角色的角度上来讲，开发经理思考项目的实施方案和管理具体的开发行为；而项目经理则保障团队的稳定性和一致性。 然而这只是基本模式，或者说，是理想模式。
第七章第三节作者向我们讲述了作为项目经理应该关注的东西，项目经理应该从细节中跳出来，思考的问题应该是完成工程的“方法”，而评价这一方法是否成功的标准便是是否节约成本。作为项目经理应该学会思考成本，不计成本的项目计划不会得到经营者的支持，毫无目的地消耗成本是项目中的慢性毒药，最致命的风险是成本的枯竭。
第七章第四五节向我们讲述了AOP与MDA/MDD。AOP不是语言，是方法论。OOP所基于的数据结构是对象(Object) ，而AOP所基于的数据结构就是方面(Aspect)。切分点是 AOP作为一个框架时所需要的一个工具：一组辨识Acpects 和Objects的索引。至于MDA/MDD。MDA(Model Driven Architecture)也是一个方法论层面上的名词。它讨论的是“创建出机器可读和高度抽象的模型”的方法。在工程中，“以什么驱动开发”其实是一个过程问题。尽管对MDA提出了一套完备的技术和方法体系，工程实施者却无法在这个体系中找到一个可以适用的软件过程模型。——MDA不讨论过程。
第八章第一节软件工程三个要素的价值。而所谓的三个要素则是：工具、方法与过程。它们实际上是相互作用的。例如“过程”问题，就既有实施过程的工具，也有相关的过程方法理论。工程的整体问题仍旧是“实现”。
第八章第二节讲了其实RUP是一个杂物箱。这主要是说RUP像杂物箱一样包容了前人在软件过程思想内容。你可能 从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者是一根钓杆……面对“软件开发”这样的一个需求，钓杆能有什么作用呢？只要你转化一下思维：钓竿可能带给你的团队精神上的激励。它就能转化成为生产力。至于RUP能不能被利用起来就要看你在“杂物箱”里取出东西后的辨识能力与组织能力了。
第八章第三节讲述了UML与甲骨文之间的异同。在你真的打算用甲骨文来写项目文档之前，请先明确UML与甲骨文之间的异同。UML 与甲骨文都是符号文字，都具有象形含义。然而这并不表明UML符号本身能表达多么丰富的含义。如果要象甲骨文一样用几代人、上千册的论著去解释它，那么UML图的价值也就只剩下象征性的意义了。而在使用UML图的时候应有相关的文字来描述，否则下一个阅读UML的人将面对的将是无异于甲骨文出土是的困境。
第八章第四节讲述了经营者与开发者的关系。经营者离开发者很远，反之亦然。一个完全不懂软件技术的老板。在EHM模型中，他所处于的位置在最右端，而开发者在最左端，在二者之间没有相同的关注界面( 关注点)。项目经理这个中间角色就有了一种使命：协调经营者与开发者之间的沟通
第八章第五节讲述了矛盾：实现目标与质量保障。在需求阶段我们就会面临“目标”的问题。然而( 在大多数时候) ，与此相反的是我们会在项目交付和试用时才会碰到客户在质量上的投诉。总之一件事，没有人会跳出来说：我们原本就错了。然而事实上可能真的出在源头：我们把目标定错了。
第八章第六节讲述恶劣枝节与细节。我们通常所说的细节，其实是对实施方法的一些有限量的描绘。比如“软件工艺”这个概念本身的提出，就是考究“细节问题”的。枝节是事实发展的次要的分枝，它不涉及行为本身，也不是对行为本身的考量。因此我在前面的文字中说到“跳出细节”，它本意是“跳出枝节”，细节只有做到何种程度的问题，而不并是关不关注。而在现实中大家却经常混淆这两个概念，所以作者提醒管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点回头。
第八章第七节讲述了我们做工程应该学会灵活，我们不能指望死读一本《软件工程》就会真正的做软件，而是要学会变通，因为死读一本书是无法做工程的，唯有学会变通，才能做好工程。