|
在数学史上，悖论是一直困扰着数学家的难题。 1902年，英国著名哲学家、数学家罗素曾经提出一个著名的理发师悖论：在萨维尔村，唯一的一位理发师挂出一块招牌：“我只给村里所有那些不给自己理发的人理发。”有人问他：“你给不给自己理发？”理发师顿时无言以对。因为，他如果给自己理，那他就属于“给自己理发的人”，根据他自己所说，他就不应该给自己理发；他如果不给自己理发，也根据他所说，他就应该给自己理发。所以，他理也不是，不理也不是。 如果你还没有揭开Rational统一过程（Rational Unified Process，RUP）的神秘面纱，你可能也会遇到“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中测试工作流相关的角色，以及角色负责的工作。
不同的软件过程（如RUP和XP），过程模型会有很大不同。为了考察软件过程的共性，我们来研究软件过程的元模型。下图（来自参考文献[5]）显示了软件过程元模型。
软件过程元模型显示了任何软件过程都必不可少的角色（role）、活动（activity）、工作产品（work product）的概念。角色是对个人或作为开发团队的一组人职责的规定；具体人和角色的关系，好比人和帽子的关系。活动就是角色执行的工作单元。而工件是工作的成品或半成品。 角色的职责，具体体现在他执行活动和负责工件上。工件是由活动生产出来的——工件是活动的输出；比如制定《编码规范》。然而，活动本身也可能以工件为输入——活动可能要求使用工件；比如编码活动要参考《编码规范》。当然，工件既是活动的输入又是它的输出——活动修改工件；比如修改《编码规范》。
2、 2、 RUP实施 在上一部分，我们讨论了软件过程开发的相关理论。理论是用来指导实践的，RUP作为一种著名的软件过程，其实施照样离不开理论的指导。不破除对RUP的恐慌（“软件过程也是软件”理论解决该问题），不全面认识RUP（软件过程元模型理论解决该问题），不理解RUP实施的工程实质（软件过程的再工程理论解决该问题），就不可能充分发挥RUP的作用。 当然，本文介绍的三个理论着眼于大局的感悟，若要真正深刻地认识RUP，还有不懈地学习和实践才行。但是，倘若没有软件过程开发及再工程的理论指导，RUP实施将难免失于“莽撞”，有瞎子摸象、囫囵吞枣之嫌。这恐怕也是不少人使用RUP以及其他软件工程方法收获不大的根本原因所在。 接下来，我们以上述理论为指导，谈一些RUP实施中的具体问题。首先，从整个RUP实施的角度，讨论其宏观过程，并重点分析过程开发理论的指导作用。然后，是一个RUP定制的例子——软件项目外包管理，通过发现外包开发和自行开发的共同之处，从而在RUP的基础上定制外包管理过程。最后，以著名的EUP为例说明如何对RUP进行扩充，以启发读者，在掌握软件过程开发理论之后，其实可以进一步让RUP适应实际实践的需要。
2.1、RUP实施指南
在开发组织中引入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.2、RUP剪裁案例：外包管理
可以说，外包和经济全球化如影随形。 全球IT外包市场在2004年强劲地增长到了516亿美元，这是个让国内软件企业不得不动心的数字。但与印度等外包强国相比，国内软件企业在许多方面存在差距，其中管理就是一个回避不了的问题。 面对这种形势，本文的RUP剪裁案例，就举外包管理！ 那么，一个企业如何通过对RUP的定制，使它适合软件外包管理的要求呢？总体而言，软件的外包管理包括承包方的选择和外包开发的管理两大部分，由于篇幅所限，本文仅讨论外包开发管理。 软件项目外包开发有其显著特点，那就是承包方自己承担软件开发和人员管理方面的工作，但软件产品和与双方都相关的软件过程，则由委托方和承包方共同管理。因此，外包项目的管理可以分为3个阶段：项目启动，项目开发，项目验收。以上3个阶段和RUP的4个阶段有着良好的对应关系，如下图所示：
在RUP剪裁方面，用于管理自身开发和用于管理承包方开发，有很大的不同。比如，一方面，开发工作由承包方来做，所以在外包开发阶段，大多数核心工程工作流为空；但另一方面，承包方的开发过程不透明又非常危险，难以监控开发进度，所以多设立检查点非常有必要。 另外需要注意的是，外包的软件项目，往往是委托方自己的更大项目的子项目。这时，委托方还应着重考察双方软件过程的“兼容性”，不要在最后才进行集成，应当在早期的里程碑就持续不断的进行集成，并进行相关的测试和反馈。 总之，正如软件过程元模型理论告诉我们的，所有的软件过程都有共性。我们应当重视软件外包开发存在的新问题，但并不能因为“不熟悉”或“害怕新事物”，而演绎出“白马非马”的故事来。
2.3、他山之石：EUP简介
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]中指出：“大约每隔5至10年，软件界就会重定义‘问题’，将其焦点从产品转移到过程。”照此看来，没几年，软件过程也要进入“随需应变”时代了。 既然RUP很简单，那么为什么必须定制？答案就是，软件过程也应“随需应变”！
|
