{"id":35,"date":"2011-12-04T10:24:55","date_gmt":"2011-12-04T09:24:55","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=35"},"modified":"2013-01-04T10:25:52","modified_gmt":"2013-01-04T09:25:52","slug":"costes-y-riesgos","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/costes-y-riesgos\/","title":{"rendered":"Costes y riesgos"},"content":{"rendered":"<p>Back to raw metrics &#8211; Vuelta hacia las m\u00e9tricas elementales.<\/p>\n<p>Un cliente te pide una auditor\u00eda de la calidad de una aplicaci\u00f3n o de un portafolio de aplicaciones. Espera una respuesta a una cuesti\u00f3n muy precisa. Por ejemplo:<\/p>\n<ul>\n<li>Esta aplicaci\u00f3n constituye una parte importante de mi presupuesto: \u00bfes posible reducir sus costes y c\u00f3mo?<\/li>\n<li>Me piden recuperar el mantenimiento de esta aplicaci\u00f3n. Solamente s\u00e9 que se trata de una aplicaci\u00f3n compleja. \u00bfQu\u00e9 debo esperar?<\/li>\n<li>\u00bfEs posible hacer un outsourcing de esta aplicaci\u00f3n? \u00bfCu\u00e1les son los riesgos?<\/li>\n<li>Vamos a fusionarnos con esta otra entidad. \u00bfCu\u00e1les sistemas utilizar? \u00bfLos suyos o los nuestros?<\/li>\n<\/ul>\n<p>Hay dos cuestiones distintas en estas cuestiones.<\/p>\n<ol>\n<li>\u00bfCu\u00e1les son los costes?<\/li>\n<li>\u00bfCu\u00e1les son los riesgos?<!--more--><\/li>\n<\/ol>\n<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignright size-full wp-image-170\" title=\"QualCostRisk2\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2011\/11\/QualCostRisk21.jpg\" alt=\"\" width=\"237\" height=\"145\" \/><\/a> El departamento TI produce aplicaciones. Pone \u00e1 disposici\u00f3n de los usuarios las aplicaciones que les permiten ejercer el negocio de la empresa. Si estas aplicaciones tienen defectos, producen errores, funcionan demasiado lentamente, pierden datos, los usuarios est\u00e1n descontentos.<\/p>\n<p>Una auditor\u00eda de la calidad de una aplicaci\u00f3n deber\u00eda siempre responder a esta cuesti\u00f3n doble: \u00bfc\u00f3mo optimizar los costes sin arriesgar la calidad del producto?<\/p>\n<p>Comencemos con las m\u00e9tricas cuantitativas disponibles con una herramienta de an\u00e1lisis de c\u00f3digo.<\/p>\n<p>La talla de la aplicaci\u00f3n o de sus diferentes m\u00f3dulos, en n\u00famero de l\u00edneas de c\u00f3digo (LOC). Esta medida es dependiente de la tecnolog\u00eda: 200 000 l\u00edneas de c\u00f3digo (o 200 kLOC) representa una talla importante para una aplicaci\u00f3n J2EE pero relativamente m\u00ednima para Cobol.<\/p>\n<p>El n\u00famero de objetos. Por objeto, entiendo por supuesto los ficheros, pero tambi\u00e9n los componentes: clases y m\u00e9todos Java, p\u00e1ginas JSP, ficheros Javascript, programas y p\u00e1rrafos Cobol, funciones y procedimientos SQL, etc. En s\u00ed mismo, este n\u00famero no es significativo, pero con el total de l\u00edneas de c\u00f3digo, obtenemos una medida muy importante: la granularidad de los objetos.<br \/>\n200 kLOC en 200 clases Java representa 1 000 l\u00edneas de c\u00f3digo por clase: es enorme. Esta aplicaci\u00f3n es probablemente poco &#8216;legible&#8217;, y necesitar\u00e1 un esfuerzo &#8211; pues un coste &#8211; m\u00e1s importante si deseamos trasladarla a otro equipo. A tomar en consideraci\u00f3n si nuestro cliente debe recuperar el mantenimiento aplicativo o para un outsourcing.<\/p>\n<p>El n\u00famero de m\u00e9todos por clase: cuanto m\u00e1s elevado, m\u00e1s las clases ser\u00e1n llenas de funcionalidades. Esto puede indicar un problema de dise\u00f1o, que va a ser un peso adicional para la comprensi\u00f3n de la aplicaci\u00f3n, pero tambi\u00e9n aumentar\u00e1 la dificultad en hacer evolucionarla. El riesgo se vuelve m\u00e1s elevado de introducir defectos cuando un desarrollador efect\u00faa una modificaci\u00f3n. Prever una carga de pruebas en consecuencia. Esto va a hacer crecer los costes de mantenimiento.<\/p>\n<p>Tambi\u00e9n mires al n\u00famero de LOC por m\u00e9todo para medir la portabilidad de la aplicaci\u00f3n. Sobre todo, el porcentaje de comentarios (l\u00edneas de comentarios \/ total LOC). Estas medidas permiten precisar el coste de transferencia de la aplicaci\u00f3n.<\/p>\n<p>El n\u00famero de l\u00edneas de c\u00f3digo en comentarios. Un desarrollador pone el c\u00f3digo en comentarios con el fin de guardar esta versi\u00f3n del c\u00f3digo. Esto indica que no est\u00e1 seguro, o sea de la nueva funcionalidad \u00e1 implementar, o sea del c\u00f3digo \u00e1 producir para \u00e9sta.<br \/>\nGeneralmente es un buen indicador de la edad de la aplicaci\u00f3n. Cuanto m\u00e1s elevado el c\u00f3digo en comentarios, m\u00e1s se sucedieron desarrolladores en la aplicaci\u00f3n, m\u00e1s la aplicaci\u00f3n es antigua. Una vez sin embargo, esta tasa de c\u00f3digo en comentarios fue elevada en una aplicaci\u00f3n que era en su primera versi\u00f3n, lo que indicaba una evoluci\u00f3n de las especificaciones funcionales durante la fase de desarrollo.<\/p>\n<p>Otras medidas interesantes, cuando est\u00e1n disponibles: los comentarios vac\u00edos. O los objetos cuyo c\u00f3digo completo est\u00e1 en comentarios: el programa o el m\u00e9todo no hace nada. Aparte aumentar las cargas de mantenimiento in\u00fatilmente.<\/p>\n<p>El n\u00famero de l\u00edneas duplicadas. Muy peligroso para la fiabilidad de la aplicaci\u00f3n. Si el mismo bloque de c\u00f3digo es duplicado N veces, cada modificaci\u00f3n de este c\u00f3digo deber\u00e1 realizarse N veces. No s\u00f3lo esto es un peso para el coste de mantenimiento, pero si el desarrollador olvida repercutir la modificaci\u00f3n sobre un solo bloque, el riesgo de malfonction para los usuarios es elevado. Pues carga de evoluci\u00f3n importante y carga de pruebas tambi\u00e9n. Ser\u00eda m\u00e1s juicioso de disponer de un componente \u00fanico que implemienta esta funcionalidad. Un componente reutilizable y de calidad en lugar de N componentes duplicados: \u00bfque prefieras, para tu presupuesto y tus usuarios?<\/p>\n<p>La complejidad ciclom\u00e1tica (CC). Sin entrar en el detalle de esta medida, digamos que la CC es un buen indicador del n\u00famero de reglas funcionales o t\u00e9cnicas presentes en un componente o una aplicaci\u00f3n. M\u00e1s all\u00e1 de 60 000 puntos de CC, una aplicaci\u00f3n incluye tantas funcionalidades que se vuelve muy dif\u00edcil \u00e1 someter a pruebas. Prever una herramienta de automatizaci\u00f3n de las pruebas, o vas a estallar tu presupuesto y tus planificaciones.<\/p>\n<p>Identificar los componentes con la CC m\u00e1s elevada con el fin de identificar los que ser\u00e1n los m\u00e1s dif\u00edciles \u00e1 hacer evolucionar.<\/p>\n<p>Cruces la complejidad con el n\u00famero de l\u00edneas de c\u00f3digo, y tendras los componentes m\u00e1s peligrosos para tus usuarios: el riesgo de introducir un defecto es elevado ya que el componente es \u00e1 la vez pesado y complejo. De nuevo, pruebas obligatorias, rigurosas y exhaustivas. Si por encima es poco documentado, puedes pensar en reescribirlo.<\/p>\n<p>Vemos que bastan algunas m\u00e9tricas elementales (raw metrics) para poder comenzar a responder a las cuestiones de nuestro cliente:<\/p>\n<ul>\n<li>\u00bfCu\u00e1l es el coste de transferencia de esta aplicaci\u00f3n? \u00bfCu\u00e1l es el esfuerzo para que un nuevo desarrollador sea operacional con esta aplicaci\u00f3n?<\/li>\n<li>\u00bfCu\u00e1l es el coste de una evoluci\u00f3n para esta aplicaci\u00f3n? \u00bfCu\u00e1les cargas de pruebas prever?<\/li>\n<li>\u00bfCu\u00e1l es el riesgo de introducir un defecto cuando se realiza una evoluci\u00f3n? Cual es el riesgo de no fiabilidad para los usuarios.<\/li>\n<\/ul>\n<p>Con un poco de experiencia \u2013 estos n\u00fameros pueden variar seg\u00fan las tecnolog\u00edas \u2013 pero sobre todo un poco de sentido com\u00fan, aprendemos r\u00e1pidamente cuales son los datos interesantes y c\u00f3mo combinarlos con el fin de optimizar estas algunas medidas.<\/p>\n<p>Una m\u00e9trica es s\u00f3lo un n\u00famero. Es la utilizaci\u00f3n que hacemos de ella qui\u00e9n le da todo su valor para responder \u00e1 la cuesti\u00f3n de nuestro cliente: \u00bfcostes y riesgos?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Back to raw metrics &#8211; Vuelta hacia las m\u00e9tricas elementales. Un cliente te pide una auditor\u00eda de la calidad de una aplicaci\u00f3n o de un portafolio de aplicaciones. Espera una respuesta a una cuesti\u00f3n muy precisa. Por ejemplo: Esta aplicaci\u00f3n constituye una parte importante de mi presupuesto: \u00bfes posible reducir sus costes y c\u00f3mo? Me [&hellip;]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2],"tags":[],"class_list":["post-35","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/35"}],"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=35"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/35\/revisions"}],"predecessor-version":[{"id":36,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/35\/revisions\/36"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=35"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=35"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=35"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}