IBM Rational SDP 助力 CMMI 流程改进 - ChinaAET电子技术应...

IBM Rational SDP 助力 CMMI 流程改进
唐李刚 时间:2007年08月20日
字 体:大中小
关键词:用例软件开发产品生命周期工作流管理层
IBM SDP 是 IBM 针对软件开发而推出的一整套解决方案平台，它的全称是 IBM Rational软件开发平台 (Software Development Platform) 。它使得软件开发组织能够更有效地开发软件产品，提高软件质量，保证开发进度、控制开发成本。
软件开发的四项基本原则
IBM SDP 中集中体现了以下软件开发的基本原则：
迭代化开发：有效控制项目风险、增加项目预见性、尽早地发现软件产品中的缺陷；
以架构为中心：采用可视化建模技术来构建以构件为基础的系统框架，有效地管理系统的复杂度，增强系统的灵活性和可扩展性；
持续地质量验证：在整个产品生命周期中持续地验证软件质量，确保产品满足客户的需求，并且构造一个高性能、高可靠的软件系统；
管理软件资产和变更：在整个产品生命周期中管理好企业的软件资产，并对所有的变更请求进行管理，支持虚拟团队的并行开发。
按角色分工的工具平台
IBM SDP 中包括了支撑整个软件开发生命周期所需的工具，这些工具是以开发人员的角色来组织的。
角色
开发工具
业务分析员
Rational RequisitePro, Rational Software Modeler
系统架构师
Rational Software Architect / Rational Software Modeler
Rational Rose XDE
软件工程师
Rational Application Developer / Rational Software Architect
Rational Rose XDE, Rational PurifyPlus
质量工程师
Rational  Functional Tester, Rational Performance Tester
Rational Robot
项目管理人员
Rational Unified Process, Rational RequisitePro
Rational ClearQuest, Rational ClearCase
Rational TestManager, Rational ProjectConsole
Rational Portfolio Manager
CMMI 模型简介
CMMI 模型的内容
CMMI 是一个应用于流程改进的模型，在 CMMI 中制定了流程改进的目标和最佳实践，它为需要提高自身开发能力的软件组织提供了一个参考标准和实践指南，并且这个标准是在前人的实践经验上总结出来的，具有很强的可实践性。
CMMI 模型的内容分为“需要的(required)”、“期望的(expected)”和“用于提供信息(informative)”三类。
需要的： CMMI 中定义了24个过程域(process area)，每个过程域都有一到四个特定目标(specific goals)；另外，针对于所有的过程域，也定义了一组共性目标(general goals)。
期望的：针对每一个目标，CMMI 定义了一组推荐的实践(practices)，通过实施这些实践可以帮助软件组织达到相应的目标。
用于提供信息：另外，CMMI 中也提供了其他一些用于辅助提供信息的内容，如：相关过程域、典型工作产品、实践与目标关系表等。
CMMI 的表示方法
由于 CMMI 是对几种不同的成熟度能力模型的集成，它的源模型有着不同的表示形式，相应的 CMMI 也有“连续式”和“阶段式”两种不同的表示方法。“连续式”模型没有规定在流程改进过程中对于过程域选择的次序，各个组织根据自己的实际情况来选择从那些过程域入手；“阶段式”模型则为流程改进提供了预定义的路线图，每一个阶都有一组相应的过程域，如果满足了某一阶段中的所有过程域目标，我们称该组织达到了该成熟度等级。
应用IBM SDP 帮助 CMMI 流程改进实践
IBM SDP 为流程改进提供了工程技术手段
CMMI 为软件组织的流程改进提供了一个系统的框架，但是它所提供的只是一个流程框图架，在实践过程中还需要具体工程技术的支持。如对于CMMI 中的每一个目标，CMMI 定义了一组特性实践和共性实践来达到该目标，但这些实践只是提出了在具体实践过程应该注意的事项，并没有列出具体可采用的工程技术。因为作为一个标准，它不可能局陷在某一特定的工程技术之上，不同的软件组织可以采用不同的技术手段来达到相同的目标。
IBM 的 SDP 正好作为一种特定的工程技术解决方案为 CMMI 流程改进提供了一种具体可操作的实践手段。以下以 CMMI 中两个相关的过程域“需求管理”和“需求开发”为例，展示 IBM SDP 解决方案是如何来实现每一个特定目标的。 CMMI 过程域“需求管理”的SDP 实现
CMMI 模型元素
描述
IBM SDP 解决方案
目的
需求管理 - 管理项目中产品和构件的需求，从而能够及时发现需求、项目计划和工作产品之间的不一致性
RUP 需求方法集提供支撑该流程域的所有目标和实践
SG1
管理需求，及时发现需求和项目计划以及其他工作产品之间的不一致性
RUP 中对于需求进行了分类(业务需要、产品特性、软件需求等)，并在不同的需求类型之间和其他工作产品之间建立追踪关联，以此来管理开发过程中所产生的不一致性
SP 1.1
与需求提供者在需求的含义上达成一致理解
RUP 建议采用用例模型的方式来描述需求，从而最大限度地保证双方对于需求的理解是一致的
SP 1.2
从项目参与者那里获得需求的承诺
RUP 中的前景(Vision)文档定义了项目开发的目标和范围，并需要获得项目参与者的认可
SP 1.3
在项目的发展过程中管理需求的变更
ClearQuest 为产品生命周期过程中的需求变更提供了全程的控制
SP 1.4
维护需求和需求、项目计划以及其他工作产品之间的双向追踪性
RequisitePro 提供了不同类型的需求之间以及从需求到设计、测试用例等其他工作产品之间的追踪性
SP 1.5
发现需求和项目计划以及其他工作产品之间的不一致性
通过追踪性关联，RequisitePro 可以自动地报告需求和其他工作产品之间所产生的不一致性
CMMI 过程域“需求开发”的SDP 实现
CMMI 模型元素
描述
IBM SDP 解决方案
目的
需求开发 - 开发并分析客户、产品和构件的需求
SG 1
收集涉众的需要、期望、约束和接口，并将其转换成为客户需求
RUP 需求方法集中的“理解涉众需要”这一工作流明细详细定义了如何收集涉众需要的过程
SP 1.1
收集涉众在产品生命周期各个阶段的需要、期望、约束和接口
同上
SP 1.2
将涉众的需要、期望、约束和接口转换成为客户需求
RUP 需求方法集中的“定义系统”这一工作流明细详细定义了如何将涉众需要转换成为客户需求的过程
SG 2
对客户需求进行提炼和细化来开发产品和构件需求
RUP 中将客户需求进一步提炼成为产品特性
SP 2.1
基于客户需求来建立和维护产品和构件需求
同上
SP 2.2
为每一个构件分配需求
可以为每一个构件(子系统)定义一个用例模型来将系统需求分配下去
SP 2.3
标识接口需求
用例模型定义的就是系统对外的接口
SG 3
分析和确认需求，并开发一个所需要的功能性定义
RUP 中利用用例模型来描述系统所有的功能性需求
SP 3.1
建立和维护操作概念及相关场景
每一个用例都包含了多个相关的应用场景
SP 3.2
建立和维护一个所需要的功能性定义
用例建模技术可以详尽地描述所有的系统功能
SP 3.3
分析已获得的需求，确保他们是必要和充分的
通过业务需要、产品特性和软件需求之间的追踪性，确保了所有的需求都是必要和充分的
SP 3.4
分析需求来综合考虑涉众的需要和约束(从而决定项目成本、进度、性能、功能、可重用性、可维护性、风险等)
需求是项目经理进行项目计划的重要输入
SP 3.5
确认需求，保证生成的产品能够在用户不同的技术环境中按要求来工作
RUP 中的迭代化开发方法在每一个迭代中都对产品需求进行确认和验证，以保证生成的产品是可用的
方法和工具并重
需要避免的一个常见误解是 IBM SDP 不仅仅是一个软件工程工具集合，其中更重要的是包含了一整套指导软件工程实践的方法论，具体体现在 Rational Unified Process 和 Rational SUMMIT Ascendant 这两个产品中。我们在使用 IBM SDP 中的所有工具时都离不开相关方法论的指导，在开发的过程中掌握一个好的开发方法是成功的关键，工具只有在好的开发方法的指导下才能发挥作用；反过来好的方法也需要高效的工具支持来提高工作效率和质量，两者是相辅相成的。
在 CMMI 流程改进的过程中，很多过程域目标可以通过部署工具平台来直接完成，也有一些目标需要应用 RUP 或 SUMMIT 中的流程方法来实现，尤其是一些涉及到与其他软件团队和个人协作的过程域目标，如供应商合同管理和组织级过程管理等，更多地是要实践 IBM SDP 中方法流程。
另外，CMMI 非常强调流程的制度化(Institutionalization)，通过提升流程的制度化水平（”Performed” -> “Managed” -> “Defined” -> “Quantitatively Managed” -> “Optimizing”）来不断地改进现有的开发流程，这部分要求直接体现在共性目标和实践中。这就要求软件组织的各级管理层非常重视和支持相关的流程改进工作，制定各种规章制度来保证流程的实践；并且要做好全体项目开发人员的培训工作，让他们认识流程改进的目标和过程，将流程改进工作落实到项目开发的每一个环节。
总结
总之，基于 CMMI 模型的流程改进是一项非常艰巨而复杂的工作，并不是应用某一些工具平台就可以达到相应的成熟度等级。在流程改进的过程中，经常需要对现有的工作流程做出一些痛苦的改动，所以取得管理层和所有相关人员的支持是一个关键。另外要明确流程改进的目的，必须把流程改进与业务目标联系起来，这样才能够取得实际有效的结果，否则易流于形式而达不到实际的效果。