Meilleure approche pour réaliser un audit de configuration physique CMMI?

Question

L’organisation pour laquelle je travaille actuellement est une organisation qui se lance dans le monde du CMMI en matière de documentation. On m'a attribué (avec une autre personne) le titre de Gestionnaire de configuration. Félicitations à moi raison.

Une partie des tâches consiste à effectuer régulièrement (il est toujours en train de définir une base régulière, soit trimestriellement, soit mensuellement) un audit de configuration physique. Il s’agit essentiellement d’une vérification des versions de code source déployées en production par rapport à ce que nous croyons être les versions de code source en production.

Notre projet est une application Web relativement petite avec une écriture en Java. Les types de fichiers avec lesquels nous travaillons sont java, jsp, xml, fichiers de propriétés et packages SQL.

Le problème que j’ai (et que j’ai exprimé mais qui semble être ignoré) est de savoir comment je suis censé ouvrir une session physique sur le serveur de production et vérifier les versions des fichiers. Même si je pouvais le faire, cela prendrait une quantité de temps ridicule.

Les versions de fichier ne sont même pas actuellement dans le fichier (c'est-à-dire dans un commentaire ou quelque chose du genre). Il a été suggéré de placer des numéros de version visibles sur chaque écran, qui sont également visibles par les utilisateurs. Je trouvais cela aussi ridicule, car les écrans eux-mêmes ne représentent qu’une petite fraction du code que nous conservons.

Les outils que nous utilisons actuellement sont Netbeans pour notre IDE et Serena Dimensions en tant qu’outil de gestion de versions.

Je recherche spécifiquement des idées sur la manière d'effectuer cet audit de manière, espérons-le, plus automatisée, qui sera à la fois précise et peu fastidieuse.

Mon idée est actuellement d'ajouter un commentaire en haut de chaque fichier contenant le numéro de version de ce fichier, un script qui s'exécute lorsqu'une version de production est créée pour créer un fichier XML ou quelque chose de similaire contenant le nom et la version du fichier. fichier de chaque fichier dans la construction. Ensuite, lorsque je dois effectuer un audit, je vais sur le serveur de production, saisis le fichier xml avec les informations et le compare par programme à ce que nous pensons être en production, et génère un rapport.

Toutes les meilleures idées. Je sais que cela doit déjà avoir été fait et me semble fou de ne pas avoir trouvé d'autres ressources.

Answer 1

Vous pouvez calculer un hachage SHA1 des fichiers source sur le serveur de production et comparer cette valeur de hachage aux versions stockées dans le contrôle de source. Si vous pouvez trouver le même hachage dans le contrôle de source, vous saurez quelle version est en production. Si vous ne pouvez pas trouver le même hachage dans le contrôle de source, des modifications non suivies ont été apportées à la production et votre nouveau titre d'emploi est justifié. :)

Answer 2

Le piège typique des organisations avec lequel le CMMI tente de tout exagérer. Si je pouvais suggérer quelque chose, ce serait commencer petit & amp; faites seulement ce dont vous avez besoin. Alors, réfléchissez bien à tous les problèmes que vous avez pu avoir dans la zone CM.

Le CMMI décrit CE QUE l’organisation doit faire, mais vous laisse le COMMENT. La spécification CMMI , le chapitre 2 en vaut bien la peine. read - il décrit les composants requis, attendus et informatifs de la spécification - en gros, les objectifs sont requis, les pratiques sont attendues et tout le reste est informatif. Cela signifie qu'il n'y a qu'une petite partie de la spécification qu'un évaluateur CMMI peut directement exiger - les objectifs. Au niveau de la pratique, il est permis d’avoir soit les pratiques telles que décrites, ou des alternatives acceptables .

Dans le cas des audits de configuration, l’objectif SG3 est "L’intégrité des lignes de base est établie et maintenue". Le SP3.2 indique: "Effectuez des audits de configuration pour maintenir l'intégrité des lignes de base de la configuration". Rien n’indique ici combien de fois ils sont faits ou combien de temps ils peuvent prendre.

Dans mon organisation précédente, FCA / PCA était généralement utilisé uniquement dans le cadre du processus de publication du produit, et nous utilisions ClearCase comme outil de gestion des versions, avec des étiquettes appliquées à travers la base de code pour définir les lignes de base. Nous n'avions pas de numéros de version dans tous les fichiers source, pas plus que sur les écrans de tous les produits. L'activité de gestion de contenu faisait le bon choix. a été étayée par des audits et cela n’a jamais été un problème dans aucune évaluation du CMMI. Nous pourrions utiliser les deltas entre les étiquettes pour voir quels fichiers ont été modifiés, effectuer des diffs pour voir les changements de code réels. Une partie importante du processus consiste à pouvoir relier ces modifications à un rapport d’exigence / de bogue / quelle que soit la raison qui a provoqué la modification.

Notre audit a utilisé des scripts pour automatiser le processus, mais il s’agissait de scripts développés en interne qui sont spécifiques à ClearCase. En gros, ils répertorient tous les fichiers, leurs versions dans le système CM et l’élément baseline / config auquel ils se rapportent. appartenu.

Answer 3

ne pouvez-vous pas utiliser votre contrôle de source pour cela? si vous déployez une version et que vous étiquetez votre source avec ce déploiement, vous pouvez alors vérifier le système de contrôle de la source