ITPub博客

首页 > 应用开发 > IT综合 > RUP的剪裁原理和剪裁过程 (转)

RUP的剪裁原理和剪裁过程 (转)

原创 IT综合 作者:worldblog 时间:2007-12-12 09:59:33 0 删除 编辑
RUP的剪裁原理和剪裁过程 (转)[@more@]RUP即Rational Unified Process,是Rational公司开发的软件过程产品。The Unified Software Development Process也指的是RUP,不过去掉了前面的公司名。本文分别采用“统一软件过程”和“RUP”作为其全称和简称。
  就笔者所了解,当前国内业界普遍关心的一个问题是:RUP的剪裁原理是什么,有没有工程化的RUP剪裁过程。本文将讨论上面两个问题。本文有不少观点来自个人心得,有不妥之处,敬请斧正。

第一部分 RUP的剪裁原理

  首先介绍“软件过程也是软件”这一著名原理,然后指明RUP的剪裁原理是:软件过程开发的再工程。

一、 软件过程也是软件


  软件工程大师Osterweil在其论文《Software Processes are Software Too》中高屋建瓴地指出:软件过程也是软件。软件有一个开发的过程,软件过程也有一个开发的过程;软件开发产出软件产品,软件过程开发产出过程产品;软件开发可以是一个演进过程,软件过程开发也可以是一个演进过程。

1. 软件过程也有一个开发的过程


  软件过程也是经过了需求捕获、分析、设计、实现和测试等活动才开发出来的。下面仅简单论述。软件过程开发中,需求是指采用该软件过程的目的是什么(高层需求),要用来指导哪些活动(需求);分析和设计是指,活动之间如何衔接甚至并行执行,各活动产出什么产品;实现是指,将软件过程文档化,相当于软件开发的coding;软件过程开发也有测试,不过是在脑子里run的,而上级领导用脑子run两遍批示通过就是验收测试。

  进一步讲,软件过程不仅有开发过程,而且有完整的软件过程生存周期。因为软件过程在开发出来之后,也有交付使用、维护升级直至废弃的过程。交付使用就是将软件过程实施,用于指导软件项目的开发。要是在使用软件过程时发现有错误之处(bug,需纠错性维护)或欠缺之处(新需求,需升级性维护),可以对原软件过程进行修改或增强。当其经过修改升级也不能满足指导开发的需要时,就将其废弃,软件过程生存周期结束。 顺便插一句,当前异常火爆的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的business rules;等等。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/10752043/viewspace-991629/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
  • 博文量
    6241
  • 访问量
    2462258