阅读这个书所需的知识基础应该超越了之前的任何一本书，目前很难领会精髓，只能先写一点感想了：
首先，实际软件开发中有很多变数，开发者会犯错，环境也会改变，客户也可能犯错，因此就有各种各样的模型用以减小变数带来的损失。
1.首先是进化树模型，它等价与增量-迭代模型，可以理解为最终结果是由不断添加组件所组成的（增量），而每次添加组件的过程中需要不断优化，更新组件（迭代）。每个增量与迭代都拥有属于自己的测试，设计，实现等阶段，而每次迭代过程不必拥有每个阶段，但一定拥有其中的一部分。
目前我认为适用性最强的就是增量-迭代模型，这个模型可以将错误细化到最小的迭代过程中，从而限制其造成的危害。而增量-迭代模型也非常符合我们面向对象的编程思想，其中每个增量都是一个对象，拥有其对外的接口，增量内部的迭代或错误对外部的影响是较小的。
2.瀑布模型：瀑布模型具有非常多的成功案例，其方法内核已经非常稳定，同时由文档驱动也赋予了其一定的严谨性。
但有一个非常致命的问题：瀑布模型的客户在最初可能收到一份根本看不懂的专业文档，而一般情况下客户会同意这个不一定合乎自己需求的开发，从而导致最终结果偏离用户目标（这就是非常大的损失了）。
3.快速原型生命周期模型：这个模型的使用者会先开发一个小的demo，使开发团队摸清需求，同时也可以让用户评估方向是否偏离需要，这样一来就大大减少了最终产品偏离需求的可能。但其实快速原型生命周期模型中存在这与敏捷过程相同的问题，即如果一个缺乏经验的团队面对一个大的项目，能够开发一个demo并不意味着可以胜任整个项目
4.开源生命周期模型：其实书中有一句话非常好：任何开源项目最终都会趋于不可维护。这其实说明了开源项目的成功是不可复制的，因此在面向客户需求时这种模型显然时不稳妥的。
5.敏捷过程：这应该是一个非常大胆的尝试，他的内核可能不在于对开发流程的规划，而在于强调开发组成员间的配合，这种方法强调时间，即期限到来时必须交付给用户一个版本。这样做有很多好处：用户不会在期限到来前随意修改计划（期限一般比较短），用户可以有更多的时间适应产品，开发组可以快速响应用户需求。但是就如书中所说，这种方法还过于年轻，目前无法考察其有效性，而且有人认为这种方式不能胜任较为大型的开发。即便如此，敏捷过程中的一些思想或许还是可以为我们所用。
6.同步稳定生命周期模型
这个没看太明白它的特点，再加上比较短，直接上图
7.螺旋生命周期模型：这是一种风险驱动模型，它的优势很明显，就是可以实时控制风险。但是问题在于不是所有风险都是可以预估，或者可以正确预估的，同时预估风险也会造成一些开销，这对于小型开发显然是不合理的。另一方面如果我们面向内部开发，那么我们可以灵活控制风险，随时暂停项目，但如果我们是面向客户开发，暂停项目可能会带来法律上的争端。
最后贴上书中的对比：