遗憾的是，其中只有一种组合才是我们真正想要的。没有足够的信息，没有合理的管理手段，我们将面临危机（事实上，这种危机在许多项目中已经一再地出现了）。
还有另外的一些问题对项目同样会产生影响。比如，在软件项目组中，往往是许多人一起配合工作。这时会出现一种需求：每个人要求工作在一个“独立”的工作环境中，也就是要求每个人进行工作时，不能影响和干扰其他人的工作和成果。但同时，当经过一定的授权或者认定后，还要求可以比较便捷地和其他人的工作进行配合。这种既独立又联系的关系，使得通常的管理手段显得力不从心。
综合上面的问题可以看出，大量的问题已经不再是单纯的技术问题了，而是需要一项专门的管理手段来处理。这个管理手段直接的目的就是保持项目的稳定性（虽然也能间接提高质量），减少因上述原因引起的项目混乱而造成的负面影响。这就是“配置管理”的产生原因。
SCM的责任
根据IEEE的定义，“软件配置管理（Software Configuration Management , SCM）是一门应用技术、管理和监督相结合的学科，通过标识和文档来记录配置项的功能和物理特性、控制这些特性的变更、记录和报告变更的过程和状态，并验证它们与需求是否一致。”从定义可以看出，软件配置管理（SCM）是一门综合性的学科，其中不仅包含管理，也包含一些技术手段。另外，SCM通过管理配置项控制变更、验证变更，使项目的混乱减到最小，使错误达到最小，并最大限度地提高生产率。
实施软件配置管理的目的是保证软件项目的工作产品在整个项目周期中的“完整性”。所谓完整性是指，工作产品要求有完整的变更历史记录，要求有正式的变更过程，而且还要求保证工作产品能和需求以及变更保持一致性。
为应用SCM支招
从上述的定义中，我们已经可以归纳出要实施软件配置管理，需要进行哪些活动了。
首先，要进行配置项的标识。所谓配置项，简单地说就是受SCM控制和管理的工作产品单元，也是配置管理的目标。什么能作为配置项进行管理？下面举一些例子，程序（源代码、目标代码、可执行程序、函数等）、文档（需求定义、系统分析、系统设计、高层设计、低层设计、测试规格说明书、测试计划、安装手册、发布说明、用户手册等）、数据（测试数据和项目数据）、执行文件等，都是典型的配置项。但有几个问题需要讨论：一、配置项划分的颗粒度问题。也就是说，配置项实际上是逻辑的概念，不完全对应物理上的文件，因此为了便于管理，就要进行一定程度的划分，比如典型的，可以把用来生成一个“构件”的几个代码文件设定为一个配置项，这样在进行变更时就需要同时对这些文件进行修改。二、不一定要把所有的工作产品都作为配置项。有些工作产品，比如状态报告，相当稳定，不容易变化，同时对最终产品发布没有直接影响，就可以考虑不作为配置项进行管理。为什么要这样考虑呢？因为如果作为正式的配置项，需要进行配置项的标识、控制、报告等等工作，会给项目增加不必要的成本。因此，可以考虑对这些产品仅仅进行简单的管理就可以了。但是对诸如项目计划文档，仍然需要进行软件配置管理。三、对于一些没有实际物理文件，但仍然需要进行配置管理的工作产品，比如操作系统参数、编译器描述、物理特性、版本描述等，为了能进行配置管理，需要对其进行描述，并形成文档，再以配置项形式进行管理。比如进行技术变更时，就有可能需要改变系统参数。
此文章共有4页 上一页 1 2 3 4 下一页
文章来源：中国项目管理资源网
 软件开发项目管理培训课程方案
|
Leadge.com首页 > 知识库 
