CMMI 3级精简并行过程综述

bankit

16.4.5 主要步骤
[Step1] 准备评审
        评审员与作者共同确定评审的时间、地点、设备、人员等。起草并将《技术评审通知》发布给相关人员。
        评审员阅读（了解）工作成果及相关材料、评审规程、检查表等。
[Step2] 评审
        [Step2.1] 介绍
        评审员介绍本次评审的议程、重点、原则、时间限制等。
        作者扼要地介绍工作成果。
        [Step2.2] 识别缺陷和问答
        评审员根据“检查表”认真查找工作成果的缺陷。
        作者回答评审员的问题，双方要对每个缺陷达成共识（避免误解）。
        [Step2.3] 讨论缺陷解决方案
        作者和评审员共同讨论缺陷的解决方案。
        对于当场难以解决的问题，由双方商定“是否有必要继续讨论”或者“另定时间再讨论”。
        [Step2.4] 给出评审结论
评审员给出评审结论和意见。评审结论有三种：
（1）        工作成果合格，“无需修改”或者“需要轻微修改但不必再审核”。
（2）        工作成果基本合格，需要作少量的修改，之后通过审核即可。
（3）        工作成果不合格，需要作比较大的修改，之后必须重新对其评审。
[Step3] 修正、跟踪与审核
        [Step3.1] 修正与跟踪
        作者修正工作成果，消除已发现的缺陷。
        审查员跟踪每个缺陷的状态。
        [Step3.2] 提交审核
作者消除所有已发现的缺陷后，再将修正后的工作成果递交给审查员审核。
        [Step3.2] 审核工作成果
审查员审核修正后的工作成果。审核结论有两种：
（1）修正后的工作成果合格。
（2）修正后的工作成果仍然不合格，需重新修改，重复[Step3]。
16.4.6 输出
        该工作成果的《技术评审报告》。
        根据评审报告修正后的工作成果。
16.4.7 结束准则
        工作成果中所有已识别的缺陷都已经被消除。
16.4.8 度量
        评审员统计工作量和上述文档的规模，汇报给项目经理。

bankit

16.5 实施建议
        对于重要性和复杂性都很高的工作成果，建议先在项目内部进行“非正式技术评审”，然后再进行“正式技术评审”。
        技术评审应当与质量保证有机地结合起来，请质量保证人员参加并监督正规技术评审是很好的方式。
        技术评审应当与配置管理有机地结合起来，规定没有通过技术评审的工作成果不允许成为基准文件（Baselined）。
        建议机构采用统一的缺陷跟踪工具，使得技术评审所发现的缺陷能被及时地消除，不被遗漏。

bankit

评审计划

bankit

评审通知

bankit

评审报告

bankit

评审检查单

bankit

第17章 配置管理

配置管理（Configuration Management, CM）的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。配置管理是对工作成果的一种有效保护。
配置管理过程域是SPP模型的重要组成部分。本规范阐述了配置管理过程域的四个主要规程：
        制定配置管理计划 [SPP-PROC-CM-PLANNING]
        配置库管理 [SPP-PROC-CM-LIB]
        配置项版本控制 [SPP-PROC-CM-VERSION]
        配置项变更控制 [SPP-PROC-CM-CHANGE]
上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。
本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改本规范，然后推广使用。

bankit

17.1 介绍
项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等，它们都应当被保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分门别类、有条理地保存起来。
凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI），配置项主要有两大类：
（1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。
（2）项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是值得保存。
每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。
基线（Baseline）由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应于开发过程中的里程碑（Milestone），一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。
所有的项目成员都要使用配置管理软件来保护自己的工作成果。机构应当采用统一的配置管理软件，常见的配置管理软件有Microsoft的Visual SourceSafe和Rational的ClearCase等。为了提高配置管理的效率和安全性，机构应当有专门的配置管理员（角色）。配置管理员为每个项目制定《配置管理计划》，创建和维护配置库。
鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（Configuration Control Board, CCB）。CCB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。对于配置管理而言，CCB是决策者，而配置管理员是执行者。
如果机构的各个项目紧密相关（例如一个产品线下的多个项目），建议机构设立公共的CCB，这个公共的CCB对所有项目的配置管理拥有决策权。如果机构的各个项目相对独立，那么每个项目可以设立各自的CCB。CCB的决策采用“少数服从多数”原则。
配置管理的流程如图17-1所示。

图17-1 配置管理流程图

bankit

一、制定配置管理计划
配置管理员制定《配置管理计划》，主要内容包括配置管理软硬件资源、配置项计划、基线计划、交付计划、备份计划等。CCB审批该计划。
二、配置库管理
配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。配置管理员定期维护配置库，例如清楚垃圾文件、备份配置库等。
三、版本控制
在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比老版本“好”，所以不能抛弃老版本。版本控制的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。
配置项的状态有三种：“草稿”、“正式发布”和“正在修改”，本规程制定了配置项状态变迁与版本号的规则。
四、变更控制
在项目开发过程中，配置项发生变更几乎是不可避免的。变更控制的目的就是为了防止配置项被随意修改而导致混乱。
修改处于“草稿”状态的配置项不算是“变更”，无需CCB的批准，修改者按照版本控制规则执行即可。
当配置项的状态成为“正式发布”，或者被“冻结”后，此时任何人都不能随意修改，必须依据“申请－审批－执行变更－再评审－结束”的规则执行。
五、配置审计
为了保证所有人员（包括项目成员、配置管理员和CCB）都遵守配置管理规范，质量保证人员要定期审计配置管理工作。配置审计是一种“过程质量检查”活动，是质量保证人员的工作职责之一。请参考质量保证规范SPP-PROC-QA，此处不再论述。
        配置管理过程域产生的主要文档有：
        《配置管理计划》，模板见 [SPP-TEMP-CM-PLAN]。
        《配置库管理报告》，模板见 [SPP-TEMP-CM-LIB]。
        《配置项变更控制报告》，模板见 [SPP-TEMP-CM-CHANGE]。

bankit

17.2 制定配置管理计划
17.2.1 目的
        制定配置管理计划，以便有计划地开展配置管理工作。
17.2.2 角色与职责
        配置管理员制定《配置管理计划》。
        CCB审批《配置管理计划》。CCB的人数视项目的规模而定。通常CCB由项目经理、资深项目成员等人组成，项目经理为CCB负责人。CCB的决策采用“少数服从多数”原则。
17.2.3 启动准则
        《项目计划》已经制定
        配置管理员和CCB已经确定。
17.2.4 输入
        《项目计划》