项目配置管理案例分析.docVIP

项目管理案例分析 在一个正在实施的系统集成项目中出现了下述情况：一个系统的用户向他所认识的一个项目开发人员抱怨系统软件中的一项功能问题，并且表示希望能够进行修改。于是，该开发人员就直接对系统软件进行了修改，解决了该项功能问题。针对这样一种情况，请分析如下问题： 1.说明上述情况中存在着哪些问题？ 2.说明上述情况可能会导致什么样的后果？ 3.在配置管理中应有完整的变更处置流程。 分析： 变更来源有两个方面 用户：是信息系统项目需求的提出者，要求用户一次性把需求讲清楚，并且不允许此后做任何变更，是不现实的。开发方只能尽力减少变更，降低其影响。开发人员如何解决好自己的工作产品与变更的用户需求之间的一致性，是需求管理这个关键过程的主要目标。 开发人员自身：他们在工作中可能发现前期工作中有些不妥当的地方，或是项目管理人员提出要修订已经确定了的项目方案。由此所导致的返工甚至部分工作产品的报废也是在所难免的。 无论来自那个方面的变更，都需要严格按照变更控制的流程进行，否则会给开发和后续维护带来很多问题。 说明上述情况中存在着哪些问题？ 没有对用户口头反映的问题进行文档化，即没有对用户的要求进行记录。任何变更申请都必须以书面的形式提出。 没有分析和评估用户变更请求。开发人员在获得用户得变更请求后，应该提交给变更管理委员会软件配置管理SCM）是一套规范、高效的软件开发基础结构。作为管理软件开发过程有效的方法SCM 可以系统地管理软件系统中的多重版本；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。SCM 对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率。从某种角度讲，SCM是一种标识、组织和控制修改的技术，目的是使错误降为最小并最有效地提高生产效率。SCM 是通往ISO9000 和SEI CMM 标准的一块基石。软件配置管理主要任务有以下几方面的内容配置标识 要配置标识，首先必须明确项目生命周期内所要产生的工作产品，然后确定工作产品的名称和标识规则。总体原则是，保证配置管理工具检索便利，让项目组成员容易记住标识规则，同时要确保组织一级的标识规则的一致性。 版本管理 版本管理一般是使用工具来完成的，如Rational ClearCase、Merant PVCS Version Manager、Microsoft Visual SourceSafe等。使用这些工具时，容易被忽视的一点是制定所使用工具的版本规则。如果直接采用工具的内部版本号，会给产品发布带来一些困难。通常采用“X.Y.Z”方式进行版本标识，明确X、Y和Z各位数字递增的规则，然后结合工具标签（Label）功能，便可实现高效的版本管理。变更管理 变更管理是项目管理的一个重点和难点，涉及的范围很广。实施高效的变更管理至少应该包括两个部分：“定义合理的变更管理流程”、“采用自动化工具作为支持”。在具体的实践中，应该对变更进行分类和分层，建立起处理不同变更的“变更控制委员会”（CCB），既保证项目组成员有一定的自主权，又不会耽误高层经理对关键问题的把握。配置审核 配置审核包括两方面的内容：“配置管理活动审核”、“基线审核”。“配置管理活动审核”用于确保项目组成员的所有配置管理活动，遵循已批准的软件配置管理方针和规程，如检入（Check in）/检出（Check Out）的频度、工作产品成熟度提升原则等。实施“基线审核”，要保证基线化软件工作产品的完整性和一致性，并且满足其功能要求。基线的完整性可从以下几个方面考虑：基线库是否包括所有计划纳入的配置项？基线库中配置项自身的内容是否完整？（如，文档中所提到的参考或引用是否存在？）此外，对于代码，要根据代码清单检查是否所有源文件都已存在于基线库。同时，还要编译所有的源文件，检查是否可产生最终产品。一致性主要考察需求与设计以及设计与代码的一致关系，尤其在有变更发生时，要检查所有受影响的部分是否都做了相应的变更。审核发现的不符合项要进行记录，并跟踪直到解决。 在实际操作过程中，一般认为审核是一种事后活动，很容易被忽视。但是“事后”也是有相对性的，在项目初期审核发现的问题，对项目后期工作总是有指导和参考价值的。为了提高审核的效果，应该充分准备好检查单。 报告配置状态 报告配置状态的目的，是向项目所有成员提供基线内容和状态、基线变更信息，这也是实现资源共享的前提。此外，在项目生命周期中进行对配置项的变更数据统计分析，有利于评估项目风险，有效控制项目的执行。在变更请求被批准、基线版本发生变化及项目组提出任何需要时，可以采用Email等方式