MODUM Primera Edición | Page 82

[ sección ] II. METODOLOGÍA En el proceso de desarrollo con modelos ágiles el primer paso es el levantamiento de requisitos con el cliente, el cual se hace periódicamente y juega el rol de Product Owner (PO), quién es el que da el linea- miento sobre el “Qué” del producto. Adicional a esto, hace la priorización de dichos requisitos, lo cual, se convierte en el primer artefacto SCRUM como lo es el Product Backlog (Peralta, 2005). Con esta prioriza- ción se da inicio a la fase de planeación del primer Sprint. Los sprint corresponden a la funcionalidad priorizada por el cliente, la cual, se despliega en una cartelera llamada Srint Backlog que posee tres columnas (Por Hacer, en Proceso, Terminado) para ubicar las historias de usuario (similar a los requeri- mientos, pero en un lenguaje más amigable para el cliente). Una vez planteados estos Sprint iniciales, entra en acción el rol del TEAM (Equipo de Desarro- llo), el cual es el encargado del desarrollo del softwa- re. Una vez realizados de dos a tres Sprint se realiza el entregable llamado RELEASE, que es el equivalente a una liberación de producto. En el caso del aplicativo Gestor de Casos de Prueba (NIVAL) se prioriza inicial- mente la liberación de la funcionalidad de Gestión de Casos de prueba, la cual ha sido entregada inicialmente para que el cliente (PO) pueda hacer un feedback en la reunión de Sprint Review de forma que se puedan hacer ajustes en la carga de tareas del siguiente Sprint y de ser el caso se pueda hacer una repriorización de la pila de requerimientos (Product Backlog). Paralelo a el desarrollo de Nival 2.0, se está realizando por medio de SENNOVA y su semillero MERLIN la gestión de adquisición de una herramienta CASE que permita al igual ejecutar pruebas similares a las que se pretenden realizar con el aplicativo hecho a la medida. En el mercado se han encontrado otras herramientas que poseen licencias GPL (Generic Public Licence) o de uso Público como Mantis Bug Tracker y Selenium HQ, las 80 cuales pretenden crear un escenario de línea base que le permita al proyecto de Testing poder realizar compa- rativos de los diferentes escenarios de prueba que se obtendrán con la aplicación desarrollada por el Team (Equipo) del proyecto. Figura 2. Logos del Software Mantis. Fuente: (https://www.mantisbt.org). Una vez se tengan tanto la herramienta propia a la medida como la adquisición del software CASE y el permiso de uso de las aplicaciones con licencia GPL, se realizará la configuración de los equipos en el entorno de trabajo del laboratorio. El laboratorio consta de 20 Equipos de tipo Work Station con proce- sador Intel® Xeon® Quad Core Processor, 16GB Memory, 1TB Hard Drive, Tarjeta Video Nvidia 2GB. Monitor de 21”. También se adquirió un servidor que permite la virtualización de los diferentes escenarios de pruebas en diferentes configuraciones de OS (Sistema Operativo) y Bases de datos. Este servidor contó con las siguientes características relevantes: procesador Intel® Xeon® E5-2620 v3 2,4 GHz, caché de 15 M, Memoria RDIMM de 16 GB, 2400 MT/s con clasificación doble ancho de datos con posibilidad de ampliar a 64 GB y 2 discos duros de conexión en caliente de 1TB 7200 RPM 6Gbps de 3.5” ampliable a 20 TB por medio de bahías de expansión. Estas especificaciones permitirán correr las diversas pruebas de diferentes productos de forma simultánea, para evitar tiempos de espera, o productos en cola con una configuración multi-hilo. Para el laboratorio de pruebas de software, se adquirieron equipos con unas especificaciones técnicas que facilitaran la instalación de las aplica-