Quelles sont les implications de l'ISO 9001 / CMMI pour le contrôle de la source en général, et GIT / Mercurial / DVC en particulier?

Question

On m'a posé cette question sur le contrôle des sources distribué en général par quelqu'un qui connaît le serveur de fondation d'équipe.

Est-il possible d'utiliser un DVC tel que GIT ou Mercurial pour le contrôle de la source et de se conformer à des normes telles que ISO 9001 ou CMMI?

Quelles exigences ISO 9001 et CMMI placent-elles sur les outils de contrôle de source devraient et ne devraient pas être capables?

Y a-t-il des choses que Git / Mercurial fait que l'ISO 9001 / CMMI considérerait comme nocif ou qui nécessiterait des considérations spécifiques?

J'ai trouvé des informations à http://www.ssqc.com/do25v6new.pdf Mais à un coup d'œil rapide, il ne semble pas dire autre que la nécessité de garder des enregistrements de ce qui a changé, quelles versions de votre logiciel que vous avez déployé, et quels problèmes ils résolvent, et il n'y a aucune raison pour que les DVC ne devraient pas être Capable de gérer cela en combinaison avec un tracker de bogue tel que Fogbugz et un serveur CI tel que TeamCity.

Answer 1

Tout d'abord, le logiciel n'est pas un compilant ISO 9001. Seules les organisations sont compilantes ISO 9001. Donc, la question comme indiqué n'a vraiment aucun sens. La seule chose que vous pourriez demander, c'est si les équipes de développement GIT ou Mercurial sont compilantes ISO 9001. (Il en va de même pour CMMI).

Tout ce que l'ISO 9001 pour une tenue de développement de logiciels signifie vraiment que vous avez un processus écrit en place pour tout ce que vous faites (développement, correctifs de bogues, etc.) et que vous le suivez. Eh bien, et vous avez payé quelqu'un pour venir faire un audit ISO 9001 certifiant ce qui précède. CMMI est beaucoup plus impliqué, mais aux fins de cette discussion, nous pouvons les considérer comme similaires.

Il faudrait probablement être assez long et difficile pour trouver un projet de communauté de logiciels gratuits qui a pris la peine de passer par le travail de grognement massif requis pour créer toute la documentation du processus et qui a gratté l'argent pour payer un audit. Si vous en trouvez un, cela ne serait probablement dû qu'à une sorte de grand sponsor d'entreprise en le souhaitant.

Si la question est de savoir ce que ces normes spécifient sur l'utilisation du contrôle des sources, dans le cas de l'ISO 9001, ce serait rien. La vieille blague est que si vous prenez votre produit et le déposez une fenêtre de 10 étages sur le quai de chargement ci-dessous, c'est très bien par ISO tant que c'est votre processus documenté et que vous le suivez.

Answer 2

Je travaille dans un environnement 21 CFR 820 (dispositif médical réglementé) / ISO 13485, mais la «vue d'ensemble» est à peu près la même que l'ISO 9001. Je suis d'accord avec tout ce qui précède à propos de l'ISO 9001 concernant le processus, pas les outils.

Cependant, vous pouvez travailler dans un domaine où vous devez mettre en œuvre des procédures pour les contrôles de conception d'ingénierie, et les contrôles de conception abordent les processus, les outils et les instructions de travail utilisées par les développeurs. En particulier, dans l'arène des dispositifs médicaux, nous devons nous soucier de tous les outils logiciels qui ont une incidence sur la sécurité ou l'efficacité du produit. Cela inclut des outils pour la gestion de la configuration et le contrôle des versions (si vous ne pouvez pas contrôler la version du logiciel que vous construisez, vous ne pouvez pas dire de manière convaincante que vous savez quelles version (s) sont dans le domaine, vous ne pouvez donc pas dire quels clients contacter pour un rappel).

Pour de tels outils, nous devons avoir une documentation de "validation des systèmes informatiques" (CSV). CSV pour un outil tiers comprend (1) une spécification d'outil qui décrit les cas d'utilisation dans le cycle de développement des produits et comment ils affectent la qualité et (2) les cas de test qui peuvent fournir des preuves objectives que l'outil est efficace dans les cas d'utilisation prévus .

Pour un système de contrôle de version, cela signifierait essentiellement un livre blanc décrivant les fonctionnalités que vous utilisez (vérifier, vérifier, branches, balises) et quelques tests de ces fonctionnalités démontrant qu'ils fonctionnent. Pour les points bonus, si le logiciel a sa propre suite de tests, vous pouvez inclure des preuves qu'il exécute et passe ses propres tests.

Answer 3

Du Page d'accueil de CMMI:

CMMI est une approche d'amélioration des processus qui fournit aux organisations les éléments essentiels de processus efficaces qui améliorent finalement leurs performances.

CMMI gère le processus, pas les outils. Ma compréhension est que vous pouvez la version contrôlée avec des tablettes en argile et être conforme au CMMI si vous aviez un processus pour le faire (niveau 2) et que vous avez suivi le processus (niveau 3,4,5).

Answer 4

J'ai pu participer à un audit Scampi C ainsi que pour développer un processus pour deux groupes de processus CMMI chez un employeur précédent et nous avons eu quelques discussions approfondies sur le contrôle des versions avec notre consultant CMMI. Nous n'utilisions pas de DVC pendant ce processus, mais pour bon nombre des raisons mentionnées ci-dessus, je ne vois pas pourquoi ce serait un problème.

En termes de ce que cmmi en fait Audits pour, les autres affiches sont correctes en indiquant que tant que le processus est documenté et que les développeurs comprennent et peuvent citer le processus de manière appropriée, vous devriez être OK.

En ce qui concerne la garantie que votre équipe est prête à passer un audit CMMI, la seule chose qui serait une légère préoccupation serait d'essayer de transformer une équipe de taille moyenne / grande à partir de VCS open source (SVN, CVS) ou de VC commerciaux (MKS, Accurev, etc ...) à un DVC sans le temps de rotation approprié. Parce que la transition peut être choquante, vous voulez vous assurer que votre équipe a une prise ferme sur les DVC avant de vous engager dans l'audit.

Answer 5

Comme d'autres personnes l'ont noté ISO 9001 ne concerne pas l'outil. Travailler dans une institution qui est des signaux conformes ISO 9001, ils (l'institution elle-même) sont "matures". Le mot mûrit, dans ce contexte, indiquant que l'organisation adhère strictement aux processus qui ont été vérifiés et se sont révélés conformes à l'ISO 9001. Les processus qui impliquent Git ou Mercurial n'affecteront en aucune façon votre capacité à devenir conforme à l'ISO 9001 (sauf si vous ne suivez pas les processus).

Du moins, c'est ma compréhension de tout cela.