我目前为组织工作的组织正在进入整个CMMI世界，记录所有内容。我被分配（以及另一个人）配置管理器的标题。恭喜我。
部分职责是定期执行（他们仍然定期定义，每季度或每月定期）进行物理配置审计。这基本上是对生产中部署的源代码版本的检查，以及我们认为是生产中的源代码版本。
我们的项目是一个用Java编写的相对较小的Web应用程序。我们使用的文件类型是java，jsp，xml，属性文件和sql包。
我遇到的问题（并且已经表达但似乎被忽略了）是我应该如何物理登录到生产服务器并验证文件版本，即使我可能需要花费大量时间？
文件版本甚至不在文件中（即在评论或其他内容中）。有人建议我们在用户也可以看到的每个屏幕上放置可见的版本号。我认为这也很荒谬，因为屏幕本身只代表我们维护的代码的一小部分。
我们目前使用的工具是用于IDE的Netbeans和用作版本控制工具的Serena Dimensions。
我正在寻找有关如何以更加自动化的方式执行此审核的想法，这既准确也不耗时。
我的想法是在每个文件的顶部添加注释，其中包含该文件的版本号，在创建生产版本以创建XML文件时运行的脚本或包含文件名和版本的类似文件构建中每个文件的文件。然后，当我需要进行审核时，我会转到生产服务器，获取带有信息的xml文件，并以编程方式将其与我们认为的生产中的内容进行比较，然后输出报告。
任何更好的想法。我知道这已经完成了，对我来说似乎很疯狂，我没有找到任何其他资源。
答案 0 :(得分：4)
您可以在生产服务器上计算源文件的SHA1哈希值，并将该哈希值与源代码管理中存储的版本进行比较。如果您可以在源代码管理中找到相同的哈希，那么您就知道正在生产的版本。如果无法在源代码管理中找到相同的哈希值，那么生产中就会有未经修改的修改，并且您的新职位名称是合理的。 ：）
答案 1 :(得分：3)
典型的陷阱组织陷入困境，CMMI正在试图超越一切。如果我可以提出任何建议，那么它将从小事做起。只做你需要的。因此，请考虑您在CM领域可能遇到的任何问题。
CMMI描述了一个组织应该做什么，但留下了如何做到这一点。 CMMI specification，第2章非常值得一读 - 它描述了规范中所需的，预期的和信息丰富的组件 - 基本上是需要的目标，预期的实践，以及其他一切都是提供信息的。这意味着CMMI评估师可以直接要求的规范中只有一小部分 - 目标。在实践层面，允许采用所描述的实践，或可接受的替代方案。
在配置审核的情况下，目标SG3是“建立并维护基线的完整性”。 SP3.2说“执行配置审核以维护配置基线的完整性。”这里没有说明这些事情的执行频率，或者他们可能需要多长时间。
在我之前的组织中，FCA / PCA通常只作为产品发布过程的一部分完成，我们使用ClearCase作为版本控制工具，在代码库中应用标签来定义基线。我们在所有源文件中都没有版本号，也没有在所有产品屏幕上都有版本号 - CM活动正在做正确的事情＆amp;审计支持，这在任何CMMI评估中都不是问题。 我们可以使用标签之间的增量来查看哪些文件已更改，执行差异以查看实际的代码更改。该过程的一个重要部分是能够将这些变化链接回需求/错误报告/无论发起变更的原因是什么。
我们的审计确实使用脚本来自动化过程，但这些是内部开发的脚本特定于ClearCase - 基本上它们会列出所有文件，它们在CM系统中的版本以及它们的基线/配置项属于
答案 2 :(得分：0)
你不能使用你的源代码管理吗？如果部署版本并使用该部署标记sourcecontrol，则可以针对源控制系统进行验证