Cm系统是什么

Cm系统是什么

配置管理（Configuration Management，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系统零售商，环境架构师和研究员，工具集成员，软件过程建模论坛和电脑辅助设计/工程，电脑集成生产商世界。