{"id":42,"date":"2011-12-14T10:36:05","date_gmt":"2011-12-14T09:36:05","guid":{"rendered":"http:\/\/dev.qualilogy.com\/es\/?p=42"},"modified":"2013-01-04T10:37:02","modified_gmt":"2013-01-04T09:37:02","slug":"best-of-both-worlds","status":"publish","type":"post","link":"http:\/\/qualilogy.com\/es\/best-of-both-worlds\/","title":{"rendered":"Best of both worlds"},"content":{"rendered":"<p><a href=\"http:\/\/vicken.deviantart.com\/\" target=\"_blank\"><img loading=\"lazy\" decoding=\"async\" class=\"alignleft size-full wp-image-311\" title=\"Qual_RedSail\" alt=\"\" src=\"http:\/\/qualilogy.com\/wp-content\/uploads\/2011\/12\/Qual_RedSail.jpg\" width=\"300\" height=\"298\" \/><\/a>Despu\u00e9s del post anterior <a title=\"\u00bfCual es la primera cuestion?\" href=\"http:\/\/qualilogy.com\/es\/cual-es-la-primera-pregunta\" target=\"_blank\">\u00bfCu\u00e1l es la primera cuesti\u00f3n?<\/a> alguien me pregunt\u00f3 si exist\u00edan algunos procesos o buenas pr\u00e1cticas que permiten alcanzar estos dos objetivos: costes vs. riesgos.<\/p>\n<p>\u00bfExiste un \u201cbest of both worlds\u201d con el fin de producir un c\u00f3digo de calidad sin sobrepasar presupuestos y planificaciones?<\/p>\n<p><!--more--><\/p>\n<p>&nbsp;<\/p>\n<p>De hecho, no es necesario buscar este \u201cmejor de ambos mundos\u201d. Por ejemplo, si tengo que realizar una auditor\u00eda de un sistema bancario, voy primero a verificar que las prioridades en t\u00e9rminos de negocios son:<\/p>\n<ul>\n<li>Asset Management: time to market, no defectos que impiden o molestan el funcionamiento del sistema el primer d\u00eda, ningun problema de rendimiento o de seguridad evidentemente. El presupuesto no es un problema: se puede doblar al equipo con el fin de respetar la planificaci\u00f3n. La mantenibilidad no es una preocupaci\u00f3n: esta aplicaci\u00f3n puede ser obsoleta dentro de algunos a\u00f1os. Y en lo peor de los casos, podemos echarla y reescribirla, o comprar un software de empresa.<\/li>\n<li>Bank retail (servicio a particulares): sistemas antiguos, generalmente Mainframe-Cobol, a menudo en outsourcing para cuesti\u00f3n de costes. Los usuarios est\u00e1n acostumbrados a que la entrega se retrase 2 o 3 semanas, y no se sorprenden si unas funcionalidades no sean correctas cuando la aplicaci\u00f3n se va en producci\u00f3n.<\/li>\n<\/ul>\n<p>Es importante cualificar la alineaci\u00f3n negocios\/TI. D\u00edgale al primer equipo en Asset Management que vas a medir las derivas de mantenibilidad con el fin de controlar el presupuesto, o al segundo equipo (Bank retail) que vas a poner en marcha una pol\u00edtica de tolerancia cero con el incumplimiento de las buenas pr\u00e1cticas de rendimiento, y te van a responder \u201c\u00bfQu\u00e9 importa? Eso no es un problema\u201d.<\/p>\n<p>No creo que existe una receta milagrosa que conduzca al \u201cbest of both worlds\u201d. Sin embargo, imaginemos un momento que se te pide encargarte de un proyecto sin conocer su \u201calineaci\u00f3n\u201d, as\u00ed lo har\u00e9 yo.<\/p>\n<p>1. \u201cYou cannot control what you cannot measure\u201d (Tom deMarco). Empezar\u00e9 primero por implementar una herramienta de an\u00e1lisis de c\u00f3digo que permita dibujar una mapa de la calidad de la aplicaci\u00f3n. <a title=\"Medir y controlar\" href=\"http:\/\/qualilogy.com\/es\/medir-y-controlar\" target=\"_blank\">Medir y controlar<\/a>.<\/p>\n<p>2. Definir\u00e9 una estrategia para el mantenimiento de esta aplicaci\u00f3n, con los expertos del proyecto. Esta \u00e1rea presenta riesgos: mejor evitar modificarla. Pero si hay que tocar \u00e1 uno de estos componentes, entonces planificar pruebas exhaustivas. Tendremos que reescribir esta parte porque hay demasiado c\u00f3digo duplicado y va a costarnos mucho esfuerzo para mantenerla. Es una prioridad de volver a desarrollarla en forma de componentes reutilizables. \u00bfDocumentar esta parte? O.k., esto puede esperar. \u00bfCu\u00e1nto tiempo para hacer todo esto?<br \/>\nEsto permite conseguir un plan de acci\u00f3n con diferentes prioridades a diferentes costes a corto\/medio\/largo plazos. Hay que conocer cu\u00e1l es la alineaci\u00f3n de la aplicaci\u00f3n para construir este plan.<\/p>\n<p>3. Los defectos de programaci\u00f3n son los m\u00e1s f\u00e1ciles a identificar y resolver. Podemos efectuar regularmente an\u00e1lisis de c\u00f3digo y definir un proceso de remediaci\u00f3n de estas violaciones en el cual integramos el plan de acci\u00f3n. Estas medidas constituyen el primer paso hacia un proceso de Continuous Inprovement. Sobre esto: <a title=\"Mejora contin\u00faa de la calidad\" href=\"http:\/\/qualilogy.com\/es\/mejora-continua-de-la-calidad\" target=\"_blank\">Mejora contin\u00faa de la calidad<\/a>.<\/p>\n<p>4. Los defectos de especificaciones (ausentes, err\u00f3neas o mal comprendidas) son los m\u00e1s costosos pero tambi\u00e9n los m\u00e1s dif\u00edciles a identificar. Implantar una metodolog\u00eda a base de revisi\u00f3n con usuarios, prototipo, m\u00e9todos \u00e1giles, etc. La que prefieres pero, en mi opini\u00f3n, debe:<\/p>\n<ul>\n<li>Implicar al usuario: el debe validar la interfaz (usability) y las funcionalidades. Posiblemente usuarios finales o sus representantes, poca importancia tiene, pero deben ser integrados en el proyecto. \u00bfCu\u00e1ntos &#8216;defectos funcionales&#8217; son de hecho especificaciones que evolucionaron en fase de proyecto? Como responsable de esta aplicaci\u00f3n, quiero que sea bien claro que no asumir\u00e9 los costes.<\/li>\n<li>Ser compatible con la tecnolog\u00eda: no veo mucho a Scrum o m\u00e9todos \u00e1giles en proyectos Mainframe-Cobol.<\/li>\n<\/ul>\n<p>5. Pruebas. Pesan mucho sobre el presupuesto y la planificaci\u00f3n. Primero, definir el nivel de QA requerido. Si la aplicaci\u00f3n no es muy voluminosa ni compleja, pruebas unitarias y de integraci\u00f3n pueden ser suficiente. De hecho, la dificultad proviene de aplicaciones gordas y complejas: \u00bfcu\u00e1nto invertir en la realizaci\u00f3n de los planes de prueba, en cargas de prueba y en herramientas?<br \/>\nEs cuando la colaboraci\u00f3n entre el equipo de proyecto y los equipos de QA es importante. Por ejemplo, un cliente desea una auditor\u00eda sobre la escalabilidad de una de sus aplicaciones: los datos y el n\u00famero de usuarios van a ser multiplicados por 3. Un primer an\u00e1lisis de c\u00f3digo identifica los escapes potenciales de rendimiento, que se corrigen. El resultado de los an\u00e1lisis posteriores es compartido con el equipo de QA durante la fase de desarrollo, con el fin de prestarles asistencia en la definici\u00f3n de sus planes de prueba. Est\u00e1 decidido automatizar las pruebas de rendimiento y concentrar las pruebas manuales en las funcionalidades nuevas.<\/p>\n<p>6. El feedback del terreno es siempre apreciable. Recuperamos el numero de defectos encontrados en producci\u00f3n y hacemos una correlaci\u00f3n con los defectos encontrados durante los an\u00e1lisis de c\u00f3digo. Podemos ense\u00f1ar los resultados al equipo pero tambi\u00e9n a los usuarios y los gestores. Normalmente, debes poder demostrar que esto va en en el buen sentido y todo el mundo est\u00e1 contento de saber que esto va en el buen sentido.<\/p>\n<p>7. Poner en marcha las herramientas adecuadas. Una herramienta de an\u00e1lisis de c\u00f3digo conectada con la herramienta de desarrollo y de gesti\u00f3n de cambios\/versiones, y herramientas de pruebas. Depende de las tecnolog\u00edas.<\/p>\n<p>8. Har\u00e1 falta un equipo con un cierto nivel de madurez.<\/p>\n<p>Esto puede tomar a\u00f1os antes de conseguir tal proceso que optimiza los costes y limita los riesgos. Pues es recomendable priorizar estas acciones seg\u00fan los objetivos y la alineaci\u00f3n negocios\/TI m\u00e1s bien que de apuntar primero al \u201cbest of both worlds\u201d.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Despu\u00e9s del post anterior \u00bfCu\u00e1l es la primera cuesti\u00f3n? alguien me pregunt\u00f3 si exist\u00edan algunos procesos o buenas pr\u00e1cticas que permiten alcanzar estos dos objetivos: costes vs. riesgos. \u00bfExiste un \u201cbest of both worlds\u201d con el fin de producir un c\u00f3digo de calidad sin sobrepasar presupuestos y planificaciones?<\/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-42","post","type-post","status-publish","format-standard","hentry","category-calidad-de-aplicaciones"],"_links":{"self":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/42"}],"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=42"}],"version-history":[{"count":1,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/42\/revisions"}],"predecessor-version":[{"id":43,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/posts\/42\/revisions\/43"}],"wp:attachment":[{"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/media?parent=42"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/categories?post=42"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/qualilogy.com\/es\/wp-json\/wp\/v2\/tags?post=42"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}