1. 引言
本文对 Rational 软件开发过程(Rational Software Development Process)的原理和结构给出了高度的描述,它是:
它具有足够的普遍性,可以在规模与应用领域方面,为各个软件产品和项目量身订做。
2.总体软件生命周期
2.1 两种视角
Rational 过程可以从两种不同而又密不可分的视角来观察:
2.2 周期和阶段
从管理的角度,即从业务和经济的角度来看,对应项目的进展,软件的生命周期包含四个主要阶段:
完成这4个阶段称为一个开发周期, 它产生的软件称作第一代(generation)。 除非产品的生命结束, 一个现有产品可以通过重复下一个相同的起始、细化、构建和移交四阶段,各个阶段的侧重点与第一次不同,从而演进为下一代产品。 这个时期我们称之为演进(evolution)。最后伴随着产品经过几个周期的演进,新一代产品也不断被制造出来。
例如,演进周期的启动可能由以下这几项触发:用户建议增强功能、用户环境的改变、重要技术的变更,以及应对竞争的需要。
实际中,周期之间会有轻微重叠:起始阶段和细化阶段可能会在上一个周期的移交阶段未结束时就开始了。
2.3. 迭代
从技术的角度来看,软件开发可以视为一连串的迭代过程,通过这些迭代被开发的软件得以增量演进。 每次迭代都以一个可执行的产品的发布而结束, 该产品可能是完整版本的一个子集,但从工程的或用户的角度来看是有用的。 每次发布都伴随一些支持性工件:版本描述、用户文档和计划等。
一次迭代包括以下活动: 计划、分析、设计、实施和测试。 根据迭代在开发周期中所处位置的不同,这些活动分别占不同的比例。
管理角度和技术角度之间是协调的, 而且各个阶段的结束还和各次迭代的结束保持同步。
换句话说,每个阶段可以分为一次或多次迭代过程。
(注意:本图中每阶段的迭代数目仅为示意)
但是,这两个角度(管理角度和技术角度),不仅仅只是保持同步,它们还具有一些完全相同的里程碑,它们共同贡献出一些随时间演进的产品和工件。 一些工件更多地处于技术方面控制之下,另一些工件更多地处于管理方面的控制之下。见第五节。
这些工件的可用性、工件是否满足所建立的评估标准,是构成里程碑的主要具体元素,比日历牌上的日期提供了多得多的内容。
像周期一样,迭代之间也会有轻微重叠。即第N次迭代的计划和构架在第N-1次迭代还未结束时就开始了。有时候,迭代也会平行进行:一个工作于系统某一部分的小组,可能在某个迭代内没有可交付的工件。
2.4.区别
对于不同的项目而言,每个阶段的侧重点,入口和出口准则,一个开发周期的各个工件,以及各次迭代的数目和长度都会不同。这主要取决于作为过程判别式的的四个主要项目特征。按照影响程度降序排列,它们是:
2.5工作量和日程安排
各阶段在工作量和时间安排上是不同的。尽管由于不同项目类型之间相差会很大,一个典型的中等规模项目的最初开发周期可以预计为下面的比率:
起始阶段 | 细化阶段 | 构建阶段 | 移交阶段 | |
工作量 | 5% | 20% | 65% | 10% |
日程安排 | 10% | 30% | 50% | 10% |
可以用下图表示:
但是对于一个演进周期来说,起始阶段和细化阶段可能大大缩减。使用特定工具和技术(如应用程序构建器),构建阶段可以远远小于起始阶段和细化阶段的总和。
3. Rational 过程的各个阶段
3.1. 起始阶段
这个阶段产生一个预测产品的最初设想,并将其转换为一个实际的项目。本阶段的目的是建立一个新产品或一次大的更新的业务案例,并且指定项目的范围。
对于一个新产品的开发,本阶段的主要结果是得到一个"做还是不做"的决定以进入下一阶段,并投入一定的时间和资金来详细分析构建什么、能否构建,以及如何构建。
对于一个现有产品的演进,这会是一个简短的阶段, 主要看用户或客户的要求、问题报告,或是新的技术动态。
对于一个契约性的开发,是否进行项目的决定取决于在特定领域的经验、以及组织在此领域的竞争力和市场情况。这里起始阶段可以归结为一个参加投标的决定,或投标活动本身。该决定可能是基于一个现有的研究原型,其结构对最终软件可能合适,也可能不合适。
入口准则:
对于一项需要的描述,可以采用以下形式:
出口准则:
通常在初试阶段结束时,我们将得到:
3.2. 细化阶段
本阶段的主要目的是更彻底地分析问题域,定义构架并使之稳定,确定项目的最大风险。这样在本阶段结束时,我们可以得到一个关于下2个阶段如何工作的综合计划:
在这个阶段,建立了一个可执行的构架原型;它至少实现了初始阶段识别出的最关键的用例 ,解决了项目的最大技术风险;根据范围、规模、风险和项目新颖程度的不同构架原型需要一次或多次迭代。这是一个生成高质量代码(这些代码成为架构基线)的演进原型,但是也不排除开发出一个或几个试探性的、一次性原型,以降低开发的风险:对需求、可行性、人机界面研究、向投资者演示等的精化。在本阶段的结束时,仍然会产生一个"做还是不做"的决定, 以确定是否要真正投资构建这个产品(或参与合同项目的竞标)。
此时产生的计划一定要足够详细,风险也必须充分降低,可以对开发工作的完成进行精确的成本和日程估算。
入口准则:
出口准则:
3.3. 构建阶段
本阶段可以划分为数次迭代,不断充实构架基线,向最终产品逐步演进或增量演进。在每次迭代过程中,上个阶段(细化阶段)的工件得到扩充和修正, 但它们最终将随着系统向正确和完整的方向的演进而稳定下来。在这个阶段,除了软件本身,还生成一些新的工件:文档(既有内部使用的文档,也有面向最终用户的文档)、测试床及测试套件、部署附件,以及用于支持下一阶段的部署辅助(例如销售辅助)。
对每次迭代,都具有:
入口准则:
出口准则:
更新后的产品和工件,另外还有:
到构建阶段的后期,必须完成以下工件,及本阶段最后一次迭代额外的出口准则:
3.4. 移交阶段
移交阶段是将产品交付给最终用户的阶段。 它涉及销售、打包、安装、配置、支持用户社区和做出修正等.
从技术角度来看,伴随本阶段迭代的是一次或多次发布:`beta' 版发布、正式版发布、修补bug , 或增强版发布。
当用户对产品满意时,本阶段即告结束。 例如,契约性开发时正式验收, 或者产品有关的所有活动都已结束。 此时,某些积累的资产可以加以整理,以为下一个周期或其他项目重用。
入口准则:
出口准则:
3.5. 演进周期
对于重要的演进,我们应用整个过程递归,仍从起始阶段开始一个新的周期。因为我们已经有了一个产品,所以比起一个初次开发的产品,起始阶段可能大大缩短。细化阶段也可能缩小范围,而在计划方面的关注程度要大于分析或构架的演进方面。需要指出:周期之间可以略有重叠。
较小的演进可以通过延长移交阶段或增加一两次迭代来完成。
移交阶段可以以一个终结过程而结束,即产品不再演进了,但是为了终结它,需要采取一些特定的动作。
4. Rational过程中的活动
Rational 过程中各个阶段的名称(如起始、细化、构建、移交)与描述高级活动的术语(如分析、设计、测试等)相差甚远。 因此我们容易理解某种活动的进行并不局限于某个特定阶段,也与其他作者、标准及特定领域的所使用的术语无关。这些活动确实发生,但它们在每个阶段和每次迭代中的程度有所不同。下图表明了活动重点如何随时间的推进而发生演进。
图中活动重点的变化也说明尽管每次迭代在形式上都是"相似"的,但它们的性质和内容却是随时间而改变的。
这还表明,一项活动的结束并不总意味着另一项活动的开始,即并不是分析完成了才开始设计,而是这些活动相关的各种"工件"在随着开发者对问题或需求的理解的加深也不断得到更新。
最后,在一个迭代过程中,计划、测试和集成这些活动不是集中堆积在开发活动的开始和结束阶段,而是增量地分布在整个开发周期的各个阶段、每次迭代之中。 它们并不表现为开发过程的某个独立的阶段或步骤。
尽管具体的项目有具体的区别,但对于一个中等规模、初次开发的典型项目来说,其开发周期中各种活动的比例如下:
计划与管理 | 15% |
分析/需求 | 10% |
设计/集成 | 15% |
实施/功能测试 | 30% |
度量/评估/验收测试 | 15% |
工具/环境/变更管理 | 10% |
维护(开发过程中的修补) | 5% |
5. 生命周期工件
开发过程不是文档驱动的:它的工件中必须一直包括软件产品自身。文档应该十分精简,数目不能太多,应只保留那些确实从管理或技术的角度有真正价值的文档。 Rational 建议保留以下典型的文档集。
5.1管理工件
管理工件不是产品,而是用来驱动或监控项目进展、估计项目风险、调整项目资源,以及使客户或投资者对项目保持一定的"可见性" 的。
5.2技术工件
它们或者是交付的产品,可执行的软件及手册,或者是一些用于制造产品的蓝图,这些产品包括软件模型、源代码和其他有助于理解和演进产品的工程信息。
本文第3部分中列举的入口准则和出口准则可以映射到这11类文档之中。
上面介绍的这套文档可以依照具体项目的类型进行扩充和删减,一些文档可以合并。 文档不必一定是纸张形式---也可以是电子表格、文本文件、数据库、源代码的注释、超文本文档等等---但相应的信息资源必须被清楚地识别,易于访问,也要保存一些历史记录。
5.3需求
Rational 软件开发过程也不是需求驱动的。 在产品演进的周期中,需求表现为不同的形式:
6. Rational过程的例子
按照2.4节中所述的区别,Rational 过程采用不同的形式。 这里有两个极端的例子。
6.1大型契约性软件开发的Rational过程
对这个软件开发项目,Rational 过程分为3个阶段建立招标, 对应3个不同类型的合同。
因为用户需要更高的可视性来评估项目,还因为项目涉及大量人员和组织,开发过程应更加正规化,要比小型、内部的项目更加重视书面工件。第5部分列出的11类文档都以某种形式或名称存在。
6.2小型商业软件产品的Rational过程
在按规模分类的过程家族的另一端,是小型的商业软件开发。它的流动性更强一些,只有有限的正规性, 表现为一些主要的里程碑和有限的文档集:
软件结构、软件设计、开发过程可以通过代码本身或软件开发环境来进行文档化。