9 项目实施指南
一个软件研发项目一般可以划分为三个阶段：计划阶段、开发阶段和维护阶段。然而从软件配置管理的角度来看，后两个阶段所涉及的活动是一致，所以就把它们合二为一，成为“项目开发和维护”阶段。
一个项目设立之初项目经理首先需要制定整个项目的计划，它是项目研发工作的基础。在有了总体研发计划之后，软件配置管理的活动就可以展开了，因为如果不在项目开始之初制定软件配置管理计划，那么软件配置管理的许多关键活动就无法及时有效的进行，而它的直接后果就是造成了项目开发状况的混乱并注定软件配置管理活动成为一种“救火”的行为。所以及时制定一份软件配置管理计划在一定程度上是项目成功的重要保证。
在“开发阶段和维护阶段”，软件配置管理活动主要分为三个层面，这三个层面是彼此之间既独立又互相联系的有机的整体。
（1） 主要由配置人员完成的管理和维护工作；
（2） 由系统集成员和开发人员具体执行软件配置管理策略；
（3） 变更流程。
|
软件阶段 |
活 动 |
活动说明 |
|
|
制定软件计划
|
一个项目设立之初，项目经理首先需要制定整个项目的计划 |
| 确定配置策略 |
配置管理委员会（CCB）根据项目的开发计划确定各个里程碑和开发策略 |
| 制定配置计划 |
配置人员根据CCB的规划，制定详细的配置管理计划，交CCB审核 |
| 批准配置计划 |
CCB通过配置管理计划后交项目经理批准，发布实施 |
|
开发阶段和维护阶段 |
确定初始基线 |
CCB设定研发活动的初始基线 |
| 配置库管理 |
配置人员根据软件配置管理规划设立配置库和工作空间，为执行软件配置管理做好准备；并定期进行备份和清理工作 |
| 授权开发 |
开发人员按照统一的软件配置管理策略，根据获得的授权的资源进行项目的研发工作 |
| 集成 |
系统集成员按照项目的进度集成组内开发人员的工作成果，并构建系统，推进版本的演进 |
| 管理基线 |
CCB根据项目的进展情况，并适时的建立基线，批准基线变更，保证开发和维护工作有序的进行。 |
| 产品发布 |
系统集成员进行产品集成，由CCB批准，进行发布 |
|
其 他 |
配置会议
|
CCB定期举行例会，根据成员所掌握的情况、配置人员的报告和开发人员的请求，对配置管理计划作出修改，并向项目经理负责。 |
| 配置报告和审计 |
配置人员定期向项目经理和CCB提交审计报告，并在配置管理例会中报告项目在软件过程中可能存在的问题和改进方案 |
| 变更管理 |
事件触发执行，由CCB批准、项目组执行，并执行审计 |
10 配置管理部署模型
基本过程
|
序号 |
阶段 |
活动 |
备注 |
1
|
获得相应管理权 |
|
|
| 1.1 |
|
建立相应负责团队
|
|
| 1.2 |
|
获得授权和资源 |
可召开启动会 |
2
|
评估配置管理现状 |
|
|
| 2.1 |
|
绘制和评估当前过程的控制图 |
可采用CMM标准 |
| 2.2 |
|
了解员工对配置管理的态度 |
|
| 2.3 |
|
了解组织的配置管理技术水平 |
|
| 2.4 |
|
了解领导期望 |
|
| 2.5 |
|
编制并评审评估报告 |
获得“现状信息” |
3
|
配置工具选择 |
|
|
| 3.1 |
|
编制、评审《评估评分表》
|
|
| 3.2 |
|
评估配置工具和供货商 |
|
| 3.3 |
|
收集其他用户的使用经验 |
|
4
|
配置过程定义 |
|
制定配置管理过程草案 |
| 4.1 |
|
利用“现状信息”和收集的经验
|
|
| 4.2 |
|
制定新的过程 |
|
| 4.3 |
|
评审新过程，并建立新的过程基线 |
|
5
|
试点 |
|
|
| 5.1 |
|
选定试点项目 |
|
| 5.2 |
|
确定试点负责小组 |
|
| 5.3 |
|
定义试点成功标准和进度 |
|
| 5.4 |
|
试点项目人员培训 |
|
| 5.5 |
|
试点改进 |
同时对草案进行改进 |
| 5.6 |
|
试点总结/推广 |
完成正式过程的发布 |
6
|
全面实施 |
|
|
| 6.1 |
|
组建相应部门和团队
|
|
| 6.2 |
|
制定各个项目的实施计划 |
|
| 6.3 |
|
配置管理知识、过程、工具的培训 |
|
| 6.4 |
|
帮助各个项目向新过程迁移 |
|
| 6.5 |
|
日常监督、抽查、沟通 |
|
| 7 |
结束 |
|
总结、奖励 |
相应操作文件 对应过程：2.2了解员工对配置管理的态度
建立一个CHECKLIST，来进行调研，如下
|
序号 |
调查内容 |
调查结果 |
| 1 |
原来是否有过类似尝试，成功或者失败了 |
|
| 2 |
是否有由于配置管理不好造成的痛苦经历 |
|
| 3 |
对建立配置管理过程是否支持 |
|
| 4 |
是否觉得配置管理过程会压抑创造性 |
|
| 5 |
是否觉得配置管理过程太繁琐 |
|
| 6 |
对配置管理是否有不合理的期望 |
|
| 7 |
是否有些急功近利 |
|
| 8 |
是否对实施配置管理工具感兴趣 |
|
| 9 |
个人英雄主义和分工协作那个是主流 |
|
对应过程：2.3了解组织的配置管理技术水平
建立一个CHECKLIST，来进行调研，如下
|
序号 |
调查内容 |
调查结果 |
| 1 |
是否已经有了配置管理过程，运作时间
|
|
| 2 |
是否使用了配置管理工具，使用时间 |
|
| 3 |
是否接受了配置管理的专门培训，培训时间 |
|
| 4 |
对配置管理过程的认识程度 |
|
| 5 |
对配置管理工具的使用程度 |
|
| 6 |
企业员工的基本素质和学习能力 |
|
对应过程：3.2评估配置工具供应商
建立一个CHECKLIST，来进行调研，如下
|
序号 |
调查内容 |
调查结果 |
| 1 |
工具可以解决当前问题，满足当前需求吗？
|
|
| 2 |
产品的市场地位 |
|
| 3 |
产品价格 |
|
| 4 |
与现有环境的兼容程度 |
|
| 5 |
运行能力（峰值情况、成熟性、稳定性） |
|
| 6 |
是否支持未来需求 |
|
| 7 |
是否具备：工作空间管理 |
|
| 8 |
是否具备：版本控制 |
|
| 9 |
是否具备：配置报告 |
|
| 10 |
是否具备：过程支持 |
|
| 11 |
是否具备：安全和保护 |
|
| 12 |
是否具备：工具集成 |
|
| 13 |
是否具备：构造支持 |
|
| 14 |
是否具备：图形界面 |
|
| 15 |
是否具备：自定义支持 |
|
| 16 |
是否具备：发行管理 |
|
| 17 |
是否具备： WEB支持 |
|
对应过程：3.2评估配置工具供应商
建立一个CHECKLIST，来进行调研，如下
|
序号 |
调查内容 |
调查结果 |
| 1 |
配置管理服务从业时间
|
|
| 2 |
成功案例数量和质量 |
|
| 3 |
培训、技术支持队伍 |
|
| 4 |
提供的培训和指导，以及其他服务 |
|
| 5 |
近期关于配置服务的商誉、资产、销售额 |
|
| 6 |
地理位置、服务及时性 |
|
对应过程：4.2制定新的过程
1. 配置管理过程至少应当包括的内容：配置标示、配置控制、报告、审计
2. 在考虑工具纳入配置过程中应当考虑下表内容
|
序号 |
考虑内容 |
| 1 |
从配置过程中分解出那些是事务性、那些是创造性的工作 |
| 2 |
考虑事务性工作的繁重程度和精度要求程度，理出一个“自动化优先级” |
| 3 |
根据过程，确定工具可以运用的地方 |
| 4 |
根据“自动化优先级”选择那些工具功能进行自动化 |
| 5 |
考虑使用工具功能自动化的前提和结果 |
| 6 |
划分出“自动化”和“人工”的接口，并清晰描述 |
| 7 |
调整过程要素，适应工具，从而形成一个纳入了工具的配置管理过程 |
| 8 |
考虑这个过程的适用性和效益 |
对应过程：6.1组建相应部门和团队
负责配置管理部署和实施的团队必须包括
|
序号 |
团队成员 |
职责和要求 |
| 1 |
组长
|
负责管理小组，并负责配置管理的部署和实施 |
| 2 |
技术人员 |
负责考虑将要和配置工具集成的各类工具之间的接口 |
| 3 |
配置专家 |
配置工具精通、配置管理理论知识熟悉 |
| 4 |
过程专家 |
负责过程建模和主要的过程分析工作 |
| 5 |
配置管理人员 |
负责评审新过程，并提供原来配置管理的经验 |
| 6 |
项目经理 |
负责评审新过程，并提供配置管理适应于项目的参考 |
对应过程：6.2制定各个项目的实施计划
计划应当包括的内容：
|
序号 |
计划内容 |
| 1 |
目标和完成标准 |
| 2 |
投资和收益分析 |
| 3 |
阶段划分和进度安排 |
| 4 |
资源投入安排 |
| 5 |
人员分工和组织 |
| 6 |
风险管理 |
|