¿Cuáles son las implicaciones de ISO 9001/CMMI para el control de la fuente en general, y Git/Mercurial/DVCS en particular?

Question

Me han hecho esta pregunta sobre el control de fuente distribuido en general por alguien que está familiarizado con Team Foundation Server.

¿Es posible usar un DVC como GIT o Mercurial para el control de origen y cumplir con estándares como ISO 9001 o CMMI?

¿Qué requisitos hacen ISO 9001 y CMMI en qué herramientas de control de origen deberían y no deberían ser capaces de ser capaces?

¿Hay alguna cosa que GIT/Mercurial haga que ISO 9001/CMMI considere dañino o que requeriría consideraciones específicas?

He encontrado información en http://www.ssqc.com/do25v6new.pdf Pero a un vistazo rápido, no parece decir mucho más que la necesidad de mantener registros de lo que ha cambiado, qué versiones de su software que ha implementado y qué problemas solucionan, y no hay ninguna razón por la cual los DVC no deberían ser Capaz de manejar eso en combinación con un rastreador de errores como Fogbugz y un servidor CI como TeamCity.

Answer 1

En primer lugar, el software no es compilante ISO 9001. Solo las organizaciones son compilantes ISO 9001. Entonces, la pregunta como se dijo realmente no tiene sentido. Lo único que podría preguntar es si los equipos de desarrollo GIT o Mercurial son compilantes ISO 9001. (Lo mismo ocurre con CMMI).

Todo el ISO 9001 para un atuendo de desarrollo de software realmente significa que tiene un proceso escrito para todo lo que hace (desarrollo, correcciones de errores, etc.) y que lo sigue. Bueno, eso y le has pagado a alguien que venga a hacer una auditoría ISO 9001 certificando lo anterior. CMMI está mucho más involucrado, pero a los efectos de esta discusión, podemos considerarlos similares.

Probablemente tenga que parecer bastante largo y difícil para encontrar un proyecto de comunidad de software gratuito que se molestara en pasar por el trabajo gruñido masivo requerido para crear toda la documentación del proceso y que preparara el dinero para pagar una auditoría. Si encuentra uno, probablemente solo se deba a algún tipo de gran patrocinador corporativo que lo desee.

Si la pregunta es qué especifican esos estándares sobre el uso del control de la fuente, en el caso de ISO 9001 que sería nada. La vieja broma es que si toma su producto y lo suelta una ventana de 10 pisos al muelle de carga a continuación, está bien para ISO siempre que ese sea su proceso documentado y lo siga.

Answer 2

Trabajo en un entorno de 21 CFR 820 (dispositivo médico regulado)/ISO 13485, pero el "panorama general" es muy similar a ISO 9001. Estoy de acuerdo con todas las cosas anteriores sobre ISO 9001 que se trata de procesos, no herramientas.

Sin embargo, puede estar trabajando en un área donde necesita implementar procedimientos para controles de diseño de ingeniería, y los controles de diseño tocarán los procesos, herramientas e instrucciones de trabajo utilizadas por los desarrolladores. En particular, en el ámbito de los dispositivos médicos tenemos que preocuparnos por cualquier herramienta de software que tenga relación con la seguridad o efectividad del producto. Esto incluye herramientas para la gestión de configuración y control de versiones (si no puede controlar qué versión del software está creando, no puede decir de manera convincente que sepa qué versión (s) están en el campo, por lo que no puede decirlo. con qué clientes contactar para un retiro).

Para tales herramientas, debemos tener documentación de "Validación de sistemas informáticos" (CSV). CSV para una herramienta de terceros incluye (1) una especificación de herramienta que describe los casos de uso dentro del ciclo de desarrollo del producto y cómo afectan la calidad y (2) los casos de prueba que pueden proporcionar evidencia objetiva de que la herramienta es efectiva en los casos de uso previstos .

Para un sistema de control de versiones, esto significaría básicamente un papel blanco que describe las características que utiliza (checkin, checkout, ramas, etiquetas) y algunas pruebas de esas características que demuestran que funcionan. Para puntos de bonificación, si el software tiene su propio conjunto de pruebas, puede incluir evidencia de que ejecuta y pasa sus propias pruebas.

Answer 3

Desde el Página de inicio de CMMI:

CMMI es un enfoque de mejora de procesos que proporciona a las organizaciones los elementos esenciales de los procesos efectivos que finalmente mejoran su rendimiento.

CMMI trata con el proceso, no las herramientas. Entiendo que podría controlar las versiones con tabletas de arcilla y cumplir con CMMI si tuviera un proceso para hacerlo (nivel 2) y siguió el proceso (nivel 3,4,5).

Answer 4

Pude participar en una auditoría Scampi C y desarrollar un proceso para dos grupos de procesos CMMI en un empleador anterior y tuvimos algunas discusiones en profundidad sobre el control de versiones con nuestro consultor CMMI. No estábamos usando un DVCS durante este proceso, pero por muchas de las razones mencionadas anteriormente no puedo ver por qué sería un problema.

En términos de lo que CMMI realmente auditorías para, los otros carteles son correctos al afirmar que mientras el proceso esté documentado y los desarrolladores comprendan y puedan citar el proceso de manera apropiada, debe estar bien.

En términos de garantizar que su equipo esté listo para pasar una auditoría CMMI, lo único que sería una leve preocupación sería tratar de hacer una transición de un equipo de tamaño medio/gran de VCS de código abierto (SVN, CVS) o VCS comerciales (MKS, AccureV, etc ...) a un DVC sin el tiempo de spin-up apropiado. Debido a que la transición puede ser discordante, debe asegurarse de que su equipo tenga un control firme en cualquier DVC antes de participar en la auditoría.

Answer 5

Como otras personas han notado que ISO 9001 no se trata de la herramienta. Trabajar en una institución que es ISO 9001 señala que (la institución misma) son "maduras". La palabra madura, en este contexto, que indica que la organización se adhiere estrictamente a los procesos que han sido auditados y que cumplen con ISO 9001. Los procesos que involucran GIT o Mercurial no afectarán su capacidad para convertirse en ISO 9001 de ninguna manera (a menos que no siga los procesos).

Al menos, eso es mi comprensión de todo.