Blockers et Critical<\/strong><\/h3>\nA ver las violaciones ahora. Recuerdate que hemos orientado nuestro modelo Calidad<\/a> hacia la identificaci\u00f3n de defectos de robustez y de rendimiento, los que afectan lo m\u00e1s a los usuarios.<\/p>\n![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV1.jpg\" "\\"QualCobolAssesV1\\"")
<\/a><\/p>\nEl n\u00famero de defectos bloqueantes es poco elevado. Encontramos el ‘SORT’ de lo que hablamos anteriormente, y 5 ‘OPEN’ de ficheros en un bucle. Este tratamiento costoso para el sistema operativo por supuesto debe realizarse antes del bucle. Estas violaciones presentan un riesgo elevado para el rendimiento pero son f\u00e1ciles de corregir.<\/p>\n
Los defectos cr\u00edticos se refieren a la robustez:<\/p>\n
\n- \n\nUn c\u00f3digo de ‘status’ declarado para la gesti\u00f3n correcta de un archivo no ha sido probado durante una operaci\u00f3n en este fichero (OPEN, READ, WRITE, \u2026). Un intento de escribir en un archivo no abierto, de leer en un archivo abierto en escritura (Output file), un tama\u00f1o de registro (RECORD) incorrecto son errores que pasar\u00e1n inadvertidos.<\/div>\n<\/div>\n<\/li>\n
- Un GOTO que encamina el tratamiento fuera del m\u00f3dulo corriente rompe la l\u00f3gica de ejecuci\u00f3n de \u00e9ste.<\/li>\n
- El EVALUATE sin WHEN OTHER es cl\u00e1sico: si ninguna de las condiciones del EVALUATE es verificada, la l\u00f3gica del programa se vuelve imprevisible.<\/li>\n
- La \u00faltima regla sobre el tama\u00f1o del fichero s\u00f3lo se aplica a Cobol Microfocus, no z\/OS (mainframe IBM).<\/li>\n<\/ul>\n
Es muy probable que exista un est\u00e1ndar de calidad para la gesti\u00f3n del c\u00f3digo ‘status’ de ficheros, pero que esta ‘best practice’ se olvida a veces. No se puede evitar la falta de atenci\u00f3n. Sin prueba de este c\u00f3digo, un tratamiento incorrecto puede llevar a cabo una inconsistencia de los datos sin que se detecta.. La b\u00fasqueda de la causa del error tambi\u00e9n ser\u00e1 m\u00e1s dif\u00edcil. Al igual que el EVALUATE sin WHEN OTHER.<\/p>\n
Cualquier violaci\u00f3n de estas reglas para la gesti\u00f3n de errores impacta no s\u00f3lo a los usuarios, sino tambi\u00e9n a los costes de mantenimiento. En nuestro caso, sus n\u00fameros son suficientemente altos para pensar que se necesita recordar estas buenas pr\u00e1cticas a los desarrolladores.<\/p>\n
Costes de remediaci\u00f3n<\/strong><\/h3>\n\u00bfTe recuerdas el widget que hemos utilizado en el post anterior<\/a>, con los defectos m\u00e1s frecuentes?<\/p>\n![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV2.jpg\" "\\"QualCobolAssesV2\\"")
<\/a><\/p>\nEncontramos de nuevo el IF sin END-IF de que ya hemos hablados, los peligrosos GOTOs, m\u00e1s de 4 500 p\u00e1rrafos sin documentaci\u00f3n y c\u00f3digo duplicado. Estas violaciones impactan la mantenibilidad de la aplicaci\u00f3n, como se puede ver en este diagrama:<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV21.jpg\" "\\"QualCobolAssesV21\\"")
<\/a><\/p>\nNo vamos a comentar en detalles estos defectos ya que nuestro objetivo es identificar a los que impactan a los usuarios. Pues las 45 violaci\u00f3nes de tipo \u2018Blockers\u2019 y los 292 \u2018Critical\u2019 representan, respectivamente, 5.6 d\u00edas y 50.5 d\u00edas de correcci\u00f3n.<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV22.jpg\" "\\"QualCobolAssesV22\\"")
<\/a><\/p>\nAproximadamente dos semanas de trabajo para un equipo de 5 o 6 personas versus m\u00e1s de 10 a\u00f1os\/hombre para corregir todas las violaci\u00f3nes que afectan los costes de mantenimiento.<\/p>\n
Plan de acci\u00f3n
\n<\/strong><\/h3>\nPor supuesto, vamos a presentar los resultados al equipo del proyecto y comentar con ellos para comprobar nuestras hip\u00f3tesis. Sin embargo, nuestro objetivo no es realizar una auditor\u00eda exhaustiva, sino mostrar c\u00f3mo es posible llegar a algunas conclusiones basadas en estos datos, y formular un plan de acci\u00f3n preliminar.<\/p>\n
Acciones a corto plazo:<\/p>\n
\n- Corregir los defectos \u2018Blockers\u2019 que afectan al rendimiento: 5 d\u00edas.<\/li>\n
- Corregir los defectos cr\u00edticos, una fuente potencial de errores: 55 d\u00edas.<\/li>\n
- Recordar a los equipos Cobol: nada de GOTO \u2013 especialmente cuando crean una excepci\u00f3n a la l\u00f3gica del m\u00f3dulo \u2013 y recordar tambi\u00e9n las mejores pr\u00e1cticas de gesti\u00f3n de errores, como la obligaci\u00f3n de comprobar el estado de un archivo despu\u00e9s de cualquier operaci\u00f3n sobre \u00e9l y el EVALUATE sin WHEN OTHER.<\/li>\n
- Realizar an\u00e1lisis peri\u00f3dicos de esta applicaci\u00f3n y verificar que no vuelven a aparecer defectos bloqueantes o cr\u00edticos.<\/li>\n<\/ul>\n
Estas acciones no cuestan mucho y se pueden realizar a corto plazo, para un beneficio optimal. Ellas conducen a la creaci\u00f3n de un proceso de mejora continua. Los usuarios te lo agradecer\u00e1n.<\/p>\n
Esta aplicaci\u00f3n cuenta con altos costes de mantenimiento. Consulte con el management si es el caso y cual es su opini\u00f3n al respecto. Es muy posible que esta aplicaci\u00f3n tenga pocas evoluciones o ninguna, y en tal caso, el mantenimiento no es un problema.<\/p>\n
Verifica tambi\u00e9n las hip\u00f3tesis que hemos formulado en el post anterior<\/a> (applicaci\u00f3n batch orientada a la gesti\u00f3n de ficheros de datos, poca critica) y explica bien que ella no puede ser subcontratada con seguridad.<\/p>\nPropone el plan de acci\u00f3n siguiente:<\/p>\n
\n- Identificar y eliminar los 184 archivos duplicados, que pesan sobre el mantenimiento.<\/li>\n
- Realizar un nuevo an\u00e1lisis para calcular la deuda t\u00e9cnica y el coste estimado de refactorizaci\u00f3n.<\/li>\n<\/ul>\n
Estrategia aplicativa
\n<\/strong><\/p>\n<\/strong>El refactoring de una aplicaci\u00f3n en Cobol es una operaci\u00f3n que rara vez se considera, porque los costes son demasiado altos. En general, la aplicaci\u00f3n puede morir de muerte natural, y se busca otra soluci\u00f3n (por ejemplo, ERP).<\/p>\n![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesV3.jpg\" "\\"QualCobolAssesV3\\"")
<\/a>Deseamos formular recomendaciones realistas. Pues esto es lo que hago: buscar los programas que tienen el mayor n\u00famero de l\u00edneas y de defectos.<\/p>\nAqu\u00ed tenemos tres programas que representan m\u00e1s de 27 000 l\u00edneas, el 15% del tama\u00f1o total de la aplicaci\u00f3n (LOC).<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesRF1.jpg\" "\\"QualCobolAssesRF1\\"")
<\/a><\/p>\n <\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesRF2.jpg\" "\\"QualCobolAssesRF2\\"")
<\/a>Tambi\u00e9n est\u00e1n entre los cinco primeros m\u00e1s complejos, con un total de 5 900 puntos de Complejidad Ciclom\u00e1tica, o el 26% de la complejidad total de la aplicaci\u00f3n.<\/p>\n
El n\u00famero de defectos bloqueantes es poco elevado. Encontramos el ‘SORT’ de lo que hablamos anteriormente, y 5 ‘OPEN’ de ficheros en un bucle. Este tratamiento costoso para el sistema operativo por supuesto debe realizarse antes del bucle. Estas violaciones presentan un riesgo elevado para el rendimiento pero son f\u00e1ciles de corregir.<\/p>\n Los defectos cr\u00edticos se refieren a la robustez:<\/p>\n Es muy probable que exista un est\u00e1ndar de calidad para la gesti\u00f3n del c\u00f3digo ‘status’ de ficheros, pero que esta ‘best practice’ se olvida a veces. No se puede evitar la falta de atenci\u00f3n. Sin prueba de este c\u00f3digo, un tratamiento incorrecto puede llevar a cabo una inconsistencia de los datos sin que se detecta.. La b\u00fasqueda de la causa del error tambi\u00e9n ser\u00e1 m\u00e1s dif\u00edcil. Al igual que el EVALUATE sin WHEN OTHER.<\/p>\n Cualquier violaci\u00f3n de estas reglas para la gesti\u00f3n de errores impacta no s\u00f3lo a los usuarios, sino tambi\u00e9n a los costes de mantenimiento. En nuestro caso, sus n\u00fameros son suficientemente altos para pensar que se necesita recordar estas buenas pr\u00e1cticas a los desarrolladores.<\/p>\n \u00bfTe recuerdas el widget que hemos utilizado en el post anterior<\/a>, con los defectos m\u00e1s frecuentes?<\/p>\n Encontramos de nuevo el IF sin END-IF de que ya hemos hablados, los peligrosos GOTOs, m\u00e1s de 4 500 p\u00e1rrafos sin documentaci\u00f3n y c\u00f3digo duplicado. Estas violaciones impactan la mantenibilidad de la aplicaci\u00f3n, como se puede ver en este diagrama:<\/p>\n No vamos a comentar en detalles estos defectos ya que nuestro objetivo es identificar a los que impactan a los usuarios. Pues las 45 violaci\u00f3nes de tipo \u2018Blockers\u2019 y los 292 \u2018Critical\u2019 representan, respectivamente, 5.6 d\u00edas y 50.5 d\u00edas de correcci\u00f3n.<\/p>\n Aproximadamente dos semanas de trabajo para un equipo de 5 o 6 personas versus m\u00e1s de 10 a\u00f1os\/hombre para corregir todas las violaci\u00f3nes que afectan los costes de mantenimiento.<\/p>\n Por supuesto, vamos a presentar los resultados al equipo del proyecto y comentar con ellos para comprobar nuestras hip\u00f3tesis. Sin embargo, nuestro objetivo no es realizar una auditor\u00eda exhaustiva, sino mostrar c\u00f3mo es posible llegar a algunas conclusiones basadas en estos datos, y formular un plan de acci\u00f3n preliminar.<\/p>\n Acciones a corto plazo:<\/p>\n Estas acciones no cuestan mucho y se pueden realizar a corto plazo, para un beneficio optimal. Ellas conducen a la creaci\u00f3n de un proceso de mejora continua. Los usuarios te lo agradecer\u00e1n.<\/p>\n Esta aplicaci\u00f3n cuenta con altos costes de mantenimiento. Consulte con el management si es el caso y cual es su opini\u00f3n al respecto. Es muy posible que esta aplicaci\u00f3n tenga pocas evoluciones o ninguna, y en tal caso, el mantenimiento no es un problema.<\/p>\n Verifica tambi\u00e9n las hip\u00f3tesis que hemos formulado en el post anterior<\/a> (applicaci\u00f3n batch orientada a la gesti\u00f3n de ficheros de datos, poca critica) y explica bien que ella no puede ser subcontratada con seguridad.<\/p>\n Propone el plan de acci\u00f3n siguiente:<\/p>\n Estrategia aplicativa <\/strong>El refactoring de una aplicaci\u00f3n en Cobol es una operaci\u00f3n que rara vez se considera, porque los costes son demasiado altos. En general, la aplicaci\u00f3n puede morir de muerte natural, y se busca otra soluci\u00f3n (por ejemplo, ERP).<\/p>\n Aqu\u00ed tenemos tres programas que representan m\u00e1s de 27 000 l\u00edneas, el 15% del tama\u00f1o total de la aplicaci\u00f3n (LOC).<\/p>\n <\/p>\n<\/a><\/p>\n\n
Costes de remediaci\u00f3n<\/strong><\/h3>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a><\/p>\nPlan de acci\u00f3n
\n<\/strong><\/h3>\n\n
\n
\n<\/strong><\/p>\n<\/a>Deseamos formular recomendaciones realistas. Pues esto es lo que hago: buscar los programas que tienen el mayor n\u00famero de l\u00edneas y de defectos.<\/p>\n<\/a><\/p>\n<\/a>Tambi\u00e9n est\u00e1n entre los cinco primeros m\u00e1s complejos, con un total de 5 900 puntos de Complejidad Ciclom\u00e1tica, o el 26% de la complejidad total de la aplicaci\u00f3n.<\/p>\n
![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesRF3.jpg\" "\\"QualCobolAssesRF3\\"")
<\/a><\/p>\n![\"\"](\"http:\/\/qualilogy.com\/wp-content\/uploads\/2012\/07\/QualCobolAssesRF4.jpg\" "\\"QualCobolAssesRF4\\"")
<\/a>