jam*_*kes 9 git mercurial cmmi
我一直被熟悉Team Foundation Server的人问到有关分布式源代码控制的问题.
是否可以使用GCS或Mercurial等DVCS进行源控制并符合ISO 9001或CMMI等标准？
ISO 9001和CMMI对源控制工具应该和不应该具备什么要求？
有没有Git/Mercurial认为ISO 9001/CMMI会考虑有害还是需要特别考虑的事情？
我在http://www.ssqc.com/do25v6new.pdf上找到了一些信息,但是除了需要记录已更改的内容,您的软件的哪个版本之外,它看起来似乎并不多.已部署,以及他们修复了哪些问题,并且没有理由说DVCS不能与FogBugz和CI服务器(如TeamCity)等错误跟踪器结合使用.
T.E*_*.D. 16
首先,软件不是ISO 9001的补充.只有组织通过ISO 9001认证.所以说的问题确实没有意义.您唯一可以问的是Git或Mercurial开发团队是否已通过ISO 9001认证.(CMMI也是如此).
软件开发服务的所有ISO 9001实际上意味着您已经为所做的一切(开发,错误修复等)制定了书面流程,并且您遵循它.那么,你已经付钱给某人做了ISO 9001审核,证明了上述情况.CMMI涉及的内容更多,但就本次讨论而言,我们可以认为它们类似.
您可能需要看起来很长很难找到一个自由软件社区项目,该项目难以完成创建所有流程文档所需的大量繁琐工作,并且需要汇总资金来支付审计费用.如果你找到一个,它可能只是由于某种大型企业赞助商想要它.
如果问题是这些标准规定的源控制的使用,在ISO 9001的情况下,什么都不是.老笑话是,如果你拿出你的产品并将其从一个10层的窗口拖到下面的装载台,只要这是你记录的过程并且你遵循它就可以通过ISO.
我在21 CFR 820(受监管的医疗设备)/ ISO 13485环境中工作,但"大图"与ISO 9001非常相似.我同意以上关于ISO 9001关于过程的所有事情,而不是工具.
但是,您可能正在一个需要实现工程设计控制过程的区域工作,而设计控件将涉及开发人员使用的过程,工具和工作指令.特别是,在医疗设备领域,我们不得不担心任何影响产品安全性或有效性的软件工具.这包括配置管理和版本控制的工具(如果你无法控制你正在构建的软件版本,你不能令人信服地说你知道哪个版本在现场,所以你无法分辨哪些客户联系进行召回).
对于此类工具,我们必须具有"计算机系统验证"(CSV)文档.用于第三方工具的CSV包括(1)工具规范,其描述产品开发周期内的用例及其如何影响质量;(2)测试用例,其可提供该工具在预期用例中有效的客观证据.
对于版本控制系统,这基本上意味着描述您使用的功能(签入,签出,分支,标签)的白皮书以及证明它们有效的那些功能的一些测试.对于奖励积分,如果软件有自己的测试套件,您可以包含它运行的证据并通过自己的测试.
| 归档时间： |
|
| 查看次数： |
2929 次 |
| 最近记录： |