Caso práctico: Health at Home (HH)

Por colaboradores de Mundo Ingenio

Las preguntas tendrán una relación con el caso práctico de la empresa Health at Home (HH) previamente expuesto.

Preguntas

1. Investigue sobre el modelo de desarrollo de software en cascada y las diferentes etapas que se definen en este. La investigación deberá hacerla con base a referencias del curso y además referencias externas que consulte por cuenta propia y que complementen la información del curso. Para cada etapa debe:
   
   • a. Explicar con sus propias palabras en qué consiste la etapa.
     
   • b. Detallar cuáles roles de la metodología se requieren para llevar a cabo las labores de esta etapa.
     
   • c. Apoyar sus afirmaciones con una referencia del curso y una referencia externa.
     
   • d. Analizando concretamente el caso de HH debe explicar qué producto o entregable se tendría como resultado del trabajo de la fase, además de explicar qué preguntas o incógnitas del enunciado del caso deberían ser aclaradas en cada fase.

Seguidamente se mencionan algunas de las principales características de cada etapa con las que cuenta la metodología Cascada. Los autores González, Calero y Loaiza (2019) mencionan que este tipo de modelo o metodología consiste en una serie secuencial de pasos o etapas las cuales se pueden identificar de la siguiente forma: Análisis, Diseño, Codificación, Prueba y Mantenimiento. 

En primer lugar, el análisis. Esta etapa o fase consiste, según los autores mencionados con anterioridad, en un estudio previo que se hace a los parámetros o funcionalidades con los que debe contar la aplicación o el proyecto antes de plantear el diseño y la codificación. Los roles principales que juegan un papel importante durante esta etapa son los del cliente y una persona encargada de cuestionar al cliente cuáles son las características específicas que debe tener el programa o aplicación, para esto se hace uso de un documento donde se listan a detalle una serie de funciones y especificaciones por parte del cliente, este proceso es riguroso, ya que este modelo de desarrollo de programas no permite incluir o improvisar requerimientos en etapas posteriores Domínguez (2020). Tomando como base el caso presentado como HH, en primer lugar, el resultado como se menciona anteriormente es un documento que contiene una lista de requisitos específicos que debe tener la aplicación solicitada por el cliente o usuario. En segundo lugar, las preguntas que deberían cuestionarse son las siguientes: debe suponerse que en primera instancia no se saben los módulos exactos con los que cuenta la aplicación, tal como se plantea en el caso. Por tanto, se debe preguntar cuál es la cobertura de la aplicación o programa que desean alcanzar, esto para determinar los sistemas operativos en los que se va a implementar la aplicación. Muy importante, es tomar en cuenta los recursos con los que cuenta la empresa o cliente para llevar a cabo este proceso de desarrollo. Por otra parte, es igualmente significativo preguntar cuáles son las especificaciones o funciones que debería contener la aplicación para que la experiencia de usuario sea óptima, ya que el objetivo principal es ser la compañía de entrenamiento personal fisico a nivel mundial, entonces hay que tomar en cuenta la cantidad y la segmentación de usuarios que se van a cargar en el modelo, es decir están los usuarios que quieren entrenar, y también están los entrenadores, entonces son varios perfiles con diferentes funcionalidades dentro del sistema. También es importante la forma de pago que es algo en lo que se interesan los usuarios, al igual que bonos que pudieran obtener por su membresía. Además, se debe estimar el tiempo de proceso de entrega, es decir que se debe plantear la fecha de inicio del proyecto.   

En segundo lugar, la etapa de diseño. En esta fase de la metodología de cascada se plantea la parte del diseño, importante para no dejar espacio a la improvisación y evitar errores al momento de codificar. Entonces, los parámetros o características del programa que se analizaron en la primera etapa del modelo son la preparación para un diseño particular; Por supuesto esta especificación de métricas y/o parámetros o funciones van a dar la pauta para un diseño de la aplicación, desde el modelo de base de datos hasta la arquitectura TutorialsPoints SimplyEasyLearning. (2021). En cuanto a los papeles metodológicos que forman parte de esta fase o etapa se menciona continuación; como menciona o explica el autor citado antes, basados en los requisitos generados en la primera etapa se procede a la elaboración de la arquitectura de la aplicación, definiendo por supuesto cuál es la más óptima para cumplir las expectativas o lista de requerimientos. También, y siendo muy significativo, está la elaboración en paralelo de la estructura de los datos, ya que sin esta base se dificulta cualquier desarrollo, desde el más pequeño hasta el más grande. Con ambas estructuras, se puede perfectamente, diseñar un boceto de la interfaz de usuario, fundamental para seguir con la siguiente etapa de la metodología de desarrollo Cascada. Ahora, referente a cuáles serían las preguntas y resultado de esta fase basado en el caso HH, a continuación se muestran. Para empezar, se debe preguntar qué tanto se va a dividir el equipo para trabajar en conjunto, cuántos van a ser los responsables, una vez definidos se puede proceder a determinar el modelo a detalle de la  estructura de datos y de interfaz, los algoritmos y su distribución dentro del marco de la codificación Domínguez (2020). Una vez definidos estas métricas o funcionalidades se obtiene como resultado un boceto sobre el cual se basa la siguiente etapa del modelo de Cascada. 

En tercer lugar, la etapa conocida como codificación o implementación. Según los autores Rodríguez, Salamanca y Márquez (s.f.), describen que en esta etapa se definen los algoritmos y sus respectivas pruebas para la detección de errores, de esta forma se avanza con las funcionalidades que se requieren por parte del cliente. Esta fase es fundamental para dar avance del proyecto, esto debido a que es aquí donde se encuentran y resuelven errores o bugs dentro del sistema, se puede llegar a optimizar el código consiguiendo un programa o aplicación eficiente para un desempeño óptimo. Respecto a las preguntas que se dan durante esta etapa del modelo y su respectivo resultado son las siguientes: es verdad que en esta etapa se testea y codifica las funciones del sistema, entonces partiendo de esta referencia, las preguntas que se trabajan en esta fase son las de alcanzar los algoritmos más adecuados tanto para la estructura de datos como para la arquitectura de la aplicación, reduciendo así errores y brindando y obteniendo como resultado una interfaz de usuario ideal al igual que una experiencia adecuada y atractiva.

En cuarto lugar, la etapa de “testing” o pruebas globales. En la etapa anterior se hacen pruebas de los algoritmos, pero por subsecciones, esto quiere decir que se trabaja por aparte por ejemplo la unidad de empleados y por otra parte la unidad de bases de datos, así con cada unidad que se defina en la etapa descrita antes. Entonces, en esta etapa se unen todas las unidades y se prueban o “debugging” en conjunto todas las unidades, siendo pruebas de la aplicación completa, es decir funcionando en su totalidad. Entonces, de estas pruebas se obtiene la calidad del sistema y se define si está o no trabajando eficientemente, sin problemas de codificación ni ningún otro tipo de error que pueda generarse Domínguez (2020). En cuanto a las preguntas y resultados de esta etapa se describen a continuación. Es importante tomar en cuenta todo el sistema en conjunto como se acaba de mencionar, para así obtener una aplicación funcional totalmente. Entonces, se debería cuestionar qué tipo de algoritmos son utilizados, son estos los más optimizados para el tipo de arquitectura y estructura de datos según la cantidad de “data” que se transferirá cuando esté la aplicación en producción, se debe igualmente preguntar si se van a utilizar interfaces atractivas que cumplan los requisitos que se plantearon en principio. Por ende, el resultado que se obtiene en esta etapa es descartar que la aplicación o programa corre bien y sin ningún tipo de problema, es decir que se elimina cualquier error o “bug” dentro del sistema, teniendo así una proyecto que cumple con los requerimientos obtenidos en la primera etapa del modelo. 

En quinto lugar, y como última fase de la metodología de Cascada se encuentra la etapa llamada mantenimiento. Esta fase consiste según González, Calero y Loaiza (2019) en la instalación y mantenimiento del sistema en su entorno respectivo, ya sea una tienda como “Google Play Store”, “AppStore”, o “desktop” con su sistema operativo correspondiente, entre otros. Igual, si se desea por parte del cliente, en esta etapa se pueden hacer modificaciones al sistema y corrección de “errores” que defina el cliente también. Y por supuesto, se definen y dirigen recursos para el mantenimiento respectivo del programa o aplicación. En cuanto a las preguntas y resultado de esta etapa, se debería preguntar claro está si el cliente encuentra útil todas las funcionalidades del sistema hasta ese momento de entrega del proyecto. Por otra parte, definir si es necesario implementar alguna otra funcionalidad o hacer cambios en la interfaz, en fin determinar si es necesario alguna función extra o en su defecto eliminarla. Basados en estas preguntas mencionadas antes, se tiene como resultado la instalación del programa o aplicación y por ende su mantenimiento, y por último se determina si se tienen que hacer o no modificaciones al sistema. 

2. En el punto 1 se tuvo un acercamiento al modelo de desarrollo en cascada. En este punto deberá realizar algo similar con el de desarrollo de software conocido como Proceso Unificado (UP). Para lograr profundizar en su conocimiento debe realizar:
   
   • a. Una explicación con sus propias palabras de cada una de las fases que componen la metodología apoyando sus afirmaciones en referencias bibliográficas.
     
   • b. Una explicación de las 9 disciplinas o flujos de trabajo que contempla UP. Para cada disciplina debe identificar qué artefacto o artefactos se producen.
     
   • c. Una explicación del concepto de desarrollo iterativo e incremental y el trabajo por iteraciones.

Seguidamente se mencionan algunas de las principales propiedades de las fases o etapas con la que cuenta el desarrollo de software llamado UP. Este modelo de desarrollo se divide en varias etapas: la fase uno o de inicio o concepción. Esta fase se basa principalmente en determinar los o el objetivo principal del proyecto, esto por supuesto va “de la mano” con preguntas significativas como los recursos económicos con que cuenta el cliente o compañía que desea llevar a  cabo el proyecto; igualmente se planifica el plazo o tiempo de entrega del mismo como también su factibilidad y se consideran los riesgos al mismo tiempo que se planifican de las siguientes etapas o iteraciones. También, se definen las funcionalidades que debe contener la aplicación o sistema.  Altamirano y Carate (2015).

Segundo, la etapa o fase de elaboración. Respecto a esta etapa del modelo de UP, es aquí donde se profundiza en el entendimiento de los requerimientos que se tomaron en cuenta en la primera etapa; con base en los requerimientos obtenidos se procede a definir la arquitectura del sistema y según el autor Torossi (s.f) se pueden contestar a las siguientes preguntas: “Se ha creado una línea base de la arquitectura? ¿Es adaptable y robusta? ¿Puede evolucionar? – ¿Se han identificado y mitigado los riesgos más graves? – ¿Se ha desarrollado un plan del proyecto hasta el nivel necesario para respaldar una agenda, costes, y calidad realistas? – ¿Proporciona el proyecto, una adecuada recuperación de la inversión? – ¿Se ha obtenido la aprobación de los inversores?” (pág. 8). 

En tercer lugar se encuentra la etapa o fase de construcción. En esta etapa los casos de uso o requerimientos son alcanzados, antes de terminarse esta fase el sistema se pone en funcionamiento haciendo pruebas que verifiquen la calidad del software; no obstante existe la posibilidad de que el sistema no esté completamente libre de errores Torossi (s.f). En resumen, en esta etapa se modela, se construye y se testea el sistema completo. 

En cuarto lugar, se encuentra la fase o etapa de transición. Aquí, según el autor mencionado antes, el sistema se coloca y prueba en un ambiente de preproducción, algo así como una versión “beta” que se testea con el fin de determinar si sus funcionalidades están “corriendo” bien y si es necesario implementar o modificar alguna otra función que requiera el cliente. Al final de esta etapa el cliente obtiene su producto final y en teoría se alcanza los objetivos planteados en la etapa de inicio o concepción.

Seguidamente se describen los flujos o disciplinas del modelo UP. Según Altamirano y Carate (2015) uno de los principales flujos del modelo se llama modelado, esta disciplina consiste en el entendimiento de los negocios de la organización, es decir el problema a resolver para su eventual solución. En este flujo de modelo se involucran los siguientes artefactos: se obtiene un modelo o documento de casos de usos o requerimientos. 

Otro flujo de modelo es la implementación. Aquí básicamente se transforman los modelos de la disciplina antes mencionada en código que puede ser ejecutado con sus respectivas pruebas de unidad. El o los artefactos que resultan de esta disciplina son los siguientes: una serie de clases modeladas respecto a las funcionalidades y sus correspondientes relaciones, que se requieren para cumplir los objetivos del sistema en proceso Altamirano y Carate (2015).

También, los mismos autores mencionados antes, describen otra disciplina significativa del modelo de desarrollo de software llamada prueba. Este flujo de modelo se basa en la detección de errores o fallas del sistema mediante una serie de pruebas controladas para así determinar la calidad del sistema y verificar si se cumplen los objetivos. Los artefactos o artefacto que se obtiene en esta disciplina es el siguiente: documentación referente a los errores detectados, si es que los hay, además de las posibles modificaciones que se pudieran requerir en la iteración actual. 

Asimismo, Altamirano y Carate (2015) describen otra disciplina o flujo de modelo llamada despliegue. Este flujo consiste en la ejecución y conclusión del sistema. Es en este flujo donde el usuario va a tener a disposición la aplicación o programa. Los artefactos que se obtienen en esta disciplina son los siguientes: documentación que dentro del proceso se compila para el análisis de rendimiento y cumplimiento de objetivos de la aplicación. 

Por otra parte, otro flujo de trabajo conocido como gestión de configuración según el autor Condori (2014), esta disciplina funciona de la siguiente manera “El objetivo de esta disciplina es la gestión de acceso a herramientas de su proyecto. Esto incluye no sólo el seguimiento de las versiones con el tiempo, sino también el control y gestión del cambio para ellos” (pág. 31). Tomando en consideración el objetivo de esta disciplina se puede inferir que los artefactos que resultan de este flujo de método es: una documentación o registro del resultado del proceso con actividades para controlar y manejar las versiones del proyecto posteriores. El mismo autor menciona más adelante otro flujo llamado gestión de proyectos y lo describe de la siguiente forma: “El objetivo de esta disciplina es dirigir las actividades que se llevan a cabo en el proyecto. Esto incluye la gestión de riesgos, la dirección de personas (la asignación de tareas, el seguimiento de los progresos, etc), coordinación con el personal y los sistemas fuera del alcance del proyecto para asegurarse de que es entregado a tiempo y dentro del presupuesto” (pág. 32); en este proceso los artefactos que resultan del método son: se da el registro a detalle de la gestión de riesgos y la coordinación de personas que se encuentra fuera del proyecto, esto quiere decir que se documentan actividades del proyecto. 

Por último, otro flujo o disciplina de método que contiene la metodología de desarrollo el mismo autor la llama entorno y la describe de la siguiente manera: “El objetivo de esta disciplina es apoyar el resto de los esfuerzos por garantizar que el proceso sea el adecuado, la orientación (normas y directrices), y herramientas (hardware, software, etc) estén disponibles para el equipo según sea necesario” (pág. 32). En otras palabras, proveer un ambiente controlado que permita el desarrollo óptimo del desarrollo del sistema o programa. Entonces se infiere que los artefactos dentro del flujo son: procesos o métodos que se utilizan para el desempeño óptimo del proyecto tales como instrumentos propios del sistema que van desde los tangibles como el hardware hasta no palpables como el software y documentación con la guía de actividades de trabajo.

3. Estudie el marco de trabajo SCRUM y explíquelo con sus propias palabras. Para lograr esto debe dividir su explicación en 3 secciones: eventos, roles y artefactos. La explicación debe hacerla de la siguiente manera:
   
   • a. Eventos: explique con sus propias palabras en qué consiste el evento apoyando sus afirmaciones con al menos una referencia bibliográfica para cada evento. Para cada evento, investigue referencias externas al curso para comprender cómo se lleva a cabo dicho evento, es decir, qué subtareas se llevan a cabo en dicho evento y qué objetivo tiene cada una.
     
   • b. Roles: explique con sus propias palabras el rol y detalle las 3 tareas que considera más importante para cada rol.
     
   • c. Artefactos: explique cada artefacto y qué utilidad tiene.

A continuación se describen los eventos significativos de la metodología de desarrollo de software SCRUM cada uno con su respectivo objetivo y actividades o características. En primer lugar, está el Sprint. Este evento es el corazón de SCRUM, este es a su vez un contenedor de otros eventos, estos eventos son la planificación del Sprint, el objetivo de Sprint, las reuniones SCRUM diarias, las reuniones de retrospectiva, la revisión del Sprint. Un Sprint es un periodo de tiempo determinado y cuando se especifica no se puede acortar ni alargar, por ende durante el Sprint no se puede cambiar el objetivo de Sprint. Por otra parte, si es necesario cancelar un Sprint se deben tomar varios aspectos en cuenta, por ejemplo, si es que el objetivo del Sprint pierde su valor real, es decir que se torna obsoleto, entonces el Product Owner toma la decisión de cancelar el Sprint. Algo muy importante que se debe mencionar es que si se llega a cancelar un Sprint, si es que algunos elementos de la lista del Sprint son relevantes o sumamente importantes para el proyecto, entonces se aceptan para su respectiva entrega, Schwaber y Sutherland (2017). 

Por otra parte, los mismos autores mencionan sobre otro evento llamado Planificación de Sprint, los siguientes datos. En este evento todos los miembros del equipo de SCRUM se reúnen para elaborar un plan para cumplir el objetivo del siguiente o primer Sprint. Aquí el Scrum Máster gestiona el tiempo, mismo que para un Sprint tarda 8 horas para una iteración de 1 mes. Existen dos cuestiones muy importantes para llevar a cabo una planificación, estas son que se va a hacer para cumplir con la funcionalidad de esta iteración contenida en la lista de del Sprint, y la otra como lo van a conseguir desde la concepción del diseño de la o las funcionalidades hasta la entrega de elementos de lista terminados. Es durante esta planificación donde nace el objetivo del Sprint. 

Más adelante, Schwaber y Sutherland (2017) mencionan otro evento significativo del modelo desarrollo SCRUM, este evento se conoce como Objetivo del Sprint. El objetivo se constituye a partir de los elementos que se desean concretar de la lista del sprint; una vez establecido esta meta se trabaja en equipo para conseguirla. En ocasiones si no se cumplen algunos elementos de la lista del sprint como parte del objetivo, se puede negociar con el dueño del producto para convenir su alcance. 

Otro evento que forma parte de este modelo de desarrollo son las reuniones diarias. Las reuniones diarias consisten en determinar que se está haciendo cada día durante un Sprint, esta reunión la conforman el equipo de trabajo (el scrum máster y el equipo de desarrolladores), tarda aproximadamente 15 minutos o menos, el scrum máster controla el tiempo, uno de los miembros del equipo de desarrollo toma el rol de orquestador de la reunión y da las pautas para preguntar y responder a las siguientes cuestiones: que se hizo ayer y que se va a hacer hoy para cumplir el objetivo de la iteración, y también, describir cuál o cuáles serían algunos impedimentos para cumplir con el objetivo del Sprint Schwaber y Sutherland (2017).

Seguidamente, según los autores mencionados antes, el evento conocido como revisión de un Sprint. Este evento es una reunión de aproximadamente 4 horas para una iteración de 1 mes, y menos para un Sprint  más corto. Los miembros del equipo y los interesados del Sprint se reúnen para una exposición de los elementos de la lista del producto que se tenían para terminar o desarrollar como objetivo de Sprint, mismos que se modifican o ajustan; el Scrum máster igualmente maneja el tiempo de la reunión y explica el objetivo de la reunión a los demás miembros de la reunión. Este evento incluye una serie de elementos significativos que a continuación se enumeran: 

1. Los asistentes son el Equipo Scrum y los interesados clave invitados por el Dueño de Producto.
2. El Dueño de Producto explica qué elementos de la Lista de Producto se han “Terminado” y cuáles no se han“Terminado”.
3. El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecen y cómo fueron resueltos esos problemas.
4. El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento.
5. El Dueño de Producto habla acerca de la Lista de Producto en su estado actual. Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el progreso obtenido hasta la fecha(si fuera necesario).
6. El grupo completo colabora acerca de qué hacer a continuación, de modo que la Revisión del Sprint proporcione información de entrada valiosa para Reuniones de Planificación de Sprints subsiguientes.
7. Revisión de cómo el mercado o el uso potencial del producto podría haber cambiado lo que es de más valor para hacer a continuación; y.
8. Revisión de la línea de tiempo, presupuesto, capacidades potenciales y mercado para las próximas entregas de funcionalidad o capacidad prevista del producto.

Por último, como parte importante de los eventos se encuentra la reunión de retrospectiva. Esta reunión básicamente se trata de una retroalimentación de lo que se hizo durante el Sprint recién terminado, esta reunión se da en medio de la finalización de un Sprint y el comienzo de otro. Es una reunión donde el scrum máster tiene mucha más participación que solo controlar los tiempos de la reunión, si no que forma parte importante, ya que debe rendir cuentas al product owner igual que el resto del equipo scrum. La reunión retrospectiva consta de 3 horas para una iteración de 1 mes, igualmente durante el tiempo de esta reunión se plantean varias preguntas importantes para la retroalimentación y cumplimiento del objetivo de la misma, como por ejemplo, “Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas. Identificar y ordenar los elementos más importantes que salieron bien y las posibles mejoras. Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo”. Schwaber y Sutherland (pág. 14, 2017). 

Referente a los roles del modelo de desarrollo de SCRUM, seguidamente se detallan sus tareas más importantes. En primer lugar se encuentra el product owner, es el encargado de elaborar la lista del producto, es decir que está en contacto directo con el cliente que desea desarrollar el sistema; esto lo hace el responsable directo de manejar la lista del producto, que en teoría para que se desempeñe con eficiencia el resto del equipo Scrum deben respetar sus decisiones. Ahora, una tarea sumamente significativa es la de crear y gestionar la lista de producto, otra es desarrollar una lista de producto clara ordenada y optimizada para el resto del equipo de trabajo; y por último la responsabilidad de permanecer el contacto directo con el cliente dueño del proyecto y hacer cumplir los requerimientos o elementos de la lista Palacio (2015, pág. 33).

En segundo lugar, según el autor mencionado antes se encuentra el scrum máster. Este es el encargado de gestionar los tiempos de las reuniones dentro de cada Sprint, también, se encarga de dirigir y hacer entender las reglas de la organización, es decir que es el líder del equipo; el scrum máster es el enlace entre el equipo de trabajo y el producto owner o dueño del producto. Algunas de las tareas más significativas que realiza un scrum master son: asesorar y formar el equipo de trabajo de desarrollo, funciona como moderador de las reuniones y también da solución a los impedimentos que puedan bloquear el trabajo de cada Sprint (dinamiza las reuniones).

Por último, el otro rol es de Equipo de trabajo o desarrollo. El mismo autor describe que este lo conforman miembros profesionales en uno o varios campos que trabajan en conjunto para cumplir con los objetivos de cada Sprint. Cada miembro puede ser o no especialista en un campo o varios, pero al final todos trabajan en conjunto con un fin específico. Las tareas más importantes del equipo de desarrollo son las siguientes: todos los miembros participan en las decisiones de cada reunión; igual cada miembro del equipo conoce a cabalidad la visión del dueño del producto; y también colaboran y ayudan al dueño del producto con la realización de la pila del producto.  

A continuación se describen los artefactos del modelo SCRUM al igual que sus respectivas funciones dentro de la metodología. Para empezar según Schwaber y Sutherland ( 2017), el artefacto conocido como la lista del producto, este artefacto consiste en una serie de requisitos que puede alargarse o no dependiendo del valor dentro del mercado; por otra parte es cambiante, es decir que al inicio del proyecto se conocen los elementos que se consideran más relevantes para realizar el mismo, sin embargo puede evolucionar según lo que se requiera adaptar para mejorar su funcionalidad. La lista del producto es manejada por el product owner desde el principio. La lista del producto consta de una serie de elementos que representan las funcionalidades, requisitos y mejoras del sistema. Una lista tiene según el mismo autor mencionado con anterioridad “como atributos la descripción, el orden, la estimación y el valor” (pág. 15, 2017). Cada atributo va más o menos detallado dependiendo de su prioridad dentro de la lista. Por otra parte, cada elemento de la lista tienen un estado dentro de la lista, esta son conocidas como terminado (final), en proceso (en acción) y preparado (listado).

Otro artefacto que mencionan los mismos autores es la lista de Sprint. Esta lista está presente durante cada Sprint, que significa que son una serie de tareas dirigida para el equipo de trabajo o desarrollo, que en conjunto con un plan de entrega cumplen con el fin de cumplir con el objetivo del Sprint. Esta lista varía su prioridad dependiendo de varios factores, por ejemplo, de la retrospectiva que se da al finalizar cada Sprint; esta lista evoluciona respecto al avance del Sprint, puede modificarse según especificaciones determinadas por el equipo al avanzar en el proyecto. 

Por último, otro artefacto es el incremento. El incremento es el conjunto de la lista de sprint culminados en cada Sprint o iteración. Según Schwaber y Sutherland describen que “Al final de un Sprint el nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y que cumple la Definición de “Terminado” del Equipo Scrum” (pág. 17, 2017). Entonces, se puede inferir que su propósito principal es documentar todos los elementos finalizados de la lista del producto que funcionan como una guía durante el proyecto y que al final provee un respaldo para verificar el objetivo principal del proyecto. 

4. Ejercite la práctica complementaria de SCRUM relacionada al uso de historias de usuario para describir los requerimientos de un sistema. En primer lugar, asuma que su rol será el de Dueño de Producto (Product Owner). Desarrolle el backlog del proyecto, definiendo 10 historias de usuario más importantes del caso práctico de HH.  A cada historia asigne una prioridad justificando el porqué del orden establecido. Seguidamente realice el rol de un miembro del equipo SCRUM y estime cada historia asignando un peso. El peso no puede ser un valor arbitrario, por lo que luego de definir las historias debe incluir una descripción detallada qué método siguió para realizar dicha estimación, el cual debe estar apoyado por una referencia bibliográfica. La historia debe tener el formato:
   
   • a. COMO UN: <nombre de actor del sistema>
     
   • b. QUIERO: <funcionalidad>
     
   • c. CON EL FIN DE: <valor de la historia>
     
   • d. PRIORIDAD: <entre más bajo, más rápido debe atenderse. Debe justificarla>
     
   • e. PESO: <estimado de la historia>

A continuación se define un backlog del proyecto donde se describen en forma de tabla (Tabla 1: Historias de Usuario) historias de usuario basados en el caso hipotético HH. Basados en la descripción de historias de usuarios de los autores Menzinsky , López y Palacio (2018). Los métodos que se utilizan para la selección de las historias de usuario son los siguientes; para empezar se debe entender que una historia es tal y como se escribe, significa que un requisito es una narrativa de cómo el cliente percibe el mundo. Ahora para dar una estimación a cada historia de usuario se toman en cuenta los siguientes parámetros: la serie de la sumatoria de Fibonacci (números que son la sumatoria de los dos anteriores) y es apta para dar un peso estimado a una historia pequeña; “Es un hecho que para historias de usuario pequeñas la incertidumbre en la estimación es mucho menor que para las historias grandes, y mientras el tamaño de las historias crece linealmente la incertidumbre crece exponencialmente” (pág. 18). Además, para identificar y visualizar mejor la serie Fibonacci generalmente se utilizan “cartas planning poker con la serie Fibonacci”. En el caso de historias denominadas grandes se utiliza la técnica de tallas de camiseta, por ejemplo, “XS, S, M, L, XL” y consiste en “utilizar las tallas de camisa nos da algo como una intuición más que una estimación, con un gran grado de incertidumbre amplio acorde a epics y temas. Está técnica tiene la ventaja de ser puramente relativa, no es posible traducir sus valores a tiempo, a jornadas u horas” (pág. 19). Para visualizar mejor esta técnica se utilizan “cartas de estimación con tallas de camiseta”. La tabla se basa en la serie de sumatoria Fibonacci.

Por otra parte, se van a tomar en cuenta los siguientes parámetros para priorizar las historias de usuarios según los autores mencionados con anterioridad: “Beneficios de implementar una funcionalidad.  Pérdida o coste que demande posponer la implementación de una funcionalidad.  Riesgos de implementarla.  Coherencia con los intereses del negocio.  Valor diferencial con respecto a productos de la competencia.” (pág. 20).

Tabla 1.

ID de la Historia	Como un – Actor	Quiero – Funcion	Con el fin de – Valor	Prioridad1(+alta) a (+10 baja)	Justificación Prioridad	Estimación 1(+baja ) a 10(+alta)
1	Usuario final	Pagar $10 de membresía	Obtener servicio de recursos de entrenamientos personalizados	1	Beneficio de la función, esto significa más usuarios en el sistema	4
2	Usuario final	Inscribirme como entrenador en la plataforma	Ofrecer servicios y generar ingresos por ello	1	Coherencia con los intereses del negocio, puesto que sin entrenadores no hay sesiones de entrenamiento	4
3	Usuario final	Tener acceso al catálogo de entrenamientos	De calendarizar mis entrenamientos y seleccionar mi entrenador	2	Beneficio de la función, pues sin catalogo seria dificil programar un entrenamiento	4
4	Usuario final	Acceder al módulo de entrenamientos	Grabar el entrenamiento para otros miembros de la plataforma que pagan por el	3	Coherencia con los intereses del negocio, al entrenador poner a disposición las grabaciones de entrenamiento	6
5	Usuario final	Tener acceso al módulo de pago	Percibir mi remuneración por mis servicios de entrenador	2	Coherencia con los intereses del negocio. El usuario entrenador recibe el pago por sus servicios	6
6	Programador	Genera un algoritmo de pago para entrenadores	Remunerar a los usuarios entrenadores	2	Coherencia con los intereses del negocio. Aquí se remunera a los entrenadores para mantenerlos en la plataforma	8
7	Programador	Crear un algoritmo de conexión con empresa BWW	Obtener cuentas IBAN de los entrenadores	2	Valor diferencial respecto a la competencia. Se tiene la ventaja de contar con la API del banco que provee cuentas IBAN	8
8	Usuario final	Grabar mi entrenamiento	Concursar y acceder al módulo de premios	4	Beneficio de la función. El usuario tiene acceso a premios y promociones	2
9	Programador	Generar un algoritmo de premios	Premiar a los usuarios que graban sus entrenamientos y concursan en el módulo de premios	4	Coherencia con los intereses del negocio. Aquí se mantiene a los usuarios en la plataforma por medio de promociones y premios	8
10	Programador	Crear un algoritmo de sesiones de entrenamiento con categorías	Dar opción a entrenadores la opción de programar sus sesiones de entrenamientos segun la categoria	2	Coherencia con los intereses del negocio. Aquí se permite dar acceso a los entrenadores para grabar sus sesiones de entrenamiento	8

Historias de Usuario

Referencia: Propia.

5. Investigue el concepto de “definición de terminado” en SCRUM. Con base a su investigación elabore su propia definición de terminado para una historia de usuario de su proyecto. Para lograr esta definición debe indicar 10 cosas que deben cumplirse para considerar una historia de usuario como terminada. Explique con sus propias palabras en qué consiste cada uno de los elementos seleccionados. Apoye su respuesta con referencias bibliográficas.

Seguidamente, se determina el significado o definición de “terminado” en el marco del modelo SCRUM. El concepto de una historia de usuario “terminado” se dice que depende del contexto en el que se encuentre dentro del equipo de desarrollo SCRUM de una empresa o compañía, ya que existen variedad de equipos con objetivos distintos, pero generalmente se interpreta como: una tarea que tiene una funcionalidad en específico, esta ha sido listada dentro de una lista de producto, luego se trabaja sobre ella se procesa o acciona y una vez que cumple las expectativas de su función y se han hecho las pruebas correspondientes dentro de la unidad o clase respectiva entonces está completada y se considera como “terminado” Schwaber y Sutherland ( 2017), esto bajo el marco de conceptos que maneja cada grupo o equipo de trabajo, todos los interpretan de la misma manera. 

Por otra parte, para que una historia de usuario se considere terminada debe cumplir una serie de parámetros. A continuación se enumeran y se describen los parámetros que según Francia (2017) considera como elementos para determinar una historia de usuario como “terminado”: 

1. Pruebas de rendimiento: un sistema siempre debe mostrar su capacidad en funcionamiento real, tanto su velocidad como su estabilidad y escalabilidad, es decir corriendo con datos reales para verificar su potencial verdadero y obtener resultados para posteriormente ser evaluados y comparados con los objetivos que se pretendían en un inicio. 
2. Pruebas de escalabilidad: estos test que se hacen basados en el rendimiento del sistema, para ello es necesario tener una referencia de los estados del rendimiento del sistema para eventualmente verificar la capacidad del sistema de adaptación, esto varía según la cantidad de transferencia de datos que se están probando o evaluando y que que son constantes o no en ese momento de pruebas.  
3. Pruebas de seguridad: esto se conoce como un conjunto de elementos que se evalúan del sistema en desarrollo para determinar vulnerabilidades o posibles fallos del programa.
4. Refactoring: para tener una codificación optimizada y “limpia” se debe muchas veces alterar este código para mejorarlo sin cambiar nada en la parte visual o front-end del sistema.
5. Internacionalización a varias culturas: en muchas ocasiones un sistema es desarrollado para usuarios de múltiples culturas, es decir que el sistema debe ser lo mas entendible posible, determinar que tan factible es colocar de una u otra forma una interfaz en una sección en específico del software por ejemplo, en palabras más sencillas tener un estándar de front-end comprensible para múltiples culturas a nivel mundial. 
6. Pruebas de aceptación del usuario: esto se refiere al momento de que el usuario está utilizando el programa debe cumplir con las expectativas que se plantearon en un inicio, además de presentar una experiencia fácil y comprensible para el. 
7. Documentación requerida por la organización: son registros necesarios con el reporte a detalle de cada historia de usuario donde se describen las funciones y objetivos alcanzados.
8. Pruebas de regresión: una vez terminadas una serie de pruebas como rendimiento, estrés y carga de sistemas; y si fue necesario modificar alguna funcionalidad del sistema entonces se verifica que luego de esa modificación funciona como se espera, eficiente y eficazmente.  
9. Revisión de código: siempre es necesario tener una codificación tanto documentada como libre de “pulgas” o código innecesario que al final no tiene una funcionalidad importante y que no impacta realmente en el proyecto, además de eliminar los errores que pudieran existir en ese momento que han pasado desapercibidos.  
10. Pruebas de integración: las pruebas de integración son las pruebas en conjunto de cada unidad funcionando al mismo tiempo, y así verificar que el sistema corre sin dificultad una vez implementadas todas las unidades del programa. 
11. Ponga en práctica la actividad de definición de un Sprint Backlog. Asuma que en la próxima iteración se desarrollará únicamente la historia de usuario definida en el punto 4 de este proyecto que tenga mayor peso, es decir, la más compleja. Desglose la historia en tareas concretas a realizar para lograr completar la historia. Tome en cuenta la definición de terminado que usted planteó en la pregunta anterior.

A continuación se desglosa en tarea la historia de usuario con la siguiente descripción en la tabla 2: Historia de Usuario: 

Tabla 2.

ID de la Historia	Como un – Actor	Quiero – Funcion	Con el fin de – Valor	Prioridad1(+alta) a (+10 baja)	Justificación Prioridad	Estimación 1(+baja ) a 10(+alta)
2	Usuario final	Inscribirme como entrenador en la plataforma	Ofrecer servicios y generar ingresos por ello	1	Coherencia con los intereses del negocio, puesto que sin entrenadores no hay sesiones de entrenamiento	4

Historia de Usuario

Referencia: Propia.

La siguiente es una lista numerada de tareas para poder concluir la historia de usuario con ID de la Historia # 2:

1. Back-end = Crear algoritmo de clase o funcion de conexion con base de datos.
2. Back-end = Crear algoritmo de registro de usuarios (entrenador).
3. Back-end = Crear algoritmo verificacion de codigo IBAN de usuarios (entrenador).
4. Back-end = Crear algoritmo verificacion de mayoria de edad de usuarios (entrenador).
5. Front-end = Crear función que despliegue la interfaz de registro de usuario (entrenador).
6. Front-end = Crear interfaz amigable y atractiva para usuarios en módulo registro usuarios (entrenador).
7. Efectuar las pruebas de rendimiento.
8. Efectuar las pruebas de escalabilidad.
9. Efectuar las pruebas de seguridad.
10. Efectuar las pruebas de aceptación de usuario.
11. Efectuar las pruebas de regresión.
12. Efectuar las pruebas de integración.
13. Verificar Refactoring de las pruebas.
14. Revisión del código.
15. Documentar la información para la organización.
16. Verificar la internacionalización a varias culturas de la interfaz.
17. Realice un análisis comparativo entre UP, Cascada y SCRUM. En su comparación debe indicar para cada metodología al menos 2 ventajas y 1 desventajas. Seguidamente explique con sus propias palabras cuál de las 2 metodologías recomendaría para el proyecto planteado en el caso práctico de HH. Justifique su recomendación basándose en elementos del enunciado que lo lleven a determinar que el problema se podría resolver de mejor manera por la metodología seleccionada.

El siguiente es un análisis comparativo entre las metodologías de desarrollo UP, Cascada y SCRUM. En primer lugar, las ventajas que representa la implementación de cada una de los modelos mencionados antes son las siguientes. UP es un modelo que permite el libre acceso a su documentación para los usuarios que la quisieran utilizar dentro de un proyecto; otra ventaja clara se basa en el hecho de que contiene una serie de roles y artefactos bien establecidos, esto permite que su implementación sea sencillo de describir dentro de un grupo de trabajo. Por otra parte el modelo Cascada cumple con las siguientes ventajas, una es que al documentarse rigurosamente los resultados y procesos permite a los miembros del equipo estar al tanto del progreso del proyecto durante cada fase o etapa; otra ventaja es la siguiente, si se toma en cuenta que para continuar con la siguiente etapa se debe finalizar la anterior, no abre espacio a errores en el sistema, lo que deja como resultado un producto o programa listo o completado en cada fase. SCRUM es un modelo que ofrece muchos beneficios, entre los cuales destacan; igual que los modelos anteriores es un sistema muy bien documentado lo que permite el acceso a una guía de uso muy bien establecida para un grupo de trabajo que quiera implementar, por ejemplo, determina cada rol de los miembros de un equipo Scrum, dejando una clara posición y actividades para cada miembro del equipo; otra clara ventaja que provee este modelo es la definición y uso que se le da a lista del producto, que funciona como base para cumplir con el proyecto, y por supuesto el hecho de que esta lista sea manejada por una sola persona no abre espacio a la improvisación y perdida de recursos y tiempo durante el proyecto. 

Ahora, sí por una parte estos modelos ofrecen claras ventajas a los usuarios que las utilizan por otra igualmente trae una serie de desventajas. El modelo UP por ejemplo, es una metodología que se basa en el modelo RUP pero mas simple, por esta razón muchos optan por utilizar RUP y no el modelo UP. Cascada por otra parte, se puede inferir por muchos desarrolladores que al ser un modelo que no permite continuar otra fase si no se termina la anterior como un impedimento de uso. Para finalizar Scrum, un clara desventaja es que si se establecen muchos roles y actividades, pero muchas veces reuniones como por ejemplo, las diarias, que constan de 15 minutos pueden no aportar tanto al desarrollo del sistema la estar tan controlado y limitado su tiempo respecto a la iteración en la que se trabaje en ese momento en particular. 

La recomendación para el caso HH es la implementación de la metodología ágil de Proceso Unificado (UP), ya que en primera instancia uno de los riesgos principales que se describen en el caso HH es que no cuentan con recursos extensos para el desarrollo del sistema, no se sabe con certeza cuál sistema operativo es el óptimo para comenzar el proyecto y el alcance del proyecto es cubrir una cantidad de usuarios a nivel mundial; esto convierte el proyecto con un riesgo sensible que se debe tomar como alta consideración para el desarrollo del programa; si se toma en cuenta que uno de los pilares de este modelo es el control de riesgos, entonces se puede claramente recomendar este modelo para satisfacer las necesidades del cliente y determinar cuál sería el futuro del proyecto.  

8. Suponga que justo a la mitad de la ejecución del proyecto de desarrollar el software solicitado por HH, se incorpora una nueva funcionalidad con prioridad máxima en el proyecto, relacionada a un dato vital en el registro de la cuenta IBAN de los entrenadores. La funcionalidad dice la cuenta debe verificarse como una cuenta con fondos superiores a los $20, de lo contrario no deberá aceptarse la suscripción, y en casos donde el usuario ya esté suscrito, no se podrán procesar pagos a estas cuentas. Estas funcionalidades impactan la funcionalidad de registros que ya estaba concluida y la funcionalidad de proceso de pagos masivos del módulo de pagos que se encuentra actualmente en desarrollo.
   
   • a. Explique qué establece la metodología RUP para la atención de requerimientos emergentes. Si usted fuera el dueño de producto del proyecto, cómo atendería este nuevo requerimiento. 
     
   • b. Explique qué establece la metodología SCRUM para la atención de requerimientos emergentes. Si usted fuera el administrador del proyecto, ¿cómo atendería este nuevo requerimiento?

RUP por un lado maneja los casos de usos o requisitos emergentes de la siguiente manera; este modelo de desarrollo se trabaja por fases y trabaja sobre el caso de usos, en este caso en particular un caso de uso debe ser modificado o actualizado, independientemente su estado dentro del proyecto, RUP provee al final de cada iteración un ejecutable, este se puede modificar respecto a las actualizaciones de los casos de uso, en este caso la actualización del monto en la cuenta que debería tener el usuario para la membresía en la aplicación. Como “dueño del producto”, el encargado en este caso lo maneja respetando la iteración, ya que una vez que termina la fase se tiene un ejecutable, entonces el caso de uso actualizado tendrá prioridad alta en la siguiente iteracion para asi modificar el sistema sin interrumpir abruptamente el proceso del proyecto. 

En el caso de la metodología Scrum, los requerimientos emergentes que al final van a modificar la lista del producto son evaluados por el dueño del producto y generalmente se discute con el equipo de desarrollo para actualizar la lista con su respectiva prioridad, y en este caso es posible manejarla fácilmente, pues una lista de producto se caracteriza por ser variante, este proceso se conoce como refinamiento dentro del modelo Scrum, Schwaber y Sutherland (2017). Como dueño del producto, se debe tomar en cuenta la historia de usuario que se tenía en principio para actualizarla y proceder a modificarla, tanto en la estructura de datos como los demás elementos que se toman en cuenta para determinar una historia de usuario terminada.  

Referencias Bibliográficas

Altamirano, O., Carate, O. (2015). ANÁLISIS, DISEÑO, DESARROLLO E IMPLEMENTACIÓN DE LOS MÓDULOS DE ADMINISTRACIÓN, ACADÉMICO Y DOBE ORIENTADO A LA WEB PARA EL COLEGIO MILITAR Nº 10 ABDÓN CALDERÓN. [archivo PDF]. Recuperado de https://repositorio.espe.edu.ec/bitstream/21000/10813/1/T-ESPE-049206.pdf

Condori, I. (2014). TESIS DE GRADO“APLICACIÓN DE LOCALIZACIÓN Y CONTROL DE DISPOSITIVOS SMARTPHONE ANDROID”. [archivo PDF]. Recuperado de https://repositorio.umsa.bo/bitstream/handle/123456789/7936/T.2827.pdf?sequence=1&isAllowed=y

Domínguez, P. (6 de febrero de 2020). En qué consiste el modelo en cascada. Recuperado de https://openclassrooms.com/en/courses/4309151-gestiona-tu-proyecto-de-desarrollo/4538221-en-que-consiste-el-modelo-en-cascada

Francia, J. (6 de mayo de 2017). Definición de Terminado (Done). Recuperado de https://www.scrum.org/resources/blog/definicion-de-terminado-done

González, F., Calero, S., y Loaiza, D. (2019). Comparación de las metodologías cascada y ágil para el aumento de la productividad en el desarrollo de software. [archivo PDF]. Recuperado de https://repository.usc.edu.co/bitstream/handle/20.500.12421/1208/COMPARACI%D2N%20DE%20LAS%20METODOLOG%CCAS.pdf;jsessionid=66B39407D62A6F4C4A82C84458F130EE?sequence=1

Menzinsky, A., López G., y Palacio, J. (2018). Historias de Usuario. [archivo PDF]. Recuperado de https://scrummanager.net/files/historias_usuario_scrum_manager.pdf

Palacio, J. (2015). Scrum Manager I Las reglas de scrum. [archivo PDF]. Recuperado de https://www.scrummanager.net/files/scrum_I.pdf

Rodríguez, I., Salamanca, M., y Márquez, I. (s.f.). Modelo Lineal o de Cascada. [archivo PDF]. Recuperado de http://www.utpuebla.edu.mx/divisiones/tic/TIC/2_materias/2/image/2do_sist/Introduccio%CC%81n%20al%20ana%CC%81lisis%20y%20disen%CC%83o%20de%20sistemas/Portafolio%20de%20evidencias/Producto%204.pdf

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

Torossi, G. (s.f.). El Proceso Unificado de Desarrollo de Software. [archivo PDF]. Recuperado de http://dsc.itmorelia.edu.mx/~jcolivares/courses/pm10a/rup.pdf

TutorialsPoints SimplyEasyLearning. (2021). SDLC – Waterfall Model. Recuperado de https://www.tutorialspoint.com/sdlc/sdlc_waterfall_model.htm

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.