网硕互联帮助中心摘要：本文系统梳理了软件配置管理、变更管理与文档管理的核心知识。配置部分涵盖配置项类型、版本状态、配置基线、配置库建库、角色职责及配置管理活动；变更部分介绍变更原因、分类、管理原则、角色职责与完整变更流程；文档部分说明文档种类、质量分级与书写规范。内容以技术规范与基准调整为主线，适合项目经理、配置管理员及开发人员阅读参考。
配置（关注可交付成果的技术规范）
配置项类型：配置项可以分为基线配置项和非基线配置项两类，基线配置项（可交付成果，需求文档，设计文档，原代码，可执行代码测试用例，运行软件所需数据等。与技术、产品、功能相关，开发人员阅读）；非基线配置项（各类计划（如项目管理计划，进度管理计划），各类报告。项目经理、配置管理员阅读）。所有配置项的操作权限应由配置管理员严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向项目经理、CCB及相关人员开放
配置项版本及状态：草稿状态（配置项刚建立时，其状态为“草稿”）：版本0.YZ（处于“草稿”状态的配置项的版本号格式为0.YZ，随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握）；正式状态（配置项通过评审后，其状态变为“正式”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”）：版本X.Y（处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，Y为次版本号。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1；……当附件的变动积累到一定程度时，配置项的Y值可适量增加。Y值增加到一定程度时，X值将适量增加。当配置项升级幅度比较大时，才允许直接增大X值）；修改状态（此后若更改配置项，则其状态变为“修改”）：版本X.XZ（处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为正式时，将Z值设置为0，增加X.Y值）
配置基线：基线通常对应于项目过程中的里程碑，一个项目可以有多个基线，也可以只有一个基线。交付给用户使用的基线一般称为发行基线，内部过程使用的基线一般称为构造基线
配置基线价值：1.为项目工作提供一个定点和快照；2.新项目可以在基线提供的定点上建立，新项目作为一个单独分支，将与随后对原始项目（在主要项目分支上）所进行的变更进行隔离；3.当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法；4.可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误
配置基线分类：国家标准基线（功能基线：系统规格说明（需求）、分配基线：软件规格说明（设计）、产品基线：软件产品所有配置项（完成））；实际工作基线（需求基线、设计基线、测试基线、产品基线）；对内对外基线（构造基线：企业内部使用、释放；发行基线：交付外部客户、交付）
配置库：开发库（开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。可以任意的修改）；受控库（受控库，也称为主库-半成品，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。可以修改，需要走变更流程）；产品库（也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更流程）
配置库建库：按配置项的类型分类建库（这种模式适用于通用软件的开发组织。在这样的组织内，往往产品的继承性较强，工具比较统一，对并行开发有一定的需求。使用这样的库结构有利于对配置项的统一管理和控制，同时也能提高编译和发布的效率。但由于这样的库结构并不是面向各个开发团队的开发任务的，所以可能会造成开发人员的工作目录结构过于复杂，带来一些不必要的麻烦）；按开发任务建立相应的配置库（这种模式适用于专业软件的开发组织。在这样的组织内，使用的开发工具种类繁多，开发模式以线性发展为主，所以没必要把配置项严格分类存储，人为增加目录的复杂性。对于研发性的软件组织来说，采用这种设置策略比较灵活）
配置角色与职责：配置经理（配置管理负责人也称配置经理，负责管理和决策整个项目生命周期中的配置活动：①管理所有活动，包括计划、识别、控制、审计和回顾；②负责配置管理过程；③通过审计过程确保配置管理数据库的准确和真实；④审批配置库或配置管理数据库的结构性变更；⑤定义配置项责任人；⑥指派配置审计员；⑦定义配置管理数据库范围、配置项属性、配置项之间关系和配置项状态；⑧评估配置管理过程并持续改进；⑨参与变更管理过程评估；⑩对项目成员进行配置管理培训）；配置管理员CMO（配置管理员负责在整个项目生命周期中进行配置管理的主要实施活动：①建立和维护配置管理系统；②建立和维护配置库或配置管理数据库；③配置项识别；④建立和管理基线；⑤版本管理和配置控制；⑥配置状态报告；⑦配置审计；⑧发布管理和交付）；配置项负责人（配置项负责人确保所负责的配置项的准确和真实：①记录所负责配置项的所有变更；②维护配置项之间的关系；③调查审计中发现的配置项差异，完成差异报告；④遵从配置管理过程；⑤参与配置管理过程评估）
配置管理目标：1.所有配置项能够被识别和记录；2.维护配置项记录的完整性；3.为其他管理过程提供有关配置项的准确信息；4.核实有关信息系统的配置记录的正确性并纠正发现的错误；5.配置项当前和历史状态得到汇报；6.确保信息系统的配置项的有效控制和管理
配置管理方针（配置是否成功关键因素）：1.所有配置项应该有记录；2.配置项应该分类；3.所有配置项要编号；4.应该定期对配置库或配置管理数据库中的配置项信息进行审计；5.每个配置项在建立后，应有配置负责人负责；6.要关注配置项的变化情况；7.应该定期对配置管理进行回顾；8.能够与项目的其他管理活动进行关联
配置管理活动（即使控告神经）：1.CMO制订配置管理计划（对如何开展项目配置管理工作的规划，是配置管理过程的基础，应该形成文件并在整个项目生命周期内处于受控状态。CCB负责审批该计划。内容包括：配置管理的目标和范围；配置管理活动主要包括：配置项标识、配置项控制、配置状态报告、配置审计、发布管理与交付；配置管理角色和责任安排；实施配置活动的规范和流程（如配置项命名规则）；实施配置活动的进度安排（如日程安排）；与其他管理（如变更管理）之间的接口控制；实施配置活动的人员、团队和其他团队之间的关系；配置管理信息系统的规划；配置管理的日常事务；计划的配置基准线、重大发布、里程碑、以及针对以后每个期间的工作量计划和资源计划）；2.配置项识别（配置项识别是识别所有信息系统组件的关键配置，以及各配置项间的关系和配置文档等结构识别。它包括为配置项分配标识、名称、日期和版本号等。配置项识别是配置管理的一项基础性工作，要确定：1.确定配置项范围；2.确认和记录配置项属性；3.为配置项定义标识符（唯一）；4.确定配置基准线；5.确定配置结构；6.确定配置命名规则）；3.配置项控制（对配置项和基线的变更控制，包括：标识和记录变更申请（项目经理或干系人）；变更评估CCB（CCB负责组织对变更申请进行评估并确定：①变更对项目的影响；②变更的内容是否必要；③变更的范围是否考虑周全；④变更的实施方案是否可行；⑤变更工作量估计是否合理）；通告评估结果CCB（CCB把关于每个变更申请的批准、否决或推迟的决定通知受此处置意见影响的每个干系人和申请人。如果变更申请得到批准，应该及时把变更批准信息和变更实施方案通知给那些正在使用受影响的配置项和基线的干系人。如果变更申请被否决，应通知有关干系人放弃该变更申请）；变更实施PM（项目经理组织、配置管理员实施修改相关版配置项并在相应版文档、程序代码或配置管理数据中记录变更信息）；变更验证与确认PM（项目经理指定人员对变更后的配置项进行测试或验证。项目经理应将变更与验证的结果提交给CCB，由其确认变更是否已经按要求完成）；变更发布CMO（配置管理员将变更后的配置项纳入基线。配置管理员将变更内容和结果通知相关人员，并做好记录）；基于配置库的变更控制CMO（配置库））；4.配置状态报告（也称配置状态统计，其任务是有效地记录和报告管理配置所需要的信息，目的是及时、准确地给出配置项的当前状况，供相关人员了解，以加强配置管理工作）
5.配置审计（配置审计也称配置审核或配置评价，包括功能配置审计和物理配置审计，分别用以验证当前配置项的一致性和完整性。配置审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求，不允许出现任何混乱现象。功能配置审计（审计配置项一致性=质量）：1.配置项的实际功效是否与需求一致、2.配置项的开发是否圆满完成（功能完成）、3.配置项是否已达到规定的性能和功能特征（功能实现）、4.配置项的操作和支持文档是否已完成，是否符合要求（文档满足要求）；物理配置审计（审计配置项完整性=是否存在=范围）：1.配置项的物理存在是否与预期一致、2.要交付的配置项是否存在、3.配置项中是否包含了所有必需的项目）；6.配置管理回顾与改进（配置管理回顾与改进即定期回顾配置管理活动的实施情况，发现在配置管理执行过程中有无问题，找到改进点，继而优化配置管理过程。配置管理回顾及改进活动包括：①对本次配置管理回顾进行准备，设定日期和主题通知相关人等参加会议；②召开配置管理回顾会议；③根据会议结论，制订并提交服务改进计划；④根据过程改进计划，协调、落实改进）
变更（关注基准调整）
变更原因：1.产品范围（成果）定义的过失或者疏忽；2.项目范围（工作）定义的过失或者疏忽；3.增值变更（需求扩展）；4.应对风险的紧急计划或回避计划；5.项目执行过程与基准要求不一致带来的被动调整；6.外部事件（如政策）
变更分类：变更性质（重大变更、重要变更、一般变更）；变更紧迫性（紧急变更、非紧急变更）
变更类型：纠正措施（现阶段绩效与计划），预防措施（未来绩效与计划），缺陷补救（修正产品），更新（修改正式文件）。（NEW）
变更管理原则：1.基准管理（合同）：基准是变更的依据。每次变更通过评审后，都应重新确定基准；2.变更控制流程化：建立或选用符合项目需要的变更管理流程，所有变更都必须遵循这个控制流程；3.明确组织分工（申请人，项目经理，CCB，配置管理员）：至少应明确变更相关工作的评估、评审、执行的职能；4.评估变更的可能影响（CCB变更控制委员会或专家）；5.妥善保存变更产生的相关文档（配置管理员）：适当时可以引入配置管理工具
变更角色与职责：项目经理PM（响应变更提出者的需求；评估变更对项目的影响及应对方案；将需求由技术要求转化为资源需求，供授权人决策；并据评审结果实施（即调整基准），确保项目基准反映项目实施情况）；变更控制委员会CCB（表决变更是否通过结果，成员包括项目经理、用户代表、产品经理、开发工程师、测试工程师、质量控制人员和配置管理员等）；变更管理负责人（变更管理负责人也称变更经理，通常是变更管理过程解决方案的负责人：1.负责整个变更过程方案的结果；2.负责变更管理过程的监控；3.负责协调相关的资源，保障所有变更按照预定过程顺利运作；4.确定变更类型，组织变更计划和日程安排；5.管理变更的日程安排；6.变更实施完成之后的回顾和关闭；7.承担变更相关责任，并且具有相应权限；8.可能以逐级审批形式或团队会议的形式参与变更的风险评估和审批等）；变更请求者（1.提交初步的变更方案和计划；2.初步评价变更的风险和影响，给变更请求设定适当的变更类型；3.对理解变更过程有能力要求等）；变更实施者（有执行变更方案的内容的技术能力，负责按照实施计划实施具体的变更任务）；变更顾问委员会（重大变更行使审批：负责对重大变更行使审批，提供专业意见和辅助审批，具体为：1.在紧急变更时，其中被授权者行使审批权限；2.定期听取变更经理汇报，评估变更管理执行情况，必要时提出改进建议）
变更流程：1.变更申请（变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前应以书面形式提出。项目的干系人都可以提出变更申请，但一般情况下都需要经过指定人员进行审批，一般项目经理或者项目配置管理员负责该相关信息的收集，以及对变更申请的初审）；2.变更初审（目的：①对变更提出方施加影响，确认变更的必要性，确保变更是有价值的；②格式校验，完整性校验，确保评估所需信息准备充分；③在干系人间就提出供评估的变更信息达成共识等）；3.变更方案论证（变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供CCB决策。对于一些大型的变更，可以召开相关的变更方案论证会议，通常需要由变更顾问委员会（相关技术和经济方面的专家组成）进行相关论证，并将相关专家意见作为项目变更方案的一部分，报项目CCB作为决策参考）；4.变更审查（CCB表决审查：变更审查过程是项目所有者根据变更申请及评估方案，决定是否变更项目基准）；5.发出通知并实施；6.实时监控（项目经理监控基准，CCB或监理单位监控成果或里程：变更实施的过程监控，通常由项目经理负责基准的监控。CCB监控变更明确的主要成果、进度里程碑等，也可以通过监理单位完成监控）；7.效果评估（项目经理组织评估，关注内容：①评估依据是项目的基准；②结合变更的目标，评估变更所要达到的目的是否已达成；③评估变更方案中的技术论证、经济论证内容与实施过程的差距，并促使解决）；8.变更收尾（变更收尾是判断发生变更后的项目是否已纳入正常轨道）
变更控制：1.变更申请控制：变更申请的提交（确保覆盖所有变更操作）；2.变更过程控制：对进度变更控制（当前状态是否和基准有偏差）、对成本变更控制（当前成本是否和基准有偏差）、对合同变更控制（与整体变更控制结合）
版本发布与回退：软件版本发布前准备（分析，备份，触发条件，职责）；本发布应急回退方案（通知，回退，回退关联系统，回退后测试）；版本发布和回退实施过程总结（分析原因，总结经验教训）
文档
文档种类：开发文档：描述开发过程本身（开发人员，包括可行性研究报告和项目任务书、需求规格说明、功能规格说明、设计规格说明、质量保证计划）；产品文档：描述开发过程的产物（用户客户，包括培训手册、参考于册和用户指南、软件支持手册、产品手册和信息广告）；管理文档：记录项目管理信息（项目经理，包括开发过程的每个阶段的进度和进度变更的记录、软件变更情况的记录、开发团队的职责定义、项目计划、项目阶段报告、配置管理计划）
文档质量：一级文档：最低限度文档（自己阅读）；二级文档：内部文档（团队阅读）；三级文档：工作文档（其他同事阅读）；四级文档：正式文档（非专业看懂）
规则与方法：文档书写规范（普通文档、原代码：管理信息系统的文档资料涉及文本、图形和表格等多种类型，无论是哪种类型的文档都应该遵循统一的书写规范，包括符号的使用、图标的含义、程序中注释行的使用、注明文档书写人及书写日期等）；图表编号规则（在管理信息系统的开发过程中用到很多的图表，对这些图表进行有规则地编号，可以方便图表的查找）；文档目录编写标准（文档名称、格式、大小：为了存档及未来使用的方便，应该编写文档目录。管理信息系统的文档目录中应包含文档编号、文档名称、格式或载体、份数、每份页数或件数、存储地点、存档时间、保管人等）；文档管理制度（如读写权限：文挡的管理制度须根据组织实体的具体情况而定，主要包括建立文档的相关规范、文档借阅记录的登记制度、文档使用权限控制规则等）
评论前必须登录！
注册