执行CMMI物理配置审计的最佳方法？

Question

我目前正在为一个组织进行工作，该组织正在进入整个CMMI记录一切的组织。我被分配（和另一个人一起）配置管理器的标题。恭喜我，对了。

部分职责是定期执行（他们仍在定义定期基础，它将按季度或按月进行）物理配置审计。这基本上是对生产中部署的源代码版本进行检查，以检查我们认为是生产环境中的源代码版本。

我们的项目是一个用Java编写的相对较小的Web应用程序。我们使用的文件类型是java，jsp，xml，属性文件和sql包。

我已经（并已表达，但似乎将被忽略）的问题是我该如何物理登录到生产服务器和验证文件版本，即使我可以需要一个荒谬的时间？

文件版本甚至不在文件中（即在评论或其他文件中）。有人建议我们在用户可见的每个屏幕上放置可见的版本号。我认为这也是荒谬的，因为屏幕本身只代表我们维护的一小部分代码。

我们目前使用的工具是用于我们IDE和Serena Dimensions的Netbeans作为我们的版本控制工具。

我正在寻找关于如何以希望更自动化的方式执行此审核的意见，这将是既准确又不耗时。

我的想法是在每个包含该文件版本号的文件顶部添加一条评论，该脚本在创建生产版本时创建，用于创建XML文件或类似的文件名，版本中每个文件的版本文件。然后，当我需要执行审计时，我会转到生产服务器，抓取包含info的xml文件，并以编程方式将其与我们认为正在生产的内容进行比较，然后输出报告。

任何更好的想法。我知道这件事已经完成了，对我来说似乎很疯狂，我还没有找到任何其他资源。

Answer 1

你可以计算在生产服务器上的源文件的SHA1哈希值，和比较哈希值存储在源代码控制版本。如果您可以在源代码管理中找到相同的散列，那么您就知道生产中的版本是什么。如果不能在源代码管理中找到相同的散列，那么在生产中会有未跟踪的修改，并且您的新职位是合理的。 :)

Answer 2

你不能使用你的源代码管理这个吗？如果您部署版本并使用该部署对源代码管理进行标记，则可以对源代码管理系统进行验证

Answer 3

典型的陷阱组织属于CMMI试图过度使用的一切。如果我可以建议任何事情，它会从小&只做你需要的。所以考虑一下你在CM领域可能遇到的任何问题。

的CMMI描述了一个组织应该做的，但保留如何给你。 CMMI specification，第2章非常值得一读 - 它描述了规范中所需的，预期的和信息性的组成部分 - 基本上是需要目标，实践是预期的，其他一切都是信息性的。这意味着只有CMMI评估师可以直接要求的规范的一小部分 - 目标。在实践层面上，可以采用所述的做法，或可接受的替代品。

在配置审核的情况下，目标SG3是“基线的完整性建立和维护”。 SP3.2说：“执行配置审核以保持配置基线的完整性。”这里没有说明这些工作的频率如何，或者可能需要多长时间。

在我以前的组织，FCA/PCA是通常只完成作为产品发布过程的一部分，我们使用的ClearCase作为版本控制工具，与整个代码库以确定适用的基准标签。我们在所有源文件中没有版本号，在所有产品屏幕上也没有版本号 - CM活动正在做正确的事情&由审计支持，并且这在任何CMMI评估中都不是问题。 我们可以使用标签之间的增量来查看哪些文件已更改，执行差异来查看实际的代码更改。流程的一个重要部分是能够将这些变化返回到需求/错误报告/无论发起变更的原因是什么。

我们的审计确实使用了脚本来自动化这个过程，但是这些内部开发的脚本是ClearCase特有的 - 基本上它们会列出所有文件，它们在CM系统中的版本，以及基线/配置项目他们属于。