El documento describe las pruebas realizadas al aplicativo YouGym. Se realizaron pruebas unitarias, de integración y de sistemas para validar el correcto funcionamiento de cada componente y módulo. También se llevaron a cabo pruebas de aceptación con usuarios para verificar que el sistema cumpla con los requisitos funcionales. Finalmente, se concluye que las pruebas permitieron identificar errores y mejorar la calidad del aplicativo.

2. YouGym app
Angel David Bolaño
Victor Alfonso Ardila

3. Descripcion del sistema
• Nuestra aplicación es un sistema de gestión
diseñado específicamente para gimnasios,
ofreciendo una solución profesional y
eficiente. Hemos desarrollado un software
altamente funcional y personalizable que se
adapta a las necesidades y desafíos de la
industria del fitness. El sistema YouGym
consta de módulos clave que abarcan
diversos aspectos de la gestión de
gimnasios, incluyendo horarios, clientes,
entrenadores y servicios ofrecidos.

4. Pruebas de software
• INTRODUCCION
• En el desarrollo del aplicativo YouGym, nos dimos
cuenta que es de vital importancia asegurar la calidad y
funcionalidad del aplicativo. Estas pruebas tienen como
objetivo principal garantizar que el software cumpla
con los estándares de calidad, funcione correctamente
y brinde una experiencia óptima a los usuarios. Las
pruebas se aplicarán en el aplicativo con el fin de
abordar diferentes aspectos del software y asegurar su
correcto funcionamiento. Las pruebas se llevarán a
cabo para evaluar el comportamiento individual de
cada componente del software. Esto nos permitirá
identificar y corregir posibles errores o defectos a nivel
de módulos, clases o funciones. Al realizar estas
pruebas, podremos verificar que cada unidad de código
cumpla con los requisitos establecidos y funcione de
acuerdo a lo esperado.

5. Objetivos
• Cada prueba realizada al código se hace con
la intención de verificar el correcto
funcionamiento de cada una de las
funciones de este para que no hallan
sorpresas o errores para los usuarios, cada
funcionamiento se ha probado de manera
individual y conjunto aplicando las prácticas
vistas de Caja negra, Caja Blanca,
Incrementales, entre otros.

6. Alcance
• Las pruebas están previstas en
nuestro aplicativo para alcanzar a
utilizar las siguientes herramientas
de pruebas para analizar el código
en busca de los defectos
mencionados anteriormente

7. Modulos a probar
Dentro de nuestro aplicativo nosotros
consideramos que el modulo mas
importante de probar seria:
• el modulo de registro de empleados
dada su importancia y complejidad en
el aplicativo
Y como secundarios tendriamos:
• el modulo de clientes ya que con estos
2 tenemos la base operacional del
aplicativo
pero a largo plazo si nos es posible nos
gustaria implementar pruebas en los
siguientes modulos del aplicativo

8. Modulos a probar
Módulos del sistema a ser Probados: Gestión de Cliente
 Modificar
 Registrar
 Progreso
Gestión de Entrenador
 Modificar
 Registrar
 Firmar Contrato
Gestión de caja
 Historial de caja
Cerrar Sesión
Gestión de servicios
 Calendario
 Modificar
 Registro
Objetivos de las pruebas: Se validará la toma de datos, el registro de estos dentro del sistema, la visualización
de las respuestas del sistema de cada uno de los módulos.
Los documentos generados por el programa y las modificaciones que se le realicen a
estos.
También la secuencia lógica de las funcionalidades del sistema.
Detalles del Orden de Ejecución de los módulos:  Proyectos
 Revisión
 Aprobación
Responsabilidad de la Prueba: Las pruebas son responsabilidad del testing del equipo (Unit), quien en conjunto con
el usuario debe seleccionar las pruebas para asegurar la efectividad de los sistemas.

9. Pruebas unitarias
Las pruebas unitarias, de integración y de
sistemas se aplicarán en YouGym con el fin
de abordar diferentes aspectos del software
y asegurar su correcto funcionamiento. Las
pruebas unitarias se llevarán a cabo para
evaluar el comportamiento individual de
cada componente del software. Esto nos
permitirá identificar y corregir posibles
errores o defectos a nivel de módulos,
clases o funciones. Al realizar estas pruebas,
podremos verificar que cada unidad de
código cumpla con los requisitos
establecidos y funcione de acuerdo a lo
esperado. Así, podremos asegurar la calidad
y fiabilidad de cada componente del
sistema.

10. Clases de equivalencia caso practico
Variables de entrada Clases validad Clases invalidas
Nombre, campo de carácter String que esta entre 2 y 35 caracteres (obligatorio). 1) 2<Nombre y Nombre<35 1) Caracteres numéricos
2) Nombre<2 y Nombre>35
3) NULL
Apellido, campo de carácter String que esta entre 2 y 35 caracteres (obligatorio). 1) 2<Nombre y Nombre<35 1) caracteres numéricos
2) Nombre<2 y Nombre>35
3) NULL
Tipo de Identificación, Campo ComboBox que puede ser “TI” o “CC”
(obligatorio).
1) TI
2) CC
1) Cualquier carácter no valido
2) NULL
Identificación, Campo carácter de tipo Int de 10 caracteres numéricos
(obligatorio).
1) Identificación<9999999999 1) Caracteres no numéricos
2) Identificación>9999999999
3) NULL
Peso, Campo de carácter tipo Float de entre 2 a 4 caracteres numéricos
(obligatorio).
1) 0<peso<9999 1) Caracteres no numéricos
2) peso<0
3) peso>9999
4) NULL
Altura, Campo de carácter tipo Float de entre 3 a 5 caracteres numéricos
(obligatorio).
1) 0<altura y altura<99999. 1) Caracteres no numéricos
2) Altura>99999
3) Altura<=0
4) NULL
Sexo, Campo de tipo comboBox donde se puede escoger “M” o “F” (obligatorio). 1) M
2) F
1) Cualquier dato que no se valido.
2) NULL
Dirección, Campo de tipo String con un máximo de 100 caracteres (obligatorio). 1) Dirección<100 caracteres. 1) Cualquier dato que no sea String.
2) NULL
3) Dirección>100
Teléfono/Celular, Campo de tipo INT de 10 caracteres numéricos (obligatorio). 1) Celular<9999999999 1) 000000000<celular
2) Celular>9999999999
3) NULL
Correo, Campo de tipo String de entre 15 y 60 caracteres (Opcional). 1) 15<=correo<=60 caracteres. 1) Correo <15 caracteres
2) Correo > 60 caracteres.
Edad, Campo de tipo INT de entre 0 hasta 100 (obligatorio). 1) 0<Edad<999 1) Edad < 0
2) Edad > 999
3) NULL
Fecha de nacimiento, Campo de Tipo Fecha, “DD/MM/AA” (obligatorio). 1) Que su formato sea “DD/MM/AA” 1) Formato no valido.
2) NULL

11. Clases de equivalencia caso practico

12. Caso de prueba
Descripción de Casos de Prueba
NOMBRE: CASO DE PRUEBA REGISTRO DE CLIENTES
FUNCIÓN PROBAR: GESTIÓN DE REGISTRO
OBJETIVO: Una vez registrados los datos, el cliente podrá acceder a los servicios del gimnasio.
DESCRIPCIÓN: El formulario permite tomar la información de los clientes para almacenarla en una base de datos.
Escenarios de prueba Respuesta esperada de la aplicación Coincide (Si/No)
Campo Valor Tipo escenario
NOMBRE Victor Alfonso
a
Victor01sad…+35
“ “ = null
Correcto
Incorrecto
Incorrecto
Incorrecto
Usuario Valido
Usuario Invalido
Usuario Invalido
Usuario Invalido
Si
No
No
No
IDENTIFICACIÓN 1003377848
ABC
12345
245421356753212577
“ ” = null
Correcto
Incorrecto
Incorrecto
Incorrecto
Incorrecto
Usuario Valido
Usuario Invalido
Usuario Invalido
Usuario Invalido
Usuario Invalido
Si
No
No
No
No
APELLIDO Ardila Montalbán
343
Ardila Montadas..+35
B
Correcto
Incorrecto
Incorrecto
Incorrecto
Usuario Valido
Usuario Invalido
Usuario Invalido
Usuario Invalido
Si
No
No
No
TIPO DE IDENTIFICACIÓN “CC”
“TI”
Ext
NULL
Correcto
Correcto
Incorrecto
Incorrecto
Usuario Valido
Usuario Valido
Usuario Invalido
Usuario Invalido
Si
Si
No
No

13. Caso de prueba
PESO 65
-12
AA
100000
Correcto
Incorrecto
Incorrecto
Incorrecto
Valor Válido
Valor Invalido
Valor Invalido
Valor Invalido
Si
No
No
No
ALTURA 1.65 cm
178 cm
-3 cm
2999 cm
Correcto
Correcto
Incorrecto
Incorrecto
Valor Válido
Valor Válido
Valor Invalido
Valor Invalido
Si
Si
No
No
SEXO “M”
“F”
“Mujer”
Correcto
Correcto
Incorrecto
Dato Válido
Dato Válido
Dato Invalido
Si
Si
No
DIRECCIÓN Manzana A casa 26
NULL
manzana dadadadafdfs….+100
Correcto
Incorrecto
Incorrecto
Dato Válido
Dato Inválido
Dato Invalido
Si
No
No
TELÉFONO 3147133330
300405
2523673747891281
Correcto
Incorrecto
Incorrecto
Valor Válido
Valor Invalido
Valor Invalido
Si
No
No
CORREO valfonsoardila@unicesar.edu.co
NULL
dsad@
dkjdajdkasjda……+60
Correcto
Correcto
Incorrecto
Incorrecto
Dato Válido
Dato Válido
Dato Invalido
Dato Invalido
Si
Si
No
No
EDAD 20
4
-4
1000
Correcto
Correcto
Incorrecto
Incorrecto
Dato Válido
Dato Válido
Dato Invalido
Dato Invalido
Si
Si
No
No
FECHA DE NACIMIENTO 10/30/2002
10-30-2002
Diciembre 28
Correcto
Incorrecto
Incorrecto
Dato Válido
Dato Invalido
Dato Invalido
Si
No
No
Observaciones: Si todos los datos del cliente son correctos, se procederá a registrar en la base de datos y a guardar su valoración dentro de la aplicación de
gimnasio.

14. Ejecucion

15. Evaluacion de la prueba
Con las pruebas unitarias, cada
módulo que se ha probado se ha
asegurado de que cumplen los
requisitos y funcionan correctamente.
Esto permitira identificar y corregir
posibles errores o defectos en una
etapa temprana de desarrollo,
evitando así problemas más costosos
y complejos en etapas posteriores.

16. Pruebas de sistemas

17. Pruebas de sistemas

18. Pruebas de sistemas

19. Pruebas de sistemas

20. Pruebas de sistemas

21. Pruebas de sistemas

22. Pruebas de aceptacion
• El objetivo de las pruebas de
aceptación es validar que la solución
desarrollada cumpla con el
funcionamiento esperado y permitir al
usuario de dicho sistema determine su
aceptación, desde el punto de vista de
su funcionalidad y de su rendimiento.
Estas pruebas son realizadas por el
cliente, donde comprueba que el
sistema cumple con lo definido y se
obtiene la conformidad del cliente.

23. PREGUNTA CUMPLE CRITERIO DE EVALUACIÓN
1. ¿Hay términos en idiomas diferentes mezclados? SI CUMPLE
2. ¿Es simple el vocabulario utilizado? SI CUMPLE
3. ¿Se proporciona tiempo suficiente para realizar las entradas por teclado? SI CUMPLE
4. ¿Hay algún tipo de asistencia para los usuarios que hacen uso del sistema por primera vez? NO CUMPLE
3. ¿El sistema es fácil de operar para alguien que no recibió capacitación en su operación? SI CUMPLE
6. ¿Se entiende la interfaz y su contenido? SI CUMPLE
7. ¿Resulta fácil identificar un objeto o una acción? SI CUMPLE
8. ¿Resulta fácil entender el resultado de una acción? SI CUMPLE
9. ¿Está diseñada la interfaz para facilitar la realización eficiente de las tareas de la mejor forma posible? NO CUMPLE
10. ¿Son apropiados los mensajes presentados por el sistema? SI CUMPLE
11. ¿Actúa el sistema en la prevención de errores? SI CUMPLE
12. ¿El sistema informa claramente sobre los errores presentados? SI CUMPLE
13. ¿Se utilizan mensajes y textos descriptivos? SI CUMPLE
14. ¿Permite una cómoda navegación dentro del producto y una fácil salida de éste? NO CUMPLE
13. ¿Se permite al usuario personalizar la interfaz? SI CUMPLE
16. ¿Se proporciona información visual de dónde está el usuario, qué está haciendo y qué puede hacer a continuación? SI CUMPLE
17. ¿Existen atajos del teclado bien hechos? SI CUMPLE
18. ¿Se presenta al usuario la información que sólo necesita? SI CUMPLE

24. Conclusion del proceso de pruebas
• SonarQube demostró ser una herramienta muy útil en
nuestro proceso de evaluación, permitiéndonos
identificar tanto las debilidades como las fortalezas de
la aplicación. Su análisis detallado del código nos dio
una imagen clara de las áreas en las que se necesitaba
mejorar y en las que tuvimos un buen desempeño.
• Con SonarQube pudimos identificar vulnerabilidades,
errores lógicos y malas prácticas de programación que
de otro modo habrían pasado desapercibidos. Esto nos
permitió tomar acciones correctivas y fortalecer la
calidad y confiabilidad de nuestra aplicación.
• Además, SonarQube destacó las fortalezas de nuestra
aplicación y destacó las áreas en las que logramos
buenos resultados y cumplimos con los estándares de
calidad. Estas fortalezas pueden considerarse buenas
prácticas que deben preservarse y utilizarse en el
desarrollo futuro.

25. Metricas de software
• Las métricas de software desempeñan un
papel fundamental en la evaluación y mejora
continua de la calidad y el rendimiento del
software desarrollado. Estas métricas
permiten obtener información objetiva y
cuantitativa sobre diversos aspectos clave de
la aplicación, lo que brinda la capacidad de
tomar decisiones informadas y realizar
ajustes. Es importante tener en cuenta que
las métricas de software en nuestro proyecto
YouGym deben seleccionarse
cuidadosamente para garantizar su relevancia
y utilidad. Es fundamental definir métricas
específicas que se alineen con los objetivos y
requisitos del proyecto, y adaptarlas a
medida que evoluciona el software.

26. Estimacion del tamaño
Tamaño por punto de caso de uso
• # DE CASOS DE USO: 15
• # DE ACTORES: 3
• # DE CLASES: 8
UUCW = (15+8)*15 = 345
UAW = (3*3) = 9
UUCP = 9 + 345 = 354

27. Estimacion del tamaño
Total: 39.5
TCF = 0.6 + (0.01 * 39.5)
TCF = 0.995

28. Estimacion del tamaño
• ECF = 1.4 + (-0.03 * 20) = 0.8
• UCP = UUCP * TCF * ECF * 1
• UCP = 354 * 0.995 * 0.8 * 1
• UCP = 282, 784

29. Estimacion del tamaño puntos de objeto
• E = NOP / PROD
• # ENTRADAS = 7
• # SALIDAS = 5
• # ARCHIVOS = 4
• VENTANA = 7 * 2 = 14
• INFORME = 5 * 8 = 40
• COMPONENTE = 4 * 10 = 40
• TOTAL = 94
• NOP = (94 * (100-30)) / 100
• NOP = 65,8
• PROD = 13
• PM = NOP / PROD
• PM = 65,8 / 13
• PM = 5,0615
• PROD = 13
• PM = NOP / PROD
• PM = 56 / 13
• PM = 4.307692308

30. Analisis estimacion de tamaño
• En este caso puntual la estimacion de
tamaño nos permite tener una
aproximacion del tamaño de la
aplicacion tan solo con tener los
puntos de caso de uso de esta esto
puede resultar util al momento de
analizar si un proyecto es factible o
que tan extenso puede llegar a ser
despues de definir detalladamente los
caso de uso

31. Metricas por funcionalidad
Tamaño por punto de funcion
• Factor de complejidad de procesamiento (FCP):
• FC = 0.65 + (0.01 * FCP)
• = 0.65 + (0.01 * 38)
• = 1.03
• Puntos de función totales (FP):
• FP = PFS x FCP
• = 76 * 1.03
• = 78.28
• KLOC= (PF*líneas de código por punto de función)/1000
• KLOC = (78.28*58)/1000
• KLOC= 4.54

32. Analisis estimacion de tamaño
• Podemos concluir de los datos obtenidos de
las métricas que nos dieron el tamaño en
términos de KLOC miles de líneas de código
que las métricas de tamaño por funcionalidad
se limitan a calcular la cantidad de líneas
programadas requeridas para cumplir los
requerimientos usables que se definan esto
representa una gran diferencia debido a que
un software siempre entregara en crudo
cuantas líneas existen dentro del aplicativo
no importa de qué tipo sean si son creadas
por el usuario o el lenguaje de programación
como resultado de esto se obtiene una
medición de tamaño menor a la obtenida
usando otras herramientas para medir el
tamaño en líneas de código

33. Metricas por funcionalidad

34. Metricas por funcionalidad

35. Herramientas de evaluación de métricas
• Existen diversas herramientas disponibles en el mercado que pueden
ser utilizadas para la evaluación de métricas de software. Pero para
caso práctico de nuestro software utilizaremos la herramienta
sonarqube:
• SonarQube: Es una plataforma de análisis estático de código que
proporciona métricas y medidas de calidad del código. Permite
analizar proyectos de diferentes lenguajes de programación y ofrece
informes detallados sobre la calidad del código, cumplimiento de
estándares, cobertura de pruebas y más.

36. Ejecucion y analisis

37. Ejecucion y analisis

38. Ejecucion y analisis

39. Ejecucion y analisis

40. Conclusiones
• Nuestro codigo es altamente mantible,
con una buena puntuacion en
seguridad osease pocas
vulnerabilidades tiene una alta
densidad de lineas duplicadas y tiene
un nivel medio de fiabilidad
• Nota: como mejoras al aplicativo se
deberia reducir el numero de lineas de
codigo duplicadas y subir el nivel de
fiabilidad del aplicativo para asi poder
obtener un producto de software con
alta calidad

41. Estimacion del tamaño puntos caso de uso
• E = NOP / PROD
• # ENTRADAS = 7
• # SALIDAS = 5
• # ARCHIVOS = 4
• VENTANA = 7 * 2 = 14
• INFORME = 5 * 8 = 40
• COMPONENTE = 4 * 10 = 40
• TOTAL = 94
• NOP = (94 * (100-30)) / 100
• NOP = 65,8
• PROD = 13
• PM = NOP / PROD
• PM = 65,8 / 13
• PM = 5,0615
• PROD = 13
• PM = NOP / PROD
• PM = 56 / 13
• PM = 4.307692308 tamaño de un caso de uso

42. Estimacion del tamaño puntos de objeto
Total: 39.5
TCF = 0.6 + (0.01 * 39.5)
• TCF = 0.995
• ECF = 1.4 + (-0.03 * 20) = 0.8
• UCP = UUCP * TCF * ECF * 1
• UCP = 354 * 0.995 * 0.8 * 1
• UCP = 282, 784 funcionalidad del sistema

43. ESTIMACION DEL ESFUERZO (RESULTADOS Y ANALISIS)
• Esfuerzo = PF / (0,125)
• Esfuerzo = 92,13 / (0,125)
• Esfuerzo = 737,04
• Total de horas / hombre = UCP * 20
• Total de horas / hombre = 282,284 * 20
• Total de horas / hombre = 5.645,68
Se ha estimado un esfuerzo de 737,04 y un total de
horas/hombre de 5.645,68 para tu software.
Es importante tener en cuenta que estas estimaciones son
aproximaciones y que pueden variar.

44. ESTIMACION DE COSTOS MODELO DE PUNTOS DE
OBJETOS
COCOMO II:
• PM = 5,0615
• Tiempo Des = [C * (PM) ^d] * SCED% / 100
• "Schedule Flexibility" (Flexibilidad de Programación).
• d = 0.33 + 0.2 * (b – 1,01)
• d = 0.33 + 0.2 * (1,102 – 1,01)
• d = 0.3484
• Tiempo Des = [3 * (5,0615) ^0.3484] * 85% / 100
• Tiempo Des = 4,48653 Meses
• Personal de tiempo completo
• PDTC = PM / T des
• PDTC = 5,0615/ 4,48653
• PDTC = 1,128 = 2
• Costos = PDTC * T des * Salario
• Costos = 1,128 * 4,48653 * $1.200.000 = $607.297,008

45. ESTIMACION DE COSTOS MODELO DE DISEÑO
ANTICIPADO
COCOMO II:
• PM = 5,0615
• Tiempo Des = [C * (PM) ^d] * SCED% / 100
• "Schedule Flexibility" (Flexibilidad de Programación).
• d = 0.33 + 0.2 * (b – 1,01)
• d = 0.33 + 0.2 * (1,102 – 1,01)
• d = 0.3484
• Tiempo Des = [3 * (5,0615) ^0.3484] * 85% / 100
• Tiempo Des = 4,48653 Meses
• Personal de tiempo completo
• PDTC = PM / T des
• PDTC = 5,0615/ 4,48653
• PDTC = 1,128 = 2
• Costos = PDTC * T des * Salario
• Costos = 1,128 * 4,48653 * $1.200.000 = $607.297,008

46. ESTIMACION DE COSTOS MODELO COSMIC
COSMIC
Es un modelo que tiene la ventaja de no establecer límites arbitrarios
al tamaño funcional, así puede medir componentes de software muy
grandes o pequeños. Adicionalmente, está basado en el desglose
funcional de los componentes de software, alineado con las prácticas
de Ingeniería de software. En el método COSMIC, utilizamos la
ingeniería de software de nuestro proyecto para determinar cuáles
son los procesos funcionales y movimientos de datos que lo
componen. Posteriormente, asignamos un punto de función COSMIC
por cada movimiento de datos identificado.
CPIF = Costo Total del Proyecto / Tamaño Funcional Total
Costo del Proyecto = Tamaño Funcional Total * CPIF
Duración del Proyecto = Tamaño Funcional Total / Productividad del Equipo
Costo por punto de función = 83 / 92,13 = 0,9009
Costo de un proyecto de software = 4,814 x 0,9009 = 4,3369
Duración del proyecto = 92,13/ 83 = 1,11 MESES

47. Conclusiones generales
• De este proceso de desarrollo y
documentacion de software podemos
concluir que las diferentes herramientas
de analisis de codigo y medicion de
metricas proporcionan un panorama
mejor de los atributos, defectos y
virtudes de un aplicativo de software lo
que facilita la identificacion y
planificacion para la mejora del
aplicativo dentro de esos aspectos para
dotar al aplicativo de calidad de
software

55. fiabilidad