|
|
|
变更是指在信息系统项目的实施过程中，由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变。项目变更是正常的、不可避免的。在项目实施过程中，变更越早，损失越小；变更越迟，难度越大，损失也越大。项目在失控的情况下，任何微小变化的积累，最终都会对项目的质量、成本和进度产生较大影响，这是一个从量变到质变的过程。
|
|
|
|
|
|
|
|
（2）项目总体设计、项目需求分析不够周密详细，有一定的错误或遗漏。
|
|
|
|
（3）新技术的出现，设计人员提出了新的设计方案或新的实现手段。
|
|
|
|
（4）建设单位由于机构重组等原因造成业务流程的变化。
|
|
|
|
|
|
配置库也称为配置项库，是用来存放配置项的工具。配置库记录与配置相关的所有信息，其中存放受控的配置项是很重要的内容，利用库中的信息可评价变更的后果，这对变更控制有着重要的意义。
|
|
|
|
|
|
（1）开发库（development library）。存放开发过程中需要保留的各种信息，供开发人员个人专用。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统（开发者系统、开发系统、工作空间）。
|
|
|
|
（2）受控库（controlled library）。在信息系统开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的，以及人工可读的文档资料。应该对库内信息的读写和修改加以控制。受控库也称为主库，对应配置管理系统中的主系统（受控系统）。
|
|
|
|
（3）产品库（product library）。在开发的信息系统产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。库内的信息也应加以控制。产品库也称为备份库，对应配置管理系统中的静态系统（受控系统）。
|
|
|
|
作为配置管理的重要手段，上述受控库和产品库的规范化运行能够实现对信息系统配置项的管理。
|
|
|
|
|
|
变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪，以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案，尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。
|
|
|
|
|
|
变更控制委员会（Change Control Board, CCB）也称为配置控制委员会（Configuration Control BoarD），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以是全职的，也可以是兼职的。
|
|
|
|
如果CCB不只是控制变更，而是承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。
|
|
|
|
|
|
|
|
（1）变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
|
|
|
|
（2）变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
|
|
|
|
（3）变更决策。由具有相应权限的人员或机构决定是否实施变更。
|
|
|
|
（4）变更实施。由管理者指定的工作人员在受控状态下实施变更。
|
|
|
|
（5）变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
|
|
|
|
（6）沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。
|
|
|
|
变更申请需要采用书面的形式提出，主要内容有如下3个方面：
|
|
|
|
（1）变更描述。包括变更理由、变更的影响、变更的优先级等，就是要申述做什么变更，为什么要做，以及打算怎么做的问题。
|
|
|
|
（2）对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和CCB对此项变更把关。
|
|
|
|
|
|
|
|
配置项可以有3种状态，分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来，对于其他配置项来说是处于不处理工作状态下（自由状态），此时它并未受到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库（实施检入），开始冻结，此时开发人员不允许对其做任意修改，因为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。配置项的状态变化过程如下图所示。
|
|
|
|
|
|
|
|
处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。
|
|
|
