DOCUMENTO DE INGENIERIA DE SOFTWARE · PDF fileCompletitud El grado en que se ha conseguido la...

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

vista

Factor Criterio

Operación

del producto

Facilidad de

uso

Facilidad de operación: Atributos del software que

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.

Facilidad de aprendizaje: Indicador que proporciona

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

producto

Facilidad de

mantenimient

o

Modularidad.

Simplicidad.

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

prueba

Modularidad.

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

dad

Modularidad.

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

Del

Producto

Portabilidad * Auto descripción.

* Modularidad.

* 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



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

𝐿𝑂𝐶 = 157.44 ∗ 20

𝐿𝑂𝐶 = 3149

Esfuerzo horas/personas:

𝐸𝐻𝑃 = 157.44/(1

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

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.


𝑋 = 1 −𝐹𝑢𝑛𝑐𝑖𝑜𝑛𝑒𝑠𝑁𝑜𝐸𝑛𝑡𝑒𝑛𝑑𝑖𝑏𝑙𝑒𝑠


Donde,

FuncionesNoEntendibles = número de funciones faltantes

TotalF = número de funciones descritas en la especificación de requisitos


entre más cercano a 1, mejor se considera el proyecto.

Aplicación



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


10 Generar Comprobante de Pago


12 Consultar Cliente

13 Consultar Empleados

14 Consultar Máquinas

15 Consultar Rutina

16 Consultar Proveedores


18 Consultar Pagos

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


FuncionesEvidentes: 18

TotalF: 20




𝑋 = 1 −2

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-

Modificados

Fa- Añadido Fe-

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.


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


Donde,

FuncionesCambiantes = número de cambios a funciones o módulos que tienen

comentarios confirmados

TotalF = total de funciones o módulos modificados


Entre más cercano a 1, más registrable. 0 indica un control de cambios deficiente o

pocos cambios y alta estabilidad.

Aplicación



funciones que requieren cambios se encuentran las siguientes:

FUNCIONES QUE REQUIEREN CAMBIOS

1 Calcular nómina

2 Asignar Rutina

3 Realizar Reserva



6 Consultar Rutina


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

Registrabilidad de Cambios



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


𝑋 = 1 −7

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 herramienta

Descripción

Architect Enterprise

8.0 Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.

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

Office 2013 Middle CASE (M-CASE), herramientas para automatizar tareas en el análisis y diseño de la aplicación.

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.

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.

http://es.wikipedia.org/wiki/Software_de_administraci%C3%B3n_de_proyectos




Recurso Cantidad Descripción

Computador portátil 1 Computador con 3 Gb de RAM Core i3 Sistema operativo Kubuntu 14.04

Computador de Escritorio

1 Computador con 4 Gb de RAM Pentium Dual Core Sistema operativo Windows 7

3.10 Configuraciones de Pruebas de ambiente

Nombre de Configuración

Descripción Implementación de la Configuración Física

Prueba de Ambiente

PA-001

La Prueba de ambiente se ejecutara con el fin de medir todos los elementos físicos que influyen en el sistema, es decir todos los factores, tanto internos como externos que en extremas circunstancias puedan causarle alteraciones al optimo desempeño de la plataforma.

Dentro de un marco de ejecución del programa, teniendo en cuenta factores externos como la electricidad; y factores como la conexión con la base de datos

4 Entregables

4.1 Lista de Entregables de Pruebas

Entregable Descripción

Plan de pruebas

En este documento se plantea un enfoque global del plan a 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 unitarias

(Rendimiento o pruebas de Funcionalidad)

En este documento se evalúan las pruebas fundamentales definidas en el kit de pruebas que permiten evaluar el código del proyecto sistema de información web para la administración del gimnasio flex gym para con esto poder verificar el correcto funcionamiento de lógica y función.

Pruebas de integración

(Pruebas de Interfaces de Usuario)

En este documento se evalúan las pruebas de integración entre 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 administración del gimnasio flex gym, tenga cohesión entre el código y su interfaz grafica

Pruebas de aceptación

En este documento se evalúa el grado de aceptación del cliente 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 sistema o la pérdida de datos.

El error debe corregirse lo antes posible. El error bloquea el progreso en esta área.

2 El error causa problemas graves en la funcionalidad u otros aspectos importantes; el producto se bloquea en casos poco claros.

El error debe corregirse antes del lanzamiento del producto.

DOCUMENTO DE INGENIERIA DE SOFTWARE · PDF fileCompletitud El grado en que se ha conseguido la...

Documents

Transcript of DOCUMENTO DE INGENIERIA DE SOFTWARE · PDF fileCompletitud El grado en que se ha conseguido la...