上一篇阅读笔记中简单提了《设计原本》的简述以及对“设计”这一概念的理解。现在开始谈本书提及的第一个模型——理性模型。
理性模型一般是工程师们在设计过程中常用的，清晰但隐含的模型，是一个关于有序过程的有序模型，是工程师的构思过程。书中通过“海滨小屋”的例子加以说明：该工程的目标是建立一个海滨小屋，必要条件是可以抵御飓风来袭，且容量要足够大。之后是从效用函数的角度对设计进行优化，通俗点说就是权重，比如这个海滨小屋设计上需要更大的窗户面积（可以看到更多的景色），那么在设计上墙与窗户的占比就需要斟酌一下，此外还有电源安放的问题，种种构成了“效用函数”，从数学的角度去初步优化设计。然而一个设计不可能不切实际，因此有了约束问题。有来自环境的约束（可施工面积不大），人为约束（甲方希望在XX日之前完成）等等。此外，还有资源分配，预算的问题。对建造有一定了解的同学都明白预算的概念，这些又会对设计造成一定的影响力。结合上述的设计因素考虑，就像是一个岔路口，这条路不行就换另外一条，因此书中将其称为“设计树”——由单一的设计决策通过各种因素的影响演变成树形决策，最后形成了设计空间。而理性模型从一开始就参与进来，包括设计空间的形成以及后续在设计空间的探索。探索过程更像是穷举法，去寻找最优解，在一个方法走向死胡同的时候会进行回溯，逐渐向正确答案靠拢。再通俗一点说，理性模型将“设计”这个说起来就很朦胧的行为精确到每一步，就是刚才说的“海滨小屋”的设计历程——目标，条件，影响因素，设计树，探索。
将设计过程建模为一种系统化，按部就班的过程的概念似乎是来源于德国机械工程社团，后来再加上其他人的补充改善，最后出现了理性模型。这个模型的优势在于为设计项目的规划提供了清晰步骤，改进团队内部的沟通（都明白要干啥），然而现在我们所常用的模型里（瀑布，螺旋....）似乎没有它的身影。因为理性模型是一个理想化的东西。实际设计过程中，我们在开发初期并不一定能明确知道要什么，这时候也就出现了烦人的甲方——“我觉得这里要改一下”，“这个地方我不想要这个”，“再加一些功能”。。。也许一开始作为开发者都埋怨甲方为什么不把要求说清楚，作者同样埋怨过，但后来他想通了：“我为客户提供最有效的服务，是帮助他决定什么是他真正想要的”。因此在设计过程中往往是边设计边探索，那么理性模型中所谓的设计决策就不是真正的决策，称它为“暂定方案”更合理一些。同时，边设计边探索也会让约束条件等等不断地变更，效用函数更是一个未知量，因此“理性模型是理想化的”这一观点一点没错。然而理性模型真的是一文不值么？显然不是，就像是其他领域中摸索出来的第一个概念，它不一定是正确的，但一定会对后续的理论造成影响，通过理性模型也衍生出了其他设计模型，比如瀑布模型。
作者在过程模型上谈了很多，而过程模型的考量是在参与工作之后，那么工作之前呢——需求。有的甲方需求简直就是天马行空，畅谈了一切美好的东西，但那是不切实际的，而随着现在技术的高速发展，遇到懂行的甲方还好一些，要是甲方对技术概念没有一个明确的界限认知的话，很容易出现需求激增，有时候会出现设计团队干的活儿与获得的报酬价值不对等，这个现象是要抵制的。针对这个现象，作者抛出了那些百年建筑的设计过程：甲方与施工方有着紧密的信任关系（合同），全程都保持着联系，正因为对工程有着足够的了解，因此不会出现“非人”的需求。这样的合同模型或许可以给软件设计工作带来一些启发，然而让甲方全程保持对工程的联系显然是不现实的，应该有更适合IT领域的解决方案。
上述的“合同”是一个重要的概念，因为它是评定一个模型好坏的关键因素，作者认为一个好的设计过程模型，理想地说能满足：强调设计需求的递进式探索和演化；易于接受理解，印象深刻；促进合同的达成。不求能够完美达成这些要求，但也要尽可能地往这方面靠，因此作者又讨论了几个模型：
共同演化模型：此模型提出者的想法是将问题空间与解空间共同演化，在演化过程中信息在两个空间之间流动。图示如下：
集市模型：这个模型的典型代表就是Linux系统，该模型顾名思义，就像集市一样获取自己想要的东西，而集市模型的使用条件要更加苛刻一些，这里牵扯到礼物-威望经济学，这种经济学通俗点说就是我写了一个很强大的软件，之后将它无偿分享出去，借以提升我在这个社区中的威望。显然程序员的圈子内share是个很不错的行为，大多都提倡开源，然而想做是一回事，能做是另一回事，这种行为需要开发者有其他经济来源支持自己，否则无偿分享很快会把自己饿死的。此外在一些场合下，这种“开源”思想并不受用，对应的保密措施才是必须品。
螺旋模型：这个模型都很熟悉，一些企业开发就用这种模型来工作。它强调的是原型方法，主张在一个可以跑起来的原型称为可能之前，就从用户界面原型和用户测试起步。