您的位置：首页 > 其它

软件过程与方法---课堂总结2 第三章惯例过程模型

2016-01-07 15:34 357 查看

第三章惯例过程模型

3.1惯例过程模型概述

（1）惯例过程模型是包括活动、动作、任务、里程碑和工作产品的明确的集合，旨在开发高质量的软件。

（2）惯例过程模型通过一套框架活动指导项目团队，这些框架活动被组织到一个过程流中，每个过程模型的术语和细节不同，但通用框架活动在一定程度上保持一致。

3.2瀑布模型

传统瀑布模型

（0） 瀑布模型的特点

l 阶段间具有顺序性和依赖性

l 推迟程序的物理实现

l 质量保证：每个阶段必须完成规定的文档：每个阶段结束前完成文档审查，及早改正错误。

l 是一种严格线性的、按阶段顺序的、逐步细化的过程过程模型

l 文档驱动，强调文档的作用

（1）瀑布模型的优点：

ü 有利于人员的组织与管理

ü 有利于软件开发方法和工具的研究

可以提高大型软件项目开发的质量和效率

（2）瀑布模型的缺点

Ø 难以解决需求不明确的问题

Ø 缺乏灵活性，开发周期长

Ø 易于陷入“阻塞状态”

Ø 反馈时间长，风险大

Ø 可操作性差

（3）瀑布模型的适用范围

l 需求明确全面、开发过程中没有或很少变更的项目

l 开发人员熟悉项目产品的应用领域

l 用户使用环境稳定项目

l 开发过程很少或不需要用户参与的项目

3.3增量过程模型

（1）增量过程模型是一种以增量的形式生产软件产品的过程模型，适用于以下场景：

l 初始的软件需求有明确的定义，但是，受时间或资源的限制不宜单纯运用线性模型。

l 迫切需要迅速提供一套功能有限的功能的产品，在后续版本中细化和扩充。

（2）增量过程模型的代表

l 增量模型

l RAD模型

3.3．1增量模型

（1）增量模型以迭代的方式运用瀑布模型

（2）每一个增量都提交一个可以操作的产品

（3）增量模型的特点

l 融合瀑布模型的基本成分和迭代的特点

l 以功能递增的方式进行软件开发

l 能较快地产生可操作的系统

l 在每一步递增中，均发布一个可操作的增量版本，把用户/开发者的经验结合到不断求精的产品中

（4）增量模型的优点：

l 人员分配灵活，刚开始不用投入大量人力资源

l 规避技术风险

l 在短时间内提交核心产品，对用户起到镇静剂的作用，具有一定市场

（5）增量模型的缺点：

l 并行开发构建，有可能遇到不能集成的风险，对软件体系结构要求高

l 容易退化为“边做边改”模型，导致对软件过程的控制失去整体性

（6）增量模型的适用范围

l 已有产品升级项目或新版本的开发项目

l 需求明确并对使用者开始时间有严格要求的项目

3.3.2 RAD模型

（1）RAD（RapidApplication Development,快速应用程序开发）是一种适用于极短开发周期的增量软件过程模型，是瀑布模型的一个“高速”变种，通过基于构件的构建的实现快速开发。

（2）RAD模型的缺点

l 对大型项目而言，RAD需要足够的人力资源

l 开发者和客户都要实现承诺，否则将导致失败

l 并非所有系统都适合：不能合理模块化的系统、高性能需求并且要调整构建接口的系统均不合适

l 不适合技术风险很高的情况

总结：无论是增量模型，还是RAD模型，增量过程主要用于需求明确但又受时间或资源约束的项目

3.4演化过程模型

（1）演化过程模型利用迭代的思想方法，使软件工程师逐渐的开发逐步完善的软件版本

（2）演化过程模型主要适用于在项目开发初期项目需求不明确，把握不充分的项目

（3）演化过程模型的代表

l 原型模型

l 螺旋模型

3.4.1原型模型

（1）原型模型针对需求不明确的情况通过迅速构建可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识，最终在确定的需求基础上开发出满意的产品。

（2）原型模型是用户驱动大的（即需求模糊或随时间变化的系统）

（3）原型模型要分两步走：

l 第一步，快速构建原型系统，实现用户与系统的交互，通过用户对原型的评价，进一步细化需求，通过逐步调整原型使其满足用户的要求，从而确定用户的真正需求。（迭代）

l 第二步，在第一步的基础上开发用户满意的产品

（4）原型的分类：

l 探索型原型：用于需求分析阶段，目的是要澄清用户的需求，确定所期望的特性，并探索各种方案的可行性。

l 实验型原型：用于设计阶段，考核实现方案是否合适

l 演化型原型：用于及早向用户提交一个原型系统，在得到用户的认可后不断扩充演变为最终的产品。

（5）原型的使用策略

l 抛弃策略：原型仅用于开发过程的某个阶段，该阶段结束后，原型随之作废。

l 附加策略：原型用于开发的全过程，由最基本的核心开始，逐步增加新的功能和新的需求，最后发展为用户满意的最终系统。

（6）原型模型的优点：

l 克服瀑布模型的缺点，减少由于软件需求不明确带来的风险。

（7）原型模型的缺点：

l 容易引起用户误解

l 缺少项目标准，对用户参与程度要求高

l 用户可能不断提出新的要求，原型迭代的周期很难控制

l 额外的花费：研究结果表明构造一个原型可能需要10%额外花费

l 为了尽快实现原型，采用了不合适技术，运行效率可能会受影响

（8）原型模型的适用范围

l 适合于那些不能确切定义需求的项目：

ü 用户未能详细定义输入、处理、输出

ü 开发人员对算法效率、OS、人机交互的形式不确定

3.4.2螺旋模型

（1）螺旋模型（Boehm，1988提出），综合了原型模型的迭代特征和瀑布模型的系统性和可控制性的特点，增加风险分析，是以风险为导向的生命周期模型。

l 采用循环方式逐步加深系统定义和实现的深度，同时降低风险

l 确定一系列里程碑，确保项目干洗人都支持可行的和令人满意的解决方案

（2）螺旋模型示意

（3）螺旋模型特点

l 把软件开发过程组成为一个逐步细化的螺旋周期序列，每经历一个周期，系统就得到进一步的细化和完善

l 紧密围绕开发中的风险问题，用风险分析推动软件设计向深一层扩展、求精

l 强调持续地判断、确定和修改用户任务目标，并按成本、效益来分析候选的软件产品性质对任务目标的贡献

l 可结合采用多种软件开发方法，但究竟结合哪一种方法仍有风险分析来决定

（4）螺旋模型优势

l 设计上具有灵活性，可以在产品的各个阶段进行变更

l 以小的分段来构建大型系统，易于成本计算

l 客户参与各阶段的开发，保证项目不偏离正确方向和项目的可控性

l 引入风险分析，随着迭代的增加风险程度随之降低

（5）螺旋模型的不足

l 过多的迭代次数会延长交付时间，增加开发成本

l 对风险评估技术和经验有较高要求，评估不当会造成重大损失

（6）螺旋模型只适合于大型软件项目的开发

3.5统一过程模型

（1）统一过程模型（RUP/UP，RationalUnified Process）

l Rational

l 统一：RUP拥有自己的一套架构，且这套架构是以一种大多数项目和开发组织都能够接受的形式存在

l 过程：RUP是以一种软件开发过程，提供了如何对软件组织进行管理的方式，并拥有自己的目标和方法

（2）统一过程模型是一种以用例驱动、以体系结构为核心、迭代及增量的软件过程模型，由UML方法和工具支持，广泛应用于各类面向对象项目

（3）RUP的二维开发模型（图同3.5.2（3））

（4）RUP是按照二维结构进行组织的

l 横轴，按时间组织：显示RUP的动态特征，通过迭代式软件开发周期、阶段、迭代和里程碑等动态信息表示

l 纵轴，按内容组织：显示RUP的静态特征，通过过程的构件、活动、工作流、产品和角色等静态概念来描述系统

3.5.1 RUP的静态结构

（1）RUP的静态结构包括6个核心工作流和3个核心支持工作流

核心支持工作流：

1.配置与变更管理

2.项目管理

3.环境

核心工作流：

1.业务建模

2.需求

3.分析设计

4.实现

5.测试

6.部署

工作流程

业务建模

需求

分析设计

实施

测试

部署

配置与变更管理

项目管理

环境

（2）业务建模工作流产生的产品

ü 商业逻辑建模（USE CASE）(ROSE)

ü 业务需求说明书（MS WORD）

ü 专业词汇表（英汉对照）（MS WORD）

ü 风险说明（MS WORD）

ü 复审说明书

（3）需求工作流

确保开发人员构建正确的系统

ü 了解目标组织的结构及机制

ü 目标组织中当前存在的问题并确定改进的可能性

ü 确保客户、最终用户和开发人员就目标组织达成共识

ü 导出支持目标支持目标组织所需的系统需求，建立系统需求模型：用例图（表示系统的功能）

(4)分析设计工作流

l 将系统需求转换为未来系统的设计

l 逐步开发强壮的系统架构

l 使设计适合于实施环境，为提高性能而进行设计

（5）分析设计工作流的流程

（6）分析设计工作流的工作产品

ü 系统总体设计报告（MS WORD）

ü 系统领域模型DOMAINMODEL(ROSE)

ü 系统设计模型DESIGNMODEL(ROSE)

ü 数据库设计模型(POWERDESIGNER)

ü 数据字典(MS WORD)

ü 系统详细设计报告(MS WORD)

ü 工作量化书(MS WORD)

ü 风险列表

（7）实施工作流

l 定义代码结构

l 以构建的方式实施类和对象

l 对已开发的构建按单元来测试，并且将结果集成到可执行系统中

l 测试仅限于对各个类进行单元测试。系统测试和集成测试将在测试工作流程中进行说明

（8）实施工作流的流程

（9）测试工作流

ü 核实对象之间的交互

ü 核实软件的所有构件是否正确集成

ü 核实所有需求是否已经正确实施

ü 确定缺陷，确保在部署软件之前将缺陷解决

3.5.2 RUP的动态结构

（1）迭代开发

通过多次执行不同的开发工作流，逐步确定一部分需求分析和风险，在设计、实现并确认这部分后，再去做下一部分的需求分析、设计、实现和确认工作，依次进行下去，直至整个项目完成，这样能在逐步集成中更好地理解需求，构造一个健壮的体系结构

（2）RUP中的迭代

每个迭代周期都是一个小的瀑布模型

（3）对迭代的特定短期目标进行分割并组织迭代开发秩序，迭代过程划分为4个连续的阶段：起始，细化，构建，转换

起始：

ü 明确项目规模，了解环境、最重要的是需求和约束，得出产品验收标准

ü 计划和准备商业理由，评估风险

ü 评估人员配备、计划、成本、进度、收益折中的备选方案

ü 明确系统关键用例和主要的功能场景

ü 展现至少一种符合主要场景要求的候选软年体系结构，准备环境

ü 做出最初的项目成本和日程估计

为系统建立商业案例和确定项目边界

细化：

ü 确保软件结构、需求、计划是足够稳定

ü 确保风险降低到能预计完成整个项目的成本和日程的程度

ü 通过完成软件结构上的主要场景建立软件体系结构的基线

ü 所有用例均被识别，大多数用例描述被开发

ü 建立一个包含高质量组件的可演化的产品原型

ü 规定项目的总体计划，显示迭代过程和对应的审核标准

分析问题、建立体系结构基础、编制计划、淘汰最高风险元素

构建：

ü 完成所有必需功能的分析、设计、开发和测试工作

ü 根据实际需要形成各个版本，达到适当的质量目标

ü 采用循环渐进的方式开发出完整产品：达到一定程度上的并行开发

ü 重点：管理资源和控制运作以优化成本、日程、质量的生产过程；通过优化资源和避免不必要的反工达到开发成本的最小化

开发构件和应用程序功能并集成为产品，所有功能被详尽的测试

转化：

ü 进行Beta版测试，按用户的要求验证新系统

ü 替换旧的系统

ü 对用户和维护人员进行培训

ü 开始调整**，例如调试、性能或可用性的增强

ü 与用户***，配置基线与评估标准一致。

将软件产品交付给用户

四个阶段分别对应着关键里程碑的划分：每个阶段都可能经历瀑布模型的从需求分析开始的各个步骤，只是每个步骤的高峰期会发生在相应的阶段

（12）各阶段的工作量和进度分布

不同的工作流，在不同的时间段内工作量不同。注意，几乎所有的工作流，在所有的时间段内均有工作量只是大小不同而已，这与瀑布模型明显不同

（13）统一过程各阶段的工作产品

3.5.3RUP与通用活动的对照

3.5 统一过程模型
（0）RUP蕴含了大量的优秀实践准则
ü 迭代式软件开发
ü 需求管理
ü 一体系结构为中心，基于构件的架构应用：1.逻辑视图2.过程视图3.物理视图4.部署视图5.用例视图
ü 建立可视化的软件模型 1.Use Case视图2.分析视图3.设计视图4.实现视图
ü 软件质量验证
ü 软件变更控制
（1）RUP三大特征
l 迭代开发
l 用例驱动
l 以架构为中心
（2）RUP的优点
l 降低风险
l 加快整个开发工作的进度
l 易于管理需求的变化
（3）RUP不足
l RUP只是一个开发过程，并未涵盖软件过程的全部内容
l RUP适用于规模比较大的软件项目，对于中，小规模的项目开销比较大
（4）RUP强调项目的可控性，是一个用力驱动的基于UML和构件架构的迭代增量式开发过程。
（5）RUP是可以裁减的，对于角色，流程，活动的要求是灵活，可配置的。
（6）RUP的各个里程碑，都规定了要交付的成果，它强调及时的更新与同步。

RUP是一种重量级的软件开发方法，比较适合大中型的软件项目和产品的开发。

3.6专用过程模型

专用过程模型具有传统过程模型的特点，但是，只适用于某些特定的软件工程方法，应用面较窄。
l 基于构件的开发模型
l 形式化方法模型

3.6.1基于构件的开发

（1）基于构件的开发采用预先打包的如那件构件开发程序，以迭代的方式构建产品。
（2）流程：
1 构建识别，评估，选择
2 设计软件架构容纳所选择构件
3 将选择构建集成到架构中
4 测试
5 重复上述步骤直到产生满意的产品

3.6.2形式化方法模型

（1）形式化方法模型使用严格的数学描述来说明、开发和验证预计计算机的系统
（2）主要活动是生成计算机软件形式化的数学规格说明
（3）优势
l 应用数学分析的方法发现和改正歧义性问题、不完整问题、不一致问题。（评审无关性）因而，可以提供无缺陷的软件
（4）不足
l 形式化模型开发非常耗时、成本很高
l 需要大量培训
l 对用户的技术水平要求高

第三章小结

惯例过程模型力图给软件开发带来次序和结构

每一种惯例过程模型都建议了一种不同的过程流，但是都实现了同样的一组通用框架活动：沟通、策划、建模、构建、部署

惯性过程模型	过程模式	优点	缺点	适用范围
瀑布模型	ü 有利于人员的组织与管理 ü 有利于软件开发方法和工具的研究可以提高大型软件项目开发的质量和效率	Ø 难以解决需求不明确的问题 Ø 缺乏灵活性，开发周期长 Ø 易于陷入“阻塞状态” Ø 反馈时间长，风险大 Ø 可操作性差	l 需求明确、全面，开发过程中没有或很少变更的项目 l 开发人员熟悉项目产品的应用领域 l 用户使用环境稳定的项目 l 开发过程很少或不需要用户参与的项目
增量过程模型	增量模型	ü 人员分配灵活，刚开始不用投入大量人力资源 ü 规避技术风险 ü 在短时间内提交核心产品，对用户起到镇静剂的作用，具有一定市场	Ø 并行开发构建，有可能遇到不能集成的风险，对软件体系结构要求高 Ø 容易退化为“边做边改”模型，导致对软件过程的控制失去整体性	l 已有产品升级项目或新版本的开发项目 l 需求明确并对使用开始时间有严格要求的项目
RAD模型	ü 促进强化合作气氛并动态收集相关需求。企业主会主动参与原型制作、撰写测试个案，以及实施单元测试。	Ø 对大型项目而言，RAD需要足够的人力资源 Ø 开发者和客户都要实现承诺，否则将导致失败 Ø 并非所有系统都适合：不能合理模块化的系统、高性能需求并且要调整构建接口的系统均不合适 Ø 不适合技术风险很高的情况	l 主要用于需求明确但又受时间或资源约束的项目
演化过程模型	原型模型	ü 克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险	Ø 容易引起用户误解 Ø 缺少项目标准，对用户参与程度要求高 Ø 用户可能不断提出新的要求，原型迭代的周期很难控制 Ø 额外的花费：研究结果表明构造一个原型可能需要10%额外花费 Ø 为了尽快实现原型，采用了不合适技术，运行效率可能会受影响	适合于那些不能确切定义需求的项目： l 用户未能详细定义输入、处理、输出开发人员对算法效率、OS、人机交互的形式不确定
螺旋模型	ü 设计上具有灵活性，可以在产品的各个阶段进行变更 ü 以小的分段来构建大型系统，易于成本计算 ü 客户参与各阶段的开发，保证项目不偏离正确方向和项目的可控性 ü 引入风险分析，随着迭代的增加风险程度随之降低	Ø 过多的迭代次数会延长交付时间，增加开发成本 Ø 对风险评估技术和经验有较高要求，评估不当会造成重大损失	只适合于大型软件项目的开发
统一过程模型	ü 降低风险 ü 加快整个开发工作的进度 ü 易于管理需求的变化	Ø RUP只是一个开发过程，并未涵盖软件过程的全部内容 Ø RUP适用于规模比较大的软件项目，对于中，小规模的项目开销比较大	RUP是一种重量级的软件开发方法，比较适合大中型的软件项目和产品的开发

内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理

标签：

相关文章推荐

新的分享

章节导航

软件过程与方法---课堂总结2 第三章 惯例过程模型

目录

第三章 惯例过程模型