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