目录 |
软件过程模型是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、程序设计和测试等阶段，有时也包括维护阶段。软件过程模型能够清晰、直观地表达软件开发的全过程，明确规定要完成的主要活动和任务，用来作为项目实施的基础。对于不同的软件项目，可以采用不同的过程模型来指导项目的实施。
20世纪70年代Winston Royce提出了软件生命周期中著名的模型——“瀑布模型”，直到20世纪80年代初，它一直是唯一被广泛采用的软件开发模型。瀑布模型将软件生命周期划分为制订计划、需求分析、软件体系结构设计、构件设计、程序程序设计、软件测试和运行维护等基本活动，并且规定了它们自上而下、相互衔接的固定次序。即在瀑布模型中，首先是对需求进行仔细的分析并制订一份功能／结构说明，接着是体系结构设计，构件设计，然后才着手程序设计。程序设计结束后进行测试，最后才是软件的发布。瀑布模型强调文档的作用，要求每一个阶段都有明确的文档产出，并要求每个阶段都要仔细验证，当评审通过，且相关的产出物都已成为基线后才能够进入到下一个阶段。
任何项目都会涉及一定的风险，虽然不可能预知所有的风险，但是如果能在生命周期中尽早发现并避免尽量多的风险，那么项目的计划自然就更趋精确。迭代模型和瀑布模型的最大的差别就在于风险的暴露时间上。在瀑布模型中，文档是主体，很多的问题要到最后才暴露出来，为了解决这些问题就会付出巨大的代价。因此，早在20世纪50年代末期，软件领域中就出现了迭代模型。早期的迭代过程被描述为“分段模型(Stagewise model)”，其应用背景是Benington领导的美国空军SAGE项目。
与迭代模型容易混淆的是增量模型。在增量模型中，软件系统被看作是一系列的增量来进行设计、实现、测试和集成，每一个增量是由多个相互作用的具有特定功能的模块构成。
增量模型在各个阶段并不需要交付一个可运行的完整产品，而只要交付满足客户需求的一个子集的可运行产品。开发人员逐个对各个增量进行交付，这样可以使软件的开发较好地适应需求和环境的变化，客户也能够不断地看到所开发的系统，从而降低开发的风险。
1988年，Barry Boehm正式提出了软件生命周期的“螺旋模型”，它将瀑布模型和快速原型模型结合起来，强调了其他模型中所忽视的风险分析，特别适合于开发大型复杂的软件系统。
螺旋模型采用一种周期性的方法来进行系统开发，基本做法是以进化的开发方式为中心，在每个项目阶段使用瀑布模型法，在瀑布模型的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制。
由于用户对需求往往具有模糊性和变更性，为了能够让用户确定真正的需求，在开发的初始阶段，构造一个统一的软件系统原型是有必要的。
原型法的基本思想是确定需求策略，对用户需求进行抽取、描述和求精。它快速地、选代地建立最终系统工作模型，对问题定义采用启发的方式，由用户作出响应。具体做法是，在获取一组基本的需求之后，利用一些比较高级的软件工具可视化地开发环境，快速地建立一个目标系统的最初版本，并把它交给用户进行试用，发现其中的不足，再进行补充和修改，产生新的版本。经过这样一个反复补充和修改过程，直到用户满意为止。
统一过程(Unified Process，UP)是一种现代的软件开发过程模型，它的历史最早可以回溯到1967的Ericsson方法。UP把复杂系统构造为一组相互联系的功能块，小的功能块相连形成更大的功能块以构造出完整的系统。尽管对于只触及到系统的部分的任何成员来说，整个系统可能是不可理解的，但是当系统被分成更小的组件时，人们可以理解每个组件提供的服务(即组件的接口)以及这些组件是如何协调工作的。或者可以说，系统被划分为具有较大的功能的子系统，每个子系统又由具有更小的功能块(组件)所实现。
UP方法是“分而治之”的思想和现在熟知的基于组件的开发(Component—Based Development，CBD)方法的有机结合。
统一过程模型是一种以“用例和风险驱动、以体系结构为核心、迭代及增量”为特征的软件过程框架，一般由UML方法和工具支持。用例是捕获需求的方法，因此，也可以说UP是需求驱动的。
UP的另一个驱动就是风险，因为如果你不主动预测和防范风险，风险就会主动攻击你。UP需要对软件开发中的风险进行分析、预测并关注软件的构造。
在基于组件的开发中，体系结构描述了系统的整体框架：如何把系统划分成组件以及这些组件如何进行交互和部署在硬件上。UP方法实际上就是开发和演进一个健壮的系统体系结构。
此外，UP也是迭代和增量的。在UP的迭代构建中，每个迭代包括五个核心工作流：
需求R——捕捉系统应该做什么。
分析A——精化和结构化需求。
设计D——基于系统体系结构来实现需求。
实现I——构造软件系统。
测试T——验证实现是否达到预期效果。