跳到主要内容

软件过程模型

概述

软件过程模型(有时也称为软件开发生命周期或SDLC模型)是软件过程的简化表示。每个过程模型都是从一个特定的侧面表现软件过程,所以只提供过程的部分信息。

例如,过程模型描述了活动和它们的顺序,但是可能表现不出人们在这些活动中的角色。

过程模型是软件过程的高层和抽象描述,能用于解释不同的软件开发方法。可以将它们视为一种过程框架,可以通过扩展和调整来创建更加特定的软件工程过程。

瀑布模型(SDLC)

瀑布模型是一个经典的软件生命周期模型,一般将软件开发分为:

  • 可行性分析(计划)
  • 需求分析
  • 软件设计(概要设计详细设计
  • 编码(含单元测试
  • 集成与系统测试
  • 运行维护

特点

  1. 上一项开发活动接受该项活动的工作对象作为输入
  2. 利用这一输入,实施该项活动应完成的工作内容
  3. 给出该项活动的工作成果,作为输出传给下一项开发活动
  4. 对该项活动的实施工作成果进行评审,若其工作成果得到确认,则继续进行下一项开发活动;否则返回前一项,甚至更前项的活动,尽量减少多个阶段间的反复,以相对来说较小的费用来开发软件

螺旋模型

螺旋模型是一个 演化软件过程模型,将原型实现的迭代特征与瀑布模型中控制的和系统化的方面结合起来。在螺旋模型中,软件开发是一系列的增量发布 特点

  • 开发过程具有周期性重复的螺旋线状,四个象限分别标志每个周期所划分的四阶段:制订计划风险分析实施工程客户评估
  • 螺旋模型强调了风险分析,特别 适用于庞大而复杂的、高风险的系统

V模型

V模型从整体上看起来,就是一个V字型的结构,由左右两边组成。左边的下画线分别代表了需求分析、概要设计、详细设计、编码;右边的上画线代表了单元测试、集成测试、系统测试与验收测试。 特点

  1. 单元测试的主要目的是针对编码过程中可能存在的各种错误
  2. 集成测试的主要目的是针对详细设计中可能存在的问题
  3. 系统测试主要针对概要设计,检查系统作为一个整体是否有效地得到运行
  4. 验收测试通常由业务专家或者用户进行,以确认产品能真正符合用户业务上的需要
  5. V模型用于需求明确需求变更不频繁的情形

原型化模型

原型化模型第一步就是创建一个快速原型,能够满足项目干系人与未来的用户可以与原型进行交互,再通过与相关干系人进行充分的讨论和分析,最终弄清楚当前系统的需求,进行了充分的了解之后,在原型的基础上开发出用户满意的产品。

原型法认为在很难一下子全面准确地提出用户需求的情况下,原型应当具备的特点如下:

  1. 实际可行
  2. 具有最终系统的基本特征
  3. 构造方便、快速造价低。原型法的特点在于原型法对用户的需求是动态响应逐步纳入的。

增量模型

增量模型:首先开发核心模块功能,而后与用户确认,之后再开发次核心模块的功能,即每次开发一部分功能,并与用户需求确认,最终完成项目开发,优先级最高的服务最先交付 特点

  • 由于并不是从系统整体角度规划各个模块,因此不利于模块划分
  • 难点在于如何将客户需求划分为多个增量
  • 与原型不同的是增量模型的每一次增量版本都可作为独立可操作的作品,而原型的构造一般是为了演示
提示

对于开发过程中需求很容易发生变化的系统而言,增量式软件开发(敏捷方法的一个基础构成部分)是一个比瀑布模型方法更好的选择。 大部分业务系统和软件产品都是这样的。很少提前确定需求,需要根据用户反馈来动态调整需求。客户也可以更早地使用软件并从中获得价值。

敏捷模型

统一过程模型 RUP

RUP 描述了如何有效地利用商业的、可靠的方法开发和部署软件,是一种重量级过程。RUP 类似一个在线的指导者,它可以为所有方面和层次的程序开发提供指导方针、模版以及事例支持。

工作流

RUP 软件开发生命周期是一个二维的软件开发模型,RUP 中有9个核心工作流,如下:

  • 业务建模:理解待开发系统所在的机构及其商业运作,确保所有参与人员对待开发系统所在的机构有共同的认识,评估待开发系统对所在机构的影响。
  • 需求:定义系统功能及用户界面,使客户知道系统的功能,使开发人员理解系统的需求,为项目预算及计划提供基础。
  • 分析与设计:把需求分析的结果转化为分析与设计模型。
  • 实现:把设计模型转换为实现结果,对开发的代码做单元测试,将不同实现人员开发的模块集成为可执行系统。
  • 测试:检查各子系统之间的交互、集成,验证所有需求是否均被正确实现,对发现的软件质量上的缺陷进行归档,对软件质量提出改进建议。
  • 部署:打包、分发、安装软件,升级旧系统;培训用户及销售人员,并提供技术支持。
  • 配置与变更管理:跟踪并维护系统开发过程中产生的所有制品的完整性和一致性。
  • 项目管理:为软件开发项目提供计划、人员分配、执行、监控等方面的指导,为风险管理提供框架。
  • 环境:为软件开发机构提供软件开发环境,即提供过程管理和工具的支持。

RUP 生命周期

RUP 把软件开发生命周期划分为多个迭代,每个迭代生成产品的一个新的版本,每个迭代依次由4个连续的阶段组成,每个阶段完成确定的任务。这4个阶段如下:

  • 初始阶段:定义最终产品愿景和业务模型,并确定系统范围。
  • 细化阶段:设计及确定系统的体系结构,制订工作计划及资源要求。
  • 构造阶段:构造产品并继续演进需求、体系结构、计划直至产品提交。
  • 移交阶段:把产品提交给用户使用。

RUP 核心概念

RUP 中定义了如下一些核心概念,理解这些概念对于理解RUP 很有帮助。

  • 角色:Who 的问题。角色描述某个人或一个小组的行为与职责。RUP预先定义了很多角色,如体系结构师、设计人员、实现人员、测试员和部署管理人员等,并对每一个角色的工作和职责都做了详尽的说明。
  • 活动:How 的问题。活动是一个有明确目的的独立工作单元。
  • 制品:What的问题。制品是活动生成、创建或修改的一段信息。
  • 工作流:When 的问题。工作流描述了一个有意义的连续的活动序列,每个工作流产生一些有价值的产品,并显示了角色之间的关系。

RUP的特点

  • 用例驱动:需求分析、设计、实现和测试等活动都是用例驱动的。
  • 以体系结构为中心:包括系统的总体组织和全局控制、通信协议等。是一个多维的结构,会采用多个视图来描述。在典型的4+1视图模型中:
    • 分析人员和测试人员关心的是系统的行为,会侧重于用例视图;
    • 最终用户关心的是系统的功能,会侧重于逻辑视图;
    • 程序员关心的是系统的配置、装配等问题,会侧重于实现视图;
    • 系统集成人员关心的是系统的性能、可伸缩性、吞吐率等问题,会侧重于进程视图;
    • 系统工程师关心的是系统的发布、安装、拓扑结构等问题,会侧重于部署视图。

RUP 4+1视图模型

  • 迭代与增量:把整个项目开发分为多个迭代过程。在每次迭代中,只考虑系统的一部分需求,进行分析、设计、实现、测试和部署等过程;每次迭代是在已完成部分的基础上进行的,每次增加一些新的功能实现,以此进行下去,直至最后项目的完成。

RUP实践案例

以下是一个银行客户管理系统开发的RUP实践例子,体现了RUP的各个概念和特点:

1. 初始阶段

  • 角色:业务分析师、项目经理、系统架构师
  • 活动
    • 业务分析师进行业务建模,分析银行客户管理的业务流程
    • 项目经理制定项目计划和风险评估
    • 系统架构师初步设计系统架构
  • 制品
    • 业务模型文档
    • 初步用例模型(识别核心用例如"客户开户"、"账户管理"等)
    • 项目计划
    • 风险评估文档
  • 工作流:主要是业务建模和需求工作流
  • 视图:主要关注用例视图,初步构建逻辑视图

2. 细化阶段

  • 角色:系统架构师、需求分析师、UI设计师
  • 活动
    • 详细需求分析
    • 详细架构设计
    • 用户界面原型设计
  • 制品
    • 详细需求规格说明书
    • 架构设计文档
    • UI原型
    • 测试计划
  • 工作流:需求、分析与设计工作流
  • 视图:用例视图、逻辑视图、初步实现视图

3. 构造阶段(分多次迭代)

  • 第一次迭代:核心功能

    • 角色:开发人员、测试人员
    • 活动:实现客户信息管理模块、单元测试
    • 制品:源代码、测试用例、测试报告
    • 工作流:实现、测试工作流
    • 视图:实现视图、进程视图
  • 第二次迭代:扩展功能

    • 角色:开发人员、测试人员
    • 活动:实现账户管理模块、集成测试
    • 制品:更新的源代码、集成测试报告
    • 工作流:实现、测试工作流
    • 视图:实现视图、进程视图
  • 第三次迭代:高级功能

    • 角色:开发人员、测试人员、系统集成人员
    • 活动:实现报表和分析功能、系统测试
    • 制品:完整系统代码、系统测试报告
    • 工作流:实现、测试工作流
    • 视图:实现视图、进程视图、部署视图

4. 移交阶段

  • 角色:部署管理人员、培训人员、最终用户
  • 活动
    • 系统部署
    • 用户培训
    • 系统验收测试
  • 制品
    • 部署计划
    • 培训材料
    • 用户手册
    • 最终产品
  • 工作流:部署工作流
  • 视图:部署视图

这个例子展示了RUP的迭代增量特性,每次迭代都交付可用的系统版本,并在后续迭代中增加新功能。同时,体现了用例驱动(从用户需求出发)和以体系结构为中心(4+1视图模型)的特点。各个角色在不同阶段有明确的职责,产生相应的制品,遵循规定的工作流程。

其它模型

喷泉模型

  • 定义:喷泉模型是一种以用户需求为动力,以对象作为驱动的模型,适合于面向对象的开发方法。
  • 特点:使开发过程具有迭代性和无间隙性。

基于构件的开发模型(CBSD)

  • 定义利用预先包装的构件来构造应用系统。
  • 构件来源
    • 可以是组织内部开发的构件。
    • 也可以是商品化成品软件构件。
  • 特点增强了复用性:在系统开发过程中,会构建一个构件库,供其他系统复用,因此可以提高可靠性,节省时间和成本。

形式化方法模型

  • 定义:建立在严格数学基础上的一种软件开发方法。
  • 主要活动:生成计算机软件形式化的数学规格说明。