Caso Práctico II: Health at Home

Por colaboradores de Mundo Ingenio

Esta es una recopilación de información relevante sobre una serie de metodologías, métricas, herramientas y técnicas de desarrollo de software; en esta investigación se compila desde las principales características que identifican una liberación de un proyecto, definición de integración, entrega y despliegue continuo así como algunas de sus herramientas e implementación; casos de pruebas, técnicas de “testing” de métodos o funciones de aplicaciones, hasta métricas de desarrollo de calidad de sistemas o programas.

Por otra parte, se pone en práctica algunas de los conceptos que a continuación se exponen, tales como liberaciones con su descripción y algunos parámetros, gestión de riesgos con sus respectivos conceptos y descripciones y también la manera de manejarlos, y por último, casos de prueba y métricas de desarrollo de software.

Algunas preguntas tendrán una relación con el caso práctico de la empresa Health at Home (HH) expuesto como hipotético.

Preguntas

1. El personal de “HH” tiene interés en hacer liberaciones (“releases”) de capacidades completas del negocio y no solamente funcionalidades aisladas. Esto les permitirá salir al mercado lo antes posible y captar clientes antes que la competencia ponga en marcha algún producto similar. Para esto se le ha nombrado a usted como “Product Owner” del proyecto y su función será diseñar un plan de entregas del producto en versiones. Cada versión deberá ser funcional tanto para el personal de “HH” como para los entrenadores y los usuarios finales. En su función de “Product Owner” se le solicita definir las 3 primeras liberaciones del proyecto. Tome en cuenta que la primera liberación debe ser el producto mínimo viable (Kanban, 2020). Para identificar el “MVP” debe poner atención a los principales objetivos del proyecto. Para cada liberación, indique:

a. El nombre de la funcionalidad de negocio que se habilita.

b. Una descripción de las funcionalidades del sistema que se ponen en producción.

c. Una justificación del orden en el que se realizará la liberación.

Para empezar, y tomando en cuenta los objetivos de la empresa “HH”, las cuales se nombran a continuación: el más importante es un excelente posicionamiento a nivel mundial (número 1); igualmente lograr que los colaboradores ganen una remuneración por los servicios prestados dentro de la plataforma y de esta forma ayudarse mutuamente; por otra parte, fidelización de clientes o usuarios de la plataforma mediante seguimiento de su desarrollo de actividades y premiación de los mismos por dichas tareas. Ahora bien, si como menciona el autor Sordo (2021), que para lograr alcanzar futuros clientes o usuarios en el desarrollo de un proyecto o producto, en este caso el de la aplicación de acondicionamiento físico por parte de la empresa “HH”, se deben tomar en cuenta varios parámetros, entre los cuales destacan los pasos para crear un producto mínimo viable: en primer lugar, construcción de ideas mediante hipótesis de nuestro producto o servicio que se desea implementar y que a su vez resuelva el problema de un eventual usuario. En segundo lugar, medición del rendimiento donde menciona que a través de varias métricas se obtienen resultados que se pueden apreciar y medir para compararlos con la hipótesis en principio planteada; en tercer lugar, aprendizaje de los resultados adquiridos y acelerar el proceso planteado. 

Por otra parte, como dueño del producto o “Product Owner” en este caso hipotético y suponiendo que tengo el cargo de las liberaciones de versiones de la aplicación, e igualmente con las características propias de un dueño de producto como mencionan los autores Schwaber y Sutherland (2017) “Expresar claramente los elementos de la Lista del Producto; Ordenar los elementos en la Lista del Producto para alcanzar los objetivos y misiones de la mejor manera posible; Optimizar el valor del trabajo que el Equipo de Desarrollo realiza; Asegurar que la Lista del Producto es visible, transparente y clara para todos y que muestra aquello en lo que el equipo trabajará a continuación; y, Asegurar que el Equipo de Desarrollo entiende los elementos de la Lista del Producto al nivel necesario.” (pág. 6). 

A continuación las funcionalidades o liberaciones de las 3 versiones. En primer lugar, y con base en la información expuesta con anterioridad, la primera tiene como nombre “HH Acondicionamiento Físico Versión 1”; como esta primera liberación debe ser el producto mínimo viable se listan y explican las siguientes funcionalidades del sistema: 

• Pago de membresía por parte de usuarios: en esta funcionalidad si se debe pagar un monto para ser miembro en la plataforma, no obstante, si tomamos en cuenta que como producto mínimo viable se debe consultar al cliente si el monto es óptimo para la clase de servicio que se ofrece, y crear una encuesta dentro de la aplicación para tener sugerencias y otras referencias sobre el valor, dando rangos de precios. 
• Inscripción de entrenadores: esta función es fundamental porque sin un equipo de entrenadores la aplicación no puede funcionar. Ahora, si se debe filtrar con los parámetros expuestos en el caso hipotético expuesto “HH”, pero, igualmente como PMV se debe tomar en cuenta la opinión de los entrenadores en su módulo respectivo. Entonces, igualmente una serie de preguntas para los entrenadores respecto a los ejercicios que se exponen por la empresa, si son o no óptimos para los usuarios, y obviamente recibir sugerencias y otros comentarios sobre la aplicación.  
• Acceso al catálogo de entrenamientos: igual que el entrenador, se necesita del usuario sus consultas, sugerencias y demás para modificar los servicios, toda esta información recolectada mediante cuestionarios y formulario de contacto. 
• Acceso al pago de entrenadores: como parte vital de la aplicación, el soporte por parte de los entrenadores en muy importante para mantener funcionando el sistema. Mediante una interfaz no tan elaborada para economizar código, se pregunta a los entrenadores si la forma de interacción en este módulo es funcional o necesita mejoras, porque al final se puede afirmar que el interés principal en este módulo es recibir el pago íntegro, fácil y rápido.
• Creación del algoritmo para conexión con empresa BWW: aquí como parte significativa de la aplicación se debe tomar en cuenta tanto la funcionalidad eficaz en el módulo donde se implemente el algoritmo, así como su usabilidad. Entonces, como parte del diseño, y en el módulo que se utilice se debe igual poner en funcionamiento para preguntar al usuario si la velocidad y eficacia de esta función es óptima y cumple los requisitos mínimos de los usuarios. 
• Creación de módulo de premios: al igual que el pago para entrenadores los usuarios reciben no solo un acondicionamiento físico, sino también una remuneración por su actividad dentro del sistema. Por lo tanto, se debe medir que tan satisfechos se sienten los usuarios finales, y para ello una serie de preguntas se debe colgar en el sistema para cumplir este objetivo. 

Seguidamente la justificación del orden de la liberación. La primera funcionalidad debe ser la primera porque es la más significativa para tomar en cuenta si el precio es el adecuado y así poder captar la cantidad de clientes o usuarios finales que permita a la aplicación un buen posicionamiento a nivel mundial. La segunda funcionalidad se encuentra en esa posición porque sin entrenadores no se puede atender a los usuarios que se inscriban en el sistema, y así poder tener material para poder entrenar a los miembros de la plataforma. Seguidamente, el acceso al catálogo se posiciona en tercero porque su implementación para los usuarios es fundamental para su entrenamiento de preferencia y así poder llegar a la siguiente función. La siguiente función de pago de entrenadores, el entrenador necesita usuarios para recibir buenas críticas y rating para conseguir motivación para quedarse y funcionar permanentemente en la plataforma. Luego, la siguiente función se encuentra en la quinta posición porque la velocidad del algoritmo va a agregar un valor a la plataforma y va a ser significativo para mantener la fidelización con los entrenadores que son uno de los pilares del sistema. Y por último, el módulo de premios, aunque no deja de ser importante, hay usuarios que no se van a quedar en la plataforma solo para ganar remuneración por hacer ejercicio, sino por el bienestar de su salud sin importar si hay o no remuneración por lo que hace dentro de la plataforma.

Con la información recolectada en las diferentes preguntas y evaluaciones por parte de los usuarios finales de la aplicación, se puede medir el resultado y llegar a una serie de conclusiones que servirán para una modificación de los módulos actuales y/o agregación de nuevos, con base en las sugerencias se puede modificar con mayor claridad la codificación que se tiene actualmente. 

La segunda liberación lleva como nombre “HH Acondicionamiento Físico Versión 1.2”. Las funcionalidades se describen y listan a continuación: 

• Pagar el monto sugerido y votado de membresía: con base en la primera liberación se obtiene servicio de recursos de entrenamientos personalizados para los usuarios.
• Inscripción de entrenador en la plataforma: igualmente con la información recolectada de la anterior liberación, se ofrecen los servicios y generan ingresos por ello.
• Acceso al catálogo de entrenamientos: de la misma forma, con la información que se obtiene de la liberación de la versión 1, se obtiene la calendarización óptima para entrenamientos y selección de entrenador para usuarios. 
• Acceder al módulo de entrenamientos: con la información obtenida en la primera liberación se procede a grabar el entrenamiento para otros miembros de la plataforma que pagan por él.
• Tener acceso al módulo de pago: en la primera liberación se obtiene información relevante con el fin de que los entrenadores perciban remuneración por los servicios que brinda.
• Crear un algoritmo de conexión con empresa BWW optimizado: con base en la primera liberación, se obtienen las cuentas IBAN de los entrenadores para proceder a su pago respectivo. Pero esta vez, optimizada la codificación para un mejor desempeñó. 
• Generar un algoritmo de premios: con base en la última funcionalidad de la primera liberación, se premian a los usuarios que graban sus entrenamientos y concursan en el módulo de premios. 

Prosiguiendo, la justificación del orden de la liberación. La posición correspondiente de las funcionalidades tiene su lugar porque son condición y dependientes una de otra. La primera y la segunda son dependientes, pero los usuarios con membresía cumplen el objetivo principal de la aplicación. El catálogo de entrenamiento y el módulo de entrenamiento, igual que las dos primeras posiciones son dependientes, pero con menos prioridad de los pilares de la aplicación como lo son los usuarios finales y los entrenadores. El módulo de pago depende del módulo de entrenadores al igual que la verificación de la cuenta IBAN, la cual se encarga el algoritmo de conexión con la empresa BWW. Y por último, la premiación no es vital para fidelizar a los usuarios finales y no evita su permanencia dentro de la plataforma. Una vez liberada la aplicación se procede a preguntar o implementar una serie de sugerencias a los usuarios finales, los entrenadores y los dueños de la empresa que pusieron en marcha el proyecto de acondicionamiento físico. 

En tercer lugar, la tercera liberación lleva como nombre “HH Acondicionamiento Físico Versión Alpha”. Las funcionalidades se describen y listan a continuación: es la misma lista que la segunda liberación, pero esta vez se toma en cuenta la información recolectada de la segunda liberación, además en este caso ya se tienen las sugerencias del cliente que solicita la ayuda del equipo de desarrolladores, que a través del “Product Owner” se hace llamado al equipo de trabajo y se pone en marcha las mejoras y modificaciones de las historias o funcionalidades planteadas en la segunda liberación.

• Pagar el monto sugerido y votado de membresía: con base en la segunda liberación se obtiene servicio de recursos de entrenamientos personalizados para los usuarios.
• Inscripción de entrenador en la plataforma: igualmente con la información recolectada de la anterior liberación, se ofrecen los servicios y generan ingresos por ello.
• Acceso al catálogo de entrenamientos: de la misma forma, con la información que se obtiene de la liberación de la versión 1.2, se obtiene la calendarización óptima para entrenamientos y selección de entrenador para usuarios. 
• Acceder al módulo de entrenamientos: con la información obtenida en la segunda liberación se procede a grabar el entrenamiento para otros miembros de la plataforma que pagan por él.
• Tener acceso al módulo de pago: en la segunda liberación se obtiene información relevante con el fin de que los entrenadores perciban remuneración por los servicios que brinda.
• Crear un algoritmo de conexión con empresa BWW optimizado: con base en la segunda liberación, se obtienen las cuentas IBAN de los entrenadores para proceder a su pago respectivo. Pero esta vez, optimizada la codificación para un mejor desempeñó. 
• Generar un algoritmo de premios: con base en la última funcionalidad de la segunda liberación, se premian a los usuarios que graban sus entrenamientos y concursan en el módulo de premios. 

En seguida la justificación del orden de la liberación. Al igual que la segunda liberación, su justificación se basa en la dependencia una funcionalidad de la otra, desde la primera de ellas hasta la tercera y cuarta función y así sucesivamente hasta la última de ellas. Por supuesto, y es necesario aclarar, que dependiendo del “feedback” que se obtiene de la segunda liberación pues el resultado final va a mejorar en su calidad, tanto en la interfaz gráfica como en la eficiencia de la codificación en el “back-end” de cada módulo y algoritmo que  se utilice dentro de ellos.

2. El departamento de tecnologías de información de HH está rezagado en cuanto a prácticas modernas de desarrollo de software. Lo único con lo que cuentan es con un repositorio central donde se integra el código. No se cuenta con ningún servidor de compilación y validación centralizada de código. Tampoco se cuenta con ninguno de los elementos recomendados por Fowler en su artículo sobre integración continua. Usted quiere alertar a la gerencia de HH sobre la necesidad de invertir en herramientas que apoyen el proceso. Ante esta situación, usted debe hacer un análisis de riesgos existentes al no contar con herramientas de este tipo. Realice una investigación sobre el manejo de riesgos en un proyecto de desarrollo de software y con base a su investigación identifique 3 riesgos que se podrían experimentar ante la carencia de este tipo de técnicas:

A continuación se describe una síntesis del manejo de riesgos en el desarrollo de sistemas, basados en el artículo del autor Sánchez-Barreiro (s.f.) donde basa el manejo de riesgos en una serie de parámetros que se deben tener presentes para un desarrollo óptimo de un sistema en desarrollo. El autor menciona que los pilares u objetivos principales para evitar la mayor cantidad de riesgos son: “1 Establecer un Plan General de Riesgos. 2 Identificar Riesgos. 3 Análisis Cualitativo de Riesgos. 4 Análisis Cuantitativo de Riesgos. 5 Plan de Respuesta a Riesgos. 6 Control de Riesgos.” (pág. 7). Entonces, el mismo autor menciona que para establecer un plan de riesgos general se deben realizar las siguientes tareas: 

• Organigrama para la gestión de riesgos. 
• Proceso de identificación y análisis de riesgos. 
• Herramientas y técnicas a utilizar. 
• Taxonomías de riesgos a utilizar. 
• Plantillas estandarizadas para la identificación y gestión de riesgos (Registro Riesgos). Actividades de control de riesgos y periodicidad de las mismas. 

En cuanto a la identificación de riesgos, se recomienda emplear el uso de varias técnicas tales como: la revisión de la documentación existente, también la revisión planificación y estimaciones; además de la tormenta de ideas, entre otras. 

Por otra parte, el análisis cualitativo de riesgos menciona Sánchez que significa la definición de manera cualitativa de la prioridad de cada uno de los riesgos, igualmente se puede utilizar varias técnicas como tablas de impacto, agrupación por causas y prioridad temporal entre otras. 

Referente al análisis cuantitativo de riesgos, el mismo autor explica que este tema se centra en la medición precisa del impacto y la probabilidad en la ocurrencia de un riesgo. 

Para poder manejar y tener un plan de contingencia contra riesgos, más adelante el autor mencionado con anterioridad menciona lo siguiente “Atenuar la probabilidad o el impacto de los riesgos mediante la inserción de actividades y recursos en la planificación del proyecto.” (pág. 27).

Por último, para controlar uno o varios riesgos Sánchez enumera los objetivos que se deben considerar, entre los cuales destacan los siguientes: “Actualizar el registro de riesgos conforme avanza el proyecto, identificando, analizando nuevos riesgos que pudiesen emerger, elaborando nuevas respuestas para tales riesgos. 2 Comprobar si han materializado alguno de los riesgos identificados; y si fuese así, ejecutar los correspondientes planes de respuesta. 3 Realizar el seguimiento de los planes de respuesta en ejecución. 4 Administrar el fondo de reserva para contingencias. ”. (pág. 30).

Es importante mencionar algunas de las técnicas que menciona el autor Desarrollo Web (2019), donde considera como referencia principal a Martin Fowler,  y hace mención al uso de herramientas y técnicas en el desarrollo de software con el método de Integración Continua. Como eje vital de esta metodología de desarrollo se debe mencionar su definición, la cual el mismo autor explica de la siguiente manera “La integración continua es una práctica del desarrollo de software ágil en la que los ingenieros van integrando los fragmentos de código que desarrollan poco a poco en lugar de hacerlo una vez concluido todo el proyecto.” (par. 6). Por otra parte, las características principales de este método se listan a continuación según el mismo autor son:

• Único código fuente: todos los integrantes del equipo de programadores deben utilizar el mismo repositorio.
• Automatizar la compilación del proyecto: mediante un solo comando se debe compilar los ficheros y las bases de datos.
• Sistemas que realizan sus propias pruebas: uso de un plan completo de sistema de pruebas. 
• Integración diaria: todos los miembros del equipo de programación deben integrar su codificación diariamente para evitar errores de compilación u otros.
• Main line operativa: el código de la línea principal se prueba constantemente siendo operable siempre. 
• Reparación inmediata:la reparación de las líneas de código se corrigen inmediatamente, no permitiendo errores.
• Integración rápida: las pruebas se realizan en dos fases para acelerar el proceso. La primera, pruebas rápidas de la compilación del proyecto. Y la segunda, tarda generalmente varias horas y se realizan pruebas exhaustivas. 
• Pruebas en una réplica del entorno de producción: mediante equipo virtual se realizan pruebas en un “ambiente” seguro y con la configuración igual al entorno de producción.
• Accesibilidad:
• Buena comunicación: esto significa la documentación de cada proceso o línea de código que realice cada miembro del equipo de desarrolladores, quedando claro para todo el equipo lo que se realiza constantemente en el proyecto. 
• Despliegue automatizado: para acelerar este proceso de pruebas de ejecutables en múltiples entornos, se utilizan scripts que lo faciliten. 

Algunas de las ventajas y desventajas del uso de esta metodología de Integración Continua son las siguientes. Entre los principales beneficios del uso de este método se encuentran la detección temprana de errores, la comunicación constante, se evita una integración final de gran envergadura y el registro exacto de las modificaciones, entre otros. Contrariamente, algunas de las principales desventajas son el cambio de procesos habituales, la precisión de servidores y entornos adicionales y la elaboración de un plan de pruebas propio, entre otros.    

Ahora, con base en la síntesis de la gestión de la administración de riesgos en el desarrollo de sistemas o software y la descripción de algunas técnicas que se utilizan en el desarrollo de software basados en la Integración Continua, se identifican los siguientes riesgos que están presentes en el caso hipotético de “HH”. Seguidamente la tabla 1 “Identificación de riesgos” con el contenido de los posibles riesgos:  

Tabla 1.

Descripción delriesgo	Nivel de impacto	Probabilidad	Acción de mitigación	Acción de contingencia
Promoción de la aplicación en redes sociales	Alto	Medio	Pago de profesionales en marketing digital	Entrenamiento autodidacta al personal encargado de redes sociales
Recursos económicos limitados	Alto	Alto	Definir Android como primer sistema operativo	Investigar a profundidad quienes y cuantos usuarios prefieren este tipo de aplicación en ambos sistemas operativos
Pago a entrenadores	Medio	Medio	Asesoría legal para políticas de internacionales de impuestos	Crear una pasarela de pago alternativa como PayPal por ejemplo

Identificación de riesgos.

3. La gerencia de HH está entusiasmada porque ha escuchado en diferentes fuentes de las grandes ventajas que tienen los negocios al implementar despliegue continuo en sus procesos de desarrollo de software. No obstante, usted nota que la gerencia utiliza a veces el término “despliegue continuo” y “entrega continua” de manera indistinta, como si fueran sinónimos. Para evitar una confusión y alinear expectativas usted debe preparar una explicación con sus propias palabras de cada uno de esos dos términos para que la gerencia lo tenga más claro para lograr comprender qué es lo que buscan. Explique de manera amplia y detallada ambos conceptos de la siguiente manera:

a. Definición amplia y detallada con sus propias palabras, pero apoyándose en al menos una referencia del curso y una referencia externa a las ofrecidas en el curso.

b. Dos ventajas de la práctica.

c. Una desventaja de la práctica.

d. Una descripción de sus propias palabras de cómo el proyecto de HH podría verse beneficiado al incorporar dicha práctica.

Para aclarar la posible confusión de los conceptos “despliegue continuo” y “entrega continua”, en primer lugar se describen las definiciones respectivas, luego dos de sus ventajas y una desventaja; y por último, el beneficio que podría obtener el proyecto del caso hipotético “HH” al implementar el “despliegue continuo”. 

En primer lugar, la definición de la  técnica “despliegue continuo”, según el autor Stumm (2016), significa el proceso de despliegue de un programa en la etapa de producción de manera rápida e iterativa, las veces que lo permita la metodología ágil. A continuación dos de las principales ventajas de este tipo de técnica, basados en el autor Esteban (2013), se listan en seguida: 

• Se simplifica todo. No hay versiones y por tanto no hay equívocos. Lo que está en la rama de producción es lo que está desplegado en producción.
• Las funcionalidades que ya están completas se suben a inmediatamente a producción y el usuario puede utilizarlas antes.

Una desventaja clara es que el cambio constante y diario podría generar disgusto entre algunos miembros del equipo de desarrolladores, al testear día tras día talvez algunas líneas de código que ya están optimizadas. 

En segundo lugar, la definición de la técnica de “entrega continua” es la siguiente. Según el autor Humble (2017), el concepto de esta técnica lo describe como la habilidad de obtener cambios de toda clase de tipos en la etapa de producción e incluso en manos de los clientes o usuarios, y estos van desde nuevos parámetros, cambios de configuración, y corrección de errores; todo esto haciéndolo de una manera segura, rápida y sustentable. El mismo autor más adelante menciona dos de los principales beneficios de la implementación del uso de esta técnica, se listan a continuación:

• Liberaciones de poco riesgo. El objetivo principal de la “entrega continua” es desplegar el programa lo mejor y más rápido posible.
• Equipo de trabajo más satisfecho: al hacer liberaciones continuas, los programadores están en más contacto con los usuarios determinando así cuáles funcionalidades están ejecutándose bien y cuáles no.

Una de las principales desventajas del uso de la “entrega continua” radica en el proceso repetitivo del constante despliegue del programa, causando alguna “perdida” de tiempo para los programadores, esto en el caso de programadores con pocas habilidades blandas que prefieren no contactar con terceros mientras realizan su trabajo de codificación.

Por último, ahora que se sabe la diferencia entre los conceptos “despliegue continuo” y “entrega continua”, se puede afirmar que el beneficio claro y más importante, para el proyecto del caso hipotético de “HH”, radica en que se puede eliminar el riesgo de poder implementar una codificación rápida, eficiente y económica, eliminando versiones extra del programa, determinando cuáles funcionalidades están correctas y eliminando todo aquello del sistema que no se necesite, esto se sabe del usuario al poder utilizar la aplicación en un tiempo corto, y así se salvaría recursos económicos, valga la redundancia, de la empresa y así poder invertir en ambos sistemas operativos, Android y iOS. 

4. Investigue el formato de un caso de prueba usado para probar un escenario específico de una funcionalidad. Se le recomienda investigar al menos 3 fuentes bibliográficas externas que le permitan comprender las secciones que comprenden estos documentos. Con base a su investigación defina 2 casos de prueba para la funcionalidad “Registrar entrenador”. El caso de prueba debe ser completo y detallado, y contemplar todas las secciones necesarias para un artefacto de este tipo.  

Para entender con claridad como funcionan los casos de prueba se debe empezar por una definición y cuál es su propósito, entonces procedamos a ello, según el autor Martínez-Pineda (2020), dice que un caso de pruebas consiste en “Un conjunto de pasos y resultados esperados que se crean a partir de los requisitos del software que se va a probar.” (pág. 4). Por otra parte, el autor Gómez (2021) dice que además de ser un conjunto de elementos que verifican la funcionalidad de un método de un software, este debe cumplir con una serie de parámetros para un mejor desempeño; entre los que destaca la siguiente lista con sus respectivas descripciones:

• “Identificador: Puede ser numérico o alfanumérico (la mayoría de herramientas lo generan solo).
• Nombre del caso de prueba: Debe ser conciso. Se debe utilizar una nomenclatura que esté definida, pero si no existe una, lo recomendable es incluir el nombre del módulo al que corresponde el caso de prueba.
• Descripción: La descripción debe decir qué se va a probar, en algunos casos, en esta sección se incluye el ambiente de pruebas, la data y las precondiciones o asunciones.
• Pasos: Son las acciones que se deben realizar para obtener los resultados.
• Resultados esperados: es lo que le indica al tester cuál debería ser la experiencia luego de ejecutar los pasos y así determinar si el test falló o pasó.
• Estado y resultados actuales: No necesariamente van dentro del caso de prueba. Muchas herramientas incluyen estas informaciones asociadas al caso de prueba, o como un récord aparte.” (parr. 6).

Ahora, otro elemento importante para la comprensión definitiva del caso de prueba para el desarrollo de software es el siguiente, según el autor Hoogenraad (2018), las mejores técnicas o prácticas para el poner en funcionamiento de los casos de uso. En primer lugar, los casos de prueba deben ser simples y transparentes, es decir que se debe hacer uso de un lenguaje legible y claro para cualquier otro desarrollador y hasta para el usuario final. En segundo lugar, crear casos de prueba teniendo en cuenta la perspectiva del usuario final para definitivamente cumplir con las expectativas de sus requerimientos. En tercer lugar, se debe evitar la repetición de caso de prueba, si se tiene que hacer uno nuevo se debe hacer aparte. En cuarto lugar, no se debe abandonar la aplicación, esto significa no asumir “una aplicación en funcionamiento mientras prepara el caso de prueba. Cumpla con los requisitos y documentos de diseño.” (parr. 24). En quinto lugar, se encuentra proporcionar una cobertura del 100% y asegurarse de que todos los requisitos del sistema se cumplan a cabalidad. En sexto lugar, los casos de prueba deben ser identificables, es decir que deben tener un “ID” propio para una mejor depuración del sistema. En séptimo lugar, el caso de prueba debe ser repetible y autónomo, es decir que siempre genere los mismos resultados independientemente de quien los utilice y ponga en funcionamiento. Por último, se debe proceder a una revisión de los casos de prueba por pares, esto se refiere a que si un desarrollador crea un caso de uso, este debe ser revisado por otro colega para verificar que no haya errores en él.

Seguidamente se procede a presentar dos casos de prueba basados en el caso hipotético “HH”, ambos se basan en la síntesis de la investigación expuesta con anterioridad y se presentan en la siguiente tabla 2 “Casos de Prueba”.

Tabla 2:

ID	Nombre	Descripción	Pasos	Resultados esperados	Estado y resultados actuales
1	Registrar entrenador – Módulo de entrenadores	El usuario que se registre como entrenador se debe registrar en el sistema y cumplir una serie de requisitos.	1. Insertar datos: nombre, primer apellido, segundo apellido, país, número de identificación, fecha de nacimiento, correo electrónico, número de cuenta IBAN al que desea que le depositen, fotografía.2. Verificar datos.3. Verificar edad entrenador.4. Verificar IBAN de entrenador.5. Dar click en el botón de Registrarse.	La expectativa es que los datos que proporciona el entrenador son reales, y mediante los algoritmos de verificación se verifican su autenticidad.	Éxito. Resultados esperados.
2	Programar entrenamiento – Módulo de entrenadores	Una vez que el usuario entrenador se registra debe proceder a programar los entrenamientos que va a impartir en la plataforma.	1. Insertar tipo.2. Insertar equipo requerido.3. Insertar nivel.4. Insertar publico recomendado.5. Insertar fecha y hora.6. Insertar duración aproximada del entrenamiento.7. Verificar datos insertados.8. Hacer click en el botón programar entrenamiento.	Se espera que el entrenador al programar sus entrenamientos, provea los elementos necesarios para cada entrenamiento, de esto se encargan precisamente los algoritmos de verificación respectivos en esta etapa o módulo de la plataforma.	Éxito. Resultados esperados.

          Casos de Prueba

5. Suponga que se quiere iniciar con la práctica de TDD en el departamento de TI de “HH”. Para esto, el personal de desarrollo ha implementado el siguiente “cascarón” de código con el siguiente método.

Código:

public ​ boolean ​ LaEdadDelEntrenadorEsValida(​ int ​ laEdadDelEntrenador)

{

​ /* Este método debe revisar la edad del entrenador y determinar si

se debe permitir su registro en el sistema

Si la edad es menor a 18, devuelve FALSE

En caso contrario devuelve TRUE */

throw​ ​ new​ Exception(​ “No implementado”​ );

}

Tome en cuenta que lo único que existe es el cascarón del método descrito en el Cuadro 1. Con base a la información brindada, responda las siguientes preguntas:

a. Según lo estipulado por la técnica de desarrollo guiado por las pruebas explicado por la literatura de Ian Sommerville (Sommerville, 2011), explique con sus propias palabras qué pasos se deberían llevar a cabo para lograr la implementación correcta de estos métodos.

A continuación se procede a identificar y describir las etapas fundamentales para un óptimo desarrollo dirigido por “test” en la construcción de programas informáticos. Según el autor Summerville (2011) los pasos que se tienen que tomar en cuenta para un desarrollo guiado de diseño de “software” son los siguientes; en primer lugar, identificar la funcionalidad nueva, generalmente este requiere de una codificación pequeña y aplicable. En segundo lugar, se procede a escribir la prueba, esto significa describir la prueba para la funcionalidad seleccionada y esta debe contener una implementación automatizada; independiente de su fallo o éxito al final de la prueba. En tercer lugar, se hace un “run” de la prueba correspondiente en paralelo con las demás pruebas implementadas, se debe tomar en cuenta que la primera vez que se ejecuta la prueba va a generar un fallo. En cuarto lugar, luego de la falla de la prueba primera, se vuelve a implementar la prueba de la funcionalidad, aquí se puede incluso agregar o modificar o eliminar líneas de código al existente para mejorar la funcionalidad. Por último, se procede a implementar la siguiente funcionalidad luego de obtener éxito en las pruebas. 

b. Proponga 2 pruebas unitarias que realizaría sobre el método ​ LaEdadDelEntrenadorEsValida​. No es necesario que las programe, solo describa qué objetivo tendría cada prueba. Describa también qué debe cumplirse para que la prueba sea exitosa. Adicionalmente, indique un posible defecto que sería capturado por la prueba. 

Respecto a la primera prueba unitaria, en primer lugar el objetivo principal que se persigue es el de verificar si es o no verdad que el usuario entrenador es mayor de edad. Prosiguiendo, la descripción de las características que se deben cumplir para que la prueba sea exitosa: 

• Por defecto una variable tipo boolean se establece su valor como false.
• Se debe tomar en cuenta que el número entero que entra por parámetros debe ser mayor que cero y si no simplemente devuelve un false.
• El valor de la variable boolean solo cambia a true si se cumple la siguiente condición: el número que entra por parámetros debe ser mayor o igual a 18.
• Se controla una excepción si el número que entra por parámetros es negativo y se envía un mensaje con la descripción del error, dirigido al usuario. 

Y por último, una posible excepción que se podría capturar es la siguiente; si afuera del método o función no se tiene control de sí el número entero es negativo, porque podría pasar que por algún motivo el usuario se equivoque al digitar su edad, entonces ese error si no se controla dentro del método o función actual, pues va a generar una excepción o error en el sistema.  

Referente a la segunda prueba unitaria, el objetivo fundamental de la misma consiste en verificar al mismo método o función; es decir que se captura una excepción de error si se detecta un número negativo que entre al método. Seguidamente, la descripción de las características que se deben cumplir para que la prueba sea exitosa: dependiendo del lenguaje de programación que se utilice, se debe controlar o capturar la excepción o error que se genere durante el proceso de la actual función o método.       

Para finalizar, una posible excepción que se podría capturar es la siguiente; como se está fuera del método o función y no se tiene control de sí el número entero es negativo, porque podría pasar que por algún motivo el usuario se equivoque al digitar su edad, al igual que en la primera prueba, entonces ese error si no se controla fuera del método o función, pues va a generar una excepción o error en el sistema. 

6. Investigue sobre métricas usadas para apoyar el proceso de desarrollo software. Con base a su investigación seleccione 3 que considere que podrían aportar más valor a su proyecto en términos de calidad. Además, explique cada una de las métricas. La explicación debe incluir una indicación de cómo se calcula. Finalmente, en el contexto del proyecto de la empresa “HH”, justifique cómo la métrica podría apoyar al proceso de desarrollo de software.

El desarrollo de software conlleva muchos parámetros que se deben tomar en cuenta para obtener una calidad óptima y entregar o liberar un proyecto eficiente y “bonito” para el usuario final. Según el autor García-Sánchez (2010) las métricas “tratan de servir de medio para entender, monitorizar, controlar, predecir y probar el desarrollo software y los proyectos de mantenimiento” (pág. 7).

Más adelante el mismo autor identifica y explica tres de los principales objetivos de las métricas utilizadas para obtener un software o sistema con una calidad buena. En seguida se listan los objetivos: 

• Entender qué ocurre durante el desarrollo y el mantenimiento. 
• Controlar qué es lo que ocurre en nuestros proyectos. 
• Mejorar nuestros procesos y nuestros productos. 

Algunos de los beneficios que se obtienen del uso de las métricas de calidad de programas son las siguientes, según el autor Barrientos (2018); en primer lugar, el retorno de la inversión del proyecto pues se identifican funcionalidades que se pueden mejorar, al igual que se optimiza el tiempo de desarrollo y pruebas, y reduce el costo de operación. En segundo lugar, mejora la comunicación con el dueño del proyecto o cliente, ya que mejora la estimación del tiempo de entrega del proyecto y a su vez se priorizan las funcionalidades realmente importantes. Por último, se optimiza el código, quedando una codificación eficiente, clara y “limpia”. 

Por otra parte, tres de las métricas que utilizan los desarrolladores de software según el autor García-Sánchez (2010), son las siguientes, estas son basadas en las métricas CK Chidamber y Kemerer, todas orientadas a objetos:

Métodos ponderados por clase (WMC: Weighted Methods per Class): funciona de la siguiente manera: calcula la suma de la complejidad ciclomática de los métodos de una clase y se calcula de la siguiente manera: WMC=∑i..n mci, siendo mci la complejidad ciclomática del método i. El WMC debe ser lo más bajo posible. Cuanto más alto es el valor WMC, más complejo el árbol de herencia y menos reutilizable. Las interpretaciones de este tipo de métrica son las siguientes: 

“El número y la complejidad de los métodos son indicadores del tiempo necesario para desarrollar/mantener la clase. Cuanto mayor sea el nº de métodos mayor impacto potencial tendrá en los hijos, sus herederos potenciales. Las clases con gran nº de métodos serán de aplicación específica, y por lo tanto más difíciles de reutilizar.” (pág. 9-10). 

Número de hijos inmediatos en el árbol de herencia (NOC: Number Of Children): una clase es más reutilizable entre mayor sea el valor de NOC, pero a su vez la probabilidad de que haya extensiones no apropiadas de la clase es mayor igualmente. Las principales interpretaciones de estas métricas son las siguientes:

“Cuanto mayor sea NOC más reutilización habrá por herencia. Si NOC es muy grande hay un fallo en la abstracción de la clase padre, falta algún nivel intermedio. NOC da una idea del peso que la clase tiene en el diseño, y de los recursos que se deben dedicar a probar sus métodos”(pág. 10).

Acoplamiento entre clases (CBO: Coupling Between Object Classes): esta métrica consiste en el número de clases acopladas en una clase. Algunas características de esta métrica son las siguientes: 

“Dos clases están acopladas cuando los métodos de una de ellas usan variables o métodos de una instancia de la otra clase. Si existen varias dependencias sobre una misma clase es computada como una sola. No es deseable que CBO > 14. Cuanto más alto es el más difícil será el mantenimiento y el reuso y en general el código será más propenso a fallos.” (pág. 10).

Las principales interpretaciones de esta métrica son las siguientes:

• Cuanto mayor es CBO, peor es la modularidad y la reutilización. 
• Cuanto mayor es CBO, peor es el encapsulamiento y más cuesta mantenerlo.

Por último, una de las métricas que se podría implementar en el caso hipotético “HH” para darle soporte y entregar un proyecto óptimo al usuario o cliente que requiere los servicios es el siguiente; la primera que se describió con anterioridad “Métodos ponderados por clase”. Ahora, esta métrica puede dar el soporte más óptimo porque el proyecto no están extenso y al esta métrica apoyarse en el concepto de la cantidad de métodos por clase, por ende al proyecto no poseer una lista de funcionalidades tan extensa, en este caso es relativo, ya que es una aplicación móvil para Android no tan pesada, pero si eficiente, va a poderse calcular la complejidad de las clases del proyecto y así determinar un estimado de tiempo para el desarrollo completo del proyecto. Con esto se consigue de inmediato el tiempo para la elaboración del proyecto, así la planeación de las demás etapas se facilita mucho más.

7. Realice una investigación de 2 herramientas existentes en el mercado para apoyar a las empresas en lograr la técnica de la integración continua explicada por Martin Fowler (Fowler, 2006). Estructure su respuesta de la siguiente manera:

a. Explicación detallada y con sus propias palabras de qué hace la herramienta y qué funcionalidades ofrece.

A continuación la primera herramienta de integración continua que da soporte a las empresas desarrolladoras de software. Su nombre en el mercado es conocido como “Jenkins”; basados en el autor Jenkins (s.f.), esta herramienta es un servidor de automatización independiente y de código abierto, que puede utilizarse para automatizar toda clase de labores en relación con la construcción, las pruebas y la entrega o el despliegue de programa. Las funcionalidades principales que ofrece esta herramienta se presentan en la siguiente lista basada en el autor Capterra (2021):

• API
• Autenticación
• Control de versiones
• Controles o permisos de acceso
• Entrega continua
• Gestión de aplicaciones
• Gestión de pruebas de software
• Gestión de tests
• Gestión del pipeline
• Implementación continua
• Panel de actividades
• Proyecciones
• Supervisión  

A continuación la segunda herramienta de integración continua que da soporte a las empresas desarrolladoras de software. Su nombre en el mercado es conocido como “GitLab CI”, según el autor Alex (2019), esta herramienta consiste en “permite a los equipos construir, probar y liberar software a un ritmo más rápido. CI/CD trata de quitar las interacciones humanas manuales donde es posible — automatizando todo excepto la entrega final manual de código a producción.” (parr. 1). Las funcionalidades principales que ofrece esta herramienta se presentan en la siguiente lista basada en el autor Capterra (2021):

• API
• Autenticación
• Control de procesos de aprobación
• Controles o permisos de acceso
• Creación de informes/análisis
• Depuración
• Entrega continua
• Flujo de trabajo basado en reglas
• Garantía de calidad
• Gestión de configuración
• Gestión de flujos de trabajo
• Gestión de la conformidad
• Gestión de modelos
• Gestión de problemas
• Gestión de proyectos
• Gestión de tests
• Gestión del cambio
• Gestión del ciclo de vida
• Implementación continua
• Integraciones de terceros
• Proyecciones
• Seguimiento de actividades
• Seguimiento de hitos
• Seguimiento de problemas
• Supervisión

b. Ilustre la herramienta con 2 imágenes de pantallas que ofrece, describa cada imagen.

GitLab CI: Imagen 1:

Escritorio principal de GitLab

Referencia: propia.

Esta es una imagen que presenta el escritorio principal de la plataforma o sistema de GitLab CI, en el cual se puede observar, que en la parte superior derecha se puede configurar el usuario y sus propiedades como administrador, en la parte superior izquierda se observa un menú de proyectos, en el centro del escritorio se visualizan varias opciones; una para crear un grupo para administrar diferentes dependencias de proyectos. Igualmente, en la parte central de la pantalla, pero en la parte inferior, se observa una sección donde se puede crear un proyecto nuevo. 

Imagen 2:

Sección de proyectos

Referencia: propia

En esta sección de la plataforma se tiene acceso a varias características con las que debe contar un proyecto nuevo “colgado” en el sistema. Por ejemplo: tiene el “path” del proyecto, ya que funciona como un servidor, tiene un nombre de proyecto; ambas partes en la parte superior de la pantalla. Luego, seguido del “path” y el nombre se encuentra un enlace donde se puede acceder a la creación de un grupo para administrar diferentes dependencias de proyectos. Después de este enlace, existe una serie de opciones para cargar un proyecto nuevo desde otra plataforma que funciona vinculada con GitLab, después sigue una caja de texto para ingresar una descripción del proyecto nuevo, y justo después se le da una visibilidad al proyecto, ya sea privado, interno o público; y por último un botón de creación del proyecto nuevo. 

Jenkins: Imagen 3:

Escritorio Principal Jenkins

Referencia: propia

Aquí se puede observar el escritorio principal de la plataforma o sistema “Jenkins”, en la parte superior derecha se puede configurar el perfil del usuario administrador. En la parte izquierda de la pantalla se encuentra el menú principal de la plataforma, donde se encuentran varias secciones: puede crear una nueva tarea, personas, historial de trabajos, administra Jenkins, mis vistas, credenciales, localización de recursos, nueva vista, trabajos en la cola y el estado de las diferentes construcciones o proyectos actuales.  

Imagen 4:

Administración de Jenkins

Referencia: propia

En esta imagen se puede observar las siguientes características. Para administrar Jenkins es necesario “clikear” en el menú principal “Administrar Jenkins”, una vez en esta sección se pueden hacer varias configuraciones tales como: el sistema, la seguridad global, credenciales, herramientas globales, también se puede actualizar la configuración desde el disco duro, administrar plug-ins, se encuentra la información del sistema y estadísticas de carga.  

Conclusiones

Seguidamente se hace un breve descripción de las conclusiones del actual proyecto. En primer lugar se logra compilar con éxito la información relevante para contestar a las preguntas con la puntualidad de cada caso. En cada respuesta se logra sintetizar cada “mini” investigación para cada caso o pregunta, tales como: liberaciones de un proyecto, despliegue continuo, entrega continua e integración continua; por otra parte, casos de prueba, prácticas TDD, métricas para el apoyo de desarrollo de software y herramientas de integración continua que utilizan empresas de desarrollo actualmente.

Por otra parte, se determinan positivamente conceptos significativos durante el desarrollo del proyecto, con los cuales se tiene un panorama global mucho más claro luego de la conclusión del proyecto, entre los conceptos que se describen y que son muy relevantes para la carrera de ingeniería de software son los siguientes: integración continua, despliegue continuo, y entrega continua, al igual conceptos como las métricas para el desarrollo de programas y técnicas como TDD para el testeo de funciones de una aplicación, además herramientas muy útiles para el desarrollo de software como “Jenkins” y “GitLab”, que también son de código abierto.  

También, se logra dar entendimiento práctico como por ejemplo los ejercicios prácticos como los de las preguntas 1, 2, 4 y 5. Es así la única forma de poder entender a profundidad un tema teórico, pero que en la práctica, igual que la programación, se comprende o queda un poco más claro. 

Referencias Bibliográficas 

Nué, E., y Malnati, M. (s.f.). PRODUCTO MÍNIMO VIABLE – CUSTOMER DEVELOPMENT + LEAN STARTUP. [archivo PDF]. Recuperado de https://www.ulima.edu.pe/sites/default/files/page/file/13_mvp_workshop.pdf

Sordo, A. (19 de enero de 2021). MVP: 3 pasos para desarrollar un Producto mínimo viable. Recuperado de https://blog.hubspot.es/sales/producto-minimo-viable

Schwaber, K., y Sutherland, J. (2017). La Guía de ScrumTM. [archivo PDF]. Recuperado de https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf

Sánchez-Barreiro, P. (s.f.). Ingeniería del Software II – Tema 07. Gestión de Riesgos en Proyectos Software. [archivo PDF]. Recuperado de http://www.elmayorportaldegerencia.com/Documentos/Gestion%20de%20Riesgos/[PD]%20Documentos%20-%20Gestion%20de%20riesgos%20en%20proyectos%20de%20software.pdf

Desarrollo Web. (4 de abril de 2019). La integración continua en el desarrollo de software

. Recuperado de https://www.ionos.es/digitalguide/paginas-web/desarrollo-web/integracion-continua/

Stumm, M. (2016). Continuous deployment at Facebook and OANDA. [archivo PDF]. Recuperado de https://www.researchgate.net/publication/303296480_Continuous_deployment_at_Facebook_and_OANDA

Esteban, M. (17 de noviembre de 2013). De despliegue continuo y de responsabilidad personal. Recuperado de https://www.logicaalternativa.com/de-despliegue-continuo-y-de-responsabilidad-personal/

Humble, J. (2017). Continuos Delivery. Recuperado de: https://continuousdelivery.com/

Gómez, C. (22 de marzo de 2021). Cómo hacer caso de prueba. Recuperado de https://www.diariodeqa.com/post/buenas-pr%C3%A1cticas-al-escribir-casos-de-prueba

Hoogenraad, W. (1 de julio de 2018). Casos de pruebas, ejemplos y mejores prácticas. Recuperado de https://es.itpedia.nl/2018/06/01/testcases-voorbeelden-en-best-practices/

Martínez-Pineda, C. (2020). GUÍA PARA CREAR Y EJECUTAR CASO DE PRUEBA. [archivo PDF]. Recuperado de https://colaboracion.dnp.gov.co/CDTI/Oficina%20Informatica/Sistemas%20de%20informaci%C3%B3n/Gu%C3%ADas%20Formatos%20Plantillas/Guia%20%20para%20Crear%20y%20Ejecutar%20casos%20de%20Pruebas.pdf?

Summerville, I. (2011). Ingeniería de Software. [archivo PDF]. Recuperado de https://sistemamid.com/panel/uploads/biblioteca/2018-06-11_03-37-12144643.pdf

Barrientos, D. (11 de octubre de 2018). MÉTRICAS DE CALIDAD DE SOFTWARE. Recuperado de https://blog.desafiolatam.com/metricas-de-calidad-de-software/

García-Sánchez, A. (2010). Evaluación de métricas de calidad del software sobre un programa Java. [archivo PDF]. Recuperado de https://core.ac.uk/download/pdf/19714326.pdf

Jenkins. (s.f.). Jenkins User Documentation. Recuperado de https://www.jenkins.io/doc/#jenkins-user-documentation

Capterra. (2021). ¿Qué es Jenkins?. Recuperado de https://www.capterra.ec/software/171026/jenkins

Capterra. (2021). ¿Qué es GitLab?. Recuperado de

https://www.capterra.ec/software/159806/gitlab

Alex. (9 de noviembre de 2019). Introducción a CI/CD con GitLab. Recuperado de https://alexmarket.medium.com/introducci%C3%B3n-a-ci-cd-con-gitlab-23d4e9cc6482

Caso práctico: HH (Health at Home)

El siguiente caso práctico plantea una situación hipotética y será utilizado como insumo para los proyectos del curso. Realice una lectura minuciosa del mismo para dar cumplimiento a los proyectos del curso. 

Introducción

La empresa Health at Home (salud en casa), en adelante HH, es una empresa de acondicionamiento físico cuya misión es posicionarse a nivel mundial como la compañía de fitness número 1 en el mundo entero. Para lograrlo han planteado la idea de implementar una aplicación para smartphones cuyo objetivo principal es ofrecer un servicio de entrenamientos en línea.

La idea es que los usuarios paguen una membresía mensual de $10 que les dará acceso a una cantidad enorme de recursos que les permitirá desarrollarse en alguno de numerosos programas personalizados y con instructores en línea. 

Para lograrlo, utilizarán el modelo de red social y colaboración masiva para dar una oferta única y variada a sus clientes, a la vez de que quienes colaboran pueden acceder a una remuneración económica (al estilo de Uber) (Uber, 2020).

Todo esto lo desean realizar a través de una aplicación para iOS y Android. No obstante, los recursos económicos con los que cuenta la empresa son limitados y no se tiene certeza clara de cuál de los dos sistemas operativos debería usarse para desarrollar en su etapa inicial.

Módulo de entrenadores

En este módulo se inscriben usuarios que desean dar sus servicios de entrenamiento en la plataforma. Para esto, el usuario debe ingresar a la aplicación e ingresar sus datos completos: nombre, primer apellido, segundo apellido, país, número de identificación, fecha de nacimiento, correo electrónico, número de cuenta IBAN al que desea que le depositen, fotografía. La compañía no tiene certeza total de si estos datos serán suficientes para tramitar un pago en línea, por lo que hay incertidumbre sobre esta funcionalidad del sistema. Se sabe que el departamento de pagos de HH cuenta con personal calificado que podría aclarar este punto.

Además de las validaciones básicas en todos los campos, el sistema tiene como requisito que los entrenadores sean mayores a 18 años, además de verificar la validez de la cuenta IBAN, para lo cual se debe consumir un Web Service externo ofrecido por una empresa externa llamada Bank World Wide (en adelante BWW) que recibe el número de cuenta IBAN y verifica que el mismo sea válido y que corresponda a una cuenta activa. 

Al concluir con las validaciones, el sistema procede a crear la cuenta del usuario.

Una vez registrado el entrenador puede programar sesiones de entrenamiento en vivo. Para programar un entrenamiento se debe indicar:

• Tipo: aeróbico, pesas, cardiovascular, funcional, crossfit, entre otros.
• Equipo requerido: se despliega una lista de artículos requeridos como ligas, mancuernas, barras, bandas, kettlebells, cuerda de saltar (se pueden seleccionar múltiples opciones).
• Nivel: principiante, intermedio, avanzado.
• Público recomendado: público en general, hombres, mujeres, jóvenes, adultos mayores, personas con mala condición física, atletas de alto rendimiento. 
• Fecha y hora del entrenamiento: debe programarse con al menos 7 días de antelación. 
• Duración aproximada del entrenamiento en minutos. 

Módulo de usuarios

En este módulo se inscriben usuarios que desean entrenar en la plataforma HH. Para inscribirse deben indicar los mismos datos de los entrenadores, excepto la cuenta bancaria que no se requiere pues los usuarios no son remunerados. A diferencia de esto el usuario debe registrar su tarjeta de crédito mediante la cual pagará su membresía mensual.

Una vez suscrito, el usuario tendrá acceso a un catálogo de entrenamientos todos los días. Para encontrar el entrenamiento adecuado el usuario puede filtrar el catálogo de entrenamientos de acuerdo con el equipo con que cuenta, el nivel, el público recomendado, la fecha en que desea entrenar y la duración aproximada. Todos los filtros son opcionales y al activar alguno de estos, el sistema refrescará la lista de entrenamientos disponibles.

El catálogo mostrará la lista de entrenamientos con toda su información, incluyendo una fotografía del entrenador y la puntuación de este, de 1 a 5 estrellas que se calcula como un promedio de la nota que le dan los usuarios.

El usuario puede seleccionar cualquiera de los entrenamientos e inscribirse al mismo.

Módulo de entrenamientos

En este módulo el entrenador accede a uno de los entrenamientos programados y el sistema le ofrecerá la opción de “iniciar entrenamiento”. Una vez realizado esto, el entrenador debe colocar el teléfono en una posición adecuada para transmitir en vivo su entrenamiento a través de la cámara.

El sistema procesará el vídeo capturado y lo transmitirá vía streaming a los usuarios que se hayan inscrito a ese entrenamiento. De esta forma, los usuarios tendrán acceso a estos entrenamientos en vivo y la idea es que participen durante el streaming haciendo los ejercicios realizados por el instructor. Al finalizar la sesión, se le solicitará al usuario indicar la calificación del trabajo del entrenador con una nota del 1 al 5.

Módulo de pagos

En este módulo el sistema realizará el pago para los entrenadores. El método de pago planteado es radical, haciendo que los mejores entrenadores sean los que reciban mayor remuneración. El cálculo se realiza de la siguiente manera: el 30% de los montos recibidos como membresía se distribuirán entre los entrenadores suscritos. Para cada usuario se determina los minutos que entrenó durante el mes y con qué entrenador, de manera que se distribuya de manera porcentual. Por ejemplo, suponga el caso de un usuario que entrenó 300 minutos durante el mes, entrenando 100 minutos con el entrenador “Carlos”, otros 100 minutos con la entrenadora “María” y otros 100 minutos con el entrenador “Andrés. El 30% de la membresía son 3 dólares, y en este caso dado los tres entrenadores tuvieron la misma cantidad de minutos, cada uno se lleva 1 dólar de la membresía de ese usuario. Está claro que los mejores entrenadores, es decir, aquellos que logren atraer a la mayor cantidad de usuarios a su programa, serán aquellos que reciban una mejor remuneración.

Para ejecutar el pago, en el backend de la plataforma tecnológica de HH existirá un proceso que realiza este cálculo para toda la población de entrenadores y realizará los pagos a las cuentas de los mismos. El equipo de desarrollo de software de HH no tiene claro aún cómo debería modelar este proceso a nivel del desarrollo de software, pues se cree que podría ser muy pesado y que además es sumamente delicado al tratarse de un procesamiento de grandes cantidades de dinero. 

Asuma que la empresa BWW ofrece un servicio Web que recibe un número de cuenta IBAN y un monto y tramita la transferencia. 

La conexión con el servicio de la empresa BWW será un enlace privado, asegurado con certificados digitales y con comunicación encriptada para reforzar la seguridad y privacidad de la información de los clientes de HH.

Aún existe un cierto grado de incertidumbre a nivel legal, pues no se tiene claro las posibles implicaciones de realizar pagos transnacionales a la comunidad de entrenadores. Existe una incertidumbre relacionada a la posibilidad de hacer esto en ciertos países con leyes restrictivas, así como las implicaciones desde la perspectiva de las políticas de impuestos de cada país. 

Módulo de premios

Si bien no forma parte de la funcionalidad básica del sistema, la administración de HH está interesada en tener un módulo que recompense a los usuarios con mayor progreso y constancia en la aplicación. Se espera que este sistema tenga un módulo que permita lograr este objetivo. El módulo de premios recompensará con descuentos a aquellos usuarios que tengan más minutos de entrenamiento cada mes. Para concursar, el usuario debe activar una opción en su perfil llamada “grabación de sesión”. Cuando se tiene esta opción activada, el sistema grabará los entrenamientos del usuario mientras los realiza. 

Entre los usuarios que tienen activada la opción, el sistema calcula cuales tuvieron más minutos de entrenamiento real en la aplicación. A los primeros 10, la administración les concederá premios y descuentos, entre otros. 

Inicialmente deberá haber una funcionalidad para que el personal de HH revise los vídeos de los usuarios con más minutos para verificar que efectivamente fueron minutos de entrenamiento reales. No obstante, se espera que las versiones avanzadas del sistema tengan un algoritmo de reconocimiento de vídeo que pueda analizar los vídeos automáticamente para evitar esta operativa por parte del personal administrativo de HH.