配置管理

 

本文阐述了信息系统项目的需求管理，需求管理在信息系统中的目的是确保项目各方对需求的一致理解，管理和控制需求的变更，实现从需求到最终产品的双向跟踪。在本项目中，我重点关注以下几个方面的需求管理工作。

 

一、配置管理计划

配置管理计划对于配置管理工作的成功实施，起着重要的作用，我通过如下步骤，完成制定配置管理计划：

配置管理计划的制定是配置管理中不可少的一步，它能有效的指导后期配置管理工作。在本项目中，配置管理计划由项目经理、客户代表、配置管理员，通过小组会议形式制定完成，主要内容包括：软硬件资源配置管理计划，配置项计划，交付计划，备份计划，基线计划，CCB审批计划等。建立了维护配置管理的组织方针，确定了配置管理的总负责人及其责任和权限，确了配置管理的项目干系人，确定其介入时机。总之，我认为项目前期做好以上铺垫工作可以减少变更，对后面一些工作可以说是水到渠成。同时，一个比较完整的计划，也可以避免不必要的项目反工，而且项目管理员的工作也会比较好做一些；

二、规范配置管理，注重版本发布

开发过程中，对文档修改非常麻烦，在配置管理中，对任何一配置项的修改都可能导致版本的变化。因此，对配置管理规范化势在必行，在本项目中，我要求配置标识一定要规范，必须独立命名配置项，配置对象的标识要充分考虑命名对象之间存在的联系。在配置管理中，项目组成员要各司其职，不得越权操作，同时还要根据自己的权限操作配置项。我的工作在配置管理中主要是：定制开发子系统，定制访问控制，制定常用策略，制定集成里程碑，进行系统集成．．．．．而配置管理员的职责主要是：创建配置顺序，为项目成员分配权限，对存储库进行日常备份恢复等．．．软件开发人员主要根据项目的开发配置管理策略，创建，修改和测试工作等。信息项目工程中某一阶段的变更都会引起软件配置的变更，对这种变更也必须做到严格规范的控制和管理。为此，我做了如下规定：处于工作状态的产品开发人员可对其修改，而作为基线进入配置库的产品，则不允许开发人员对其进行修改。在本项目中，我们还成立了临时变更控制委员会CCB,由项目经理，用户代表，质量控制人员，配置管理员5人组成。我们要求对于用户提出的变更请求要严格按照变更控制流程处理。在用户提交更多请求后，开发人员对其进行评价，并产生变更报告。由变更控制委员会〈CCB〉作出决定是否进行变更。通过批准，就重新检出变更的配置项，建立测试基准程序，并执行质量保证和测试活动，必须通过CCB的鉴定审批后，方可实施变更。项目中的各种文件、技术文档和程序版本均列入版本控制的范畴，按照一定的规则保存配置项的所有版本，配置管理员负责版本编号及控制工作。所有项目成员都必须遵照版本控制规程操作配置库。

 

三、需求跟踪

在实际项目开展过程中，经常会发生这样的情况。测试人员在进行测试时，发现某些需求未实现，或者客户接收测试时，发现某些功能点未测试全。诸如此类的问题，很大一部分原因是由于需求双向跟踪未做好。本项目采用需求双向跟踪，包括从用户原始需求到系统需求、设计、编码、测试用例等之间的双向跟踪。

 

双向跟踪包括：从需求到设计、源码、测试用例的过程，用于明确是否所有需求都被设计了、被编码了，被测试了等。一旦某个需求需要变更，就可以快速找到所有影响的范围。 

·反向跟踪：从缺陷到测试用例、源码、设计、需求的过程，用于明确所有的工作成果都是有对应的需求，避免测试多余、设计多余的情况发生。同时，一旦某项设计因多种原因发现需要变更，也可快速找到对应的需求，以便快速确认相应的需求是否需要变更。

 

 

在本项目里，我们采用RP实现了上述双向跟踪。通过该工具，大大减少我们人为进行需求双向跟踪所需的工作量。而且通过RP和CQ集成，在进行需求变更时，我们可快速找到需求关联项。 

 

 

经过上述过程的努力，项目的外包采购管理过程得到了有效的保障。经过团队的共同努力，该系统顺利在2011年11月份正式上线，半年后通过初验。回顾项目的整体需求管理工作过程，虽然基本上满足要求，但仍然存在许多小问题，包括对客户安全性需求把握不够、用户交互类产品用户体验不足等。发现这些问题后，我们及时的采取应急措施进行补救，总体上没有对项目进展造成大的影响。

 

综上所述，严谨的需求管理计划、严格的需求变更控制、需求双向跟踪管理，是我项目中需求管理中的几个主要实践，为项目的成功奠定了基础。在以后的项目整体管理工作中，我要加强关注各相关方利益的权衡，继续深化各方沟通，努力提高项目管理水平，更好地完成项目实施管理。