UML软件工程组织

随需而变的RUP
来源:《程序员》

在数学史上,悖论是一直困扰着数学家的难题。

1902年,英国著名哲学家、数学家罗素曾经提出一个著名的理发师悖论:在萨维尔村,唯一的一位理发师挂出一块招牌:“我只给村里所有那些不给自己理发的人理发。”有人问他:“你给不给自己理发?”理发师顿时无言以对。因为,他如果给自己理,那他就属于“给自己理发的人”,根据他自己所说,他就不应该给自己理发;他如果不给自己理发,也根据他所说,他就应该给自己理发。所以,他理也不是,不理也不是。

如果你还没有揭开Rational统一过程(Rational Unified ProcessRUP)的神秘面纱,你可能也会遇到“RUP悖论”!

看看Per Kroll怎么说,“实际上,RUP并不困难也不复杂。编写本书的目的就是要告诉读者RUP实际上是很简单的[1]。”再看看Gary Pollice说些什么,“为每一个项目定制你的过程。不要假定一个开发过程的每一个方面都自动地适合你当前的情况[2]。”于是,“悖论”似乎出现了——既然RUP很简单,那么为什么必须定制?

现实情况就是这么尴尬,不少人还在坐等RUP会突然变得简单!醒醒吧,看看方法论学家Peter Coad给我们的提醒——如果发生了问题,请上升一个层次,找出该做的事情[3]

Peter Coad大师的教诲没错!

本文上升一个层次,站在“软件过程层”,介绍过程开发理论;然后列举三个案例,从而示范如何运用这些理论,帮助我们在日常工作中切实有效地进行RUP实施。本文虽然不是专门探讨Agile和其他软件过程的,但笔者认为,过程开发理论对理解所有软件过程都是大有裨益的。

 

1 过程开发理论

在这一部分,我们将介绍3个软件过程开发的相关理论。首先,是“软件过程也是软件”的观点,它让我们感悟到,软件过程是也开发出来的。接下来,在过程开发的基础上,探讨过程开发的再工程理论。而过程开发再工程理论的基础,是要首先对软件过程有深刻理解,所以,我们最后探讨软件工程元模型的相关理论。

 

1.1、软件过程也是软件

文本框: “比较方法能够使人们……发现问题,找到突破口……”
——鲍健强,《科学思维与科学方法》

 

 

 

 


      不知道如何定义“大师”,但大师说话总是很有启发性。当看到面向对象的“单一职责原则”被表述成“一个类应该仅有一个引起它变化的原因”时,我就想这太Cool了——多么具有可操作性的表述呀——谢天谢地没有表述成“一个类应当只有一个职责”。

“软件过程也是软件”就是很有启发性的大师级表达。一个类比,有四两拨千斤之妙!

《软件过程也是软件》是软件工程大师Osterweil的一篇论文[4],论文中指出:软件过程也是软件。软件有一个开发的过程,软件过程也有一个开发的过程;软件开发产出软件产品,软件过程开发产出过程产品;软件开发可以是一个演进过程,软件过程开发也可以是一个演进过程。

软件过程也是经过了需求捕获、分析、设计、实现和测试等活动才开发出来的。软件过程开发中,需求是指采用该软件过程的目的是什么(高层需求),要用来指导哪些活动(需求);分析和设计是指,各活动产出什么产品,活动之间如何衔接,以及如何并行执行;再看看实现,通常我们将软件过程文档化,相当于软件开发的coding;还有测试,软件过程开发的测试,最常见的是相关人员通过头脑来进行“运行”和评审。

进一步讲,软件过程不仅有开发过程,而且有完整的软件过程生存周期。因为软件过程在开发出来之后,也有交付使用、维护升级直至废弃的过程。交付使用就是将软件过程实施,用于指导软件项目的开发。然而,如果在使用软件过程时发现有错误之处(bug,需纠错性维护)或欠缺之处(新需求,需升级性维护),就需要对原软件过程进行修改或增强。直到有一天,当其经过修改和增强也不能满足指导开发的需要时,就意味着要将其废弃——于是软件过程生存周期结束。

 

1.2、软件过程的再工程

文本框: “随着科学的不断分化、细化、专业化,使学科的门类和专业越来越细,越来越多。”
——鲍健强,《科学思维与科学方法》

 

 

 

 

     软件工程技术历经三十年的发展,目前已进入成熟期。随着学科的深入发展,软件开发技术中,分化出了软件再工程技术。同样,软件过程开发中,也分化出了软件过程的再工程技术。

再工程(reengineering)是一个工程过程,它通过逆向工程、重构和正向工程的组合,将现有系统重新实现为一种新的形式。下图(来自参考文献[4])显示了正向工程、逆向工程、再工程等概念的关系。

 

 

当实施软件的再工程时,软件理解是再工程的基础和前提。而对于软件过程来说,需要对软件过程进行再工程时,也必须全面到位的理解该软件过程,这也是开展软件过程再工程的首要条件。下一节,我们就来讨论软件过程的元模型。

 

1.3、深入认识软件过程:软件过程元模型

文本框: “RUP本身是使用与软件设计中相似的技术设计的。”
——Per Kroll,《Rational统一过程:实践者指南》

 

 

 

 


     模型从某一角度出发,捕捉事物最重要的方面,而忽略或简化其他方面。软件过程作为一个研究领域,也可以用模型来刻画它的领域知识。比如,下图的模型刻画了RUP中测试工作流相关的角色,以及角色负责的工作。

不同的软件过程(如RUPXP),过程模型会有很大不同。为了考察软件过程的共性,我们来研究软件过程的元模型。下图(来自参考文献[5])显示了软件过程元模型。

 

 

软件过程元模型显示了任何软件过程都必不可少的角色(role)、活动(activity)、工作产品(work product)的概念。角色是对个人或作为开发团队的一组人职责的规定;具体人和角色的关系,好比人和帽子的关系。活动就是角色执行的工作单元。而工件是工作的成品或半成品。

角色的职责,具体体现在他执行活动和负责工件上。工件是由活动生产出来的——工件是活动的输出;比如制定《编码规范》。然而,活动本身也可能以工件为输入——活动可能要求使用工件;比如编码活动要参考《编码规范》。当然,工件既是活动的输入又是它的输出——活动修改工件;比如修改《编码规范》。

 

2、 2 RUP实施

在上一部分,我们讨论了软件过程开发的相关理论。理论是用来指导实践的,RUP作为一种著名的软件过程,其实施照样离不开理论的指导。不破除对RUP的恐慌(“软件过程也是软件”理论解决该问题),不全面认识RUP(软件过程元模型理论解决该问题),不理解RUP实施的工程实质(软件过程的再工程理论解决该问题),就不可能充分发挥RUP的作用。

当然,本文介绍的三个理论着眼于大局的感悟,若要真正深刻地认识RUP,还有不懈地学习和实践才行。但是,倘若没有软件过程开发及再工程的理论指导,RUP实施将难免失于“莽撞”,有瞎子摸象、囫囵吞枣之嫌。这恐怕也是不少人使用RUP以及其他软件工程方法收获不大的根本原因所在。

接下来,我们以上述理论为指导,谈一些RUP实施中的具体问题。首先,从整个RUP实施的角度,讨论其宏观过程,并重点分析过程开发理论的指导作用。然后,是一个RUP定制的例子——软件项目外包管理,通过发现外包开发和自行开发的共同之处,从而在RUP的基础上定制外包管理过程。最后,以著名的EUP为例说明如何对RUP进行扩充,以启发读者,在掌握软件过程开发理论之后,其实可以进一步让RUP适应实际实践的需要。

 

2.1RUP实施指南

文本框: “如果开发团队不清楚要达到哪些目标,那么用于改进过程的时间很容易超出计划。”
——Per Kroll,《Rational统一过程:实践者指南》

 

 

 

 

在开发组织中引入RUP及其支持工具,原因是因为它们可以提高项目质量,从而得到实际的商业利益。但是,RUP的引入对开发组织来说,意味着改变(或部分改变)以前的工作方法,其中必然会有一定风险。让我们根据相关理论分析解决之道。

回忆一下Osterweil的教诲:软件过程也是软件!想必擅长软件开发的你,已有了思路了——让我们有理有据地进行需求采集、分析、设计,之后“开发出”适合团队实际情况的RUP实施方案。有了实施方案,评审通过之后,就成为指导团队协作的管理依据,这是RUP实施已完全明朗。

下面结合参考文献[1]给出的相关指南,对上述过程进行工程化的描述。在项目开始时引入RUP,共需如下5个步骤:

1.评价(assess)。评价开发团队以前在软件过程方面遇到的问题,明确过程实施的目标。

2. 计划(plan)。计划的具体实施过程,包括相关培训。

3. 3    配置和定制(configure and customize)。剪裁和定制RUP,使它符合项目的实际情况。

4. 4 执行(execute)。进行培训,并启动项目,在项目中运用你定制的RUP

5. 5 评估RUP的实施情况,为以后改进做准备。

由上面的步骤可以看出,RUP的实施不是一个单纯的过程开发与执行,而是过程的再工程与执行。RUP包含了众多的软件开发最佳实践,以及详尽的工作指南,在RUP的基础上进行再工程是明智的。由此还可以看出,我们介绍的软件过程再工程理论,对指导具体RUP实施工作,是非常有意义的。

需要说明的是,最好在项目开始时(而不是项目进行到一半时)就实施RUP,这样可以避免项目过程中工作方法的改变引起的复杂问题。

 

2.2RUP剪裁案例:外包管理

文本框: “经济繁荣带来的是竞争的日趋激烈,适应新的竞争环境,处理好内部资源与外部资源的整合问题,已成了企业实现竞争力的关键因素,这也是企业与业务伙伴形成战略外包关系的根源。”
——胡少华,《外包制胜·序言》

 

 

 

 

可以说,外包和经济全球化如影随形。

全球IT外包市场在2004年强劲地增长到了516亿美元,这是个让国内软件企业不得不动心的数字。但与印度等外包强国相比,国内软件企业在许多方面存在差距,其中管理就是一个回避不了的问题。

面对这种形势,本文的RUP剪裁案例,就举外包管理!

那么,一个企业如何通过对RUP的定制,使它适合软件外包管理的要求呢?总体而言,软件的外包管理包括承包方的选择和外包开发的管理两大部分,由于篇幅所限,本文仅讨论外包开发管理。

软件项目外包开发有其显著特点,那就是承包方自己承担软件开发和人员管理方面的工作,但软件产品和与双方都相关的软件过程,则由委托方和承包方共同管理。因此,外包项目的管理可以分为3个阶段:项目启动,项目开发,项目验收。以上3个阶段和RUP4个阶段有着良好的对应关系,如下图所示:

RUP剪裁方面,用于管理自身开发和用于管理承包方开发,有很大的不同。比如,一方面,开发工作由承包方来做,所以在外包开发阶段,大多数核心工程工作流为空;但另一方面,承包方的开发过程不透明又非常危险,难以监控开发进度,所以多设立检查点非常有必要。

另外需要注意的是,外包的软件项目,往往是委托方自己的更大项目的子项目。这时,委托方还应着重考察双方软件过程的“兼容性”,不要在最后才进行集成,应当在早期的里程碑就持续不断的进行集成,并进行相关的测试和反馈。

总之,正如软件过程元模型理论告诉我们的,所有的软件过程都有共性。我们应当重视软件外包开发存在的新问题,但并不能因为“不熟悉”或“害怕新事物”,而演绎出“白马非马”的故事来。

2.3、他山之石:EUP简介

文本框: “重型方法不会消失的,在某些情况下,它们很适用。”
——Scott W. Ambler,《空手道和太极拳》[7]

 

 

 

 

    RUP的剪裁与实施,普遍存在一个误解,那就是RUP剪裁只能简化RUP,而不能扩充。

EUP网站[8]声称,根据Ronin International公司的经验,RUP并不总是足够。笔者也有过这样的经历:一次讲授RUP课程的时候,有位听众问,哪个工作流负责软件过程改进,我说,没有,需要扩充RUP

EUP(Enterprise Unified Process)是著名的RUP扩充方案,如下图(来自参考文献[8])所示。在阶段方面,增加了初始前阶段(Pre-Inception phase)、产品化阶段(Production Phase)和废弃阶段(Retirement Phase)。在工作流方面,增加了8个:1个核心支持工作流,7个核心企业工作流。

以软件过程改进工作流为例,下图(来自参考文献[8])显示了其工作流程。

EUP也象RUP一样提供详尽的工作指南,例如下图(来自参考文献[8])是“创建过程”活动的工作流明细。

 

可见,RUP不仅可以定制,还可以扩充。掌握了软件过程开发理论,软件过程“随需应变”不再是遥不可及的天方夜谭。

 

3、软件过程也应“随需应变”

本文立足于软件过程开发理论的讨论,揭开了RUP的神秘面纱;然后选取了几个RUP实施中的问题,结合理论进行讨论和解决。

由于是“上升一个层次”进行思考,我们还得到很多启发。

软件过程和软件一样,是我们“开发”出来的。软件项目各不相同、开发团队情况各异、商业环境瞬息万变,这些都是决定软件过程开发或再工程的需求。面对如此复杂的软件过程需求,不禁让人想起了软件开发领域“随需应变”的口号来。而Roger S. Pressman在其经典著作《软件工程:实践者的研究方法》[9]中指出:“大约每隔510年,软件界就会重定义‘问题’,将其焦点从产品转移到过程。”照此看来,没几年,软件过程也要进入“随需应变”时代了。

既然RUP很简单,那么为什么必须定制?答案就是,软件过程也应“随需应变”!

 


 

版权所有:UML软件工程组织