软件配置管理详解.pptVIP

配置项识别的参考标准： 可能被两个或两个以上组使用的工作产品； 无论是因为错误还是因为需求变更而导致变更的工作产品； 工作产品相关依赖，其中一个变更会导致另外一个变更； 对项目非常重要的工作产品（环境类文档应当属于这一类）。 机构应制定如下配置项标识命名规则： 文档类配置项命名规则， 文档版本编号规则， 代码类配置项命名规则， 单元（模块）源代码和执行码版本编号规则。 配置项识别及标识 编制配置管理计划 配置管理计划的形成时间：项目计划初步阶段形成草稿，项目计划细化阶段定稿，并与项目开发计划一起评审。 根据《机构标准软件过程》中的列表，识别本项目中的配置项，并作为配置管理计划的一部分。在项目经理的指导下，配置管理员完成配置管理计划。 明确各类基线包含的工作产品及建立的时间、标识等。 需求基线（SRS_BL）:在软件需求规格说明书批准时建立； 计划基线（PLN_BL）:在项目计划批准时建立； 设计基线（DESIN_BL）:在概要设计、详细设计和数据库设计批准时建立； 编码基线（CODE_BL）:在单元测试通过时为集成测试建立； 测试基线（TEST_BL）:在集成测试时通过为系统测试建立； 产品基线（RELEASE_BL）:在系统测试通过为产品发布时建立 配置管理计划——定义基线 在项目计划初步阶段，必须明确与需求相关的配置项及基线生成时间，配置库结构及权限。 确定职责和所需资源； 确定软件项目配置项； 确定基线条数、基线包含配置项、建立时间、审计人； 确定要执行的活动及活动的进度安排。 明确配置库目录及存取权限/方式； 确定系统的开发环境、测试环境、运行环境；配置库的备份方式。 配置管理计划文档化 配置管理审计 配置管理的审计活动一般分为两类，一是对基线的审计，二是对配置库的审计。基线审计是为了检查基线的正确性及一致性；配置库审计是为了保证配置库的完整性、可用性。 基线审计一般按下面步骤进行： 项目经理在基线生成之前填写《基线计划及跟踪表》； 由指定专人根据基线计划及跟踪表对配置库进行审计； 审计出的问题修改之后，由CCB批准后，配置管理员生成基线，并打基线标识。 在里程碑处或基线生成之后进行； 由配置管理员或项目经理指定负责人对配置库进行审计，填写配置审计报告； 主要内容包括：配置库结构是否正确，是否能正常签入签出；基线库的建立手续是否齐全；配置项版本历史信息是否正确； 质量保证工程师根据相关规程对配置管理过程进行审计，填写《QA阶段审计报告》中的“QA配置管理过程审计报告”，在确保配置管理活动按照要求开展。 配置管理审计 变更控制简述 变更控制做为配置管理的主要内容之一，在操作过程中有严格的控制流程，以保证配置项的一致性、有效性。一般变更控制的内容为： 确定变更批准人的责任范围和权限； 建立变更控制流程，实施变更控制； 对配置项变更进行管理； 对基线变更进行管理； 设立两个变更授权机构：CCB、项目经理； CCB成员为项目级的，可因项目的不同而有所不同，由总工程师在《项目任务书》中定义。 变更控制流程图 在项目立项时，根据项目规模和特点，确定变更授权机构及其职责，并纳入立项报告及计划阶段的配置管理计划； 确定变更等级：变更等级一般由项目经理判断，并在配置管理计划中描述各自控制的变更，建议若是影响需求基线和产品基线的变更以及严重影响项目进度、成本、产品质量的重大变更提交CCB控制；其他变更（如：文字编辑、格式调整）由项目经理控制。 变更控制活动 对评审定稿配置项（简称受控项，代码类指通过集成测试之后）和基线（有重大缺陷）的所有变更在实施前均要通过变更授权机构的评审和批准；变更过程必须记录在《配置项变更申请表。 变更控制流程适用于开发过程中所有配置项变更，非以上提到的项可不填写《配置项变更申请表》，但需在修订页中说明。 对于受控项，不论是项目经理还是CCB控制变更，其提请变更的流程相同，配置管理员只负责受控项标识更新和配置项变更状态报告的填写，不参与其它活动；所有《配置项变更申请表》由项目经理负责提交配置管理员纳入受控库；配置管理员提交配置项变更记录给相关受影响人员。 变更控制要求 变更控制流程 变更申请人填写配置项变更申请表说明问题来源或修改原因；变更对其他配置项的影响，估计变更对项目造成的影响等。对于代码类变更，可以记录在BUG管理工具里，而不填写专门的配置项变更申请表，但在项目经理分配BUG时，必须分析变更所需花费的工时、工作量、成本及变更带来的风险，并填写在BUG管理工具中。如果代码类变更，对里程碑有影响，则必须填写配置项变更申请表。 项目经理收到变更申请后，评估变更带来的影响、分析变更所需花费的工时、工作量、成本及变更带来的风险等，并将评估结果应写入“审批意见”栏；然后提交变更授权机构（比如，CCB），若是不需