经典软件过程模型的特点（瀑布模型、增量模型、演化模型、统一过程模型）
一、软件过程
软件过程的概念；经典软件过程模型的特点（瀑布模型、增量模型、演化模型、统一过程模型）；过程评估与CMM/CMMI的基本概念；敏捷宣言与敏捷过程的特点
01：瀑布模型（Waterfall Model）
1970年Winston Royce提出了著名的"瀑布模型"，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。 瀑布模型将软件生命周期划分为制定计划、需求分析、软件设计、程序编写、软件测试和运行维护等六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，几乎被业界抛弃，其主要问题在于：
（1） 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
（2） 由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
（3） 早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
我们应该认识到，"线性"是人们最容易掌握并能熟练应用的思想方法。当人们碰到一个复杂的"非线性"问题时，总是千方百计地将其分解或转化为一系列简单的线性问题，然后逐个解决。一个软件系统的整体可能是复杂的，而单个子程序总是简单的，可以用线性的方式来实现，否则干活就太累了。线性是一种简洁，简洁就是美。当我们领会了线性的精神，就不要再呆板地套用线性模型的外表，而应该用活它。例如增量模型实质就是分段的线性模型，螺旋模型则是接连的弯曲了的线性模型，在其它模型中也能够找到线性模型的影子
02：增量模型（Incremental Model）
又称演化模型。与建造大厦相同，软件也是一步一步建造起来的。在增量模型中，软件被作为一系列的增量构件来设计、实现、集成和测试，每一个构件是由多种相互作用的模块所形成的提供特定功能的代码片段构成. 增量模型在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。整个产品被分解成若干个构件，开发人员逐个构件地交付产品，这样做的好处是软件开发可以较好地适应变化，客户可以不断地看到所开发的软件，从而降低开发风险。但是，增量模型也存在以下缺陷：
（1） 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
（2） 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。
在使用增量模型时，第一个增量往往是实现基本需求的核心产品。核心产品交付用户使用后，经过评价形成下一个增量的开发计划，它包括对核心产品的修改和一些新功能的发布。这个过程在每个增量发布后不断重复，直到产生最终的完善产品。
例如，使用增量模型开发字处理软件。可以考虑，第一个增量发布基本的文件管理、编辑和文档生成功能，第二个增量发布更加完善的编辑和文档生成功能，第三个增量实现拼写和文法检查功能，第四个增量完成高级的页面布局功能
03：
http://blog.sina.com.cn/s/blog_6a06f1b7010121hz.html
统一过程（RUP/UP，Rational Unified Process）是一种以用例驱动、以体系结构为核心、迭代及增量的软件过程模型，由UML方法和工具支持，广泛应用于各类面向对象项目。RUP是由Rational公司开发并维护，和一系列软件开发工具紧密集成。RUP蕴含了大量优秀的实践方法，如：迭代式软件开发、需求管理、基于构件的构架应用、建立可视化的软件模型、软件质量验证、软件变更控制等。
如上图所示，RUP是按照二维结构进行组织的。其中横轴按时间组织，显示RUP的动态特征，通过迭代式软件开发的周期、阶段、迭代和里程碑等动态信息表示；纵轴按内容组织，显示RUP的静态特征，通过过程的构建、活动、工作流、产品和角色等静态概念来描述系统。
RUP的静态结构包括6个核心工作流（业务建模、需求、分析设计、实现、测试、部署）和3个核心支持工作流（配置与变更管理、项目管理和环境）。
业务建模工作流产生五个工作产品，即商业逻辑建模（USE CASE）(ROSE)、业务需求说明书（MS WORD）、专业词汇表（英汉对照）（MS WORD）、风险说明（MS WORD）、复审说明书。需求工作流为了确保开发人员构建正确的系统，要了解目标组织的结构及机制；要明确目标组织中当前存在的问题并确定改进的可能性；确保客户、最终用户和开发人员就目标组织达成共识；导出支持目标组织所需的系统需求，建立系统需求模型：用例图（表示系统的功能）。分析设计工作流将系统需求转换为未来系统的设计，逐步开放强壮的系统架构，使设计适合于实施环境，为提高性能而进行设计。实施工作流要定义代码结构，以构件的方式实施类和对象，对已开发的构件按类和单元来测试，并且将结果集成到可执行的系统中。测试仅限于对各个类进行单元测试。测试工作流包括核实对象之间的交互，核实软件的所有构件是否正确集成，核实所有需求是否已经正确实施，确定缺陷，确保在部署软件之前将风险降到最低。
RUP模型采用迭代开发，通过多次执行不同的开发工作流，逐步确定一部分需求分析和风险，在设计、实现并确认这部分后，再去做下一部分的需求分析、设计、实现和确认工作，依次进行下去，直到整个项目完成，这样能够在逐步集成中更好的理解需求，构建一个健壮的体系结构。