Cartilla TSP

Con base en el libro de TSP de Humphrey se construyó una cartilla de tan solo 10 capítulos en los que se describe la metodología a nivel general y las actividades a ejecutar en cada fase de cada ciclo de desarrollo, especificando responsabilidades y criterios de salida de una fase a otra. En el anexo 4 se encuentra dicha cartilla, de la que se destaca su precisión y formato legible a fin de apoyar la comprensión de la metodología, especialmente para estudiantes que están en proceso de aprendizaje de TSP.

9.7.4 Comparador de código

Medir el tamaño del producto software genera costos por la especial atención a los cambios presentados durante el desarrollo; por esta razón se propone una herramienta software capaz de

117

comparar dos versiones de código a fin de identificar rápidamente las funciones agregadas, eliminadas y modificadas.

En la ilustración 36 se puede observar la interfaz para agregar las dos versiones de código:

Código Antes y Código después, para validar su contenido y posteriormente comparar los archivos

de acuerdo a un lenguaje de programación específico. Esta propuesta brinda comparación de código para lenguaje Java, sin embargo, su diseño permite adicionar cualquier otro lenguaje sin generar grandes costos de implementación.

9.7.5 Exportador de datos

En el prototipo, resultado de este proyecto, se presenta el ícono mostrado en la parte superior derecha de cada formato, tal como se muestra en la ilustración 37 sobre el formato LOGT.

Bajo un simple click, la herramienta provee los datos del formato TSP en una hoja de cálculo para que los usuarios puedan tomar total control sobre éstos, especialmente para los casos en que deseen documentar las características del proyecto a la fecha.

9.8 PRUEBAS DE PROTOTIPO

Las pruebas sobre el producto se llevaron a cabo en tres escenarios con distintos contextos, dos de ellas como pruebas de validación y la tercera y última como prueba de verificación.

Ilustración 37. Servicio de exportación de datos para el formato LOGT. Fuente autor Ilustración 36. Interfaz de comparación de código. Fuente autor

118

Finalmente, con base en las características evaluadas en [109] (de K.K. Aggarwal), se determina porcentualmente, el grado de completitud y satisfacción del prototipo en su totalidad.

9.8.1 Hardware utilizado

A continuación se describen los dispositivos utilizados en las tres pruebas realizadas al prototipo, asignando a su vez un nombre que los ayude a identificar en posteriores observaciones. Cabe aclarar que se superaron las limitaciones al disponer de un ordenador más para las pruebas.

9.8.1.1 Lenovo G40-30

Es el ordenador portátil donde, además de efectuar el desarrollo del prototipo, se despliega la aplicación para las pruebas, cumpliendo tanto el rol de servidor como de cliente.

Nombre: Lenovo

Procesador: Celeron N2830 2.16 Ghz

Memoria RAM: 8GB

Arquitectura: 64 bits

Sistema operativo: Windows 8.1/Ubuntu 14.04.2

9.8.1.2 Compaq Mini CQ10-120la

Ordenador portátil cliente con las características mínimas, incluso insuficientes, para oficina.

Nombre: Compaq

Procesador: Intel Atom N270 1.60 Ghz Memoria RAM: 2GB

Arquitectura: 32 bits

Sistema operativo: Windows 8.1

9.8.1.3 Compumax Intel core 2 duo

Ordenador de escritorio, cliente, con características de oficina.

Ilustración 38. Servidor de pruebas y desarrollo.

119 Nombre: Compumax

Procesador: Intel core 2 duo 1.89 Ghz Memoria RAM: 1GB

Arquitectura: 64 bits

Sistema operativo: Windows 8.1

9.8.1.4 Router ETB ZTE-ZXV10-W300

Router o comúnmente llamado modem, corresponde al dispositivo de comunicación entre ordenadores vía Ethernet y WiFi.

9.8.2 Escenarios

9.8.2.1 Curso de aprendizaje

El prototipo fue alimentado con los datos provenientes de un proyecto desarrollado por estudiantes de un curso de aprendizaje de la metodología TSP. El proyecto, de nombre Caso de

estudio coorperativa de egresados UPB [111], fue llevado a cabo en el año 2016 con un solo ciclo

de desarrollo, en el que se documentó formalmente el proceso de ingeniería y sobre todo, la gestión de las métricas, indicadores y medidas obtenidas a lo largo de la ejecución del proyecto.

A partir de los documentos proporcionados por la instructora de dicho proyecto, se ingresaron los datos del proyecto simulando la ejecución de éste, a fin de garantizar la completitud de las mediciones y con ello la obtención de indicadores y métricas correspondientes. A

Ilustración 40. Ordenador de escritorio de cliente.

120

continuación se muestran algunas comparaciones entre las vistas de los documentos proporcionados para la prueba y las vistas del software una vez los datos fueron diligenciados en éste.

9.8.2.1.1 Comparación definición de metas

La definición de metas pudo llevarse a cabo satisfactoriamente puesto que la herramienta permitió adicionar las metas rápidamente sin excepción alguna y con un alto nivel de amigabilidad. En la ilustración 42 se pueden observar las metas definidas en el documento del plan de calidad que creó el equipo y las metas ingresadas al software.

9.8.2.1.2 Comparación formato STRAT

En la ilustración 43 se pueden observar tres divisiones; las dos primeras corresponden al documento de estrategia del equipo (incompleto, puesto que es de gran tamaño), el cual separó el formato STRAT en dos tablas a diferente nivel de detalle. La tercera división de la imagen unifica los valores ingresados por el equipo al estándar de la metodología TSP en el software.

121

La ventaja del software se hace evidente cuando son necesarios los cambios. Si el equipo decide añadir o eliminar una función de algún módulo, requerirá de gran esfuerzo y tiempo, en cambio, en el software, tanto el nuevo registro como los registros dependientes, se ajustarán en forma automática.

122

9.8.2.1.3 Comparación formato ITL

En la ilustración 44 se puede observar la tabla definida por el equipo de desarrollo para registrar los riesgos del proyecto y un registro de éstos en el software. La clasificación de los registros de la tabla se hizo con colores, y en el software con base en el filtro del nombre del componente, facilitando su interpretación a la vez que brinda la posibilidad de añadir más riesgos a cada uno de éstos sin recurrir a grandes cambios.

9.8.2.1.4 Comparación formato TASK

En la ilustración 45 se puede observar una muestra del formato TASK realizado por el equipo de desarrollo. El formato TASK resultado del software se puede observar en el anexo 5, el

Ilustración 44. Comparación de formato ITL documentado e ingresado al software. Fuente autor

123

cual tiene ligeras diferencias relacionadas a la fácil gestión de los cambios (agregar, remover y editar tareas).

Este formato en particular presenta varias mejoras, pues a falta de una herramienta que guiara el diligenciamiento del formato TASK, el equipo tuvo que construir una hoja de cálculo por cada rol, diligenciarlo en forma individual y finalmente unificar los datos en un único formato de equipo. Al diligenciar los datos en la herramienta, bastó con diligenciar un único formato TASK capaz de actualizar los datos en tiempo real, evitando errores en las mediciones y brindando posibilidades de cambio sin recurrir a enormes esfuerzos de versionado y descontrol de información al no poseer una interfaz capaz de enfocar la atención de los integrantes.

9.8.2.1.5 Comparación formato SUMP

Dado el tamaño del formato SUMP, la ilustración 46 muestra únicamente el formato SUMP diligenciado por el equipo de desarrollo. En el anexo 5 se puede localizar el formato SUMP obtenido, con variaciones en los valores dadas las dificultades por obtener exactamente los mismos resultados en simulación.

Ilustración 46. Comparación de formato SUMP documentado e ingresado al software. Fuente autor

124

La herramienta software, para el caso de SUMP, provee únicamente los campos a diligenciar por el usuario para centrar su atención en determinados aspectos, como lo es la planeación, pues las mediciones, indicadores y métricas reales se gestionan automáticamente.

9.8.2.1.6 Comparación formato SUMQ

Es muy similar a SUMP al momento de comparar. Parte del formato proporcionado por el equipo de desarrollo se muestra en la ilustración 47 y el resultado obtenido mediante el software se muestra en el anexo 6. Así, también se brindan los campos específicos para los usuarios y se gestiona automáticamente gran parte de la información recolectada.

9.8.2.1.7 Comparación formato LOGT

En la ilustración 48 se puede observar la comparación entre los formatos LOGT del equipo de proyecto y de la aplicación. Básicamente ofrecen la misma información; lo importante en esta comparación es reconocer el grado de dificultad de construcción. Se desconoce exactamente qué metodología personal ejecutó cada integrante del equipo para controlar el tiempo de sus tareas, sin

Ilustración 47. Comparación de formato SUMQ documentado e ingresado al software. Fuente autor

125

embargo, se tuvieron que registrar manualmente los tiempos, asegurarse de que las tareas sean las definidas por el equipo y marcar, con alta probabilidad de errores, si la tarea fue finalizada o no.

9.8.2.2 Simulación en red LAN

Con esta prueba se pretendió evaluar la herramienta prototipo en el contexto más real posible, sin embargo, dadas las limitaciones de hardware, el caso ideal de 5 o 6 ordenadores y un servidor no fue posible llevarlo a cabo, y por tanto, se procedió a gestionar tres roles en el servidor Lenovo (que también se utilizó como cliente) y dos roles en el equipo cliente Compumax.

Además de recolectar información sobre los defectos presentados en la herramienta, se obtuvo una comprensión empírica del desempeño del sistema, teniendo en claro que el servidor no cuenta con las características mínimas para ejecutar dichas tareas, y por tanto tuvo que forzar sus recursos para responder a las peticiones presentadas en el software.

La ilustración 49 representa el escenario sobre el cual se hizo la prueba en una red local y la ilustración 50 evidencia el escenario real sobre el que se llevó a cabo la prueba. La distribución de roles sobre cada uno de los ordenadores se hizo como se muestra en la tabla 54.

Ilustración 48. Comparación de formato LOGT documentado e ingresado al software. Fuente autor

126

En síntesis, la ejecución de esta prueba fue satisfactoria al permitir ejecutar todas las tareas de la prueba anterior y sobre todo, permitir gestionar las métricas y culminar el proyecto. Los resultados a detalle sobre el rendimiento y defectos encontrados, se describen en forma precisa en el anexo 5.

Tabla 54. Ordenador sobre el que se gestionaron los datos de cada rol. Fuente autor

Ordenador Rol

LENOVO Líder de equipo COMPAQ Gerente de planeación COMPUMAX Gerente de calidad/proceso

LENOVO Gernte de soporte LENOVO Gerente de desarrollo COMPUMAX Instructor

9.8.2.3 Verificación final

Como última prueba se realizó una simulación de proyecto con la finalidad de refinar detalles asociados a la amigabilidad, el apoyo a los usuarios de la herramienta y algunas funcionalidades involucradas.

Considerando la última prueba como un proceso de validación, donde el cliente es representado por la docente Alba Consuelo Nieto (especial conocedora de las bondades de la metodología TSP), quien concluyó que la herramienta satisface en gran medida las necesidades de la metodología TSP al grado que “no se puede considerar un prototipo, sino la versión 1 de un software en producción”.

127

A continuación se enlistan los cambios solicitados por la docente desde el punto de vista del cliente y alineándose a la metodología TSP propuesta por Humphrey.

• Vista del logo del grupo de investigación y de la institución universitaria. Adicionar

información acerca del grupo de investigación

• Brindar información de ayuda sobre la elección del día de revisión semanal • Solicitar el número de teléfono de los integrantes

• Brindar la información de gerencia y miscelánea al final del formato TASK. • Brindar ayuda en las tareas asignando el nombre de la etapa

• Permitir asignar un tiempo para las tareas que no se deseen implementar • Redondear los valores calculados para facilitar su lectura

• Asegurar el nombre de cada formulario en el encabezado de éstos.

Una vez se realizaron los cambios solicitados, el software se desplegó en un servidor de la comunidad universitaria bajo la intención de que los estudiantes tomen conciencia de la importancia de medir su trabajo, para con ello desarrollar disciplina y mejorar continuamente sus procesos que los permitan destacar a nivel general, y en especial, a nivel laboral.