3,CM系统的概念 

　  前一小节简述了CM系统关注的需求，本小节将详细论述CM系统的功能。某种程度上讲，这部分将验证上一小节中提到的支持某些功能域的概念，这些概念通过对CM系统演进的表现来组织，每一种概念在一种特定的CM系统下描述。CM系统关心的将要讨论的功能域包括：组件、过程、结构组合、构建特性和团队概念。图2显示了CM系统的概念图谱，下面是对概念和优势的简要描述。这一部分以一个总结和一个对这些概念优势和限制的分析作为结束。

    . 软件配置管理概念－3.1 警告
    . 软件配置管理概念－3.2 组件概念
    . 软件配置管理概念－3.3 过程概念
    . 软件配置管理概念－3.4 结构和构建概念
    . 软件配置管理概念－3.5 团队概念

    4,CM系统的未来

    图2展示的概念代表了典型的商用CM系统的概念，随着研究的继续，以及使用和组合概念的经验，许多新武器将会加入进来，这意味着有可能CM系统将会获取一组新的基础CM服务来满足用户的需求。但是，不考虑是否每个CM系统设计师正在努力实现相同的特性，始终有一些政治和技术问题影响着CM系统的未来。（政治问题关系到市场和标准；技术问题关注实现特定机制的可行性。）

　  一个主要的政治问题是电脑辅助软件工程（CASE）工具的演进。例如，是否CASE工具零售商会回避用他们的工具范围内实现CM，并且假定环境零售商将会在它们的框架中提供CM支持？如果CASE零售商与其自己的CM工具支持绑定，当用户安装它们的CASE工具时，将需要解决集成不同CM 系统的问题。同样，从零售商的角度，他们会从本质上重复解决许多环境框架解决的问题吗？

　  另一方面，如果CASE零售商不将CM工具组合到工具中，他们可以依赖CM环境工程提供合适的框架来集成CASE工具，并且同时提供一些全局性的CM功能吗？没有人知道这些问题的答案。在任何情况下，CM系统与环境的关系有一种隐含的标准，反之亦然。

　  许多技术，研究问题影响CM系统的能力，类似的问题正在上升。构建CM系统基础的合适技术是什么？一个支持对象持久化的面向对象数据库是否合适？什么级别的环境是CM合适的？它在数据库中必须是基础级别，环境框架的集成部分吗？或者是将CM指定为架构中的较高等级？CM的机制是否可以与CM 功能分离，也就是是否有标准的CM原型可以用在所有的环境来支持所有的CM功能？是否有一个统一的CM模型？是否可以支持分布式的CM支持？地理位置分离的团队是否可以使用同一个CM系统来进行本地CM和系统集成？这是业界，特别是国防部的协议中的主要问题。是否有可能支持跨软件开发？工程师是否可以在主机开发一个产品，并在维护中同时发布到目标机器？标准是否扩大了CM系统的限制？是否CM同样的支持一个百万行代码的产品和一个上亿行代码的产品？是否可以对CM过程的所有方面，包括用户敏感的部分建模，并在CM系统中实现？

　  以上问题的答案还不清晰，进展很有可能会源自各个方面－－从CM系统零售商，环境架构师和研究员，工具集成员，软件过程建模论坛和电脑辅助设计/工程，电脑集成生产商世界。

　  5,结论

    CM是对软件产品演进的管理，在CM系统的操作级别，CM是标识、控制、统计、审核、复审、加工、过程管理和团队协作。这是一个软件工程环境领域取得的进展，这显然是来自概念图谱，也是来自现存CM系统和其能力。本文展示的图谱是对许多不同CM系统实现的概念的快照，每一种系统专注不同的用户问题－－角色、集成、控制、自动化程度、过程对产品的支持和使用系统提供的功能进行CM的非常好的开始时间。希望提供这个图谱可以辅助我们理解CM系统的能力，并且能够提供一个讨论CM工具支持的共同框架。

    致谢

　  十分感谢本文的评审者，特别是Peter Feiler, Grace Downey, Kurt Wallnau, Ed Morris, Bob Ellison, Chuck Weinstock, Mario Barbacci, Rick Green, Jim Tomayko, 技术作家Marie Elm和SCM3的评审者。