RUP实施之夺命七招.docVIP

RUP实施之夺命七招 来源：赛迪技术天地 作者：张恂 Rational统一过程(Rational Unified Process，RUP)提供了一个极有价值的软件开发业务框架，它正在成为一个广受欢迎的当代软件开发过程的事实标准——它整合了公认的最佳实践，例如适应性的、迭代的和风险驱动的开发模式；它是由在大、小型系统开发中均具有丰富经验的世界级领导者设计的；它在应用和扩展上都很灵活，而且被正式的出版物以及相应产品很好地记录了下来。然而作为框架，必须根据每个项目团队及其环境的需要进行调整。RUP本来是用一种轻型和敏捷的方式来开发项目的，而不是被当作一个“万能尺码”的开发过程。若干因素妨碍了RUP的成功实施，其导致的结果往往非常糟糕。本文用略带一点俏皮的口吻，与大家分享一组常见的RUP应用陷阱。如果您的目标是让RUP实施的结果一塌糊涂，那么我们向您推荐以下七招。第一招：在RUP之上叠加瀑布思维您的开发过程是否有点像：(1)企图定义和稳定绝大部分的需求，然后进行签署；(2)基于需求，进行详细设计；(3)基于设计，进行实现；(4)进行集成、系统测试和部署。这是一个线性的、串行的瀑布型生命周期的典型例子，而且是一个最优先的、最棒的，也是最常见的让RUP实施完全失败的策略。如果您的开发过程看上去与这很像，那么祝贺您，您成功地没有采用RUP！关于瀑布型生命周期与迭代式开发最重要的一件事是，我们在20世纪60年代和70年代被误导了：许多人当时接受到的教育是瀑布式做法是聪明老练的。然而，历史研究表明，这一建议的出现并没有得到任何统计意义上的证据的支持，而且更为重要的是，当前的软件项目失败研究结论性地表明，瀑布型是风险最高、极易失败、低生产率以及高缺陷率的软件构建方法。如果您要一个软件项目失败，您应该遵循瀑布型做法！而与之相反，现在有极具说服力的证据表明，迭代和演进式方法(如RUP)能带来较低的失败率、更低的风险和更高的生产率。值得称道的是，美国国防部原本提倡瀑布过程和观点，在发现那么多采用了该方法的失败之后，不但放弃了对它的要求(如1988年的STD-2167A标准)，而且从1994年的报告开始，积极地鼓励采用更加现代化的迭代式生命周期来取代瀑布型做法。从发展的角度，瀑布型过程与20世纪60年代开发软件的随心所欲方式相比，它是一个相对合理的策略。这一做法借鉴了其他领域的工程和建造，但遗憾的是，未经对其应用于软件开发的真正适应性进行认真和严肃的研究，它就被广泛地传播和采用了，于是几代师生都不假思索地学习、不断地照搬它。不幸的是，如今仍有许多软件过程“专家”、咨询顾问、项目经理和过程工程顾问(例如某些带有瀑布型偏好的CMM实施顾问)似乎一点儿不知道已有的研究证据，仍然继续根据自己的主观意愿或信念而非统计意义上的证据来行事。有些东西必须像建筑那样被建造，然而人们发现软件通常不属于这一类。这有许多原因，最具有说服力的是一个错误的假定，即可以在项目的第一个阶段中定义绝大部分的需求。Capers Jones等人的研究粉碎了这一神话。如图1所示，在这项含有6700个项目的庞大研究中，蔓延的需求(在项目开始时没有预见到的需求)是软件开发业当中非常显著的一个事实，在普通项目中它大概占到了25%，而在大型项目中则占到50%。 需求变化呈常态 瀑布式价值观和做法是：(1)完成绝大部分的需求，隐含着假定那些以前没见过该产品的用户们能很好地定义这些需求；(2)根据能够精确地为一个定义很差的问题制定解决方案这一假设，进行详细设计；(3)尽管设计还没有被证实，而且往往不可能被证实，仍然进行系统的实现；(4)集成、测试和部署。瀑布型竭力回避需求变化的现实，它假定需求和设计能够正确地被指明和冻结，这与项目的现实严重不符。软件开发在设计和实现之前无法固定需求有许多原因，但不管什么原因，高明的应对方法不是去“对抗变化”，竭力固定需求，而正相反，应像Kent Beck积极主张的那样“拥抱变化”，并把这当作软件过程的一个核心驱动力。于是，在RUP当中，开发的行进表现为一系列的迭代，每个迭代都被时间盒限定在一个固定的工期(例如正好4周)当中，每次迭代结束时都将产生最终系统某个子集的一个稳定内部发布。在迭代式开发中，时间盒限定是一个关键的概念：它意在固定迭代的结束日期，而且通常不允许结束日期的推迟。如果无法满足所有的目标，那么就要从迭代中去掉一些需求，而不是延长当前迭代的工期。在一个迭代中，有一种类似微型瀑布的情况。首先挑选一小部分需求，相对全面地对其进行分析；用几天时间进行设计，然后迅速地对系统的这一部分开始实现、集成和进行实际的系统测试与压力测试。每次迭代的结束将产生一个可运行的部分系统，它能产生反馈