What are the implications of ISO 9001/CMMI for source control in general, and Git/Mercurial/DVCS in particular?

Question

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.

Answer 1

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.

Answer 2

From the CMMI homepage:

CMMI is a process improvement approach that provides organizations with the essential elements of effective processes that ultimately improve their performance.

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).

Answer 3

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.

Answer 4

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.