{"id":1336,"date":"2014-09-27T10:31:13","date_gmt":"2014-09-27T09:31:13","guid":{"rendered":"http:\/\/qualilogy.com\/es\/?p=1336"},"modified":"2014-09-29T07:33:18","modified_gmt":"2014-09-29T06:33:18","slug":"aplicacion-legacy-refactorizacion-reingenieria-7","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactorizacion-reingenieria-7\/","title":{"rendered":"Aplicaci\u00f3n Legacy \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (VII)"},"content":{"rendered":"<p><a href=\"http:\/\/500px.com\/Vicken\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-2067\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlan1.jpg\" alt=\"Qualilogy Legacy Application Refactoring Reengineering\" width=\"320\" height=\"320\" \/><\/a>Hemos visto en <a title=\"Aplicaci\u00f3n Legacy \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (VI)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactorizacion-reingenieria-6\/\" target=\"_blank\">el post anterior<\/a> c\u00f3mo usar el dashboard SonarQube para estimar el esfuerzo de pruebas de caracterizaci\u00f3n, pruebas recomendadas por Michael Feathers en su libro \u00abWorking Effectively with Legacy Code\u00bb.<\/p>\n<p>Hemos clasificado los componentes de nuestra aplicaci\u00f3n Legacy (Microsoft Word 1.1a) en diferentes grupos de funciones: las m\u00e1s simples con Complejidad Ciclom\u00e1tica (CC) de menos de 20 puntos, las complejas y muy complejas hasta 200 puntos de CC, y finalmente 6 componentes &#8216;monstruosos&#8217;.<\/p>\n<p>Hemos definido una f\u00f3rmula basada en la Complejidad Ciclom\u00e1tica y un factor de legibilidad (Reading Factor%) para evaluar el esfuerzo de pruebas en cada uno de estos grupos. <!--more--><\/p>\n<h2>Evaluaci\u00f3n de los resultados<\/h2>\n<p>El resultado total es de 234 d\u00edas, que se reparten de la siguiente manera:<\/p>\n<p style=\"text-align: center\"><strong><em>Tabla 1 &#8211; Distribuci\u00f3n del esfuerzo de pruebas por categor\u00eda de componentes <\/em><\/strong><br \/>\n<a href=\"http:\/\/qualilogy.com\/es\/wp-content\/uploads\/sites\/4\/2014\/09\/Qualilogy-Legacy-TestEffort-Synthesis2.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-1366\" src=\"http:\/\/qualilogy.com\/es\/wp-content\/uploads\/sites\/4\/2014\/09\/Qualilogy-Legacy-TestEffort-Synthesis2.jpg\" alt=\"Qualilogy-Legacy-TestEffort-Synthesis\" width=\"482\" height=\"179\" srcset=\"http:\/\/qualilogy.com\/es\/wp-content\/uploads\/sites\/4\/2014\/09\/Qualilogy-Legacy-TestEffort-Synthesis2.jpg 482w, http:\/\/qualilogy.com\/es\/wp-content\/uploads\/sites\/4\/2014\/09\/Qualilogy-Legacy-TestEffort-Synthesis2-300x111.jpg 300w\" sizes=\"(max-width: 482px) 100vw, 482px\" \/><\/a><\/p>\n<ul>\n<li>93.5 d\u00edas para cubrir el 60% de las funciones con una CC inferior a 20 puntos, un 40% del esfuerzo total y el 44% del total de la Complejidad Ciclom\u00e1tica de la aplicaci\u00f3n.<\/li>\n<li>92 d\u00edas (39% del tiempo total) para las 503 funciones entre 20 y 100 puntos de CC, lo que representa 44% del total de CC.<\/li>\n<li>25 d\u00edas (11% del tiempo total) para las 30 funciones entre 100 y 200 puntos de CC, lo que representa el 9% del total de CC.<\/li>\n<li>23.5 d\u00edas o 10% del esfuerzo total para las 6 funciones m\u00e1s complejas, lo que representa el 3% de la CC de toda la aplicaci\u00f3n.<\/li>\n<\/ul>\n<p>Este esfuerzo nos permite alcanzar la cobertura del 65% de las funciones, es decir, las dos terceras partes de nuestra aplicaci\u00f3n.<\/p>\n<p>Pas\u00e9 bastante tiempo en la f\u00f3rmula para evaluar el esfuerzo de pruebas, y conseguir una valoraci\u00f3n que me parezca l\u00f3gica, coherente y comprensible, basandonos en el n\u00famero de caminos l\u00f3gicos en una funci\u00f3n, representado por la Complejidad Ciclom\u00e1tica, y la mayor o menor facilidad de lectura. Por lo tanto, es as\u00ed que procede un desarrollador para estimar el n\u00famero de d\u00edas que se puede necesitar para desarrollar un c\u00f3digo de pruebas unitarias en una aplicaci\u00f3n desconocida.<\/p>\n<p>Tambi\u00e9n quer\u00eda que la regla sea precisa (pero simple), para que se puedan ajustar los parametros con el tama\u00f1o y la complejidad de los componentes. He jugado un poco con <a title=\"Aplicaci\u00f3n Legacy \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (VI)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactorizacion-reingenieria-6\/\" target=\"_blank\">los factores &#8216;Readibility Factor%&#8217; et &#8216;Characterization Test time&#8217;<\/a> con el fin de lograr un resultado para cada categor\u00eda de componentes que me parezca correcto: 54 minutos de programaci\u00f3n de pruebas para una funci\u00f3n entre 12 y 20 puntos de CC, 120 minutos para una funci\u00f3n de entre 40 y 50 puntos de CC y 200 a 300 l\u00edneas de c\u00f3digo, 240 minutos (medio d\u00eda) para una funci\u00f3n de entre 60 y 70 puntos DC y entre 500 y 700 l\u00edneas de c\u00f3digo, etc.<\/p>\n<p>Una vez realizadas las diferentes tablas de evaluaci\u00f3n del esfuerzo con esta f\u00f3rmula, mi primera reacci\u00f3n fue de encontrar los resultados finales bastante realistas. 234 d\u00edas para una cobertura de pruebas de 2\/3 de las 3 936 funciones distribuidas en 349 programas C: no parece inveros\u00edmil.<br \/>\nIncluso creo que no est\u00e1 subvaluado, teniendo en cuenta que los tiempos necesarios para completar las pruebas de los componentes m\u00e1s simples (&lt;20 CC) a moderadamente complejos (20 &lt;CC &lt;50) son, pienso yo, estimados generosamente. Para los componentes m\u00e1s pesados, es dif\u00edcil hacerme una idea clara de la precisi\u00f3n de esta evaluaci\u00f3n. Pero tres d\u00edas para una funci\u00f3n compleja con 200 puntos y 750 l\u00edneas de CC de c\u00f3digo no parecen inconsistentes.<\/p>\n<p>La distribuci\u00f3n del esfuerzo de la prueba tambi\u00e9n parece interesante:<\/p>\n<ul>\n<li>Dos cifras muy similares acerca de 90 d\u00edas para cada una de las dos primeras categor\u00edas, con cerca de 19 000 puntos de CC para cada categor\u00eda, en 3 400 componentes sencillos y tambi\u00e9n para 500 componentes complejos.<\/li>\n<li>Dos cifras de nuevo de 25 d\u00edas para 30 componentes muy complejos y 23 d\u00edas para 6 componentes &#8216;monstruosos&#8217;.<\/li>\n<\/ul>\n<p>Cuando digo que estos resultados parecen realistas, no quiero decir que sean completamente precisos y fiables, pero que pueden resistir a algunas objeciones.<\/p>\n<h2>Objeciones<\/h2>\n<p>Termin\u00e9 <a title=\"Aplicaci\u00f3n Legacy \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (VI)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactorizacion-reingenieria-6\/\" target=\"_blank\">el post anterior<\/a> preguntando si esta estimaci\u00f3n parec\u00eda correcta y la respuesta fue bastante positiva, que era &#8216;OK&#8217;, y la &#8216;escalabilidad&#8217;, es decir, el cambio de escala entre las diferentes categor\u00edas en funci\u00f3n de la creciente CC, parec\u00eda bastante correcta.<br \/>\nSin embargo, como consultor, tengo que prepararme para objeciones durante la presentaci\u00f3n de estos resultados a un cliente. \u00bfQu\u00e9 podr\u00edan preguntarme?<\/p>\n<p style=\"padding-left: 30px\"><em>Un gerente o responsable funcional de la aplicaci\u00f3n, respresentando a los usuarios (stakeholder) :\u00a0\u00a0\u00a0\u00a0 \u00ab Yo no entiendo: usted dice que tenemos 4 minutos por cada punto de la complejidad de los componentes m\u00e1s simples y 2 minutos por cada punto de la complejidad de los componentes m\u00e1s complejos. \u00bfNo deber\u00eda ser lo contrario? \u00bb<\/em>.<\/p>\n<p>Bueno, la escritura de un test requerir\u00e1 el desarrollo de una funci\u00f3n espec\u00edfica para esta prueba, con el fin de verificar uno o m\u00e1s dato(s) y valor(es) para cada camino l\u00f3gico, y entonces por cada punto de complejidad. Si s\u00f3lo tengo un \u00fanico punto de CC, voy a dedicar menos tiempo a escribir una l\u00ednea de prueba de estos datos y proporcionalmente m\u00e1s tiempo a desarrollar la funci\u00f3n para compilar, ejecutar, verificar el resultado de la prueba y a veces modificar la funci\u00f3n y probar de nuevo. Si tengo m\u00faltiples puntos de CC, voy a pasar un poco m\u00e1s tiempo para probar diferentes valores y proporcionalmente menos tiempo en la programaci\u00f3n y ejecuci\u00f3n de la funci\u00f3n.<\/p>\n<p>Por lo tanto, no vemos realmente diferencia cuando pasamos de una simple funci\u00f3n de entre 12 y 20 puntos de CC con 54 minutos de realizaci\u00f3n de pruebas, a una funci\u00f3n moderadamente compleja entre 20 y 30 puntos de CC y de 50 a 60 minutos de pruebas (seg\u00fan el tama\u00f1o de la funci\u00f3n, en l\u00edneas de c\u00f3digo).<\/p>\n<p style=\"padding-left: 30px\"><em>Un miembro del equipo del proyecto: \u00ab Tu formula me va bien, pero creo que el factor de legibilidad (RF%) no es bastante progresivo. Pasamos de repente de 4 a 10 para las funciones muy complejas \u00bb.<\/em><\/p>\n<p>De acuerdo.<\/p>\n<p>Para tener una segunda hip\u00f3tesis, es decir un rango alto para nuestra evaluaci\u00f3n, cambiamos este factor de la siguiente manera:<\/p>\n<ul>\n<li>Por menos de 100 l\u00edneas de c\u00f3digo (LOC), dejo el RF% = 1.<\/li>\n<li>Entre 100 y 200 LOC, aumento el RF% de 1.5 a 2.<\/li>\n<li>Entre 200 y 300 LOC, el RF% sube de 2 a 3.<\/li>\n<li>Entre 300 y 500 LOC, el RF% sube de 2.5 a 4.<\/li>\n<li>Entre 500 y 700 LOC, el RF%\u00a0 sube de 4 a 6.<\/li>\n<li>M\u00e1s all\u00e1 de 700 LOC, quedamos con los valores actuales.<\/li>\n<\/ul>\n<p>La nueva tabla con los resultados por estos valores :<\/p>\n<p style=\"text-align: center\"><em><strong>Tabla 2 &#8211; C\u00e1lculo del esfuerzo de pruebas de las funciones muy complejas (hip\u00f3tesis alta) <\/strong><\/em><\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-CCSup20_NweRF.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2080\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy-Legacy-TestEffort-CCSup20_NweRF.jpg\" alt=\"Qualilogy-Legacy-TestEffort-CCSup20_NewRF\" width=\"671\" height=\"555\" \/><\/a>Pasamos de 117.2 d\u00edas a 131.8 d\u00edas, un aumento de 14.6 d\u00edas, pues un esfuerzo adicional de alrededor del 12% de la carga inicial. As\u00ed que el impacto de este cambio es relativamente moderado. Por otra parte, podemos ver que es m\u00e1s importante en los componentes de mayor tama\u00f1o (tiene sentido), que no son los m\u00e1s numerosos. Por ejemplo, subimos de 4 a 5 horas de esfuerzo para un componente de 60 a 70 puntos de CC, con m\u00e1s de 500 LOC, pero como tenemos un \u00fanico en toda la aplicaci\u00f3n &#8230;<\/p>\n<p style=\"padding-left: 30px\"><em>El CIO : \u00ab \u00bfC\u00f3mo de fiable son estos resultados? \u00bfHasta qu\u00e9 punto puedo confiar en estos n\u00fameros para decidir si externalizar esta aplicaci\u00f3n? \u00bb.<\/em><\/p>\n<p>Perm\u00edtanme aclarar esto mediante la presentaci\u00f3n del plan de acci\u00f3n.<\/p>\n<h2>Plan de acci\u00f3n<\/h2>\n<p>Tenemos un total de 234 d\u00edas para esta operaci\u00f3n de transferencia de conocimiento con desarrollo de pruebas de caracterizaci\u00f3n, o 248.8 d\u00edas si modificamos el par\u00e1metro RF% como visto anteriormente, lo que representa entre 11.7 y 12.5 persona\/meses sobre la base de 20 d\u00edas por mes. Vamos a basar nuestro plan de acci\u00f3n sobre estas dos hip\u00f3tesis, la primera &#8216;hip\u00f3tesis media&#8217;, la segunda &#8216;hip\u00f3tesis alta&#8217;.<\/p>\n<p>De hecho, no podemos contar con 20 d\u00edas al mes, porque supone que no falta nadie, o no tener vacaciones. Consideramos (en Francia) que una persona dispone de cinco semanas de vacaciones y dos semanas de d\u00edas feriados. Puede variar de un a\u00f1o al otro, pero digamos que contando con d\u00edas de baja, es una cifra usual. Esto nos da un total de:<\/p>\n<p style=\"text-align: center\"><em>52 semanas al a\u00f1o &#8211; 7 semanas de ausencia = 45 semanas trabajadas.<br \/>\n45 semanas x 5 d\u00edas a la semana = 225 d\u00edas al a\u00f1o.<br \/>\n225 d\u00edas \/ 12 meses = 18,5 d\u00edas de trabajo al mes.<\/em><\/p>\n<p>Nuestra carga total de proyecto es de 234 d\u00edas (hip\u00f3tesis 1) o 248.8 d\u00edas (hip\u00f3tesis 2), que representan respectivamente 2.5 o 2.65 hombre\/meses para un equipo de 5 personas y 18.5 d\u00edas por mes.<\/p>\n<p>5 personas: creo que es un equipo de tama\u00f1o correcto para encargarse de esta aplicaci\u00f3n y garantizar su futuro mantenimiento. Dudo que el equipo original en Microsoft haya sido menos numeroso. Sobre la base de este equipo, nuestro proyecto de transferencia de conocimiento y desarrollo de pruebas ser\u00eda inferior a 3 meses.<\/p>\n<p>Sin embargo, tres meses es el tiempo sistem\u00e1ticamente utilizado para la fase &#8216;transferencia de conocimiento&#8217; en cualquier respuesta a un RFP. Menos de 3 meses, no es cre\u00edble: requerir\u00eda un mayor n\u00famero de personas que el n\u00famero de personas necesarias en las fases posteriores de desarrollo. Esto significar\u00eda no completar la fase de transferencia correctamente y por lo tanto poner en peligro la prestaci\u00f3n de externalizaci\u00f3n.<br \/>\nM\u00e1s all\u00e1 de los 3 meses, se toma el riesgo de aumentar la carga y por lo tanto el coste del proyecto m\u00e1s all\u00e1 de lo que ofrecen los competidores, y por lo tanto se pierde el contrato. As\u00ed que todo el mundo va a proponer un periodo de 3 meses, duraci\u00f3n bastante aceptable para un CIO.<\/p>\n<p>Entonces, vamos a basar nuestro plan de acci\u00f3n en una planificaci\u00f3n de tres meses, con una carga de 2.5 (o 2.65 hombre\/meses) para un equipo de 5 personas. Esto nos da un margen de 20% (3 &#8211; 2.5 = 0.5 = 20% de 2,5) o 13% (por un cargo de 2.65 hombre\/meses).<\/p>\n<p>La siguiente tabla resume estos resultados:<\/p>\n<p><a href=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlanTable.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2082\" src=\"http:\/\/qualilogy.com\/fr\/wp-content\/uploads\/sites\/2\/2014\/09\/Qualilogy_Legacy_ActionPlanTable.jpg\" alt=\"Qualilogy_Legacy_ActionPlanTable\" width=\"371\" height=\"162\" \/><\/a><br \/>\nPor lo general se evalua la carga de gesti\u00f3n del proyecto en un 20% del total del proyecto, pero creo que ser\u00e1 m\u00e1s bajo en una transferencia de fase de conocimiento. En cualquier caso, tenemos un poco de margen si empezamos con una planificaci\u00f3n de tres meses.<\/p>\n<p>As\u00ed que me gustar\u00eda hacer las siguientes propuestas:<\/p>\n<h3>Empezar con las funciones m\u00e1s complejas<\/h3>\n<p>30 funciones muy complejas requieren 25.1 d\u00edas en nuestra hip\u00f3tesis 1 o 26.9 en nuestra hip\u00f3tesis 2, y 6 funciones &#8216;monstruosas&#8217; requieren 23.5 j. En total, voy a redondear hasta 50 d\u00edas de carga, 10 d\u00edas\/hombre por un equipo de 5 personas.<\/p>\n<p>Mi consejo es utilizar las dos primeras semanas de nuestro calendario de 3 meses para escribir las pruebas y documentar las funciones m\u00e1s complejas, con reuniones frecuentes (al menos 2 por semana) para ver si esta primera parte del proyecto puede cumplirse en las 2 semanas planificadas. Si este es el caso, podemos tener confianza para la realizaci\u00f3n del resto de nuestras pruebas.<\/p>\n<h3>Compartir tareas entre los dos equipos<\/h3>\n<p>Otra recomendaci\u00f3n que me gustar\u00eda sugerir para esta primera fase: dividir el trabajo de desarrollo de pruebas por estos componentes m\u00e1s complejos entre los dos equipos, el primero que ya conoce el c\u00f3digo actual, y el segundo que se llevar\u00e1 a cabo la transferencia de conocimiento. Podemos trabajar de dos maneras:<\/p>\n<ul>\n<li>Desarrollo conjunto: un desarrollador del nuevo equipo programa pruebas con la ayuda de un desarrollador del equipo actual.<\/li>\n<li>Desarrollo separado con transferencia de conocimiento: cada desarrollador programa sus pruebas de manera independiente sobre las funciones m\u00e1s complejas (no las mismas al mismo tiempo, obviamente). Ambos se encuentran en el final de la tarde para presentar su trabajo, hacer comentarios al respecto, explicar y facilitar la transferencia de conocimiento para el desarrollador del nuevo equipo.<\/li>\n<\/ul>\n<p>La primera opci\u00f3n es, probablemente, la que va a optimizar la calidad de nuestra cobertura de pruebas, ya que tenemos los beneficios del descubrimiento y de la comprensi\u00f3n del c\u00f3digo por un desarrollador del nuevo equipo, con la ayuda de un desarrollador que ya conoce este c\u00f3digo. La desventaja es que requiere recursos adicionales del equipo actual, no directamente productivos como en la segunda opci\u00f3n.<\/p>\n<p>Debo decir que tengo una ligera preferencia por la segunda opci\u00f3n, que me parece m\u00e1s beneficiosa. El desarrollador del nuevo equipo realiza pruebas de caracterizaci\u00f3n que le permitan descubrir y entender el comportamiento de la aplicaci\u00f3n. En paralelo, un desarrollador del actual equipo escribe pruebas unitarias en un c\u00f3digo conocido, antes de pasarlo al desarrollador del nuevo equipo. Es importante, sin embargo, reservar tiempo para que los dos comparten su trabajo y que el desarrollador del equipo actual, o verifica y completa el trabajo del desarrollador del nuevo equipo, o ense\u00f1a y comenta las pruebas que \u00e9l mismo desarroll\u00f3. Este tiempo compartido tambi\u00e9n debe permitir documentar las pruebas. Creo que una hora al d\u00eda trabajando juntos al principio, deber\u00eda permitir la transferencia de conocimiento. Sin embargo, probablemente pasar\u00e1 a 2 horas por d\u00eda r\u00e1pidamente.<\/p>\n<p>En ambos casos, esta divisi\u00f3n del trabajo deber\u00eda permitir:<\/p>\n<ul>\n<li>Garantizar la transferencia de conocimiento y realizar pruebas de calidad en las funciones m\u00e1s complejas.<\/li>\n<li>Un mejor seguimiento de esta fase del proyecto, probablemente la m\u00e1s dif\u00edcil.<\/li>\n<li>Asegurar el calendario y evitar cualquier contratiempo en el inicio del proyecto, beneficiandose de los conocimientos del c\u00f3digo del equipo actual.<\/li>\n<\/ul>\n<h3>Modular los recursos m\u00e1s eficientemente<\/h3>\n<p>En ambos casos, necesitaremos recursos del equipo actual, pero de nuevo, durante un per\u00edodo relativamente corto de aproximadamente dos semanas. Sin embargo, es posible modular, m\u00e1s f\u00e1cilmente en la segunda opci\u00f3n, con menos desarrolladores del equipo actual. Incluso podemos mezclar las dos opciones: por ejemplo, desarrollo conjunto de las 6 funciones &#8216;monstruosas&#8217; y cada uno separado para desarrollar las otras 33 funciones de alta complejidad.<\/p>\n<p>Creo que este tipo de recomendaci\u00f3n se puede ofrecer en comit\u00e9 de proyecto, y ver lo que piensan los diferentes participantes. Entre desarrollo compartido o separado, con m\u00e1s o menos recursos de cada equipo. De hecho, se puede imaginar todas las variantes posibles.<br \/>\nPor ejemplo: 2 desarrolladores del equipo actual y tres desarrolladores del nuevo equipo, para un total de 5 personas, comparten el trabajo de escritura de pruebas sobre estos componentes m\u00e1s complejos. Durante el mismo tiempo, otros dos desarrolladores del nuevo equipo comienzan a trabajar sobre los componentes menos complejos. Con el fin de:<\/p>\n<ul>\n<li>Aseg\u00fararse de evitar retraso en la caracterizaci\u00f3n de los componentes m\u00e1s complejos, con dos personas que tienen el conocimiento &#8230;<\/li>\n<li>&#8230; mientras se adquiere una primera visi\u00f3n de la tarea de escritura de pruebas en los componentes de entre 20 y 200 puntos de CC, para una mejor visibilidad de toda la aplicaci\u00f3n y por lo tanto del proyecto.<\/li>\n<\/ul>\n<p>En funci\u00f3n de las distintas opciones, es evidente que hay que calcular la carga adicional en el equipo actual y los impactos en el calendario.<\/p>\n<h3>Modificar la cobertura de pruebas<\/h3>\n<p>Creo que empezar con los componentes m\u00e1s complejos, con cobertura de estos componentes de 100% de su Complejidad Ciclom\u00e1tica debe asegurar la transferencia de conocimiento sobre la parte m\u00e1s dif\u00edcil, la m\u00e1s pesada y compleja de la aplicaci\u00f3n, y por lo tanto el proyecto. Luego podemos ir a las 503 funciones de \u2013 relativamente \u2013 menor complejidad.<\/p>\n<p>\u00bfQu\u00e9 hacer si nos estamos quedando atr\u00e1s, encontrando retrasos? Si quieremos cumplir el plazo de tres meses que hemos decidido, vamos a tener que reducir la carga de trabajo y por lo tanto la cobertura de pruebas.<\/p>\n<p>Se evalu\u00f3 al 65% de la Complejidad Ciclom\u00e1tica de los componentes de la aplicaci\u00f3n, 100% de los de m\u00e1s de 20 puntos de CC y 60% y para los dem\u00e1s. Dec\u00edamos en <a title=\"Aplicaci\u00f3n Legacy \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (VI)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-refactorizacion-reingenieria-6\/\" target=\"_blank\">nuestro post anterior<\/a> que el esfuerzo de pruebas corresponde (m\u00e1s o menos) a una distribuci\u00f3n de Pareto, y que era casi lo mismo el tiempo para desarrollar el 70% o el 80% de las pruebas para un componente que el tiempo necesario para el 20% o 30% restante. Esto es relativo, pero una disminuci\u00f3n menor en nuestra cobertura de pruebas debe permitir reducir la carga de trabajo de manera proporcionalmente mayor.<\/p>\n<p>Por ejemplo, si en vez de 100% de cobertura de los componentes de entre 20 y 200 puntos de CC, tenemos la intenci\u00f3n de reducir la cobertura hasta 80%, nuestra carga de trabajo cambia de la siguiente manera:<\/p>\n<ul>\n<li>93.7 d\u00edas frente a 117.2 d\u00edas en nuestra hip\u00f3tesis 1, o 23.5 d\u00edas, una disminucion del 20% de la carga inicial.<\/li>\n<li>105.4 d\u00edas frente a 131.8 d\u00edas en nuestra hip\u00f3tesis 2, o 26.4 d\u00edas para de nuevo una ganancia de 20%.<\/li>\n<\/ul>\n<p>Podemos ver que cualquier retraso se puede reducir al ganar d\u00edas con una reducci\u00f3n m\u00ednima de cobertura de pruebas, sin sacrificar demasiado la calidad de la transferencia de conocimiento.<\/p>\n<h2>S\u00edntesis<\/h2>\n<p><a title=\"Aplicaci\u00f3n Legacy C \u2013 \u00bfRefactorizaci\u00f3n o reingenier\u00eda? (I)\" href=\"http:\/\/qualilogy.com\/es\/aplicacion-legacy-c-refactorizacion-reingenieria-1\/\" target=\"_blank\">Una de las tareas asignadas<\/a> consiste en calcular el coste de la transferencia de conocimiento de la aplicaci\u00f3n a un otro equipo y proponer una estrategia para un proyecto de este tipo.<\/p>\n<p>Nos basamos en el concepto de caracterizaci\u00f3n de pruebas de Michael Feathers, con la doble ventaja de tener una cobertura de pruebas para nuestra aplicaci\u00f3n Legacy y asegurar la transferencia de conocimiento.<\/p>\n<p>Construimos una f\u00f3rmula basada en la Complejidad Ciclom\u00e1tica y un factor de legibilidad, tratando de encontrar el equilibrio adecuado entre simplicidad y precisi\u00f3n. Examinamos las posibles objeciones a los resultados obtenidos con esta f\u00f3rmula.<\/p>\n<p>Por \u00faltimo, hemos construido un plan de acci\u00f3n, con diferentes propuestas que pueden convencer (o tranquilizar) a un CIO de la fiabilidad de nuestro an\u00e1lisis y la viabilidad de nuestro proyecto.<\/p>\n<p>En nuestro pr\u00f3ximo post, vamos a trabajar en nuestra segunda misi\u00f3n: la refactorizaci\u00f3n de nuestra aplicaci\u00f3n Legacy, con la ayuda del plugin Sqale de SonarQube.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Hemos visto en el post anterior c\u00f3mo usar el dashboard SonarQube para estimar el esfuerzo de pruebas de caracterizaci\u00f3n, pruebas recomendadas por Michael Feathers en su libro \u00abWorking Effectively with Legacy Code\u00bb. Hemos clasificado los componentes de nuestra aplicaci\u00f3n Legacy (Microsoft Word 1.1a) en diferentes grupos de funciones: las m\u00e1s simples con Complejidad Ciclom\u00e1tica (CC) [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-1336","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1336"}],"collection":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/comments?post=1336"}],"version-history":[{"count":37,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1336\/revisions"}],"predecessor-version":[{"id":1378,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/1336\/revisions\/1378"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=1336"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=1336"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=1336"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}