为什么说分解与抽象是软件设计的核心思想?为什么要为变更而设计?
分解与抽象很重要，但是还谈不上核心思想。
要为变更而设计只是适合某些类型的软件，而不是放之四海而皆准的铁律。
你应该问核心思想是什么，而不是为什么它是
我写了一本书，核心思想是xx=yy，你问我为什么它是？
分解与抽象不是软件设计的核心思想，而是只要是想要解决问题，你必须先分解问题，抽象问题
这是人类思考的底层逻辑
至于为什么要为了变更而设计，那你可以试试设计的时候别考虑变更，看一旦要变更的时候会发生什么
瀑布模型认为，软件开发是一个阶段化的精确的过程。就像要制造一艘航空母舰，首先需要知道航空母舰的参数（长 、 宽 、 高 、 排水量 、 航速等）。在这些参数的技术上需要对航空母舰进行设计，设计包括总体设计和详细设计。只有设计得一清二楚的图纸才能交付施工，否则造出的零件肯定拼装不到一起。制造完毕后，要把这些零件一个一个地拼装起来，拼装成发动机 、 船舱等部分，并检查这些部分是否符合设计标准，这就是集成测试。最后，把各个部分组合在一起，造出一艘巨大的航母。这个过程正如图 1 中的描述，软件要经过需求分析 、 总体设计 、 详细设计 、 编码 、 调试 、 集成测试和系统测试阶段才能够被准确地实现。在图 1 中，每一阶段都有回到前一阶段的反馈线，这指的是，在软件开发中当在后续阶段发现缺陷的时候，可以把这个缺陷反馈到上一阶段进行修正。
从图 1 中可以看出瀑布模型的一个重要特点：软件开发的阶段划分是明确的，一个阶段到下一个阶段有明显的界线。在每个阶段结束后，都会有固定的文档或源程序流入下一阶段。在需求分析阶段结束后，需要有明确的描述软件需求的文档；总体设计结束后，需要有描述软件总体结构的文档；详细设计结束后，需要有可以用来编码的详细设计文档；而编码结束后，代码本身被作为文档流到下一个阶段。因此也称瀑布模型是面向文档的软件开发模型。
当软件需求明确 、 稳定时，可以采用瀑布模型按部就班地开发软件，当软件需求不明确或变动剧烈时，瀑布模型中往往要到测试阶段才会暴露出需求的缺陷，造成后期修改代价太大，难以控制开发的风险。
分解和抽象被认为是软件设计的核心思想，因为它们能够将复杂的问题分解成更小、更简单的组成部分，并把它们抽象成更通用、更可复用的模块。这使得软件开发更易于管理，更容易实现变更和升级，并减少了出现错误的可能性。其中，分解可以通过模块化、函数化等方式实现，抽象可以通过面向对象、泛型等方式实现。通过分解和抽象，我们可以更好地管理和维护软件系统，提高代码的可读性、可重用性和可扩展性。
软件设计需要考虑变更因素并作出设计，是因为软件的生命周期往往很长，需求和技术也在不断地变化和发展。如果在设计的时候没有考虑可能的变更因素，那么当需求变化时，需要改动的代码就会非常多，甚至需要全部重构，这会带来巨大的后果和成本。而如果考虑了变更因素，设计的代码就更容易被修改和维护，同时也更能够适应未来的变化。
对于案例1，我会基于以上分析，使用模块化、面向对象等方式进行软件设计，同时在设计的时候考虑到未来可能的需求变化，将系统设计得易于修改和维护。在预估工时时，我会综合考虑功能需求、性能需求、环境需求、用户界面需求等因素，再乘以适当的复杂度系数和原创度系数，从而得出大概需要374.4人天的工时和599040元的费用。最适合选择小型外包工作室来开发这个系统。
对于案例2，由于复杂度和原创度要求比较低，我会使用简单的增删改查方式进行设计，同时注意系统的可扩展性。在预估工时时，我会根据模块数量、复杂度系数等因素，得出大概需要28.8人天的工时和14400元的费用。在选择开发公司时，也应该选择符合项目规模和复杂度的外包公司。
对于案例3，由于系统复杂度和原创度都非常高，需要考虑大量的变更因素，我会在设计阶段就采用高度模块化、面向对象等方式，同时将DSL等技术应用到软件开发中，将代码设计得易于修改和维护。在预估工时时，我会根据模块数量、复杂度系数和原创度系数等因素，得出需要82944人天的工时和207360000元的费用。在选择开发公司时，应该选择有能力完成这样复杂项目的专业软件开发公司。