1、Catalog 目 录1Objectives 目的31.1确保维护团队的配置管理活动已计划；31.2确保维护团队所有的配置项都已经唯一标识并且可访问；1.3确保对维护团队所有配置项的更改都可控和跟踪；1.4确保所有维护团队配置项的一致性和完整性；1.5确保维护团队所有已基线化配置项的状态通知到相关人员。2Scope 范围33Responsibilities 职责33.1维护经理职责：3.2维护团队CMO职责：3.3维护团队CCB职责33.4QA职责：3.5PDE职责：4Inputs 输入34.1交接清单34.2版本树34.3版本开发计划34.4参考类文档写作需求34.5资料开发计划35Outp
2、uts 输出35.1维护团队配置管理计划35.2审计报告35.3配置项状态跟踪表单35.4版本配套表35.5版本描述文档35.6升级指导书35.7产品配置库归档表35.8维护项目失效部件清单36Control mechanism 控制机制36.1维护经理保证维护团队配置管理活动遵守本规程。6.2产品质量体系EPG组负责批准所有针对该规程的修改。6.3通过内部质量审计来检验流程的符合度。7Procedure 规程37.1维护团队配置管理活动的对象37.2维护团队配置管理活动的启动37.3维护团队配置管理活动37.4Configuration Identification 配置标识37.5The
3、reporting and tracing of CI status 配置项状态的记录和跟踪37.6Establishing the Baseline 建立基线37.7Management of Configuration Library 配置库管理37.8Change Control 变更控制37.9Configuration Status Accounting配置状态发布37.10Software Release Management软件版本管理37.11Configuration Audit 配置审计37.12The Product configuration management cl
4、osure 配置管理活动的结束3List of abbreviations 缩略语清单：Abbreviations缩略语Full spelling 英文全名Chinese explanation 中文解释BOMBill of Material物料清单CCBConfiguration Control Board or Change Control Board配置控制委员会或变更控制委员会CIConfiguration Item 配置项CMConfiguration Management配置管理CMOConfiguration Management Officer配置管理员CRChange Req
5、uest变更申请CSAConfiguration Status Accounting配置状态发布DRDesign Requirement设计需求DSDesign Specification设计规格HWHardware硬件IPDIntegrated Product Development集成产品开发OR Offering Requirement产品包需求PALProcess Asset Library过程资产库PCBPrinted Circuit Board印制电路板PDMProduct Data Management产品数据管理PDTProduct Development Team产品开发团队
6、PMMProduct Maintenance Management产品维护管理QAQuality Assurence Engineer质量保证工程师SWSoftware软件SysEPGSystem Engineering Process Group 系统工程过程组PDEProduct Data Engineer产品数据工程师PCNProduct Change Notice产品变更通知List of reference 参考资料清单：1 PCM01-Product Configuration Management Procedure1 Objectives 目的1.1 确保维护团队的配置管理活动
7、已计划；1.2 确保维护团队所有的配置项都已经唯一标识并且可访问；1.3 确保对维护团队所有配置项的更改都可控和跟踪；1.4 确保所有维护团队配置项的一致性和完整性；1.5 确保维护团队所有已基线化配置项的状态通知到相关人员。2 Scope 范围适用于公司内所有符合IPD流程的产品维护阶段配置管理活动。3 Responsibilities 职责3.1 维护经理职责：3.1.1 负责维护团队配置管理工作，制定维护团队配置管理计划；3.1.2 参与维护团队版本发布计划的制定，组织版本发布使用文档的编写；3.1.3 启动维护团队配置管理活动并指导维护团队配置管理工作；3.1.4 协助进行维护团队配置
8、审计；3.1.5 组织建立基线；3.1.6 组织归档配置库；3.1.7 组织进行PDM部件失效操作；3.2 维护团队CMO职责：3.2.1 接受移交或建立配置库，并维护配置库；3.2.2 协助维护团队CCB工作，跟踪维护团队CCB决策的执行以及变更解决完成情况；3.2.3 根据维护团队CCB决议，负责进行维护团队配置变更过程的修改授权；3.2.4 维护团队配置状态发布；3.2.5 负责建立基线；3.2.6 提交版本发布，维护版本基础信息。3.2.7 协助进行维护团队配置审计；3.2.8 负责实施维护团队配置管理的相关培训；3.2.9 归档配置库。3.3 维护团队CCB职责3.3.1 事件驱动和
9、定期召开CCB会议，评估和分析CR，裁决变更，并确保所有CI的更改得到同步和一致；3.3.2 确保评估与分析CR时考虑CR的影响范围（包括计划、进度、工作量、相关接口的影响），识别和评估受影响的所有CI，确定修改方案、修改人、修改版本、修改时间、验证方式和验证人。必要时需要邀请外部专家和相关受影响的内外部人员一起参与评审。3.4 QA职责：3.4.1 负责维护团队配置审计活动。3.5 PDE职责：3.5.1 负责产品配置项归档PDM审核确认。4 Inputs 输入4.1 交接清单4.2 版本树4.3 版本开发计划4.4 参考类文档写作需求4.5 资料开发计划5 Outputs 输出5.1 维护
10、团队配置管理计划5.2 审计报告5.3 配置项状态跟踪表单5.4 版本配套表5.5 版本描述文档5.6 升级指导书5.7 产品配置库归档表5.8 维护项目失效部件清单6 Control mechanism 控制机制6.1 维护经理保证维护团队配置管理活动遵守本规程。6.2 产品质量体系EPG组负责批准所有针对该规程的修改。更改后的规程必须得到研发质量部部长的签发。6.3 通过内部质量审计来检验流程的符合度。7 Procedure 规程7.1 维护团队配置管理活动的对象维护团队配置管理活动的对象包括整个维护生命周期中OR、DR、DS、SRS、软硬件设计文档、CODE、PCB、原理图、BOM、测试
11、类文档、信息交付件、PCN、参考类文档、管理类文档。注：维护生命周期中的参考类文档包括但不仅限于以下类别的文档：1、操作指导类：包括应急指导书、某类问题定位指导书、开局指导书、生产维修类指导书、生产EC类操作指导；2、总结报告类：包括各类问题定位报告；3、咨询答复类：问题咨询答复文档。4、局点信息类：用服每月提取的局点信息库信息表单。7.2 维护团队配置管理活动的启动7.2.1 在维护团队正式任命后，维护经理负责确定维护团队的配置组织结构，包括维护经理，维护团队CMO，维护团队CCB组长和成员等角色的任命。7.2.2 维护经理开始组织维护团队配置管理的计划活动。7.3 维护团队配置管理活动制定
12、配置管理计划是实现配置管理活动的前提，配置管理计划用于指导整个维护团队的配置管理活动，使之有章可循，因此制定配置管理计划应该注重实践性和可操作性。维护团队配置管理计划根据PCM01T01-配置管理计划模板、本规程及相应的维护团队计划制定。7.3.1 产品研发维护经理/开发代表根据产品配置管理计划，负责整理并制定移交维护团队版本的PCM01F05-产品配置库归档表单，并根据归档表单完成配置项PDM发行，PDE负责审核确认。7.3.2 产品研发维护经理/开发代表根据交接清单模板、版本树模板PMM-CM02F01-Product Version Evolution Relationship Desc
13、ription产品版本衍生升级和补丁关系表共同负责制定移交维护团队版本的交接清单和版本树表单。交接清单中要明确移交维护团队版本的所有内容，同时要明确移交维护团队版本中与其他产品有共用关系且共用部分由本产品维护的内容清单。版本树表单中，要明确移交维护团队版本的关联关系。1、移交维护团队的版本一般是指R版本。2、“其他产品有共用关系且共用部分由本产品维护”是指本产品负责开发、维护的某单板或软件模块被其他产品直接借用。7.3.3 移交维护团队版本的交接清单和版本树表单由PDT经理批准。7.3.4 维护经理根据批准的交接清单，负责制定（特指第一次移交维护团队的版本）或修改维护团队配置管理计划，组织维护
14、团队成员学习本规程及已有的配置管理计划。需要时，安排对参与配置管理计划拟制活动的人员培训。7.3.5 维护经理组织维护团队成员讨论，明确写作范围和内容，形成维护配置管理计划。7.3.6 维护经理组织评审，在评审中根据PCMCHK01-配置管理计划检查单对维护配置管理计划进行检查。7.3.7 维护配置管理计划由PDT经理批准。7.3.8 维护配置管理计划批准后，维护团队CMO接受移交、建立或维护配置库。维护团队配置库的结构根据维护团队项目文件夹结构建立。7.3.9 维护经理在版本开发计划批准、参考类文档写作需求正式采纳或资料开发计划批准后更新产品配置管理计划，并组织评审，评审完成后的产品配置管理
15、计划报维护经理批准后，维护团队CMO更改配置库。7.4 Configuration Identification 配置标识配置标识是对维护团队配置的管理，并维护在整个维护生命周期中配置的完整性和可跟踪性的前提和基础。配置标识包括了配置项的划分、命名和描述的过程。命名是指开发出一套命名和编码的框架方案来标识配置项；而描述则是对配置项特性进行文档化的描述过程。7.4.1 CI Decompose 配置项的划分7.4.1.1 配置项根据实际情况进行分级划分，一篇文档或者多篇文档可根据不同的管理需求划分成一个配置项。7.4.1.2 一般情况下，整个维护生命周期中文档清单中列举的内容建议作如下处理：a
16、文档：将一篇文档划分为一个配置项。b 代码：对于单板软件、模块或需要单独管理的软件代码可设置为一个配置项。如果没有特别管理需求，所有组成一个Build的代码也可作为一个配置项。c 手册：将资料开发部开发的产品手册划分为一个配置项。d PCN：一个PCN作为一个配置项。7.4.1.3 一般希望作为配置项管理的文档应该具有类似下面的特征，例如其变更需要得到控制，开发历史记录需要保存，和其它工作产品存在接口依赖关系，并且与其它配置项耦合性小等。这样也可以将这类文档确定为配置项进行管理。7.4.1.4 对于维护团队自主开发的工具，可以将所有生成工具的代码作为一个配置项进行管理。7.4.1.5 对于非由
17、维护团队直接改动的配置项（例如：用户提供的软件，购买的工具等等）， 维护团队CMO将配置项放入配置库或者维护配置项的版本信息， 以保证该配置项是可控和可跟踪的， 此时配置项处于“受控” 状态。7.4.1.6 维护团队所有确定的配置项应在PCM01F01-配置项状态跟踪表单中明确。7.4.2 配置项的命名配置项被分配唯一的名称用来和其它配置项区分。配置项的命名规范应该在配置管理计划中描述清楚。7.4.2.1 所有非参考类文档的配置项以文档名称作为配置项名称标识。详见：PDM文档附件名称和文档名称命名规范（DKBA1241-2003.06）。7.4.2.2 参考类文档的配置项以及文档名称作为配置项
18、名称标识1、操作指导类文档标识：XXX（产品线名称）- XXX（产品名称）- 指导书类-XXX（产品名称）XXXXXX（指导书名称）XX示例：WCDMA-NODEB-指导书类-BTS3812应急指导书2、总结报告类文档标识：XXX（产品线名称）-XXX（产品名称）-总结报告类-XX（省份）-XX（局点名称）-XXXXX（问题简要描述）问题定位报告XXWCDMA-NODEB BTS3812-总结报告类-福建-永同昌大厦-输出功率小问题定位报告3、咨询答复类文档标识：XXX（产品线名称）-XXX（产品名称）-XXXXX（问题简要描述）咨询答复报告XXWCDMA-NODEB BTS3812 -光传输
19、网元配置咨询答复报告3、局点信息标识：XXX（产品线名称）-XXX（产品名称）-局点信息类-XXXXX（局点名称）局点信息表单XXXXXX（年月）WCDMA-NODEB BTS3812-局点信息类-河北石家庄局点信息表单2004087.4.2.3 关于Build代码的配置项以Build名称作为配置项名称标识。有关交付生产的代码和目标程序的命名参见：7.4.2.4 其它由维护团队自己确定的配置项，由维护经理和相关人员共同确定其配置项名称标识。例如，维护团队自主开发的工具，可以用其工具本身的名称作为配置项名称标识。7.4.3 配置项的版本配置项的版本号是表示一个配置项具有一组定义的功能的一种标识，
20、随着功能的增加对其进行修改或删除，配置项会被赋予不同的版本号。配置项的版本定义规范在配置管理计划中描述清楚。7.4.3.1 关于文档的配置项相应的版本标识，形式为：a xx.yy的十进制标识符，其中xx起始为“1”，yy起始为“0”。b 所有上述数字都是阿拉伯数字，并且单步递增。c 对文档配置项，版本标识应写入文档修订记录并及时更新。7.4.3.2 关于Build配置项的版本参见产品版本命名及使用规范-03.00.00。7.4.3.3 其它配置项：由维护经理和相关人员确定其配置项版本号。例如，维护团队自主开发的工具，可以用其工具本身的版本号作为配置项版本号。7.4.4 Status of CI
21、 配置项的状态7.4.4.1 已基线化己基线化的配置项是指已完成评审、批准和签发（如果需要）的配置项。例如：一个设计文档已评审通过、批准、签发，成为编码活动的基础。7.4.4.2 管理和受控指已提交评审，但还没有形成基线的配置项。一个正在进行评审的设计文档。7.4.4.3 受控对于非由维护团队直接改动的配置项（例如：用户提供的软件，购买的工具等等），维护团队CMO将配置项放入配置库或者维护配置项的版本信息， 以保证该配置项是可控和可跟踪的， 此时配置项处于“受控” 状态。7.4.5 Others其它除了上述，需要对配置项的下列相关特征进行描述：7.4.5.1 计划基线时间，计划中该文档评审并修
22、改完成，形成基线的时间。7.4.5.2 实际基线时间，实际开发中该文档评审并修改完成，形成基线的时间。7.4.5.3 存放位置，文档形成基线后，可以被查阅的访问路径。如果在维护团队配置库中，必须指明存储路径。7.4.5.4 上述所有配置项的特征必须在PCM01F01-配置项状态跟踪表中明确，由维护团队CMO进行维护和跟踪，并在配置状态发布中提供。7.5 The reporting and tracing of CI status 配置项状态的记录和跟踪7.5.1 维护经理与维护团队CMO完成PCM01F01-配置项状态跟踪表，记录所有产品配置项的初始特征，包括配置项名称，计划受控时间等。7.5
23、.2 在维护生命周期中，维护团队CMO及时更新PCM01F01-配置项状态跟踪表单。7.6 Establishing the Baseline 建立基线7.6.1 在配置管理系统中，基线就是配置项在其生命周期的特定时间点上通过正式评审而进入正式受控的一种状态。作为配置管理的基础，基线保证了后续开发活动所需信息的稳定性和一致性。7.6.1.1 Baseline character:基线的特征：a 基线是特定时间点上配置项的状态。b 基线是针对配置项而言的。7.6.1.2 文档经过批准、签发（如果需要）后建立基线；代码在批准后基线化。此后对该配置项的更改要通过提交变更申请进行。7.6.1.3 维护
24、生命周期中，要建立发布基线。a 当到达PCM01F01-配置项状态跟踪表中定义此基线的时间点时，维护经理开始组织建立该基线。b 维护经理确认本次待建立的基线中包含的所有配置项已经管理和受控，其变更已经完成。c 维护经理根据PCMCHK03-基线建立检查单进行初步检查，确定是否满足建立该基线的条件。d 检查通过后，维护经理通知维护团队CMO可以建立该基线。e 维护团队CMO创建该基线。f 维护团队CMO升级版本树。g 维护团队CMO和PDE对版本开发、资料开发或维护团队自主开发的工具的发布并进行PDM发行操作和审核确认，同时根据PCM01F01-配置项状态跟踪表中的发放部门名单，建立基线发布公告
25、，公告内容为PCM04F01-版本配套表、PCM04T02-版本描述文档、PCM04T03-升级指导书、PCN。h 对参考类文档，维护团队CMO根据PCM01F01-配置项状态跟踪表中的发放部门名单，进行参考类文档的发放。7.7 Management of Configuration Library 配置库管理这部分的内容请参见PCM03-产品配置库管理规程中的描述。7.8 Change Control 变更控制这部分的内容请参见PCM02-产品变更管理规程中的描述。1、 由其他产品发现的维护团队所维护版本的共用部分的问题，需要提交客户需求电子流进行跟踪。维护团队采纳此类需求后，需提交缺陷跟踪
26、电子流进行问题修改。2、 配置状态跟踪表单的更改需要提交缺陷跟踪电子流。7.9 Configuration Status Accounting配置状态发布7.9.1 配置状态发布报告应由维护团队CMO准备，由维护经理审核。维护配置状态发布报告需要向维护团队所有成员，相关产品和人员发布。维护配置状态发布的所有配置项应具有易获取性， 即相关人员在拥有对应权限的条件下可以访问本次发布的配置项。7.9.2 周期性配置状态发布的主要内容为PCM01F01-配置项状态跟踪表单。维护团队CMO一般两周至少进行一次配置状态发布。维护配置状态报告要记录和报告这个周期中维护配置项的状态。维护经理确定在什么情况下可
27、以事件驱动地进行产品配置状态发布，并明确在配置管理计划中。一般适用于进行事件驱动的情况例如文档的批量刷新，版本发布公告等。7.9.2.1 对于基线发布和事件驱动型的配置状态发布，维护经理和维护团队CMO可以根据情况或者维护团队的需求对配置状态发布中的内容进行完善和补充，依照配置管理计划中的约定进行发布。基线成功建立后，维护团队CMO要将当前基线的情况和清单向维护团队发布。7.10 Software Release Management软件版本管理参见PCM04-Software Release Management Procedure7.11 Configuration Audit 配置审计配
28、置审计是确定一个发布的基线已经通过验证证明符合所有的功能需求，并且包含了它应包括的所有配置项的过程。7.11.1 配置审计由QA计划并组织执行，在各个配置项基线化之后进行。对于上一次审计的遗留问题同时作为在本次审计中的问题进行审计并跟踪。审计团队可以包括维护经理、维护团队CMO、同行、用户等等。7.11.2 配置审计针对不同的配置项，着重点不尽相同。所有的审计内容按照PCMCHK02- Configuration Audit Checklist检查。一般情况下，配置审计会涉及到下面的内容：7.11.2.1 维护团队的配置管理活动是否符合本规程？7.11.2.2 维护团队配置管理流程是否正确有效的执行?7.11.2.3 配置项是否完整？7.11.2.4 相关的更改是否已经正确实施?7.11.3 审计结果应记录在PCMCHK02-Configuration Audit Checklist 和 PCM01F02-Con
