ISO 9001/CMMI 对于源代码控制，特别是 Git/Mercurial/DVCS 有何影响？
熟悉 Team Foundation Server 的人曾向我询问过有关分布式源代码控制的问题。
是否可以使用 Git 或 Mercurial 等 DVCS 进行源代码控制并遵守 ISO 9001 或 CMMI 等标准？
ISO 9001 和 CMMI 对源代码控制工具应该具备哪些能力和不应该具备哪些能力提出了哪些要求？
Git/Mercurial 是否有任何 ISO 9001/CMMI 认为有害或需要特定考虑的事情？
我在 http://www.ssqc.com/do25v6new.pdf 找到了一些信息，但是乍一看，除了需要记录更改内容、部署的软件版本以及修复的问题之外，它似乎没有说太多，而且 DVCS 没有理由不能够结合 Bug 跟踪器（例如 FogBugz）和 CI 服务器（例如 TeamCity）来处理该问题。
I've been asked this question about distributed source control in general by someone who's familiar with Team Foundation Server.
Is it possible to use a DVCS such as Git or Mercurial for source control and comply with standards such as ISO 9001 or CMMI?
What requirements do ISO 9001 and CMMI place on what source control tools should and should not be capable of?
Are there any things that Git/Mercurial do that ISO 9001/CMMI would Consider Harmful or that would require specific considerations?
I've found some information at http://www.ssqc.com/do25v6new.pdf but at a quick glance it doesn't seem to say much other than the need to keep records of what's changed, which versions of your software you've deployed, and which issues they fix, and there's no reason why DVCS shouldn't be able to handle that in combination with a bug tracker such as FogBugz and a CI server such as TeamCity.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
首先，软件不符合 ISO 9001 标准。 只有组织符合 ISO 9001 标准。所以所提出的问题确实没有任何意义。您唯一可以询问的是 Git 或 Mercurial 开发团队是否符合 ISO 9001 标准。 （CMMI 也是如此）。
对于软件开发机构而言，ISO 9001 的真正含义是，您所做的一切（开发、错误修复等）都有一个书面流程，并且您必须遵循该流程。好吧，您已经花钱请人来进行 ISO 9001 审核，以证明上述内容。 CMMI 涉及的内容要多得多，但出于本次讨论的目的，我们可以认为它们是相似的。
您可能需要花很长的时间才能找到一个自由软件社区项目，该项目费心去完成创建所有流程文档所需的大量繁重工作，并筹集资金来支付审计费用。如果你找到了一个，那可能只是因为某种大型企业赞助商想要它。
如果问题是这些标准对源代码控制的使用有何规定，那么对于 ISO 9001 来说，这将是无意义的。有一个老笑话是，如果你把你的产品从 10 层楼的窗户扔到下面的装货码头，只要这是你记录下来的流程并且你遵循它，ISO 就可以了。
First off, software is not ISO 9001 compilant. Only organizations are ISO 9001 compilant. So the question as stated really makes no sense. The only thing you could ask is if the Git or Mercurial development teams are ISO 9001 compilant. (The same goes for CMMI).
All ISO 9001 for a software development outfit really means is that you have a written process in place for everything you do (development, bug fixes, etc) and that you follow it. Well, that and you've paid someone to come do an ISO 9001 audit certifying as to the above. CMMI is a lot more involved, but for the purposes of this discussion, we can consider them similar.
You'd probably have to look pretty long and hard to find a Free Software community project that bothered to go through the massive grunt work required in creating all the process documentation and that scraped together the money to pay for an audit. If you find one, it would probably only be due to some kind of large corporate sponsor wanting it.
If the question is what those standards specify about the use of Source Control, in the case of ISO 9001 that would be nothing. The old joke is that if you take your product and drop it out a 10 story window to the loading dock below, that's just fine by ISO as long as that's your documented process and you follow it.
我在 21 CFR 820（受监管的医疗器械）/ISO 13485 环境中工作，但“总体情况”与 ISO 9001 非常相似。我同意上述关于 ISO 9001 是关于流程而不是工具的所有内容。
但是，您可能在需要实施工程设计控制程序的领域工作，而设计控制将涉及开发人员使用的流程、工具和工作说明。特别是在医疗器械领域，我们必须担心任何影响产品安全性或有效性的软件工具。这包括用于配置管理和版本控制的工具（如果您无法控制正在构建的软件版本，则无法令人信服地说您知道现场有哪些版本，因此您无法分辨联系哪些客户进行召回）。
对于此类工具，我们必须拥有“计算机系统验证”(CSV) 文档。第三方工具的 CSV 包括 (1) 工具规范，描述产品开发周期内的用例及其如何影响质量，以及 (2) 测试用例，可以提供客观证据，证明该工具在预期用例中有效。
对于版本控制系统，这基本上意味着一份描述您使用的功能（签入、签出、分支、标签）的白皮书以及对这些功能的一些测试，以证明它们的工作原理。为了获得加分，如果该软件有自己的测试套件，您可以提供它运行并通过自己的测试的证据。
I work in a 21 CFR 820 (regulated Medical Device)/ISO 13485 environment, but the "big picture" is much the same as ISO 9001. I agree with all the things above about ISO 9001 being about process, not tools.
However, you may be working in an area where you need to implement procedures for engineering design controls, and design controls will touch on the processes, tools, and work instructions used by developers. In particular, in the medical device arena we have to worry about any software tools that have bearing on the safety or effectiveness of the product. This includes tools for configuration management and version control (if you can't control which version of the software you are building, you can't say convincingly that you know which version(s) are in the field, so you can't tell which customers to contact for a recall).
For such tools, we have to have "Computer Systems Validation" (CSV) documentation. CSV for a third-party tool includes (1) a tool specification which describes the use cases within the product development cycle and how they affect quality and (2) test cases which can provide objective evidence that the tool is effective in the intended use cases.
For a version control system, this would mean basically a white paper describing the features you use (checkin, checkout, branches, tags) and some tests of those features demonstrating that they work. For bonus points, if the software has its own test suite you can include evidence that it runs and passes its own tests.
从 CMMI 主页：
CMMI 处理的是流程，而不是工具。我的理解是，如果您有执行此操作的流程（级别 2）并遵循该流程（级别 3、4、5），则您可以使用粘土片进行版本控制并符合 CMMI。
From the CMMI homepage:
CMMI deals with process, not tools. My understanding is that you could version control with clay tablets and be CMMI compliant if you had a process for doing it (level 2) and followed the process (level 3,4,5).
我能够参加 SCAMPI C 审核以及为前雇主的两个 CMMi 流程组开发流程，并且我们与我们的 CMMi 顾问就版本控制进行了一些深入的讨论。在此过程中我们没有使用 DVCS，但由于上述许多原因，我不明白为什么这会成为问题。
就 CMMi 实际审核的内容而言，其他发帖者正确地指出，只要记录了流程并且开发人员理解并可以适当地引用该流程，就应该没问题。
在确保您的团队准备好通过 CMMi 审核方面，唯一需要注意的就是尝试将中型/大型团队从开源 VCS（SVN、CVS）或商业 VCS（MKS、 AccuRev 等...）到 DVCS，但没有适当的旋转时间。由于过渡可能会令人不安，因此您需要确保您的团队在参与审核之前牢牢掌握所有 DVCS。
I was able to take part in a SCAMPI C audit as well as develop process for two CMMi Process Groups at a previous employer and we had some in-depth discussions about version control with our CMMi consultant. We were not using a DVCS during this process, but for many of the reasons mentioned above I can't see why it would be a problem.
In terms of what CMMi actually audits for, the other posters are correct in stating that as long as the process is documented and the developers understand and can cite the process appropriately, you should be ok.
In terms of ensuring that your team is ready to pass a CMMi audit, the only thing that would be a slight concern would be trying to transition a medium/large sized team from open source VCS (SVN, CVS) or commercial VCS (MKS, AccuRev, etc...) to a DVCS without the appropriate spin-up time. Because the transition can be jarring, you want to make sure your team has a firm grip on any DVCS before engaging in the audit.
正如其他人指出的那样，ISO 9001 与工具无关。在符合 ISO 9001 的机构工作表明他们（机构本身）是“成熟的”。在这种情况下，“成熟”一词表示组织严格遵守经过审核并符合 ISO 9001 的流程。涉及 Git 或 Mercurial 的流程不会以任何方式影响您遵守 ISO 9001 的能力（除非您不遵循这些流程）。
至少，这是我对这一切的理解。
As other people have noted ISO 9001 is not about the tool. Working at an institution that is ISO 9001 compliant signals they (the institution itself) are "mature". The word mature, in this context, indicating that the organization strictly adheres to processes that have been audited and found to be ISO 9001 compliant. Processes that involve Git or Mercurial will not affect your ability to become ISO 9001 compliant in any way (unless you don't follow the processes).
At least, that's my understanding of it all.