案例分析重点知识 变更文档配置收尾

十二、变更管理

变更管理常见考点：

一.变更控制流程；变更没做好的影响

二.变更中存在的问题及应对

需要掌握的识点：

1、变更的常见原因（引起变更的因素）：

（1）产品范围（成果）定义的过失或者琉忽

（2）项目范围（工作）定义的过失或者琉忽

（3）增值变更

（4）应对风险的紧急计划或回避计划

（5）项目执行过程与项目基准要求不一致带来的被动调整

（6）项目团队人员调整；

（7）技术革新的要求；

（8）外部事件（例如政策变动或自然环境变化等）

2、项目变更有的多种分类方式：

（1）按变更性质分为重大变更、重要变更和一般变更，可通过不同审批权限控制。

（2）按变更的迫切性分为紧急变更和非紧急变更，可通过不同的变更处理流程进行控制。

（3）按变更所发生的领域和阶段，可分为进度变更、成本变更、质量变更、设计变更、实施变更和工作（产品）范围变更等。

（4）按变更来源可分为内部变更和外部变更等。

3、变更管理过程涉及到的角色主要包括项目经理、变更申请人、CCB、变更实施人、配置管理员。

4、变更的 8 个步骤（工作程序）：

（1）提出接受安更申请

变更提出应当及时以正式方式进行，并留下书面记录。变更的提出可以是各种形式，但在评估前版以书面形式提出。

（2）对变更的初审

变更初审的目的如下：

1，对变更提出方施加影响，确认变更的必要性，确保变更是有价值的

2，格式校验，完整性较验，确保评估所需信息准备充分

3，在干系人间就提出供评估的变更信息达成共识

4，变更初审的常见方式为变更申请文裆的审核流转

（3）变更方案论证

变更方案的主要作用，首先是对变更请求是否可实现进行论证，如果可能实现，则将变更请求由技术要求转化为资源需求，以供、CCE 决策。常见的方案内容包括技术评估和经济评估，前者评估需求如何转化为成果，后者评估价值和风险。

（4）项目变更控制委员会审查

审查过程，是项目所有者根据变更申请及评估方案，决定是否批准变更。评审过程常包括客户、相关领域的专业人士等。审查通常是文档会签形式，重大的变更审查可以包括正式会议形式。审查过程应注意分工，项目投资人虽有最终的决策权，但通常在专业技术上并非强项。所以应当在评审过程中将专业评审、经济评审分开，对涉及项目目标和交付成果的变更，客户的意见应放在核心位置。

（5）发出变更通知并开始实施

评审通过，意味着项目基准的调整，同时确保变更方案中的资源需求及时到位。项目基准的调整，包括项目目标的确认、最终成果、工作内容和资源、进度计划的调整。需要强调的是，变更通知后，不只是包括实施项目基准的调整，更要明确项目的交付日期、成果对相关干系人的影响。如变更造成交付期的调整，应在变更确认时发布，而非在交付前公布。

（6）变更实施的监控

要监控的，除了调整过的项目基准中所涉及变更的内容外，还应当对项目的整体基准是否反映项目实施情况负责。通过监控行动，确保项目的整体实施工作是受控的。变更实施的过程监控，通常由项目经理负责项目基准的监控。管理委员会监控变更明确的主要成果、进度里程碑等，可以委托监理单位承担监控职责。

（7）变更效果的评估

变更评估可以从以下几个方面进行。

①首要的评估依据，是项目基准。

②还需结合变更的初裹来看，变更所要达到的目的是否已达成。

③评估变更方案中的技术论证、经济论证内容与实施过程的差距并推进解决。

（8）判断发生变更后的项目是否已纳入正常轨道

        项目基准调整后，需要确认的是相应的资源配置和人员是否及时到位，更需多加关注。之后对项目的整体监控应按新的项目基准进行。涉及变更的项目范围及进度，在变更后的紧邻监控中，应更多地关注，当确认新的项目基准已经生效则按正常的项目实施流程进行。

有可能的问题

①对用户的要求未进行记录

②对变更的请求未进行足够的分析，也没有获得批准

③在修改的过程中没有注意进行版本管理

④修改完成后未进行猃证

⑤修改的内容未和相目千系人进行沟通

导致的后果

①缺乏对变更请求的记录可能会导致对产品的变更历史无法追溯，并会导致对工作产物的整体变化情况失去把握

②缺乏对变更请求的分析可能会导致后期的变更工作失误

③在修改过程中不注意版本管理，一方面可能会导致当变更失败时无法进行复原；另一方面，对于组织财富和经验的积累也是不利的

④修改完成后不进行猃证贝滩以确证变更是否正确实现

⑤未与项目干系人进行沟通可能会导致项目干系人的工作之间出现不一致之处。

4、项目控制委员会或配置控制委员会（CCB），或相关职能的类似组织是项目的所有者权益代表，负责裁定接受哪些变更。CCB 由项目所涉及的多方人员共同组成，通常包括用户和实施方的决策人员。CCB 是决策机构，不是作业机构；通常 CCB 的工作是通过评审手段来决定项目基准是否能变更，但不提出变更方案。

5、项目经理在变更中的作用，是响应变更提出者的需求，评估变更对项目的影响及应对方秦，将需求由技术要求转化为资源需求，供授权人决策；并据评审结果实施即调整基准。确保项目基准反映项目实施情况。

6、没有像好变更可能的后果（影响）：

（1）没有遵循正式的变更控制流程，可能导致（范围）需求变更的过程失控和不可追溯。

（2 没有对变更的影响进行完整的分析，可能导致无法全面了解这次变更对项目的进度、范围、成

本、质量等造成多大的影响。

（3）没有修改更新项目管理计划，可能导致实际工作内容与计划有较大的偏差，使项目管理计划无法指导项目实施。

（4）没有对相应技术文档进行修改可能导致需求、设计与缤码无法对应，不利于后期的测试和以后

的维护工作。

（5）版本管理和配置管理没有做好，可能导致在变更失败后无法将项目恢复到变更前的状态。

（6）没有让用户对最终结果进行确认，可能导致双方对变更结果的意见不一致，不利于项目验收和最终交付。

7、变更管理可能出现的问题：

（1）未提交书面变更申请

（2）变更控制委员会组成成员不合理，应该包括客户代表，最好是高级管理人员，并明确分工

（3）几乎所有变更都被批准和接受，说明 ce 没有严格控制项目变更申请的提交，没有认真审核

（4）应该对变更因素施加影响，积极沟通，确认变更的必要性

（5）没有进行变更后的评审，对变更造成的影响没有进行分析

（6）没有将变更可能造成的影响告诉变更提出方（或对应的干系人）

（7）没有严格按照变更控制流程进行变更管理。

（8）没有对变更作记录并形成文档，造成变更内容无法追浏。

（9 ）变更批准后，没有及时更新相应的项目计划和文件，导致内容不一致

（10）变更结果没有进行正式验证，未得到吝户的确认

（11）是否接受或拒绝变更，不应该全部由项目经理（或某个人）决定

（12）项目变更后没有相应的变更合同。

8、露求不明确的情况下就签订合同，开发过程中开发人员对于变更随便答应。随着项目进行，变更越来越混乱，导致项目失败。

答题要点：这类题目是变更管理里面的典型题目，总结了一下基本需要答以下几点

①在项目功能和标准不明确的时候就签订了合同，为后来的项目变更埋下了隐患

②没有建立项目变更管理制度（例如：开发人员随口答应，不上报给项目经理）

③作为上点的衍生品，还可以回答，变更请求没有经过评估，没有评估产生的费用和技术要求，也没有签字确认

④变更实施时没有考虑对系统其他功能的影响，也没有考虑能否实现

⑤变更后没有进行验证

⑥没有对变更后的内容进行存档，也没有通知给相关的项目干系人

十三、文档和配置管理

配置管理常见考点：

一、配置管理的内容及工作、配置项、配置库及作用、版本管理二、配置管理存在的问题及应对

需要掌握的知识点：

1、配置管理包括 6 个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

2、配器项可以分为基线配置项和非基线配器项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

3、配置库可以分开发库、受控库、产品库 3 种类型。

（1）开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，动态库是开发人员的个人工作区，由开发人员自行控制。可以任意的修改

（2）受控库，也称为主库。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。可以修改，需要走变更流程

（3）产品库，也称为静态库、发行库、软件仓库。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更流程。

4、配置控制委员会负责对配置变更像出评估、审查以及监督巳批准变更的实施。CCB 其成员可以包括项目经理、用户代表，产品经理、开发工程师、测试工程师、质量控制人员、配置管理员等。CCB 不必是常设机构，完全可以根据工作的需要组成，例如按变更内容和变更请求的不同，组成不同的 CCE。小的项目 CCE 可以只有一个人，甚至只是兼职人员。通常，CCB 不只是控制配置变更，而是负有更多的配置管理任务，例如：配置管理计划审批、基线设立审批、产品发布审批等。

5、配置审计包括功能配置审计和物理配置审计。配器审计的实施是为了确保项目配置管理的有效性，体现了配置管理的最根本要求——不允许出现任何混乱现象，例如：

（1）防止向用户提交不适合的产品，如交付了用户手册的不正确版本

（2）发现不完善的实现，如开发出不符合初始规格说明或未按变更请求实施变更

（3）找出各配置项间不匹配或不相容的现象

（4）确认配置项已在所要求的质量控制审核之后纳入基线并入库保存

（5）确认记录和文裆保持着可追浏性

1）功能配置审计是审计配置项的一致性

（1）配置项的开发已圆满完成

（2）配置项已达到配置标识中规定的性能和功能特征

（3）配置项的操作和支持文裆已完成并且是符合要求的

2）物理配置审计是审计配置项的完整性

（1）要交付的配置项是否存在

（2）配置项中是否包含了所有必需的项目

6、配置项的内容主要包括：

（1）外部交付的软件产品和数据；

（2）指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。

        典型配器项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。

7、配置项的状态有三种：草稿、正式发布和正在修改。

        配置项刚建立时，其状态为“草稿”。处于“草稿”状态的配置项的版本号格式为0.YZ，YZ的数字范围为01~99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。

        配置项通过评审后，其状态变为“正式”。处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1~9。Y为次版本号，取值范围为0~9。配置项第一次成为“正式”文件时，版本号为1.0。

        此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状

态又变为“正式”。处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。

8、配置库的主要作用：

（1）记录与配置相关的信息

（2）利用库中的信息可评价变更后的后果，这对变更控制有着重要的意义。

（3）从库中可提取各种配置管理过程的管理信息，可利用库中的信息查询回答许多配置管理问题

9、配置管理可能出现的问题：

（1）未建立配置管理系统和机制，配置管理混乱

（2）未设置专门的配置管理员，对配置进行综合管理

（3）没有做好整体版本管理

（4）没有建立基线。导致需求、设计、编码无法对应

（5）没有做好变更控制

（6）配置管理人员经验不足

（7）对配置管理工具没有进行有效评估

（8）未进行配置工具使用及配置管理的培训

（9）未制定配置管理计划

（10）未建立配置管理机制及权限管理，配置管理较乱

（11）没有定义配置管理流程

十四、收尾管理

需要掌握的夫知识点：

1、通常，系统集成项目的验收工作包括：

（1）系统测试

（2）系统的试运行

（3）系统的文裆验收

（4）项目的最终验收报告

2、项目总结

项目总结属于项目收尾的管理收尾。而管理收尾有时又被称为行政收尾，就是检查项目团队成员及相关干系人是否按规定履行了所有责任。实施行政结尾过程还包括收集项目记录、分析项目成败、收集应吸取的教训，以及将项目信息存裆供本组织将来使用等活动统一为一个整体。

3、项目总结会的内容

总结的内容应包括：项目绩效，技术绩效、成本绩效、进度计划、绩效识别问题和解决问题意见和建议。

4、项目总结内容和意义

（1）了解项目全过程的工作情况及相关的团队或成员的绩效状况

（2）了解出现的问题并进行改进措旄总结

（3）了解项目全过程中出现的值得吸取的经验并进行总结

（4）对总结后的文裆进行讨论，通过后即存入公司的知识库，从而纳入企业的过程资产

5、甲方不验收，一般可以怎么做?

（1）请求公司的管理层出面去与甲方协调

（2）重新确认需求并获得各方认可

（3）和甲方明确合同、以及双方确认的补充协议等，包括修改后的范围、进度和质量方面的文件等，作为验收标准

（4）准备好相应的项目结项文档，向甲方提交

6、对于系统集成项目，所涉及的文档应该包含如下部分：

（1）系统集成项目介绍

（2）系统集成项目最终报告

（3）信息系统说明手册

（4）信息系统维护手册

（5）软硬件产品说明书、质量保证书等

7、项目收尾可能存在的问题

（1）未制定规范的项目收尾规程

（2） 没有做好验收前的准备工作，软件还存在缺陷，缺隆未经修复和确认便进入正式验收环节

（3） 在验收过程中未根据变更控制流程对软件进行修改，导致文档与软件不一致

（4）软件更新后没有对文档进行变更便交付给客户

（5）项目产品未经正式验收和确认，未签署验收报告就进行了项目总结

（6）项目收尾时应提交的必要文件没有准备好，并经客广签收验证

（7）催收剩余款项没有正式和必要的依据

（8）项目收尾时与建设方的勾通工作没有做好

（9）项目在产品和项目工作上都还不满足收尾条件

（10）项目总结报告未能反映项目的实际情况

（11）未经过正式规范的收尾就提前报告项目结束、可进行人员转移，给项目带来诸多风险（12）项目总结会议没有让全部项目人员参与