Release 1.0 is the beginning of your softwares life, not the end of the project. Your quality of life after Release 1.0 depends on choices you make long before that vital milestone. Michael T. Nygard
ndice 1. Resumen ........................................................................................................................................................... 3 En el presente documento se propone una serie de tcnicas y prcticas, as como una serie de adecuaciones a los procesos que actualmente existen en conjunto con el uso de herramientas de software con el fin de llevar a cabo liberaciones de sistemas de forma exitosa reduciendo el riesgo de fracaso. .................................................................................................................................................................. 3 2. Glosario de Trminos .................................................................................................................................. 3 3. Antecedentes ............................................................................................................................................... 43 4. Problemtica ................................................................................................................................................ 54 5. Anlisis ........................................................................................................................................................... 65 5.1. Caso de Estudio ........................................................................................................................................... 6 5.2. Otras Metodologas .............................................................................................................................. 108 5.3. Herramientas ......................................................................................................................................... 119 6. Solucin Propuesta ............................................................................................................................... 1210 6.1. Diseo de la arquitectura ............................................................................................................... 1611 6.2. Desarrollo, pruebas y CI a la Agile ............................................................................................... 1812 6.3. Control de Versiones y CI ................................................................................................................ 2014 6.4. Pruebas (Unidad, Sistema, Estrs...) .......................................................................................... 2015 6.5. Deployement & Release .................................................................................................................. 2418 7. Anlisis Costo-Beneficio ..................................................................................................................... 2620 8. Conclusin................................................................................................................................................ 2620 9. Referencias .............................................................................................................................................. 2620 10. Apndices .............................................................................................................................................. 2721 1. Resumen ........................................................................................................................................................... 3 2. Glosario de Trminos ................................................................................................................................. 3 3. Antecedentes .................................................................................................................................................. 3 4. Problemtica .................................................................................................................................................. 4 5. Anlisis .............................................................................................................................................................. 5 5.1. Caso de Estudio ........................................................................................................................................... 6 5.2. QSSDP ............................................................................................................................................................. 8 5.3. Otras Metodologas ................................................................................................................................... 9 5.4. Herramientas ........................................................................................................................................... 10 6. Solucin Propuesta .................................................................................................................................... 12 6.1. QSSDP .......................................................................................................................................................... 12 6.2. Diseo de la arquitectura .................................................................................................................... 15 6.3. Desarrollo, pruebas y CI a la Agile .................................................................................................... 17 6.4. Control de Versiones y CI ..................................................................................................................... 18 6.5. Pruebas (Unidad, Sistema, Estrs...) ............................................................................................... 19 6.6. Deployement & Release ....................................................................................................................... 23 7. Conclusin..................................................................................................................................................... 24 8. Referencias ................................................................................................................................................... 25 9. Apndices ...................................................................................................................................................... 26
1. Resumen En el presente documento se propone una serie de tcnicas y prcticas, as como una serie de adecuaciones a los procesos que actualmente existen en conjunto con el uso de herramientas de software con el fin de llevar a cabo liberaciones de sistemas de forma exitosa reduciendo el riesgo de fracaso. 2. Glosario de Trminos Liberacin de Software (delivery)- La liberacin de un producto de software se refiere a una serie de tareas y esfuerzos enfocados en poner el producto a disposicin de los usuarios. La liberacin implica que el producto de software se encuentre en ejecucin sobre el ambiente productivo. Algunos de los aspectos ms importantes que se deben considerar como parte de la liberacin son: Construccin del producto Configuracin del ambiente Migracin de datos Instalacin Pruebas Capacitacin Soporte Monitoreo Optimizacin
Deployment - Se refiere a las tareas asociadas a la preparacin de la aplicacin para su instalacin en un ambiente de ejecucin. El deployment no necesariamente implica la liberacin del producto a los usuarios finales ya que se puede realizar un deployment a un ambiente de pruebas. El deployment involucra el empaquetamiento del producto para convertirlo en un artefacto ejecutable, la distribucin del artefacto ya sea a un servidor o en equipos cliente, la configuracin del ambiente de ejecucin y la instalacin del artefacto ejecutable.
3. Antecedentes Durante nuestra experiencia en Quarksoft hemos participado en diversos proyectos con caractersticas muy distintas. Algo que parece ser una constante en la mayora de los proyectos son los problemas que se presentan al liberar la aplicacin en el ambiente productivo. Generalmente en esta etapa se presentan una serie de complicaciones que provocan un ambiente de tensin muy caracterstico que lamentablemente se ha hecho familiar para quienes hemos vivido la experiencia. Esta etapa se caracteriza por un ambiente general de tensin en el equipo de desarrollo, impaciencia por parte del cliente y una gran presin sobre todo el equipo y en particular sobre el arquitecto y el lder de proyecto. La razn de todos estos sntomas es la incertidumbre que se tiene de que el producto pueda funcionar en el ambiente productivo de la manera en la que se concibi. El riesgo de que pueda ocurrir algn problema durante la liberacin del producto es alto y el costo asociado a la ocurrencia del problema puede ser mayor an. Ciertamente nuestros procesos de desarrollo estn orientados a que la calidad del producto est garantizada y para ello se tienen diversos mecanismos que nos ayudan a lograr este objetivo, sin embargo es evidente que existe una deficiencia en la definicin de los procesos, en su entendimiento o en nuestra efectividad al momento de aplicarlos. Es incuestionable que los problemas surgidos durante la liberacin de un sistema tienen un costo indeterminado en los desarrollos actuales (an aquellos de pequea y mediana escala) y por ello es necesario que se puedan identificar las causas que originan esta desviacin ya que de otra manera no es posible plantear soluciones efectivas. El propsito de este anlisis es proponer mejoras a los procesos actuales que permitan llevar a cabo esta transicin de manera controlada. En su forma ideal, el proceso de liberacin de un sistema debe ser como el resto de nuestros procesos: repetible, medible, confiable y adaptable. Con el fin de llegar a una propuesta que aporte un valor para la organizacin tenemos que partir de un anlisis de nuestra situacin actual y de nuestras experiencias pasadas para conocer en dnde estamos fallando y encontrar entonces qu podemos hacer para mejorar. De nuestra propia experiencia podemos aportar prcticas que hemos aplicado y que han probado ser benficas a nuestro proceso. La experiencia vivida durante el desarrollo y puesta en produccin de MidasSistema X ha servido como fuente principal de inspiracin para esta propuesta que resulta una suerte de postmortem donde analizamos lo que se hizo bien y lo que se hizo mal. Aunado a nuestra experiencia estn las experiencias de toda una comunidad que se ha enfrentado a problemas similares y que tambin nos pueden aportar beneficios. Por ello nuestra propuesta parte del anlisis de los siguientes puntos: Caso de estudio (Midas, NMP) Nuestro proceso de desarrollo actual (QSSDP) Manejo del delivery en otras Metodologas Herramientas de apoyo 4. Problemtica El delivery de un producto de software es un proceso generalmente doloroso para el equipo de desarrollo debido mayormente a la incertidumbre que plantea la ejecucin en un ambiente productivo. En trminos bsicos el problema del delivery se resume en trasladar una aplicacin de un ambiente de ejecucin controlado por el equipo de desarrollo a un ambiente de ejecucin productivo donde generalmente existen muchos factores impredecibles que son difciles de replicar en los ambientes de pruebas.
Uno de los problemas ms graves del delivery es que an con nuestros procesos y mtricas no somos capaces de estimar ni medir el costo en tiempo y esfuerzo que va a tomar la puesta en produccin de la aplicacin. De acuerdo a nuestros procesos la liberacin es un mero trmite cuyo costo no es considerable, sin embargo la realidad nos ha demostrado que la liberacin requiere de planeacin, tiempo y esfuerzo y que generalmente este esfuerzo va ms all de desplegar la aplicacin en el servidor productivo.
Es complicado cuantificar el costo generado por una liberacin no planeada ya que los costos repercuten tanto del lado del cliente como de nuestro lado. El cliente puede estar perdiendo dinero por cada da de retraso del producto en produccin. De nuestro lado, al no estar planeado adecuadamente, la consecuencia es una desviacin en el plan que repercute en costos por los recursos y tiempo no planeados adems de posibles sanciones econmicas establecidas en el contrato de trabajo.
De manera general se pueden identificar los siguientes problemas asociados al delivery: Situaciones o elementos no previstos (pueden ser de carcter tcnico, tecnolgico, arquitectnico, de infraestructura o administrativo). Deficiencias en el cumplimiento de los requerimientos no funcionales. Nmero de defectos encontrados en produccin mayor a lo planeado. Tiempo no planeado para la configuracin, estabilizacin y puesta a punto de la aplicacin. Dificultad para diagnosticar y resolver problemas de la aplicacin que no pueden ser replicados en el ambiente de pruebas.
En las secciones subsecuentes se presenta un anlisis que pretende encontrar soluciones concretas que nos permitan reducir el grado de incertidumbre que implica la liberacin de un producto de software. 5. Anlisis En esta seccin se describe de manera general el anlisis que se llevo a cabo para encontrar los posibles puntos en los que estamos fallando como organizacin para garantizar un delivery exitoso. Para ello se estudi un caso en particular, que es el sistema MIDAS (sistema core de Nacional Monte de Piedad) el cual es un claro ejemplo de la problemtica que estamos viviendo. Tambin se consider importante analizar nuestros procesos para determinar si la causa de las principales fallas es un seguimiento inadecuado de los procesos o es que nuestros procesos no nos proveen de gua suficiente para alcanzar el objetivo de delivery y por ltimo se llevo a cabo un anlisis de algunas herramientas que nos pueden facilitar las tareas para lograr el objetivo deseado.
5.1. Caso de Estudio MidasSistema X es la aplicacin que da soporte a la operacin diaria de NMP en ms de 200 sucursales distribuidas en el territorio nacional. MidasSistema X es probablemente el sistema de mayor escala que se ha desarrollado en QuarksoftLa Empresa y debido a eso es que su liberacin ha sido una de las ms complicadas que hemos experimentado.
El anlisis de lo sucedido durante la liberacin de MidasSistema X nos llev a identificar los problemas que se presentaron y sus posibles causas (ver Apndice A). A pesar de que los problemas identificados pueden parecer muy particulares de la aplicacin, en el fondo se puede detectar que las causas tienen su origen en decisiones o acciones ejercidas en etapas anteriores.
Las decisiones que se toman en etapas tan tempranas como preanlisis o Diseo de Alto Nivel (HLD) son fundamentales para que el producto final pueda funcionar en un ambiente productivo de la manera en que fue concebido. A partir del anlisis de los problemas identificados en MidasSistema X hemos determinado una clasificacin que generaliza los problemas identificados: 1. Arquitectura Seleccin tecnolgica inadecuada (seleccin basada en tendencias de las comunidades de desarrollo, seleccin basada en solicitudes poco fundamentadas del cliente). Insuficiencia en anlisis de factibilidad (infraestructura disponible, atributos de calidad, tecnologa). No se llevan a cabo pruebas de concepto como una prctica comn. 1. Ambiente Indefinicin del ambiente productivo desde etapas tempranas del desarrollo. Diferencias entre el ambiente de desarrollo/pruebas y el ambiente productivo No contar con un ambiente de pruebas de sistema que sea lo ms cercano posible al ambiente productivo. Capacidad para almacenar/replicar/recrear ambientes completos para pruebas. 2. Tecnolgico/infraestructura Subestimacin de requerimientos de infraestructura y/o tecnolgicos. Disponibilidad de hardware y software que permita crear ambientes de prueba semejantes al ambiente productivo. Dificultad para determinar con precisin los requerimientos en infraestructura requeridos por la aplicacin (servidores, memoria, capacidad de procesamiento, almacenamiento, ancho de banda, etc.) Carencia de una base de conocimientos y mejores prcticas. No contamos con institucionalizacin de software para: diseo y arquitectura, modelado de datos, monitores de mtricas de performance, automatizacin de pruebas de capacidad. 3. Desarrollo Falta de identificacin de componentes crticos para su asignacin y cuidado de aspectos crticos del diseo. Incompetencia tcnica de los ingenieros (deficiencia en POO, desconocimiento del lenguaje, poca capacidad de investigacin, profesin errada) 4. Pruebas Pruebas de capacidad se dejan hasta el final si es que se llevan a cabo. Pruebas unitarias/integrales deficientes (pruebas de happy path). Pruebas de sistema no automatizadas. Pruebas de despliegue inexistentes. No hay lineamientos ni guas para generar pruebas de capacidad. Concepto de Integracin Continua mal entendido. 5. Administracin de la configuracin Uso inadecuado del repositorio. Scripts de configuracin inexistentes. Scripts de configuraciones no versionados. Scripts de BD no versionados. Liberaciones no versionados. Liberaciones no documentados (features, fixes, known bugs, etc.) 6. Metodologa No existe un plan de liberacin. No existe una estrategia de liberacin. La estrategia de pruebas se ha convertido en un formato ms que hay que llenar para cumplir con los procesos. No existe estrategia/plan de soporte. No existen guas o mejores prcticas para la actividad de soporte. No existe un plan de transicin de la nueva aplicacin hacia el personal de operaciones del cliente. Nuestros procesos ven la liberacin como un mero trmite administrativo no como una transicin en la que intervienen muy diversos factores que hay que medir y controlar para alcanzar el objetivo. 7. Administrativo Cmo establecer estrategias de interaccin con el cliente y otros proveedores involucrados. Cmo manejar la Tercerizacin del desarrollo (interaccin con otros proveedores).
Cabe sealar que algunos de los problemas mencionados salen del alcance de la presente propuesta ya que involucran un anlisis ms profundo y la participacin de otras reas como Recursos Humanos. Nuestra propuesta se enfoca mayormente en el aspecto tcnico/tecnolgico y metodolgico del rea operativa.
5.2. QSSDP Fase de Estimacin y Planeacin Proceso de Preanlisis: En s el proceso es bastante claro en cuanto a su alcance y propsito. El problema que hemos detectado es durante la ejecucin del proceso. Son muchas las ocasiones en las que no se le dedica el tiempo suficiente al preanlisis o no se le da la importancia necesaria. Otra observacin del proceso de preanlisis es que si parte de un anlisis muy superficial o con informacin limitada, la lista de componentes y la estimacin es generalmente una aproximacin muy lejana a la realidad. Formato para la estimacin de recursos crticos de computadora: En este template se mencionan aspectos relacionados al hardware como: memoria, espacio, procesamiento que son importantes para la operacin de la aplicacin durante el desarrollo y puesta en produccin. Sin embargo no se consideran los recursos necesarios para realizar las pruebas correspondientes al sistema. Fase de aceptacin del proyecto Forma STRAT: Este formato contiene la estrategia completa del proyecto. Todas las actividades y artefactos entregables se definen en este formato para ser adecuadamente planeados y contemplados en los costos asociados al proyecto. El proceso en si es claro y adecuado. Las fallas generalmente provienen de la falta de comunicacin o experiencia tanto del lder de proyecto como del arquitecto. Actualmente en la mayora de proyectos realizados por Quarksoft no se contemplan en la estrategia todos los recursos y actividades necesarias para realizar las pruebas, as como capacitacin de los ingenieros en herramientas necesarias para realizar las pruebas durante el desarrollo del proyecto.
Fase de desarrollo SPMP (Plan de Administracin del Proyecto de Software): Este proceso define la estrategia de desarrollo sin embargo no contempla una estrategia de deployment. El deployment no debe ser visto como una tarea que se inicia slo al finalizar el desarrollo del producto. SDP (Plan de Desarrollo de Software): En este formato se definen todas las tcnicas y prcticas relacionadas con el desarrollo de la aplicacin, sin embargo no se menciona ninguna prctica que el equipo deber seguir durante el desarrollo, con el propsito de garantizar el delivery. Plan de Pruebas: En este formato se define todo lo referente a las pruebas. Una parte importante que se incluye en este formato son los requerimientos de los ambientes de pruebas, sin embargo, como sucede con muchos otros formatos del proceso, no se utilizan con plena conciencia y se terminan rellenando las secciones con el nico propsito de cumplir con el proceso. Generalmente este formato se llena como un requisito durante el lanzamiento de la fase de desarrollo cuando debiera ser un documento que debe ser responsabilidad del arquitecto una vez concluido el HLD que es cuando se tiene plena conciencia de la arquitectura, los atributos de calidad y el tipo de componentes que se contemplan. SRS: En este formato se registran principalmente los requerimientos tanto funcionales como no funcionales, sin embargo a lo largo de los proyectos, no siempre se fijan las mtricas correctamente, resultando un tanto ambiguas y complejas de medir. Estrategia y Plan de Liberacin: Tras revisar todos los procesos y guas del QSSDP no encontramos alguno que hablara especficamente sobre la planeacin de actividades enfocadas a la liberacin del producto. Pareciera que se parte de la premisa de que todos los procesos de desarrollo y pruebas son suficientes para que al final del ltimo ciclo de desarrollo la aplicacin sea liberada en el ambiente productivo sin ningn problema. 5.3.5.2. Otras Metodologas RUP Rational Unified Process (RUP) es una de las metodologas de desarrollo de software ms conocidas y aceptadas dentro de la industria. RUP es un proceso que puede ser descrito en dos dimensiones. En el eje horizontal divide el ciclo de vida del proyecto en cuatro fases de las cuales la ltima de ellas (Transition) es dedicada a transferir el producto de software de un ambiente de pruebas a su ambiente final en produccin. Dentro de las nueve disciplinasAl mismo tiempo verticalmente se divide en 6 disciplinas de ingeniera y 3 de soporte, entre las que se encuentran: Business modeling, Requirements, Analisis and Design, Implementation, Test y Dse incluye el deployment. que es elEste ultimo es el conjunto de tareas enfocadas a poner el software a disposicin de los usuarios. La disciplina de deployment se intensifica en la fase de Transition por obvias razones, pero existen algunas actividades relacionadas con esta disciplina que se inician desde etapas anteriores (Elaboration y Construction). Tambin es importante sealar que las tres disciplinas de soporte: Configuration & Change MgmtManagement., Project Management y Environment sirven como apoyo para alcanzar los objetivos de la fase de Transition.
Una de las actividades importantes de la disciplina de deployment, es la elaboracin del artefacto Plan de Deployment en el que se detallan aspectos importantes que deben ser cubiertos durante la fase de transicin tales como: identificar factores de compatibilidad, estrategias de migracin y conversin de datos, establecer una agenda para las actividades de deployment, definir una estrategia de deployment y determinar un plan de capacitacin.
Scrum Scrum es una de las metodologas mas populares entre las metodologas de desarrollo de software agiles; es por ello que se llevo a cabo un anlisis especfico de cmo esta metodologa administra la fase de release. Una de las principales actividades es definir el Realease Planning, as como el Release Planning Meeting. El propsito de Release planning es definir los contenidos de una liberacin o especificar el incremento de un producto entregable. Esto supone identificar y asegurar lo siguiente: Un objetivo por cada liberacin. Un conjunto de requerimientos de mayor prioridad que sern desarrollados en la liberacin. Una estimacin poco granular por cada requerimiento Una fecha para la liberacin
La regla de oro en el Release Planning es no ir al detalle, no es responsabilidad del Relaese Planning precisar el detalle. Los planes de liberacin deben ser imprecisos, slo cuando el equipo inicie los trabajos de liberacin, entonces tendr retroalimentacin y empezar a entender que tan rpidamente se avanzar y cuanto puede ser logrado.
El propsito del release planning meeting, es que cada persona en el equipo entienda y se comprometa a entregar la liberacin convenida en la fecha acordada, En esta junta debern estar presentes: el dueo del producto, cualquier otro stakeholder que pueda agregar valor a la junta.
La junta debe tomar el siguiente camino: 1. El dueo del producto explica el objetivo de la liberacin al equipo. 2. Los desarrolladores proporcionan su productividad del equipo. Si el equipo no ha cambiado, la productividad debera ser el nmero de iteraciones en la liberacin multiplicado por la productividad de la ultima iteracin. 3. De acuerdo al valor, el dueo del producto introduce cada una de los requerimientos a los desarrolladores. 4. Los desarrolladores preguntan lo suficiente acerca de los requerimientos hasta ser capaces de constatar las estimaciones poco granulares. 5. Los desarrolladores evalan los riesgos tcnicos por cada requerimiento y proporcionan algunas calificaciones, por ejemplo. Alto, medio o, bajo. 6. Dado el objetivo de la liberacin y tomando en cuenta los valores, estimaciones o costos y riesgos, el dueo del producto, el dueo del producto selecciona los requerimientos de su lista y hace el plan de liberacin. 7. Se realiza un consenso de las necesidades que sern cubiertas en el plan de liberacin con cada uno de los presentes.
5.4.5.3. Herramientas 1
Fue necesario realizar un anlisis de herramientas que nos puedan ayudar a llevar a cabo tareas asociadas a lograr una liberacin exitosa. Principalmente para llevar a cabo pruebas de unidad, integracin y sistema existen libreras/frameworks que hemos adoptado dentro de la organizacin para apoyarnos al realizar estas actividades, sin embargo cuando se trata de realizar pruebas de capacidad, desempeo o concurrencia nos encontramos con que no hay una normatividad que nos proponga, sugiera u obligue a utilizar alguna herramienta particular. Sin esta gua es muy fcil perderse entre todas las herramientas que encontramos disponibles en Internet. Por eso es importante contar con un catlogo de herramientas que provea alguna gua sobre las capacidades de cada herramienta y preferentemente un tutorial para poder obtener beneficios de la
1 Para mayor detalle sobre este anlisis vase apndice D herramienta en un corto tiempo y no perder tiempo buscando en la documentacin cmo obtener un funcionamiento bsico. Aunque existen muchas herramientas no comerciales, en ocasiones no proveen todas las ventajas que ofrecen algunas herramientas comerciales. A continuacin se muestra una lista de las herramientas que fueron analizadas y sus principales caractersticas.
Generadores de carga: Un generador de carga permite simular picos de carga sobre servidores, redes u otros objetos, permitiendo as encontrar fcilmente cuellos de botella en las aplicaciones.
Profilers Hoy en da las aplicaciones han ido cambiando, a tal grado de tener aplicaciones distribuidas, virtualizadas, clusterizadas, etc.; por lo que desarrolladores, reas de calidad y hasta los dueos del negocio tienen que trabajar de manera conjunta para poder maximizar el valor del negocio. Por lo anterior, es difcil liberar una aplicacin sin problemas de desempeo, consumos mnimos de anchos de banda, cuellos de botella, optimizacin de algoritmos entre otras cosas. Abajo se muestran las caractersticas de algunas herramientas que ayudan en la solucin de problemas de este tipo.
6. Solucin Propuesta De acuerdo a los objetivos perseguidos y a partir del anlisis realizado en el capitulo anterior, se pueden formular una serie de propuestas de mejora que repercutan directamente sobre las liberaciones de sistemas desarrollados por Quarksoft.
Estas propuestas de mejora estn planteadas con la intencin de generar un beneficio significativo a los equipos de desarrollo dentro de Quarksoft. Estas propuestas, se enfocan principalmente en el QSSDP, Diseo de Alto Nivel, Diseo de la arquitectura, Administracin de la Configuracin, Pruebas e Integracin Continua.
6.1. QSSDP Fase de Estimacin y Planeacin Proceso de Preanlisis: Normalmente este es un proceso cuya duracin es determinada parcialmente por las necesidades del cliente. En ocasiones se reciben requisiciones de propuestas para participar en un concurso en el que se requiere una respuesta en un periodo de unos poco das. En este caso lo nico que proponemos es buscar u obtener la mayor informacin posible de ser posible mediante juntas con el cliente o asignar a un arquitecto con la suficiente experiencia para proponer una solucin viable, ya que desafortunadamente, la persona que desarrolla las propuestas inciales es aquella que no est asignada a un proyecto, lo cual no siempre lleva a que esta persona sea la ms adecuada para proponer una solucin. Seguir el procedimiento de diseo de arquitectura basado en la identificacin de requerimientos de negocio y atributos de calidad. En la medida de lo posible evitar generar propuestas al vapor que se solicitan con dos o tres das de antelacin. En muchas ocasiones se parte de un anlisis muy superficial o con informacin limitada, la lista de componentes y la estimacin es generalmente una aproximacin muy lejana a la realidad. La propuesta en este punto es que en casos en los que de antemano sabemos que nuestro anlisis no es suficientemente profundo, el lder del proyecto debe tratar de negociar de antemano con el cliente una reestimacin posterior cuando se hayan determinado todos los requerimientos y se haya definido una lista de componentes ms acorde a la realidad. Formato para la estimacin de recursos crticos de computadora: Adems de los aspectos que ya cubre el documento, proponemos que se deberan establecer todos los aspectos importantes para configurar un ambiente de pruebas similar o equivalente al que se espera tener en produccin para llevar a cabo nuestras pruebas durante todos los ciclos de desarrollo. Si de antemano se conoce el sistema operativo y la versin que se usar, es importante buscar tener ese mismo sistema operativo en nuestro ambiente de pruebas, si sabemos que la aplicacin requiere ser clusterizada, es importante considerar tener un cluster con al menos 2 nodos para las pruebas de sistema. El servidor de aplicaciones y el servidor de la base de datos que se van a utilizar tambin deben especificarse en conjunto con las especificaciones para cada ambiente necesario durante el desarrollo. Ya que hoy en da slo se mencionan los recursos crticos para el desarrollo, pero igual de crticos son los recursos para realizar pruebas. Fase de aceptacin del proyecto Forma STRAT: En lo que respecta al delivery, se debe contemplar en la estrategia todas las actividades y recursos necesarios para habilitar los ambientes necesarios para las pruebas y la capacitacin a los ingenieros en las herramientas que se requieran durante las pruebas. Se debe considerar tambin tiempos para llevar a cabo el proceso de deployment. Normalmente se llega a esta etapa y ya no hay una tarea especfica para registrar este tiempo y as es muy complicado cuantificarla y generar datos histricos que nos permitan medir el comportamiento y costos asociados a esta etapa.
Fase de desarrollo SPMP (Plan de Administracin del Proyecto de Software): Creemos que el deployment no debe ser visto como una tarea que se inicia slo al finalizar el desarrollo del producto, por lo que proponemos que debera iniciar durante el proceso de desarrollo en forma de despliegues parciales en puntos estratgicos del desarrollo, quizs al trmino de cada ciclo o como mejor convenga de acuerdo al proyecto y al anlisis realizado por el equipo. La intencin de los despliegues parciales es hacer ensayos en etapas tempranas para observar el comportamiento de la arquitectura en un ambiente cercano al productivo. Es importante monitorear con ello aspectos crticos funcionales, pero principalmente los aspectos no funcionales. Detectar en forma temprana problemas arquitectnicos o de diseo; sera vital para poder corregir a tiempo y evitar que el problema se detecte en etapas posteriores, lo cual es mucho ms costoso de corregir segn nuestros datos histricos sobre errores y la etapa de correccin. SDP (Plan de Desarrollo de Software): Proponemos que en este documento se deben documentar todas las posibles prcticas que el equipo deber seguir durante el desarrollo con el propsito de garantizar el delivery. Muchas de las prcticas y tcnicas que proponemos en este documento debieran incluirse como parte del plan de desarrollo para que sirva como una gua para el equipo de las polticas y prcticas que deben seguir y respetar. Plan de Pruebas: Proponemos que sea un requisito establecer el ambiente requerido para cada tipo de pruebas y apegarse a esa definicin con el fin de reducir riesgos durante la implantacin. Tambin se reduce la posibilidad de discrepancias entre ambientes de pruebas (e.g. en pruebas de unidad en el ambiente de un desarrollador pasa la prueba y en el de otro(s) no pasa.). Cada ambiente tiene caractersticas y configuraciones distintas y es importante identificarlas desde etapas tempranas del desarrollo. Incluso es posible tener distintas versiones del ambiente productivo con condiciones distintas que sirvan para realizar pruebas de capacidad (e.g. un ambiente de pruebas con una sola instancia, un ambiente de pruebas clusterizado). Para cada ambiente deben considerarse todas las caractersticas relevantes tales como: versin del sistema operativo, parches requeridos del sistema operativo, versin de la mquina virtual de Java, versin del servidor de aplicaciones, versin del servidor de aplicaciones, versiones de los sistemas operativos cliente soportados, versiones de los navegadores soportados por la aplicacin, entre otros. SRS: Es necesario establecer mtricas cuantificables ya que de otra forma el uso de mtricas ambiguas se convierte en un riesgo al llegar a la etapa de liberacin. Estrategia y Plan de Liberacin: La liberacin de un producto de software implica un periodo de transicin que involucra tareas de monitoreo, estabilizacin, optimizacin y puesta a punto de nuestra aplicacin. Tambin involucra tareas de capacitacin a usuarios y transmisin del conocimiento tcnico, e incluso tareas relacionadas al soporte tcnico. Otras metodologas como RUP consideran el deployment como una fase ms del proceso de desarrollo con actividades y procesos muy particulares. Consideramos importante incorporar en Quarksoft un proceso para planear desde un inicio del proyecto todas las actividades, riesgos, tcnicas, y condiciones necesarias para llevar a cabo una liberacin controlada. La estrategia de liberacin debe incluir todos los aspectos que rodean la liberacin del producto y que requieren de un seguimiento continuo para evitar que se salgan de nuestro control. Algunos de los elementos que debe contener este documento son: Lista de responsables de cada una de las reas que van a participar de alguna forma en el proceso de liberacin de la aplicacin. Debe incluirse algn medio de contacto y una descripcin breve de la intervencin dentro del flujo de la liberacin. Lista de supuestos, dependencias y restricciones. Lista de ambientes requeridos para cada etapa de pruebas. Estrategia de monitoreo de la aplicacin. Se deben establecer los mecanismos o herramientas que se pretenden utilizar para poder monitorear diversos aspectos de la aplicacin que permitan diagnosticar cualquier problema de manera rpida y efectiva. Descripcin del procedimiento para realizar un deployment en produccin. Generalmente todas las empresas tienen polticas o protocolos especficos que se deben seguir para realizar cambios en sus ambientes. Plan de liberacin. Se debe definir si la liberacin va a ser gradual (para un nmero limitado de usuarios bajo criterios como: perfil, situacin geogrfica, funcionalidad, etc.) o global. Si la aplicacin va a sustituir a otra aplicacin se debe planear una estrategia para llevar a cabo la transicin de la forma ms conveniente para el negocio y los usuarios. Este plan debe definirse en conjunto con el cliente. Plan de contingencia. Debe determinarse el mecanismo mediante el cual puede recuperarse el estado de la aplicacin luego de algn evento que rompa con la continuidad de la operacin, as como establecer el tiempo mximo en que este plan ser ejecutado, para poder garantizar la continuidad de la operacin. Plan de recursos requeridos por la aplicacin en un ambiente productivo. Determinar la tasa de crecimiento de la base de datos, ancho de banda requerido, espacio en disco, memoria. Plan de depuracin. Si la aplicacin genera muchos datos histricos o archivos temporales es importante considerar algn mecanismo para depuracin. Plan de migracin de datos. En ocasiones es necesario realizar migraciones de datos de aplicaciones anteriores a la nueva aplicacin. Es importante definir la estrategia que se va a seguir para llevarlo a cabo. Determinar el mecanismo y establecer el procedimiento para llevar a cabo la migracin. Estrategia de correccin de defectos. Determinar el procedimiento y herramientas mediante los que los usuarios van a reportar los errores y la estrategia de atencin de los errores. Plan de liberacin para actualizaciones. Determinar el proceso que se va a seguir para determinar las condiciones para liberar una nueva versin, los das y horarios que se dispongan y el protocolo necesario para ejecutar la liberacin. Plan de capacitacin/transicin. Es importante determinar las actividades para transmitir los detalles tcnicos a los nuevos responsables de la aplicacin. El Plan de Deployment contiene los detalles tcnicos del procedimiento para liberar una versin de la aplicacin en el ambiente productivo. Precondiciones para el primer deployment. Normalmente para el primer deployment se requieren ciertas configuraciones adicionales que se hacen una sola vez. Lista detallada de los artefactos del deployment. Procedimiento de deployment. Definir los pasos para realizar el deployment en forma manual y de ser posible su automatizacin explicar tambin cmo ejecutar el proceso de deployment automtico. Procedimiento para ejecutar las pruebas de deployment. Procedimiento de rollback del deployment en caso de que ocurra algn problema. Ubicacin de las bitcoras de la aplicacin y una descripcin de lo que contienen. Mecanismos de monitoreo disponibles para la aplicacin. Documentacin de errores comunes y sus posibles soluciones.
6.2.6.1. Diseo de la arquitectura El diseo de la arquitectura es una instancia fundamental en la que se puede definir el xito o fracaso de un producto de software. La arquitectura de software es definida como un conjunto de decisiones que determinan la estructura de una aplicacin. Una mala decisin o la omisin de factores importantes pueden repercutir de manera importante en la consolidacin del producto final as como en la calidad de vida de los integrantes del equipo de desarrollo. Creemos que eEn la medida en que estas prcticas se lleven a cabo de manera sistemtica en cada proyecto, el riesgo de que se presenten errores graves de diseo al liberar una aplicacin ser mucho menor que en la forma en la que tradicionalmente se lleva a cabo el HLD. Algunas de las prcticas que consideramos importantes en las actividades del diseo arquitectnico son: El diseo de la arquitectura se debe llevar a cabo antes de documentar el HLD como una tarea independiente a la Creacin del documento de HLD, la cual debe ser planeada en la estrategia como una tarea independiente que se debe planear desde un inicio. En el diseo de la arquitectura debe participar el/los arquitecto(s) nicamente. La participacin de los ingenieros generalmente no es productiva. Si el arquitecto lo determina puede involucrar a algn ingeniero del equipo con mayor experiencia, pero no debe ser como una imposicin sino como una decisin en conjunto del lder del proyecto y el arquitecto para determinar las mejores condiciones para llevar a cabo la actividad. La responsabilidad final sobre la arquitectura y las decisiones de diseo es siempre del arquitecto. El proceso de validacin de la arquitectura debe ser promovido y gestionado por el rea de Operaciones. Es importante contar con disponibilidad planeada de otros arquitectos para este tipo de actividades. Una sugerencia sera planear a los arquitectos al 8075% en todos los proyectos para que exista la posibilidad de involucrarlos en alguna evaluacin/estimacin/preanlisis. La creacin de prototipos funcionales que demuestren la factibilidad de la arquitectura es una prctica muy til y que tambin debe ser evaluada la necesidad de realizarlo desde un inicioetapas tempranas del desarrollo, para que se considere en la planeacin. Considerar la creacin/adaptacin del arquetipo del proyecto como una tarea o como parte de la tarea de Diseo de la Arquitectura. El arquetipo constituye una parte importante para que el desarrollo se inicie de manera ms rpida y controlada. Considerar en el diseo todos las posibles variables del ambiente productivo que puedan afectar nuestra aplicacin. Algunos aspectos importantes son: las caractersticas de la red, caractersticas del servidor, caractersticas de los clientes, versiones de sistemas operativos de servidor y clientes, requerimientos mnimos de operacin, sistemas externos, repositorios, bases de datos, mecanismos de seguridad, versiones del navegador soportadas(en caso de aplicaciones web), versin del manejador de base de datos, versin del servidor de aplicaciones, entre otras. Ser cuidadosos en la seleccin tecnolgica. Muchas veces nos dejamos llevar por las tendencias e innovaciones y buscamos incorporarlas de inmediato en algn proyecto. Antes de decidir introducir una nueva tecnologa hay que hacer un trabajo de investigacin y de ser posible pruebas de concepto para asegurarnos de que cubre con todas las necesidades de nuestro proyecto. Algunos aspectos que se deben cuidar son: soporte del producto, el tamao de la comunidad de usuarios, casos exitosos actualmente en produccin, tener en cuenta el tipo de aplicacin, s es una aplicacin web rica en contenido, s es un aplicacin stand-alone, visitar los foros para darnos cuenta si hay muchas quejas de bugs sin atender, los tiempos de respuesta a issues, limitaciones del producto, su licenciamiento. Solicitar el consejo de otros arquitectos. Formar un comit con otros arquitectos y Charlar discutir con otros arquitectos acerca de las inquietudes que tenemos sobre nuestra propuesta arquitectnica es una buena idea. Las experiencias de otros pueden enriquecer nuestra arquitectura o darnos una visin distinta de las cosas. Mientras no contemos con una base de conocimientos en la que podamos concentrar las experiencias y lecciones aprendidas, la mejor manera sigue siendo el contacto directo entre colegas. Ya que no se cuenta con una base de conocimientos sera bueno que se dedicar cierto tiempo para que los arquitectos puedan compartir sus experiencias con las tecnologas que han usado en proyectos reales (no cuentan los Hello World) y as contribuir a que cada arquitecto pueda hacer una mejor eleccin a la hora de seleccionar una tecnologa. 6.3.6.2. Desarrollo, pruebas y CI a la Agile Uno de los principios fundamentales del Manifiesto gil es satisfacer la necesidad del cliente a travs de entregas tempranas y continuas de un software que aporte un valor desde el punto de vista del negocio. De este principio nace el concepto de Continuous Delivery (CD) que se resume en una serie de prcticas y patrones para producir desde etapas tempranas del desarrollo versiones del software listas para proveer parcialmente funcionalidad que ofrezca un valor para el cliente. La premisa principal detrs del concepto continuous delivery es que la mejor forma de garantizar que el producto final pueda funcionar en un ambiente productivo como se concibi originalmente, es mediante constantes ensayos en un ambiente que sea lo ms cercano posible al ambiente productivo final. Para lograr una prctica real del CD es necesario cumplir con algunos pre-requisitos y ponerlos en prctica para eventualmente lograr la madurez necesaria para hacer liberaciones continuas.
Entre las practicas propuestas por CD, esta el uso de Continuos Integration el cual pretende una integracin frecuente de cualquier cambio o cdigo nuevo existente en el repositorio, lo cual recientemente se introdujo en La Empresa, sin un gran xito.
Para mejorar esta situacin y obtener el mayor beneficio de nuestro servidor de CI proponemos los siguientes puntos que consideramos importantes: Fomentar en el equipo la importancia de realizar una prueba bien hecha y que cada commit de cdigo debe ir acompaado de sus respectivas pruebas funcionando correctamente. Transmitir al equipo la importancia de CI y motivarlos a cumplir con su objetivo. Fomentar la prctica de check-ins frecuentes, al menos una vez al da. Formatted: Font: 12 pt, Not Bold Formatted: Left Formatted: Font: 12 pt, Not Bold Prestar atencin a las notificaciones de Bamboo para actuar de forma inmediata cuando falle un build. Pero principalmente buscar tener el cuidado necesario al realizar un check- in Idealmente Bamboo debe ejecutar un build por cada commit en el trunk. La recomendacin de los agilistas para este punto es: si duele, hazlo con ms frecuencia. Considerar los reportes de Bamboo como elementos auditables durante las auditoras de calidad. Mientras no se vuelva parte integral de nuestros procesos, no existe forma de medir ni cuantificar la eficacia de nuestra herramienta de CI. Otro beneficio es que al ser un elemento auditable estamos obligados a cumplir con l. A nadie le gusta hacer las cosas por obligacin, pero es un buen mecanismo cuando los equipos no tienen un grado mayor de madurez. Al fallar un build el responsable (el que hizo el ltimo commit) debe detener todo lo que est haciendo y avocarse a corregir el error. El resto del equipo, al ser notificados del fallo, deben abstenerse de subir nuevos cambios hasta que reciban una nueva notificacin de build exitoso. Establecer tiempos mximos para corregir errores en el build (10 minutos es un tiempo recomendado). Si al cumplirse el tiempo establecido no ha sido posible corregir el error, el responsable debe deshacer sus cambios y regresar a la versin anterior para que el resto del equipo pueda continuar con sus check-ins. Incorporar un script para el uso correcto del repositorio y el servidor de CI con los puntos mencionados. El procedimiento recomendado antes de hacer un check-in es: descargar la versin ms reciente del cdigo desde el repositorio, resolver conflictos por cambios en la copia local, compilar y correr todas las pruebas de unidad/integracin; si no ocurri ningn error, entonces se procede a subir el cdigo, en caso contrario se debe corregir el error y repetir todos los pasos mencionados. Bajo ninguna circunstancia comentar cdigo de las pruebas, as como archivos de configuracin para que el build sea exitoso. La experiencia dicta que ese cdigo permanecer comentado por el resto del desarrollo y eso puede impactar negativamente en la calidad del producto final. Contar con la infraestructura adecuada para soportar tanto servidor de versionamiento, como servidor de CI disponibles en cualquier lugar de forma efectiva. En su defectoBuscar tener acceso tanto a tu repositorio como al CI desde cualquier parte de forma directa, ya que mediante VPNs slo provoca que el equipo no quiera realizar un check-in o un update a su copia local, por el tiempo que va a perder en realizar esta actividad. Como se puede observar CI no se trata simplemente de una herramienta como Bamboo, es una prctica que involucra varias herramientas: control de versiones (SVN), automatizacin de la construccin y ejecucin de las pruebas (Maven) y una herramienta para automatizar y monitorear la construccin y pruebas (Bamboo) las cuales a lo largo de la construccin se van convirtiendo en pruebas de regresin, y lo ms importante es no perder de vista el compromiso del equipo para practicar CI de la manera correcta.
6.4.6.3. Control de Versiones y CI En QuarksoftLa Empresa el uso de SVN es una prctica comn en prcticamente todos los equipos. Todos lo usamos para versionar el cdigo y trabajar de forma distribuida, pero no hemos aprendido a usarlo como parte integral de CI y en ocasiones lo utilizamos en nuestra propia contra haciendo de su uso una verdadera odisea. A continuacin hacemos algunas recomendaciones que ayudarn a mejorar el uso de SVN: La forma ms efectiva de practicar CI es haciendo integraciones del cdigo directamente en el trunk. Claro est que esta forma de trabajar requiere no de una varita mgica, sino de disciplina y compromiso de todo el equipo de desarrollo. Sincronizar nuestro cdigo local con los ltimos cambios del trunk de manera frecuente. Entre ms frecuente lo hagamos menos problemas tendremos cuando estemos listos para incorporar nuestros cambios. Hacer check-ins frecuentes. No dejar pasar das sin incorporar nuestros cambios ya que los cambios ms pequeos son ms fciles de incorporar que los cambios grandes. Lo ideal es hacerlo varias veces al dadespus dar por terminado cualquier componente o cambio, previamente probado. Limitar el uso de branches a casos muy particulares. Una buena razn para hacer un branch es cuando se llega a una versin estable que es candidata para liberacin a pruebas preproductivas o a produccin (branching for release). La gran ventaja de generar este branch es que nunca va a ser reincorporado al trunk, su propsito es tener una versin candidata para liberacin congelada. Mucho mejor que cerrar el acceso al trunk durante cierto tiempo. Cuando un branch cumpli con su propsito hay que eliminarlo. Cuando se tenga una versin estable, candidata a ser liberada, esta deber ser congelada creando un tag, lo cual nos permitir saber exactamente que se esta liberando. Evitar usar branches que se mantengan vivos durante largos periodos de tiempo. Este es un claro anti-patrn de CI. Documentar cada commit con informacin relevante del cambio. Una buena prctica es en una sola lnea presentar el propsito general del cambio y en las lneas subsecuentes explicar detalles adicionales de manera que al consultar el log se pueda ubicar de manera inmediata cada cambio y cuando sea necesario se pueden consultar los detalles. Es muy frustrante consultar un log y ver mensajes sin sentido como: Se suben correcciones. 6.5.6.4. Pruebas (Unidad, Sistema, Estrs...) Pruebas unitarias e integracin Las pruebas unitarias e integracin sirven bsicamente para garantizar un correcto funcionamiento de las partes que componen el sistema y las interacciones que tienen los componentes. El enfoque de estas pruebas no tiene que ser necesariamente orientado a flujos de negocio sino a un funcionamiento bsico (entradas vs. salidas esperadas). Lo importante de estas pruebas es que cada componente sea evaluado en todas las posibles condiciones para verificar que su comportamiento sea el esperado. Es difcil proponer alguna prctica para lograr pruebas unitarias/integrales eficaces. Lo mnimo que esperamos de un ingeniero de software es que sea responsable de entender el componente que hizo y que genere un set de pruebas completo y congruente con lo que se espera del componente. Lo que proponemos para aumentar la eficacia de nuestras pruebas unitarias/integrales es : Calcular la complejidad ciclomtica del cdigo, lo cual lo podemos hacer mediante alguna herramienta como Cobertura o Cclover. Utilizar un analizador de cobertura de las pruebas. Es posible configurar el build en Bamboo para que establezca una poltica de fallo en caso de no cubrir con algn porcentaje mnimo de cobertura de las pruebas. Incorporar a nuestro proceso de construccin un analizador de estndares de codificacin que permita detectar y eliminar malas prcticas de programacin. Una herramienta como FindBugs permite realizar este anlisis desde el entorno de desarrollo e incluso cuenta con un plugin para incorporarlo al proceso de build con Maven. Inspeccionar los casos de prueba o la prueba durante la inspeccin de cdigo. Al realizar una prueba de unidad, tener en cuenta las 6 reglas Primero escribe la prueba (Test driven) Nunca escribas una prueba que pase a la primera Inicia con el caso Null o algo que creas que no va a funcionar No tengas miedo en hacer algo trivial para que la prueba pase Bajo acoplamiento y la capacidad para realizar las pruebas van de la mano Haz uso de objetos MOCK Tratar de transmitir a los ingenieros de software la visin completa de la aplicacin y los conceptos bsicos del negocio. Entre ms conocimiento tengan sobre el propsito de la aplicacin, mayores argumentos tienen para generar un set de pruebas acorde a los objetivos del negocio.
Pruebas orientadas al negocio Las pruebas de sistema tienen un alcance ms amplio y su enfoque debe ser completamente orientado a los flujos de negocio que cubre la aplicacin. Lo ideal es que este set de pruebas sea elaborado en conjunto con el cliente para que los escenarios realmente representen algo muy cercano a lo que se espera en un ambiente productivo. El siguiente paso es definir el mecanismo para ejecutar las pruebas. Bsicamente se tienen dos opciones: ejecucin manual o automatizada. La ejecucin manual requiere de recursos y tiempo, lo que generalmente es costoso aunque Formatted: Font: Italic Formatted: Font: Italic cuenta con la ventaja de que se pueden identificar errores o problemas de usabilidad que no se pueden identificar mediante herramientas de automatizacin. Se recomienda que siempre que sea posible automatizar las pruebas de sistema se haga. Cada proyecto es distinto y por eso es tarea conjunta del arquitecto y el lder de proyecto definir la estrategia de pruebas desde un inicio. No en todos los casos es posible automatizar las pruebas desde la interfaz grfica de usuario ya que depende del framework o tecnologa utilizada, pero en tales casos es posible automatizar las pruebas desde la capa subyacente. Si la aplicacin est correctamente diseada, debiera ser posible correr pruebas contra los servicios detrs de la capa de vista. Adicional a las pruebas de sistema automatizadas es recomendable tambin llevar a cabo pruebas exploratorias que son pruebas manuales desde la interfaz grfica de usuario para encontrar problemas de usabilidad o errores visuales que son difciles de detectar desde las pruebas automatizadas. Sin embargo estas pruebas no deben ser exhaustivas ni cubrir todos los escenarios posibles, son pruebas que incluso pueden ser ejecutadas por usuarios del sistema en un ambiente de pruebas piloto. Otro aspecto importante de las pruebas de sistema es el ambiente de ejecucin. Es indispensable contar con un ambiente lo ms cercano posible al ambiente productivo desde etapas tempranas del desarrollo para llevar a cabo estas pruebas y verificar que nuestra aplicacin funciona correctamente en el ambiente que se espera tener en produccin. Se deben tomar en cuenta todos las posibles variantes del entorno como: Versin del sistema operativo del servidor Caractersticas del servidor (memoria y procesador) Versin del manejador de la base de datos Versiones de sistemas operativos soportados por la aplicacin para los clientes Caractersticas de los equipos cliente (memoria y procesador) Versiones de navegador de Internet soportadas (en el caso de aplicaciones web) Versin de libreras o dependencias instaladas en los equipos cliente (e.g. versin de la JVM) Configuraciones especiales en el servidor o en equipos cliente (e.g. configuracin requerida de nivel de seguridad del navegador de Internet) Modelos de dispositivos de hardware, as como firmware del hardware controlados por la aplicacin (Si aplica) Caractersticas de la red en el ambiente productivo. Creemos que eEl ambiente de ejecucin realmente impacta en los resultados de las pruebas y que en la medida en que se le de mayor importancia a los ambientes de ejecucin, las liberaciones van a tener un grado mayor de certidumbre.
Pruebas de requerimientos no funcionales Las pruebas de aspectos no funcionales son quiz las ms difciles de llevar a cabo. Para empezar es necesario tener bien claro el objetivo de cada prueba y las mtricas que van a usarse para medir cada atributo de calidad. Es responsabilidad del arquitecto no generar falsas expectativas desde el inicio y valorar cada atributo de calidad con el que debe cumplir y establecer mtricas alcanzables por la aplicacin. En general los aspectos no funcionales estn correlacionados de tal forma que se contraponen uno con otro. Por ello no es posible comprometer una aplicacin a cumplir con todos los atributos de calidad en las mismas proporciones. Las recomendaciones para llevar a cabo las pruebas de requerimientos no funcionales son: Contar con el ambiente adecuado para ejecutar las pruebas. Entre ms cercano sea al ambiente productivo, ms veracidad tendrn las pruebas. De ser posible, utilizar el servidor productivo y llevar las pruebas a cabo en instalaciones del cliente. Evitar caer en especulaciones sobre la capacidad real del sistema basada en mediciones sobre un ambiente de pruebas. Extrapolar la capacidad del sistema de un ambiente de pruebas al productivo es un engao. Por ejemplo, pensar que la aplicacin ser el doble de rpida en produccin debido a que se cuenta con un procesador ms rpido o con ms memoria fsica. Definir los escenarios de pruebas. Generalmente se seleccionan algunos escenarios que son los ms representativos o crticos para el negocio. Utilizar una herramienta para automatizar la ejecucin de las pruebas mediante la virtualizacin de usuarios y provocacin de estrs en la aplicacin. Utilizar una herramienta de profiling para monitorear la ejecucin de las pruebas y analizar el comportamiento de la aplicacin, as como posibles cuellos de botella, fugas de memoria entre otras cosas. Utilizar herramientas para monitoreo de la red. El resultado de nuestras pruebas puede variar de acuerdo a la carga de la red en el momento en que se ejecutan. El trfico y calidad de la red son factores impactan las pruebas y que deben considerarse y medirse. En pruebas de capacidad es recomendable ejecutar una prueba pequea a manera de calentamiento de la aplicacin antes de ejecutar la prueba que se va a medir. Esto es porque las aplicaciones normalmente tienen configuraciones de cach que se van inicializando conforme se va requiriendo. De la misma forma el entorno de ejecucin tambin puede tener un comportamiento adaptativo como es el caso de la Mquina Virtual de Java (JVM) que va optimizando algunos aspectos internos conforme se van descubriendo ciertos patrones durante la ejecucin. Cuando se realizan cambios a la configuracin del servidor o la JVM con el propsito de mejorar la respuesta de la aplicacin, hay que tener cuidado de hacer un cambio a la vez para tener oportunidad de probar, medir y obtener una conclusin sobre la eficacia del cambio. Considerar pruebas de longevidad. Observar si el desempeo de la aplicacin vara despus de mucho tiempo de estar en ejecucin. Este tipo de pruebas permite identificar fugas en la memoria o problemas de estabilidad. Considerar realizar pruebas con ciertos volmenes de informacin, ya que el desempeo de la aplicacin puede variar mucho con respecto a ciertos volmenes de informacin y esto se debe principalmente al diseo de la base de datos.
Pruebas de despliegue El ltimo tipo de pruebas que queremos comentar son las que se enfocan en el deployment. Su propsito es verificar que todas las variables del ambiente de ejecucin de nuestra aplicacin se encuentran en el estado esperado. Este tipo de pruebas es relevante cuando se libera una nueva versin a produccin y por ello es importante hacer un check-up de todo lo que sabemos que puede salir mal: Verificar que todas las instancias de la aplicacin estn respondiendo en las direcciones y puertos esperados. Verificar que todos las instancias de la base de datos responden Verificar que todos los sistemas externos de los que depende la aplicacin estn respondiendo. Adicionalmente es recomendable incluir en las pruebas de deployment una serie de pruebas rpidas para verificar que la aplicacin no se encuentra en un estado de error. A este tipo de pruebas se les conoce como smoke tests y su propsito es hacer fallar la aplicacin lo ms pronto posible si es que va a fallar. Estas pruebas incluyen por ejemplo: iniciar sesin desde cada instancia de la aplicacin y hacer alguna operacin de consulta por ejemplo para verificar as que la aplicacin est respondiendo en todas sus capas. Es importante considerar en automatizar tambin el set de pruebas de deployment para que pueda ser ejecutado fcilmente por los encargados de realizar el deployment de la aplicacin sin la intervencin del equipo de desarrollo o pruebas.
6.6.6.5. Deployement & Release Muchos ven la liberacin de la versin 1.0 como el final del camino, sin embargo nosotros lo vemos ms como el final de una etapa y el inicio de otra. La liberacin marca el inicio de la vida de nuestra aplicacin y de este punto en adelante solo resta esperar que la aplicacin soporte en pie todos los imponderables que se susciten en el ambiente productivo. Todas las pruebas realizadas previas a este momento son una simulacin de las condiciones que pueden esperarse en un ambiente productivo, pero nunca igualarn a la realidad. Si nuestra aplicacin sobrevive a los ataques de un ejrcito de usuarios con conductas impredecibles que nos resultan generalmente ilgicas, solo entonces podremos estar tranquilos y ciertos de que nuestro trabajo ha terminado. En el 99% de los casos esto no ocurre as, por lo que nuestra responsabilidad a partir de ese punto es llevar a nuestra aplicacin a un punto de estabilidad. La estrategia de liberacin va a ser fundamental para que este proceso no se alargue en demasa y se logre alcanzar el objetivo en el menor tiempo y con la menor inversin de recursos. A partir Comment [EM1]: Jorge menciona agregar una seccin de pruebas de regresin, pero en realidad yo lo veo como pruebas funcionales automatizadas, que es una seccin anterior de la primera liberacin las condiciones son distintas a las que se tenan en la fase de desarrollo. Consideramos que es de vital importancia para el proyecto lograr una identificacin temprana de todos los stakeholders la aplicacin e involucrarlos desde el inicio para preparar el terreno y lograr una colaboracin adecuada. Existen algunas prcticas que consideramos son tiles como parte de la estrategia de deployment. 1. Evitar tener un experto en deployment. Lo ideal es tener un script versionado bajo configuracin que ejecute todos los pasos requeridos para el deployemnt en forma automtica mediante un simple comando. Adicionalmente todos los ingenieros del equipo deben conocer y entender desde un principio cul es el procedimiento para ejecutar un deployment. Depender de una sola persona o de un documento no es una buena estrategia. 2. Automatizacin del deployment. El deployment consiste en una serie de pasos repetible. La mejor manera de ejecutarla es mediante un script que pueda ser interpretado por una mquina. De ser posible este proceso automtico de deployment puede registrar cada accin en una bitcora para tener registro de quin y cundo lo ejecut. 3. Contar con un set de pruebas de deployment. El objetivo de estas pruebas es hacer un checklist de todo lo que puede afectar nuestra aplicacin. Tambin un conjunto de smoke- tests que identifiquen problemas con la versin de manera rpida. 4. No corregir errores directamente en el ambiente productivo. Cuando se hacen cambios en el ambiente productivo se pierde el control de lo que se hizo y las consecuencias pueden ser muy graves. 5. Considerar un procedimiento de rollback. El costo de que la aplicacin no funcione como se espera en un ambiente productivo es muy alto. Debemos tener la capacidad de reaccionar de manera muy rpida ante cualquier problema detectado en la nueva versin. 6. Cuando ocurre algn error debemos tener la forma de encontrar el problema de manera rpida y transparente. El log de la aplicacin es generalmente el primer lugar donde debemos buscar y debemos ser cuidadosos con su configuracin. El nivel de logging es importante mantenerlo en WARNING en el ambiente productivo para evitar que se sature con mensajes de debugging. Adems de estas prcticas existen un par de tcnicas para pruebas que pueden ser tiles con sistemas de alta criticidad que difcilmente pueden estar fuera de operacin por un periodo largo de tiempo y consideramos que deben ser tomadas en cuenta para sistemas de esta ndole.
Tcnica Blue-Green deployment. La idea de esta tcnica es tener dos versiones idnticas de nuestro ambiente de produccin (servidores, configuracin, base de datos, etc.). En una de estos ambientes permanece la versin actual de la aplicacin (verde) y en el otro ambiente (azul) se deploya la nueva versin que queremos liberar. Basta hacer un cambio en la configuracin de la red para direccionar a una u otra aplicacin.
Tcnica del canario en la mina de carbn. Esta tcnica hace referencia al uso que se les daba antiguamente a estas aves como alarmas de la toxicidad en las minas de carbn. Los canarios eran llevados al fondo de la mina junto con los mineros y al ser animales muy susceptibles al monxido de carbono o al metano, su muerte era una seal de alarma para que los mineros desalojaran la mina. En el deployment de software se usa esta analoga para una tcnica que consiste en liberar una nueva versin a un nmero limitado de usuarios mientras que el grueso de los usuarios sigue accediendo a la versin estable. Esta tcnica permite detectar rpidamente los posibles problemas y minimiza el impacto a un grupo pequeo y controlado de usuarios.
7. Anlisis Costo-Beneficio
8. Conclusin En la presente propuesta se han dado a conocer una serie de blueprints tanto para el diseo como para la construccin y liberacin de sistemas de software, las cuales fueron tomadas principalmente de casos de xito, otras metodologas y libros de entidades representativas en el desarrollo y liberacin de software.
Las practicas aqu recomendadas se supone sean utilizadas, en todas las fases de la creacin del sistema. Creemos que el uso apropiado de estas practicas ayuda a reducir los riesgos de liberar un sistema incapaz de satisfacer las necesidades por las cuales fue concebido, adems de reducir en gran medida el tiempo dedicado a la fase de liberacin.
9. Referencias [1] Jez Humble, David Farley, Continuous Delivery, Addison Wesley, 2010 [2] Michael T. Nygard, Release It! Design and Deploy Production-Ready Software, The Pragmatic Bookshelf, 2007 [3] QuarkSoft , Checklist para Pre-anlisis, Mxico D.F., 2003 [4] QuarkSoft , Formato para Monitoreo de Recursos Crticos de Computadora, Mxico D.F., 2003 [5] QuarkSoft , Forma Estrategia (STRAT), versin 2.5.6, Mxico D.F., 2002 [6] QuarkSoft , Estndar Template SPMP, versin 1.5, Mxico D.F., 2001 [7] QuarkSoft , Estndar Template SDP, versin 1.3, Mxico D.F., 2002 [8] QuarkSoft , Gua para la Generacin y Uso de Prototipos, versin 1.0, Mxico D.F., 2003 [9] QuarkSoft , Template de Plan de Pruebas, versin 1.3, Mxico D.F., 2003 [10] QuarkSoft , Gua Metodolgica de Diseo de Alto Nivel y Detallado, versin 1.2, Mxico D.F., 2003 [11]QuarkSoft , Descripcin y Gua de Seleccin de Ciclos de Vida de Software, versin 1.0, Mxico D.F., 2003 [12] Rational Software Corporation , Rationa Unified Process Documentation, http://www.ts.mah.se/RUP/RationalUnifiedProcess/ [13] Scott Ambler, Effective Software Deployment, 1999, http://drdobbs.com/architecture-and- design/184415760?cid=Ambysoft [14] Scott Ambler, The Agile End of Game, 2007, http://drdobbs.com/architecture-and- design/198800565?pgno=1 [15] Scott Ambler, System Deployment Tips and Techniques, 2005, http://www.ambysoft.com/essays/deploymentTips.html [16]John Birtley, Agile Deployment Best Practices for Risk-Free Deployment, 2004
10. Apndices
A. Problemas Identificados en MidasSistema X
Problema Causas Al realizar el despliegue de la aplicacin sobre el App. Server Oracle Weblogic no levant la aplicacin debido a problemas del server para interpretar las interfaces de EJB 3.0 La definicin del App. Server no se estableci desde el inicio del proyecto. Fuimos early adopters de EJB 3.0 ya que la especificacin tena algunos meses de haber sido liberada y apenas unos pocos App. No contamos con las licencias de la ltima versin de Weblogic que introdujo la primera implementacin de EJB 3.0 Se inici el desarrollo y las primeras pruebas sobre JBoss app. Server (que tambin tena una implementacin de EJB 3.0) basados en la premisa de que todos los application servers se basan en una misma especificacin. El ambiente de desarrollo y el ambiente de integracin no era semejante al que se esperaba tener en produccin. Seleccin tecnolgica Nuestra propuesta original se basaba en una seleccin tecnolgica orientada a cubrir con los requerimientos de performance bajo las restricciones de infraestructura del cliente (anchos de banda limitados) y por ello descartamos el uso de una aplicacin web. Sin embargo hubo pugnas internas (Cliente) para optar por la aplicacin web argumentando que se mejorara la infraestructura de red y que de acuerdo a un experto de BEA, una arquitectura JSF/Ajax con EJB y JPA consumira el mismo ancho de banda que la aplicacin 4GL actual. No tuvimos elementos suficientes para rebatir la decisin del cliente ya que a pesar de que se hizo una prueba de concepto y se realizaron algunas pruebas de capacidad, el ambiente de dichas pruebas no era ni remotamente cercano al ambiente de NMP. No contamos con herramientas ni expertise suficiente como para hacer pruebas punto a punto que sirvan como un sustento cuantitativo confiable al momento de tomar este tipo de decisiones Al intentar crear la estructura de la BD en Informix a partir de un DDL creado a partir de una herramienta de exportacin ocurrieron mltiples errores No contamos con herramientas organizacionales para el mapeo de E-R a DDL. Se utiliz la herramienta Embarcadero con licencia apcrifa. Las pruebas de unidad de componentes terminados comenzaron a fallar en el ambiente de integracin continua por mapeos y tipos de datos que no haban sido probados en Informix. El ambiente de desarrollo utilizaba MySQL en lugar de Informix. El arquetipo estaba diseado para crear la BD y el set de pruebas sobre MySQL por cuestiones de simplicidad y limitaciones de algunos equipos de desarrollo. Idea equivocada de que el cdigo es independiente de la BD y que las diferencias entre una BD y otra radican slo en parmetros de configuracin. En el ambiente pre-operativo del cliente las transacciones no se podan ejecutar. La configuracin del esquema de buffering de la base de datos no era compatible con las transacciones de la aplicacin. No se llev un control adecuado de las configuraciones necesarias de la BD para poder operar. No existe un procedimiento o mecanismo adecuado para replicar de manera consistente un ambiente o configuracin de los sistemas que soportan la aplicacin (SO, RDBMS, LDAP, etc.) El mecanismo de autenticacin contra el directorio de usuarios no funcion la primera vez que se instal en un ambiente de pruebas del cliente. No se cont con un ambiente de pruebas previo (QS) de integracin/sistema que fuera lo ms cercano posible a la realidad. Las integracin de la aplicacin sobre el servidor a utilizar (Oracle Weblogic) fueron muy tardas, lo que ocasion problemas de configuracin no previstos. Al realizar el despliegue de la aplicacin sobre un cluster de Weblogic ocurrieron problemas con la serializacin de objetos entre la capa de presentacin y el backend cuando la peticin era atendida por un nodo distinto al que origin la peticin. A pesar de que en la teora la opcin de separar las capas (front-end y back-end) como aplicaciones independientes era posible a travs de la invocacin remota de los EJBs, hubo problemas debido al uso de una librera (cglib) que se utiliz para generar proxys de ciertas clases para la ejecucin de bsquedas dinmicas. Aunque se contempl la posibilidad de desplegar la aplicacin bajo este esquema, nunca se hicieron pruebas. No se hicieron pruebas de integracin/sistema sobre ambiente clusterizado. No se replic el ambiente del cliente para pruebas por falta de hardware y licencias. Problemas de lentitud y con los dispositivos de impresin. Ancho de banda limitados a 128kb y 256kb Una mala configuracin en la aplicacin la cual hacia un consumo excesivo en el ancho de banda. No se haba considerado la compresin de datos Applets que se descargaban en cada peticin del cliente (debido a una configuracin errnea)Una mala configuracin en recursos que deben residir del lado del cliente Cambio en las versiones del navegador, se realizaron pruebas en una versin y en produccin se tena otra versin. Inicialmente no se implement algn esquema de caching a nivel aplicacin. Liberaciones con defectos de lgica Pruebas unitarias e integrales deficientes, aunque existe mucho cdigo de pruebas, no es funcional y no prueba exactamente lo que tiene que probar, esto se debe principalmente a que los ingenieros que desarrollan las pruebas, no tienen idea que probar. Revisiones e inspecciones deficientes. Falta de mantenimiento al set de pruebas unitarias. Algunas pruebas unitarias comenzaron a fallar y muchas de ellas terminaron comentadas. Ambientes de prueba no homologados. En ocasiones no era posible reproducir algunos errores por diferencias en los ambientes de prueba lo que ocasionaba que se cerraran equivocadamente issues al no poder reproducirse cuando en realidad el problema prevaleca. Deficiencias en el equipo de desarrollo. A los ingenieros que se identificaba que no eran buenos codificando, se les asign la tarea de realizar/ejecutar las pruebas considerando que era una tarea tcnicamente menos compleja. La estrategia tampoco funcion ya que su falta de habilidad tcnica llev a que las pruebas no fueran tiles o representativas. Las pruebas de sistema no fueron automatizadas y por tanto la ejecucin de los escenarios era propensa a fallas u omisiones. Escenarios de pruebas de sistema insuficientes o limitados. Programadores inexpertos o simplemente malos programadores. Uso inadecuado del servidor de integracin continua. Inexistencia de un plan de release/deployment que estableciera un procedimiento que pudiera garantizar la validez de cada release. Uso deficiente del mecanismo de control de versiones. Frecuentemente se suba cdigo que no se encontraba probado o listo para produccin. No se contempl un protocolo o procedimiento para probar el nuevo deploy (lo que se conoce como smoke tests). Lo ms que se probaba era que todos los nodos respondieran y que se presentara en cada uno la pantalla de login y si acaso ingresar con un usuario. Nuevas versiones del cdigo que no estaban sincronizadas con cambios en la BD o viceversa Problemas de comunicacin entre los miembros del equipo. No haba un canal adecuado para informar al resto del equipo sobre cambios al esquema de la BD que pudieran afectar al cdigo existente. Carencia de un protocolo o procedimiento sistemtico para realizar un deploy. Carencia de mecanismos para replicar configuracin o estado de la BD de manera sistemtica y controlada. No se versionaron los scripts de la BD ni se versionaron los releases. De esta forma es imposible llevar un control sobre la compatibilidad entre versiones de releases y BD. El deploy del sistema debe incluir todos los elementos o sistemas subyacentes y no nicamente el cdigo de la aplicacin. Mientras el deploy de un sistema no se considere como un TODO que integre todas las posibles variables el problema va a persistir. Deficiencia en el mecanismo de rastreabilidad del cdigo (componentes). No fue posible mantener al da la matriz de rastreabilidad y aunque se hubiera mantenido, por el tamao del proyecto y el nmero de componentes hubiera sido complicado utilizarlo ya que el formato en si no se presta para el manejo de tantos componentes. Al realizar una auditora de la aplicacin mediante una herramienta de profiling se estableci que los tiempos de respuesta no eran aceptables. Cdigo no optimizado (e.g. Llamadas redundantes, ciclos sin break points) Configuracin de Hibernate y naturaleza de hibernate provocan cierto overhead en la aplicacin. Falta de una solucin para caching a nivel aplicativo. Problemas con los filtros en la capa web. Se tenan filtros de ms y algunos no eran los ms eficientes. No se cuenta con una estrategia/herramienta para realizar un profiling de la aplicacin desde una etapa de pre-produccin en la que se puedan realizar pruebas de estrs que permitan identificar umbrales para definir la capacidad real de la aplicacin, as como identificar los posibles cuellos de botella y determinar si pueden ser solventados. Ya en produccin se utiliz una herramienta con una licencia temporal y en un ambiente en el que la capacidad del hardware disponible limitaba las pruebas a 15 sesiones concurrentes. Falta de capacitacin, guas o scripts para realizar pruebas de capacidad, se carece de documentacin de las experiencias de otros equipos en sistemas similares, falta de una base de conocimiento que concentre las experiencias de todas las aplicaciones que se desarrollan en QS. Lentitud en el sistema y cadas frecuentes de uno o ms nodos de la aplicacin. Configuracin no optimizada del clster. La cantidad de memoria para la mquina virtual de Java era menor a la recomendada por los expertos de Oracle. No existe mucha informacin disponible al pblico sobre las recomendaciones o mejores prcticas para la configuracin de Weblogic. No contamos en QS con expertos o partnerships de los servidores de aplicaciones comerciales ms utilizados (Oracle WL e IBM Websphere). No hay una base de conocimiento sobre configuraciones y mejores prcticas. No se cont con un ambiente de pruebas similar al productivo donde poder realizar pruebas de capacidad y establecer escenarios de estrs con condiciones semejantes a los momentos pico de la operacin normal. Liberaciones con errores de configuracin Procedimiento de deployment no completamente automatizado. Dependa de la presencia del experto en deployment, lo que indicaba que el procedimiento requera de pasos manuales. Inicialmente requera de modificaciones manuales (direcciones IP) para apuntar a recursos del ambiente productivo lo cual era propenso a errores. No existe una cultura organizacional que promueva la automatizacin el deployment de manera que sea un proceso repetible y auditable. Carencia de un plan de deployment que contemple todas las partes variables de la aplicacin (no nicamente el cdigo). Carencia de set de pruebas para verificar el deployment (smoke tests). Este set de pruebas se enfoca especficamente en probar que todos los recursos utilizados por la aplicacin estn disponibles, que la aplicacin responda en todas las instancias existentes, se prueban las conexiones a BD, Ldap, sistemas externos, balanceadores, etc. Mecanismos de monitoreo insuficientes o limitados. Problemas con el equipo de soporte y administracin de la infraestructura Falta del ejercicio de governance de parte del cliente. Al ser dos empresas (QS y HP) contratadas por el cliente con contratos de servicio especficos cada uno velaba por sus propios intereses y prioridades. Problemas para regresar a una versin previa del deploy de manera rpida y sistemtica No se tena una estrategia formal para identificar/versionar los releases. No se generaba un control de releases, no se utilizaban tags para marcar cada release, no se documentaba cada uno de los releases con informacin de los cambios (fixes, features, etc.) ni se llevaba un control de etiquetacin (labeling) de cada release. Como mecanismo de control al hacer un deploy nuevo se tomaba el EAR anterior y se renombraba con la fecha del da en que se reemplazaba, sin embargo el mecanismo era propenso a errores adems de que la versin se guardaba compilada y no haba forma de relacionarla con una versin concreta del cdigo. Tampoco haba garanta de que no fueran borradas por error. Ineficacia ante errores en el ambiente productivo. No se contaba con un ambiente de pruebas con las mismas condiciones (configuraciones, versin del cdigo) y datos del ambiente productivo que estuviera ejecutndose a la par del ambiente productivo. Dificultad para levantar ambientes de pruebas. Generalmente no estaban levantados y para replicar los errores era necesario primero identificar y generar la versin del cdigo que correspondiera a la versin productiva y luego levantar todo el ambiente para iniciar las pruebas. No exista un catlogo de usuarios de pruebas para todos los roles para poder ingresar con el rol correcto y replicar el error. Dificultad para reproducir el error de manera rpida. Muchas ocasiones la opcin mas rpida y efectiva para reproducir el error era levantar el ambiente de prueba apuntando a la BD y LDAP productivos, lo cual no es por mucho una buena prctica. En casos extremos se ingresaba a la aplicacin productiva para replicar el error (a veces con autorizacin del usuario y a veces sin su autorizacin). No haba plan de accin, slo reaccin. Errores o problemas por accidentes al ejecutar sentencias de SQL Al no tener en muchos casos forma de arreglar alguna incidencia mediante la aplicacin, se proceda a modificar la BD productiva directamente, con todos los riesgos que esto conlleva. directamente sobre la BD productiva Debido a problemas de lentitud muchas veces se proceda a realizar actualizaciones de manera masiva ya que los usuarios no podan hacerlo desde la aplicacin por lentitud o errores del sistema. Solicitudes de informacin que no se podan consultar desde la aplicacin porque no fueron requeridas desde un inicio pero la demanda de los usuarios nos obligaba a realizarlas. Falta de regulaciones y protocolos para realizar este tipo de operaciones. El cliente pareca acostumbrado a trabajar de esta manera, sin embargo nos vimos arrastrados por esa inercia y terminamos cayendo en las mismas prcticas. Errores y omisiones con la ejecucin de procesos masivos (crones) No eran procesos 100% automatizados, requeran de la ejecucin y en algunos casos de la configuracin manual. Deficiencia en la definicin del alcance de los crones. Nos enfocamos en definir y entender el funcionamiento, pero obviamos detalles importantes acerca de las condiciones de ejecucin y las variables que pudieran afectar su periodicidad. Las condiciones de ejecucin podan variar de manera diaria. Algunas de estas condiciones iban ms all de los requerimientos originales Algunos procesos no tenan una periodicidad fija sino que simplemente se ejecutaban cuando el cliente decida que era oportuno de acuerdo a regulaciones internas. Al ser una operacin manual era frecuente que alguien olvidara ejecutar alguno de ellos o que fueran ejecutados cuando no era necesario o que fueran ejecutados y posteriormente se recibiera una orden de omitir una o varias sucursales. No existan condiciones o regulaciones que permitieran o facilitaran la automatizacin completa de los procesos nocturnos. No existan mecanismos automatizados que permitieran deshacer los cambios realizados por un proceso masivo (cron). Muchas ocasiones fue necesario revertir algn proceso masivo y en todos los casos se haca mediante ejecuciones de updates masivos directamente a la base de datos en horas de operacin. No se contempl la necesidad de revertir la ejecucin de estos procesos. No se identific como un requerimiento del cliente, sin embargo se convirti en un requerimiento del rea de soporte. Falta de regulacin en los procedimientos y normatividad para la ejecucin de los procesos masivos (crones). Muchas veces se omitan por diversas causas y las notificaciones no eran oportunamente enviadas al equipo de soporte o no se enviaban por un medio formal, en ocasiones era simplemente una orden verbal. Con el crecimiento de la base de datos y el nmero de sucursales migradas, los procesos masivos (crones) comenzaron a extender su tiempo de ejecucin y a salir de las ventanas de tiempo establecidas. La implementacin de los acumulados no fue la planeada sino una solucin temporal debido a retrasos en el desarrollo y obligados por la necesidad de contar con la funcionalidad en produccin. Uso ineficiente del lenguaje de stored procedures de informix (SPL). Falta de pruebas de estrs de los crones con condiciones similares a las productivas. Falta de expertise en el lenguaje SPL o de algn experto que validara el uso eficiente del lenguaje Dificultad para consultar errores en el log de la aplicacin El log se enviaba a archivos de texto plano y por cada nodo del cluster se generaba un archivo. El primer problema era adivinar en qu archivo se haba registrado el error que se buscaba. El crecimiento de los archivos de log era muy acelerado. Inicialmente tenamos acceso abierto para consultarlo directamente en el servidor, sin embargo para abrir el archivo poda tardarse varios minutos y el procesamiento del archivo repercuta en el uso del procesador del servidor productivo. Encontrar los errores en archivos tan grandes era una tarea difcil sobre todo si no se sabe qu buscar. Uso inadecuado de los niveles de logueo a nivel del cdigo. Muchos de los registros del log eran comentarios a nivel informativo que se usaron para pruebas unitarias o de integracin y que no tenan cabida en el ambiente productivo. Mal manejo de excepciones. Mensajes de error incongruentes o poco descriptivos, errores que no incluan la traza del error original, cdigos que se tragaban la excepcin (no la relanzaban ni la manejaban). Configuracin inadecuada de los niveles de logueo. Inicialmente se generaban registros a nivel de debug y se incluan mensajes de frameworks como hibernate que hacan crecer muy rpido los archivos. No se previ una estrategia para unificar el logueo a nivel del cluster o para centralizar el registro en un repositorio comn. Inicialmente no se contemplaron otros mecanismos para registrar ciertos tipos de errores a nivel aplicacin para que fuera ms sencillo consultarlos. Con el incremento gradual de usuarios se presentan problemas espordicos en los clculos de cobros y pagos. Deficiencias en la programacin que evidencian un desconocimiento de los ciclos de vida de los objetos. No se realizaron pruebas de concurrencia. No se tiene la prctica de identificar desde el HLD aquellos componentes crticos que requieren de pruebas especializadas y de un desarrollo cuidadoso. La asignacin de componentes es resultado ms de un procedimiento de optimizacin de tiempos y recursos que de un anlisis cuidadoso de la complejidad de cada componente y de la experiencia de cada ingeniero del equipo. Este tipo de errores es difcil que se detecten en etapas tempranas ya que las pruebas de unidad e integracin generalmente se enfocan en la funcionalidad y no en probar el comportamiento de la aplicacin con carga y accesos concurrentes. No se cuenta con herramientas institucionales para llevar a cabo este tipo de pruebas.
B. Aciertos Identificados en MidasSistema X
Aciertos Resultados Se gan la confianza total del sponsor del proyecto La comunicacin entre el lder de proyecto (y el resto del equipo) y el sponsor de proyecto siempre fue clara y transparente. El sponsor del proyecto se convirti en un aliado del equipo de desarrollo y en momentos complicados del proyecto soport la presin de su lado para que el equipo continuara trabajando. Se tena informacin oportuna y de primera mano de todas las situaciones que pudieran afectar el desarrollo del proyecto La confianza y disposicin del sponsor fueron muy importantes para lograr obtener toda la informacin y recursos necesarios para la continuidad del proyecto Involucrar a miembros del equipo de desarrollo en la etapa de transicin a MidasSistema X como parte del equipo de soporte en sitio El equipo tuvo retroalimentacin de primera mano del los usuarios finales de la aplicacin se tuvo la oportunidad de ver la aplicacin ejecutndose en el ambiente operativo Al conocer y ver de cerca la operacin real se obtiene informacin muy valiosa que muy difcilmente se comprende en su totalidad al leerla en un documento como el SRS Mayor comprensin de las necesidades y problemas que viven los usuarios da a da Se identifican ms fcilmente problemas de usabilidad que de no identificarse posteriormente pueden reportarse por los usuarios de manera inadecuada como problemas de performance. Se entiende y se adquiere el sentido de urgencia e importancia que los usuarios tienen al solicitar ayuda del equipo de soporte Factorizacin de cdigo. Hubo componentes que se detectaron con deficiencias y se tom la decisin de asignar tiempo para redisearlos en lugar de simplemente parchar el cdigo Cdigo ms limpio y legible y por lo tanto ms sencillo de administrar Mejoras en funcionamiento y/o performance Divisin del equipo en grupos con responsabilidades especficas. Cada grupo se enfoc a resolver los problemas que tena bajo su responsabilidad sin ser agobiados por los problemas de otro grupo (e.g. el grupo de soporte no se preocupaba de corregir los defectos que salan y el grupo responsable de la correccin no se preocupaba si en una sucursal no podan operar por algn problema con el ambiente productivo) Con el tiempo cada grupo logr un buen nivel de eficiencia en lo que haca. Contar con el apoyo de expertos en la configuracin y puesta a punto del servidor de aplicaciones (Weblogic) Aportaron su experiencia y conocimiento para configurar de la mejor manera el ambiente productivo del cluster del servidor de aplicaciones Trabajaron de manera muy cercana a un representante del equipo de desarrollo de manera que el ambiente y la configuracin giraran en torno a las caractersticas de la aplicacin. Cambiar la estrategia de deployment de nuevos releases utilizando una sucursal piloto. El impacto de defectos en la nueva versin solo repercuta en una sucursal. Minimizacin del riesgo de afectar la operacin diaria Menor presin para los grupos de soporte y correccin de defectos al liberar una nueva versin Mayor certeza de la calidad de los releases una vez que se liberaban a produccin Involucrar al rea de mantenimiento e infraestructura en los deployments de la aplicacin Se les deleg la responsabilidad de realizar las operaciones necesarias para deployar la aplicacin Se restringi el acceso al equipo de desarrollo a los servidores, liberndolos de la responsabilidad de operarlos, monitorearlos o mantenerlos funcionando Se libr al equipo de desarrollo de cualquier responsabilidad en el caso de cadas de los servidores o configuraciones que afectaran la aplicacin Involucrar a todas las reas responsables de los recursos alrededor de la aplicacin en la etapa de migracin de sucursales Los das de migracin deba estar disponible al menos un responsable de cada rea para atender cualquier incidencia relacionada a su rea Se tena ms confianza al hacer las migraciones sabiendo que estaba alguien disponible para apoyar en el momento en que se requiriera De alguna manera todos se responsabilizaban de las migraciones y no era un proceso exclusivo del equipo de desarrollo. Cambio de estrategia en la migracin de datos utilizando Stored Procedures en lugar de ETL Se redujo notablemente el tiempo de migracin/conversin de datos Permiti la migracin de las sucursales ms grandes que no hubieran sido posibles con ETL en las ventanas de tiempo disponibles Permiti la reanudacin de la migracin en el caso de que se presentara algn error, se correga y se continuaba desde el ltimo registro procesado. Realizar pruebas de capacidad llevadas a cabo por un evaluador externo Se obtuvieron muchas observaciones y puntos de mejora Al ser un evaluador imparcial y ajeno al proyecto la evaluacin es ms amplia y detallada ya que no se encuentra restringida por ideas o prejuicios La entidad externa es especialista en este tipo de evaluaciones y cuenta con las herramientas apropiadas para llevar a cabo su labor Al ser ajeno al proyecto evit o aminor los constantes enfrentamientos o tensiones entre el equipo de desarrollo y el personal de infraestructura/operaciones Las observaciones dieron pie a muchas correcciones y ajustes a la configuracin y el cdigo de la aplicacin que mejoraron notablemente el desempeo general de la aplicacin. Dio pie para que el equipo de desarrollo comenzara a utilizar una herramienta similar para estresar la aplicacin y encontrar nuevos cuellos de botella Se genera mayor confianza hacia el equipo de desarrollo conforme se van solucionando los problemas encontrados. El hecho de que el evaluador sea externo es algo que fortalece en mayor medida el grado de confianza hacia la aplicacin. Involucrar al experto en Informix del lado del cliente para realizar auditoras de la BD Se obtuvieron algunas observaciones que ayudaron a mejorar o corregir algunos Stored procedures Se obtuvieron algunos puntos de mejora Se involucr a los responsables de mantenimiento e infraestructura del cliente en el mantenimiento y mejora del esquema de datos. Se dio oportunidad al cliente de verificar el diseo y estructura de la BD Al ver que las observaciones no eran tan graves tambin se genera una mayor confianza en el equipo de desarrollo Contar con un contrato de soporte del servidor de aplicaciones (oracle weblogic) La atencin de los issues reportados era atendida de manera casi inmediata Es un recurso importante para el equipo de desarrollo con el que puede contar en caso de alguna eventualidad Al cliente le da la confianza de que cualquier problema relacionado con el servidor de aplicaciones est garantizada su solucin Incluir a ciertos arquitectos desde etapas tempranas, tales como requerimientos y diseo de alto nivel. Tener un completo contexto de la regla de negocio, as como un claro entendimiento de las necesidades del cliente, lo cual le dio una gran confianza al cliente. Proporcionar una mejor ayuda a los ingenieros de desarrollo al explicarles con mayor claridad la funcionalidad de cada uno de los componentes.
C. Experiencias
Big Design Up Front (BDUF) vs. Diseo Incremental
Algo que fue particularmente difcil durante la fase de HLD de MidasSistema X fue realizar un diseo completo de la aplicacin en una sola fase/etapa. Cabe mencionar que el diseo original entregado en el documento de HLD sufri muchos cambios posteriores debido en parte a la premura de entregar el documento y tambin a aspectos no considerados en un inicio. Por defecto PSP/TSP se toma como un proceso de desarrollo en cascada y por ello cada fase debe culminarse en su totalidad antes de iniciar con la siguiente. En sistemas pequeos o medianos puede resultar adecuado, sin embargo con sistemas de mayores dimensiones el riesgo que se asume es proporcional al tamao del sistema. Los promotores de metodologas giles consideran el BDUF un anti-patrn argumentando el alto costo en tiempo y esfuerzo y la poca validez que puede tener un diseo basado en demasiados supuestos. Nosotros consideramos que eEs indispensable iniciar el desarrollo con una definicin clara en trminos de diseo de lo que se va a hacer, pero con estrategia basada en el diseo incremental como se describe en [11] mediante la identificacin de mdulos funcionales con cierta independencia para tener varias iteraciones completas de HLD-Code-Test. En la primera iteracin se llevara a cabo un esfuerzo importante para definir toda la estructura principal de la aplicacin, todos los elementos comunes que requieran ser definidos de inicio e incluir tambin el diseo del primer mdulo funcional. Con esto se llevaran a cabo ciclos completos de desarrollo (Design, Code, Test) y al final de cada ciclo se puede tener un entregable funcional que puede ser implantado en un ambiente preproductivo para ser probado e incluso evaluado por el cliente sin tener que esperar hasta el final de todo el proyecto y llevarse la sorpresa de que el sistema no cumple con los requisitos por los cuales fue concebido.
Integracin Continua
La prctica de la Integracin Continua (CI) no tiene mucho tiempo en QuarksoftLa Empresa y un problema que hemos detectado es que no se ha transmitido de forma efectiva el propsito de usar una herramienta de CI. En MidasSistema X utilizamos la herramienta de CI (Bamboo) pero eso no signific que realmente practicramos la Integracin Continua por lo que el uso de la herramienta result en ms problemas que beneficios. Inicialmente configuramos Bamboo para hacer una o dos ejecuciones diarias, al menos una al final del da. Muy pronto comenzaron a fallar las ejecuciones y comenzamos a recibir las notificaciones de falla. Al principio nos encargbamos de buscar el error y corregirlo, pero pronto nos dimos cuenta que apenas se suba la versin corregida, alguien ms suba un nuevo cambio que volva a romper el build. Debido a esto se tom entonces la decisin de forzar la ejecucin del build en Bamboo cada vez que se subiera un cambio al repositorio con el propsito de obligar a los ingenieros a hacerse responsables de sus cambios. En realidad esta prctica debe ser la ideal para practicar CI, sin embargo es indispensable que el equipo entienda el concepto de CI o el resultado puede ser contraproducente como lo fue en nuestro caso. Con la nueva configuracin comenzamos a recibir infinidad de notificaciones de fallas en los builds ya que se seguan subiendo cambios que rompan el build y aunque se intent seguir corrigiendo los problemas result muy complicado debido a que se continuaban subiendo cambios sobre la versin defectuosa. Como resultado dejamos de hacer caso a las notificaciones de Bamboo por un buen tiempo (varias semanas e incluso meses) y continuamos con el desarrollo. La conclusin a la que podemos llegar ahora es que la prctica de ejecutar el build con cada nuevo cambio no era mala, el error estuvo en nuestra actitud y falta de entendimiento de CI. Es evidente tambin que existe otro problema de fondo en nuestras pruebas unitarias, muchos creemos que las pruebas son solo para cumplir con el proceso ms que para garantizar la calidad del componente desarrollado, es por ello que no le damos la suficiente importancia como para garantizar que cada componente desarrollado vaya acompaado de un conjunto de pruebas efectivas que prueban cada bloque de cdigo y sus bifurcaciones. Esta experiencia nos indica que de poco sirve tener una herramienta de CI si no nos preocupamos por entender la importancia de las pruebas y su repercusin directa en la calidad del producto final.
Control de Versiones
Durante el desarrollo de MidasSistema X intentamos utilizar varias tcnicas con el uso del SVN para mejorar nuestra productividad aunque con resultados no tan satisfactorios. Inicialmente todos subamos nuestros cambios al trunk, pero conforme se incrementaban los commits, se incrementaban tambin los problemas con los builds del trunk. Las ejecuciones de Bamboo comenzaron a fallar con mucha frecuencia y se tom la decisin de utilizar un branch para el desarrollo de cada componente (tcnica conocida como branching by feature), as cada ingeniero poda subir sus cambios sin afectar el cdigo en el trunk. Pronto nos dimos cuenta que est tcnica conllevaba un problema importante; al momento de terminar el componente, el ingeniero deba incorporar sus cambios al trunk mediante un merge. El problema con esta tcnica es que si el branch se mantiene fuera de sincrona con el trunk por mucho tiempo, el procedimiento para reincorporarlo se vuelve muy complicado ya que requiere de mayor tiempo y esfuerzo del ingeniero para realizarlo. Con esto no pretendemos decir que hacer un branch no est bien, sino que hay que analizar bien la situacin para determinar la opcin que otorgue el mayor beneficio a largo plazo. Otra tcnica que intentamos usar fue la de cerrar el trunk durante ciertos lapsos en los que se requeran hacer pruebas de sistema. Se avisaba a todos los ingenieros que durante cierto periodo se prohiban hacer incorporaciones al trunk para que no afectaran las pruebas. La intencin era buena, sin embargo en este caso si creemos que hay mejores formas de hacerlo como la creacin de un tag o un branch que en este caso si hubiera podido utilizarse sin la complicacin del merge.
Automatizacin de Pruebas de Sistema
En MidasSistema X tuvimos la buena intencin de automatizar las pruebas de sistema con una herramienta para simular las interacciones de un usuario desde el front-end, sin embargo por la premura que se viva en aquel momento para terminar la aplicacin y liberarla, el equipo designado para llevar a cabo las pruebas se vio limitado en tiempo y capacidad tcnica para automatizarlas y se tom la decisin de realizarlas de manera manual. Como resultado de esa decisin tuvimos que lidiar con las siguientes consecuencias: Conforme se iban agregando ms funcionalidades, el set completo de pruebas iba extendiendo su tiempo de ejecucin. Una o dos personas tardaban varias horas en ejecutar todos los escenarios. El proceso de pruebas comenz a depender de las personas que se volvieron expertas en ejecutar las pruebas. Si alguno de los expertos llegaba a ausentarse, la ejecucin de las pruebas no poda llevarse a cabo. El proceso manual era propenso a errores u omisiones. En ms de una ocasin se liberaron versiones con errores que debieron ser detectados en las pruebas de sistema. Los ingenieros que ejecutaban las pruebas dedicaban prcticamente todo su tiempo a las pruebas y por ello no podan apoyar en otras actividades. La recomendacin es que siempre que sea posible automatizar las pruebas de sistema debemos hacerlo. Cada proyecto es distinto y por eso es tarea conjunta del arquitecto y el lder de proyecto definir la estrategia de pruebas desde un inicio.
La importancia del ambiente de pruebas
Normalmente en QuarksoftLa Empresa no se le presta demasiada importancia a los ambientes de pruebas y en muchos casos las pruebas de sistema se llevan a cabo sobre los mismos equipos de desarrollo. Creemos que el ambiente de ejecucin realmente impacta en los resultados de las pruebas y que en la medida en que se le de mayor importancia a los ambientes de ejecucin, las liberaciones van a tener un grado mayor de certidumbre. MidasSistema X es un buen ejemplo de las consecuencias que se viven cuando no se tiene un cuidado adecuado de los ambientes de ejecucin. Durante el desarrollo nunca contamos con la disponibilidad de un ambiente de pruebas de sistema adecuado. Aunque se solicit un ambiente de pruebas con caractersticas especficas, ste no pudo ser proporcionado por nuestra rea de GSTAC por lo que las pruebas se llevaron a cabo en un equipo que no contaba con las caractersticas del servidor requerido y que ni siquiera fue proporcionado por QuarksoftLa Empresa. Cuando lleg el da de instalar MidasSistema X por primera vez en un ambiente productivo no logramos pasar ms all de la pantalla de login. No habamos considerado las configuraciones necesarias para establecer una comunicacin correcta con el directorio de usuarios para realizar el proceso de autenticacin. Tan solo esa configuracin nos tom un par de das y noches. Ese fue el primero de varios obstculos que encontramos antes de ver la aplicacin ejecutndose en el ambiente productivo. Basta decir que desde ese primer intento de implantar la aplicacin en el ambiente productivo hasta el inicio de las pruebas piloto pasaron varias semanas.
Pruebas de Requerimientos No Funcionales
Este es uno de los puntos que deben ser mayormente reforzados en QuarksoftLa Empresa mediante una combinacin de guas metodolgicas y herramientas de monitoreo y automatizacin de pruebas. Con MidasSistema X no se hicieron pruebas de capacidad previas a su puesta en produccin. Dado que la liberacin ocurri de manera gradual, inicialmente no se observaban problemas de desempeo con un nmero reducido de usuarios y las que se observaron se atribuyeron en su momento a problemas con la red de transmisin de datos. Conforme se fue incrementando el nmero de usuarios se empez a evidenciar algn problema con el desempeo de la aplicacin y ante nuestra poca capacidad para demostrar cuantitativamente lo contrario, NMP se decidi involucrar a un auditor externo que se apoy en una herramienta para medir el desempeo de nuestra aplicacin. Como resultado de la auditora se identificaron puntualmente varios cuellos de botella que estaban afectando el desempeo de la aplicacin. Solo despus de esta experiencia comenzamos a utilizar una herramienta similar para continuar haciendo pruebas por nuestra cuenta y seguir optimizando la aplicacin.
Pruebas de Deployment
Este tipo de pruebas ni siquiera es mencionado o considerado dentro de nuestros procesos, sin embargo por experiencia sabemos que este set de pruebas es de gran importancia durante el proceso de liberacin. La intencin principal de estas pruebas es detectar oportunamente problemas con la versin a liberar antes de que los usuarios puedan accesarla. En MidasSistema X no tenamos un set automatizado de pruebas de deployment ni un script formal de este tipo de pruebas, sin embargo por lo general se llevaban a cabo pruebas manuales que consistan en ingresar mediante el navegador a cada uno de los nodos del cluster y verificar que estaban respondiendo de manera adecuada. Igualmente se probaba el acceso a travs de la URL que apuntaba al balanceador de cargas y verificar que responda correctamente. Por ltimo se ingresaba a la aplicacin con algn usuario en cada uno de los nodos lo cual nos permita corroborar la correcta interaccin con el directorio LDAP y con la base de datos. Este set de pruebas, aunque limitado, constitua nuestras pruebas de deployment y en algunas ocasiones nos permiti detectar problemas con anticipacin suficiente para corregirlas o dar marcha atrs al deployment. La gran desventaja de no haber tenido un set formal de pruebas de deployment automatizado era que su ejecucin quedaba a juicio del responsable de desarrollo que validaba el deployment. Las pruebas eran manuales y por tanto propensas a omisiones y al no formar parte formal del proceso de deployment no siempre se llevaban a cabo. De ah la importancia que nosotros vemos en generar un Plan de Liberacin y de automatizar en la medida de lo posible tanto el deployment como las pruebas.
El factor humano
Un aspecto fundamental para el xito de MidasSistema X fue sin duda obtener la confianza total del sponsor de la aplicacin desde antes del inicio del proyecto. Gracias a esta confianza se presentaron condiciones favorables para el desarrollo y posterior implantacin del sistema. Por ello consideramos que es de vital importancia para el proyecto lograr una identificacin temprana de todas las personas involucradas de alguna forma con la aplicacin e involucrarlos desde el inicio para preparar el terreno y lograr una colaboracin adecuada. En el caso de MidasSistema X no todas las condiciones fueron favorables. Intereses polticos al interior de NMP y el involucramiento de proveedores externos en la administracin de todos los servidores y del desarrollo y mantenimiento de aplicaciones complicaron en muchos momentos el proceso de liberacin. Es normal encontrar resistencia de reas internas que pueden generar conflictos debido a que cada grupo responde a intereses distintos. No pretendemos dar una solucin para este problema tan complejo, pero si queremos resaltar la importancia de las interacciones personales en el xito de la liberacin de un producto de software. Existe un movimiento dentro de la comunidad de desarrollo de software llamado DevOps que presenta algunos principios y prcticas para lograr una colaboracin de todos los involucrados en la liberacin de un producto de software. No pretendemos que QuarksoftLa Empresa adopte estos principios, pero si destacar que sin duda la colaboracin y la dinmica social son una preocupacin creciente en la industria del desarrollo de software y por ello consideramos que debemos comenzar a darle mayor importancia a este tema estableciendo algunas estrategias y guas que faciliten esta interaccin. La mayora de los que laboramos en QuarksoftLa Empresa hemos tomado el curso de Semiologa y en mayor o menor medida tenemos la capacidad de identificar los rasgos principales de cada tipo de persona. Sera interesante documentar los perfiles de todas las personas del lado del cliente involucradas durante el desarrollo y liberacin de la aplicacin como una referencia interna para entender a cada persona y estar preparados para actuar de acuerdo a su personalidad.
La tcnica del Canario en la Mina de Carbn (Un detalle ms completo de la tcnica)
Esta tcnica consiste en liberar una nueva versin a un nmero limitado de usuarios mientras que el grueso de los usuarios sigue accediendo a la versin estable. El uso de dicha tcnica permite detectar rpidamente los posibles problemas y minimiza el impacto a un grupo pequeo y controlado de usuarios. Esta tcnica se aplic con xito para MidasSistema X. La tcnica no se plane desde un inicio sino que se utiliz como plan de contingencia a partir del crecimiento del nmero de sucursales/usuarios que usaban la aplicacin. Al incrementar los usuarios se incrementaba el impacto de liberar nuevas versiones defectuosas. Por ello se decidi tener un servidor alterno en el que se liberaba la nueva versin y que era accedido solamente por una de las sucursales mientras el resto de las sucursales continuaba accediendo al servidor principal con la versin estable. De esta manera la sucursal piloto se convirti en nuestro canario en la mina de carbn. Idealmente estas y otras tcnicas similares deben planearse desde el inicio del proyecto con el fin de minimizar los riesgos al liberar nuevas versiones del software.
Estrategia de Capacitacin
La capacitacin es un tema contemplado por nuestros procesos, sin embargo no existen muchas guas en cuanto a la ejecucin o a las tcnicas que pueden ser usadas para facilitarla. En el caso de MidasSistema X la capacitacin involucr toda una logstica muy particular ya que la distribucin geogrfica de los usuarios estaba determinada por la ubicacin de las ms de 200 sucursales de NMP en todo el pas. La estrategia parti de una implantacin gradual en la que la aplicacin se liberaba en un nmero reducido de sucursales cada semana. La transicin se haca los fines de semana a partir de los viernes cuando se enviaba personal de soporte a la aplicacin para preparar y configurar los equipos y dar la capacitacin al personal de la sucursal durante el fin de semana. A partir del lunes se iniciaba la operacin de esas sucursales en la nueva aplicacin y el personal de soporte se mantena en sitio durante dos das ms para apoyarlos durante esta transicin y resolver cualquier problema de manera inmediata. Esta estrategia dio buenos resultados y adicionalmente permiti a algunos miembros del equipo de desarrollo participar como capacitadores en sitio durante el proceso de implantacin. Las ventajas que vemos en involucrar al equipo de desarrollo en esta actividad son: El equipo tuvo retroalimentacin de primera mano del los usuarios finales sobre la aplicacin. Se tuvo la oportunidad de observar el desempeo de la aplicacin ejecutndose en el ambiente operativo. Al conocer y ver de cerca la operacin real se obtiene informacin muy valiosa sobre el negocio y sobre la dinmica de los usuarios en la operacin real. Mayor comprensin de las necesidades y problemas que viven los usuarios en el da a da. Se identifican ms fcilmente problemas de usabilidad que de no identificarse posteriormente pueden reportarse por los usuarios de manera inadecuada como problemas de desempeo. Al involucrarnos en la dinmica del negocio se entiende y se adquiere el sentido de urgencia e importancia que los usuarios tienen al solicitar ayuda del equipo de soporte.
D. Anlisis de herramientas
Generadores de carga: Un generador de carga permite simular picos de carga sobre servidores, redes u otros objetos, permitiendo as encontrar facilmente cuellos de botella en las aplicaciones.
JMeter (Apache): Carga y ejecucin de pruebas en diferentes tipos de serivdores (Web, SOAP, DB, LDAP, JMS, MAIL, etc) Portabilidad, ya que es 100% java Grabacin de flujos mediante un macro Construccin de flujos mediante los parmetros del GET / POST Permite realizar un anlisis de manera grafica del resultado de las pruebas ejecutadas Silkperfomer (Borland): Lo mismo que el anterior pero de manera ms amigable Soporte Web 2.0 (Flash, Flex, Silverlight, Ajax y HTML) Modelo de pruebas hibridas (ya sea en local o en la nube) Integra el diagnostico de la causa raz del problema
Profilers Hoy en da las aplicaciones han ido cambiando, a tal grado de tener aplicaciones distribuidas, virtualizadas, clusterizadas, etc. Por lo que desarrolladores, reas de calidad y hasta los dueos del negocio tienen que trabajar de manera conjunta para poder maximizar el valor del negocio. De lo anterior es difcil liberar una aplicacin, sin problemas de desempeo, consumos mnimos de anchos de banda, cuellos de botella, optimizacin de algoritmos entre otras cosas. Abajo se muestran las caractersticas de algunas herramientas que ayudan en la solucin de problemas de este tipo.
JConsole (Oracle, OpenSource) JConsole es una herramienta de monitoreo, la cual hace un completo uso de JMX sobre la Maquina Virtual para extraer informacin de desempeo y consumo de recursos de las aplicaciones que estn corriendo sobre la plataforma Java.
Principales caractersticas: Tiempos de procesamiento en CPU Medicines de memoria en el sistema En general da una idea de cmo se comporta la mquina virtual (comportamiento de GC, Threads) Dynatrace (Comercial) No intrusivo al cdigo pero si al Application Server. Requiere modificacin de scripts de arranque Deteccin y aislamiento de problemas de forma sencilla y rpida Acta de forma similar a un debugger remoto Proporciona toda la informacin sobre rbol de invocacin, tiempos de ejecucin de mtodos, querys ejecutados. Permite graficar el tiempo que se tarda cada framework (porcentajes) Vista de threads, comportamiento, consumo de memoria, etc... Interfaz amigable al usuario final.
JProfiler (Comercial) Muy parecido a Dynatrace pero menos legible e intuitivo Excelente soporte para JEE Tiempos que hay dentro de calls de rbol de invocacin Monitoreo de CPU y memoria Es extensible (Permite la creacin de profilers personalizados de acuerdo a las necesidades) Mnimo overhead Permite detectar facilmente cuellos de botella Mucho mas barata que Dynatrace
Yourkit Monitoreo de CPU y Memoria Monitoreo sobre demanda Libre distribucin en produccin (DLL) Completo soporte para J2E y .NET Soporte para Java 5, 6 y 7 Licencias comerciales y open source
Automatizacin de pruebas TestMaker Automatizacin de pruebas de integracin Permite correr pruebas en ambientes grid y en la nube Soporta Ajax, SOA, RIA, Flex, Flash y REST Construccin de pruebas de forma sencilla (grabado para aplicaciones web, herramienta grafica para construccin de pruebas SOA/REST ,soporte para pruebas escritas en Java, Jython, Ruby y cualquier lenguaje dinamico de scripting) Integracin con Maven Open Source (Versin libre y versin Pro de paga) Monitoreo de CPU, deteccin de Memory leaks Corre en cualquier plataforma (Linux, Mac, Windows) Soporte para cualquier navegador comercial (IE, Firefox, Chrome y Opera)