-
Unified
Process
,统一软件开发过程
RUP(Rational Unified
Process
,统一软件开发过程
)22010/08/20
19
:
24
五、开
发过程中的各个阶段和里程碑
RUP
中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段
(Ince
ption)
、细化阶段
(Elaboration)
、构造阶段
(Construction)
和交
付阶段
(Transition)
。每个阶段结束于一个主要的
里程碑
(Major Milestones)
;每个阶段
p>
本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个
阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个
< br>阶段。
1.
初始阶段
初始阶段的目标是为系统建立商业案例并确定项目的边界。为了达到该目的必须识
别所
有与系统交互的外部实体,在较高层次上定义交互的特性。本阶段具有非常重
要的意义,
在这个阶段中所关注的是整个项目进行中的业务和需求方面的主要风
险。对于建立在原有
系统基础上的开发项目来讲,初始阶段可能很短。初始阶段结
束时是第一个重要的里程碑
:生命周期目标
(Lifecycle Objective)
里程碑。生命
周期目标里程碑评价项目基本的生存能力。
2.
细化阶段
细化阶段的目标是分析问题领域,建立健全的体系结构基础,编制项目计划,淘汰
项目
中最高风险的元素。为了达到该目的,必须在理解整个系统的基础上,对体系
结构作出决
策,包括其范围、主要功能和诸如性能等非功能需求。同时为项目建立
支持环境,包括创
建开发案例,创建模板、准则并准备工具。细化阶段结束时第二
个重要的里程碑:生命周
期结构
(Lifecycle Architecture)
里
程碑。生命周期结构
里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中
进行衡量。此
刻,要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
3.
构造阶段
在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被
详细
测试。从某种意义上说,构建阶段是一个制造过程,其重点放在管理资源及控
制运作以优
化成本、进度和质量。构建阶段结束时是第三个重要的里程碑:初始功
能
(Initial Operational)
里程碑。初始功能里程碑决定了
产品是否可以在测试环
境中进行部署。此刻,要确定软件、环境、用户是否可以开始系统
的运作。此时的
产品版本也常被称为
版
。
4.
交付阶段
交付阶段的重点是确保软件对最终
用户是可用的。交付阶段可以跨越几次迭代,包
括为发布做准备的产品测试,基于用户反
馈的少量的调整。在生命周期的这一点
上,用户反馈应主要集中在产品调整,设置、安装
和可用性问题,所有主要的结构
问题应该已经在项目生命周期的早期阶段解决了。在交付
阶段的终点是第四个里程
碑:产品发布
(Product Re
lease)
里程碑。此时,要确定目标是否实现,是否应该
开
始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结
束重合。
[
编辑本段
]
六、统一软件开发过程
RUP
的核心工作流
< br>
RUP
中有
9
个核心工作流,分为
6
个核心过程工作流
(Core Process Workflows)
和
3
个核心支持工作流
(Core Supporting
Workflows)
。尽管
6
个核心
过程工作流可
能使人想起传统瀑布模型中的几个阶段,但应注意迭代过程中的阶段是完全
不同
的,这些工作流在整个生命周期中一次又一次被访问。
9<
/p>
个核心工作流在项目中轮
流被使用,在每一次迭代中以不同的重点
和强度重复。
1.
商业建模
(Business
Modeling)
商业建模工作流描述了如何为新的目标组织开发一个构想,并基于
这个构想在商业
用例模型和商业对象模型中定义组织的过程,角色和责任。
2.
需求
(Requir
ements)
需求工作流的目标是描述系统应该做什么,并使开发人员和用户就这一
描述达成共
识。为了达到该目标,要对需要的功能和约束进行提取、组织、文档化;最重
要的
是理解系统所解决问题的定义和范围。
< br>3.
分析和设计
(Analysis&Design)
分析和设计工作流将需求转化成未来系统的设计,为系统开发一个健壮的结构并调
整设计使其与实现环境相匹配,优化其性能。分析设计的结果是一个设计模型和一
个可选的分析模型。设计模型是源代码的抽象,由设计类和一些描述组成。设计类
被组织成具有良好接口的设计包
(Package)
和设计
子系统
(Subsystem)
,而描述则体
< br>现了类的对象如何协同工作实现用例的功能。设计活动以体系结构设计为中心,体
系结构由若干结构视图来表达,结构视图是整个设计的抽象和简化,该视图中省略
了一些
细节,使重要的特点体现得更加清晰。体系结构不仅仅是良好设计模型的承
载媒介,而且
在系统的开发中能提高被创建模型的质量。
4.
实现
(Implementation)
实现工作流的目的包括以层次化的子系统形式定义代码的组织
结构;以组件的形式
(
源文件、二进制文件、可执行文件
)
实现类和对象;将开发出的组件作为单元进行
测试以及集成由单个开发者
(
或小组
)
所产生的结果,使其成为可执行的系统。
5.
测试
(Test)
测试工作流要验证对象间的交互作用,验证软件中所有组件的正确集成,检验所有
的需求已被正确的实现
,
识别并确认缺陷在软件部署之前被
提出并处理。
RUP
提出
了迭代的方法
,意味着在整个项目中进行测试,从而尽可能早地发现缺陷,从根本
上降低了修改缺陷的
成本。测试类似于三维模型,分别从可靠性、功能性和系统性
能来进行。
6.
部署
(Deployment)
部署工作流的目的是成功的生成版本并将软件分发给最终用户。部署工作流描述了
那些与确保软件产品对最终用户具有可用性相关的活动,包括:软件打包、生成软
件本身以外的产品、安装软件、为用户提供帮助。在有些情况下,还可能包括计划
和进行
beta
测试版、移植现有的软件和数据以及正式验
收。
7.
配置和变更管理
配置和变更管理工作流描绘了如何在多个成员组成的项目中控制大量的产物。配置
和变更管理工作流提供了准则来管理演化系统中的多个变体,跟踪软件创建过程中
的版
本。工作流描述了如何管理并行开发、分布式开发、如何自动化创建工程。同
时也阐述了
对产品修改原因、时间、人员保持审计记录。
8.
项目管理
(Project
Management)
软件项目管理平衡各种可能产生冲突的目标,管理风险,克服
各种约束并成功交付
使用户满意的产品。其目标包括:为项目的管理提供框架,为计划、
人员配备、执
行和监控项目提供实用的准则,为管理风险提供框架等。
< br>
9.
环境
(Environment)
环境工作流的目的是向软件开发组织提供软件开发环境,包括过程和工具。环境工
作流集中于配置项目过程中所需要的活动,同样也支持开发项目规范的活动,提供
了逐步的指导手册并介绍了如何在组织中实现过程。
[
编辑本段
]
七、
RUP
的迭代开发模式
RUP
中
的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环,产生
一个可执行的
产品版本,是最终产品的一个子集,它增量式地发展,从一个迭代过
程到另一个迭代过程
到成为最终的系统。传统上的项目组织是顺序通过每个工作
流,每个工作流只有一次,也
就是我们熟悉的瀑布生命周期
(
见图
2
)
。这样做的结
果是到实现末期产品完成并开始测试,在分析、
设计和实现阶段所遗留的隐藏问题
会大量出现,项目可能要停止并开始一个漫长的错误修
正周期。
一种更灵活,风险更小的方法是多次通过不同的开发
工作流,这样可以更好的理解
需求,构造一个健壮的体系结构,并最终交付一系列逐步完
成的版本。这叫做一个
迭代生命周期。在工作流中的每一次顺序的通过称为一次迭代。软
件生命周期是迭
代的连续,通过它,软件是增量的开发。一次迭代包括了生成一个可执行
版本的开
发活动,还有使用这个版本所必需的其他辅助成分,如版本描述、用户文档等。
因
此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过,这些工作流至
p>
少包括:需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像
一个小型的瀑布项目
(
见图
3)
。
图
3
RUP
的迭代模型
RUP
的迭代模型
与传统的瀑布模型相比较,迭代过程具有以下优点:
降低了在一个增量上的开支风险。如果开发人员重复某个迭代,那么损失只是这一
个开发有误的迭代的花费。
降低了产品无法按照既定
进度进入市场的风险。通过在开发早期就确定风险,可以
尽早来解决而不至于在开发后期
匆匆忙忙。
加快了整个开发工作的进度。因为开发人员清楚问
题的焦点所在,他们的工作会更
有效率。
由于用户的需求并不能在一开始就作出完全的界定,它们通常是在后续阶段中不断
细
化的。因此,迭代过程这种模式使适应需求的变化会更容易些。
[
编辑本段
]
八、统一软件开发过程
RUP
的十大要素
1.
开发前景
2.
达成计划