总结一下经常可以见到的系统开发周期模型。
在过去的几年里，可以很奇葩的碰到类似于“创业项目库”这种需求非常明确，工作量十分可控，对质量要求比较低，业务建模比较easy，功能构成比较少的“面子项目”。类似于这种项目，采用传统意义上的瀑布模型就非常合适了，如果范围控制和风险控制做的比较好的话，真的如同一个瀑布一样，会“飞流直下三千尺”，直接将项目送到客户的小机上，部署运行，大家欢乐的拿到绩效奖金，回家happy去了。
但是仅仅注重“面子”的项目很难碰到几次，另一方面，即便是“面子型”的项目，也应当极其重视质量环节。项目管理的几个要素：质量，成本，时间，范围。质量是项目最重要的一环，如果丧失了质量，可以说项目产品就变成了无根之树，空中楼阁。所以，加强质量的把控是非常重要的，也需要对每一个阶段进行质量方面的控制，因此，V模型就是这样一种将开发过程与验证过程想对应的一种对称型的结构。
在项目实践中，用户的需求总是随着项目进展而更加明确，控制用户的需求变得非常的重要。为了让用户能在项目的起始阶段就深入的对自己的需求有一个明确的理解，原型就变得非常的重要，我们经常在开发中看到的LOW-FI的页面原型、其他类似项目的DEMO就算这种类型，用户对将来的产品有了直观的了解。建立在这种基础上的分析开发，会减少很多后面流程中可能出现的风险。在瀑布模型以及V模型当中，在需求分析阶段采用原型化，是目前非常有效甚至是必须要采用的手段。
现在的软件项目越来越大，同项目可能由相互联系的若干个子系统构成的，这样仅凭开发一个模型或者多个模型是满足不了项目对于多方面的要求，于是就衍生出了螺旋模型，螺旋模型适合于大型的软件的原因是，它更加注重风险的控制，强调风险的识别、风险的分析、以及风险的消除。
工作的后几年里，经常会按照Sprint（冲刺短跑）为周期的进行开发。这种敏捷的方式，是属于迭代式开发的一种实现。所谓迭代式模型就是在项目的每一个小的阶段中，都会执行一个传统的、完整的串行过程，执行一次就是一次迭代，每次迭代都可能会包含需求分析、设计、编码、测试等其中的全部或者部分活动。
这样就对软件的四种开发模型有了简单的了解：瀑布模型，V模型，原型化模型、螺旋模型、迭代模型。
下面对几个开发模型，结合理论逐一分析。
1.迭代模型
迭代模型，摒弃了传统的需求分析，设计，编码，测试的流程，而是将整个生命周期变成若干个冲刺（Sprint）阶段，而每一个阶段都是由以上若干或者全部传统的流程组成，在每一个阶段中，都会包含下面四个阶段：初始阶段，细化阶段，构建阶段，交付阶段。在初始阶段中，确认本次冲刺的范围，边界，系统选择的架构，计划，以及所需要的资源等信息。在细化阶段中，对问题进行建域，创建开发案例，创建模板以及准备工具等。在构建阶段的主要任务就是完成构建的开发并且进行测试，将完成的构建集成为产品，并且测试所有的功能（CI）。在交付阶段，主要是完成本次冲刺，将软件产品交付给相关的干系人。
2.螺旋模型
螺旋模型，尤其重视风险分析阶段，特别适用于庞大并且复杂，非常高风险的项目。通常螺旋模型由四个阶段组成：制定计划、风险分析、实施工程和客户评估。螺旋模型中，发布的第一个模型甚至可能是没有任何产出的，可能仅仅是纸上谈兵的一个目标，但是随着一次次的交付，每一个版本都会朝着固定的目标迈进，最终得到一个更加完善的版本。
3.原型化模型
原型化模型第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。在实际的项目过程中，借助于组织过程资产以及快速模型软件，一般在需求分析的时候，就可以建立一些简单的原型，例如在第一家YH公司中，因为是“行业软件提供商”，所以拥有各个地域的行业解决软件方案，惯用的伎俩就是将其他地市的项目拿到本次项目实施地，作为原型化模型。原型化模型是极具意义的项目实践。
4.V模型
V模型从整体上看起来，就是一个V字型的结构，由左右两边组成。左边的下划线分别代表了需求分析、概要设计、详细设计、编码。右边的上划线代表了单元测试、集成测试、系统测试与验收测试。看起来V模型就是一个对称的结构，它的重要意义在于，非常明确的表明了测试过程中存在的不同的级别，并且非常清晰的描述了这些测试阶段和开发阶段的对应关系。
5.瀑布模型
瀑布模型是一个特别经典，甚至有点老套的周期模型，一般情况下将其分为计划、需求分析、概要设计、详细设计、编码以及单元测试、测试、运行维护等几个阶段。瀑布模型的周期是环环相扣的。每个周期中交互点都是一个里程碑，上一个周期的结束需要输出本次活动的工作结果，本次的活动的工作结果将会作为下一个周期的输入。这样，当某一个阶段出现了不可控的问题的时候，就会导致返工，返回到上一个阶段，甚至会延迟下一个阶段。