¿El mejor enfoque para realizar una auditoría de configuración física de CMMI?

Question

La organización en la que trabajo actualmente para una organización que se está moviendo en todo el mundo CMMI de documentar todo. Me asignaron (junto con otro individuo) el título de Configuration Manager. Felicitaciones a la derecha.

Parte de los deberes es realizar de forma regular (aún se están definiendo de forma regular, ya sea trimestral o mensualmente) una auditoría de configuración física. Esto es básicamente una verificación de las versiones de código fuente implementadas en producción a lo que creemos que son las versiones de código fuente en producción.

Nuestro proyecto es una aplicación web relativamente pequeña escrita en Java. Los tipos de archivos con los que trabajamos son java, jsp, xml, archivos de propiedades y paquetes SQL.

El problema que tengo (y he expresado pero parece que se está ignorando) es cómo se supone que debo iniciar sesión física en el servidor de producción y verificar las versiones de los archivos, e incluso si pudiera, tomaría una cantidad de tiempo ridícula.

Las versiones del archivo ni siquiera están actualmente en el archivo (es decir, en un comentario o algo así). Se sugirió que coloquemos números de versión visibles en cada pantalla que también sean visibles para los usuarios. También pensé que esto era ridículo, ya que las pantallas en sí mismas representan solo una pequeña fracción del código que mantenemos.

Las herramientas que utilizamos actualmente son Netbeans para nuestro IDE y Serena Dimensions como nuestra herramienta de control de versiones.

Estoy buscando específicamente ideas sobre cómo realizar esta auditoría de una manera más automatizada, que será precisa y que no consumirá tiempo.

Mi idea es agregar un comentario en la parte superior de cada archivo que contenga el número de versión de ese archivo, una secuencia de comandos que se ejecuta cuando se crea una compilación de producción para crear un archivo XML o algo similar que contenga el nombre y la versión del archivo. Archivo de cada archivo en la compilación. Luego, cuando necesito hacer una auditoría, voy al servidor de producción. Agarro el archivo xml con la información, lo comparo programáticamente con lo que creemos que está en producción y produzco un informe.

Cualquier idea mejor. Sé que esto ya se ha hecho y me parece una locura que no haya encontrado ningún otro recurso.

Answer 1

Podría calcular un hash SHA1 de los archivos de origen en el servidor de producción y comparar ese valor de hash con las versiones almacenadas en el control de origen. Si puede encontrar el mismo hash en el control de código fuente, entonces sabrá qué versión está en producción. Si no puede encontrar el mismo hash en el control de fuente, entonces hay modificaciones sin seguimiento en la producción y su nuevo título de trabajo está justificado. :)

Answer 2

La trampa típica en la que caen las organizaciones con el CMMI es tratar de exagerar todo. Si pudiera sugerir algo, sería un comienzo pequeño & amp; Solo haz lo que necesites. Por lo tanto, tenga en cuenta cualquier problema que pueda haber tenido en el área de CM con piedad.

El CMMI describe QUÉ debe hacer una organización, pero deja el CÓMO a usted. La especificación de CMMI , el capítulo 2 vale la pena Leer: describe los componentes requeridos, esperados e informativos de la especificación. Básicamente, se requieren los objetivos, se esperan las prácticas y todo lo demás es informativo. Esto significa que solo hay una pequeña parte de la especificación que un tasador de CMMI puede exigir directamente: los objetivos. En el nivel de práctica, está permitido tener las prácticas descritas, o alternativas aceptables para ellas.

En el caso de las auditorías de configuración, el objetivo SG3 es "Integridad de las líneas de base establecida y mantenida". El SP3.2 dice "Realice auditorías de configuración para mantener la integridad de las líneas de base de configuración". No hay nada establecido aquí sobre la frecuencia con la que se hacen, o el tiempo que pueden tomar.

En mi organización anterior, FCA / PCA generalmente solo se realizaba como parte del proceso de lanzamiento del producto, y utilizábamos ClearCase como herramienta de control de versiones, con etiquetas aplicadas en la base de código para definir líneas de base. No teníamos números de versión en todos los archivos de origen, ni tampoco números de versión en todas las pantallas de productos: la actividad de CM estaba haciendo lo correcto & amp; fue respaldado por auditorías, y esto nunca fue un problema en ninguna evaluación de CMMI. Podríamos usar los deltas entre etiquetas para ver qué archivos han cambiado, realizar diferencias para ver los cambios reales del código. Una parte importante del proceso es poder vincular esos cambios a un requisito / informe de error / cualquiera que sea la razón por la que se inició el cambio.

Nuestra auditoría usó scripts para automatizar el proceso, pero estos fueron desarrollados internamente y son específicos de ClearCase. Perteneció.

Answer 3

¿no puedes usar tu control de código fuente para esto? Si implementa una versión y etiqueta su control sourcec con ese despliegue, puede verificar el sistema de control de origen