|
|
|
软件过程模型习惯上也称为软件开发模型，它是软件开发全部过程、活动和任务的结构框架。典型的软件过程模型有瀑布模型、增量模型、演化模型（原型模型、螺旋模型）、喷泉模型、基于构件的开发模型和形式化方法模型等。
|
|
|
|
|
|
该模型给出了软件生存周期各阶段的固定顺序，上一阶段完成后才能进入到下一阶段，整个过程就像流水下泻，故称为瀑布模型。瀑布模型为软件的开发和维护提供一种有效的管理模式，对保证软件产品的质量有重要的作用。但是这种模型缺乏灵活性，无法通过开发活动来澄清本来不够明确的需求，这将可能导致直到软件开发完成时才发现所开发的软件并非都是用户所需要的，此时必须付出高额的代价才能纠正这一偏差。
|
|
|
|
|
|
增量模型融合了瀑布模型的基本成分和原型实现的迭代特征，它假设可以将需求分段为一系列增量产品，每一增量可以分别开发。该模型采用随着日程时间的进展而交错的线性序列，每一个线性序列产生软件的一个可发布的"增量"。当使用增量模型时，第1个增量往往是核心的产品。客户对每个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。增量模型强调每一个增量均发布一个可操作的产品。
|
|
|
|
|
|
在获取一组基本的需求后，通过快速分析构造出该软件的一个初始可运行版本，这个初始的软件通常称为原型，然后根据用户在使用原型的过程中提出的意见和建议对原型进行改进，获得原型的新版本。重复这一过程，最终可得到令用户满意的软件产品。该模型是用于对软件需求缺乏准确认识的情况。
|
|
|
|
（1）原型模型。原型是预期系统的一个可执行版本，反映了系统性质的一个选定的子集。一个原型不必满足目标软件的所有约束，其目的是能快速、低成本地构建原型。当然，能够采用原型方法是因为开发工具的快速发展，使得能够迅速地开发出一个让用户看得见、摸得着的系统框架。这样，对于计算机不是很熟的用户就可以根据这个框架提出自己的需求。开发原型系统首先确定用户需求，开发初始原型，然后征求用户对初始原型的改进意见，并根据意见修改原型。
|
|
|
|
（2）螺旋模型。将瀑布模型和演化模型相结合就成了螺旋模型。这种模型综合了瀑布模型和演化模型的优点，并增加了风险分析。螺旋模型包括四个方面的活动：制订计划、风险分析、实施工程、客户评估。
|
|
|
|
|
|
喷泉模型主要用于描述面向对象的开发过程。该模型具有迭代和无间隙特性。迭代意味着模型中的开发活动常常需要重复多次，在迭代中不断完善软件系统。无间隙是指在开发活动之间不存在明显的边界，允许开发活动交叉、迭代地进行。
|
|
|
|
|
|
基于构件的开发是指利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品（Commercial Off-The-Shelf，COTS）软件构件。基于构件的开发模型具有许多螺旋模型的特点，它本质上是演化模型，需要以迭代方式构建软件。其不同之处在于，基于构件的开发模型采用预先打包的软件构件开发应用系统。
|
|
|
|
|
|
形式化方法是建立在严格数学基础上的一种软件开发方法，其主要活动是生成计算机软件形式化的数学规格说明。
|
|
|
|
形式化方法用严格的数学语言和语义描述功能规约和设计规约，通过数学的分析和推导，易于发现需求的歧义性、不完整性和不一致性，易于对分析模型、设计模型和程序进行验证。通过数学的演算，使得从形式化功能规约到形式化设计规约，以及从形式化设计规约到程序代码的转换成为可能。这种方法的一个变形是净室软件工程。
|
|
|
|
|
|
统一过程（UP）模型是一种"用例和风险驱动，以架构为中心，迭代并且增量"的开发过程，由UML方法和工具支持。迭代的意思是将整个软件开发项目划分为许多个小的"袖珍项目"，每个"袖珍项目"都包含正常软件项目的所有元素，如计划、分析和设计、构造、集成和测试以及内部和外部发布。
|
|
|
|
统一过程包括5个阶段，即初始阶段、精化阶段、构建阶段、移交阶段、产生阶段。前4个技术阶段由主要里程碑所终止。
|
|
|
|
|
|
|
|
|
|
|
|
统一过程的典型代表是RUP（Rational Unified Process）。RUP是UP的商业扩展，完全兼容UP，但比UP更完整、更详细。
|
|
|
|
|
|
敏捷开发的总体目标是通过"尽可能早地、持续地对有价值的软件的交付"使客户满意。
|
|
|
|
（1）极限编程（XP）。XP是一种轻量级（敏捷）、高效、低风险、柔性、可预测的、科学的软件开发方式。它由价值观、原则、实践和行为4个部分组成，彼此相互依赖、关联，并通过行为贯穿于整个生存周期。
|
|
|
|
|
|
5个原则，包括快速反馈、简单性假设、逐步修改、提倡更改和优质工作。
|
|
|
|
12个最佳实践，包括计划游戏（快速制订计划、随着细节的不断变化而完善）、小型发布（系统的设计要能够尽可能早地交付）、隐喻（找到合适的比喻传达信息）、简单设计（只处理当前的需求，使设计保持简单）、测试先行（先写测试代码，然后再编写程序）、重构（重新审视需求和设计，重新明确地描述它们以符合新的和现有的需求）、结队编程、集体代码所有制、持续集成（可以按日甚至按小时为客户提供可运行的版本）、每周工作40h、现场客户和编码标准。
|
|
|
|
|
|
|
|
|
