本文来自于 Rational Edge：软件开发组织执行SEI的能力成熟度模型(CMM)可能会由于在 Rational 统一过程或RUP中缺乏一个软件质量保证(SQA)工作流而失败。本文描述了一个虚拟的 SQA 工作流，其源自于 Leslee Probasco 的RUP的十点要素。
存在有九个RUP工作流程，包括了需求、项目管理、配置 & 变更管理，甚至还有业务建模——但是没有一个是用于软件质量保证(SQA)的。这种明显的疏忽对寻求SEI的软件成熟度模型(CMM)的项目和组织是非常棘手的1，因为SQA的关键过程域(KPA)承载了成熟度模型的重要工作。自从有了需求管理的KPA，其可以精细地映射到Rational 统一过程?或RUP?的需求工作流，还有项目管理(包括计划和监控)和配置管理的关键过程域同样分别精细地映射到RUP的项目管理以及配置和变更管理的工作流，难道只是对SQA没有吗?
我开始回答这个问题，并且沿着这条路揭示了CMM以及RUP实质的SQA工作流中的质量的真正含义。
SQA和CMM
软件工程协会(SEI)将软件质量保证设置为CMM的基础级别2。他们也将所有其它关键过程域的验证和确认放在了质量保证中。此外，CMM反复强调高级管理人员必须“保护个人履行SQA责任”，因为这有可能会给发现不一致问题的职员带来管理上的问题。如此强调 SQA活动和需求，为什么没有一个SQA工作流，以及更重要的是在RUP中没有一个SQA角色呢?一个SQA工作流会提供活动，还有工件，以及在其它RUP流程里提供个人执行SQA的各自的检查点。
虚拟的SQA工作流
为了解决这个迷惑，我寻找什么是已经被证实了的RUP里有效解决问题的实践。RUP是通过软件工程过程权威(SEPA)进行质量保证--尽管理论上是SQA，这是一个组的职责，而不是一个个体的角色。我做了一个练习，创建了RUP的一个视图，以满足SQA角色的需要，如同在CMM中所确定的那样。我特别实行了Leslee Probasco在“RUP的十点要素--一个有效开发过程的精髓”中所描述的建议，3来创建一个真实的SQA工作流。在她的论文(在此以后用RUP10来指代)，Probasco推荐形成一个有标签的笔记本4，每个标签代表每个要素(V-PRI-BAPE-CU)，用来管理一个项目的基本元素。所以我创建了一个这样的笔记本，每个标签包括了RUP的必要工件描述，复制了相关活动以产生RUP已经定义的元素和所有的检查点，还有个人记录和元素以支持各自的要素。
例如，对于必要元素 #1，远景(Vision)，我插入了远景工件的副本，还有RUP中用于产生远景的三个活动：开发远景，管理依赖关系，以及评估概念构架的生存能力。我也包括了远景和涉众请求检查点的一个副本。接着我执行了这些活动，将结论文档化，并且正如Probasco建议的那样，我产生了很多记录。5在我对RUP和CMM有了更多认识时，我增加了更多的工件、活动、检查点以及指南到相应的标签中。
远景
远景的开发包括了很多的便笺，因为众多的远景都会成为想法。远景必须有效地针对涉众所面对的问题。SQA工程师既不是一个RUP角色，也没有一个所描述活动和定义工件的工作流视图。为了更好地理解我的涉众-SQA工程师的需要，我借用了Alan Cooper的The Inmates Are Running the Asylum及其开发“角色”的实践。6我的SQA工程师角色是一位名叫Ginger的女性。她在RUP和CMM的训练方面属于中级水平的工程师。在对分配给她的项目上涉及到的过程不一致发出错误警告上，她并不是资历较浅的，但是在期望她挑战那些拥有更多过程或领域专门知识上也并不是经验丰富的。
Cooper 这样形容“消极角色”：某些人，对于他们，过程不是在被构建，而是需要更好地理解过程需求。这些消极的角色代表了30多个的RUP角色，这些角色是Ginger必须接口的，因为她提供了对产生的工件产品和执行的活动的客观评审。这些个人在软件开发实践方面接受了更细致的训练和练习。Ginger不在项目中，并且没有涉及到所有的项目活动，因此对她来说，很容易遗漏或误解一些事情。当 Ginger足够成熟来理解她的个人职责时，她被期望知道在什么时间和执行哪些验证和确认活动，她不被期望能够强制过程一致性(就是SEPA)。进一步的，与CMM一致的是，当她尝试“逐步升高项目外部的偏差”到可执行级时，她被保护以免于可能的“敌对人员行为”。
计划
对于Ginger，计划就是遵循RUP10，并产生一个虚拟的SQA工作流程。过程规模度量的搜集、分析和报告是Gingre必需进行的工作。她知道在RUP里有多少工件、活动、角色评审和评估的步骤，因此能够更好地计划和安排她的任务时间表。在冲突解决领域，她知道工件的所有人和活动的产生者不是相同的角色这种情况，她或许能通过确保这些工件的检查点或规格特征在每个团队成员间达成一致。这些在RUP10素材笔记本里的表述帮助Ginger知道了什么、在哪里以及如何开始她的质量审核。她的工作流程将会遵循RUP过程相关的素材和图表，作为RUP的工件和活动集合。我也会进一步使用RUP10来配置一个过程，集中在质量和使用的规模度量上(通过阶段和角色来统计工件和活动)。
风险
对Ginger而言，计算风险意味着将场景脚本化。成功和可选场景揭示了在项目中冲突可能出现的地方。CMM通过重复使得履行SQA角色的个人需要得到保护这点非常清晰。因此，虚拟的SQA工作流程需要揭示潜在的危险领域。如果Ginger的老板是项目经理，对她的职业生涯有什么影响?如果她识别了一个不一致问题，但是项目不能按照过程来解决它，那么她必须把这个问题进行上报到这个经理之上。此风险的缓解包括确保过程是明确的，并且在冲突可能出现的区域，在C级别(CIO，COO，等)上得到管理委员会的批准。
问题
对Ginger而言关键问题是术语。RUP和CMM都有大量的词汇。当在审计期间发现过程中有一个不一致问题时，在挑选出什么是必需的和什么仅仅是方针上可能会有一些困难。当不一致的问题在项目中出现时，开发过程就变成了存储库，每个人都从中寻找为他们自己辩护或攻击其他人的东西。过程的机械模仿变成了会议和电子邮件中的标准操作流程。管理是强迫的、迫不得已的，间歇前进。因此，“捕获一个公共词汇表”的RUP活动--特别是评价结果的步骤--需要非常仔细地来解决这个问题。所有过程的涉众--经理，实施人员，以及Ginger--必需同意 1)什么是过程所必需的，2)在项目开始前什么只是一个方针。
业务用例
识别业务用例是简单的。组织的高级管理人员建立业务用例来完成CMM的合格证明。这依次变成个人、项目和组织过程所有者的业务用例。
构架
所有构件设计模式的来源，模型-视图-控制器8，是此项任务的理想构架设计模式。在这个经典模式中，模型是过程(RUP)，视图是Ginger的，并且控制器是质量活动(包括测试)。质量活动必须使成本和进度处于项目的控制之下，以满足CMM的精神。其它设计模式也在过程定义里也有一席之地，也就是维护和支持。这些模式包括反射(变更工作产品以变更开发者的行为)，仲裁人(解决冲突--对SEPA有益)，以及命令链(提升远离项目的不一致)。
产品
Ginger的一个虚拟SQA工作流包括了RUP工件及其检查点、活动及其步骤的度量和总结，和计划不同CMM活动的角色总结。她也有一个RUP10要素的笔记本，分别按照RUP和CMM的相关项进行了裁剪，包括了将RUP映射到CMM的IBM白皮书。她现在可能正用这项信息来计划并执行其工件的过程审计。这个视图让她知道：
1)哪些RUP的产品工件有检查点;
2)哪些工件推荐为必需的，哪些工件对于一个给定的阶段是可选的;
3)哪些活动具有称为“结果的评估和验证”的步骤，以及谁来验证它们。
例如，软件需求规格说明书(SRS)工件是需求详细说明人负责的。它有定义的检查点，是详细说明软件需求活动的结果，也是由需求详细说明人执行的。它是定义测试方法活动的一个输入，定义测试方法活动包含评估和验证你的结果(对于测试设计人员)和确认测试动因(由测试经理)。Ginger需要确保担任测试设计人员和测试经理角色的个人被包含在需求的评审中，并且她可能使用检查点来执行分别的产品审计。Ginger现在知道如何有效地和高效地报告产品和过程度量给SEPA。
评估项目管理者联盟
Ginger对过程的评估需要检查在开始的时候先检查利己主义(她的和我的)。我们必需保持关注，并且为了避免被她的批评观点所泄气，我需要对他们加以分类，或者是 1)一个过程的误传，这需要修正，或者 2) 一个过程需求的误传，这需要澄清。同样地，当在她的项目中发现偏离时，Ginger必需将她的评估展现为建设性的批评;出于同样原因，当她发现指示一致时，她必须提供积极的反馈。所有这些都需要进一步发展和改进过程。
变更
管理材料的变更是非常不正式的，并且及时地根据Ginger的需要进行管理。简单的日期和时间标注还有电子邮件日志这样指示变更的基本解释是不足的。
用户支持
对Ginger提供支持如此简单，就象是重新建立特定的RUP工作流、角色、活动、工件或CMM关键实践。RUP10论文展示了过程建立、配置和监控的一个清晰路径。
结束语
使用RUP10为Ginger建立一个虚拟的SQA工作流是富于挑战性的和有益的，因为正如我所发现的，质量的概念出现在RUP的任何地方。关于SQA工作流的一个明显之处是在测试工作流和要求评估的已定义活动中。然而，带有检查点以及工件和活动集合在测试或其它流程中的地方的工件数量，以及涉及到的多个角色，要求每个人想到Ginger。质量活动不是被限制为由一个指定的角色执行的一个单一活动或一组活动。而且，SQA角色是在所有的角色中共享的，而不是从这个包中分离出去的。组织必需依靠其所有的员工来在每个点上确保质量，一个产品就是在这些点上被定义、设计、实现、配置、评审、测试和发布的。Ginger只不过是这个负责质量的抽象角色的实现--一个使用Cooper术语“角色”：当所有的角色都执行分配给他们的活动时，我们必须考虑这个角色的多个方面。
备注
1 因为质量保证被植入了CMM和集成CMM(CMMI)的阶段，因此在本文的上下文中，区分对于区别两个模型不是必需的。我简单地查阅了整个“CMM”。有关CMM和软件CMMI更多的信息，以及关键过程域。
2 带有特别是级别1的CMM过程成熟度的基础等级(2)。
3 参见“The Ten Essentials of RUP：The Essence of an Effective Development Process”，Leslee Probasco, IBM Rational 白皮书
最新内容请见作者的GitHub页：http://qaseven.github.io/
