配置项CI列表和配置库目录结构

配置管理程序

配置管理程序1.目的本程序的目的是规定并控制服务和基础设施组件，并保持正确的配置信息，为事件管理、问题管理、变更管理和发布管理的运作提供支持。

2.范围本程序适用于运维服务项FI的配置信息管理。

3.定义配置管理数据库(CMDB)：包括所有与配置项及其状态和相互关系有关的信息的数据库。

配置管理数据库(CMDB)对所有IT组件、组件的不同版本和状态以及组件之间的相互关系进行跟踪。

在其最基本的形式下，一个CUDB可能是由一些纸质表格或一套清单组成。

基线：一个产品或系统在某一特定时刻的配置状况。

配置不仅体现了其产品或系统的结构，还反映了其具体内容，从而使得以后可以按照上述配置重建该产品或系统。

尽管被作为基准线的这个配置状态以后可能会发生改变，但这个基准线本身却保持不变。

这个基准线可以作为初始状态的一个参考或当前状态的一个对照。

4.职责软件产品研发部：■开发识别系统和确定配置项的命名规范；,规划和实施CMDB的组建及管理工作；' 组织配置审计并报告。

5.流程输入：组织中变更的信息、新IT组件的信息。

输出：其他流程、IT管理报告、新添加的和更新的配置记录。

流程活动：5. 1识别：定义和维护IT基础架构的物理组件和有关文档的命名规范和版本号，以及定义和维护这些组件之间的相互关系和相关属性。

记录在《配置记录说明书》中。

5. 1.2为识别IT组件，需要决定配置管理数据库(CUDB)的范围(宽度)，分解的层数(深度) 以及详细的程度(细节)。

深度问题又可以进一步分为：层次的数目，需要跟踪的关系，命名规范以及属性。

识别包括：-定义范围：IT服务和它们对客户业务活动的贡献；特定的范围，如工作站、文档、打印和应用服务、中央处理器、数据库、IT系统和电话服务；硬件、软件和文件，如服务级别协议、规程、手册、技术规范说明书和项目计划等。

-定义属性：序列号、名称、制造商、版本号、位置、所有者。

-详细程度：为每一类配置项确定其属性的详细程度是建.配置管理的一个重要的方面；在确定属性的详细程度时，需要审慎地平衡变更需求、事件、问题、其它管理流程、以及用于支持配置管理所需的相关的负载量以及可利用的资源等方面的关系。

配置管理规程

配置管理（Configuration Management, CM）的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性。

配置管理过程域的四个主要规程：制定配置管理计划－配置库管理－配置版本控制－配置变更控制定义1.工作成果（Work Product）项目研发和管理过程中会产生许许多多的工作成果，例如文档、程序和数据等。

2.配置项（Configuration Item, CI）所有纳入配置管理范畴的工作成果统称为配置项，配置项主要有两大类：（1）属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。

（2）项目管理中产生的文档。

如计划、报告等。

这些文档虽然不是产品的组成部分，但是值得保存。

每个配置项的主要属性有：标识符、名称、文件状态、版本、作者、日期等。

所有配置项都须保存在配置库里，确保不会混淆、丢失。

配置项及其历史记录反映了软件的演化过程。

3.基线（Baseline）基线由一组配置项组成，并且这些配置项已被“冻结”，任何人不能再随意修改（见变更控制规程）。

基线通常在里程碑处建立，所以一个产品可以有一个或多个基线。

基线的主要属性有：标识符、名称、版本、日期等。

通常将交付给客户的基线称为一个“Release”，为内部开发所用的基线则称为一个“Build”。

4.项目配置管理员（Project Configuration Manager）为了提高配置管理的效率和安全性，项目需要有专人为项目制定《配置管理计划》，创建和维护配置库，在本文档中，该负责人称为项目配置管理员。

在公司，项目支持负责人担任项目配置管理员的角色。

5.项目变更控制委员会（Change Control Board, CCB）项目CCB对项目内配置管理的各项活动拥有决策权（例如审批配置管理计划，审批变更请求等）。

对于配置管理而言，项目CCB是决策者，而项目配置管理员是执行者。

系统集成项目配置管理产品配置的管理题库

系统集成项目配置管理产品配置的管理题库配置管理(CM)的定义：是通过技术或行政手段对软件产品(源代码、产品、文档规范等)及其开发过程和生命周期进行控制、规范的一系列措施。

配置管理的目的：记录软件产品的演化过程，确保产品开发者在软件生命周期中的各个阶段都能得到精确的产品配置，本章重点讨论的题目包括：配置管理的有关概念、制定配置管理计划、配置识别和建立基线、建立配置管理系统、版本管理、变更管理、配置状态报告和配置审计(大纲要求)配置管理的几个相关的思想(1)文档由几个人一起编写，最后不知道谁是最新版本了，所以需要用配置管理来规藏文椽廊的问题(2)无变更就无配置管理，配置管理的白的就是为了防止变更时配置项版本搞乱(变更和配置管理的关系)(3)一般我们常用VSS软件来管理文档的版本就是配置管理的例子1.1配置管理的概念1配置项（配置管理的对象）凡事纳入配置管理范畴的工作成果都是配置项（CI）例如：文档、源代码、成品、半成品等2 .配置库存放配置项的仓库3 .软件配置管理（SCM）4 .基线（必会）基线（Base1ine）评审确认后的标准，例如：进行应询算成本预算基线进行成本控制成本控制基线重要的检查点是：里程碑重要的里程碑是：基线5 .配置管理活动配置管理主要包括：制定配置管理计划、配置识别和建立基线、监理配置管理系统、版本管理、配置状态报告和配置审计6标识为配置项取名字，详细描述配置项7控制通过建立产品基线，控制软件产品的发布和在整个生命周期内对软件产品修改。

1.2制定配置管理计划（了解）配置管理目标是为了让变更更加规范化1标识团队项目配置管理目标（为了让变更更加规范化）2 .描述角色和责任（需要哪些角色，分别做什么）3 .描述工具、过程和支持基础机构（必须建立配置库，从硬件、软件进行描述）4 .标识配置项（选定哪些作为配置管理的对象并加以标识。

例如：源文件是配置项，中间文件不是配置项)5 .描述配置项和基线的标识方案6 .描述基线策略7 .标识基线(必会，重点看下)标识要使用的不同类型的基线(D功能基线：创建相互独立的项目里程碑，以扑捉特定级别的功能，例如：拆分同时进行的工作或捕捉需要级别的行为(2)开发基线：创建此基线可以使开发人员在更正预定数量的代码(尤其是界面)后重新同步，此基线不一定必须发挥作用(3)评审基线：通过创建此基线可以检直和分析自上一基线以来进行的更改，使用此基线可以确定改动级别和提交质量等事项(4)发布基线：通过此基线可以捕捉产品相对于特定的外部发布状态。

配置管理过程及工具的使用

不要把CVS作为练习的场所
配置管理过程

岗位及职责项目建立配置管理计划出入库变更流程配置状态报告 SCM总结报告验证
岗位与职责

SCCB（Software Configuration Control Board） SCCB负责人：一般由室主任、项目所有者(Project Owner)或项目负责人担当，主要职责是审批《配置管理计划》、审批重大的变更； SCCB成员：一般由室主任、项目负责人、SQA人员共同组成，主要职责是讨论、审批配置项或基线的变更； SQA：主要职责为审核配置管理活动；配置管理员：主要职责为制定《配置管理计划》、创建和维护配置库、定期做《配置状态报告》。
包括中间发布和最后的发布配臵库结构说明3配臵管理放臵项目配臵项清单配臵管理光盘清单配臵状态报告等scm读写其他人只读质量保证放臵项目不符合报告sqa核查表和sqa周报等sqa读写其他人只项目跟踪和监控放臵项目状态报告项目周报个人工作周报等评审和报告基线工作产品入基线时评审的报告项目组长读写其他人只读配臵库使用说明1因为cvs工具本身的问题如果你将文件放在错误的位臵或者命名不规范scm进行位臵移动或者修改文件名称的时候会造成历史版本的丢失想要找回历史版本很不容易给配臵管理造成一定的工作量

配置审核
配置审核包括两方面的内容：配置管理活动审核及基线审核。配置管理活动审核确保项目组成员所有配置管理活动遵循批准的软件配置管理方针和规程，比如检入（Check in）/检出（Check Out）的频度，工作产品成熟度提升原则等。实施基线审核，保证基线化软件工作产品的完整性和一致性，并且满足其功能要求。
the log message”，请大家一定要填写，主要填写几个方面的内容：修改的目的，修改的主要内容（段落或者函数名称），修改可能造成的影响。尤其是进入编码和测试阶段，要求每个文件的提交必须有log message。请大家注意！

配置管理结构

配置管理结构
配置管理结构是一种用于组织和管理软件或系统的配置信息的框架。

它的主要目标是确保配置项的准确性、一致性和可控性。

以下是一个配置管理结构的示例，包括主要组件和功能：
1. 配置管理数据库（CMDB）：用于存储和管理所有配置项的中央存储库。

它包含关于硬件、软件、网络设备、应用程序等的详细信息。

2. 配置项（CI）：配置管理中的基本单位，代表系统中的一个具体元素，如服务器、数据库、网络设备等。

每个配置项都有唯一的标识符和相关的属性信息。

3. 配置管理流程：包括配置项的创建、修改、审核、发布和退役等一系列步骤。

这些流程确保配置变更得到适当的控制和记录。

4. 版本控制：跟踪配置项的不同版本，包括历史记录和变更说明。

这有助于回滚到以前的版本或了解配置的演化过程。

5. 关系和依赖：记录配置项之间的关系和依赖，以便在变更时评估其影响。

6. 配置视图：根据不同的需求和角色，创建不同的配置视图，展示相关的配置信息。

7. 访问控制：实施适当的访问控制机制，以确保只有授权用户可以进行配置变更。

8. 报告和审计：提供配置管理活动的报告和审计功能，以满足合规性要求。

通过配置管理结构，组织可以更好地管理和控制其IT 基础架构的配置，提高可靠性、合规性，并促进有效的变更管理。

软件项目配置管理规范(配置项标识和配置审计的标准)

软件项目配置管理规范（配置项标识和配置审计的标准）1．概述本规范用于规范和指导全公司的配置管理活动，适用公司研发项目及技术支持阶段产品的开发工作，主要包括以下几个方面：建立和维护配置管理环境。

公司配置库权限管理配置库的备份和恢复。

公司配置管理相关规程及工具的培训。

制定和维护基线计划。

标识配置项。

变更控制和管理。

版本管理。

配置审计。

2．术语及定义配置管理（Configuration Management，CM）：是一套应用技术上和管理上的指导和监督的方法，用来识别和记录配置项和功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否符合特定的需求（IEEE-STD-610）。

配置项（Configuration Item，CI）：配置管理中可相对独立地进行管理的单元，如文档和模块代码。

基线（Baseline）：经过正式评审并且达成一致的一组工作产品，是进一步工作的稳定基础；基线化后的工作产品只能依据变更控制规程通过变更评估、审批后才能变更。

配置审计（Configuration Audit，CA）：通过对配置库进行物理审计和功能审计来验证配置项信息与配置标识的一致性，确保软件资产备份的有效性和完整性。

配置库备份：配置库的备份包括全量备份和增量备份。

3．配置项标识编写《配置项识别表》时，配置管理工程师负责标识配置项范围，并由项目负责人确认。

项目组成员创立配置项时，根据配置项命名规则分配唯一的标识符，配置项命名根据以下原则。

文档类命名规则：公司级命名规则： [ 简称-] 文档名称 [-模块/主题简称]文档类命名原则：【局点+RM单号】-【项目名】-【文档名称】（如项目规模较大时，需分模块说明时，可增加模块简称的后缀）。

会议纪要等可增加主题简称、日期等后缀。

版本编号规则：v1.0.0.0（m.n.j.k） m 主版本号、n代表次版本号 j代表文档批准次数或者代码发布次数 k文档修改次数或者代码测试次数.配置项状态配置项状态通常有如下三种情况：草稿（draft）;评审中（in review）；已发布（released/passed）日常工作中经常将其剪裁为：草稿（draft）；已发布（released）这两种状态，根据是否通过评审为判断节点。

软件项目配置管理规范(配置项标识和配置审计的标准)

软件项目配置管理规范（配置项标识和配置审计的标准）1．概述本规范用于规范和指导全公司的配置管理活动，适用公司研发项目及技术支持阶段产品的开发工作，主要包括以下几个方面：建立和维护配置管理环境。

公司配置库权限管理配置库的备份和恢复。

公司配置管理相关规程及工具的培训。

制定和维护基线计划。

标识配置项。

变更控制和管理。

版本管理。

配置审计。

2．术语及定义配置管理（Configuration Management，CM）：是一套应用技术上和管理上的指导和监督的方法，用来识别和记录配置项和功能特征和物理特征；控制这些特征的变更；记录和报告变更的处理和执行的状态；以及验证其是否符合特定的需求（IEEE-STD-610）。

配置项（Configuration Item，CI）：配置管理中可相对独立地进行管理的单元，如文档和模块代码。

基线（Baseline）：经过正式评审并且达成一致的一组工作产品，是进一步工作的稳定基础；基线化后的工作产品只能依据变更控制规程通过变更评估、审批后才能变更。

配置审计（Configuration Audit，CA）：通过对配置库进行物理审计和功能审计来验证配置项信息与配置标识的一致性，确保软件资产备份的有效性和完整性。

配置库备份：配置库的备份包括全量备份和增量备份。

3．配置项标识编写《配置项识别表》时，配置管理工程师负责标识配置项范围，并由项目负责人确认。

项目组成员创立配置项时，根据配置项命名规则分配唯一的标识符，配置项命名根据以下原则。

文档类命名规则：公司级命名规则： [ 简称-] 文档名称 [-模块/主题简称]文档类命名原则：【局点+RM单号】-【项目名】-【文档名称】（如项目规模较大时，需分模块说明时，可增加模块简称的后缀）。

会议纪要等可增加主题简称、日期等后缀。

版本编号规则：v1.0.0.0（m.n.j.k） m 主版本号、n代表次版本号 j代表文档批准次数或者代码发布次数 k文档修改次数或者代码测试次数.配置项状态配置项状态通常有如下三种情况：草稿（draft）;评审中（in review）；已发布（released/passed）日常工作中经常将其剪裁为：草稿（draft）；已发布（released）这两种状态，根据是否通过评审为判断节点。

软件配置管理规范流程

软件配置管理规范流程Is the eternal love the truth. December 22, 20211概述目的本文档主要目的在于规范项目配置管理活动,确保配置项正确地唯一标识并且易于存取,保证基线配置项的更改受控,明确基线状态,在整个软件生命周期中建立和维护项目产品的完整性和可追溯性;适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动,针对项目不同在流程上作适当的删减;配置管理可采用各种工具及手工办法,本文件以CVS并行版本系统配置管理工具为例,规定公司的配置管理办法,使用其他工具时也可对应本文件的要求参照执行;术语和缩略语软件配置管理Software Configuration Management,SCM软件配置管理是对软件修改进行标识、组织和控制的技术,用来协调和控制整个过程;是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施;配置管理的目标是记录软件产品的演化过程,确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置;配置项Configuration Item,CI凡是纳入配置管理范畴的工作成果统称为配置项,配置项逻辑上组成软件系统的各组成部分,一般是可以单独进行设计、实施和测试的;每个配置项的主要属性有：名称、标签、文件状态、版本、作者、日期等;所有配置项都被保存在配置库里,确保不会混淆、丢失;配置项及其历史记录反映了软件的演化过程;基线Baseline在配置管理系统中,基线就是一个配置项或一组配置项在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,这些配置项构成了一个相对稳定的逻辑实体,而这个过程被称为“基线化”;每一个基线都是其下一步开发的出发点和参考点;基线确定了元素配置项的一个版本,且只确定一个版本;一般情况下,基线一般在指定的里程碑处创建,并与项目中的里程碑保持同步;每个基线都将接受配置管理的严格控制,基线中的配置项被“冻结”了,不能再被任何人随意修改,对其修改要严格地按照变更控制的过程进行;在一个软件开发阶段结束时,上一个基线加上增加和修改的基线内容形成下一个基线;基线的主要属性有：名称、标签、版本、日期等;权限与职责研发总经理助理1 审核变更请求;项目经理Project Manager,PM1 审核批准配置管理计划；2 接收或拒绝小范围的变更申请；3 召集评估变更；4 提出配置管理的建议和要求；5 配合配置管理员的工作;配置管理员Configuration Management Officer,CMO1 编写配置管理计划；2 执行版本控制和变更控制方案；3 制定访问控制策略；4 负责项目的配置管理工作,包括搭建环境、权限分配、配置库的建立、配置项的控制等；5 配置管理工具的日常管理与维护；6 配置库的日常操作和维护；7 负责配置审核并提交报告；8 根据配置部署表单编译发布版本,并维护版本；9 对开发人员进行相关的培训；10 对配置审核中发现的不符合项,拟订纠正措施,要求相关责任人进行纠正;11 监督项目组成员规范的执行情况;开发人员Developer1 根据确定的配置管理计划和相关规定,提交配置项和基线；2 负责项目组内部测试；3 负责软件集成和版本生成；4 按照软件配置管理工具的使用模型来完成开发任务;2 实施细则配置项管理配置项的范围软件配置可包括以下几方面：开发文档,代码,第三方控件、插件,参考资料,测试文档,用户文档,项目管理文档,验收文档等;l 项目文档主要指：立项建议书、可行性分析报告、技术建议书、用户需求说明书、项目计划、项目进度计划、项目阶段性计划、产品需求规格说明书、概要设计报告、详细设计、数据库设计、界面设计、用户操作手册、用户安装手册、培训文档、验收报告以及上述文档的评审记录;l 代码主要指：源代码等;l 工具主要指：脚本文件、插件、第三方控件等;配置项基线管理结合SPP和ISO9000的相关规定,配置管理员根据配置管理规范及配置管理计划,对配置项进行分阶段管理,每一阶段正式评审通过后纳入受控库,作为该项目的一个基线;l 项目启动：配置项包括技术建议书、可行性分析报告、用户需求说明书等立项阶段产生的文档,评审或审批通过后建立发布基线;l 需求阶段：系统调研后开发人员进行需求分析,并整理产品需求规格说明书;产品需求规格说明书经过客户的确认后,建立需求基线;如需升级版本则必须通过评审或审批并得到客户的确认;l 项目计划：需求分析完成后即可制定项目的开发计划,包括项目计划和主要下属计划;包括项目进度计划、配置管理计划、质量保证计划、测试计划、项目阶段性计划;项目开发计划评审通过后,建立项目计划基线;l 设计：系统设计可分为概要设计、详细设计、数据库设计、数据库字典、界面设计;针对用户需求规格说明书进行系统设计,配置时应说明系统设计的版本与需求分析报告版本的对应关系;设计说明书评审或审批通过后,建立设计基线;l 编码设计实现：编码按功能模块分子项目,即每个模块记作一个配置项;代码在提交项目组系统测试时建立Beta版本,系统测试产品正式发布后建立Version版本;l 测试：单元测试和系统测试;单元测试通过提交单元测试报告,项目启动后应提交系统测试计划,系统测试完成后应提交系统测试报告;配置时应说明测试的版本与编码版本的对应关系;系统测试完成后建立测试基线;l 版本发布：项目组提交部署表单,CMO根据部署表单进行编译,发布测试服务器上,并对版本进行维护;同时将发布的版本上传到文档服务器上备份;l 交付与验收：在交付前配置审核完成后建立产品基线,产品基线包含程序以及有关文档配置项,包括交付文档、代码、工具等;l 产品部署：部署时应包括操作手册、安装维护手册、维护文档以及必要的业务和技术培训文档;l 相关资料：相关资料也应作为配置项纳入配置管理,此部分包括：1 相关法律、法规；必须遵照或项目组约定的技术规范；2 与客户或项目组内部重要的交互信息记录,如会议记录、会谈记录、e-mail和MSN记录等；版本控制文档的版本控制所有文档的管理纳入配置管理库,用版本控制工具进行统一管理;文档的版本控制主要通过文档的名称、文档控制页及版本控制工具的标签来实现,主要分为以下几类：版本变化型文档命名方式：文档名称+子系统名称可选适用文档：项目计划、配置管理计划、质量保证计划、项目进度计划、用户需求规格说明书、产品需求规格说明书、体系结构设计报告、数据库设计报告、详细设计报告、用户操作维护手册、测试用例等;示例：项目计划.doc详细设计_SP门户.doc标签结构：大版本 + 子系统简称 + 版本号 + 日期标签控制说明版本信息l 大版本：可选 ,表示同一项目为不同用户定制的版本;l 子系统简称：可选,当一个项目有多个子系统时,为区分不同子系统而设置;l 版本号：采用Vs_x_y的形式;l 日期：纳入基线管理的日期,用8位表示,如说明：a.文档发布名称采用文档名+ Vs_x_y的形式,文档的版本号应该和版本控制工具中相应标签上的版本号一致;b. 对文档的修改需要从配置管理库中取到本地进行;c. 对于文档小的修改,如文字错误,格式调整,变更Vs_x_y中的y来区别如：V1_0_1;d. 文档内容没有大的增加和删节,意思表述没有发生重大的变化,版本标识通过版本工具中加上x标签来表示如：V1_1_0,以及在文档内部控制页标注变化来表示;e. 文档有重大增加和删节,意思表述有重大变化的,版本标识通过在相应文档加上s标签来表示如：V2_0_0;f. 对于纳入基线库的文档的修改需要提交变更申请,经批准才能进行修改,并且修改的内容要经再次评审才能重新纳入基线库,作为后续阶段的参考文档;时间区别型文档命名方式：文档名称＋撰写时间适用文档：文档名称有明确的含义,需要用时间标识的日常性文档;如周例会会议纪要,项目月计划,项目月总结,阶段性计划等等;示例：周例会会议纪要时间序号型文档命名方式：文档名称+人员姓名拼音+撰写时间+序列号适用文档：测试报告示例：单元测试报告其他文档：对于不能按照前四种类型进行命名的文档会议纪要：会议纪要YYYYMMDD示例：9月9日召开的项目启动会命名为：会议纪要项目启动.doc评审报告：评审报告YYYYMMDD同”会议纪要”要求一致;示例：10月9日召开的项目总体方案评审命名为：评审报告总体方案.doc发行版本表示发行版本采用标签说明,结构如下：大版本 + 版本类型 + 版本号 + 子系统简称拼音+日期 +序号大版本：可选 ,表示同一项目为不同用户定制的版本;子系统简称：可选,当一个项目有多个子系统时,为区分不同子系统而设置;版本类型：分为3种Beta表示项目组内部测试,标签：Release系统测试,标签：Version正式发行版,标签：版本号对于Version正式发行版是必须要注明的,而其它可选;发行产品基线在版本号前加Version,如Version_1, Version_2,Version_3….表示分支；Version_1_0, Version_1_1, Version_1_2… 表示在分支Version_1上的标签；Version_0_0, Version_0_1, Version_0_2… 表示在主线上的标签;配置库管理配置库的分类配置库统一由配置管理员负责管理,服务器端使用,客户端主要使用乌龟CVS;配置库目录结构如下：配置库的建立所有项目应建立配置库,以便管理各配置项,配置管理员组织建立配置库;程序库主要通过设置版本的分支来实现对配置项权限管理：1开发库：开发人员相对比较自由的存储空间,开发人员可以在自己的权限范围内任意取出提交;2基线库：配置管理员有最高权限,其余相关人员均为读的权限,发生变更时变更人员须提交变更申请后方可修改基线库内的配置项;文档评审通过后,文档严格受控;由配置管理员将通过评审后的文档移植到基线库里同时将该配置项从开发库移除;代码一般在移交系统测试时纳入基线库受控,可根据项目的具体情况设置基线;3产品库：产品库的产品均出自于基线库,产品库存储的产品用于交付和存档;配置三库统一由配置管理员管理,根据各开发阶段的实际情况定制相应的版本选取规则,来保证开发活动的正常运作;在变更发生时,应及时做好基线的推进;分配权限项目开始后配置管理员编写配置库目录结构表明确项目组成员以及相关人员的权限;在wincvs里有三种权限,读r、写w、添加删除c权限;在开发库内,文档部分项目组成员有rcw权限,其他相关人员只r权限；代码部分项目组成员有rcw权限,其他相关人员没有任何权限;在基线库内,项目组成员仅有r权限,其他相关人的权限视情况而定;在产品库内,所有人没有任何权限;配置管理员在三库内均拥有最高权限;配置变更控制变更的分类软件及其相关文档的变更按照变更的影响范围进行分类：1A级：变更会影响系统级的需求、外部接口、产品价格或者交付期；这类变更必须经过配置管理委员会审核并有客户批准和确认;2B级：变更会影响配置项间的功能接口、内部功能的设计、组件；这类变更必须由项目经理或配置管理委员会的批准和认可;3 C级：变更只会影响配置项内部或对BUG问题的处理；这类变更可以由配置项的管理人员负责批准;系统测试前变更控制流程：系统测试完毕发布release版本后变更控制流程图2 变更控制流程变更请求的提出a．由技术支撑中心汇集顾客意见,影响到需求变更则填写配置项变更控制报告,并提交给配置管理员;b．配置管理员对申请表是否清晰、明确和完整性进行审查,若发现变更不明确或不完整,应返回申请者;对通过审查的变更申请分配变更ID,以便跟踪和记录变更信息;评估变更a．配置管理员将配置项变更控制报告发送给项目经理或者其他授权人员,由项目经理负责对变更进行评估;b．项目经理对变更进行分解,一般的BUG修正不需要审批直接由项目经理决定是否需要变更;新增功能或对整个项目影响重大的变更必须由研发总助审批通过后方可变更;变更评估文档在完成变更评估后发送给配置管理员;变更实施和确认a．变更被批准后,项目经理提交变更实施进度计划,开发人员开始实施变更,并详细记录变更的内容；质量部对变更的实施进行跟踪;b．对于代码变更,必须进行回归测试,以确保变更没有引入新的Bug;另外与变更相关的文档必须修订,以反映变更;当变更以及测试完成后,进行提交;c．通过测试后,质保人员需对变更进行审核,审核的范围一般涉及以下方面：测试记录；变更请求；配置项的检入及检出；文件的命名；版本的编号;a．审核后,由配置管理员更新到基线库中;配置状态报告目的记录和报告整个软件生命周期演化状态;记录内容配置状态报告记录的内容包括：1 软件和文档的标识；2 目前状态；3 基线演化状态；4 变更状态；5 版本交付信息等;生成报告配置管理报告自第一个基线创建时建立,由配置管理系统生成,及时反映当前配置状态;配置审核类别配置审核分为：1功能配置审核Functional Configuration Audit,FCA：审核软件功能是否与需求一致,并符合基线文档要求,通常要审查测试文档等;2 物理配置审核Physical Configuration Audit,PCA：审核要交付的组成项是否存在,是否包含所有必需的项目,如正确版本的源代码、资源、文档、安装说明等等;执行时机通常选择以下几种情况由质量保证人员负责实施配置审核：1软件产品交付或是软件产品正式发行前；2软件开发的阶段工作结束后；3在产品维护工作中,定期地进行;不符合项处理对配置审核中发现的不符合现象,配置管理员进行记录,并交由责任部门限期进行纠正,配置管理员负责纠正措施的验证;所有的不符合项报告均关闭后,才能发布新版本;发行管理通过配置审核后,经项目经理批准,由配置管理员负责生产新版本;交付管理这里“交付”是指从配置库中提取配置项,交付给客户或项目外的人员;交付出去的配置项必须有据可查,避免发生混乱;流程如下：1交付人向质量部申请；2质量部如果不同意交付,则拒绝交付配置项;如果同意交付,配置管理员应给出详细的交付清单；3交付人验收后签字;。

项目管理-项目三库配置管理规范

配置管理规范1目的规范产品开发过程中配置活动的流程和要求，确保产品及其相关交付件的版本和使用在项目的整个生命周期中的完整性和可追踪性。

2适用范围适用于本公司所有项目及其整个软件开发生命周期的所有配置管理活动，及项目产生的技术文件的入库及使用管理。

3定义3.1 配置管理Configuration Management（CM）是通过技术或行政手段对产品及其开发过程和生命周期进行控制、规范的一系列措施。

配置管理的目标是记录产品的演化过程，确保开发者在产品生命周期中各个阶段都能得到精确的产品配置。

3.2 配置项凡是纳入配置管理范畴的工作成果统称为配置项。

配置项包括两大类：一是属于产品组成部分的工作成果，例如印制板图、源代码、需求文档、设计文档、测试用例等等；二是在管理过程中产生的文档例如各种计划、监控报告等等。

3.3 配置库包括项目开发库、项目受控库、项目检验库、项目成品库。

3.3.1项目开发库存放与项目研制有关的可由计算机读取的产品开发过程文档的信息库，命名为XXX PDL （project development library），其中XXX为项目代号。

项目开发库的地址为：“\\技术部门\项目开发库”。

3.3.2 项目受控库存放与项目研制有关的可由计算机读取的通过里程碑和节点评审的产品的信息库，命名为XXX PCL（project controlled library)。

项目受控库的地址为：“\\技术部门\项目受控库”。

3.3.3 项目检验库作为受控库的子库，用于存放边研制边生产阶段的设计文档。

3.3.4项目成品库存放符合最终研制要求的设计文件(含电子版、纸质版及其它形式)成品的库，命名为XXX PPL （project product library）。

项目成品库由总师办标准化/技术资料部进行管理，包括底图室、科档室和软件成品库。

详细管理要求见《项目成品库管理办法》。

4角色与职责4.1 高级管理者负责建立项目的CCB配置控制委员会，一般情况由管理团队中的总工程师担任，负责Ⅰ类技术文件借用的最终审批。

软件配置模板

目的（Purpose）为了建立和维护软件项目中所有产品的完整性，该文件描述了用于软件配置管理Software Configuration Management（SCM）的过程。

目标（Objective）通过有计划的软件配置管理活动，使软件工作产品经过标识、受到控制并具有可用性。

任何对软件工作产品的更改都是受控的，并确保相关小组和个人能及时了解软件基线的状态和内容。

范围（Scope）受控于配置管理下的工作产品，包括交付给客户的软件产品，以及生成软件产品所需要的或由软件产品标识的有关项。

准备/前提/条件（Input）软件配置控制委员会（SCCB）：负责评价、认可或否定有关基线更改建议并确保确认的更改得以执行。

具体活动包括，授权标识与建立软件基线，阐述项目负责人和所有受软件基线变更影响的小组的权益。

高层SCCB包括BUM和高层经理。

项目SCCB包括项目经理和产品经理。

每个软件产品都有一个软件配置管理（SCM）小组负责协调和实施产品的软件配置活动。

SQA定期对SCM小组的活动进行监察与审核，以验证SCM小组的活动是否按照相应的规程进行。

规程/任务/活动（Procedure）制定SCM计划Making SCM Plan在项目的初期需要制定《SCM计划》SCM Plan.dot，并且始终与项目保持一致。

在项目计划（Project Plan.dot）的软件配置管理一章中，需要指明该项目对应的SCM计划文档。

项目经理或由项目经理指定的SCM小组成员制定SCM计划，并提交该项目的SCCB进行审批。

SCM计划的主要内容包括：确定该项目的SCM小组以及SCCB的成员名单。

需要管理的工作产品和项目使用工具，以及管理它们的目录结构设置。

项目的工作产品包括项目文档、源代码、源代码所生产出的EXE、OCX、DLL等所有生成文件。

目录结构设置可参考《SCM路径设置规程》（SCM Path Setup Procedure.doc）。

配置管理计划模板完整版

项目编号：xxxxxx项目名称：xxxxxx 配置管理计划修订历史记录目录1. 简介 (4)1.1目的 (4)1.2范围 (4)1.3定义、首字母缩写词和缩略语 (4)1.4参考资料 (5)1.5概述 (5)2. 软件配置管理 (5)2.1组织、职责和接口 (5)2.2工具、环境和基础设施 (6)3. 配置管理活动 (8)3.1配置标识 (8)3.2配置项变更控制 (10)3.3配置管理活动计划 (10)3.4报告和审计 (17)4. 培训和资源 (18)4.1培训所需环境 (19)4.2培训参加人员 (19)4.3培训具体安排 (19)5. 分包商和厂商软件控制 (19)错误!未指定书签。

1.简介1.1目的在项目的生命周期内，为了保证该项目工作产品、过程记录及项目相关资料的版本统一和完整，特制定本计划。

1.2范围纳入项目配置管理的配置项、过程记录及其它相关资料。

1.3定义、首字母缩写词和缩略语本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。

这些信息可以通过引用项目词汇表来提供。

1.3.1CM (Configuration Management）配置管理。

1.3.2配置项（Configuration item)指定为配置管理的对象且作为单个实体进行处理的硬件、软件或两者的集合。

1.3.3基线（baseline）一种通过正式评审和认可的规范说明或产品，此后将其作为进一步开发的基础，只有通过正式的变更控制过程才可以变更。

1.3.4基线库（Software baseline library）项目软件生命周期中基线的集合。

用VSS软件工具管理时，基线库可以是一个独立的VSS系统，也可以是VSS系统中的一个目录。

1.3.5配置审计（Configuration audit）审核配置管理库系统的结构和设施，验证软件基线库内容的完备性和正确性，验证与适用的配置管理标准和规程的符合性1.3.6配置控制委员会（CCB）有权力管理项目基线的委员会，它代表项目经理和所有可能受到项目基线更改影响的组的利益，由它审定项目基线的建立和配置项/单元的标识，评审和审定对项目基线的更改，审定对项目基线库制造的产品的生成。

《系统集成项目管理工程师》案例分析题答题技巧

9
二、揭示问题与方案、策略设计题
请用400字以内的文字，描述小丁在处理监理工程师提出的问题是否正确？如果你作为项目经理，该如何处理？解题要领
先揭示问题相关项目管理法则、法规的知识点再根据当前知识点，形成此问题的处理策略
10
实例参考答案根据《中华人民共和国招投标法》第48条：中标人应当按照合同约定履行义务，完成中标项目。中标人不得向他
3、表述的规范性
要求多角度、条理性表述，学会分点，不能泛泛而谈，切忌“前言不答后语”点正确切题：能按照试题要求，针对材料进行答题；学科语言运用完整；表述清晰；说理正确。 10分
观点正确：能按照试题要求，针对材料进行
答题；学科语言运用恰当； 9分
观点基本正确；能按照试题要求。结合所给材料答题；学科语言运用一般；表述一般。 8分
项目的基线变更控制委员会由客户代表、产品经理、项目经理和技术经理组成，对发布的里程碑类基线的变更必须由变更控制委员会确认并由QA进行变更记录，所有被变更影响的配置项都需要重新同步后再次发布；而对于仅仅作为工作状态保留的基线，一般只需要建立基线的小组确认更改并在QA进行记录即可。
13
三、项目管理过程改进题假设你被任命为本项目的项目经理，请问你对本
合同生效后，小丁开始进行项目计划的编制，开始启动项目。由于工期紧张，甲方要求提前完工，总经理比较关心该项目，询问项目的一些进展情况，在项目汇报会议上，小丁给总经理递交了进度计划，公司总经理在阅读进度计划以后，对项目经理小丁指出任务之间的关联不是很清晰，要求小丁重新处理一下。
新的计划出来了，在计划实施过程中，由于甲方的特殊要求，需要项目提前2周完工，小丁更改了项目进度计划，项目最终按时完工。
项目经理小丁在接到监理工程师的通知后，对于第二个问题拒绝了监理工程师的要求，理由是机房工程由B公司承建，且B公司经过了建设方的认可，要求追究B公司的责任，而不是自己公司的责任。对于第一个问题，小丁把任务分派给程序员老张进行修改，此时，系统设计工作已经在进行中，程序员老张独自修改了已进入基线的程序，小丁默许了他的操作。老张在修改了需求规格说明书以后采用邮件通知了系统设计人员。

配置管理规范

配置管理规范对于一个一般的项目来说，配置管理规范的内容至少需要包括以下的内容：1、配置项及其命名规则；2、配置库文件目录结构；3、角色和权限定义；4、配置项变更流程；5、配置项发布；6、基线定义和基线变更。

配置项及其命名规则对我们的项目来说，配置项需要包括以下的内容：1、项目管理过程文档；a) 项目任务书；b) 项目计划；c) 项目周报；d) 个人日报和周报；e) 项目会议纪要；f) 培训记录和培训文档；2、QA过程文档；a) QA不符合报告；b) QA周报；c) 评审记录；3、工作产品a) 需求文档；b) 设计文档；c) 代码；d) 测试文档；e) 软件说明书和手册；4、项目中使用的第三方产品上文中用红色部分标识的是容易遗漏的配置项，尤其是第4个（项目中使用的第三方产品），实际上，一个工程型的项目会大量使用第三方的软件（例如，我们的产品中就使用了IBM的MQSeries、Oracle、一些第三方的开发控件），对这些产品的管理至少可以解决三个方面的问题：1、版本配合的问题：大部分的第三方软件在升级之后，并不能实现二进制层面上的兼容，需要对原有的代码重新编译；甚至有的第三方软件在升级之后，API层面上的兼容性都做不到；因此，在工程实施的过程中，版本的配合问题是一个需要关注的问题；2、发布的完整性问题：一般来说，比较大型的第三方软件在发布过程中都不会有遗漏，但对一些小的第三方软件来说，比如我们使用的许多perl的CPan模块，如果在开发过程中没有有意识的进行管理的话，很容易就会发生遗漏；3、在某些特殊条件下由于第三方软件的变化引起的基线变更：这种情况极少会发生，但在我们以前的项目中，确实还遇见过。

一般是因为原来选型时使用的第三方软件不能满足要求，只能通过更换新的第三方软件，这就补课避免地需要变更基线（例如需求文档、设计文档等）；将第三方软件纳入配置管理的范畴可以更方便地管理基线的变更。

关于第三方软件产品配置项的管理还有一点需要说明：由于第三方软件有可能会比较大，而且相对我们的项目来说，是很少会发生变更的（一般在一个项目过程中，不会采用不同的配置项的命名可以便于查找相关配置项。

配置管理计划

配置管理计划配置管理计划（CMP）是一份用于规划、实施和控制项目中所有配置项及其相关变更的文件。

下面我们将对CMP进行详细介绍。

一、背景和目的：CMP是为了确保项目中所有的配置项都被正确创建、标识、跟踪、审查、控制和记录，以使其符合项目及其相关需求、规范和标准。

CMP将制定项目的配置管理策略和程序，包括配置项标识、变更控制、配置管理报告等方面，以便确保项目的成功。

二、范围：CMP应作为项目计划的一部分，覆盖项目中的所有配置项、项目管理和技术团队成员。

CMP应包括项目配置项的定义、识别、版本控制、变更和库存，并应覆盖所有配置项的生命周期管理过程。

三、定义：1、配置项（CI）：在项目中被标识、管理、授权和控制，并且需要跟踪其修改历史和状态信息的任何物理或逻辑单元。

2、配置项库（CMDB）：存储配置项信息的单一数据库。

3、配置标识：用于标识配置项的名称、编号、版本号、类别、层次结构等。

4、变更控制：用于跟踪和控制配置项的变更过程，包括变更请求、审查、批准和实施等。

5、配置状态：指定每个配置项的创建状态、批准状态、发布状态等。

6、配置审核：审查和确认配置项的准确性、可靠性和功能性。

四、配置管理策略和程序：1、配置项标识和目录结构：在项目开始时，应对每个配置项进行标识，为其定义唯一的名称、编号和版本号。

对于大型项目，可以将配置项组织成层次结构并为其定义类别。

2、变更控制：应该建立一个变更控制委员会，监督配置项变更请求的审查、批准和实施。

变更请求应由项目经理或相关技术人员提出，并记录在变更控制台账中。

变更控制委员会应该在规定好的时间间隔内组织会议，以审查和记录变更过程。

在变更实施之前，必须对变更进行功能和安全性测试，并使批准结果记录在变更控制台账中。

3、配置跟踪和审查：应该建立一个配置项库来存储所有配置项的信息。

当配置项进行修改时，应在CMDB中记录其变更历史和状态。

应该对每个配置项进行定期审查，以确认其正确和完整，并检查是否需要进行更改。

产品开发部配置管理制度

文件编号:GM/KFB/CMS/20090720版本号：V1.00。

000产品开发部配置管理制度部门：产品开发部编写：＊*＊＊＊＊＊*审核：批准：日期: 2009-07—20**＊*****有限公司修改历史目录第一章概述 (5)1。

目的 (5)2。

范围 (5)3.术语 (5)4。

角色与职责 (6)5。

VSS配置库目录结构 (7)6.配置项命名规则 (7)7.配置项编号规则 (7)8.配置项状态变迁规则 (10)9。

配置项版本号规则 (10)第二章配置管理范围 (11)第三章配置库建立 (11)第四章配置管理流程 (12)1。

配置管理流程 .................................................................................................................................... 错误!未定义书签。

2。

基线建立流程 .. (14)3.变更控制流程 (15)4.产品发布流程 (16)第五章配置库权限变更管理 (17)第六章配置库备份 (17)第七章配置库使用规范 (17)第八章附录 (18)附录1《附录清单》 (18)附录2《配置库目录结构》 (19)附录3《配置申请单》 (20)附录4《受控库产品清单》 (21)附录5《变更申请单》 (22)附录6《发布产品配置表》 (22)附录7《产品发布申请及验收表》 (23)附录8《产品发布检查表》 (25)附录9《产品发布清单》 (26)第一章概述1.目的为了保证产品开发部研发项目文件的安全性、机密性；为了保证软件产品的完整性、有效性及可追溯性，特根据部门实际情况制订本制度。

2.范围适用于产品开发部所有项目.3.术语4.角色与职责5. VSS配置库目录结构●开发库：主要用来保存开发过程中不稳定的配置项（源码和相关文档），主要由开发人员支配。

配置项ci通俗解释

配置项ci通俗解释CI（Continuous Integration）是指在软件开发的过程中，不断地将代码集成到主干代码库中，并通过持续自动化测试来保证代码质量，避免后期集成时的问题。

在实践过程中，需要配置一些参数来确保CI的顺利运行。

下面是一些常见的配置项解释。

1. 项目源码的路径：指定软件项目源码所在的路径，用于CI平台拉取代码进行自动化构建和测试。

2. 构建脚本的路径：构建脚本是CI平台自动构建的重要配置，指定构建脚本所在的路径，例如编译代码、运行测试等。

3. 依赖管理工具：在构建过程中需要使用依赖管理工具，如Maven、Gradle等。

指定依赖管理工具的版本和配置文件的路径。

4. 测试框架：CI平台需要配置测试框架来执行测试用例，以确保代码的质量。

常见的测试框架有JUnit、TestNG、Selenium等。

5. 分支策略：指定代码库中开发分支和主干分支的名称，并指定相应的构建策略和测试策略。

6. 代码质量检查工具：CI平台需要配置代码质量检查工具来审查代码质量，例如Checkstyle、FindBugs、PMD等。

7. 环境配置：指定CI运行的环境配置，例如Java版本、操作系统版本、数据库类型和版本等。

8. 部署配置：CI平台需要配置部署流程，包括部署到哪些服务器、如何进行部署等。

9. 通知配置：CI平台需要配置通知策略，在构建或测试失败时进行通知，以及成功后给出相关信息。

10. 版本控制系统的集成：CI平台需要集成版本控制系统，例如Git、SVN等。

这样才能自动拉取代码进行构建和测试。

总的来说，通过配置这些参数，实现CI。

CI对于软件开发的快速迭代和质量保障非常重要，也对于从事软件开发的人员有帮助。