RUP 阳飞Word文档格式.docx
《RUP 阳飞Word文档格式.docx》由会员分享，可在线阅读，更多相关《RUP 阳飞Word文档格式.docx（61页珍藏版）》请在冰点文库上搜索。
顺便插一句，当前异常火爆的CMM说是“软件过程框架和标准”，当如何理解。
从“软件过程也是软件”的角度考虑，CMM的本质其实是软件过程开发的需求和测试方案：
CMM的每个“关键实践”都是软件过程开发的一条需求；
至于“关键过程域”和“关键实践类”，从需求的层次角度（请参考Wiegers著陆丽娜译《软件需求》一书），可分别理解为“业务需求”和“用户需求”；
CMM提问单的每个问题就是测试方案的一个一个的测试案例，测试方案是依照需求来制定的，CMM把需求和测试方案二合一了。
“CMM是软件过程的进化框架”也不难从“软件过程也是软件”的角度找到犀利的理解，那就是：
CMM对所有软件过程开发的需求，依据重要性和相互依赖关系，划分了优先级，然后依据需求的优先级将需求分成五组，即初始级、可重复级、已定义级、定量管理级和优化级。
2.软件过程开发产出过程产品
软件开发产出的软件产品是程序和文档的集合，那么，过程开发产出的过程产品是什么样呢？
过程成品从存在形式上，是一些文档。
通过评审的过程产品，就是标准化制度化的文档，这些文档来指导和制约软件开发过程。
过程产品都必须具备四要素：
功能要素（即活动），行为要素（即活动间通过依赖等关联构成活动模型，其实四大经典开发模型的图基本都是活动模型），组织要素（即人和活动间的关联），信息要素（即产品）。
再看RUP，该过程产品也是一些文档，总共有上千页，被组织成可以在线查询的知识库。
我们看其核心概念：
角色、活动、工作流和工件，并没用离开四要素的范畴：
角色即人（的职责），工件即产品，工作流是涉及角色、活动和工件的模型。
3.软件过程开发也可以是一个演进过程
为了进一步证明软件过程开发和软件开发的相似性，我们选择很流行的“演进”概念来考察二者。
演进开发在RUP中叫增量开发，就是后一步的开发在前一步开发的半成品的基础上进行。
软件开发采用演进开发的，一般称为“喷泉模型”。
而软件过程开发也可以采用演进开发，特别是开发针对大项目的软件过程时，由于软件过程足够复杂，演进开发是必要的。
二、RUP的剪裁原理
首先说明再工程的概念，然后说明RUP剪裁就是一项再工程。
1.再工程的概念
再工程（reengineering）是对现有软件系统的重新开发过程，包括逆向工程、新需求的考虑和正向工程三个步骤。
2.RUP剪裁是软件过程开发的再工程
既然“软件过程也是软件”，那么再工程概念对软件过程开发也适用。
RUP剪裁的故事就可以这样讲：
Rational公司开发出了RUP；
我们想将RUP剪裁后用于某软件项目，于是我们就对RUP进行逆向工程得到《RUP开发需求》和《RUP设计方案》等文档；
然后，再考虑我们这个软件项目得到《某软件项目软件过程需求》；
最后，比较两个需求，借鉴《RUP设计方案》，进行软件过程开发的正向工程得到《某软件项目软件开发过程》。
是的，“RUP剪裁是软件过程开发的再工程”的观点确实很有启发，为我们制定工程化的RUP剪裁过程打下了坚实的理论基础。
第二部分对RUP进行逆向工程
依据“RUP剪裁是软件过程开发的再工程”的观点，RUP剪裁分为对RUP进行逆向工程、考虑软件过程新需求和过程开发正向工程三个步骤。
但是，对RUP进行逆向工程只需进行一次，以后的RUP剪裁过程都可以重用了。
所以，笔者将“对RUP进行逆向工程”从“工程化的RUP剪裁过程”单独提出讨论。
另外，本文也不打算详细阐述逆向工程的工程化过程，那将是非常庞大和非常理论化的。
本文采取的方法是，列出逆向工程过程的产出产品的子集，而且每个产品的内容也仅涉及核心子集。
其实，如果不从理论化的角度讲，对RUP进行逆向工程其实就是个理解RUP的过程（不理解RUP就没用办法进行剪裁），因此，下面的阐述也是笔者对RUP的一点理解，抛砖引玉，敬请斧正。
一、需求
Rational的大师们在开发RUP时先要进行需求捕获，他们捕获到的需求肯定少不了下面的内容：
◆RUP将是一个有足够通用性的过程产品，将RUP适当剪裁后应能适合绝大多数项目。
（功能需求）
◆采用RUP作为开发过程，开发风险必须最小化。
（非功能需求）
二、分析
接下来进行分析，想必会是这样：
◆开发过程由多种“活动”组成。
◆每种“活动”生产出不同的“产品”，也可能多种“活动”生产出一种“产品”。
◆活动有业务建模、需求、分析和设计、实现、测试、实施、配置和变更管理、项目管理和环境。
（RUP的九个核心工作流）
◆产品有：
用例模型、分析模型、设计模型、源程序和测试报告等。
◆活动可以包含子活动，子活动之间可以并行进行，干脆把活动改称工作流，把子活动改称活动。
◆“产品”可以是成品或供演进的半成品，干脆把成品和半成品合称为“工件”。
三、设计
接下来进行设计，想必会是这样：
◆为了满足通用性需求：
借鉴面向对象的泛化思想（即参数化或模板），RUP只提供框架而和具体项目无关。
◆为了满足风险最小化需求：
引入阶段概念和迭代开发模型，以便给开发者足够多的机会，在付出太多代价之前放弃或调整开发。
四、实现
RUP的实现我们都看到了，就是那个可以在线查询的知识库，内容很丰富。
第三部分工程化的RUP剪裁过程
在对RUP进行了逆向工程，并且比较好地理解了RUP之后，还需要进行的两个步骤是RUP剪裁过程的核心部分，本段给出一种工程化的解决方案。
首先，讨论软件过程开发的需求工程；
然后，讨论软件过程开发的正向工程，即五步法；
最后，对五步法给出几点说明，着重说明五步法是如何降低RUP剪裁的复杂性的。
下面要阐述的工程化的RUP剪裁过程，不是放之四海而皆准的，但确实有一定的通用性。
一、软件过程开发的需求工程
这里，软件过程开发的需求工程，完全可以借鉴软件开发中的需求工程，包括需求捕获、需求分析、编写需求文档和需求评审。
1.需求捕获
首先明确项目环境，然后向项目所有涉及人员收集信息。
项目环境包括软件类型、软件规模、软件重要程度、开发人员素质、合作单位素质等，这些因素都会影响到将来软件过程的制定。
项目涉及的人员包括用户、开发人员、合同确定者和投标者等，从他们那里收集对软件过程的要求。
2.需求分析
研究采集到的要求，形成有条理的需求表述。
3.编写需求文档
将有条理的需求表述文档化。
4.需求评审
组织由上级领导、开发人员及其他人员参加的评审。
若评审未获通过，根据具体情况从上面三步的其中一步开始回溯，直至评审通过。
二、软件过程开发的正向工程
采用“五步法”。
一方面，五步法保留了RUP的优秀概念，如阶段、迭代、工作流、工件和角色等。
另一方面，五步法采用了一些旨在降低RUP剪裁复杂性的策略，在后面“五步法的几点说明”中有讲述。
1.确定本项目的软件过程需要哪些工作流
根据项目规模的大小不同，RUP的九大工作流并不总是需要的；
另外嵌入式软件项目一般不需要业务建模工作流。
虽然工作流中可以包含并行执行的活动，但本阶段并不关心这些，而是仅把工作流看成黑盒，也就是说工作流退化成了活动。
2.确定每个工作流产出哪些工件
因为很多开发单位还是评审传统形式的文档，因此，可以规定工作流产出某传统文档。
3.确定阶段间演进
RUP将开发过程分为四个阶段（初始阶段、细化阶段、构造阶段和移交阶段）是控制风险的很好的方法，确定阶段间演进就是要以风险控制为原则，决定每个阶段要执行哪几个工作流，每个工作流执行到什么程度，产出的工件有哪些，每个工件完成到什么程度。
4.确定阶段内的迭代计划
迭代是RUP非常强调的一个概念，可以进一步降低开发风险，在RUP的四大阶段（在后三个阶段进行迭代更常见）中，决定是否采用迭代开发，每次迭代开发的内容有哪些。
5.规划工作流内部结构
工作流不是活动的简单堆积，工作流涉及到角色、活动和工件，并且工作流的复杂程度和项目规模及角色多少等有很大关系。
因此，我们应首先决定本软件过程要设立哪些角色；
如果第二步中引入了传统文档，还要将传统文档映射到RUP工件；
最后，规划工作流内部的结构，通常用活动图的形式给出。
若想通过对RUP剪裁得到比较复杂的软件过程，无疑这一步是剪裁的难点。
三、五步法的几点说明
1.确定软件过程的时机
在实际中，确定软件过程的时机不是一成不变的。
比如，如果新项目和该项目组以前开发过的某个项目很相似，就可以在软件开发开始之前确定将采用的软件过程；
如果是不熟悉的项目，就可能在初始阶段完成后才能确定或修改要采用的软件过程；
如果项目有很多未知因素，迭代计划推迟到阶段开始前比较好，工作流规划也同样推迟。
2.五步法为何前瘦后胖
五步法中的五步，让人感觉前三步很“瘦”，而后两步比较“胖”，这是为什么呢？
其实，将迭代计划和角色设立都往后推迟，是为了使软件过程开发简单化。
软件过程开发主要有两种流派：
以活动为中心和以角色为中心。
而RUP的工作流这个核心概念是角色和活动并重的，通过适当推迟规划工作流，可以使RUP剪裁简单化。
五步法正是这样一种RUP剪裁过程：
它以活动为中心的，它的第一步就是确定活动；
并且它把角色的设立推迟到了最后，既降低了RUP剪裁的复杂性，又保留了工作流的优点。
3.传统文档和RUP工件的对应关系
传统文档和RUP工件之间，有时存在一定的对应关系，而且往往是一对多的关系。
因此五步法的第二步可以用传统文档，不仅是符合习惯的，也减少了软件过程开发先期阶段的细节，降低了RUP定制的复杂性。
到了第五步，再将传统文档分解成RUP工件，以利用RUP的工作流方面的指南。
传统的《软件定义文档》可以分解为RUP的scope、vision和features；
传统的《软件需求规格说明书》的非功能需求部分要包括RUP的businessrules；
等等。
一图胜千言：
RUP核心概念解析
作者：
温昱 来源：
希赛网 2008年1月2日 发表评论 进入社区
在实践中，笔者发现，对概念的理解不到位，特别是对概念之间的关系理解不到位，是阻碍不少人成功应用RUP的原因之一。
本文采用“为概念及其关系建模”的方法，对概念及其关系进行考察，以期深入理解RUP的核心概念。
1、弄清概念的必要性
随着软件学科和软件业的不断发展，“名词”越来越多。
但是，“名词”背后的“含义”也真的有如此之多的增长吗?
举个例子。
1986年，BarryBoehm提出了软件开发的螺旋模型。
从那时起，螺旋模型被当作软件开发的标准方法。
螺旋模型还有其他不同的常用名字，比如演进模型，或者迭代模型[1]。
类似的例子还有很多。
看来，软件界存在不少这种“新瓶装旧酒”的现象——一个新名词出现了，它可能仅仅是披着新的表达形式的外衣，而其含义其实和某个旧名词相同。
笔者认为，在软件学科飞速发展的今天，反而是踏踏实实搞清楚“变幻无穷”的诸多名词背后的真正含义，才是最便捷之道。
2、本文的方法：
一图胜千言
本文采用“为概念及其关系建模”这样一种方法，不仅考察单个名词的含义，还考察名词之间的关系。
一图胜千言。
一个概念的本质，往往需要从它同其他概念的关系中，得以体现。
不仅考察个体，还考察多个个体之间的关系，这种方法在系统论中，被比喻成“1+1>
2”。
令人愉快的是硬币的另一面，注重考察关系这种方法，从其成本角度而言却是“1+1<
3、RUP核心概念解析
3.1、任务来自问题
RUP著名的二维结构，其时间维相关的概念有阶段、迭代、里程碑等，内容维相关概念有工作流、角色、活动、工件等。
但笔者发现，不少人对这些概念理解不深，特别是对概念之间的关系把握不到位，造成实践中出现问题。
另外，就是迭代式开发——这种包括RUP在内的多种软件工程过程都一致推崇的最佳实践——和活动、工件这些基本概念有何关系。
不知道迭代和活动、工件的关系，实际应用RUP时又如何贯彻迭代式开发的思想呢?
还有，配置和变更管理对所有现代软件开发过程都是必不可少的支持活动，RUP更是将其列为“RUP的6大最佳实践”之一。
但笔者发现，不少开发人员认为配置和变更管理太麻烦，仅仅是因为他们没有理解配置和变更管理和工件的基本关系。
我们的任务，就来自于这些问题。
我可以用一幅图解决这些问题吗?
3.2、一图胜千言
下图是一幅UML类图，它概括了上述问题的相关概念，并着重表达了概念之间的关系。
本图的丰富语义，我们通过下面几节细细来分析。
3.3、角色执行活动，活动生产工件
任何软件工程过程，都少不了角色（role）、活动（activity）、工件（artifact）等概念（或者类似概念）。
这些概念本身很好理解。
角色是对个人或者作为开发团队的一组人的职责的规定;
具体人和角色的关系，好比人和帽子的关系。
活动就是角色执行的工作单元。
工件就是工作的成品或半成品。
倒是这些概念的关系显得更加重要。
角色的职责，具体体现在他执行活动和负责工件上。
工件是由活动生产出来的——工件是活动的输出;
比如制定《编码规范》。
然而，活动本身也可能以工件为输入——活动可能要求使用工件;
比如编码活动要参考《编码规范》。
还有一种关系，工件既是活动的输入又是它的输出——活动修改工件;
比如修改《编码规范》。
3.4、阶段和迭代：
提供不同级别的决策时机
尽早解决重大风险，是软件工程管理中的一条重要原则。
正如TomGlib所说：
“如果我们不主动化解风险，那么它们会自己找上门来。
”[2]心存侥幸是很危险的。
RUP是风险驱动的。
它将整个开发生命周期分为4个阶段：
初始阶段、细化阶段、构造阶段、移交阶段。
初始阶段着重化解业务风险，并确保所有涉众对项目达成一致的认识。
细化阶段主要化解技术风险，要定义并创建可执行的系统架构。
相对而言，当决定开始构造阶段的时候，风险已经比较小了。
当然，风险是动态变化的，构造阶段和移交阶段照样会有这样那样的风险存在。
RUP的每个阶段又可分为一到多个迭代周期。
采用迭代式开发，意味着有持续不断的反馈;
反馈是决策的基础，也是化解风险的基础。
迭代式开发的一个主要目的就是尽早降低风险，通过每次迭代中分析、按重要性排序并解决主要风险，来达到尽早化解风险的目的。
这个根据持续反馈来进行决策的时机，叫做里程碑（milestone）。
里程碑有2种，阶段结束对应的里程碑叫做主要里程碑（majormilestone）;
迭代结束对应的里程碑叫做次要里程碑（minormilestone）。
可以说，阶段和迭代，为开发团队提供了不同级别的决策时机。
上图清晰的表达了上述分析的思想。
里程碑分为主要里程碑和次要里程碑2种;
阶段可以包含多次迭代;
每个阶段必然有一个主要里程碑标识结束，每个迭代必然以一个次要里程碑标识结束。
迭代的具体进行，是要靠角色执行相关活动。
上图中的迭代和活动的多对多关系，精彩地反映了迭代开发的特点——每次迭代都执行多个（甚至全部）开发活动。
3.5、配置和变更管理支持迭代式的基于基线的开发
迭代式开发意味着每个后继迭代，都以前一个迭代为基础，不断地进化和完善系统，直至完成最终产品。
历史上有一段时期，为了强调这一点，RUP曾特意宣传“迭代和增量开发”。
建立并管理基线（baseline），为迭代式开发提供了有力支持。
基线的要点有二：
一是要通过评审，二是要受配置和变更管理控制。
IEEE对于基线的完整定义是：
已经通过正式复审和批准的某规约或产品，它因此可以作为进一步开发的基础，并且只能通过正式的变更控制过程进行改变。
配置和变更管理完成建立并管理基线的任务。
置于配置和变更管理之下的工件，称为配置项（configurationitem）——因此下图把配置项建模为工件的子类。
而基线就是有多个配置项组成的瞬时快照——因为受配置和变更管理控制是基线的必要条件。
上面讨论了“工件-配置项-基线”这些静态概念，下面再讨论一下相关动态概念。
任何工件，都有可能发生变更;
正如并不是所有工件都是配置项一样，变更也不一定都受控，比如，用于讨论的临时设计就不必受控。
只有配置项的变更，才是需要受配置和变更管理控制的。
到底哪些工件应当受控，是根据实践情况决定的，应当在规范性和灵活性之间权衡考虑。
3.6、发布是什么，发布不是什么
发布（release）是软件产品的一个稳定的、可执行的版本，它包括了发布说明、用户手册等相关工件。
单纯的文档或者不能执行的软件版本，并不是发布。
发布是某个迭代周期的成果，但是并非每个迭代周期都用发布。
图中表达得很明白，发布是特殊的基线。
这意味着发布不是单一的工件，而是工件集;
而且发布的工件都应当置于配置管理的控制之下，这是因为你必须标识和跟踪这些工件，开发团队或者用户的很多活动都和它们相关。
4、总结
UML已经广泛用于软件开发活动，可视化表达使得理解和解决问题变得容易。
本文是UML的另一个应用，它被用来明确概念之间的关系，希望对大家有所启发。
参考文献：
[1]GaryPollice等著，宋锐等译.小型团队软件开发：
以RUP为中心的方法.中国电力出版社，2004
[2]PerKroll等著，徐正生等译.Rational统一过程：
实践者指南.中国电力出版社，2004
作者简介：
温昱，架构设计师，松耦合空间（）创办人。
擅长面向对象、架构和框架设计，对设计模式、UML和软件工程有深入研究。
可以通过wenyu@和作者联系。
RUP：
通过用例应用需求管理（上）
RogerOberg、LesleeProbasco和MariaEricsson 来源：
RationalCorp 2008年1月2日 发表评论 进入社区
如果您对需求管理一无所知或者一知半解，但有志于改进需求过程，那么本文将为您提供一个框架，您可以利用它开发自己的方案。
用例和软件需求规约（SRS）
为了让读者更好地理解需求管理工作流程，作者从RationalSoftware的UnifiedProcess以及工业标准统一建模语言特地挑选了一些文档类型和需求管理工件予以说明。
UnifiedProcess和统一建模语言都推荐使用一种用例驱动的软件工程流程。
因此，本文描述了一种用于指定软件需求的用例驱动方案。
这些工作流程还可代替用例模型和用例，或作为它们的补充，与更传统的软件需求规约（如IEEE标准）一起使用。
流程时代的软件和系统开发
对大多数软件和系统开发团队来说，与过去自由的日子相比，20世纪90年代是一个强调流程的时代。
评测和验证有效的软件开发流程的标准得到推广和普及。
许多论述软件开发流程的书籍和文献以及关于业务建模和重建的的相关材料纷纷出版。
不断涌现出的软件工具已经帮助人们制定和应用有效的软件开发流程。
在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展，提高了系统质量。
既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢?
即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢?
随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量?
像往常一样，答案就在于该行业的人员、工具和流程。
需求管理通常在软件开发出现问题时作为解决方案提出来，但对于这门学科的改进则较少关注。
本文介绍有效需求管理流程的元素，特别强调成功实施需求管理所面临的障碍。
需求管理除了应用于纯软件项目以外，同样也应用于软件只占最终结果的一部分或根本不包括在内的项目。
为方便起见，本文以后将使用“系统”这个词来指代任何或所有这些项目。
然而，正是软件开发的抽象本质本身，或者和硬件一起，使需求管理复杂化了，因此本文的重点在于软件开发。
为什么要管理需求?
简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。
满足项目需求即为成功打下了基础。
若无法管理需求，达到目标的几率就会降低。
以下最近收集的证据很有说服力：
StandishGroup从1994年到1997年的CHAOSReports证实，导致项目失败的最重要的原因与需求有关。
[1]
1997年12月，ComputerIndustryDaily报导了SequentComputerSystems公司的一项研究，该公司对美国和英国500名IT经理作调查后发现，百分之七十六的受访者在他们的事业中经历过完全的项目失败。
其中提到最多的导致项目失败的原因就是“变更用户需求”。
[2]
避免失败就是一个很充分的理由。
提高项目的成功率和需求管理所带来的其他好处同样也是理由。
StandishGroup的CHAOS报告进一步证实了与成功项目关系最大的因素是良好的需求管理。
什么是需求?
理解需求管理的第一步就是对什么是需求管理达成共识。
Rational把需求定义为“（正在构建的）系统必须符合的条件或具备的功能”。
电气和电子工程师学会使用的定义与此类似。
著名的需求工程设计师MerlinDorfman和RichardH.Tha
升级会员 