配置管理

配置管理1识别并记录产品、成果、服务或部件的功能特征和物理特征；控制对上述特征的任何变更；记录并报告每一项变更及其实施情况；支持对产品、成果或部件的审查，以确保其符合要求。-PMBOK2008辨识与定义系统中的项目、控制它们在生命周期中的改变、记录并报告它们的状态、提出变更要求，以及验证这些项目的正确与完整性。-IEEE一组用来控制变更的活动，其方法包括：辨识容易改变的工作产出、建立它们之间的关系、定义管理不同版本的机制、控制加入的改变、审查并报告所做的变更。-Pressman配置管理基本概念2定义：审查所有变更请求，批准变更，并管理对可交付成果、组织过程资产、项目文件和项目管理计划的变更的过程。对于大型的软件开发项目，无控制的变更将迅速导致混乱，使整个项目无法顺利进行下去而失败。变更控制的对象主要指配置库中的各基线配置项变更控制3配置项：一个产品在生命周期的各个阶段所产生的各种形式和各种版本的文档、程序及其数据的集合中的每一个元素，称为该产品配置中的一个配置项。基线，由一个或若干个通过评审并得到确认的配置项组成，是项目进入下一个生命周期阶段的基准已经过正式的评审和批准。作为项目发展和产品升级的基础。其变更必须遵循《变更控制规程》的约定。配置项和基线4为开发工作提供了一个定点和快照。新项目可以从基线提供的定点建立，作为一个单独分支，新项目将与随后对原始项目所进行的变更进行隔离。各开发人员可以将建有基线的工作产品作为他在隔离的私有工作区中进行更新的基础。当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。基线目的5需求基线（SRS_BL）：《用户需求说明书》、《软件需求规格说明书》经过评审。计划基线（PLN_BL）：详细计划经过评审。设计基线（DESIN_BL）：在概要设计和详细设计阶段结束后，设计阶段工作产品经过了评审。实现基线（CODE_BL）：代码和集成测试计划、用例、报告等工作产品经过了评审。测试基线（TEST_BL）：系统测试计划、用例、报告等工作产品经过了评审。发布基线（RELEASE_BL）：通过软件系统验收测试与正式的配置审核，产生了作为最终产品交付用户的配置项的集合。常用基线6配置管理活动关系建立配置管理环境配置项入库CM周报基线建立和发布CM阶段报告识别配置项制定配置管理计划产品发布变更管理配置审计7配置管理员阅读《项目计划（草稿）》，并参照项目选定的标准、过程、规程等与项目经理一起，识别出需要受到管理和控制的工作产品，并明确相关信息，包括：配置项名称、包含内容、受控级别、入库时机和准则、何时设立基线、责任人等登记到《配置管理计划》中的配置项列表内参考《配置库管理规程》制订配置项标识规则配置项列表和配置项的标识规则是《配置管理计划》的组成部分识别配置项8代码类配置项（源代码、可执行代码以及相关的数据文件）的划分由项目组结合项目具体情况确定（例如，一个单元或模块的代码作为一个配置项），代码类配置项的命名必须结合软件产品的特征，而版本编号则应符合机构统一规定。开发环境、测试环境和运行环境描述，单独成文，并作为单独的配置项进行管理。文档类配置项，比如：需求类文档、计划类文档、设计类文档、测试用例/方案文档、测试报告、用户手册等。实际执行时项目组应遵照机构标准并结合项目具体情况加以适当裁剪。配置项分类9配置项识别的参考标准：可能被两个或两个以上组使用的工作产品；无论是因为错误还是因为需求变更而导致变更的工作产品；工作产品相关依赖，其中一个变更会导致另外一个变更；对项目非常重要的工作产品（环境类文档应当属于这一类）。应制定如下配置项标识命名规则：文档类配置项命名规则，文档版本编号规则，代码类配置项命名规则，单元（模块）源代码和执行码版本编号规则。参考标准及标识10CM工程师需要在项目开始的早期策划配置管理活动根据配置管理活动策划的结果，编写《配置管理计划》《配置管理计划》作为项目整体计划的一部分，需与《项目计划》一起进行评审，评审通过以后需要得到高层经理的批准方可生效《配置管理计划》的内容和形式请参考《配置管理计划模板》输出通过评审，并经高层经理批准的《配置管理计划》制定配置管理计划11按照《配置管理计划》的资源描述搭建配置管理软硬件平台按照《配置管理计划》建立配置管理库，并把配置库划分为开发库、受控库和产品库，根据需要，也可以建立基线库和支持性记录库按照《配置管理计划》为不同的配置库划分目录，以便于管理和访问按照《配置管理计划》设置配置库和目录访问的权限建立配置管理系统12申请：责任人向CM工程师提交入库申请（Email，简要说明提交内容及所在位置）检查：CM工程师执行入库检查，检查项参照《配置管理计划》中配置项入库时机和准则的要求。若检查通过，进入下一步；若检查不通过，则将检查结果返回申请人进行处理入库：CM工程师执行入库操作，并更新《配置项状态报告》通知：CM工程师通知项目相关人员配置项已入库，并分发最新的《配置项状态报告》（Email，告知存放位置）创建配置项及基线13发布申请：项目经理提交《基线及产品发布申请单》给CM工程师，说明要求发布的时间，发布的基线名称、版本及所含配置项信息CM工程师检查：CM工程师参照发布申请对发布对象进行检查，具体检查项参见《配置管理计划》中的基线列表。检查发现的问题需与项目经理沟通并记录处理结果。发布审批：CCB根据申请单、CM工程师的检查结果，审批基线的建立和发布申请，若同意发布，则进入下一步；若拒绝发布，则描述原因并通知相关人员建立基线：CM工程师建立基线，并更新《配置项状态报告》和《基线状态报告》。通知发布：CM工程师将基线发布结果通知给项目相关人员（邮件方式，通知内容包括发布的基线名称、所含配置项及版本、基线标识、存放位置等信息。建议邮件附上基线状态报告）基线发布14产品构造一般应在集成测试、系统测试前，及产品交付客户前进行；对于一些小的项目，根据项目具体情况，也可考虑只构造一次，即产品交付前。在构造产品之前，需要制定集成计划。CCB审定软件受控区构造的产品的生成。不论为内部或外部使用，有软件受控区构造的产品仅仅由软件受控区中的配置项和单元组成。产品构建发布15在基线发布或变更和里程碑结束时，启动配置审计活动配置审计可以分为物理审计和功能审计两个方面。对于配置审计发现的问题，需要制定行动计划，并跟踪直至解决。《基线审计检查表》配置审计16周报CM工程师参考相关的配置管理记录，每周定期编写《CM周报》报告给项目组、高层经理和其他相关人员。阶段报告阶段活动完成，工作产品受控，且里程碑评审将启动时提交此报告CM工程师在里程碑评审前，需要完成CM阶段报告，并发送给参加评审的所有人员。状态报告17项目组软件配置管理应有专人负责（称配置管理员）；中小型项目，由项目经理或指定专人担任配置管理员，负责项目配置管理。大规模项目，应建立配置管理小组（CM组），在项目经理领导或授权下负责项目配置管理。配置管理贯穿软件生命周期全过程，但分两个阶段：从需求到产品发布的开发阶段，配置管理由项目经理或指定专人负责；发布后进入产品维护阶段，由负责该产品技术支持部门指定的配置管理员负责。最佳实践18在整个开发阶段，各类工作产品（配置项）及其变更是项目配置管理的重点；而开发环境、测试环境和运行环境的描述文档则只作为配置项纳入配置管理，受到控制。在产品维护阶段，配置管理的重点则包括变更控制、版本控制和基线管理。项目启动后就应开始配置管理活动，包括：定义、标识配置项，定义基线，建立配置库和基线库，确定访问权限，控制配置库/基线库的签出（Checkout）和签入（Checkin）。最佳实践（续）19在项目计划阶段，应编写配置管理计划（CM计划），与项目开发计划一起提交评审；在产品发布后进入维护阶段，也应编写CM计划。按评审确认的CM计划建立基线、审计配置库和基线，及时报告配置状态。每一个产品的所有配置项的变更均应得到管理和控制。（每一个项目组的）软件产品最终集成（产品发布基线，或产品发布后的产品维护阶段定期生成的基线），由项目配置管理员负责实施，技术支持的配置管理员负责监督。最佳实践（续）20变更流程输入输出配置管理计划项目开发计划提出变更请求,填写配置项变更申请表配置项变更申请表评审更新的配置项变更申请表变更任务分配批准N提取配置项修改批准的配置项变更申请表配置项变更记录跟踪、验证变更结果更新配置库对变更内容、及其影响进行评估更新的配置项变更申请表拒绝变更N更新的配置项变更申请表更新的配置项变更申请表21在项目立项时，根据项目规模和特点，确定变更授权机构及其职责，并纳入立项报告及计划阶段的配置管理计划；确定变更等级：变更等级一般由项目经理判断，并在配置管理计划中描述各自控制的变更，建议若是影响需求基线和产品基线的变更以及严重影响项目进度、成本、产品质量的重大变更提交CCB控制；其他变更（如：文字编辑、格式调整）由项目经理控制。活动22对评审定稿配置项和基线的所有变更在实施前均要通过变更授权机构的评审和批准；变更过程必须书面记录。对于受控项，不论是项目经理还是CCB控制变更，其提请变更的流程相同，配置管理员只负责受控项标识更新和配置项变更状态报告的填写，不参与其它活动；所有《配置项变更申请表》由项目经理负责提交配置管理员纳入受控库；配置管理员提交配置项变更记录给相关受影响人员。最佳实践23常用工具