l 结构：表示产品的架构。
l 创建：支持产品的构建及其产品的附件。
l 审核：对产品及其过程的审核予以保留。
l 统计：采集与产品、过程相关的数据。
l 控制：控制产品变更的方式及时间。
l 过程：支持产品演变的管理。
l 团队协作：促进项目组开发及产品维护。
以下将对这些功能区域的进一步探讨。
u 对于元素的要求，用户要：记录元素的版本及其差异，差异的原因；确定构成配置及配置版本的组件群；标识出产品的基线及其外延产品，确定表示项目组件群及附件项目环境。而且，用户需要数据库来存取组件及CM信息，同时还有资源和对象编码、执行情况、图表、文档和基线。
u 对于机构的要求而言，用户要：通过表示产品组件库的系统模型来模拟产品的结构；标明组件、版本、配置的界面使之可以重用；确定及维护组件间的关系；选择兼容的组件使之形成有效的、一致的产品版本。
u 对构建的要求而言，用户要：容易创建产品的手段；能随时静态分析产品的现状；通过减少组件的堆积和节省区间来优化系统创建的机制；进行更改分析以预测因更改而导致的细小分化的手段；随时都能对产品的任何部分、在任何阶段容易得到更新。
u 对于审核的要求而言，用户要：所有更改的历史记录；所有与产品相关的组件与其演变的追溯性；完成任务的所有细节的日志。
u 对于统计的要求而言， 用户要：统计记录的机制，产品现状的检验，有关产品和过程的所有方面的报告能较易产生。
u 对于控制要求而言，用户要：为避免不必要的变更或变更冲突对系统中的组件的获取应予以控制，对于更改要求的表格及问题报告形成在线支持；错误查找的手段及何时对何人会产生什么影响；在不同但相关的产品版本之间以受控的方式进行更改告知；将产品进行分割的手段以限制更改影响。
u 对于过程要求而言，用户要：对生命周期模型及组织方针予以支持；确定要完成的任务及如何完成、何时完成的能力；将相干的事务的讯息在适当的人员之间进行沟通的能力；将产品的经验文档化的手段。
u 对于团队协作的要求而言， 用户要：个人和小组的工作区间；在汇合时产生冲突的解决办法；对产品的创建及其维护予以支持的手段。
注意：图中过程方框与团队方框代表功能区域极为重要的部分。这是因为它们影响所有其它区域或受到所有其它区域的影响。对于用户来讲，理想的CM系统随团队协作和过程的完全融合应当能支持所有的功能区域。但目前还没有此类系统。
2.2 CM系统的集成任何CM系统在某种程度上都能与它的环境融合。CM系统可与其它工具并存或完全融合。适合与不同环境方面融合的有：过程、工具组和数据库。过程集成是将CM系统的使用模式（指CM过程）同环境的使用模式（指软件生命周期过程）的结合；工具组的集成是将CM系统安装在环境中使之至少能环境中其它所有工具共存。譬如，在编辑过程中， 每当用户发出“SAVE”命令时，用户就会要求CM功能能建立一新的版本。数据集成指的是CM数据库的逻辑定位——它是否能与现存环境的数据库能做某种方式的合并，或它的数据库是否独立存在的，或它能否利用其它数据库中的信息。所有此类集成都是普通的工具集成和技术的转换问题。但，由于CM将影响到环境中的绝大部分物件并贯穿每一物件生命周期的所有阶段，CM系统的集成势必对环境中的很多工具有重要影响。大多数CM系统能与其它工具共存，有些环境把CM看成其必不可少的一部分。
2.3 何时启用CM系统对于在开发和维护产品过程中, 项目组何时启用CM系统是不定的。有些项目组选择在产品经历开发生命周期并准备发到用户地时开始启用。有的选择在项目一开始就将一切置于CM下。二者都有各自的一般费用。譬如，项目组可能基于变更要求的费用上来决定何时启用。如果有许多的手工程序（如：将变更申请表归档、寻求CCB的批准与确认可），项目组会选择在大部分开发完成之后将软件置于CM的控制之下。但如果变更要求程序能在线很快地得到处理，CM将在软件生命周期的早期就被用上。理论上讲，CM在产品的整个生命周期都能派上用场 —— 从创建、开发、产品发放、交付、使用到维护。在理想的情形下，CM能在较少的花费下对此予以支持，由此CM才能在项目中尽可能早地予以应用。
然而，现有的CM系统只关注生命周期的某一特定的阶段，用户因此受到限制。
文章来源于领测软件测试网 https://www.ltesting.net/
