基本软件开发模型分析

软件开发模型主要有五个：

瀑布模型，

螺旋模型，

迭代模型，

增量模型，

敏捷模型。

具体我们来一个个看下：

一、瀑布模型
1.1 流程

 1.2 优缺点
优点：
强调开发的阶段性； 
强调早期计划及需求调查； 
强调产品测试。

缺点：
依赖于早期进行的唯一一次需求调查，不能适应需求的变化； 
由于是单一流程，开发中的经验教训不能反馈应用于本产品的过程；
风险往往迟至后期的测试阶段才显露，因而失去及早纠正的机会。

1.3 适用性
适用于需求稳定的项目，因为失去了纠正错误的最佳时机。
项目周期较短。需求是预知的，软件实现方法是成熟的；

二、螺旋模型
2.1 适用性
适合那些规模庞大、复杂度高、风险大的项目。这种迭代开发的模式给软件测试带来了新的要求，它不允许有一段独立的测试时间和阶段，测试必须跟随开发的迭代而迭代。

2.2 优缺点
优点：
强调严格的全过程风险管理。 
强调各开发阶段的质量。 
提供机会检讨项目是否有价值继续下去。

缺点：
一引入非常严格的风险识别、风险分析和风险控制，这对风险管理的技能水平
提出了很高的要求。这需要人员、资金和时间的投入。

三、增量模型
3.1 概述
增量模型也称渐增模型。使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。
增量模型把整个软件产品分解成许多个增量构件，分批地逐步向用户提交产品。

3.2 特点
把瀑布模型的顺序特征与快速原型法的迭代特征相结合;
将软件看作一系列相互联系的增量，在开发过程的各次迭代中，每次完成其中的一个增量。

3.3 优缺点
优点：
能在较短的时间内向用户提交可完成部分工作的产品;
将待开发的软件系统模块化，可以分批次地提交软件产品，使用户可以及时了解软件项目的进展;
以组件为单位进行开发降低了软件开发的风险。一个开发周期内的错误不会影响到整个软件系统;
开发顺序灵活。开发人员可以对组件的实现顺序进行优先级排序，先完成需求稳定的核心组件;
当组件的优先级发生变化时，还能及时地对实现顺序进行调整.

缺点：
由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大
优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性
如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别
开发的方法较适应于需求经常改变的软件开发过程

3.4 适用性
需求经常改变，开发人员数量不够的项目

四、迭代模型
4.1 概述
开发迭代是一次完整地经过所有工作流程的过程：（至少包括）需求工作流程、分析设计工作流程、实施工作流程和测试工作流程。实质上，迭代模型是类似小型的瀑布式项目。
每一个迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。

4.2 适用项目
适合于事先不能完整定义产品的所有需求，计划多期开发的项目。

4.3 优缺点
优点：
更适应需求的变化
降低了在一个增量上的开支风险
通过在开发早期就确定风险，能尽早来解决风险
加快了整个开发工作的进度

缺点：
需要高素质的项目管理者带领和高水平的开发团队

五、敏捷模型
5.1 来源
来源于敏捷宣言，强调：
个体与交互重于过程和工具
可用的软件重于完备的文档
客户协作重于合同谈判
响应变化重于遵循计划
在每对比对中，后者并非全无价值，更看重前者。

5.2 概述
敏捷开发以用户需求为核心，采用迭代、循序渐进的方法进行软件开发。它强调适应性而非预测性，强调以人为中心，而不是以流程为中心。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果经过测试，都具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成。在此过程中，软件一直处于可使用状态。敏捷开发的宣言就是尽早的、持续的交付有价值的软件来使客户满意。

5.3 原则
（1）通过早期和持续交付有价值的软件，实现客户满意度。欢迎不断变化的需求，（2）即使是在项目开发的后期。要善于利用需求变更，帮助客户获得竞争优势。
（3）不断交付可用的软件，周期通常是几周，越短越好。
（4）项目过程中，业务人员与开发人员必须在一起工作。
（5）项目必须围绕那些有内在动力的个人而建立，他们应该受到信任。
（6）面对面交谈是最好的沟通方式。
（7）可用性是衡量进度的主要指标。
（8）提倡可持续的开发，保持稳定的进展速度。
（9）不断关注技术是否优秀，设计是否良好。
（10）简单性至关重要，尽最大可能减少不必要的工作。
（11）最好的架构、要求和设计，来自团队内部自发的认识。
（12）团队要定期反思如何更有效，并相应地进行调整。

5.4 特点
1.快速迭代
采用复杂问题分解方法，对于小版本的需求、开发和测试更加简单快速。

2.让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。研讨组需要包括测试人员和开发者，这样可以更加轻松地定义可测试的需求，将需求分组并确定优先级。同时，该种方式也可充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。

3.编写可测试的需求文档
开始就要用“用户故事”（user story）的方法来编写需求文档。这种方法，可以让我们将注意力放在需求上，而不是解决方法和实施技术上。过早地提及技术实施方案，会降低对需求的注意力。

4.多沟通，尽量减少文档

任何项目中，沟通都是一个常见的问题。良好的沟通是敏捷开发的先决条件，强调高效沟通的重要性。团队要确保日常的交流，面对面沟通比邮件更有效。强调软件开发的产品是软件，而不是文档。文档是为软件开发服务的，而不是开发的主体。

5.响应变更胜过遵循计划
在敏捷方法开发软件过程中，接收需求变更，预料系统需求的变更，并快速响应变更，设计系统使之适应变更。主动适应变化，而不是预测

6.及早考虑测试
及早考虑测试在敏捷开发中很重要。传统软件开发中，测试用例大多都是最后才开始写，这导致过晚发现需求中存在的问题，使得改进成本过高。若较早地开始编写测试用例，在需求完成时，可以接受的测试用例也基本同时完成。

5.5 优缺点
优点：
是一种非常现实的软件开发方法。
促进团队合作和交叉培训。
功能可以迅速发展并得到证明。
资源要求最低。
适合固定或变化的要求
提供早期部分工作解决方案。
适用于稳定变化的环境的良好模型。
最小的规则，易于使用的文档。
在整体计划环境中实现并发开发和交付。
很少或根本不需要计划。
易于管理。
为开发人员提供灵活性。

缺点：
不适合处理复杂的依赖项。
可持续性，可维护性和可扩展性的风险更大。
总体规划，敏捷领导者和敏捷的PM实践是必须的，如果没有它，它将无法工作。
严格的交付管理决定了范围，要交付的功能以及满足截止日期的调整。
在很大程度上取决于客户互动，因此如果客户不清楚，团队可能会被推向错误的方向。
由于生成的文档最少，因此存在非常高的个人依赖性。
由于缺乏文档，技术转让给新的团队成员可能非常具有挑战性。