软件工程概述-----RUP开发模式

RUP

  • Rational Unified Process(简称RUP)是一套软件工程过程
    ,主要由Ivar Jacobson的 The Objectory Approch 和 The
    Rational Approch 发展而来。
  • 是文档化的软件工程产品,所有RUP 的实施细节及方法导引
    均以Web文档的方式集成在一张光盘上。
  • RUP又是一套软件工程方法的框架,各个组织可根据自身的
    实际情况,以及项目规模对RUP进行裁剪和修改,以制定出
    合乎需要的软件工程过程。

历史

在这里插入图片描述

RUP生命周期

在这里插入图片描述

核心工作流

  • 业务建模(Business Modeling)
    • 对开发系统所在的机构及其商业规则进行建模;
  • 需求(Requirement)
    • 定义系统功能及用户界面;
  • 分析设计(Analysis & Design)
    • 建立分析模型和设计模型;
  • 实现 (Implementation)
    • 编码实现;
  • 测试 (Test)
    • 软件测试;
  • 部署 (Deployment)
    • 打包、分发、安装软件

每个核心工作流程都与一个特定的模型集相关联

在这里插入图片描述

核心支持工作流(在组织中的流程)

  • 配置与变更管理(Configuration & Change
    Management)
    • 跟踪并维护系统开发过程中所产生的所有制品的完整和一致性;
  • 项目管理 (Project Management)
    • 为软件项目提供计划、人员分配、执行、监控等方面的管理;
  • 环境 (Environment)
    • 为软件开发机构提供软件开发环境的支持。

RUP的特点

  • 用例驱动
    在这里插入图片描述

  • 以体系结构为中心
    在这里插入图片描述

在这里插入图片描述

主要概念

在这里插入图片描述

角色

  • Role
    – 角色定义了在软件工程组织的环境中,个人或协同工作的多人小组的行为和
    职责。角色代表项目中个人承担的任务,并定义其如何完成工作。
  • Rup预定义的角色:
    – 分析员角色
    • (业务流程分析员 、业务设计员 、业务模型复审员、需求复审员 、系统分析员 、
    用例阐释者 、用户界面设计员 )
    – 开发人员角色
    • (构架设计师 、构架复审员 、封装体设计员、代码复审员 、数据库设计员 、设计
    复审员 、设计员 、实施员 、集成员 )
    – 测试专业人员角色
    • (测试设计员 、测试员 )
    – 经理角色
    • (变更控制经理 、配置经理、部署经理、流程工程师、项目经理、项目复审员 )
    – 其他角色
    • (任意角色 、课程开发员 、图形设计员 、涉众 、系统管理员、技术文档编写员 、
    工具专家)

工作流程

  • 一个工作流程就是一系
    列活动
  • 按 UML 术语,工作流
    程可以表现为序列图、
    协作图或活动图。在
    RUP中,使用活动图。

活动

• 活动是参与项目的角色为提供符合要求的结果而进行的工作。
• 一项活动是一个工作单元,由参与项目的某一成员执行,其
具体内容由角色进行说明。
• 活动有明确的目的,其内容通常表述为创建或更新某些工件,
例如一个模型、一个类或一个计划。每个活动都被分配给具
体的角色。
• 一个活动一般延续几个小时到几天,它通常涉及一个角色,
只影响一个或少数几个工件。
3) 活动
• 例:在这里插入图片描述

3) 活动
• 例:需求活动在这里插入图片描述

3) 活动
• 例:分析与设计活动在这里插入图片描述

工件

  • 工件是流程的工作产品:
    – 角色使用工件执行活动,并在执行活动的过程中生成工件。

  • 工件是单个角色的职责,它体现的是这样一种思想:
    – 流程中的每条信息都必须是一个具体的人的职责。即使一
    个人可能“拥有”某个工件,但其他人也可以使用该工件,
    如果授予权限,或许他们还可以更新这个工件。

  • 工件分为输入工件和输出工件。

  • 工件有多种形式:
    – 模型,例如用例模型或设计模型,它包含其他工件。
    – 模型元素,即模型中的元素,例如设计类、用例或设计子系统
    – 文档,例如商业理由或软件构架文档
    – 源代码和可执行程序(某种构件)
    – 可执行程序

  • 工件示例:
    – 存储在 Rational Rose 中的设计模型。
    – 存储在 Microsoft Project 中的项目计划。
    – 存储在 ClearQuest 中的缺陷。
    – RequisitePro 中的项目需求数据库。

  • 主要工件在这里插入图片描述

  • 例:需求工件在这里插入图片描述

  • 例:分析与设计工件在这里插入图片描述

阶段

  • RUP把生命周期分为若干个循环(Cycle),每个循环有4个
    阶段组成,并生成产品的一个新版本。
  • 四个阶段:
    – 初始(Inception)
  • 定义最终产品视图和业务模型,确定系统范围;
    – 细化(Elaboration)
  • 设计系统的体系结构、制定工作计划和资源要求;
    – 构造(Construction)
  • 构造并完成产品;
    – 移交(Transition)
  • 产品交付给用户使用;

阶段——初始阶段

主要目标包括:

– 建立项目的软件规模和边界条件,包括运作前景、验收标
准以及希望软件中包括和不包括的内容。
– 识别系统的关键用例(也就是将造成重要设计折衷操作的
主要部分)。
– 评估整个项目的总体成本和进度(以及对即将进行的精化
阶段进行更详细的评估)
– 评估潜在风险(不可预测性的来源)
– 准备项目的支持环境。

核心活动

– 明确地说明项目规模。
– 计划和准备商业理由。

评估风险管理、人员配备、项目计划和成本/进度/收益率折衷的备

选方案。
– 综合考虑备选构架,评估设计和自制/外购/复用方面的折
衷,从而估算出成本、进度和资源。
– 准备项目的环境,评估项目和组织,选择工具,决定流程
中要改进的部分。

里程碑:生命周期目标

– 生命周期目标里程碑评估项目的基本可行性。
– 先启阶段末是第一个重要的项目里程碑,即生命周期目标里程碑。此时,检
查项目的生命周期目标,并决定继续进行项目还是取消项目。

评估标准

– 规模定义和成本/进度估算中,所有相关因素(如客户等)可并行
– 对是否已经获得正确的需求集达成一致意见,并且对这些需求的理解是共同
的。
– 对成本/进度估算、优先级、风险和开发流程是否合适达成一致意见。
– 已经确定所有风险并且有针对每个风险的减轻风险策略。

如果项目无法达到该里程碑,则它可能中途失败或需要进行相当多的重新考虑。

阶段——细化阶段

主要目标包括:

– 确保构架、需求和计划足够稳定,充分减少风险,从而能够有预见性地确定
完成开发所需的成本和进度。对大多数项目来说,通过此里程碑也就相当于
从简单快速的低风险运作转移到高成本、高风险的运作,并且在组织结构方
面面临许多不利因素。
– 处理在构架方面具有重要意义的所有项目风险
– 建立一个已确定基线的构架,它是通过处理构架方面重要的场景得到的,这
些场景通常可以显示项目的最大技术风险。
– 制作产品质量构件的演进式原型,也可能同时制作一个或多个可放弃的探索
性原型,以减小特定风险,例如:

设计/需求折衷

构件复用

产品可行性或向客户和最终用户进行演示。

– 证明已建立基线的构架将在适当时间、以合理的成本支持系统需求。
– 建立支持环境。

核心活动

– 快速确定构架、确认构架并为构架建立基线。
– 根据此阶段获得的新信息改进前景,对推动构架和计划决
策的最关键用例建立可靠的了解。
– 为构建阶段创建详细的迭代计划并为其建立基线。
– 改进开发案例,定位开发环境,包括流程和支持构建团队
所需的工具和自动化支持。
– 改进构架并选择构件。 评估潜在构件,充分了解自制/外
购/复用决策,以便有把握地确定构建阶段的成本和进度。
集成了所选构架构件,并按主要场景进行了评估。通过这
些活动得到的经验有可能导致重新设计构架、考虑替代设
计或重新考虑需求。

里程碑:生命周期构架

– 生命周期构架里程碑为系统构架建立管理基线,并使项目
团队能够在构建阶段调整规模。
– 精化阶段末是第二个重要的项目里程碑,即生命周期构架
里程碑。此时,您检查详细的系统目标和规模、选择的构
架以及主要风险的解决方案。

评估标准

– 产品前景和需求是稳定的。
– 构架是稳定的。
– 可执行原型表明已经找到了主要的风险元素,并且得到妥善解决。
– 构建阶段的迭代计划足够详细和真实,可以保证工作继续进行。
– 构建阶段的迭代计划由可靠的估算支持。
– 所有客户方人员一致认为,如果在当前构架环境中执行当前计划来
开发完整的系统,则当前的前景可以实现。
– 实际的资源耗费与计划的耗费相比是可以接受的。

如果项目无法达到该里程碑,则它可能中途失败或需要进行相当多的重新考虑。

阶段——构造阶段

主要目标包括:

– 通过优化资源和避免不必要的报废和返工,使开发成本降
到最低。
– 快速达到足够好的质量 。
– 快速完成有用的版本(Alpha 版、Beta 版和其他测试发
布版) 。
– 完成所有所需功能的分析、开发和测试。
– 迭代式、递增式地开发随时可以发布到用户群的完整产品
。这意味着描述剩余的用例和其他需求,充实设计,完成
实施,并测试软件。
– 确定软件、场地和用户是否已经为部署应用程序作好准备

– 开发团队的工作实现某种程度的并行。
1.4.3.6 阶段——构造阶段

核心活动

– 资源管理,控制和流程优化;
– 完成构件开发并根据已定义的评估标准进行测试;
– 根据前景的验收标准对产品发布版进行评估。

里程碑:最初操作性能

– 最初操作性能里程碑确定产品是否已经可以部署到 Beta 测试环境。
– 在最初操作性能里程碑,产品随时可以移交给产品化团队。此时,已
开发了所有功能,并完成了所有 Alpha 测试(如果有测试)。除了软
件之外,用户手册也已经完成,而且有对当前发布版的说明。

评估标准

– 该产品发布版是否足够稳定和成熟,可部署在用户群中?
– 是否已准备好将产品发布到用户群?
– 实际的资源耗费与计划的相比是否仍可以接受?

如果项目无法达到该里程碑,产品化可能要推迟一个发布版。

阶段——移交阶段

主要目标

– 进行 Beta 测试,按用户的期望确认新系统
– Beta 测试和相对于正在替换的遗留系统的并行操作
– 转换操作数据库
– 培训用户和维护人员
– 市场营销、进行分发和向销售人员进行新产品介绍
– 与部署相关的工程,例如接入、商业包装和生产、销售介绍、现场人
员培训
– 调整活动,如进行调试、性能或可用性的增强
– 根据产品的完整前景和验收标准,对部署基线进行的评估
– 实现用户的自我支持能力
– 在用户之间达成共识,即部署基线已完成
– 在用户之间达成共识,即部署基线与前景的评估标准一致

核心活动

– 执行部署计划
– 对最终用户支持材料定稿
– 在开发现场测试可交付产品
– 制作产品发布版
– 获得用户反馈
– 基于反馈调整产品
– 使最终用户可以使用产品

里程碑:产品发布

– 产品化阶段末是第四个重要的项目里程碑,即产品发布里
程碑。此时,您确定是否达到目标,以及是否应该开始另
一个开发周期。有时候,该里程碑可能与下一周期的先启
阶段末重合。产品发布里程碑是项目验收复审成功完成的
结果。

评估标准

– 用户是否满意?
– 实际的资源耗费与计划的耗费相比是否可以接受?

在产品发布里程碑处,发布后的维护周期同时开始

。这涉及开始一个新的周期,或某个其他的维护发
布版。

工具

• Rational Unified Process 中的许多活动是由软件工程工具
支持的。
• 工具向导详细说明了如何使用 Rational 软件工具来支持特定
的步骤和活动。
• 提供以下向导:
– Rational AnalystStudio Rational ClearCase
– Rational ClearQuest Rational RequisitePro
– Rational Rose Rational PerformanceStudio
– Rational Purify Rational PureCoverage
– Rational Quantify Rational SoDA for Word
– Rational Unified Process
– Rational TeamTest/TestStudio 的功能部件:
• Robot TestManager
• TestFactory Log

  • 0
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

醉卧考场君莫笑

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值