目录
1. 边做边改模型(Build-and-Fix-Model)
4. 快速原型模型(Rapid-Prototype-Model)
5.2 迭代模型(Stagewise-Model)(迭代增量式开发/迭代进化式开发)
8. 敏捷开发模型(Agile-Development-Model)
1. 边做边改模型(Build-and-Fix-Model)
在这种模型中,既没有规格说明,也没有经过设计,软件随着客户的需要一次又一次地不断被修改。在这个模型中,开发人员拿到项目立即根据需求编写程序,调试通过后生成软件的第一个版本。在提供给用户使用后,如果程序出现错误,或者用户提出新的要求,开发人员重新修改代码,直到用户和测试等等满意为止。
优点:
这是一种类似作坊的开发方式,边做边改模型的优点毫无疑问就是前期出成效快。
缺点:
对编写逻辑不需要太严谨的小程序来说还可以对付得过去,但这种方法对任何规模的开发来说都是不能令人满意的。
原因在于
- 缺少规划和设计环节,软件的结构随着不断的修改越来越糟,导致无法继续修改;
- 忽略需求环节,给软件开发带来很大的风险;
- 没有考虑测试和程序的可维护性,也没有任何文档,软件的维护十分困难。
2. 瀑布模式(Waterfall-Model)
特点:
- 严格按照需求 ->分析->设计->编码->测试的阶段进行
- 阶段间具有顺序性和依赖性:
-
- 前一阶段完成后,才能开始后一阶段
- 前一阶段的输出文本为后一阶段的输入文本
- 适合于一些大型稳定的项目
- 推迟实现的观点
- 质量保证:
- 以质量为第一目标
- 每个阶段必须交付出合格的文档
- 对文档进行审核
优点:
- 可以保证整个软件产品较高的质量
- 保证缺陷能够提前的被发现和解决
- 可以保证系统在整体上的充分把握,使系统具备良好 的扩展性和可维护性
缺点:缺乏灵活性,太过线性理想化,不适合现代软件开发
- 前期就需要把需求做到最全。所以对于前期需求不明确,而又很难短时间明确清楚的项目则很难很好的利用瀑布模型。
- 瀑布模型强调的保证软件的质量,往往忽略人力,时间,资源等成本因素。对于中小型的项目,需求设计和开发人员往往在项 目开始后就会全部投入到项目中,而不是分阶段投入,因此采用瀑布模型会导致项目人力资源过多的闲置的情况
- 惧怕用户测试中的反馈,惧怕需求变更
- 每次需求发生变更都要从头再来
当一个新系统的开发存在多个完全不相关的独立需求的功能开发的时候,这个时候也可以选择将整个开发过程按独立的需求来分为多个小瀑布进行操作.这种方式的最大问题就是没有一个完全总体的设计,架构设计人员无法在洞悉了所有需求后从系统的可扩展性,复用等方面总体规划.
BTW:
很多人往往会以进度约束而不选择瀑布模型,这往往是一个错误的观点.导致这种情况的一个关键因素往往是概念需求阶段人力不足.因此在概念需求阶段人力能 够得到充分保证的情况下,瀑布模型和迭代模型在开发周期上并不会存在太大的差别.反而是很多项目对于迭代或敏捷模型用不好,为了赶进度在前期需求不明确, 没有经过一个总体的架构设计情况下就开始编码,后期出现大量的返工而严重影响进度.
在项目管理中有一种压缩进度的方法叫赶工,因此瀑布模型的另外改进处就在适当的重叠各个阶段过程,达到资源的有效利用.比如我们通过讨论,会议确定的实现方式就可以开始执导下一个阶段的工作而不一定完全等到相关的交付物文档化出来.
3. 螺旋模型(Spiral-Model)
1988年,巴利·玻姆(Barry Boehm)正式发表了软件系统开发的“螺旋模型”,它将瀑布模型和快速原型模型结合起来,强调了其他模型所忽视的风险分析,特别适合于大型复杂的系统。
螺旋模型沿着螺线进行若干次迭代,图中的四个象限代表了以下活动:
(1)制定计划:确定软件目标,选定实施方案,弄清项目开发的限制条件;
(2)风险分析:分析评估所选方案,考虑如何识别和消除风险;
(3)实施工程:实施软件开发和验证;
(4)