Actualización del software asociado a un sistema empresarial real en Django

ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA DEL SOFTWARE Actualización del software asociado a un sistema empresarial real en Django Software updating associated with a real business system in Django Realizado por Javier Vázquez Burgos Tutorizado por Gerardo Bandera Burgueño Departamento Arquitectura de Computadores UNIVERSIDAD DE MÁLAGA MÁLAGA, Noviembre 2014 Fecha defensa: El Secretario del Tribunal Resumen: El objetivo del TFG es ejectuar y documentar el proceso de actualizaci´on de un sistema software real de car´acter empresarial, perteneciente a la empresa dedicada a las transacciones de divisas Foreign Exchange Solutions SL. El sistema est´a implementado en Python 2.7 usando el framework de desarrollo r´apido de aplicaciones web Django que, comenzando por su versi´on 1.3.1, terminar´a al final del proyecto en la versi´on 1.4.10, lo que nos llevar´a a tener que actualizar todas las librer´ıas relacionadas, adem´as de mejorar la calidad del c´odigo e incluso cambiar la estructura del proyecto, prestando adem´as especial atenci´on a la pruebas unitarias y de regresi´on para comprobar el correcto funcionamiento del sistema a lo largo del desarrollo. Todo esto con el fin de conseguir las nuevas funcionalidades y caracter´ısticas que una versi´on m´as nueva nos ofrece, adem´as de mejorar la calidad de la aplicaci´on -aumentar la reutilizaci´on del c´odigo y reducir futuros errores gracias a un c´odigo m´as sencillo y legible-, aumentar el rendimiento, y obtener una buena cobertura de pruebas. Usaremos adem´as la metodolog´ıa ´agil Scrum, el SGBD PostgreSQL, adem´as de otras herramientas como Solr, ElasticSearch, Redis, Celery o Mercurial para el control de versiones. Palabras claves: Python, Django, Actualizaci´on, Pruebas, Documentaci´on, PostgreSQL, Scrum Abstract: The objective of the TFG is to execute and to document the process of updating of a real entrepreneurial software system, belonging to Foreign Exchange Solutions SL, company engaged in currency transactions. The system is implemented in Python 2.7 using the rapid development framework Django for web applications that, starting in version 1.3.1, until the end of the project in version 1.4.10, which will lead us to have to update all related libraries, and also to improve code quality and even change the structure of the project, paying special attention to the unit and regression tests to verify the correct operation of the system throughout the development. All this in order to get new features and functionality that a new version offers, besides improving the quality of implementation -increase code reuse and reduce future errors thanks to a simple and legiblecode, increase the performance and get a good coverage tests. Also will use the agile methodology Scrum, the PostgreSQL DBMS, and other tools like Solr, ElasticSearch, Redis, Celery or Mercurial for version control. Keywords: Python, Django, Update, Tests, Documentation, PostgreSQL, Scrum ´ Indice Lista de Acr´onimos I 1. Introducci´on 1 1.1. Introducci´on................................... 1 1.2. Objetivos .................................... 2 2. Situaci´on Inicial 3 2.1. LaCompa˜n´ıa .................................. 3 2.2. Aplicaciones................................... 4 2.3. Procesodedesarrollo.............................. 7 2.4. Porqu´eScrum ................................. 10 2.5. L´atex....................................... 11 3. Estudio inicial y pruebas de regresi´on 13 3.1. EstudioInicial.................................. 13 3.2. Pruebasderegresi´on .............................. 14 3.3. Otrastareas................................... 16 3.4. Alfinal...................................... 17 4. Hacia Django 1.3.7 21 4.1. Introducci´on................................... 21 4.2. Tareasrealizadas ................................ 21 4.3. Progreso..................................... 22 i 5. Mejorando BOS 25 5.1. Introducci´on................................... 25 5.2. Tareasrealizadas ................................ 25 5.3. SalidaaProducci´on............................... 28 5.4. Progreso..................................... 29 6. Django 1.4 31 6.1. Introducci´on................................... 31 6.2. Tareasrealizadas ................................ 31 6.3. Progreso..................................... 35 7. Django Desencadenado 37 7.1. Introducci´on................................... 37 7.2. Tareasrealizadas ................................ 37 7.3. Progreso..................................... 40 8. Finalizando el Proyecto 43 8.1. Introducci´on................................... 43 8.2. Tareasrealizadas ................................ 43 8.3. Progreso..................................... 45 9. Conclusi´on 47 9.1. Resumen..................................... 47 9.2. Posiblesmejoras................................. 48 9.3. Balancefinal................................... 49 Referencias 51 A. Documentos adjuntos 53 ii Acr´onimos BOS Back Office System BOS API BOS Application Programming Interface EBO Ebury Online BDU BOS Django Update BSD Berkeley Software Distribution DRY Don’t Repeat Yourself Fx-Solutions Foreign Exchange Solutions S.L. FOREX Foreign Exchange Market FX Foreign Exchange Market SGBD Sistema Gestor de Bases de Datos TDD Test Driven Development XP eXtreme Programming QA Quality Assurance LTS Long Term Support iii iv Cap´ıtulo 1. Introducci´on 1.1. Introducci´on Hoy en d´ıa la velocidad con la que se dan los avances tecnol´ogicos es cada vez mayor, motivo por el que tanto las empresas como los particulares se ven con la necesidad, incluso obligaci´on en muchos casos, de seguir el ritmo de esta evoluci´on tecnol´ogica. Esto conlleva poner al d´ıa el software y hardware de un sistema, lo que puede incluir solucionar fallos o incluir nuevas funcionalidades. Se ha de diferenciar entre dos tipos de actualizaciones: actualizaci´on funcional, que consiste en a˜nadir nuevas funcionalidades a las ya existentes, y actualizaci´on t´ecnica, consistente en instalar una nueva versi´on de software. Es com´un en la actualidad, aunque cada vez menos, dar prioridad a la funcionalidades, sin prestar demasiada atenci´on a ciertos aspectos como la calidad del c´odigo, lo adecuado del software o t´ecnicas usadas, e incluso a la correcta documentaci´on, debido principalmente a la prisas de tener un producto funcionando. Tarde o temprano, esto conlleva un proceso de actualizaci´on que puede resultar m´as costoso que el hecho de usar buenas t´ecnicas durante el desarrollo del producto. Por lo general, el proceso de actualizaci´on comienza con un estudio previo del sistema con el objetivo de descubrir cuales son las carencias del mismo, como pueden ser m´odulos obsoletos o ilegibles. Posteriormente, y sabiendo ya cuales son los puntos d´ebiles, estudiar los diferentes procesos de mejora, con el fin de elegir aquel m´as econ´omico, r´apido y, sobretodo, factible. Finalmente se lleva a cabo el proceso de migraci´on, una serie de 1 Cap´ıtulo 2. Situaci´on Inicial Figura 2.2: Diagrama con el funcionamiento de Scrum Reuni´on de inicio (Sprint Start), al comienzo de cada sprint para decidir que tareas estimar la duraci´on de las tareas, aclarar el contenido y distribuirlo. Reuni´on de revisi´on (Sprint Review), en mitad y al final del sprint para ver como ha terminado y los problemas que han surgido. Reuni´on de demostraci´on (Sprint Demo), en donde se muestra al Product Owner el producto final de ese sprint. La organizaci´on llevada puede ser observada en las imagen 2.2. Hemos de entender que cuando estamos en la semana 1, estamos la semana -2 del siguiente sprint, es decir, sprint draft y empezar a planearlo; adem´as coincidir´ıa con la semana en la cual se sacar´a a producci´on el sprint anterior. Cuando estemos en la semana 2 del actual sprint, estaremos en la semana -1 del pr´oximo sprint, y deber´ıan de quedar cerradas las tareas que se van a realizar en la pr´oxima semana; fijemonos que si todo ha ido bien el anterior sprint debe haber gfinalizado ya. Cuando sea la semana siguiente volver´ıamos a la situaci´on inicial. Pueden parecer demasiadas reuniones, pero se ha de intentar agilizar su duraci´on -con medidas como tener la reuni´on de piey sirve para estar todos los afectados por el sprint constantemente informados de la evoluci´on del mismo, lo que nos aporta muchas ventajas, como la posibilidad de corregir r´apidamente en caso de error. Adem´as es constante el intercambio de correos y llamadas entre los desarrolladores y los Product Owners en el caso de que no sea posible el encuentro f´ısico entre ellos. Adem´as usamos ciertas t´ecnicas adoptadas de otras metodolog´ıas, como por ejemplo Test Driven Development (TDD)[12]: metodolog´ıa proveniente de eXtreme Program8 Cap´ıtulo 2. Situaci´on Inicial ming (XP)[13], consistente en la realizaci´on de las pruebas antes del propio desarrollo del c´odigo y la funcionalidad, teniendo en cuenta de antemano aquellas situaciones que nuestra implementaci´on ha de superar. Podemos comentar tambi´en el uso regular de la refactorizaci´on, del uso de pruebas autom´aticas y de integraci´on continua. Estos desarrollos adem´as han de ser coordinados con los dise˜nadores, el equipo QA y el de sistemas. Por un lado tenemos a los dise˜nadores, quienes no tienen siempre relaci´on con todos los proyectos, pero en el caso de que sea as´ı, debe asistir tambi´en a las reuniones de definici´on con el fin de comprender las nuevas funcionalidades y poder dise˜nar los nuevos estilos y gestionar la distribuci´on visual de los elementos con el fin de una usabilidad ´optima. Por otro lado tenemos al equipo de QA, quien tambi´en debe asistir a todas las reuniones y cuyo trabajo consiste en definir los diferentes tests unitarios que han de desarrollar posteriormente los desarrolladores -no olvidemos que seguimos la metodolog´ıa TDDy los tests de aceptaci´on que ellos mismos har´an posteriormente, ya sea con Selenium [14] -herramienta para la automatizaci´on de pruebas directamente sobre el navegador, b´asicamente es un script con una serie de pasos que se van a seguir y una serie de respuestas que se van a recibiro manualmente; la ventaja del primer m´etodo es que el automatizar las pruebas sirve para su posterior utilizaci´on como tests de regresi´on y el poder ejecutarlos repetida y r´apidamente una vez implementados. El equipo de QA es el encargado de dar el visto bueno al proyecto y quien dictamina si este sale a producci´on o es necesario la correcci´on de errores, el cambio de funcionalidades o la realizaci´on de m´as pruebas antes de ser un producto v´alido para ser lanzado. Finalmente est´a el equipo de sistemas[15], encargado de distintas tareas: por un lado se encarga de la configuraci´on de los diferentes entornos de despliegue -equipos dedicados para cada uno de los diferentes grupos, donde es desplegado tanto BOS como EBO as´ı como los diferentes servicios necesarios-, y por otro lado se encarga de sacar el proyecto una vez finalizado a preproducci´on (staging) -entorno similar al de producci´on en donde se prueba durante una semanay posteriormente sacarlo definitivamente a producci´on. Las labores tanto de QA como de los SysAdmin son muchas m´as de las aqu´ı descritas, pero me he limitado ´unicamente a aquellas que participan activamente con el trabajo de los desarrolladores. Para el control de versiones usamos Mercurial[16]. Tenemos ramas tanto para producci´on como para preproducci´on, adem´as de la correspondiente rama por cada uno de los 9 Cap´ıtulo 2. Situaci´on Inicial proyectos en curso y otra para funciones de soporte. Contamos adem´as con Jenkins[17], aplicaci´on web para la integraci´on continua que nos permite desplegar autom´aticamente los diferentes entornos y ejecutar los tests cuando se suben cambios al repositorio, adem´as de otras muchas caracter´ısticas. Ya hemos explicado las diferentes metodolog´ıas y herramientas usadas durante el proceso de desarrollo, por lo que ya solo queda ir explicando la evoluci´on del proyecto a lo largo de los diferentes sprints hasta tener totalmente funcional BOS con la versi´on 1.4.1 de Django. 2.4. Por qu´e Scrum En muchas ocasiones es cierto el dicho de ’Renovarte o morir’ y nunca mejor que aplicado al hecho de tener que actualizar el sistema, y esta vez no va a ser menos hablando de Scrum. Existen multitud de metodolog´ıas para eligir, pero ciertamente Scrum es la m´as usada y recomendada hoy en d´ıa para la mayor´ıa de los desarrollos -tenemos un art´ıculo muy interesante por parte de dos investigadores de Microsoft hablando de las virtudes de esta metodolog´ıa [18]- y para el proceso de actualizaci´on de un s´ıstema m´as a´un. El hecho de poder ir paulatinamente realizando pruebas (o incluso antes gracias al TDD, algo muy lejos del t´ıpico desarrollo en cascada) junto al desarrollo, poder cambiar especificaciones, e incluso sacar versiones del producto no final pero funcional, es una ventaja demasiado abrumadora respecto a las antiguas metodolog´ıas. Llegado el momento es hora de eligir entre Scrum o XP, las dos metodolog´ıas ´agiles de moda, y es entonces cuando llegamos a la pregunta: ¿Por qu´e no ambas? Esta fue la opci´on elegida por nosotros, tener lo mejor de ambas y descartando aquellas opciones que no se adaptan o no son compatibles con el desarrollo. En nuestro caso rechazamos la idea de XP de programar por parejas, ya que aunque es una buena t´ecnica que ahorra bastantes errores, en ese momento la empresa no dispon´ıa de tantos recursos. Para ampliar conococimiento sobre el uso coordinado de ambas metodolog´ıas, recomiendo ’Scrum y XP desde las trincheras’[19]. 10 Cap´ıtulo 2. Situaci´on Inicial 2.5. L´atex Este documento describe todo el proceso seguido para llevar a buen puerto el proyecto, y por supuesto para ello nos vemos obligados a hablar de las distintas herramientas que usamos para programar, controlar las versiones, controlar la calidad, etc. Y por esta raz´on no podemos olvidarnos de Latex, ya que tiene un papel protagonista en todo esto permiti´endonos generar este documento. Latex es b´asicamente un sistema de edici´on de textos, pero enfocado a presentar una alta calidad tipogr´afica, siendo extensamente utilizado en art´ıculo y libros cient´ıficos por parte de f´ısicos, matem´aticos o ingenieros [20]. El motivo de su potencia es el estar constituido por comandos TeX (lenguaje con acciones muy elementales). Adem´as es de c´odigo abierto, lo que lo hace propenso a recibir librer´ıas de parte de la comunidad -al igual que Django-. Lo que diferencia a Latex de un editor normal como puede ser LibreOffice, es que mientras en estos ves lo que escribes, en Latex te centras ´unicamente en el contenido, para luego dar formato al texto mediante etiquetas. 11 Cap´ıtulo 2. Situaci´on Inicial 12 Cap´ıtulo 3. Estudio inicial y pruebas de regresi´on Comenzamos el proyecto con un primer sprint, llamado Authentic Adder, con dos objetivos claramente diferenciados, por un lado estudiar el estado actual del sistema y de sus librer´ıas y los potenciales cambios a realizar, y por otro lado comenzar a hacer test unitarios que nos servir´an en el futuro para las pruebas de regresi´on. Adem´as nos instalamos el sistema y todas las dependencias y comenzamos a usar Jira y SonarQube [21]. La duraci´on de un an´alisis inicial puede variar bastante dependiendo del impacto del proyecto y de los miembros a cargo, si bien en nuestro caso fue de tres semanas. 3.1. Estudio Inicial Respecto al estudio inicial se tuvieron en cuenta dos temas principalmente: Librer´ıas: Se elaboraron varios documentos excel para evaluar las diferentes librer´ıas usadas, as´ı como los cambios necesarios y su posible repercusi´on. El principal de estos documentos podemos verlo en la imagen 3.1 -de manera parcial-, y en el podemos ver una lista con las librer´ıas de Django y de Python usadas, as´ı como la versi´on inicial y a que versiones era necesario actualizarnos en caso de que fuese posible. Sobre ciertas librer´ıas aparec´ıa poca informaci´on en la web por lo que tuvimos que comprobar su correcto funcionamiento en posteriores sprints. Usamos un sistema de colores bastante intuitivo: verde si no es necesaria ninguna 13 Cap´ıtulo 3. Estudio inicial y pruebas de regresi´on actualizaci´on, naranja en el caso de que si sea necesaria una actualizaci´on, amarillo si no es necesaria actualizar la librer´ıa pero si cambiar el c´odigo, y rojo si la librer´ıa no es compatible. Tenemos un caso m´as curioso en color fucsia: esta librer´ıa es una copia de una funcionalidad de Django 1.4 que no existe en 1.3 y como nosotros la necesit´abamos depend´ıamos de ella, si bien una vez actualizados a la 1.4 podremos dejar de usarla para comenzar a trabajar con la nativa de Django. Pruebas (Tests): Es importante planear cuales son las pruebas a realizar y la prioridad, pues por tiempo y recursos es imposible tener analizado el sistema con un 100 % de cobertura, y por ello es necesario decidir que pruebas haremos y cuando. Adem´as es importante cubrir el mayor porcentaje de cobertura posible lo m´as pronto posible, por lo que es cr´ıtico elegir bien las pruebas. B´asicamente se cre´o un excel con distintas p´aginas, la primera de ellas un cola con las url de las p´aginas a probar, y el resto de hojas era un resumen por aplicaciones de urls probadas y urls por probar. La idea era ir haciendo poco a poco pruebas sobre las urls de la cola, si bien al final no llegaron a realizarse muchas de ellas. 3.2. Pruebas de regresi´on Respecto al tema de las pruebas se realizaron tres tareas principalmente: En primer lugar se instal´o una aplicaci´on llamada SonarQube para medir la calidad del c´odigo y extraer informes sobre el estado inicial de BOS, el cual podemos ver en el anexo 1, si bien en la imagen 3.2, tenemos un fragmento donde se muestra un reparto de las l´ıneas de c´odigo en las distintas aplicaciones. Esta informaci´on se usar´a al final del proyecto para ver las mejoras. Obtuvimos informaci´on muy variada, desde el n´umero de l´ıneas - 233.465 lineas totales y 185.232 l´ıneas de c´odigo -, pasando por el n´umero de archivos -1025y clases -851-, por c´odigo duplicado -21 %-, as´ı como por el porcentaje de comentarios -7.1 %- y por la complejidad, adem´as de un an´alisis de la distribuci´on del c´odigo. En segundo lugar se cre´o una rama Regression a partir de Default (el c´odigo de producci´on), rama en la que se comenzar´a a hacer los test que el sistema debe pasar despu´es de las modificaciones. Finalmente se comenz´o a hacer los tests unitarios. En esta etapa se hizo pruebas del login, de la vista de inicio de BOS y de las vistas de inicio de las principales secciones -en Django se llama vista a lo que en Modelo Vista Controlador se llama 14 Cap´ıtulo 3. Estudio inicial y pruebas de regresi´on Figura 3.1: Estudio de las librer´ıas dependientes 15 Cap´ıtulo 3. Estudio inicial y pruebas de regresi´on Figura 3.2: Dimensi´on de BOS por aplicaciones controlador-. B´asicamente eran pruebas sin demasiado nivel de detalle que ´unicamente comprobaban que al entrar en estas direcciones estando logueados y con los permisos pertinentes, pod´ıamos acceder correctamente y recibir sin problemas los templates - los templates en Django ser´ıan equivalentes a la cl´asicas vistas en MVC, archivos html con c´odigo empotrado-. 3.3. Otras tareas Aparte de las tareas anteriormente descritas: Por un lado se creo la rama BDU a partir de la rama Default. En esta rama se comenzar´an a realizar todos los cambios propios de proyecto y peri´odicamente se traer´an los tests hechos en Regression para ir comprobando que todo funciona bien. Esto conlleva adem´as la instalaci´on del sistema en local, es decir: descargar los fuentes, crear un entorno virtual para Django 1.3.1 en donde instalarnos todas las dependencias, adem´as de descargar la base de datos y los ´ındices y prepararlos. Un entorno virtual sirve para poder tener en una misma m´aquina diferentes versiones de las dependencias simult´aneamente, b´asicamente lo que hacemos es activar el entorno virtual -al que llamamos bdu env - y proceder a instalar todas las dependencias -las dependencias son todas aquellas librer´ıas de las que depende la aplicaci´on 16 Cap´ıtulo 3. Estudio inicial y pruebas de regresi´on Figura 3.3: Captura de Jira mostrando el tabl´on de Scrum para funcionar correctamente, como por ejemplo tener instalado Python 2.7, Django 1.3.1 o Celery -, de manera que mientras tengamos este entorno virtual activo estaremos usando estas librer´ıas, pero en el momento en que salgamos o cambiemos a otro entorno estaremos usando otras distintas, pudiendo as´ı cambiar f´acilmente de un proyecto a otro. La herramienta usada para esta tarea es VirtualEnv y realmente es fundamental para casi cualquier desarrollo en Python. M´as adelante comenzamos a usar tambi´en VirtualEnvWrapper, herramienta que nos permite cambiar r´apidamente de un entorno a otro con un simple comando ”workon [nombre del entorno]”. Por otro lado se empez´o a limpiar el proyecto, eliminando todo el c´odigo comentado o que ya no se usa -tarea dif´ıcil, y a´un as´ı despu´es de esto segu´ıan quedando demasiadas funciones duplicadas o por las que no se pasaba nuncay aquellos comentarios que no aportaban nada. Durante este sprint y empezando varias semanas atr´as comenzamos con el estudio tanto de Python y Django como del resto de librer´ıas y herramientas a utilizar, as´ı como de BOS, pues el conocimiento sobre la mayor´ıas de las ´areas necesarias era bastante escaso. 3.4. Al final Al final de este sprint tuvimos cierto retraso, adem´as de un ligero descontrol, originado por los siguientes motivos: 17 Cap´ıtulo 4. Hacia Django 1.3.7 24 Cap´ıtulo 5. Mejorando BOS 5.1. Introducci´on En un tercer sprint, llamado Crazy Cobra, y con una duraci´on de dos semanas - aqu´ı el tiempo si que es completamente variable, dependiendo de la cantidad de recursos que quieras dedicar a la mejora del sistema o continuar el proceso de actualizaci´on lo m´as pronto posible-, a˜nadimos algunos de los cambios disponibles tras actualizar Django a la versi´on 1.3.7, refactorizamos los tests para disminuir el tiempo de ejecuci´on y de desarrollo de los mismos, creamos nuevas pruebas, comenzamos a usar Jenkins como sistema de integraci´on continua, adem´as de traernos la rama default para no permanecer desactualizados, acci´on que tendremos que realizar continuamente a lo largo de todo el desarrollo. Finalmente corregimos tambi´en algunos errores, pues al termino de este sprint se saco a producci´on una versi´on estable de BOS actualizado a la 1.3.7. Despu´es de esto ya quedaba el ´ultimo y m´as dif´ıcil empuj´on: actualizarnos a Django 1.4.1. 5.2. Tareas realizadas Entremos en detalle en el trabajo realizado: Uni´on(merge) con default: un merge consiste en unir dos ramas distintas de c´odigo. Puede parecer menos importante de lo que en realidad es, pero en cualquier desarrollo en el momento en el que existen varias ramas y est´an empiezan a alejarse puede 25 Cap´ıtulo 5. Mejorando BOS llegar a complicarse el unirlo en un futuro, por lo que es importante ir trayendo los cambios continuamente para evitar problemas m´as adelante. Refactorizaci´on de tests: la inexperiencia hizo que en un principio los tests fuesen m´as ineficientes de lo necesario, pero sobretodo que estuviesen bastante desordenados. Una de las cosas m´as importantes que se hizo en este ´ambito fue la creaci´on de funciones gen´ericas para la creaci´on de mommies, f´acilmente reciclables y extensibles por los programadores, lo que aument´o el posterior rendimiento del desarrollo. Empezamos a usar marcadores adem´as para ejecutar los tests que nos interesa: podemos marcar los tests m´as lentos de manera que si es necesario una comprobaci´on r´apida podemos ejecutar ´unicamente lo tests m´as r´apidos. Creaci´on de nuevos tests: nos enfocamos sobretodo en la creaci´on de tests de Haystack, pues era un cambio muy delicado y cr´ıtico, adem´as la librer´ıa se usa en muchas partes y un fallo en una consulta puede ser muy costoso. Nuevos cambios: tuvimos que dedicar mucho tiempo a estudiar los nuevos cambios de esta versi´on tanto en el anterior como en este sprint, para saber distinguir correctamente la importancia e impacto de estos cambios, y saber de que forma proceder. Nos encontramos ante 3 tipos diferentes de cambios: •Por un lado cambios de funcionamiento de Django, mejoras ante las que no tenemos que hacer nada. Por ejemplo mejorar la seguridad ante los ataques de Cross-site scripting, o el aumento de formularios inline (formularios dentro de formularios) a 1000. •Por otro lado tenemos aquellos cambios o actualizaciones que afectan a funciones o caracter´ısticas que no usamos, o nuevas caracter´ısticas que decidimos no meter. Por ejemplo tenemos que se evitaron ataques DOS en la subida de im´agenes cuando estas son excesivamente grandes, aunque no era un problema que nos preocupase pues no ofrecemos servicio de subida de im´agenes; o el cambio de su parseador XML, ya que nosotros usamos una librer´ıa externa para esto. •Por ´ultimo tenemos aquellos cambios que forzosamente nos obligan a hacer modificaciones de c´odigo, ya sea por cambio de funcionalidad o de uso, o por eliminaci´on de la funci´on y tener que buscar una alternativa. Aunque en este sprint no nos enfrentamos a ninguna tarea de este tipo, en el siguiente sprint y por el mayor cambio de versi´on si que tuvimos importantes cambios en el c´odigo. 26 Cap´ıtulo 5. Mejorando BOS Figura 5.1: Captura Jenkins mostrando la pantalla principal de un proyecto Integraci´on continua: comenzamos a establecer las pautas a seguir para el correcto desarrollo y posterior puesta a punto. Para ello comenzamos a usar Jenkins, el cual como ya hemos dicho es un sistema de integraci´on continua, y que nos proporciona diversas funcionalidades, de las que podemos destacar: ejecuci´on autom´atica de los tests cada vez que hay cambios en el repositorio, y as´ı nos aseguramos de no romper nada cada vez que hay un cambio (confianza que va aumentando seg´un aumenta la cobertura y el n´umero de pruebas); y por otro lado permite tambi´en automatizar los despliegues en los diferentes servidores de desarrollo y producci´on. Todo esto lo hace con una interfaz amigable y f´acil de usar, de manera que nos permite ver f´acilmente si hay tests ejecut´andose, cuales fallaron la ´ultima vez, llevar un seguimiento de los resultados en el tiempo o reiniciar el servidor con solo un click -imagen 5.1-. Adem´as cada equipo comienza a tener un QA asignado, quien se encarga de gestionar Jenkins, de dise˜nar los tests de aceptaci´on y tests unitarios que hemos de implementar, y de hacer las pruebas funcionales y manuales correspondientes. Volviendo a la imagen, pasemos a describir brevemente lo que vemos. La pantalla nos muestra una visi´on general sobre los tests ejecutados ´ultimamente sobre el proyecto BDU, del cual podemos ver como en la ´ultima ejecuci´on hemos tenido 5 fallos. A la derecha tenemos una gr´afica sobre el resultado de los tests a lo largo del tiempo: el color azul determina los tests ejecutados y el color rojo los tests fallados; adem´as a la izquierda tambi´en podemos ver el resultado de los ´ultimos tests juntos con algunos detalles. Existen otras opciones, como configurar el proyecto, lanzar los tests o ver los ´ultimos cambios en el repositorio. 27 Cap´ıtulo 5. Mejorando BOS Release (salir a producci´on): una vez hecho todo lo anterior y comprobado que no hay bugs y que el funcionamiento es el correcto, procedemos a pasar el c´odigo a la rama de preproducci´on. En esta rama est´a el c´odigo durante aproximadamente una semana antes de pasar a producci´on. Este ´ultimo paso lo suele hacer el equipo de sistemas, si bien es com´un que haya uno de los desarrolladores que trabajo en el proyecto por si hay alg´un problema de ´ultima hora. 5.3. Salida a Producci´on Hablemos m´as detalladamente sobre el proceso de sacar a producci´on un proyecto nuevo. A la hora de publicar un desarrollo nuevo son distintos los enfoques que se le suele dar seg´un la empresa y el tipo de producto, ya que no es lo mismo una herramienta de uso interno a una herramienta p´ublica en la web, ni es lo mismo una sencilla p´agina est´atica a una aplicaci´on que de servicio a otras o que se encargue de tareas ininterrumpibles. Por lo general suele ser interesante no cortar el servicio ofrecido en ning´un momento, pero no siempre es posible. En el caso de modificar ´unicamente archivos est´aticos es tan sencillo como subir los nuevos al servidor y listo, pero si se requiere cambios en la l´ogica o incluso en lo modelos, la cosa cambia. Una opci´on que se suele contemplar en estos casos es la de apuntar la url a otro servidor de manera temporal, y una vez actualizado nuestro servidor principal, volver a redireccionar bien. En nuestro caso, si el cambio es solo de c´odigo no hay problema, se actualiza el c´odigo y se reinicia el servidor, pero en el caso de que los modelos cambian y haya que modificar la base de datos no podemos simplemente cambiar la url, pues lo cambios que se hagan en los datos en este tiempo no constar´an en nuestro servidor principal una vez completada la actualizaci´on, adem´as estamos ante un proceso que puede alargarse bastante en el tiempo. En nuestro caso la opci´on que solemos tomar es, que en caso de que sea sencillo el cambio -cambiar ficheros est´aticos, o c´odigo sencillose hace un reinicio del servidor a ´ultima hora cuando ya nadie est´a haciendo uso del servicio. El problema es en el caso de que el proceso sea m´as complicado, ya sea por cambios en los modelos o por la necesidad de probar el c´odigo si es complejo, propenso a errores o las funcionalidad es muy prioritaria; pues esto nos llevar´ıa a tener que invertir tiempo en probar todo, adem´as de tener que hacer una copia de la base de datos y tener tiempo para restaurar el sistema si hay alg´un problema. En este caso la opci´on elegida es sacar 28 Cap´ıtulo 5. Mejorando BOS Figura 5.2: Burndown Chart del tercer sprint el proyecto el Viernes a ´ultima hora, ya que al ser una aplicaci´on de uso interno, no es usada durante el fin de semana, y nos da tiempo tanto para probar con seguridad, como para maniobrar correctamente en caso de necesidad. 5.4. Progreso Al finalizar este sprint ten´ıamos BOS en producci´on actualizado con todos los cambios realizados hasta ahora en el proyecto. La cobertura de los tests aument´o un 2 % hasta un 26 %. Podemos ver en la imagen 5.2 el Burndown Chart de este sprint, en el cual ya vemos como el trabajo comienza a funcionar mejorar, y ´unicamente vemos dos desviaciones puntuales por alg´un error que fue solucionado inmediatamente. 29 Cap´ıtulo 5. Mejorando BOS 30 Cap´ıtulo 6. Django 1.4 6.1. Introducci´on Hagamos un peque˜no balance de nuestro estado actual: nos hemos actualizado y lanzado a producci´on una versi´on estable de BOS con Django 1.3.7, actualizando para ello todas las librer´ıas y dependencias; hemos comenzado con la realizaci´on de tests unitarios hasta cubrir un 26 % de c´odigo; hemos comenzado a usar Jenkins como herramienta de integraci´on continua, adem´as del nuevo apoyo de QA con los tests manuales; y finalmente podemos decir que durante el camino hemos adquirido mucho conocimiento, desde programar con Python y Django, pasando por el uso de metodolog´ıas de prueba, hasta llegar al aumento del trabajo en equipo, en parte fomentado por Scrum y su desarrollo ´agil. En el tercer sprint de nuestro proyecto, llamado Dutiful Dugite, de dos semanas de duraci´on -llegados a este punto la divisi´on de los sprints no es tan importante, si bien era posible hacer dos sprint de dos semanas, como en nuestro caso, o un sprint de una semana-, nos actualizamos a Django 1.4, que supuso gran cantidad de cambios importantes y cr´ıticos. Adem´as de continuar desarrollando tests unitarios, empezamos a dise˜nar e implementar tests funcionales para cubrir los flujos b´asicos en BOS. 6.2. Tareas realizadas Entremos en detalle en el trabajo realizado: 31 Cap´ıtulo 6. Django 1.4 Figura 6.1: Nueva estructura de ficheros despu´es de la actualizaci´on Actualizaci´on a Django 1.4: lo primero fue actualizarnos a Django 1.4, lo que aparte de las mejoras y del cambio en las dependencias, supuso un gran cambio a nivel de estructural. En la figura 6.1 podemos ver la nueva estructura, entre los cambios dados podemos dividirlos en dos: los obligados por Django y los impulsados por nosotros por motivos de orden. En el primer grupo tenemos la creaci´on de una carpeta con el nombre del proyecto, y dentro de ´el tienen que ir el archivo settings.py y el archivo urls.py, en nuestro caso settings es una carpeta porque tenemos diferentes settings dependiendo de en que entorno se despliegue BOS -devel.py, test.py, release.py o prod.py, entre otros, por ejemplo para despegar el servidor de release: python manage.py runserver – settings=bos.settings.release-. Respecto al fichero urls, b´asicamente hemos de decir que es el fichero que contiene todas las urls de nuestra aplicaci´on o, en muchos casos, la direcci´on a otros ficheros de urls, pero todas comienzan siempre buscando en este archivo. Otro de las obligaciones impuestas por Django es el tener las carpetas de aplicaciones -digamos que Django se divide en aplicaciones, y dentro de cada una podemos tener su propio fichero urls.py, models.py y views.py, de manera que podemos tener una aplicaci´on para gestionar facturas y otra para gestionar clientes, 32 Cap´ıtulo 6. Django 1.4 si bien todo forma parte al final del mismo proyecto webal mismo nivel que la carpeta llamada como el proyecto, en nuestro caso bos, como puede ser el caso de la aplicaci´on sales. Los cambios incentivados por nosotros son el tener una carpeta docs dentro de la cual tenemos toda la documentaci´on -m´as adelante hablaremos de esto en detalle-, otra carpeta con todos los scripts -para crear la base de datos de tests, para hacer una reconstrucci´on (rebuild) de los ´ındices-, una carpeta requirements - que tiene los archivos con las dependencias para cada uno de los sistemas, por ejemplo para instalar las librer´ıas de desarrollo: pip install -r requirements/dev.txt-, o el inclusi´on de los ficheros est´aticos (css, js, im´agenes) dentro de la carpeta BOS, de los daemons -los daemon son procesos que se ejecutan peri´odicamente o continuamente encargados de ejecutar ciertas funcioneso del fichero utils.py -que contiene una serie de funciones creadas por nosotros que nos son de mucha utilidad para usarlas en las diferentes aplicaciones-. En la ra´ız del proyecto encontraremos tambi´en el archivo manage.py, uno de los m´as importantes de Django, pues es el encargado de ejecutar gran cantidad de los comandos -python manage.py command-, cuyo c´odigo hay que cambiar, pues en Django 1.5 la versi´on antigua es marcada como deprecated (en desuso) y en Django 1.6 ya no puede usarse. Estos cambio estructural llevo adem´as un gran cambio de c´odigo, pues muchas importaciones hubo que refactorizarlas -por ejemplo from utils import * pas´o a ser from bos.utils import *, o import settings.py pas´o a ser from django.conf import settings, que toma autom´aticamente el settings con el cual se ha lanzado el proyecto-. Por ´ultimo comentar que las variables con datos sensibles como contrase˜nas para la conexi´on la base de datos o con servicios externos fueron sacadas del c´odigo por motivos de seguridad, de modo que era necesario tenerlas activas en el entorno virtual de la manera habitual de Linux: export BOS DB DEFAULT USER=***** export BOS DB DEFAULT PASSWORD=***** Actualizaci´on de librer´ıas: algunas librer´ıas tuvieron que ser actualizadas: django-form-utils 0.2.0 to 1.01 django-polimorphic 0.4 to 0.53 33 Cap´ıtulo 7. Django Desencadenado •Adem´as, se creo un script para comprobar, tanto en local como en los diferentes entornos, que la conexi´on con los distintos servicios -xignite, el cual nos proporciona los ratios de cambio; o sugar, nuestro crm; por nombrar algunosse realiza correctamente. •Continuamos tambi´en intentado aumentar la cobertura de tests y para ello realizamos pruebas de la parte de reconciliaci´on, modulo se encarga de unir aquellas entras bancarias reales que llegan al sistema con las entras en BOS, parte important´ısima como es de imaginar. •Por ´ultimo, cambiamos el SGBD para los tests, los cuales se ven´ıan ejecutando con Sqlite -bastante ligeropor PostgreSQL -m´as lento pero mucho m´as potente-. B´asicamente tuvimos que cambiar la configuraci´on en el settings, adem´as de modificar nuestro script que nos creaba la base de datos de tests. Se aprovecho para mejorar algunos tests que comenzaron a fallar y que sqlite no detectaba. La ´ultima de las tareas y la que llev´o m´as tiempo fue la correcci´on de errores no tanto por los cambios realizados en este sprint sino por la actualizaci´on del sprint anterior, el cual dej´o muchos bugs pendientes. Hubo que corregir pr´acticamente todos los tests, los cuales pasaron de heredar de TestCase a heredar de BosBaseTest -esta nueva clase hereda de la anterior, con la diferencia de que antes de ejecutar cada test reinicia los ´ındices al estado inicial-. Referente a lo anterior, algunos filtros que usaban los ´ındices comenzaron a fallar tambi´en, y nos dimos cuenta que algunos iban m´as lento de lo deseado, motivo por el que comenzamos a pensar en cambiar de motor de´ındices, si bien se hicieron algunos fixes temporales. No podemos olvidarnos adem´as del merge habitual y de los problemas que trae. 7.3. Progreso Llegamos a los ´ultimos momentos del partido y aunque pueda parecer que ya est´a todo listo, en el siguiente y ´ultimo sprint se cambio Solr por ElasticSearch, cambio bastante complejo, adem´as de mejorar la documentaci´on, optimizar el rendimiento de pantallas cr´ıticas en BOS, actualizar jQuery, as´ı como terminar de hacer nuevos tests y mejorar algunos antiguos, y corregir bugs. La cobertura de tests subi´o a un 27 %. Podemos ver en la imagen 7.2 el Burndown Chart de este sprint, nuevamente atacados por la gran cantidad de errores -principalmente los ´ındices-, motivo que hizo que si bien 40 Cap´ıtulo 7. Django Desencadenado Figura 7.2: Burndown Chart del quinto sprint se ten´ıa pensado acabar el proyecto en un sprint de tres semanas, se pas´o a dejar el sprint en dos semanas y terminar con un ´ultimo sprint de otras dos semanas que dejase todos los detalles finos y que nos permitiese cambiar a ElasticSearch. Cabe decir que el motivo de la repentina subida a mitad del sprint fue la incorporaci´on de test funcionales por el equipo de QA que previamente no hab´ıan sido estimados, por lo que supuso un aumento del trabajo restante que no se hab´ıa pensado inicialmente. 41 Cap´ıtulo 7. Django Desencadenado 42 Cap´ıtulo 8. Finalizando el Proyecto 8.1. Introducci´on Durante el ´ultimo sprint, Forceful Flying-Snake, de dos semanas de duraci´on (nuevamente podr´ıa haber sido ampliado el plazo o incluso posteriores sprints para a˜nadir m´as mejoras, si bien se decidi´o finalizar el proyecto aqu´ı), conseguimos dejar BOS totalmente estable, sin errores, y con mejoras de rendimiento funcionando perfectamente en todos los servidores. Actualizamos jQuery, mejoramos la documentaci´on, y cambiamos Solr por ElasticSearch. 8.2. Tareas realizadas Entremos en detalle en el trabajo realizado: Actualizaci´on de jQuery: un cambio que se comi´o tambi´en bastantes horas fue la actualizaci´on de jQuery, la cual se hizo en dos pasos. Primero actualizamos de 1.4.4 a 1.11.0, para posteriormente actualizarnos a las 2.1. Lo que se hizo fue testear manualmente las distintas p´aginas para corregir aquellas que dejasen de funcionar o que cambiasen de comportamiento. Tests: se continu´o realizando tests funcionales de los flujos principales, adem´as de realizar algunos tests nuevos para comprobar los correctos cambios de jQuery. En este sprint no se realizaron tests unitarios. 43 Cap´ıtulo 8. Finalizando el Proyecto Documentaci´on: Se mejor´o la documentaci´on a˜nadiendo un manual de instalaci´on para todos aquellos que quisiesen actualizarse BOS al estado posterior a este proyecto o para aquellos que quisiesen instalarlo de 0. Integraci´on de ElasticSearch: lo primero fue cambiar los distintos settings y las dependencias, y luego se comenz´o a corregir los distintos errores que fueron surgiendo. Adem´as hubo que cambiar los diferentes scripts existentes y documentar las novedades. Securizar el setting: lo que hicimos fue sacar todas las variables sensibles del setting, pues tanto como contrase˜nas como identificadores era puestos directamente sobre el c´odigo. Lo que hicimos fue que se extrajeran de las variables de entorno, por lo que cada uno en su entorno era responsable de tener las variables correctamente actualizadas. Optimizar pantallas cr´ıticas: se hizo un gran esfuerzo en aumentar la velocidad de carga de aquellas p´aginas demasiado pesadas o importantes. Uno de las caracter´ısticas que se intent´o usar fue la paginaci´on en aquellas partes m´as antiguas que no fueron inicialmente hechas as´ı. Se intent´o adem´as reducir el tama˜no de la base de datos, pero debido a lo entremezclado de los datos, y a la necesidad de sacar reportes sobre diferentes datos muy antiguos o incluso desde el comienzo de la aplicaci´on, hicieron inviable esta opci´on. Errores: por supuesto este sprint tuvimos que corregir muchos errores, si bien es cierto que el merge fue m´as ligero que de costumbre. Tuvimos que pelear con Jenkins, el cual fallaba al intentar matar a celery si no estaba andando (se solucion´o con un ’— true’ en el script); se mockearon - un mock es un sustituto de una funci´on que devuelve un valor predefinidociertas llamadas a servicios externos, pues algunos tests comenzaron a fallar por motivos ajenos a nosotros, ya sea por tiempo excedido (timeout) o por incapacidad de conectar en ciertos momentos; por comentar algunos de los errores m´as interesantes. Mejoras de rendimiento: se instal´o en un sistema BOS antes de la actualizaci´on y en otro despu´es de todo el proyecto para comparar los resultado de los diferentes tests de escalabilidad y de rendimiento. En el anexo 2 encontramos el documento que se extrajo del an´alisis, en el podemos ver algunas p´aginas en las que el aumento del rendimiento ha sido m´as que notable, aunque tambi´en hay algunas en las que se ha reducido algo el rendimiento, aunque puede ser por el aumento de informaci´on 44 Cap´ıtulo 8. Finalizando el Proyecto Figura 8.1: Burndown Chart del sexto sprint de la base de datos, o por las nuevas funcionalidades que han ido a˜nadiendo otros equipos paralelamente a nuestro desarrollo. Release: despu´es de todo este desarrollo se tuvo al proyecto una semana m´as en preproducci´on para terminar de probar la aplicaci´on y corregir los ´ultimos detalles, hasta que finalmente se puso en producci´on sin grandes complicaciones. 8.3. Progreso Finalmente hemos finalizado el proyecto, dejando BOS en la versi´on de Django 1.4.10 de manera estable. En el siguiente cap´ıtulo analizaremos la evoluci´on del proyecto y el estado final. Podemos ver en la imagen 8.1 el Burndown Chart y como nos hemos acercado m´as a la estimaci´on inicial. Solo nos hemos dejado en el tintero el realizar m´as pruebas funcionales del flujo de la aplicaci´on, pero a´un as´ı estamos bastante contentos con el resultado final. 45 Cap´ıtulo 8. Finalizando el Proyecto 46 Cap´ıtulo 9. Conclusi´on 9.1. Resumen Nos hemos encontrado con 6 sprint a lo largo de los cuales hemos ido actualizando Django y las diferentes librer´ıas, haciendo los oportunos cambios de c´odigo e incluso de tecnolog´ıa a veces, para terminar dejando el sistema en un estado estable. En el primer de estos sprint hicimos un estudio fundamental de estado inicial del sistema y de las diferentes pruebas a realizar, adem´as de la posibles librer´ıas a actualizar, y creamos los distintos entornos necesarios. Comenzamos con la implementaci´on de pruebas unitarias y limpiando un poco el c´odigo, adem´as de empezar a usar Scrum como metodolog´ıa ´ Agil con la herramienta web Jira. En el segundo sprint, aparte de seguir desarrollando m´as pruebas, actualizamos Django y las librer´ıas asociadas, adem´as de estudiar la actualizaci´on de jQuery. En el tercer sprint seguimos desarrollando nuevas pruebas, e incluso se mejoraron los ya existentes. Importante en esta etapa fue la inclusi´on de la Integraci´on Continua y el uso de Jenkins. Al final de este sprint se saco a producci´on una primera versi´on estable con los primeros cambios. En el cuarto sprint seguimos naturalmente con las pruebas unitarias, pero tambi´en comenzamos a hacer pruebas funcionales. En esta fase se dio el paso m´as grande de versi´on, 47 Cap´ıtulo 9. Conclusi´on hasta Django 1.4.1, lo cual supuso una enorme cantidad de cambios y bugs. En el quinto sprint hicimos la actualizaci´on final de Django y de algunas librer´ıas, y a˜nadimos un sistema de documentaci´on con Sphinx y continuamos analizando los cambios y corrigiendo errores. Hubo gran movimiento en el tema de tests unitarios, sobretodo teniendo en cuenta el cambio de Sqlite a PostgreSQL. En el sexto y ´ultimo sprint, dejamos BOS totalmente estable, actualizamos jQuery, mejoramos la documentaci´on, y cambiamos Solr por ElasticSearch, e incluso se realiz´o un an´alisis comprando BOS antes y despu´es del proyecto. Finalmente se despleg´o el c´odigo en producci´on y se actualizo el c´odigo de los otros proyectos sin ninguna incidencia grave. 9.2. Posibles mejoras Si pensamos en el recorrido del proyecto, podemos ver perfectamente como nos hemos dejado ciertas cosas en el tintero, si bien algunas de ellas son bastante prioritarias y es un riesgo no llevarlas a cabo: M´as pruebas: es una realidad que ante la magnitud de un cambio como el realizado el riesgo de errores es bastante elevado, y a mayor cantidad de pruebas m´as sencilla es tanto la b´usqueda de errores como su correcci´on, lo que disminuir´ıa la probabilidad de fallos en el sistema y aumentar´ıa la calidad del c´odigo. Hemos de entender que en un entorno empresarial se est´a muy controlado por los recursos disponibles, y no siempre es posible tener cubiertas todas las necesidades. A la hora de hablar de pruebas hemos de concretar que son necesarias pruebas unitarias, de integraci´on y funcionales. Esto adem´as reducir´ıa el tiempo de prueba necesario por los QAs. Librer´ıas: aunque todas las librer´ıas fueron actualizadas sin problemas, es cierto que podr´ıamos haber dedicado m´as tiempo a analizarlas en profundidad para analizar la verdadera necesidad que tenemos de ellas, pues puede ser que existan algunas nuevas librer´ıas mas potentes o sencillas de usar a las que habr´ıa sido conveniente cambiar. Nuevas funcionalidades: vimos tambi´en como las nuevas versiones a˜nad´ıan bastantes funcionalidades, muchas de las cuales habr´ıa sido interesante estudiar su posible uso, pero que por falta de tiempo o verdadera necesidad fue imposible hacer. 48 Cap´ıtulo 9. Conclusi´on Documentaci´on: la documentaci´on es la gran olvidada en muchos proyectos -incluso algunas metodolog´ıas ´agiles la rechazany, si bien es cierto que nosotros a˜nadimos un buen sistema de documentaci´on, podr´ıamos haber dedicado m´as esfuerzos a documentar de manera mucho m´as extensa todas las interesantes novedades de cara al resto de la empresa. 9.3. Balance final Haciendo balance del proyecto, podemos decir que ha permitido a la empresa mejoras en la seguridad del sistema gracias a la actualizaci´on de Django, aumento en el rendimiento en algunas partes de la aplicaci´on, mayor legibilidad y extensibilidad de c´odigo gracias a la nueva estructura y a las pruebas, pues se puede hacer cambios con m´as seguridad de que nada esta fallando, adem´as de la incorporaci´on de muchas nuevas funcionalidades y facilidades para usar por los desarrolladores. Es cierto que se retraso un poco el tener el sistema con Django 1.4.10 totalmente funcional y depurado, lo cual influy´o en que se cancelase el actualizar Django a la m´as versi´on para m´as adelante en pos de otros desarrollos, pero el resultado final fue muy satisfactorio, y los trabajadores de la empresa quedaron muy contentos con los cambios hechos y las mejoras introducidas. Si hemos de decir que factores han afectado tanto positiva como negativamente, diremos que el hecho del escaso conocimiento inicial de Python y Django por un lado, y de BOS por otro, hicieron que el rendimiento no fuese el de un trabajador experimentado, adem´as de ser la primera vez que yo trabajaba en una empresa y adem´as usando de manera totalmente real Scrum; y tambi´en fueron muchas las herramientas y procedimientos que tuve que aprender en poco tiempo. Un aspecto positivo fue que se realizaron bastantes an´alisis en un comienzo que nos fueron muy ´utiles posteriormente, y si he de destacar algo por encima de todo lo dem´as, la introducci´on tanto de un sistema de integraci´on continua como de un equipo de QA que estuviese al tanto de los cambios realizados por el equipo y que controlase que tanto las distintas funcionalidades como los tests fuesen hechos de manera correcta fue un factor totalmente fundamental para el ´exito de este proyecto. Aprovechamos para mencionar que siempre, y m´as a´un cuando trabajamos en una 49 General Status Initial Time Machine Code Distribution  Lines of Code (LOC)    Complexity  Useless Code Duplicated Lines  Legend  LegendofCyclomaticComplexity:  Value Meaning 110 LowRisk 1120 ModeratedRisk 2150 HighRisk >50 HighestRisk(Notestableprogram) ANEXO 2 En este segundo anexo podemos ver un informe comparando el rendimiento de BOS antes y después de la actualización.