DOCUMENTO DE INGENIERIA DE SOFTWARE

Proyecto:
SISTEMA DE INFORMACIÓN WEB PARA LA ADMINISTRACIÓN DEL GIMNASIO
FLEX GYM CENTER

Producto:
SISTEMA PARA LA ADMINISTRACIÓN DEL GIMNASIO -SIGYM

FREDDY HERNÁNDEZ MENDOZA 1151078

FABIAN YESSID MENDOZA CORREDOR 1150074

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER

FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
SAN JOSÉ DE CÚCUTA
2015-1
 DOCUMENTO DE INGENIERIA DE SOFTWARE

Proyecto:
SISTEMA DE INFORMACIÓN WEB PARA LA ADMINISTRACIÓN DEL GIMNASIO
FLEX GYM CENTER

Producto:
SISTEMA PARA LA ADMINISTRACIÓN DEL GIMNASIO -SIGYM

FREDDY HERNÁNDEZ MENDOZA 1151078

FABIAN YESSID MENDOZA CORREDOR 1150074

Presentado a
MSC. I.S. JUDITH DEL PILAR RODRÍGUEZ TENJO

UNIVERSIDAD FRANCISCO DE PAULA SANTANDER

FACULTAD DE INGENIERÍA
INGENIERÍA DE SISTEMAS
SAN JOSÉ DE CÚCUTA
 2015-1

INTRODUCCIÓN

El proyecto se encarga de gestionar todas las diferentes actividades que se realizan

durante el funcionamiento diario del gimnasio, utilizando una plataforma que permita
el desarrollo efectivo y sistematizado de los procesos que se dan dentro del
establecimiento.
El sistema se realiza con el objetivo de brindar un servicio óptimo para los usuarios
que interactúan con la plataforma, dando la oportunidad de controlar los datos que se
ingresan y proporcionar fiabilidad en el manejo de los mismos.
Esta etapa nos lleva a plantearnos una cuestión fundamental acerca de cuál debe ser
el funcionamiento óptimo que ofrezca el sistema. Para llegar a esta conclusión,
debemos evaluar la situación actual dentro de la empresa, recopilar información para
la formulación de los requerimientos que el usuario del sistema debe suplir y definir las
alternativas de solución, que nos pueden llevar a un planteamiento de un sistema que
cumpla con todos los requisitos fundamentales del usuario final.
En este documento se encuentra la información referente al aseguramiento de la
calidad del software, métricas y pruebas del proyecto, estas hacen parte del control de
la calidad del proyecto. Las métricas que se van a evaluar basándonos en la
funcionalidad (Punto de Función, Adecuidad), usabilidad (Entendibilidad), eficiencia
(Comportamiento en el tiempo) y mantenibilidad (Índice de madurez, registrabilidad de
cambios). Por otra parte se encuentran las pruebas al proyecto SIGYM, estas se
dividen en unitarias, integración, del sistema y aceptación.
 1. PLAN DE CALIDAD DEL SOFTWARE

La calidad del software se da gracias a la mezcla de variables que influyen dentro del
proyecto. En el presente documento analizamos algunos de los factores que son
aplicables al proyecto, teniendo en cuenta dónde es necesaria la aplicación, e
indicando la dirección hacia donde debemos buscar las soluciones. Las actividades
del aseguramiento de la calidad del software contemplan aquellas tareas del proceso
de desarrollo de software que buscan asegurar el diseño, desarrollo y distribución de
una aplicación exitosa u otra forma de tecnología de software.

1.1 OBJETIVOS
1.1.1 Objetivos de SQA
Los principales objetivos del Aseguramiento de la Calidad del Software son los
siguientes:

 Planificar las actividades de aseguramiento de la calidad para monitorear

apropiadamente el desarrollo del producto.
 Revisar y auditar objetivamente los productos y las actividades para verificar
que están conformes con los procedimientos y estándares aplicables.
 Asegurar que cualquier desviación en el producto, el proceso, o los estándares
son elevados a la gerencia para poder resolverlas.
1.1.2 El Rol de SQA
Las personas que influyen en el proyecto de software (desarrollo y cliente) son las
principales responsables de la calidad del proyecto. El rol de SQA es supervisar la
forma en que los grupos ejecutan las acciones que le compete a cada uno de ellos.
Debido a esto, nos enfrentamos a estas posibles situaciones que afecte la calidad:

 La existencia de un procedimiento de SQA no quiere decir que los estándares

se están cumpliendo de acuerdo a lo planteado.
 El SQA solo puede hacerse efectivo al revisarse de forma periódica los soportes
que esta tenga.
  Es un error pensar que el personal de SQA puede cumplir con la calidad del
proyecto sin una guía específica.
Todo lo que puede hacer SQA es alertar a la dirección sobre las desviaciones a los
estándares y procedimientos establecidos.

1.1.3 Responsabilidades de SQA

Las principales responsabilidades del rol de SQA son las siguientes:

 Auditar con frecuencia para determinar el nivel de cumplimiento de los

estándares.
 Integrar el equipo para las revisiones finales del proyecto, registrando los
estándares y procedimientos no alcanzados durante el proyecto.
 Ejercer el rol de moderador en cada inspección que se haga en el diseño y otros
aspectos del proyecto.
 Verificar que estén correctamente diseñados los planes de desarrollo y calidad
del proyecto.
1.1.4 Funciones de SQA
Las principales funciones del rol de SQA, a través de todo el ciclo de vida, son las
siguientes:

 Prácticas de QA: se definen y están disponibles herramientas, técnicas,

métodos y estándares de desarrollo adecuados para ser usados como
estándares de las revisiones de QA.
 Evaluación de la planificación del proyecto de software: si no se planifican
prácticas de calidad adecuadas desde el inicio y sincronizadas con el plan del
proyecto, luego no serán implementadas.
 Evaluación de los requerimientos: como es extremadamente inusual que se
desarrollen productos de alta calidad a partir de requerimientos de baja calidad,
los requerimientos iníciales deben ser revisados contra los estándares de
calidad establecidos.
 Evaluación del proceso de diseño: se definen los medios para asegurar que el
diseño sigue las metodologías planificadas, que implementa los requerimientos
y que la calidad del diseño propiamente dicha es revisada independientemente.

1.2 MÉTRICAS DE CALIDAD

Se definen un conjunto de métricas para cada uno de los factores de calidad. El
esquema de graduación propuesto por McCall va en una escala de 0 (bajo) a 10 (alto).
A continuación mostraremos las métricas según McCall que se empleará en el
proyecto SIGYM

 Exactitud La precisión de los cálculos y el control.

 Completitud El grado en que se ha conseguido la total implementación de las

funciones requeridas.

 Consistencia: El uso de un diseño uniforme de técnicas de documentación a

los largo del proyecto de desarrollo de software.

 Estandarización en los datos: El uso de estructuras de datos de tipos

estándar a lo largo de todo el programa.

 Tolerancia a fallos: El daño que se produce cuando el programa encuentra un

error.

 Eficiencia en la Ejecución El rendimiento en tiempo de ejecución de un

programa.

 Independencia del Hardware El grado en que el software es independiente del

hardware en que opera.

 Modularidad La independencia funcional de los componentes del programa.

 Facilidad de Operación La facilidad de operación de un programa.

 Seguridad La disponibilidad de mecanismos que controlen o protejan los

programas o datos.

1.3 PRINCIPALES ACTIVIDADES EN PLAN DE CALIDAD SQA

 ASEGURAMIENTO DE CALIDAD. Establecer estándares en los

procedimientos que sean aplicables al entorno aplicable del proyecto, que nos
ayuden a obtener un producto de alta calidad.
 PLANIFICACIÓN DE LA CALIDAD. Selección de actividades que se
encuentran dentro de los estándares planteados para un proyecto de software
específico.

 CONTROL DE LA CALIDAD. Definición y aplicación de los procesos que

aseguren que los procedimientos y estándares.

 REPORTES DE PROBLEMAS Y ACCIONES CORRECTIVAS. Dentro del

proceso de calidad se generarán reportes de los inconvenientes, donde se
describe los procedimientos a ser utilizados para darle tratamiento al problema
(reportar, monitorear y resolver) relacionado con el producto y los procesos de
software.

 REALIZAR REVISIÓN TÉCNICA FORMAL (RTF) Una revisión técnica formal

(RTF) es una actividad de garantía de calidad del software llevada a cabo por
los ingenieros del software (y otros). Los objetivos de la RTF son: 1. Descubrir
errores en la función, la lógica o la implementación de cualquier representación
del software; 2. Verificar que el software bajo revisión alcanza sus requisitos; 3.
Garantizar que el software ha sido representado de acuerdo con ciertos
estándares predefinidos; 4. Conseguir un software desarrollado de forma
uniforme 5. Hacer que los proyectos sean más manejables.

 ASEGURAR QUE LAS DESVIACIONES SON DOCUMENTADAS Las

desviaciones detectadas dentro de los procesos deben ser documentadas y
manejarlas según las reglas iniciales del proceso. Se debe garantizar que los
encargados de la documentación de estos sucesos, actualicen de forma
adecuada cada descripción del proceso que reporta la desviación.

 DOCUMENTACIÓN Identificación de la documentación relativa a desarrollo,

Verificación Y Validación, uso y mantenimiento del software. Se establecen los
criterios de evaluación de los documentos y los parámetros para la aceptación
de los mismos.

 DOCUMENTACIÓN MÍNIMA REQUERIDA La documentación mínima es la

que va a ser útil a los usuarios y clientes en el proceso de ejecución del
producto.

 ESPECIFICACIÓN DE REQUERIMIENTOS DEL SOFTWARE El documento

de especificación de requerimientos deberá describir, de forma clara y precisa,
cada uno de los requerimientos esenciales del software además de las
 interfaces externas. El cliente deberá obtener como resultado del proyecto una
especificación adecuada a sus necesidades en el área de alcance del proyecto,
de acuerdo al compromiso inicial del trabajo y a los cambios que este haya
sufrido a lo largo del proyecto, que cubra aquellos aspectos que se haya
acordado detallar con el cliente.

 DESCRIPCIÓN DEL DISEÑO DEL SOFTWARE. El documento de diseño

especifica como el software será construido para satisfacer los requerimientos.
Deberá describir los componentes y subcomponentes del diseño del software,
incluyendo interfaces internas. Este documento será elaborado primero como
preliminar y luego será gradualmente extendido hasta llegar a obtener el
detallado. El cliente deberá obtener como resultado del proyecto el diseño de
un producto de software que cubra aquellos aspectos que se haya acordado
con el cliente incorporar al diseño.

1.4 FACTORES QUE DETERMINAN LA CALIDAD DEL SOFTWARE.

“Concordancia con los requisitos funcionales y de rendimiento explícitamente
establecidos, con los estándares de desarrollo explícitamente establecidos, con los
estándares de desarrollo explícitamente documentados y con las características
implícitas que se espera de todo software desarrollado profesionalmente”, [Pressman
98].
Según Pressman se clasifican en dos grupos:
1. Factores que pueden ser medidos directamente.
2. Factores que solo pueden ser medidos indirectamente.
Por otro lado, según McCall se clasifican en tres grandes grupos:

 Los Factores de Revisión incluyen: Flexibilidad, mantenibilidad y

contestación.

 Los Factores de Transición incluyen: Portabilidad, reusabilidad e

interoperabilidad.

 Los factores de Operación incluyen: Eficiencia, Integridad, Usabilidad,

Fiabilidad y Corrección.
CAPACIDAD DE REVISIÓN

- Facilidad de mantenimiento (¿Puedo localizar los fallos?): El esfuerzo requerido

para localizar y reparar errores.
- Flexibilidad (¿Puedo añadir nuevas opciones?): El esfuerzo requerido para
modificar una aplicación en funcionamiento.
- Facilidad de prueba (¿Puedo probar todas las opciones?): El esfuerzo requerido
para probar una aplicación de forma que cumpla con lo especificado en los
requisitos

CAPACIDAD DE TRANSICION

- Portabilidad (¿Podré usarlo en otra máquina?): El esfuerzo requerido para transferir

la aplicación a otro hardware o sistema operativo
- Reusabilidad (¿Podré utilizar alguna parte del software en otra aplicación?): Grado
en que partes de una aplicación pueden utilizarse en otras aplicaciones
- Interoperabilidad (¿Podrá comunicarse con otras aplicaciones o sistemas
informáticos?: El esfuerzo necesario para comunicar la aplicación con otras
aplicaciones o sistemas informáticos.

CARACTERISTICAS OPERATIVAS

- Corrección (¿Hace lo que se le pide?): El grado en que una aplicación satisface

sus especificaciones y consigue los objetivos encomendados por el cliente.
- Fiabilidad (¿Lo hace de forma fiable todo el tiempo?): El grado que se puede
esperar de una aplicación lleve a cabo las operaciones especificadas y con la
precisión requerida.
- Eficiencia (¿Qué recursos hardware y software necesito?): La cantidad de recursos
hardware y software que necesita una aplicación para realizar las operaciones con
los tiempos de respuesta adecuados.
- Integridad (¿Puedo controlar su uso?): El grado con que puede controlarse el
acceso al software o a los datos a personal no autorizado.
- Facilidad de uso (¿Es fácil y cómodo de manejar?): El esfuerzo requerido para
aprender el manejo de una aplicación, trabajar con ella, introducir datos y conseguir
resultados.

SQA (Aseguramiento de la Calidad del Software)

El SQA puede realizar unas sugerencias para obtener el apoyo y la cooperación de los
diferentes grupos en la organización, estas son:

1. CON EL AREA OPERATIVA

- Asesorarlos en sus funciones con respecto a la calidad
- Ser guía y mentor en prácticas de ingeniería del software y técnicas de verificación
y validación como revisiones
- Ayudar a los ingenieros de software a visualizar cómo sus actividades influyen en
la calidad del producto final
- Sensibilizarlos y mostrarles como los procesos les ayudan en la ejecución de sus
tareas diarias.

2. CON LA ADMINISTRACIÓN DEL PROYECTO

- Asesorarlos en aspectos relacionados con su proyecto
- Recompensarlos por sus esfuerzos, dándoles visibilidad correspondiente.
- Señalando las desviaciones de los procesos y/o productos, pero aplaudiendo los
logros.
- Capacitándolos en los procesos y procedimientos para mejorar la calidad
- Escuchándolos y escalando sus sugerencias de mejora a los procesos.

3. CON LA GERENCIA MEDIA

- Mantenerlos informados sobre el estado de los proyectos a su cargo
- Asesorarlos en las funciones que corresponden de acuerdo de acuerdo a los
procesos definidos por la organización
- Proporcionarles visibilidad sobre los problemas comunes de aseguramiento de
calidad en sus áreas y/o de otras áreas de la organización.
- Sugiriendo mejoras a prácticas administrativas y de ingeniería de software en sus
proyectos.
4. CON LA ALTA GERENCIA
- Vigilando el apego a procesos, procedimientos, estándares y políticas definidos en
la organización.
- Escalando problemas que deban ser atendidos por este nivel
- Reportando los resultados de diferentes áreas
Brindando visibilidad sobre la calidad de productos.

1.5 MÉTRICAS DE CALIDAD APLICADAS AL ANÁLISIS, DISEÑO E

IMPLEMENTACIÓN DEL PROYECTO

En el proyecto es importante la aplicación de ciertas métricas definidas por McCall para

el aseguramiento de la calidad.

Punto de Factor Criterio

vista
Facilidad de Facilidad de operación: Atributos del software que
uso determinan la facilidad de operación del software.
Facilidad de comunicación: Indicador del software
que determina la calidad de entendimiento que tienen
las salidas y entradas.
Operación Facilidad de aprendizaje: Indicador que proporciona
del producto la facilidad que tiene el usuario al utilizar el software
en su primer uso.
Integridad Control de accesos. Atributos del software que
proporcionan control de acceso al software y los datos
que maneja.
Facilidad de auditoría: Atributos del software que
facilitan la auditoría de los accesos al software.
Seguridad: La disponibilidad de mecanismos que
controlen o protejan los programas o los datos.
Corrección Completitud: Atributos del software que proporcionan
la implementación completa de todas las funciones
requeridas.
 Consistencia: Atributos del software que
proporcionan uniformidad en las técnicas y notaciones
de diseño e implementación.
Trazabilidad o rastreabilidad: Atributos del software
que proporcionan una traza desde los requisitos a la
implementación con respecto a un entorno operativo
concreto.
Fiabilidad Precisión: Atributos del software que proporcionan el
grado de precisión requerido en los cálculos y los
resultados.
Tolerancia a fallos: Atributo que indica la continuidad
y el normal funcionamiento del software luego de que
se presente una situación fuera de lo contemplado.
Modularidad: Atributos del software que proporcionan
una estructura de módulos altamente independientes.
Simplicidad: Atributos del software que posibilitan la
implementación de funciones de la forma más
comprensible posible.
Eficiencia Eficiencia en ejecución: Atributos del software
muestra el tiempo de respuesta en lapsos aceptables
dentro del funcionamiento.
Eficiencia en almacenamiento: Atributos del
software utilizan el espacio de almacenamiento solo
para las funciones requeridas y de forma óptima.
Revisión del Facilidad de Modularidad.
producto mantenimient Simplicidad.
o Consistencia.
Concisión: Atributos del software que posibilitan la
implementación de una función con la menor cantidad
de códigos posible.
Auto descripción: Atributos del software que
proporcionan explicaciones sobre la implementación
de las funciones.
Facilidad de Modularidad.
prueba Simplicidad.
Auto descripción.
Instrumentación: Atributos del software que
posibilitan la observación del comportamiento del
 software durante su ejecución para facilitar las
mediciones del uso o la identificación de errores.
Flexibilidad Auto descripción.
Capacidad de expansión: Atributos del software que
posibilitan la expansión del software en cuanto a
capacidades funcionales y datos.
Generalidad: Atributos del software que proporcionan
amplitud a las funciones implementadas.
Modularidad.
Reusabilidad Auto descripción.
Generalidad.
Modularidad.
Independencia entre sistema y software: Atributos
del software que determinan su dependencia del
entorno operativo.
Independencia del hardware: Atributos del software
que determinan su dependencia del hardware.

Interoperabili Modularidad.
dad Compatibilidad de comunicaciones: Atributos del
software que posibilitan el uso de protocolos de
comunicación e interfaces estándar.
Compatibilidad de datos: Atributos del software que
posibilitan el uso representaciones de datos estándar.
Estandarización en los datos: El uso de estructuras.
Revisión Portabilidad * Auto descripción.
Del * Modularidad.
Producto * Independencia entre sistema y software.
* Independencia del hardware.
Tabla 1. Métricas de calidad aplicadas al análisis, diseño e implementación del
proyecto

2. METRICAS DEL PROYECTO SIGYM

 2.1 MÉTRICAS DE FUNCIONALIDAD
a. Métrica de punto de función.
ILF son los ficheros lógicos internos en este caso se tomaron como entidades ya que
son Grupos de datos relacionados entre sí internos al sistema.

CANTIDAD DE ILF EN EL PROYECTO

# ENTIDAD

1 Empleado

2 Cliente

3 Maquina

4 Pago

5 Suscripción

6 Rutina Cliente

7 Proveedor

8 Mantenimiento

9 Ejercicio

10 Reserva

Funciones del Proyecto SIGYM

Entradas del usuario

1 Registrar Cliente

2 Registrar Empleado

3 Registrar Máquina

4 Registro de Pago

5 Registrar Proveedor
 6 Registrar Mantenimiento

7 Calcular nómina

8 Iniciar Sesión

9 Asignar Rutina

10 Realizar Reserva

Salidas del usuario

11 Mostrar Cálculo de Nómina

12 Generar Comprobante de Pago

13 Generar Estadísticas

Consultas del usuario

14 Consultar Cliente

15 Consultar Empleados

16 Consultar Máquinas

17 Consultar Rutina

18 Consultar Proveedores

19 Consultar Reservas

20 Consultar Pagos

21 Consultar Ejercicio

Tabla 1, Definición de actividades desarrolladas dentro del proyecto.

CÁLCULO DE PUNTOS DE FUNCIÓN SIN AJUSTAR

Baja Media Alta Total

EI 7∗3 2∗4 1∗6 35
EO 3∗4 0 0 12
EQ 5∗3 2∗4 1∗6 29
ILF 4∗7 6 ∗ 10 0 88
 ELF 0 0 0 0
PFSA 164

OBTENER PF AJUSTADOS

# Factor VALOR

1 Comunicación de datos 3

2 Proceso distribuido 2

3 Objetivos de rendimiento 2

4 Configuración de explotación compartida 0

5 Tasa de transacciones 1

6 Entrada de datos en línea 4

7 Eficiencia con el usuario final 4

8 Actualizaciones en línea 2

9 Lógica de procesos interno compleja 3

10 Reusabilidad del código 5

11 Conversión e instalación contempladas 0

12 Facilidad de operaciones 2

13 Instalaciones múltiples 0

14 Facilidad de cambios 3

15 Ajuste de complejidad técnica 31

FACTOR DE COMPLEJIDAD TÉCNICA

𝐹𝐶𝑇 = 0.65 + (0.01 ∗ 31)

𝐹𝐶𝑇 = 0.96
𝑃𝐹𝐴 = 𝑃𝐹𝑆𝐴 ∗ 𝐹𝐶𝑇
𝑃𝐹𝐴 = 164 ∗ 0.96
𝑃𝐹𝐴 = 157.44

CÁLCULO DE ESFUERZO
Líneas de código

Entorno y leguaje Líneas de código por PF Horas por PF

Lenguajes 2 generación 300 20 a 30

Lenguajes 3 generación 100 10 a 20

Lenguajes 4 generación 20 5 a 10

𝐿𝑂𝐶 = 𝑃𝐹𝐴 ∗ (𝐿𝑂𝐶𝑠 𝑝𝑜𝑟 𝑃𝐹)

𝐿𝑂𝐶 = 157.44 ∗ 20
𝐿𝑂𝐶 = 3149

Esfuerzo horas/personas:
1
𝐸𝐻𝑃 = 157.44/( 𝑃𝑒𝑟𝑠𝑜𝑛𝑎/ℎ𝑜𝑟𝑎𝑠)
8
𝐸𝐻𝑃 = 1259.52

Este resultado lo dividimos en 2 que son la cantidad de personas participantes en el

proyecto SIGYM

Duración del proyecto = 629.76 horas

Para calcular la estimación del proyecto en meses estimamos que se trabajaran 6

horas al día, de lunes a viernes. De este modo la duración en meses es:

Duración en meses = 629.76 horas/120 horas por mes

Duración en Meses = 5.248 Meses

 b. Métrica de Adecuidad
En el proyecto se busca aplicar la métrica de adecuidad, teniendo en cuenta qué tan
completa está la funcionalidad, esto se hace en base a las funciones faltantes
identificadas previamente en la fase de evaluación y haciendo un conteo respecto a
las funciones especificadas en los requisitos del proyecto.

En esta métrica se plantea la siguiente fórmula:

𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠𝐹𝑎𝑙𝑡𝑎𝑛𝑡𝑒𝑠
𝑋 =1−
𝑇𝑜𝑡𝑎𝑙𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠

Los valores obtenidos esperados deben estar entre el rango de 0 a 1 (0 <= X <= 1),
entre más cercano a 1, más completa se considera el proyecto.

Aplicación

En la Tabla 1 vista anteriormente se encuentra el listado de las funciones del Proyecto

SIGYM, en esta se definieron 30 funciones, de las cuales al realizar un análisis de las
funciones faltantes o que requieren cambios se encuentran las siguientes:

FUNCIONES FALTANTES O POR CAMBIOS

1 Asignar Rutina

2 Realizar Reserva
 3 Generar Estadística

4 Consultar Rutina

5 Consultar Ejercicio

Tabla 5. Funciones Faltantes proyecto SIGYM- Métrica Adecuidad

Al analizar los datos podemos definir las variables, definimos:

FuncionesFaltantes: 5
TotalF: 21
Aplicando la formula obtenemos,

𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠𝐹𝑎𝑙𝑡𝑎𝑛𝑡𝑒𝑠
𝑋 =1−
𝑇𝑜𝑡𝑎𝑙𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠

5
𝑋 =1−
21

𝑋 = 0.76

Podemos concluir que tenemos un 80.9% de la funcionalidad desarrollada en esta

etapa del proyecto.

2.2 MÉTRICA DE USABILIDAD

La métrica de usabilidad se utiliza para calcular el esfuerzo necesario para el uso del
software y la valoración individual de tal uso, por parte de un conjunto de usuarios.

Métrica de Entendibilidad
En el proyecto se busca aplicar la métrica de Entendibilidad con el propósito de
comprender qué proporción de las funciones del sistema son evidentes al usuario.
Este proceso se realiza contando las funciones evidentes al usuario y realizando una
comparación con el número total de funciones.

En esta métrica se plantea la siguiente fórmula:

𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠𝑁𝑜𝐸𝑛𝑡𝑒𝑛𝑑𝑖𝑏𝑙𝑒𝑠
𝑋 = 1−
𝑇𝑜𝑡𝑎𝑙𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠
Donde,
FuncionesNoEntendibles = número de funciones faltantes
TotalF = número de funciones descritas en la especificación de requisitos

Los valores obtenidos esperados deben estar entre el rango de 0 a 1 (0 <= X <= 1),
entre más cercano a 1, mejor se considera el proyecto.

Aplicación

En la Tabla 1 vista anteriormente se encuentra el listado de las funciones del Proyecto

SIGYM, en esta se definieron 20 funciones, de las cuales al realizar un análisis de las
funciones evidentes se encuentran las siguientes:

FUNCIONES EVIDENTES

1 Registrar Cliente

2 Registrar Empleado

3 Registrar Máquina

4 Registrar Proveedor

5 Registrar Mantenimiento

6 Iniciar Sesión

7 Asignar Rutina

8 Realizar Reserva

9 Mostrar Cálculo de Nómina

10 Generar Comprobante de Pago

11 Generar Estadísticas

12 Consultar Cliente

13 Consultar Empleados

14 Consultar Máquinas
 15 Consultar Rutina

16 Consultar Proveedores

17 Consultar Reservas

18 Consultar Pagos

Tabla 6. Funciones Evidentes proyecto SIGYM- Métrica Entendibilidad

Al analizar los datos podemos definir las variables, definimos:

FuncionesEvidentes: 18
TotalF: 20
Aplicando la formula obtenemos,

𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠𝐹𝑎𝑙𝑡𝑎𝑛𝑡𝑒𝑠
𝑋 =1−
𝑇𝑜𝑡𝑎𝑙𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠

2
𝑋 =1−
20

𝑋 = 0.9

Podemos concluir que tenemos un 90% de entendibilidad en sus funciones, quiere

decir que la cantidad de funciones evidentes del proyecto, es alta.

2.3 MÉTRICA DE MANTENIBLIDAD

Es el esfuerzo necesario para realizar modificaciones específicas.

Índice de Madurez del Software (IMS1)

Proporciona una indicación de la estabilidad de un producto software basada en los
cambios que ocurren con cada versión del producto.

El índice de madurez del software se calcula de la siguiente manera:

𝑀𝑇 − (𝐹𝑐 + 𝐹𝑎 + 𝐹𝑒)
𝐼𝑀𝑆 =
𝑀𝑇

1
IMS- Índice de Madurez del Software
Con el IMS se determina la siguiente información:

MT= Número de módulos en la versión

actualFc= Número de módulos en la versión actual que se han cambiado
Fa= Número de módulos en la versión actual que se han añadido
Fe= Número de módulos en la versión actual que se han eliminado

A medida que el IMS se aproxima a 1 el producto se empieza a estabilizar. El IMS

puede emplearse también como métrica para la planificación de las actividades de
mantenimiento del software.

Aplicación

En la siguiente tabla se establecen los módulos del proyecto, donde se analizan

cuales módulos se han añadido, cuales eliminado y cuales modificados:

MODULOS Fc- Fa- Añadido Fe-

Modificados Eliminado

Gestión de Clientes

Gestión de Empleados

Gestión de Proveedores

Gestión de Maquinas

Gestión de Reservas X

Gestión de Rutinas X

Cálculo de Nómina X

Gestión de Estadísticas X

Gestión de Pago de Suscripción

Identificación Mediante Código QR X

Total 2 3 0

Tabla 8. Módulos del proyecto SIGYM- Métrica IMS

Se aplica la formula,

𝑀𝑇 − (𝐹𝑐 + 𝐹𝑎 + 𝐹𝑒)
𝐼𝑀𝑆 =
𝑀𝑇
10 − (2 + 3 + 0)
𝐼𝑀𝑆 =
10
𝐼𝑀𝑆 = 0.5
El resultado que arroja la realización de la métrica, muestra que esta tiene un índice
de madurez medio con un 50%, requiere mejorar.

Registrabilidad de cambios
En el proyecto se busca aplicar la métrica de registrabilidad de cambios, esta se aplica
con el propósito de verificar si se registran adecuadamente los cambios a la
especificación y a los módulos con comentarios en el código. Esta se aplica registrando
la proporción de información sobre cambios a los módulos.

En esta métrica se plantea la siguiente fórmula:

𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠𝐶𝑎𝑚𝑏𝑖𝑎𝑛𝑡𝑒𝑠
𝑋 =1−
𝑇𝑜𝑡𝑎𝑙𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠
Donde,
FuncionesCambiantes = número de cambios a funciones o módulos que tienen
comentarios confirmados
TotalF = total de funciones o módulos modificados

Los valores obtenidos esperados deben estar entre el rango de 0 a 1 (0 <= X <= 1),
Entre más cercano a 1, más registrable. 0 indica un control de cambios deficiente o
pocos cambios y alta estabilidad.

Aplicación

En la Tabla 9 vista anteriormente se encuentra el listado de las funciones del Proyecto

SIGYM, en esta se definieron 20 funciones, de las cuales al realizar un análisis de las
funciones que requieren cambios se encuentran las siguientes:

FUNCIONES QUE REQUIEREN CAMBIOS

 1 Calcular nómina

2 Asignar Rutina

3 Realizar Reserva

4 Mostrar Cálculo de Nómina

5 Generar Estadísticas

6 Consultar Rutina

7 Consultar Reservas

Tabla 9. Funciones que requieren cambios del proyecto SIGYM- Métrica

Registrabilidad de Cambios

Al analizar los datos podemos definir las variables, definimos:

Aplicando la formula obtenemos,

𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠𝐶𝑎𝑚𝑏𝑖𝑎𝑛𝑡𝑒𝑠
𝑋 =1−
𝑇𝑜𝑡𝑎𝑙𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠

7
𝑋 =1−
20

𝑋 = 0.65

Podemos concluir que el valor obtenido está en un nivel medio con un 65%, y se deben
aplicar las mejoras.

3. Plan de Pruebas

3.1 Antecedentes y Propósito

3.1.1 Antecedentes
 En este caso será la primera vez que se realice un kit de pruebas en el producto
del software SIGYM el cual ayudara a determinar fallos en el sistema mediante
diferentes técnicas, herramientas y pruebas realizadas en general. Lo cual nos
 dará un punto de partida que nos permitirá realizar un análisis sobre la calidad
con la que cuenta el software SIGYM.
 En la actualidad existen diferentes navegadores web y cada uno de estos
interpreta de una manera diferente una misma página HTML por lo que se debe
realizar las pruebas respectivas en los diferentes navegadores para que la
página se visualice de igual manera en la mayoría de los navegadores web que
existen en el mercado.

3.2 Propósito de la Evaluación

"Calidad" se refiere a todas las cosas buenas que nos gustaría ver en nuestro producto.
La idea fundamental es hacer un producto de calidad y esto se logra manteniendo
calidad en mente todo el tiempo y realizando las actividades para esto. Las pruebas
son una actividad de aseguramiento de calidad. Es necesario un plan para seleccionar
y coordinar todas las actividades para asegurar la calidad del producto durante el ciclo
de vida del proyecto, para ello a de especificarse para cada iteración a realizarse cuál
es el objetivo a conseguir con la aplicación de este plan:
 Encontrar tantos errores como sea posible.
 Supervisar si se cumple las especificaciones de diseño.
 Supervisar si se cumple los requisitos del análisis.
 Realizar pruebas de rendimiento y capacidad.
 Encontrar los problemas importantes y determinar los riesgos percibidos de la
calidad.
 Otros.

3.3 Motivadores de la prueba

 Requerimientos Funcionales
 Requerimientos no Funcionales
 Cambios de Requerimientos

3.4 Objetos a ser Evaluados

Los objetos a ser evaluados en las pruebas son:
• La Interfaz Gráfica de Usuario
• El código fuente.
• La transmisión de datos
• El nivel de Seguridad e integridad
• La transacción interna de datos entre capas.
• Las características del Hardware requeridas para el sistema
• Los tiempos de Respuesta

3.5 Ámbito de las Pruebas

A continuación se menciona el conjunto de tareas necesarias para conseguir el
objetivo del proyecto Sistema de información web para la administración del gimnasio
Flex Gym Center.

3.5.1 Dentro del Ámbito

 Depuración del código fuente: Éste debe ser entendible, que exista
modularidad, estructurado de tal manera que se evite la redundancia de código
innecesario incrementando el tamaño del código y desperdiciando recursos del
sistema.

 Evaluación de la Interfaz: La interfaz de usuario debe ser entendible para

cualquier tipo usuario que la utilice, permitiéndole hacer sus funciones sin
ningún tipo de contratiempo.

 Transporte de datos: Los datos se deben mantener auténticos sin llegar a sufrir
alteraciones de ningún tipo.

3.5.2 Fuera del Ámbito

 Evaluación del Hardware: El hardware utilizado debe contar con ciertos

requerimiento mínimos para poder cumplir su labor, cosas como compatibilidad
de componentes, tiempos de respuesta, son piezas fundamentales que ayudan
a la mejor comodidad del cliente con la aplicación.

 Usabilidad del Software: Qué tan contento se siente el usuario final con la
aplicación.
3.6 Lista de Ideas de las Pruebas
Las pruebas serán identificadas siguiendo la técnica de generación de casos de
prueba a través de los casos de uso, detallando los siguientes pasos:
• Para cada caso de uso, se identifican los caminos posibles, permitiendo
establecer los escenarios.
• Para cada uno de los caminos, se identifican los conjuntos de valores de entrada
y precondiciones, al igual que el resultado esperado.
• Se hace, a través de una tabla, un resumen por cada caso de uso que muestre
los distintos caminos posibles con sus entradas y salidas.
Los recursos utilizados para la identificación de las pruebas se mencionan a
continuación:
• El documento de especificación de requerimientos del software.
• El documento de arquitectura de software.
• Generación de pruebas de sistema a partir de la especificación funcional.
• Mejora de la calidad de los requisitos mediante la generación de pruebas.
• Especificación e implementación de casos de prueba.

3.7 Enfoque de las Pruebas

Los tipos de pruebas que se realizarán al software son:

 Prueba de medición de tiempos de respuesta a la base de datos

 Pruebas de interfaces de usuario

 Pruebas de función

 Pruebas de fallas y recuperación

 Pruebas de seguridad y control de acceso

En el documento “Kit de Pruebas.doc” se encuentran todas las especificaciones de las
pruebas, donde se describe los procedimientos que se van a realizar, las herramientas
que se van a utilizar y los recursos necesarios para realizar la prueba.

3.8 Herramientas para las Pruebas

A continuación se describen algunas herramientas utilizadas para las pruebas:

3.8.1 Software
Durante las pruebas se utilizaron las siguientes herramientas de supervisión del
sistema:

MariaDB 10.0.17: Sistema de Administración de base de datos

Cinebench 11.5: Mide el rendimiento del PC
Aptana Studio 3.6.1

Nombre Versión

MariaDB 10.0.17 Sistema de administration de base de datos

PageSpeed Herramienta para evaluar el rendimiento de
la página.
Aptana Studio 3.6.1 Funcionalidad y ejecución

3.8.2 Herramientas de Soporte y Productividad

Durante las pruebas se utilizaran las siguientes herramientas de supervisión del
sistema:

 Architect Enterprise: Combina el poder de la última especificación UML 2.1 con

alto rendimiento, interfaz intuitiva, para traer modelado avanzado al escritorio, y
para el equipo completo de desarrollo e implementación.
  Microsoft Project: Es un software de administración de proyectos diseñado,
desarrollado y comercializado por Microsoft para asistir a administradores de
proyectos en el desarrollo de planes, asignación de recursos a tareas, dar
seguimiento al progreso, administrar presupuesto y analizar cargas de trabajo.

Nombre Versión Tipo de Descripción

herramienta

Architect 8.0 Middle CASE Combina el poder de la

Enterprise (M-CASE), última especificación UML
herramientas 2.1 con alto rendimiento,
para interfaz intuitiva, para traer
automatizar modelado avanzado al
tareas en escritorio, y para el equipo
el análisis y di completo de desarrollo e
seño de la implementación.
aplicación.
Microsoft Project Office 2013 Middle CASE Es un software de
(M-CASE), administración de
herramientas proyectos diseñado,
para desarrollado y
automatizar comercializado por Microsoft
tareas en para asistir a administradores
el análisis y di de proyectos en el desarrollo
seño de la de planes, asignación de
aplicación. recursos a tareas, dar
seguimiento al progreso,
administrar presupuesto y
analizar cargas de trabajo.

3.9 Hardware
Se describirán cada uno de los dispositivos físicos que comprenden el sistema de
computación a utilizar para la realización del conjunto de pruebas.
 Recurso Cantidad Descripción

Computador portátil 1 Computador con 3 Gb de RAM Core

i3 Sistema operativo Kubuntu 14.04
Computador de 1 Computador con 4 Gb de RAM
Escritorio Pentium Dual Core Sistema operativo
Windows 7

3.10 Configuraciones de Pruebas de ambiente

Nombre de Descripción Implementación de

Configuración la Configuración
Física
Prueba de La Prueba de ambiente se ejecutara Dentro de un marco
Ambiente con el fin de medir todos los elementos de ejecución del
físicos que influyen en el sistema, es programa, teniendo
PA-001 decir todos los factores, tanto internos en cuenta factores
como externos que en extremas externos como la
circunstancias puedan causarle electricidad; y
alteraciones al optimo desempeño de la factores como la
plataforma. conexión con la base
de datos

4 Entregables
4.1 Lista de Entregables de Pruebas

Entregable Descripción
Plan de En este documento se plantea un enfoque global del plan a
pruebas realizar con las pruebas determinando herramientas, tipo de
pruebas criterios, personal.
 Entregable Descripción
Kit de pruebas En este documento se plantean las pruebas que se van a aplicar
en el proyecto sistema de información web para la
administración del gimnasio flex gym
Pruebas En este documento se evalúan las pruebas fundamentales
unitarias definidas en el kit de pruebas que permiten evaluar el código del
proyecto sistema de información web para la administración del
(Rendimiento o gimnasio flex gym para con esto poder verificar el correcto
pruebas de funcionamiento de lógica y función.
Funcionalidad)
Pruebas de En este documento se evalúan las pruebas de integración entre
integración la interfaz gráfica y el código definidas en el kit de pruebas que
permiten en que el proyecto sistema de información web para la
(Pruebas de administración del gimnasio flex gym, tenga cohesión entre el
Interfaces de código y su interfaz grafica
Usuario)
Pruebas de En este documento se evalúa el grado de aceptación del cliente
aceptación al proyecto sistema de información web para la administración
del gimnasio flex gym, mediante los requerimientos funcionales
que harán la vez de contrato. Todo esto establecido en el kit de
pruebas

5 CRITERIO PARA EL INICIO Y FIN DEL PLAN DE PRUEBAS

5.1 Criterios de inicio
Para iniciar el plan de pruebas:
 La base de datos debe tener una buena cantidad de datos.
 Los módulos a revisar deben estar terminados en su totalidad.
 Se deben tener la especificación de los casos de uso.

5.2 Criterios de fin

 Se deben haber evaluado todas las especificaciones y requerimientos del

sistema.
5.3 Criterio de suspensión y retomo de actividades
  En el caso de existir fallos en el sistema se debe mandar a corregir y revisar
los componentes que se deben cambiar.

6 CRITERIOS PARA EL LANZAMIENTO

6.1 Criterios de evaluación

 No pueden existir errores sin solución de gravedad 1 o gravedad 2.

 No pueden existir errores que no se haya implementado una solución que

tengan prioridad 1 o prioridad 2 y que no representen gravedad dentro del
proyecto.

 Los casos de prueba se han completado satisfactoriamente.

6.2 Clasificación de errores.

CALIFICACIÓN DEFINICIÓN DE GRAVEDAD DEFINICIÓN DE PRIORIDAD

1 El error provoca el bloqueo del El error debe corregirse lo antes

sistema o la pérdida de datos. posible. El error bloquea el
progreso en esta área.

2 El error causa problemas graves El error debe corregirse antes del

en la funcionalidad u otros lanzamiento del producto.
aspectos importantes; el producto
se bloquea en casos poco claros.